tech.guitarrapc.cóm

Technical updates

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位になるには帯域.....

AzureAD ログインと Docker for Windows Shared Drive によるボリュームマウント

Docker は普段 macOS で使っているのですが、そういえば Docker for Windows がGAされて久しいです。ふつうに Linux コンテナが動かせるのは WSL とは違うコンテナとしての良さに満ちてていいものです。

docker run -it centos /bin/bash

とはいえ Docker for Windows は、触るたびにHyper-V をはじめとしていくつかの特徴的な挙動で難しく感じます。

さて、今回は AzureAD でログインしている Windows において、Docker の Shared Drive が上手く使えない症状に遭遇したので、解消方法をメモしておきます。

見つけるまで結構悩んでしまったので、もしほかの方が同様の症状にあった時にうまくいくヒントとなることを祈ります。

更新

2020年6月 時点で、最新 Docker Desktop for Windows にて修正されています。やったね!

github.com

目次

概要

Docker はホストのドライブをコンテナで共有する機能があります。Docker for Windows の場合は、SMB (TCP445) を使います。(SMB/CIFS)

これにより、ホストのファイル更新をコンテナと共有が可能だったり、ログ処理したりが可能になります

環境

Docker for Windows 17.09.1-ce-win42

Share Drive 方法

Docker for Windows > Settings > Shared Drives に行きます。ここで共有したいドライブを有効にします。

  • シェアしていない状態

  • シェアした状態

うまくいきましたか? やりましたね!完璧です。そのまま docker run -v を楽しみましょう。

docker run --rm -v c:/Users:/data alpine ls /data

単純にこれで済む場合は、local User でログインしている Administrators 権限を持っているケースか、AD でログインしていて適切に権限が付与されているケースが経験あります。

注意点

Network Connection Profile

もし自ネットワークプロファイルが private でない場合は、Private にしておきます。ただ、Hyper-V のプロファイルはパブリックネットワークで構いません。

自宅や職場で guest or public netrowk は、相応の理由がない場合はちょっと困ったことを引き起こしやすいです。(Firewall ルールからしてセキュアに守られる)

Hyper-V ではない、自分のイーサネットやWifi のネットワークコネクションのプロファイルを プライベートネットワークに変更する場合は、PowerShell 上で以下でさくっとできます。*1

# 対象のId を確認しましょう。
Get-NetConnectionProfile
$id = "対象のConnectionIdをどうぞ"
Set-NetConnectionProfile -NetworkCategory Private -InterfaceIndex $id

うまくホストのネットワークが プライベートになりましたか?

Firewall

Firewall の警告が出た場合はこのケースがあり得ます。

Firewall で弾かれる場合は TCP 445 のコンテナip 10.0.75.1からのアクセスになっている DockerSmbMount のエントリが許可になっていますか?

このコンテナIP 10.0.75.1 は、Docker for Windows > Settings > Network にあるデフォルトの値です。自分でIPを設定されている場合はよきように解釈してください

もしアンチマルウェアを使っていらしゃる場合は、そのソフトのブロックを解除してあげるか White list に追加するといいでしょう。

これで共有ができましたか?

AzureAD の場合

さて、本題です。

AzureAD でログインしたUserにおいては、そのままでは Shared Drives が失敗します。*2Driveのシェアを実行 > 認証を入力 > 数秒で Share がはずれる。という状態です。

ログを見ると原因がわかります。

[11:19:49.606][NamedPipeClient][Info   ] Sending Version()...
[11:19:49.607][NamedPipeClient][Info   ] Received response for Version
[11:19:49.607][NamedPipeServer][Info   ] Version()
[11:19:49.608][NamedPipeClient][Info   ] Sending Mount(C, AzureAD\UserName:**********, Docker.Core.Settings)...
[11:19:49.607][NamedPipeServer][Info   ] Version done in 00:00:00.
[11:19:49.609][NamedPipeServer][Info   ] Mount(C, AzureAD\UserName:**********, Docker.Core.Settings)
[11:19:49.629][SambaShare     ][Info   ] Mount C
[11:19:49.679][Cmd            ][Info   ] この共有リソースは存在しません。
[11:19:49.679][Cmd            ][Info   ] NET HELPMSG 2310 と入力すると、より詳しい説明が得られます。
[11:19:49.681][SambaShare     ][Info   ] "C" is not shared
[11:19:49.681][SambaShare     ][Info   ] Creating share "C:\" as "C" with Full Control to "AzureAD\UserName"
[11:19:49.740][Cmd            ][Info   ] C が共有されました。
[11:19:49.777][Cmd            ][Info   ] 共有名             C
[11:19:49.777][Cmd            ][Info   ] パス               C:\
[11:19:49.777][Cmd            ][Info   ] 注釈
[11:19:49.777][Cmd            ][Info   ] 最大ユーザー数     制限なし
[11:19:49.777][Cmd            ][Info   ] ユーザー
[11:19:49.777][Cmd            ][Info   ] キャッシュ         キャッシュは無効
[11:19:49.778][Cmd            ][Info   ] アクセス許可       AzureAD\UserName, FULL
[11:19:49.778][Cmd            ][Info   ] コマンドは正常に終了しました。
[11:19:49.780][SambaShare     ][Info   ] "C" is shared
[11:19:50.700][SambaShare     ][Info   ] Username: UserName
[11:19:50.700][SambaShare     ][Info   ] Host IP: 10.0.75.1
[11:19:50.700][SambaShare     ][Info   ] Cifs options: noperm,iocharset=utf8,nobrl,mfsymlinks,vers=3.02,domain=AzureAD
---- 中略 ----
[11:19:52.190][SambaShare     ][Error  ] Unable to mount C drive: 10.0.75.1 (10.0.75.1:445) open
umount: can't unmount /c: No such file or directory
umount: can't unmount /C: No such file or directory
rmdir: '/c': No such file or directory
rmdir: '/C': No such file or directory
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting //10.0.75.1/C on /c failed: Invalid argument

[11:19:52.192][SambaShare     ][Info   ] Removing share C
[11:19:52.244][SambaShare     ][Info   ] Mount C
[11:19:52.273][Cmd            ][Info   ] この共有リソースは存在しません。
[11:19:52.273][Cmd            ][Info   ] NET HELPMSG 2310 と入力すると、より詳しい説明が得られます。
[11:19:52.275][SambaShare     ][Info   ] "C" is not shared
[11:19:52.275][SambaShare     ][Info   ] Creating share "C:\" as "C" with Full Control to "UserName"
[11:19:52.300][ApiProxy       ][Info   ] proxy >> GET /images/sha256:9e4f13a0901e7cdc0c16babf4ebec822828ecae42947c79b69c51e2e22e0470e/json
[11:19:52.300][ApiProxy       ][Info   ] Dial Hyper-V socket 45ef270d-7ba5-4a0c-9633-f0d79d3b0f30:23a432c2-537a-4291-bcb5-d62504644739
[11:19:52.300][ApiProxy       ][Info   ] Successfully dialed Hyper-V socket 45ef270d-7ba5-4a0c-9633-f0d79d3b0f30:23a432c2-537a-4291-bcb5-d62504644739
[11:19:52.302][ApiProxy       ][Info   ] proxy << GET /images/sha256:9e4f13a0901e7cdc0c16babf4ebec822828ecae42947c79b69c51e2e22e0470e/json
[11:19:52.309][Cmd            ][Info   ] システム エラー 1332 が発生しました。
[11:19:52.309][Cmd            ][Info   ] アカウント名とセキュリティ ID の間のマッピングは実行されませんでした。
[11:19:52.311][SambaShare     ][Error  ] Failed to create share "C:\" as "C" with Full Control to "UserName" with code: 2
[11:19:52.341][Cmd            ][Info   ] この共有リソースは存在しません。
[11:19:52.343][NamedPipeClient][Info   ] Received response for Mount
[11:19:52.341][Cmd            ][Info   ] NET HELPMSG 2310 と入力すると、より詳しい説明が得られます。
[11:19:52.343][SambaShare     ][Info   ] "C" is not shared
[11:19:52.343][NamedPipeServer][Info   ] Mount done in 00:00:02.7347295.
[11:19:52.449][ApiProxy       ][Info   ] proxy >> GET /images/sha256:9e4f13a0901e7cdc0c16babf4ebec822828ecae42947c79b69c51e2e22e0470e/json
[11:19:52.449][ApiProxy       ][Info   ] Dial Hyper-V socket 45ef270d-7ba5-4a0c-9633-f0d79d3b0f30:23a432c2-537a-4291-bcb5-d62504644739
[11:19:52.449][ApiProxy       ][Info   ] Successfully dialed Hyper-V socket 45ef270d-7ba5-4a0c-9633-f0d79d3b0f30:23a432c2-537a-4291-bcb5-d62504644739
[11:19:52.450][ApiProxy       ][Info   ] proxy << GET /images/sha256:9e4f13a0901e7cdc0c16babf4ebec822828ecae42947c79b69c51e2e22e0470e/json

原因は アカウント名とセキュリティ ID の間のマッピングは実行されませんでした。 がまさにそれです。要は no mapping between security id ですが、Windows においてこれは Security上の アクセスIdが一致していないことを示します。一度 C: とドライブ共有できているにもかかわらず、なのがなかなか厄介です。 何がセキュリティIdと違うのかというと、 認証時に AzureAD ログインしているときに入れないといけない AzureAD\ が原因です。では、ということで AzureAD\ を除いてユーザー名のみにすると、そんなIdはないので共有自体が失敗します。セキュリティIdが一致していない、厄介。AzureAD で Windows ログインすることはかなり快適なのですが、こういう問題はたびたびあります。

問題がわかれば対処方法が思いつきます。

対処方法は、AzureAD\UserName の UserName だけの ローカルユーザーを作りましょう。ユーザー作成後、Administrators を与えます。これで、AzureAD\UserName で共有後に、UserName も見つかるので正常にドライブ共有が可能になります。

PowerShell ならこうです。

# ここでポップアップがでるので、追加したいユーザーのUsername と Password をいれます。
$credential = Get-Credential
New-LocalUser -AccountNeverExpires -PasswordNeverExpires -UserMayNotChangePassword -Name $credential.UserName -Password $credential.Password
Add-LocalGroupMember -Group Administrators -Member $credential.UserName

もしGUI でやりたい場合、UserName をご自身のユーザー名に置き換えてください

参考

*1:管理者権限がいります。ADならDomainAuthenticated なので問題ないはずですが Firewall ルールが問題になる可能性はあります

*2:私は5度やって5度失敗したのでそういうものでしょう

PowerShell の配列表現と生成処理時間

面白い記事があります。

blog.shibata.tech

PowerShell において配列生成は 言語仕様上にある通りカンマ演算子 , によって表現されるものであり、ASTでも満たされている。しかし、そこに言及がなく ()$()@() で生成しているような表現を見かけるけど実は違うんだよ。ということが説明されています。とはいえ、@() で囲むことに意味はあるので注意なのですが。

tech.guitarrapc.com

さて、結果としてみるとどの表現でも配列が生成されます。が、AST を見てもそれぞれ違うことから「表現可能な方法が複数ある場合にどれを使うのがいいのか」を考えてみましょう。

目次

PowerShell の構文木 AST を見る

もし PowerShell の AST が見たい場合は、ShowPSAst でモジュールを入れておくといいでしょう。

# 今のユーザーにのみ導入する
Install-Module ShowPSAst -Scope CurrentUser

github.com

配列の生成

今回は、ベンチマークでは単純に配列評価の時間を測定したいため、配列の生成は事前に文字列を起こしておきましょう。

以下のようにすると配列が生成できます。

gist.github.com

これで2種類の配列文字列が取得できたので準備ok です。

1,2,3,4,5,....

1
,2
,3
,4
,5
....

ベンチマークの測定対象

それではベンチマークを測ってみましょう。

測定対象として選んだのは記事にあった表現とその派生です。

  1. ArrayLiteralAst : カンマ演算子, による配列の生成 = 最速の予定
    • 1,2,3
  2. ParenExpressionAst + ArrayLiteralAst : () で カンマ演算子 , による配列の生成のラップ
    • (1,2,3)
  3. ArrayExpressionAst + ArrayLiteralAst : @() でカンマ演算子 , による配列の生成のラップ
    • @(1,2,3)
  4. SubExpressionAst + ArrayLiteralAst : $() でカンマ演算子 , による配列の生成のラップ
    • $(1,2,3)
  5. (ArrayExpression + ArrayLiteralAst) * PipelineOutput : @() でカンマ演算子 , による配列の生成のラップした結果をパイプラインでマップ
    • @(1,2,3) | % {$_}
  6. Constraints + ArrayLiteralAst : @() で生成した中身を前置カンマにしました
@(
1
,2
,3)

ベンチマーク結果

1000回実行したっけの平均/最大/最小を見ます。単位は ms です。

PowerShell でのベンチマークは、今回簡易に Measure-Command を用いました。

Code Target Count Average Maximum Minimum
1,2,3 ArrayLiteralAst 1000 6.72703 76.897 1.109
(1,2,3) ParenExpressionAst + ArrayLiteralAst 1000 6.70472 77.452 1.0702
@(1,2,3) ArrayExpressionAst + ArrayLiteralAst 1000 7.020254 185.7868 1.0828
$(1,2,3) SubExpressionAst + ArrayLiteralAst 1000 7.59060 85.0647 1.4674
前述参照 (ArrayExpression + ArrayLiteralAst) * PipelineOutput 1000 75.666 234.0299 52.0301
前述参照 Constraints + ArrayLiteralAst 1000 8.67313 195.6095 6.1331

いかがでしょうか? 予想通りですか?

ArrayLiteralAst

さすがに Average / Maximum / Minimum のいずれにおいても安定して最速です。

ArrayLiteralAst だけの場合、次のAST評価となっています。

# AST  : {1,2,3} | Show-Ast
# Eval : ScriptBlockAst > NameBlockAst > PipelineAst > CommandExpressionAst > [ArrayLiteralAst] > ConstantExpressionAst(s)

ParenExpressionAst + ArrayLiteralAst

こちらも ArrayLiteralAst のみと比較して、ParenExpressionAst + ArrayLiteralAst では、() で括った分一段要素が増えます。一方で実行速度にはほとんど差がなく、() は評価の軽い要素であるのが明確です。

# AST  : {(1,2,3)} | Show-Ast
# Eval : ScriptBlockAst > NameBlockAst > PipelineAst > CommandExpressionAst > [ParenExpressionAst] > PipelineAst > CommandExpressionAst > [ArrayLiteralAst] > ConstantExpressionAst(s)

ArrayExpressionAst + ArrayLiteralAst

Maximum 測定誤差がでたと考えられます。次のAST評価となっています。 ArrayExpressionAst + StatementBlock + CommandExpressionAst が増えていることからもそこそこ評価が増えてきました。が誤差レベルですね。

# AST  : {@(1,2,3)} | Show-Ast
# Eval : ScriptBlockAst > NameBlockAst > PipelineAst > CommandExpressionAst > [ArrayExpressionAst] > StatementBlockAst > PipelineAst > CommandExpressionAst > ArrayLiteralAst > ConstantExpressionAst(s)

SubExpressionAst + ArrayLiteralAst

こちらは、Minimum が少し大きいですが同様に誤差でしょう。

部分式は多用するのですが、AST評価を見ても [SubExpressionAst] > StatementBlockAst > PipelineAst > CommandExpressionAst となっており、ArrayExpressionAst とだいたい同様ですね。こちらも気にしなくてよさそうです。

# AST  : {$(1,2,3)} | Show-Ast
# Eval : ScriptBlockAst > NameBlockAst > PipelineAst > CommandExpressionAst > [SubExpressionAst] > StatementBlockAst > PipelineAst > CommandExpressionAst > ArrayLiteralAst > ConstantExpressionAst(s)

(ArrayExpression + ArrayLiteralAst) * PipelineOutput

原因は明らかで パイプラインです。ASTを見ても明らかに要素数が多くなることが分かります。パイプラインほんと重いんですよね。配列を生成するためにこの利用は避けましょう。

# AST  : {@(1,2,3) | % {$_}} | Show-Ast
# Eval : ScriptBlockAst > NameBlockAst > PipelineAst > CommandExpressionAst > [ArrayExpressionAst] > StatementBlockAst > PipelineAst > CommandExpressionAst > ArrayLiteralAst > ConstantExpressionAst(s)
#                                                             | > CommandAst 
#                                                                         | > StringConstantExpressionAst
#                                                                         | > ScriptBlockExpressionAst > ScriptBlockAst > NamedBlockAst > PipelineAst > CommandExpressionAst > VariableExpressionAst

Constraints + ArrayLiteralAst

最初の要素 1 のみ 速やかに ConstantExpressionAst として評価されています。しかし後続は前置のカンマによってシングル要素の配列 とAST評価されてしまいArrayLiteralAst とついています。AST評価を見てみると明らかですね。

# AST  : {@(
# 1
# ,2
# ,3)
# } | Show-Ast
# Eval : ScriptBlockAst > NameBlockAst > PipelineAst > CommandExpressionAst > [ArrayExpressionAst] > StatementBlockAst > PipelineAst > CommandExpressionAst > [ConstantExpressionAst]
#                                                                                                                    | > PipelineAst(s) > CommandExpressionAst > [ArrayLiteralAst] > ConstantExpressionAst
#                                                                                                                    | > PipelineAst(s) > CommandExpressionAst > [ArrayLiteralAst] > ConstantExpressionAst

まとめ

特に制約がない時に書くなら、すなおに , でくくるのみにするか () で括るのが良さそうです。

$a = 1,2,3
$b = (1,2,3)

String Interporation のような文字列埋め込みに使う 表現も悪くはなさそうです。

$c = "$(1,2,3)" // "1 2 3" となる

良く紹介される形も明らかな齟齬はなさそうです。

$d = @(1,2,3)

ただしパイプライン、お前はだめだ。

$e = @(1,2,3) | % {$_}

ベンチマークコード全体

コードを置いておきます。参考になれば幸いです。

https://gist.github.com/guitarrapc/8a89dc9438673871a71649ab8315e0e8