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

2017/4/21のGlobal Azure Bootcamp 2018@Tokyoでお話してきました。

発表に使用したスライドはこちらです。

テーマ選定

スタンプカードアプリ作りたかった

妻が筋トレ(?)か何かをするにあたり、スタンプカードアプリ(別にアプリである必要はなかった)がほしい、スタンプはできれば猫がいい、みたいなことを言ってたのがきっかけの1つです。

※継続的に筋トレする習慣を作るのに必要なのは本当にスタンプカードなのかどうかはわからない

Durable FunctionのHuman Interactionパターン実装したかった

去年のServerless ConfかなにかでAzure Functionsの拡張機能であるDurable Fuctionsを知り、興味を持ちました。

中でもパターン #5: 人による操作に謎のロマンを感じ実装してみたくなりました。

一定以上のまとまりがあるコードが書きたかった

LTなり、何か記事を書くなり、技術系のアウトプットをするには技術的なインプットが必要と思っていますが、インプットの質を上げるためにももうちょっとアウトプットせねばという思いがありました。

しょうもなくてもいいからGitHubにひとまとまりのソースコードを上げられるだけコードを書くというのが今年の方針です。

振り返り

スライドでは主にコードについて書いてますが、もうちょっと取り組み全体寄りの振り返りです。

Good

  • クライアントもサーバもコードを書いてGitHubに上げたこと
  • 期待した動作をするアプリができたこと
  • Azure FunctionはHTTP Triggerを1回触る程度でよくわかってなかったけど、全体的なお作法をざっと見た上でDurable Fucntionsのキャッチアップに入れたこと
  • Durable Fucntionsの実行の仕組みもなんとなく把握できる程度にデバッグ実行したりストレージの中身のぞいたり研究できたこと
  • PaaSの組み合わせ方にもデザインパターンがあり、実装するからこそそのありがたみを感じられることを実感できたこと

Challenge

  • 声出すの、歌とかでなくてもほんとに音にならなくてつらい
  • 全部喋らんけど資料になるから資料厚くしよう、そして喋るときはいろいろ飛ばそう、はまだ自分には早そう
    • (練習した後)ギリギリまで資料を変えて本番に臨むとわりと混乱して大事などころだけ絞って喋るって緊張してると難しい。今回は資料アップロードした後もここ表現こうした方がいいとか、順番はやっぱこういう方がいいとか10回くらい直してアップロードし直した
  • 実装的にあれも足りないこれも足りないとウジウジしてないで学びたいことを学ぶためのサンプルと割り切ること
    • 足りないと思う部分はissueとかで残しとくともっと深めようとか現実的に稼働させたいとか思ったときに役立つかも
  • 一方で個人的に本番運用するプロダクトがあってもよいなぁ
    • クラウドリソースの認証・認可さすがにザルすぎる
  • ログの追い方は「とりあえずサンプル1つ動いた」の次の段階くらいで意識的に時間とって把握するのがよさそう
    • 今回くらいの規模のサンプルでも途中デプロイすることがあったり、単にブレークポイントはる以外にログきちんと追いたい局面が多々あった
  • Azure FunctionsがV1ベース
    • V2でやろうとするとnugetからのインストールからうまくいかなくて、古めのバージョンでうまくいく組みわせでやり過ごしてしまった感
  • 実行の仕組みの研究とか言うわりに「どう実装されているか」をコード見ながら考えてない。動きからテキトー想像する「だけ」は研究とは言わない
  • UI苦手やぁ
    • よくあるアプリのパーツ実装してみるとか、作りたいと思ってるものに沿った形で取り入れてみるのはやった方が表現の幅が広がっていきそう

まとめ

総じて取り組んでよかったなぁと思います。

需要があるかはおいておいて、今回のスライドでも20分くらいじっくり喋りたかった内容だったりするので機会があればリベンジしたいなぁと思いました。

あと、今回みたいなアーキテクチャでデータの整合性はどうすると保てるのかだったり、クラウドアーキテクチャの原則は何なのかだったり、もっと踏み込んで学んだら楽しそうな分野に出会えてよかったです。

クラス設計もデザインパターンからでなく、その前提となる原則やそれを実現するための具体的なコード(の変化)を追うととても実感がわきました。

今ではクラウド設計の原則的なことも整理が進んでいると思うので、追ってけたらなぁと思いました。

勉強会ではこのセッションが特に印象的でした。

技術書典3

以前このブログでも紹介した、技術書典3で出展・販売に携わった『Extensive Xamarin』という技術同人誌が3月に商業出版されました。

『Essential Xamarin』同様インプレスさんのNextPublishingからです。

Extensive Xamarin ─ひろがるXamarinの世界─ Essential Xamarinシリーズ

Essential Xamarin ネイティブからクロスプラットフォームまで モバイル.NETの世界

会社でも同僚が紹介記事書いてくれたのすごいうれしかったなぁ...
弊社エンジニアが共著で参加した Xamarin の技術書が発売されます

Aamazonで自分の名前を検索したら本が出てくる一定の感慨深さはありますが、『Essential Xamarin』がとても好きですし、この本の商業出版化様々という気持ちです。

あとは以前の記事のとおり、「いつか書けたらいいなぁ、で逃げなくてほんとによかったです。」がすべてで、技術書典3は去年一番の思い出かもしれないということに尽きます。

技術書典3で『Extensive Xamarin』という同人誌の出展・販売に携わりました

技術書典4

自分では何も書いていないですが、一足先に読ませていただいたこともあり、当日は新刊の売り子をやります。

新刊の内容はMonoDevelopとXamarin.iOSについてです。

MonoDevelop

以前仕事でもVisual Studio for Macを使っていたにもかかわらずOSS的な部分とプロプラエタリな部分でどういう風に構成されているのか、自分で拡張するためにはどうすればいいのかの手がかりが掴める内容になっていて感動しました。

ただ、MonoDevelopに限らずIDEやそれに準ずるものがどういう取り決めで本体とデバッガ間で通信するのかなど他のIDEでも共通して考えれるヒントが惜しげも無く散りばめられている貴重な内容になっています。

Xamarin.iOS

なんとなく書いていたらハマるだろう(ハマっていることにすら気づけない自分みたいなパターンもけっこうありそう)現象の原因と対策がサンプルコードとともに丁寧にまとめられています。

ネイティヴなコードをXamarinでラップすることでどう表現が変わるのか、.NETな表現をするためにXamarinが何をやっているのかの解説はただただ鮮やかです。

どっちもほんとにすごいんです!!(こなみ)

えのもとさんの記事
技術書典4新刊によせて

区切りなので3ヶ月分くらいゆるめに振り返ります。

副業

開業届を出してから3ヶ月が経ちました。

開業freeeで10分でパラレルキャリアをはじめました

いくらかお声がけいただき、土日はもっぱら取り組んでいます。

  • 本執筆
  • ハンズオンの素材作り

共著なので、担当部分を書くというものです。

今年は2冊にかかわるという目標ですが、書きたいと思ってもタイミングよく書けるものではないと思うので話があればなんとか都合をつけたいですね。

ただ、1〜2章書くだけでも最低2ヶ月(の土日)は時間がかかります。そのため、つぎのことは覚悟なり検討なりして臨みたいなぁという思いを強めました。

内容

現時点でめちゃくちゃ詳しい分野はないので、書き終えたときに身についているはずの内容に詳しくなりたいか?はよく考えたいです。

ちなみに今回の内容(のうちデバッガ関連)はさっそく開発に活きています。

書くことに決めた当初章立ても普段よくつかう部分しか思い浮かびませんでしたが、書くなかで俯瞰できてとても勉強になりました。

モチベーション

書き始めたらそれなりに時間はかかるはずなので、数章なら2〜半年くらいモチベーションを保てるのか、仮にとても詳しくて高速に仕上げられるならその期間もつのかは考えたいです。

特に期限が決まっていなかったり、共著だったりする場合、他のメンバーより早く書き上がったときに出版までの間原稿をアップデートし続けられるだけの思い入れなり、技術との接点があるのかだったりは大事なポイントではないかなぁと思います。

期間

僕の場合、執筆期間は他のことに手が回らなくなってしまいます。

それは他の仕事(副業)を受けられなかったり、新しく興味をもったことを全力でキャッチアップする時間がとれなかったりするかもしれないということです。

とか言ってるときっと単著は書けないので、付き合い方はうまくしていかなくてはと思っています。

3つに分けたものの、結局その技術に詳しくなりたいかどうかが大きそうですね。

ハンズオン

まだハンズオン自体は先なので素材作り段階での話です。

僕の弱点の1つは気づいたらインプットに偏ってわかった気になり、実際手が動かないという点です。

人によって違うかもですが、僕の場合はまずテーマになる技術でひととおり動くものを作ってしまってから手順書作りに入ります。

そのため、なにはともあれひととおり動くものを短期間でつくるので、否が応でもアウトプットします。

そして、

  • はまりそうなポイント
  • アップデートに影響を受けそうなポイント
  • 環境によって手順が違いそうで、検証が必要なポイント

などなど整理しながらドキュメントを作ります。

これも詳しくなりたい素材をひととおり手を動かしながら深められるので楽しいですね!

まだ募集等始まっていないですが、公開するタイミングで告知するのでよろしくお願いします。

開発

実案件に加わる話は調整中です。

副業をはじめた理由はこの記事でも触れたようにエンジニアとして強くなりたいのが一番大きいので、うまく軌道に乗せられたらなぁと思います。

いろいろな仕事でそれぞれのよさがあり、どれも捨てがたいですが、実戦・実践に勝るものはないと思っています。

ただ、まだやったことはないので、いつか本業と別の仕事は開発じゃない方がいいとか言ってるかもしれませんね。

総括

ゆとりはないし、まだ目立った成果はまだないものの、始めてよかったなぁと思います。

お金の動きは自社サービス(会計freee)で記録しているのですが、はじめて請求書を発行してそれが収入取引として記録されたときはひとえに感動しました。

きっとサービスへの愛着も増すと思います。

習慣

年初に立てた目標はこんなんでした。

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

目標はあるものの、〜ができるようになりたいという形式のものよりも、目標に向けてよい(と思う)習慣作りに重点を置くようにしています。
(もはや目標と呼ぶ類のものではない)

歌は最近ふつうに喋るのもつらい(声がでない)のでちょっと距離を置く所存です。

執筆に取り組むと技術記事のおろそかになる度合いがすごいですが、手を動かすことよりになったタイミングで技術記事書くのも再開したいです。

品川健康センターには毎週行って筋トレするようになりました。

月単位の軽い振り返りを行って、その中で書いた記事の一覧や書いたソースコード、出したPRの紹介とかあると落ち着いた生活が送れるかもしれません。

読んだ本、読んでいる本など。

読んだ

【レビュー】山田祥寛さん著 『独習C# 新版』(2017/12/15、翔泳社)の感想

読むタイミングを間違えました。

AWS LambadaとGoとServerless Frameworkをわかりやすいサンプルで学べる手頃な本でした。久々の洋書。

読んでる

エンジニアとして出会った本の中で一番影響を受けそうな本です。

妥当なクラス設計をしたい...と思ったときに、なにが原則が、原則を適用すべき場面で原則を適用するとコードはどう変わるのかをRubyの実例をもとに説明してくれています。

日々業務の中で実践し、でも足りない部分があるから指摘してもらって改善し、徐々に書くコードも変わってきたかなぁという感じです。

ひととランチしない日はいつもこれ読みながらごはん食べてます。

Goの文法ひととおり追ったらがっつり時間割く価値あるなぁと思いながら毎日割いています。

練習問題付きですが、練習問題をやらず写経するだけでもキャッチアップになってる実感があります。

Azure Functionsに焦点をあてて、「こういうビジネス上の課題をこう解決する」みたいなレシピがたくさん書いてあります。

マイクロソフト公式のドキュメントも充実していると思いますが、もう少しいろいろなユースケースを見たくて読みはじめてみたところ、ユースケースはもちろん、デプロイとかテストとかベストプラクティスとか詳しく書いててよさげです。

読みたい

手元にはあるのが大半で、早くよみたい本たち。

ちょっとやりたいことがあってDurable Functionsを調べているとき、そもそもAzure Functionsももくもく会でXamarinアプリからHttpTriggerちょこっと触ったくらいだったことを思い出し、さささっと把握したいなぁと思いました。

そんなとき目に飛び込んできたのがUdemyの1/12 17:00まで¥1,300セール(!)でした。

Udemyとは?

Udemyは、学びたい人、教えたい人のためのオンラインのマーケットプレイスです。プログラミング、マーケティング、データサイエンスなど、55000以上のコースを1500万人の受講生が学んでいます。

だそうです。



なんとなくAzure Functionsで検索してみたらそれっぽいのが出てきました。

Azure Functionsの講座の感想

とてもよかったですw

Getting Started with Azure Functions

ポータルで簡単なスクリプトを実行するに始まり最終的にはARMテンプレートでCIするまでを5時間で概観できるとは思っていませんでした。

標準的な開発を説明するだけでなく、複数ある開発手法(デバッグ、デプロイ)のメリット・デメリット比較やAzure Fucntions/Logic Apps/Microsoft Flowの使い分け、料金プランを比較したり、サーバーレス・マイクロサービスアーキテクチャのベストプラクティスをどう適用するかにまで話が及んでいて想像以上に本格的でした。

全部英語だったのでついていけるか不安でしたが、Udemy側で自動生成の英語字幕(Serverlessを一度も正確に表示できないなど不完全ではあるw)がついていたり、速度を変えれたり(*0.5、0.75、1.25、1.5、2)親切でした。

定価の¥15,000だったら尻込みしますが、これがたったの¥1,300だなんてラッキーだなぁと思います。

ちなみにお品書きはこんな感じでした。

1. Get Started with Azure Functions

  • The Course Overview: 2:25
  • What are Azure Functions?: 9:22
  • Setting Up Your Azure Account: 6:20
  • Writing Your First Azure Function: 7:38
  • How Does Pricing Work?: 9:08

2. Different Languages in Azure Functions

  • JavaScript in Azure Functions with NodeJS: 10:25
  • C# in Azure Functions: 10:45
  • F# in Azure Functions: 12:08
  • Python in Azure Functions: 10:41
  • PHP in Azure Functions: 9:46
  • Other Languages in Azure Functions: 4:27

3. Triggers and Bindings

  • Introduction to Triggers and Bindings: 7:33
  • Basic Triggers: 12:20
  • Storage Triggers: 13:50
  • Other Triggers and Bindings: 5:24
  • Advanced Bindings: 13:23

4. Architecting with Azure Functions

  • Choosing Between Flow, Logic Apps, Azure Functions, and WebJobs: 7:23
  • Choosing a Hosting Plan: 3:04
  • Best Practices for Azure Functions: 5:35
  • Security Concerns: 15:10

5. Building a Serverless Architecture

  • What is Serverless Architecture?: 6:38
  • Why Serverless?: 3:13
  • Serverless Considerations: 6:10
  • Serverless Best Practices: 5:03
  • Moving to a Serverless Architecture: 5:36

6. Testing and Monitoring Your Azure Functions

  • C# Integration Tests: 12:31
  • Using the Postman REST Client: 9:59
  • Monitoring Your Azure Functions: 11:55
  • Debugging Your Azure Functions: 6:35

7. Automating Deployment

  • Using Azure Functions Core Tools: 8:45
  • Using Git to Edit and Deploy Functions: 11:18
  • Introduction to Azure Resource Manager: 10:09
  • Using Azure Resource Manager with Function Apps: 12:16
  • Putting it All Together for Continuous Delivery: 9:18

Getting Started with Azure Functions

プログラミングの勉強に動画はあり?

どちらかと言うと無し派でした。

Code SchoolでRspecの勉強したときよくわからなくて若干トラウマです。

今回は

  • テーマ的に部分部分知っていた
  • 言語(C#)的に馴染みがあった
  • どういうポイントがあるのかを押さえたいという目的があった

ので、それらに適う形でかなりありだなぁと思いました。

ある程度知ってる前提で、実際の動作(ポータルからポチポチする、コードを書く)を1つ1つ見せてもらえるのはザザッとキャッチアップしたいときにはもってこいっぽいです。

Golang一瞬でキャッチアップ()しないといけないのでこれ(評判良い)を観てみるのと、他にもいいのがあったら買っておこうと思いました。

人にプレゼントもできるらしいです。

Go: The Complete Developer's Guide (Golang)

英語動画コンテンツ

純粋にAzure Functions勉強したいという思いとは別にこの本を読んで思うところがありました。

(しつこい)

著者はプルーラルサイトでiOS、Android、.NETなどの講座を大量に持ってる人です。

資産形成の面で、たしかに1回作ればそれなりの期間は収入入り続けるのかとか、一瞬で古くなってしまうのではとか色々考えていました。

いざ観てみるとFunctionsの話はめちゃくちゃクオリティが高くて、これ1人でどうやって作んねん…って思ったら最後のページにCreditが出てきて9人がかりで作成されたコンテンツであることがわかって吹きました。

なかなかイバラな道なんでしょうか。

あとは今年の3月に1週間くらいアメリカに行って技術セッションに参加するので、Udemyにかぎらず慣らさねばって思いました。

個人事業主になりました。

と言うと数年前の自分ならびっくりする響きですが、個人でもお仕事を受けるようになりました。

いわゆるパラレルキャリアというやつです。

今の会社をやめるわけではありません。

弊社のサービス開業freeeで必要な種類を準備し、税務署に書類を提出してきました。

開業の届け出にかかった時間

書類の準備: 5分

開業freeeで質問に答えていくと必要な種類がPDFで出力できます。

僕の場合は

  • 個人事業の開業・廃業等届出書

氏名、住所や事業の概要等を書きました。

質問への答え方に応じてよしなに書類を埋めてくれます。

利用料かかりません!!!

具体的にはこんな画面です!

金額は検討つかないので仮です。

  • 所得税の青色申告承認申請書

確定申告の種別毎にできることや必要な準備を教えてくれます。

僕はこれまた自社サービスの会計freeeで請求書を発行して、帳簿をつけて、申告まで行いたいので青色申告にします。

あとは青色の控除分くらいは越えたいという気持ちですw

お仕事お待ちしてます!

書類の提出: 5分

税務署に書類を持参しました。

郵送もできますが、自社事業と税務署は切っても切れない縁があるので一度行かねばと思い行ってきました。

1月4日の品川税務署はガラガラで待ち時間もほとんどなかったので、

  • 整理券を受け取って順番を待つ
  • 書類を渡す
  • 紙に名前と電話番号書く
  • 本人確認できるもの渡して番号控えてもらう

全部込みで5分くらいで終わりました。

個人事業としてやることと動機

だいたいブログのABOUT MEで書いているとおりです。

  • iOS、Androidアプリプロトタイプ開発(Xamarin)
  • Xamarinハンズオン(マンツーマンサポート)
  • Xamarin関連の寄稿
  • AWS Lambdaの.NET Core運用
  • Ruby on Railsを使用したWebサービス開発
  • 海外技術書や記事の日本語訳

自身の技術習得の一基準としてここに載せれるのを目指すという意味合いが大きいです。

詳しい動機はこちらに書いてます。

転職して3年が経ちました。2017年の振り返りと2018年の目標

この本の影響がとても大きいです。

強めのエンジニアになるぞー

宣伝

弊社パラキャリという、新しい働き方を考えるメディアも出してますのでよろしくお願いしますー!

また、最近スマホでかんたん確定申告 ~青色申告をラクに済ませるfreeeの使い方から節税のコツまでという本も出し
、freeeの1ヶ月無料クーポンもついてますのでそちらもよろしくお願いします!

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

freeeに転職して( = エンジニアとして働き始めて)3年が経ちました。

2017年はいろいろはじまたいい年だったなぁと思っています。

2018年を強く生きるために2017年を振り返ったり、今年やりたいことを書いたりします。

2017年

仕事面

年初の時点ではこんな感じであれやりたいこれやりたいみたいなことを言ってたみたいです。

転職して2年が経ちました。2016年の振り返りと2017年の目標

  • クエリ、データベース: 自分で早くKPIを追えるように、それが動く土台も詳しく
  • 機械学習: 経営者が一歩先に進むための判断をサポートするという文脈かついいタイミングなので追いたいです
  • 設計: 打ち手を増やして、サービスを作る、変える、大きくするを継続的によくするために。汎用的なデザインパターンとクライアントサイドの定石をまず身につけます。まだまだベストプラクティスを追うフェーズでよいと思っています。
  • フロントエンド: ユーザさんが直接的に触る部分をよくするための技術、問題解決できるサービスであることを伝えるための手段として。サービスで使われてるメインの技術をまずは追えるように…C#(WPF)的な文脈ではもうちょいxamlちゃんと理解しようと思います。
  • linux: もうちょっとコマンド自由に使えるように…去年はLinux標準教科書を環境作って追ってみたら多少ましになったので、その復習プラスサーバの負荷状況調べれるようになりたいです。
  • git: 最低限もわかってない感があるので、本一通り見るのは最低限やります…
  • Xamarin: C#のコードが自分のスマホで動くのは純粋に楽しそう
  • エディタ: RubymineとVisual Studioもうちょい使いこなそう…

実際書いた通りにやったこともあります。

機械学習も3月頃まで毎週勉強に参加しつつCourseraやったり、最終的にはAzure MLを使って社内勉強会でハンズオンをやったりしたのは楽しかったです。

でも、とあるランチがきっかけでもっと目の前の問題に向き合おうと思いました。(毎年言ってる気もする)

Tokyo Jazug Nightで「Azure FunctionsとAWS Lambdaの開発フローの違い」を話してきました。初めての登壇とその理由 #jazug

「自分が困った問題の原因を考え抜く、調べきる」

どういうテーマ・技術分野をするにしても、それによって解決したい問題がある状況の方が身になると。

一方で、本を読んだりする中で何かを学ぶときのスコープ(範囲、期間)の定め方が曖昧過ぎたのかなとも思いました。

今年最も影響を受けた本の1冊でもあるSOFT SKILLS ソフトウェア開発者の人生マニュアルでも「学ぶことを学ぼう」という部(9章分)が確保されているほど大事なテーマです。

今年は初めてLTや長めのセッションにも登壇しましたが、学習の習慣作りとして重要な役割を果たしてくれました。

日付 イベント タイトル
6/22 第6回 Tokyo Jazug Night Azure FunctionsとAWS Lambdaの開発フローの違い
7/25 第7回 Tokyo Jazug Night VSTS、Slack、Microsoft FlowでASP.NET CoreアプリのCIをやってみる
8/30 初心者歓迎XamarinのLT会!Xamarin入門者の集い #3 LottieXamarinで始めるXamarinアプリのアニメーション
10/7 .NET Conf 2017 Tokyo, Japan Xamarin本の歩き方
12/9 JXUG福岡 Xamarin初心者向けハンズオン Xamarin本の歩き方2017

登壇の申し込みをする時点では何もテーマがないんですが、そこからそのときそのときの関心事を考えて、そこまで余裕のない期限に焦りつつ勉強し、なんとか資料にしていきます。

もちろん自分に確実に技術が身についていなくても喋れるのは喋れるし、妥協もいっぱいします。

それでも短期間で一定の形にして人前に晒すのを繰り返すことは意味があると思うので続けます。

登壇は最初は自分で申し込んだものの、.NET ConfやJXUG福岡での登壇はお声がけいただいたものでした。

きっと5分のLTの経験、しかも3回しかなかった自分が45分のセッション(.NET Conf)や東京から離れた土地での勉強会(JXUG福岡)に自分から踏み込む勇気はなかったはずですw

幸運にも機会が機会を読んでくれました。

会社では窓際(物理)でだいたいひきこもっている一方で、コミュニティや他社の方との絡みが広がっていったのもとても嬉しかったです。今年もかまってください。

一方登壇系は自分のやり方ではテーマがバラバラになったり、腰を据えて勉強するのが難しい短期決戦なのでもう少し長いスパンで取り組みたいと思うこともけっこう初期からありました。

そこで取り組んだ技術書典での同人誌の執筆やQiitaでのアドベントカレンダー記事、特定リポジトリ(OSS)へのコミットなど継続的にやっていきたいことです。

技術書典3で『Extensive Xamarin』という同人誌の出展・販売に携わりました

Advent Calendar 4記事の背景にあったテーマ

結果的にMicrosoft MVPも受賞できましたが、受賞自体よりも受賞することで得られる機会を大事にしていきたいと強く思っています。

Microsoft MVP を受賞しました

つまるところ、勉強しないといけないテーマ(技術領域)は年初に「これがやりたい」と思う以上にそのときそのときで変わります。

業務で Xamarin(今後公式にお知らせしますが、Xamarin.Macを使ったMacアプリは無事リリースしました🎉🎉🎉)やることになるとは微塵も思っていませんでした。

そのため、目の前の課題にしっかり向き合い、その向き合い方をより真摯で本質的にするための姿勢・習慣作りを明確にしておくことが大事そうということです。

ある程度「こういう領域やってみたい!」もないといざというときに「え、自分って何やりたいん…?」って困るんですけどね…

そういうわけで2018年の目標はより習慣的なところに重きを置きたいと思います。

音楽面

歌については去年の6月を最後に歌って気持ちいいなぁと思えない状況がひたすら続いています。

各フレーズの1言目が音にならなかったり、息が続かず異様にお腹に力が入ったりただただ苦しいです。(語気弱め)

苦手でできないことばっかりやっているので、ランチカラオケ復活してゆるゆるする時間でも作ろうと思います。

一方聴く面では7月にいった福岡でのミスチルライブが空前絶後のクオリティでした。

中3ではまりバンドをやり始めたきっかけにもなったミスチル、2009年にSUPERMARKET FANTASYのドームツアーで本物を見てからずっと追いかけていますがこの回ほど完璧と思ったことはあいませんでした。

各曲最高のシーンを集めた映画のようで、ある意味では臨場感を失っていました。

今年は早速主題歌も決まってるので楽しみですね!

家庭面

嫁氏最高本当にありがとうに尽きます。

行きたかった海外旅行(マレーシア・マラッカ)には行けたものの、新婚旅行だったり、結婚式的なものだったり大事なイベントがまだだったりするので、日付決めます。

あと、結婚したら自分の両親とお嫁さんと沖縄に行く!!!って何年か前にしていた約束も果たせたのはよかったです。

今度は2人で離島行きたい。

精神面

年初に掲げていた睡眠の質向上は継続的に取り組み、眠いと感じる日は1年でほぼなかったです。

このスリープ・レボリューションという本で文字通りスリープをレボリューションしました。

あと、精神は半信半疑で読んだマインドフルネス系の本(世界のエリートがやっている 最高の休息法――「脳科学×瞑想」で集中力が高まる)が刺さりました。

イライラと向き合うにあたり、宗教的なアプローチ(反応しない練習 あらゆる悩みが消えていくブッダの超・合理的な「考え方」とか)や名言的アプローチ(デール・カーネギーの悩まずに進め ──新たな人生を始める方法)もそれぞれわかる、せやかて工藤みたいなノリでなかなか定着しませんでした。

でもこの本は単にイライラしない以上に自分のパフォーマンスに直結するのと、よりハードワークな状況を迎えるにあたっての「心身を休める技法」の必要性に迫られている状況がある中取り組みの裏付けもしっかりしているようで比較的定着しそうです。

2018年

仕事面

新チーム

年初からこの1年親しんできた技術とはけっこう別の技術スタックを扱うチームでがんばることになりました。

技術面では、C#や.NETに触れる中で言語の周辺を支えるツールやライブラリの中身まで追うようになってきました。

その向き合い方を忘れずにまずはキャッチアップしてやり切れることを増やしたいなぁと思います。

副業/複業

あと大きいのは副業/複業を始めることです。

またしてもSOFT SKILLS ソフトウェア開発者の人生マニュアルの影響ですが、自分が個人で仕事受けるとしたら何だろう?と、そういうテーマの章を読んでこのブログのAbout Meページで求職を書いてみました。

About Me

そしたら

「こういうことできるので仕事ください!」

と出せることの幅や深さに問題意識を持たざるを得ませんでしたw

そして実際に書いた内容で求職(副業/複業)し始めました。

意図としては、

  • 自分ができるようになってきたと思うことは社外でも(ある程度客観的に)通用するのか挑戦したい
  • ここに書くことをテーマに深めていけたら素敵。振り返りもしやすい。
  • 「どこまで勉強するか」の1つの基準になる。「仕事を受けてやり切れるまで」
  • 弊社サービス会計freeeで帳簿をつけ、Macアプリで電子申告する
  • 特定の組織に依存せず生きる力を…

というところです。

週あたりの時間を決めてやって行く予定ですが正直やってみないとわからないのでこれを主軸にやってみてから考えます。

幸い開発と本を書くことについてはお声がけいただいています。※確定して始まっているわけではない

弊社のサービス開業freeeで必要な書類は揃えたので、1/4か5に税務署に提出してきます。

習慣

習慣としてはこういうのを目安に作っていきたいです。

絶対達成したいのとできたらやりたいのを敢えてふわっと…

機会があれば他をおいても挑戦します。優先度順。

  • 本: 2冊/年
  • 登壇: 6回/年
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術記事: 2記事/月
  • 技術書: 30分/日
  • その他本: 30分/日

寄稿とかないかな?

テーマ

昨年はXamarin勉強した一方でサーバーレスな技術に触れてとても楽しかったです。

UIをHTMLやJS的なフロント以外(モバイル、Bot、Chat)におさまるというかフロント苦手意識が強い?

色々ためしてみたいことたくさんあるので、Trello(カンバン式タスク管理ツール)にチケット切って積み重ねていこうと思っています。

あとはこういう単位で自分で一通り使える状態のコード書いてGitHubにあげていきたいです。
https://github.com/toshi0607/ErrorNotificationLambda

「これできます」と言うためには、細々tips記事書くのを目標にしていたら到達しない(書くことは大事)だと思っていて、一通りサービスなりライブラリなり形にしていくのを増やしていかないとと思うこともあり上に載せたコードを書きました。

そして去年はAWS LambdaやAzure Functionに少し触れてとても楽しく、PaaSの幅広げたい(組み合わせて使いたい)のでAWSかAzureの認定資格とります。

音楽面

楽しいと思う気持ちを復活させる。

  • カラオケ: 2回/月
  • 歌練習: 1回/週

家庭面

家をきれいにw

いらないものを捨てて、書斎を復活w

ソファとか床とかでPC長時間いじるの辛い…

あと、

  • 品川健康センター: 2回/月
  • 走る: 1回/週

最近引きこもりすぎて走るのすらやってなかった。

健康診断評価のランクは変わってないけど、数値は悪くなっているw

そして現金以外の資産の比率高める。

精神面

平和な気持ちで過ごしていい1年にしような!

独習C 新版のレビュー記事です。本の分量自体が索引含め606ページととても読み応えのあるものだったため、読んだ感想(ざっくり)からだんだん詳細が伝わるように書いていこうと思います。

全部読み、各章についているの理解を確認するための問題も一通り考えてみました。

こういう人が読むといいかも

普段業務や趣味でC#である程度意図通り動作するアプリケーションを書いているが…

  • 人のコードを読んでいて構文的にわからないことがある
  • 動くけどなんでそれが構文的に正しいかよくわかってないなぁと思うことがある
  • いつも手に馴染んだ書き方で書いているが、他にも書き方ありそうなので打ち手を増やしたい
  • C#を体系的に勉強したいけどなにを「体系的」とするか一例を見てみたい

書いたことがあるけど、動いている部分を説明できるように「基礎」を勉強し直したいときに読むとよさそうです。

僕自身が読むにあたっては理解や知識に漏れがる部分がどんどん埋まっていく感じがしました。

こんな人が読むのは厳しいかも・向いてないかも・書いてないかも

  • デスクトップアプリ、モバイルアプリ、Webアプリケーションのフレームワークの使い方が知りたい
  • Visual Studioを使いこなしたい
  • はじめてC#を書くにあたってC#の概要を知りたい

はじめてC#に触れる人がこの本を読むのはちょっとしんどいと思いました。

C#経験が少ない人のことも意識されてますが、網羅的かつ詳細に説明されているだけに、どれも大事なことのように思えて読み終わらなさそうです。優先度の甲乙がつけがたい。

レビューを書く人(自分)のC#歴

C#との接点

  • 2015年夏くらいから業務でWPFのアプリ開発を半稼働くらいで開始
  • 2016年は半分と少しくらいWPFアプリ開発に従事
  • 2017年は7割くらいXamarin(Macアプリと趣味でモバイルアプリ)とWPFとAWS LambdaでC#を触る

読んだ本

  • Xamarin本一通り

あとC#本何冊か部分部分読みました。

特徴的なところ・いいなと思ったところ

似た使い方をする構文の違いの説明が詳しい

  • ジャグ配列と多次元配列のLengthの違い
  • ==Equalsの違い
  • &&&の違い
  • Regexのインスタンスメソッドとクラスメソッドの違い
  • readonlyconstの違い
  • File/DirectoryFileInfo/DirectoryInfoの違い
  • 値型の値渡し、参照型の値渡し、値型の参照渡し、参照型の参照渡しの違い
  • ListLinkedListの使い分け
  • LINQのクエリ構文とメソッド構文の違い
  • 匿名型とタプルの用途の違い
  • interfaceと抽象クラスの使い分け
  • DynamicObjectExpandoObjectの使い分け

本文中で説明されているものもあれば、「エキスパートに訊く」という特設コーナーでQA形式で説明されているものもあってとても勉強になりました。

使っているはずだけど知らなかったことが振り返れる

  • ifwhiledo while{...}省略時の意図していないはずの挙動
  • フィールドの初期化子、コンストラクター、オブジェクトの初期化子の初期化の順番
  • C#6からラムダ式で書けるようになったメンバーの一覧
  • Spritメソッドでseparatorなしの場合はIsNullOrWhiteSpace相当区切り
  • 正規表現で最長一致・最短一致させるための書き方
  • Stackforeachで取り出すときも後ろから取り出す
  • 構造体使用が妥当なケース
  • ハッシュテーブルへのアクセス効率

自明なものとして表立って説明されることはなかったり省かれたりすることが多いけど概念的に大事なことを一言で言い表した上でC#の実装や図表と合わせて説明されている

  • サロゲートペア
  • バッファー
  • コレクション
  • スタック
  • キュー
  • セット
  • ディクショナリ、マップ、ハッシュ、連想配列
  • ジェネリック
  • アセンブリ
  • ストリーム
  • シグニチャ
  • スレッド
  • プロセス

ラムダ式登場の経緯

デリゲート型にをより簡素に書くためにラムダ式が登場した背景が具体的なコードと共に説明された上で、ラムダ式をよく使うLINQの説明がなされていてとても頭に入ってきやすかったです。

この部分に限らず、全体的に単に使い方だけでなく構文登場の背景や、以前のC#バージョンではこう書いていたが今はこう書けるので今後はこう書いていくべきのようにC#をとりまく歴史の中で説明されているので頭がスッキリしました。

全然知らなかった、考えてみたこともなかった…

  • volatile
  • 属性や動的オブジェクト(DynamicObject派生クラス)を自分で定義して使う
  • .NET FrameworkでPythonを動作させる(IronPython
  • マルチキャストデリゲート
  • 演算子のオーバーロード

章毎の確認問題

章毎に理解度を確認するための問題がついています。

コードを書く以外の問題(◯×問題)を掲載するので、試しに確認してみてください。答えが気になる方は是非本でどうぞ!

※章途中の小問題もけっこうあるのでここに掲載する倍以上の問題とその解説が載っています。

  • 1章
    • C#の特徴を「マルチパラダイム」「マルチプラットフォーム」というキーワードを絡めて説明してみましょう。
    • C#アプリは、どのメソッドから実行されますか。また、そのようなメソッドのことをなんと呼ぶでしょうか。
    • 文の末尾を示す記号を答えてください。
    • C#で使えるコメントの記法をくべて挙げてください。また、これらのコメントの違いを説明してください。
  • 2章
    • 次の文章は、C#の基本構文について述べたものです。正しいものには◯、間違っているものには×を記入してください。
    • ( )小数点型は、符号なし型と符合あり型とに分類できる。
    • ( )文字列リテラルはダブルクオート、またはシングルクオートでくくる。
    • ( )short型の型サフィックスは「〜s」である
    • ( )暗黙的な型変換は常に安全なので、桁落ちなどの情報欠落は発生しない
    • ( )メソッド/フィールドなどにアクセスするには、必ずnew演算子でクラスをインスタンス化しなければならない。
  • 3章
    • (省略)
  • 4章
    • (省略)
  • 5章
    • (省略)
  • 6章
    • この文章は、コレクションについて説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )Listへの挿入/削除は、位置に関わらずほぼ一定のスピードで可能です。
    • ( )LinkedListへの挿入/削除では要素前後のリンクの付け替えが発生するので、比較的低速である。
    • ( )HashSetは要素の重複を許さず、一意の値を決められた順序で保持します。
    • ( )Dictionaryは一意のキーと値のペアでデータを管理します。キーの並び順は保証されません。
    • ( )Stackは先入れ先出し、Queueは後入れ先出しと呼ばれるデータ構造です。
  • 7章
    • 以下はオブジェクト指向の主要なキーワードについて説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )フィールド/メソッドは外部から呼び出すことが前提の仕組みなので、アクセス修飾子も既定はpublicである。
    • ( )readonlyフィールドとローカル変数の名前は重複してはならない
    • ( )forループで宣言されたカウンター変数は登場以降、そのメソッドの内部であればアクセス可能である。
    • ( )匿名型はその場限りであれば、引数や戻り値の型として利用することが可能である。
  • 8章
    • 以下の文章はオブジェクト指向構文について説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )派生クラスから基底クラスのコンストラクターを呼び出すには、superキーワードを利用する。
    • ( )virtual修飾子のないメソッドを、派生クラスで再定義することはできない。
    • ( )override修飾子のないメソッドに、sealed修飾子を付けることはできない。
    • ( )as演算子は左オペランドが右オペランドの方に変換できる場合にtrueを返す。
    • ( )インターフェイスを複数実装することはできるが、クラスと一緒に実装/継承することはできない。
  • 9章
    • 以下の文章は本章で学んだ機能について説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )catchブロックは、ブロックで指定された例外と発生した例外とが一致した場合にだけ実行される。
    • ( )クラス/インターフェイス/構造体は、互いに入れ子の関係になることが可能である
    • ( )構造体では、継承は可能だが、インターフェイスの実装はできない。
    • ( )列挙定数の型は、任意の数値型から選択できる。
    • ( )演算子のオーバーライドという機能を利用することで、「+」「-」「==」のような演算子をクラス独自に再定義できる。
  • 10章
    • 以下の文章は、デリゲート/ラムダ式/LINQについて述べたものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )引数にメソッドを引き渡すような用途では、ラムダ式よりも匿名メソッドを利用すべきである。
    • ( )ラムダ式で引数がない場合には、「=>式」のように引数そのものを省略できる。
    • ( )LINQのクエリ構文は、メソッド構文でできることであれば必ず表現できる。
    • ( )LINQでは、与えられたデータソースによってプロバイダーを決定するので、アプリ開発者がプロバイダーを意識する必要はない。
    • ( )LINQのクエリ構文は必ずselect句で終了しなければならない。
  • 11章
    • 以下の文章は本章で解説したテーマニついて説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )スレッドを維持しておくのはリソースの浪費なので、できるだけその場その場で解放するのが望ましい。
    • ( )await演算子は、指定された非同期処理の終了を待ってメインスレッドを待機させる。
    • ( )属性によって適用できる要素は決まっている。
    • ( )dynamic型では、存在しないメンバーを呼び出してもエラーにはならない。
    • ( )イベントを登録するには、「=」演算子を利用する。

目次

意外とネットに転がってない…

  • 1章 イントロダクション
    • 1.1 C#の特徴
    • 1.2 C#アプリを開発/実行するための基本環境
    • 1.3 C#プログラミングの基本
  • 2章 C#の基本
    • 2.1 変数
    • 2.2 データ型
    • 2.3 リテラル
    • 2.4 型変換
    • 2.5 参照型
  • 3章 演算子
    • 3.1 算術演算子
    • 3.2 代入演算子
    • 3.3 関係演算子
    • 3.4 論理演算子
    • 3.5 ビット演算子
    • 3.6 その他の演算子
    • 3.7 演算子の優先順位と結合則
  • 4章 制御構文
    • 4.1 条件分岐
    • 4.2 繰り返し処理
    • 4.3 ループの制御
    • 4.4 制御命令のその他の話題
  • 5章 標準ライブラリ
    • 5.1 文字列の操作
    • 5.2 正規表現
    • 5.3 日付/時刻
    • 5.4 ファイル操作
    • 5.5 その他の機能
  • 6章 コレクション
    • 6.1 コレクションAPIの基本
    • 6.2 リスト
    • 6.3 セット
    • 6.4 ディクショナリ
  • 7章 オブジェクト指向構文(基本)
    • 7.1 クラス定義
    • 7.2 フィールド
    • 7.3 メソッド
    • 7.4 コンストラクター
    • 7.5 クラスメソッド/クラスフィールド
    • 7.6 引数/戻り値のさまざまな記法
  • 8章 オブジェクト指向構文(カプセル化/継承/ポリモーフィズム)
    • 8.1 カプセル化
    • 8.2 継承
    • 8.3 ポリモーフィズム
  • 9章 オブジェクト指向構文(名前空間/例外処理/ジェネリックなど)
    • 9.1 名前空間
    • 9.2 例外処理
    • 9.3 列挙型
    • 9.4 特殊なクラス(入れ子のクラス/パーシャルクラス)
    • 9.5 ジェネリック
    • 9.6 Objectクラス
    • 9.7 演算子のオーバーロード
  • 10章 ラムダ式/LINQ
    • 10.1 デリゲート/匿名メソッド/ラムダ式
    • 10.2 LINQ
  • 11章 高度なプログラミング
    • 11.1 マルチスレッド処理
    • 11.2 属性
    • 11.3 動的型付け変数(dynamic型)
    • 11.4 イベント

独習C 新版

今年は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

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

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

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

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

まとめ

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

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

freeeに転職して2年と11ヶ月が経とうとしています。新卒で入って企画/営業をしていた前職SIerには2年9ヶ月いたので、とうとうエンジニアとして働いた期間の方が長くなってしまいましたね…

Open Source Friday

最近freeeというか所属しているチームでOpen Source Fridayという取り組みが始まりました。

これ(「Open Source Friday」をGitHubが提唱。金曜日は自分の好きなオープンソースに貢献しよう)をやってみようというものです。

私たちはGitHubの従業員に対して少なくとも毎週第四金曜日には時間をとってオープンソースに協力し、お互いにどんなことをしたのか共有しあいましょうと呼びかけてきました

毎週(元記事の誤訳)でも毎月でもないですが、試行錯誤しつつ今後も続いていきそうです。

なぜやるのか?

  • かつての社内でもあったGoogleの20%的なものを継続的にやる
  • 社内のプロダクトへの貢献という枠を越えてOSSに貢献する
  • コードを集中して書く

あたりです。自分たちのプロダクトもOSSに支えられているので自分たちも貢献しようというのにはとても共感します。

こういう取り組みがなくてもやりたい人はやればいいと思いますが、「会社においても大事な活動と捉えられ、サポートしてもらえる」というのはとてもテンションが上がりました。

※サポート = 時間を確保してもらえる

推奨される活動

  • OSSにパッチを出す
  • 自分でリポジトリを立ててコードを書く
  • その他オープンな技術的な活動

テーマ設定

イベントありきで無理にテーマをひねり出すのではなく、普段の活動の延長でやりたいなぁという思いがありました。

Micorosoft公式リポジトリのハンズオンを日本語訳してQiitaに投稿した記事が元々あったので、どうせなら公式ドキュメントにしてしまうか…

ということで、「自分で訳した記事を本家に取り込んでもらう!」をテーマにすることにしました。

Qiita記事: Visual Studio for Mac で Azure Functions と Azure Table Storage を操作する Microsoft 公式チュートリアルの日本語訳
本家リポジトリ: Microsoft/vs4mac-labs

Visual Studio for Macのハンズオンに特化したリポジトリで、下記のようなカテゴリがあります。

  • Azure Functions
  • Docker
  • IoT
  • Mobile
  • Unity
  • Web

それぞれのカテゴリ自体の情報は多いですが、基本的にVisual Studio "for Windows" で扱うものが多く、その辺にわざわざリポジトリを独立させてある意義もあるのかなぁと思っています。

日本語記事が1ページ増えること自体はどうってことないかもしれませんが、広まるきっかけ作りになればいいなぁと思っています。

PR作り

PRの中身大体できてるんだからそれPRにしたらおしまいでは?と思う方もいらっしゃるかもしれません。実際そうです。

ただ、いくつか元々わかってなかったことがありました。

画像のホスティング

README.mdに載っている画像ってどこから配信してるんでしょうか?

同一リポジトリに画像フォルダでもあるのかなと思って探してみたのですが、ありませんでした。

URLを見てみると、たとえばこんな感じ。

https://user-images.githubusercontent.com/3944468/29033686-bdddd454-7b4a-11e7-8494-b3dad886c20a.png

このURLを調べてみると、GitHubのissueに画像をD&DするとURLが生成され、そのissueの存在の有無にかかわらずコンテンツは残り続けるということがわかったので活用しました。

いつ消えても文句言えないけど、それはGitHub諸共なくなってしまうときでは…とか思ったり。

参考: GitHubのissueを悪用して画像をホストする

あとは日本語設定にしたVS4Macでハンズオンを追い直しながら画像準備して、注目してほしい部分をSkitchを使って囲うという作業ゲーが最高に面倒でした。

素の画像サイズで上がるので、元の画像いじっておくか、タグで幅指定するとよさげです。

元のハンズオンのサイズに合わせました。

<あいえむじー src=https://user-images.githubusercontent.com/7035446/31535876-a84b33d0-b037-11e7-96fb-f8e27d43daee.png width="620px">

PRの規約

特にルールとかなさそうだったものの、一応commitはまとめました。

あと、初めてPR出すときはContributor License Agreementへの同意が求められました。

急いでるときに見たらちょっとびっくりするので、先に見ておいてもよさげです。

Microsoft Contribution License Agreement

同意してないとこのbotに怒られます。

msftclas

マークダウンの文法

Qiitaで投稿したときにナンバリングがうまくいかず、バックスラッシュでごまかしたけどこれレビューで弾かれるんじゃ…って思ったので直しました。

と思ってPR見直したら直してなかったwww

以上を経て完成したPRがこちらです。

Azure Functions lab for Japanese

なかなかレビューされない

Open Source Fridayの実施が2017/10/13、マージされたのは2017/11/21でした。

それまでの間、

  • 日本のMSの方々にこのリポジトリ関係の知り合いいないか、レビューしてもらえないか聞いてみる
  • コミットの多い人にPR内でメンションする
  • twitterアカウント把握したのでお願いしようとしたけど思いとどまる

などをしていました。

直近めちゃくちゃ活発に動いてるわけではないリポジトリだとこういうこともあるかもしれません。

とりあえずマージされてよかった。

ドキュメント翻訳に思うこと

ドキュメントの翻訳は最近よくやっています。

  • (受験)英語もともと苦手ではない
  • 日本語記事あると捗るなら、まず公式のドキュメントが日本語で存在してほしい
  • 何回も見る記事を訳すので、あると自分にとっても都合がいい
  • 素のままで読めてると思っても、訳してみて「え?そんなこと書いてたっけ?」みたいにとりこぼしがある。もったいない。

ただ、今回のPRにしても、訳すにしても微妙だなぁと思うこともあります。

  • どうせならコード(設定ファイルとかでもいいから)でコントリビューションしたい
  • 翻訳は人間がやるべき本質的な作業ではない
  • 自分の「価値」をだいぶ疑う、頭使ってない感に負い目を感じる

とは言え、もちろん全部手で訳すほど暇ではないので、1文ずつGoogle Chromeのエクステンション(文にカーソル合わせたら訳文を表示してくれる)の訳文と原文見比べて、実態にそぐわないものや構文的な誤訳を修正するみたいなフローを延々と繰り返しています。

その中でまだ人が介在しないと危うい部分が少なからずあるので、このモヤモヤを振り払って翻訳している次第です。(自己弁護)

それでもやっぱりモニョるのはやっぱりコード書いてドヤァするまで拭えない感情でしょう。

まとめ

いろいろ論点ごっちゃにしてしまいましたが、

  • Open Source Friday楽しかった
  • 公式リポジトリに自分のPRがマージされたのは嬉しかった
  • コードでコントリビューションしていけるようにがんばるぞ

というおはなしでしたー