4年ほど前に「テスト駆動開発の経験」と題して記事を書いています。 テスト駆動開発の経験（1） テスト駆動開発の経験（2） テスト駆動開発の経験（3） テスト駆動開発の経験（4） テスト駆動開発の経験（5） 1978年に大学でプログラミングを始めてから、（「テスト駆動開発の経験（1）」に書いてあるように）2003年まで、私自身はテスト駆動開発を経験したことがありませんでした。 1990年代までのソフトウェア業界では、自動実行するテストを書いて資産として残していく習慣はありませんでした。手作業によるテストと目視確認というのが普通に行われていたのがソフトウェアのテストでした。テストコードが書かれたとしても、テストコードを手作業で実行し、目視確認が終わったら捨てるということが行われていました。実際、同じようなことを、Martin Fowler、Robert Martin、Joshua Blochが

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック 作者: Pete Goodliffe出版社/メーカー: オライリージャパン発売日: 2017/12/15メディア: 単行本（ソフトカバー） 間もなく発売されますが、先日紹介した目次に加えて、アマゾンでは以下のように紹介されています。 プログラマとしてのキャリアをスタートすると、構文や設計を理解するだけでなく、その他の様々な事柄を理解し習得する必要があると気づきます。 本書は、優れたコードを作りだし、人々と効率的に働く生産性の高いプログラマになるための考え方とテクニックを38のテーマで紹介します。 はじめに、コード1行1行の書き方、デバッグやエラー処理、コードの改善方法など開発現場でのコーディングを取り上げます。 次にコードを単純に保つこと、コード変更やテスト、リリースなどソフトウェアを開発する際の考え方や心構えを扱い

2000年にclibと呼ばれるC++用のライブラリーを開発しました。それは、今でも富士ゼロックスのデジタル複合機で1000万行を超えるコントローラソフトウェア（＊）と呼ばれる制御ソフトウェアで使われているライブラリです。メモリ管理機構とマルチスレッドプログラミング機構を統合したようなC++のライブラリです。 （＊）http://www.atmarkit.co.jp/ait/articles/1507/06/news009.html clibは、私がそのAPI仕様をすべて設計し、実装は他の優秀なエンジニア2名に行ってもらいました。API仕様には、防御的プログラミングも含めて、メモリ管理機構での細かな動作仕様も書いていました。 このライブラリに関して、忘れないうちに一連のブログ記事として書きたいと思います。しかし、記憶は嘘をつきます。したがって、事実とは異なった私の記憶の嘘が含まれているかもし

普段英語を話す機会は全くないのですが、リスニングは継続的にながらで行っています。主にはニュースを聞いていることが多いです。 毎日、朝起きて見るのは、NBC Nightly Newsです。朝見ると一日遅れだったりするのですが、映像と共に米国のニュースを知ることができます。 通勤の時には音声だけのPodcastをiPod Touchで聞いており、次の二つです。 BBCの「Global News Podcast」 NHKの「English News - NHK WORLD RADIO JAPAN」 BBCのニュースは、イギリス英語に慣れるためにも聞いています。NHKは、日本のニュースを英語で伝えています。 BBCとNHKで聞くニュースがなくなったら、音楽を聴いているかKOITを聞いていることが多いです。KOITはサンフランシスコにあるFM放送局であり、基本的に音楽が流れていますが、サンフランシス

UUUM社の採用に関するブログ「優秀なエンジニアを採用するために面接で気をつけていること」でエンジニアの学習に関して次のように書かれています。 採用を決める時の一番重要なポイントは実力ですが、20代の若い方は将来性を期待して、ポテンシャル採用をすることもあります。 ポテンシャル採用で重要なのは、なんといっても向上心。 「いろんな技術を勉強したいんです」というのは誰でも言いますよね。 本当にそう思っているのであれば普段から勉強しているはずなので、中身をちゃんと理解できているのかを確認させてもらいます。 20代に関しては、現時点での実力が多少低くても採用します。 その代わり、しっかり勉強してもらって、ちゃんとした技術力を身につけてもらいます。 30代になってくると、やはり実力が求められます。 10年近くもエンジニアをやっていながら、技術的な知識の薄い人が多いのには驚かされます。 それだけ長い時

デバッグの基本的な方法については、「デバッグの科学的手法」に説明しています。それに関連して、デバッグでは、正しい知識を持っていることが重要であると「デバッグを支える知識」で述べています。 デバッグにおいては、知らない部分を適当にきっとこうだろうと断定して進めるのは危険です。たとえば、fopenとfreadを使用して1バイトをハードディスク上のファイルから読み込むことを考えてみてください。この場合、具体的にどのように読み込まれるかの仕組みを知らないのに、「最初の1バイトの読み込みでハードディスクから1バイトだけ物理的に読み込まれる」と仮定するのは非常に危険です。 この場合、ハードディスクからOSを経由してどのようにして読み込まれるのか知らないのであれば、「どのような仕組みで読み込まれるか分かっていません」という認識することが重要です。つまり、分かっていないからさらに調べたり学習したりする必要

「ソフトウェアエンジニアの心得」教育や講演では、論理的思考ということで、デバッグのやり方について話をします。しかし、その方法についてはスライドを準備せずに口頭で話をしてきました。本書の28章では、その点に関して、上手くまとめてありましたので、紹介します。 1. プログラムの失敗を観察する 2. 観察と矛盾しない失敗の原因についての仮説を立てる 3. 仮説を使って予想する 4. 予想を実験でテストして、さらに観察する a. 実験と観察が予想を満たすなら、仮説をさらに精緻なものにする b. 満たさないなら、別の仮説を立てる 5. 仮説がこれ以上精緻にできなくなるまで、手順3と4を繰り返す。そして、次のように述べられています。 あいにく、現状の対話的デバッガは科学的手法をサポートしていません。確かに、デバッガはコードをつついたり調べたりして自由に結果を得られる偉大なツールです。これはとても良いこ

ソフトウェア開発グループあるいはソフトウェア開発組織の開発スピードが遅いとか速いとはか、何を基準に判断するのでしょうか。 人が単純な作業を行わずに、自動化できる部分を徹底的に自動化した場合、残っている部分が本当の意味では、その組織での開発スピードです。 たとえば、システム全体のビルド作業を手作業で週に一回行っており、開発メンバーは、単体テストも書かずに、高残業をしながら一週間に多くの機能を実装したと報告する開発を考えてみます。もちろん、他のモジュールとのビルドもしていないし、ビルドするのは翌週の月曜日ということになります。これは、80/90年代によく行われた開発スタイルです。 一方で、Jenkinsを使用しながら継続的インテグレーションを行い、自動実行される単体テスト・システムテストを作成しながら、システム全体の機能のデグレードや副作用が起きていないかを常に検証しながら、開発メンバーがあま

今翻訳している本で、数多く引用されているので読みました。合気道が話題となっていますが、熟達するのに必要な事柄が述べてあります。古い本ですが、やはり、熟達への道は、合気道でもソフトウェア開発でも同じだと再認識しました。 マスタリーの旅は予想外の苦労や報酬をともなうだろうが、「最終的な目的地」に到着することはあり得ない（最終的に完全にマスターできるような技能は、たいした技能とはいえない）。

大学時代の私の恩師である重松先生の新刊です。C言語のプログラミング中級クラスの方を対象としているそうです。内容を見ていないですが、POSIX Threadによる並行プログラミングが書かれているのではないかと思います。 私がいわゆる並行プログラミングを学んだのは、アセンブリ言語でマルチタスクプログラミングをしていた大学時代を除けば、会社で学んだMesa言語によるものです。そうは言っても、Mesa言語でコードをたくさん書いた訳ではなく、既存のコードを修正・デバッグすることが主でした。 本格的なマルチスレッドプログラミングは、1993年からSolaris 2.3を用いてC++言語で行いました。主に、Solarisに付属するマニュアルで学習しながらプログラミングしていました。 開発がほぼ終盤になった1995年の暮れに、出版されたばかりの『Threads Primer』を読みました。それまでは、スレ

このブログを始めた頃に「40代、50代のプログラマー？」と題する記事を書いています。タイトルとしては、40代、50代ということなのですが、実は30代にも当てはまります。特に、30代後半です。 大学（大学院）を卒業して、10年以上が経過したら、30代後半になってきます。つまり、10年以上の経験があると期待される訳です。前述の記事の言葉を言い換えれば、次のようになります。経験年数10年以上相応の問題解決能力、解決に向けての提案能力、あるいはトラブルなどの的確な説明能力を回りの若い人達は期待する。当然、指示する側としても、そのような対応を期待する訳です。 ここで、注意しなければならないのは、同じ指示でも、新人への指示と10年以上の経験がある人への指示は、指示している側の「信頼残高」への影響が異なるということです。具体的な例で説明します。 あるエンジニアが担当しているソフトウェア開発に関して、進捗

APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行本（ソフトカバー） まもなく書店に並びます。序章「なぜ新たなデザイン本が必要なのか」の冒頭からの抜粋です。 みなさんは、「プログラミングの世界にはもう十分な数のデザイン本があるのでは」と思うかもしれません。実際、数多くの本があるので、なぜ私がもう1 冊書かなければならないのか（そして、なぜみなさんが読まなければならないのか）と疑問に思うことは当然です。特に、オブジェクト指向システムでのデザインパターンに関しては、いわゆる4 人組（Gang of Four）と呼ばれる人達が執筆した有名なDesign Patterns: Elements of Reusable Object-Oriented Soft

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 作者: Dave H. Hoover出版社/メーカー: オライリージャパン発売日: 2010/07/08メディア: 単行本（ソフトカバー）

「ソフトウェアエンジニアの成長カーブ」 最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事

2000年から技術書の翻訳を行うようになって、当初はピアソン・エデュケーション、そして、ピアソン桐原となりましたが、ピアソンからは13年半で11冊を翻訳させてもらいました。また、1冊ですが、自著も出版させてもらいました。 11冊の中で増刷を繰り返した書籍は残念ながら少なく、以下の4冊だけでした。 プログラミング言語Java第3版 プログラミング言語Java第4版 Effective Javaプログラミング言語ガイド Effective Java第2版 この中で、今日時点で、Amazon.co.jpで購入できるのは、『Effective Java第2版』だけとなってしまいました。 『Effective Java第2版』を除いて残り10冊は、書店の店頭在庫のみの販売となり、桐原書店から出荷されることはありません。『Effective Java第2版』は、今年4月に増刷しているので桐原書店の在庫

技術を完全に消化し、いつルールを破るべきか知っている。また、技術記事などを執筆している。さらに、中級職人以下の職人を上級職人にすべく、組織に対して教育・指導を行っている。 社内の評価というのは相対評価であり、ソフトウェアエンジニアとしてのキャリアパスを続けるためのモチベーションを維持するためには、外向きの活動が必要だということで、「名人」「匠」を定義しています。 このソフトウェア・スキル・インデックスを吉澤正孝さんと検討してまとめたのは、かなり前のことです。2007年に出版した『プログラマー現役続行』には掲載していますので、2005年か2006年に検討したのだと思います。 残念ながら、ここで定義されている「名人」「匠」のような活動をすることで社外からは評価されるようになっても、日本の多くの企業（特に大企業）では、社内からは評価されないかもしれません。その理由の一つは、名人や匠で定義している

Programming in Objective-C (5th Edition) (Developer's Library) 作者: Stephen G. Kochan出版社/メーカー: Addison-Wesley Professional発売日: 2012/12/14メディア: ペーパーバック 私にとって12冊目となる翻訳本の作業が1月末に終了しました。刊行日や日本語タイトル等は未定です。原著は第5版ですが、日本語版に翻訳されたのは今回が初めてとなります。 索引まで入れると500頁を越える本なので、私的な時間に行う翻訳作業は約9ヶ月を要しました。原著は、第5版で昨年12月出版ですが、翻訳は第4版で始めていて、途中で第5版が出版されたために第5版の翻訳となっています。 5年前に書いた「技術書の翻訳」では、高嶋優子さんの次の言葉を引用しています。 質が悪く、誤植の多い訳書があるのも確かです

How Google Tests Software 作者: James A. Whittaker出版社/メーカー: Addison-Wesley Professional発売日: 2012/03/23メディア: ペーパーバック

SEが20代で身につけておきたいこと (技評SE選書) 作者: 荒井玲子，深沢隆司，前田卓雄，柴田芳樹，三宅和之出版社/メーカー: 技術評論社発売日: 2012/09/24メディア: PDF