こんにちは、システム本部技術部たんぽぽGの森本です。 先日のmixi大規模障害の原因となったmemcachedの不具合の詳細な解明ができました。 再来週まで発表を見合わせようと思ったのですが、早くお伝えしたほうがいいと思いましたので公開発表致します。 memcachedとlibevent memcachedはlibeventというライブラリを使用してクライアントからの要求(接続、コマンド送信)を処理しています。 libeventを使用するにはevent_baseという構造体を用います。 main threadはmain_baseを使用します。 static struct event_base *main_base; ... int main (int argc, char **argv) { ... main_base = event_init(); ... /* enter the ev

「モダンなEclipse環境の構築方法」とかね。 2010-07-21 - marsのメモ 僕が書くのも場違いな気がするけど、とりあえず書いてみるよ。 Webアプリ作るという前提だとまずEclipse IDE for Java EE Developersをダウンロードしてインストールする。JDKは別途ダウンロードする。Tomcatも別途ダウンロードする。 JDKはWindowsの場合はデフォルトではProgram Files以下にインストールしようとするがパスに空白が含まれてるのが嫌なのでC直下とかにする。 Tomcatもインストーラを使わずにZIP版を解凍して、パスに空白が含まれていない場所にインストールする。 プラグインはSubversionクライアントとしてSubclipseを、プロパティエディタとしてちょま吉をインストールする。ここまでは必須。 DB使うようならDBViewerもイ

※ ここで言うプログラマは日本的な意味でのプログラマ。広い範囲を職能とする海外のプログラマは対象にしていない。 どうもプログラマという職業の評価というのは曖昧だ。営業マンのようにうまいこと数字で表せない。ロジカルな世界であるはずのプログラマという職業は、評価において非常にアナログだ。 何によって評価されているのか？ということがわからないと、人は迷走してしまう。 ゴールドマンサックスのリーダー養成担当であったスティーブ・カーという人が、「仕事に対するフィードバックが無いのはピンの見えないレーンでボーリングをやるようなものだ。結果を把握しないで仕事をしていると2つのことが起こる。1つには上達しない。もう一つに、どうでもよくなる。」と言ったそうだ。深い。 コーディング能力や言語の知識だけで評価されないどころか、その評価軸は半分以下であることは言うまでもないが、私の同僚の中でも有数のキレモノは、こ

[この発想はなかった] 専任のSubversionオペレータなる人がいるらしく、受理された申請書と変更ファイル(を入れたUSBメモリ)をSubversionオペレータさんに手渡すと、あとはオペレータの人が代わりにコミットしてくれるみたいですよ。

家電通販最大手のジャパネットたかた。同社における開発言語のメインはCOBOLだ。通信販売で取り扱う商品は日々追加され、客先でのセッティングといった付帯サービスも多様化している。情報システムを統括する星井龍也専務執行役員は、「こうした状況変化に迅速に対応するためには、COBOLの高い生産性が必要だ」と語る。（聞き手は井上英明＝日経コンピュータ、写真は林田大輔） メインの開発言語にCOBOLを据えていると聞く。 2008年1月、基幹システムをメインフレームからUNIXサーバーにオープン化するプロジェクトを開始する際に、「当社はメインの開発言語をCOBOLとする」と宣言しました。26人いる情報システム部員の全員が、COBOLを読み書きできるようにしています。それまでは、COBOLを読み書きできる部員は3人だけでした。 当社のシステムにおいて基幹となるのは、販売管理システムです。お客様からの注文や

全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ

先週末、ちょっとしたプログラムをGAE/Jで動かして実際に使ってもらってみたのですが、そうすると、いままでテストでちょこちょこやってたときには全部のDaily Quotaが0%だったものが、数%の数字を示すようになります。 これを、ちゃんとプロモーションして多くの人に使ってもらおうとすると、課金が発生したり制限にひっかかったりしそうです。 で、たとえばDatastore APIの呼び出し回数がヤバいとして、API呼び出しを減らすためにキャッシュしようとすると、MemcacheのほうのAPI呼び出し回数がヤバくなってきます。 で、じゃあということでデータストアにデータを置くようにすると、保存量の制約で課金がかかってきます。で、それならと、データストアに置くのはシリアライズしたデータにしてデータ量が最低限になるようにすると、今度はその処理をするためのCPU時間で課金がかかってきます。 コードを

だいぶ前の話になりますけど、「新人にデータ移行ツールのコーディングを任せるので、面倒をみてやってくれ」と頼まれたことがありました。 その新人はやたらとGoogle検索に頼る人で、とにかくわからないことがあると、わたしに聞かずにGoogle先生に尋ねるんですね。 検索サイトにはわたしもかなりお世話になっていますし、昔に比べるととても使い勝手がよくなっていますけれど、その人の技術レベルに対応して検索結果を出してくれるほど高機能なわけではありません。 そのため新人の書いてくるコードは、つぎはぎというかちぐはぐというか、身についてない知識に振り回されてる感が満載でした。 そういう弊害を気にしつつも、自分で調べようとする気持ちは尊重するべきなのかなあ、と思ってとりあえず黙認していたんですが、あるとき「ちょっと考えが甘かった」と思い知らされるトラブルが発生しました。 その新人が「Windowsのレジス

株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 偽装請負というのは、コの業界（古い隠語だけれどコンピュータ業界のことね）のいわゆる悪弊であったりするのですが、それぞれについて分からないというお話や勘違いしてることも多いかと思うので、ちょっと整理してみよう。 ● まずは言葉の意味から ■ 請負契約 納品物に責任を負う契約。つまり、成果物が完成しなければ報酬はもらえない。どのように作ったかは個別に契約していない限り問われない。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。 ■ 委任契約（準委任契約） 作業に責任を負う契約。ちゃんと作業をしていれば（善管注意義務を果たしていれば）成果物がなくても報酬がもらえる。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。 ※ ここまでを分かりや

無料なのは間違いないが、（おそらく）最速にしてあるところがミソ。 魔法使いに必要なもの 基本的なRubyの知識 基本的なhttp, htmlに関する知識 Googleアカウント 魔法使いに必要でないもの 自宅サーバ レンタルサーバ MVCとかDBとかの知識 前提 アプリケーションはGoogle App Engine(Java)の上で動かす JRuby+Sinatraで構成。JRubyはJava仮想マシン上のRuby実行環境のことで、SinatraはRubyの超お手軽・軽量Webフレームワーク。 そんじゃあ始めます。俺の環境がLinuxなので、WinやMacを使ってる方は適宜読み替えてね。 １、まずGoogle App Engineのアカウントを取得する。アプリケーションを適当に登録する。 Googleのアカウントがない人はまずそこから。既に持ってる人はGoogle App Engineに登

「情報システム関係の人とかこれ見とくといいよ - チョコっとラブ的なにか」と「パフォーマンスベース契約関連の話の続き・その1 - チョコっとラブ的なにか」の続きの話です。 id:andalusia さんとのやりとりで、 これ、どうやって工事進行基準やるんだ？ というブコメに対して、私がちゃんと調べないで感覚的に答えてしまって申し訳なかったのですが、その後、8/3のエントリでは、下記のように追記しました。 対価の額に関する定めの一部又は全部が将来の不確実な事象に関連付けて定められている場合で、かつ、信頼性をもって見積ることができるものについては、パフォーマンスベース契約でも、工事進行基準の会計基準となると思います。 ただし、信頼性をもって見積ることができないものについては、工事進行基準にはできず工事完成基準となるということだと思います。正確な見積もりができるかどうか、という点にかかっています

答え 約2000人月 開発の流れ 要件定義 顧客の発注を受ける １次請け、要件定義書の執筆を始める １次請け、顧客と交渉し、家の中に繋がっている家電製品を全て調べ上げる 一次請け、基本設計実施要領の執筆を始める 基本設計 この工程は、２次請け以下には秘密裏に行われている 詳細設計 １次請け、詳細設計実施要領の執筆を始める １次請け、だいたいこのあたりで２次請けへと乾坤一擲 ２次請け、使用する規格やフレームワークなどの部品を選定開始 詳細設計書の執筆がスタート、電球の大きさや重さ、丸み、光度、味、匂いなどを定義する このあたりで、既に５次請けくらいまで仕事が割り振られている 製造 １次請け、製造工程実施要領の執筆を始める １次請け、単体テスト実施要領の執筆を始まる ５次請け、電球フィラメントのくるくるを手で作成しはじめる ４次請け、求める匂いが上手く出せないと３次請けに駄々をこねる ３次請け

こんなの出てたから、見ておくといいかもね。 経済産業省では、情報システムの取引において、現行の「人月方式」以外での価格決定方法を模索するため、情報システムの付加価値に着目して価格を決定する「パフォーマンスベース契約」について検討を行ってまいりました。 今般、「情報システムのパフォーマンスベース契約に関する調査研究」報告書として取りまとめましたので、公表いたします。 「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について - 経済産業省 本文のさわりにはこんなことが書いてあったよ。 1 はじめに 1-1 背景と目的 我が国の情報システム市場は、現在、主として「人月ベース」の価格表示を行っており、それに伴う価格の根拠がユーザ側の価格への不信感につながっていることは従来から多数指摘されている※が、残念ながら、この課題は現在まで業界全体として抜本的に解決されるには至っていな

ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの

こんにちはこんにちは！！ プログラミング言語とかマスターしてると、なんかかっこいい感じですよね！ 就職とか転職にもバッチリ有利そうだし…！ だけど難しいよね、言語とか…。 入門書とかどれだけ買ってみても毎回 Hello world どまりだし…。 なんでなんだろう？ なんでうまく覚えることができないんだろうね。 世の中には、ちゃんとプログラミングできる人がたくさんいるのに…！ うーん。 たぶんこれかな… なにか作りたいものがある または なにかを作る必要がある なんて状況以外で、マトモにプログラミング言語を習得してる人って ぼくほとんど見たことないんだけど、みなさんはどうでしょう…！ たしかに、コンピュータを教えてくれる学校に通って、ちゃんと教えてもらえればJavaだってなんだってしっかりと、その時だけは身に付くんだけど、 でもそういうのって、ほんとに「その時だけ」なんだよね…。ほとんどの