先週の水曜日（10月19日）に、アジャイル開発手法「スクラム」を学ぶイベント「Scrum Gathering Tokyo 2011」が都内で開催されました。 スクラムを実際に導入した事例として紹介されたのが「Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み ～組織と現場から～」のセッションで紹介されたヤフー株式会社の例。 同社は2名の担当者が中心となり、社内セミナーなどでスクラムに興味を持ってもらうことで社内の自主的な変化を促す一方、評価制度や内部統制などの制度を調整する担当役も置くことで制度面での変化も後押しするなど、スクラム導入の具体的な手法が紹介されました。 そのセッションの内容を紹介しましょう。 2名で分担してアジャイル開発の推進を開始 ヤフー株式会社 R&D統括本部プラットフォーム開発本部本部長 志立正嗣氏。 組織の立場から見て、どういう風にスクラムを導入してき

本日社内向けのTechTalkにて、並列・並行プログラミングに関する話を行いました。 昨今、プログラムの並列化はなくてはならないものとなっています。しかし、そのプログラミング環境は依然としてロックを用いたものが主流です。今回の発表の主張を端的に申し上げますと、 “Locks must go！” ということになります。並列プログラミングに銀の弾丸はありません。しかし、ロックは別の何らかの安全性を確保したプログラミングモデルで置き換えられなければいけません。そうでなければ、再現しにくいバグに苦しめられ、終電を逃す日々と決別することはできないでしょう。また、ロックによるプログラミングの抱える本質的問題にも言及しています。 この界隈の最新の動向として、去年OOPSLA’10にて発表されたConcurrent Revisionsについての解説も行なっております。また、弊社研究開発において、先日Con

最近あるMLでテスト自動化の目的について考える機会があったのですが、今回は整理としてそこで言及したことをまとめたいと思います。 色々な目的 よく言及されていますが、テスト自動化の目的は単に「人がやっていることをツールにやらせて楽をする」といったものに限りません。思いつくものでも、例えば以下があります。 繰り返し作業を効率化する 何度も繰り返す作業を自動化して、繰り返しによる作業重複分を効率化します。 継続的なテストの実現 テストの繰り返し実行を容易にして、高頻度の回帰テストを実現します。例えばCIへのテストの組み込み等を実現します。 素早いフィードバックの実現 継続的なテストの実現により、コミットといった小さな追加・変更のステップごとのテスト実行を実現します。これによりプロダクトやテストの追加・変更を小さな単位でテストをしつつ進められるようにします。 バグの早期検出の実現 頻繁な回帰テスト

開発に関わる種々の問題を抱えている状況はどこも似たようなものだし、開発者同士でアイデアを出し合ったり、上手くいった（行かなかった）事例を紹介すれば、互いに参考にしながら上手くやっていけそうな気もする。だから、商売云々の話は別として、開発現場での取り組み事例などは非常に気になるトピックスだったりする。 そんな事を考えつつ或る人と話をしていたら、その内容が強烈だったので差し障りの無い程度に紹介してみたい。 現場で使えない人間は退職に追い込む。わざわざ教育しなくても代替の開発者は他に幾らでもいる。 毎年xxx人を採用して、同じ数の退職者が出る。生き残った者だけが仕事を続けられる。 開発現場を回すのがマネージャの仕事。そのためには人月単価の安い下請けを使うことが必須だし、常に安い所を探している。 Excelさえ有れば仕様書を書けるし、人員計画、ガントチャートや進捗報告も作れる。だから、他のツールは

どういう訳か知らないけれど、日本の会社では「頑張って働く」という意味が「夜遅くまで残業して働く」ことと同じと思われているフシがあるように思う。作業時間にリニアに比例する仕事ならそのような関係が成り立つのかも知れないけれど、長い時間働けば当然疲れて能率は落ちるはずだし、その疲れが翌日まで残って業務に影響するのであれば、そもそも残業した意味なんて無くなってしまうはずだ。それなのに、残業を礼賛してやまない精神論重視の風潮が残るのは嘆かわしいことだと思う。 会社というところはつくづく不思議な場所だ。特に開発の現場では、いくら能率の悪いやり方をしていても怒られることが無いし、品質の低いアウトプットを出していても残業を続ける限り「頑張って働く良い奴」と前向きな評価が得られてしまうし、何もせずに会社に残っているだけで残業代というお金が貰えてしまうのだ。一体いつからこのような社会システムが構築されてしまっ

この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*1やlalhaさんにまで言及いただき大変光栄で、なにより多くの人に読んでもらえた。多謝。 一方で、自分で読み直すと「先のエントリ」は、いくぶん観念的でいまいちよく分からないところもあるかなと思った。というわけで、より実践に結びつきやすいように、「何に気をつければいいのか」「どういう考え方でコードを書けばいいのか」を書いてみる。 lalhaさんがエントリで強調したかったという (1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い への包括的な対策であり、 (2) たく

今週末は熱海の温泉に行ってきた。 行き帰りの新幹線で読んだJoel on Softwareは衝撃的に良かった。 この本はソフトウェア開発に携わるすべての人が読むべき本だと真剣に思う。 中でも第三章に書かれているジョエルテストが面白かったので、 これをアプレッソに当てはめて判定してみることにした。 現在のアプレッソでは、12のテストのうち、10項目が当てはまっている。 該当する項目が2から3の会社が圧倒的に多いということなので、 判定結果としてはかなり良い方だと思う。 しかし、今は導入した後でその効果を知っているから全面的に賛成できるのだが、導入する前は、 「今のままで特に大きな問題があるわけでもないし、 新しい方法を導入することにはリスクも伴う。 このままでも良いのではないか。」 という理由で導入を躊躇したものも多かった。 これらはどの項目についても、マネージャーがどんなに反対したとしても

プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ

「若手や中堅の優秀なエンジニアが、この一年で3人辞めてしまいました。来月もまた一人やめる予定です。いったい、どこに問題があるのでしょうか。」 あるSIerの経営者から聞いた話です。私はこう答えました。 「楽しくないからじゃないですか?」 先週のブログでも書きましたが、コンピューターが、まだまだこれからという時代は、コンピューターを導入することが、業務のイノベーションをもたらしていました。SIerがシステム・ハウスと言われていた時代です。まだまだこれからの時代ですから、新規の導入や開発が仕事を支えていました。また、運用・保守も時代を先取りした仕事であった様に思います。当然、新しい技術を走りながら取り込んでゆくことが当たり前の時代でした。 その後、情報システムが企業内で一巡し、業務で広く使われるようになるころには、ユーザー企業は膨大なシステム資産を抱えることになりました。そうなると、新規開発は

あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;

1級身体障害者が法律家を目指すブログだいちゃんです☆ 身体障害者1級　人工透析患者をやりながら法律家を目指してます。最終目標は弁護士です。 日常のことメインに書こうと思います。 ちょくちょく政治、経済、法律などの硬いことも書いたり、超ふざけた日記書いたりしようと思ってます(●´д｀●)

NEXTSTEP/OPENSTEP時代には、当面使わないアプリケーションをディスク上から削除せず書庫化したり圧縮処理（再パッケージ化）したりと、気の利いた機能を備えていた「Installer.app」。もちろん削除機能も装備され、パッケージはかんたんな作業でアンインストールすることができた。 Mac OS Xの時代に入り、パッケージ（.pkg）は手動でなければ削除できない――アンインストール用スクリプト付きの気の利いたものもまれにあるが――状況が続いた。これはこれでやむを得ぬ事情があったのだろうということで、とやかく言っても始まらない。 しかし、コマンドライン方面では変化が生じている。新設の「pkgutil」コマンドを利用すれば、インストールしたパッケージを“きれいサッパリ”削除できるのだ。ここでは、筆者に縁がないLexmarkのレーザープリンタ用ドライバを例に、その手順を紹介してみよう。

GNU screenはもう古いので皆さんtmuxへ移行しましょう、という話。Gentooならemerge tmux。 スクリーンショット 手元のtmuxを撮ってみた。縦分割モード。ウィンドウマネージャはawesome。左のircクライアントはweechat。 本家にもいくつかスクリーンショットがある。 tmuxへ移行する理由（メリット） 標準設定のままでもそれなりに使えるステータスバー 各ショートカットがコマンドベース（コマンドで操作ができる） 標準で縦分割機能搭載 GNU screenがたまに固まる問題（が発生するのは私だけ？）が発生しないかも ビュー専用のスクロールモード 柔軟なペイン制御 コピー＆ペースト用のバッファを複数保持できる terminfo的にscreen互換 メモリ消費量が少ない(GNU screenの約1/5) 一部機能でマウスが使用できる(mode-mouse, mo