SSブログ

書籍『Go言語による分散サービス』の予約注文が可能になりました [本]

書籍『Go言語による分散サービス』が、Amazon.co.jpで予約注文可能になりました。

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築

  • 出版社/メーカー: オライリージャパン
  • 発売日: 2022/08/03
  • メディア: 単行本(ソフトカバー)

電子版(PDF)は、発売後にオライリー・ジャパン(ページはまだ用意されていません)のサイトから購入可能になります。

目次は、次の通りです
本書への推薦の言葉
はじめに

第I部 さあ始めましょう
1章 レッツGo
2章 プロトコルバッファによる構造化データ
3章 ログパッケージの作成

第II部 ネットワーク
4章 gRPCによるリクエスト処理
5章 安全なサービスの構築
6章 システムの観測

第III部 分散化
7章 サーバ間のサービスディスカバリ
8章 合意形成によるサービス連携
9章 サーバディスカバリとクライアント側ロードバランス

第IV部 デプロイ
10章 Kubernetesでローカルにアプリケーションをデプロイ
11章 アプリケーションをKubernetesでクラウドにデプロイ

訳者あとがき

コメント(0) 

急性心筋梗塞から2年が過ぎました [心筋梗塞]

2020年6月20日(土)の夕方に急性心筋梗塞で緊急搬送されてから2年が過ぎました。発症から今日までの経過は、こちらからまとめて読むことができます。

急性心筋梗塞では、冠動脈の血流が止まることで、心臓の心筋が壊死してしまいます。壊死した部分は回復しないそうです。私の場合は、幸い軽かったので、壊死した部分も少なかったようです。

心筋の壊死の状況によっては、回復後も心電図の波形に異常が現れるそうです。私の場合、心電図では何も異常はなく、血液検査やレントゲンなどの一般的な検査だけであれば、正常としか判断されないようです。心筋が壊死していると分かる検査は、心臓超音波検査だけです。

今年の5月に行った心臓超音波検査の結果は、1年前よりはよくなっていました。壊死した部分が回復したというよりも心臓全体が良くなっていたようです。週に5日程度は、自宅で30分のエアロバイクを継続していることと、食事制限、それと薬の効果だと思います。

幸い、2年前に亡くなるとか重体になることもなかったおかげで、この2年間では、『Linuxシステムの仕組み』と『Go言語による分散サービス』の技術書を翻訳することができました。

スーパーユーザーなら知っておくべきLinuxシステムの仕組み

スーパーユーザーなら知っておくべきLinuxシステムの仕組み

  • 出版社/メーカー: インプレス
  • 発売日: 2022/03/08
  • メディア: Kindle版

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築

  • 出版社/メーカー: オライリージャパン
  • 発売日: 2022/08/03
  • メディア: 単行本(ソフトカバー)

コメント(0) 

書籍『Go言語による分散サービス』 [本]

Amazon.co.jpではまだ先行予約できませんが、私にとって通算20冊目となる翻訳本が8月上旬に発売されます。
『Go言語による分散サービス ― 信頼性、拡張性、保守性の高いシステムの構築』
ISBN:978-4-87311-997-7
280ページ(予定)
出版月:2022年8月
価格:3,200円(税込:3,520円)

原著はこちらです。

Distributed Services With Go: Your Guide to Reliable, Scalable, and Maintainable Systems

Distributed Services With Go: Your Guide to Reliable, Scalable, and Maintainable Systems

  • 作者: Jeffery, Travis
  • 出版社/メーカー: Pragmatic Bookshelf
  • 発売日: 2021/03/30
  • メディア: ペーパーバック


目次は、次の通りです
本書への推薦の言葉
はじめに

第I部 さあ始めましょう
1章 レッツGo
2章 プロトコルバッファによる構造化データ
3章 ログパッケージの作成

第II部 ネットワーク
4章 gRPCによるリクエスト処理
5章 安全なサービスの構築
6章 システムの観測

第III部 分散化
7章 サーバ間のサービスディスカバリ
8章 合意形成によるサービス連携
9章 サーバディスカバリとクライアント側ロードバランス

第IV部 デプロイ
10章 Kubernetesでローカルにアプリケーションをデプロイ
11章 アプリケーションをKubernetesでクラウドにデプロイ

訳者あとがき

コメント(0) 

『プログラミング言語Go』オンライン読書会は、第2サイクルで終了します [オンライン読書会]

2020年6月6日から開始した『プログラミング言語Go』のオンライン読書会ですが、第2サイクルが8月で終了します。第3サイクルは開催しないことにします。
コメント(0) 

手動テストだけのソフトウェアは腐っていく [プログラマー現役続行]

1990年代までのソフトウェアテスト

1990年代までのソフトウェア開発におけるテストは、手作業で目視確認が主流でした。今日のようにテスト駆動開発で、自動テストを書くという習慣はありませんでした。いくつかの書籍から、本当でそうであったかを引用すると次の通りです。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

  • 出版社/メーカー: オーム社
  • 発売日: 2014/07/26
  • メディア: 単行本(ソフトカバー)

著者のMartin Flowerは、この本の中で次のように述べています。
テストの実行は確かに簡単になりました。しかしテストの実行は簡単になってもテストは依然として極めて退屈なものでした。これは、コンソールに出力されるテスト結果を私がチェックしなければならないためです。

Clean Code アジャイルソフトウェア達人の技 (アスキードワンゴ)

Clean Code アジャイルソフトウェア達人の技 (アスキードワンゴ)

  • 出版社/メーカー: ドワンゴ
  • 発売日: 2017/12/28
  • メディア: Kindle版

この本で、著者のRobert Martinも、次のように述べています。
この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。

Coders at Work プログラミングの技をめぐる探求

Coders at Work プログラミングの技をめぐる探求

  • 出版社/メーカー: オーム社
  • 発売日: 2011/05/25
  • メディア: 単行本(ソフトカバー)

『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。
「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」
それに対して、Joshua Blochは、

「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」

という話をしています。

1週間半費やしてその原因が何であったかというと、彼が書いたコードではなくて彼が書いたコードが使っていたミューテックスのライブラリにバグがあったっていうことです。それに対してインタビュアーが、

「そのミューテックスの作者がテストを書いていればバグは見つかったはずで自分が1週間半デバッグすることはなかったのにと思いますか?」

と聞いています。
インタビュアーの質問に対するJoshua Blochの回答は次の通りです。
頭に入れておく必要があるのはこれが90年代初期の話だということです。十分なユニットテストを書いていないということで、そのエンジニアを非難しようという気は全く起きませんでした。
1990年代は、このような時代だったのです。実際、私自身も、テスト駆動開発を行うようになったのは、2003年からです。

手動テストだけのソフトウェアは腐っていく

私自身は、1980年代、1990年代といくつかのプロジェクトに従事してきました。そのほとんどが、新規開発プロジェクトでしたが、後継の商品が開発されないものがほとんどでした。結果、手作業でテストしていたにも関わらず、開発されたソフトウェアが長年にわたって肥大化する前にプロジェクトが終わってしまい、ソフトウェアが腐っていくといことをあまり実感していませんでした。

2000年以降も新規開発プロジェクトにいくつか従事したのですが、一方で、既存のソフトウェアの修正などのレビューも多く行ってきました。さまざまなソフトウェアをレビューしていくなかで、分かったのは、「手動テストだけに頼っているソフトウェアは、年々腐っていく」ということです。
  1. 手動テストだけに頼ってテストされており、すべての機能のテストに多くのテスターと長い期間を必要とする
  2. 機能が毎年追加されたり、修正されたりしている
1.に関しては、最初は少人数で短期間であっても、機能追加が行われるごとにテスターの人数が増えて、テスト期間が長くなっていきます。

すべての機能を一通りテストする工数が増大してくると、追加された機能やバグ修正された機能だけをQAがテストして、リリースしようとします。そうなると、機能の追加やバグ修正の際に、次のことが(マネジメントから)要求されるようになります。
  • 既存の機能のコードには一切変更を入れない。たとえ、新規機能で追加されるコードと共通化できるコードがあっても、共通化が既存の機能のコードの修正になるなら、共通化は行わない。
  • バグを修正する場合も、修正コードを追加した結果、仮にif文のネストが深くなったり、caseラベルの処理が長くなったりしても、関数化やメソッド化によって既存の機能のコード変更になる場合、関数化やメソッド化は行わない。
つまり、既存の機能のコードは、一切触らないし、リファクタリングもしないまま、次のようなコードが生み出されていきます。
  • 似て非なるコードが多くある。つまり、既存の機能のコードをコピーしてきて、一部を修正しただけのコードが増えていく。
  • if文のネストがとても深くなっていく。
  • caseラベルの処理が長くなっていく。さらに、その処理にネストが深いif文が書かれる
  • 一つの関数やメソッドが長くなっていき、その中のローカル変数のスコープが広くなって、実質的にグルーバル変数のようになってしまう。
このように腐ってしまったソースコードは、エディタで開いた瞬間、そっと閉じたくなるものです。
コメント(0) 

テストファースト開発(2) [プログラマー現役続行]

以前、「テストファースト開発」と題して、当時どのように開発していたかを書いています。その中で開発のフローについて、次のように書いています。各ステップの解説については、前述のブログを読んでください。
  1. 既存のAPIの仕様の記述の変更、もしくは、新たなAPIの仕様の記述
  2. 既存のAPIの実装の調査(新たなAPIの場合には似たAPIの実装の調査)
  3. テストコードの作成
  4. 機能の実装
  5. リファクタリング
今週は、あるマイクロサービスの機能の一部を別のマイクロサービスへ移行する作業をしました。機能そのものは小さかったのですが、実際に行ったことは、次の通りです。

API仕様の確認

最初に、API仕様、つまりgRPCの.protoに書かれているrpcの仕様を確認しました。仕様を読んで、疑問に思うことが何点かありました。つまり、仕様から読み取れない振る舞いがあった訳です。それで、既存の実装コードを調べたり、既存のe2eテストを修正して試したりして、不明な振る舞いの動作を確認しました。

確認した内容のすべてをもとの.protoファイルに記述するPR(Pull Request)を作成し、もとの開発者にレビューをお願いしました。私が調査から読み取れていなかった点の指摘があったので、指摘点を修正して、PRをapproveしてもらい、マージしました。.protoファイル内にコメントして記述されている仕様の修正なので、特に実装の変更はありません。

テストコードの作成

もとのマイクロサービスにあったe2eテストを参考に、修正されたAPI仕様に書かれていることをすべて網羅するのを確認しながら、新たなe2eテストを作成して、すべてのテストが失敗するのを確認しました。

実装

テストが合格するように順次実装していくのですが、まだ実装していない箇所にコードが到達した場合には、panicするかUnimplementedエラーを返すようにコードを入れながら実装していきます。テストがすべて合格するまで、実装を行っていきます。

すべてのテストが合格したら、テストによって実際に実行されたコードをカバレッジで確認します。ここで重要なのは、カバレッジのパーセントではなく、実装したコードがすべて実行されたかです。私個人としては、「開発者はカバレッジのパーセントではなく、実行されたコードを確認することが重要」と思っています。

確認してみると、実際に起きたらInternalエラーになるコードが実行されていないことが判明しました。Internalエラーは、設計上想定していないことが起きていることを意味しますので、そのエラーをテストで起こせるかどうかは、内容次第となります。今回は、テストコードで起こせるものだったので、追加のテストコードを作成しました。

この追加のテストコードは、すでに実装が書かれているので、合格するテストを最初から書いてしまうと単に合格してしまいます。それでは該当コードが実行されたことによって合格しているのか、それとは別の理由で合格しているのか分からなくなってします。それで、わざと(正しくはない)合格しないテストを書いて、失敗することを確認してから、正しいテストへ修正して、合格することを確認しました。

最後にカバレッジで実行された実装コードを確認して、実装作業は終了です。

コードを見直して、とくにリファクタリングは必要ないと判断し、PRをレビューに出しました。
コメント(0) 

20冊目の技術書の翻訳の状況 [プログラマー現役続行]

私にとって通算20冊目となる技術書の翻訳本ですが、早ければ今週中に出版社での組版が終わった初校が上がってきそうです。初校のPDFが送られてくたら、私の方で10日ほどでチェックすることになります。

一年で2冊出すのはあまりないのですが、今年3月に出版した19冊目の『スーパーユーザーなら知っておくべきLinuxシステムの仕組み』と比べると、20冊目はページ数も少なくコードも多いので、翻訳に要した時間は、19冊目の1/3程度となっています。
コメント(0) 

メルペイで4年が過ぎました [プログラマー現役続行]

ソラミツを退職して、メルペイに入社したのが、2018年6月1日でした。ちょうど4年前です。

入社前の面談で、週4日勤務(金曜日は休み)を希望したのですが、雇用形態としてはそのような制度はないということで、正社員として採用されました。ただし、金曜日は欠勤としたり、有給休暇を使ったりして休んでよいということで、入社しました。メルペイのサービスを最初にリリースする前の2か月ほどは、金曜日に働いたことはありますが、それ以外は金曜日は欠勤か有給休暇で休んでいます(欠勤すると所定労働時間に達しないので、不足分は給与が減額されます)。

技術教育と技術書の翻訳

金曜日は、主に複業としての技術教育(Java言語教育Go言語教育)や技術書の翻訳などを行ってきました。もちろん、単に休むこともあります。副業としてのソフトウェア開発を行っているエンジニアも多いですが、ソフトウェア開発は締め切りがあったり、デバッグがいつ終わるか予想できないことがあるので、私は行わないようにしています。

Go言語教育では、古川陽介さん和田卓人さんが受講してくれました。古川さんは、彼が社会人になった頃からの知り合いですが、和田さんとも知り合えたのがよかったです。

技術書の翻訳も以下の4冊を行えています。4冊目(Go言語による分散サービスに関する書籍)はまだ発売されていませんが、4月末には私の作業は終わっており、現在出版社による組版を待っています。

メルペイでの活動

メルペイでは、Backendのソフトウェアエンジニアとして、マイクロサービスの開発に従事してきました。1984年4月に社会人になってから、主にワークステーション開発とデジタル複合機の組み込みシステムの開発を行ってきており、ウェブサービスの開発に本格的に従事したのはメルペイが初めてでした。Kubernetesについては、書籍『Kubernetes in Action』で独学しながらの開発でした。

マイクロサービスの開発を通しての成果として、いくつかのTech Blogを書いています。また、GDG DevFest Tokyo 2019JaSST'19 Tokaiで登壇して、マイクロサービスでのテスト駆動開発について話しました。

今後

現在の私の年齢は62歳6か月であり、65歳までにあと2年半となりました。今後もソフトウェア開発に従事しながら、複業を続けていきたいと考えています。
コメント(0)