はてなブックマーク

2018年6月1日から働き始めた株式会社メルペイを9月30日付けで退職します。4年4か月勤務したことになります。1984年4月1日に社会人として富士ゼロックスで働き始めてから、7社目の会社でした。10月1日からは、新たな会社でソフトウェアエンジニアとして働き始めます。 週4日勤務「ソラミツ株式会社を退職します」でも書きましたが、リコーを退職してからは、基本的に週4日勤務をしてきました。メルペイでも、金曜日は欠勤するか有給休暇を使うなどして、週4日勤務をしてきました（週4日勤務で働くことに関して、入社前に合意してもらっていました）。10月からの会社では、週4日勤務の雇用契約で働きます。 初めてのウェブサービス開発富士ゼロックス、富士ゼロックス情報システム、リコーの3社で合計31年7か月を過ごし、富士ゼロックスでのワークショテーション開発を除くと、その多くは、デジタル複合機のソフトウェア開発に

エンジニアが集まって、LTを行ったり、20分から30分程度の発表を平日の夜に行うというのは、いつ頃から広まっているのか定かではありませんが、この10年間で確実に広まってきています。さらに、コロナ禍により、オンライン開催も加わり、広く行われるようになりました。 一方、Advent Calendarといったtech blog（技術文書）を公開することも多く行われています。企業内の開発で得た知見を、オンラインで説明しながら話したり、tech blogとして公開することは、今日のIT業界では、当たり前のように行われています。これらは、すべて外部へ向けての発信です。 外部発信することで、その企業の技術力を発信することにもなり、エンジニアを惹き付けることにもなります。私自身もTech Talkで話をしたり、tech blogを書いてきました。このような情報発信は、今後も多くのIT企業やスタートアップで

この本で、著者の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章「ラムダパラメー

2018年6月にメルペイで働き始めて、今年は2年目でした。ちょうど一年7か月働いたことになります。今年一年間は、Backendのマイクロサービスの開発で、ずっとGo言語とVimでプログラミングしていました。昨年は、5月は全く仕事をせずに休みだったのと、メルペイに入社してしばらくはAPI仕様ばかり書いていたので、振り返ってみると最後に一年間プログラミングした年は2008年だと思います。 リコーに勤務していた8年間（2009年9月〜2017年8月）では、現場のソフトウェアをレビューすることはあっても、自分でプログラミングすることはほとんどありませんでした。 一年間プログラミングし続けたと言っても、月曜日から木曜日までなので、40代の頃と比べると時間的には少なかったです。また、40代に行っていた複雑なマルチスレッドプログラミングと比べるとそれほど複雑なプログラミングは行っていないです。 基本的に

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

（「API仕様を書く（4）」からの続き） RPCの実装も通常のライブラリを作成するように「防御的プログラミング」を必要とします。すなわち、以下の状態に正しく対処する必要があります パラメータ値不正 呼び出し順序不正 設計ロジックの誤り 最初の二つは呼び出した側の誤りのですので、そのような不正呼び出しに対して、どのようなエラーを返すかを記述する必要があります。三つ目は設計ロジックの誤りです（これらの三つの詳細な説明については、『API設計の基礎』の「第3章 防御的プログラミング」を参照してください）。 gRPCのprotoファイルの例として、https://grpc.io/docs/guides/ には次のようなサンプルが掲載されています。 // The greeter service definition. ① service Greeter { // Sends a greeting　②

「API仕様を書く」として私自身の過去の経験を書いたものを読みやすく並べてみました。 API仕様を書く（1） API仕様を書く（2） API仕様を書く（3） API仕様を書く（4） API仕様を書く（5）ー gRPC protoファイル ー API仕様を書く（6）ー gRPC protoファイル（2） ー API仕様を書く（7） ちょうど同じような内容が『A Philosophy of Software Design』に書かれていました。 関連する章は、第12章「Why Write Comments? The Four Execuses」と第15章「Write The Comments First」です。第12章では、コメントを書かない理由として多くのソフトウェアエンジニアが挙げる理由について反証しています。第15章ではコメントを最初に書くことの有用性を説いています。ここでのコメントは、私

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

新たなプログラミング言語への取り組みソフトウェア業界は停滞することなく、常に発展してきました。さまざな問題を解決するために、さまざまなプログラミング言語が登場してきましたし、これからも登場してくると思います。登場するすべてのプログラミング言語に取り組み、スラスラとその言語でコードを書けるようになるのは難しいと思います。したがって、私を含めて、多くのソフトウェアエンジニアは、書いたことがあるとしても、スラスラと書ける言語とそうではない言語に分かれると思います。 スラスラと書ける言語は、日々のソフトウェア開発で使ってきた結果として、指が自然と動くということです。そして、日々のソフトウェア開発で使うプログラミング言語は、バイブル本（「プログラミング言語のバイブル本と言語仕様」）を通してきちんと学ぶべきです（あるいは自己学習すべきです）。その理由としては、以下のことが挙げられます。 毎日使っている

1978年4月、大学一年生で初めてのプログラミングをFORTRANで学びました。それから、今月末で丸41年が過ぎたことになります。今と違って当時は、プログラミングは大学の計算機センターに行かなとできませんでした。当時の九州工業大学の計算機センターは、幸いパンチカードではなく、TSS（Time Sharing System）の端末を使ってプログラミングできました。でも、自分の学科（情報工学科）のさまざまなコースの演習は違っていました。 コンパイラの授業では、パンチカードを使ってPL/Iでプログラミングしました。パンチ室が3階で、計算機室が4階だったので、自分が書いたコンパイラのコードである7百枚ぐらいのパンチカード（つまり、700行のソースコード）を持って3階と4階を行ったり来たりして、デバッグして完成させました。 CPUの内部を学習する授業では、APLで動作が記述されている英語の教科書でし

技術評論社の雑誌に書いた複数の記事をもとに、加筆・修正し、再構成して書籍にまとめて出版したのが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』の改訂

『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ページを費やして解説しています。 今日、マルチコアやマルチプロセッサ