.NET Fringe Japan 2016の個人的な振り返り
dotnetfringe-japan.connpass.com
運営及び発表者として参加しました。
運営といっても、勉強会運営に慣れている方が多かったのでやること・やらないことが初期から明確だった気がします。 当日の懇親会周りの運営を手伝えなかったのは申し訳なく思いつつ……。
発表内容
not_fsharp_deep_dive.md · GitHub
発表内容はぎりぎりまで悩みつつ、気がつけば難産だったらしいkekyoさんとチキンレースを繰り広げていました。
最初はコンピュテーション式のコンパイラ側の話にしようと考えていましたが、朝からそんな話を聞かされるのはつらいだろうと判断して早々に却下。 次にFSharp.Compiler.Serviceに挑戦しようかな、と考えましたが、別の発表でRoslynがでてきそうな気配があったのでこれも見送り。 では自分らしくどういうライブラリを作ったかについて話すか……と思いつつ、いやいやnueccさんの発表があるからなぁ、みたいな。
そうした紆余曲折があった結果、F# がどういう機能を持ち、持たず、その上で具体的に何が作れるのかについてしゃべることにしました。 が、今考えるとFSDNの話は削ってF#とC#関係について話した方が良かった感ありますね。
F#は今の所、.NET Frameworkや.NET Core、C#とは縁を切れない関係です。 おそらく今後もF#は何かしらの影響を与え、そして与えられる立場であることでしょう。 そういう意味で、F#のRFC機能について紹介しました。 RFCはディープではないはず……と思っていたけど、今考えたら「策定段階の企画書読む」って十分ディープでしたね……。
あと、発表の途中で".NET Framework 2.0ではTask
の独自実装が〜"と口走ったのは完全に間違いで、正しくはCancellationTokenSource
です。
大変失礼しました。
全体
今回の登壇者が同じ場所に揃う機会、ないのではないでしょうか。 Partitionの話とか、なかなか聞けないので面白かったです(なお理解度は怪しいorz)。 あとは、本当にマルチプラットフォームだなーという謎の気持ちが大きかったですね。
時間が長丁場だったのは反省点か……とはいえ、もう少し大きな会場で2部屋使えれば解決できるとは思いますが。 そういう意味では、継続するには協力者を増やす必要がありますね。 まぁ、来年のことは来年考えましょう(とか言っているとすぐ来年になる)。
終わりに
異端と呼ばれているイベントに登壇する機会をいただけて、かなり満足しました。
ueberauth_qiitaとueberauth_hatenaを作った
久々にElixirネタ。
といっても表題がすべてを表していますが……。
https://github.com/pocketberserker/ueberauth_qiita
https://github.com/pocketberserker/ueberauth_hatena
ueberauthはElixir向けの認証ライブラリで、RubyのOmniauthに強い影響を受けているらしいです。 TwitterやFacebookなど主要なサービスは一通り実装されているので結構便利です。
とはいえ、さすがに日本向けサービスの実装はなかったので、仕組みを調べるついでにQiitaとはてな用のものを作りました。
ueberauth_qiitaはhexにpublish済みですが、ueberauth_hatenaはとある依存ライブラリをscm形式で依存させている関係でpublishできていません (昔はそれでもhexにpublishできていたのだが、仕様が変わった?)
基本的にはueberauth_facebookやueberauth_twitterと同様の実装になっています。 まぁ、サービスごとに微妙に挙動が異なるので辛い気持ちになりましたが……「もう少し統一感だしてくれー」と叫びたくなりました。
特にこれといった技術的解説点もないので以上。
TypeProviderでFizzBuzzを取得可能な自然数型を生成する
コンパイル時に生成できますね、というだけの話です。
準備: FSharp.TypeProviders.StarterPackのインストール
NuGetからインストールしてください。
注意点としては、ファイルの定義順序がそのままだとコンパイルできない可能性があることでしょうか。
- ProvidedTypes.fsi
- ProvidedTypes.fs
- DebugProvidedTypes.fs
でコンパイルできるはず。
型を生成してFizzBuzzを取得できるようにする
https://github.com/pocketberserker/MLStudy/commit/9a0a2795d5f8915cab89a5badf65d3abe17b1cf1
FizzBuzzは1から100まで
と範囲が明確に決まっていますが、それでは面白くないので任意の範囲でとれるようにしましょう。
ProvidedStaticParameter
でTypeProvider利用時に引数を渡せるようになるとかなんとか。
定義したProvidedStaticParameter群はProvidedTypeDefinition#DefineStaticParameters
に渡すことで登録でき、第2引数で生成の操作を記述できます。
λ式内でやっていることは簡単です。
使う側ではlet inline dump (value: ^n) = (^n: (member FizzBuzz: string) value) |> printfn "%s"
という風に静的に解決された型パラメータを用いてFuzzBuzz
を持つ値を出力できるようにします。
足し算がしたい
https://github.com/pocketberserker/MLStudy/commit/aee21c03a3d7e804c48e9c2fc13655c459645e40
数値なのに足し算できないのはおかしい、ということで足し算できるようにします。
- 数値と型のマッピングをもっておく
- 足し算で得た数値の型が存在するなら
op_Addition
メソッドを定義、そうでないなら何もしない
こう改良することで、生成される範囲の自然数型で足し算ができます。 もちろんFizzBuzzも表示できます。
余談
ここで生成した各自然数型は共通するインターフェースを持ちません。 足し算程度ならインターフェースを用意しなくてもオーバーロードでごり押しできます。
発展
この状態ではリストを取得できません。 HListを用いれば良いはずですが、これに関しては読者の課題とします。
Twitterで流れてきたListReaderコンピュテーション式の解説
先日、Twitterで id:n7shi さんが面白いコードを投下していた。
コンピュテーション式のビルダーは1回しか書いたことがないので、簡単なものでも苦戦した。用途を限定してリストを順に読む例(モナドではない)。 https://t.co/Zfq0M9vm0n
— 七誌 (@7shi) June 29, 2016
これに対しての私のreplyが以下。
@7shi @callmekohei 面白そうだったのでいじってみました https://t.co/yg7dLSHKs4
— ナゲット・もみあげ (@pocketberserker) June 29, 2016
これらのコンピュテーション式はちょっとわかりづらいのでちょっとした解説を試みる。
7shiさん版ListReaderBuilder
7shiさんのコードに少し手を加えたものが以下のコードである。 元コードとの挙動に差はない。
type ListReaderBuilder() = member __.Bind(_, f) = function | x::xs -> f x xs | [] -> () member __.Zero() = fun _ -> () let listReader = ListReaderBuilder() let test = listReader { let! a = () in printfn "%d" a let! a = () in printfn "%d" a } test [1;2;3] printfn "---" test [4]
このコードの出力は以下のようになる。
1 2 --- 4
このビルダーで使われる変換規則は以下の通り。
T(let! p = e in ce, V, C, q) = T(ce, V ⊕ var(p), λv.C(b.Bind(src(e),fun p -> v), q)
T(do e in ce, V, C, q) = T(ce, V, v.C(e; v), q)
T(e;, V, C, q) = C(e;b.Zero())
test
を展開すると以下のようになるだろう(実際はもっと異なるかもしれないが、私はコンパイラではないのでわからない)。
// val test: int list -> unit let test = // let! a = () in ... の展開 listReader.Bind( (), fun a -> // do printfn "%d" a in ... の展開 printfn "%d" a // let! a = () in ... の展開 listReader.Bind( (), fun a -> // printfn "%d" a; の展開 printfn "%d" a listReader.Zero() ) )
- Bindメソッドのシグネチャは
'T * ('U -> 'U list -> unit) -> ('U list -> unit)
- Zeroメソッドのシグネチャは
unit -> ('a -> unit)
((Bindの型パラメータと異なることを強調したかったのであえて'a
表記にしている)) printfn
部分でa
はintに固定される
ことを考えれば、型に問題はないことに気づくだろう。
考察
面白いコードだが、個人的に気になったことがあった。
let! a = () in ...
がなんだか冗長に見えるのだ。
do! ...
のほうが短くて見やすい気がする。
いじってみた版
type ListReaderBuilder() = member __.Bind(g, f) = function | x::xs -> f (g x) xs | [] -> () member __.Return(_) = fun _ -> () let listReader = ListReaderBuilder() let test = listReader { do! printfn "%d" do! printfn "%d" }
このビルダーで使われる変換規則は以下の通り。
T(let! p = e in ce, V, C, q) = T(ce, V ⊕ var(p), λv.C(b.Bind(src(e),fun p -> v), q)
T(do! e in ce, V, C, q) = T(let! () = e in ce, V, C, q)
T(do! e;, V, C, q) = T(let! () = src(e) in b.Return(), V, C, q)
同じようにtest
を展開してみる。
// val test: int list -> unit let test = // do! printfn "%d" in ... の展開 listReader.Bind( (printfn "%d"), fun () -> // do! printfn "%d"; の展開 listReader.Bind( (printfn "%d"), fun () -> listReader.Return(()) ) )
- Bindメソッドのシグネチャは
('T -> 'U) * ('U -> 'T list -> unit) -> ('T list -> unit)
- Returnメソッドのシグネチャは
'a -> ('b -> unit)
- 最終的に残ったリストはReturnが返すλ式で捨てられる
g x
でprintfn "%d" x
が実行され、その戻り値unit
がf
に渡る
こちらも型は問題ないことがわかるだろう。
やりたいことができるか試す
その後の7shiさんとのやり取りで、以下のようなことがやりたかったというコメントを頂いた。
改変後のコードでも同様の挙動にできるか試してみよう。
ビルダーとaddPerson
のシグネチャの順序、コンピュテーション式を書き換える。
// 変更したコードのみ載せています type ListReaderBuilder() = member __.Bind(g, f) = function | x::xs -> f (g x) xs | [] -> () member __.Return(_) = fun _ -> () ... let addPerson data name = if name <> "" then persons.[name] <- data ... row |> listReader { let! company = id do! addPerson (company, "会長") do! addPerson (company, "社長") do! addPerson (company, "副社長") do! addPerson (company, "専務") } ...
最初の値は他の場所で使いたいのでid
で取得する。
残りはprintfn
の時と同じ要領だ。
実際に試してみると同じ結果を返した。
おわりに
結果は同じでも、ビルダーの定義次第でコンピュテーション式の書き方が変わる。 他言語のマクロのように自由ではない限られた変換で何が表現できるのか、疑問は尽きない。
F# API検索サービス"FSDN"を作りました
公開から少し間が空きましたが、改めて周知ということで。
http://fsdn.azurewebsites.net/
このサービスは現在Azureで運用しています。 運用にあたり、株式会社オンザロード様にスポンサーについていただきました。
私がメンテナンスしていく限りはUNIX、Linux環境でも動くようにしておくつもりです。 ただ、メンテナが変われば方針が変わるかもしれません。
検索対象ライブラリ、アセンブリ追加要望は https://github.com/fsdn-projects/FSDN/issues でお願いします。
FSharpApiSearchにべったり依存しているので、機能によってはそちらを先に拡張しないとFSDN側ではどうにもならない可能性が大きいのです。
技術的なお話はまた今度。
Babelの勉強と称してmuscle-assertを作ってみる
私は型がないと死んでしまう(コンパイラと相談しないと考慮漏れが多発して死ぬ)ので、JS系を触る場合は主にTypeScriptなのですが、とはいえ昨今の事情的にBabelを食わず嫌いするのなぁ…と思ったのでライブラリとそれ用のpuluginを作ってみることにした。
勉強前のスキル
- Babel系の情報は追っていたが使うのは(ほぼ)始めて
- 既に別の人が構築したものをちょろっと触ったことならある
- TypeScriptは使える(詳しいわけではない)
方針
こういうのは強い方々の力を借りるに限る。
https://github.com/azu/power-assert-as-tool-demo
Babel pluginの知識は https://github.com/thejameskyle/babel-handbook を斜め読みしつつ、https://github.com/power-assert-js 下にあるbabel pluginを読み漁った。
作るついでに類似品チェック
Persimmon用アサーションライブラリMuscleAssertを作った - pocketberserkerの爆走
この記事の記憶がまだ自分の脳内に残っているうちに移植してみたかったので、今回はこれを題材にした。 一応類似品を紹介しておく。
https://www.npmjs.com/package/assert-diff
やっていることはだいたい同じだが、標準assertをベースにしたかったので自作しようという心持ちである。
あと、似たようなdiff表示はmocha
であれば行ってくれる。
だからmochaであれば必要ない…のだが、eaterなどではそういうわけにもいかないと思う。
成果物?
https://github.com/pocketberserker/muscle-assert https://github.com/pocketberserker/babel-plugin-muscle-assert https://github.com/pocketberserker/muscle-assert-demo
Babel初で一日少々にしては私的には頑張ったほうじゃないですね…まぁ、参考にできるものがおおかったからだろうけど。
muscle-assertは標準のassert.deepStrictEqual
のみを置き換える方針にした。
こうしたほうがシンプルだろうし、他のライブラリとも干渉しなくなるだろうと思った。
そういうわけでBabel plugin側も最低限の置き換えにとどめている。
使い方はデモプロジェクトをみればわかるはず。 表示がしょぼいのはプロトタイプなので勘弁してください。 バグっていたらそのうち直します。
ドキュメントがなさすぎるのは…本気で実装する気力が起きれば書く。
課題
なるべくpower-assertと干渉しないように作りたい…と思っていたのだが、以下の問題にぶつかった。
@pocketberserker babel-plugin-espower は Babel 黒魔術を使って他の全ての plugin に先回りして動作するからです
— Takuto Wada (@t_wada) 2016年6月6日
babel-plugin-espowerが先に変更してしまうのでテストがおかしくなる。
回避方法は今のところbabel-plugin-espowerのpatterns
にassert.deepStrictEqual
をいれないという場当たり的なもの…なんとかしたいが、なんとかできるのかなぁ。
というわけで、今のところbabel-preset-power-assertとの共存は難しいのではないかと考えている。
おわりに
Babelは入門するだけならそんなに時間がかからないようだ。 power-assertの導入は記事が乱立しすぎているし古い情報がノイズになってTypeScriptのときはつらい気持ちになっていたが、Babel前提だとbabel-preset-power-assertがよろしくやってくれるので良いと思う。 とはいえ、楽になったのはあくまでBabelマンだけなのでTypeScriptの時にもう少しどうにかならないか考えてみたくもある。
babel-plugin-espowerのあれはやりたいことを考えると仕方がないのだと思う。 こういうのは後発ライブラリが頭をひねれば良い問題だと思うので、babel-plugin-espwerさんはそのままの強さで居てほしい。
Persimmon用アサーションライブラリMuscleAssertを作った
正確には「作っていたライブラリをPersimmon.MuscleAssertにrenameした」です。
注意
この記事はあくまで私の考えでありpersimmon-projectsの総意であるわけではありません。
前提
- PersimmonはF#用のテスティングフレームワークです https://github.com/persimmon-projects/Persimmon
そんなにF#寄りの話はしないはずなのでこれくらいの情報量で大丈夫なはず…?
Persimmonはpower assertの夢を見るか?
昨今はpower assertの認知度が格段に上がっているようですね。 これはJavaScript向けのpower-assertによるものが大きいのではないかと思われます。
ちょっと脱線しつつPersimmonにpower assertが必要か考えてみましょう。
どの意図でのpowert assert?
assertという言葉は二つの用途で使われいると思います。
- DbCとしての表明(assertion)
- checkingを目的としたassert関数
DbC向けの用途でpower assertが利用されることはまだ少ないようです。 たぶんGroovyとJavaScript*1くらいなのではという認識です。 私が知らないだけかもしれないのですが…。
一方、ユニットテストフレームワークの文脈上で登場するpower assertは様々な言語に存在します。 .NETにもhttps://github.com/PowerAssert/PowerAssert.Netが存在します。 使い勝手は触ったことがないのでよく知りません…。
今回は後者のほうでのpower assertについての言及です。
我々が欲しかったものはpower assertなのか
かつて、下記の記事が界隈をにぎわせました。
そろそろPower Assertについてひとこと言っておくか - ぐるぐる~
状況が少し変わっているのは
- Groovy(こっちは当時から?)やJavaScriptのpower assertでは文字列の比較で差分を表示する
あたりでしょうか。 あとは下記も参照すると良いかもしれません。
https://github.com/persimmon-projects/Persimmon/issues/4#issuecomment-60347183
これにF#的な補足をしておくと
- オブジェクトの一致を確認することが多い
- 判別共用体やレコードなど型を作りやすい環境にあるため、文字列や数値などではなくプロパティを持ったオブジェクトを比較することになりやすい
- パイプライン演算子でつなげるスタイルで結果をassert関数に渡す場合もある
- Elixirのように強力なマクロがあるわけではないので途中の式が解析対象にできない
- power assertのためにスタイルを変えるのか?的な
みたいな話があるようなないような感じです。
プロパティを幾つも持つオブジェクト(例えばJSONオブジェクトをマッピングしたレコード)をpower assertにかけると無駄に情報過多になりやすく、しかしinlineに式を書かないことのほうが多いため必要な情報が増えるかどうかは微妙なところです。 情報が増えないのにグラフィカルな失敗結果が表示されても嬉しいとは思えません。
はたしてこの状況で、苦労してpower assertを実装する必要があるのでしょうか?
少なくとも私には手を出す気力がおきませんでした*2。
力技で不要な情報を握りつぶす
しかし、やはり単純なassert関数は力不足です。
// https://github.com/persimmon-projects/Persimmon/blob/cdba2509e5d48e4cdd47f292f3578b00371c85fc/src/Persimmon/Assertions.fs#L9 let assertEquals expected actual = if expected = actual then pass () else fail (sprintf "Expect: %A\nActual: %A" expected actual)
上記はPersimmon 1.1.0のassertEquals
ですが、とにかく貧弱です。
情報量がsprintf
で出力可能な範囲に絞られるわけですが、こいつの表示はあまりあてにできないと思ったほうが良いです。
ひどいときには型名しか表示されません(それでも言語組み込みのassertよりはマシですが)。
これではさすがにつらい(らしい)のでもうちょっと情報量増やせないか、という話になるのは必然です。 しかしpower assertには懐疑的…どうしようという話になります。
さて、id:bleis-tiftさんの記事ではこう述べられていました。
ユニットテストにおいて、最も欲しいのは「どこがどうなっているか」ではなく、 「どこがどう違っているか」じゃないですかね。
これをPersimmon開発チームでもう少し協議した結果、「オブジェクトのdiffをだそう」という流れになりました。 というわけで出来上がった試作ライブラリがPersimmon.MuscleAssertです。
https://github.com/persimmon-projects/Persimmon.MuscleAssert
このライブラリができることは「等値比較し、不一致だったらオブジェクトの差分をひたすら表示する」ただ一つです。 とはいえ、実際には以下の制約がつきます。
System.Type
はアクセスした瞬間に例外が飛ぶプロパティもリフレクションで取れてしまうためFullName
プロパティのみ対象にする- IEnumerableはdiffの対象にしないで「無視したよ」と警告をだす
- 無限リストのである可能性や、iterateする際に副作用が発生しオブジェクトが操作されてしまう可能性があるため
- stringも未加工で表示
- 今後の方針次第ではdiff-match-patchを導入するかもしれません
コード例と実行結果を見てみましょう。
open Persimmon open UseTestNameByReflection open Persimmon.MuscleAssert type TestRecord = { X: string list Y: int } type TestDU = | A | B of TestRecord | C let ``dump diff list includeing DU`` = parameterize { source [ ([A; A], [A; C]) ([A], [B { X = []; Y = 2 }]) ([B { X = []; Y = 1 }], [B {X = []; Y = 2 }]) ] run (fun (expected, actual) -> test { do! expected === actual }) }
テスト結果では以下のような表示が垣間見えるはずです。
Assertion violated ... 1. .[1] left TestDU.A right TestDU.C Assertion violated ... 1. .[0] left TestDU.A right TestDU.B Assertion violated ... 1. .[0].Item.Y left 1 right 2
値が異なる部分のみに表示を握り潰す、実に脳筋ですね。
命名理由
「普通のアサーションと区別しにくいから名前をつけよう」という話になった際に
Power Assertは時代遅れ、今はMuscle Assertだ!的な話かな?
— ガブさん肉 (@gab_km) June 1, 2016
これがなぜかそのまま採用されました。
power assertと対立する存在なのか?
不明です。
正直なところ、言語によってはpower assertのほうが使い勝手が良い可能性はもありますし、各種power assertライブラリがオブジェクトdiff機能を取り込めば話は変わってくるかもしれません。
とはいえ、一つだけ明確に言える違いがあります。 それはdiffを取得するだけであればASTの操作は必要ないという点です。 世の中にはテストでASTを操作することに懐疑的な派閥もあるらしいですが、そういった派閥にも受け入れられる可能性は残されています。
どんな言語でも実装できるのか
オブジェクト用diffライブラリはJavaから移植しました。
そのライブラリではget
プレフィックスのついたメソッドを対象としていたので、何かしらの制約(getterのような慣習的なもの)を設ければ実装できるのではないでしょうか。
おわりに
ユニットテストフレームワークには以下の方針や理想(?)があると思っています。
- 成功時は沈黙し、失敗時はやかましく
- 「なぜ失敗したのか」を的確に伝える
- もしくは容易に推論可能な形で表示する
power assertがこのまま勢いを増すのか、筋肉式assertの流れが来るのか、第三の概念がかっさらうのかはわかりません。 ただ日々考え、実装し、議論を交わさなければ停滞するだけだと思います。
これを機会に一度、「テスト失敗時に欲しかった情報とは何か」を考えてみるのも良いかもしれません。
*1:https://github.com/power-assert-js にあるツール群を駆使すれば可能という話を聞きかじっただけなので、詳細はその方面の方に尋ねてください
*2:テストケースの構文自体を解析対象にしようと試みたことはありますが、これも情報過多になりそうだったので一旦開発を止めています https://github.com/persimmon-projects/Persimmon.Pudding