tech.guitarrapc.cóm

Technical updates

VSTSの YAML Build Preview でビルド

Visual Studio Team Service (以降 VSTS) は、プロジェクト管理、Gitリポジトリ、CI (リリース含む) などソフトウェア開発を支援する結構大掛かりなサービスです。

私自身は CI の環境としては結構好き*1な一方他の機能はちょっと大掛かりと感じます。本記事では言及しませんが、パッケージ管理も便利です。*2

今回は VSTS でずっとほしかった YAML 定義からのビルドパイプラインについてです。ようやくYAML来たので少しは楽できそうです。

YAMLといっても、この VSTS 拡張じゃないので悪しからず。

https://marketplace.visualstudio.com/items?itemName=adamvoss.yamlmarketplace.visualstudio.com

目次

参考資料

ある程度概要をつかみつつ詳細を見通すのには、このあたりを見ておけばいいと思います。英語記事も含めて触ってみた、こんな感じという内容が多いのは利用者の絶対数と、他CIに比べて Yamlでの調整がしにくいのが大きい感じがします。(GUI でのパイプライン構築が強いのもありますが)

kkamegawa.hatenablog.jp

docs.microsoft.com

azure-pipelines-agent/yamlgettingstarted.md at master · microsoft/azure-pipelines-agent · GitHub

概要

従来 VSTS ではWebポータルからGUIでビルドパイプラインを構築していました。このあたりは、CircleCI や Travis、AppVayor に慣れてると不思議な感覚です。

VSTS の YAML Build とは、簡単にいうと Circle CI のような yaml 定義でのビルドパイプライン構築ができるというものです。慣れた手法ですね。なお、ビルドパイプラインだけなので、Push連動などビルドタイミングやオプション設定はできません。

さて、ではGUI での構築はどうなんでしょうか? YAML を使いたいだけの理由があるのでしょうか?私にとっては、ものによる、と思います。ビルドの95%はシンプルなので YAML がベターです。一方でその場でインスタントに組むにはGUIも悪くないでしょう。

今がPreview だからこそ、感覚として他のビルドで慣れた肌感との違いをメモしておきます。

GUI のメリット

  • リポジトリにコミットがいらないので CI ビルドのためにコミットを重ねる必要がないのはあるあるでしょう。*3
  • パイプラインを作っていてある程度複雑になっても意外とやりやすいと感じます
    • yaml ですこし細かいことをしたときに読み解かなくてもパッとみたいことに目線のスコープを絞れるのは GUIの良さでしょう

GUI で困ること

  • GUIで1つずつのパイプラインを組むので、どんな構成なのかをざっと把握するには不便です。全体の普遍的な把握にはだるいです
  • ビルド構成のクローンからの作成が可能ですが、まとめて直したいときには1つずつ直す必要があって容易に刺身タンポポになります
    • ビルド職人さんはほぼ発生しないのですが、刺身タンポポさんが発生しやすいのは由々しき欠点です
  • リポジトリごとに決まったパターンでのビルドを、ビルド構成/デプロイ先の些細な差異で構築したときに面倒さが爆発します
    • ビルドパイプラインは単純を維持するのがいいので、Parallel にパラメータ変更で回すなどは避けるべきです
    • 一方で、似たビルドが多数できても違いを把握するのは大変でしょう

YAML ビルドの利用開始前作業

YAML ビルドを試す前にちょっとだけ準備です。

アカウントをとる

VSTS にアクセスして適当にアカウントをとっておきます。無料です。Hosted Agent でマネージドビルドができるので、まぁあってもいいかなぐらいです。

www.visualstudio.com

YAMLビルドの有効化

まだ YAML Build は Preview 機能なので有効化が必要です。

  • アカウントのアイコンから Preview features を開く

  • ユーザーアカウントではなく 作成した VSTS アカウント全体の設定に切り替えます for this account
  • Build YAML definitions を on に変更

これで準備できました。

YAML でビルドパイプラインを書いてみる

では本筋です。ドキュメントは本家を見ておけば大丈夫だと思います。

azure-pipelines-agent/yamlgettingstarted.md at master · microsoft/azure-pipelines-agent · GitHub

YAML 定義をする前にどんな定義なのか見る

適当にビルドをWebポータルからポチポチ組むと YAML でどう定義するのか見られます。便利。

View YAML からYAML をプレビューしてみました。

なるほどいい感じです。

gist.github.com

リポジトリに YAML 定義を置いてみる

ではプレビューした YAML使ってビルドプイプラインを定義してみましょう。コピペです。

github.com

ビルドパイプラインをYAMLで作る

書いたYAML からビルドパイプラインを作ります。

VSTS で作業しましょう。

YAML によるビルド定義を作る

VSTS の Build and Release > Build からビルドを新規作成します。

新規ビルドジョブを作ってみると YAML が選択できるようになっています。

Agent Queue の選択

適当に名前を付けたら、Agent Queue を選択します。2018/1/24 現在は、YAML ビルドは マネージドビルドであるのみサポートされています。

  • Hosted VS 2017
  • Hosted Linux Preview
  • Hosted macOS Preview

https://docs.microsoft.com/en-us/vsts/build-release/actions/build-yaml

今回は C# プロジェクトなので Hosted VS2017 を選択します。

YAML パスの指定

YAML ビルドは、Git ソースパスとして Github か VSTS がサポートされています。YAML はリポジトリ内の任意のパスを指定できます。ルートが一番楽で、.vsts-ci.yml がドキュメントで記述されている名前ですが他でもok です。

今回は、v2 フォルダ配下に置いたので、v2/.vsts-ci.yml と指定します。

ビルドリポジトリの指定

Get Source からビルドリポジトリを指定します。Github からぽちっと。

Submodule など チェックアウトオプションの指定

YAML 定義の リポジトリのチェックアウト指定には制約があります。

https://github.com/Microsoft/vsts-agent/blob/master/docs/preview/yamlgettingstarted-features.md

  • YAML 上では Submodule checkout を指定できない
  • Build Report の有効化が指定できない

しかしこれらは、UI上でリポジトリのチェックアウトとしては有効化がかのうなので必要に応じてUIで有効化すればいいでしょう。

環境変数の設定

YAML 内部でも Variables は定義可能です。が、ビルドによって変わるものやシークレットは当然入れなくないでしょう。

https://github.com/Microsoft/vsts-agent/blob/master/docs/preview/yamlgettingstarted-phase.md#variables

CircleCI でもそうですが、シークレットな情報は環境変数に鍵付きマスクで設定しておけます。

ビルド実行

ビルド設定ができたらこれでおしまいです。Save & Queue でビルド開始してみましょう。

なお、YAML の定義がおかしい場合、Queue 実行時にわかります。ちょっとタイミング遅いですね。

問題なく YAML が解釈できればビルドが開始するでしょう。

ビルド画面

ビルド画面はリアルタイムでビルド状況が表示されます。ここで YAML のパイプラインがわかります。ビルドUIでわからないのがやはり嫌ですね。

うまく変数も解釈され、ビルドが成功しました。

まとめ

Hosted Agent でしか動かないのが苦しいですが、おおよそ機能は満たしていていい感じです。

VSTS をこれからちょっと使ってみる、iOS ビルドで触ってみる (Hosted Agent on macOS) 場合にはYAML定義が慣れ親しんでいることが多いのでいいと思います。他のビルドサービスより癖が強く YAML 定義のハードルが高いのでなんとかしてほしいですね。

現状の利用シーン

エージェントが弱いのでほどほどの開始から、という印象ですが Private Agent がきたらすぐにでも使えそうですね。

  • Recommend: Your Project is Simple enough includes pipeline count and parameters
  • Recommend: Your Project is referencing variables with many pipelines. yaml offers easy view checking
  • Accept: yaml <-> pipeline conversion is not available
  • Accept: Private Agent is not available

VSTS yaml ビルドのここが苦しい

  • Checkout options: Tag sources, Report build status, Checkout submodules
  • Hosted Agent のみ対応
    • Private Agent対応していないので強いのがほしいときに非力
    • Hosted Agent がかなり非力で大きなリポジトリのビルドが現実的な時間でできないので致命傷になりかねない
  • パラメータなに使えるかとか初見殺し
    • ぽちぽち作成 -> yaml 生成しないとむりぽ
    • Circle CI とかだとコマンド実行しか露出させないのに対してパイプラインのカスタム要素で構築していく VSTS スタイルだときっつい
    • Store のパイプラインのところとかで、パラメータ提供してくれないときつそう
  • yaml定義はパイプラインには出ない
    • パイプラインの途中だけ無効とかが当然できない
    • パイプラインの内容を yaml 翻訳はできても yaml -> パイプライン翻訳ができてないので制約としは自然
  • yaml -> ふつうのパイプライン、ふつうのパイプライン -> yaml の変換ができない
    • 新しく作るしかない...

ここは嬉しい

  • dotnet みたいにグループ定義になっている場合にParameters として変数見えてるので設定しやすい
  • ビルドステップが単純なら各ブランチビルド定義が楽ちん
  • 変数が定義しやすいのは相当楽。見通しいい
  • UIぽちぽちから yaml 出力できるので定義が楽にテンプレート組める
    • ただし、これがただしいとは限らない
    • 変数が抜けていたりする

*1:Windows な Managed CI Service は VSTS か AppVeyorぐらい

*2:Git リポジトリを Github 以外で管理するメリットがかなり薄いのもあり微妙

*3:ブランチ切って履歴から抹消という手もありますが、そこはチームにお任せで

.NET Core App を Docker コンテナとして公開する

C# を使っていて最も困るのがランタイムと感じます。

C#は書きやすい、Visual Studio も使いやすいは良く耳にします。実際享受しやすいメリットだと思いますが、C# を Windows 以外で実行したいはどうでしょうか?

今回はその実行方法についてコンテナを用いるのはどうかと考えたメモです。

※ モバイルではなく、サーバー/デスクトップにおけるアプリケーションについて考えます。

目次

感じる課題

.NET を実行するときにはランタイムが必要です。現在、 Windows / macOS / Linux など色々な環境で同じように動かす場合は .NET Core が用いられます。簡単に実行を実行を確認したい、さくっと試したい、使いたいというユースケースが大半を占めるのではないでしょうか。

これをはじめに考えてみます。

ランタイムの導入

ローカル開発でランタイムが入っている方が便利と感じるシーンは多いです。これは、エディタ/IDEでの開発でSDKやランタイム参照をしつつ動的に解決することが多いためで、「開発したい」に対して「インストール、導入」という手間なコストをかけても割が合うことが多いです。またツーリングからみても、今はまだランタイムをインストールする方が様々なツールとの統合も楽でしょう。*1

ではサクッと動かしてアプリを試したい。場合はどうでしょうか? 例えば、 .NET Core で書いたC# アプリを macOS で動かしたい、Linux で動かしたい*2、あるいはRasPi で動かしたい、むしろ Windows Server では? このような色々なプラットフォームで動かす場合は事情が変わると思います。

私は、動かしたいプラットフォームに合わせて「動かす」、ただこれだけのためにランタイムを入れるのは大変と感じるぐらいにはぐうたらです。いい感じのアプリがあった!ワンオフで動かしたい!.NET Core を使って動かせばいいの?そのランタイムはどうやって入れるの?なるほど、ランタイムをダウンロードしてインストールをこのアプリだけのためにするの.... 更新は? 実行の保証は? 面倒です。*3

例えば .NET Core の場合環境に合わせて実行ランタイムがあるのはご存知の通りです。

www.microsoft.com

C# をWindows で実行する分には.NET Framework が初めから入っていることもあり気にならなかったことが、マルチプラットフォームだとおっくうと感じるのが、今*4のC#に感じる障壁の高さと思っています。

実行保証

「アプリのロジック」ではなく、「アプリをどう実行するか」が C# にとっては大きな課題に感じると書きました。*5

他に気になることとして「プラットフォームでの実行保証」があります。環境によって動かしてみたら予想外の挙動をした。というのは、C# に限らず良くあることで様々な言語が平等に持つ課題です。

これも解決は単純で、手元に環境があればいいでしょう。では、環境どうやりましょうか、めんどくさくないですか?

コンテナはどうなのか

これらの課題は、Docker をはじめとしたコンテナ*6で一定の改善が期待できます。*7

例えば配布するコンテナイメージにランタイムが入っていれば、利用する側は docker run するだけで ランタイムを隠蔽*8して機能を実行できます。これは多くの言語で作成されたツールが活用しているようにC# だってもちろん同様にできます。

また、Windows でも macOS でもローカルコンテナでの動作が確認できれば、そのコンテナイメージを配布することで同じ挙動が期待できます。ポータビリティの高さは重要なのは言わずもがなです。

S3Sync - .NETCore で S3同期するツール

x00万を超える大量のアセットファイルを配信したいということをしたくなったときに、S3などのオブジェクトストレージがパット思いつきます。*9これを現実的な速度でS3と同期するためにツールを作りました。*10数年前に PowerShell で同様の同期ツールを書いたのですがx000ファイルを対象に書いていて大量のファイルだと遅かったので C# で書き直ししたものです。

Github にて S3Sync として公開しました。

github.com

ツールは、docker でも利用可能です。これは Dockerfile 専用のリポジトリを別途用意しています。

github.com

Docker hub はこちら。

https://hub.docker.com/r/guitarrapc/s3sync/

どんなことをしているのかを通して、Docker として公開する良さを考えてみます。

Docker hub での公開用リポジトリ

もともと単一リポジトリにしていたのですが、Docker hub での automated build と コードの更新/バージョン管理とずれるため分離しました。他のDocker Automated build をしている人も同様にしているようなので、まぁこれが素直なのかなと思いますがいいアイディアあったら教えていただきたく...。

今は、s3sync-docker リポジトリのmater/tag を使って自動ビルドしています。

これでバージョンに応じたタグでイメージも公開されるので楽ちんです。

docker hub 用の Dockerfile は、コード側リポジトリの指定バージョンのリリースに仕込んだバイナリを持ってくるようにして、コードのバージョンとコンテナのバージョンを合わせています。

FROM microsoft/dotnet:2.0-runtime
WORKDIR /app
ENV S3Sync_LocalRoot=/app/sync
RUN curl -sLJO https://github.com/guitarrapc/S3Sync/releases/download/1.2.0/s3sync_netcore.tar.gz \
    && tar xvfz s3sync_netcore.tar.gz \
    && rm ./s3sync_netcore.tar.gz
CMD ["dotnet", "S3Sync.dll"]

.NET Core と .NET4.7 ビルド対応

両方のビルド対応は、凝ったことはしておらず <TargetFrameworks>netcoreapp2.0;net47</TargetFrameworks> のみです。

https://github.com/guitarrapc/S3Sync/blob/master/source/S3Sync/S3Sync.csproj#L6

Docker でのアセンブリビルド

Visual Studio の Docker Support が、いまいちイケテナイというか結構癖あって docker 触るだけのためにその構成は苦しい。ということで、ベースとしつつ組んでいます。*11

Microsoft からはこのあたりで

docs.microsoft.com

Docker からも出てるのでこのあたりみつつがいいです。

https://docs.docker.com/engine/examples/dotnetcore/docs.docker.com

Docker for Windows / Docker for Mac だけ入れておくと Docker 操作ができます。*12

さて、dotnet build ビルドを、VSと docker のどちらでも行えます。Docker を使ったビルドが楽なのは手元にdotnet ランタイムがなくてもビルドできることで、ビルド結果がどのOSでも変わらず取得できます。.NETCore をビルドするのにランタイムが必要、という都合を気にしないで使うというのは良さを感じます。

Docker でのビルドをするにあたり、以下のような docker-compose.yml を用意してあります。

version: '3'

services:
  ci-build:
    image: microsoft/dotnet:2.0-sdk
    volumes:
      - .:/src
    working_dir: /src
    command: /bin/bash -c "dotnet restore ./S3Sync.sln && dotnet publish ./S3Sync/S3Sync.csproj -c Release -o ./obj/Docker/publish -f netcoreapp2.0"

S3Sync/source パスで docker-compose -f docker-compose.ci.build.yml up をコマンド実行することでdocker コンテナ内部で dotnet build が実行され、S3Sync/source/S3Sync/obj/docker/publish にdotnet build によって生成されたアーティファクトができます。

$ docker-compose -f docker-compose.ci.build.yml up
Starting source_ci-build_1 ...
Starting source_ci-build_1 ... done
Attaching to source_ci-build_1
ci-build_1  |   Restoring packages for /src/S3Sync.BenchmarkCore/S3Sync.BenchmarkCore.csproj...
ci-build_1  |   Generating MSBuild file /src/S3Sync.BenchmarkCore/obj/S3Sync.BenchmarkCore.csproj.nuget.g.props.
ci-build_1  |   Generating MSBuild file /src/S3Sync.BenchmarkCore/obj/S3Sync.BenchmarkCore.csproj.nuget.g.targets.
ci-build_1  |   Restore completed in 225.41 ms for /src/S3Sync.BenchmarkCore/S3Sync.BenchmarkCore.csproj.
ci-build_1  |   Restoring packages for /src/S3Sync.Core/S3Sync.Core.csproj...
ci-build_1  |   Restoring packages for /src/S3Sync/S3Sync.csproj...
ci-build_1  |   Generating MSBuild file /src/S3Sync/obj/S3Sync.csproj.nuget.g.props.
ci-build_1  |   Generating MSBuild file /src/S3Sync.Core/obj/S3Sync.Core.csproj.nuget.g.props.
ci-build_1  |   Generating MSBuild file /src/S3Sync/obj/S3Sync.csproj.nuget.g.targets.
ci-build_1  |   Generating MSBuild file /src/S3Sync.Core/obj/S3Sync.Core.csproj.nuget.g.targets.
ci-build_1  |   Restore completed in 78.35 ms for /src/S3Sync.Core/S3Sync.Core.csproj.
ci-build_1  |   Restore completed in 74.78 ms for /src/S3Sync/S3Sync.csproj.
ci-build_1  | Microsoft (R) Build Engine version 15.5.179.9764 for .NET Core
ci-build_1  | Copyright (C) Microsoft Corporation. All rights reserved.
ci-build_1  |
ci-build_1  |   Restore completed in 18.76 ms for /src/S3Sync.Core/S3Sync.Core.csproj.
ci-build_1  |   Restore completed in 3.33 ms for /src/S3Sync/S3Sync.csproj.
ci-build_1  |   S3Sync.Core -> /src/S3Sync.Core/bin/Release/netcoreapp2.0/S3Sync.Core.dll
ci-build_1  |   S3Sync -> /src/S3Sync/bin/Release/netcoreapp2.0/S3Sync.dll
ci-build_1  |   S3Sync -> /src/S3Sync/obj/Docker/publish/
source_ci-build_1 exited with code 0

$ ls S3Sync/obj/Docker/publish

Docker コンテナビルド

コンテナと配布するにはローカル実行を試しておきたいので、コンテナイメージのビルドもしましょう。これも 以下のような docker-compose.yml を用意してあります。

version: '3'

services:
  s3sync:
    image: guitarrapc/s3sync
    build:
      context: ./S3Sync
      dockerfile: Dockerfile

ローカルビルド用の Dockerfile は次のようなものです。

FROM microsoft/dotnet:2.0-runtime
ARG source
WORKDIR /app
ENV S3Sync_LocalRoot=/app/sync
COPY ${source:-obj/Docker/publish} .
CMD ["dotnet", "S3Sync.dll"]

S3Sync/source パスで docker-compose build をコマンド実行することでdocker イメージがビルドできます。

$ docker-compose build
Building s3sync
Step 1/6 : FROM microsoft/dotnet:2.0-runtime
 ---> c3e88dec1c1a
Step 2/6 : ARG source
 ---> Using cache
 ---> 647c269a901b
Step 3/6 : WORKDIR /app
 ---> Using cache
 ---> 6b3ed8b5ba59
Step 4/6 : ENV S3Sync_LocalRoot /app/sync
 ---> Using cache
 ---> 0e5b9c7353eb
Step 5/6 : COPY ${source:-obj/Docker/publish} .
 ---> 9eef14226f86
Step 6/6 : CMD dotnet S3Sync.dll
 ---> Running in 8ceb9cd9194d
 ---> 7e32766ae910
Removing intermediate container 8ceb9cd9194d
Successfully built 7e32766ae910
Successfully tagged guitarrapc/s3sync:latest

イメージの生成 は docker image ls で。

$ docker image ls
REPOSITORY                   TAG                 IMAGE ID            CREATED             SIZE
guitarrapc/s3sync            latest              b33b90c72cee        6 hours ago         220MB

ローカル実行

exe / .NETCore / Docker のいずれもローカル実行ができます。IAM Role で認証をバイパスできない場合は、AWS Credential Profile を利用します。*13

同期パラメーターは、引数か、環境変数で指定できます。デフォルトで DryRun が有効になっているので、同期を実行する場合は「引数で DryRun=false」 か 「環境変数 でS3Sync_DryRun=false」 してください。

https://github.com/guitarrapc/S3Sync#configuration

# Full .NET
$ S3Sync.exe BucketName=your-fantastic-bucket LocalRoot=C:/Users/User/HomeMoge DryRun=false
# dotnet core
$ dotnet S3Sync.dll BucketName=your-awesome-bucket LocalRoot=/Home/User/HogeMoge DryRun=false
# docker
$ docker run --rm -v <YOUR_SYNC_DIR>:/app/sync/ -e S3Sync_BucketName=<YOUR_BUCKET_NAME> -e AWS_ACCESS_KEY_ID=<YOUR_ACCESS_KEY> -e AWS_SECRET_ACCESS_KEY=<YOUR_SECRET> S3Sync_DryRun=false guitarrapc/s3sync

Docker イメージは Windows/mobyLinux/macOS 上で動作を確認しています。

速度

ベンチマークを測る中で速度自体は、.NET4.7 も .NETCore2.0 もあまりずれは出ていません。

.NET Core で遅くなるかもと思っていたので、なるほど計測大事。

ec2 で実行しているのですが、CI の記録では 20000ファイルで20sec 程度のようです。350000ファイルぐらいだと、初回のアップロードが6minで、以降差分であれば100sec 程度のようです。

Complete : Calculate Diff. 10.01sec
-----------------------------------------------
Start : Upload to S3. New = 0, Update = 0)
-----------------------------------------------
Complete : Upload to S3. 0.11sec
-----------------------------------------------
Start : Delete on S3. (0 items)
-----------------------------------------------
Complete : Delete on S3. 0sec
===============================================
Detail Execution Time :
-----------------------------------------------
Obtain S3 Items : 3.32sec
Calculate Diff  : 10.01sec
Upload to S3    : 0.11sec
Delete on S3    : 0sec
-----------------------------------------------
Total Execution : 13.44sec, (0.22min)
===============================================
===============================================
Show Synchronization result as follows.
===============================================
| TotalCount  | New  | Update  |  Skip  | Remove |
| ----------: | ---: | ------: | -----: | ------: |
|      20000  |   0  |      0  | 20000  |      0 |
Complete : Synchronization. 13.69sec
Total. 20.54sec

MSDeploy のようなファイル同期だと恐ろしく時間がかかりますが、S3などオブジェクトストレージだと手早くできるのはいいですね。

課題

.NETCore だと、大量のファイルを送信すると時々通信が打ち切られる現象を確認しています。何度か遭遇しているのですが、発生原因がいまいち見えず困っています。そのため、.NET4.7 で実行するのが安定していて、こまったちゃんです。

github.com

まとめ

docker run で C# で書いたアプリが実行できる。dockerを日常的に触っていると、アプリを試したりどこか環境を変えて利用するには一番楽です。

利用する側にとって「使うための準備を最小限にする」というのは重要だと考えています。この意味で、これから .NET Coreで書かれたアプリが どんどん Docker で公開されるといいですね。特に、ASP.NET Core MVC とかは nginx 同様ホスティングするだけなのでやりやすいわけで。

*1:APIやHTTP(S) など通信で隠蔽できない場合を想定しています

*2:ディストリは本質ではないのでおいておきましょう

*3:もちろんやってきたのですが、面倒だと思っています

*4:そしてこれから

*5:個人の感想です。私がC# を各環境で動かすにあたっていつも感じる感想であって、読んでいる方にとっては別の課題をお持ちだと思います

*6:ハイパバイザーでいい人はそれでいいんじゃないでしょうか

*7:必ずしも最善ではないですが、現状では現実解として妥当と思います

*8:カプセル化と言い換えてもいいです

*9:BlobでもGCSでも好みで置き換えてください

*10:aws clie の s3 sync だと大量データの同期がCaused by : [Errno 104] Connection reset by peer) でおちるのもある

*11:dotnet restore できなくするのはワカルけどその解決でなぜ納得すると思うのか

*12: Linux Containers on Windows (LCOW)を使う - http://www.misuzilla.org/Blog/2017/12/27/Lcow を使うともうちょい楽そうです

*13:aws configure でも AWS Tools for PowerShell でも VS でも生成できるのでご随意に

2017年 に使ったサービス

選択はいたってシンプルにしています。

  • 基本的に無料のサービスでいいものがあれば使う
  • 有料のサービスでしかない場合は、必要性に応じて使うようにしている
    • 有料サービスはサブスクリプション以外は使わないようにしている

この状況って、いつでも状況に合わせてやめたり変更が効くようになるのだが、逆にいくらだったかなとなってしまうように思うです.... Money Foward できっちり管理してみようかしら。

ここで1回書き出します。

わたしの考えはごく単純です。

目次

有料継続

はてなブログProと GitKraken が異様に大きいですね。GitKraken はいいのですが、はてなブログ Pro は本当に変え時かもしれない。

サービス名 価格 種類 用途
AWS $2.64/month クラウド Route53 / Lambda / S3
Flawless $30/永年 iOS開発 デザインとシミュレートの確認
Github $7.00/month DVC Private Repository が使いたいのとメインストリームだから
GitKraken $49/user/year Git GUI Git 操作にWindows/Mac 両方で利用
G Suite Basic ¥600/user/moth オフィス Gmail / Group / Calendar / Drive & Document / Photo
Google Play Music ¥980/user/month 音楽 Google Home からの音楽再生
Jump+ ¥900/month 雑誌 そろそろおわりかな
TeamsId $3/user/month パスワード管理 チーム管理の楽さが神がかってる
Udemy コース次第 スクール 技術系の動画スクール
Zaim Premium ¥360/month 家計簿 キャッシュフロー管理
はてなブログPro ¥8434/year ブログ 今使ってるマネージドなブログサービス

AWS

Route53 のみで課金されている。そろそろ GCP にしようと思っているのでRoute53 解約の兆し。(実は DNS 管理なら GCP のほうが安い)

Flawless

ちょうど安かった時に$15かったのでした。iOS 開発にめっちゃオススメ。

applech2.com

Github

2013年からずっと使い続けているが、Private Repository が数無制限になってかなり使いやすくなりました。

LFS は個人では使う必要なくて使ってない。

GitKraken

SourceTree を長年使っていて、どんどん操作が重くなっていったので乗り換え。

GitKraken にして、操作の待ちが消えた、Branch/Tag付けの操作容易さ、Conflict 解決が非常に楽になったことでかなりメリットを享受できています。

G Suite Basic

もともと会社で G Suite 使うにあたって普段から使い慣れておこうと思って始めたのがきっかけ。

Email 登録系のサービスによって グループメールにしたりオフィス系をこっちに寄せていて、完全に基幹になってる。

あと、使うサービスが Google 認証に対応しているかが利用の基準にもなってる。(SSO は大事です)

Google Play Music

Google Home で音楽を再生するにあたり、Spotify と悩んだ。

選択理由は使い勝手が一番の理由。Spotify がジャンル指定とか使いにくいと感じる一方で、Google Play Music は苦しさがなかった。

あとは、自分が聞く曲の多くがGoogle Play Music にあって Spotify になかった。(クラシックが多いです。ようは演奏者 * 曲の組み合わせ)

Jump+

OnePiece や Stone world が特に面白いです。読まずに忙しさにかまけることがあって、忙しさのバロメータにしていたり。

でもそろそろおわりかなぁ。

TeamsId

Meldium おわったので乗り換え。チームレベルでのパスワード管理できるのは本当に楽。

使ってて不満はほぼない*1

Google ログインえらい。

Udemy

知らないことを学ぶのにいい。

Zaim Premium

家計簿なのですが、クレジット連携したくてプレミアムにしたもののよく連携きれるしもういや。ってことで 2017年はほぼ能動的に使わずに過ごしてしまいました。

Money Forward を実は契約だけしてあるので、切り替え予定。

はてなブログPro

WordPress.com から はてなブログに移行してずっと使ってる。

主にカスタムドメインがProを使いたい理由。

はてなブログを選んでいる理由は、マネージドサービス + SEO 流入の良さ から。

ただ、https 移行のアクションの遅さを見るとそろそろやめようかと思ったり。Medium 一度試して辞めたのですが、記事の書き方を変えて使うようにしようかな?

Google ログインできるのえらい。

無料継続

サービス名 価格 種類 用途
Azure 無料 クラウド AzureFunctions / AppService / AKS メイン
CircleCI 無料 ビルド ビルド全般
Cloud Craft 無料 AWS構成図 構成図を描くのに便利
Docker Hub 無料 CR コンテナリポジトリ
Eight 無料 名刺 名刺管理
Fastly 無料 CDN 検証に Developer Account で。
Google Analytics 分析 はてなブログの分析
Google Adsense アド収入 やらないよりやってみようで
Grammarly 無料 校閲 英語の校閲
Heroku 無料 PaaS Python 系とか乗っける時に
inVision 無料 プロトタイピング 他はいらない
Kibela 無料 Wiki ドキュメント/Wiki/ Blog / 勉強会メモ
GCP 無料 クラウド Firebase / Cloud Functions
Slack 無料 チャット 通知とかチャット、メモ、RSSとか
Visual Studio 2017 Enterprise MVP特典 IDE C# での開発全般
Visual Studio App Center 無料 ビルド iOS/Androidビルド
Visual Studio Team Service 無料 ビルド Windows系/Azure系ビルド
Wunderlist 無料 TODO TODOの管理
一休 無料 予約 レストラン、ホテル他

Azure

主に技術検証や無料内でのサービス利用なので無料枠で足りてる。

AzureFunctions の JapanWestPlan (Consumption: 0 Small) だけ $5.7 と思いきや、Visual Studio Enterprise の枠ないで収まっており無料。

Circle CI

ビルドサービスとして利用している。2.0 でコンテナになっていい感じ。

iOS ビルドどうするか検討中。

ビルドサービスは複数扱えると何かと良さの検討になるので無料内は使っておく

Cloud Craft

AWS の 3D的な構成図書くのにちょくちょく使ってる。

Google ログインできるのえらい。

Docker Hub

コンテナのリポジトリ管理

Eight

名刺管理最高。名刺もらってもすいませんがいらないです。Eight で交換が最高。

Fastly

開発向けの Developer Account の範囲で検証に利用。

GCP

Firebase や Cloud Functions に使っているが無料内なので課金なし。

当然ですが、Google ログインできるのえらい。

Google Analytics

はてなブログの閲覧はこいつでとってます。

Google Adsense

広告を出さないための Pro だからこそ、広告ってどれぐらいの効果で目的を持てるのかを測るために入れてみました。

Grammarly

たいぽつぶし、経度な文法のミス。

Heroku

なにかとしれっと乗っけるには便利。最近は使う頻度減った。

GAE でいいかなという気分。

inVision

もう他いらないです。最高。free で結構十分使える。

Kibela

esa.io をドキュメントに利用していたが、個人利用の範囲だと kibela でいい気がしてきたので乗り換えた。

Google ログインできるのえらい。だが、一度ログインしてから設定なのは結構いや。イケテナイ。

Slack

チャットはこいつ。今のところ他いらない。

Visual Studio 2017 Enterprise

以前は Pro 買ってた。個人で使う分には、Visual Studio Community で困らない感じする。

CodeLens が Community にきたのは大きい。

Visual Studio App Center

モバイルビルドに使っている。

ビルドサービスは複数扱えると何かと良さの検討になるので無料内は使っておく

パイプラインが使えず、割り込み処理をスクリプト定義なのでいや。

Visual Studio Team Service

Windows 系のビルドに使ってる。

ビルドサービスは複数扱えると何かと良さの検討になるので無料内は使っておく

Wunderlist

TODO として。なくなるらしいけど乗り換え先見つからない...。

一休

便利。好きな会社、好きな人が働いていることもあるけど、必要な時に重宝してる。

普段からは使ってない。

解約したサービス

サービス名 価格 解除 用途
esa.io ¥500/user/month Wiki ドキュメント、Wiki、勉強会メモ -> kibela に乗り換え
Meldium 無料 パスワード管理 Discontinue
ReSharper $299/user/year VS Extension VSの強化 -> 不要
Unity Plus $37.80/月 2018/1 マルチプラットフォームなゲーム/3D開発 -> 不要

esa.io

ドキュメントに利用していたが、個人利用の範囲だと kibela でいい気がしてきたので乗り換えた。

有料の範囲で不満はなかったが、個人としてはほぼ同等機能の場合に無料が勝った。

Google ログインできるのえらい。

Meldium

おわこん..。

ReSharper

VS2017 でReSharper で使ってた機能入っていらなくなった。

重すぎ。

Unity Plus

しばらく Plus を使ってきたが、おおよそすべての開発は Free で十分できるようになった。

アセットストアの月一お得も含めて特典になるのだが、加味した上で個人ユースでは解除でいいと判断した。

Free でいいといえる判断ができるようになったぐらいには、Free は強力になりました。すごい。

store.unity.com

検討して使わなかったサービス

LastPass

いやぽ。使い勝手も悪い。

OneLogin

使い勝手悪い

OnePassword for Team

ないです。使い勝手最悪

Office365 Solo

G Suites で十分以上に事足りているため。

Tower

Git UI が面白くない。操作が別に GitKraken よりいいと思えるものもなかった。だったら GitKraken でいい。

*1:Google 認証の定めとしてChromeツールバーでログイン解けること多いぐらい

2018年目標

オフラインで抱負を毎年やっているのですが、こういうのは外に書いておくことに意味があって自分で後日読み返せるので書いておきます。

個人のプライベートにおける目標です。

目次

テーマ

挑戦。

知らない、なんとなく後回しにしていたことを回さない。今年とこの先を見て優先度をつけて選択する。という普通のことを続ける。

CSharp

.NETCore を前提に。Full .NET からなるべく離れる。

コンテナ動作を前提に。ランタイムをどこまで気にせずに実行できるようにできるかが今後のカギ。アプリケーション実行までの到達フローとスピンアップが大きな課題かな。

Unity は、2017.3 以降の動向が結構気になる。,NETCore どうなるのかもあるけど、いくつか使ってない機能があるので手元に取り込んでおきたい。ライブラリちょっと作ってるの出す。

言語機能は引き続き積極的に使っていくが、動向は注意。

言語勉強会は NETCore ベースで参加したいが、IL や CPP 化も少し興味ある。

Swift

課題のView は、Storyboard への View分離、Routerでのナビゲーションをきっちり組めるように。Autolayout 自体は苦ではないので、あとは数感。

裏は随時変化が必要なので、Rx必要なら引き続き RxSwift 。他ライブラリは、言語、Xcode標準で苦しいかどうかで考える。

基本的にサーバーレスにどこまでできるのか、サーバーサイドをどう組み合わせてパイプライン化できるのか。

アプリと並行して、いくつか非同期系処理はライブラリとして作っておきたい。

Serverside Swift は様子見。

えり好みなしで時間を作って頻度高めに参加したい。

Firebase + FireStore + CloudFunctions

クライアントの要。サーバーサイドをイベント、API を HttptriggerでできないならGAE前提で。ここできついならちょっと設計まずいと思うようにするほうがよさげ。*1

TypeScript でのデータフロー処理自体は慣れてきたが、いまいちもうちょっといいやり方がありそうなのと、エコシステムにキャッチアップできてないのでもう少し見る機会は増やす。

勉強会も機会見て参加したいが、優先度はまだ低い。

PowerShell

体系的にまとめる。早々にまとめる方がメリット高そうなので、個人の時間で一定の時間を毎日割く。昨年後半から挑戦していて、なんとか時間の工面は立つめどできたので、今年は個人の最優先でやり切る。

勉強会はその後に開催しておきたい。参加でもいいけど、いずれにしてもやっておきたい。

他言語

昨年から引き続き、Kotlin の優先度は上がってる。

もう少し低いレイヤというかネイティブに C/C++との絡みと増えているので、いい加減C++ か Rust は手を付ける説あるが不透明。ちょっと考えるが、優先度を高める可能性ある。

コンテナ

k8s がいいけど微妙に悩ましいので、GAE ぐらいの緩さがいい感じ。今年はここが主戦場の1つ。サーバーレス効かないものってまだ多くて、そのあたりはまぁさくっと封じ込めつつパイプライン組んでしまう。

動画配信

去年末にすこし触っていたが想像以上に楽しい。でも1sec未満を目指すとめちゃめちゃハードル高い。そもそもミドルウェア自作となると、かなり苦しい。

面白いのでこのあたりはアンテナはるが、趣味なので優先度は低め。

AWS / GCP / Azure

流れを作るのが AWS なのはもうしばらく続きそう。その意味で更に使っていくが、IoT は完全に蚊帳の外にしてるがたぶん手を付ける余裕はひねり出せない予感。AI も今年も手を付けるのが苦しそう。

個人開発のGCP比重は極めて高く。DNS 含めて移してもいいぐらいには完全に移行しても良い。

Azure は、Azurefunctions と AppService の動向が少し悩ましいのでアンテナ感度は高めに。AzureAD も停滞を感じるので、そろそろ次も選択肢に。

スマートホーム

去年から使ってる Google Home が Google Apps 対応したらちょっと使い方を真剣に考える。それまでは今のゆるふわでok。

ツール

個人 Google Apps もあるので Googleに集約しているが、このままでいい気がする。

MS 系ツールは、Outlook がわずかに使っていたがこれもなくしてもいい感じ。というかなくす。メイン製品で使うのはVisual Studio ぐらいかな?

Adobe も 今の利用なら Sketch + inVision で十分。

Slack は維持でよさげ。

esa はkibela のログインがGoogle 連携なさげで微妙だけど個人利用ならこれでいいかも。5人まで無料は大きい。ちょっと悩ましいけど考える。

Wunderlist が終わるとなった場合の代替見つけられてなくてつらい。Todo はあれは違う..。

アウトプット

ブログメインで。Qiita からは離れる気がする。dev.to はありだけど。

ブログも、はてなブログの https化と画像の目途次第で変更するかも。

*1:低レイテンシや常時接続だと話は別

2017年を振り返って

どうやら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年の最大の獲得であり、今後試されます。ハードルあがった...。

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

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

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