今年はAdvent Calendarを4本書きました。

記事の内容自体を勉強したり広めたいというよりも、テーマの部分に自分のエンジニアとしてのあり方をこう変えていきたいという思いを込めていたのでその辺りをまとめることにしました。

概要

テーマ(ブログ内リンク) 記事タイトル Advent Calendar
OSS、ドキュメントじゃなくてコードでコミットしたい! CloudWatch Logsに書き込まれた内容をSlackとGoogle Homeで通知するAWS Lambda using dotnet AWS Lambda Advent Calendar 2017
ライブラリ、使い方のお勉強ばっかりしてないで自分でビルドして追いたい! XAMLの基本(Xamarin公式XAMLページ全訳)と基礎の入り口 Xamarin その1 Advent Calendar 2017
導入からリリースまで自力でやり抜きたい! Rubyがマジョリティな会社でC#を使ってAWS Lambdaの本番運用を開始した話 freee developers Advent Calendar 2017
エディターにも学習時間もっと割きたい! VS Code上でHTTPリクエストを送信し、VS Code上でレスポンスを確認できる「REST Client」拡張の紹介 Visual Studio Code Advent Calendar 2017

本題

OSS、ドキュメントじゃなくてコードでコミットしたい!

CloudWatch Logsに書き込まれた内容をSlackとGoogle Homeで通知するAWS Lambda using dotnet @ AWS Lambda Advent Calendar 2017

11月に会社のOSS Fridayという取り組みで、Microsoftの公式リポジトリに出したプルリクエスト(以下PR)がマージされました。

freeeのOpen Source FridayでMicrosoft公式リポジトリに出したPRがマージされて嬉しかったけど、ドキュメント翻訳で微妙にモニョるおはなし

ただ、それはチュートリアルの全訳でした。自分が必要だからやっているとはいえ、エンジニアならコードでコミットしたいなぁというのが正直な感想でした。

そこで、12月のOSS Fridayではアドベントカレンダー記事のようなコードを公開するのを世間体対策とし、なんとしてもこのリポジトリに自分が書いたコードをぶっ込むことを真の目標にしていました。

aws/aws-lambda-dotnet

AWS Lambda の.NET Core実装です。

自分がリポジトリに対して出す予定のPRに含める予定のコードをとりあえずは自分が公開するコードでユースケースとして妥当で実際に動作することを確認しました。

アドベントカレンダー記事にコードも掲載しています。

そして送ったPRがこちら。

add cloudwatch logs event #188

自力では何も実装してないに等しいですが、足りてないかつ自分が足せそうな部分がわかる程度ライブラリの実装を読んで、マージされるまでやりとりなり修正なりするのは今後もやっていきたいです。

最終的に本家に別途足されたデータのデコード部分(アドベントカレンダー記事に書いてる)や、PRの方向性が間違ってなかったら足そうと思っていたテストも足すべきなのはちょっと考えたらわかる話だったなぁという反省はあります。

実際に公式のライブラリから自分が足した部分がダウンロードでき、自分のプロジェクトで置き換えて見るのは思った以上に嬉しかったです。

CloudWatch Logs用のクラスに差し替える #3

今は特にserverless/serverlessAzure/azure-functions-durable-extensionに興味があるので、その辺りで何かやっていきたいです。

ライブラリ、使い方のお勉強ばっかりしてないで自分でビルドして追いたい!

XAMLの基本(Xamarin公式XAMLページ全訳)と基礎の入り口 @ Xamarin その1 Advent Calendar 2017

今年は「ライブラリ製作者」「ライブラリ利用者」という対立構造?が印象的でした。

僕は多くの人が利用するライブラリを作っているわけでも作れるわけでもないです。

しかし、「ライブラリ利用者」であってもライブラリの設計を理解し、足りなければ足し、「基礎」から理解しないと単なる消費者だし、それは嫌だなぁと思いました。

そして、そうかそういう原理で動いてるのかみたいなの追うのは楽しいです。

これはOSSへのコミットでも強く意識していたことですし、XAMLの記事でも同じスタンスです。

最近読んでいるSOFT SKILLS ソフトウェア開発者の人生マニュアルを読んで思うのは、技術の身につけ方のフォームを持ちたいなぁということです。

技術書を買ったら最初から最後までじっくり読みたくなってしまう派ですが、実現したいことベースで学習スコープを決め、技術書であれ何であれ学習リソースを確保し、試行環境が構築できて実現したいことに対する最低限の情報が揃ったら手を動かして実験したり、コード書いて公開したり、よりアウトプットに時間かけたいです。

来年は副業もしようと思っているので、自分に足りない技術を身につける速度を上げて、本業にもプラスになったみたいな流れを作ります。

導入からリリースまで自力でやり抜きたい!

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

自分のする仕事の大半は既存システムのメンテナンスだったり、機能追加やUI改善と言ってもやはり既存のシステムの枠組みの中での作業だったりです。

そんな中でもう少し解決したい課題に対して設計し、実装し、解決するという一連の流れを運用も考慮し「システムを構築」したいです。

そのためにちっさくてもいいので、「プロジェクトの追加」みたいな部分からCI/CD(CIサービスでボタンクリックしてビルド・デプロイできればいい)まで一気通貫でやりきるみたいな経験ができたというのが結果的にアドベントカレンダーの記事になりました。

※人の手を借りていないという意味ではないです

仕事に限らず、アウトプットは記事自体を目的にせず、何かしらサービスやライブラリを落としどころにしてその過程を技術記事でも出すくらいのスタンスにします。

エディターにも学習時間もっと割きたい!

VS Code上でHTTPリクエストを送信し、VS Code上でレスポンスを確認できる「REST Client」拡張の紹介 @ Visual Studio Code Advent Calendar 2017

これは新装版 達人プログラマー 職人から名匠への道に影響を受けています。

職人たるもの道具こだわってなんぼ的なやつです。

非効率と思いつつも無駄にキー連打で解決みたいなことやりがちなので、ショートカット覚えるなり、特定のユースケースのためのツール使いこなせるようになるだったりの意識が強まりました。

アドベントカレンダーの記事も、「便利な機能あったですごいやんな?」的なものではなくて、使いこなせるようになるために公式ドキュメント読み込んだ際の副産物という位置づけです。

まとめ

今年もやっとしてたいろいろなことを次に進めるための一歩がそれぞれ踏み出せてよかったです。

今年はまだ残っているとは言え、もう少し広い範囲で振り返ったり、来年のための準備に時間を割こうと思います。