1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」（※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→）
門脇 敦司/ Atsushi @at_sushi_ Knowledge Sense, Inc. CEO ← 東大 / エンタープライズ向け生成AIプロダクトで成長中のスタートアップ（2019年~） / ソフトウェアエンジニアを募集中（800万円~+SO）→DM開放中 / 好きな言葉は「実験と学習」/ 最新の生成AI 事情に少し詳しいです https://t.co/PwBZaT31cB 門脇 敦司/ Atsushi @at_sushi_ 1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」 （※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→） twitter.com/jasoncwarner/s… 2022-11-16 09:20:18 Jason Warner @jasoncwarner I'm convinced that o
『Joel on Software』を読んだ - 30歳からのプログラミング
Microsoft での勤務経験を持ち Stack Overflow の創業者でもある Joel Spolsky によるエッセイ集。 Joel は自身が運営するウェブサイト Joel on Software で多数の記事を公開しており、その一部を掲載したのが本書。 ひとつひとつの章がかなり短い（長いものでも 20 ページくらい、短いものだと 4 ページほど）ので気軽に読めるし、各章は独立しているので興味のある部分だけ読むこともできる。 技術そのものについて解説している技術書ではなく、ソフトウェア開発やソフトウェア産業についての著者の考えが書かれており、 Paul Graham の『ハッカーと画家』にテイストが近いかもしれない。 無料で公開されているエッセイ集をまとめたもの、というのも『ハッカーと画家』に似ている。 本書に収録されているのは 2000 年から 2004 年に書かれた記事なので
こんなテスト仕様書は書かないで - Qiita
はじめに これまでのテスト実施やテスト仕様書作成の経験を踏まえてこんなテスト仕様書は書いてほしくないという思いを伝えたいと思います！ その１ 操作方法が分からない システムの仕様が分かる人（自分など）向けにしか書かれておらず、詳細な操作方法が書かれていないというケースです。 テスト仕様書は必ずしも自分がやるとは限らないため、システムの仕様を把握していない人でも実施できるようなテストケースを記載すべきです。丁寧に書くと手間なのですが、結局この操作方法はどうやるのかという問い合わせが来る可能性が高くなり説明するのが手間ということにも繋がると思います。 Point 入社したての新卒でも分かるかということを想像しながら丁寧に記載する その２ 期待値が曖昧 例として「〜が正しいこと」のように人によって判断がブレてしまうケースです。 人によって判断がブレてしまうと不具合が生じていても正しい期待値として
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
