確率的に犠牲的 - steps to phantasien
Martin Fowler が Sacrificial Architecture と言い出した時は驚いた。“変化を受け入れよ” はどこにいったの。書き直しはダメと自分の中の結論が出たのは随分前のことだけれど、ひさしぶりに考え直してみる。 Sacrificial Architecture の論拠として Martin Fowler はいくつかのインターネッツ企業を例にとっている。でも一般化するには偏ってないか。それにこれら企業が面していたのはごく限られた種類の変化だ: 彼らはもっぱら性能不足と戦っていた。 機能の変化に強いコードは柔軟性の裏で性能を犠牲にしがち。機能の変化を捉えることに先鋭化した従来の Agility は性能要件の変化を必ずしもやり過ごせない。一方で存在感を増すスタートアップの世界では性能への期待が当たり前のように大きく変わる。だから Agile はあてにならない、堅牢なアーキ
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
例え話だけで解決に向かうのか? - 技術的負債論 - MassKaneko.Out
はじめに 以下のエントリがHOTになっています。公開4日後の現在で949はてブです。 技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog 私は企業で Software Engineer in Test としてソフトウェアの保守性に責任を持つポジションに就いている身ですのでこのテーマに関心があるのはよいことだとは思います。技術的負債そのものについてのエントリは過去にも沢山あるようですが、mizchi さんのエントリは誤解を恐れないシンプルで断定的な書き方ですので多くの人に刺さったのでしょう。 ただ、技術的負債(technical debt)というメタファーが万人に誤解無く伝わるのかは疑問です。時間を借りているのかはピンと来ませんし、財務的負債と異なり返済の義務はありません。また、エンドユーザーに提供する価値よりも負債にフォーカスし
Takuto Wada on Twitter: "既存システムをサブシステム分割して段階的/定期的に刷新し続ける戦略について議論と説明をするときに、伊勢神宮の式年遷宮をメタファとして使うと通りが良くて助かる。伊勢神宮はアーキテクチャスタイルのリファレンスモデルであり、時を超えるためのパタンランゲージでもあるのではないか。"
既存システムをサブシステム分割して段階的/定期的に刷新し続ける戦略について議論と説明をするときに、伊勢神宮の式年遷宮をメタファとして使うと通りが良くて助かる。伊勢神宮はアーキテクチャスタイルのリファレンスモデルであり、時を超えるためのパタンランゲージでもあるのではないか。
トヨタの急加速事故は欠陥だらけのファームウェアが原因？――原告側調査の詳細
トヨタの急加速事故は欠陥だらけのファームウェアが原因？――原告側調査の詳細：ビジネスニュース 企業動向（1/3 ページ） 2007年に米国オクラホマ州で、トヨタ自動車の乗用車「カムリ」が急加速したことによる死亡事故が発生した。事故をめぐる訴訟において、原告側証人として事故原因の調査を行った組み込みソフトウェアの専門家は、裁判で「カムリのエンジン制御モジュール（ECM）のファームウェアに重大な欠陥が見つかった」と報告した。 2013年10月24日、トヨタ自動車の乗用車の急加速による死亡事故をめぐる米国オクラホマ州での訴訟において、陪審団は同社に対し賠償を命じる評決を下した。なお、本訴訟は、10月25日に和解が成立している。 この事故は、2007年にオクラホマ州で、2005年モデルの「カムリ」が急加速し、運転者と同乗者の2名が死傷したというもの。運転者ら原告側は、運転者の意図しない急加速（UA
ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国
えっらそうに大規模開発を語るような立場じゃないんだけど、何かと話題のこのへんの記事を読んでいろいろと日ごろ思うところがふつふつとわいてきたので……。 Life is beautiful: 特許庁のシステム開発が破綻した本当の理由 Fumi's Travelblog: "費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた 特許庁システムのことはそれなりに話題で、日本についてから何度も話にあがってきている。まあ不祥事だのなんだのって話もあるがそれはおいとくとしても、設計段階で60人体制ってだけでも多すぎるのに、増員で1300人体制とか……。設計を穴掘りかなにかと勘違いしてるとしか思えない対策でそりゃまあ破綻するよなあと。 それからね、中嶋さんの記事のコメント欄に書き込まれてた、よく言われる大規模開発でのこのへんの話。 SIerが開発を行う場合、この1
もっと車輪の再発明をしよう - ビスケットのあれこれ
以前，若い人と話をしていたら何かを躊躇するような発言があって，聞いてみたら「それは車輪の再発明になっちゃう」ということを言っていた．どうやら，最近の若い人たちの間では車輪の再発明を極端に怖がるような流れになっているようだ． 車輪の再発明はなぜいけないのか．Wikipediaによるとライブラリがあるのにそれを使わないと互換性が無くなるから，といったことが書いてあったがこれは，車輪の再発明なんかではない．そもそも車輪というすごい発明に対してライブラリなんていう誰でも思いつくものと比較するのは車輪に対して失礼だ．ライブラリを活用しないでオリジナルのライブラリを作っちゃうとソフトウェアのメンテナンスが大変だという現象は，そういう名前を付けて止めるようにすべきだ．車輪などといったすごい発明を借りるべきではない． 確かにソフトウェア工学的にはライブラリの再利用をしないのはよくないことだけど，ちょっと検
リアクティブプログラミングが世界中のソフトウェア技術者の９５％に普及しないと考える理由と今後に対する期待 - おろかな日々
id:pokarimさんの日記エントリなぜリアクティブプログラミングは重要か。 - Conceptual Contextureにブックマークコメントをつけたら、twitterでお返事をもらいました。なぜ自分はああ考えたか、丁寧にフォローしてもらったのでそこにきちんと返事をしたい。それにはちょっと、twitterだとツライなと。１４０字で区切られるのは、ちょっと不便すぎる。 という事で、元記事に対して自分の考えを整理したうえで、なんであーゆーブックマークコメントになったのかを説明してみよう、という主旨のエントリです。 最初のブックマークコメントの、もうちょっと細かい説明 元記事は↑のリンクを踏んでもらうとして、まず、私のブックマークコメントを引用してみよう。 面白いエントリ、面白い技術ではあるけど、大きな仕事にあつまる大勢の人達全てが、これを必要とはしない。世界中のPを書く人の5%程度の人に
複雑に絡み合うコード……プログラムの進化を視覚化すると大変なことに
プログラムを書いているとき、コードの量がどんどん増えていって規模も内容も訳が分からなくなってしまうことを俗に「スパゲッティ」と言ったりしますが、まさにその状態を視覚化したインフォグラフィックです。ApacheやPythonなど著名なオープンソースソフトウェアについてのものばかりなので図を見て「あーやっぱり」と思うことがあるかもしれません。 これらはカリフォルニア大学デービス校の研究者、マイケル・オガワ氏が制作したもの。それぞれのラインは開発者、横軸は時間を表し、上下のラインが近いほど、関係の深いコードの開発を行っていることを示します。 また対応しているブラウザでは、それぞれのラインの上にカーソルを置くとハイライトされます。 以下、クリックすると元のサイズのSVG画像が表示されます。 Webサーバーのデファクトスタンダード、Apache。最初の2年間はほぼドキュメント作りに費やされ、なかなか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
