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

ちょっと前の話になりますが、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で販売するぞ!