git-gsub v0.0.6をリリースした

リポジトリ内のファイルを一括置換するGitのサブコマンドgit-gsubの新しいバージョンをリリースしました。

なかなか便利になったと思うのでお試しください。

新機能

ファイル名の変更も一緒にできるようになった

クラス名を変えたい時はgit gsub Foo Barとファイル内の文字列を置換した後、ファイル名をgit mvなりで別途変更する必要がありました。これは非常に面倒。なので、--renameオプションを渡すとファイル名も変更するようにしました。

内部的には

for f in $(git ls-files  | grep Git::Gsub)
  do mkdir -p $(dirname $(echo $f | sed 's/Git::Gsub/Svn::Tr/g'))
  git mv $f $(echo $f | sed 's/Git::Gsub/Svn::Tr/g') 2>/dev/null
done

というようなスクリプトを実行しています。

実験的な機能としてSnake/Camel/Kebab caseに変換した文字列も置換するようにした

例えばRailsプロジェクトだと OrderDetail ってモデルがあると、 order_detail という変数があり、 order-detailというDOMのクラス名があったりします。これをそれぞれ置換するのは面倒なので、--snake、--camel、--kebabというオプションでそれらも一括で置換するようしました。

--renameオプションで行う置換にも適用されます。これによってRailsプロジェクトのモデル名変更がコマンド一発でほぼ完了するようになりました。

ただこれ、ActiveSupport::Inflectorを使っていて、これが下記のようなRubyっぽい変換をします。これは他の言語では迷惑なはず。 「実験的」としているのはこのためです。なんとかしたい。

'ActiveModel::Errors'.underscore # => "active_model/errors"

変更点

sedで行っていたファイル内の文字列置換をPerlに書き換えました。これでgsedが入っていないと使えないって不具合もなくなったはず。もともとsedの文字列置換機能はPerl由来である、など教えてくれた @knu に感謝です。

その他所感

  • 自分が使いたくて作っているので、内部実装はかなり雑
  • 雰囲気でPerlのワンライナーを書いているので若干不安
  • テストが読みにくいのでなんとかしたい

2016年に読んだ本の一部

確か年明けに書いたと思われる下書きが出土したので投稿してみます。一年分まとめて書くのは無理ですね…。

会社で「論理的な文章とは」というような話をしていて、若者に一冊読むならこれかなと思い、再読した。よく外銀・コンサル出身の人が言う「ファクトベース」は実証的な学問のやり方がベースになっているので、ファクトベース思考を身に着けたいなら、実証的な学問のやり方を理解するのが正確な近道だと思っている。その作法を知るにはよいテキストだと思います。

ついでにこれも今再読している。『論文の教室』と被る部分があって、そちらは作法がメイン（作法も重要です！）、こちらは主張の仕方がメイン。クリティカル・シンキングの本として、哲学の入門書として、とても良い本です。久々に読んで、自分の思考法のベースは哲学なんだなあと再認識した。もう卒業して10年経ってるんだけどな。実証的な主張がしにくい価値に関する主張の説得力をどうやって増すか、あたりで、哲学が「役に立つ」のを見て取れるはず。

名作に潜む数学的な美しさを説明する本。美が何で構成されているかを知ると、理解の解像度も上がります。

久々にRDBを使うので読んだ。有名な本なのであまり解説はいらないと思うけど、同じ轍を踏まぬよう読んでおく価値がある本でした。

久々にRDBを使うので読んだ。発行されたSQLの裏側で何が起こっているか、なんとなくでも理解しておくと思わぬところで役に立つ。たしか役に立った瞬間があったんだけど忘れてしまった…。あまり楽しくない読書になるかなと思ったけど、RDBMSの仕組みを理解するのは知的刺激があった。よい一冊でした。

めちゃくちゃ面白かった。地方銀行とは何か、いま進んでいる金融庁の金融改革とは何か、それで地方銀行はどうなるのか、が、金融改革をやってる人たちの群像劇で補強されつつ語られる。娯楽として読める本。Amazonのレビューも面白いので（読了後に）見てみてください。

とある勉強会で発表するために再読した。冷戦期を代表する大統領、リチャード・ニクソンが同時代の国家元首たちを語る。当然ながら国家元首の振る舞いはリーダーシップ論として有用。あと、僕らの世代が注目すべきは、イデオロギーで世界が2つに分かれて、お互いに大量の核弾道を積んだミサイルを向けあっていた時代、今は誰も上手くいくとは思っていなかった共産主義が一つの選択肢だった時代の空気。すこし追体験できる。本人が書いたのかはわからないけど、文章も読ませる。

今年ベスト。中国共産党の凄まじい権力闘争を忍耐、実務能力、知性、人間性で生き抜いた周恩来。彼がいなかったら中華人民共和国も毛沢東も文化大革命もここまでうまく（うまく…？）いかなかったはず。確実に自分にとって必要なパーツだった周恩来を毛沢東は死ぬまで警戒し続け、信じられないことまでして（詳しくは是非読んでみてください）失脚させようとするが、周恩来は粘り強く回避する。この本を読めば、辛いことがあっても周恩来だったらどうするかなと考えることができるようになる。我慢の一択なんだけど。

ソビエト連邦にはマルクス・レーニン主義という「正解」があった。正解がある社会は恐ろしい。権力闘争の結果、正解を正解たらしめていたロジックから個人に権威が移譲され、濫用される。『周恩来秘録』でも見てとれる現象だった。これは組織の失敗といえるのではないか。20世紀の大失敗組織のひとつ、旧日本軍については『失敗の本質』で教訓がまとめられてるけど、ソビエト共産党、中国共産党のそれは見当たらない。誰か書いてくれないかな。もう一つ、「不正解」とみなされた人間は排除される。『周恩来秘録』と違って、この本では排除というか虐殺にフォーカスがあたっている。イデオロギーが合わない人間がすべて殺される。そんなことあるのか？と思う人は是非読んでみてほしい。

フィリップ・グラスの自伝。自分の人生で音楽が趣味というレベル以上に重要で、ニューヨークが好きな人は絶対読んで欲しい。2016年もっとも感動した一冊だったような。

シェフの小説。不良。

CTOなので久々に読んだ。読む価値ある。「賢くて、物事を成し遂げる人を雇え」ってメッセージは普遍的。

プラグマティズムあまり詳しくないのとブランダムなど新しい（僕が哲学科を卒業したのは10年以上前なので結構取り残されている）哲学者の話も読めるということで読んだ。アメリカの哲学はどうしても論理実証主義から分析哲学って流れの説明が多くなっちゃうので、そこら辺の補強に便利だった。普通に読書としても面白い。

泣ける。統合失調症に関心がある人は是非。

ハーバード大学哲学科が教える、哲学を学ぶ理由

ハーバード大学哲学科のサイトにあった「なぜ哲学を学ぶのか」があまりに良かったので、精度が上がったという評判のGoogle翻訳を試すついでに訳してみました*1。

僕も大学で哲学を勉強していました。もはや半可通でしかないのですが*2、後半にある「哲学があなたに教えるスキル」は僕が仕事をする上で全ての基礎になっています。哲学を勉強してよかった。

原文はこちら。訂正などありましたら是非コメントください。

Why Study Philosophy? | Harvard University Department of Philosophy

カリフォルニア大学バークレー校の哲学者であるジョン・キャンベルは、哲学についてこう考えていますー「それは、私たちがふだん凄いスピードで行っていることを分解し、説明し、評価する。すると、別の選択肢が可能であることがあきらかになる」。

哲学を学ぶことは、何千年もの間人類を悩ませてきた問いに、過去存在した偉大な思想家たちとの対話を通じて取り組むことです。1つ2つの授業を取る、集中して哲学を学ぶ、どちらの場合も、生徒たちは哲学を学ぶことが大学生活で最も有益な知的体験であることを知ります。哲学を研究する主な理由は、反省と熟考の本質的な価値を知ることです。

それにもかかわらず、哲学に惹かれている多くの学部生は、哲学の学位は貧困への道だと心配しています。しかし実際のところ、哲学を学ぶことで得られるスキルは、不安定かつ急速に変化する経済環境の中で、高い市場価値があります。多くの特化したスキルは最終的に時代遅れになり、いずれの場合でもほとんどの人は人生の中で何度もキャリアを変えてしまいます。哲学があなたに教えるスキルは、常に需要が高いはずです。明快に思考し、書くこと。認識されていない前提を明らかにすること。複雑なアイデアを明快に説明すること。つながりと含意を解きほぐすこと。幅広い文脈で物事をとらえること。慣習に挑戦すること。一言で言えば、哲学はどんな業種でも適用できるスキルを提供します。

ハーバード大学の哲学専攻生は、多様で価値あるキャリアを追求してきました。哲学の卒業生は、法律、財務およびコンサルティング、ビジネス、インターネットのスタートアップ、医学、ジャーナリズム、芸術、非営利の仕事、教育、学術（哲学と他の学問分野の両方）で成功を収めています。あなた自身に問うべき質問は「私は哲学の学位で何ができますか？」ではなく、「私が哲学の学位でできないことは何でしょうか？」でしょう。

*1:Google翻訳したものを自分で直しました。文体が不自然だったり、なぜか訳出されない箇所があったりで、結構直した

*2:先日学部の友人と話していて「藤村君が学生の頃とは常識が変わった」と言われました。ですよねー。いつかじっくり時間をとってキャッチアップを試みたい

起業してました＆エンジニア募集しています

近況報告としては、退職のご報告からすっかり間が空きました。TechCrunchや東京新聞の記事で既にご存知の方もいらっしゃるかもしれませんが、2015年10月にProper, Inc.を共同創業し、現在「近所のつながりを通して、地域の課題を解決する」というミッションのもと、ご近所SNSマチマチを運営しています。

前職をやめてからは結構悩みましたが、こういう時は一番ハードルが高くてテンションが上がるやつを選ぶべきだ！ということで「自分でやる」って選択肢を選びました。パートナーは、直近だとOh My Glassesをやっていた六人部生馬です。複数のスタートアップを経験している、Rubyistと仕事をしている、神奈川出身であるなど共感できるところが多々ありつつキャラ的にも能力的にも補完的という、良いチームになりました。

今、マチマチの開発チームは、現在エンジニア1人（僕）デザイナー1人（元山さん）の2人です。まだまだやるべきことが満足のいくスピードでやれていない状況です。また、現状Web版だけのマチマチですが、多くの方からアプリ化の要望を頂いています。ということで、一緒に働く仲間を募集することにしました。具体的にはWebエンジニア、iOSエンジニア、Androidエンジニアに加えて、ビジネス側のメンバーを募集しています。下にWantedlyのリンクを貼っているので、詳細はそちらをご覧ください。

話は変わりますが、新しい事業を始めるにあたって最も重要な事は「適切な事業領域を選ぶこと」だと思います。

日本は、高齢化、過疎化、少子化、厳しい子育て環境、衰退しつつある地域コミュニティと、大きな課題をいくつも抱えた課題先進国です。また、ベーシック・インカム、地域通貨などの新しい再分配のあり方の登場、シェアリング・エコノミーの浸透による家事、買い物など生活スタイルの進化、ライドシェア、自動運転車などで変わる都市における移動と距離感、スマートシティと呼ばれる電力、エネルギーの技術革新など、いま社会には多くの変化が訪れています。

そして、これらの課題・変化、すべて具体的には「地域」で起こっていることです。

ここ、僕らの持っている人生の貴重な時間を使う先として、課題としてのサイズと意義は十分ではないでしょうか。テクノロジーで改善できる事は沢山あります。時間とエネルギーと熱意をつぎ込むに値する、魅力あるフィールドだと思います。僕達はこの領域に対し「つながり」という軸で手を打ちはじめました。

ちょっと熱くなってしまいましたが、そんな感じで面白い事をやっています。良い経営チームとめちゃくちゃ面白い問題は用意できたと思うので、いいチームといいエンジニアリングで、どんどん問題を解いて行きましょう。ぜひみなさんの力を貸してください。

少しでも面白いと思ったら、下記のWantedly、 daisuke.fujimura@proper-inc.com 、各種ソーシャルアカウントでお気軽にご連絡頂ければと思います。みなさんお忙しいと思うのでランチでも行きましょう。転職考えてない人も歓迎です。なお、マチマチの技術的な側面については末尾に付録としてまとめておきましたのでご笑覧ください。

あと、Forkwellさんのミートアップでパネルディスカッションに参加させて頂きます。是非お越しください！

forkwell.connpass.com

直前ですが、Haskell Dayでチュートリアルのチューターをやる予定です。こちらも是非！Simon Payton Jonesさんが来ます！

connpass.com

付録: マチマチを支える技術 ダイジェスト版

現状、主要なコンポーネントは

という構成でやっています。サービスの初期ということで、仕様の変化が多く、かつ長期的なコードベースへの影響が大きいので、なるべく素直な構成とコードを心がけています。変更しやすいよう、テストは割と手厚く書いています。

その他、やってることや特徴をピックアップすると、下記のような感じです。

  • GitHub上の全ブランチをデプロイして動作確認できるようにしている
  • 開発用のミドルウェア（DBとか）はdocker-composeで管理
  • End to endテストは書く。それと重複してもなるべくモデルのテストは書く
  • Reactのコンポーネントもある程度はテストを書く
    • End to endテストでカバー出来ているけど、書いたほうが再利用性が上がる
  • ES6, Babel, Browserify, mocha, jsdom, Enzyme, sinon, power-assert
  • 定期実行は全てJenkinsから。cronは使わない
  • 依存ライブラリ(Gem, npm)はJenkinsからPR出して自動でアップデート
  • コードフォーマットはeslint, Rubocopを使ってJenkinsでPR出して自動で修正
  • データ分析はBigQueryとre:dash。データベースとMixpanelからEmbulkを使ってインポートしている
  • Railsのカバレッジは95%以上、JavaScript単体は25%程度

機能開発以外の今後の課題は

  • Herokuへのリクエストの太平洋超えレイテンシをなんとかしたいけど、開発効率が良いのでやめたくない
  • 地図データがきれいに揃っていないので整えたい
  • やがてやってくる通知の再実装問題
  • jbuilder遅い

など。興味ある事や知りたい事があったら可能な限りいくらでも情報開示します。気軽に聞いてください。

クリスマスイブに聞く本格ブラックメタル

METALバンド Advent Calendar 2015の24日目の記事です。担当がクリスマスイブになったのは偶然です。

詳しい説明はしませんが、それぞれその時代と国を代表する正統派ブラックメタルバンドです。恐らく本気でブラックメタルを聞いていた人は誰も文句を言わない、ブラックメタルという音楽の本質を味わえるチョイスだと思います*1。

しかし、ここまで人間のダークサイドにフォーカスした音楽が他にあるでしょうか！？改めて聴いて震えました。カーテンを閉じ、部屋の照明を全て消し、大音量で聞いてください！

1995, France

www.youtube.com

1989, Hungary

www.youtube.com

1993, United States

www.youtube.com

1994, Sweden

www.youtube.com

1994, Norway

www.youtube.com

1986, Sweden

www.youtube.com

1991, Swiss

www.youtube.com

2001, France

www.youtube.com

*1:入れたかったけど量的に割愛したバンドが沢山います。BurzumとかKatharsisとかSarcofagoとか。

Hspecベストプラクティス

Hspecベストプラクティス

Haskell Advent Calendar 2015 の14日目のエントリーです。

イントロ

Hspec はHaskellコミュニティにすっかり受け入れられたテスティングフレームワークと言ってよいかと思います。しかし！まだ確たるベストプラクティスは無いと言えるのではないでしょうか！

Hspecの元となったRSpecはRubyコミュニティでデファクト・スタンダードとなっており、ベストプラクティスの蓄積があります。これを、Haskellの事情を鑑みつつ適用してみようという記事です。

ではないので、その辺りは別の記事を読んでください。

あと、オフィシャルのexampleがあるので、これに先に目を通しておくと話が早いかもしれません。

気になる点、賛同できないプラクティス、改善点などありましたら、是非コメントで教えてください。

では始めます！

一般的なディレクトリ構造に従う

  • 一つのソースファイルに一つのスペック
  • ファイル名はSpec.hsで終える
  • ソースコードのディレクトリ構造に対応させる

が慣用的です。 例えば src/Foo.hsのSpecはtest/FooSpec.hs、src/Data/Bar.hsはtest/Data/BarSpec.hsとなります。

hspec-discoverでテストスイートをまとめる

複数あるテストを一つのテストスイートにまとめるのは結構面倒です。 上記の命名規則(Spec.hsでファイル名が終わる)に従い、各ファイルでspec :: Specをエクスポートしておけば、hspec-discoverが規約に沿ったファイルから自動的にテストスイートを作ってくれます。

下記のようにファイルを作っておけば $ stack testできるはず。

test/Spec.hs:

{-# OPTIONS_GHC -F -pgmF hspec-discover #-}

foo.cabal:

test-suite foo-test
    main-is: Spec.hs

それぞれの関数について、振る舞いの説明をする

describeで説明する関数を宣言し、itでその振る舞いを説明します。

例:

describe "Foo.bar" $
  it "should return multiple of given number" $ do
    Foo.bar 4 `shouldBe` 8

contextを活用する

contextに文脈を書くと整理されたテストスイートになります。

describe "Foo.baz" $
  context "when [] was given" $ do
    it "should return Nothing" $ do
      Foo.baz [] `shouldBe` Nothing

  context "when [1] was given" $ do
    it "should return Just 1" $ do
      Foo.baz [1] `shouldBe` Just 1

一つのテストで一つの振る舞いを確認する

複数の振る舞いを確認すると失敗するテストを見つけるのが難しくなります。

テストが遅くなりすぎる場合は複数の振る舞いを検証するのもアリです。

Good:

describe "Logger.log" $
  it "should write log to log file" $ do
    -- 省略
  it "should write log to stdout" $ do
    -- 省略

Bad:

describe "Logger.log" $
  it "should write log to log file and stdout" $ do
    -- 省略

テストをあまり抽象化しない

BDDはソフトウェアの振る舞いを記述するための手法です。多少冗長でも、記述された振る舞いの読みやすさを優先したほうがよいです。

ちょっといい例が思いつかないので、瑣末な例で。

describe "Foo.baz" $ do
  forM_ ["cat", "dog", "snake"] $ \name -> do
    context "with '" ++ name ++ "'" $ do
      it "should return " ++  name ++ "-chan" $ do
        -- 省略

は

describe "Foo.baz" $ do
  context "with 'cat'" $ do
    it "should return cat-chan" $ do
      -- 省略
  context "with 'dog'" $ do
    it "should return dog-chan" $ do
      -- 省略
  context "with 'snake'" $ do
    it "should return snake-chan" $ do
      -- 省略

としておいた方がよいです。前者の例はコードから振る舞いを読み取れません。BDDのテストコードは抽象化の対象ではなくソフトウェアの振る舞いを記述するものである、ということを心に留めておきましょう。

今年の24 days of HackageでHspecが取り上げられており、コメント欄でYesodやPersistentのメンテナーであるGregさんもテストの抽象化には反対していました。

とはいえ現実世界では、読みやすい抽象化をすればいいのでは？とか、さすがにボイラープレートコードが多すぎる、とか、悩ましい状況は発生します。適度にルールを破る分には良いかと。

マッチャーを知る

shouldBe、shouldReturnなどをマッチャーと言います。これはそんなに数多くないので、一度目を通すとよいです。 ドキュメントはこちら にあります*1。

GHCIでテストする

module FooSpec (main, spec) where

main :: IO ()
main = hspec spec

spec :: Spec
spec = describe "Foo.bar" $ do
  -- 省略

というようにmainとspecをexposeしておくと、

$ stack ghci
λ import qualified FooSpec  
λ FooSpec.main
Foo.bar
  should return something
Foo.baz
  should do something

という具合にGHCiの中でテストを実行できます。$ stack test より GHCiの中でreload! するほうが早いのでオススメ。

便利なライブラリがある

一時ディレクトリ、一時ファイルの利用はMockeryが便利です。またSilentlyを使うと標準入出力をキャプチャできます。

WAIにはhspec-wai、Snapにはhspec-snapがあります。ちなみに僕はhspec-waiの作者の一人です。

まとめというか所感

Hspecいいソフトウェアだと思います。型がリッチな言語とふわっと振る舞いからコードを育てるBDDの相性がめちゃくちゃ良い。doctestと併用して、(Type|Test|Behaviour) Driven Developmentは捗ります。

あと、他にもRSpecのベストプラクティスをパクれるところは沢山あると思うので、RubyわかるHaskeller諸氏は是非参考にしてみてください。ちなみにRSpecを長年メンテしてたDavid ChelimskyさんはClojureの人になってしまいました。悲しいですね！

リンク集

本家

この記事の元ネタ

RSpecについて:

Hspecについて

*1:ちなみに中置記法があるおかげでRSpecのようにshould/expect論争がないです。

Haskellでなぜストリーム処理ライブラリが必要なのか

関数型ストリーム処理勉強会で発表したので、ブログにも書いておきます。

元になった資料はこちら

Haskellでストリームデータを扱う方法としては、Handleを使う方法、Lazy IOがありました。しかし、それぞれに問題があり、再利用性が高く堅牢なコードを書くことは困難でした。

この状況を解決すべく、Conduit、Pipes、io-streamsなどのストリーム処理ライブラリが現れたのですが、そもそもそれらが必要とされた経緯は具体的にはどのようなものだったのでしょうか？

元ネタ: http://okmij.org/ftp/Haskell/Iteratee/talk-FLOPS.pdf

ソースコード: https://github.com/fujimura/functional-stream-processing-meetup-sample

そもそもストリームとは

必要に応じて処理されるデータの連なりのこと。具体的には標準入力、ファイル、ソケットなど。

上記の定義はSchemeの実装提案書より。 この定義では入力側をストリームと読んでいますが、出力側（標準出力への書き込みなど）もストリームとして扱われてる場合が多い気がします。

ストリームは多くの場合、IOです。

具体例

200MBのテキストファイルに含まれる空白文字の数を調べる、という例で比較します。200MBのファイルを一気にメモリ上に読み込むのは効率的とは言えません。ストリーム処理の出番です。

Lazy IOの場合

run :: FilePath -> IO ()
run fname = do
  file <- Text.Lazy.readFile fname
  print (countWhiteSpace file)

countWhiteSpace :: Text -> Int
countWhiteSpace = fromIntegral . Text.Lazy.length . Text.Lazy.filter isSpace
  • 良いところ
    • 単純でわかりやすい
  • 悪いところ
    • 純粋な関数で例外が起こる
      • readFileで読んだファイルに不正なバイト列が含まれていた場合は例外が起こります。そして、Haskellは遅延評価なので、値は必要になった時に評価され、例外は評価時に発生します。つまり、評価されるまで例外は発生しないのです！この性質により、なんと純粋な関数で例外が起こることがあります。これのデバッグは非常に難しいです。
      • 具体的には上記のコードの場合、Text.Lazy.filterで不正なバイト列が評価される時に発生します。
    • いつ、どれだけファイルが開かれ、開放されるか予測しにくい
      • 上記と同じ理由でファイルが開放されるタイミングも単純には予測できません*1。また大量のファイルが同時に開かれてしまう場合もあります。

Handleの場合

run :: FilePath -> IO ()
run fname = do
  handle <- openFile fname ReadMode
  i <- countWhiteSpace handle
  print i

countWhiteSpace :: Handle -> IO Int
countWhiteSpace h = loop 0
  where
    loop i = do
      eof <- hIsEOF h
      if eof
        then return i
        else do
          c <- hGetChar h
          if isSpace c then loop (i+1) else loop i
  • 良い所
    • 素朴で理解しやすい
  • 悪いところ
    • ローレベル
      • 素朴さの裏返しですが、Olegさん言う所の「Haskellで書かれた、典型的なCのコード」*2で、実にローレベルです。関数プログラミングとは何だったのか！
      • ロジックを書いている部分より、Handleの世話をしている部分が多い
        • 実際、ロジックが複雑になると大変なことになります。コード量が増えると、それだけバグの入る可能性も増えます。

io-streamsの場合

run :: FilePath -> IO ()
run fname = do
  i <- Streams.withFileAsInput fname countWhiteSpace
  print i

countWhiteSpace :: InputStream ByteString -> IO Int
countWhiteSpace is = Streams.decodeUtf8 is >>=
                     Streams.map (Text.length . Text.filter isSpace) >>=
                     Streams.fold (+) 0
  • 良い所
    • ハイレベルでコンポーザブル
      • ストリーム自体の扱いはio-streamsが隠蔽しています。
      • ストリームを受け取る関数を、Unixのパイプのように >>=で処理を繋ぎます。繋がれたそれぞれ処理は抜き差しがしやすいので、部品化も簡単です。io-streamsで入力を処理する場合、 InputStream a -> IO (InputStream a) を繋いでいくことになります。
    • 安全な例外
      • それぞれの部品はIO (InputStream -> a)を返すので、bracketで例外を捕捉できます。
    • 少ないメモリ使用量
      • io-streamsが面倒見てくれます。
  • 悪いところ
    • ＼(^o^)／ない

まとめ

既存の解決方法には問題がある。

  • Lazy IO: 純粋な関数で例外が起こる、リソース管理が難しい

  • Handle: 関数プログラミングっぽくないローレベルなコードになる

ストリーム処理ライブラリで、それら問題を解決できる。

  • io-streams: サプライズの少ない例外*3、ハイレベルでコンポーザブル
    • ただ、リソース管理は自分でやらないといけない。

ということで、ストリーム処理ライブラリを活用すると、効率がよく、見通しがよく、サプライズが少ないプログラムが書けるようになります。

参考資料＆リンク集

*1:seqやBangPatternsを使ってサンクを潰して回る羽目になります

*2:http://okmij.org/ftp/Haskell/Iteratee/talk-FLOPS.pdfの7ページ参照

*3:実はこれHandleでもwithFileを使えば実現できます。