わたしが C# を学ぶにあたって教わっている先達のサイトをまとめてみる

書いていないネタは多いのですが、アンケートで C# についてと言われました。

次なんの記事がいいですか？ #書く記事募集中

— guitarrapc_tech (@guitarrapc_tech) April 23, 2016

そこで、私自身 C# を学ぶにあたって参考にしているものをまとめておくことことにします。*1

はじめに感謝と尊敬を。ここに載せていないサイト、書籍の多くからも学びも得ています。今現在もそうです。

私自身が何か恩返しをできればと思いつつ、同じように悩まれている方への参考となれば幸いです。

目次

個人ブログ

順番には大きな意味はありません。

サイト	ブログ主	参考にしている分野	備考
++C++; // 未確認飛行 C	++C++; // 管理人: 岩永 (@ufcpp) / Twitter	C#, プログラミング全般	C#は書籍よりもここから。 初めての C# から現在もずっと学び続けています。 実は初めての PowerShell もここでした。 ご本人とあまりしゃべらないけどセッションいつも楽しいです。
neue cc	neuecc (@neuecc) / Twitter	C#, Rx, ASP.NET, OWIN, Unity, プログラミング全般	C# をどういった時に、どのように使うか、なぜC#なのかを学んでいます。 C# じゃなくても言語を問わない実装の違い、理由にも詳しくてすごい。 実際は本人から直接学ぶ部分が非常に多いです。
kekyoの丼 – プログラムの話題とか	Kouji Matsui (@kekyo2) / Twitter	C#, 言語実装, 動的生成	なぜC# でその処理をそのように書くのかって疑問じゃないですか？ C#にかぎらずプログラムについて、Windowsについて学んでいます。 async/await や LINQ について度々読みなおしています。 COMとか全然理解が追いつかなくてぐぬぬ...
NyaRuRuが地球にいたころ	NyaRuRu (@NyaRuRu) / Twitter	C#, プログラミング全般	やばいです。とても影響を受けています。 内容に最も感動を受けたサイトの1つです。
https://t.co/pBQkOmDxij	ぐらばく☪ (@Grabacr07) / Twitter	C#, WPF	WPF といえばダントツです。 図書館の如くネタにあふれています。
ぷろじぇくと、みすじら。	Mayuki Sawatari (@mayuki) / Twitter	C#, プログラミング全般	全力ガチサイトです。 本当に勉強になります。すぎょい。
銀の光と碧い空	たなか (@tanaka_733) / Twitter	C#, .NET Core, RHEL, IIS, CI	他のサイトにない一風変わった品揃えです。 .NET でサーバーサイドとか考えるならまさにです。 最近 .NET Core 中心で色々注目です
ぐるぐる～	ぐるぐる系SQL（@bleis）さん / Twitter	C#, F#	ぐるぐる～
TAKESHIK.ORG	たけしけー (@takeshik) / Twitter	C#, 式木, LinqPad, 変なこと	いつも更新すると面白い内容です。 一通り見てると面白いです。
平々毎々（アーカイブ）	Kentaro Inomata (@matarillo) / Twitter	C#, F#, Java	C# を一歩下がった目で冷静に評価されているという印象です。 中身かなり濃いのでとてもおもしろいです。
Threading in C# - Free E-book	Joe Albahari	C#, Threading	C# で Thread や Task, Parallel って何を知りたかった時に@neuecc に教えてもらった神サイトです。 感動を覚えるぐらい素晴らしい内容で、日本語訳とかもあったりします。
しばやん雑記	Tatsuro Shibamura (@shibayan) / Twitter	IIS, Azure, ASP.NET	色々なネタがあって面白いです。 Azure に強いですが、他の色々な情報があって好きです。 ASP.NET で困ったらだいたいここで助けられます。
miso_soup3 Blog	みそ (@miso_soup3) / Twitter	ASP.NET Web API, Azure	Swagger とか OWIN とか、Web系の取っ掛かりはいつもここです。
xin9le.net	じんぐる (Takaaki Suzuki) (@xin9le) / Twitter	C#, LINQ, Rx	結構シリーズもの多いです。サラッと読めます。
かずきのBlog@hatena	かずき(Kazuki Ota) (@okazuki) / Twitter	C#, Rx, WPF, UWP	ほぼ毎日更新があります。 毎回の記事が短いので読みやすいです。 シリーズものが多いです。
pierre3のブログ	ピエール (@pierusan2010) / Twitter	C#, PowerShell	何かに刺激を受けて、というサンプル記事が多く参考にさせていただくことが多いです。
鷲ノ巣	あえとす (@aetos382) / Twitter	C#, PowerShell, ETW	いいですよ、すごく。 他の人が書かない記事が多いですし、造詣が深く勉強になります。
http://hidori.jp/	Hidori (@hidori) / Twitter	C#, PowerShell	初めのころに多くの記事で学びました。 更新お待ちしております。
テラシュールブログ	椿 (@tsubaki_t1) / Twitter	C#, Unity	Unity で困ったらここ
RyotaMurohoshi - Qiita	むろほし（@RyotaMurohoshi）さん / Twitter	C#	デリゲート, Func と LINQ についての理解に助けられました。
ScottGu's Blog - ScottGu's Blog	Scott Guthrie (@scottgu) / Twitter	ASP.NET, Azure全般	Azure関連の大きな動向とか
Scott Hanselman - Scott Hanselman's Blog	Scott Hanselman 🌮 (@shanselman) / Twitter	ASP.NET, Microsoft全般	大体真っ先の情報が出たりします
Code, code and more code.	Marc Gravell (@marcgravell) / Twitter	C#, Redis	言わずと知れた StackOverflow の凄腕すごい人 グラニで利用しているフレームワークの開発者でもあるので超重要
You’ve Been Haacked | You’ve been Haacked is a blog about Technology, Software, Management, and Open Source. It’s full of good stuff.	https://hachyderm.io/@haacked (@haacked) / Twitter	C#	他の人が扱ってなくて困リ切った時に救われます。
Implementing the Singleton Pattern in C#	Jon Skeet (@jonskeet) / Twitter	C#, Singleton	シングルトンの歴史すごい。Lazy<T> 便利！

Microsoft関連

サイト	備考
C# リファレンス | Microsoft Learn	リファレンスです。C# でこれどうだっけ？をさくっと確認するときに
.NET API ブラウザー | Microsoft Learn	このクラスって... を調べるならここです。 一日何度お世話になっていることか
Introduction - C# language specification | Microsoft Learn	C# 言語仕様をみたくなったら
Reference Source	.NET Framework のリファレンスソースが公開されているのです。中身みれるの最高
.NET Platform · GitHub	.NET 関連の GitHub リポジトリです。Roslynm Coreclr から始まって色々みるのです
Microsoft · GitHub	Microsoft 関連の GitHub リポジトリです。TypeScript, VSCode, MSBuild から docker のFork まで
GitHub - dotnet/reactive: The Reactive Extensions for .NET	Reactive Extensions (Rx) ならここ あと Home · ReactiveX/RxJava Wiki · GitHub はMicrosoft 関連じゃないですが、Rx の絵が親切

困ったときの

サイト	備考
Stack Overflow - Where Developers Learn, Share, & Build Careers	困った時の世界の先輩
Google	Yahoo や Bing じゃないです。Google しか使ってません。 だいたいエラーメッセージで叩くと救われます。

まとめ

色々忘れている気がします。不定期に更新しよう。。。

*1:あまりこういう記事は書かないのですが思うところもあったので

Azure Functions の API Key を扱ってみる

Azure Functions を使っていて気になるのが認証制御です。

AWS API Gateway + Lamdba では、任意の Token をつけることができました。それでは Azure Functions はどうでしょうか？

App Service Authentication/Authorization のような、アカウント連携はあまりに重厚でしょう。単純にAPI Keyで済ませたいものです。

そこで今回は Azure Functions で API Keyを使った認証について見てみましょう。

目次

API Key認証の例

API Key認証といってもどんなものでしょうか。

AWS

たとえば API Gateway では API Keys としてトークンを発行できます。

このトークンを任意のAPIで有効化することで、APIごとに認証トークンがヘッダにないとアクセスできないようにできます。

Azure Functions

翻って Azure Functions です。

Azure Functions を触っていて気づくのが、Github WebhookだけURL が違い/Github Secretを持つということです。

なんともわかりやすいでしょう。

Function 種類	Function Url フォーマット	Github Secret	サンプル
Empty	なし	なし
Http Trigger	https://{function app name}.azurewebsites.net/api/{function name}?code={api key}	なし
Generic Webhook	https://{function app name}.azurewebsites.net/api/{function name}?code={api key}	なし
Github Webhook	`https://{function app name}.azurewebsites.net/api/{function name}	{api key}

API Key の詳細

ここ最近アップデートされたドキュメントに概要が説明されています。

azure.microsoft.com

You can use an HTTP or WebHook trigger to call a function in response to an HTTP request. The request must include an API key, which is currently only available in the Azure portal UI.

基本的には HTTP、WebHookトリガーのいずれもリクエストに API Key を含む必要があります。

さて API Key などの認証については、Function の設定に依ります。すなわち Function が HTTP Trigger なのか Webhook なのかということです。

Integrate タブから function.json を見てみましょう。

Advanced Editor から詳細の json を操作できます。例えば GenericWebhook なら次のとおりです。

{
  "bindings": [
    {
      "webHookType": "genericJson",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    }
  ],
  "disabled": false
}

プロパティのの説明は、ドキュメントにあるとおりです。

HTTP Request のプロパティです。

プロパティ	Webhookトリガーの場合	HTTPトリガーの場合
name	Function コード内でリクエストオブジェクトを示す変数名として利用されます。*1 res にしたならコードでも res として受けるということです。	同左
type	必ず httpTrigger とします。	同左
direction	必ずin とします。	同左
webHookType	正当な入力値は github, slack, genericJsonのいずれかです。	WebHook ではないのでこのプロパティを空文字"" とします。
authLevel	Webhookトリガーの場合無視され適用されません。	API Keyについて制御できます。 function とすることでAPI Keyを必須とできます。 anonymousとすることで API Keyを無視します。 adminとすることで、master API Key を必須とします。

HTTP Response のプロパティです。

プロパティ	説明
name	レスポンスオブジェクトを示す変数名です。 reqにしたならコードでも reqで返す必要があります。
type	必ず http とします。
direction	必ず out とします。

API Key の保存場所

API Key は、D:\home\data\Functions\secrets に保存されています。

Kudu で見てみましょう。

host.json

最も大事な master key は、host.json に書かれています。

host.json に書かれた2つのキーを説明します。

キー	説明
masterkey	FunctionApp 内の全てのFunctionで利用できます。無効のFunctionもトリガー実行できません。 function.json で authLevel をadminにすることで必須にできます。
functionkey	FunctionApp 内の全てのFunctionで利用できます。無効のFunctionはトリガー実行できません。

しかしこの host.json の鍵は権限が強すぎます。Wehook のプロバイダと共有なんてもっての他です。

もっと対象の Function だけに働きかけられる鍵はないでしょうか。

Functionごとの鍵

実際の利用を考えた場合、host.json ではなく、各ファンクションを作った際に自動的に生成される<Function名>.jsonの鍵を使いましょう。例えば GenericWebhookCSharp1 というFunction を作成したらGenericWebhookCSharp1.json がその鍵をもつファイルです。

この鍵の key プロパティの値が、対象Function を叩くための API Key です。

またこの鍵は、Functionを作成した時の Function Url で、クエリストリングに埋め込まれています。

トリガーによるAPI Key 必須選択と渡し方

ドキュメントにある通りです。Wehook トリガーでは API Key は必須です。HTTP トリガーでは選択可能です。

To trigger a WebHook function the HTTP request must include an API key. For non-WebHook HTTP triggers, this requirement is optional.

API Key の埋め込み方

API Key は2つの埋め込み方があります。

1. code という名前で、クエリストリングに含める
2. x-functions-key という、HTTP リクエストヘッダに埋める*2

もちろんHTTPトリガーに関しては、function.json で authLevel を anonymous にすることで API Key がなくても問題なくできます。

簡単なメソッドで検証してみましょう。1つはクエリストリングでキーを渡します。もう1つはx-functions-keyヘッダで渡します。

gist.github.com

Webhook トリガー

HTTP Request は、API Key をクエリストリングで含んでいる必要があります。

クエリストリングにAPI Key がなかったり、間違っていると BadRequest が返ります。

gist.github.com

gist.github.com

正しいAPI Key を含めると、jsonが判定されて応答が返ってきます。

gist.github.com

また、ヘッダにx-functions-key でキーを渡してもダメなのが特徴的です。

gist.github.com

HTTP トリガー

API Key はオプショナルです。この指定を行うのが、先ほどの function.json の HTTP Request にある authLevel プロパティです。

authLevel が省略 or function

もしfunction.json で authLevel が省略された場合はfunction相当、となるためAPI Key が必須となります。

クエリストリングにAPI Key がなかったり、間違っているとUnauthorized が返ります。

gist.github.com

gist.github.com

クエリストリングに正しいAPI Key を含めると、jsonが判定されて応答が返ってきます。

gist.github.com

Webhook と違い、ヘッダにx-functions-key でキーを渡することでも認証ができます。

gist.github.com

authLevel が anonymous

匿名認証のためAPI Key は無視されます。URL さえ正しく叩ければいい状態です。

gist.github.com

authLevel が admin

host.json のmasterKey 以外の鍵では呼べなくなります。host.json のfunctionKey でも実行できません。

gist.github.com

鍵の変更

もし API Key を変更したくなったどうしましょうか？

ドキュメントに記述がありませんが、D:\home\data\Functions\secrets の鍵を書き換えれば更新されます。

変更前 :

変更後 :

変更が確認できましたね

gist.github.com

まとめ

これに気づかず、独自ヘッダ認証を組み込んでからドキュメントが発行されました。

Azure functions で作成するとデフォルトで API Key が必須です。HTTPS であることからも、安全がある程度担保されているので、いい感じに扱えますね。

API の更新も含めて、うまく使う目処がそろそろ立つのではないでしょうか？

*1:あるいは、Node.js の場合はリクエストボディとして扱われます。

*2:HTTP Trigger でのみ利用可能のようです

LINE BOT API で緊急避難情報を返すボットのβバージョンを公開しました

熊本地震災害に遭われた方、その関係者の皆様の無事を祈っております。

少しでも力になれることがないかと、LINE BOT API で緊急避難情報を返すBOTを作成したので公開します。

まだLINE BOT API がβバージョンのため、友達上限が50人と苦しい制限があるのが心苦しいです。

目次

ソースコード

Githubで公開していますので、ライセンスの元、ご自由にお使いください。

github.com

使い方

次の手順で利用できます。

1. BOTと友達になる
2. LINE で「位置情報」をBOTに送る
3. BOT から応答がきます

見ていきます。

BOT と友達になる

公開した BOT とは、QR コードで友達になることができます。

QRコードでの友達のなり方は、いくつかのサイトで紹介されています。

appllio.com

LINE で「位置情報」をBOTに送る

BOT とのチャット画面で、位置情報を送ってください。(英語、日本語に対応)

https://help-life.net/?p=1111help-life.net

BOT から応答がきます

BOT が共有された位置情報の緯度/経度を元に 近くの緊急避難所を探します というサービスのURL を返します。

「近くの緊急避難所を探します」ってサービスを、九州の方が使ってくれたらしい

もし共有された位置情報が熊本県の場合、ナビタイム災害情報 のページも返します。

近くの緊急避難所を探しますはこのような地図サービスです。

ナビタイムは、避難情報に加えて交通情報なども教えてくれます。

テキストやスタンプを送ると、説明が返ってきます。

2016/4/17 追記

安否情報などが集まっているので、Google クライシスレスポンス情報もBOT応答に足しました。

Public Alerts Help

まとめ

少しでもみなさんの役に立てばと幸いです。

LINE BOT API がβで友達が50人というのは正直かなり厳しいので、なんとか追加してくれるとうれしいのですが.... Slack や Gitter で 公開するのもありかと思います。

Azure Functions - C# を活用するために気をつけていることをまとめてみる

Azure Functions たのしいです。今回は、現時点で グラニにおいて Azure Functions を展開するにあたり気をつけていることをメモしておきたいと思います。

現時点で、リリースされて2週間程度に加えて、プレビュー版なので今後変わる可能性が高いです。

が、いったんのまとめということで。

目次

サンプルコード

Azure Functions に関する記事で扱った内容は、Github にあげています。参考になれば幸いです。

github.com

API Gateway + Lambda ほど API的な利用はできない

これはコンセプトの違いなので、よくも悪くもないです。

API Gateway + Lambda

API Gateway を AWS Lambda の前面におくことで、RESTful API のように展開ができます。

dev.classmethod.jp

これの何が嬉しいかというと、GET や POST などの 各種HTTP Method を自由に組み合わせたり、API共通の Token を設けたり Request Header や Response Header をいじったり、エンコーディング触ったりと、いい感じにフロントエンド(API Gateway)で加工してからロジック(Lambda) に渡せます。カスタムドメインを割り当てたりアクセスURLも統一的に扱えて、バージョニング、デプロイタイミングまで自在です。つまり、本当に Managed RESTful API なんですね。

URL もこのようにAPI Gateway で管理して、Lambda は API ごとに割り当てます。複数の処理も常に統一したアクセスURL で提供できるのがいいです。

https://<gatewayname>.apiname.ap-northeast-1.amazonaws.com/<stage>/<apiname>
https://<customdomain>/<stage>/<apiname>

とはいえ、手元の環境からいい感じでデプロイ、C# サポートがない、など今後にまだまだ期待を持っています。

Azure Functions

ではAzure Functions はどうかというと、あくまでも入力に対して何かをしてくれる関数 であり、関数ごとに個別にURL + tokenを付与したものです。

そのため、次のような URL が発行されます。

https://<FunctionAppName>.azurewebsites.net/api/<FunctionName>?code=<Functionごとに一意な文字列>

外から叩くときも、POST メソッドで application/json しか受け付けられません。雑に叩くとこんな感じです。

gist.github.com

ちなみに PowerShell でInvoke-RestMehotdを使って叩くと、エンコーディングが utf8 じゃないので日本語が化けます。HttpClientを使いましょう。

gist.github.com

Function ごとに一意の文字列が付与されることも含めて、API Gateway + Lambda ほどは RESTful として統一的なアクセスは難しいということです。しかし、似た処理を1つのFunction App にまとめることでアクセスをある程度統一的にできないことはないです。

性質からすると、比較的 Webhook 処理を任せたり、Azure のリソースをイベント発火点としてFunction起動するのが初めの一歩としても役割としても活用しやすいでしょう。

tech.guitarrapc.com

tech.guitarrapc.com

実装において気をつけていること

単純なことです。

#load を活用する

Azure Functions が実行を保証していない以上、処理をつなげるのに Azure Functions を内部で次々と呼び出すネスト構造は不向きです。

そこで、多段 Azure Functions の呼び出しをやめて #load に寄せる のが効果的です。

tech.guitarrapc.com

機微情報は App Settings を使う

コード生埋めは避けましょう。System.Configuration.ConfigurationManager.AppSettings[<string>] で取得できるので、違和感なく扱えるはずです。

tech.guitarrapc.com

拡張メソッドを利用する

拡張メソッドが利用できるかは使い勝手に直結します。積極的に使っていくといいでしょう。

私は、拡張メソッドを Function App の上位階層に配置して、必要に応じて#load で読み込んでいます。こうすることで、再利用性があがっていい感じえす。

tech.guitarrapc.com

tech.guitarrapc.com

安定性の向上

パフィーマンスチューニングのしようがほぼないので、少しだけ設定で気をつけることです。

メモリを増やすと実行が安定する

Azure Functions は、SLA 100% のような必ず実行される というものではありません。実際、グラニでは128MB では50回の実行で 5回程度は失敗を計測しています。

Azure Function を安定的に動かすには、処理によってですが メモリを 128MB から 256MB 程度に増やすのも有効です。

メモリを256MB に増やした後は実行がこけることなく安定するようになったように見えるので、今後も計測監視です。

32-bit Platform のままにする

Azure Functions は、Azure Web Appsなので32bit と 64bit でプラットフォームが選択可能です。デフォルトが 32bit ですが、現在のところ 64bit にしないことが推奨です。

Azure Functions の父であるDavid Ebbo が質問に解答してくれました。

stackoverflow.com

デプロイ

CI 大事です。

本番系は CI を組む

Azure Functions が、AWS Lambda + API Gateway より圧倒的に楽なのが CI です。特に Github CI は、PRベースとかなり相性が良く最強感あります。

かならず、本番系はCI を組むことを推奨します。Azure Portal と開発環境を可能な限り分離するのは当然あるべき状態です。

tech.guitarrapc.com

テスト環境を用意する

もう1つ大事なのが、テスト環境です。残念ながら API Gateway と違ってステージの考えを持たないため、別に Function App を用意しましょう。

私はこの環境は CI しないことで、好きに触ったり本番を再現したりしています。

開発環境

私はVSCode と LinqPad を使っています。

code.visualstudio.com

https://www.linqpad.net/

本番を Github CI しているので、Visual Studio から直接 Publish というのはなしです。

Visual Studio を使った リモートデバッグ周りの情報が乏しいので、次はその辺ですね。

わからないことは気軽に質問する

公式の推奨は、MSDNフォーラム か StackOverflow(azure-functions タグ) に質問を投げることです。

Msdn forums - Azure Functions

stackoverflow.com

実際、私も StackOverflow に質問を投げてますが、中の人から超速でアドバイスが来ます。すぎょい。

stackoverflow.com

現在は、なぜか Azure Functions の記事を公開すると Azure Functions の中の人に補足されています。そのお陰か Twitter でつぶやくと質問に解答が来たりします。

@guitarrapc_tech We often test new, non-impacting features in production to get organic user feedback, but that does mean there is less docs

— Christopher Anderson (@crandycodes) April 15, 2016

とりあえずオススメは、ふと調べて疑問に思ったら Twitter で英語でつぶやく + StackOverflow で質問 です。

今後の期待

Azure Functions も AWS Lambda 同様にちょくちょく実行が失敗するします。

そのため、モニター機能が待ち望まれます。GA することで、SLA も少し来るかもしれませんね。

まとめ

現時点で気をつけていることを簡単にまとめました。日々良くなっていっているので、使える機能や面白い活用が思いついたら記事にしたいと思います。

Azure Functions で Monitoring (監視)機能が利用可能になったようで実は？

まだリリースに関する告知がないのですが、Azure Functions で リリースが待たれていた Monitoring Functionality (監視機能) が先ほど利用可能になりました？

azure.microsoft.com

早速見てみましょう。

目次

Monitoring Functionality

ずっと待ち望んでいた機能です。つまり、Function App の実行結果を追うことができそう....?

Monitoring への アクセス

Monitoring には、確認したいFunction App を選択して、Monitoring を選択することでアクセスできます。

何ができるのか

まだごく限られた操作しかできません。ドキュメントが無いので正確ではないかもしれませんが、ぱっと見た感じは以下のとおりです。

操作	内容
閲覧範囲	現在時刻から 過去 24時間が見れます。
期間の操作	結果表示の期間を伸ばす、指定するなどの期間操作はできません。
計測単位	実行ユニット単位です。つまり、ファンクションの実行回数ではありません。
計測対象	個別の Function ではなく、指定したFunction App 全体です。
精度	かなり抜けがあるように見えます。 実際、一日100回以上実行されていますが足りてません。 例えば、22:05、22:08 と実行していますが表示されていません。

ほしいMonitoring はまだリリースされていない

気づかれたでしょうか？そう、Function App の各 Function ごとに Monitor があるということに。

そう、本当にほしい個別のFunctionの実行回数などの監視 が実装されるとしたらこちらでしょう。早速みられるか確認すると？

正座待機！

まとめ

現状の、Function App 全体の Monitoring はちょっと使い物になっていないので待ちましょう。

まぁ Coming Soon ですよ。期待です。

どうしてもほしいなら、適当に Monitoring.csx を作って、New Relic などにAPI で実行記録を投げればいいでしょう。暫定版ですが、どのみち 1min 単位の計測になりそうなので十分でしょう。