詰め込めるように練習してなんとか時間を短縮したのもあって、本番を想像すると近況が余計に増すのが何より厳しかったです。時間が余りそうなら余りそうで不安だとは思いますけどね。「ゆっくり話して収まるように思い切って削る」を次はやります。Meetupの登壇資料とログミーさんから出た記事の媒体の反響の差分は資料単体の拙さだったり、コンテキストの差だと思います。今回の登壇準備で得た知見はコードを追いながら文字で説明したい部分が特に重要な箇所だったので自分でやってみようと思いました。READMEから抜け出せてない感がまだまだ強いです。今回いただいたフィードバックの観点や実装面で深掘りして新刊を出すので、そこでもう少しなんとかしたいです。それでもアウトプットの機会を経るごとに理解できたと思うことは増えているのは思うので、理解しようとするスコープを定めて着実に進んでいこうと思います。妥協したが理解した方がいい部分RouteとIstioRouteがIstioのリソースをいじってると思い込んでてGateway、VirtualService、DestinationRuleなど探したものの、Routeの変更が反映されたりはしていませんでした。Glooなど他のGatewayに差し替えれるにしてもRoute設定したときに何を変更しているのかなどは理解したいです。TektonTektonでPipelineを作ってKnativeのサンプルをデプロイしようとしたもののできなかったのでその原因を調べ切りたいです。CloudEventsもっと追ってみると楽しそうでした。FaaSの課題、イベントドリブンなものを作るつもりで書いてたのにあまり触れられなかったのもイケてないです。Eventingのリソースbrokerとfilterのdeployment、ラベルを消してもDeploymentを消しても何度でも蘇り消えなかったので実装追いたいです。issueにさっきコメントついたので読む仕様を覚えるだけで実現する仕組みを追わないのは、他のことを追い始めても先が見えてる気がするのでここは後手に回っても最終的に妥協しないようにしたい。あと、この文脈は関係ないけど登壇依頼される程度に特定の分野に詳しいことが認知され、なおかつその分野の正しい見識を持っている状態になりたい。speakerで何人かにご質問いただいたり、お話ししたり、インターネッツから拾ったりしました。Knativeの発表でこんなに色々話してるの聞いたのは初めてみたいな声はお世辞でも嬉しかったです。Runどう使うとよさそうかIstio、Gloo以外にもAmbassador使えるのでは?EventingのIstio依存ってもうないのでは?自分のアウトプットに対してこういう声をもらうのが目的なので本当に嬉しいと思ったり、重要な視座をもたらしてくれる人はだいたい変わらないのでそういう人に直接話に行った方が強くなれるのでは?って思ったりしています。最後の5つはいざ使うときに技術選定する大事なポイントだったり、自分が情報を追う上で見つけられなかった点だったりして深めていこうと思います。affinityの件は問題を生じる状況を理解できていないところだったりします。フィードバックは業務で得られるはずですが、それに加えて行なっている個人的な活動なのでいただいた内容を糧に強くなっていこうと思います。#8で登壇してきました。Fridayに出れるときは出るようにしてるのですが、その勢いです。勉強会後にSlackの分報部屋で10分くらいなら喋れるかもしれないって呟いたら回収していただきました。社内SlackにKnativeのアイコンを登録するなどしている割には何も実装を追ったことがなかったので追ってみることにしました。KubernetesのコントローラーとKnativeGoで書いてるならまぁ読めるやろくらいの気持ちで臨みました。したら個々のコードの意味はなんとなく追えても全体像の見えなさがすごかったです。Applicationsを読んでみると本番の2、3日前にようやく自分なりの整理の仕方が見えてきました。「ライブラリとコード生成ツールとSDK」を区別し始めて次のようなポイントに落ち着きました。Kubernetesや実装を追いながらなぜ直接WatchやListを直接実行せずinformerを介するのかインメモリキャッシュの実体は何かListとlisterの違いは何かworkqueueにエンキューされるのは何かなどを調べました。この図には至ったものの、sample-controllerの方の図にあるFIFOキューとReflectorがknativeでは見つかってません。無いならなぜ使わない判断をしたのか理解していません。振り返りGood30分話しきった何はともあれ話しきったのはよかったとしたいです。Kubernetesのコントローラーへの興味が強まったこれまでKnative文脈ではどうしても概念の理解やKubernetes自体に必要な膨大な知識をキャッチアップするのに必死でした。そこから具体的にどう実装されているのに踏み込むんだことでこれまでと違う視点が得られてよかったです。CRDとコントローラーも言葉では知っているつもりになっていたものの、いざ追ってみると何一つわかってなくて高まりました。準備期間がちょうど技術書典7の募集期間と被ったこともあり、Knativeを切り口としたコントローラーの話で応募することにしました。Knativeの既刊もバージョンアップしたいのでバランスは難しいところですがやっていきです。Goへの気持ちも高まった今年前半のお仕事ではがっつり実装していたわけではなかったですが、最近は実装タスクの割合が高く、Goの一実装として学ぶことが多かったです。無限ループを安定して実行するゴルーチン、チャネル複雑なクライアントを組み立てるコード生成スレッドセーフなキューサーバーリクエストとキャッシュ機構すぐにでも活かしたい部分があるので活かそうと思います。Goを学び始めたきっかけの1つがサーバーレスなOSSへのコントリビューションなのでそちらもやっていきたいです。練習30分の発表でも事前に4回くらい通して読んで時間調整できたのはよかったです。最初とりあえず30分読んでみたら16枚余ったので、その時点と比較するといい具合になったと思います。2週間朝晩集中室に引きこもりました。強すぎる切迫感と集中を欠く割にダラダラ過ごした感もあるので、来月の登壇は進め方を工夫します。集中することを決めるのに集中する。焦っているときほどはやる気持ちを抑えて「25分集中して5分休む」のポモドーロのサイクルを徹底する。一方で、今回も全体像を見通して集中することを決めようとはしていたものの、何に集中すべきかがよくわからず右往左往した時間が長かったです。それを見つけるために、行き詰まったら人に聞くとかやりようはあるかなと思いました。会社にもコミュニティにも強い人類はたくさんいるので。ライブソースコードリーディングその場でやり切る意図がそこまでない(技術書典の話に繋げたい)にしろ、もう少し大きく映すゆっくり進むなどやり方は工夫できたかなと思います。フィードバック自分で知りたいと思ったことが知れたのはいいとして今回の話を人が聞いてどう思ったんでしょう?Goを冠した勉強会で話す内容として適切だったんでしょうか?せっかく懇親会もあるので聞けばよかったですね。まとめつぎは初のCFPを経たカンファレンスでの登壇。人に事前に2回聞いてもらい、軌道修正する今月中に目処を添えてお願いするテーマである「解決する課題」を明確にして関係するユースケースを話すデモとかするにしても何のためにやって何を見て欲しいかを明確にする漠然と機能や実装を追わず検証のゴールを先に決めるつぎの土日は項目出しのためにグダグダ調べていいただしその後は集中すべきことに集中する。公式サイトからもセッション情報を確認できるようになりました。toshi0607·0件のコメント技術書典6、無事終了しましたね!関わられたすべてのみなさんお疲れ様でした。つぎの出展に備えて振り返りたいと思います。本の内容についてはこちらにまとめています。手にとってくださった方はこちらのページで変更内容をお知らせしていくのでぜひ見てみてください。単著と言いつつも妻に編集や表紙デザイン、サークルカット作成、入稿(本とダウンロードカード)をお願いしました。だらけの前回と比べると多少平和だった感はあるものの、4/8入稿に対して4/7の夜まで粘ってしまったので丁重に労わせていただく所存です。執筆環境として、TechBoosterさんのTechBooster/ReVIEW-Template、@atsushienoさんのatsushieno/vscode-language-reviewを今回も活用させていただきました。ありがとうございます!!振り返りGoodテーマこちらでも書きましたが、Kubernetesをある程度理解しないと先に進めないKnativeをテーマにしたことは仕事にも大いに役立ちました。#serverlesstokyoさらに、サーバーレスと謳っているとはいえ最初は愛しのLambdaには程遠く感じたKnativeも、愛しのLambdaに感じる愛しさの根源を見つめ直し、それをKubenretesの利用者に届けたい気持ちを感じとれたことは今後の検証の方向付けになりました。Tokyoでも「Knativeで実現するKubernetes上のサーバーレスアーキテクチャ」というタイトルで発表させていただけることになったので進めていきます。KubernetesからServerlessを訪ねて』をよりよくしていきます。具体的にはつぎのような内容の章を追加します。Knativeのコンポーネントを組み合わせたユースケースKnativeを使ったプロダクトを利用することで「開発者にとってより機能・サービスのユーザーに対する価値向上」に集中できるかKnativeで作る俺たちのLambdaそして何より、普段の仕事で感じるような感じないような課題と自分の趣味の交点がこのあたりな気がするので楽しい!!楽しいよ!!!わくわくする技術との出会いが何よりも大きな価値です。書いたら振り返りもう満足した。技術書典5では本番後に販売を開始しましたが、今回は入稿日に販売を開始しました。前回そうしなかったのは「本来紙本を買ってくれるはずの人が紙本でなくBOOTHに流れ、紙本が売れ残るのがこわかったから」です。BOOTHで事前に買ってくださる方は当日参加できない事情がある(別の用事がある、興味があるが会場が遠い)方のような気がしたのと、紙本売れ残るリスクそんなに感じなくなりました。ABテストできるわけではないので何とも言えないですが、収益が目的ではないので告知タイミングで欲しいと思ってくださった方が当日を待たずその場で手に取れる方が幸せだと思うので今後もそうします。Log杉田さん(@toshi0607)からサーバーレスなワークロードをk8s上で実行できるKnativeの解説本を読ませていただきました。2019いただいた感想が嬉し過ぎて本当に書いてよかったなぁと思いました。前書きに始まるKnativeを僕が書く必然性(僕が書くのにふさわしいとかそういう意味ではない)や、それぞれのコンポーネントのサンプルの登場させ方、順番、組み合わせ方。中身としてはREADMEを超えるものにはなりませんでしたが、話の流れとして自然になるようにする部分にはこだわりました。いう部分や愛情が伝わったのは嬉しいです。Knativeを一緒にわいわいやる仲間が増えていくのは財産です。2019お気に入りです。ConfはLTやってみたい!と思っていたものの、技術書典5の準備と重なったり、それを発表できる形に整理する方法も思いつかずただただ指をくわえて見ていました。Meetup登壇を1つのマイルストーンとし、自分の認識もブラッシュアップしながら進めることができました。#serverlesstokyo継続して取り組みたい大きなテーマがあるときはアウトプットの場が分断されずいい感じに繋がるので継続したいです。最新バージョンへの追従を諦めなかったこと入稿数日前に0.4系から0.5系へのアップデートがリリースされ、1つのコンポーネントのアーキテクチャが大きく変更されました。進捗も逼迫していたので迷ったのですが、開発に勢いがありどうせすぐ情報が古くなるなら可能な限り新しいものを届けたいと思い追従することにしました。古いままだと、本を読みきったと思ってもまた別途新バージョンをキャッチアップする必要が生じやや二度手間感が生じます。それよりは早くユースケースに進んでわいわいして欲しい。事前にテーマの近い人が知れる(そういう風に配置していただける)ことで事前にTwitterでいろんな方と交流できたのもよかったです。当日を迎えるのが楽しみになる要素の1つでした。2019何に1000円を支払っていただくのか前回比ページ数が減った上で同じ値段なの気が引けると思っていたこともあったのですが、そう考えるのはやめました。検証された最新技術が本当に必要最低限の分だけまとまっていて、安心して気軽に入門できるのも1つの価値です。当日実際手にとってみて、「この分量で1,000円かよ」って思われるなら別にそれでいいなぁと。ソフトウェアをコードの行数で値付けする・しないと似たような話かもしれません。あと僕は一度買ってくださった方には増補改訂版(電子)を無料で配布しています。目の前にある紙に1,000円払ってくれと言ってるわけでもありません。「紙を渡して1,000円を受け取る」しか見ないのは悲しいし、本質から遠いです。Challengeうやむやにしていること期限あるものに間にあわせるにあたり妥協している部分があります。詳細は割愛する形でリンクだけのっけているようなものを全部完全理解しているわけではないし、公式のREADMEに書いてる仕様の実装全部追ってるわけでもありません。今後ユースケース中心に見ていくにあたり、それが楽しくて疎かになりそうだが理解する時間を確保すべきだなぁと思う部分は個別に整理するなり、Knative本に唐突にコラムとして追加するなりしたいです。分散システムのアーキテクチャ無限に学ぶことがあって楽しいですね。実装面は5月の後半に少しGoにフォーカスした内容で30分くらいお話しすることが決まりつつあるのでいい流れです。作った本を視覚的に伝えるチャンスなのにもったいない。OGP画像に最適なサイズと、これらを使えばキャッシュクリアできる知見を得たのでよかったです。過去に投稿した分も更新されます。再投稿してもいいし、再投稿しなくてもいい。https://cards-dev.twitter.com/validatorhttps://developers.facebook.com/tools/debug/og/object/こういう感じに整理するのすごく見やすくていいなぁと思いました。何を頒布しているかわかりやすい。Pa-Maおしながきできました。当日限定のセット価格もあります。2019コミュニケーションパス何かあったら@toshi0607まで!みたいなのわざわざメンションしてコミュニケーションすることもないのかな。頻繁に「Knative」でTwitter検索してるのでだいたい拾えている気もする。考えていたところこんなツイートが!とりあえず1章。抽象化してサーバレスっぽく見せかけるんやろ?って想像した。2019ハッシュタグでゆるくつぶやいていただけたら拾いますくらいの方が楽に感じたり、何か言葉を投げかけてくれる人がいるかもって思いました。ハッシュタグ作りやすいタイトルだと便利、しかしハッシュタグに最適化したタイトルつける必要もないみたいな姿勢でいけたらと思います。みんなその辺どうしてるんやろうと思ってBOOTHのぞいたら完璧な方がいらっしゃって感動しました。第2版ハッシュタグ検索結果のURL貼っておくの正しいっぽいし、それに限らず親切な作りになっていて勉強になります。会いに行けるアイドルならぬ、タイムライン上にいる著者をたくさん生み出した技術書典。気軽に絡んで技術もふもふわいわい盛り上がりたいものです。数字の整理は後からしますが、Knative本の方は100部刷って完売が14時過ぎでした。Lambda本は既刊の第2版で50部刷ったものの完売が終了直前。Lambda本はちょうどいい具合だったと思うのですが、Knative本は150部刷ったらその分頒布できたのかわからないし、毎回テーマも異なるのでなんとも言えないですね。言えるのは、紙本が当日残ってもそれを必要としてくれる人に届ける手段はいろいろあるので、ちょっと余るだろうなぁくらい刷ってみるのも試してみようと思います。金銭面では紙よりも電子で買っていただける方がよいかもしれませんが、自分は技術書はほぼ紙でしか読まないし、読もうと思ってくださった人が読みやすい形で手にしていただけるのが一番です。事前に募集したものの、その時メンションしてくださった方にすぐ返せず、いざというタイミングで探したらメンションはなくなっていました。興味持ってくださる方は大切にしつつ、ゆるぼで集めるのは厳しく感じます。紙本になる前に読んで欲しいケースもなったあとに本でほしいケースもどちらもあるので、目的を明確にしてお願いする形にすることにしました。Run(Knativeを利用したプロダクト)が出たのは追い風になったと思うのですが、その追い風や発表直前のアップデートは頑張れば読めたかもしれなです。発表前にBOOTHで販売を開始していたのはすごくよかったと思います。一方でこの点考慮できていれば紙本もうちょっと刷ろうと思っていた可能性が高いです。2019このとおりです。振り返りの「テーマ」と「うやむやにしていること」あたりをいい感じにやっていきたいと思っています。分散システムのアーキテクチャとKnativeめっちゃ楽しそう。16,000円BOOTH販売(PDF、ePub。