Shares転職して1年が経ちました。Shares転職して3年が経ちました。Lambdaの開発フローの違い」を話してきました。Calendarを4本書きました。記事の内容自体を勉強したり広めたいというよりも、テーマの部分に自分のエンジニアとしてのあり方をこう変えていきたいという思いを込めていたのでその辺りをまとめることにしました。Fridayという取り組みで、Microsoftの公式リポジトリに出したプルリクエスト(以下PR)がマージされました。FridayでMicrosoft公式リポジトリに出したPRがマージされて嬉しかったけど、ドキュメント翻訳で微妙にモニョるおはなしただ、それはチュートリアルの全訳でした。自分が必要だからやっているとはいえ、エンジニアならコードでコミットしたいなぁというのが正直な感想でした。Fridayではアドベントカレンダー記事のようなコードを公開するのを世間体対策とし、なんとしてもこのリポジトリに自分が書いたコードをぶっ込むことを真の目標にしていました。自分がリポジトリに対して出す予定のPRに含める予定のコードをとりあえずは自分が公開するコードでユースケースとして妥当で実際に動作することを確認しました。アドベントカレンダー記事にコードも掲載しています。#188自力では何も実装してないに等しいですが、足りてないかつ自分が足せそうな部分がわかる程度ライブラリの実装を読んで、マージされるまでやりとりなり修正なりするのは今後もやっていきたいです。最終的に本家に別途足されたデータのデコード部分(アドベントカレンダー記事に書いてる)や、PRの方向性が間違ってなかったら足そうと思っていたテストも足すべきなのはちょっと考えたらわかる話だったなぁという反省はあります。実際に公式のライブラリから自分が足した部分がダウンロードでき、自分のプロジェクトで置き換えて見るのは思った以上に嬉しかったです。#3今は特にserverless/serverlessやAzure/azure-functions-durable-extensionに興味があるので、その辺りで何かやっていきたいです。2017今年は「ライブラリ製作者」「ライブラリ利用者」という対立構造?が印象的でした。僕は多くの人が利用するライブラリを作っているわけでも作れるわけでもないです。「ライブラリ利用者」であってもライブラリの設計を理解し、足りなければ足し、「基礎」から理解しないと単なる消費者だし、それは嫌だなぁと思いました。いう原理で動いてるのかみたいなの追うのは楽しいです。これはOSSへのコミットでも強く意識していたことですし、XAMLの記事でも同じスタンスです。読んで思うのは、技術の身につけ方のフォームを持ちたいなぁということです。技術書を買ったら最初から最後までじっくり読みたくなってしまう派ですが、実現したいことベースで学習スコープを決め、技術書であれ何であれ学習リソースを確保し、試行環境が構築できて実現したいことに対する最低限の情報が揃ったら手を動かして実験したり、コード書いて公開したり、よりアウトプットに時間かけたいです。来年は副業もしようと思っているので、自分に足りない技術を身につける速度を上げて、本業にもプラスになったみたいな流れを作ります。2017自分のする仕事の大半は既存システムのメンテナンスだったり、機能追加やUI改善と言ってもやはり既存のシステムの枠組みの中での作業だったりです。そんな中でもう少し解決したい課題に対して設計し、実装し、解決するという一連の流れを運用も考慮し「システムを構築」したいです。そのためにちっさくてもいいので、「プロジェクトの追加」みたいな部分からCI/CD(CIサービスでボタンクリックしてビルド・デプロイできればいい)まで一気通貫でやりきるみたいな経験ができたというのが結果的にアドベントカレンダーの記事になりました。※人の手を借りていないという意味ではないです仕事に限らず、アウトプットは記事自体を目的にせず、何かしらサービスやライブラリを落としどころにしてその過程を技術記事でも出すくらいのスタンスにします。職人たるもの道具こだわってなんぼ的なやつです。非効率と思いつつも無駄にキー連打で解決みたいなことやりがちなので、ショートカット覚えるなり、特定のユースケースのためのツール使いこなせるようになるだったりの意識が強まりました。アドベントカレンダーの記事も、「便利な機能あったですごいやんな?」的なものではなくて、使いこなせるようになるために公式ドキュメント読み込んだ際の副産物という位置づけです。まとめ今年もやっとしてたいろいろなことを次に進めるための一歩がそれぞれ踏み出せてよかったです。今年はまだ残っているとは言え、もう少し広い範囲で振り返ったり、来年のための準備に時間を割こうと思います。miniOrange。