by ·0件のコメント

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

サマリ

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

by ·0件のコメント

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

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