by ·0件のコメント

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しろとかそういう話でない）
  • 読みやすいと思って書いたコードもきっとそのうち…
  • 自分が過ごしやすいなと感じたとき、その環境を作ってくれた人がいる
  • いいものは偶然発生するかもしれないけど大体は誰かが作り、そういうものであり続けるように維持してくれている

by ·0件のコメント

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

次の四半期のアクションや意識することが出てくるのが理想ですが、最低限年末にこの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

by ·0件のコメント

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

by ·0件のコメント

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分くらいじっくり喋りたかった内容だったりするので機会があればリベンジしたいなぁと思いました。

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

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

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

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

by ·0件のコメント

技術書典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新刊によせて

by ·0件のコメント

区切りなので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に焦点をあてて、「こういうビジネス上の課題をこう解決する」みたいなレシピがたくさん書いてあります。

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

読みたい

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

by ·0件のコメント

ちょっとやりたいことがあって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にかぎらず慣らさねばって思いました。

by ·0件のコメント

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

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

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

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

弊社のサービス開業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ヶ月無料クーポンもついてますのでそちらもよろしくお願いします！

by ·0件のコメント

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

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年にしような！

by ·0件のコメント

独習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のインスタンスメソッドとクラスメソッドの違い
  • readonlyとconstの違い
  • File/DirectoryとFileInfo/DirectoryInfoの違い
  • 値型の値渡し、参照型の値渡し、値型の参照渡し、参照型の参照渡しの違い
  • ListとLinkedListの使い分け
  • LINQのクエリ構文とメソッド構文の違い
  • 匿名型とタプルの用途の違い
  • interfaceと抽象クラスの使い分け
  • DynamicObject、ExpandoObjectの使い分け

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

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

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

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

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

ラムダ式登場の経緯

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

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

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

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

章毎の確認問題

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

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

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

  • 1章
    • C#の特徴を「マルチパラダイム」「マルチプラットフォーム」というキーワードを絡めて説明してみましょう。
    • C#アプリは、どのメソッドから実行されますか。また、そのようなメソッドのことをなんと呼ぶでしょうか。
    • 文の末尾を示す記号を答えてください。
    • C#で使えるコメントの記法をくべて挙げてください。また、これらのコメントの違いを説明してください。
  • ２章
    • 次の文章は、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 新版