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 ·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 ·1件のコメント

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に向け原稿進めます。

by ·0件のコメント

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

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

執筆のモチベーションについては宣伝記事に書いたので、今回はこれからに向けての話を中心に書こうと思います。

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

謝辞

今回は単著やで！と言いつつ、大いに助太刀してくれた2人にまずお礼を言いたいです。

まず前職の同僚@Shuheiktgwさんです。査読でわかりにくい部分を指摘してくれたことで特に2章は大きく構成を見直せました。更にGitHubのリポジトリにもPRをくれ、大きく貢献してくれました。

そして妻です。9月12日時点ではまだ原稿0のようなペースで原稿以外に時間が割けなかったので9/8に「原稿以外のすべてを頼む！！！」と一任（丸投げ）し、締切管理、表紙デザイン、ダウンロードカードデザイン、発注・入稿、当日のチェックリストに基付いたパシリまで何一つ文句も言わずにやってくれました。改めて文字にしてみるとひどい夫や。

それでも、発注してくれた本の開封の儀やイベント当日の売り子を通じて「つぎは書いてみようかな…！」なんて言ってくれるのは心の救いです。ディズニーで打ち上げしてきます。

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

フィードバックが欲しい

今回頒布した『AWS Lambda』は技術書典3の『Extensive Xamarin』で担当したXamarin.Macの章と比べ実装に基づく内容になっています。もっと言えばAWSのアカウントがありGitHubからソースコードを落としてくればそのままデプロイできるものです。

それは、書籍を執筆するとは言いつつも自分が実装する手触りが欲しかったのが1つあります。そして、自分が技術を学ぶときは最低限のルール説明を読んだら掲載したサンプル+αの粒度のコードが読みたいと思うからです。

説明しないと伝わらないソースコードなら書き方がよくないかもしれないし、どうしても必要ならコードコメントでよいのではないかと思います。

けどそれならGitHubにしっかりREADMEを書いて公開して終わりになるし、書籍にする意義が見出せません。結局、GitHubと技術書の間みたいな構成の本になりました。

幸い印刷していた分は売り切れ、ダウンロードカードも購入いただき、BOOTHで販売している分も着実に売上を伸ばしています。

つまり、売れ残った紙本に縛られず思い切って増補改訂ができ、ダウンロードカードのURLを通じて紙本を買ってくださった方にも更新情報をお伝えできる状況です。

そこで、フィードバックをくださる方にダウンロード版（PDF、ePub、MOBI）を差し上げたいと思っています。ぜひ@toshi0607までDMをください。もちろん購入いただく分は止めません。それはそれでとても嬉しいです。

  • 本としてこの形式がありと思うか？
  • ソースコードはわかりやすいか、どうすればわかりやすくなるか？
  • 構成として過不足はあるか？
  • ユースケースから自分でLambdaを利用したアーキテクチャを検討するイメージはわくか？
  • もしあまり触ったことがなければ触りたくなるか？何が辛そうか？

このあたりの感想がほしいです。

僕が欲しかったのは売上ではなく自分の技術力を高めるための言葉だったことに気がつきました。

お金は社が十分供給してくれます。

増補改訂

他の記事でちょっと書いたのですが、目次を考えている段階ではLambdaを活用する上で組み合わせそうな技術要素をもっと盛り込む予定でした。

  • 認証・認可（4章、CognitoとかAutn0とか使う）　
  • サーバーレスSPA（4章、Vue.js）
  • Lambda上でヘッドレスブラウザ使うユースケース（途中まで実装してた）
  • GitHubアサインのSlack通知
  • AWS Serverless Application Repository
  • Kinesisを使うユースケース
  • DLQの設定
  • Alexaスキル系
  • GraphQL（AppSync）
  • SQS（FIFOキュー）のユースケース
  • CQRS（とても実装したかった）

しかし、9月12日の午前段階で3目のユースケースの実装が一通り終わったような状況だったので見送りました。

4章関連とCQRSはやって章も足したい。自分が買ったPDFの技術書の章、気付いたら増えてるとテンション上がりませんか？上がらなくても大丈夫です。

ただ、仕事ではAWSに触れなくなったのでいい感じに共存したいなぁとは思っています。

AppSyncもFargateも触りたい気持ちはあります。

けど、Serverless Conf Tokyoで@marcy_teruiさんのセッションを聞いて、プロダクトそのもの以外の技術系アウトプットの理想形はこういうのだと感じました。

実運用に裏打ちされた教訓が他には無い独特かつ研ぎ澄まされた視点で語られる40分はただただ感動ものでした。

季節性のあるいい感じのアウトプットイベントに一生懸命向き合うこと自体はもちろん価値があるけれど、それが自分が向き合うべき課題の解決に関連するものであれば尚更素晴らしいということです。

逆に関連ない方がよい結果になるかもしれないけれど、やってみないことにはわからないやってみよう。

数字の整理

売上

  • 本 + ダウンロードカード（PDF、ePub、MOBI）: 1000円 × 100部 = 100,000円（14時完売）
  • ダウンロードカード: 1000円 × 24枚 = 24,000円
  • BOOTH販売（PDF、ePub。MOBIは希望者に送付、技術書典終了日23時頃オープン）: 1000円 × 22 = 22,000円

原価

  • 紙本印刷費（日光企画さん）: 30760円
  • ダウンロードカード印刷費（プリスタさん）: 940円
  • 技術書典参加費: 7,000円
  • ダイソーで小物（ホワイトボード、テーブルクロス、見本誌台など）: 1,000円
  • 人の力

被チェック数

技術書典当日（10/8）最高で127、そこから減って最終的に123。

  • 10/1: 38
  • 10/3: 51
  • 10/4: 57
  • 10/6: 73
  • 10/7: 98
  • 10/8 8:00: 116

何が原因で売れる・売れないが決まるかよくわかりません。

僕は10/1の夜入稿したので、結果的に完売は嬉しかったものの100部刷るのすらだいぶこわかったです。

そのためBOOTH販売に本来紙で買ってくださる方が流れて欲しくなかったので技術書典終了後に開始しました。

ただ言えるのは技術書典で自分のブースに来てくださったお客さんを見ているとやっぱり紙の本が欲しそう。

そしてBOOTHで買ってくださる層（住んでる地域とか紙・電子書籍のスタンスとか）と違ってそう。

まとめるとやっぱりよくわかりません。テーマやサークルの配置によっても変わりそう。

いろいろと考え方はあると思いますが、僕は紙本を余裕をもって売り切ってスッキリした気持ちでつぎの技術書典を目指したいです。執筆やその根底にある技術力向上にフォーカスしたいなぁと思いました。かと言って当日のダウンロードカード販売とBOOTH販売だけ行って紙本をもっていかないのも嫌です。

技術書典は楽しくてしょうがないけれど、技術書典でアウトプットすること自体は自分にとっての目的ではありません。

これからも自分なりのスタンスで向き合っていきたいなぁと思いました。