詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある - L'eclat des jours(2014-03-11)
_ 詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある 流儀や呼び名はいろいろあるだろうが、ここでは3種類あることにする。 ・要件定義書 要件を定義したもので、ユースケースについて記述したものだ。 ・機能設計書 要件を機能として記述したものだ ・詳細設計書 機能を実装に落とし込むものだ で、詳細設計書って何それおいしいの？ ということだが、もちろん不味い。むしろ毒だと言うべきで、そんなものを記述するよりさっさとプログラムを書けば良いし、その時間を使ってテストプログラムを書けばさらに良い。 特に、1990年以降、オブジェクト（あるいはクラス）ライブラリが拡充され、APIがほとんどなんでもやってくれて、コンポーネントがそこら中に転がり始めてからは、単にそれらをグルーでつないでいくのがほとんどなのだから、そんなものを書いてもまったく意味がない。 しかし、実はそう単純でもない。 問
L'eclat des jours(2013-10-25)
_ WebMVCと設計パターン WebMVC（面倒なので以降はただのMVC。J2EEのMVCがSmalltalkのMVCと異なるMVCだということは既に10年以上の歴史があるのだから、今更どうでもよろしい）というのは、Transaction Script PatternとDomain Modelの間にまたがるスペクトラムだ。これがMVCの最大の特徴であり利点なのだが、なぜか、Transaction Script PatternとDomain Modelの両極端の声の大きい人が自分の視点を叫ぶ(実際に前者で声が大きい人はいない。彼らは沈黙のうちにコードを広める)。そこで混乱が生まれ、最悪のTransaction Script Pattern実装（貧血）と最悪のDomain Model実装（鬱血 ）が幅をきかせることになる。といっても、最悪のDomain Modelは普通は作れないのでそれほど
JavaScriptが難しいのではなくIEが難しくしてくれている - L'eclat des jours(2011-09-16)
_ JavaScriptが難しいのではなくIEが難しくしてくれている IE9で開発していて、次のように書いた。 var keywords = ['ab', 'cd', 'ef', ]; for (var i = 0; i < keywords.length; i++) { obj[keywords[i]] = getValue(keywords[i]); } で、動いたもので実環境へ持っていく。そこではIE8が動いていた。 ら、死ぬ。 不思議に思っていろいろ動かしてみたら、IE8では、[1,2,3,]は４要素（length == 4)、IE9では3要素（length == 3）ちなみにChromeも3要素ということがわかった。 はて、どちらが正しいのか。順当にはバージョンが新しいIE9が正しそうだ。かつ、そちらのほうが直観に近い。直観というよりも、JavaやCの印象からだけど。 int[]
エンタープライジーなREST - L'eclat des jours(2010-08-10)
_ エンタープライジーなREST オライリーから私が監訳（という作業を初めて経験したわけですが、それは別の物語）した、『JavaによるRESTfulシステム構築』という本が近々出ます。 JavaによるRESTfulシステム構築(Bill Burke) この本は、実にいろいろな面からおもしろい。おもしろいので、オライリーの編集の方に翻訳して出版する価値もあれば意義もあるとお勧めしたわけで、当然、読むことをお勧めします。 さて、何がおもしろいのか。一端は後書きに書いたけど、当然、書ききれない点や後書きに書いてもしょうがない点とかは省略しているので、そのあたりを含めて紹介します。 1. 著者がBill Burke これはおもしろい。というのは、BillはJBoss野郎なのだ。当然、CORBAからのORPC男。当然EJB。もちろんEJB3。 なぜ、そのBillが『JavaによるRESTfulシステ
手ぬぐいと納税者は絞れるだけ絞れと行政官は言った - L'eclat des jours(2009-07-03)
_ 手ぬぐいと納税者は絞れるだけ絞れと行政官は言った 流れよわが涙、と警官は言った (ハヤカワ文庫SF)(フィリップ・K・ディック) 昨日書いた後悔先に立たずの公開だが、ぶくまこめで「。与える情報を絞るのではなく、与えた情報を絞らせるように設計すべき。」に対する反応があって、それも正しい反応だと思った。もっとも2行あるのは例示のあやなので、ちょっとそこに突っ込まれてもとは思うが。 たとえば、次に示すBase64EncoderクラスのAPIは何がなんでもおかしい。 public class ComponentInfo { public byte[] getGuid() { ... } public byte[] getCpuInfo() { ... } } ... public class Base64Encoder { public String encodeGuid(ComponentI
5年後に後悔しないJavaプログラムの書き方 - L'eclat des jours(2009-07-02)
_ 5年後に後悔しないJavaプログラムの書き方 ここ数日、死ぬほど後悔しまくっているので、あらためて（というのは、数年前にも一度後悔しまくって、そのときの知見はあらかた処方箋とかコーディングの掟に書いているからだが）後悔しないための書き方をいくつか紹介する。 とにかく、ファクトリメソッドパターンを使うこと。 これは本当に重要。しかも簡単でありながら効果は絶大。 だめな例。 public class FooBar { private Connection conn; ... protected void setup() { ... conn = DriverManager.getConnection(url); ... } urlを指定することや、DriverManagerの実装を交換すれば良いだろうと想定していても（というか、Connectionならそういう方法もあり得るが、そうはいかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
