by ·0件のコメント

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

サマリ

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

習慣

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円とかコスパ良すぎる…。

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

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

よく切れます。

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

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

毛抜いたら整えます。

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

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

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

大きめでよいです。

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

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

by ·1件のコメント

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のリンク流してくださる程度で大丈夫です）していただける方がいらっしゃれば差し上げます。

ぜひお声がけください。

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

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

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回/週

家庭

今年も捨てるぞ！

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

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

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

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

by ·1件のコメント

2018年12月28日に『GoとSAMで学ぶAWS Lambda』が発売します！

内容としては技術書5で書いた『Goで学ぶAWS Lambda』に少し追記したり、いくつかいただいたフィードバックを元に改善したりしたものです。

フィードバックは僕が前々職で営業として働いているときにプログラミングを教えてくれた師匠である@ms2satoさん、前職の同僚である@Shuheiktgwさんにいただきました。

技術書典5の後にインプレスR&Dの山城さんにお声がけいただき、言葉遣い的なところを直していただき複数のプラットフォームでの出版にいたりました。

https://nextpublishing.jp/book/10326.html より

そして表紙を描いてくださったのはわかばちゃんと学ぶシリーズでおなじみの湊川あいさんです。

出版を目前にした今でもお話ししたことはないにもかかわらず、これほどまでに素晴らしいカエルに出会えると思っておらず感動しました。

技術書典5、BOOTHから読んでくださってるみなさん含めありがとうございました。

宣伝媒体

色々と出していただいてます。

同人版

技術書典5の後に出し始めたBOOTHでも先日とうとう50部を超えました。

技術書典5の『Goで学ぶAWS Lambda』の振り返りとフィードバックのお願い #技術書典でも書いているとおりアップデートがあるときは商業版とは別にアップデートは続けます。

句読点の使い方等僕の好きな表現の仕方もあるので、細々とやっていけたらと。

by ·0件のコメント

この記事は裏freee Developers Advent Calender 2018の24日目です。

こんにちは！かつてfreeeに在籍しニャンちゅうと呼ばれていた者です。

最近ではトシと呼ばれています。自分の寿憲（としのり）という名前がとても好きなのと、ニャンちゅうと呼ばれることでキャラ付けに下駄を履かせていただいていた過去の自分を乗り越え、純粋にエンジニアとして闘争したいという思いからニャンちゅうはアイコンにとどめることにしました。

エンジニアとして成長したい方向性と今のロール

自分がエンジニアとしてどう成長したいかを表現する局面でかつてこんな風に書いていました。

技術寄りでサービスを考え、作り、変え、大きくしていくことができるエンジニア（になる）

時期によって担当するプロダクトの方向性を考えるPdM的な役割も担いサービスを考えることもありました。しかし、ここ1年くらいはそういうことは少なく、上記の「作り、変え」にあたりインフラも含めてどう設計するとよいかを考えることが多いです。

9月からはメルペイという会社で信用を創造して、なめらかな社会を造るべくその足がかりとしての決済システムを開発しています。

メルペイではマイクロサービスを開発するチームの1つでテックリードをしています。きっと組織によって「テックリード」の位置付けは異なると思いますし、少なくともfreeeにかつていた（？）テックリードとは異なります。

メルペイのテックリードの役割はこの記事で触れられているとおりこんな感じです。

エンジニアたちにとって開発の妨げになっているものを取り除くほか、全体設計や技術にある課題を解決する。

エンジニアと立ち話。Vol.19 @foghost（メルペイBackend）ちょっとお話いいですか？

メルペイに転職したのは自分が技術で解決したいと思うものが会社の方向性と合致しているからです。そこでどう貢献するか形は色々とある中、テックリードとして技術課題に立ち向かうのは自分がエンジニアとして成長する上でもとても重要なことだと捉えています。

とはいえ、ロール以前にGoやGCP、最初から全体的にマイクロサービスなどそもそも技術的に初めてしっかりと触れることが多く、想像以上に難しい・わからんと感じる局面が多いです。

全方位的に完璧を目指すのは現実的でない雰囲気な中、何を解決すればメルペイ（特に自分が担当するマイクロサービス）をリリースでき、安定して運用をできるのかを考えそのときそのとき一番大事っぽいことに集中して取り組む必要があります。

来年よりいい感じでチーム開発を進めるために、注意し続けたいことや改善したいことをまとめます。

設計

方針的な実装と詳細な実装、アーキテクチャを暫定的にでも決定しないと実装できないところとそうでないところをきちんと分けないと進みません。

マイクロサービスに対し、入社前はそのマイクロサービスのドメインをきっちり深め運用までしっかりしていく必要がある一方であまり他のサービスのことを知らなくてもよいというイメージがありました。

そのイメージの正誤はおいておいて、他のサービスの設計にどうしても依存せざるを得ないケースがあります。さらに複数のサービスが関係することもあり、設計・仕様の調整を待っていては進まんみたいな状況もありえます。

ただ、本当にそれが決まり切らないと全ての作業が無駄になるということもないので、影響を受ける部分とそうでない部分の境界を見極める、影響を受ける部分を分離するということが大事そうです。

仕様を決める時点で複数のサービスが拘るならその部分はその後も他のサービスの影響を受けるかもしれませんし、自サービスの都合で自由に変更し辛いかもしれません。

このあたりの設計を考える上では今年Clean Architecture 達人に学ぶソフトウェアの構造と設計に最も影響を受けました。

本にも出てくる「できる限り決定を遅延できる設計」というのは自由にコントロールできない部分がありかつ不確実なものに立ち向かう上では肝に銘じたい言葉です。

一方で、今の技術スタックに十分に馴染みのないまま考えて実装の現実味がない部分もあったので実装力にある程度裏付けされた設計ができないと辛いです。

個人開発でコード書けば済む部分もあれば、ある程度大きめのコードベース・複雑な前提で試さないと現実味がいつまで経ってもわかない部分もあります。なので、調整系のタスクの優先度が高いにしても自分で実装するのも必ず残すよう心がけます。

意思決定

「こういう設計で行こう！」と決めないと進まないという思いと、詳細な実装を進める上で困るようであれば自由に変えてよいのではという思いは同居しています。

しかしそのふわっとした感じだと、メンバーに決まってるのか決まってないのかようわからん、とモヤモヤが生じることもあります。

やり方まで押し付けるのは嫌な一方でどこかのタイミングで結論（それが未来永劫変わらないというものではない）を出さないといけないし、そうせざるをいけないといけないこともあります。

その上でやるべきことは

  • そう決定した根拠を整理し、 腹落ち感があるまで 説明したり議論したりする
  • 根拠はその仕様を決めないといけない背景・コンテキスト、仕様面、技術的制約、社内外問わないコミュニティの動向、社内的な議論を構成要素とする
  • 腹落ち感がありそうかなさそうかリアクションを見てわかる程度の関係を構築する

だと感じていて、全てが技術そのものに閉じるわけではなさそうです。

あと決定するにあたっては、自分のサービス的にはとても重要だけども他のサービスにとってはの優先度は異なるケースで、適切に「こういう仕様でないと困りそう」だったり、「こういう仕様をそっちのサービスで検討してないと困ると思うよ」だったり議論をリードしたり検討を促すことも大事そうです。

AはBがやると思っていて、BはAがやると思っていた、など認識の齟齬や浮いてしまっていた仕様にも気づけます。

プロジェクトマネジメント

不確定な要素が多いが期限があるものにどう向き合うべきか？これはこれまでエンジニアが向き合ってきたものの中でも最も手強い課題の1つではないでしょうか。

細かい工夫はいろいろとできるとは思うのですが、とにかくチームが意識して追うべきものと前提が揃ってないときつそうです。

と言いつつこれがまだまだできてなさそう。

アジャイルな感じでJIRAでチケット管理しているのですが、もうちょっといい感じにしたいのはこの辺りです。

  • バーンダウンチャートの残StoryPointが0になる = リリースできてる状態
    • リリースまでに必要なタスクが全てチケットになっている
    • 必要な作業が出てきたら足して見積もる
    • 遅れてると足すことが悪いように自分でも感じてしまうけど必要なものは必要
    • ただそれが過剰でないかは議論の余地があるのでまずはチケットにする
    • 各チケットの粒度が多少違ってもレビューを含む・含まないは最低限揃っている
  • バーンダウンチャートではバージョンのフィルターをかけて増減を追う
  • 「各Sprintにはバージョンに直接貢献しないがやるべき作業（研修や同僚の評価など）がある」のでStoryPointを入れてチケットにする
    • バージョン以外の作業も含むチームのベロシティはスプリントあたりどれだけStoryPointを消化できるかがわかり、次Sprintに積むチケットの量を考える基準になる
  • 厳密にはやらないもののSprintのプランニングで積むチケットはやりきるというコミットでやりきるべき、逆に差し込まれたタスクはやらなくていい or その場で判断しなくていい、差し込まれないように 誰か が守るべき
    • そのために自分はPRレビューを最優先する（Todo -> InReview -> Doneのブロッカーを作らない）
    • Sprint内やまたいで滞留しているチケットに対してアクションをとる
    • 自分が実装タスク持つとほぼその週で終わらん…！
  • StoryPointで各チケットに工数を入れ、便宜的に2StoryPoint = 1人日としているが関心事はあくまでも
    • 1SprintでこなせるStoryPointを最大化すること
    • 1Sprintの平均ベロシティからプランニング時に積めるチケットの妥当なStoryPoint合計を見ること
    • n人いるので2 * 5（営業日） * n = 10n StoryPointには必ずしもならない（なることもある）
    • 相対値であり、大きければ大きいほど不正確・作業内容の変更リスクが大きいのでプライニング時に毎回見直す

前職でアジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~を教えてもらって読んで1度サービスのリリース（直前）までチームリードしたことはあるものの、そのときの経験がまるっと活かせるものでもありませんでした。

ただ言えるのは、これそのものがなんとなく場当たり的にやるのでは身につかない専門性ある技術なのと、バーンダウンチャートのリリース予測がパッと見計算間違いではって思えるようなものでも的確に現実の問題を明らかにしていることです。

「自分が全ての問題を解決しきる」のが目的でも求められていることでもないので、厳しかったり答えが見つけられないなら助けを求め、その結果を全体に還元できるように尽力します。

なかなか痺れる毎日ですが日々闘争し、いいサービス出します。

by ·0件のコメント

このページでは『Goで学ぶAWS Lambda』の正誤表と増補・改訂をお知らせします。

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

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

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

正誤表

PDFページ 誤 正 PDF反映 ePub版反映 MOBI版反映 修正日
22 destBucket = os.Getenv("DEST_BUCKET") destBucket = os.Getenv("UNZIPPED_ARTIFACT_BUCKET") done done done 2018/10/16

増補・改訂

PDFページ 内容 PDF反映 ePub版反映 MOBI版反映 修正日
7 Go1.11.2へのバージョンアップ done done done 2018/11/18
30 利用可能なRuntimeの追加 done done done 2019/04/08
31 RetentionInDaysのリファレンス追加 done done done 2019/04/08
66 DynamoDB localを使ったテストの安定性向上 done done done 2019/04/08
全般 CloudWatch Logs確認にsawコマンドを利用 done done done 2019/04/08
全般 S3へのファイルアップロードにawsコマンドを利用 done done done 2019/04/08

リソース

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販売だけ行って紙本をもっていかないのも嫌です。

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

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

by ·0件のコメント

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

サマリ

  • 技術書典で書ききれなかった章足すぞ
  • GCPのサーバーレスやるぞ
  • 今年もアドベントカレンダーがんばろう

習慣

今年の目標（再掲）

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

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

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

この中で歌系は前回の振り返り時点でやめています。

進捗

本（執筆）: 2冊/年

1/2

前回の振り返り時に技術書典5の申し込みをし、落選も脱落もせず当日を迎えられそうです。

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

終わったらこれはこれで振り返ろうと思います。

もう1冊技術書典関係なく共著で書いたやつもう無理かなぁ…

登壇: 6回/年

4/6

登壇と呼ぶかどうかは置いておいて、XamarinとAzure APIを使ったハンズオンの講師をしてきました。振り返り記事を書こうと思って完全に忘れていました。

副業の一環でした。たしかソースコードは3月くらいに書いたはず。

コードはmacで書いたのですが、参加者たぶんWindowsやろと思ってハンズオン教材をWindows向けに作ったら参加者全員macという大惨事でした。

今回お誘いいただいたkazuyukimiyakeさんに助けていただきました。今後もなにかしら一緒にお仕事させていただきたいです。

なにかしらコードを書く前提 + 喋るみたいなお仕事はいいですね。

ただ、扱う技術は直近の仕事で使うものや近いもの、もしくは仕事関係なくてもついつい触ってしまう領域だと人生的な効率はよいかもと思いました。

あと、時間が余ったとき用に過去の登壇資料を読み直していたのはやっといてよかったです。

今後についてはテーマのところでちょっと考えます。

OSS: 1PR/月

5/3

やらないよりましなものの設定ファイル追加とかハンズオンの手順修正だけして「OSSにコミットした！！」とか言いたくないなぁ。

そういう意味でもServerlessconf Tokyo 2018 Contributor Dayは今後の活動のよいきっかけできればと思っています。

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

4/3

下3つは技術書典向けに書いたものです。現実のユースケースがそれなりに見える形（ほんとに初めて触るサンプル +α的なもの）をコンセプトに書いてるので、1つ1つそこそこ時間がかかっています。いや、そうでもない？

ただ言えるのは「現実にこれ運用するならこういうコード書いた方がいいかも」って思った書いたコードは仕事でもたぶんそういうコード書くと思うし、今の実力（？）こんなもんかという感じです。手を抜かずに書こう。

技術記事: 2記事/月

1/6

何も書いてないな？技術書典の本は技術記事の延長にあると思うけど、その中から細かい粒度で「こうハマったけど、こうしたら解決できた」みたいなの出してけばよかったかもですね。

あと会社では今細かめにドキュメントに残してるので、毎日書いてると言えば書いてる。

もうすぐアドベントカレンダーの季節もやってくるのでテーマ部分で合わせて考えようと思います。

技術書: 30分/日

読んだ

AWSでいう…みたいな感じで予習になりました。仕事用のキャッチアップとしては遠い…

JSのテスト先に書いてるのがんばってますねみたいな感じであんまりサーバーレス！！！みたいなのは覚えてないですね。

一度読んだ気がするのですが技術書典の参考にすべくもう一度読み直しました。

イメージしやすいサンプルのためのサンプル過ぎない具体的なユースケースとGUI操作は行わずとことんコマンドで操作する感じがとてもよかったです。

読んでる

向き合い続けるものとは思いますが、設計が大事な時期なので。

DynamoDB localのDockerイメージとの出会いで覚醒しました。そういうタイミングに学ぶのが一番モチベーションが高く効率がよいので一気に読みたいです。

技術書典の本の最後のユースケースはサーバーレスSPAにしたかったんですができなかったのと、『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』で最後のユースケースでVue.jsが使われていてこれは…！！！って思ったので入門することにしました。

無駄に洋書で読むマン。Safaru Books Onlineのアカウントを得ました。

インプット・アウトプットの質向上には常に取り組むべき。

その他本: 30分/日

別でまとめてるのでそちらで！

カラオケ: 2回/月

声が出なくなったのでやめました。

歌練習: 1回/週

声が出なくなったのでやめました。

品川健康センター: 2回/月

週1で通う習慣が続いています。

走る: 1回/週

品川健康センターで走ってるのでこれも続けられてます。

転職

新しい会社で働き始めてから1ヶ月が経ちました。もう3ヶ月くらいいるような感覚です。

freeeでの闘争を終え、メルペイで闘争します

試用期間大丈夫かなぁ…///などは考える余裕は一瞬もありませんでした。

仕様把握、設計から新たなマイクロサービスを作るというのはまさにやりたかったことで、配属の希望面談どおりです。

はい闘争です。

9月は仕事ではコードを書きませんでしたが、設計もひと段落しとうとうコードを書き始めました。設計も楽しいですが、実装が見えてくると一層楽しい！！

一緒に課題を解決してくれる仲間を探しているので、もしご興味あればご飯でも行きましょう！

merpay Careers

夏休み

転職にあたり、7月末を最終出社として8月はお休みしていました。

前半の記憶があまりないのですが、技術書典のユースケースの実装1つ終わらせた気がします。

後半は新婚 #とは 旅行に行ってきました。結婚したのは一昨年の2年なのでけっこう経ちましたが行けてなかったので。

個人的にずっと行きたかったクロアチア（ドブロブニク、スプリト）、セルビア・モンテネグロ、イタリア（ベネチア）、フランス（モン・サン・ミシェル）に行ってきました。

毎日旅行記を書いていてまだ公開していないので、写真も添えつつちょっとずつ出していこうと思います。

テーマ

直近3ヶ月でいう技術書典的な位置付けでつぎの3ヶ月なにをやるかどうしようかなぁと思っています。

『Goで学ぶAWS Lambda』の続きとVue.js

今回頒布した本の目次は構成要素を考えている段階ではもっと豪勢な感じでした。

少なくとも最終章のURL短縮サービスはサーバーレスSPAにするつもりで、構成要素はつぎのようなものを含むはずでした。

  • 認証・認可（CognitoとかAutn0とか使う）　
  • Vue.js

あとは

  • Lambda上でヘッドレスブラウザ使うユースケース
  • GitHubアサインのSlack通知
  • AWS Serverless Application Repository
  • Kinesisを使うユースケース
  • DLQの設定
  • Alexaスキル系
  • GraphQL（AppSync）
  • SQS（FIFOキュー）のユースケース

GCPのFaaS

Cloud FunctionのGoサポートの申請を待ちつつ…

GCPではまずコンテナやみたいな雰囲気をスルーして本で扱ったようなユースケースを実装してどう違うか触ってみたい気持ちがあります。

GCPのサーバーレス

GCPも最近「サーバーレス」って言い始めたもののAWSやAzureのそれとは何か異なる気がしてその辺を追いたいし、つぎの技術書典のテーマにしたくもあります。

この勉強会とても楽しみです。

GCPUG Shonan vol.32 feat. Serverless & Knative

GCP関係ないけど、Serverless Confで触れたOpenFaaSも近そうで気になります。

Docker/k8s

マネージドサービスでどう扱うかについては仕事上避けて通れないし、GCPのサーバーレスに触れる上では一緒に触れそうです。

アドベントカレンダー

この3ヶ月に技術書典はないので、周囲とワイワイしながらヒーヒー言うイベントは12月のアドベントカレンダーが大きそうです。

去年も相当気合を入れて書きました。

Advent Calendar 4記事の背景にあったテーマ

その結果、問題意識を形にできたり、よい習慣ができたり、書籍の執筆に誘っていただけたりいろいろいい影響がありました。1つのアウトプットの場として今年もなにかしら書こうと思います。

取り組み

一通り並べたところでどう取り組むか迷いますね。アドベントカレンダーの季節にはまた別の興味が生まれているかもしれません。

なにするにしても「これ作ろう」「これ書こう」というアウトプットの形なしに何となく「勉強」を始めるのはとても効率が悪いので、

  • サーバーレスSPA（短縮URL）
  • Lambdaでヘッドレスブラウザ動かすやつ

に実装観点の主軸を置きつつGCPの勉強会でアウトプットの形を探るみたいな感じで行こうと思います。

まとめ

  • 技術書典で書ききれなかった章足すぞ
  • GCPのサーバーレスやるぞ
  • 今年もアドベントカレンダーがんばろう

あ、あとPokemon GO復帰したので友達申請させてください！

by ·0件のコメント

10/8（月/祝日）開催の技術書典5で『Goで学ぶAWS Lambda』という本を出展します。76ページです。

カエルと空というサークル名で場所は「か76」です。

ぜひ遊びに来てください！！

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

本の紹介

Goで実装したAWS Lambdaのユースケースを見ながら開発方法を学んでいく構成になっています。

目次はこんな感じです。

  • 第1章 環境構築
    • anyenv
    • anyenvupdate
    • goenvとGo
    • pyenvとPython
    • aws-cli
    • aws-sam-cli
    • インストールトラブルシューティング
    • direnv
    • dep
    • gig
  • 第2章 S3イベントの活用
    • 概要
    • S3
    • シーケンス
    • フォルダ構成
    • ソースコード
    • テスト
    • デプロイ
    • 削除
  • 第3章 SNSとSQSによるファンアウト
    • 概要
    • SQS
    • SNS
    • シーケンス
    • フォルダ構成
    • ソースコード
    • テスト
    • デプロイ
    • CloudFormationトラブルシューティング
    • 削除
  • 第4章 API GatewayとDynamoDBを使ったURL短縮サービス
    • 概要
    • API Gateway
    • DynamoDB
    • シーケンス
    • フォルダ構成
    • ソースコード
    • テスト
    • LambdaとAPI Gatewayのローカル実行
    • デプロイ
    • DynamoDBのテーブル定義変更
    • 削除

ユースケースは3つです。

3つともSAM(AWS Serverless Application Model)で定義を書いていて、Lambdaはもちろん、関連するAWSのサービスのデプロイはすべてコマンドで完結します。

勢いでシーケンス図も載せてみます。

  • 2章

  • 3章

  • 4章

執筆のモチベーション

Lambda好きや！！！

なんというか、AWS Lambdaがかわいくてしかたがないです。

趣味で触り始め、前職ではC#で書いて本番運用してました。

Rubyがマジョリティな会社でC#を使ってAWS Lambdaの本番運用を開始した話

今のお仕事ではAWSは触らなくなったものの今年に入ってからGoに出会い、Goを書いたら書いたで幸せな気持ちになることができました。

つまり、GoでLambdaを書けばよいのでは？ということで、他の言語に比べたらGoのサンプルも少ないし布教したい！という ~~名目~~ 一心で書いてみることにしました。

ただ、Lambdaの制限はーとか、実行方法はーとか、AWS公式チュートリアルを見ればおしまいなことだけを書いても悲しいのでとにかく実装に寄せることにしました。

よく見るアイコンが並べられたアーキテクチャ　の図を眺めてふんふん言ってるのではなくて実装するのです。自分で手を動かすのです。

SAMなりCloudFormationなりも各リソースのプロパティをYAML・JSONで定義すれば終わりでしょうとは言わず、エラーにハマりまくってInfrastructure as codeを体得するのです。

そんな気持ちで書きました。

勉強になるかは知りません。ちょっとでもこのLambda（とGo）への愛情が伝わり、興味を持ち、触るきっかけを掴む方が増えたら嬉しいです。

「技術」書、単著

技術書3の頃にちょうど前職でXamarinでMacアプリを開発していたこともあり、Xamaritansというサークルの『Extensive Xamarin』の出典・販売に携わりました。そして技術書典4では同サークルの本のレビューにちょこっと携わり、当日売り子をさせてもらいました。

技術書典3で『Extensive Xamarin』という同人誌の出展・販売に携わりました

技術書典3で携わった『Extensive Xamarin』が3月に商業出版されました。そして間近な技術書典4

やっぱ技術書典は！書かないと！！寂しいの！！！

というわけで技術書典5の申し込みが開始されてから秒で申し込みました。

ここ半年の社会生活に鑑み単著で、『Extensive Xamarin』では全然技術書っぽい章にできなくて（他の著者はちゃんとした内容でしたよ）不甲斐なかったので思いっっっ切り実装してから書く前提で。

ルールを調べてまとめただけの記事をもう書いてはいけないの！！！

つまりモチベーションはエンジニアとしての愛と憎しみです。

あと年初目標的には年間執筆数があります。

カエルと空

前々職のCMで一時期カエルを使っていたことから今も惰性でカエルグッズを集めています。

机はカエルでいっぱいです。

蛙（かわず）から連想するものの1つに、「井の中の蛙大海を知らず」という諺があるじゃないですか？

一方で、日本の後付けで「井の中の蛙大海を知らず、されど空の深さ(青さ)を知る」というのもあります。

由来の真偽はどうでもいいです。

自分にカエル属性があるかどうでもいいです。

ただ、思い上がるのも卑下するのも時間の無駄で、自分が見識を深めるべきもの、解決すべきものにひたすら向き合うのだという思いがあります。

その象徴としてカエルと空というサークル名にしました。

今向き合うべきはLambdaではない可能性があります。

現在はBOOTHでも頒布中です。