改訂2版 みんなのGo言語

全体の感想

ある程度自分でCLIやアプリケーション開発をした上で読むと、「あれってどうやると良いんだろう?ベストプラクティス的なのって何だろう?」という疑問が解決できそうな本でした。

僕は改訂前の本をA Tour of Goを一通りやり終えた後にすすめられて読んだのですが、あまりピンときませんでした。

しかし、プログラミング言語Goを読んで文法を理解した後に自分でCLIをいくつか書いてみたり、業務でGoのマイクロサービスをいくつか開発した今読むと実感できることが増え、改めて手を動かして確認したり、実践でも活用してみたいことが多いなぁと感じました。

全体的に各テーマ類似するパッケージの特徴や使い方やベンチマークを比較しながら評価・解説されていることが多く、自分で技術選定する際の参考にもなります。

Goを活用した開発を実践する上での課題を解決する手がかりが多く見つかるよい本でした。

各章の感想

1章 Goによるチーム開発のはじめ方とコードを書く上での心得

自分の開発環境を改めて見直すきっかけになってよかったです。

パッケージ分割の基準や大きいstruct作るべきではないのはなぜかなども言語化されていてなるほどなぁと思いました。

  • GOPATH、GOROOTは環境構築するたびに結局今ってどうするんやっけ?という気持ちになりますが自分の使い方では変える必要なさそうということでfix
  • Build ConstraintsをBuild Constraintsと呼ぶと意識して開発してなかったのでググる力が増しました
  • リポジトリ移動にpeco/peco
    を使ってなかったのでmotemen/ghqと合わせて使ってみます
  • Makefileのhelpコマンドは人が書いたワンライナーはっつけてましたがSongmu/make2helpよさそうですね
  • 「単独のパッケージとしてほかのプロジェクトから使えるかどうかがパッケージを分割する基準」よさそう
  • 「正規表現のパフォーマンスが悪いのは最悪ケースの処理時間が極端に遅くならないように設計されているため」知りませんでした
  • 「たくさんのフィールドを持つような巨大なstructを定義するのではなく、再利用可能な小さな部品を組み合わせてデータ構造を定義」よさそう

2章 マルチプラットフォームで動作する社内ツールのつくり方

一度でもCLIツールやアプリをクロスコンパイルして配布しようと思ったことがあるとありがたみが増す章でした。

バージョンアップデートを追うポイントについても学びがあり活かせそうです。

  • マルチプラットフォームに対応したツールを作るときは特にWindows周りでパス、文字列、ファイル操作、ホームディレクトリあたりを気をつけようと思いました。自分でCLIツール作るときはとりあえずmacOSで使えるものを作った後にクロスコンパイルしてWindowsとかでも使えるようにするぞ!みたいな流れだったので、最初から気をつけるべきポイントがわかっているといざ配布するときに体験を損なわずに済みます。
  • バイナリにリソースを埋め込むにあたり、jteeuwen/go-bindatajessevdk/go-assetsはもうメンテされないので、rakyll/statikgobuffalo/packrを勧めていた話の流れがよかったです。リソース埋め込みでまず思い浮かぶのがgo-bindataとgo-assetsだったので認識を改めることができました。
  • awesome-goGUIセクションがあることやGUI用のライブラリがたくさんあるのを知りませんでした。CLIツールを作るものという固定観念を打破してくれました。自分で積極的に作るモチベーションはないけれどそういう章があったら楽しめそうです。
  • 設定ファイルのフォーマットと場所をどうするかについて各フォーマット向けライブラリの成熟度などを比較した上で筆者の見解が述べられていたり、実装の注意点が整理されていたのがとてもよかったです。cgoを使っているかどうかによるクロスコンパイルの挙動差異や、ホームディレクトリ関連でcgoに依存しないAPIが特定Goバージョンから利用できるようになったことは自分がこれまで意識できていなかった観点で、バージョンアップを追うモチベーションやポイントの1つになりました。

3章 実用的なアプリケーションを作るために

タイムアウトやシグナルハンドリングなど、実践でよく使うが理解不十分だった部分の理解が深まった章でした。

  • 標準出力のバッファリングをあるLL言語と比較しつつ、bufioパッケージを利用した実装と利用していない実装を使ってシステムコール回数をstraceで観察していたのがよかったです。システムコール自体の重みがよくわかってないのでベンチとろうと思いました。
  • dustin/go-humanize便利そう。わかりやすく表示できるのも、わかりやすい形式で引数などに指定できるのもいいですね。
  • 乱数系のパッケージはおそるおそる使っている感があるのでmath/randcrypto/randの性質の違いがまとまっているのはとてもありがたかったです。
  • contextパッケージはタイムアウトやgoroutineを扱う上で必ず通るのでありがたかったです。シグナルハンドリングと合わせて載っていてありがたみが増しました。シグナルハンドリング実装はよく目にしますが、シグナルを受けたときのデフォルトの挙動がドキュメント化されているのは知らず、とても良い知見でした。
  • 「シグナルハンドリングでやるべき処理」
    • 外部からの新規リクエストを受けなくする
    • 受信時に実行中の処理が完了するまで待つ
    • メモリ上に確保したバッファをすべて書き出してファイルを閉じる

4章 コマンドラインツールを作る

CLIを書くときに実践すべきことが詰まっている章でした。

はじめてCLIを開発し、テストの仕方を調べるときも筆者のブログを読ませていただいた記憶があります。

flagパッケージへの気持ちも感じることができました。

  • パッケージ構成を考える上でバイナリ + ライブラリを提供するのか、ライブラリを提供するのかで変えるのは面白いなぁと思いました。ただ、バイナリメインでもコマンドはcmdの下において外部提供する意図の無いパッケージをinternal下に置くのもありなのかなぁとも思いました。何れにしても意図をパッケージ構成で伝えるというのは取り入れたいです。
  • flagパッケージの使いこなしを実装を追いながら学べ、その他サードパーティの利用方法や特徴と比較していた点がとてもよかったです。章全体でなぜ?が重視されていて学びが深まったので、筆者が標準のflagパッケージしか使わなくなった点も一層気になりました。
  • 「os.Exitはdefer文で呼び出した関数を実行せずに処理を終了する」あまり意識してなかった気がするので気をつけてみます。本章にも書いてあるとおりos.Exitは無闇に呼ぶべきではないと思っているので、仮に出会った時に見落としそう。
  • 「ロングオプション: 説明的、シェルスクリプトやドキュメント、ショートオプション: 簡単に素早く」そうだなぁと思いました。
  • 今度サブコマンドを扱うCLIを書くときはmitchellh/cliを使ってみようと思いましたがメンテされてない…?サブコマンドをインターフェースとして定義するの好きです。

5章 The Dark Arts Of Reflection

ベンチをとった解説がわかりやすく、reflectionのメリット・デメリットがよく伝わる章でした。

他の章でもベンチをとって比較するのは登場していたのですが、特に効果的に感じました。

  • 型アサーションとソートについてreflectパッケージを使う場合とそうでない場合のベンチを比較していて、利用場面を選んで使うべきという主張の説得力が増していてよかったです。
  • 動的にselect文を構築する部分は難しくてよくわかりませんでした。

6章 Goのテストに関するツールセット

アプリケーション開発で常に実践せざるを得ない感がもっとも強い章でした。

ベンチマークを普段ほとんどとってないので、実装方法で迷ったり、チューニングする上ではやらねばと思いました。

僕はモックはgolang/mockが好きで、比較はgoogle/go-cmpが気になるものの試せていません。

  • Exampleテストのfunction名でgodocのどこに載るかが変わるのを知りませんでした。
  • reflect.DeepEqualの挙動がtypeごとに説明されていてよかったです。ドキュメントにけっこう書いてあるんですね…!意外とオジェクトを比較するテストに出会っていません。
  • Race Detectorの出自を知らなかったので勉強になりました。使用時にメモリ使用量5〜10倍、実行時間2〜20倍になることや、静的解析ツール出ないことも書いてあってよかったです。
  • インテグレーションテストとユニットテストをBuild Constraintsで分ける話がよかったです。Makefileにテスト種別を区別して実行するためのパッケージ分類スクリプトが書いてあるのを見てきましたが、Build Constraintsを使うと明示的になりそうです。
  • カバレッジについては所属組織のデフォルトMakefileやIDE、ツール(Sourcegraph)に頼っていたのでそもそものgo toolの中身を知れてよかったです。

7章 データベースの扱い方

DBやそれを扱うためのORMの章ではありますが、ライブラリ選定をちゃんとやろうという気持ちになれる章でした。

普段GoのAPIを書くことが多く、フロントも込みで開発することがないので画面込みで開発する部分は別章が丸々設けられていても楽しそうでした。(それやると別タイトルの本になりそう)

  • cgoに対するpure goという概念を覚えました。
  • mattn/go-nulltypeの紹介が、DB文脈でnullableを扱う上での課題を十分に説明した上で出てきて良い流れだなぁと思いました。
  • ライブラリの選定プロセスを垣間見ることができる構成でとてもよかったです。
  • 「本書が古くなりこれらのライブラリが古くなってしまったとしても、プログラマのみなさんがやるべきことは変わりません。新しい技術要素を調査し、あらゆる候補を比較するためにベンチマークをとることです」は最高のしめでした。

改訂2版 みんなのGo言語

CloudNative Days Tokyo 2019で登壇してきました。振り返ります。

発表資料はこちらです。

なぜプロポーザルが必要なカンファレンスに登壇するか

今回の登壇は初めてCFPに対してプロポーザルを提出し、審査を経たものでした。

なぜプロポーザルを提出する系のカンファレンスで登壇をしたいと思ったのかについては2019年1月に遡ります。

目標を立てるにあたって昨年は登壇回数を指標にしていました。それももちろん意味はあるのですが、

「自分はこれを喋る」というのを明確に定めた上で検証、準備し、そのテーマに興味のある人にダイレクトに話を届け、問い、フィードバックを得て自身の学習サイクルやスキルを向上させる

というのが意義だと思っています。

それで日々お世話になっているコミュニティへの貢献だったり、仕事で生み出す価値の質が上がれば言うことはありません。

2018年の振り返りと2019年の目標 〜何かしらCFP出すぞ!〜

そのため、今年は登壇回数ではなくてCFPを4ヶ月に1回出してみるというものに習慣目標を変更しました。

その後またOKRの運用を始め方針が変わったものの、プロポーザルの内容がOKRでより具体的になる感じなので両立できそうです。

2019年4〜6月ふりかえり 〜個人OKR運用開始〜

テーマの選定

プロポーザルとして提出したのはこんな文章 + αでした。

講演タイトル – Abstract Title

(最大50文字)受講者の目を引くようなるべく具体的なテクノロジー名を含めることをおすすめします

Knativeで実現するKubernetes上のサーバーレスアーキテクチャ

講演内容 – Abstract

(200文字程度)どんな人に向けた講演かこの講演によって受講者がどんな情報を得られるかを含めることをおすすめします

Kubernetes(K8s)上でサーバーレスアーキテクチャを実現するKnativeが何を解決するのかを構成するコンポーネントやユースケースを交えて紹介します。
本講演は次のような方を対象にしています。
・Knativeがなんなのか、k8sとどのような関係にあるのか、どういう仕組みなのかを知りたい
・K8s上でもサーバーレスアーキテクチャを実現したい
・K8s上のアプリケーションの開発・運用負荷を下げ、機能開発により集中したい

なぜKnativeをテーマにするのかについてはこれまでのServerless Meetup、mercari.go、技術書典6など折に触れて書いてきました。

  • みんな大好きLambda奴を自分で実装できるっぽい
  • Kubernetes詳しくならざるを得ない状況を作れる

からです。

Serverless Meetup Tokyo #11 で「入門 Knative 〜KubernetesとServerlessとの出会い〜」を話してきました #serverlesstokyo

1〜2月にKubernetes完全ガイドでK8sに入門し、2月にk8s source code reading #1に参加してみてちょうどCFPの話があったので応募してみることにしました。

提出時点ではまだKnativeに触ったことはなかったものの、5ヶ月くらい準備があり、継続して学びたいテーマであるため「自分がこの5ヶ月で理解したいこと」をプロポーザルに書くことにしました。

準備

主に準備すべきことはプロポーザルに書いたこの3つです。

①Knativeがなんなのか、k8sとどのような関係にあるのか、どういう仕組みなのか
②K8s上でもサーバーレスアーキテクチャを実現するにはどうしたらいいのか
③K8s上のアプリケーションの開発・運用負荷を下げ、機能開発により集中するにはどうしたらいいのか

①についてはServerless Meetup、mercari.go、技術書典6で調べていたのでアップデート分を調べつつ、直近の2週間では②、③を中心に検証したり調べたりしました。

特にユースケースについてREADME以上のことに触れられていなかったので、「③を実現するサーバーレスアーキテクチャを実現するためのプラットフォームを構築する」という観点でtriggermesh/knative-lambda-runtimeやOpenFaaSを調べました。

振り返り

OKR

CNDTは個人OKRを達成する上で重要な位置付けにありました。Objective2は家庭面なので、CNDTの位置付けが明示されているObjective1について振り返ります。

Objective 1

DIY FaaSのためのKnativeのユースケース、動作の仕組みを理解する

Key Result 1

どんな課題に対してどう使うのかを説明できる

  • CloudNative Days Tokyo 2019 登壇
    -> コンテナベースのアプリケーションを開発するにあたり、各ユースケースがどんな課題を解決するのかを意識して説明するようにしました。

K8sでサーバーレスをやる意義の中でKnativeがK8sとサーバーレスをどう捉えているか述べた上で説明した(つもりな)のでよかったんじゃないかと思います。

  • ServerlessDays Melbourne 登壇
Key Result 2

Knativeを使ったプロダクトでどう利用されているか説明できる

  • CloudNative Days Tokyo 2019 登壇
    • Knative Lambda Runtime

-> これは今回の登壇で一番伝えたかった部分です。FaaSをDIYする上でのリファレンスアーキテクチャの思想や設計を調べるのは楽しかったし、一般化できたのは大きな進捗でした。

スライドの図 + コードを見ながら具体的に追っていくことがさらに理解を促し、自分で作る上でも意義があると思うので下に書いてあるKnative本で実現しようと思っています。

  • 技術書典7執筆 既刊Knative本アップデート
    • Pivotal Function Service
    • OpenFaaS functions on knative
  • 何かCloud Runの話できる機会があれば
Key Result 3

Knativeの主要機能の実装方法を説明できる

-> CNDTの文脈ではかすりませんでした。

mercari.goの反省を踏まえて

6月に登壇した mercari.go #8での反省を踏まえて次のようなことを意識してCNDTの準備を行いたいと書いていました。

mercari.go ♯8で『Goで学ぶKnative』を話してきました #mercarigo

人に事前に2回聞いてもらい、軌道修正する

  • 今月(6月)中に目処を添えてお願いする

-> 何もかもできませんでした。事前に見て欲しいのは

  • 道徳、コンプラ、セキュリティ面でアウトなことがないか
  • 人に聴いてもらって感想をもらったら大体気づきが得られる

という目的があったと思います。

  • 割とこれまで話したことが多い
  • 書籍などこれまでのアウトプットに対してもらったフィードバックやこれまでの登壇のフィードバックを盛り込んでいる

などがあり「事前」にそこまでこだわらなくてもいいかもと思い始めました。

ただ、OKRを決めて集中すべきことを絞るのはギリギリまで資料作りに追われるようなスケジュールにしないという意図もあるので、何かの登壇前には一度やってみようと思っています。

やってみた上でスタイルは決めたいです。

あと事後的な感想はまだ間に合いそうなので聞きに行ってみます。

テーマである「解決する課題」を明確にして関係するユースケースを話す

  • デモとかするにしても何のためにやって何を見て欲しいかを明確にする

-> けっこう久々にデモしました。「簡単さ」「手軽さ」みたいなものを伝えるならmanifestファイルをkubectlで適用するのではなくて、knコマンドなど直接それらを触らない形で見せられるとよかったのかもと思っています。

漠然と機能や実装を追わず検証のゴールを先に決める

  • つぎの土日は項目出しのためにグダグダ調べていい
  • ただしその後は集中すべきことに集中する。やすみやすみ!

-> 今回は何か作業する前にリスト作ってそれに集中するというのを意識的にやった気がします。それも含めた管理にNotionが適していたので使い始めました。

Good

プロポーザル出した

第一歩を踏み出せたことはよかったなぁと思います。

調べたかったことを調べて理解できた

K8s上でFaaSをどうやったら作れるか?の具体的なイメージがわく程度に調べることができてよかったです。

ただ、その主要な調査自体は1日だったので、Objectiveを達成するためにもっと近道しようと思えばできるということは意識しておきたいです。早く切り上げてより難しいことや他のことをやりたくなったとき向けに。

準備プロセスの改善

やる作業のスコープを定めて集中するのと調べる項目を洗い出すのに時間をとるのはよかったです。

とはいえ調べてる途中でも項目は変わるので、アウトプットも1つのプロダクトと思ってアジャイルしますかー

Challenge

前見て喋ろう

DEMOもするのでマイク固定で話していたら前傾して前を見れないし、反応見れないしでけっこう不安なまま突っ切った感があります。

固定できても必要なときだけホルダーに置き、基本は持つようにします。

あと今回せっかくピンマイクも使えたのに普段と違う設備でやるのが不安で避けましたが多分使えたら使うのがベストプラクティスっぽい。

後ろからDemo画面見よう

大きめにしてたけどDemo画面後ろまで見えてたかわからぬ…

スクリーンに表示して後ろから見て調整するようにします。人から今どう見えてるのかは把握しときたい。

分量

セッション枠に対してゆとりある分量にしてゆっくり喋りたい。

とりあえず資料作って読み上げたら40分枠に対して50分以上かかりました。そこから内容を削り、練習では最終的に43分くらい。本番も42分半。アウトです。

詰め込めるように練習してなんとか時間を短縮したのもあって、本番を想像すると近況が余計に増すのが何より厳しかったです。

時間が余りそうなら余りそうで不安だとは思いますけどね。

「ゆっくり話して収まるように思い切って削る」を次はやります。

セルフログミー

Serverless Meetupの登壇資料とログミーさんから出た記事の媒体の反響の差分は資料単体の拙さだったり、コンテキストの差だと思います。

今回の登壇準備で得た知見はコードを追いながら文字で説明したい部分が特に重要な箇所だったので自分でやってみようと思いました。

それがそのままKnativeの既刊に追加されそう…

表面的

技術的深掘りがREADMEから抜け出せてない感がまだまだ強いです。

今回いただいたフィードバックの観点や実装面で深掘りして新刊を出すので、そこでもう少しなんとかしたいです。

それでもアウトプットの機会を経るごとに理解できたと思うことは増えているのは思うので、理解しようとするスコープを定めて着実に進んでいこうと思います。

妥協したが理解した方がいい部分

  • RouteとIstio
    • RouteがIstioのリソースをいじってると思い込んでてGateway、VirtualService、DestinationRuleなど探したものの、Routeの変更が反映されたりはしていませんでした。Glooなど他のGatewayに差し替えれるにしてもRoute設定したときに何を変更しているのかなどは理解したいです。
  • Tekton
    • TektonでPipelineを作ってKnativeのサンプルをデプロイしようとしたもののできなかったのでその原因を調べ切りたいです。
  • CloudEvents
    • もっと追ってみると楽しそうでした。FaaSの課題、イベントドリブンなものを作るつもりで書いてたのにあまり触れられなかったのもイケてないです。
  • Eventingのリソース
    • brokerとfilterのdeployment、ラベルを消してもDeploymentを消しても何度でも蘇り消えなかったので実装追いたいです。
    • issueにさっきコメントついたので読む

仕様を覚えるだけで実現する仕組みを追わないのは、他のことを追い始めても先が見えてる気がするのでここは後手に回っても最終的に妥協しないようにしたい。

あと、この文脈は関係ないけど登壇依頼される程度に特定の分野に詳しいことが認知され、なおかつその分野の正しい見識を持っている状態になりたい。

フィードバック

登壇後にAsk the speakerで何人かにご質問いただいたり、お話ししたり、インターネッツから拾ったりしました。

Knativeの発表でこんなに色々話してるの聞いたのは初めてみたいな声はお世辞でも嬉しかったです。

  • K8s使い始めだとメリットが理解しづらかった
  • 実際どう?使ってる?メルペイでもサーバーレスワークロードって検討してる?
  • K8sクラスタでFaaSを使えるようにする意義は?
  • node affinityと両立するにはどうしたらいい?(?)
  • FaaSはわかるけどPaaS基盤を構築するってどういうこと?
  • いつGA?ロードマップでてる?
  • ブルーグリーンデプロイってK8sやIstioでもできると思うけどKnativeでやる意義は?
  • 隠蔽されることで調査しづらくなったりする部分ないか
  • K8sでできるけどKnative使うとできなくなることないか
  • (プラットフォーム的に現実的に選択できる)Cloud Runどう使うとよさそうか
  • Istio、Gloo以外にもAmbassador使えるのでは?
  • EventingのIstio依存ってもうないのでは?

自分のアウトプットに対してこういう声をもらうのが目的なので本当に嬉しいと思ったり、重要な視座をもたらしてくれる人はだいたい変わらないのでそういう人に直接話に行った方が強くなれるのでは?って思ったりしています。

特に最後の5つはいざ使うときに技術選定する大事なポイントだったり、自分が情報を追う上で見つけられなかった点だったりして深めていこうと思います。

その他も言われてみたらたしかに気になる点だと思うし、node affinityの件は問題を生じる状況を理解できていないところだったりします。

一番のフィードバックは業務で得られるはずですが、それに加えて行なっている個人的な活動なのでいただいた内容を糧に強くなっていこうと思います。

四半期ごとの人生振り返りです。

サマリ

個人OKRで集中とゆとりを

習慣

2019年の目標

  • 本(執筆): 2冊/年
  • CFP: 4ヶ月に1回出してみる
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術書(読む): 30分/日
  • その他本(読む): 30分/日
  • ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月
  • ピアノ晒す: 1回/月
  • 筋トレ: 1回/週

進捗

本(執筆): 2冊/年

1/2

前回から変更ないです。技術書典7に出典申し込みしたので、8〜9月にもう1冊を書けたらいいですね。

CFP: 4ヶ月に1回出してみる

CloudNative Days Tokyo 2019のあと、海外カンファレンス2つに計4本のプロポーザルを出しました。合計5本になったので今年の目標は達成です。

年初のプロポーザルを提出したことがない状態から「とりあえず書いてみる」はできるように成長したと思います。

テーマがあれば関連する国内外のカンファレンスに提出する習慣はできたので来年は別の目標にしようと思います。

今年修正しないのは今年提出予定のカンファレンスがあと2〜3回あり、まずはそれをできる限りいい感じにこなすので手一杯だからです。

いっぱいいっぱい感がすごいのでそれをなんとかする目標は早い段階で立てないとちょっと体がもたなそうで、断るというのを覚えた方がいいかもしれません。

8月のServreless Days Merbornは審査に通過したので15分Knativeのお話をしてきます。初海外カンファレンス登壇ドキドキ!

ServerlessDays Stockholmもプロポーザル出したいのですがServreless Days Tokyoに近すぎるので自重するか迷います。CFPのクローズが9/1なので、8月半ばに考えます。

OSS: 1PR/月

8/3

https://github.com/ahmetb/cloud-run-faq/pull/22
https://github.com/syndbg/goenv/pull/86
https://github.com/syndbg/goenv/pull/84
https://github.com/knative/docs/pull/1373
https://github.com/syndbg/goenv/pull/83
https://github.com/syndbg/goenv/pull/78
https://github.com/syndbg/goenv/pull/73
https://github.com/knative/docs/pull/1147

達成したものの、ただGoがリリースされた瞬間にgoenvの設定ファイル足すマンになってるだけですね…

CloudRunのFAQ修正はGCPUGで話題になったことを一応手を動かして確認したのでよかったかもしれません。

数を追う目標はこの辺でおいておいて、本当にコントリビューションしたいOSSに腰を据えて取り組む方が意に沿っているかもしれません。

ひとまとまりのソースコード公開: 1リポジトリ/月

ダメです。

技術書(読む): 30分/日

読んだ

カスタムリソースやコントローラーに入門するのにうってつけでした。今度の技術書典のテーマなのでもう一度読んで咀嚼したいです。

読んでる

その他本(読む): 30分/日

読んだ

めっちゃよかった。前職からOKRで目標管理されているけどO/KRの設定仕方やそれをいい感じに運用するためのC(対話)F(フィードバック)R(承認)への認識を見直せた。

薄々意識しつつあまり考えないようにしていたけど、個人の振り返り(四半期ごとにやるこのブログ状のもの、会社のではない)ではよさげな習慣を身につけるべくコントローラブルな目標をどの程度達成したかを確認しています。

けどそれってO(目標)なきKR(主要な結果)なのではと思います。

よさそうな習慣なんて取捨選択しなければ自分ではこなしきれないほどある中で、何を大事にするのかは目指すべき方向性から考えると平和そうです。何を捨てるかも同じです。

最近は登壇と執筆の1つ1つが重い中、業務も産みの苦しみを味わっている真っ只中で公私ともに心のゆとりを失いました。

自身の挑戦や成長に伴って得られた思いもよらない機会を大事にしたい一方で、1つ1つクオリティが下がっても元も子もないなと思います。

読んでる

If you want to go fast, go alone. If you want to go far, go together.

の後者の意味を忘れつつあるので思い出したいです。

1人でやってるわけでも全然ないのになんやろう?

ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月

今QベストはMeasure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKRでした。

ピアノ晒す: 1回/月

とうとう晒し始めることに成功しました!

YouTube チャンネル

が、早々にピアノを触る余裕を失ったので取り戻したい。

筋トレ: 1回/週

完璧!

往復40分、1回500円、回数券とポイントありのところに通い続けるか、近くのエニタイムに変えるかはちょっと迷っています。

外部的要因が無ければチャリも運動と思って続けそう。

技術面

12月のServerless Days FukuokaのCFPに応募して「Knativeで作るDIY FaaS」みたいな話がしたいです。

話せなくていいから作りたい。そしてServerless Advent Clendarとかでコード交えてじっくり説明したい。

OKR

OKR本の文脈で書いた取捨選択らへんの話をもう少し考えてみます。

今年の予定はここから雑誌寄稿を追加する予定なのと、Serverless Meetup Tokyoの登壇が次の回にずれるというのと8月のSeverless Days Merbornに登壇する以上には増えないかもしれません。

とは言え、7月段階で考える半年の予定なのでかなり当てにならなそうです。

個人OKRを決めて集中すべきことに集中してみようとなったときに、仮に「FaaS作るぞ!」をObjectiveに据えると

  • 今関心があってやってみたいことなので、3ヶ月これに集中するぞ!という絞り込みには有効そう
  • 長期的に何ができるようになりたくてどう位置付けるべきかは考えないと「で?」ってなる
  • 登壇や執筆は求められるテーマとタイミングによるところもあるが、そこまで乖離することもないのでObjectiveから導ける範囲で取り組むと有効に活用できそう
  • 暗黙の長期目標(これを明らかにしたい)の中で足腰鍛えたいなぁと思うこと、例えば前回の振り返りの技術面で書いたネットワーク(L4/L7、DNS、名前解決)なども「Knativeを触る上で必ず出てくるので1つKey Resultにおいてみる」とかするとモチベーションを保ったまま強くなれるのかもしれない

という感じで、概ねポジティブな印象です。

一方、これから7〜9月のOKR考えるぞ!ってなったときに、ある程度の執筆や登壇のテーマは先に決まっていて、それらをこなすだけでも時間かかりそう。

ただ、技術書典の出展申し込みをしたときのスタンスとして、「今はKnativeの実装をKubernetesのコントローラーを見ながら詳しくなりたい。ただし、書き始めたタイミングで興味関心が変わればそっちを書く」としていて

  • 事前申し込みするときテーマ・解釈に幅を持たせると気持ちが楽
  • 1〜2ヶ月(申し込んでから実際に準備したりするまで)でそこまで興味関心すぐ変わるというわけでもなさそう

とも思うのでクオーター単位のOKRから始めていって様子を見ることにします。ただし必ず生活面のOKRも含めることとする!

2019/07〜09

Objective 1

DIY FaaSのためのKnativeのユースケース、動作の仕組みを理解する

Key Result 1

どんな課題に対してどう使うのかを説明できる

  • CloudNative Days Tokyo 2019 登壇
  • ServerlessDays Melbourne 登壇
Key Result 2

Knativeを使ったプロダクトでどう利用されているか説明できる

  • CloudNative Days Tokyo 2019 登壇
    • Knative Lambda Runtime
  • 技術書典7執筆 既刊Knative本アップデート
    • Pivotal Function Service
    • OpenFaaS functions on knative
  • 何かCloud Runの話できる機会があれば
Key Result 3

Knativeの主要機能の実装方法を説明できる

Objective 2

嫁氏とゆったりした時間を過ごす

Key Result 1
  • スパイダーマン観に行く
  • バンブルビー観る
Key Result 2

花火大会に行く

よさそう。長期的なことや次のQを意識しつつ直近3ヶ月に集中すること書くのは目的意識を持てそうです。

筋トレとかピアノとかも年間で掲げている習慣を意識するのもいいかもしれないですが、3ヶ月で何を目指すかの方が調整もできてやる気も出るかもしれません。

長期の目標を達成する上で3ヶ月単位では漏れてしまうことは1年の習慣の方においておいてもいいかなと思う一方で、長期目標を達成するための過程として各QのOKRが設定できてるなら敢えて分ける必要もないかも。

登壇

mercari.go ♯8で『Goで学ぶKnative』を話してきました #mercarigo

執筆

技術書典4月でしたね。BOOTHでも継続して販売してます!

関連記事

記事

バズらないことに定評があるので嬉しいです。

3月の登壇をログミーさんに記事にしていただきました。

話した通りに完璧に文字起こししていただいたのですが、自分の言葉遣いが酷くて反省しました。

結果、読める程度に大幅に修正することに…

仕事面

生きたい。

とある目標を持ち始めたので、それを実現するために個人OKR活用できるかもしれません。

仕事は仕事で達成すればええやんとも思うものの、ストレートに結びつかないこともありそう。

生活面

ひたすら猫がかわいい。

haru201907121

技術書典6の売り上げで購入した食洗機、本当に買ってよかったです。

分岐水栓取り付けについては、固着してカバーが外れなかったので自力では全部できず大変でした。本当にほぼ新築なのか…?

mercari.go #8で登壇してきました。振り返ります。

発表資料はこちらです。

登壇経緯

社内勉強会のGo Fridayに出れるときは出るようにしてるのですが、その勢いです。

勉強会後にSlackの分報部屋で10分くらいなら喋れるかもしれないって呟いたら回収していただきました。

テーマ選定

社内SlackにKnativeのアイコンを登録するなどしている割には何も実装を追ったことがなかったので追ってみることにしました。

KubernetesのコントローラーとKnative

Goで書いてるならまぁ読めるやろくらいの気持ちで臨みました。そしたら個々のコードの意味はなんとなく追えても全体像の見えなさがすごかったです。

Programming Kubernetes: Developing Cloud Native Applications

を読んでみると本番の2、3日前にようやく自分なりの整理の仕方が見えてきました。

「ライブラリとコード生成ツールとSDK」を区別し始めて次のようなポイントに落ち着きました。

kube-apiserverのライブラリclient-goの機能もProgramming Kubernetesや実装を追いながら

  • なぜ直接WatchやListを直接実行せずinformerを介するのか
  • インメモリキャッシュの実体は何か
  • Listとlisterの違いは何か
  • workqueueにエンキューされるのは何か

などを調べました。

この図には至ったものの、sample-controllerの方の図にあるFIFOキューとReflectorがknativeでは見つかってません。

もし無いならなぜ使わない判断をしたのか理解していません。

ちゃんと追いたいところです。

振り返り

Good

30分話しきった

何はともあれ話しきったのはよかったとしたいです。

Kubernetesのコントローラーへの興味が強まった

これまでKnative文脈ではどうしても概念の理解やKubernetes自体に必要な膨大な知識をキャッチアップするのに必死でした。

そこから具体的にどう実装されているのに踏み込むんだことでこれまでと違う視点が得られてよかったです。

CRDとコントローラーも言葉では知っているつもりになっていたものの、いざ追ってみると何一つわかってなくて高まりました。

準備期間がちょうど技術書典7の募集期間と被ったこともあり、Knativeを切り口としたコントローラーの話で応募することにしました。

Knativeの既刊もバージョンアップしたいのでバランスは難しいところですがやっていきです。

Goへの気持ちも高まった

今年前半のお仕事ではがっつり実装していたわけではなかったですが、最近は実装タスクの割合が高く、Goの一実装として学ぶことが多かったです。

  • 無限ループを安定して実行する
  • ゴルーチン、チャネル
  • 複雑なクライアントを組み立てる
  • コード生成
  • スレッドセーフなキュー
  • サーバーリクエストとキャッシュ機構

すぐにでも活かしたい部分があるので活かそうと思います。

Goを学び始めたきっかけの1つがサーバーレスなOSSへのコントリビューションなのでそちらもやっていきたいです。

練習

30分の発表でも事前に4回くらい通して読んで時間調整できたのはよかったです。

最初とりあえず30分読んでみたら16枚余ったので、その時点と比較するといい具合になったと思います。

Challenge

時間のやりくり

毎度イベント前に休んだりしてる気がしますが、今回は発表の週に1日丸々 + 2週間朝晩集中室に引きこもりました。あと土日。

強すぎる切迫感と集中を欠く割にダラダラ過ごした感もあるので、来月の登壇は進め方を工夫します。

集中することを決めるのに集中する。

そして焦っているときほどはやる気持ちを抑えて「25分集中して5分休む」のポモドーロのサイクルを徹底する。

一方で、今回も全体像を見通して集中することを決めようとはしていたものの、何に集中すべきかがよくわからず右往左往した時間が長かったです。それを見つけるために、行き詰まったら人に聞くとかやりようはあるかなと思いました。

会社にもコミュニティにも強い人類はたくさんいるので。

ライブソースコードリーディング

その場でやり切る意図がそこまでない(技術書典の話に繋げたい)にしろ、

  • もう少し大きく映す
  • ゆっくり進む

などやり方は工夫できたかなと思います。

フィードバック

自分で知りたいと思ったことが知れたのはいいとして今回の話を人が聞いてどう思ったんでしょう?

Goを冠した勉強会で話す内容として適切だったんでしょうか?

せっかく懇親会もあるので聞けばよかったですね。

まとめ

つぎは初のCFPを経たカンファレンスでの登壇。

  • 人に事前に2回聞いてもらい、軌道修正する
    • 今月中に目処を添えてお願いする
  • テーマである「解決する課題」を明確にして関係するユースケースを話す
    • デモとかするにしても何のためにやって何を見て欲しいかを明確にする
  • 漠然と機能や実装を追わず検証のゴールを先に決める
    • つぎの土日は項目出しのためにグダグダ調べていい
    • ただしその後は集中すべきことに集中する。やすみやすみ!

というわけでやっていき!!ぜひ遊びに来てください!

https://cloudnativedays.jp/cndt2019/

技術書典6、無事終了しましたね!関わられたすべてのみなさんお疲れ様でした。

つぎの出展に備えて振り返りたいと思います。

本の内容についてはこちらにまとめています。

技術書典6で『Knativeの歩き方 KubernetesからServerlessを訪ねて』と既刊第2版を出展します #技術書典

手にとってくださった方はこちらのページで変更内容をお知らせしていくのでぜひ見てみてください。

早速修正がありますすいません…

『Knativeの歩き方 〜KubernetesからServerlessを訪ねて〜』の正誤表と増補改訂情報 #技術書典

謝辞

今回も単著と言いつつも妻に編集や表紙デザイン、サークルカット作成、入稿(本とダウンロードカード)をお願いしました。

初めてだらけの前回と比べると多少平和だった感はあるものの、4/8入稿に対して4/7の夜まで粘ってしまったので丁重に労わせていただく所存です。

執筆環境として、TechBoosterさんのTechBooster/ReVIEW-Template@atsushienoさんのatsushieno/vscode-language-reviewを今回も活用させていただきました。ありがとうございます!!

振り返り

Good

テーマ

こちらでも書きましたが、Kubernetesをある程度理解しないと先に進めないKnativeをテーマにしたことは仕事にも大いに役立ちました。

Serverless Meetup Tokyo #11 で「入門 Knative 〜KubernetesとServerlessとの出会い〜」を話してきました #serverlesstokyo

さらに、サーバーレスと謳っているとはいえ最初は愛しのLambdaには程遠く感じたKnativeも、愛しのLambdaに感じる愛しさの根源を見つめ直し、それをKubenretesの利用者に届けたい気持ちを感じとれたことは今後の検証の方向付けになりました。

CloudNative Days Tokyoでも「Knativeで実現するKubernetes上のサーバーレスアーキテクチャ」というタイトルで発表させていただけることになったので進めていきます。

その検証の課程で『Knativeの歩き方 KubernetesからServerlessを訪ねて』をよりよくしていきます。

具体的にはつぎのような内容の章を追加します。

  • Knativeのコンポーネントを組み合わせたユースケース
  • Knativeを使ったプロダクトを利用することで「開発者にとってより機能・サービスのユーザーに対する価値向上」に集中できるか
  • Knativeで作る俺たちのLambda

そして何より、普段の仕事で感じるような感じないような課題と自分の趣味の交点がこのあたりな気がするので楽しい!!楽しいよ!!!

わくわくする技術との出会いが何よりも大きな価値です。

って書いたら振り返りもう満足した。

BOOTH事前販売

技術書典5では本番後に販売を開始しましたが、今回は入稿日に販売を開始しました。

Knativeの歩き方 KubernetesからServerlessを訪ねて(PDF、ePubセット版) #技術書典

前回そうしなかったのは「本来紙本を買ってくれるはずの人が紙本でなくBOOTHに流れ、紙本が売れ残るのがこわかったから」です。

BOOTHで事前に買ってくださる方は当日参加できない事情がある(別の用事がある、興味があるが会場が遠い)方のような気がしたのと、紙本売れ残るリスクそんなに感じなくなりました。

ABテストできるわけではないので何とも言えないですが、収益が目的ではないので告知タイミングで欲しいと思ってくださった方が当日を待たずその場で手に取れる方が幸せだと思うので今後もそうします。

うれしい感想

いただいた感想が嬉し過ぎて本当に書いてよかったなぁと思いました。

前書きに始まるKnativeを僕が書く必然性(僕が書くのにふさわしいとかそういう意味ではない)や、それぞれのコンポーネントのサンプルの登場させ方、順番、組み合わせ方。

中身としてはREADMEを超えるものにはなりませんでしたが、話の流れとして自然になるようにする部分にはこだわりました。

そういう部分や愛情が伝わったのは嬉しいです。

そしてKnativeを一緒にわいわいやる仲間が増えていくのは財産です。

本のタイトル

お気に入りです。

Serverless meetupを諦めなかったこと

去年のServerless ConfはLTやってみたい!と思っていたものの、技術書典5の準備と重なったり、それを発表できる形に整理する方法も思いつかずただただ指をくわえて見ていました。

今回は3月頭という技術書典1ヶ月前のタイミングでのServerless Meetup登壇を1つのマイルストーンとし、自分の認識もブラッシュアップしながら進めることができました。

Serverless Meetup Tokyo #11 で「入門 Knative 〜KubernetesとServerlessとの出会い〜」を話してきました #serverlesstokyo

継続して取り組みたい大きなテーマがあるときはアウトプットの場が分断されずいい感じに繋がるので継続したいです。

最新バージョンへの追従を諦めなかったこと

入稿数日前に0.4系から0.5系へのアップデートがリリースされ、1つのコンポーネントのアーキテクチャが大きく変更されました。

進捗も逼迫していたので迷ったのですが、開発に勢いがありどうせすぐ情報が古くなるなら可能な限り新しいものを届けたいと思い追従することにしました。

もし古いままだと、本を読みきったと思ってもまた別途新バージョンをキャッチアップする必要が生じやや二度手間感が生じます。

それよりは早くユースケースに進んでわいわいして欲しい。結果期限ギリギリになり妻には迷惑をかけてしまったので丁重にry

CloudNativeコミュニティの方々との交流

事前にテーマの近い人が知れる(そういう風に配置していただける)ことで事前にTwitterでいろんな方と交流できたのもよかったです。当日を迎えるのが楽しみになる要素の1つでした。

CloudNativeコミュニティやその勉強会、Meetupでもぼっちにならない…!ありがとう!!!

謎の試み

何に1000円を支払っていただくのか

前回比ページ数が減った上で同じ値段なの気が引けると思っていたこともあったのですが、そう考えるのはやめました。

検証された最新技術が本当に必要最低限の分だけまとまっていて、安心して気軽に入門できるのも1つの価値です。

当日実際手にとってみて、「この分量で1,000円かよ」って思われるなら別にそれでいいなぁと。

ソフトウェアをコードの行数で値付けする・しないと似たような話かもしれません。

あと僕は一度買ってくださった方には増補改訂版(電子)を無料で配布しています。

目の前にある紙に1,000円払ってくれと言ってるわけでもありません。

「紙を渡して1,000円を受け取る」しか見ないのは悲しいし、本質から遠いです。

Challenge

うやむやにしていること

期限あるものに間にあわせるにあたり妥協している部分があります。

たとえば、詳細は割愛する形でリンクだけのっけているようなものを全部完全理解しているわけではないし、公式のREADMEに書いてる仕様の実装全部追ってるわけでもありません。

今後ユースケース中心に見ていくにあたり、それが楽しくて疎かになりそうだが理解する時間を確保すべきだなぁと思う部分は個別に整理するなり、Knative本に唐突にコラムとして追加するなりしたいです。

  • Istio、Envoy、サービスメッシュ
  • IstioとKnative Serving(、Eventing)の関係
  • 実装としてのKnative
  • Kubernetesで特に弱いService周りの仕様、基礎事項
    • DNS、kube-dns
    • L4/L7
    • iptables
    • Ingress
    • kube-proxy
    • パブリッククラウドのLB
  • イベントドリブン、リアクティブなアーキテクチャ概論
  • 分散システムのアーキテクチャ

無限に学ぶことがあって楽しいですね。

実装面は5月の後半に少しGoにフォーカスした内容で30分くらいお話しすることが決まりつつあるのでいい流れです。

OGP画像

圧倒的失敗。せっかく作った本を視覚的に伝えるチャンスなのにもったいない。

OGP画像に最適なサイズと、これらを使えばキャッシュクリアできる知見を得たのでよかったです。

過去に投稿した分も更新されます。再投稿してもいいし、再投稿しなくてもいい。

https://cards-dev.twitter.com/validator
https://developers.facebook.com/tools/debug/og/object/

こういう感じに整理するのすごく見やすくていいなぁと思いました。何を頒布しているかわかりやすい。

コミュニケーションパス

何かあったら@toshi0607まで!みたいなのわざわざメンションしてコミュニケーションすることもないのかな。結構頻繁に「Knative」でTwitter検索してるのでだいたい拾えている気もする。

と考えていたところこんなツイートが!

ハッシュタグでゆるくつぶやいていただけたら拾いますくらいの方が楽に感じたり、何か言葉を投げかけてくれる人がいるかもって思いました。

ハッシュタグ作りやすいタイトルだと便利、しかしハッシュタグに最適化したタイトルつける必要もないみたいな姿勢でいけたらと思います。

みんなその辺どうしてるんやろうと思ってBOOTHのぞいたら完璧な方がいらっしゃって感動しました。

りあクト! TypeScriptで始めるつらくないReact開発 第2版

ハッシュタグ検索結果のURL貼っておくの正しいっぽいし、それに限らず親切な作りになっていて勉強になります。

会いに行けるアイドルならぬ、タイムライン上にいる著者をたくさん生み出した技術書典。

気軽に絡んで技術もふもふわいわい盛り上がりたいものです。

新刊の部数

数字の整理は後からしますが、Knative本の方は100部刷って完売が14時過ぎでした。

一方Lambda本は既刊の第2版で50部刷ったものの完売が終了直前。

Lambda本はちょうどいい具合だったと思うのですが、Knative本は150部刷ったらその分頒布できたのかわからないし、毎回テーマも異なるのでなんとも言えないですね。

ただ言えるのは、紙本が当日残ってもそれを必要としてくれる人に届ける手段はいろいろあるので、ちょっと余るだろうなぁくらい刷ってみるのも試してみようと思います。

金銭面では紙よりも電子で買っていただける方がよいかもしれませんが、自分は技術書はほぼ紙でしか読まないし、読もうと思ってくださった人が読みやすい形で手にしていただけるのが一番です。

査読

事前に募集したものの、その時メンションしてくださった方にすぐ返せず、いざというタイミングで探したらメンションはなくなっていました。

興味持ってくださる方は大切にしつつ、ゆるぼで集めるのは厳しく感じます。

紙本になる前に読んで欲しいケースもなったあとに本でほしいケースもどちらもあるので、目的を明確にしてお願いする形にすることにしました。

Knativeの動向

Cloud NextでCloud Run(Knativeを利用したプロダクト)が出たのは追い風になったと思うのですが、その追い風や発表直前のアップデートは頑張れば読めたかもしれなです。

発表前にBOOTHで販売を開始していたのはすごくよかったと思います。一方でこの点考慮できていれば紙本もうちょっと刷ろうと思っていた可能性が高いです。

今後

このとおりです。振り返りの「テーマ」と「うやむやにしていること」あたりをいい感じにやっていきたいと思っています。

  • Knativeのコンポーネントを組み合わせたユースケース
  • Knativeを使ったプロダクトを利用することで「開発者にとってより機能・サービスのユーザーに対する価値向上」に集中できるか
  • Knativeで作る俺たちのLambda
  • Knativeの実装
  • IstioとKnative Serving(、Eventing)の関係
  • 分散システムのアーキテクチャとKnative

めっちゃ楽しそう。楽しそう…!!!

数字の整理

売上

  • 本 + ダウンロードカード(PDF、ePub、MOBI): 1000円 × 100部(Knative) + 1000円 * 50部 = 150,000円
  • ダウンロードカード: 1000円 × 16枚 = 16,000円
  • BOOTH販売(PDF、ePub。MOBIは希望者に送付、Knative本を公開した4/8〜この記事を書いている4/20まで): 1000円 × 40部(Knative) + 1000円 × 11部(Lambda本) = 51,000円

-> 217,000円

きっとBOOTHはまだまだ伸びる…!BOOTHでのそう販売数は累計113部(Knative: 40部、Lambda: 73部)です。

かんたん後払いは 81/166(100 + 50 + 16)でした。半分くらい!

41/124で3割くらいだったので普及が進んでますね。あれだけ混んでても2、3件ちょっとアプリUI更新遅れたくらいで不自由をほぼ感じず、管理する側も便利でした!

原価

紙本印刷費(日光企画さん): 23,600円(Knative) + 21,890円(Lambda) = 45,490円
ダウンロードカード印刷費(プリスタさん): 1,700円(Knative)
技術書典参加費: 7,000円

-> 54,190円

Lambda分は前回とQRコード変えてないので残り分をそのまま利用、小物も追加なしです。

執筆関連の人の稼働という観点では、技術書典なくても検証するしまとめもするので皆無です。

表紙やダウンロードカード、サークルカットのデザインは妻がやってくれましたが、仕事として他の方に依頼するとけっこうかかる気がします。

大丈夫そう!

被チェック数

雑に貼ります。前回は最高127だったので前回よりは手にとっていただけそうな雰囲気はあるものの、当日ブースまでたどり着いて見つけていただくまでには混み具合なども影響すると思います。

あと複数頒布するとどちらにどの程度興味をもっていただけてそうなのかがわかりません。

来場者数も増えて母数増えたのかなとも思ったのですが、入場者数自体は前回と大差なさそうでした。

前回参加者10340人、今回10260人、運営や出展者込み。

  • 20190319 2227 16
  • 20190320 2353 18
  • 20190322 1530 24
  • 20190323 1850 25
  • 20190324 1925 26
  • 20190325 1904 29
  • 20190326 2227 31
  • 20190327 2121 34
  • 20190328 1819 34
  • 20190329 1100 35
  • 20190330 0931 36
  • 20190331 1038 38
  • 20190401 1224 39
  • 20190402 2245 42
  • 20190403 0853 42
  • 20190404 1022 47
  • 20190405 2054 48
  • 20190406 2139 50
  • 20190407 2211 56
  • 20190408 1842 57
  • 20190409 0826 66
  • 20190410 2128 82
  • 20190411 2358 96
  • 20190412 1357 104
  • 20190413 1931 138
  • 20190414 0836 185
  • 20190414 1400 207

技術書典5の数字はこちら

まとめ

技術書典好き!!!

このページでは『Knativeの歩き方 〜KubernetesからServerlessを訪ねて〜』の正誤表と増補・改訂をお知らせします。

この本を手にとってくださった方がちょっとでも選んでよかったと思う本に育てていきたいので、章の追加なども楽しみにしていてください。

引き続きフィードバックお待ちしてます!@toshi0607

更新情報や新刊情報もこのアカウントでつぶやきます。

正誤表

ダウンロードカード経由の方は

PDFページ PDF反映 ePub版反映 MOBI版反映 修正日 version
25、37 istio-system –output ‘jsonpath={.status.loadBalancer.ingress[0].ip’)} istio-system –output ‘jsonpath={.status.loadBalancer.ingress[0].ip}’) done done done 20190418 v1.0.1

増補・改訂

PDFページ 内容 PDF反映 ePub版反映 MOBI版反映 修正日

リソース

四半期ごとの人生振り返りです。

サマリ

  • プラットフォームのプラットフォームを実装しよう!
  • 猫かわいい
  • リリースした

習慣

2019年の目標

  • 本(執筆): 2冊/年
  • CFP: 4ヶ月に1回出してみる
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術書(読む): 30分/日
  • その他本(読む): 30分/日
  • ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月
  • ピアノ晒す: 1回/月
  • 筋トレ: 1回/週

進捗

本(執筆): 2冊/年

1/2

技術書典6に出す新刊がなんとか間に合いました!ということで年間進捗50%です。

技術書典6で『Knativeの歩き方 KubernetesからServerlessを訪ねて』と既刊第2版を出展します #技術書典

技術書典6は単体で学びや反省があるので、それは本番が終わってからまとめます。

お陰様で紙本は売り切れましたが、BOOTHで販売してます!

Knativeの歩き方 KubernetesからServerlessを訪ねて(PDF、ePubセット版) #技術書典

CFP: 4ヶ月に1回出してみる

初めてプロポーザルを出しました。講演内容の字数制限が200字とけっこう厳しめでした。「どんな人に向けた講演かこの講演によって受講者がどんな情報を得られるかを含めることをおすすめします」を書くことが推奨されていて、それを書くだけで埋まります。

こんな内容で提出しました。

[講演タイトル]
Knativeで実現するKubernetes上のサーバーレスアーキテクチャ

[講演内容]
Kubernetes(k8s)上でサーバーレスアーキテクチャを実現するKanativeが何を解決するのかをユースケースを交えて紹介します。
本講演は次のような方を対象にしています。
・Knativeがなんなのか、k8sとどのような関係にあるのか、どういう仕組みなのかを知りたい
・k8s上でもサーバーレスアーキテクチャを実現したい
・k8s上のアプリケーションの開発・運用負荷を下げ、機能開発により集中したい

会社でたくさん登壇をしている方のスライドでこの記事が紹介されていたので熟読し、ポエムになったり、過度に理解の前提をおいたりしないよう気をつけました。

肝心のKnativeをタイポしてて悲しくなった…。

登壇の可能性をあげる!カンファレンスプロポーザルの書き方のススメ

プロポーザル一覧

採否がわかったのは振り返りスコープ外の4月になってからですが、採択していただけたようなのでがんばります!

そしてプロポーザルを出すことに抵抗を感じなくなったので、自分のテーマに関連のあるものは出していこうと思いました。プロポーザルを出したカンファレンスでまだ登壇したことないにも関わらずw

わくわくしながら継続的に取り組みたいテーマがあるのはやりやすいです。

OSS: 1PR/月

what-happens-when-k8sは頑張った感があります。今年に入ってKubernetesキャッチアップするにあたってだいぶ勉強になりました。

Serverless FrameworkへのCloud FunctionsのGoテンプレート追加はServerless Meetupのきっかけにもなったのでよかったです。

設定ファイルばっかり追加してても自分には何も進歩ももたらさないので、もうちょっとサンプルなりKubernetes周辺のコードなりいじっていこうな!

ひとまとまりのソースコード公開: 1リポジトリ/月

2/3

Cloud Functions Goは技術書典終わるまで触るまいと思ってたのですが、Serverless Frameworkを見てみたらテンプレートがなかったのでほんのちょっとだけ触ることにしました。

pseは年末〜正月に書いていたCloud Pub/SubのエミュレータをいじるためのCLIツールです。社内の勉強会で発表したら需要皆無だったのでまぁお疲れさまみたいな気持ちです。

最近個人プロジェクトも何も書いてないですね。

Knative周りは概念理解フェーズが終わっていよいよユースケースをいろいろ検証するフェーズに入るので何か書こうと思います。

技術書(読む): 30分/日

読んだ

この本に出会ったおかげでKubernetesを深めていこうという気持ちが湧きました。今年のすべてはここから始まった。

読んでる

8章のFunctions and Event-Driven Processingだけとりあえず読みます。

今読んで意味がありそうなのと、読まずに実装と概念の間ばっかり追ってても設計力上がらなそうなので一歩引いてみたいです。

近々邦訳版が出ると思いますが、たしか何かのときにタダでPDF配ってたはず…?で手元にあったのを読んでます。

その他本(読む): 30分/日

読んだ

内容的にビジネスライティング的な域を出てない気がしました。が、社内ドキュメントを書くときに意識してみると構成を改善できたのでたまにこういうのも触れるといいなぁと思いました。

自分(というか人間)が思い込みで判断しがちな観点に自覚的になれそうです。

たぶん2、3日くらいで忘れるのでまとめページたまに見返すとよさそう。

学び方を学ぶのには定期的に投資したいです。

チューターのときによく話していた忘却曲線の話が乗っていたり、苦しくて避けてしまう「意識的に思い出す」出すなどいろいろと技術習得に取り入れるとよさそうなことが書いてありました。

特定言語の文法など、反復せざるを得ないことは必要期間忘れないかもですが、Kubernetesの仕様など体系が大きく、習得が困難なものや概念の理解に特に活かせそうです。

すごいいいこと書いてあった気がするけどだいたい忘れました。技術を離れて知らない「概念」に出会う機会が最近なかった気がするので新鮮でした。

結局身近なものとのアナロジーで理解しようとするので歪めてる気はしつつ、そういう自覚をもって向き合うことも大事そう。

書いてあったことだいたい忘れました。

ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月

今QベストはKubernetes完全ガイドでした。

感想とは。

ピアノ晒す: 1回/月

MIDI出力あるキーボード使っててその録音方法がわからん…!

スピーカーはない。こんな感じです誰か助けて!!!

YAMAHA ステージピアノ P-90
これ

筋トレ: 1回/週

完璧!

技術面

Knativeを追う中でプラットフォーム(を作るためのプラットフォーム)を作りたい気持ちが強くなりました。

それを抽象化するミドルウェアも楽しい。

けど現状作るには全然いたらずなぞってるだけなので、次の3ヶ月はユースケースを追う、作るなどやっていきます。

カスタムコントローラーに限らずKubernetesのAPI叩く何かを実装するのはいろいろと楽しそう。

なのでこれ読んだりもしたいです。

導入的なところだけ読んだらKubernetesを拡張する仕組みはCRDとカスタムコントローラー以外にもいくつかありそうで最高っぽかったです。

あとKubernetes追いながらそもそも弱すぎると思ったのがたくさんあったのでがんばれっていう感じです。

・データ構造
 ・計算量
・アルゴリズム
・ネットワーク
 ・L4/L7
 ・DNS、名前解決
・暗号化
 ・KMS
 ・ローテーション
・CPU/memory

登壇は目標でなくなったけど記録。

仕事面

リリースしました。

生活面

昨年末にペット可物件に引っ越し、とうとう1月末に猫を迎え入れました。

豆柴かその他猫か迷ってたのですが、ペットショップにどんな子がいるか見に行った帰りには子猫を連れて帰っていました。

数日間ケージや餌をもらってホームステイさせてもらえるところがあったので乗っかりました。

自分が猫・犬アレルギーだったのが最後の懸念点だったのですが、まぁ死にはしなさそうだったので、契約後正式に家族に。

種類は大きくなるノルウェージャンフォレストキャットで、論理的帰結として名前はハルくんです。

プラス、リリースできる未来があまり描けてなかった冬、僕らにも春が来るようにとの過度な希望を託しました。ごめん。

ちゃんと来たよ、春。

もうほんとかわいくて、かわいい以外の感想が出てこない程度にかわいいです。

最初こそ自分から寄って来ることはそんなになかった気がしますが、最近は帰宅して座っていると膝の上に乗ってきて迎えてくれます。

かわいさしかない。

引っ越しや新たな家族迎え入れを契機にいろいろ買いました。

最新はV11とか出てますが、吸引力十分で音もそこまでうるさくなくて満足です。

テレビでこれを使って撫でられてる猫の表情がやばかったので買ってみました。

とりあえずうちの子はこれを噛みます。

お出かけ時に入ってもらう用。普段から部屋の中に置いていて、狭いところが好きなのでたまに自分から入ります。

最初こそこれで爪をといでましたが、最近はソファーと半々くらいです。

ソファー意外と痛まないので好きにさせてます。

これで遊ぶと絵的にかわいいという下心で買いました。

最初こそ猫キックしてましたが最近はオブジェです。

これ本当によくて毎日遊んでます。まだ飽きてないし、140円とかコスパ良すぎる…。

そこまで耐久性はないかもなので、まとめて買っておくとよいかも。

何使っても爪切るのは嫌がるので、眠そうなときを狙うとなんとか切らせてもらってます。

よく切れます。

これで毛を抜いてます。ふわふわしてるので隔週くらいでお手入れです。

帰宅して膝に座って甘えてくるタイミングが狙い目です。

毛抜いたら整えます。

大きくなる猫種なので大きめのを選びました。

留守のときケージに入れときたくもないけどもうちょい受け入れ体制が必要。

水かえやすくてよいです。

大きめでよいです。

前傾姿勢で食べるので、ちょっとでも高さがある方がよいと思って選びました。まぁ何使ってもよく食べます。

技術書典も無事終わったのでものいろいろ捨てよう。あと食洗機買おう。

4/14(土)開催の技術書典6で2冊出展します!

カエルと空というサークル名で場所は「う46」です。ぜひ遊びに来てください!

興味を持っていただけた方はサークルのチェックリストに登録しておいていただけると助かります。今後の印刷数の参考にします。

『Knativeの歩き方 KubernetesからServerlessを訪ねて』

今回の新刊はKnativeについてです。KnativeはKubernetes上でサーバーレスなワークロードを実現するためのパーツ群です。

昨年9月に現職に転職してKubernetesを触り始めたことや、AWS LambdaをはじめとするFaaSやサーバーレスアーキテクチャに興味があり調べてみることにしました。

より詳細な動機はSeverless MeetupでKnativeの話をする機会をいただいた際にまとめています。

Serverless Meetup Tokyo #11 で「入門 Knative 〜KubernetesとServerlessとの出会い〜」を話してきました #serverlesstokyo

自分の大好きなLambdaを実装するための仕組みを学ぶのはとても面白く、今後も検証を続けていく予定です。増補・改定も伴うはず。

今回の本ではKnativeを構成するコンポーネントであるServing、Build、Eventingをサンプルを触りながら基本的な仕組みを理解できるように(自分が理解したい)という思いで書きました。

Knativeは鋭意開発中のため、入稿4日前にガラッと仕様が変わったのに気づいて慌てて一から勉強みたいなのも乗り越えてここまでやってきました。まさしく愛憎劇です。

Kubernetes上に成立つ仕組みなので、最低限Kubernetesの特徴として知っておきたいこともまとめています。

GKEを触りながらぜひKnativeの世界に入門してください!

本の名前はこんな気持ちでつけました。

ついでにこれは愛猫ふわふわくんの様子です。

目次です。

第1章 Knativeの概要
1.1 Knativeの構成要素
1.2 Serving
1.3 Build
1.4 Eventing

第2章 Kubernetes環境の準備

第3章 KubernetesとKnativeの関係
3.1 Kubernetesの基本的思想
3.2 Kubernetesのオートスケール
3.3 Kubernetesの拡張機能

第4章 Knative Serving
4.1 Knativeのインストール
4.1.1 Istioの設定
4.1.2 Knativeの設定
4.2 Configuration
4.3 Revison
4.4 Routes
4.5 Service
4.6 オートスケールの仕組み

第5章 Knative Build
5.1 Build
5.2 BuildTemplate
5.3 Servingと組み合わせる

第6章 Knative Eventing
6.1 Sources
6.2 BrokerとTrigger
6.3 ChannelとSubscription

お値段は前回に引き続きこんな感じです。

  • 最初の100冊は紙本 + ダウンロードカード: 1000円
  • あとはダウンロードカード: 1000円

実はすでにBOOTHで購入できる状態になっています。

https://toshi0607.booth.pm/items/1309468

当日会場に来れない方や今すぐに読みたい方、お待ちしてます!

『Goで学ぶAWS Lambda 第2版』

技術書典5で出展した既刊の第2版も50部持っていきます。

初版ではS3へのアップロードやログの確認でGUIに移動していましたが、諸々の準備によりコマンドで完結できるようになりましたw

更に、新刊に合わせて表紙も新しくなっています。嫁氏デザイン!

お値段は前回に引き続きこんな感じです。

  • 最初の50冊は紙本 + ダウンロードカード: 1000円
  • あとはダウンロードカード: 1000円

お陰様で商業版を出版したり、こちらもすでに第2版がBOOTHで購入できる状態になっています。

https://booth.pm/ja/items/1034858

GoとSAMで学ぶAWS Lambda

技術書典5で『Goで学ぶAWS Lambda』を出展します #技術書典

お願い

技術書を書くのは技術を身につけるためです。もし『Knativeの歩き方 KubernetesからServerlessを訪ねて』か『Goで学ぶAWS Lambda 第2版』を読んでフィードバックをくださるか宣伝(TwitterでBOOTHのリンク流してくださる程度で大丈夫です)していただける方がいらっしゃれば差し上げます。

ぜひお声がけください。

Serverless Meetup Tokyo #11お疲れ様でした!久々に登壇したのと、Serverless Meetupには勝手ながら思い入れがあるので振り返ります。

発表資料はこちらです。

登壇経緯

Serverless Frameworkのコアメンテナをやっている@horike37さんにお声がけいただいたのがきっかけでした。

Cloud FunctionsがGoをサポートしたのをきっかけに、サンプルを書いたり、それをテンプレートをServerless Frameworkに追加するPRを出したりしていました。

その辺を踏まえ、GCPのサーバーレス周りで話せることないか?と。(1月末)

ちょうど1月頭に(Kubernetesすら何もわからん状態だったけど)Knativeについて4月の技術書典6で書く予定だったのでKnativeの話させてください!!!と、申し出たらOKをいただきました。

テーマ選定

技術書典6含め、なぜKnativeについて調べようと思ったかにはいくつか理由があります。

みんな大好きLambda奴を自分で実装できるっぽい

AWS Lambdaが好きで技術書典5のテーマはまさしくGoで学ぶAWS Lambdaでした。

ユースケース的にまだまだ実装してないこともある一方で、サービスとしてどう実装されているかが気になったタイミングで登場したのがCustom AWS Lambda Runtimesでした。

これもしかして実装もわかるのでは?という期待を胸にすでにサポートされているGoで実装してみたものの、実態はランタイムのAPIクライアント奴でした。実装しなくても仕様ドキュメント見ればわかる。

そのとき書いた記事は鳴かず飛ばず感すごかったけど、今まで自分が書いた記事の中で一番好きです。

時は突然2018年の10月末のGCPUG Shonan vol.32 feat. Serverless & Knativeに遡ります。

ここでKnativeに出会いました。ようわからんけどk8sでサーバーレスできるんやーっていう印象はあったのと、k8s含め実装は公開されているので深めるにはもってこいというのとで調べてみることにしました。

Kubernetes詳しくならざるを得ない状況を作れる

Knative調べるぞ!みたいなモチベーションがあってもk8sの上に乗るものだし、トラフィックコントロール関連でIstioへの依存もあります。

仕事でGKE + gRPC + Goなマイクロサービス開発・運用していながらk8sちんぷんかんぷんでその上に(k8sはいったん忘れて)Knativeを調べるのは筋も効率もよくありません。

そういうわけでKnativeを進める前にk8sも調べる(基準曖昧)ことにしました。

登壇準備

Kubernetes

1月半ばから2月半ばまではk8s期間として本やソースコード読みました。

この本が最高で、仕事でk8s関連の知見をまとめる際にも秩序が生まれ始めました。(自分比)

Kubernetes完全ガイド

k8s source code reading #1に行ってみると上の本書いた人がいたり、k8sとKnativeの関係がわかったりしてよかったです。

それに関連し、k8sにしてもKnativeにしても、宣言的理想状態定義と、現在の状態と理想状態を調整するコントローラーの仕組みの理解は必須な中、よい記事を社の人に教えてもらえたのもよい出会いでした。

感極まって全訳PRを出しました。

Knative

2月前半に上のKuneretes本を読み終わり、Knativeのハンズオン、ドキュメント、記事などを漁りました。

よかったものは登壇資料の付録にまとめてます。

2月半ばにPivotalさんからKnative本が出たのは大きかったです。

3/2(土)、3(日)で資料準備を終えるはずが終わらず、3/5(火)に休みをとって仕上げました。

RAKU SPA 1010 神田のコワーキングスペースで資料終わらせて整えるかーと思い行ったまではよかったのですが、先に整えてしまい、しばらく薪を眺めるという失敗をおかしました。

先にやることやってから整えような!

突然のtips

準備の過程で海外カンファレンスのCFPにプロポーザルを出す気持ちを高めたり、CloudNative Days Tokyo 2019のCFPにプロポーザルを出したりしました。

CloudNative Days Tokyoは今選考中なので、もし興味ある方はいいねとリツイートで応援していただけると嬉しいです!

技術書典後の活動に大きく関わります。

登壇内容

特にKnativeの各コンポーネントについては口で補ったので資料だけではわかりづらい部分もあるとは思います。技術的な部分は技術書典6の本で書けたらいいなぁと思います。

Serverlessとは何か、KnativeのいうServerlessとは何か、みたいな話はせずKnativeが解決してくれることみたいな部分にフォーカスしたいという思いがあっての今回の構成です。

ただ、今回の構成でもKnativeが解決すると書いてることを厳密に区別すると、

  • KubernetesでもできなくはないけどKnativeでより便利になること
  • Kubernetes + CI/CDで実現できるけどKnativeでもっとKubernetes nativeに実現できること
  • Knativeで初めて実現できること
  • Knativeが拡張するIstioの機能

とかごっちゃになってる気がするんですが、そこには目をつむりました。

これから検証したり、実装を追ったりする人にとって大枠が掴めるものになればいいなぁと。

Kubernetesとの関係性にも入り込まず付録でCRD、Operatorにちょっと触れる程度にしましたが、技術書典6の方ではその辺ももう少しだけ書こうと思っています。

Severless Meetupへの思い

いつかSeverless Meetupで登壇したいなぁという思いがありました。

ServerlessConf Tokyo 2017に参加して心踊らせたり、前職でLambdaを本番導入したりしていた中での1つの目標です。

それ以来本や記事書いたり、ServerlessConf Tokyo 2018にも参加したり、Serverlessconf Tokyo 2018 Contributor DayでServerless Frameworkに初めてコントリビューションしたりの流れの中で実現できたことなので感慨深いものがあります。

ServerlessDaysも何か話したりハンズオン担当したり(?)、海外でも登壇できたらなぁと思っています。

どちらかというと登壇そのものというよりは、人に話したくなったり、話してフィードバックもらいたくなるような好きな技術に常に触れていられたら幸せという気持ちの方が強いです。

そういうハンズオンやContributor Dayも含め、好きになる可能性のある技術に触れたり、どっかの誰かがなんか言ってる技術が自分の身近な課題を解決できるものと感じられるようになる場を作るというのにも興味を持ち始めました。

自分の技術力や思いありきな前提で、これはこれで知見がいりそうですね。

振り返り

Good

社内公開とフィードバック獲得

社内のしかるべきと思われるチャンネルに貼ったらフィードバックや、どういう観点で検証したら社にとってもプラスになりそうかという示唆が得られてよかったです。

Eventとプロバイダー間の一貫性あたりはこの辺参考に考えるとよいとのことでした。

Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services
(8. Functions and Event-Driven Processing)

1アウトプットにかける時間と粒度大きいのが増える一方で、小さめのもの(Qiitaで記事書くとかサンプルコード書くとか)が減ってる + 両立できないものでもないと思うので動き見せられたらなぁと思います。

完成する前に声に出して読む

最初Eventingを書いたところで16分くらいだろう(持ち時間は20分)と思って読んだら12分くらいだったので、完成に向けて進めるのに加えて時間収まらなさそうだから書かんでいいやって思ったのを足したらちょうどいいくらいになりました。

当日は付録の後半飛ばして20分30秒(付録飛ばせたけどイベント全体けっこう巻いてたので後半だけ飛ばした)。

Spaeker Deckに上げる(PDFにする)前提で変な作り方してるところがある分枚数多く見える(が実際1枚ページ送るだけ)部分があるのでそこはいい感じにつじつまが合うようにしたいものです。

Spaeker Deckで見たらURLクリックで飛べない(?)し、作るのはGoogleスライドだしで、もはやSpaeker Deckに上げずにGoogleスライドのURL公開すればいいのではって思いながらいくつもの季節が過ぎました。

(スライド全体が完成してから練習するのは大前提として)

Challgende

スライドのURL汚い

Speaker DeckのURL生成ルール的に原則タイトルベースで、それっぽく変えたいときはスラッシュの後ろに書く、みたいなの知ってる人増えてるはず。

こんな感じ。
入門 Knative 〜KubernetesとServerlessとの出会い〜 / getting started with knative

が、失敗してこうなりました。

h ttps://speakerdeck.com/toshi0607/getting-started-with-knative-90ff6190-1251-4b7b-ada9-bbba5a8ca4b8

一度
https://speakerdeck.com/toshi0607/getting-started-with-knative
で生成されたものの、PDFをアップロードした後にスライド処理が進まず、いったん削除して上げ直したら区別奴がついてしまいました。

結局時間がかかっても処理されるので放置するか、潔く別のURLになるように変えたりの方が意図通りのURLで公開できそうでした。

少なくとも発表ちょっと前にバタバタしながらアップロードするのやめよう。

検証少ない

去年の登壇では手を動かして作ったものについて発表をすることにこだわっていたものの、今回の発表に向けて手を動かしたのはハンズオンくらいでした。

発表までに残されていた時間と発表内容的に対して最適な手段だったとは思うものの、検証時間比率は増やします。

本出すにあたってはコードよりも原稿書かないとですが…両立できないものでもない。

まとめ

色々な思いが詰まったイベントを迎え、無事過ごすことができてよかったです。

技術書典6に向け原稿進めます。

明けましておめでとうございます。

2018年はGoに出会って気づいたら転職し、新婚旅行し、ロールが変って闘争が激化し、引っ越し、初の単著商業誌が発売された年でした。

新婚旅行記事毎日書いたのにいまだにブログのっけてない…

振り返りは3ヶ月単位でやってるのですが、年単位のやつも10〜12月分の振り返りに組み込みます。

それに加えて2019年の目標と立てます。

2018年10〜12月と2018年の振り返り

2018年の目標(再掲)

年初に立てる目標は定量的に白黒はっきりするアクションにしました。

特定の技術領域に詳しくなる、的なテーマはその時その時で変わるのでアクションの方向付けくらいに考えています。

  • 本(執筆): 2冊/年
  • 登壇: 6回/年
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術記事: 2記事/月
  • 技術書: 30分/日
  • その他本: 30分/日
  • カラオケ: 2回/月
  • 歌練習: 1回/週
  • 品川健康センター: 2回/月
  • 走る: 1回/週

これまでの振り返り

進捗

本(執筆): 2冊/年

2/2

一応達成しました。2冊目は1から書いたものではないもののよいことにします。

『GoとSAMで学ぶAWS Lambda』がインプレスR&Dさんから発売されます!

GoとSAMで学ぶAWS Lambda (技術書典シリーズ(NextPublishing))

1冊目は技術書典5版の『Goで学ぶAWS Lambda(PDF、ePubセット版) #技術書典』です。

(そういう意味ではExtensive Xamarin ─ひろがるXamarinの世界─が出たもの今年ですね!こっちは本当に自分は何も加筆修正してません)

もう1冊自分の担当章 + 追加で依頼された分書いてたのですが、結局全体として校正プロセスに進みませんでした。

自分がいまいまやってる分野に近ければ調べて書くなり、完了状態に持っていくためのアクションをとったかもしれません。

けど自分の担当した章ですら再現する環境がもう無い程度に離れてしまったのでそういう気もおきませんでした。

2〜3月の土日をだいたい返上して書いただけに残念ですが、

  • 今の興味関心と合致するか?
  • 本書くことが目的になってないか?
  • 共著であれば全員やりきってくれそうか?

みたいな自分が本を書くべきかどうかを判断すべき基準ができた1年でした。

共著と単著と商業誌とフィードバック

共著は何かしら共通するテーマで本を書くだけに、共著メンバーのレビューも期待できる(かもしれない)し、分量が求められる局面でも一人で頑張るよりは応えやすいです。一方、「技術書典に出す」などのどうあがいても覆らない期限がないと完成しないこともあります。

単著でかつ非商業誌の場合は完成しなければ単にそこで終わりだったり、適当なサイズで技術記事にしてしまえば書いた分が無駄になることもなく、共著よりスケジュール面でコントロールできる裁量は大きいです。

ボリュームについては、自分が読者として本を読むときは知りたいこと、知ってよかったことが書いてあるかどうかの方が本全体のボリュームより大事だと感じます。なので自分が本を書いて世に送り出すにあたっては量は気にせず、何が書いてあったら嬉しいか、(分量を稼ぐための)冗長な表現があるとしたらかえって理解を阻害していないか、などに集中すればよいと思います。

商業誌としてAmazonに出ると「分量の割に値段が」というレビューがついてしまうのが頭を過ぎります。この「分量」が単に本全体の分量なら知らんがなページ数書いてるやろっていう感じですが、有益に感じられる部分が少ないのだとしたらレビューを書いた人にとってその本に知りたい内容が含まれるかどうかを判断できる情報を出す努力もすると平和そうです。過剰なキャッチで出さない、いい感じに各章にサマリをつけるなど工夫の余地があります。

そういうレビューすらつかなければ世間でどう見られているのかわからんですね。

本が技術書典を飛び出し、商業誌として出版されること自体の価値はわからないです。ある程度の分量の文章を期限内に書けるということは技術書典で本が出せたら対外的に示せます。

もし商業誌がたくさん売れたら幅広い人にウケる内容の本をウケる書き方で仕上げることができる、というのが結果的に示せるのかもしれません。

色々と思索に耽ることはできると思います。しかし、僕が本を書く根底にあるのは、ある程度人への説明になる言葉で一定量以上まとめることでその技術の知見を深めることです。

なので読んで欲しいと思う人々に書いてる事実を知ってもらいつつ、確実にフィードバックがもらえる行き渡らせ方をできるようにしたいなぁと思いました。こういう感じで告知したり、勉強会でタダで配ったりしても期待する成果は得られませんでした。

フィードバックが欲しいなら高めたい技術と仕事で扱う技術を完全に一致させてレビューを受けざるを得ない状態にしたりするそもそも論があります。それでもやっぱり本という形に仕上げるのはとても楽しいので、これからもよいやり方を探りながら続けようと思います。

今年も2冊は出したいです。技術書典が年2回続く限り達成できるけど、毎回コンスタントに自分が向き合うべき技術に関して本書くのってただそれだけで難易度高いと思います。

今のところこの辺りで考えています。自分が向き合うものが変わったり新しく出てきたらそっちを優先します。

  • Knativeのアーキテクチャ
  • Knativeで提供するFaaS
  • Goで学ぶ Cloud Functions(GA期待)

登壇: 6回/年

5/6(年)

1回足りませんでした。

2018年10〜12月には1回。登壇かと言われると違うけど[秋葉原] Vue.js入門 輪読会 10章 中規模・大規模向けアプリケーション開発 (実装)で資料まとめて発表するマンをやりました。

資料
Vue.js 入門の第10章「中規模・大規模向けのアプリケーション開発③実装」

サーバーレスの文脈でフロントを書くにあたりVue.js使いたくて、各章週1で進んでいく勉強会の敢えて最終回に立候補しました。

勉強会では早く終わりすぎかつそういう場合を想定したネタの仕込みもなく至らなかった感が大きいです。

大体実装の説明が書いてある章でどうやったら輪読会として意味が出るのか考える過程でこういう枠で整理したらよさそうみたいなのが見つかったので今度こういう機会があればまたやってみます。

  • 概要: 本の内容をまとめたもの
  • 仕様: 本で使われている技術の仕様を確認するもの
  • 議論: 本で論点が提示されていて意見を聞いてみたいもの
  • 質問: 読んでてよくわからなかったので助けてください
  • 感想: 感じたこと

同じ目的の整理用フレームワークとかありそう。

本を書くのと同根で、自分が知見を深めたいテーマの勉強会やカンファレンスに申し込むのはこれからもありだと思います。

発表すること自体を目的にせず、何かしらコードを書いたり、調べてみて世に問うてフィードバックをもらえる状態にすることが前提です。

キャパや工夫が足りず実現できなかったのものの、2018年ならserverless Conf TokyoでLTなりセッションするなりできればよかったです。

ウケ狙わず純粋に自分の興味関心分野でCFPを出して通ればよりフィードバックに期待できそうですね。

CFP出すのにリスクはたぶん無いので出してみようと思います。

目標として「6回何かしら登壇する」よりも「テーマ決めて覚悟決めてCFP出す」って挑戦しがいがありそうですよいと思いました。

出す、というのもコントローラブルです。

OSS: 1PR/月

7/3(10〜12月)

2018年10〜12月としては

です。Goを初めたきっかけの1つはサーバーレスなOSSがGoで書かれることが増え、PR出すワンチャンあると思ったからです。

Serverless Frameworkはjsですが、Goのテンプレート生成する部分なのでGo書く必要があり、目標の1つが果たせてよかったなぁという感じです。

1年まとめると

10〜12月: 7
7〜9月: 5
4〜6月: 3
1〜3月: 5

ということで20のPRを出しました。これもPR出すことを目的とせず、自分が深めたい分野のOSSを読んだり使ったりしていると直せる部分は必ず出てくるので、それを放置せずみんなが使いやすいようにしようという感じで続けられたらよいなぁと思います。

今年も去年と同じく四半期3PR目安くらいでがんばります。

ひとまとまりのソースコード公開: 1リポジトリ/月

2/3(10〜12月)

できませんでした。

10〜12月は

の2つです。

custom-runtime-go-sampleはLambdaの新機能Lambda Custom RuntimesをGoで実装したものです。ライブラリ書いたの初めてです。

公式でもGoはサポートされてるだけあってわざわざ実装してる例はパッと見GitHub上にはなかったのでこういう「自分の理解を測るための無駄」はどんどんやっていきたいです。

pseは久々のCLIツールです。Cloud Pub/Subのエミュレータをいじる公式のツールがなく、公式ドキュメント上ではPythonのスクリプトをダウンロードさせて実行させてたので作りました。

数的には届かなかったけど僕はそれぞれ好きなので満足です。

1年全体としてはhomebrew用のリポジトリは除いてちょうど12リポジトリでした。

去年はGopher道場に参加してからCLIツールを作ったり、技術書典に本を書く前提としてまとまった分量のコードを書いたのが大きいし、そうしてとてもよかったと感じました。

「影響を受けて俺も似たようなコードを書いてみた。こういう仕様にしたらもっとよいのでは?みたいなイシューも立ててもらって公開しておいてよかったみが強かったです。

逃げかもですが、UIをHTMLとCSSとJSで書かなくてもツールをシュッと公開・配布ができることで世界が広がりました。

別にJSでもPythonでもなんでもCLIツールくらい書いて出せばよいと思うものの、自分が書いてて楽しいと思う言語自体と周辺環境がいい感じに実現しやすい状態になっていると思うので、なんというかありがとうという気持ちです。

ボットも同じ文脈でUI書かなくても公開できるのには変わりないですね。

ツールを公開する上ではビルド環境がある人向けにはコード書いてGitHubにでも置いておけばいいですが、各OS向けにビルドしたり、HomebrewやScoopに継続的に対応する過程でCIの知見も増えました。

いい流れだと思うので、同じ目標で継続します。

本や登壇と絡めつつ、WebなUIを伴うものも書けるといいですね。

技術記事: 2記事/月

4/6

年間は17でしょうか?あんまり書いた記憶もないですね。

4〜6月に職場で書いたQiita::Team計算に入れてた雰囲気があるので、現職のWikiを加えるともう少し増えそうです。

本、登壇、リポジトリで大体目的は果たせてそうなので技術記事の数値目標は置かなくてよいと思いました。

GitHubのREADMEとか、多くの人に知ってほしいツールは英語記事書くとかそういうのがんばろう。

削れるものは削ってシンプルにしたいですね。

振り返りが手間的に辛くなったら元も子もないです。

本: 30分/日

技術書とそれ以外30分ずつということでおいてますが、11月くらいから毎日技術書は読めてないかもです。

読めなくなるまではコンテナ系の本を読んでたのですが最近は気持ち的に焦り日々の仕事の状況整理に充てていました。

長期的にみてよくないので戻そう。

読んだ

去年一番影響を受けた本です。

テックリードとしての闘争

でも触れています。

やっぱちっさくてもいいから自分が作りたいものを作ってみないとわからんと思いました。

もっと色々検査した方がよさそうと思いました。口周りの病気、思ったより全身に影響ありそうなので四半期に1回は検査受けるとよさそう。

ある言論の妥当性を判断するとき、昔からそうやってきたからそうあるべきとか、普通はそうだからそうとか、自分の考えに沿わせたいからそうしないのは嫌とかになっていないか?(主観が含まれていてもいいがそれも含めて)妥当でなく、手間が増えるだけとかならはっきりNOと言おうと思いました。

あんまり覚えてないですがここまで徹底できるのすげぇと思ったし、仕事最高!!!みたいな価値観で石原さとみさんを勝ち得ているので完全に勝っていると思いました。

「断捨離」とイメージするものよりもちょっとスコープの広いもので、いろいろやめてみてもいいかもなぁと思いました。

自分が人に対して嫌だなぁと思うことって自分を写す鏡(自分にも少なからずそういう部分があって、自分は抑圧している)なのでまず自分と向き合え(?)みたいなのなるほど身がありました。

好きなことにとことん熱中しような!

『えんとつ町のプペル』の宣伝かな?って思ってたんですが、読んでみたらまさにタイトル通り「現代のお金と広告」の話でめちゃくちゃ面白かったです。

本音で生きような!

読んでる

まず本のスタイルとして、哲学通史的な説明だとつまらんから人生に洞察のある切り口ごとに紹介していくというものになっていて面白いです。

また、机上的な話が多いと思いきや心理学の実験 + 直接しがちな状況への適用など、自分が生きる上で目の前の現象の捉え方に影響があるような書かれ方がされているので、エンジニアリングにもマネジメントにも活きている実感があります。

はよ読まな…

歌系

とうとうやめました。歌に限らず、飲み会など大きめの声を出さないと会話できない状況で話し始めの一音目が出ない(空気が漏れる感じで音にならない?)状態です。

ほぼ聞き直されるので余計焦って一層声出ないみたいな感じで結構つらいです。

「どもる」といってイメージされる症状とは違うんですが、これに名前ってついてるんですかね?

日常生活で普通に不便なので治せるものなら治したいです。が、症状だけでググってもなんと呼んでよいものかわからずです。

一方、前職退職時にこのキーボードをいただき、ちょろちょろ弾くようになりました。

動画と音別で録ってYouTubeに上げたいのですが録音したやつ取り出す方法がようわからんです。

もともと幼稚園のときに買ってもらった61鍵のめちゃくちゃタッチの軽い電子ピアノしか持ってなかったので、家に88鍵のいいタッチのピアノがあることは憧れの1つでした。

今年は5曲くらい上げれたらと思ってます。

運動系

  • 品川健康センター: 2回/月
  • 走る: 1回/週

去年1月から品川健康センターに通い始め、毎週土曜日か日曜日、5月の1回を除き通い続けることができました。

いい感じに習慣にできたのではと思います。

年末に引っ越したので品川健康センターは多少遠くなりましたが、目黒区民センター体育館が近くなりました。

週末に行ってみようと思います。

総合

1年をざっと振り返ると、技術面はGoとの出会いを起点に色々と手を動かしながら学べた年だったんではないかなぁと思います。

仕事に寄り添いつつも仕事の外で立てた習慣目標も達成できた(習慣かできた)ことが多く、今年も続けたいことがたくさんありました。

ただ、この実感は直近の仕事に対する感覚とけっこう乖離してしまっていて課題に正面から向き合わねばと思っています。

目標としては自分がコントロールできて、習慣化できるものを設定する(この方針よかった)ので、課題に向き合うための足腰を鍛えるようなものになりそうではありますね。

あとこれもはや懐かしいです。

好評の Windows 版に続いて急遽リリースを決めた Mac 版アプリの開発に、Xamarin.Mac を採用して大幅な開発効率のアップと機能の標準化を実現。

今となっては関連技術からだいぶ離れてしまいましたが、Microsoft MVP関連でシアトル行けたのもよかったです。一応まだMVPです。

行こう行こうと思って行けていなかった新婚旅行、憧れの長期ヨーロッパ旅行も行けました。よかったよかった。

運動は最高でした。

音楽はつらかったけど聴くと落ち着くピアノで好きな音楽弾けるのはそれはそれでよいでしょう。

ちょっと広めの家に引っ越しも無事終わってよかったです。

引っ越し準備でものを減らしたいだったり、メルカリ使ってみたいだったりでたくさん本や使わない家具・家電を出品したのもよかったけど無駄なものは多いと感じるのでどんどん捨てたいですね。

習慣目標に上げたものは振り返りやすいしそれに対する思いもすごい出てくるけど、そうでないものはものすごいふわっとするというかあんまり覚えてないな…

と思ったら習慣以外にもどんな感じにしたいか書いてました

複業はMS関連のセミナー講師やったりや本書いたり下のとは別に開発チームに入ってやろうとしてましたが、話を聞いてから実際に手を動かせるタスクまで時間が空きすぎて状況が変わったり、いつもそんな暇なわけではないっす…みたいな気分になったりで結局やりませんでした。

身に付けたいけどできないことに飛び込むだけの余裕って今は完全にスケジュールコントロールできないと厳しいのと、それなら本業打ち込むとよさそうな気はします。

給与が大きく変わったのも大きい気はします。

Go、GCP、サーバーレス、コンテナあたりで人的ストレスなければ受けてみたいという謎のスタンスでお待ちはしてます。

2019年目標

仕事面

リリースするぞ以外考える余裕はないです。

テックリード観を持ち、今何が課題で、課題を解決するために自分に何が足りないのかがわかり、足りないことに対してアクションが取れる状態にはしたいです。

今は何に集中すべきというのがいまいちわからず、ただただつらいです。

まずはここから!

  • テックリードとは的な記事読んでなるほどせやなって思うことがあるのでまとめてみる
  • テックリードとかテックリードだった人とかに話聞いてみる

その結果、ロールとしてあるべき姿、自分がこうあるべきと思った姿と自分が目指したいことがずれていたらちょっと考える。

習慣

  • 本(執筆): 2冊/年
  • CFP: 4ヶ月に1回出してみる
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術書(読む): 30分/日
  • その他本(読む): 30分/日
  • ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月
  • ピアノ晒す: 1回/月
  • 筋トレ: 1回/週

家庭

今年も捨てるぞ!

そして犬か猫を迎え入れます。

食洗機、ダイニングテーブルも迎え入れたいです。

まとめると大体技術的に頑張りたいことが多くて、技術はまだまだ追うことあるので項目として大きく増やしたり減らしたりすることもないなぁという感じです。

家をすっきりさせて、適当に旅行とか温泉とか行って、サウナ毎週行って、たまにピアノ弾いて、基本コード書いたりいい感じに頭使えたらええんではと思います。