So-net無料ブログ作成
  • ブログをはじめる
  • ログイン
プログラマー現役続行 ブログトップ
前の10件 | -

書籍『Kubernetes in Action』 [プログラマー現役続行]

Kubernetes in Action

Kubernetes in Action

  • 作者: Marko Luksa
  • 出版社/メーカー: Manning Publications
  • 発売日: 2018/01/20
  • メディア: ペーパーバック

メルペイで5か月が過ぎました」でも書きましたが、今年の6月にメルペイ社に入社して読み始めたのが『Kubernetes in Action』です。メルペイ社では、Go言語を用いてマイクロサービスで開発していますが、各マイクロサービスはKubernetes上のPodとして動作します。

基盤としてKubernetesを使っているとはいえ、細かな設定などはSREチームが行っているので、細かな仕様を知っている必要はないのかもしれません。しかし、やはり使っている技術はきちんと学ぶのが基本ですので、どの本がよいかをAmazon.comで調べてこの本を選びました。ただし、出版元のManning PublicationsからPDF版を購入しました。

この本は大きく、3部から構成されています。
Part 1 Overview
Part 2 Core Concepts
Part 3 Beyond the Basics
Part 1は、導入部分であり概要が説明されています。Part 2では基本的な事柄が説明されています。Part 3は、どのような仕組みで動作しているかや、さまざまなリソースのチューニングなどが説明されています。

実際にテキストの指示に従って、Google Cloud Platform上にクラスタを構築しながら、手を動かして読み進めて理解を深めることができます。私自身は普段の開発に必要なさまざまなツールの設定はこの本の指示に従って行いましたし、日々の開発に必要とするKubernetesの知識もこの本で学びました。普段手に取って簡単に参照できるように、紙の本を会社で購入したのですが、紙の本は図が白黒なので、読むのにはPDFの方がよいかと思います。

前職のソラミツ社ではgRPCを用いた開発は多少しましたが、Backendのサービス開発は初めてと言ってもよいです。Fortranでプログラミングを初めて学んでから40年が過ぎましたが、ソフトウェアにはエンドレスに新たな技術が登場します。そのため、学び続けるのと、実際に作り続けることが必要な領域だと思います、


スポンサーリンク





コメント(0) 

悪い癖、間違った思考・行動パターン [プログラマー現役続行]

私自身は、メンバーの業績評価を伴わないリーダーとしての立場から、メンバーの業績評価を伴うマネージャとしての立場、さらに開発部の部長という立場までさまざまな経験をしながら、ソフトウェア開発組織を作り上げることをどこかで意識してきました。働いてきたソフトウェア開発組織のほとんどは、毎年、新卒新人が入社して、彼ら彼女らを育成していくことが必要な組織でした。そのような経験をまとめたのが「ソフトウェア開発組織が持つべきカルチャー」です。そうは言っても、意識していたのは30代後半以降です。20代と30代前半は、そのような意識もなくソフトウェアを開発していました。

そして、私自身、ソフトウェアエンジニアとしてのさまざまな悪い癖は、自分自身で気付いて直してきました。当たり前だと思ってやっていたことが、後に、bad practiceと分かることがありますが、その場合には意識して直してきました。

しかし、私自身が長い年月を経て習得してきたことを、新卒新人に同じ年月をかけて習得させるのは非効率ですし、ひょっとしたら全く習得しないかもしれません。そのために、新卒新人の頃から変な癖や間違った思考・行動パターンにならないように指導してきました。

ソフトウェアエンジニアの変な癖やまた違った思考・行動パターンは、いつ身に付くかというと、新卒新人で入社した最初の会社です。それと同時によい習慣や正しい思考・行動パターンが身に付くもの最初の会社です。とくに前者の場合、一度身に付いてしまうと、組織を変わってもなかなか変えることが難しくなるのではないかと思います。


スポンサーリンク





コメント(0) 

副業 [プログラマー現役続行]

最近は、企業が副業を解禁するしないという話題が目立つようになりました。今働いているメルペイ社では副業は禁止されていません。私自身は、技術雑誌の記事の執筆、技術書籍の翻訳、技術書の執筆などを2000年から副業としてやってきました。現在は、技術書籍の翻訳と企業向けの技術教育が中心です。

最初に副業を始めたのは富士ゼロックス情報システム社に勤務している頃で、就業規定に明確に兼業禁止規定がありました。しかし、技術系の活動に関しては、毎回社内で申請処理をする必要がありましたが、認められていました。

2008年9月にリコーへ転職したのですが、就業規則を何度読み返しても「兼業禁止規定」は書かれていませんでした。それでも、技術書の翻訳で社内申請をしようとしたのですが、当時の室長に「入社前からやっている活動であり、そのことは承知して採用しているし、申請するとそれを審査するために無駄に社内の工数が取られるので申請しなくてよい」と言われました。それ以来、リコー内では何も申請することなく、技術書の翻訳本を出したり、自分の本を出したりしていました。

リコーに勤務していた間には、頻度は年に1回程度でしたが新卒新人向けの技術教育を2社ほど他社向けにやっていました。1社は土曜日で、もう1社は有給休暇を取得してやっていました。これらは、最初だけ社内の申請を行いました。

2017年8月末で8年間勤めたリコーを早期退職しました。年齢的にも58歳に近くなっていたので、週4日勤務という条件でソラミツで働き始めました。それは、金曜日は個人で技術教育やコンサルティングなどの副業をする日に当てたかったためです。企業向け技術教育となるとどうしても平日ということになります。

今の若い人達は、ソフトウェア開発で副業をしている人も多いようです。私が20代から30代の頃は、そのような副業は不可能な時代でした。ソフトウェアを開発するには、会社に行かないとできなかった時代ですので、平日の夜とか休日にプログラミングの副業は無理でした。

今日のベンチャー企業やスタートアップ企業では、ソースコードコントロールやCIツールなどの多くがクラウドベースになっているため、自宅でもソフトウェアを開発できる時代になっています。

私の30代に同じ環境があってもソフトウェア開発での副業は無理だったかもしれません。当時は、朝7時に出社して12時間近く会社でソフトウェア開発をして、そして飲み会という日々だったからです。そして、休日出勤しない限り、土日にプログラミングすることはなかったので、休みには体を休めることができました。副業でお金をもらってソフトウェア開発をするには、若くても体調管理をしっかりとする必要があるかと思います。

コメント(0) 

デバッグを支える知識(3) [プログラマー現役続行]

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

メルペイ社で働き始めて、私にとってはGCP(Google Cloud Platorm)やKubernetesは初めての経験です。そもそもAWSもほとんどやったことがないです。結果として数時間ではなく、数日の単位で行き詰まったデバッグが今までに3件ありました。3件とも解決はしましたが、最近経験した3件目は、ほぼ完全に行き詰まった状態で、それまでの状況を再度整理して社内のSlackで流したら、「○○をやってみたら」という返事があり、それで解決しました。
※ 1996年9月に日本オラクルに入ってからデータベースを勉強した経験に似ています。

解決してしまえば、現象を説明できる原因、それにもらった助言の意味を理解できたのですが、私自身は、現象から原因への仮説を立てるのがほぼ行き詰まっている状態でした。このような経験により仮説を立てるための知識が少し増えたことになりますが、やはり、1時間で解決したかった種類の不具合でした。

コメント(0) 

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

2018年6月1日にメルペイ社に入社(メルカリから出向の形態)して働き始めて5か月が過ぎました。

【仕事】メルペイが提供するサービスを構成するバックエンドのマイクロサービスの1つの開発を担当しています。開発言語はGo言語です。マイクロサービスが提供するAPIはgRPCベースですので、提供する機能の仕様をprotoファイルに書く作業をしばらく行っていました(「API仕様を書く」)。

最初から最終版のAPI仕様を書くことは不可能ですが、最初の仕様ができあがったので、テスト方法の検討と実装です。私が担当しているマイクロサービスは複数のマイクロサービスに依存しているので、どのようにe2eテストコードを書くかを検討しました。要件としては、以下の項目を最初に考えました。
  • 担当するマイクロサービスを起動して、gRPCを本当に呼び出してテストできること
  • 依存するマイクロサービスのgRPCを本当に呼び出すこと
  • 依存するマイクロサービスの振る舞いを、テストコードに記述できること(RPCが呼び出されたら、返すレスポンスをテストコードで記述できること)
  • テストを実行したら、担当するマイクロサービスのカバレッジが取れること
  • このe2eテストをCIで実行できること
これらの要件を満たす方法を検討・実装した後は、担当するマイクロサービスが提供する機能を実装したり、必要に応じたAPI仕様の修正したりといった開発業務を行っています。また、開発環境にデプロイされた後に、外部から疎通テストを行うテストの開発も行っています。

【学習】長年、デジタル複合機のコントローラソフトウェア開発に従事していて、組み込み系がほとんどだったので、使っているクラウド技術は全く初めてのものばかりです。基盤としてはKubernetesを使っているので、読むべき本をAmazonで自分なりに調べて、『Kubernetes in Action』を選びました。読みながら実際に手を動かして学習してきました(まだ全部は読み終えていません)。本に従って、開発環境を整備したり、Google CloudにKubenetesを設定しながら学習することできます。

Kubernetes in Action

Kubernetes in Action

  • 作者: Marko Luksa
  • 出版社/メーカー: Manning Publications
  • 発売日: 2018/01/20
  • メディア: ペーパーバック

【勤務時間】基本的に7時30分頃に出社して、16時過ぎには退社します。通勤時間は、往復で4時間を超えています。16時過ぎには退社するので、19時過ぎに行われることが多い各種イベント(社内向け、社外向け)に出席することはありません。

【副業】副業をそのものは禁止されていませんが、メルペイ社に入社前から行っていた以下の副業は続けています。
  • 技術書の翻訳
  • 講演や技術教育
技術教育に関しては、今年はリクルートテクノロジーズ社向けの「Go言語研修」が主です。『Effective Java 第3版』の翻訳原稿を用いたJava研修の補講もやりました。今後は、企業向けの「『Effective Java 第3版』研修」も予定しています。

コメント(0) 

ロック(ミューテックス)の再入可能性 [プログラマー現役続行]

Go言語で提供されているsync.Mutexは、再入可能(re-entrant)ではありません。それについては、『プログラミング言語Go』(p,306)には次のように書かれています。
Go のミューテックスが再入可能ではないことには正当な理由があります。ミューテックスの目的は、共有された変数のある種の不変式がプログラム実行中の重要な時点で維持されているのを保証することです。不変式の一つは、「共有された変数へアクセスするゴルーチンが存在しない」*2ですが、ミューテックスが保護しているデータ構造に特有の追加の不変式が存在するかもしれません。一つのゴルーチンがミューテックスロックを獲得したときには、そのゴルーチンは不変式が維持されていると想定するでしょう。ロックを保持している間に共有された変数が更新され、一時的に不変式が破られるかもしれません。しかし、ロックを解放するときには、秩序が回復されて不変式が再び維持されていることを保証しなければなりません。再入可能なミューテックスは他のゴルーチンが共有された変数へアクセスしていないことを保証するでしょうが、それらの変数の追加の不変式を保護することはできません。
*2 訳注:ゴルーチンがミューテックスロックを獲得する前の時点とそのロックを解放した時点で「共有された変数へアクセスするゴルーチンが存在しない」という意味です。この段落は、ミューテックスロックが獲得されていない場合の不変式について言及しています。
一方、Javaのオブジェクトのロック(モニター)は、再入可能です。つまり、同じスレッドが同じロックを複数回獲得できます。

私自身がマルチスレッドプログラミングを本格的に行ったのは、Solaris 2.3を用いていたFuji Xerox DocuStation IM 200の開発です。当時、Solaris 2.3で提供されていたC言語用のスレッドライブラリ(POSIX Threadが登場する前です)は、再入可能なロックは提供していませんでした。そのためデッドロックが発生すると、場合によってはC++のメンバー関数の分割を行ったものです。privateのロックを獲得しないメンバー関数と、ロックを獲得してprivateのメンバー関数を呼ぶpublicの公開用のメンバー関数へと分割します。この分割については、上記の『プログラミング言語Go』にも書かれています。

IM 200が商品化された後の1996年にJavaを学び始めた時に、ロックが再入可能だというのは非常に魅力的に思えました。Javaの影響を受けて、2000年に設計したC++用のスレッドライブラリ(「clibと呼ばれるライブラリー開発の思い出」)では、再入可能なロックを提供するCSynchronizerというクラスを用意しました。そのライブラリを用いた最初の商品開発では、オブジェクトを介してスレッド間で同期するという設計は行われていませんでしたので、再入可能であることはそれほど利点がありませんでした。

2003年から2009年に従事したコントローラソフトウェア開発では、clibを用いてマルチスレッドプログラミングをかなり行ったのですが、再入可能であるために起きる問題に悩まされて、マルチスレッドプログラミングの難しさを痛感したものです。幸い、その開発は完全なテスト駆動開発でしたので、「マルチスレッドプログラミングにおける重要な4要件」を満たしており、様々な問題を解決する経験を積むことができました。このソフトウェア開発で経験した問題は、『Effective Java 第3版』でJoshua Blochが述べていることそのものでした。
再入可能ロックは、マルチスレッドのオブジェクト指向プログラムの作成を単純化しますが、活性エラーを安全性エラーに変える可能性があります。

『Effective Java 第3版』(p.319)

活性エラーはデッドロックとして表面化しますが、安全性エラーはコードが動作しているように見えるが正しく動作していないという問題を引き起こします。特に競合状態(race condition)により引き起こされる問題は、現象の再現性も低く、調査が非常に難しいことが多いです。

2013年7月から2015年5月まで行ったコントローラソフトウェア開発は、私にとっては4回目のコントローラソフトウェア開発でしたが、マルチスレッドプログラミングの複雑さをGo言語のゴルーチンとチャネルで軽減できないかの検証も狙っていました。しかし、やはりデジタル複合機のコントローラソフトウェアは複雑であり、デッドロックはよく発生しましたし、競合状態も発生しました。幸い、Go言語には競合検出機能が提供されているので、その点は助かりました。

現在、従事しているソフトウェア開発では、再入可能性が問題となるような複雑なソフトウェア開発は行っていません。その点では、4回のデジタル複合機のコントローラソフトウェア開発は、私に貴重な経験を与えてくれたと言えます。

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

  • 作者: Alan A.A. Donovan
  • 出版社/メーカー: 丸善出版
  • 発売日: 2016/06/20
  • メディア: 単行本(ソフトカバー)

Effective Java 第3版

Effective Java 第3版

  • 作者: Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2018/10/30
  • メディア: 単行本(ソフトカバー)


コメント(0) 

言語仕様とメモリモデル [プログラマー現役続行]

『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ページを費やして解説しています。

今日、マルチコアやマルチプロセッサを前提とした言語は、Javaだけではありません。たとえば、Go言語ではゴルーチン(goroutine)に関してのメモリモデルが、言語仕様であるThe Go Programming Language Specificationとは独立したThe Go Memory Modelとして定義されています。私自身は、C++でのプログラミングから離れてから久しいのですが、C++でもマルチスレッドプログラミングのサポートに伴いメモリモデルが定義されています。
※ 『プログラミング言語Go』では、「メモリモデル」という表現は使っていませんが、「happens before」関係に関しては、「8.4.1 バッファなしチャネル」、「9.1 競合状態」、「9.4 メモリの同期」で述べられています。

以前の記事「マルチスレッドプログラミングにおける重要な4要件」で述べた一番目の要件「きちんとしたレビュー」では、「マルチコアやマルチスレッドプログラミングのきちんとした経験および知識を持つ人が設計やコードをレビューしていること」と述べてします。ここでの「知識」には当然「メモリモデル」も含まれます。

JaSST Tokyo 2018の招待講演では、デジタル複合機のコントローラソフトウェア開発を4回行った経験に基づいて話をしたのですが、振り返ってみると、そのような開発に従事したからこそ、マルチスレッドプログラミングでの開発を経験できたと言えます。それらの開発は、C++もしくはGoによる開発でしたが、マルチスレッドプログラミングに関わる様々な問題(もしくは、ゴルーチンにとチャネルによる様々な問題)に直面し、デバッグを経験することで多くの知識と経験を得ることができました。

株式会社メルペイでbackend engineerとして働き始めて3か月が経過しましたが、(私のバックエンドの開発経験がまだ少ないからかもしれませんが)ウェブシステムでのバックエンド開発では、上記の一番目の要件を満足できるような開発経験を積むのは困難なのかなと感じ始めています。Go言語で開発していますが、メモリモデルを理解しないといけないようなプログラミングはほとんどしないので・・・私が今から経験する必要はないのですが、今の若い人達はいつ経験して知識を得るのだろうかと。

コメント(0) 

マルチスレッドプログラミングにおける重要な4要件 [プログラマー現役続行]

JaSST Tokyo 2018の招待講演で話した資料(こちら)に書いてあることですが、今までの人生で私自身は、デジタル複合機コントローラソフトウェア開発を4回もアーキテクチャを変えて行いました。デジタル複合機の難しさは、ハードウェアからの非同期なさまざまなイベントとユーザからの様々なイベントを両方を上手く処理しなければならず、かなり複雑なソフトウェアとなります。

ソフトウェアエンジニアとして合計すると10年以上をデジタル複合機コントローラソフトウェアの開発に従事し、マルチスレッドプログラミングを行ったことになります。公開資料に詳細情報は含まれていませんが、資料にある「Take 3」と「Take 4」は、デジタル複合機コントローラソフトウェアを完全にテスト駆動開発で行うというものでした。

4回ともマルチスレッドプログラミング(厳密には、Take 4はマルチゴルーチン(goroutine)プログラミング)を行った経験から言えるのは、次の4要件です(JaSSTの公開資料に含まれています)(書かれていませんが、テスト設計も非常に重要です)。

20180308 JaSST2018Tokyo(V4).001.jpeg

この4項目がきちんと行われいるソフトウェア開発はかなり少ないと思います。最初の項目のハードルが非常に高いからです(二つ目も、かなりハードルが高いですが)。つまり、以下のことができません。
マルチコアおよびマルチスレッドプログラミングのきちんとした経験および知識を持つ人が設計やコードをレビューしていること
ある程度(手作業であっても)動作が確認されたプログラムでも、ソースコードを見ると間違っていることがあります。マルチスレッドプログラミングが厄介なのは、その間違いが原因で不具合が現象として現れる可能性が非常に低い場合があることです。

上記の項目3に書かれているように膨大な長時間ランニングテストを数十台のPCで行っていたにもかかわらず、微妙な間違いが入ってから、3か月後に1台のPCだけでその間違いが原因で止まることを経験したことがあります。朝出社したら私のPCでテストが止まっていたので、数時間かけて若手と二人でデバッグしてその間違いに気付きました。しかし、その間違いはソースコードレビューだけではおそらく気付かないようなものでした。そして、その間違いの修正が入ったのがいつかを調べたら3か月前だったのです。

コメント(0) 

技術書の間違いに気付いたら [プログラマー現役続行]

「ぐるなび」社内の勉強会で『ベタープログラマ』を読んでおられて、今までに多くの間違いを指摘していただきました。


出版までに間違いをできるだけ少なくするように出版社も含めて努力をしていますが、どうしても誤字脱字だけでなく、技術的間違いを見落とすことがあります。

「ソフトウェアエンジニアの心得」と題した講演や教育では、「技術書には間違いがあると思って読んでください」と話しています。そして、技術的間違いだと思ったら、出版社や著者に問い合わせてくださいとも話しています。技術的間違いに関しては、大きく分けて次の二つに分類されます。
  • 確かに技術的に間違っている
  • 読者の知識不足あるいは勘違いにより間違いではない
どちらであっても、問い合わせて損することはありません。技術的に間違っていたら、著者や出版社から感謝されますし、著者によっては正誤表に名前を掲載して、感謝してくれます。正誤表に名前を掲載してくれる例としては、『The Go Programming Language』の正誤表(こちら)があります。まれですが、増刷ごとに本の中の謝辞に追加してくれる場合もあります。『Elements of Programming』は増刷ごとに謝辞が追加されています(正誤表はこちらです)。一方、指摘事項が実は間違いではなく、読者の知識不足や勘違いの場合、なぜ間違いではないかという回答をもらえば、自分自身の知識を修正することができます。

ただ、残念ながら間違いに気付いても連絡する人はそれほど多くはないようです。問い合わせ先を調べないといけないし、特に誤字脱字だと「まあ、いいか」となりがちです。結果、私の翻訳本に関しては、間違いの指摘をしてくれる人達の多くが、私の知り合いです。知り合いではない読者からの問い合わせや連絡は、非常に少ないです。

少し面倒かもしれませんが、技術書を読まれて間違いや誤字脱字に気付かれたときは、出版社、著者、翻訳者へ連絡していただければと思います。

コメント(0) 

第1回グローバリング・イノベーション・セミナー [プログラマー現役続行]

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

  • 出版社/メーカー: 翔泳社
  • 発売日: 2016/12/19
  • メディア: Kindle版

『Joy Inc.』の著者であるリチャード・シェリダンによる基調講演を含む「第1回グロバーリング・イノベーション・セミナー」が2018年1月10日(水)に開催されます。

セミナーの詳しい内容は、こちらです。

リチャード・シェリダンは、メンローイノベーションズ社の社長であり、メンローイノベーションズ社はソフトウェア開発において、デスマーチとは全く正反対でかつ、高品質なソフトウェアを作り出すためのソフトウェア開発組織を作り上げています。そこには、「Joy(喜び)」に満ちた組織が作られています。そのため、書籍のタイトルが『Joy Inc.』なのです。

書籍には、日本のソフトウェア開発組織がいまだに到達していないレベルのソフトウェア開発が述べられています。多くの日本企業の場合、単に「到達していない」のではなく、残念ながら「目指したことがない」事柄が多くの述べられています。ソフトウェア開発者や組織にとっては、この本の内容は、目指すべき姿の一つが描かれていますし、夢物語ではなく、現実にメンローイノベーションズ社では実践されているのです。

私自身もさまざまなソフトウェア開発で色々な改善を試みてきましたが、メンローイノベーションズ社のレベルを達成するには、マネジメント層の理解やサポートが非常に重要だと考えています。その意味でもソフトウェア開発のマネジメント層に読んでもらいたい書籍だと思います。

セミナーでは、私自身も技術講演として30分だけですが、私自身の取り組んできた実施例を紹介させてもらいます。

みなさんの参加をお待ちしています。

コメント(0) 
前の10件 | - プログラマー現役続行 ブログトップ