Elm の automaton を F# に移植した

F#

おはようございます、ライブラリ移植するマンです。

つい先日、関数型ストリーム処理勉強会 - connpassという勉強会がありましたねというタイミングで、ElmのFRPライブラリが情報網にひっかかったので移植しました。

https://github.com/evancz/automaton

automaton is 何

ここでは "Arrowized FRP の実装の一つ"、という一言で終わらせてしまいます。 詳しくはリンク先のコード見たり論文読みましょう。

移植コード

https://github.com/pocketberserker/FSharp.Automaton

もう少し名前ひねるべき、という話もありますがまーそこはリスペクトということで。

雑多な話

  • なんで Elm のライブラリ？
    • higher kinded types をサポートしていないので移植しやすい
    • Arrow を明示しているわけではないので移植しやすい
    • Elm の Signal を .NET の System.IObservable で読み替えれば移植が楽そうだった
  • 別に移植しなくても System.IObservable とか Rx でいいじゃない
    • 趣味の問題
  • テストは？
    • あとでかく(ダメじゃん)
  • サンプルコードは？
    • あとでかく

Elixir入門するついでにelixir-supervisordというライブラリを作った

Elixir

だいたいのことはErlangでいいんじゃないかなと思いつつ、まー触ってみないことには何とも言えないよねというのもあり、今回重い腰をようやくあげた。

触り始めて一週間。

ついでにライブラリ作った

https://hex.pm/packages/supervisord

supervisordのXMLRPC叩くだけの簡単なライブラリを作った。 supervisorという名前の影響で検索しづらい…

Elixir とか Phoenixとかの雑感

まだ一週間だからなんともではあるが

  • パイプライン演算子、第一引数が対象なのかー的な
    • F#erとしては最後の引数を対象にしてほしかった
    • けど、統一的という意味では第一引数なのだろうなぁ
    • まぁ、パイプライン演算子便利ですね
  • dialyzerなしで使ったらやはりつらい
    • パターンマッチがある分いくらかRubyとかより安心感あるけど、それでもね
    • でもdialyzer重いんだよなーあーうーとか言ってみる
  • Phoenix、Railsぽいだけはあるなーと
    • ElixirとPhoenix触り始めて一日くらいで最低限の目的を達成できたので
    • とはいえ外れたことやろうとすると苦労するんだろうなぁ…
  • Phoenixが標準にしてるbrunchつらい(JavaScriptじゃないか！という突っ込みはなしで)
  • Erlang OTPべんきょーしておいてよかった
    • relxからのexrmとか、rebar3触ってからのmixとか、わりとさらっと入れる気がする

次の目標はマクロかな…どの言語でも黒魔術系苦手なので手になじむかびみょーだけど…

Persimmonはユニットテストを分散実行する夢をみるか?

F#
  1. みるかもしれない。

どういうこと？

かいつまんで問題を説明すると

という話。

今回採用したもの: 案1

コードというか題材というか

https://github.com/persimmon-projects/Persimmon.Ripe/tree/fee25ceabae567cb21e110fe2df2b4f07b72286c

テストオブジェクトのシリアライズ、assemblyロード

別サーバでテストを実行するためには、テストオブジェクトに関連するassemblyをロードする必要がある。 仮にロードしないでテストを実行した場合は例外投げてテストに失敗する。

しかしどうやってロードするかね、という話の段階でVagabondの出番となる。

https://github.com/nessos/Vagabond

このライブラリはリモート環境でAssemblyをロードしたり色々できる優れものである。 また、通信することを想定してFsPicklerというシリアライザ*1を用いてオブジェクトをシリアライズする。

現時点でのPersimmn.Ripeは、Vagabondを使ってAssemblyやテストをRabbitMQ越しにやり取りするライブラリを提供している。

  1. 入力のdll群をロードしてテストオブジェクト一覧を取得する
    • ここまでは通常のPersimmonと同じ
  2. テストオブジェクトに関連するAssemblyをVagabondで取得、RabbitMQに投げる
    • サーバ側はテキトーに受け取ってAssemblyをロードする
  3. テストオブジェクトをシリアライズしてRabbitMQに投げる
    • インターフェースだとキャストに失敗して原因もよくわからなかったのでTextWriter -> objでやり取りしてる…
    • TextWriterを渡す理由は実行したテスト名を出力したいから
  4. 各サーバがメッセージをconsumeしてテスト実行、結果をRabbitMQに投げる
    • 失敗したらエラーをメッセージとしてなげる
  5. 全体統括者がテスト結果を収集して、全部取得できたら結果表示
    • エラーだったら規定回数リトライ、それでもダメなら自分で実行するとかもやってる

この方式のキモ

  • Vagabondが行っているAssemblyの解析とロード
  • FsPicklerが行っている、IL Emitを前提としたシリアライズ

この二つのようなことができれば他の中間言語を持つやつでもわりとなんとかできそう。

課題

Vagabondが対応できる範囲でしか実行できない。 実際、RabbitMQではなくAzure Service Busに切り替えて試してみようとしたところ、VagabondがAssemblyをロードできず死ぬという現象が発生した。

案2を採用しなかった理由

  • コンパイルする環境整えるのつらくない？
  • 全体統括者がWorkerとなるサーバ群を知らないといけないとかそこそこ面倒
  • プロジェクトファイルのsyncだけでリソースもってかれそう

今後の予定とか

  • VagabondでロードできるAssemblyを増やせないか試す
  • AMQP以外のものにも対応させる
    • 例えばアクターとか
  • ちょっと気になっているRubyのtest_queueさんについて調べる
  • Scalaで似たようなことができないか考える

*1:こっちもnessos製

#fsharp 用テスティングフレームワーク Persimmon 1.0.0 をリリースしました

F#

https://github.com/persimmon-projects/Persimmon/releases/tag/1.0.0

https://github.com/persimmon-projects/Persimmon.Dried/releases/tag/1.0.0

https://github.com/persimmon-projects/FAKE.Persimmon/releases/tag/1.0.0

Testing Framework Meetingで話にだしてたやつの F# のほうです。

first commit 一年からそろそろ一年だし、取り急ぎ入れたいものとかもなかったし、いつまでもbetaなのは微妙な気持ちになるので思い切ってリリースしました。

Persimmon 自体には デモプロジェクトがあったり Persimmon.Dried にはリポジトリ内にサンプルがあるので、使い方はそっち見てくださいということで。

姉妹ライブラリ

今後

  • VS拡張ェ…
  • Persimmon.Dried
    • いくつかの型がnullを生成していないので、nullも生成するようにする
    • そのうえで、NonNullに楽に切り替えられるようにする

Persimmon使ってるプロジェクト

順不同

java-ja.OSSに参加

イベント

初のjava-ja参加でした。

java-ja.OSS - connpass

なんというかよく分からないテンションなので書きなぐってみます。

(遊びで書いた)コードの保管場所としてのGitHub

PC移行するときに面倒臭いしGitHubに置いてそういうリポジトリの通知を無視する勇気をもつ、とかそういう話が途中に発生していた。

これは私もある種同意見というか、私はもっとアレな表現として"GitHubはある種のゴミ箱"という考え方を持っている。 (会場でその発言したのも私なので謝る必要がある。アレな表現でごめんなさい)

私は仕事以外のコードはだいたい暇つぶしとか遊びで書いている感覚で*1、まぁPCを交換するかもしれないしなんか捨てるのももったいないので、どこかに退避させたいときにGitHubやBitbucketが楽だからpushするわけですね。 でまぁ、ここまでならアーカイブとかかっこいい言い方をすればいいのかもしれないですけど、他人が見るわけでもない、自分が見返すこともほとんどない、そんなコードが放り込まれている。 このただの投棄をカッコよくいう気は私はしないという話なだけです。

2015/10/06 13:00頃の追記

私にとっては、なので別に他の人にその定義を押し付けるつもりはありません。

GitHubでのコミュニケーション云々

したくないというか、英語できないマンとしてはno descriptionでpull request送ったり5単語以内に収めるとかよくわからないことしてます。

当日聞きたかったけど聞けなかったこととしては

no descriptionのpull requestが飛んでくるとどんな気持ちになりますか？

というのがあったが、まー本題ではないしいいや。

コミュ障とかパートナーとか

コミュ障というものにはいくつかあると思っていて、今回の場合だと

  • 見知った人にはそれなりに受け答えできる
  • 興味があること以外に関する会話の組み立てができない
  • (初対面だとだいたい「あー…」とか「えーと…」という反応になりがち)

とかそういう意味でのコミュ障ではないかと想像している。 だから勉強会運営などは知り合いメンバーで固めればそれなりになんとかなるし、ある程度定型文での受け答え+興味ある話での受け答えでなんとかなるのではないか、と。


パートナー云々の話は、パートナーという存在がいない身としては「ふーん、大変そうですね」以上の反応しかできなさそうです…。 いやまぁ、この自由こそがパートナーがいないことと引き換えの何かなのだろうとは思いますけど。

枯れたOSSの件

戦略的にはまだいくつかあると思いました。たとえば

  • 「私はつよい。ので、このOSSは完成している。疑問があるならここで質問どうぞ」と書く
  • 信頼度の問題？
    • 例えば定理証明支援器(Coqとか)で証明されたリポジトリに対して「最終更新が昔だから」とかの理由で使わないってあるのかな、みたいな

週末に自分のプロダクトを頑張る

目的があってやってるとこういうことになるのだなーということがしれてよかった。

目的なく気が向いたら自分のプロダクト触っているマンなのでたぶん縁のない話でしょう…。

自己鍛錬としてのOSS

なんか、つよいなーという感想(小並感

前述の通り私は休日は暇つぶしととか気が向いたらコードを書いている面が強いので、たぶん筋トレ的な開発は向いていないだろう。 気が向かないのにやろうとしてもストレスにしかなりそうにないと言い訳しつつ。

プログラマとしてOSSと関わりながら生き残るためにとった生存戦略 - scalaとか・・・

そういえば、上記記事も似たような理由でつよいなーと思ったのでした。 まぁ、私はOSS開発者という括りには入っていないと思われるので生存できてないわけですが。

余談: 暇つぶし道具としてのGitHub notifications眺め

昔からmixiのなにかとか、Yahooニュースのコメント欄とか、twitterとかを数時間(長ければ丸一日)飽きもせず(かといって楽しむわけでもなく)ぼーっと眺めて人生の何割(?)かを過ごした身としては、ある意味GitHub notificationsは暇つぶし手段として良いと思っています。

ただリアルタイムに追っているわけではなく、メールで飛んできているnotificationを、時系列の新しいものから順に気の向くまま目的もなく眺め続けるだけなので、結果として役に立っているかどうかは不明ですね。 ザ・時間の無駄遣い。

感情とOSS(?)

目的あって開発している人はパワーが違うなと思ったり、というか感情爆発させたあとでもきちんとリカバリーできているのすごいなと思いました。 私だったら間違いなく後悔で2週間ほど引きずるので感情で動けない…。

独裁とOSS

仮にscalazコミュニティ崩壊の元となった方にLinus氏やDHH氏のようなカリスマ?(他に単語を思いつかなかった)みたいなものがあれば、ことなる結果を歩んでいたのだろうか。 いやでも、Scalaってそういう優しい(?)独裁者をなかなかみない気がするのでScalaというコミュニティ的に避けられなかった話なのだろうか？

*1:pull requestは例外

勉強会開催について考えていることを雑に書く

雑です。

前提

  • 多くても100名くらいの
  • 発表系イベントで
  • コミュニティで企画するのではなくてきとーに興味ありそうな人に声をかける

開催のモチベーション

  • 私が表立って開催している勉強会は「知らないことは何か、ということを知る」ことを目的として開催しているつもり
  • つまり想定参加者層なんてないようなものだ(と思いたい)

発表者募集

  • 発表者を探すのは大変
    • これだけで力つきる可能性もある
    • ので、発表者が集まらなければ諦めるのも一つの手かなと
  • 話したい人が話したいように話せば良いと思う
    • 何かを得られるかどうかは聞く側の捉え方次第

懇親会 vs 省電力運営

  • キャンセルはでる(一桁だろうが二桁だろうが)
  • 省電力開催するなら懇親会は面倒臭い
  • とはいえ、懇親会の会話で得られることもある

どうしたものやらと思いつつ今の考えは

  • ビアバッシュ可能な会場を選択する
  • 参加者は当日募る
  • 飲み物は調整しやすいし赤字になってもダメージすくないので前日勘で頼む
  • 食べ物は当日頼む
    • ピザは楽
    • しかし糖質制限の方やチーズがだめな方に対応しずらい
    • ここはちょっとまだ模索中…
  • 省電力運営であることを通知する
    • あまりに注文が多いなら以降「懇親会を開催しない」というとか？
  • 参加者募集を前日もしくは当日まで募集しない?
    • 仕事や病気など、どうしても当日キャンセルせざるを得ない理由はある
    • とはいえ、当日参加可能になったと気付ける人は多くない
    • なら、当日だけ募集にすれば参加できそうかつ本気で参加したい人が参加可能になるのでは？

みたいなことを考えつつ、まぁ次回あたりから順次試してみようかなという感じ

募集ページの概要

  • 読まれないことが多い
    • もしくは、読んだとしても忘れる
  • ので、「こういうイベントだよ」というのはイベント名で伝えたほうがよさそう
    • だが世の中厳しい
  • その他のことは前日に別媒体で情報を流したほうがよさそうな気がする

まとめ

なんか色々発生するけど万能な解決策はない。 毎回考えるしかない気がする。

#TestingFrameworkMeeting を開催しました

イベント

発表資料やtogetterは以下にあります。

https://github.com/tddbc/TestingFrameworkMeeting/blob/master/links.md

久々にこの濃度のイベントに参加した気がしますね…。 今やってることに直接参考になる話とかも聞けたりしたので個人的には大満足でした。

というわけで熱にあてられたので記憶している範囲で振り返ってみます。

t-wadaさんの発表

「simplify, amplifyで何かお願いします」とゆるめにお願いしてしまって、あとあとこれで良かったのかと悩んでもいたけど、まーさすがt-wadaさんというか、最初の発表としていい感じに話を広げてくださった。

議論などの流れでアドリブ入ったり脱線したりしたのはなかなか楽しい展開だった。

Evolve slowly

私はてきとーに作ってはGitHubにポイ捨てするタチなのでそんなこと考えてなかったけど、確かにテスティングフレームワークは緩やかな発展のほうが良いというのには納得。 ただ、それで発展が阻害されてしまっては意味ないと思うので、適度な競合ライブラリはあっても良いのではないかとは思っている。

Runnerの挙動が全体的にバッチっぽい

  1. テストケースを収集して
  2. テスト実行して
  3. レポートを出力する

RUnnerとしてはこの流れが主流だけど、もっとincremental(?)にやれるのではという話を(たしかJUnit5の話の流れで)きいて、確かにこの部分はどの言語でもわりと胸中しているなと感じた。 そしてなかなか手を出しづらい場所でもあるよね…。

余談

シンプルな方向に作る人たちってどういう時にCoreに機能を追加するのだろう、と前々から思っていたけど、話きいたり質問して"Coreという存在はなく、小さな各ライブラリに依存性がある"という見方をするのが良い落とし所なのかなと個人的に結論付けた。

あとpower-assertが非英語圏で流行ってるというのに妙に納得した。

Goとテスト

tenntennさんの講演。 Goのテストに加えてGo文化の話も聞けて良かった。

標準パッケージとして色々揃っている

これは後方互換を重視する言語であれば強みだろう。 なにしろよほどのことがない限り公式がメンテするのだから。

ifとassertion

  • Goのtestingライブラリにはassertionがない
  • if文を書いてテストに失敗した時はErrorfなどを返す

というのに対して

  • assertionがぱっと見どこにあるのかわかりづらい

という返しがあったのは、私にはなかった着眼点だった。 個人的にはifもassertionもそんなに変わりない気がしているが、違和感ある人はあるのだろう。

あえて機能を少なくすることで何が起こるか実験しいるのでは

みたいな意見があった。 推測の域を出ないけど興味深い考察だとは思うので、今後を見守りたいものである。

Lint

Kuniwakさんの講演。 私は個人プロジェクトではあまり使っていないが、仕事ではお世話になっているので最近の動向なども含めて色々きけて満足。

"変数名のtypoを単体テストで発見するのは遅すぎる"

静的型付け脳な私としては「それバックグラウンドでインクリメンタルコンパイルしておけば」と思わなくもないが、動的型付けだと確かにこの問題はあるのかもしれない。

省力化ツール

この話をきいて、かつてmzpさんが「機械的に調べられるものは機械が勝手に修正をコミットしてくれるまで行けばいいよね」的なことを仰っていたことを思い出した。

読み手のみの省力化だけでなく書き手の省力化も、というのが今後業界的な流れになってもおかしくないのではないだろうか。

Lintとテストレフームワークを共通化

Runnerを共通化するという発想は私にはなかった考えなので新鮮だった。 どのくらい新鮮だったかというと、翌日から F# と Scala の自作テスティングフレームワークにその機能を組み込めるか試して見る程度には。

ぱっと考えてみた限り原理的にはいけそうなだが、どこまでビルドチェーンを複雑にせずに組み込むかはちょっと考える必要がありそうだとは思ってる。

ASTにに含まれない情報はどうする？

  1. 具象構文木をlintの対象にする
  2. トークン列も組み合わせる

というパターンが存在するみたい(前者はやや実験的傾向がまだ強うそうに思うのだがどうなのだろう)。

余談

「PythonでVimScriptのLint作ってます」「GoでLuaのLint作ってます」の会話が個人的にツボだった。

QuickCheck(という名のテスト合成 + Property Based Testing)

私の発表。 これまた脱線しまくるという状況になった。

power assertに反逆したい

流行にはあえて反逆したくなることがあるので、そういうことを考えていますよという話をちょろっとしていた。 時間があったらもっと話したかったけど本題ではなかったので泣く泣くスキップ。。。

テストの合成

ここで色々と脱線してた。

  • テストの合成とはなんぞや
    • 初出ではなく、おそらく昔からある考えだとは思うけど出典見つけられず…
  • テストが疎結合にならないのではないか?
    • 疎結合とテスト実行速度のバランス次第だと思っている
  • 話し損ねたこと
    • unitを引数に受け取りテストケースを戻り値とする関数 -> 副作用を内包する
    • 変数に束縛されたテストケース -> 副作用を持たない or 一度しか実行しない
    • このあたりは言語によるかもしれない…?要検証

エッジケースの話

  • だいたい人間でもわかりそうな部分のエッジケースしか発見できなさそう

これは一理あるけど、でも経験的に予想外のテスト失敗に遭遇したことがある身としては

性質自体を間違ってしまうリスクをどうやって減らす?

これは難しい問題だと思っている。 個人的には、

  • よくある事例から性質を引っ張ってくる
  • ミューテーションテスト
  • 最初はユニットテストで担保し、ある程度でいけそうだと判断したら入れ替える
  • エラー周りから攻める
    • エラー系は入力集合を作りやすいことが多いし性質も"エラーになる"で終わらせられるから

あたりだと思っているが、根本的打開策になっていないのが厳しいところではある。

これはこれでスキルいるね

性質を導き出せるかは個人のスキルによるので、慣れていないとチーム全員で使うのは厳しいのではないかという指摘(というか参加者の感想)。

これは指摘通り。 まぁ、最初はリファクタリングの際に導入するとかで慣れていくしかないのではないでしょーか。

Serverspec

mizzyさんの講演。 OSSに対する姿勢などもきけて良い学びがあった。

AssurerとServerspecの思想の違い

実装動機が異なるとここまで異なるプロダクトになるのだなーと。

なぜRSpec?

  • 強いこだわりがあるわけではない
  • 非本質的なことには振り回されたくない

非本質的なことに振り回されたくないはかなり同意。 とはいえ、絶対に振り回されないは厳しいと思うのでどこまで最小限にできるかどうかなのかもな、と。

応用的な観点

テストをインフラの方面にもってきた、かつ敷居を低くしたというのを実感できる発表だった。

雑感

  • ここでもUNIX哲学の話が
  • テストあまり関係ないけど、人気ライブラリ開発者のお悩み相談的な部分が観れたのはとても良かった
    • やっぱり苦労している部分*1はあるのだなぁ、と
    • 長期間メンテされてないリソースはどうしているの？ -> コミットした人にping送ったりして、反応ないなら消す(ちょっとここ聞き損ねたのでこういうニュアンスだったか怪しいです…)
  • 若干java-ja OSS編先取りしてしまった感あるけど面白かった!

飛び入り発表

飛び入りでESDocやoktestの話も聞けて、大変参考になった。 この辺りは思うところがあったのでちょっとライブラリに手を加えたりしてみている。

懇親会での話

特に記憶に残っている話を箇条書きで。

  • 枯れた(安定した)ライブラリが最終更新で判断されるのはなんか違う気がする
    • GitHubのstarや最新コミットが目につきやすいので無意識・意識的に誘導されてしまう？
    • どの程度使われているかに注目できれば良いのかも？人気言語まとめとかもどこかの団体が勝手にやってるわけだし
  • 信頼問題
    • Python2からPython3に移行できない理由とか
  • 人は自分が使っている言語を擁護するように動く傾向がある
    • かつてJavaにclosureやinterfaceのデフォルト実装はいらないという一派がいたらしいが、今や彼らはlambdaやデフォルト実装を推し進めている
    • オフサイドルールを否定的にみるRubyistをみかけるわりにその人たちはcoffee使うよね
    • (個人的には数年経てば考えも変わるよねとは思ってるけどあの場で言い忘れてた)
  • DBセットアップのテスト
    • Serverspec的なものをDBにも応用できないだろうか
    • DB界隈とソフトウェア界隈の空気の違い?的な話
  • 懇親会費が余ったのでJUnitに寄付することにした
  • いつv1.0.0をリリースするか
    • あれもこれもとズルズルいってしまう
    • 対象環境が多いとどこまで対応してからリリースすべきか悩ましい
    • 最低限という区切りを設ける/締切駆動開発などで時限式にするとか

furiosaやawsspecの話もきけて満足。

次回やるとしたら

やるかわからないけどこの辺り題材にゆるっと平日夜にやれないかな(議論したい、聞きたいというそこの貴方、発表者探しを手伝っていただけませんか? or 発表者になりませんか?)

  • 1メソッド1アサーション
  • ドキュメントとテストの関連性
    • doctestの話がちらほらでたり、飛び入りでESDocの発表があったので、もっと深堀りしたい
  • power assert

謝辞

企画に関わってくださった皆様、発表者の方々、他のイベントと被りまくっていたのに本イベントに足を運んでくださった皆様に感謝します。 皆様のおかげで、とても意義のあるイベントになりました。

そしてmixiさんとKuniwakさん、朝早くから夜遅くまで会場準備撤収ありがとうございました。 とても気持ちよくイベントを行えました。

*1:というか心の葛藤?