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/

by ·0件のコメント

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

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

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

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

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

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

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

謝辞

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

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

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

振り返り

Good

テーマ

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

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

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

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

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

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

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

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

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

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

BOOTH事前販売

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

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

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

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

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

うれしい感想

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

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

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

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

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

本のタイトル

お気に入りです。

Serverless meetupを諦めなかったこと

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

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

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

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

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

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

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

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

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

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

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

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

謎の試み

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

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

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

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

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

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

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

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

Challenge

うやむやにしていること

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

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

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

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

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

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

OGP画像

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

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

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

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

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

コミュニケーションパス

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

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

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

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

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

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

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

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

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

新刊の部数

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

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

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

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

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

査読

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

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

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

Knativeの動向

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

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

今後

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

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

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

数字の整理

売上

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

-> 217,000円

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

かんたん後払いは 81/166（100 + 50 + 16）でした。半分くらい！

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

原価

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

-> 54,190円

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

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

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

大丈夫そう！

被チェック数

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

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

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

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

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

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

まとめ

技術書典好き！！！

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 ·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でも頒布中です。

by ·0件のコメント

ちょっと前の話になりますが、4月〜5月にかけてメルペイさん主催のGopher道場#1に参加し、2回LTしました。

業務で1〜2週間Go言語を触ったときのなんとも言えない幸福な日々がきっかけでGoもっと書きたい学びたいと思い参加することにしました。

※Go触ってない他の日々が幸福でないとは言ってない

講義を聴き、次の講義が期限（？）の宿題を解きながら、うんうん完全に理解したと思っていたことがいざ手を動かしてみると理解できてないことを実感する、というのを繰り返しました。

Goで作り直すgitignore生成コマンド

宿題は指定仕様のCLIやサーバーを書くものもあれば、hogehoge interfaceの意義など説明する系のものもありました。

その中でio.Writerを調べていると、自分もそれ使って書きたいという気持ちが高まり書いたのがこちらです。

toshi0607/gig

generate (or output) .gitignore using github/gitignore

.gitignoreを生成するためのコマンドです。

Usage:
  gig [OPTIONS] [Language]

Application Options:
  -l, --list      Show list of available language
  -f, --File      Output .gitignore file
  -q, --quiet     Hide stdout
  -v, --version   Show version

Help Options:
  -h, --help      Show this help message

もともとgiboというシェルスクリプトベースのコマンドがあったのですが、

  • git cloneベースでなくて、毎回最新のファイルをgithub/gitignoreから取得したい
  • コマンド書いたことない（Gopher道場の選考課題で初めて書いた）のでGoで一から書いて配布するところまでやってみたい
  • io.Writer interfaceを活用した柔軟な出力差し替えを体験したい

という動機のもとで書きました。

まだ機能比較でもgiboに追いついてないのはありますが、どちらかというとｼｭｯとリリースするためのスクリプトを準備する方が時間がかかった気がします。

https://github.com/toshi0607/gig/tree/master/scripts

このあたりの組み合わせです。

Gopher道場の最終回でLTする時間をいただけたのでお話してきました。

Goのinterfaceを使って外部サービスに依存しないテストを書く

AWS Lambdaが好きなので、今度は何かAPI書いてみようということで書きました。

toshi0607/release-tweeter

API to tweet the latest release tag version using AWS Lambda(Golang) & API Gateway

コマンドをアップデートするときに、そのコマンドのGitHubリポジトリの最新タグを拾ってきてtwitterに投稿してくれると楽だなぁと。

いかにも既存の何かしらだったり、連携機能やサービスで実現されてそうですがその辺は気にせず…

テーマはAWS Lambda使うという大前提がありつつも、

  • API GatewayとAWS Lambdaをローカル実行する
  • SAMのCLI使ってデプロイしてみる
  • direnv使ってみる
  • 外部サービスに依存する部分はモックしてテスト書く

というのを試してみたかったのでそうしました。

その最後の1つについてGopher道場#1 LT大会でお話してきました。

このLTについてはつぎのようなツッコミをいただいてます。

  • 「差し替えたい対象が複数になったら困る」が正しいのであれば、関数使うのがアンチパターンになってしまい、全部interfaceにすればいいよね？ってなる
  • 処理の差し替えであれば関数でいいし、抽象として扱いたいのであればinterfaceにすればいい

処理の差し替えであれば関数でいいし、抽象として扱いたいのであればinterfaceにすればいい、大賛成です。

差し替え対象が複数になっても困りはしないと思いますが、もし差し替えたい処理が増えてバラバラ1つずつ入れ替えないといけない状況になったら依存するサービスごとinterfaceで抽象化してしまった方が見通しいいかもくらいのテンションで当日はお話していました。

ただ、タイトルを「結論」としてinterface使わない方法はよくないみたいな資料の流れになっているのは間違いないので、資料単体で見返したときにも誤解を生まないかという観点でも見直すなり、資料に表現しきれない部分も記事にするなり改善方法はあるなぁと反省しています。

コメントいただけるのはとても嬉しいです。

振り返り

コードを書く

Gopher道場の影響を大きく受け、これも作りたいあれも作りたいみたいな思いが沸くことが増え（？）GitHubの緑化が進みました。

READMEしか直してないみたいな日もありますが、「作りたい！」ありきでその中で試したいこと、テーマがあるくらいのテンションだと愛着も増すし、手も動くのでいい感じです。

コードを読む

（すでにあるかどうかを度外視して）そのとき作りたいものを作ると大体選考実装や要素技術の実装例はGitHubに転がっているので、個人開発の文脈で人のコードを意識的に読む時間が増えた気がします。

これまではtwitterなどで流れてきた人気リポジトリをなんとなくたどることが多かったですが、自分が知りたいことを探しながら追うと吸収度や感情の振れ幅が変わりました。

発信する

これまでMicrosoft系のコミュニティでしか話したことがなかったので、今年はその外で話すというのが隠れ目標でした。
https://speakerdeck.com/toshi0607

発信する内容としては自分が初めて対外LTしたときみたいに特定技術（サービス）の使い方をなぞる系はやりたくないと思っています。

やるメリットももちろんあると思いますが、技術力をつけるという観点では

  • 何かしらの課題を解決すること
  • 何かをテーマに作りきること

を最重視すべきと思っていて、その過程自体や困ったこと、うまくいったことの言語化・発表を通じより前進できると考えます。

5月に行った2つのLTはたとえ入門レベルの内容であったとしても、信念は貫いたのでよい経験をさせていただいたなぁと思っています。

次はgolang.tokyoで発表できるか？と言われたらとてもハードルを感じているのが正直なところなので作りたいもの作るなり、解決したい課題を解決するなり積み重ねていこうと思います。

次

「こんなことやりたいと思っている」を書くと、書いたことで満足してしまう節がなくはないですが追い込めもするので書いてみようと思います。

Serverlessconf Tokyo 2018

去年参加してとても楽しかったので今年も参加しようと思っています。

ただ、今年はLTしたいなぁと。

CFP受付中ですが、それは尻込みしています…

サーバーレスなアーキテクチャの認証・認可どうやればええねんって思っていて、追っかけてると楽しくなってきたのでその辺の話をする予定です。

もちろんサンプルコードはGoで！

技術書典

前回はレビューと当日の売り子だけ参加で多少寂しかったので、今度はしっかり書きたいなぁと思っています。

技術書典3の『Extensive Xamarin』は強い方々におんぶに抱っこ感がすごかったので、今度はサーバーレスシングルページアプリケーションチュートリアル的な感じで丸っと自分の力で書いてみたい！

rejectされてもnoteで販売するぞ！