築地で豪華なウニ丼を食べてきた！
GW休みも終盤に差し掛かった5月8日金曜日。築地で豪華なウニ丼を食べてきました！
お店はこちら↓tabelog.com
お店は築地市場駅から徒歩5分くらいのところにあります。
AM11時過ぎ頃に訪問したのですが店内は数名お客さんがいる程度で空いていました。
お店の外の通りは観光の外国の方達で賑わっていましたよ(^^)
こちらのお店で頂いたのが「元祖こぼれウニ丼」。
豪華ですね！
すごい迫力です。
青森のムラサキウニと北方四島のバフンウニがWで載っています！
口の中でとろける味わいで最高です(^^)
ちなみに丼とは別に小鉢のウニも付いてました。
こちらは純粋にウニだけを味わうものでしょうか。
とにかくウニ好きにはたまらないです。
他にもいくら丼など数種類のメニューがあるので
海鮮が好きな人はぜひ一度訪問してみてはいかがでしょうか(^^)
以上。
ASP.NET Web APIのattributeルーティングについて
ASP.NET Web API 2から使えるattributeルーティング
ASP.NET Web API 2からattributeルーティングと呼ばれるルーティング設定が可能になりました。
以前から使えるconvention-basedルーティングと比較しながらまとめてみたいと思います。
convention-basedルーティングってどんなの？
まずはWeb APIのリリース当初から使えるconvention-basedルーティングについて。
Visual StudioでWeb APIのテンプレートからプロジェクトを作成するとWebApiConfigのRegisterメソッド内にこんな感じのコードありますよね。これです。
// これがconvention-basedルーティングの設定 config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } );
じゃあattributeルーティングってどんなの？
対してattributeルーティングでは以下のようにアクションメソッド毎にルーティングの設定を行います。
// これがattributeルーティングの設定 [Route("customers/{customerId}/orders")] public IEnumerable<Order> GetOrdersByCustomer(int customerId) { ... }
比較
2つのルーティング設定のメリット・デメリットを比較するとこんな感じです。
| ルーティング | メリット | デメリット |
|---|---|---|
| convention-based | ルートテンプレートが一箇所で定義可能。ルーティングルールが全てのコントローラーに対して一貫して適用される | 一般的なREST APIのURIパターンをサポートすることが難しい。例えば/customers/1/ordersのようなURIにしようと思った場合に難しい。 |
| attribute | 簡単に/customers/1/ordersのようなURIのルーティングを設定できる | 使い方による |
あえてattributeルーティングのデメリットを「使い方による」と書いたのは使い方次第でデメリットとなりうる場合があるからです。
例えば、それほどAPIの種類も多くなくURIのパターンも単純な場合（convention-basedで全てのルーティングが事足りる場合）にわざわざattributeルーティングを使用するとメソッド毎にルーティングの設定が必要なため複雑さが多少増してしまうと思います。それでもAPIの多機能化が将来予見される場合には最初からattributeルーティングベースで作るのもありかと思います。
「ベース」と書いたのは実はこの2つのルーティングは混在させる事が可能だからです。うまく組み合わせるといいと思います。
まとめ
attributeルーティングについて超簡単にまとめてみました。
うまく2つのルーティングを使い分けたいですね。
attributeルーティングは他にもパラメータに制約を設けたりと色々設定できます。
attributeルーティングの書き方について詳しく知りたい方はこちらをご覧ください。
今回は以上です。
OData V4のバージョンヘッダについて
OData V4でのバージョンヘッダについて調べたのでメモ。
仕様書：http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.pdf
OData-Version
OData-MaxVersion
- クライアントはOData-MaxVersionヘッダを指定すべきです。
- クライアント側で受け入れ可能なプロトコルの最大バージョンを指定します。
- このヘッダが指定された場合、サービス側は指定されたバージョン以下のOData-Versionでレスポンスを生成しなければいけません。指定されない場合、サービス側は「リクエストはサービスによってサポートされている最大バージョンと同じOData-MaxVersionを持っている」と解釈すべきです。
まとめ
- OData-Versionはクライアント側、サービス側双方で正しく設定する
- クライアント側はOData-MaxVersionも正しく設定しておいたほうが良い
以上。
JavaScript言語仕様メモ
普段の仕事でゴリゴリ素のJavaScriptを書くというのはあまり無い（jQueryを使う方が多い）のですが、
ある程度JavaScriptの言語仕様についてきちんと理解しておいたほうが良いと思い復習・学習したことを備忘も兼ねてメモ。
- varが無い変数は全てグローバル変数
- ブロック（{}）レベルのスコープは存在しない
- 関数の定義方法は以下の3つ
- argumentsオブジェクトが引数の情報を管理する（実はargumentsプロパティはCallオブジェクトのプロパティ。）
- Callオブジェクトは関数が呼び出される度に都度自動で内部的に作られるオブジェクト。
- ローカル変数もこのCallオブジェクトのプロパティ。
- クラスは無い。プロトタイプ（雛形）いう概念だけが存在。
- プロトタイプとはあるオブジェクトの元となるオブジェクトの事。
- コンストラクタでのメソッド追加は「メソッドの数に比例して無駄なメモリを消費する」問題がある
- インスタンス毎に異なる値を持つプロパティをプロトタイプで宣言する意味は無いので以下のように使い分けること。
- 静的プロパティ・メソッドはインスタンス経由では呼び出せない。（関数オブジェクトに追加されたメンバであるため）
- 静的プロパティは基本的に読み取り専用にすべき（変更した場合の影響範囲が大きいため）
- インスタンスに定義されていないメソッドはプロトタイプオブジェクトを辿って呼び出される⇒プロトタイプチェーン（終端はObject.prototype）
- クロージャとは「ローカル変数を参照している関数内関数」
- クロージャとオブジェクトの使い分け
- 変数(群)に伴う処理をひとつしか必要としない → クロージヤ
- 複数の処理を必要とするケース → オブジェクト
Azure Web RoleでSSLクライアント証明書認証を使用する方法
今回はAzureネタです。
とある案件でAzure Web Roleで稼働しているWebサービスにSSLクライアント証明書認証を実装することになり、初めての経験だったのでやったことの記録を残しておきたいと思います。
開発環境
開発環境は以下の通りです。
| IDE | Microsoft Visual Studio Premium 2013 |
|---|---|
| 対象のフレームワーク | .NET Framework 4 |
| Microsoft Azure Tools バージョン | 2.4 |
| クラウドサービスVMオプション | Web Role |
やらなくてはならないこと
Web RoleでSSLクライアント証明書認証をするためには以下を行わなければいけません。
上記の作業はWebサービスをAzure上にデプロイした後でもRDPが有効であれば
手動で設定可能なのですが、やっぱりデプロイ時に自動でやりたいですよね？っていうか
手動の場合はスケールアウトした時にも都度手動設定が必要になるのでクラウドのメリットをあまり受けられずイケてないですよね？
ってことでWebサービスデプロイ時に自動で設定するにはどうしたら良いか調べてみました。
証明書インストールの自動化
まず、証明書のインストールは以下の方法でスタートアップスクリプトで自動化しました。
- デプロイ対象のプロジェクトにStartupフォルダを作成し、その中にAddCert.cmd（コマンドファイル）とhogehoge.cloudapp.net.cer（ルート証明書）を追加。
- 追加した2つのファイルのプロパティで「出力ディレクトリにコピー」を「常にコピーする」に変更。
- AddCert.cmdに下記内容を記述する。見ての通りルート証明書として証明書を追加しているだけです。
certutil -addstore root Startup\hogehoge.cloudapp.net.cer
- ServiceDefinition.csdefにスタートアップタスクの設定を行う
<Startup> <Task commandLine="Startup\AddCert.cmd" executionContext="elevated" taskType="simple"></Task> </Startup>
ここでのポイントはexecutionContextに"elevated"を指定することでスタートアップタスクが管理者特権で実行されるように指定していることです。この辺りの設定はスタートアップ タスクのベスト プラクティスをご覧ください。
SSLクライアント証明書認証有効化の自動化
こちらについては概ねこちらの記事の通りです。
スタートアップタスクでやるのはダメなの？って感じですが、スタートアップタスクはRoleのOnStartより早い段階で実行され、その段階ではまだIIS上にサイトができていないのでサイトの設定を行うにはタイミングが早すぎてNGです。RoleのOnStartでやるのがいいみたいですね。
ここで一点注意点が。
参考記事中だとsslFlagsに"Ssl,SslRequireCert"を設定していますがこれだとクライアントからのリクエストに対して常に403を返してしまいNGでした。
その理由はフラグの設定が不足しているからです。
正しくは"Ssl,SslNegotiateCert,SslRequireCert"です。
下記表はIIS ManagerからSSL Settingsを手動で設定した場合のsslFlagsの値を表したものです。
この表のRequire SSLにチェックありかつClient certificatesがRequireの状態にしたいので
"Ssl,SslNegotiateCert,SslRequireCert"を設定しないとダメということです。
| Require SSL | Client certificates | sslFlags |
|---|---|---|
| チェックなし | Ignore | None |
| チェックなし | Accept | SslNegotiateCert |
| チェックあり | Ignore | Ssl |
| チェックあり | Accept | Ssl,SslNegotiateCert |
| チェックあり | Require | Ssl,SslNegotiateCert,SslRequireCert |
今回は以上です。
MacのPowerPointで個人用テンプレートを使う方法
会社のMacにOffice for Mac 2011をインストールしたのですが
PowerPointの個人用テンプレートの使い方がわからなくて調べたのでメモ。
下記フォルダの中にpotxファイルを配置すればPowerPointがテンプレートファイルとして読み込んでくれます。
/Users/<ユーザー名>/Library/Application Support/Microsoft/Office/ユーザー テンプレート/個人用テンプレート
※「個人用テンプレート」フォルダがない場合は作成する必要があります。私の環境ではフォルダが無かったので自分で作成しました。
