Moonmile Solutions Blog

de:code ｜ 日本マイクロソフトの開発者/アーキテクト向けイベント – Microsoft Events & Seminars
http://www.microsoft.com/ja-jp/events/developer/

結論から言えば、何かと前評判が悪かった de:code ですが、蓋を開けてみれば「損はさせません」のツイートは本当でした。値段相応なのか、値段以上なのかはさておき、自分の言ったセッションをメモ書きしておきます。

キーノートはプレゼントの発表が二転三転したのでさておき、

DE-023 Windows アプリ開発、どこへ向かうのか

お昼に「.NET開発テクノロジ入門 2014年版」を買って読みながら奥主さんの話を聞く。行く予定のプレゼン資料は事前に OneNote で配布されていたので、そのまま Surface に入れてひと通り見ておく。紙の資料がないので、手荷物が少なくてよい。メモしたいときは OneNote に書くか、自分のメモ帳に書くか。今回は Twitter にちらちらと流すだけで十分かと思ってメモは取らず。全体というか、de:code の歩き方になるので、デバイス関係の事前内容がわかる。

DE-018 Windows ストア アプリ開発、テスト、デバッグ、ストアへの提出

４人のエバンジェリストがリレー式にストアアプリの最初から最後までってことで、ひと通り流し。初心者向けになっているけど、この道は何度も通るし、少しずつ情報が変わる（便利になるという意味で）。WinJS は少し手を付けてみたい。

TL-003 最新 Web API 開発 ~ASP.NET API 2 とクラウドの活用~

ASP.NET MVC と Web API 絡みの情報集めとして。WCF の複雑さから、REST、OData にして疎通を簡単にする感じに向っている。クロスプラットフォーム（特にマルチクライアント）ならば当然の帰着という感じで。OData はなんとなくわかったので、後で認証まわりと合わせて、ASP.NET MVC と合わせて知識埋め。

DE-015 Visual Studio 2013 Update 2 と HTML5 によるクロスデバイス、クロスプラットフォーム開発の全貌

HTML5/WinJS を使って、ストアプリ、Windows Phone、ブラウザアプリを共通に作れるという話。ブラウザを含められるのは Javascript ならではで、これは、Xamrin.iOS/Android の WebView にも含められるかも。CORDOVA/PhoneGap を使えば、ブラウザ的な UI を持ってくるのは楽になる。逆にストアアプリ風の UI をブラウザに表示させることも可能。

DE-010 デスクトップ アプリケーションと Windows ストア アプリの連携

同じ PC にあるのに、デスクトップアプリとストアアプリの連携は非常に制限されている。のだが、Windows 8.1 Update からサイドローディングに限り、ローカル PC へのループバックを許可、さらにアプリブローカーを通してデスクトップの COM へアクセスできる。これができるということは、大抵の業務ロジックを COM にして動作させることが可能…なんだが、現実は View にべったりだったりして無理なんだろうな。デスクトップ DLL を有効に使いたいときに利用するテクニック。

SV-014 ハードウェア構築・管理のない世界 ～ Azure 仮想マシンの現実 ～

Azure プログラミングはいくつかやったけど、なぜか仮想マシンは作ったことがない。Linux を動かしたいならレンタルサーバを借りたほうが安いから、とも思っていたのだが、スナップショットを取れるとか、ローカルで作成した HD をアップロードできるから環境構築はこっちのほうが効率的かもしれん。試験用に CentOS+CakePHP で作ってみるかも。

DE-005 VWindows Phone 8.1 プラットフォーム徹底解説

Windows Phone は完全にノータッチだったのだが、ユニバーサルアプリがあるので、ストアアプリ（タブレットアプリ）からのアプローチのひとつとして聞きに行く。WP8 から Windows NT カーネルに変わったということで、WinRT と共有化できる準備ができる。Xamarin.iOS/Android に Xamarin.Forms が加わったので、UI 的にも Windows Store/Phone を加える環境が整ってきている。先の WinJS/HTML5/WebView と組み合わせる自由度が高い。ちなみに、私の教材は Lumia 1520 なので解像度がフルHD。電話にしてはでかいので、私としてはタブレットとして使う。Sim を持ってないし。

SN-005 C# を使い倒す iOS/Android 開発の新潮流

人のうわさを聞くためと、どんな人が興味があるのか？な感じでお昼。「C#によるiOS、Android、Windowsアプリケーション開発入門」に興味を持ってもらえるかってこと。環境としては、Visual Studio で作れるのだが、有償というのはそれなりに敷居が高い。カンファレンス内では使用期間3か月のチケットを配るそうなので、まずは使って貰えるパターンかと。ただし、Xamarin の本格的なターゲットは iOS/Android アプリ作成にあるので（今後は Windows Phone も加わるが）、通常のデスクトップアプリ作成経験だけだと難しいかも。Windows ストアアプリ作成との並行して行うのがおすすめ。あと、まだ Phone のほうに目が向いていることが多いが、実は Tablet のほうに勝機がある。

DE-017 Windows ストア アプリ で収益を上げるには

手元にもある「アプリ内課金＋広告 iPhoneプログラミング」の Windows 版。いまのところ、アプリの有償手段は、「ユーザーに直接売る」「内部課金する」「広告を出す」の3種類しかない。無料の場合は「広告アプリとして出す」（最近の映画関連のゲームアプリとかがそれ）、「実力/テンプレートを示す」（他の案件とつなげる）というパターンがある。会社/個人の違いやターゲット（ゲーム/書籍/非ゲーム）もあるし、何を売るか？（コンテンツなのか技術なのか）ってのもある。Xamarinを含めると、iOS/Android/Windows Store/Windows Phone と 4種類になるので、これのそれぞれで、ダウンロード販売/アプリ内課金/広告を表示、の共通化を考える時期なのかも。

AR-006 マルチデバイスアプリ開発における設計戦略 ~ Webか？ ネイティブか？ あるいは両方か？

結論からあれば、いろいろ選択肢が用意されているので、前提条件（既存コンテンツか新規か、簡易アプリか複雑な操作か）によって選択する必要がある。既にブラウザコンテンツがあれば HTML5 をそのまま使えるパターンができるし、さらにちょっとして工夫が加えられる。WebView ならば Invoke を使うとか、逆にネイティブ操作でも詳細やヘルプ表示に WebView を使うとか。カードゲームアプリは WebView を使っているものが多いが、逆にマップはネイティブで作ってカード表示をネイティブらしくHTMLで作るという方法もある。

DE-006 ユニバーサル Windows アプリの画面設計 ～ 4 インチから 82 インチまで ～

実は iPod nano は正方形画面で、いくつかのフォト機器は正方形だったりする…のだが、そうそう、パズルアプリの画面を正方形にしておくと縦と横の両方に対応できる。で、旧スナップの横 500px の縦置きが今後の考えどころ。あと、flush paint のように、横置き全画面以外は動作しない、というのもアリなのかってのは目から鱗だった。確かにアプリがユーザーの使い方を規定してもよい。DPI に関しては考える必要がないし、DPI の高さについてはハード屋さんが熟知しているので、ソフト屋としてはもうちょっとアプリのほうに目を向けて。

DE-007 C#/.NET で iOS/Android アプリを開発 ～ Xamarin で実現するクロスプラットフォーム開発 ～

自分の締めとして Xamarin の話。デモは、おととい発表されたばかりの Xamarin.Forms を含めて。WebView で Razor を使うトリッキーなコードは、なるほどその手があったかという感じ。ループとかバインドを頻発するときには重宝しそうな感じ。いや、後からよく考えたら JQuery とか使ったほうがよいかも w。ただ、このカンファフェンスを通して Windows Phone, Xamarin で感じたのは、ここまで他のプラットフォームを連呼する Microsoft になったのだなということ。キーノートでもあったけど、Windows を連呼していた Windows DNA あたりの時期から一変している。

日経BP書店｜C#によるiOS、Android、Windowsアプリケーション開発入門
http://ec.nikkeibp.co.jp/item/books/P98340.html

そんなわけで、教材として貰った/買った dynabook tab と Lumia 1520 どうするかと模索中。現在dynabook のほうは windows 8.1 update までして、サブディスプレイ状態（苦笑）。Lumia のほうは 8.0 のままで…後で、開発者登録しないと。

自前の関数型電卓のパースが間に合わなかったのと、先週の.NETラボ勉強会で「関数型言語の本質とは？」にうまく答えられなかったので、それっぽい言語を考えてみる。

うーん。私自身は関数型言語自体を扱っている期間が短いので、先駆者の言葉を借りれば「関数プログラミング」から「式が簡略化できる」ことと、「型システム入門」から「型が決まる/推論可能である」ことに尽きる…と思うのだけど、じゃあ、オブジェクト指向型言語との違いは？というと、なんだろう。
実は、「オブジェクト指向型言語は内部に状態を持つ、対して関数型言語は内部に状態を持たない」というのは正しいのだけど、オブジェクト指向型言語に根拠があるので、これは「ごまかし」である（ごまかしと分かっていて言うんだけど）。でも、状態を持たない（あるいは持てないように作る）ので、パラレル化がしやすいし、ドメイン駆動設計による分散に対象になる（内部にアトムを持たないので）。

で、懇親会で話したように、

• 「オブジェクト指向による関数型言語」
• 「関数型指向によるオブジェクト指向型言語」

ってのも考えられるわけで、どちらの排他的なものにはならない。特に F# の場合は、内部でクラスが作れるしオブジェクト指向的な .NET Framework も使えるわけで、そのあたりは良しなにハイブリット的に作れる。加えていれば、LISP は LISP なので、関数型言語に入れると怒る人がいるかもしれない。

以前、Ruby で後付メソッドが作れる、JavaScript のプロトタイププログラミングを知った頃に、すべてのメソッドのプロパティが virtual であればよかろうというのを思いついたことがある。今でいえば、C# の dynamic なんだけど、F# の型推論と組みあわせると、もっと静的言語に近い形で実現できないか？と妄想してみる。

view =
 name = "masuda tomoaki"
 address = "tokyo"
 age = 46

 button.click = 
  db.submit (name,address,age)

name is TextBox
address is ComboBox
age is TextBoxOnlyNumber
button is Button

.submit t = 
 insert into Person values ( t.name, t.address, t.age )

F# も C# もそうだけど、関数定義やクラス定義は前置参照が基本になる。これはコンパイル時点にワンパスになるような工夫でもあるし、コンパイル時の時間短縮でもある。しかし、Javascript や ruby のように後付けでメソッドが作れる場合は（先付のメソッドとは完全に同じではないにせよ）実行時にメソッドの存在をチェックすることになる。

が、これを型推論をフルに使って「あらゆるオブジェクトのメソッド/プロパティを後付けできる」と定義してしまう。先の例だと view で、やりたいことは「name, address, age の3項目があってデータベースに登録する」」ということなので、それを先に書く。これらがどういうものかは後で書く。

「name is TextBox」ってのは、正確に書くと「name that is TextBox」になる。詳細を that で補完していく英語の構文になる。先に適当なことを書いて、後から追記する方式です。

更に言うと、この .submit 部分はあとから上書きができて

.submit t = 
 insert into Person values ( t.name, t.address, t.age )

.submit t = 
 fs = open "person.txt"
 fs.write t.name t.address t.age

のように後ろに二番目の .submit をつけると、これが採用される。普通は前置メソッドが優先されるが、後付け言語 post では、後から定義したほうを採用するので、後ろの .submit が使える。

当然、null オブジェクトのメソッドはどうなるか？とか問題があるけど、Objective-C の nil のように、無視する。こうなると、obj.?method のような変な記号を使わなくていいので、タイピングが楽になる…ハズ。

もうちょっと適当に考えると、

main
 v1 = (10,20)
 v2 = (30,40)
 ans = v1 + v2
 printfn ans

main.(+) x y = 
 ( x[0] + y[0], x[1] + y[1] )

main.(+) x y = 
 ( x.0 + y.0, x.1 + y.1 )

main.(+) x y = 
 this.left  = x.left + y.left
 this.right = x.right + y.right

.left (x,y) = x
.right (x.y) = y

.left   (x,y,z) = x
.middle (x,y,z) = y
.right  (x,y,z) = z

こんな風にベクトルの計算を考える。型推論を使えば、2つの .right メソッドは容易に区別がつくので、間違わない。むろん、プログラミングしているときは間違えそうな気もするけど。

別にコンピュテーション式を調べていたのではなくて、「ひょっとしたらコンピュテーション式とCustomOperation属性で独自の二項演算子がエミュレートできるのでは？」と思っていて探していた訳で、結果的には「できない」なんですが、その派生としてマーチン・ファウラー著のDSL本を斜め読みしたので、その関連で。

32.4 Using Multiple Builders for the calender(Java) のところまで読みながら、局所的なマクロは業務コードを組むと良く出てくるパターンで、lex/yacc まで使わなくても（いや、yacc 使ったほうが手っ取り早いときもあるんですが）アセンブラ風のコマンドが先頭にあってパラメータが続くというパターンは解析がしやすいので、作るのも解釈するのも楽です。それもあって、手軽なものならば１回こっきりの自作コードを作っては捨ててもそんなに惜しくない。と言いますか、そのあたりが「スクリプト」感覚ですよね（最近のLLという意味ではない、昔のスクリプティングという意味で）。

C#やJavaの場合にはメソッドチェーンを使いますが（LINQの場合はクエリ式で並べるというパターンのあるかと）、VBの場合は With というキーワードがあります。

With obj
 .Name = "masuda"
 .Country = "Japan"
End With

みたいな書き方で、obj.Name = “masuda” と羅列する代わりに With obj で囲む方法ですね。C言語の頃は、変数名が長くなると面倒くさいので、

Person *longlonglongobjectname ;
Person *o = longlonglongobjectname;
strcpy( o.Name, "masuda" );
strcpy( o.Contry, "Japan" );

みたいに代入したりします。いや、これだとスタックを消費してしまうから、Person &o = *longlonglongobjectname; な風に参照を使ってみたりする場合もある訳ですが、この手の方法は C# でもよくやります。まあ、C# の場合は、長い変数名とかメソッド名は、インテリセンスを使って記述できるように工夫する方法もよくやりますが。

さて、さっきの With を使う方法は、VB.NET でも使えていて、メソッドにも使えるのですが、VB.NETの場合メソッド呼び出しは必ず括弧が入るので、いまいちスクリプトっぽくないんですよね。そういう点では、F# はスクリプトっぽいし、メソッドチェーンもスクリプトっぽい。見た目は大事です。

じゃあ、どうせ書くならば VBA ということで（VB6でもOK）、メソッドを羅列してスクリプトっぽく書くと、こんな風に書けます。

Option Explicit

Sub test()
    Dim cb As New CalenderBuilder
    With cb
        .Add "DSL tutorial"
        .On__ 2009, 11, 8
        .From "09:00"
        .To__ "16:00"
        .At__ "Aarhus Music Hall"
        
        .Add "Making use of Ptterns"
        .On__ 2009, 10, 5
        .From "14:15"
        .To__ "15:41"
        .At__ "Aarhus Music Hall"
    End With
End Sub

.From とかで羅列していますが、最初の CalenderBuilder オブジェクトに対して With しているだけです。
これを実装するためには、2つのクラス（CalenderEvent、CalenderBuilder）が必要です。

CalenderEvent.cls は単純なデータクラス

Option Explicit

Public Name As String
Public year As Integer
Public month As Integer
Public day As Integer
Public startTime As String
Public endTime As String
Public location As String

CalenderBuilder.cls がビルダークラス

Option Explicit

Public items As New Collection
Public cur As CalenderEvent

Public Sub Add(title As String)
    Set cur = New CalenderEvent
    items.Add cur
    cur.Name = title
End Sub

Public Sub On__(year As Integer, month As Integer, day As Integer)
    With cur
        .year = year
        .month = month
        .day = day
    End With
End Sub

Public Sub From(s As String)
    cur.startTime = s
End Sub

Public Sub To__(s As String)
    cur.endTime = s
End Sub

Public Sub At__(s As String)
    cur.location = s
End Sub

関数名が To__ のようにアンダーバーをつけて伸ばしているのは、スクリプトにしたときにインデントを揃えるためとキーワード逃れです。From, To__ 関数の中身はサボっていますが。

じゃあ、コンピュテーション式風にIfとかWhileを再定義できるかという出来ないわけで、コンピュテーション式とは程遠い訳ですが、DSL には近いかなと思ったり。
DBの初期設定とかヒアドキュメントに書けるのが利点かと思います。コードに直接設定を書くので汎用性はないのですが、むしろ汎用性を無くして設定ファイルが散逸しないメリットを活かせます。

ちなみに、この場合はビルダークラス使わなくても、大抵の場合は以下で書く。
CalenderEvent メソッドのほうに From メソッド等を移動させて、こんな感じ。

Dim obj As CalenderEvent
Dim items As New Collection

With obj
	Set obj = New CalenderEvent
	items.Add obj
    .Name "DSL tutorial"
    .On__ 2009, 11, 8
    .From "09:00"
    .To__ "16:00"
    .At__ "Aarhus Music Hall"
         
	Set obj = New CalenderEvent
	items.Add obj
    .Name "Making use of Ptterns"
    .On__ 2009, 10, 5
    .From "14:15"
    .To__ "15:41"
    .At__ "Aarhus Music Hall"
End With