信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
反復型モデルは速さとは真逆のプラクティスである。 - レベルエンター山本大のブログ
反復型vsウォーターフォールを新人教育で教えるときに、 あるゲームで体感してもらったんだが、現実にあるあると言える面白い結果になった。 結論から言うと、反復開発は速くはないということがわかった。 題材は、伝言ゲームである。 ■基本ルール ・５−６人で１チームを作り、最後尾の人がマジックと紙を持つ。 ・講師が先頭の人だけに絵を見せる。絵は以下のようなものだ。 ・先頭の人は、自分が伝言している間だけは何度でも講師の絵を見に来ることができる。 ・言葉だけを使った伝言ゲームによって順番に1人1人回して行く。 ・最後の人が紙に書き出しす。 ・制限時間は15分 ■ウォーターフォールバージョン 基本ルールに加えて以下をルールとする。 ・伝言のフローは1回だけ。1回で伝えきること。 ■反復型バージョン 基本ルールに加えて以下をルールとする。 ・伝言のフローは何回行っても構わない。 ・ただし、先頭の人を起点
ソフト開発をステップ数で見積っていることに疑問を持たなくてはならない - レベルエンター山本大のブログ
ステップ数を見積もり根拠にする会社さんは、いまだに多い。嘘じゃない。 お世話になってる会社さんもそういう仕組みをとってるところがあって、いいにくい部分もなきにもあらずだが、お世話になってるからこそいいたい。 そんなことやってちゃだめだと。 １キロステップの生産性指数をだして、今回の開発は10キロだから１０００万円とか。 汎用機時代ならまだ百歩譲ってわからんでもないけど、オープン系という言葉すら死語になりつつあるこのご時世において、ステップ数が１キロ（１０００行）だったら１人月とかどうこうという話は、もはや見積もりでもなんでもなく、こじつけだ。 フレームワークのコアのコードも、 ビジネスロジックの肝のコードも、 ネットワークの通信コードも、 自動生成したコードも同じ１ステップとカウントする。 見積もり時の計画ステップ数と、実際に開発したときの実績ステップ数を比較して 次の開発の値決め（ダンピ
SI開発におけるヒトとカネの話 - レベルエンター山本大のブログ
エンジニアやりつつ、経営や営業をやっている。 このところずっと思っていることがある。 ソフトウェア開発という仕事の成否について、 失敗するのは金の使い方によってであり 成功するのは人の集め方によってである。 プロジェクトは、開発プロセスや、フレームワークやツールやサーバや言語で成否が決まるんじゃない。 開発プロセスがどーのこーのとか、僕もよく言ってたけどね。 極論だけれどもアジャイルでもウォーターフォールでも、なんでもいいって。 プロジェクトは、それを動かす人が良ければ成功する。 言い換えれば技術や方法論は、どうあがこうが組織に溜まるのではなく人に溜まるんだ。 だから良い人に任せたい。 現場マネージャーの立場で考えると、プロジェクトを回すとき 自社の優秀なメンバーばかりで固められたらいいのだが、 優秀な人こそ案件を抱えてるのでうまくアサインできるとは限らない。 自社社員だけで足りない部分を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
