どうやら2年に一度振り返り記事を書いているようです。
前回は 2015年でした。
tech.guitarrapc.com
例年も挑戦だらけですが、今年は踏み込みにくかったことへも挑戦の連続だったのでメモします。
目次
総合
2015年の終わりにこう書きました。
個人的には、もう少しインフラやそれ以外に Unity を取り入れたりしたいですね。C# に完全に技術基盤が移行しているので、PowerShell というより、C# を中心とした動きが強くなると思います。HoloLens に胸を躍らせる日々です。
2017年は、これが完全にシフトしてUnity やクライアントにシフトしていました。2016-17 にかけてはC# を中心としています。HoloLens もさんざん触っていました。アウトプット忘れてた。ここにメイン言語としては Swift / TypeScript が入ってきました。家も実はずいぶん前から MBP だったり。
引き続きやることは多岐にわたっていて、さらに頑張らないとなのですが、どう楽しむかも方も幅が広がったので引き続き楽しく過ごします。
プログラミング
2016年から続く流れとして、2017年も Unity + C# での開発が大きなウェイトを占めました。後半にSwift と TypeScript がメインの武器に入ってきたのは本当に良かったです。2018年は、C# / Swift / TypeScript / ShellScript / PowerShell あたりがよく使いそうと思いつつ。
ひたすらコード書いていた気もしますが、チームビルディング、マネージネントにも時間を割きました。まだまだ課題は多いですが、プロジェクトを楽しく完遂させることを主眼にどうやるといいか、毎日模索しています。
CSharp
お仕事として、黒騎士と白の魔王がリリースできたのは良かったです。
メインの武器としてこれまでもサーバーサイド、サーバーレス、ライブラリをよくやっていたのですが、クライアントも武器として働くようになりました。Unity でアプリを複数作りきったこともそうですが、サーバーサイド、サーバーレス、クライアントのいずれもをクライアントに比重を置きつつやっていました。表にだしたもので、Project Sonata や 黒騎士VRミュージアム を作ってました。黒騎士VRミュージアムは、Google VR SDK と Unity 5.6 の組み合わせですが、はじめから最後まで作りきったので、黒騎士のファンボックス的にも楽しんでもらえると嬉しいもので。Unity での開発基盤からチューニングまでやっていて、今までよりもパフォーマンスに気を配りつつUIや言語対応フローまで網羅していったのですが、考える事がまだまだ多くUnity 開発まだまだ楽にすることが多くていい感じですね。やることがなくなったと思ったらそこで進化がオワリなので、継続して向上していくのは重要だし、マインドとして失わないようにしたいです。
AzureFunctions や Lambda に代表される C# でのサーバーレス処理ですが、AzureFunctions が特に複雑度を増していてそろそろ苦しいです。仕方ないのですが。Lambda も何年もやっているとそろそろ API Gateway のめんどくささがあります。イベントベースとはいえ、このあたりの手間のかかりようから、AzureFunctions への完全シフトがなされました。Lambda いいんですが、やっぱり苦しい。後述する Cloudfunctions が颯爽と登場して、私の中では CloudFunctions 激熱です。
Unity といえば、Shader もごりごり触っていました。C# Script からの操作はあめぇ、と思いつつパフォーマンス気にしないでいい場面では便利なわけで。この辺りは、Shader まだまだ勉強足りないためつい逃げてしまって、ぐぬぬです。スクリプト処理よりも、ビジュアルへの影響が大きいものへのアクションは強化しないと苦しいです。ライティングはさすがに怖さはなくなってなれてますが、ビジュアル関連はどうも苦手ですね。物理演算の数学も使うものをしっかり学びなおさないと武器にできてない感じがあるので、課題です。画像のフォーマット、サイズも当然入ります。コンシューマの知識って大事。
サウンド周りも手を付けました。主にCRI ですが、なるほどこうやって制御するといい。というのを参考に一から組んでみましたが、うまく制御できてよかったです。自作のサウンドエンジンは別ですが、サウンドミドルウェアはものによって思想が違い、それがC# スクリプトのAPIにもよく現れていて、なるほどムズカシイ感あります。サウンドデザイナー、サウンドエンジニアと呼ばれる方々に学びっぱなしで、尊敬の念が深まるばかりです。サウンド、波、便利だけど習熟までのハードルは高い。それがVR や AR だとさらにやばい。サウンドヤバイ。
積極的な相談とそこから確実に学んでいくことは大事です。学べることは私にとって何よりも幸せと感じます。
.NET Core は可及的速やかにスタンダードになってほしいし、するべくと考えています。次の記事で少しそのあたりに踏み込みたいです。ビルドも、MSBuild きっついので、Gradleのようなスクリプトベースでの制御がほしいです。正直ちょっとやばい。
Swift
今年からの武器になりました。ネイティブをずっとやろうと思ってもにょもにょ触ってはうーんという感じでしたが、Swift4 できっちりやろうと思って始めました。Unity でもネイティブになる瞬間にしり込みする悪い傾向があったのも理由です。*1
Swift どんなのを何をしているかは別機会にまとめるとして、感触としてはやっていて楽しい/よく考え抜かれていて素晴らしい言語と感じます。どんな言語もそうですが、1つの言語をやると構文的な違いはあっても、考え方の根幹を学んで沿えば言語スタック、フレームワークの意図しているであろう良さを享受できると信じています。*2
Swift に関しては、幸いにしてコミュニティの熱気、先達の素晴らしい情報の共有があるので、これまでやってきた言語の中でも飛びぬけて入りやすい。楽しいを感じるまでのスパンが短いです。Xcode や Storyboard も使い方も知らないからはじまります。できないのではなく知らないという前提で、調べて学んでいくスタイルを徹底するように気を付けていますが、幸いにして多くを楽しく学ぶことができています。このまま学ぶ姿勢を絶やさず、今年は学んだことを記事にアウトプットしていきたいです。
主に@_monoさんから学んでいます。そろそろ Wishlist をみようとおもいます。Swift ですが、コミュニティ活動が国内海外を問わずすごいです。それが一番楽しい言語界隈の1つと感じるのかと思っています。TOKTYO - try! Swift が 2018年3月1日1 からありますが、早々に予約しています。心から楽しみです。
www.tryswift.co
なお、おうちでは Swiftを毎日書いていたり。
TypeScript
Swift + Firebase が私のなかで鉄板のクライアント構成です。クライアントアプリ作るときにサーバーサイドを考えるなら、まず Firebase でできるか考えるのが多くのシーンでは適切だと思っています。
さて、これまでもサーバーレスの処理にNode.js をたびたび触っていましたが、Firebase となると Google Cloud Platform なので CloudFunctions です。言語対応の薄さから、あんまりと思っていましたが、Swift を機会にさくさく TypeScriptに入ってほとんど詰まらずに楽しめています。あれ? と思うぐらいに、楽しく楽です。型のおかげな感じもありますが、VSCode + TypeScript が相当書きやすく macOS 上で普段書いています。デプロイも楽ですし。
2018年も引き続きメインに据えてやっていくので、これもアウトプットできるといいですね。
Python
今年はあまり触る機会を作れませんでしたが、ちょろちょろデータ処理をするときに使っていました。Rの代わりじゃないですが、Jupyter Notebookつくときに触っています。言語自体は好みですが、書く機会の少なさが習熟の遅さにつながっている気がします。
しかし、Google Cloud 触っていると Python 2.7 なのが本当に苦しいのでいい加減 3.x にしたい..。
PowerShell
発信を少なくしていましたが、他の言語もガッツリ腰を入れて触っていることもあり基礎から考えてみることにする機会になりました。APIデザインやコーディングスタイルはその1つで、共有意識として何かしらの形でチームとしてもっておきたいものです。で、どうだったかというと、なるほど結構あるようでない。Verb-Noun のような、ずっと言われていることはともかく、このデザインはどういう意図なのかの、背骨となる考えが不透明な感じがします。その場の対応が続いたのかな? という印象が拭えないのは、(PowerShell を使っていて慣れたころに出会う) 直感に反する動きからも、ふむと思います。
このあたりは、伝え方というか、体系としてまとめることが必要と感じており何かしら結果をだしたいと思うので、2018年の課題にします。
PowerShell Core が最もいいニュースであり、今後の進む道です。これはまちがいなく、PowerShell Team がオープンな場で常に挑戦に向かっていることが素晴らしいと思います。
ShellScript
Docker をmac上で使っていましたが、Windows でも使っています。さすがに勝手が違って戸惑いが多いのでいまいちmacほど使いやすくないのですが、だいぶんWindows上でのDockerも慣れました。
さて、Docker といえばなにぶんイメージを軽くするのに最低限しかいれないこともあり、DockerFile で ShellScript はサーバー運用でごりごり書いていたころほどでなくてもかなり使います。あんまり頑張りすぎないのが、PoweShell/ShellScript に共通する普遍的なお約束だと思っているのですが、そういう意味ではほどほどに、でも効果を強くできそうでいいですね。
言語的なスキキライが、あまりなくなってきたこともあり楽しくやってます。
インフラ
私が一番力を発揮できることは? と考えると、インフラというか基盤のように思います。そういう意味で部署を横断するインフラ的な考えはかなり好みなわけで。
Serverless
インフラ設計の基本であり、真っ先にどうやるとサーバーレスでシンプルに組めるか考えるようになりました。プラットフォームや処理によりますが、全般的なことはAzureFunctions でやっています。AWS リソースのイベントなら Lambdaです。
そのなかで クライアント主軸の開発にできる場合は、Firebaseとの相性から CloudFunctions を選ぶ選択が自分のなかで当然になったのは興味深く面白いです。C# 、サーバーレスでいいと思いきやスピンアップの遅さやデプロイのめんどくささがあり、なるほどマルチプラットフォーム、エコシステムについて考えるきっかけになりました。
インフラって、めんどくさいことを極限まで消すといらない存在なのですが、そこがインフラの良さでサーバーレスの良さなので、まだまだやることは多いです。
Docker
シェルスクリプトもそうですが、Serverless を用いれない場合のインフラの最小構成単位がコンテナです。どうやってやるかが設計の要ですがアウトプットを早めにしたいです。この辺りはまたいずれ。
前述したC# ですが、Docker 対応を前提に .NETCore は基本になるのが望ましいと思っています。マルチプラットフォームのエントリーポイントが Docker なので、Docker でどこででも(ポータビリティ) 動くことを前提に組むのは今後の最低要件となるでしょう。すくなくとも C# が大きく飛躍して生きていくには。Docker はいくつかの利用者視点での側面がありますが、アプリケーションの実行単位としてのDocker は、いろいろ便利というか言語が隠ぺいされる意味ではもっとも身近でもっとも導入しやすいでしょう。これは C# にとって、非常にアドバンテージとなりえます。
GCP
GCPへの傾倒と利用がとりわけ激しかったです。AWS に一番強い自覚がありますが、今年は GCP の利用頻度が半端なかったです。GCP 最高ではないし、課題も多いですが、クライントアプリ開発者としての視点からいくと、ほかのクラウドプラットフォームを大きく突き放して使いやすいです。正直AWS がつけ入るスキが今のところほぼない。Azureも AppCenter はいいですが、ほぼない。GCP でのエコシステムに乗れるなら乗るのが私は楽と感じます。
インフラとしてみても GCP は比較的隙がなくて、AWS -> GCP も GCP -> AWS も AWS -- GCP もいいと思います。個人でも GCP をメインにしています。
GAE / Firebase / CloufFunctions / Google Cloud Datastore は、引き続き最も有力な選択肢です。Spanner や GKE は少し重いですが、まぁ初めから前提にするにはいいです。GCE Container もそういう意味では便利です。
Fastly
Fastly は、CDN の姿を変えました。いくつかの利用ケースを考えてきましたが、Fastly Yamagoya Meetup 2017 は過去に見たCDNが主の勉強会で最高に熱く、素晴らしかったです。参加できたこと、学びを得たことが本当に幸せで徹夜して資料書いて参加できてよかったです。ちょうどスケジュール的に追い詰められていたこともありますが、もう徹夜はいやです。
techplay.jp
CDN は今後のありかたは変わります。自分のプロダクトにて変えられるかが力量ですが、同時に最も楽しい挑戦でしょう。もっと Fastly の利用者増えてほしいです。国内で1位じゃないのが意味わからないです。*3
Datadog
黒騎士といえば、開発が2年続いた、終盤のクローズドベータテスト中に、「NewRelic を中心としてきた、これまでのモニタリングの仕組みでは監視がまともにできない」ことに気づいて、一気にDatadog での監視の仕組みに変えました。このあたりは 黒騎士と白の魔王を支えるDatadogを使ったモニタリング にも詳細を書きました。
engineering.grani.jp
何を使うのか、どう使うのか、どのようにモニタリングをみせるのかを今のモニタリングの考えから改めてゼロベースで考えて構築し、その後も継続的に更新できていてよかったです。すでに会社から New Relic は一掃し、Datadog に集約することで、今までよりも一歩踏み込んだモニタリングに到達できました。
C# 的に gRPC的にどのようにやるといいのかを、@neuecc とやり取りするなかで、neuecc/DatadogSharp とかも爆誕しました。.NET でも Datadog APM 使えるのでぜひ、本番でも使ってます。@t_tetsuzin とも ASP.NET MVC でどう組むか、gRPC の時と違う挑戦をしましたが、これもキレものと一緒にがっつりやりきれて良かったです。
github.com
さらに一歩先にすすめるための布石は積み重ねているので、また一歩いい感じにしたいと思います。そのあたりは2018年早々にさくさく実現します。
コミュニティ
コミュニティ活動は、アウトプットが要だと思っています。この意味でFastly Yamagoya Meetup 2017 の1本だけしか出てないのは、相当ダメです。
techplay.jp
ここは2018年の課題です。
勉強会に参加する中で、今年は「参加することに楽しむかどうか」が重要と感じました。特に、Google Cloud INSIDE Games and Apps と Serverless Conf Tokyo 2017 ではそれを強く感じ、効果的に感じました。だいたいなんでも「楽しむ」ことをモットーとしていますが、改めてなんでも、どんな自分の体調でもうまくセルフマネージメントできるかは自分自身のハンドリングなのでしょう。
記事
なんとまさかの14本。書いた数は最低です。内容もそこまで濃くもないので、これは単純にインプットの消化が間に合わず、記事を書く理由を自分で作れなかったことにあります。学びが多いのでアウトプットは本来多いのですが、まぁしかたないので今年書きましょう。
ライフスタイル
記事の要因ですが、深夜にちょっと時間をとるだけの体力がなくなってきた気がするのは、おやおやまぁまぁ。ライフスタイルも少し修正しないとなんでしょう。必ずしも時間が取れないわけではないので、すこし自分に甘えているようなのでこれは失笑ものです。
2018年は?
流れは年末から変わらず。C# / Swift / TypeScript / Serverless / Container がメインです。やること多いので、いっこずつ片付けます。
やりこんでできないより、やりきるは何より大事です。できるを最低条件に過程をよくするのは力量です。自分でハードルを挙げておいて、工夫してよじ登るのが続くのでしょう。
インフラ、サーバーサイド、クライアントサイドの視点からどうやるといいのかを考えられるようになったのが2017年の最大の獲得であり、今後試されます。ハードルあがった...。
