以下の内容はhttps://tech.guitarrapc.com/entry/2018/01/01/050736より取得しました。


2017年を振り返って

どうやら2年に一度振り返り記事を書いているようです。

前回は2015年でした。

http://tech.guitarrapc.com/entry/2015/12/31/073146

例年も挑戦だらけですが、今年は踏み込みにくかったことへも挑戦の連続だったのでメモします。

総合

2015年の終わりにこう書きました。

個人的には、もう少しインフラやそれ以外にUnityを取り入れたりしたいです。C#に完全に技術基盤が移行しているので、PowerShellというよりC#を中心とした動きが強くなります。oloLensに胸を躍らせる日々です。

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からありますが、早々に予約しています。心から楽しみです。

https://www.tryswift.co/events/2018/tokyo/jp/

なお、おうちではSwiftを毎日書いていたり。

TypeScript

Swift + Firebaseが私のなかで鉄板のクライアント構成です。クライアントアプリ作るときにサーバーサイドを考えるなら、まずFirebaseでできるか考えるのが多くのシーンでは適切だと思っています。

さて、これまでもサーバーレスの処理にNode.jsをたびたび触っていましたが、FirebaseとなるとGoogle Cloud PlatformなのでCloudFunctionsです。言語対応の薄さから、あんまりと思っていましたが、Swiftを機会にさくさくTypeScriptも書いていてほとんど詰まらずに楽しめています。型のおかげな感じもありますが、VS Code + TypeScriptが相当書きやすくmacOS上で普段書いています。デプロイも楽ですし。

2018年も引き続きメインに据えてやっていくので、これもアウトプットできるといいですね。

Python

今年はあまり触る機会を作れませんでしたが、ちょろちょろデータ処理をするときに使っていました。Rの代わりじゃないですが、Jupyter Notebookつくときに触っています。言語自体は好みですが、書く機会の少なさが習熟の遅さにつながっている気がします。

しかし、Google Cloud触っているとPython 2.7なのが本当に苦しいのでいい加減3.xにしたい..。

PowerShell

発信を少なくしていましたが、他の言語もガッツリ腰を入れて触っていることもあり基礎から考えてみることにする機会でした。APIデザインやコーディングスタイルはその1つで、共有意識として何かしらの形でチームとしてもっておきたいものです。で、どうだったかというと、なるほど結構あるようでない。Verb-Nounのような、ずっと言われていることはともかく、このデザインはどのような意図なのかの、背骨となる考えが不透明な感じです。その場の対応が続いたのかな? という印象が拭えないのは直感と反する動き。

このあたりは、伝え方というか、体系としてまとめることが必要と感じており何かしら結果をだしたいので、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は比較的隙がなくてGCPもいいですね。個人でもGCPをメインにしています。

GAE / Firebase / CloufFunctions / Google Cloud Datastoreは、引き続き最も有力な選択肢です。SpannerやGKEは少し重いですが、まぁ初めから前提にするにはいいです。GCE Containerもそういう意味では便利です。

Fastly

Fastlyは、CDNの姿を変えました。いくつかの利用ケースを考えてきましたが、Fastly Yamagoya Meetup 2017は過去に見たCDNが主の勉強会で最高に熱く、素晴らしかったです。参加できたこと、学びを得たことが本当に幸せで徹夜して資料書いて参加できてよかったです。ちょうどスケジュール的に追い詰められていたこともありますが、もう徹夜はいやです。

https://techplay.jp/event/633461

CDNは今後のありかたは変わります。自分のプロダクトにて変えられるかが力量ですが、同時に最も楽しい挑戦でしょう。もっとFastlyの利用者増えてほしいです。国内で1位じゃないのが意味わからないです。*3

Datadog

黒騎士といえば、開発が2年続いた終盤のクローズドベータテスト中に「NewRelicを中心としてきたこれまでのモニタリングの仕組みでは監視がまともにできない」ことに気づきDatadog監視へ変えました。このあたりは黒騎士と白の魔王を支えるDatadogを使ったモニタリングにも詳細を書きました。

http://engineering.grani.jp/entry/2017/05/29/173141

何を使うのか、どう使うのか、どのようにモニタリングをみせるのかを今のモニタリングの考えから改めてゼロベースで考えて構築し、その後も継続的に更新できていてよかったです。すでに会社からNew Relicは一掃し、Datadogに集約することで、今までよりも一歩踏み込んだモニタリングに到達できました。

C#的にgRPCをどのようにやるといいのかを、@neueccとやり取りするなかで、neuecc/DatadogSharpとかも爆誕しました。.NETでもDatadog APM使えるのでぜひ、本番でも使ってます。@t_tetsuzinともASP.NET MVCでどう組むか、gRPCの時と違う挑戦をしましたが、これもキレものと一緒にがっつりやりきれて良かったです。

https://github.com/neuecc/DatadogSharp

さらに一歩先にすすめるための布石は積み重ねているので、また一歩いい感じにしたいです。そのあたりは2018年早々にさくさく実現します。

コミュニティ

コミュニティ活動は、アウトプットが要だと思っています。この意味でFastly Yamagoya Meetup 2017の1本だけしか出てないのは、相当ダメです。

https://techplay.jp/event/633461

ここは2018年の課題です。

勉強会に参加する中で、今年は「参加することに楽しむかどうか」が重要と感じました。特に、Google Cloud INSIDE Games and AppsとServerless Conf Tokyo 2017ではそれを強く感じ、効果的に感じました。だいたいなんでも「楽しむ」ことをモットーとしていますが、改めてなんでも、どんな自分の体調でもうまくセルフマネジメントできるかは自分自身のハンドリングなのでしょう。

記事

なんとまさかの14本。書いた数は最低です。内容もそこまで濃くもないので、これは単純にインプットの消化が間に合わず、記事を書く理由を自分で作れなかったことにあります。学びが多いのでアウトプットは本来多いのですが、まぁしかたないので今年書きましょう。

ライフスタイル

記事の要因ですが、深夜にちょっと時間をとるだけの体力がなくなってきた気がするのは、おやおやまぁまぁ。ライフスタイルも少し修正しないとなんでしょう。

2018年は?

流れは年末から変わらず。C# / Swift / TypeScript / Serverless / Containerがメインです。やること多いので、いっこずつ片付けます。

やりこんでできないより、やりきるは何より大事です。できるを最低条件に過程をよくするのは力量です。自分でハードルを挙げておいて、工夫してよじ登るのが続くのでしょう。

インフラ、サーバーサイド、クライアントサイドの視点からどうやるといいのかを考えられるようになったのが2017年の最大の獲得であり、今後試されます。ハードルあがった...。

*1:これは本当にダメとしかいいようないので、ネイティブはまちがいなくやった方がいいです。いやとかわからないと思ったら、なるべく早く。それが多少しか必要なくても、です。

*2:それが本当にそれかは常に学び続ける必要はあるし絶対的に正しいかは別ですが

*3:1位になるには帯域.....




以上の内容はhttps://tech.guitarrapc.com/entry/2018/01/01/050736より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14