tech.guitarrapc.cóm

C#, PowerShell, Swift, Unity, Cloud, Serverless Technical Update and Features

2018年を振り返って

2019年になって4日経過しました。

2017年の振り返りに続いて、2018年の振り返りをしてみます。

tech.guitarrapc.com

目次

総合

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回目の延長は昨年で、部門立ち上げてアプリもいくつかリリースしたころで、「黒騎士と白の魔王」のリリース間近だった + クローズドβで問題が確認できないことから社内のモニタリング基盤を一新することになりリリースを成功させるために延長しました。

このモニタリングの変更によって開発から運用まで根底から取り組み変えることになったため、安定するまで見届けたいという思いがありました。このあたりはグラニの開発者ブログで書きました。

engineering.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本のコミットが混じっていてちょっとノイズがはげしいです。

f:id:guitarrapc_tech:20190105053411p:plain

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に似た気持ち悪さがあるのですが、フレームワークの成熟ってこういう感じかなぁとも感じるので、シカタナイ気もします。

一つ感じるのは、.NET Standard はかなりきつく、.NET Core 最高感です。特に .NET Core 2.2 から楽になった感じが大きいので、今後は .NET Core 2.2 /3.0 がスタンダードでいきたいところです。

相変わらずC# に感じるビルドが苦しいという状況は光明が見えないです。dotnet (msbuild) でのラップはいいのですが、制御しにくさがなかなか大きいです。

シングルバイナリくるくる詐欺が本当にくるっぽいので、期待しています。シングルバイナリ何がうれしいって、CI/CD/コンテナ でめちゃめちゃうれしいのです。

と書いていたところで、反応もらいました。

運用面はどうとでもなるんだけど、それは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本の執筆が決まり書き上げました。

tech.guitarrapc.com

反省も書いたので、次があれば生かすということで。

tech.guitarrapc.com

PowerShell 6.0 がリリースされ、6.1 がリリースされたことでPowerShellも .NET Core に踏み出しました。*6

PowerShell Coreについては本でも書きましたが、参考になるモジュールを用意していなかったので書いたのがUtf8BomHeader です。

tech.guitarrapc.com

私自身の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 を使って一日のざっくりとした時間消費を測っています。

www.rescuetime.com

私は普段 Chrome を使っているのですが、自宅の環境でウェブサイトブロッカー (Beta) を使うことで、Youtube を完全にブロックしました。iframeは見れるので、何かの記事のYoutube閲覧には困りません。

期限に関しては、Google Calendar でこまめにスケジュールに組むことを徹底することで、上手くいっています。

セルフレビューは、Geekbot を用いて自己報告をしています。感じるのは、「年配の経験つまれた方に一日一回レビュー受けるサービス」受けたいなぁと。*7

2019年は?

会社としては、2019年は作りたいサービスを形にして何本かリリースするため働き方をシフトします。*8 個人は、会社のサービスリリースと収益化です。注力する言語的にはC# / Golang 、ツールはTerraform + Kubernetes + GCP/AWS/Azure + Unityです。

2019年は2018年より、さらに(自他に)求められるレベルが高くなっており、天井知らずを感じつつ楽しみたいと思います。

あとは自分の習慣の改善なので、ガンバリマス。

*1:予定になく先方にも申し訳なかったです

*2:予定では7年前に起業だったので予定より遅れた

*3:あるいは働き方を変える

*4:事業計画通り

*5:Windows Containerではない

*6:リリースして初めて踏み出せる

*7:なんていうんでしたっけ、すごいいいなぁと思ったけど忘れました

*8:事業計画通り