一か月前に「株式会社カウシェを退職します」を書きました。その時点で12月からの勤務先は決まっていませんでしたが、12月1日より株式会社令和トラベルで、嘱託社員契約でバックエンドエンジニアとして働きます。 勤務形態週4日（月曜日〜木曜日）勤務です。週4日勤務は、2017年9月から続けている勤務形態です。 オフィスは渋谷（カウシェの新たなオフィスの近く）ですが、基本的に自宅からフルリモートで働きます。実は、1年2か月在籍したカウシェには、入社前にオフィスへ行ったことはあるのですが、在籍期間中は一度も出社しませんでした。 9社目11月で64歳になり、令和トラベルで社会人になって9社目となります。 富士ゼロックス（1984年4月入社） 日本オラクル ジャストシステム 富士ゼロックス情報システム リコー ソラミツ メルペイ カウシェ 私の世代は定年まで1つの会社で働き続けるのが普通でした。実際、富士

4月に発売された「WEB+DB PRESS Vol.134」で特集1「実践API設計」を執筆していますが、そこから部分的に紹介します（目次は、こちらです）。 第1章「優れたAPI仕様とは何か --- よくある問題と記述すべき事柄」の冒頭で次のように述べています。 今日、多くの企業がWeb サービスとしてさまざまなサービスを提供しています。Webサービスは、iOS、Android、ブラウザといったフロントエンドと、それらに対して機能を提供するバックエンドサービスから構成されます。バックエンドサービスが提供するさまざまな機能はAPI （Application Programming Interface）として定義され、フロントエンドから呼び出されます。フロントエンドは、バックエンドサービスが提供する機能を使ってユーザーへ提供する機能を実現します。 定義されたAPI を介することで、フロントエン

Amazon.co.jpではまだ先行予約できませんが、私にとって通算20冊目となる翻訳本が8月上旬に発売されます。 『Go言語による分散サービス ― 信頼性、拡張性、保守性の高いシステムの構築』 ISBN：978-4-87311-997-7 280ページ（予定） 出版月：2022年8月 価格：3,200円（税込：3,520円） 原著はこちらです。 目次は、次の通りです 本書への推薦の言葉 はじめに 第I部　さあ始めましょう 1章　レッツGo 2章　プロトコルバッファによる構造化データ 3章　ログパッケージの作成 第II部　ネットワーク 4章　gRPCによるリクエスト処理 5章　安全なサービスの構築 6章　システムの観測 第III部　分散化 7章　サーバ間のサービスディスカバリ 8章　合意形成によるサービス連携 9章　サーバディスカバリとクライアント側ロードバランス 第IV部　デプロイ 10

この本で、著者のRobert Martinも、次のように述べています。 この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。 『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。 「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」 それに対して、Joshua Blochは、 「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」 という話をしています。 1週間半費

私にとって、18冊目となる技術書の翻訳本です。再出版も入れると通算で21冊目となります。初めての翻訳本が2000年12月に出版された『Javaリアルタイム仕様』ですので、Java関連の書籍としては10冊目となります。 この本の原著はJava 12までカバーしていたのですが、プレビュー言語機能やAmberプロジェクトに対して解説されていた内容はこれから出るJava 14までに変更されているものがあります。 言語仕様の変更部分については、この本の原著が執筆された時点と、日本語への翻訳時点では異なっている部分が多くなっており、日本語版では、必要な修正、削除、追加を訳者の判断で行っています。また、日本語版では必要に応じてJava 13および14へ言及したり、訳注を付けたりしています。 言語仕様に関しては、以下の説明が行われています。 var(第1章「ローカル変数での型推論」と第5章「ラムダパラメー

（私自身のテスト駆動開発については、こちらにまとめてあります） 一年以上、メルペイでウェブサービスのbackendのマイクロサービスを開発していますが、組み込み系のソフトウェア開発と異なり、短期間に新たな機能を開発してリリースすることが求められます。2週間のスプリント単位でリリースしていますが、一つのスプリントで数個の機能を開発することも普通になっています。現在は、ウェブブラウザのフロントにAPIを提供しているあるマイクロサービスを担当しているため、機能の追加は、既存のAPIの仕様変更だったり、新たなAPIの追加だったりします。 開発順序現在担当しているマイクロサービスは、その開発の当初から私自身が関わっていたものでないため、既存のコードを調査して理解する必要がある場合が多く、開発はおおまかに次の順序となります。 既存のAPIの仕様の記述の変更、もしくは、新たなAPIの仕様の記述 既存のA

出版までに間違いをできるだけ少なくするように出版社も含めて努力をしていますが、どうしても誤字脱字だけでなく、技術的間違いを見落とすことがあります。 「ソフトウェアエンジニアの心得」と題した講演や教育では、「技術書には間違いがあると思って読んでください」と話しています。そして、技術的間違いだと思ったら、出版社や著者に問い合わせてくださいとも話しています。技術的間違いに関しては、大きく分けて次の二つに分類されます。 確かに技術的に間違っている 読者の知識不足あるいは勘違いにより間違いではない どちらであっても、問い合わせて損することはありません。技術的に間違っていたら、著者や出版社から感謝されますし、著者によっては正誤表に名前を掲載して、感謝してくれます。正誤表に名前を掲載してくれる例としては、『The Go Programming Language』の正誤表（こちら）があります。まれですが、

ソフトウェアを書いて、手作業でテストする手法とは異なり、テスト駆動開発ではいくつかの規律が求められます。その中で、「テスト駆動開発の経験（6）」で述べたことの一つが「不具合が発生した場合、必ず再現テストを書く」です。 不具合への対処は次のようなステップとなります。 不具合が発生した際に、その原因を調査します（「デバッグの科学的手法」） その不具合を再現させるテストを作成します（不具合が存在するために失敗するテストです）。 テストが失敗するのを確認します。 不具合の原因を取り除いて修正します。 テストが成功するのを確認します。 マルチスレッドプログラミングでは、原因の調査および再現テストを書くことが非常に困難な場合があります（「マルチスレッドプログラミングにおける重要な４要件」）。その場合の再現テストは、普通の再現テストとは異なる工夫が必要になります（詳細については別の機会に書きたいと思いま

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

技術評論社の雑誌に書いた複数の記事をもとに、加筆・修正し、再構成して書籍にまとめて出版したのが2007年9月です。私がまだ47歳のときです。当時は富士ゼロックス情報システムで、開発部の部長をしながら同時に毎日C++でマルチスレッドプログラミングを行っていました。 「現役続行に必要な七つの力」として次の項目を挙げて解説しています。 論理思考力 読みやすいコードを書く力 継続学習力 コンピュータサイエンスの基礎力 朝型力 コミュニケーション力 英語力 現在は59歳で、今年の11月には60歳になります。1978年4月に九州工業大学情報工学科へ入学して、初めてコンピュータに触れ、Fortranでプログラミングを学んでから40年の歳月が流れました。 今日、上記の7つの力に追加するとしたら、「健康力」かもしれません。つまり、健康であることです。この歳になってくると、体の色々なところに問題が発生します。

以前、「デバッグを支える知識」として次の記事を書いています。 デバッグを支える知識 デバッグを支える知識（2） また、デバッグの科学的手法を「デバッグの科学的手法」で述べていますが、再度『ビューティフルコード』の第28章から引用すると以下の通りです。 1. プログラムの失敗を観察する 2. 観察と矛盾しない失敗の原因についての仮説を立てる 3. 仮説を使って予想する 4. 予想を実験でテストして、さらに観察する a. 実験と観察が予想を満たすなら、仮説をさらに精緻なものにする b. 満たさないなら、別の仮説を立てる 5. 仮説がこれ以上精緻にできなくなるまで、手順3と4を繰り返す。この「仮説」を立てるために必要なのが「知識」です。バグに直面したときには、仮説を立てるために必要な知識が不足していても、今日ではある程度ネットで調べて補えます。しかし、本質的な知識の欠如は、デバッグを阻みます。

Go言語で提供されているsync.Mutexは、再入可能（re-entrant）ではありません。それについては、『プログラミング言語Go』（p,306）には次のように書かれています。 Go のミューテックスが再入可能ではないことには正当な理由があります。ミューテックスの目的は、共有された変数のある種の不変式がプログラム実行中の重要な時点で維持されているのを保証することです。不変式の一つは、「共有された変数へアクセスするゴルーチンが存在しない」*2ですが、ミューテックスが保護しているデータ構造に特有の追加の不変式が存在するかもしれません。一つのゴルーチンがミューテックスロックを獲得したときには、そのゴルーチンは不変式が維持されていると想定するでしょう。ロックを保持している間に共有された変数が更新され、一時的に不変式が破られるかもしれません。しかし、ロックを解放するときには、秩序が回復されて不

（「API仕様を書く（6）ー gRPC protoファイル（2） ー」からの続き） きちんとしたAPI仕様を書いていない場合、そのAPIのテストコードは当然のことながら、正常ケースだけだったり、不正なパラメータが渡されたときにどのように振る舞うかは実装のソースコードを見ないと分からなかったりします。さらに、「エラー翻訳」（「例外翻訳」）を行っていない実装は、いつのまにか返されるエラーが変わってしまっていることも起こり得ます。 おそらく多くの大学ではAPI仕様の書き方も含めてAPI設計の教育は行われていないと思います。そして、社会人となってから、個々のソフトウェアエンジニアがAPIの仕様をどの程度記述するかは、その人が属したソフトウェア開発組織の文化に影響を受けると思います。 私自身、gRPCを用いたソフトウェア開発では、前職のソラミツが初めてでした。そこでは、protoファイルには何も仕様

私にとって17冊目の翻訳本になる『Effective Java 第3版』が今月末には書店に並びます。第2版がちょうど10年前です。第2版は、ジェネリックスを含めた大きな言語仕様の変更がJava 5で行われた後でした。今回は、Java 8でラムダとストリームという言語仕様の変更とライブラリの拡張が行われた後となります。 新たに追加された項目は以下の通りです（項目番号は、第3版の番号です）。 項目9 try-finally よりもtry-with-resources を選ぶ 項目21 将来のためにインタフェースを設計する 項目25 ソースファイルを単一のトップレベルのクラスに限定する 項目32 ジェネリックスと可変長引数を注意して組み合わせる 項目43 ラムダよりもメソッド参照を選ぶ 項目44 標準の関数型インタフェースを使う 項目45 ストリームを注意して使う 項目46 ストリームで副作用の

昨年の2月から原著『Effective Java Third Edition』の草稿のレビューが始まり、レビューが終わったのが11月で、昨年末には原著が発売されています。翻訳作業は、昨年の12月から始めて、すべての作業が今月初めに終了しました。今回も、翻訳および（索引作りも含めた）組版までLaTeXで行いました。 原著のレビューのときには気付かなかった多くの間違いは、翻訳作業を通してJoshua Bloch氏へ知らせており、原著の4th printing（第4刷）では修正されています（原著の正誤表は、こちらです）。 今回はもっと早く終わるかと思ったのですが、結局、約430時間を翻訳作業に費やしました。翻訳に先立っての原著のレビューは約42時間でした。 Amazon.co.jpでは、以下のように紹介されています。 Javaプログラマーにとって必読の定番書『Effective Java』の改訂

株式会社メルペイに入社して、3か月が過ぎました。1984年に社会人となってからさまざまなソフトウェア開発に従事してきましたが、今日でいうところの「Backend Engineer」というのは前職のソラミツ社で少しかじった程度でした。現在は、あるマイクロサービスの開発を担当しており、この3か月間の半分以上は、そのマイクロサービスのAPI仕様を書くことに費やしていました。マイクロサービスの通信は、gRPCで行いますので、API仕様はその.protoファイルにコメントの形式で書いています。 実装をほとんどせずにAPI仕様を書くということをいつ頃からやった経験があるのかと振り返って見ると、1993年から開発に従事したFuji Xerox DocuStation IM 200です。レイヤ構成のアーキテクチャで、最下位層はハードウェアを抽象化したAPIを提供するMCA（Machine Control

『Effective Java 第3版』の第11章「並行性」（あるいは、第2版の第10章「並行性」）を内容を理解するためには、Javaのメモリモデル（memory model）を理解する必要があります。『Effective Java 第3版』の翻訳原稿による補講でも「メモリモデルとは何か」という質問がありました。 マルチコアやマルチプロセッサを前提としてマルチスレッドプログラミングを言語仕様として提供する言語では、メモリモデルは言語仕様の一部とも言えます。Javaであれば、『The Java Language Specification』の17.4節の「Memory Model」、あるいは、『プログラミング言語Java第4版』の14.10節 「メモリモデル:同期とvolatile」に書かれています。それぞれ、22ページと5ページを費やして解説しています。 今日、マルチコアやマルチプロセッサ

一か月前に「ソラミツ株式会社を退職します」を書きました。その時点では6月からの勤務先は未定でしたが、6月1日から株式会社メルペイで「ソフトウェアエンジニア（Backend）」として働くことになりました。 通勤勤務場所は六本木ヒルズです。今までよりも乗り換えが1回増えるために、通勤時間はおそらく片道で15分ぐらい長くなるのではないかと思います（往復で3時間を超える？）。朝は今まで通り、自宅の最寄り駅の始発（初電）に乗車して、各駅停車で行く予定です（「通勤電車の書斎化」）。フレックス勤務でコアタイムは12:00〜16:00なので、今までのように出社前にスターバックスに寄って翻訳などの作業をせずに、そのまま出社して早めに帰宅するつもりです。 7社目1984年4月に富士ゼロックスに就職した頃には全く想像もしていませんでしたが、これで7社目となります。 富士ゼロックス 日本オラクル ジャストシステム