dataという面白そうな記事が公開されていました。今回はこの記事をざっくりまとめてみます。おおかたの人が一度は見たことのあるサイトを題材にクラウドとビッグデータの話をするという内容です。眼鏡を外すということが明らかになります。how-old.nethttps://how-old.net/(図1)の話です。Suiteが持つ顔認識APIのデモ用サイトです。重要ポイントとして、このblogエントリではクラウドファーストで構築するWebには、データ規模の小さなアプリをビッグデータなものへと変貌させうる力がある。Insightsなど。Lakeなどもふくめて)試して学ぶhow-old.netはモバイルファースト・クラウドファーストで作ったことで開発稼働をあまりかけることなく迅速な実験を繰り返せたが挙げられています。クラウド事業者の多くが話しているストーリーですが、今回の話の面白さは次に挙げる動画の側にあります。Worldというイベントのキーノートでこういうことを喋るよー」という予告エントリでした。実際のキーノート映像もすでに公開されています。このなかでは、how-old.netを公開してから得られた利用者の反応やこぼれ話などがユーモラスに展開します。いくつか挙げてみます。冒頭に貼った寿司ツイートはここから辿った)写真を若く見せるために大事なこと4つヒゲを剃る笑わない眼鏡を外す????(ぜひ動画で確認してみてください!)後半のアーキテクチャ面での重要ポイントとして4つ挙げているのは今回のエントリと同じですが、挙げられている中身は少し違ったりします(講演の内容でカバーされる部分があるためか)。10分少々と短めで、わりと英語もわかりやすいのでオススメです。Learning)のblogから面白そうなエントリを掘り出してポイントをまとめるシリーズです。Componentsへと切り分ける方法という話だった。UnityのPrefabっぽいものをワークフローへどのように組み込んでいくかという話で、実際に使っていかないと身につかないんだろうなという感じがした。#1https://wiki.unrealengine.com/Videos/Player?series=PLZlv_N0_O1gbY4FN8pZuEPVC9PzQThNn1のランゲー作成をやってみる。ユーザは固定位置で走っていく障害物を避けたりアイテムを取ったりするコースはどんどん自動生成するイントロ今回はイントロということで初期設定などの話。Personのテンプレートからプロジェクトを新規作成する。このチュートリアルが収録された頃にはまだブルーマンだったんだなぁと思いながら作成(図1)。ブルーでなくなってしまったマン続いて、キャラクターのBPを開いてゴリゴリといじっていく。デフォルトで生成されているBPのうちで今回不要な分を削除していく。固定位置のランゲーを作るのでGamepad、タッチ入力、マウス制御が不要ということで削除。キー入力イベントからRotatorをいじって指定時間かけて指定角度の回転をおこなうあたりはイディオムだなーという感じ。これに方向転換を許す領域としてコライダーを追加して内部の方向転換可否フラグを書き換え、そしてコライダーとの干渉後に一度方向を変えたらもう変えられないように方向転換可否フラグを落として終了(図2)と。方向変えられるようになったマン12分のビデオだけど所要時間は45分ぐらい。メモを取ったりスクショを撮ったりとしつつだけど、結構わたわたとしてしまうので大事なポイントを把握して脳内で手順を再構築できるようになってないんだなーと思う。次回はステージを作るらしい。APIのモックを作ったよー。APIの非公式な.NET版クライアントライブラリを書きました。sandboxがないので管理クライアントや他言語SDKの開発がつらい」という話をしてから1週間ほど経ちます。「よーし足りないAPIを追加するかー」と思ったものの、やはり最低限はテスト環境が無いとリグレッション検出などで結構困るので、テスト用のモックサービスを作ることにしました(手間がでかすぎてyabaiというほどでもないし)。https://github.com/muojp/SoraCommonNet/tree/master/SoraCommonNetSandbox置いておきます。本家でsandboxがリリースされたらひっそりとクローズすると思います。パスワード指定ポリシーは本家のAPIに準拠したりしていますが。complete状態にあります。コードの安定性はさておき、現時点で提供されているAPIセットはよほどのことがない限り製品版まで変更されないはずです。最悪落ちても辛くない系プロダクトを書き始めるのにちょうど良いタイミングということです。6が良いチュートリアルです。5のプロジェクトテンプレートは多少古く、beta5用のものです。じきにVS自体のアップデートで更新されると思いますが、現段階ではひとまずbeta5を使っておきましょう。project.jsonの中身を直接書き換えて依存関係を更新する策もありますが、これを書いている時点ではMicrosoft.AspNet.Server.IISだけbeta8版が出ていないので、更新待ちです*2。軽い気持ちで混ぜたところやっぱりダメだったので混ぜるな危険。しても新betaを使いたければIISをやめてKestrelを使うなど、手はあります。それはそれでハマりそうですが。レスポンスの返し方について少々メモプログラムにエラー処理はつきものです。RESTfulなAPIでもさまざまなエラー処理が必要です。Studioのテンプレートから生成されるValuesControllerは普通に各APIからの戻り値をstringやIEnumerable<string>と宣言します。MVCのランタイム側で適当にJSONへ詰め込んで返してくれます。このフローは型情報をきっちり書く面ではとても良いのですが、不便なところがあります。HTTPのエラー情報を返すうえで厄介なのです。MVCではこの処理に例外を使っていました。HttpResponseException(HttpStatusCode.NotFound);という具合です。5でこのように書いても単純に内部でハンドルされていない例外が発生した扱いとなるだけです。するのかというと、レスポンスをラッピングできるIActionResultというインタフェースに従った値を返すようにします。HTTPのエラーコードはいろいろありますが、要はテンプレコードです。省力でカバーしたいものです。MVC的にはBadRequestResultとBadRequestObjectResultのふたつの選択肢があります。レスポンスのボディがあるか無いかという違いを考えると、このようにわかれているのは仕方ないのですが、呼び分けるのが微妙に面倒です。MVCのControllerは至れり尽くせりで、HttpBadRequestというstaticメソッドがオブジェクトを引数として渡すか否かで生成オブジェクトを切り替えてくれます。これを使って次のようにサクサクとエラー処理を書けます。https://github.com/aspnet/Mvc/blob/f57e1809716/src/Microsoft.AspNet.Mvc.ViewFeatures/Controller.cs#L970-L1009粛々とAPI仕様に従ってコントローラを書く書きます。最初のうちは動作確認をcurlでおこなっていましたが、途中からFiddlerへ変更してサクサク確認していきました。IEからの通信を自動キャプチャとかとても便利でした。API構築は割と生産性高くて良いです。面倒なボイラープレート系のコードはほとんどなく、コーディング時間のうちほとんどをAPI定義→C#コードへの翻訳に使えました。"hoge":"fuga"})で記述とあり、それぞれが結構楽に扱えるようになっています。}(https://github.com/muojp/SoraCommonNet/blob/master/SoraCommonNetSandbox/Controllers/Subscribers.cs#L145-L155からの抜粋)というようになります。URIパス内の特定部分に名前をつけて受け取るリクエストボディのフォーマットを規定したら[FromBody]属性をくっつけて受け取るというのをさらっと書けています。前述のエラー処理に関するポイントと共におさえておくと、楽にサービスを書き始められると感じました。operatorもhttps://github.com/muojp/SoraCommonNet/blob/master/SoraCommonNetSandbox/Controllers/Subscribers.cs#L40のような場所で役に立ちますね。テストのテストをどうするかという話Ruby版SDKなど、他言語用のバインディングを使ってテストする策がありますが、今のところこれ自体のテストは書いていません。適当にデプロイして様子を見るどうせ誰も使わないので適当に公開しておきます。Serviceの無料版はSSL非対応なのでhttpのみです。これは所詮モックで、SoraCommonNet側のコミットフックなどでのテスト実行時のみに利用するものなのでquota的な問題はないでしょう*3。ちなみにこれは無料プランゆえのtipsですが、自動テストから叩く際にはSetUp的なメソッド内で適当なAPIを叩いてスピンアップさせるのが無難です。ないと序盤のテストケースで10秒程度固まり、標準の2秒タイムアウトだと何かと面倒な感じになるでしょう。無駄に検索エンジンから拾われるのもアレなのでrobots.txtぐらいは置いておいたほうが良いのかもしれません。Model前回はプライベートメソッドにはプリフィックスをつける(ただし_はAppleのものと被って事故るので避けるように)という話でした。今回はObjCのエラー処理モデルを理解するという話です。infoという3つの情報を返せるので使い勝手がいいARC下では関数内でNSError**を作ってもautorelease対象となるため返せないこれでは困るので呼び出し側からNSError**を渡して関数内で値を突っ込む方針でいくライブラリの専用NSErrorを用意して区別つくようにしたり、ヘッダにコメントを書いたりするとなおよしとてもすっきりな話だった。5およびDNXのbeta8がリリースされていました。調べてみると1週間ほど前にリリースされていました。5のロードマップ中でbeta8は最後のbeta版と位置づけられているためです。安定性を高めたRC1版を来月(2015/11)中にリリースその後は適宜RCを重ねて2016年のQ1(1-3月)に正式リリースということになっています。5初期リリースからオミットされてしまった要素を除けば全部実装済み!という状態ですね。Core(CoreCLR+CoreFX)の完成度に大きく依存します。CoreFXの完全NuGet主義なフレームワークコード開発はだいぶ進んでいますが、CoreCLRのクロスプラットフォーム実装はまだまだ発展途上にあります。5のシンプルな公式サンプルをいくつかいじり回すだけでボコボコとクラッシュするような状態です。個人的にこれはstabilizeという領域のだいぶ手前にあるように感じられます。Technologiesぱいせんなども世の中にはいるので、短期間に完成度を上げるのも不可能ではないと思いますがMicrosoftがCoreCLRの完成に向けて極端な量のリソースを投下して頑張るかというと現状そんなインセンティブのあるエリアでもないはずです。mono状態でリリースするのでは、というのが今のところの見立てです。5のコードが一切動かない状態でもリリースは可能と。いえ、そろそろバグを見つけたら可能な限り切り分けてせっせとissueを作っていくフェーズには来てるのかなーという気持ちの高まりを感じたbeta8リリースでした(前回書いたように、私はDNXベースでクロスプラットフォームなツールをほいほいと作っていきたいので)。ここでは複数バージョンのフレームワークをお互いに干渉させることなく同一環境へ同居させて使い分けられる仕組みを指します。IL2CPPによる64-bitサポートをAppleのデッドライン付近でひとまずの着地まで持っていったのは本当に凄いと思います。#2前回はデータ構造の序盤ということでリストの話と内包表記の話などでした。タプル今回はタプルです。タプル自体は他の言語でも馴染み深いものです。メモタプルのリストを作る際に異なるシグニチャのものを混ぜてはいけないというのが新鮮に感じた前回やったリストのポリシーを考えると「リストは特定の型の要素の列」ということなのだから当然だった2要素のタプルはペアとも呼ばれ、3要素のタプルはトリプルとも呼ばれるペアに対して先の要素と後の要素を取り出すfstとsndという関数は頻出らしい名前的には覚えやすいトリプルから同様に値を取り出すものについてはちょっと後で出てくるとのこと。24][(6.0,8.0,10.0),(8.0,6.0,10.0)]と強引に解きました。解法を見たら泣けるほどきれいにフィルタリングで条件を詰めていっていてそれっぽかった。[1..c]などの値の持つ性質を反映したリストを作るというのは結構大事なポイントになるんだろうな。多少手が動くようになってきたところで今回は終わり。次回は第2章「型を信じろ!」の話です。Apps(WebJobs)、なかなかいいです。AWSのLambdaと似たいわゆるサーバレスなアプリケーションコードホスティングの仕組みですが、特性は割と違います。Serviceは原則的にリソース予約版がメインで、共有リソース版(Lambdaのような動的アプリ展開版)はおまけ扱い共有リソース版でも最大1GBという比較的大きなアセンブリ群をホストして比較的低頻度デプロイをする想定Lambdaのようにms単位でのコード実行とは謳わない(個人的にはもっと共有リソース版のプラン種類を増やしてほしい)実行ノードからアプリがアンロードされた状態からのデータロードと処理実行は、きちんと計測していませんがLambdaのほうが体感速いです。Serviceは小規模・リソース共有版なら1日あたり60分のCPU利用まで無料で使えます。したバッチを試作するのにうってつけです。Azure上でC#とNode.jsのいいとこ取りをしたいNode.jsというかnpm上には豊富なパッケージが存在します。なかにはNuGetに同等のものがあるものも存在しますが、Node.js界隈に特有のものやNuGetを探すのが面倒なものも多くあります。デプロイモデルを選べる)を使ってバッチを書いているんですが、その中でnpm配布されているコマンドを使いたい場面がありました。餅は餅屋というわけで、Node.js方面でコマンド提供されているものを簡単にC#(.NET)から呼び出していいとこ取りをしようというのが今回の話です。AppsでのNode.jsサポート概要そもそもAzureでNode.jsをまともに使えるのかという話から始まりますが、しっかり使えます。Node.jsのバージョンはデフォルトで「アプリケーション設定」内にある設定(この場合は0.10.32)が使われますが、かなり多くのバージョンをサポートしています。バージョンの指定で詳しく書かれています。今後もきちんと増えていく雰囲気です。Appsで実際にNode.jsが実行される環境はWindowsマシン上です。それがどうしても許せない人は諦めてください。Node.jsベースのコマンドをインストールするここでは、JSONファイル同士のdiffをいい感じに出力してくれるjson-diffモジュールをインストールしてみます。Console」を開きます*1。json-diffを実行します。図1という具合で文字出力が一部化けて残念な感じになっていますがインストール処理は完了します。Apps構成データとして保存されます。installをおこなう必要はありません。C#コードからnode.jsベースのコマンドを呼び出す試しに適当なJSONファイルとしてD:\home\node_modules\json-diff\package.jsonとD:\home\node_modules\json-diff\node_modules\cli-color\package.jsonの差分を出力してみましょう。違うnpmパッケージのpackage.json同士なので、大量のdiffがあるはずです。C#からの外部プロセス作成は通常通りSystem.Diagnostics.Processを利用します。}...という感じでJSONファイル同士のdiffが出力されます。正しいアプリベースディレクトリの取得方法がわからなかったのでD:\home\node_modulesを決め打ちしています。アクセスして出力されるディレクトリ一覧からnode_modulesを探してくるのが正攻法な気もします。正しい指定方法をご存知の方いらっしゃいましたら教えて下さい。Apps上でnpmからNode.jsベースのコマンドを拾ってきてC#(.NET)から呼び出すのは結構簡単なので、手軽に使えそう。文書になるべく図を入れたいけれどRe:VIEWで文章を書いていてサッと図を入れたい場面、結構ありますよね。{Photoshop|Illustrator|GIMP}を開くのが面倒で、結局文字だけでの説明をしてわかりづらくなる場合も多いのではないでしょうか。Re:VIEWよくできてんなRe:VIEWはビルトインでgraphという記法をサポートしています。グラフ表現ツールを使った図に記載のとおりgraphvis、gnuplot、blockdiagをサポートしています。ここではプレーンテキストでブロック図を作成できるblockdiagを使ってみました。blockdiagのインストールRe:VIEW側は環境にインストールされたblockdiagコマンドを叩くだけなので、予めこれをインストールしておく必要があります。Xでのインストール方法はhttp://blockdiag.com/ja/blockdiag/introduction.html#macosx-homebrewのとおりです。blockdiagで終わります。Re:VIEW上でのblockdiagの基本//graph[図ID][blockdiag]{〜}の間にblockdiag本来の記述をおこないます。作図で使える記法はhttp://blockdiag.com/ja/blockdiag/examples.htmlに記載されていますので参照ください。冒頭の図は、次のようにさまざまな要素てんこ盛りで作ってみました。}}基本的には要素間を->でつないでいくだけです。いうように変換されます。便利!これは標準ワークフローに組み込んでもいい感じの便利さですね。かなしさAtom+language-review環境はgraphを今のところサポートしていないので、図2という悲しい感じになります。文法エラー扱いということはもちろんプレビューも全体的に効かなくなるので、ふんわりとどうにかしたいところです。宣伝.NETからSORACOMのAPIをさらっと叩ける非公式SDKをつくりました。https://github.com/muojp/SoraCommonNet気になる点があればふわっとissueに書いて頂けるとうれしいです。本エントリでは、この開発中に使ったツール類や方法論、より深くSORACOMに触れてみて得たものなどをメモします。イントロ届いたSORACOM、さーてどう使おうかなと思って公式の開発者向けWebサイトを眺めていたら「.NET用SDKないじゃん!」と気付いて呆然としたところからスタートしました。サーバから手元の携帯電話まで、広い環境で動作するプロファイル(PCL)で書くことにしました。ここまでやったひとまず昨晩ごりごりと作ってOperatorの新規登録(仮登録メール送信〜登録確認まで)Operatorとしてのログイントークン更新Subscriber(SIM)の一覧取得までできるようになったのでNuGetへ投下しました。逆にSubscriber(SIM)の絞込検索グループ管理イベント管理あたりはまだ書いていません。out!機能から叩いてもエラーを吐くものをいくつか見つけた時点で一旦心が折れたので実装はそこまでになっています。あっ、今回はなるべくRuby版のコードは無視して公式ドキュメントのみで書いてみる縛りでやってみました。初見時からときおりドキュメントに怪しい部分があると感じていたのですが、これに沿って実装することで抜け漏れを洗い出せた気がします。Airからの通信をソラコムのゲートウェイで受けて適宜プロトコル変換、ヘッダ付与のうえで他のサーバへ投げ直す」という仕組みです。聞くと、どんなヘッダがついてくるのか、署名データはどのようなものなのか気になって実際にサクッとHTTPリクエストのログを取ってみたくなりますね。まあサーバを立ち上げてリクエストロガーをこさえて待ち受けるなどするのは結構面倒です。このエリアで「発行されたURLへHTTPリクエストを投げると、その内容を記録して後から調べられるようにしてくれる」というスナックなサービスとしてrequestbinが有名です。残念ながらrequestbinはHTTPSでのデータ送信をサポートしていないようです。少なくともSSL証明書の真正性検証まわりでエラーを吐くので、ゴリ押しで実行してもデータ送信側サーバのポリシーによっては接続確立させない可能性があります。今回の用途ではひとまず避けるのが無難でしょう。いうわけでHTTPSをきちんと通せる代替サービスを探してみました。https://www.runscope.com/がこの用途にぴったり合いそうです。14日トライアル後の料金を見ると月$79と結構な額するのでびっくりしますが、実は「トライアル期間後も月間25,000リクエストまでは無料で使えるので安心してね」と書いてあります。Beamの中継結果をダンプとても便利ですね。SORACOMにはsandboxがないので、実際のIMSIなどを含む情報を第三者のサーバへ渡しつつ開発することになるのが嫌な気もしますが、そういう際にはRunscope自身が提供しているrequestbinのソースを使って自前で立てるのが良いと思います。共有のワイルドカードSSL証明書が導入された環境を用意して...と相応に手間ですが。MQTTや生TCPプロキシ機能あたりも考えていくと、かしこいBeam対向サーバソフトウェアの需要は一定ある気がしますね(署名検証のみやって既存ソフトへ渡すラッパでも良いはず)。Phone端末(MADOSMA)WPのデータセンサー機能がなかなか良いよという話です。Airからリクエストを発生させる必要があります。SIMが刺さっていて、おとなしい(バックグラウンド通信をガンガンしない)環境が必要です。5.x端末のSIMスロットの調子が悪いので、別解を求めて0.2里というところです。手元にある中でなるべくバックグラウンド通信が静かな端末を探したらMADOSMAだったので、こいつに挿してちまちまとアクセスすることにしました。Phoneにはデータセンサーという機能があります。モバイルネットワークの通信量を制御したり、バックグラウンド挙動に制限を加える機能です。Phoneは高速ネットワークが一般的でない地域でのシェアを得るためにか、本機能をなかなかよく作り込んでいます。通信量制限の基本設定をおこなえば、あとはスイッチひとつで基本的にバックグラウンド通信をごっそり遮断できます。いうことが多分ありません。8.1のデータセンサーもちろんiOSなどにも似た機能はあるのですが、iOSの場合は「モバイルネットワーク利用を認めないアプリをひとつひとつスイッチでオプトアウトしていく」という途方も無い作業が必要です。それに、iOSはシステムサービスが相応にデータ通信をおこなっています。そこで、どのご家庭にもあるMADOSMAの登場です。Beam側エンドポイントURLをいじったら適宜QRコードを生成してMADOSMAで開く」というフローをとりました。ここでのポイントはMacなどからMADOSMA経由のテザリングアクセスをしないことです。Storeなどは「Wi-Fi環境だ!わっほーーーい」という具合に無慈悲なアップデートをおこなったりするので、気付いたらデータ転送量がアホみたいに膨らんだりします。Macからcurlを叩いてリクエスト検証をしたい場合には(デフォルトルート指定に気をつけつつ)Wi-Fiとは別にBluetoothテザリング経由で携帯端末にアクセスするなどの工夫が必要でしょう*1。これはUSBドングル形式の3G/LTEモデムを利用する場合でも同じです。接続順などでデフォルトルートを書き換えられないよう、あるいはそれを上書きするように一定注意すればなんとかなるでしょう(そしてたまに事故る)。APNのプロキシ設定でいい感じに足回り整備できないかの検討SIMに対するAPN設定欄にはプロキシサーバの設定項目があります。一時期はWeb閲覧高速化プロキシをここに指定することでWebブラウジングが快適になる、という使い方をちらほら見ました。最近は通常事業者側の透過プロキシで処理されるためあまり見かけませんが。このプロキシサーバ設定で自前のサーバを指定し、不要なアプリの通信やOSアップデートなどのリクエストを遮断できるのでは、という指針です。一定はできると思います。OSのアップデートファイルダウンロードあたりを止められるかはわかりませんが、基本的にアプリケーションのトラフィックを流せるようになりますし。この場合、プロキシに指定するのは開発者自身が用意したサーバとなります。Airでこの仕組みを使うと、相応のものを失うことになります。Beamが持つ「低負荷なMQTTや生TCPをセキュアなプロトコルに変換しておたくのサーバに届けるよ」というおいしい仕組みを利用できないというつらさです。beam.soracom.ioへのトラフィックのみプロキシを介さずに処理できれば両立できそうですが、APNへのプロキシ設定に例外ホストを指定できる環境を見たことがないので、多分無理なのではないかなと。いうことで一長一短ありますね。常用しているAndroid端末からのほとんどのリクエストを叩き落とす系の用途には使えそうなので、ネタとしてストックしておいてよさそうですが(相応のプロキシサーバを用意しないとフィルタリングも結構たいへんじゃないかなぁ)。Phone上でも動かしたかったので、PCLにしました。APIへのアクセスライブラリは割とどれも一長一短あるのですが、PortableRestを使いました。Trackerへのアクセスライブラリに手を入れた際に試してみて「完全ではないけれど事足りる」とわかっていたためです。PortableRestの厄介なところは概ね以下のとおりです。ステータスコードを取得するのが結構大変エラー(4xx、5xx)が戻ってくると容赦なく例外を吐いてレスポンスボディを捨てるので「400を返しつつヒント情報をレスポンスボディで戻す」ようなAPI(SORACOMもこれ)との相性がかなり悪いドキュメント(たまに間違ってる)を読みながらゴリゴリと実装していくパターンとの相性は、あまりよくありません。PortableRestは1年以上バージョンアップが止まっているし、そろそろこのライブラリ自体に手を入れたほうが良いのかもという気もしています。ちなみにmultipartリクエストにおいて複数ファイルのアップロードをサポートしていないという問題もあるのですが、SORACOMのAPIを叩く分には関係ありません。out!から叩いても普通にエラーを吐くAPIがあるたとえば/subscribers/{imsi}/enable_terminationで、IMSIを指定して実行するとサーバが400を返してきます。Json"}という具合です。/subscribers/{imsi}/disable_termination/subscribers/{imsi}/activate/subscribers/{imsi}/deactivateあたりも同様です。JSON本体を持たない系リクエストが失敗している風味があるので、ひょっとすると空ボディでも食わせればうまくいくのかもしれません。実装的にはRuby版SDKの中身を読んでそれに合わせるのが手っ取り早いです。/subscribers/{imsi}はドキュメントに記載されている項目よりもたくさん値を返してくる以下が増えていました。ドキュメントを書いた後で増えたのかもしれません。groupIdterminationEnabledsessionStatusmoduleTypeplanなお、ドキュメントされていないsessionStatusは未使用SIMではnullを返します。そのSIMを使い始めた後には戻ってくる値が変わり、ネストした要素でimeiなどの値を持つようになります。登録済み・未使用状態のSIMを使ってSDK開発をおこなっている際には気付かず、後から念のためテストを一回しした際に見つけて「ヒッ」となりました*2。その後、ひとまずhttps://github.com/muojp/SoraCommonNet/commit/09e8c9037でワークアラウンドを入れました。じきにちゃんとスキーマを書くと思います。optional)}と書かれていますが、実際はtokenというキーで戻ってきます。#0があるので、そこで聞こうという備忘録も兼ねてメモ。書いているあいだじゅう、sandboxがないのでTermination(SIM解約)コマンドとかほいほいとテストできないことがとてもつらかったです。いうことで、いくつか要望をまとめました。Devel(rysandboxがほしいsandboxがほしいsandboxがほしいSubscriberの無効化とかは適当にイベントAPIから流してほしさがある(完全性確保は求めないとしても)加えて、イベントはInvokeAWSLambdaAction以外に普通のHTTP/Sキックをできてほしい...諸々Azureに流したいけどプロキシだけのLambda書くのも嫌な感じこれができると、Azure上で指定容量到達イベントを受け取ってSubscriberをdeactivateするような仕組みをさらっと作れて嬉しいBeam専用モード(Beamのエンドポイント以外への通信を遮断するモード)がほしいBeamのログをS3のバケットにスロッシュしておいてほしいサーバ上で走り続けるプログラムからアクセス元SIMのIMSI検証などをおこなうことを考えると事実上サーバへのID/パスワード保存が必須(トークンを延長し続けていってエラーを吐いたら詰むため)。#34前回はインタフェースの継承と実装の継承をうまく使い分けるという話だった。今回はvirtual関数の代替策を考えるという話。virtualな実体を呼び出す方法がある。処理実体の前後に特定の処理(ロギングなど)を挟み込みたい場合に便利。interface(NVI)イディオムと呼び、デザインパターン方面ではテンプレートメソッドと呼ばれるもの。ここでのテンプレートはC++のテンプレートとは関係ないよというのが書かれている。関数ポインタを使ったStrategyパターンそもそも処理実体がクラス内に存在する必要がない場合にはNVIイディオムはあまりマッチしない。いう場合にはコンストラクタに計算用関数のポインタを渡すなどして外部のものを使う方法がある。この場合は計算ロジックを実行時に選択できるし、同クラスの別インスタンス同士で異なる計算ロジックを利用できる。一方で計算ロジックが元クラス外にあるということは元クラスのpublic要素にしかアクセスできなくなる問題がある。原則的にこれはクラスのカプセル化をゆるめることで解決するしかない。tr1::functionを使ったStrategyパターンさきの関数ポインタによる実装に柔軟性を持たせられるのがtr::functionを使うパターン。関数の代わりに関数オブジェクトを使ったり、指定型の戻り値の代わりにその型へ変換できる任意の型を使ったり、という便利さを得られる。Meyers自身による説明がhttp://www.aristeia.com/EC3E/TR1_info.htmlにある。クラシックなStrategyパターン計算用クラスのツリーを作っていき、そのポインタを計算利用側に持つという伝統的なやつ。計算種類を増やしたくなったら計算用クラスを継承して新規作成すればいい。結果いろいろな方法が考えられるということはおさえておこうねというのが論旨、という話でおしまい。#1前回は関数の記述と適用の話だった。if式にはelse節が必須など、いくつかのルールを学んだ。今回からはデータ構造の話、今回はリスト。リストの基本操作と性質まずはリスト。定義の仕方や扱い方はざっくりと他の言語と変わらないように見える。GHCi内での定義にはletを使うとひっそりtipsが書かれてる。リストの連結は++でおこなう。文字列は文字のリストとして表現されるので、リスト関数は文字列に対して適用できる。リストの末尾に連結をおこなうのは何度もスキャンが必要となるため遅い。リストの先頭への追加はとても速い(スキャンしないから)。これをおこなう演算子が:。cons演算子とも呼ばれる。ここの例で'h'など文字(Cでいうところのchar相当)指定が出てる。前回の中身でアポストロフィは名前の一部に使えるというのがあったけど、この感じだと先頭には使えない(letter表現とかぶるため)のだろう。cons演算子(:)で第一引数になるのは連結対象リストの単一要素。++演算子では両方ともリストを渡す。Haskellでは[1,2,3]は単に1:2:3:[]の糖衣構文と。リストの要素へのアクセスは!!でおこなう。リストの端を超えた場所にアクセスすると例外が投げられる。リストの中に更にリストを入れられるけれど、違う型はダメ。リストの比較は辞書順でおこなわれる。最初に見つかった異なる要素の順序が大小を決定する。空でないリストは常に空リストよりも大きいとみなされる。リストAがリストBのスーパーセットである場合はリストAのほうが大きいとみなされる。その他のリスト操作としてhead/tail/last/initの紹介。空のリストに対してこれらの操作をすると例外を吐く。length関数で要素数を調べたり、null関数で空か否かを調べたりして空リストへの操作が発生しないように処理すると。take関数は要素数を指定して取り出す。0を指定して空リスト取り出しができる。リスト要素数より多い要素を取り出そうとするとリスト全体が返される。[]は空リストを返すだけで特に問題ない。maximumとminimum関数は想像通りの挙動。elemは要素とリストを受け取って、指定要素がリストに含まれるかを返すもの。中置関数として使うことが多いという説明がされてる。レンジ指定はまあまあ賢いよという話。[1..20]は自然数を刻んでくれるし、[a..z]は小文字アルファベットを列挙してくれる。[1.1..20.0]を試してみると[1.1,2.1,3.1,4.1,5.1,6.1,7.1,8.1,9.1,10.1,11.1,12.1,13.1,14.1,15.1,16.1,17.1,18.1,19.1,20.1]となったので、まあこんなもんかなと。2つ目の要素を指定するとその差分を刻みとしてほどよくやってくれると。試しに[1,3..]とすると噂の無限リストがさっくり作れた。思ったらすぐ後にそのまま無限リストの話が出てきた。cycle関数は指定リストを無限にリピートする。repeatは単一要素を受け取ってそれをひたすら繰り返す(yesコマンドぽい)。replicateは指定要素からなる指定長のリストを作るもの。10)は同じになるけど、内部の処理的にはどっちのほうが効率的なのだろう、というのが気になったりした。続けてリスト内包表記の話。Pythonなどでお馴染みという感じだけど、あるリストから要素列を取り出して指定の名前に束縛し、加工方法を記載する出力パートに投げ込んで結果リストを作っておしまい。要素列の取り出しと束縛をおこなうパートにカンマで続けて条件(述語とも呼ぶ)をつけ、元リストからの取り出しをフィルタできると。条件はカンマで区切っていくつも書けるので、複数条件指定のためにわざわざリスト作成を何重にもおこなう必要はない。複数のリストからの取り出しも構文的には条件と同様なんだけど、利用時をイメージするとイマイチ直感的ではなかった。取り出した要素の全組み合わせが結果リストに反映される(5要素のxと3要素のyなどを取り出すと15要素の結果リストができる)。慣れると便利な局面が多そう。lengthっぽい関数を独自定義するくだりはゴリ押しすぎて面白かった。全要素を1に射影してsum*1。リストから取り出したけど使わない値を変数名_に突っ込んで捨てるのはお馴染みのイディオム。試してみると複数のリストからの取り出しで全部同じ変数へ突っ込むこともできるんだけど、その場合実際に取り出せるのは最後に書いたものらしい。[10,100]][10,100,10,100,10,100]ふむ。どっかに仕様書いてあるだろうからそのうち調べそうなメモ。]は慣れるとサクサク読み書きできそうだけど、あまり複雑になりすぎると脳スタックがあふれそうな気もした。外枠から把握していくとルール付ければ破綻はしないか。思ったら、入れ子の内包表記は複数行で書いたほうが読みやすいよと注記されていた。誰かのコードを読むなかで慣れよう。C#+LINQやRxの文脈でも似たことをやるコードは見かけますが、たとえば極単純な配列長チェックに使う場合は確実に無駄ですね。特定条件でフィルタした結果の件数取得などでは合理的な可能性あります。おしまいリストについてはここまで。写経しつつメモを書きながら読み進めたところ、分量的にはあまり進まなかった。各関数の挙動を実際に試しつつなので、まあこんなものかなとも思う。確実に「おっけー!」という部分がまだほとんどないので、出てきたものを片っ端からメモ取る状態になってるのが辛いところ。この先改善していくと良いけれど、あまり改善しないようなら何かしら方法を考える必要がある。[1..])と叩いてみたけど、結果がかえってくる気配がなかったから^Cで止めた。いうことは出来ないんだなぁ。5はなかなか意欲的なバージョンです。過去のプロジェクト構成を完全に捨て去っていくスタイルです。私は去年の暮れ*1に割とがっつり調べたのですが、その後に大きく変わった最近の状況にあまりついていけていませんでした。いうわけで最近の事情について調べた個人的メモです。vNextと呼ばれていました。5では、過去バージョンにあったWindows縛り・.NETランタイムのバージョン縛りや同一サーバ上への複数バージョンインストールに関する厄介事から解放されることになっています。実行環境自体がポータブルになり、サーバ上へのSxSデプロイも超絶簡単(容量面でもコンパクトかつバージョン競合を避けられる方式になる)になるというのが目玉です。Coreプロジェクト)はざっくりと2つに分けられます。軽量かつクロスプラットフォームなサーバ向けランタイム(CoreCLR)の開発クラスライブラリの整備(CoreFX)CoreFXでは画面描画系をごっそり無視しています。Environment)です*2。Coreプロジェクト自体が発表されておらず、非Windowsのクロスプラットフォーム動作においてはMonoを利用するという流れでした。Xを現状で不安定版サポートしている)の64-bitサーバ用環境として育っていくCoreCLRを見ていると不思議な気持ちでもあります。DNXでは依然.NETアセンブリの実行やアプリケーションコードのビルドにMonoを利用するランタイムオプションを提供していますが、Mono側のバージョン固定が多少面倒な部分は否めません*3。5の実サーバ運用においてはMonoが絡むシーンは少なくなっていくのでしょう。Runtimeと呼ばれていたものが改称されました。Monoに関しては基本的にどんどん最新版を使っていけばいいのですけれど。CoreベースのDNXがマトモに動作しないケースも多いため答えを出すまでもないのですが、私はおおむね中期(-3年)まではNo、と考えています。Coreが担っていくことは基本的にMonoとXamarinにとっても良いことと見えます。Monoの太古の需要のひとつは非Windows環境でのASP.NETシリーズ実行だったと記憶していますが、この領域は2015年時点でXamarinのビジネス領域から外れています。現時点のXamarinのビジネス領域は確実にモバイル向けのC#開発環境(可能な範囲でのクロスプラットフォームと共に)で、この領域で同社のリソースを振り向けたいことは山ほどあるはずです。そんななかで(外から見ている分には)Xamarinにとってのサーバ向け領域は「できればそろそろやめたい」エリアと見えます。CoreCLRが進化の果てに他領域(たとえばiOSでのfull-AOTサポート)までを広くカバーするようになり、CoreFXについてもGUIツールキットとの連携または取り込みと各OSの膨大なAPIライブラリに対するまともなバインディングが生えてきたとすると、「ん?これXamarin要らんのでは?」となる世界も想定はできます。innovationとなる可能性がありますね。それはつまりMicrosoftが本気でXamarinを殺しにかかっているタイミングで、おそらくは相応の資金を投入してXamarinを買収することによって実現すると考えるのが妥当に見えます。そのへんはきっと先の話なのでよくわかりません。機能的には以前調べたタイミングからあまり変わっていません。dnvmコマンドRubyのrbenvやNode.jsのnodebrewに相当するコマンドです。ホームディレクトリの下に.dnxというディレクトリを作成し、その下へ各バージョンのランタイムを突っ込んでいくスタイルです。Managerの略とされています。前述のポータブルなランタイムをネット上から拾ってきていい感じにシステム上へ配置し、複数のランタイムを共存させたり利用するバージョンを切り替えたりするために使います。ランタイムのアップデートなどがコマンドひとつで完結するので、これまでの.NET系環境と比較するとかなり楽という感じがします。今のところ非Windows環境でのデフォルトランタイムはMonoです。CoreCLRを明示してインストールするためには-r(-runtime)オプションでcoreclrを指定する必要があります。Xの場合)を使ってバイナリを実行していく流れです。以前はkvmというコマンドでした。kvmって他の用語と被りすぎにも程があるという感じのものだったのですが、dnvmとなりました。他のコマンドも芸なく先頭にdn(.NETの意)と付いて4文字になったのか、と思いきやそんなことはないので安心してください。dnuコマンドNode.jsのnpmに相当するパッケージ管理系を担うコマンドです。以前はkpmという名前で、そのまんまでした。DNXのアプリ定義ファイル(JSON形式)に記述されている依存ライブラリをネット上から拾ってきたりできます。依存ライブラリ管理のみではなく、buildというサブコマンドを使うとアプリのソースをもとにアセンブリを作成できたり、publishを利用するとアプリをデプロイ用に固めたりということができます。publishかけてrsync一発で動くような楽な感じの構成はとても良いですね。packサブコマンドを使うとプロジェクトのNuGetパッケージを作成できます*4。MyGetでの自社向けアプリコード配信とか、なかなか手軽な策になりそうで期待が持てます。Utilityという、色々と諦めた感じの命名です。CoreCLR環境では生成に失敗しますが、同Monoではうまく生成できます。dnxコマンドdnvmコマンドで拾ってきた.NET実行環境のエントリポイントとなるのがdnxコマンドです。X)環境で拾ってきたMono版のdnxコマンドの実体は前述のようにシェルスクリプトですがCoreCLR版は普通にMach-Oのバイナリです。以前はkreというコマンドでした。X)環境でのx64利用について考えるとDNXと組みにするのはMonoよりもCoreCLRのほうが今後楽しそうです。X環境で64-bitランタイムを使いたいシーンではMonoよりも扱いやすいです*6。X向けの通常ダウンロードで64-bit版バイナリを提供していない(自前でビルドはできる)ためですが。CoreCLR+DNXは、実行環境の取得・バージョン固定・アップデートが楽という特性により、クロスプラットフォームなコマンドラインツール*5を作るための優れた基盤となり得るものです。「クロスプラットフォーム動作するユーティリティをサクサク作りたいけどJavaScript書きたくないな〜〜」という人々の大半はPythonが2と3でゴタついている間にgolangへ行った感がありますが、そこC#でもよくね?と考えていくと夢が広がります。環境をあまり汚さずに導入できるし、Mac用の導入手順が公式サイトにある(http://docs.asp.net/en/latest/getting-started/installing-on-mac.html)のでMacの方も試してみて「なるほどなるほど〜〜」となってみると楽しいかも、という感想でした。あ、グラフィックス(GUI)系を扱う必要がある場合にはMonoを使うという具合です。いうかCoreCLRはまだきちんと32-bit構成持たないんじゃないかな。JIT実行にRyuJITのみを使ってるのなら。途中の番号から始まる読書メモシリーズ。Programsは、ObjCを読み書きする際には読んでおいたほうが良い本だと思います。言語の文法を把握してそこそこコードを書けるようになってきたぐらいの人がハマりがちな罠や当該言語流の作法といったものが豊富に書かれていて*2かなりオススメ度が高いです*1。Xのメモリ管理とマルチスレッドで、あとは大体オンラインドキュメントと各種公開コードで学んでいった記憶があります。私はこの本を読み始めてから結構長く、2年少々経ちます。発売日を調べてみると、どうやら刊行後すぐに買って読み始めたようですね。同年の暮れには日本語訳も出ているので、これから読み始めるならこちらのほうが楽だと思います*3。私は、さっと通読した後はObjCを書くタイミングでポイントにより振り返ってたまに読んでいます。当初はメモを取らずに読んでいて途中からメモを書くようにした都合上、このメモは初回なのに#20からスタートというわけです。実際はもう少し手前のメモも残っているので、気が向いたら整理してみます。他のObjC本をそんなにしっかり読んではいないので、比較ベースで語ることはできないのですけれど。他のEffectiveシリーズと共通するところです。Amazonの商品ページを見てみると、翻訳が独特というレビューがついていますね。どの程度なのかは翻訳版を読んでいないのでわかりません。Names前回は名前付けの話で、またしっかり戻ってきたい話でした。今回はプライベートメソッド名にプリフィックスをつけろという話です。ObjCには言語的なプライベートメソッドの仕組みがないのでうまく運用でカバーするというのが前提です。Appleのライブラリ群では_をプリフィクスにしているんだけど、それに倣ってはいかんという話が面白かったObjCの事情として実行時にメソッドが反応できるものを判断するので、不意にでも被ってしまうのは避けたほうが良いコンパイル時に全部確定するわけじゃないという_objc_msg方面の動的解決な話_をプリフィクスとして使ってしまうとクラスの継承タイミングなどで意図せずAppleのメソッドと被る危険性があるなのでp_をプリフィクスにするのが良いという話。言われてみると確かにそのほうが安全だなー、なるほどなー感が強い回でした。前置き3年半ぐらい前にHaskell公式サイトのオンラインドキュメント(どちらかというと仕様書に近い)からHaskellを学ぶという取り組みをしていたのですが見事に頓挫(http://www.muo.jp/2012/04/haskell_03.html)していました。これはその続きの勉強の話です。́・_・`)氏訳の「すごいH本」は1年半ほど前に*1物理本を買い、少しずつ読んでいました。これは評判に違わぬ良い本で、私から(純粋)関数型プログラミングに対する恐怖感というかつらそう苦しそうという先入観を取り払う役目を担ってくれました。型クラスの説明あたりまでしか読み進んでいない状態でずいぶん時間を開けてしまったのですが、その後にScalaの勉強を始めた時に本の説明がすんなり頭に入ってきたのはこの本のおかげだと思っています。tanakhさんにお会いしてその帰りにAmazonで注文したような憶えがあります。ない...!1ヶ月少々ぶりに読もうと思ったんですが、どうも見つからない。自宅の机のうえで手の届きやすい場所へ置いておいたはずだけど全然見つからない。家の中をひっくり返して探してみても見つからない。1ヶ月ぐらい前に数日間アメリカへ行ってきた際の移動時間用に持っていったっきりなのでは、と思い始めました。移動中は結局他のことをやっていて読まなかったため、とても記憶が曖昧です。(中略)探すのを諦めて達人出版会の電子版を追加購入しました。本をなくしたのは何年ぶりだろう。いうわけで以前取ったメモの再構成を交えつつ勉強していくメモです。関数の記述と適用の話1章を読み始める。イントロへ戻ってこいと言われる。