by ·0件のコメント

ServerlessDays Tokyo 2019に関わられたすべてのみなさんお疲れさまでした！

僕は主に10/21（月）のWorkshop03「Knativeで作るDIY FaaS」のコンテンツ作成と当日の解説・進行に携わりました。22（火・祝）のカンファレンスではスタッフとしてうろうろしたり、Knative本を頒布したりしていました。

大規模なワークショップを作ったり運営したりするのは初めてだったので振り返ってつぎにつなげようと思います。

概要

  • 概要説明のスライド
  • ワークショップコンテンツの本体
  • カンファレンスでKnative Servingのお話をされていた@toversus26さんにいろいろ教えてもらってKnativeのDesign Docs見れるようになったのでもっと正確に、深く、理解したい

ServerlessDaysでワークショップを担当することに対する思い

これを実現したかったからです。

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

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

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

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

去年、一昨年とワークショップに参加して、僕はカンファレンスで話を聞いているよりも手を動かす場の方が好きでした。そこで今度は自分がそういう場を提供できるようになりたいという思いがありました。

改善点はあるとは思うものの、まずは思いを持ってServerlessDaysのワークショップを担当できて幸せでした。

テーマ

GCP

今年取り組んでいたKnativeを使ったワークショップを準備しました。題材はOSSなので実行環境はどこでもよかったのですが、つぎの理由からGKEを中心にGCPのサービスを使っています。

  • AWSとMicrosoftは毎年ワークショップあるのにGoogleはないので自分がやろう
  • 会社でGCPたくさん使っているものの、普段はGKEのクラスタ構築したりgcloudコマンド叩いたりすることが少ないので馴染みたい
  • 環境やマシンスペック揃える観点でローカルは避けたい、そしてGCPのCloud Shellが必要十分なことは技術書典で本を書く中で検証済みだった

DIY FaaS

KnativeでFaaSを作るというテーマにしたのはつぎの理由からです。

  • コンポーネントの各機能を動かしているだけではなんとなくいろいろな機能があって複雑なものという印象で終わってしまう（特に普段FaaSを触っている人から見ると）
  • リソースの抽象化は一面でしかないので抽象化好き、嫌いの好みの問題で終わってしまう（特に普段プラットフォームの運用・開発をしている人から見ると）

こういう背景があり、プラットフォームを作り運用する人の観点とプラットフォームを利用する開発者という立場を明確に分け、両方の立場からKnativeやKnativeがベースとなっているプロダクトに触れられるようにというコンセプトを強めに押し出しました。

  • Knative、Tektonの各コンポーネントを理解するステップ
  • KnativeベースのOSSを自分たちのプラットフォームにインストールして使うステップ
  • OSSを組み合わせてプラットフォームを構築するステップ
  • Knativeベースのマネージドサービスを使うステップ

という構成がそのコンセプトを具体化したものです。

対象参加者

Serverlessコミュニティ向けに行うということを考えたときに、Kubernetesをどこまで前提知識にするかは少し迷いました。必要最低限のリソースやコンセプト的な部分は軽くスライドで触れることにしました。

そして募集の段階で対象はつぎのように明示しました。それ以外の人の参加を拒否する目的ではない旨を話した上で参加者に挙手してもらうと、実際は右に書く人数が該当していました。

  • 普段Kubernetes上でアプリケーションを開発している方: 数名
  • プラットフォームを開発している方: 数名
  • AWS Lambda、Azure Functions、Cloud FunctionsなどFaaSが好きな方: 参加者40人くらいほとんど
  • Goでアプリケーションを開発している方: 数名

想定とずれてはおらず、自分のできる範囲で用意すべき材料は用意したという感じでした。こういうときはやはりフィードバックがほしいですし、自分で質問項目を準備して具体的なフィードバックを求めるべきですね…。

進行

つぎのような感じに進めました。

  • コンテンツに入る前にスライドで概要を説明
  • 基本的に僕が前で解説・実行しながら進める
  • 自分のペースで進めたい人はどんどん先に行って大丈夫

ゆっくり目に進めたつもりが進行が早かったとの声もあり、どう進めるのがよいのか考えていました。社内で毎週Go（とGCP）の知見を共有したり議論したりするGo Fridayという勉強会があり、このワークショップを紹介するとともに、golang.tokyo、Women Who Go Tokyo、GCPUGなどでどのようにワークショップを運営されてるのかを聞いてみました。

僕の進め方に足りてないと思ったのはこういうのです。

  • 前でやってから参加者の方々がコマンド動かす時間を確保する
  • step毎の完成イメージや動くものを先に見てもらう

前でやるなら見てもらうフェーズと操作してもらうフェーズを分けないと前見たりPC見たり大変で進められない！というのに自分で気づけなかったのは謎です。

あとはコードを書くタイプならTODOが書いてある枠組みを配ったり（tenntenn/gohandson）、他にもコードラボ形式のもあると教えてもらいました。

今回僕がやったCloud Shell上で進めていくものであればチュートリアル形式もあったりするので活用するのがよさそうです。

少なくともGitHubとCloud Shellを行ったり来たりしてYAMLの中身を保存してもらうよりはCloud Shellでgit cloneしてもらう方がよさそう。そうするとkubectl applyをひたすら打つだけになる気もする一方で、YAMLの中身をコピーして保存するときも必ずしも中身が読まれるとは限らないですね。

今度は11月頃に社内でやる予定なのでやっていき！！

振り返り

Good

  • 本番が始まるまでになんどもコンテンツを見直せた
  • 実際に自分でやってみながら致命的なミスを修正できた
  • ロールの分類とstepの位置付け明確化
  • ワークショップがまとまりあるアウトプットとして残るのはなんとなくうれしい
  • スライドを作るのが速くなった気がしたけど単に使い回し比率高いだけの気もする

Challenge

  • 進行方法改善
  • Eventing薄めなのでもう少しやりたい、cloudevents/sdk-goに馴染みたい
  • ワークショップでDIYしたFaaSはこの辺に書いてるとおり課題があるので、現実的な課題解決に耐えうるものを作りたい

今後

カンファレンスでKnativeの話をされた方にいろいろ教えていただきかなり学びがありました。

実際にSREとしてインフラや開発者の声に向き合いながらKnativeの本番環境での活用に向け検証を進められているようで、掘り下げも素晴らしかったです。定期的に話を聞きに行きたい。

教えてもらった中でもこのページのknative-users@とknative-dev@でGoogleグループをたどれて、「参加する（devは人が承認）」とTeam Drive内のDesign DocやMTGの議事録などいろいろ見れるようになるのは超重要情報でした。公式のドキュメントも古くなってる部分もあるとのことで、実装とこの辺りの情報を見ながら理解をアップデートしていく所存です。

今後はKnativeももちろん追いつつ、以下の記事でも書いてるようにプラットフォームエンジニアへの闘争を推進すべくKubernetes自体の理解に軸足を置けるとよいかなぁと思っています。

2019年7〜9月ふりかえり　〜プラットフォームエンジニアへの闘争〜

by ·1件のコメント

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

2019年の目標とは別に個人OKRの運用を開始したため、そちらを中心に振り返ります。

サマリ

プラットフォームエンジニアへの闘争を開始します

OKRの振り返り

基本的にやるべきことに集中するために大事なことを列挙する形で設定したのでつぎの3段階くらいでいいかなと思います。

  • できた
  • 微妙
  • できなかった

Objective 1

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

Key Result 1 【できた】

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

  • CloudNative Days Tokyo 2019 登壇
  • ServerlessDays Melbourne 登壇

CloudNative Days Tokyo 2019で『Knativeで実現するKubernetes上のサーバーレスアーキテクチャ』を話してきました #CNDT2019

ServerlessDays Melbourne 2019でBuild serverless application on top of Kubernetesを話してきました #sdmel19

CloudNative Days TokyoではKnativeが「どういう課題に対し、なんの機能がある」という形を意識してユースケースを組み立てました。

それに対してもうちょっとKnativeの大枠の意義や、どういうロール人の何を解決するのか、個々のコンポーネントの使い方でなくて構築したプラットフォームをどう使うのかという部分が知れるとよくなるのではないかというフィードバックをいただきました。

ServerlessDays MelbourneではKubernetesで運用するアプリケーションのツラミからそのソリューションの1つとしてのKnativeのような形に構成を変更して臨みました。

他のソリューションとの比較や構築したプラットフォームの活用までは至っていませんが、それは10〜12月のOKRに深く関係します。

対外的な発表だけでも検証した内容の抽象化や再構築にはとても役立ちますが、フィードバックをいただきブラッシュアップするプロセスはとても大事だと改めて感じました。

また、発表する前にレビューしてもらう段取りができなくて落ち込むこともありました。しかし、長期的なテーマを設定していろいろと取り組む前提で、イベントが終わってからじっくり感想をいただく形式も必ず進捗が生まれるので気が楽になりました。

Key Result 2 【できた】

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

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

技術書典7で『Knativeソースコードリーディング』『Knativeの歩き方 第2版』『Goで学ぶAWS Lambda』を出展します #技術書典

CloudNative Days Tokyoではユースケースの後半にKnative Lambda RuntimeとOpenFaaSのWatchdogを活用したプラットフォーム構築のお話をしました。

その過程で整理したこの1枚のスライドは、Knativeを使って自分でFaaSを組み立てるときに何を開発する必要があるのかという観点でとても大事なことのようです。この知見を元に10〜12月実際に触れるサーバーレスプラットフォームを構築します。

その調査内容を文字化して『Knativeの歩き方』に章を増やす形で足しました。

Cloud Runの話はServerlessDays Melbourneで少し触れました。会社ではGCPを中心にサービスを構築しており、検証環境も充実しているので自然なユースケースで活用できる可能性も高いかなと思います。その観点で仕様の詳細を理解しておくと意味がありそうです。

Key Result 3 【できた】

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

  • 技術書典7執筆 新刊KubernetesのコントローラーをKnativeで理解する
  • 技術雑誌寄稿 kube-apiserverのクライアント
  • Programming Kubernetes: Developing Cloud Native Applications 再読

技術書典7の『Knativeソースコードリーディング入門』の振り返り #技術書典

6月にかなりお世話になったProgramming Kubernetes: Developing Cloud-native Applicationsを再読し、Knativeの実装を追う本を書きました。

Kubernetesのクライアントライブラリを含むコントローラーの追い方は慣れてきたものの、Knativeの固有実装部分までは終えてないなぁと思います。

メトリクスベースでスケールさせる仕組みや証明書管理、イベント関連の抽象化設計などはKnativeに閉じずプラットフォームの設計・実装にとって重要な要素だと思うので引き続き追っていこうと思います。

寄稿については技術書典が終わってからツール作成に着手し、初稿もなんとか10月頭に間に合いました。社内や編集者の方からたくさんのコメントをいただいたので今後の執筆にも大いに役立ちそうです。別途振り返る予定です。11月半ばに発売されるはずなので楽しみにしていてください！

コントローラーではないもののKubernetesのクライアントを書いたり、関連書籍を読むと自分で書きたい気持ちは高まりました。

Objective 2

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

Key Result 1 【できた】

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

観た！

Key Result 2 【できた】

  • 花火大会に行く

行った！

行ってみたいところ、やってみたいことは突発的に発生するところだけではなく、計画しないと実現できないこともあります。

カッパドキア行きたいとかクリスマス島のカニ見たいとかディズニーのミラコスタ泊まりたいとか。

リストにすると「やるべき」こと感が出る一方で、本当に実現したいなら先に時間を確保しないと「俺は強くなりたいので今期はそういうのしない」という判断を永遠に繰り返しそうです。でも今期爆進だけではしんどいということを強く体感しました。

10〜12月期はリスト化して、各期そこから1つOKRに入れてみようかなと思います。

OKR総括

全達成よく頑張ったたまには褒めてあげよう！

習慣の振り返り

2019年の目標

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

進捗

本（執筆）: 2冊/年

2/2

終わり！

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

合計5本提出のまま変わらず。この振り返りが終わったら2本書く予定です。

OSS: 1PR/月

30/3

1つ1つは細かいですがたくさん出しました。lintツールを実行してそれに基づく修正をしているだけです。

何もリントエラーが出ないプロジェクトと、大量すぎて比較的大事な項目だけ選んでPRを出すプロジェクトの差が激しいです。

このgolangci-lintを利用しています。

https://github.com/mercari/wrench/pull/7
https://github.com/mercari/wrench/pull/5
https://github.com/mercari/wrench/pull/4
https://github.com/mercari/wrench/pull/3
https://github.com/mercari/go-emv-code/pull/8
https://github.com/mercari/go-emv-code/pull/7
https://github.com/virtual-kubelet/virtual-kubelet/pull/774
https://github.com/syndbg/goenv/pull/97
https://github.com/google/ko/pull/89
https://github.com/knative/client/pull/412
https://github.com/knative/pkg/pull/646
https://github.com/ijin/serverlessdays-tokyo/pull/16
https://github.com/k1LoW/tbls/pull/137
https://github.com/kedacore/keda/pull/343
https://github.com/GoogleCloudPlatform/cloud-run-button/pull/82
https://github.com/google/kf/pull/659
https://github.com/google/go-cmdtest/pull/1
https://github.com/syndbg/goenv/pull/95
https://github.com/kedacore/keda/pull/323
https://github.com/syndbg/goenv/pull/94
https://github.com/deislabs/osiris/pull/37
https://github.com/kedacore/keda/pull/323
https://github.com/syndbg/goenv/pull/88
https://github.com/syndbg/goenv/pull/86
https://github.com/kubernetes-sigs/kubebuilder/pull/967
https://github.com/knative/client/pull/388
https://github.com/knative/eventing-contrib/pull/557
https://github.com/knative/eventing/pull/1732
https://github.com/syndbg/goenv/pull/91
https://github.com/syndbg/goenv/pull/90

自分な好きなOSSに対しリリースノートに載るようなインパクトのあるコントリビューションがしたいという思いを強めました。

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

1/3

雑誌寄稿に向けて作りました。10月分のような気もします。

https://github.com/toshi0607/jctl

ワンコマンドで下記全部やってくれます。

  • Goアプリケーションビルド
  • コンテナイメージビルド
  • レジストリにプッシュ
  • Kubernetes Jobとして実行

client-goとgo-containerregistryを活用したCLIです。

GitHub Actionsでkindを使ってE2Eテストもやってみました。

以上…！

10〜12月期にはこんなの作りたいです。

  • 何かしらコントローラー
  • サーバーとfunctionsをつなぐミドルウェア
  • DIY FaaS用CLI

意図通りのものがあれば詳しく調べて記事にするのでもよさそう

技術書（読む）: 30分/日

読んだ

Kubernetesがもっと好きになる！この本がなければKnativeソースコードリーディング入門　Knativeで学ぶKubernetesのカスタムリソースとカスタムコントローラーは生まれませんでした。Knativeに限らずKubernetes本体はもちろん、作られたタイミングがどうであれ他のコントローラーも読める雰囲気が出てきました。

kedacore/kedaとか読むとよさそうです。

【レビュー】『改訂2版 みんなのGo言語』（2019/8/1、技術評論社）の感想

技術書全然読んでへんわろたw

その他本（読む）: 30分/日

読んだ

前作に引き続き読みました。日報とか強化し始めた気がします。社会を形作るのは絶対的な原則ではなく人間なのでたまには処世術に触れるのもよいのではないでしょうか。

氏の本は読むのに時間がかかる本の後にパーッと読みたくなります。

プレゼンの神様、Microsoft澤さんの本です。自分のプレゼンを直視して改めて絶望したので、聞く人の気持ちを考えることにしてみました。まずは社内でやるプレゼンにいくらか活かしてみました。

今も自分が喋りたいことを喋る基本姿勢は変わってません。けど、喋る目的は発信することでフィードバックを得てよりよい理解・アウトプットに繋げることです。なのでこの本で言われているように伝えたい中核となるものや聴衆観点で何をもって帰ってもらうのかを整理することは結果的に自分がもらえるかもしれないフィードバックの質を確実に上げます。

任天堂のWiiの企画をした方の本です。既知の良さと未知の良さがあって、最初は受け入れられないかもしれない未知の良さを探求する方法が具体的なお話を添えて解説されていました。

未知の良さを提供し、最終的に世界を良くするのは大変かもですがやりがいはありますよね。サーバーレスとか直感的に現実的でない、良さよくわからんみたいな声が依然として強いのでチャンスです。

読んでる

Windowsプログラミングの父？チャールズペゾルドさんの本です。コンピュータが動く仕組みを解説する「読み物（≠技術書）」です。めちゃくちゃ面白い。バイナリコードの説明が、「通りを挟んで反対側に住む子供同士が夜中にどうやって会話するか？」から始まって懐中電灯、モールス信号みたいな風に進んでいって「コンピュータの仕組み」的な本と一線を画しています。

CAREER SKILLSで紹介されてて読んでみて正解でした。けっこう時間かかりそう。

あとは筋トレ中のAudible始めました。

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

今Qベストは世界№１プレゼン術でした。

ピアノ晒す: 1回/月

鍵盤1回も触らなかった…久石譲さんやっていきたい。

筋トレ: 1回/週

完璧！締め切りがいろいろ厳しくて2回くらいスキップしようとしたもののちゃんと行ってえらい。

今後の話

プラットフォームの運用・構築・開発、利用サポートができるエンジニアになりたい思いが強まったので、個人OKRもそれに寄せていきたいです。人と話して目の前の技術スタックに活きる順番ではまずKubernetesの使い方・動作原理を理解してより低レイヤーに降りていくのが現実的そうでした。本業として実現できるように頑張る。

サーバーレスも何かしらのPaaSやFaaSを使って開発することが目的ではなく、嫌なオペレーションを少なく、ビジネス価値により集中できるプラットフォームを活用して開発するのが本旨です。

これらを踏まえて技術スタックを3ヶ月単位で積み上げていきます。そういう方向性をもって人生を歩んだ結果3ヶ月後に全然違うことを言うのはありとします。7〜9月のOKRや集中すべきことを考えたり、運用したりする中で、何をやってもなにかしら自分にとってプラスの経験にもなるし思いもよらないよい出会いもあるけれど、長期的に目指したい姿を思い描いた上でやる方がよりワクワク過ごせそうです。集中もセレンディピティも失うことなく進んでいくのです。

10〜12月の個人OKRはつぎのような感じでいきます。

Objective 1

プラットフォームエンジニアへの闘争

Key Result 1

DIY Serverlessプラットフォームを構築する

  • ServerlessDays Tokyo
  • ServerlessDays Fukuoka
  • CLI
  • server -> functionのミドルウェア

Key Result 2

Kubernetesの知識を網羅的・原理的に理解する

  • CKA取得
  • 何かコントローラー作る
  • つぎの図をソースコードに基づき説明できるようになる

Key Result 3

プラットフォームを支えるOSSにコントリビューションする

機能 > テスト > リントツールでわかるもの > 設定ファイル > ドキュメント・コメント

Objective 2

ゆとりある心で秋〜冬を感じる

Key Result 1

心があたたまる食べ物を食べる

  • 鍋パする

Key Result 2

季節のイベントに参加する

  • ディズニーハロウィン
  • 温泉
  • もみじ、山

Key Result 3

やりたこと、いきたいことリストをつくりワクワクする

他

登壇

賞

執筆

記事

by ·1件のコメント

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

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

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

技術書典7で『Knativeソースコードリーディング』『Knativeの歩き方 第2版』『Goで学ぶAWS Lambda』を出展します #技術書典

Boothでも販売しています！

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

『Knativeソースコードリーディング入門』

『Knativeソースコードリーディング入門　〜Knativeで学ぶKubernetesのカスタムリソースとカスタムコントローラー〜』の正誤表と増補改訂情報 #技術書典

『Knativeの歩き方』

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

『Goで学ぶAWS Lambda』

『Goで学ぶAWS Lambda』の正誤表と増補改訂情報 #技術書典

謝辞

今回も妻に編集、表紙、デザイン、サークルカット作成、入稿（本とダウンロードカード）をお願いしました。毎回パワーアップしていてすごい。圧倒的感謝です。

今回はPOPも専用のを作ってもらいました！

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

振り返り

Good

継続

Knativeの歩き方やAWS Lambdaから継続して足を運んでくださる方がいらっしゃって嬉しいと共にホッとしました。

Knative本の続きを読んでみようと思ってくださる方や、カエルと空の本を今回も読んでやろうと思ってくださる方がいらっしゃるのはとても励みになります。

Boothの購入履歴を見ていてもその継続性はたどれたりします。

一方で、過去作読んだがやめとこうと思った方もいらっしゃるはずです。技術力や表現力を磨きながら、手に取ってくださった方によかったなぁ、またつぎも読みたいなぁと思っていただけるようなアウトプットを出せるよう修行していくしかないです。

個人OKR上の成果

今回の原稿の個人OKR上の位置付けは

Objective 1「DIY FaaSのためのKnativeのユースケース、動作の仕組みを理解する」のKey Result 2「Knativeを使ったプロダクトでどう利用されているか説明できる」技術書典7執筆 既刊Knative本アップデートとKey Result 3「Knativeの主要機能の実装方法を説明できる」技術書典7執筆 新刊KubernetesのコントローラーをKnativeで理解するに紐づけていました。

既刊ではKnatieの各コンポーネントに何を足せばDIY FaaSになるのかを章を増やして説明することにしました。これは10月、12月のServelessDaysに向けてストレートにやるべきことだったので、7月のCloud Native Days Tokyo登壇向けて行った調査を踏まえてよい時間を過ごせました。

実装を追った新刊については、Knativeの利用法を追うだけでなく、動作の根本原理を理解したいという思いで書きました。

時間

当初Cloud Native Days Tokyoが終わる7月末〜9/15までで書く予定でした。しかし、8月末に海外登壇に挑戦することになったのと、予想外に準備に時間がかかり9月の2週間で準備 + 執筆することになりました。
それでも

  • 9月の夜の予定をServerless Meetup以外すべてブロックする
  • スマホゲームをクロノ・トリガー以外すべて削除する

などしながら新刊60ページ、既刊アップデートと10数ページ追加を終えたのは確保できた時間でできる精一杯だったかなと思います。

想定時間通りに使えたらよりよい検証、執筆ができたかはわからないです。

Challenge

時間

できる限りのことはしたものの、やっぱりしんどかったのは事実です。内容が自分の好きなことであったとしても余裕がない状態でぶつかり切ると内容に関係なく嫌いになるリスクや燃え尽きるリスクがあります。

今度出展するときはまずOKRに位置付けられる前提で、2ヶ月調査・執筆に割けないなら見送りも検討するとよさそうです。いや、書きたい。

部数

まだ家に送った分が到着してないので正確な数はわからないですが、320部刷って200部くらい残りました。年末にかけてのイベントがあるので多く刷ろうとしていたものの、印刷発注日時点で前回より被チェック数が伸びてない状況で刷りすぎ感がありました。

実際に刷ったのは

  • Knativeソースコードリーディング入門 200部
  • Knativeの歩き方 80部
  • Lambda本 40部

でしたが、Knativeソースコードリーディング入門は100部でよかったです。前回歩き方を手に取ってくださった方の人数に鑑みさすがに200はない…！他の本はほんの少し少なめでもよかったかもくらいでした。

発注時点で平和な気持ちでいられるくらいの気持ちの余裕が必要です。

数字は記事下の方にまとめます。

ServerlessDays Tokyo/Fukuokaでも頒布します！！！

頒布情報

書ける部分も書くの遅かったかもと思っています。頒布情報に限らず、サークルの数も増える中でいかに自分の出展情報にたどり着いていただくかは悩みどころですね。

ただ、Knativeを知りたい気持ちがある方がたどり着くのに十分な情報はTwitterで発信してると思い込んでいます。力を入れるにしても、普段からKnative自体を知る人が増え、面白いので一緒に勉強してみたいと思う人を増やして盛り上げてく方がいいのかなと思います。

「OAuth」「DNS」「AWS」「Kubernetes」「Knative」みたいな並べ方をしたときにKnativeでうおーってなる人の数は他よりずっとずっとずっと少ないですよね。その分Knativeの人として認知されやすいかもしれませんが、それでも母数が厳しいです。

今後

直近は『実践Knative』という本があったときに入ってそうな内容は見ていきたいなぁと思っています。個人のOKR上では年内にDIY FaaSを（Knativeで）作るということになっています。

そのプラットフォームがある前提で

  • 独自に構築したプラットフォームのユースケース（Knative単体ではなくて、そのプラットフォームでどんなアーキテクチャが実現できてどんな課題を解決できるのか）
  • 運用・監視
  • 開発フロ
  • プラットフォームのデバッグ
  • 権限管理

などの全体的な見通しを示せないと、仕事で使うなり、現実世界の問題を解決するプロジェクト・プロダクトであるということを示したりできないと思っています。

また、そもそもIstio（をはじめゲートウェイコンポーネントとして依存するもの）やKubernetes自体の知見なしに存在するプラットフォームではないのでその観点から自分の知識・経験は強化して臨む必要もあります。

KnativeのServingはRC2ということでGAも遠くはない状況なので、つぎの技術書典の頃にはきっとGAし、Knativeベースのプロダクトの数も今よりきっと増え、プロダクション利用も増えてるかもしれませんね。

本のテーマはOKRや自身が詳しくなっていきたい分野にすると決めているので、年明けくらいにまたその直近の3ヶ月、その後の技術書典が含まれるであろう3ヶ月のテーマと決めようと思います。

あと、今回のようなOSSを触るときに、リリースノートに載る程度主要な機能を追加できるようになりたいと強く思います。

数字の整理

売上

現金

内訳は後日！
現金: 47000円

後払い

  • Knativeの歩き方 第2版: 21冊
  • Goで学ぶAWS Lambda 第2版: 7冊
  • Knativeソースコードリーディング入門: 42冊

1000円 × 70部 = 70,000円

Booth

9/17〜9/23分

  • Knativeの歩き方 第2版: 12冊
  • Goで学ぶAWS Lambda 第2版: 3冊
  • Knativeソースコードリーディング入門: 13冊

1000円 × 28部 + 優しさ1500円 = 29,500円

原価

  • 本印刷: 79240円
  • 参加費（パトロン）: 20000円
  • ダウンロードカード印刷: 940円

被チェック数

  • 8/26 6
  • 8/27 9:00 14
  • 8/28 23:00 21
  • 8/31 23:00 23
  • 9/3 0:20 26
  • 9/5 29
  • 9/6 11:00 29
  • 9/7 12:00 30
  • 9/9 19:00 34
  • 9/10 23:00 38
  • 9/13 23:00 41
  • 9/14 23:00 44
  • 9/16 23:00 46 印刷発注日
  • 9/17 23:00 53
  • 9/18 23:00 58
  • 9/20 23:00 64
  • 9/21 23:00 74
  • 9/22 7:50 79
  • 9/22 11:00 87
  • 9/22 11:50 90
  • 9/23 18:30 99

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

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

by ·0件のコメント

2019年9月22日（日）開催の技術書典7で3冊出展します！

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

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

『Knativeソースコードリーディング入門 Knativeで学ぶKubernetesのカスタムリソースとカスタムコントローラー』

今回の新刊はKnativeの実装についてです。Knativeの仕組みをより深く追おうとすると必ずKubernetesのカスタムリソースやカスタムコントローラーの話が出てきます。

以前mercari.goで発表した内容をより詳細にコード参照しながら解説します！

目次です。

第1章 KnativeとKuberentesの関係
1.1 Kubernetesの概要
1.2 Kubernetesの拡張方法
1.3 Knative の概要

第2章 KubernetesのAPI
2.1 APIサーバーの責務
2.2 Kind
2.3 APIグループ
2.4 バージョン
2.5 リソースとサブリソース
2.6 APIリクエストの処理フロー

第3章 APIクライアント
3.1 client-go
3.2 Object
3.2.1 TypeMeta
3.2.2 ObjectMeta
3.2.3 Spec
3.2.4 Status
3.3 ClientSet
3.4 Informer
3.5 APIMachinery
3.5.1 Scheme
3.5.2 RESTMapper

第4章 カスタムリソース
4.1 CR
4.2 CRD
4.2.1 categories
4.2.2 shortNames
4.2.3 subresources
4.2.4 additionalPrinterColumns

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

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

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

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

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

正誤表や増補改訂情報ページはこちらです。

『Knativeソースコードリーディング入門　〜Knativeで学ぶKubernetesのカスタムリソースとカスタムコントローラー〜』の正誤表と増補改訂情報 #技術書典

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

既刊をパワーアップしてお届けします！

一番大きな更新ポイント（章追加）は「Knative Lambda RuntimesとOpenFaaSのWatchdogから学ぶ、KnativeとFaaSプラットフォームの間を埋めるもの」です！

Knativeの概要記事は多いものの、それを実際どう活用してプラットフォームを構築するのかという話はそれほど出てないのではないかと思います。

本書ではその辺を見つつ解説します。

初版時点ではv0.5だったKnativeも今やv0.8、v0.9やGAも間近なのでアップデートもしました。

Buildが廃止されTektonに引き継がれた点も触れています。

こちらもすでにBOOTHで購入できる状態になっています。

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

すでにBoothやダウンロードカードセットで初版をご購入いただいている方も購入ページやダウンロードURLからダウンロードできるできるようになっています。

ボリュームも増えているので、ぜひお読みになってください。

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

正誤表や増補改訂情報ページはこちらです。

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

『Goで学ぶAWS Lambda 第2版』

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

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

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

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

GoとSAMで学ぶAWS Lambda

ServerlessDays Tokyo 2019

ServerlessDays Tokyo 2019では僕が講師を務めるKnativeハンズオンを実施予定です。

そちらも奮ってご参加ください！

by ·1件のコメント

このページでは『Knativeソースコードリーディング入門　〜Knativeで学ぶKubernetesのカスタムリソースとカスタムコントローラー〜』の正誤表と増補・改訂をお知らせします。

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

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

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

正誤表

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

PDFページ 誤 正 PDF反映 ePub版反映 MOBI版反映 修正日 version
44 カスタムコントーラー カスタムコントローラー 未 未 未 --- ---

増補・改訂

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

リソース

by ·0件のコメント

ServerlessDays Melbourne 2019で登壇してきました。振り返ります。

発表資料はこちらです。

書き起こし記事@mediumはこちらです。

Build serverless application on top of Kubernetes #sdmel19

なぜ海外カンファレンスに登壇するか

海外だから特別視してるわけではなく、今年の目標「4ヶ月に1回CFPに応募する」の一環でした。

とはいえいつか海外のカンファレンスも登壇できたらいいなぁとは思っていました。

プロポーザル

PaperCall経由で6/9に2つ提出しました。CFPのオープンが4/9、クローズが6/10でした。

CFPはこれです。

プロポーザルは社内の方にレビューしていただきました。正式にお願いしていたのではなく、提出予定の内容を分報部屋に貼って寝たら翌朝的確かつハートフルなコメントをつけていただいていたというのが事実です。

感動しました。

プロポーザルはServerlessconf New York City '19にもだいたい同じ内容で出していたのですがそちらは通過しませんでした。

ニューヨークのとメルボルンのは設問や制限字数などが異なるので多少内容は変えていますが大枠同じものを提出しました。

提出した内容はつぎのとおりです。

通過したプロポーザル

Title

Build serverless application on the top of Kubernetes

Talk Abstract

An application engineer who has never used Knative might be surprised when he starts using it while imagining something like AWS Lambda or Azure Functions. It’s because it’s neither PaaS nor FaaS. It provides “building blocks”. In my talk, participants can grasp the way to build DIY FaaS platform!

Talk Description

Recently, serverless has been seen in container workload. Container orchestration by Kubernetes is awesome in terms of deployment, scaling and self healing. But, it is a little more complicated for application engineers. They (including me) have to write Dockerfiles and Kubernetes manifests, build Docker images, push them to Docker registry, and so on. In my talk, I’ll show you how Knative and Knative based services like Cloud Run help application engineers focus more on codes and features introducing use cases and my containerized application development experience.

Notes

I wrote two books about serverless in Japanese

  • Learning AWS Lambda with Go
  • How to deal with Knative

I’m one of organizers of the biggest Serverless community in Japan.

Additional Information

※過去の登壇内容を出してくれというのがリクエストでした

This is the latest talk about serverless on Serverless Meetup Tokyo. https://speakerdeck.com/toshi0607/getting-started-with-knative-90ff6190-1251-4b7b-ada9-bbba5a8ca4b8

I’m going to talk about serverless on top of Kubernetes next month at CloudNative Days Tokyo 2019, the biggest conference about Cloud Native in Japan.

https://cloudnativedays.jp/cndt2019/ Talk E3

https://speakerdeck.com/toshi0607/serverless-architecture-on-the-top-of-k8s-with-knative

他に出してたプロポーザル

Title

How does Knative work in Cloud Run?

Talk Abstract

Participants can see how Knative, which aims to standardize APIs across multiple clouds, is used in managed services and Cloud Run running on GKE. This will allow them to guess and guess what Knative’s goal will be realized and what features will be added to Cloud Run in the future.

Talk Description

I’ll talk about how Knative, which provides parts for building containe-based serverless applications on Kubenetes, is used in Cloud Run. Cloud Run is a managed compute platform that enables you to run stateless containers that are invocable via HTTP requests. Cloud Run is implemented in Knative. Cloud Run on GKE allows you to search for Knative components using a kubectl command that manipulates Kubernetes APIs. Also, since Knative is OSS and we can investigate its features and implementation, we will speculate on the features provided by Cloud Run in the future.

Notes

同上

Additional Information

同上

プレゼンの準備

基本はCloudNative Days Tokyo 2019で話した「Knativeで実現するKubernetes上のサーバーレスアーキテクチャ」（45分）の大事な部分を抽出して15分にまとめようと思っていました。

しかし、CNDTの振り返りでも書いたとおり事後的に何人かにフィードバックをもらいにいきました。

1on1を設定させてもらったり、ドキュメントに書いてもらったり、いろいろな観点から意見をいただけました。

それを踏まえると構成は結構考え直した方がよいと思い結果的に使いまわしたスライド（図）はあったものの一から練り直しました。

準備過程で出会ったこの記事からの学びもとても大きかったです。

Kubernetes Workloads in the Serverless Era: Architecture, Platforms, and Trends

Kubernetes Patterns: Reusable Elements for Designing Cloud-Native Applicationsの著者ということでそちらも気になりました。

資料は渡航2、3日前に一通り作成し終わりました。

社内の人に発表練習を聞いてもらったりするといいよという紹介もしていただいてたのですが、資料作成（構成練り直し）にけっこう時間がかかってしまいそれはできませんでした。

資料とスピーカーノート用にメモした内容は前職の同僚がかなり丁寧に添削してくれてとても助かりました。

ServerlessDaysの本番2日前の夜に現地入りしたのですが、添削してもらった内容をもとに前日に資料修正し、発表練習の詰めをしました。

前日

朝は会場のメルボルン博物館への経路確認と下見、昼は資料修正と発表練習をして夜はスピーカーディナーでした。

スピーカーディナーは諸事情により途中参加になってしまいました。

運営メンバーとスピーカー合わせて10人くらい。日本でのカンファレンスと違って知り合い皆無だったので、少しでも知り合いが増えたのは当日の安心感につながりました。

当日

接続チェックは入念に行いました。

緊張して飛んだら困るのでけっこうGoogleスライドのメモ欄を使っていて、プレゼンター表示（スピーカーノートやタイマー、現在と前後のスライドが表示されるやつ）が出ないと困るためです。

持参したコネクターの接続もあまりよくなく本番もちょっと手こずりましたがオーガナイザーの方のいい感じの喋りで浮くことはありませんでした。ありがたい。

コンテンツ自体に対するリアクションは伝わってるか伝わってないかわからないですが、とにかくあたたかい雰囲気でした。

登壇後もいろんな方が話しかけてくれました。

中でも帰り道、会場の外で「ネイティブのスピーカーより発音、文法、簡潔さどの点をとってもよかった。よくやった。気つけて帰るねんで」とわざわざ自転車から降りて話しかけてくれた人もいてまた感動しました。

他の方の発表で感じたのは、デモする人以外は画面（PCもスクリーンもあまり）見ずにそれっぽい身振り手振りしつつ「プレゼン」っていう感じが強いというものです。

PC直接操作もせず、黒曜石的なフィンガープレゼンターとハンズフリーのマイクがデフォでした。

どういうやり方がより伝わるかわかんないですが一度試してみるのもよさそうです。

トピックは全体としてかなりバランスがよかったです。

https://www.serverlessdays.me/

サーバーレストレンド系、K8s系、ワークフロー（Step Functions）、リアルタイム（SignalR）、マルチクラウド、チャットボット（Bot Framework）、ステートフル（Durable Functions）、本番導入事例、オブザーバビリティ、セキュリティ、フロント、mBaaS（Firebase）

ここまでバランスいいのすごいです。ベンダー的にはMS・Azureが多かったですがGoogle、AWSの中の人が出てきてました。

日本はK8s系を話す人がサーバーレスコミュニティにあまり来なくて自分が盛り上げる気でいますが、その点でも3トークあるのは印象的でした。

途中のコーヒー休憩・ランチ・ネットワーキングタイムもバランスよく設けられており、ほぼ全員会場から出て参加者同士けっこう話していたのも目立ってました。企業ブース散歩も含めてです。

マジで休憩時間中に会場内に残ってたのはつぎのスピーカーと運営の人2、3人。これはすごい。

一番よかったなぁと思った発表はこれです。

とにかく構成が美しいです。

ログ、メトリクス、トレーシングをAWSのどのサービスが実現しているのか、サーバーレスなアーキテクチャでマネージドサービスとファンクションをつなぐイベントとはどうあるべきでどう管理すべきかという文脈で最近出たEventBridgeが出てきたり、1つ1つの説明に対する引用が的を射ていたり。

スピーカーはAWSでサーバーレスのPrincipal EvangelistをやっていてAWS Lambda in Action: Event-driven serverless applicationsの著者でもある@danilopさんでした。

他の内容も#sdmel19を追えば大体わかります。マルチクラウドの話をした@ineffybleさんが大体リアルタイムで全部ツイートしてくれてましたすごい。

資料は後日集めてまとめられるっぽいです。

他にもいい話がいっぱいあったので公開されるタイミングでできたら改めてまとめたいです。

振り返り

Good

十分な準備

いろんな人に協力してもらって内容を練るところから資料のブラッシュアップまで十分準備して臨めたと思います。

構成考え直した

CNDTからけっこう直したのはよかったです。認識のブラッシュアップ・再構築はフィードバックもらう意義ですね。

スマホのゲーム消した

けっこうやってしまうポケGO、マージドラゴン、アビスリウムを消しました。

家でやってしまってた時間は準備に充てられるし、通勤で歩く時間もリスニングの時間になりました。

Kubernetes Podcast from Googleは特に内容も好きですし、知った表現をプレゼンに取り込んだりできて学習効率が高かったです。

飛行機ずっと本読んでた

飛行機の中や待ち時間には映画の誘惑に一切負けずずっとProgramming Kubernetes: Developing Cloud-native ApplicationsとCAREER SKILLS ソフトウェア開発者の完全キャリアガイドを読んでいました。

Challenge

もっと内容に関して議論できるとよかった

K8sやってる人に登壇後出会えなかったのはあるにしろ、一応議論の土台は喋ってるのであれこれ話できるとよかったかなと思いました。

KEDAの話をした人も、KEDAとOpenFaaSとKnativeの話をした人とGoogleの人もいたので自分から話しかける選択肢はあったはず。

カンファレンスでは事前に聞く話を決めることがあっても、このテーマでちょっと議論したいみたいなスタンスで臨んだことはないのでそういう観点で準備するといいかもと思いました。

自分で検証するときのトピックの網羅性

今回のオブザーバビリティやセキュリティなどの話を聞いたり、普段人と話して思うのは「実際使いたいときに開発フローに組み込むことはできるのか？」「各開発フロー毎のベストプラクティスは？」みたいなのに関して自分が全然答えられないなという部分です。

根本のコンセプト、仕様、実装ももちろん理解してないと使えないですが、現実的に開発フローを組み立てるにはどうしたらいいのかという観点で検証して自分の知識を整理して発信していくのは有意義に思えました。

時間かけすぎ

9月締め切りがある原稿たちの執筆時間をかなり削った感は否めません。

個人OKR運用で継続で改善していくとは思います。

原稿の後には10月のServerlessDays Tokyoの Knativeハンズオンの準備が待ってるので、それにも活かせる形で書き上げたいです。

by ·0件のコメント

改訂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-bindataやjessevdk/go-assetsはもうメンテされないので、rakyll/statikやgobuffalo/packrを勧めていた話の流れがよかったです。リソース埋め込みでまず思い浮かぶのがgo-bindataとgo-assetsだったので認識を改めることができました。
  • awesome-goにGUIセクションがあることやGUI用のライブラリがたくさんあるのを知りませんでした。CLIツールを作るものという固定観念を打破してくれました。自分で積極的に作るモチベーションはないけれどそういう章があったら楽しめそうです。
  • 設定ファイルのフォーマットと場所をどうするかについて各フォーマット向けライブラリの成熟度などを比較した上で筆者の見解が述べられていたり、実装の注意点が整理されていたのがとてもよかったです。cgoを使っているかどうかによるクロスコンパイルの挙動差異や、ホームディレクトリ関連でcgoに依存しないAPIが特定Goバージョンから利用できるようになったことは自分がこれまで意識できていなかった観点で、バージョンアップを追うモチベーションやポイントの1つになりました。

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

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

  • 標準出力のバッファリングをあるLL言語と比較しつつ、bufioパッケージを利用した実装と利用していない実装を使ってシステムコール回数をstraceで観察していたのがよかったです。システムコール自体の重みがよくわかってないのでベンチとろうと思いました。
  • dustin/go-humanize便利そう。わかりやすく表示できるのも、わかりやすい形式で引数などに指定できるのもいいですね。
  • 乱数系のパッケージはおそるおそる使っている感があるのでmath/randとcrypto/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言語

by ·0件のコメント

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の件は問題を生じる状況を理解できていないところだったりします。

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

by ·1件のコメント

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

サマリ

個人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の売り上げで購入した食洗機、本当に買ってよかったです。

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

by ·1件のコメント

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/