この怪文書はクリエイティブ・コモンズ・ライセンスの元でライセンスされています。引用した文章など Kuwata Chikara に著作権のないものについては、それらの著作権保持者に帰属します。
朝起きたら心の折れる音を聞いたので今日はお休み。
前々からちょっと体のおかしい部分を診てもらう必要があるなと思っていたので、午後から医者行ってくる。どうも皮膚数ヶ所と関節がおかしなことになってるっぽい。
「これからは仕様を確定させてからでないとシステム開発は不可能です」だって? これ、ちょっとヤバいんじゃねえのか? 俺はこの辺の話は全然詳しくないが、直感的に以下の部分が特にヤバいと感じる。
もちろん実際にできるかどうかは別の話だが、実はそんな悠長なことを言ってはいられない。外部設計がしっかりできないと、2009年4月以降はSIビジネスに重大な支障が生じる。工事進行基準による会計処理が事実上、義務付けられるからだ。
進行基準ではプロジェクトの進捗状況に合わせて売上を計上するが、その進捗状況はコストで測る。従って、事前に原価総額を正確に見積もれなければならない。外部設計が確定していないと正確な原価総額なんか出せないから、要件定義や外部設計をいい加減にやっていると、システム開発の売上計上ができないなんていう事態にもなりかねない。
そもそも仕様を確定させるなんてことが全てのプロジェクトで可能なのかという話もあるが (俺はそれが出来ることがレアケースだと思ってる)、それよか元記事の「仕様確定を必須にする=プロジェクトの火種はほぼ消える」というのも怪しい。というかウソだろこれは。確かにユーザからの仕様変更は大変な火種になるけど、他にもソフトウェア開発上の火種はいくらでも転がっているわけで、そしてそれらの火種はユーザの仕様が固まっているかどうかに関係ない。ちょっと適当に書いていくと、
とか色々出てくる。あ、上の奴は全部今のプロジェクトで起こったことだ。
ところで工事進行基準ってのは初めて聞いた言葉だったのだけど、 exBuzzWord の工事進行基準によると、建設業とかで長期工事の際に進行状況に応じて収益を計上する制度らしい。といっても、俺にはイマイチよくわからんが。でもこれ、ソフトウェア開発にそのまま適用できる制度じゃないだろう。
あんまり不安感を煽ったりするのはどうかと思うけど、とりあえずちょっとこれは頭の片隅には置いとこう。
どうも Scribes は以下の条件で結構なメモリ食い虫になるようだ (きちんと検証してません)。
まあ、 Scribes は入力補助のためのサービスを立ち上げてその上マルチスレッドで動作していたりするので、確かに一つのプロセスでメモリをそれなりに消費するだろうな。
ところで Python ってグローバルインタープリタロックのせいでマルチスレッドではパフォーマンスがたいして上がらなかったよな。その点については Guido van Rossum の http://www.artima.com/weblogs/viewpost.jsp?thread=214235 とそこへのコメントが参考になる。ちなみに俺は Bruce Eckel による以下のコメントに同意だ。
We do need some kind of solution, but it probably shouldn't be threads. I think a process-based approach is probably best. I'd like to see if it's possible to, from within one cpython instance, easily start up a second one in a different process and easily communicate between them. Then you could use an agent system and the programming would become very easy and safe, while effortlessly making use of multiple processors. And no GIL removal would be necessary.
この怪文書はクリエイティブ・コモンズ・ライセンスの元でライセンスされています。引用した文章など Kuwata Chikara に著作権のないものについては、それらの著作権保持者に帰属します。