状態設計から「なんとなく」を無くそう
ウォンテッドリー株式会社の社内イベント "Tech Lunch" で話した発表です。 プログラムには大小さまざまな粒度の「状態」が存在します。 状態の設計を工夫することで、コーナーケースの発生を抑止し、ユーザー体験を最適化することができます。 本発表では、私が普段どのように「状態」について考えているか、言語や環境を問わずできるだけ普遍的に使える形での言語化を試みます。本発表を通じて、「状態」をなんとなくではなく合理的に設計するためのヒントを提供します。 GoogleスライドのURL: https://docs.google.com/presentation/d/1PNzz69UV05HlKPuWGlooemnPslLbLKsyLwl3R4U_XqE/edit
Developer Productivity Engineering at Netflix
Should GET and POST be the only HTTP request methods used by developers?
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
「バグ」と呼ぶのをやめて、名前をつけてあげよう - blog.takuyasuemura.dev
ある日の午後、オフィスでサポートエンジニアとQAが会話していた。 サポートエンジニアは言った。「すべてのバグを直すことなんて不可能だ」。 QAはこう返した。「そんなことはない。バグとはただの考慮漏れだ。バグが市場に出るということは、テストするときになにかのパターンを考慮していなかった。ただそれだけだ。」 「その考えは素朴すぎる。例えば我々のSDKがユーザーの使っている別のサードパーティーのライブラリと相性が悪いことだってあるだろう。こういう組み合わせは無限にある。すべてを考慮することは出来ない。」 QAは更にこう返した。「それは 互換性 という別の問題だ。おれが言っているのは 機能性 に関するものだ。」 サポートエンジニアは尚も言う。「それにしたって、すべてのパターンをテストすることは出来ない。お前はテスターのくせに 全数テストは不可能 だという事実すら知らないのか？」 「わかった。同値分
マイクロソフトの調査にみるコードのオーナーシップと品質の関係 - mtx2s’s blog
ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ
変化に適応するソフトウェアアーキテクチャと組織構造への道程 - クラウドワークス エンジニアブログ
年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。crowdworks.jpの開発をしているプロダクト開発部部長兼VPoEの@hihats です。 本記事はクラウドワークスAdvent Calendar 2022 24日目の記事です。 我々の組織ではこれまでも技術的負債解消に取り組んできていましたが、今期（10月）よりさらに人と時間をそこに集中しています。これまでこのブログでも紹介されてきたようにRuby on Railsのモノリスとなっているcrowdworks.jpにおいて、フロントエンドのVue.jsへの移行は今年に入ってから着々と進む中、バックエンドのほうは保守性の低下からどう脱却していくかが手付かずに近い状態でした。 この本丸を攻略するにあたって、闇雲にリファクタリングしていくぞ！では到底うまくいきそうにない。まず「何故やるのか、何をゴールとするのか」の意識あわ
Good Tech Lead, Bad Tech Lead
A brief guide to tech leadership at Foursquare, inspired by Ben Horowitz’s Good Product Manager, Bad Product Manager. TeamworkGood tech leads act as a member of the team, and consider themselves successful when the team is successful. They take their share of unsexy grungy work and clear roadblocks so their team can operate at 100%. They work to broaden the technical capabilities of their team, ma
テックリードという役割
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
継続的なソフトウェア・アップデートのためのDevOpsベストプラクティス・アンチパターン / DevOps Patterns and Antipatterns for Continuous Software Updates
Cloud Native Days Tokyo 2020
Webサービスの障害対応のときの思考過程 - ぱいぱいにっき
起こってほしくはないのですが、あらゆるWebサービスは完璧に動作する状態を維持することは難しく、やはり障害対応・トラブルシューティングといった作業が発生します。 筆者は普段仕事で障害対応を不幸なことによくやるのですが、障害対応のスキルというのはスピードや判断の正確さが求められるせいか、今までやったことがある人・ノウハウがある人に集中し、それ以外の人は眺めるだけ・あとからログを見返すだけの状態によく陥ることがあります。 これはWebサービスを開発・運用するチームとしてみたときにそういった苦労が特定の人に集中するのは良くないので、それを緩和する目的として、筆者が障害対応時に考えていることを記述してみます。なお、これが唯一の正解ではないとは思っているので、ツッコミや、自分はこう考えているよというのを教えていただければ幸いです。 具体的な手法を避けて思考の方法を述べているのは、障害というのはパター
費用ゼロ円でリアルタイムなログ監視（ログのプッシュ通知）をしていく - uzullaがブログ
こんちわ、うずらです。 現在デプロイをしたいんだけど、できない、というつらい状態で待ち時間が発生しております。 世界の中心で愛をさけんでいますが、（検閲削除）なので、なにもできないストレスを発散しているともいいます。 本題、ログ監視 さて、みなさんログ監視していますか？特にFatalなログ監視というものは非常に重要ですね。 ログはデバッグログしかない、クレームがきてから対応すればいい、Uncaughtな例外を見ない、運用開始したら/dev/nullおくりにする、E_ALLあるいは-1ではない、といった方々におかれましては、ピンとこないかもしれません。 しかし、Fatalなログを監視することで、なにか発生した問題に先立って対応できるので（対応しないとしても、知っていて無視するのと、しらずに来るのは違います）、大変便利です。攻めの監視です。 そういったことが「いみわかんない」という方々には、残
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
同期エンジンの心臓部を書き換える
0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン（コードネーム「Nucleus」）をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着
運用を支えるためのログを出すにはどうするか？ #jjug_ccc #ccc_m3
JJUG CCC 2019 Fallで話した時のスライドです。
Learn to build secure and reliable systems with a new book from Google | Google Cloud Blog
Learn to build secure and reliable systems with a new book from Google In the new “Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems” book, engineers across Google's security and SRE organizations share best practices to help you design scalable and reliable systems that are fundamentally secure. Reliability matters for businesses throughout
[GitHub] ブランチの保護設定を活用しよう 【レビューが通るまでマージさせんぞ】 | DevelopersIO
ブランチを保護していますか？ master ブランチにマージしたらテストに失敗！ みたいな経験をしたことはないでしょうか？開発の中心となるブランチは、問題なく動作する状態を健全に保ちたいですよね。 GitHub では、リポジトリの設定にて ブランチの保護 が可能です。この機能を使うと、以下のような保護を実施できます。 CIが通らなければマージできない 他のメンバーからレビューを承認(Approve)されなければマージできない 特定のメンバーはマージできない 設定方法 ブランチの保護の設定は「Settings」の「Branches」から行うことができます。何もコミットがないリポジトリは、設定そのものが出てきませんのでご注意ください。 「Protect branches」セクションの「Choose a branch...」をクリックし、保護対象とするブランチを選択します。 ページが切り替わりま
![[GitHub] ブランチの保護設定を活用しよう 【レビューが通るまでマージさせんぞ】 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/fdcc20784930f9e696050408d2bf25b1fbfb0f9f/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F05%2Foctcat-eyecatch.png)
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
「FF6」の新たなバグを発売25年後に見つけたテスト技術者の腕前
遊びつくされたゲームからバグを見つけ出す着眼点 エディさんは「バグは何かの条件が重なったときに起こる場合が多い。バグを見つけるときの基本的な考え方だ」と言う。特に本来は重なることがない条件が重なったときには、ゲーム開発者が想定していない挙動が起こる可能性がある。この考え方に基づいて、シドタイマー持ち込みバグと別のイベントを組み合わせ、低歩数クリアの記録更新ができないか試したという。 バグを見つけ出す方法について、エディさんは次のように話す。「プレー中に発見することは意外と少ない。ゲームで遊んだ後に外出して歩いているときなど、ゲームをプレーしていないときに突然思いつく」。シドタイマーも雪の降る日、喫茶店からの帰り道でひらめいた。「頭の中でFF6のプレーを想像していると『このタイミングでこうしたら、こういう現象が起こるのではないか』とひらめく」（エディさん）。 ひらめいた仮説を基に実機で思いつ
「いい検索」とはなにか？ 検索システムのしくみと評価指標を解説
2019年2月26日、検索技術研究会が主催するイベント「Search Engineering Tech Talk」が開催されました。「検索」や「検索システム」にまつわる技術や手法を共有する本イベント。第1回となる今回は、3人のエンジニアが、現場の経験を通して学んだノウハウや、検索にまつわる知見を語ります。プレゼンテーション「『いい検索』を考える」に登壇したのは。株式会社リクルートテクノロジーズの内田臣了氏。一般的に用いられる検索エンジンの仕組みと「いい検索」の条件について解説します。講演資料はこちら 「いい検索」を考える 内田臣了氏（以下、内田）：よろしくお願いします。「いい検索を考える」というタイトルで、リクルートテクノロジーズの内田が発表いたします。 まず自己紹介なんですけども、内田臣了（しんりょう）です。 けっこう珍しい名前だと言われます。2017年に株式会社リクルートに新卒で入社し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マスタデータの管理と運用について
