ってどこにあるんだろうな、と何かの仕様書を見てふと思った。あんたの言っていることはmodelなのか？それともbehaviorなのか？modelとはそれ自身のbehaviorを含めてmodelなのか？静的なスナップショットか、動的な…アレ*1なのか？ああ、これっぽいか。大部…

「HTMLのテンプレートとコントローラ等の処理系を分ける」って言うのは開発で定石のように語られて、最大の根拠は「デザイナとプログラマが別々に開発できる」とされてる。だけど、StrutsやJSFの流れではJSPはより多機能になる方向が見えるわけで、前提がか…

何が違うって、何も違わないような。

通りすがり 2008/04/17 10:34 どうやら、「単体テスト」の認識も食い違っているようです。 このへんで私は退散します。 oredoco 2008/04/17 13:30 オレ認識の単体テストというのは、一般的だと思います。 http://d.hatena.ne.jp/oredoco/20080415/1208222548…

何を使っても、結局何でもできる ServletからJDBCとか、JSPからJDBCとか、ActionからJDBCとか、ClickのPageからJDBCとか、やりようによっては何でもできる。その辺りを規制しない。ってか、WEBアプリにデータ層は関係ない。そのフレームワークが解決する問題…

リクエストを受け付けるURIの定義 リクエストパラメータの検証と、そのオブジェクト化 リクエストに対応する処理の特定と、その呼び出し 返却メッセージ(HTML, XML, JSON, plain text, ...)の作成と、その送信 基本的に"pure Servlet" + "web.xml"っていうベ…

何らかのレベルの技術者を想定してるはずなのに、それが隠蔽されるため。JDK5.0の基本とServlet動作とJSP文法とEJB3.0を理解していれば、Ease of Development!!

とりあえず、2つの理由があげられます。英語読むのはだるいけど、そこは我慢の子。 図画が充実してるかも知れない 編集上の問題か、もしかして著作権的な問題か、日本語版に記載されていない図があることがある。 日本語版にはない。⇒Model View Controller …

確かに面倒ですよね。試験表だろうとxUnitだろうと何だろうと。いやいや、テストのメリットはわかりますよ。十分にわかります。でも、面倒なんです。 書くのが面倒 頭の中に入ってるし 動かせばわかる 作りながら動かしてるし 保守とか、心配しすぎだろ 今、…

「ソフトウェアの部品化」が失敗する理由という記事を呼んで。再利用は茨の道なんかじゃない。prototype.jsは？commonsは？wicketは？RoRは？大きさは違えど、みんな部品化され、広く利用されている。JavaとかRubyとかの言語レベルでも、広い意味では部品だ…

http://d.hatena.ne.jp/wasisan/20080420/p1という記事があったので、乗っからせて頂きます。個人的に丁度ホットな話題なのでー。 Model–view–controller - Wikipedia クラス図を見ると，これは上で言っているのと同じに見える．モデルからコントローラへの…

google:関数型言語 マップで検索すると、「map」も検索対象になるらしい。 微妙に便利かも。

根本的には関係ないはず。なのに、巷では開発プロセスは規模の大小の影響を受けるというような言質は多い。「アジャイルは大規模に向かない」って、真実かどうかは別として、聞いたことない人いないですよね。開発プロセスが理想に程遠いのか、それとも新し…

インターネットで手に入れられても良さそうなのに手に入らない情報まとめ - IT戦記の記事関連で。「インターネットで手に入れられても良さそうなのに手に入らない情報」をインターネットで手に入れようとしたアイデアが面白いと思った。で、ブクマコメントか…

ギークは新しい技術に目がないが、スーツは枯れた技術が大好きだから。 考察（蛇足） スーツはシステムを作らない人ということで、特にマネージャを指すと考える。ギークはシステムを作る人とする。直接部門と間接部門。*1で、スーツの主戦場であるマネージ…

確立したシステム開発プロセスが存在していないなら、必要です。枯れた技術を用いた枯れたプロセスで進めるなら、マネージャの負担は軽くなります。マネージャの負担は、枯れた技術に対する新しい技術の割合に比例します。

例えば、以下の業務を考える。この業務をシステムに落とす場合、どうする？ 営業部門は顧客から受け付けた注文書を元に、生産部門へ出荷指示書を発行し、生産部門は顧客へ指示通りに商品を出荷する。 「注文書にはどういう内容があるのか？商品、数量、納期…

設計書が標準化されればうまくいくという意見を見かけたことがあるが、自分はそうは思わない。設計書が標準化されたからといって中身が濃くなるわけでもないし、作ったり表現したいことは毎回違うわけで、万能な設計書なんてありえない。逆に標準化された設…

細部を作りこまずに抽象的な概要をコード化するって大事だと思うし、それがオブジェクト指向設計の醍醐味だと最近ようやく気付いたんだけど、プログラム＝具体的で詳細な実装で慣れきった人からすれば、意識の転換をしなきゃ難しかったりするんだよね。まぁ…

google:生活ができないより、1名様。どこがどうなって生活できなくなっちゃったのか心配だけど、そもそも生活できない理由をgoogleで検索する辺りが画期的な利用方法だと感心した。

だよなあと思うけど… - Kowの日記という記事から言及されたので、もうちょっと考えてみた。 それがダメなのかといえば、それでいいと思う。建築家が製図だけしてとび職やらないみたいに、そういうのはうまくやれればうまくいく方法なのだと思う。 設計をどう…

粒度の荒い要素まで含まなきゃ受領者に誤解されるかもしれないって、設計書として不完全ってことじゃなく？詳細な要件定義を依頼するって言うんなら、粒度の荒い要件定義を含んだ方がいいと思うけれども。

の部分がどうハマルかが勝負な気がする。

google:1バレル wikipedia:バレルによると、樽の単位から来ているそうな。

動作を追いやすいって方がメリットが大きいように、個人的には思う。

色んな意見を読ませて頂きまして、結局、設計書が設計書として存在するためには次の2点は欠かすことのできない要素なようです。 文脈 意図 んー、なんとも抽象的。上記2点に加え、読者が理解できることが設計書の条件だそうで。わかる。わかるけど！ とりあ…

到着記念。すべて日本語なので、ご安心くださいｗ http://www.ogis-swe.jp/process/am-res/am/artifacts/ モデリング（＝モデル化＝業務設計？）のtips。具体例があり、かなりわかりやすい。 からの抜粋らしい。 モデリング成果物の欄の順番は、粒度順や作成…

「上流工程」でユーザと要件定義するとき、ユーザと開発者が何回も会議したりして共同で作っていきますよね。ユーザが一方的に要件定義書を作るわけじゃないですよね。プログラム設計書を粒度が小さい要件定義だと解釈すると、設計者による一方的な設計書が…

仕様書やプログラムを書く大変さ - GeekFactory http://d.hatena.ne.jp/oredoco/20080415/1208222548 プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - yvsu pron. yas 上の方々の記事を読んで、その「プログラム設計書」って何な…

案外情報が少ない。 チュートリアルしかない。 旧バージョン情報が多い。全てノイズになる。 フレームワークの見通しがつかない。 やっぱりSQLに慣れてるからか。 2日しか試してないけどｗ 今後？ 具体的なライフサイクルの制御方法は？ 集計クエリなど、複…