雑感 - masayang's diaryだが寝てない（笑
明日のためにその１：トランザクション処理に依存しすぎない - masayang's diary
最近いわゆる非RDBでちょいと苦労したので、この記事は楽しく読めた。一方で、この記事を勘違いして読み取って、やたらとロックかけまくるようなシステムを作り上げる人達が増えないことを願って、ちょいとメモ書きなどを。 DBの「トランザクション分離レベル」が必要な理由 （PostgreSQLで，ファントム・リードを防止すべきサンプル事例） 分離レベルがデフォルト（read comitted）のままだと，恐ろしい不具合が発生する。 この後簡単な例題があって「ね、ファントムリードって怖いでしょ」という話に進んでいるわけだ。でも考えてみよう。「ある瞬間に唐突に締めきって、その瞬間にお金を分配する」なんていう処理はあるのだろうか？ 商売の世界なら「締め時間」があり、それ以前に受け付けたものなら処理の対象になる、というのが普通であろう。そして午後3時に締めて、そのコンマ数秒後に結果を出さなければならない、
今日のシステム延命は向こう5年の技術的負債（しかも高金利雪だるま） - masayang's diary
相変わらずクラウド活用とAgile開発を売り歩く日々なわけだが。 企業のシステム投資周期は必ずしも景気循環周期とは同期してくれない。償却が迫り、老朽化が目立っているシステムのその後を検討する際に、外部経済環境が最悪で動くに動けない、という状況に陥るのは珍しい話ではない。 だからといって現行システムの延命を図ることが正解なのだろうか。 今延命を図ろうとしているシステムは少なくとも5年前の事業戦略・事業設計・システム設計を基準にしているわけだ。当時の事業戦略が今も有効である可能性は高くはないだろう。そこを無理して延命すれば、5年後に改修ないしは再構築が待っている確率は極めて高くなる。 その場合(5年前のシステムを延命して5年待った後): 基準となる事業戦略は10年前のもの。 それを継承する事業設計も10年前のもの。 システムとして具現化した基盤もアプリも10年前の設計・技術。 これらを熟知して
日経ITProの記事にケチつけておく - masayang's diary
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
設計書の意味をもう一度考えてみろよ - masayang's diary
katzchangのつぶやきで、オブジェクト指向開発を理解した開発者に、設計書は不要という両記事を知る。書かれていることは特に目新しくない。前から言われていることだし別にオブジェクト指向に限った話でもなかろう。→The Source Code Is The Design 2009年2月23日に書いた記事より再掲: 今更ながら「設計ができる」人に問いかける その「設計書」なるもので、本当にコード書けるの？ 「書ける『はず』」ってのは「書ける」のとは違うよ。 だが、はてぶに寄せられた意見にはなんだかな〜と思わせるものも目立つ。 これは一緒に仕事したくない人だ。UMLも書きたくないのかな →UMLからコード起こせるの？ Really? この記事は酷い。この著者は10年間で何をしてきたのか？偏った開発経験しかしていない気の毒な開発者。 →ただしい開発現場で経験を積んできたようにしか見えないが...
物事をややこしく考える人たち - masayang's diary
仕事の後軽く飲んで、帰りがけに外が青いコンビニに寄って買い物をしてきた。支払いはSuicaで。で、Suicaを何度も精算器に叩きつけるが受け付けてくれない。ひたすらバシバシとSuicaを叩きつける私にコンビニ店員は告げた。 「タッチパネルのSuicaアイコンを触ってください！！」 たしかにPOSレジの脇にある15インチくらいの液晶画面にはSuicaのアイコンが表示されている。そして、そのSuicaアイコンを触るとあ〜ら不思議。Suicaの精算器がカードを読み込んでくれて精算完了♪ だが待てよ。 私は店員にSuicaで、と精算手段を告げている。 液晶パネルにはSuicaアイコンしか表示されていない。 この状況において、客にSuicaアイコンを触らせる意味はあるのか？ そもそもカード読み取りの際にどこが発行したものか判断できないの？ ということで、なんでわざわざシステムとの対話フローを増やして
レガシーコードとどう付き合うか？ - masayang's diary
吉岡さんがレガシーコード改善ガイド読書会という勉強会を立ち上げた。レガシーコードとどう付き合っていくか、を議論していくらしい。可能なら参加したいが、ちょいと距離があるので中々難しい。 自分もこのお題目については色々考えてきたし、自分なりに実践もしてきたつもりなので、トラックバック送りながら意見などを... レガシーの定義 「テストがないコードはレガシーコードだ」という定義には100%同意。 我々は今この瞬間にもレガシーコードを簡単に書くことができる。 だけど、そのテストのないレガシーコードにも「レガシー度」みたいな尺度があるのではないかと。 レガシー度 といっても簡単に数値化できるようなものではない。 monolithic度合い。何千行とある関数とか、何百とメソッド持ってるクラスとか。 結合度、依存性などという言葉で表現されるアレ。 Interfaceの設計。変な値を渡さない工夫をしている
FriendFeedにおけるMySQLへの大規模データ格納 - masayang's diary
非RDBだのKey-Valueだのと騒がしい今日この頃ですが皆様いかがお過ごしでしょうか。私は元気です。先日、ベイエリアクラウド勉強会で教えてもらったHow FriendFeed uses MySQL to store schema-less data(FriendFeed流・スキーマレスデータのMySQLへの格納)を適当に翻訳してみますよ。(原文はCreative Commonsライセンス) 背景 FriendFeedではすべてのデータをMySQLに格納している。利用者の増加に伴い、FriendFeedのデータベースも拡大してきた。現時点では2億5000万件以上の記事が登録されており、これにコメントやお友達一覧のお気に入りなどのデータが加わる。 データベースの急成長に伴ない、規模に関する課題にも段階的に対処してきた。基本的な対処はおこなってきたつもりだ。具体的には、読み取り専用スレーブの
新生すばらしい！ - masayang's diary
週刊ダイアモンド2月20日号News & Analysis "金融庁検査で破談寸前？ 新生・あおぞら統合交渉の行方" 16ページより: 新生のシステムは、他の銀行と比べて「とても簡素らしい」というのは有名な話だった。 「インド人幹部が、ドキュメントも作らず一人で構築から運用、管理まで手がけており」 →これってシステムとしては最高の「あるべき姿」じゃん（笑 たぶん、インドで動いているシステムを日本に持ってきて適当にこちょこちょっと修正したのだろうけど、見方を変えれば「銀行のシステムはその程度でもよい」ということだろう。そういう本来大したモノではない対象に仰々しく体制を張り付け、無駄な仕事を創出してきた日本の金融系システム業界の化けの皮を剥ごうとした新生の姿勢は評価できる。 残念なのは新生自身が、長銀ゾンビに外資の皮を貼りつけただけだった、というところかな。 リーンソフトウェア開発と組織改革
今度の不況でSI業界が悲惨な状況に陥りそうな３つの理由 - masayangの日記（ピスト通勤他
釣り 題名に「３つの理由」みたいに数字を入れるとアクセス数が上がると聞いた。 本当かな？ 本題 自分がこの業界で景気後退を経験するのはこれで3度目。 一回目は1990年前半のバブル崩壊後。 二回目は2000年のネットバブル崩壊後。 今回のは1990年前半のそれを、規模・深刻さ共に凌駕すると予想している。 理由(1): 空洞化 「上流＝付加価値の高い仕事」という概念は根強く、開発という「核となる」行程を安い外部に流すようになってしまった。 レバレッジ効果があるから収益向上につながってきた。 が、新たな仕事が来なくなるとレバレッジは逆転を始める。 つまり、外部依存率を下げつつ、利益率向上を目指すという苦痛が待っている。 →開発を忘れた人達には無理。 理由(2): 分業化 1990年代初頭の情報処理試験は「二種」「一種」「特種」しかなかった。 今はなんだよ... 情報処理試験の中の人達に雇用機会
GSMの暗号が解かれた模様 - masayang's diary
PCWeek: Hackers Show It's Easy to Snoop on a GSM Call PCWorld: GSM Encryption Cracked, Showing Its Age BBC: Secret mobile phone codes cracked 日本では使われていない(が、世界では主流に近い)携帯電話通話方式のGSMに使われている暗号が解かれた模様。 この手の研究は多くの国で違法らしい。米国では電話盗聴技術の議論すらご法度なんだとさ。 が、弁護士の指導の元、違法とならないように研究したKarsten Nohl氏は、GSM通話に使われている暗号の解読に成功。既に2TBに及ぶ逆引きデータベースを用意したらしい。 現時点ではリアルタイム盗聴に必要なハードは３万ドル。 ムーア法則によれば、再来年には半額になる（笑 さてさて...GSM網に依存している国々はどう
ハッカー道場 - masayang's diary
上記写真は、福岡Rubyの皆さんと訪問したHacker Dojo。 Dojo=道場。 といっても、ここはハッキング技術を鍛錬する場所ではなく、「コミュニティ主導型起業支援施設」とでも呼びたい場所。 自治体が提供する起業支援(incubation)施設はシリコンバレーには数多いが、安くても家賃は$300-$400。 が、ここは「一人月額$100の会費制」。 これで 朝10時〜夜10時までの仕事場 入退室はそれなりに管理されているので、割と安心*1 ネットワークアクセス 電気、炊事場、トイレ ハードウェア工作のための各種機器を借りられる。部品のストックも豊富→部品納品待ちで時間をつぶす確率が減る 等などが得られる。 さらに... 同じ屋根の下に屈強なプログラマや起業家がいるので、意見交換や質問を気軽にできる。 良いネタならFounder Instituteの審査を経て、運転資金を投資してもらえ
金融システム開発終わりの始まり - masayang's diary
Naked Capitalism経由FT: Hidden costs emerge from the debris of Lehman crash リーマン崩壊からほぼ一年。 その債務処理にかかる費用が当初の予想を大きく越えそうだ、という記事。 理由はいつものあれだよ。 そう、システム保守にかかる費用が見積もりを大きく越えてしまったらしい。 理由は簡単。リーマンで働いていたシステム開発要員達がごっそり消えてしまった(evaporated)から。 破綻後に採用された人達は「仕様書がないからわからない〜」という、いつものアレで仕事が進まない、と。 雑感 金融のフロント周りって、トレーダーと開発者が渾然一体となって、どっかんどっかん開発を進めることが多い。 Agileの一派であるXPを推進してきた人達は、金融フロント開発出身が珍しくない。 高い利益を上げるトレーダーに、高い利益を生む開発者。 こ
権限委譲をしないことによる機会損失 - masayang's diary
日本からカンファレンス参加で出張している人と夕食。 そこでの話題。 アメリカのカンファレンスでよくやってるアンケート調査では、「役職」の他に「決定権」「予算権限」が質問される。こんな感じ。 機器発注に関するあなたの決定権限は？ 【最終決定権限を持つ】【提言するところまで】【助言するところまで】 機器発注に関するあなたの予算権限は？【1万ドルまで】【10万ドルまで】【100万ドルまで】 でも、日本の企業だとこれらがことごとく部長とかそれ以上の役職に集中しちゃうよね、というお話。 なんでも集中しちゃうから、その人達は短時間で物事を判断しなければならなくなる。 そのための説明資料作りで部下達は奔走しないといけない。 だとしても、短期間での判断を強いられるので、意思決定はどうしても「守り」に偏ったものになる。 こういう「資料作成とか説明にかかる時間」とか「保守的な判断に偏ることで失われる機会」とか
Agile失敗パターン三部作 - masayang's diary
Allan Kelly氏の「Agile失敗三部作」を適当に日本語訳してみた。 Agileで失敗する時 続・Agileでうまくいかないとき まだあった・Agileでうまくいかないとき 読めばわかってもらえると思うけど、「Agileだからうまくいかない」というわけではない。 未知の技術を採用したり、未知の領域のアプリを開発したりするような場合には、プロジェクトはそれなりの(把握できない)リスクを抱える事になる。だとしても、プロジェクト終盤で問題が発覚することが多いウォーターフォール型開発よりは、比較的早い段階で問題を把握できるAgileの方が有利ではある。ただしそれも、「問題が起きている」ということを把握できる実力がAgileチームにあれば、の話である。 二番目と三番目は、それぞれAgile計画管理、そしてAgile開発手法に特化した話だが、ぎゅっと圧縮すれば「経験がなければ問題が起きている事
労働強化！ - masayang's diary
昨今の年金問題で懐かしい言葉を耳にした。「労働強化」だ。 日本の某システムインテグレータで営業部隊のお手伝いをしていた頃の話。１５年以上前になる。そこで叩き込まれたのは「官公庁向け提案書では業務効率化を前面に出してはならない」ということ。そんなことをしたら、組合が「労働強化反対！」と騒ぎだして提案が通らなくなるから。じゃあ、なんのためにシステムを入れるのか？ 答：予算消化 単年度予算のお役所は、あてがわれた予算を使い切ることが極めて重要になる。そしてそこには効率化という概念の微塵もない。金をドブに捨てるとはまさにこのこと。まあ、おかげさまでシステムインテグレータも各ベンダも食い扶持には困らないわけだけど。 今日、労働強化という言葉を検索すると... 労働強化...2,230,000件 労働強化 年金...1,550,000件 新鮮な話題だからかもしれないけど、年金問題と結びつけているページ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チワワ＋シベリアンハスキー混血 - masayang's diary