あの時を振り返る
ふと、 初回TDDBC名古屋 が開催されてから5年が経過したことに気がついた。
あの時はブログをやっていなかったので感想記事を書けなかったが、良い機会だし、感傷に浸りたい年頃になってしまったので、駄文(になるだろう)を書いてみる。
なお、これを読んでも得られるものはないだろう。
参加したきっかけ
あれは大学4年になるかならないかという時期、指導教員の [twitter:mikantsuki] と相談してTDDに関連する研究にしようと決まった時のこと。
「そういえば、TDDに関する勉強会が北陸であったらしいんだけど、それが次は名古屋で開催されるみたいだね。 遠いから無理かもしれないけれど、行けるなら参加したら？」
勉強会という存在を始めて知った瞬間である。 きっと良い経験になるだろうと思ったので、行く決意を固める。
今考えると、よく思い切ったものだ。
登録した時期
応募がはじまったよ、と教えてもらったので早速登録しようとする。
twitterアカウントを持っているなら記載してもらえると嬉しい、とある。 持っていなかったので作った。
その頃に研究でデータがほしいから「データ取りに協力していただけると〜」みたいなことをつぶやいた記憶がある。 若干黒歴史だが…。
ちなみに id:t-wada さんのtwitterアカウントを始めてみた時の感想は「サッカー好きなのだなー」。 その頃はちょうどW杯が始まるくらい時期だったので、たぶんそれ系のつぶやきが目に入ったのだろう。
id:bleis-tift さんは、もっと年上な人を想像していた。
初日
ここからはちょっと長くなるかもしれない（後書き：そんなに長くならなかった）。
会場到着あたりまで
初名古屋。 若干迷いながら会場に到着する。
会場の1Fにそれらしき人々を見つけるも、怖くてしゃべりかけることができない。 黙々と開場まで待つ。 (どうでもいいが、この時の愛機はIS01だった)
初勉強会なので勝手がわからず、てきとーに空いてる席に座る。
午前
飛び交っている単語がわからないものばかりだ。
不安が募る。 ただ、タイミングよくイベントが開始されたので講演に集中する。
「なるほど、そういうことか」とか「ここはみかままが講義で言ってた気がする」 とか思ったりなどしていた。
ペアプロデモはRubyでわからないところがでてきたりしたのでその場で調べていたりした気がする。
ペアプロ
お昼ご飯を食べ、ペアプロ前半。 お題が講義の課題とにていたためその時の記憶に引っ張られてしまったなーと反省した記憶がある。
ペアプロ後半。 Mock の存在を知ったのはこの時だ。
お題が進み、時刻の概念が現れた時にペアの方が「これはMockを使うべきなのかな」と言ったのだ。
初めて聞く単語だったので、何をしていいか全然わからない。 わからないから、「わからないので、使い方を見せてください」とペアプロを放棄してお願いした。 ペアプロ体験が目的のイベントでこれを言っていいのかと迷ったが、興味の方が勝った。
レビューあたり
このあたりで、自分の力のなさに絶望していた。 あのくらいプログラミングできないと就職してから仕事できないのか…みたいな。
懇親会
知らない人ばかりだったため、なかなか話しかけることができずわりとぼっちになってたところ、bleisさんやt-wadaさん、kokubo_yusukeさんが話しかけてくださった。 これがなければ気分が沈みっぱなしだったと思う。 喋っているうちに心が軽くなる。
懇親会後は会場に戻ってnagiseさんのGenerics談義をきいていた。 この話もとても面白かった。
デモ用にレガシーコードを提供したのはこの辺りだ。 bleisさんとt-wadaさんがデモ用のちょうど良いサイズのコードがなくて困っているという話をしていた。 ここで自分のPCに使えそうなコードがあることに気づき、懇親会で話掛けてくださったことへのせめてもの感謝の気持ちとして、恥を捨ててコード提供を提案した。
なお件のレガシーコードは、現在はデモ用として一部構成をいじった上でGitHub上で公開されている。コードに関してはそのままなので、レガシーコード改善の練習として触ってみるのも一興かもしれない。
しかしひどいな、これ。 今ならparser combinatorで一発事案だ…制約がある中で書いたコードとはいえ、これはひどい。
余談だが、もともとこのコードにはテストコードが存在していた。 探せばでてくるかもしれないが、JUnit3で書いていたし古傷をえぐるだけだろうと思い掘り返さないでいる。
宿泊部屋
修学旅行みたいに何人かで集まってワイワイコード書いてた。 この時に何名かの方が研究データ取りに協力してくださった。
2日目
寝たら気分すっきり、気力が回復する。
朝食の席ではコンパイラについておしゃべりしていた記憶がある。 そして赤味噌うみゃー。
講演とデモ
講演とデモ。 デモでコードがどんどん改善されていくのはとても勉強になった。
昼食はうどん・そば・ごはんという謎コンボ。
グリーンバンドの話が持ち上がっていたのはこの時だっただろうか。 購入者を募っていたが、私は距離が距離だったためさすがになと思って購入を控えた。 …正直言うとちょっと後悔した。
午後
最初は苦戦しつつ、途中から慣れてきてテストを差し込んだりあれこれ相談したりしていた気がする。
ところで、作業中にきがついたことの一つに、OCamlやScalaでコードを書いていた方々が感動するくらい良い笑顔だったというのがある（(一番記憶に残っているあの顔はきっとmzpさんだ)）。 関数型言語=大学で習ったけどよくわからなかったし怖い*2、と思っていた私にはわりと衝撃的だった。 この衝撃が、今の私を形成するに至った要因の一つである。
レビューの際もわからない単語だらけだったが、この時は開き直っていた。 「自分のレベルの低さに絶望したことなら前にもあるじゃん。メモして今から調べてやればいいんだよ」みたいな。 厨二病全開だったりもした。「絶望は人を次のステージへと昇華させる…」
帰りは時間の都合があったため、ささっと退散。
帰り
t-wadaさんの言葉が脳内でリフレイン。
『TDDBC は「やりたい」と手をあげれば始められるイベントです。』
この濃度のものは、今はおそらくこのイベントを開催しなければ体験できない。 彼らを巻き込みたい。 私より数段できる彼らなら、きっとそれを糧にするだろうから。
気がついたらtwitterで「佐賀でもやりたいなー」と書き込んでいた。
そして新幹線内で爆睡し、特急電車に乗り換えてさらに爆睡し、帰宅後は熟睡した。
振り返って
思い出しながら書いていたら「若かったなー」と思ってしまうあたり、おっさん度が上がっている。
得たことはたくさんあるが、
- 知らなかったことを後悔するよりさっさと調べる
- やりたいと思ったらやれ
- 動いていれば何かにつながる
あたりは特に今も自分の生活や勉強会開催のモチベーションにつながっている。
ありがとう、かつての私。 あの時参加していなければ、絶望していなければ、ここには居ないし今も技術に対して足掻いていることはなかっだろう。
JavaScriptのパーサコンビネータparsimmonをTypeScriptで使ってみる
時代の流れに逆らえなくなってきた感があるので、TypeScriptの練習。
とはいえ、最初は慣れ親しんだものから攻めるのが現実的だと思われるので、パーサコンビネータを題材にする。
ライブラリはこれを使う。 自作するかとも考えたが、特に車輪の再発明する理由がなかったので採用。
お題
このオフサイドルールな入力を解析する。
出来上がり
https://github.com/pocketberserker/sample-parser/tree/3c3f2ea57e0dc647dc88dedb32e6cf1c113af5cb
思ったこと
- tuple を使うと型が推論されてもよさそうな部分で推論されなくなることがあった気がするので、あまり使用しないほうがいいのか？
- 現時点のDefinitelyTyped に登録されている d.ts が最新に対応していないのでちょっと自分で定義してあげる必要がある
- ひたすらメソッドチェーンなので気を付けないとインデントが…
- array.sliceしまくっているけど、これいいのだろうか…？
余談
実は最初のほうはJavaScriptでも書いていたのだが、テスト実行時に「hogefuga not found」を連発されて降参した。 やっぱりコンパイルがないと無理だったよ…。
7月以降に開催するイベントの告知
こんにちは、もみあげです。
最近ブログではイベントの告知をあまりしていなかったのですが、今回はいくつか企画が走っているので紹介しておきます。
FSharp談話室(20) ゲストもくるよ！
Yan Cuiさんの来日に合わせての開催です。 現状参加者がちょっと少ないので、Yanさんの twitter bioにビビッときた方はぜひお越しください。
関数型Scalaの集い
昨年開催されたScalaz勉強会の範囲拡大版ですね。
こちらは発表者を募集しております。 (参加枠は埋まってしまってます…が、運が良ければニコニコ生放送があるかも？)
余談ですが、公開前の仮イベント名はわりとひどかったです。
関数プログラミング交流会
こちらは今のところ発表者のみ募集中です。
枠以上の応募があった場合は選考方式のため、発表できない可能性も」ありますが、枠から漏れた方の参加枠はあらかじめ確保するのでご安心ください。
参加枠は後日募集開始となります。
connpassにフォローブックマーク機能があるみたいなので、忘れそうな方はブクマしておくと良いかもしれません。
ちなみに、前日にはProof Summitが開催されるみたいなので、こちらにも足を運んでみてはいかがでしょうか。
Functional Java の HList を C# に移植して F# 拡張を作った
前々からFunctional JavaにHListが存在するのは知っていたのですが、なかなか手をだせていませんでした。
で、最近Lensライブラリ移植の息抜きにちょっと時間があったので移植してみました。
そもそもHListって？
heterogenous list。 日本語ではたまにヘテロリストとも呼ばれてるみたいですね。 "haskell HList"とか"HList shapeless"で検索すれば何かしら情報は手に入ると思います。
というわけで作った
下記リポジトリから取得できいます。 NuGetにも公開しているので簡単に試すこともできます。
pocketberserker/Data.HList · GitHub
移植自体はそんなに難しくなかった…嘘ですごめんなさい。
実は最初は Pure F# で実装していたのですが、型推論がだめな方向に作動してしまって型エラーをなんとかするのが面倒になった経緯があります。 以下残骸。
Pure F# で HList を実装しようとしたが…型推論に阻まれる
Apply.Cons に型を書けば問題なく通るかもですが、それやるのであればいっそもうC#で実装したほうがいいんじゃない、ということでC#にスイッチしました。
使い勝手は？
HaskellやScala(shapeless)のそれに比べると使い勝手は悪いかもしれません…というかまず機能の差が。 それに彼らはこちらにはないHTやマクロ、型クラスがありますからね。
これは完全に型推論の力に依存して使いやすさが変わります。 サンプルコードを見ればその違いがよくわかるので、いかにリンクを並べておきます。
- Java https://github.com/functionaljava/functionaljava/blob/435cdac93bee544a93f5db9dabbaa0ec693e14e6/demo/src/main/java/fj/demo/HList_append.java#L13
- C# https://github.com/pocketberserker/Data.HList/blob/6db260b37d52764a9819fdc1c0918b6c47ee26ee/examples/HList.CSharpExamples/Program.cs#L10
- F# https://github.com/pocketberserker/Data.HList/blob/6db260b37d52764a9819fdc1c0918b6c47ee26ee/FSharp.Data.HList.Tests/HListTest.fs#L22
HAppendの例だけなのと、C#の実装がこれでよいのか自信がないのであれですが、C#...。
Javaは変数の型を書くのはだるいものの、型は比較的わかりやすいためそんなに考えなくてもなんとかなります。 が、C#はメソッドのほうが推論されないため、4つの型パラメータに何を当てはめれば望みの型になるのか考える必要があります。 F#もC#と同じ道をたどるかと思いきや…この程度のコードだと空気を読んで型を推論してしまいます*1。
まとめ
*1:推論に頼りすぎると前述みたいな型エラー事案に遭遇するのでご利用は計画的に
QuickCheck系統のGenのfilter(suchThat)実装比較
Gen#filter · Issue #5 · xuwei-k/scalaprops · GitHub
こういうissueを投げたあとで、オープンではない場所で色々話していた際にちょっと調べてみたのでメモ。
filter(suchThat)の挙動
あるジェネレータから条件を見たす値のみを出力したい場合に使う
-- こんなシグネチャ Gen a -> (a -> Bool) -> Gen a
処理的には
- 値をランダムに生成して
- 生成した値が述語を満たすかチェックし
- 満たすならその値をGenで包んで返す
- そうでない場合はseedを変えてやり直し
問題点
- 条件を満たさなければ再生性を行わなければならない都合上、再帰関数にするかwhileでぶん回す必要がある
- 実装次第で無限ループに陥る
- 無限ループしない場合でも処理の遅延につながる
対策
- 生成回数の上限を決める
- 生成失敗を組み込む
- 別の機能で置き換える
- 覚悟を決めてぶん回す
lazyかどうかは関係ないはず。
上限を決める
思い処理でなければ現実的な時間に収まる。 ただし、生成方法によってはかならずExhaustedになる。 また、テストがエラーとして扱われる。
生成失敗を組み込む
ただし、この方針を採用すると他の機能にかなりの影響を与える。
- Genの生成結果を取得して新たなGenを作る際に失敗処理を組み込む必要がある
- とくにCoArbitraryとの相性が悪い
別機能で置き換える
定型処理になるしテスト失敗になる確率が増えるが、安定はする。
気合いでぶん回す
- タイムアウト機能必須(なかったら無限ループに陥る)
- 条件を満たす値をみつけるまで繰り返すため遅い
- ユーザは気楽にフィルタリングできる
まとめ
妥協できるかどうかはユーザ次第。
以下追記
QCheckも上限回数決めてますね https://t.co/rWJbXY9SUF https://t.co/EFNJzbt2BV #sml
— ELD-R-ESH-2 (@eldesh) 2015, 5月 22F# User Goup Japan用のgitter roomができました
タイトルの通りです。
yukitosさん++
何する場所？
F#についてゆるふわ喋る場所です。
以前から scalajp/public - Gitter みたいなのがF#にもあるといいなぁ、と思っていたので、嬉しい限りです。
など、なんでもありだと思います。
Quoteメソッドでコンピュテーション式に介入する(実践編?)
全国コンピュテーション式ユーザの皆様こんにちは。
GWの進捗どうですか？
私は駄目です。 ネプテューヌVⅡを1周しようと思っていたのにまだできていません…。
さて、今回はQuoteメソッドを使ってコンピュテーション式への介入しようという話の実践編(?)です。 疑問符つきなのは、プロトタイプしかできてないからという話ですね。
題材は例によってPersimmonです。
読んでおいたほうが良い資料
詳説コンピュテーション式 - ぐるぐる～ コンピュテーション式の変形後を覗き見る #FsAdvent - 眠気と戦う日々 コンピュテーション式の変形後を覗き見るを改良する - ぐるぐる～
コード全貌
persimmon-projects/Persimmon.Pudding at f3789f7cf6682bcdcab0a8ae1a90532bdcdda4fe · GitHub
これを見ればなんとなくわかると思います。
実装の話
というわけでここから本編です。
前提とゴール
今回のゴールは次のようになります。
元のテストコードにモジュールの open を加えるだけで、テスト失敗時にパラメータと簡約結果の一部が出力されるようになる
また、前提条件として
- Persimmonには一切手を入れない
があります。 まぁ、手を入れないからこその拡張ライブラリですよね、的な。
下ごしらえ
Quoteメソッドを追加することで得られる Expr<'T> を自前で解析するのは手間なので、FSharp.Quotations.Evaluatorを fork して改造するため、同じリポジトリに同梱したりライブラリ名が衝突しないように名前を変えます。
また、 FSharp.Quotations.Evaluatorから Compile 以外の public な関数、メソッドを削除します。
他のことは一切できないよということを明示したいとかなんとか。
なぜFSharp.Quotations.Compilerを使わなかったの？
面倒くさかったLetRecursiveがまだ未実装だったからです。
あと、今回はスタックオーバーフローは気にしなくてもいいだろうという慢心もあります。
ただ、パフォーマンス調査次第では乗り換える可能性も残っています。
引数、戻り値をDictionaryに登録する
このあたりの関数を呼び出すことで、Expr<'T> が eval されたときに Dictionary に値が登録されるようになります。
λ式の引数は戻り値が unit な登録関数を手続き的にλ式のbodyにくっつければよいだけです。
値の適用や戻り値の結果を登録するには、Dictionaryに登録したあとで元の値を返す必要があります。
仕上げとして、
こんな感じ
でDictionaryと Expr<'T> のコンパイル結果を返します。
これで、 eval 後に 実行中の変数や簡約結果を取得できるようになります。
コンピュテーション式を拡張する
QuoteとQuote用のRunメソッドを型拡張で追加します。
これで、モジュールをopenすれば Quote が存在することをトリガーに `Expr
今回はDelayが邪魔だったので除去してからEvaluatorに渡していますが、Delayが仮に何らかの処理を行っている場合は除去するべきではないでしょう。
実行結果
open Persimmon
open Persimmon.Pudding.Quotations // 既存のテストコードにこれを追加するだけ
open UseTestNameByReflection
let ``return int`` = test {
return 1
}
let ``fail test`` = test {
let! a = ``return int``
do! assertEquals 2 a
return a
}
このようなテストを実行すると
.x
Assertion Violated: fail test
1. [parameter]
_arg1: System.Int32 -> 1
_arg2: Microsoft.FSharp.Core.Unit -> <null>
a: System.Int32 -> 1
[method call]
Persimmon.TestBuilder.Return(1) -> TestCase<Int32>({Name = "";
Parameters = [];})
assertEquals(2, 1) -> NotPassed (Violated "Expect: 2
Actual: 1")
2. Expect: 2
Actual: 1
============================== summary ===============================
run: 2, error: 0, violated: 1, skipped: 0, duration: 00:00:00.3012002
なんとなくパラメータと簡約結果の一部が取得できているのがわかると思います。
_arg1 がlet! aのBindの変換で現れるλ式の引数、_arg2 が do! の Bindの変換で現れるλ式の引数です。
きちんと実装すればこの辺りを除去できますが、まぁそれは今後の課題ということで…。
まとめ
Quoteメソッドを追加し、式木をいじることでコンピュテーション式に介入することができました。
これをがんばっていくと"コンピュテーション式内の途中経過をいい感じにdump"できるんじゃないかなと思っています。 そういう拡張ライブラリがほしかったので、今回のこれは Persimmon.Pudding として育ててみようと思っています。
