blog.katsuma.tv
クックパッドさん主催のRuby on Railsセミナーに参加してきました。Railsは仕事では利用していないのですが、CakePHPなんかはRailsと似たところがあるし、スケーリングの話なんかは参考になるところもあるかな、と思い参加。CTOの橋本健太さんのトークのみ、という内容だったのですがRailsに留まらない「クックパッドとしてのものづくりに対する考え方」は非常に興味深い内容がふんだんでした。以下、そのメモです。（誤字とかRails系の用語は間違っているものもあるかも、、） クックパッド 毎日の料理を楽しみにすることで心からの笑顔を増やす これだけやる！ 世界で一番！生活に役立つサイト作り 月刊ユーザ524万人 四国の人口よりおおい！ 20,30代女性中心 20代は４人に１人が見てる！ Railsサイト中世界８位（ユーザ数） 月刊PV2.8億 PV的にはRailsサイトで世界３位
アーキテクチャとは？ Grady Booch によると。。。：An Agile Way：オルタナティブ・ブログ
アーキテクチャとは何だろうか？この問いはいろいろな人に聞くといろいろな答えが返ってくるので、「リクルートの面接時に必ず問う」という人もいるはずだ。ソフトウェアと分野に限らなくてもよいし、さらに、システムという分野に限らなくても答えられる。 ぼくの知識の中で、もっともらしいと思われているのが幾つかある。 IEEE1471のアーキテクチャに関するコンセプチャルなフレームワーク これは、図のようなモデルで表現される。これは、かなりフォーマルに「アーキテクチャとは何か？」に答えているようだ。システムには１つのアーキテクチャがあり、１つ以上のアーキテクチャ記述によって記述されており、１つ以上のビューとモデルを含み、ステークホルダと関連している。ステークホルダは１つ以上の関心事をもっており、１つの視点は１つ以上の関心事をカバーしている。。。。。。」と読む（読めるか？）。 RUP RUPは、それ自身、「
GitHub - rietveld-codereview/rietveld: Code Review, hosted on Google App Engine
GitHub Wiki: https://github.com/rietveld-codereview/rietveld/wiki Google Group: http://groups.google.com/group/codereview-discuss This project shows how to create a somewhat substantial web application using Django on Google App Engine. It requires Python 2.7 and Django version 1.3 (although a previous version using Python 2.5 and Django 1.2 can still be found in the py25 branch in the repository)
ネットワーク側から見たヨドバシカメラ問題 - なぷさく
ヨドバシカメラのサイトがリニューアルに失敗してレスポンスが著しく低下している。ただでさえ重いところに、「ほらほらみてみて、重くなってるよ！見に行ってみてよ」なんてGIGAZINEが煽ったり、yahooニュースに飛び火したりしてさらにリクエストが増えて、瀕死の重病人いよいよまさに往生せんとす、といった雰囲気である。構築した会社は今頃針のむしろだろうし、ヨドバシ側の担当者もきっと現場からは「使い物にならんぞ！」と突き上げを食らい、上からは「なんでこんなところに依頼したんだ！」と怒られて社内キャリアはぶっ吹っ飛んだだろうし、まあ他人事ながら同情申し上げる。すでにあちこちで、CMSが腐ってるとか構築会社の社長がすごいとかいろいろ言われているが、基本に立ち返って外側から見える現象をひとつずつチェックしてみよう。1. DNSは問題なし大阪吹田にあるどっかの会社のサーバでDNS引いてみた。 $ dig
日本ＩＢＭを下請けが提訴へ 七十七銀の案件で追加費用を得られず経営破綻 - 工藤探偵事務所
普段読まない雑誌を眺めていてふと目に留まったのが、この記事でした。 あまりの悲惨さに他人事とは思えず、身震いしてしまいました。しかしながら、大小を問わず似たようなことは、いつ何処でも起きているのでしょう、たぶん。自分がこのようなことに係わらないようにするために、メモ書きします。 果たして、問題はどこにあったのでしょうか？ 一体誰が悪いのでしょうか？ 見かけた記事というのはコレです。 日経コンピュータ 2008/08/15号 ニュース SPECIAL REPORT 日本ＩＢＭを下請けが提訴へ 七十七銀の案件で追加費用を得られず経営破綻 『日本IBMからシステム開発を受注した地方ベンダーが、IBMに追加費用の支払いを求める訴訟を準備していることがわかった。開発規模が見積もりの7.5 倍に膨らんで4億円弱の予算超過となったこの下請けベンダーは、7月に民事再生法の決定通知を受けている。 「日本IB
レバレッジ経営・レバレッジ開発 - masayang's diary
ということで、リーマンブラザーズが飛んでしまった。 例によって「デリバティブ取引が悪い」などという論調もあるが、デリバティブだけが悪いのではない。 借入れた資金でレバレッジをかけて張っていたのが問題なのだ。 以下、かなり長文 レバレッジ 自己資金1万円で年利5%の運用をしても、利回りは5%。当たり前。 でも、5万円を年利2%*1で借りて、自己資金と合わせて5%で運用すると... 得られる利益は60,000*0.05=3000円 借入金に対する利息は50,000*0.02=1000円 差し引き2000円の運用益 自己資金10000円に対する利回りは20%! 低金利で借り入れて投資に回すことで、高い運用益を実現できる。これがレバレッジのもたらす恩恵。では、短期で借り入れる金利が上昇したらどうなるだろう？ 例えば上記例での短期借入れ金利が4%に上昇したとしよう。 5万円を年利4%で借りて、自己資
堀江貴文『ANAのシステムトラブル』
堀江貴文オフィシャルブログ「六本木で働いていた元社長のアメブロ」 一般的には、ホリエモンとか堀江とか呼ばれています。コメントはリアルタイムには反映されません。私にコンタクトを取りたいときは、info@takapon-jp.comへメールでご相談ください。 ANAのシステム障害、原因は「認証機能の有効期限切れ」 たまたま、この時飛行機に乗る予定があって、私が乗った飛行機はちゃんと飛んだのですけど、欠航したりしたら、嫌だなあとおもったりしていて、原因が発表されてた。役員を減俸したところで、再発防止策になるわきゃねーな、と。 この種のケアレスミス？は前の会社でも、たまにあって、たとえばドメイン名の有効期限が切れてたとか、SSLの認証鍵が有効期限きれてたりとか。大慌てで直して謝罪してみたいな感じで大変なんだけど、なかなかこういうのはなくならないね。 端末を扱う社員のITリテラシーが高いわけもなく、
戦略・戦術・目先対応 - masayang's diary
つば九郎さんのコメント経由、［XDev］「COBOLは現役バリバリ」，東京海上日動がシステム全面再構築でCOBOLを選んだワケ 5つのロジックと10の命令文で当社は30年間システムを保守できているからだ。 すばらしい... ウシと鋤だけで300年農業やってきたから、トラクターもコンバインもいらねーだ、みたいな。 30年システムに携わっているが，COBOLは規格として長期間安定し，ビジネスロジックの書きやすさにおいては右に出る言語はない そりゃCOBOLしか書けない人はそう言うだろうね。 自分なら「mutual stateなCOBOLほど、テストコードを書きにくい(あるいは書くのが不可能な)言語はない」と言うね。 ロジックの書きやすさだけで語るのは片手落ち。 システムは開発して終わりではない，いかにそれを高い効率と信頼性を保って保守していくかが欠かせない ならば当然テストは自動化されるべきだ
デザイナに eRuby を書かせるべきか否か - kなんとかの日記
masayang氏に、わざわざ回答をいただいた。ありがとうございます。 eRubyでXHTMLの大枠を記述するのはRubyエンジニア そのeRubyの編集をデザイナにも解放せよ デザイナがeRuby構造を壊したとしても、テストで検知できるし、最悪リポジトリから戻せるではないか 技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記 これは同意できる。 リポジトリの概念はCSSの階層構造を理解できるデザイナなら、すぐに習得できる 技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記 これはよくわからない。リポジトリと、CSSの階層構造は、似ているとは思えない。 デザイナが先にHTMLテンプレートを作成し、プログラマがそれを参照にeRubyを書くという古典的手法では、「先に画面デザインを確定させる必要がある」ということになり、A
2008-07-25
書籍を共著で執筆しました。本日発売です。 Webアプリケーションテスト手法 水野 貴明, 石井 勇一, 新藤 愛大, 岸田 健一郎, 荻野 淳也, 安井 力, 田中 慎司 http://www.amazon.co.jp/exec/obidos/ASIN/4839924309/yattom-22 Webアプリのテスト全般について、ツールと手法中心に幅広く紹介しています。 Perl ActionScriptとAS3Unit PHPとSimple Test Ruby on Rails Selenium ほか、スケーラビリティ、セキュリティ、ユーザビリティなどの話にも触れています。 私は今回Seleniumの章を担当しました。Seleniumは、ブラウザの挙動をユーザの操作をエミュレートしながらテストできるという、稀有な存在です。サーバーサイドからAJAXまでをカバーしてテストできるのはSelen
『EM ZERO』はじまったな, オブジェクト倶楽部2008夏イベント - 角谷HTML化計画(2008-07-01)
■1 『EM ZERO』はじまったな 『EM ZERO』は「エンジニア向けのフリーペーパー」だそう。gihyo.jpのエンジニアマインドのページとの関係や内部の事情は知らない(知りたいわけでもない。念のため)のだけれども、これはイイ。すごくいい。 編集長の野口さんによる「創刊のことば」を引用しておこう: EM ZEROはソフトウェア開発のあり方をゼロから考える新しいメディアです。人と技術に関するテーマを中心に、ソフトウェア開発の未来を切り開くヒントをゼロから探っていきます。また、作り手と読み手の関係を極限までシンプルに考え、ゼロ円、つまりフリーで提供しています。 EMにはいろいろな意味を込めています。エンジニアのE、エレクトロニックのE、エモーションのE。マインドのM、ミッションのM、メイドのM。一人ひとりの皆さんが想像していろいろな言葉を当てはめたり組み合わせたりしてください。いろいろな
6000人が作ったシステムは必ず動く：ITpro
最盛期の開発要員6000人，開発工数11万人月，投資額2500億円，取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ，勘定系システム一本化プロジェクトの成果物である。6000人のシステムズエンジニア（SE）が作り上げた巨大システムは，2008年5月の連休明けに必ず動くはずだ。 23年間にわたって情報システム開発プロジェクトの取材を続けているが，6000人のSEを集めた事例は過去に一度も見聞きしたことがない。世界を見渡してもおそらく例がないはずだ。これから何年間，記者を続けるのか分からないが，今回の三菱東京UFJ銀行を除けば，6000人を動員するプロジェクトを取材する機会は二度とないだろう。 6000人のSEが同時期に集まったのであって，「6000人月」ではない。開発工数は先に書いた通り，11万人月である。この数字も凄い。一体何を作ったのかと思ってしまう。正確にはこのSEパワーは開
三菱東京UFJ銀の一部障害、直接の原因は文字コードの設定誤り
三菱東京UFJ銀行の一部キャッシュカードが、5月12日の午前7時から約5時間セブン銀行のATMで使えなくなった原因が分かった。三菱東京UFJ銀のシステムからセブン銀のシステムに送信する取引結果データの文字コードに誤りがあり、セブン銀のシステムが取引結果を正常に処理できなかった。約2万件の取引が影響を受けた。 取引ができなかったのは、取引対象が旧東京三菱銀の店舗の口座で、かつ通帳に未記入の明細が10件以上あるときに限られる。この条件を満たす場合、三菱東京UFJ銀のシステムは、通帳記帳を促す案内文を取引結果データに加えて、セブン銀に送信する。この案内文はカタカナだけを使用すると両行で取り決めていた。 一方、三菱東京UFJ銀は5月10日の夜9時から12日朝7時までシステムを臨時停止し、旧東京三菱銀ベースの勘定系システムに旧UFJ銀の機能を追加した新システムを稼働するための切り替え作業を実施した。
『受託開発の極意』トークセッション - ちびかめ日記
会場はジュンク堂 会場はジュンク堂の喫茶室でした。 40人定員で60人以上いたらしく、かなりぎゅうぎゅう。 その分、トークをする先生方(ジュンク堂の人がそう呼んでいた)が近くに感じられる 雰囲気だったと思います。 いろんな人のトークセッションやっているみたいなので、 今度機会があったらまた行ってみたいと思いました。 トークセッション内容 変化がキーワード 角谷さんがこのセッションのきっかけを作った 池袋に生まれて、池袋に還る ジュンク堂は自分にとって大事な3冊の本と出合った場所。そこでこのセッションができるのは感慨深い なぜ受託？ 受託が得意 スーツでもギークでもない人がたくさんいる。その人達に誇りをもってほしかった 変化がキーワード 会社(永和)、仲間、自分、それぞれの変化 角谷さん⇒岡島さん 「リーダーだ！」 岡島さん⇒角谷さん 仕事を楽しんでいる(マーチンファウラーに会うから帰ります
アジャイル開発者の習慣―acts_as_agile：第4回 ドキュメントを大切にする｜gihyo.jp … 技術評論社
ソースがドキュメントだ。バグも完全に記述されている。 ――まつもとゆきひろ[1] はじめに 本連載ではアジャイル開発を「アジャイルに開発する人たち（アジャイル開発者）が開発するからアジャイル開発」と考え、アジャイル開発者に必要なスキルを磨くための習慣を紹介しています。 これまでの3回を費して紹介した「フィードバックを重視する」「仕組みを育てる」「スケール間に連続性を築く」といった習慣は、チームによるシステム開発の現場でアジャイルにプログラムを書くことを重視したものでした。 しかし、これでは開発対象となるシステムを構成する2つの要素のうち主に1つしか説明していません。2つの要素とは、プログラムとドキュメントです。今回は、これまであまり触れてこなかった、2つの要素のうちの1つであるドキュメントに関する習慣を紹介します。 そのためにまず、アジャイル開発者にとってのドキュメントの位置づけを説明
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Koichi Hirano's Weblog. About OneAgileTeam - Keepin' Agile Development real with Getting Real
Koichi Hirano's Weblog. PhotoShare Interview
テクノロジックアート技術者のブログ: オフショアにおける人材のアンバランス
http://neta.ywcafe.net/000938.html
Sign in - Google Accounts