SSブログ

書籍『Docker Deep Dive』 [本]

Docker Deep Dive: Zero to Docker in a single book (English Edition)

Docker Deep Dive: Zero to Docker in a single book (English Edition)

  • 作者: Poulton, Nigel
  • 出版社/メーカー:
  • 発売日: 2016/09/20
  • メディア: Kindle版

「MAY 2020」とカバーにある(おそらく最新版)を読みました。普段、Dockerを深く使いこなしてはいないので、Docker全体を知るために読んでみました。

Dockerfileやdocker-composeについてはもちろん説明はされています。それ以外にも、Docker Swarm、Docker Stacks、ネットワーキングについても解説されていますし、15章「Security In Docker」ではセキュリティに関する基本的な事柄も説明されています。

Dockerのセキュリティに関しては、ちょうど「Security Journey」で基本を学んだばかりでしたので、復習にもなりました。

Docker Swarm関連では、分散サービス用のRaft、gossipプロトコル、リーダー選出(leader election)などの用語が事前説明なしで使われています。これらも『Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築』で学んだばかりだったので、問題なく理解することができました。

本の内容は、実際に手元でDockerを動作させて確認できますし、Docker Swarmについても(全部ではないですがある程度)Play with Dockerで試すことができます。

コメント(0) 

『人月の神話』オンライン読書会を開催します [オンライン読書会]

人月の神話

人月の神話

  • 出版社/メーカー: 丸善出版
  • 発売日: 2021/07/13
  • メディア: Kindle版

9月より、月に1回、土曜日の午後1時〜5時で、書籍『人月の神話』のオンライン読書会を開催します。


この本については、拙著『ソフトウェア開発の名著を読む【第二版】』でも紹介しています。

ソフトウェア開発の名著を読む 【第二版】 (技評SE選書)

ソフトウェア開発の名著を読む 【第二版】 (技評SE選書)

  • 作者: 柴田 芳樹
  • 出版社/メーカー: 技術評論社
  • 発売日: 2009/10/21
  • メディア: 単行本(ソフトカバー)

コメント(0) 

『Go言語による分散サービス』オンライン読書会を開催します [オンライン読書会]

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

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

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

今までのオンライン読書会は、出版されてから時間がしばらく経過している本を取り上げることが多かったのですが、8月に出版される私の新たな翻訳本を使ったオンライン読書会を開催します。


月に1回、土曜日の午後1時から5時までの読書会です。

2020年からさまざまなオンライン読書会を開催してきていますが、第1回が最も参加者が多く、徐々に少なくなっていきます。最後まで参加される人は、だいたい決まっています。これは、オンラインの読書会に限った話ではなく、会社内で行ってきた読書会も同じ傾向でした。

オンライン読書会での特徴の一つとして、過去に私の他のオンライン読書会に参加経験がなくて、ある本のオンライン読書会の何回目かに初めて参加される人の中には、必ずといってよいほど、キャンセル処理をすることなく欠席される人がいます(開催の案内メッセージで、「都合により欠席される場合、キャンセル処理をお願いします。」と毎回書いているのですが)。そのようなキャンセル処理なしで欠席されたことがある参加者は、申し込まれても私の方でキャンセル処理することがあります。
コメント(0) 

書籍『Googleのソフトウェアエンジニアリング』 [本]

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

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

職種としての「ソフトウェアエンジニア」は、ソフトウェアの設計から実装まで行うものと考えられることがあると思います。しかし、そこにエンジニアリングという視点はどの程度含まれるのでしょうか。さまざまな設計手法、さまざまなレビュー、テスト駆動開発、継続的インテグレーションなどの実践は、確かにエンジニアリングではあります。しかし、実践できていない開発組織もまだまだ多いと思います。

仮に実践できているとしても、小さな組織で行っているエンジニアリングが、Googleほどの大きな組織へと拡大するためには、スケールするのかを考える必要があります。Googleほどの大きさにならなくても、ビジネスが成長しているのであれば、それを支える開発組織も大きくなっていき、今までのエンジニアリング的な実践がスケールするのかを考える必要が自然と発生していきます。

この本では、大きなソフトウェア開発組織へと成長する過程で、試行錯誤しながらGoogleが取り組んできたソフトウェアエンジニアリングについて述べられています。

私自身のウェブサービスの開発経験はメルペイで働き始めてからなので限られてはいますが、この本を読みながら、現在自分達が直面している問題、あるいは、今後直面するであろう問題を色々と考えさせられることが多い内容でした。ただ、私自身があまり馴染みがない領域に関しては内容を理解できないものもありましたが、全体としてはとても参考になることが多い本でした。

この本で紹介されているHyrumの法則というのがあります。
あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様として何を約束しているかは重要でない。作られたシステムが持つあらゆる観測可能(obserbable)な挙動に関して、それに依存するユーザーが出てくるものである。
この法則に、いかに苦しんできたかは、この本全体でいろいろなところに登場します。小さな組織であれば、API仕様をきちんと書いておくだけでおそらく十分なのでしょうが、組織が大きくなれば、Hyrumの法則が登場して、思わぬ使われ方や想定が行われるようになっていくということです。
コメント(0) 

書籍『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)