2019年になって4日経過しました。
2017年の振り返りに続いて、2018年の振り返りをしてみます。
総合
2018年の初めにこう書きました。
流れは年末から変わらず。C# / Swift / TypeScript / Serverless / Container がメインです。やること多いので、いっこずつ片付けます。 やりこんでできないより、やりきるは何より大事です。できるを最低条件に過程をよくするのは力量です。自分でハードルを挙げておいて、工夫してよじ登るのが続くのでしょう。 インフラ、サーバーサイド、クライアントサイドの視点からどうやるといいのかを考えられるようになったのが2017年の最大の獲得であり、今後試されます。
2018年はクライアントとサーバーサイドの両方をやっており、アーキテクチャから考えて実装までやることが多かったです。クライアントとしてはHoloLensアプリ開発に携わっており、2017年に得た蓄積を2018年発展させることになりました。サーバーサイド/インフラは、Python/C#/Docker/Serverlessが主になり、一方でSwift/TypeScriptを触る機会がかなり減りました。クロスプラットフォームで動かすことが多いため、Golangを触る機会が明らかに増えたのも目立ちました。転職、起業が入って想定よりも少し色々やることになりました。
総じて、自分の経験を活かしつつ足りない部分を学びつつ適用していくことの連続でした。今までの延長のようで、実際はOS、クラウドともに環境を選ばなくなっており一部に安住・固定できなくなったという意味で、自分の未熟さと向上が求められる一年でした。
退職と転職と起業
グラニ社は2018年退職しました。ちょうど5年いたことになります。入社当初から「3年経ったら辞めるor @neueccがいなくなる時は私もやめる」と伝えていたのですが、2年延長するぐらいには好きな会社でした。延長を振り返ってみます。
1回目の延長は3年経った一昨年で、「黒騎士と白の魔王」のリリースを見届けたいこと + ゼロからVR部門の立ち上げに誘われたことからあまり機会ないのと面白そうと思って伸ばしました。
2回目の延長は昨年で、部門立ち上げてアプリもいくつかリリースしたころで、「黒騎士と白の魔王」のリリース間近だった + クローズドβで問題が確認できないことから社内のモニタリング基盤を一新することになりリリースを成功させるために延長しました。
このモニタリングの変更によって開発から運用まで根底から取り組み変えることになったため、安定するまで見届けたいという思いがありました。このあたりはグラニの開発者ブログで書きました。
http://engineering.grani.jp/entry/2017/05/29/173141engineering.grani.jp
2018年は延長する理由がないので1月にいくつかお会社に訪問して、面白そうなプロジェクトに参画しようと考えていましたが身内の緊急事態があり断念することになりました。*1と思いきや3月に@neueccが退任することになったので予定通り退職しました。グラニは、neueccに誘われたから入りneueccがいるからいたという意味で、人に惹きつけられて働くという試みでしたが、想定以上に楽しく自分を鍛える場となりました。ひとえに多くの同僚と周りの人に支えられた結果だったので心から感謝しています。やりたいことと人と仕事が一致していたという意味でとても面白かったです。
3月いっぱいでグラニを退職することにしたものの、どこに行くか決めておらずいくつか会社を訪問し、4月に某社へ転職し2週間で退職しています。人生で一番早かったのですが、入社までにかかわった方には申し訳ない限りです。入社や退職エントリーを書いていないことからも詳しい理由は書きませんが、あくまでも自分の想定との乖離が激しかったためであって、その会社やメンバーに起因するものではないです。詳しく聞きたい方はご飯に行きましょう。
で、5月に起業しました。2018年4月時点では後2年先になる想定だったのですが、2年で得るもの、やることを考えた末でした。*2多くの人に支えられてまずはスタートを切っています。使うべきではない言葉なので修正してくださいことばかりで頭が回らない、日々いっぱいいっぱい感がありますが、本当に周りの人に助けられています。とはいえ年末の2週間は、手痛いドジを2回踏み、日常生活すらも余裕を失い、体力も限界に近かったので2019年はこれぐらいは余裕でクリアできるはず。*3
さて、起業したものの2018年は一人会社なので個人事業主とあまり変わりません。*42018年は、知人の紹介や打診で複数のお会社でお手伝いをしています。
プログラミング
2018年は、前半と後半でやっていることが全く変わっています。 前半は、ASP.NET MVCからASP.NET Core 2.0/Terraformがメイン、後半はお手伝い先に合わせていろいろでした。
最も使ったのは、C# ですがGolangを読む機会が大きく増えました。
Gitコミットは、まぁこんなものでしょうか。PowerShell本のコミットが混じっていてちょっとノイズがはげしいです。
CSharp
お仕事としては、ASP.NET MVCのASP.NET Core MVC化が大きなトピックでしたがやり残しになったのが残念でした。 一方で、HoloLens + Unityでのお仕事があり、CI/CDの構築からサーバーサイド連携、MVP4Uアーキテクチャなどチャレンジができたのは良かったです。
特にMVP4Uは、ZenjectによるDIをアーキテクチャのために使う失敗に対するカウンターになったのが大きく、DIに対する自分の中の一喜一憂が大きく浮き沈みしました。ASP.NET CoreのDIはフレームワークが組み込んでしまっているので「どうこう考えるより先に使えばいい」で構わないですが、UnityのDIは「自分で意図をもって用いる」のでここで失敗をしたのは良かったです。現状UnityでDIは、テストかScriptableObjectの解決以外は使いたくないし避けていく予定です。
C# はUnityを除き .NET Coreに集約されました。.NET Frameworkありがとう、さようなら、でいいでしょう。とはいえ、macOS、Linuxはまだ、.NET Coreなアプリを動かすことないんですよね。たいがいコンテナ上で動かしてサービス組むので、.NET Coreというよりコンテナで動かせる *5という見方です。コンテナとして考えて、開発はC# でできるのはCI/CD、オーケストレーションの全方位でメリットなのでようやく追いついてきた感じがします。
面白かったのがUWPアプリを書いていたことです。HoloLensのごにょごにょで必要となり書いたのですが、昔からXAMLは苦手な部類にあってようやく書ききりました。書きやすいは書きやすいのですが、これを今後も続けるのはどうにもと感じるのでなんともです。UWPも制約の高さが結構あからさまに出てるのが微妙で悩ましいです。今後のUWP全然光が見えないのですが、本当にこれやるんですかね?
Serverlessに関しては、Azure Functions v2.0がGAしたことで、いくつか書き換えが入りASP.NET Coreっぽくなりました。暗黙的なお約束が増えたことはDIに似た気持ち悪さがあるのですが、フレームワークの成熟ってこういう感じかなぁとも感じるので、シカタナイ気もします。
1つ感じるのは、.NET Standardはかなりきつく、.NET Core最高感です。特に .NET Core 2.2から楽になった感じが大きいので、今後は .NET Core 2.2 /3.0がスタンダードでいきたいところです。
相変わらずC# に感じるビルドが苦しいという状況は光明が見えないです。dotnet (msbuild) でのラップはいいのですが、制御しにくさがなかなか大きいです。
シングルバイナリくるくる詐欺が本当にくるっぽいので、期待しています。シングルバイナリ何がうれしいって、CI/CD/コンテナでめちゃめちゃうれしいのです。
と書いていたところで、反応もらいました。
そういえばself-containedでpublishすれば別にシングルバイナリに拘らなくても運用的な意味では問題ないと思ってるんですがどうじゃらほい(見た目はuglyですけど実用的には変わらないかとは)
— neuecc (@neuecc) January 5, 2019
運用面はどうとでもなるんだけど、それはuglyであることを受け入れた結果なので、ベストではないと考えています。シングルバイナリならコピーと参照がシンプルになるのは明らかです。 ファイルを指定するか、フォルダを指定するかの違いは思ったよりも大きくて、基本的に対象が単独ファイルであることは簡単です。とくにフォルダになった場合、子フォルダも考慮する必要が出てくることがほとんどなので、シングルバイナリの楽さに比べて格段にめんどくさいと常々感じます。シングルバイナリでないだけで、余計な手間とコストがかかっているので「2019年にもなってそんなこといい加減なんとかしたい」というのが気持ちの根底にあります。ただ、dll差し替えで済むケースなど部分的な入れ替えとか考えだすとアカンコレなのでバランスなのでしょう。
Python
お手伝いの流れで、メイン言語で読み書きをしていたという意味で触る機会が増えました。C#以外は全てVSCodeなのですが、コードレンズで追っかけるのが楽なので始まりのエディタとしては良さがありました。もともと時々読み書きすることはあったのですが、VSCodeで案外楽になっていたのは良かったです。
某SDKを使っていたのですが、エラーから原因を追いかける時にスタックとレース通りではあるもののエラーメッセージから状況が読めず、周りからも同じ見解であるものの解消まで手間取ったというのがありました。デプロイしないと状況が発生しないこともあり、リモートデバッグどうすればいいんだ、となりながら苦しかったので対処知りたい。
pyenv苦しいので、全面的にpipenv使えばいいでしょう。あとDockerではpyenvとかせず、おとなしくPythonをいれましょう。その方がパスと依存性がきっちり制御できて時間短縮できます。pyenvやばい、pyenv使いたくなくなった。
そういえば、Azure / AWS / GCP全てPython 3.xで問題なくなっているので、Python 2.xは使わなくなりました。
Golang
Windows/macOS/Linux全ての環境を触ると出てくるのが、クロスプラットフォームで上手く使えるツールなのですが、Golangの独壇場でした。それもあり、OSSツールを使うことがほとんどなので、Golangを読む機会がかなり増えました。
一方で、余り書く機会を作れずにいたので、Golang書く機会を強制的に設けるようにしはじめました。どうしても必須なので、しばらく維持して書く機会を強制的に増やす方向にしています。
PowerShell
これまでと違ったこととして、2017年末に出版社様から打診をいただいたPowerShell本の執筆が決まり書き上げました。
反省も書いたので、次があれば生かすということで。
PowerShell 6.0がリリースされ、6.1がリリースされたことでPowerShellも .NET Coreに踏み出しました。*6
PowerShell Coreについては本でも書きましたが、参考になるモジュールを用意していなかったので書いたのがUtf8BomHeaderです。
私自身のPowerShellを仕事で用いる頻度は、Windows 100％ なのですが、個人では60％ Docker (Linux) / 40％ Windowsなのでまぁこんなものと感じます。そもそもWindows以外の仕事でPowerShellを用いる理由がないのですが、Windows、特にAzureだと用いているのが楽なケースも散見されるのでまぁそんなものですかね。
いろんなお会社でいろんなやり方を見ている限り、PowerShell CoreはWindowsがない環境で標準的に使われるのはないと感じますがもう少し様子見で。AzureはPowerShellでしかできない操作があるの本当に良くない。
ShellScript
PowerShellよりも圧倒的に書くことが多かったのは当然Dockerで使うからです。Terraformと組み合わせることが多く、このやり方はつらいことへの一直線なので悲しいものがあります。
ある意味では素直なので、このままちょくちょく書くことが多い状況は続くのでしょう。
インフラ
お手伝いで求められ、発揮しやすいのがインフラとアプリをつなぐ部分とサービス全体の安定化です。ということで、インフラ的な部分は2018年もやってます。
特に、Docker、 Terraform + Ansibleが多く、Kubernetesに少し踏み込んだ感じでした。
Terraform
一年通して、Terraformでした。
Azure/AWS/GCPどのプラットフォームも書いていましたが、どこも癖が違って微妙にやりにくいのが解消せず厳しい...。 AzureRm Providerに関しては、10以上Issueあげたりしたので2018年末はだいぶん楽になりました。2018年5月はどうしようかと思いましたが、なんとかなるぐらいにはなってよかった。
AWSがやはり一番書きやすいというかリソースがそろっている感じはあります。書きやすいというと嘘で、Regionが露骨に出てくるので、どうstateを分割するのかは悩ましいところがありますが、Organization含めてアカウント分離はしやすく安定して模範的な環境でしょう。2018年は、年始と年末でだいぶんTerraformへの取り組みや構成、CI、Atomic担保が構成、説明できるようになったので次に行きましょうという感じです。
GCPでも問題なく書くだけのリソースはあります。マルチクラウドがふつうなので、Terrafornを使うのは妥当な判断だと感じますが、もう少しいい手がないかは常に悩むものがあります。2019年はそこかしら。
なお、カクカク詐欺な記事を書いているのでちょっと待ってください。(いつリリースなの)
Ansible
Ansbile + Terraform + Packerはまぁ安定なのですが、あんまり好みではないのでいやですね。ここはもう少しなんとかならないかなぁ感とお付き合いします。
コンテナ
コンテナに関しては、普通に開発フローに組むのが楽で当然あってしかるべきな状況が一段と浸透しています。むしろコンテナを前提にしないとCI/CDの難易度が高いという方が適切にも感じます。
そういう意味では、.NET Core + k8sは良い流れで、来年はこれが普通かなぁと感じます。ローカル開発バックエンドならDocker-Composeでいいのですが。
AWS
2018年は、嫌い/苦手だったサービスに真正面から取り組んだのでちょっとは楽になりました。
Organizationsをベースに、マルチアカウントも楽になっているので引き続き楽になっていくでしょうし期待です。
stsの改善や2018年re:InventでAWSはいい感じにゆるさと硬さのバランスが取れてきたのはあって、とてもバランスが良くなったように感じます。
Azure
2018年最も触ったクラウドはAzureになりました。
Portalを除き、Terraformのみで扱える範囲に関してはずいぶんと楽になりました。一方でリソースの生成、削除の時間のかかりよう、Atomic性が壊れる当りの挙動が一年通して安定しないのでそんなものかなぁと割り切っています。Previewだから、というのが出てきて一向にGAにならなかったりするのは苦しいものがあります。
MSIが使いやすいので、MSIを標準的に使いたいところです。
初期はいいけどサービススケール時以降は使いたくない感じがありどうしようか悩ましいです。
AWSやGCP含めて使ってて感じるのは自分のサービスの最大の顧客が自分なんだなという感じに対して、「Azureの最大の顧客ってもしかしてMicrosoftじゃないのでは?」という感じがあり、Azureの今後に注目しています。
GCP
会社のメインクラウドはGCPです。理由はいくつかありますが、手間とスケールと安定のバランスから行くとちょうどいいというのがあります。
AWSだと手間が大きい、Azureは安定とバランスが好みではない、ちょうど自分がほしいのに近いのが現在はGCPです。
ヘビーに使うので、しばらくは注力が続くでしょう。
コミュニティ
2018年は、try! SwiftやCEDECに初めて参加しました。両方とても刺激的で面白かったです。会社のふるまいが見えるので、結構おススメです。
Yamagoya Meetup 2019やGoogle INSIDE、Serverless Conf 2018も参加しましたが、最高でした。また参加したいぐらいには。
Unity完全に理解したシリーズにも出てましたが、どれも学びがありました。「完全に理解した」は語句としては意味と内容がずれてるのでもう少しいい表現ないのかしら。
コミュニティに人が多いと私はすぐに逃げてしまうので、コミュニティ後の食事とかで見かけたらレアです。必要がない限り、今後も逃げます。
2018年は、書いているセッションノートを即公開することを試みてみました。Kibelaにセッションノートを書いているのですが、これをそのままはてなブログに張り付ける方式です。ここ数年文章構造を作りながら書くようにしているので余り困らない感じがあります。
記事
21本、すくないです。PowerShellが多いのはいいですが、あんまりよくないです。お手伝い先で週2-4本書いているのでそこで体力使っている感じがあります。2019年は、公開前提で書けるといいかもなので調整してみます。
ライフスタイル
睡眠時間が年間平均3時間10分だったので、もう少し寝るようにします。また、ランチを抜くとかなり快適に一日を過ごせるのが分かっており、朝夜ご飯を徹底するのがよさそうです。昼食べる場合は、炭水化物を抜けばよさそうです。
PCの利用状況、睡眠リズム、徒歩数を計測することで、ある程度自分の傾向と反省を週一で促せるのでキープするとよさそうと感じます。また、ストレッチをしていると体が楽なので、これも継続がよさそうです。
さて、自分の欠点である「個人に依存することはエンジンがかかるの遅い」を解消するために以下の対策をうちました。
- 消費時間を計測する
- YouTubeを
ウェブサイトブロッカー (Beta)でブロックする - 期限を設ける
- 一人でもセルフレビューをいれる
エンジンかかるのが遅いのは他のことに時間を費やすことから見えるはずなので、何にどれだけ時間をかけているかを計測することを始めました。
私は、Windows / macOS両方を使うので、Rescue Timeを使って一日のざっくりとした時間消費を測っています。
私は普段Chromeを使っているのですが、自宅の環境でウェブサイトブロッカー (Beta)を使うことで、YouTubeを完全にブロックしました。iframeは見られるので何かの記事のYouTube閲覧には困りません。
期限に関しては、Google Calendarでこまめにスケジュールに組むことを徹底することで、上手くいっています。
セルフレビューは、Geekbotを用いて自己報告をしています。感じるのは、「年配の経験つまれた方に一日1回レビュー受けるサービス」受けたいなぁと。*7
2019年は?
会社としては、2019年は作りたいサービスを形にして何本かリリースするため働き方をシフトします。*8 個人は、会社のサービスリリースと収益化です。注力する言語的にはC# / Golang 、ツールはTerraform + Kubernetes + GCP/AWS/Azure + Unityです。
2019年は2018年より、さらに(自他に)求められるレベルが高くなっており、天井知らずを感じつつ楽しみたいです。
あとは自分の習慣の改善なので、ガンバリマス。
