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

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

家庭

今年も捨てるぞ!

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

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

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

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

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』の振り返りとフィードバックのお願い #技術書典でも書いているとおりアップデートがあるときは商業版とは別にアップデートは続けます。

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

この記事は裏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度サービスのリリース(直前)までチームリードしたことはあるものの、そのときの経験がまるっと活かせるものでもありませんでした。

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

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

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

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

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

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

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

正誤表

PDF PDF、ePub、MOBI版反映 修正日
p22 destBucket = os.Getenv(“DEST_BUCKET”) destBucket = os.Getenv(“UNZIPPED_ARTIFACT_BUCKET”) done 2018/10/16

増補・改訂

リソース

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

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

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

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

謝辞

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

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

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

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

執筆環境として、TechBoosterさんのTechBooster/ReVIEW-Template@atsushienoatsushieno/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販売だけ行って紙本をもっていかないのも嫌です。

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

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

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

サマリ

  • 技術書典で書ききれなかった章足すぞ
  • 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復帰したので友達申請させてください!

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

freeeでの闘争と謝辞

2018年7月末を最終出社日としてfreeeを卒業します。

2015年1月に入社して以来、社内外関係なくいろんな人、コミュニティ、組織にお世話になりました。

freeeには職業エンジニアとしての経験のない僕を受け入れ、特に最初の1年くらいは自分でも引くくらい成長速度が遅かったにも関わらず見放さずに育ててもらいました。

やる気以外何もないところから、よい会社に移ってよい給料がもらえる程度の1人のエンジニアを育てる環境を提供できてそれだけで死ねる

長生きして欲しいですが、こんなこと言って送り出してくれる会社他に無いと思います。言われた後トイレで10分くらい泣いてたのは内緒です。

エンジニアとして育ててもらったのはもちろんなのですが、それ以上に学びが大きかったことがあります。それは愚直に課題に向き合って価値を届けるということとそれに必要なマインド(freeeでは価値基準という)です。

僕はコードを書いたり勉強したりするだけで楽しいし、力がついていってるような錯覚に陥ってしまいます。ただ、その結果として何が解決される?本当にそれは解決されるべき大事なこと?は常に考えないと、何をするにしてもよい流れにならなかったり、求める結果を得るのに膨大な時間がかかったりでうまくいかなかったです。

手段自体楽しいと思える方が人生楽しいとは思いますが、だからこそ一層意味のあるものにしたいという願いのような意味合いでもあります。

エンジニアとしても(働く、あるいは世の中に価値を届ける)人としても大事なことを学ばせてもらったfreeeに出会えて本当によかったし、今でもfreeeが大好きです。

二度と一緒に仕事したくない人もいますが、それですら何を大事に人生を歩んでいきたいかがよりはっきりしたがゆえの反発だし、どういう組織でもきっと出会うはずなので自分自身が向き合う課題です。

そんな状態でもfreeeを去るのは、自分が届けたい価値に向き合った結果です。

これまでfreeeで対峙してきたデータや自分のお金に対する考え方(捕らわれ方)、これまでとこれからのお金が表現するすべきもの、価値の表し方を考えていたときに9月から働くメルペイのビジョンに出会いました。

メルペイが実現しようとしていることはまさに自分が解決に携わりたい思う分野での大きな社会的課題の解決です。

これまで扱ってきた技術スタックとはまた異なりますが、freeeで身につけた課題に向き合う姿勢を忘れずに価値を届けます。

約3年半、本当にありがとうございました。

これは例のリストです。

ふりかえり

新しい開発組織や自分がそんなに触れたことが無い技術になるべく早くキャッチアップできるように、freeeで携わったプロジェクトを出せる範囲でふりかえります。

Web

青色申告承認申請書メール送信サービス

入社3ヶ月目くらいのとき初めて自分メインでリリースしたサービス。今はもう別のサービスが包含してるのでありません。

リリース期限がどうしてもずらせないときは他の変数で調整してなんとかやり切るしかないというのを学びました。

電子証明書連携アプリ(Windows)

対応口座拡大と品質向上

入社7ヶ月くらいのときに電子証明書ログイン対応1行のときにWindowsデスクトップアプリを引き継ぎました。

まだRubyも覚束ない中、C# + Visual Studioに初めて触り対応口座数を増やしていきました。

  • 拡張できる設計とリファクタリング(当時テストは…)
  • 防御的プログラミング(確実なこととそうでないことの切り分けと制御)
  • ログ
  • エラー通知
  • サポートチーム、セールスチームと協力しながら問題解決
  • 優先順位、割り切り
  • 目の前の技術を一歩引いてみる(技術的マイノリティプロジェクトで幸せに過ごすための5つの方法

を身につけました。

当初他のプロジェクトやりながら半稼働、という状態が1年弱あったんですが、社内的に知見があるわけでもなかった技術を身に付けるには思い切って全投入するのが真っ当なやり方だったみたいです。

この会社でC#…みたいな迷いも大きかったですが、何人の方にもアドバイスを頂いた通りまずは自分の目の前の技術をしっかり身につければ応用も効くから頑張れという言葉を信じ頑張ってみました。

あと、技術単体で解決できないときには他のチームの協力を得てできることもあるというのは大きな学びでした。

価値は技術だけでは届きません。

このプロジェクトだったり、得た知見を他の分野にも活かすことで大きな成果に繋がりました。

アプリ + Web UX改善

デスクトップアプリの品質がよくなってきたところで、本来使うと作業が効率化できるはずのユーザーさんに存在や利便性に気づいてもらえなければ意味がありません。

  • 問い合わせ内容分析
  • KPI設定
  • ユーザーさんへのインタビュー
  • サポートチームへのDemoやFAQ共有
  • Webの導線やアプリの使い勝手の改善、リニューアル
  • 保守しやすいコード(しにくいコード)

などを通して、Web上で登録する導線から問い合わせしてくださったユーザーさんに価値が届く(トラブルシューティングを含む)までの全フロー(の中で効果がありそうな順)に対して施策を打ちました。

サポートチームとの知見共有は(もともとの仕様共有が甘ければ)目先のやり取りが減りプロダクトの改善に割ける時間が増えます。駄菓子菓子、その後は問い合わせが減ったとしても

  • サポートチームのメンバーがユーザーさんからの問い合わせに精度高く答えてくれて単にエンジニアまで届く声が減ったのか
  • 「改善」の結果ユーザーさんが離脱してしまっていないか

など目に見える現象だけで判断せず、何か数字がよくなる代わりに他にしわ寄せが及んでいないか、本当に改善したいものは改善できているか、改善そのものの数値化が難しくてもなんとか可視化できないか、その数値が妥当かどうかベンチマーク取れないかなどいくつか考える必要がありました。

プロダクトマネジメントの文脈での「解決すべき課題に向き合う」を実感する日々でした。

この本にとてもとても影響を受けました。

Inspired: 顧客の心を捉える製品の創り方

プロダクトにどういう立場で関わるにしても忘れてはいけない視点として肝に命じています。

あと、改善の過程でフロントに保守しづらいコードを結構足した自覚はあるものの、じゃあどういう設計だったら保守しやすいんだみたいな理想形が全く見えませんでした。

そこからよい設計とは?を考える、学ぶ、意識して書く時間が増えました。

パフォーマンス改善

Windowsアプリといえども、サーバーサイドは他サービスと同じくRailsのサーバーです。

C#を書きつつ、サーバーサイドで必要な修正も行なっていました。

利用してくださるユーザーさんが増えるとAPIサーバーに問題が出て段階的に対応していきました。

非同期化の過程で色々と学びがありました。

  • 時間とコストを考えて段階的に理想的なアーキテクチャに近づけていくやり方もある
  • 問題に対する打ち手を複数考える(※結論ありきの比較にしてはいけないが、自分の推しは持つこと)
  • AWS Lambdaをきっかけにインフラを含めたアーキテクチャ(特にサーバーレスアーキテクチャ)に興味を持った
  • PaaSへの抵抗(食わず嫌い?)が激減
  • OSSヘのコントリビューションのきっかけになった

自分が携わるプロジェクトに対して新しい技術をまるっと(?)導入したこともなかったので大きめの粒度で設計・導入することは考えることが多い分学ぶことはめちゃくちゃ多かったです。

電子申告アプリ(Mac)

すでにリリースしているWindowsアプリのMac版を作って明確な期日までにリリースするプロジェクトです。

Macアプリ開発の知見が社内に無い中、色々なことにチャレンジしました。

Windowsアプリ資産を活用するためにXamarin.Macを採用し、技術検証期間も取りつつチームリードとしてプロジェクトマネジメントするなどです。

  • アジャイル風プロジェクトマネジメント
  • コミュニティから力を借りること、貢献すること
  • CI/CD環境作り
  • ビルド、コンパイル入門

リリースにこぎつけただけでなく、結果的に日本マイクロソフトさんの事例掲載、大型イベント登壇、商業出版(共著)、Microsoft MVP受賞、福岡やシアトル出張などこれまでになかったくさんの機会に恵まれました。

アジャイルはこの本にだいぶ影響を受けました。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アカウントアグリゲーションエンジンのリプレース

2018年はC#を完全に離れ、この記事にある「アカウントアグリゲーションエンジンのリプレース開発」に携わっていました。

Goも利用するプロジェクトで、2週間くらいGoも書く期間はあったものの、だいたいRubyを書いて過ごしました。

かつあまり読み書きできなかったRailsのコードやRspecも昔よりは理解できるようになっていたり、改めて追い直してみると理解できたり最後の最後まで発見が多い毎日でした。

  • 昔読めなかったコードが今も読めないとは限らない
  • データ移行に必要な計画とシミュレーション
  • 防御的プログラミング(困るデータができる前に徹底的に落とす、ロールバック)
  • テストと設計のよい関係(?)
  • インフラ構築やWebアプリのデプロイフロー

この本に出会って設計良くなったかはわかりませんが、Rubyの文脈でpublicメソッドとしてクラスが持つべき責務は何か?を考えることでテストがとても書きやすくなり、テストに助けられたことも何度もありました。

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

あと、個人的にGoに興味をもち、コマンドラインを作ってみたりAPIを書いてみたりもかなり楽しかったです。

コマンドラインを作ってみることでコマンドラインを使うときもどう使って欲しいかちょっと理解が及ぶようになったり、シェルスクリプトが書きやすくなったりいろいろいいことがありました。

教訓

最後に、自分がエンジニアとして働く上で今のところ注意したいなぁと思うポイントをまとめます。

デバッグ環境できるまでが環境構築

  • とりあえず対象のサービスがローカルで実行できるようになった、で環境構築を終えたことにしない
  • コーディングとテストを含むフィードバックサイクルを効率的に回せる状態にすることに最初に一気に投資する
  • 同じ文脈でIDE、エディタの使い方は暗記する、できる(使いこなせる)ことを増やす時間はとり続ける

担当する(マイクロ)サービスは全部追え

  • エントリーポイントへのアクセスからそれが返るまで
  • コードを増やしてからデプロイが終わって稼働するまで(デプロイスクリプトや設定を含む)
  • 依存するライブラリ
  • サービスの基盤の性質
  • どう動くかわかるが意味がわからんならドメイン知識を聞くか調べる

本当に無駄なことはするな

  • 議論のための議論
  • 議論したことは残して立ち帰れる状態にする、前提を必ず書く
  • 登壇のための登壇
  • 2回くらいキー連打したり面倒に感じたことはショートカット覚えたりするために立ち止まる
  • 適度に無駄っぽいことはする、脇道にそれる

思い上がるな

  • 時間を空けて読んだコードが読みやすいと思ったとき、自分が成長してるかもしれないし、自分の知らないところで他の人がいい感じに直してくれたのかもしれない(git blameしろとかそういう話でない)
  • 読みやすいと思って書いたコードもきっとそのうち…
  • 自分が過ごしやすいなと感じたとき、その環境を作ってくれた人がいる
  • いいものは偶然発生するかもしれないけど大体は誰かが作り、そういうものであり続けるように維持してくれている

四半期めどに振り返ろうと思います。

次の四半期のアクションや意識することが出てくるのが理想ですが、最低限年末にこの1年何やってたか思い出すための記録ができてればOKとします。

サマリ

  • 技術書典5とServerlessconf Tokyo 2018がんばろうな
  • 振り返り観点に「失敗」足そうな
  • 「ひとまとまりのソースコード公開: 1リポジトリ/月」この調子で続けていこうな

習慣

今年の目標

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

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

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

この中で歌系はやめることにしました。

進捗

本(執筆): 2冊/年

1冊は自分の担当部分終えて待ちです。もう1冊は10月の技術書典5で書くことにしました。

当落発表は8/1ですが、AWS LambdaとGo言語、サーバーレスアーキテクチャ関連で書きたいことがあるので、仮に落選してもnoteなどで販売する予定です。

当選してもnoteでも販売すればいいですね。

この辺り詳しい方にレビューお願いするかもしれないのでよろしくお願いします。

登壇: 6回/年

3回終わりました。

今年もServerlessconf Tokyo 2018の季節がやってくるので、そこで技術書典5のテーマ関連でお話できたらなぁと思っています。

LT想定ですが、7月でいい感じに進んだらCFP出すのもありではと思ってきました。

サーバーレスアーキテクチャの認証認可のお話。

OSS: 1PR/月

ドキュメントや設定ファイルでわーわー言いたくないですが、設定ファイル1つ足すのも普段使ってるOSSがどういう仕組みで動いてるのか勉強になってよかったです。

その仕組みに思うところがあると、自分が何か書くときのインプットになったりするので続けていきたいです。

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

  • toshi0607/StampCard
    • Xamarin.FormsとDurable Functionsでつくるサーバーレスな承認フローを経由するスタンプカードアプリです。
    • Global Azure Bootcamp 2018のときに作ったやつ。
  • toshi0607/gig
    • generate (or output) .gitignore using github/gitignore
    • Gopher道場期間に作ったコマンド
  • toshi0607/release-tweeter
    • API to tweet the latest release tag version using AWS Lambda(Golang) & API Gateway
    • Gopher道場期間に作ったAPI
  • toshi0607/bookInfoSpreader
    • get book info by ISBN on Google Sheets
    • 会社の書籍管理用。Google Apps Script初めて書きました
  • toshi0607/kakuyasuuu
    • WIP
    • Goでクローラー書いてます

習慣の中で一番重視したいのはこれなので、この3ヶ月の仕事以外の進捗としては悪くないなぁと思っています。

それぞれそんなに大きくないけれど、挑戦したいことや検証したいこと、反省して改善したことが詰まっていてどれも思い入れがあります。

技術記事: 2記事/月

下の2つの記事はこのブログの記事で、ブログではそんなに技術的な話をするつもりなないけどまぁアウトプットはしてるし、特定の技術にも触れてるしよしとします。

Goで書いたコマンド関連でmediumに英語記事投稿しようと思いつつ、そのコマンド完成してなくて書いてもないです。

技術書典の準備の次くらいの優先度でやっていこうかなぁと思います。

  • gig: もう1つオプション足せたら。単に実装すれば終わりという感じでもなくて、pecoと一緒にいい感じに使える実装考えるのが難しくて放置気味
  • release-tweeter: 機能的には完成してるけどGitHubのタグのとり方微妙なのと、AWS Serverless Application Repositoryにのっけたい

技術書: 30分/日

けっこう続いてますね。

4〜6月に読んだ本の整理

読んだ

テストの書き方から変わったし、よい設計したいと思う気持ちと実務の最高の架け橋でした。

この本にも書いている設計の考え方を元にたくさん(考えながら)コードを書いて、実際それがよいコードかフィードバックを受けてよくしていくしかないので人生はじまたという感じです。

大好物でした。サーバーレスアーキテクチャの認証認可を学びたいというのがモチベーションの1つだったのですが、認証認可だけで1章割いているのと、その前の章で章でIAMユーザーとロールについて丁寧に説明されているのが好感度高かったです。

あと、AWSを中心に説明しつつもAuth0やFirebaseなどのFunctional SaaSなどを取り入れていたのが印象的でした。

全体を通してYouTubeのような動画シェアサイトを作る流れになっていてUIも作るんですが、自分がいざ何か作るときにはその部分を今風に作るのが一番苦労しそうな気がしました。

たくさんユースケースのっててかつ関連サービスの設定方法もしっかり説明されてるのでさっとパターンを学びたいときによいと思います。

読んでる

もともと毎朝読んでたのですが、最近は自分のプロダクトのコードなり、会社のサポートツールなり書いてるのでおやすみ気味。

Gopher道場期間中になんとなく手に取ったのがきっかけでした。

Goの標準パッケージの読みやすさからちょっとずつレイヤー低めのところまで読んでみる習慣ができつつあったのですが、この本を読むと個々の処理同士の繋がりが見えやすくなってきた感があります。

例えば、TCPやソケットを意識して書かれたサーバーとクライアントではこれまで個人的にあまりメソッド名としてしっくりきていなかったListenだったり、Acceptだったりの意味合いが把握できるようになってきました。

情報処理の試験でなんとなく聞いたことがあった言葉と実装が繋がり始めた感覚です。

尊い本なので引き続き読んでいきます。

その他本: 30分/日

読んだ

この本を読んだ2〜3日後に爆誕したのがtoshi0607/gigですw

基本的にうだうだ言ってないでとっととやれ、しか書いてないので、うだうだ言ってないでとっととやる気持ちになれます。

前職で営業してモヤモヤしてるときにもゼロ―――なにもない自分に小さなイチを足していくを読んで影響を受けた記憶があります。

何を書いてあったかは何も覚えてないですがたぶんどっかに書き残してるはず…

20代でもっとも影響を受けた本の1つになりました。

他者からの注目と言う貨幣換算が難しい価値を好きなタイミングで人脈、金、情報という別の価値に転換できる。ネットの普及で自分の価値をどんな方法で保存しておくか選べるようになってきた

昨今、これまでのお金による価値把握(交換・保存・尺度)も変わりつつあります。

その流れの中でお金の流れはどうあるべきかだったり、それをどう活用するかだったり、自分はどう関わっていくべきかだったり考えるのはとても楽しかったです。

この話は近々改めて記事を書く予定です。

なんでだと思います?漫画要素はタイトルの字面ほど強くないですが面白そうと思って読んでみたら面白かったです。

ただ、人間認知によって商品そのものの価値と関係ないところに左右されるのは事実なんだとしても、本質的に価値あるものを作って届けたいなぁと強く思いました。

ザ・ゴール コミック版を読んで以来、有名な(できれば再現性のある理論に基づいた)本から自分の行動を変える程度の影響を受けるのに別に文字の羅列はいらないし、たかだか1つ実行に移せればラッキーと思うようになりマンガでわかる系の本も読むようになりました。

が、この本を読んでピンときたことは特になかったです。

飯要素強いときの方が好きでしたね。けどきっと新巻出たらまた買うんだと思います。

読んでる

どういうきっかけかまったく覚えてないのですが、功利主義に影響を受けた時期があり久々にJ.S.ミル氏読もうと思って読んでます。

高校のとき隔週の学年新聞にずっと(受験勉強中も…!)連載していてその中で自由私論()とかいう記事を書いたことがあったりしたので、今書いたら何書くんだろうとか考えるのも楽しいです。

世界史の勉強するとき、テーマ史の話の流れ追うのすごい楽しかったものの覚えられなくて論述爆死した記憶しかないですが、今特に興味ある分野を読んでみるとどうなるんだろうと思って読んでみたらしんどい。

一定の時期・地域の流れを追ったあとに同一時期・別地域の流れを追うというのが全然できない。

覚える必要あるのかと言われたらそんなことはないですが、覚えてるからこそ脳みその中で浮き彫りにできることもある気がしているし、覚えるほど反復するからこそ何か気づいたのかもしれないし、その辺の向き合いかたは未だにようわからんです。

仕事ではそんなことも言ってられないので、一度に扱うこと絞るなり分担するなり生き方を模索しています。

カラオケ: 2回/月

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

歌練習: 1回/週

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

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

週1で通う習慣ができました。プロテインもはじめました。

走る: 1回/週

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

テーマ

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

とは書いたものの、明らかにサーバーレスアーキテクチャとGo言語に振ってる感がありますね。

ただ、それらの技術自体というよりもそれらを通じてよい設計を考えるだったり、もうちょっとレイヤーを掘り下げて実装したいだったりが主要な感心です。

最近はSQSがLambdaのイベントソースに指定できるようになったのにテンションが上がりました。

AWS Lambda Adds Amazon Simple Queue Service to Supported Event Sources

発表当日に早速aws/aws-lambda-goなりaws/aws-lambda-dotnetにPR出すかと思ったところアナウンス前後にはもう対応されていました。

イベントソースから送られてくるjsonをパースするための構造体なりクラスなりは比較的にPRが送りやすい一方で、公式ページに掲載されているjsonサンプルでは必ずと言っていいほどサンプルでは網羅できずパースこける的なissueが上がっている部分でもありました。

PRの機会が減るのは残念ですが、今回みたいな誰もが待ってました!みたいなものに関しては中の人が足してくれるのがよいなぁと思った次第です。

「よい設計をしたい」と思ったときに、クラス設計に止まることはないと思いますし、サーバーレスアーキテクチャとしてサービスを切り出すタイミングで担うべき責務を考えざるを得ません。

サーバーレスアーキテクチャを考える中でLambdaのようなFaaSだけではなく、その文脈の外でよく使うPaaSに触れることで日常業務にもよい影響があります。

今は一エンジニアとしての関心と、趣味(純粋にサーバーレスアーキテクチャなりGo言語なりは触れていて楽しい)と、業務的関心の交点にいる感んじがしてとても楽しいです。

まとめ

振り返り記事を書いてよかったかどうかと言うと、よかったかなぁと思います。

技術書典申し込もうと思いつつ申し込んでなくて、技術書典に触れる部分を書きながらサークル申し込みしました。

本とかも読み終わって全部の本で反芻してるわけではない(お金2.0はけっこうハイライトした部分読み直した)ので、その本の位置づけなり、次どうしたいと思ったのかなり考える時間をちょっととるだけでも、読書に費やした自分の時間の自分にとっての価値は上がるように感じました。

習慣の枠には書いてないですが、同僚とランチしたときに「最近ちゃんと失敗してる?」的な話題が上がって大事な振り返り観点な気がしました。

誰も失敗したくて失敗するわけではないし、当然失敗すること自体に目標を置くことはないです。(得られるものが増えるわけでもないのに)敢えて失敗する手法を選択することもないです。

万全の体制で臨んでも失敗するような、それまでの自分の枠を超えた不確実なイベントに向き合っているか?そこから次の一歩のために何をしたのか?という観点は選択や振り返りを行う上で大事っぽいということです。

記憶に残ってる範囲ではあるけど書けないので次に活かします。

この3ヶ月はお金2.0とGopher道場に受けた影響がとても大きかったように思います。

Gopher道場期間の振り返りはこちら

Gopher道場♯1でメルペイさんにお世話になりました #gopherdojo

そんなこんなで6月にとうとう30才になり、いろいろと環境が変化していきそうです。

そっと例のリストを置いてみます。

https://www.amazon.co.jp/hz/wishlist/ls/355R1ZKLIIDFM

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