開発プロセスとしての伽藍とバザール - yojikのlog
わかりやすく、21世紀現在の言葉で、伽藍とバザールという対比を現実社会に当てはめると、もっとも近いものは、ウォーターフォールvsアジャイル だ。 artonさんが述べているように、伽藍とバザールは、OSSのアジテーション文書とかハッカー賛美の書ではなく、実際にはESRがFetchMailの開発をすることによって得たバザール方式開発プロセス*1のプラクティスを紹介するエッセイです。 コードをオープンにすることは必要条件であって十分条件ではない。コードをオープンにすることは、それ自体が目的じゃなくて素敵なソフトウェアを自然につくるための手段にすぎない*2。一般的な開発者の数百倍の生産性をたたき出すハッカー賛美などはどこにも無い。 いくつか興味深い部分をピックアップしてみましょう。 6. ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。 これは、XPな
[tech]GUI-MVCとWeb-MVCの違い - yojikのlog
一部でMVC議論が流行っていたので、自分のためにSmalltalk由来のMVC(以下、一般化してGUI-MVCと呼びます)はWeb-MVCとどう違うか? という点についてまとめて見ました。突っ込みは歓迎。 あと本稿ではドメインモデル貧血症批判とかは全く盛り込まない。それは少し違うレイヤーの話なんです。 0. VCは大抵の場合、緊密に結びついたペアである GUI-MVCではView-Controller(以下VCペア)は不可分のペアだとされています。情報の入力(および制御)と出力ですから、お互い強く依存するのはあたりまえですね。MicrosoftのMFCとかJavaのSwingではVCはひとつのコンポーネントとして扱っています(Document-Viewパターンとも呼ばれます) ただ、この点についてはWeb-MVCでもそんなに変わらないかも。 1. GUI-MVCのView-Controll
![[tech]GUI-MVCとWeb-MVCの違い - yojikのlog](https://cdn-ak-scissors.b.st-hatena.com/image/square/b01b0c66c2194b2606fbb5505652ff3db80d0cdf/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729901763%2F12704830469097198255%2F1365590825)
RESTfulな設計とCRUDはちょっと相性悪いという話 - yojikのlog
http://www.infoq.com/jp/news/2009/08/CRUDREST 上記URLを読んで自分なりに例題を考えてみる。(todo:あとで状態遷移図を追加) RestBucks cafe 完全にオンライン化されていてWebAPIで注文できるというすごいカフェを想定します。(この手の例にStarbucksを使うのはGregor Hopeさん以来の伝統らしいです) 客側から見たユースケースはこんな感じ 客はレジのサービスを呼び出して、注文を入力して支払い 自席で注文状況をチェック、出来上がっていたら取りに行く。 注文というエンティティと、[注文編集] [支払い] [受け取り] という(アプリケーション)状態によって上手く表現できそうです。 (RESTfulだけど)CRUDな設計 CURDな設計では、リソースをURLにマッピングします。それに対してCRUDするというイメージです
なにがムカつくかというと、この人達が何の葛藤も悩みも見せないところ - yojikのlog
http://www.atmarkit.co.jp/news/200805/28/ipa.html まぁ記事のまとめ方の問題があるのかもしれませんが、このSI業界の重鎮達の発言が苛立ってしょうがない。 この人たちは何の悩みも葛藤もなく上から語る。何様なんだ!? 「若いうちは1つの仕事を与えられても、そこから全体が見えるようになるまでは時間がかかる。それでも、知る努力をしなければいけない」 「仕事をするときには時間軸を考えてほしい。プログラマからエンジニア、プロジェクトマネージャになっていく中で、仕事というのは少しずつ見えてくるものだ」 「本当に優秀な人は1人で何人分もの生産性を上げるのに、入社採用時はみんな一律のことが多い」という学生の不満には、 「本当に自分が売れると思う人は、そういう個々人のスキルが最大限に生かせる企業に行くといい」 「大きなシステムの構築などの仕事では、個々人の突出し
プログラミングは「設計」か「製造」か - yojikのlog
よく見ると、おおもりさんの記事だ。少し意外な論調な気もする。(via れごぼく) http://techon.nikkeibp.co.jp/article/TOPCOL/20070821/137958/ ソフトウェアをある程度製造(自動生成)する路線というのはアリだと思ってる。コンテンツっぽい部分はユーザが作成し、あとは自動生成に任せるとか。わかりやすくいえばRPGツクールみたいなイメージで。単純労働する人が減るのはいいことだよね。*1 でも、それでは真の意味での新しいソフトウェアは作れない。ソフトウェアの製造(自動生成)をおこなうためのソフトウェアを設計作成するのがエンジニアのメインの仕事になると思う。 いや、そもそも最初から、ソフトウェアエンジニアの仕事は、ソフトウェアを作ることじゃなくて、ソフトウェアを作るためのソフトウェアを作ることなのかも。 優秀なソフトウェアというのは、常に最終
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
