A while back I argued on the Blue Site1 that "test-first development" (TFD) was different than "test-driven development" (TDD). The former is "write tests before you write code", the latter is a paradigm, culture, and collection of norms that's based on TFD. More broadly, TFD is a special case of Verification-First Development and TDD is not. VFD: before writing code, put in place some means of ve
Disclaimer: This post expresses my opinions, which do not necessarily reflect consensus by the whole Web Components community. A blog post by Ryan Carniato titled “Web Components Are Not the Future” has recently stirred a lot of controversy. A few other JS framework authors pitched in, expressing frustration and disillusionment around Web Components. Some Web Components folks wrote rebuttals, whil
Have you ever wondered what happened after CSS3? It’s common knowledge that we never saw CSS4 come after it, yet we have a plethora of new features that have no similar way of defining when they were introduced. The W3C CSS-Next community group is actively searching for better approaches for how we describe the evolution of CSS over time and identify feature sets as effectively as we did with CSS3
Level up your testing skills by learning directly from me! Read more Honestly, I'd never thought I'd be writing about this, but the matter of patching globals turned out to be one of those topics that a lot of engineers seem to misunderstand. Most of us don't do monkey-patching, and even fewer stay around those implementations long enough to witness their impact. All the more reason to talk about
2024.04.08 働き方 及川卓也PdMプログラミングプロダクト 前編に続いて及川卓也さんにプログラミング初学者向けの学習サービス『Jasmine Tea』のこの1年を聞く。リリースからちょうど1年が経った『Jasmine Tea』だが「実は思っていたよりうまくいっていない」のだという。未知の挑戦に課題はつきものではある。及川さんらはどんな課題にぶつかり、それとどう向き合っているのだろうか。 事前に立てた仮説のことごとくが外れたこと、それでもブレずに開発を続けられている理由、少し脇道に逸れて、生成AI時代のエンジニアに必要なことも伺った。 Tably株式会社 代表取締役 Technology Enabler 及川 卓也さん（@takoratta） 早稲田大学理工学部卒業、日本DECを経てMicrosoftに転職。Windowsの開発に携わり、その後Googleではプロダクトマネジメント
Software people are always all up in the XY problem: someone asks about how to do X when what they’re really trying to solve is Y. I find the YX problem much more frustrating: where software people decide that they want to answer question Y even though what someone asks is question X. I’ve seen a few different manifestations of this pattern: Respondent doesn’t know the answer to X, but does know t
Most articles explaining the benefits of GraphQL focus on advantages for the frontend: things like preventing overfetching, reducing round trips, and iterating faster. But GraphQL provides just as many advantages for backend developers, which is why I choose it by default for new APIs and why you should consider it, too. Improved communication The goal of building any API is to enable someone to u
I joined GitLab in October 2015, and left in December 2021 after working there for a little more than six years. While I previously wrote about leaving GitLab to work on Inko, I never discussed what it was like working for GitLab between 2015 and 2021. There are two reasons for this: I was suffering from burnout, and didn't have the energy to revisit the last six years of my life (at that time)I w
This was data was available via last year's update, but was somewhat buried. Going forward, I'll produce both as top-line guidance. The usual caveats apply: Performance is a deep and nuanced domain, and much can go wrong beyond content size and composition. How sites manage resources after-load can have a big impact on perceived performance. Your audience may justify more stringent, or more relaxe
あらためて、また思います。ぼくは、じぶんが参考にする意見としては、「よりスキャンダラスでないほう」を選びます。「より脅かしてないほう」を選びます。「より正義を語らないほう」を選びます。「より失礼でないほう」を選びます。そして「よりユーモアのあるほう」を選びます。
※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです： 法規制対応、標準化対応、その他公的なガバナンス要求へ
ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出ているものでは、 yrmcds: memcached クローンで、レプリケーション機能などを持つ usocksd: SOCKS4/5 サーバー & ライブラリ transocks: アプリのネットワーク通信を透過的に SOCKS サーバーにプロキシする透過プロキシ coil v2: Kubernetes の CNI ネットワークドライバ moco: MySQL を自動運用する Kubernetes オペレーター accurate: Kubernetes 上で namespace ベースのソフトマルチテナンシーを実現するためのソフトウェア などがあります。これらのソフトウェアの多くは、現役
今回は、（前回とは逆で）SOの付与を受ける従業員側の視点でスタートアップに参画する際にSOのどういった点に留意すべきか、という内容を記載したいと思います。 前回の記事で記載しましたが、SOはまだ資金的に余裕のないスタートアップが「会社の価値を大きく引き上げてくれる貴重な人財」を早期から仲間に迎え入れ同じ目標を向いて全力で走っていくための重要な手段です。 そうした貴重な人財がより未来を作るスタートアップに多く集まっていく一助として、従業員側がどういった視点でSOの設計を見るのが良いか、というポイントをこのnoteでお伝えできればと思います。 以下、SOについては様々な考え方がある中で、私自身の経験や知見に基づくところが大きいですが、SO付与のあるスタートアップに参画する際に確認しておいた方が良いポイントを重要な順に記載していきます。 ちなみに（読んで頂く前の大前提として、）スタートアップのS
執筆趣旨：イネーブルメントのモデルケースを示すナレッジワーク HR Manager 徳田です。 今回のDevelopers Blogは、エキスパート人材の活動を支援する「ナレッジスポンサーシップ制度」を紹介します。 ナレッジワークは仕事のイネーブルメント(能力の向上や成果の創出)をコンセプトとした企業向けソフトウェアを開発・提供しています。 コーポレート部門は「イネーブルメントのモデルケースを示す」をミッションとして掲げ、ナレッジワークがイネーブルメントを体現するモデルとなれるように組織作りに取り組んでおり、2022年10月-12月の3ヶ月間でも計8つの制度を社内リリースしました。 そのうちの1つが「ナレッジスポンサーシップ制度」です。 制度内容はシンプルで「世の中へのナレッジシェアのための社外活動について、業務時間利用や会社費用負担等を認めることで支援する」というものです。 制度はシンプ
Over many years, “DevOps” practitioners applied Theory Of Constraints to our problems, ruthlessly optimizing our delivery pipelines and practices. Manual release management? Hell no, automate that. Deployment? Automate that too. Image management? 🔨 No thanks. Rolling back after we trebuchet a flaming dumpster into production? Automated. Whatever low value activity we could find in the process of
charity.wtf charity wtf's about technology, databases, startups, engineering management, and whiskey. Lately I’ve been doing some career counseling for people off Twitter (long story). The central drama for many people goes something like this: “I’m a senior engineer, but I’m thinking about being a manager. I really like engineering, but I feel like I’m just solving the same problems over and over
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く