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
- 良いところ
- 単純でわかりやすい
- 悪いところ
- 純粋な関数で例外が起こる
- いつ、どれだけファイルが開かれ、開放されるか予測しにくい
- 上記と同じ理由でファイルが開放されるタイミングも単純には予測できません*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
- 良い所
- 素朴で理解しやすい
- 悪いところ
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
- 良い所
- 悪いところ
- \(^o^)/ない
まとめ
既存の解決方法には問題がある。
Lazy IO: 純粋な関数で例外が起こる、リソース管理が難しい
Handle: 関数プログラミングっぽくないローレベルなコードになる
ストリーム処理ライブラリで、それら問題を解決できる。
ということで、ストリーム処理ライブラリを活用すると、効率がよく、見通しがよく、サプライズが少ないプログラムが書けるようになります。
参考資料&リンク集
- io-streams
- Conduit
- Pipes
- サンプルコード
- ストリーム処理ライブラリブームの端緒となったIteratee論文
- Iterateeについての発表資料。わかりやすい
- Iterateeの紹介
- io-streamsリリースのお知らせ&紹介。Conduit, Pipesとの比較もある
- Conduit, Pipes, io-streamsの比較 by Conduitの作者Simonさん
- Lazy IOの罠
- Conduit概要
*1:seqやBangPatternsを使ってサンクを潰して回る羽目になります
*2:http://okmij.org/ftp/Haskell/Iteratee/talk-FLOPS.pdfの7ページ参照
*3:実はこれHandleでもwithFileを使えば実現できます。
これからエンジニアがやったらよさそうな仕事
技術顧問ブームですね。先日退職してから色々な会社を回ってて、これニーズあるんじゃね?って仕事を何個か思いついたので、列挙してみます。
チーム開発を軸にした技術顧問
やること: 開発プロセスの構築・実行・改善、ミーティングのファシリテートを行い、チーム開発を良い感じにする。
必要そうなスキル: チームを作った経験。ソフトウェア開発プロセスの知識と実務経験。それなりの技術力。
GitHubでコードレビューしてCI/CDを回して、っていうスタートアップでよくあるエンジニアリングの型はある程度できているけど、うまく運用できていないところは少なくないと予想している。わかってる人が手伝ったら軌道に乗るまでが早そう。事業や組織の性質・フェーズに合わせる必要もあるし結構難しい。チームで仕事をするというカルチャーを伝えるのも価値がありそう。人間力が問われますな…。
個別技術を軸にした技術顧問
やること: 技術選定、アーキテクチャやコードのレビュー。
必要そうなスキル: 当該技術への深い知識と経験。
どのテクノロジーも正しく効果的に使うのは簡単ではない。深い知識は価値が高いはず。
採用支援
やること: エンジニアをうまく採用できていない会社の採用活動を支援する。待遇をエンジニアに訴求するものに再構築し、エンジニアに訴求する求人活動を行う。採用基準の策定。面接、スクリーニング。エンジニア組織の構築・改善。
必要そうなスキル: エンジニアの採用経験。マネジメント経験。幅広い技術とそのシーンの把握。人脈。
困っているファウンダーは多いと思います。カンファレンスやコミュニティの運営をしていて、自社で採用していない人とか良いのでは*1。組織がいけてない場合はそこの改善、場合によってはゼロから構築とかも必要かもなあ。
ベンチャーキャピタリスト
やること: 技術面のデューデリジェンスと、開発体制の構築、技術支援、リクルーティングなどのハンズオン。
必要そうなスキル: VC実務能力に加えて、ハンズオンで説得力を持たせられるだけの技術力とマネジメント経験。エンジニア・コミュニティでの人脈。
金融の友達に、会社やめたのでいろんなスタートアップ回ってるって話をしたら、藤村さんVCやったら?って言われた。その発想は全く無かった。そもそものベンチャーキャピタリストとしての素養が必要なのは言うまでもない。技術面のハンズオンは価値あると思われる。エンジニア業界とVC業界はコミュニティが離れてるので、そこを繋げられるのは悪くないかも。アメリカだと普通にいるっぽい。そもそもYコンビネーターのポール・グレアムはLISPハッカー。
まとめ
ベンチャーキャピタリスト以外は副業でもできそう。こういうハイエンドな仕事を良い感じに流動化したらシニアエンジニア各位の将来も幸せなのではないか。流動化したハイエンドな労働力を良い感じに流通させるしくみが必要なのかも。
こういう仕事もニーズありそうだよ?とか、追加あったら是非教えてください!
*1:人材紹介業は免許がいるので、紹介で直接対価をもらうのは出来ないと思われる。
無職日記 (1)
Quipperを退職しました & 求職中です - fujimuradaisuke's blog から一週間弱経ちました。
ありがたい事に沢山のお声掛けを頂きました*1。大変申し訳ないのですが、全てのご連絡にお返事できていない状況です…すいません!気がつけば今月のランチ・夕食の予定がほぼ埋まってしまいました。
で、7/24-7/28まで福岡に行きます。Rails Girls Fukuokaでコーチ。その後7/30から20日ほどタイ中心にアジアのどこかに行く予定です。シンガポールは確定、あとはスリランカかな。
今は部屋でこれを聞いてます。60分間、ひたすらミニマルに変化し続ける音楽。スーフィーの音楽を思い出しました。ジャケがかっこいい。 www.youtube.com
wishlistからTシャツと本を送って頂きました!ありがとうございます。記念に着て自撮りを行いました。次の仕事の初出勤はこのTシャツで臨もうと思います。
*1:退職エントリ公開初日で60件くらい
Quipperを退職しました & 求職中です
一言でいうと: Quipperを退職しました。Quipperの皆さん、本当にどうもありがとうございました!現在求職中です。ご興味あれば me@fujimuradaisuke.com か https://facebook.com/dfujimura までご連絡ください。Ruby、JavaScript、チーム開発のリード、などができます。wishlistはこちら
2015年6月末日をもって、Quipperを退職しました。
立ち上げ当初のMercariを体を壊して*1辞めて*2入院して手術受けて退院、さて今後どうしようと悩んでいるところで、ひとまずフリーランスで働こうとQuipperで働き始めました。2013年6月でした。
当初からフリーランスはあくまでモラトリアム期間という位置づけで、いずれは正式に会社に入るつもりでした。働いてみるとQuipperは想像以上によいところで、9月には正社員になっていました。教育という事業領域、グローバルな体制という点もさることながら、何よりメンバーが素晴らしかったのが決め手です。
Quipper在籍中にやったことを、立場で切って大きく分けるとこの二つでしょうか。
- ベネッセさんとの大規模実証実験で開発チームリーダー
- プロジェクトの仕組み作りとか、協業体制作りとか、開発チームの運営とか。
- 東京開発チームのリーダー
- 採用とかメンバーの配置とか面談とか。あと、オフィスが3つある(London/Manila/Tokyo)ので、その分担の相談とか。どちらかというと裏方。
一番の実績としては、ベネッセさんとのプロジェクトが無事完遂し高い評価を得たことになるのかな。もちろん全く事故ってないとは言えませんし*3、今思い出しても心がムズムズする反省点もあります。そもそも僕個人の実績ではなく、チームの実績だし。とはいえ、開発チームのリーダーとして在籍していたプロジェクトが「成功です!」と関係者に評価されていることは、客観的に見て実績と考えてもよいだろう、と判断することにしています。
あとQuipper Schoolのリリース体制を整備したりしてました。もちろんコードも普通に書いていました。
ちなみに退職の理由はよくあるタイミング的な問題です*4。Quipperは先日リクルートに買収されましたが、これは関係ないです。個人的にはリクルートと仕事するのはとても楽しみだったし、素晴らしいチームになれると思っていたので、残念です。
次の仕事は決まっていません。のんびり勉強しつつ*5、Quipper在籍中に蓄積した思考を解きほぐして、じっくり次の仕事を決めるつもりです。やることとしては、今までしてきた仕事を考えると、技術と組織の掛け算で事業に貢献するって感じになるかな思います*6。けど、よい目的と信頼できるメンバーがいれば、関わり方はなんでもいいかなーと*7。
ということで、エンジニアもしくはそれに類する職種の人間をお探しの方、ご興味あれば me@fujimuradaisuke.com か https://facebook.com/dfujimura までお気軽にご連絡ください。下に略歴をまとめておきました。お昼も都合がつきますので、ランチのお誘いお待ちしています。
Quipperは素晴らしい会社です。崇高なゴール、興味深い事業領域、安定した高い技術力、先進国・新興国含めたグローバルな体制、なにより最高のメンバー。なかなか離れがたいです。が!僕は僕の道で高みを目指して頑張っていこうと思います。
辞めた人間が宣伝するのも妙ですが、Quipperは各ポジションで絶賛採用中なので、興味を持たれた方は是非連絡してみてください。
- Quipperで新しい学びの形を創造したいWebエンジニア募集 - Quipper Ltdの求人 - Wantedly
- Quipperで新しい学びの形を創造したいiOSエンジニア募集 - Quipper Ltdの求人 - Wantedly
- Quipperで新しい学びの形を創造したいAndroidエンジニア募集 - Quipper Ltdの求人 - Wantedly
- Quipperで新しい学びの形を創造したいUIデザイナー募集 - Quipper Ltdの求人 - Wantedly
最後に、渡辺さん、中野さんをはじめQuipperの皆さん、社外のお世話になった皆さん、本当にどうもありがとうございました!今後のQuipperと皆さんの発展を心より願っております。何か今の立場で協力できることがあれば、遠慮なくご連絡ください*8。
ということで、皆様今後ともどうぞよろしくお願いします。
略歴
早稲田大学第一文学部哲学専修を卒業。大手ERPパッケージソフトの導入エンジニア(2次請け)としてソフトウェア開発を始める。Rubyがやりたくなり、とあるITベンチャーに7人目の社員として入社、Ruby on Railsを使うようになる。一年後業績不振のためレイオフされ(およそ半年後会社もなくなった)、groovesに入社。Rubyをメイン言語とする開発チームを中心人物として立ち上げる。その後Aimingに入社、認証サーバー、分析基盤などのチームを経て、Unityで作られたゲームをHTML5へ移植するプロジェクトに開発チームリーダーとして参画、なんとかリリースにこぎつける。その後フリーランス、Mercariなどを経てQuipperに参加。東京開発チームのリーダーとしてベネッセとの共同プロジェクトを成功に導くなどする。
プログラマーとしてはRubyを最も得意とする。JavaScriptを用いたシングルページ・アプリケーションの開発実績も多数ある。チーム開発をリードする経験も複数ある。プライベートでは主にHaskellを書いており、オープンソース・プロダクトへの貢献がいくつかある。
PS: wishlistを作ってみたので、貼っておきます。僭越ながらよろしくおねがいします。どちらかというとご笑覧向けのおもしろリストになっております。 http://www.amazon.co.jp/gp/registry/wishlist/3Q71MJUSPEEX8/
*1:扁桃炎が扁桃周囲膿瘍になり慢性化しました。最終的に2週間周期くらいで再発しててまじ辛かった。排膿のため口に注射針を入れて喉から膿を抜くんですが、それが痛いし怖い。あと一回再発することに5回点滴に通わないといけなくて超めんどくさかった。挙句の果てにMRSAが出たりした。扁桃腺が怪しい方はどうぞ切除をご検討ください!当たり前ですが、治ります。再発もしません。切除手術を受ける基準としては年4回発症だそうです。ちなみに今は完治して健康です。
*2:とんでもないタイミングで抜けたので、本当に申し訳なく思ってます…。
*3:ソフトウェア開発プロジェクトは大体そうだと思いますが。
*4:知りたい方は個人的に聞いてください。
*5:戸次大介『数理論理学』 を読む予定。論理学の知識が中途半端なので脱半可通したい。これ以外にも不足している/ずっと興味がある領域の知識を補おうと思ってます。『離散数学―コンピュータサイエンスの基礎数学』と『ふつうのLinuxプログラミング』をちゃんとやり、『プログラミング言語の基礎概念』は勉強会も開催されてるので読もうかなと。
*6:技術に振るかマネジメントに行くか?って話しについては、過去の経験から見るに、どこに行ってもマネジメント的な仕事をは避けようがない雰囲気なので、両立主義者として生きていくことにしました。そもそもマネジメントというか組織のことは興味もあるし、嫌いではないです。
*7:どんな事業がいいの?って問いについては、僕はヴィジョナリータイプではないので、熱量と千里眼のある(法)人と出会いたいです!業界的には、学生時代からインフラストラクチャーを支えたいという気持ちはあります。エネルギーとか交通とか。スタートアップ向けエンジニアという今の自分のスキルセットが直球で活かせる業界ではなさそうなんですが。投球スタイルを変えるのも面白そうではある。
『12大事件でよむ現代金融入門』 と『コンテナ物語 』を読んだ
出張中&帰りの飛行機で読んだので軽く感想文を。
倉都 康行『12大事件でよむ現代金融入門 』
1970年以降の国際金融システム史。12の事件が時系列に解説される。金融を中心とした国際経済のしくみがわかる。著者はその現場にいた人。それでか、平易な文体の中にも生々しさがある。この手の本でありがちな「新自由主義が悪い」って論調にではなく、あくまで中立的に書かれているように思える。きっと著者が現場で金融というシステミック・リスクと戦っていたからだと思う。そういう語り口もあってか、好きになれる本だった*1。歴史の本としても教科書としても読める。良書でした。ちょっと消化不良なので再読すると思う。
マルク レビンソン『コンテナ物語 』
箱に荷物を詰めて送るようにしたら物流コストがめっちゃ下がった。けど導入は組合が反対したり標準化でもめたりして大変だった。箱の発明もだけど、それをがんばって導入したマルコム・マクリーンは偉い!って本。色々な人が褒めているだけあって、ものすごい面白い。
この本は幾つかのトピックから読める。
一つめは「起業家としてのマルコム・マクリーン」。ちょっと儲かるとすぐ借金したり資金調達したりして新しいことをやる。お金の突っ込み方がダイナミックで面白い。こうやって会社運営ってするんだあ…という。
二つ目「実録・機械に仕事を奪われた」。かつて沖仲士が手動で船から荷物を下ろして仕分けしてトラックに詰めていた。この仕事はコンテナを導入するとかなり無くなってしまう。なので沖仲士の組合はめっちゃ反対する。けど時代の変化には勝てない。という話。
最後「コンテナリゼーションがいかにして海運を効率化したか」。要はバッチサイズを一定にして作業を標準化するとスループットが上がる、という。トヨタ生産方式を思い出した。20世紀後半の生産性改善の定石なんだろうか。ソフトウェア開発プロジェクトにも活かせそう。
あと、ブルックリンのレコード屋で買ったこれが最高だった。ニューヨークのラテン・ソウル。ほんと良い。
Joe Bataan - I Wish You Love, Part 1 & 2 - YouTube
*1:その点、最近の水野和夫は辛い。『人々はなぜグローバル経済の本質を見誤るのか』は名作だったと思うんだけど、それ以降はこの本でデータから導いた結論に本人が乗っ取られちゃってる感じ
宮崎市定『アジア史論』が超面白かった
戦後日本を代表する東洋史学者が、西はシリアから東は日本まで含めたアジアを中心に世界史を論じる。文明間の交通を軸に話を進めるのでとにかくダイナミック。
シリアが古代より世界のハブだった、とか、プロテスタントの改革は既にイスラム教が成し遂げていたスキームの横展開だったとか、中世は近代のための準備期間だった、とか。中世に成功しすぎたイスラム世界は、その成功が故に没落も悲惨だった、とか。今のイスラム世界の辛い感じを見てどう思うんだろうな。
僕はウォーラーステインをちゃんと読んでないんだけど、その影響を受けたと思しき人の本を読む感じだと、とても似ているように思う。ということでニーアル・ファーガソン、水野和夫あたりが好きな人はハマるはず。
以下、面白い所を抜書き
p.8
また文化の影響ということが、いつも清水の中にインキを垂らしてこれを染めるようにばかり行われるとは限らない。人類は叡智を持った生物なので一を聞いて十を知り、単にヒントを与えられただけで奥義を悟ることがあり得る。
p.37
所詮、イスラム教とキリスト教との間には近世と中世との相違が横たわっていた。ルーテルの宗教改革こそは、中性的キリスト教をして近世的水準にまで向上させようとする運動に外ならなかった。そしてその説くところはと見れば、進行の根拠を根本経典たる『聖書』に求めようとし、聖徒の軌跡を含む一切の迷信を排斥し、僧侶は単に宗教的知識の宣布者たるべくして進行の媒介者であってはならず、また彼らの結婚生活を承認すべし等と説く。それらの事柄は、いずれもそのの規範を当時のイスラム教に見出すことが出来る。
p.74
『論語』や『孟子』はその主人公の伝記の一部分として歴史的に読むべきものであろう。(中略)現今の時勢にも間に合う所だけ読んで利用しようというのでは意味をなさぬ。それでは鏡に向かって、自分の姿のある角度だけを移すのと変わらない。
p.293
一個の閉ざされたる社会における平和の維持し難きは、一個人の閉ざされたる平和の維持し難きと同断である。これは倫理でもなく、道徳でもなく、ただ歴史が教うる現実なのである。
p.318
一般的に言って好条件は複雑な条件の結合の中から生れる。何とと言っても、手持ちの駒が豊富なでなければ完璧な布陣はできないものだ。そして豊富な持駒は、狭い局地で取り揃えることはできにくい。一番いいのは公益だ。交易ほど経済的で効果的なものはない。
ニューヨークにいる / Visiting New York City
仕事でニューヨークに滞在しています。3/13まで。 ブルックリン、ウィリアムズバーグの北にある、グリーンポイントという街でシェアハウスを借りた。元々ポーランド人街なので、ポーランド系のスーパーとかレストランがある。あと、TØRSTという素晴らしいビアバーがある。
予定としては
Darkside NYCのライブ
1349のライブ
SteffiとDVS1の出るパーティー
Rust-NYC
New York Haskell Users Group
あたりに行きます。
I'm now visiting New York. It's a business trip. Will back to Tokyo Mar 13.
My house for this visit is at Greenpoint, Brooklyn. This is a Polish town. I should have a try some Polish food. Also I found outstanding brew pub called TØRST.
My plans:
Show: Darkside NYC
Show: 1349
Party: Steffi and DVS1
Meetup: Rust-NYC
Meetup: New York Haskell Users Group