モデリングと設計の違い - masayang's diary
2007/12/21追記 「内部設計 見本」「外部設計 見本」などで検索に来た皆さん、残念でした。ここには見本はありません。でも、この書き込みに来たのも何かの縁。一度、外部設計とか内部設計とか、本当に必要なのか考えなおしてみませんか？ 詳しくは、下記本文で。 以下、本文 BMUF (Big Modeling Up Front)＝上流設計のインチキを斬るでは、敢えて「Modeling≒設計」みたいな感じで訳しちゃった。その後いろいろ考えたけど、BMUFは「先行設計」と訳すべきだったかもしれない。 辞書でmodel（動詞）を引くと、「見本を作る」というのがひっかかる。そして、おそらくソフトウェアにおけるModelingとは「見本を作る」ことであろう。 モデリング BMUF (Big Modeling Up Front)＝上流設計のインチキを斬る元記事で紹介されていたSketches of Fr
念入りな画面設計などやめてしまおう - masayang's diary
本日もAgile布教活動。 若手中心でAgileに挑戦しているチームを訪問。だが、状況を聞いているうちに「これはよろしくない」と思った。問題なのは画面の紙芝居で発注者と要件を調整していることだ。そして、きれいな画面設計書には「このボタンを押すとどんな処理が走る」「このリンクをクリックするとどこに飛ぶ」みたいな懇切丁寧な説明まで書かれている。 画面ベース開発の欠点 実際にプログラムを書かずに、利用者が使うことになるはずの画面見本を元に要件を固めていく。この方法が間違いとは言わないが、以下のような欠点を抱えている。 要件定義工程が膨らむ 画面に部品を描けば、必ずその部品が引き起こすイベントについて記述する必要がでてくる 結果、関連画面も芋づる式に記述していくことになり、検討する対象が増えてしまう 要件が硬直化してくる 検討対象が増えてくれば、検証にも時間がかかるようになる 運良く、漏れや間違い
Android G2はFiresheepの犠牲者となるか? - masayang's diary
最近、こんなFirefox拡張機能が公開された。→Firesheep パケットを拾って、そこからCookieを抜き出してFacebookなどの他人セッションを乗っ取れますよ、という触れ込み。同サイトにある画面コピーを引用。 もちろん、パケットを拾えない限り意味はないので 昔ながらのパケット垂れ流しHub 同じ筐体を共有したブラウジング(最近はあまりいない？) SwitchでわけられてもARP Poisoningでなんとかなる? 暗号化なしのWiFi接続 などの環境では、SSL保護されていないセッション識別用Cookieは盗み取れちゃうかもしれない。Firesheep作者は特にFacebookサイトにおけるセッション管理を問題視している。 ちなみに我が家のWPA2環境で 犠牲者(?)...Android G2 盗む側...MacBook Pro+Firefox+Firesheep という組み
San Francisco New Tech Japan Night - masayang's diary
10/13: SF New Tech & btrax Present: SF Japan Night! With Coopa, Drrop, GazoPa, Lang-8, myGengo, Spysee and More!というのに参加してきた。こういう起業系の集まりというのはなんか苦手なんよね。雰囲気は2000年ネットバブルを思い出させるものがある。ただし開催場所はパロアルトではなく、サンフランシスコ。事前にネットで予約しないと入れないとか、UStreamでの中継があるとか、10年一昔を感じさせる差もちらほら。 最初の2時間くらいはいわゆる人脈作りの場で、みんな飲み物片手にわいわいがやがや。今回は日本企業による発表が主役なので、日本人ならびに日本語を操る各国人が目立った。日本語がダメな人は当地の起業家かVCの人達か。 その後は「集団監視下における5分間エレベーターピッチ」みたいな感じで
明日のためにその１：トランザクション処理に依存しすぎない - masayang's diary
最近いわゆる非RDBでちょいと苦労したので、この記事は楽しく読めた。一方で、この記事を勘違いして読み取って、やたらとロックかけまくるようなシステムを作り上げる人達が増えないことを願って、ちょいとメモ書きなどを。 DBの「トランザクション分離レベル」が必要な理由 （PostgreSQLで，ファントム・リードを防止すべきサンプル事例） 分離レベルがデフォルト（read comitted）のままだと，恐ろしい不具合が発生する。 この後簡単な例題があって「ね、ファントムリードって怖いでしょ」という話に進んでいるわけだ。でも考えてみよう。「ある瞬間に唐突に締めきって、その瞬間にお金を分配する」なんていう処理はあるのだろうか？ 商売の世界なら「締め時間」があり、それ以前に受け付けたものなら処理の対象になる、というのが普通であろう。そして午後3時に締めて、そのコンマ数秒後に結果を出さなければならない、
Google I/O 2011申し込みサイトが残念だった件 - masayang's diary
本日公開され、あっという間に繋がらなくなったgoogle-io.com。何が悲しいって、申し込みページのURLが .cfm で終わっていた、ということ。これってCold Fusionかなんかで作った、ってことでしょ？ Google App Engineかなんかでやってほしかったじゃないですか。 $ dig www.google-io.com ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.google-io.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7467 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SE
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
自転車を発電機にする - masayang's diary
昨年購入したSolioを使えば、直射日光下約6時間でAndroid G2を50%ほど充電できることがわかっているが、今回日本を襲ったような災害では不安が残る。もっと効率よく発電できる仕組みはないか？ 自転車があるじゃないか！ ということで、調べてみた。自分はやや古いハブダイナモを使ったホイールを持っているので、こいつを使えばよかろう。室内で三本ローラー回せば発電できる。 製品 以下のような製品があるらしい。買えるかどうかは確認してない。欧州はこういうの好きみたいね。 (1) The Plug ドイツTout社 フロントフォークに統合されていて、配線すっきり。 149ユーロ (2) E-Werk ドイツBusch & Muller社*1 USBだけじゃなくて、出力端子を色々選べる。 139ユーロ (3) Universal Cable for AC Hub Dynamo 豪PedalPowe
今度の不況でSI業界が悲惨な状況に陥りそうな３つの理由 - masayangの日記（ピスト通勤他
釣り 題名に「３つの理由」みたいに数字を入れるとアクセス数が上がると聞いた。 本当かな？ 本題 自分がこの業界で景気後退を経験するのはこれで3度目。 一回目は1990年前半のバブル崩壊後。 二回目は2000年のネットバブル崩壊後。 今回のは1990年前半のそれを、規模・深刻さ共に凌駕すると予想している。 理由(1): 空洞化 「上流＝付加価値の高い仕事」という概念は根強く、開発という「核となる」行程を安い外部に流すようになってしまった。 レバレッジ効果があるから収益向上につながってきた。 が、新たな仕事が来なくなるとレバレッジは逆転を始める。 つまり、外部依存率を下げつつ、利益率向上を目指すという苦痛が待っている。 →開発を忘れた人達には無理。 理由(2): 分業化 1990年代初頭の情報処理試験は「二種」「一種」「特種」しかなかった。 今はなんだよ... 情報処理試験の中の人達に雇用機会
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
