■PARTAKE（告知サイト）
http://partake.in/events/9a5f18bf-ca0c-48cd-a050-8a564c1ab0d9
■発表資料まとめ
https://sites.google.com/site/fpmjp2012/home
■togetter
その１： http://togetter.com/li/366053
その２： http://togetter.com/li/366046
ちなみに私、関数プログラミングは、大学3年生（もう10年位前ですが。。。）の講義で受講した ML と OCaml 、あと去年から参加している「スタートHaskell」という勉強会で出会った Haskell ぐらいしか経験ありません。
ただ、やっぱ関数プログラミングに触れてみた感覚は強烈で、現在学んでいるHaskellにも刺激されっぱなしです。なので、初心者ながら今日のイベントに参加してみることにした次第なのです。
会場はお茶の水女子大学の理学部３号館です。
かなりの大規模イベントで、参加者は200人くらいでしょうか。
しかも参加者はほぼ男性なんですが、会場は女子大という。。。
あと、名古屋でも関数型プログラミングの勉強会がいくつか開催されているのですが、それに関係ある出席者もかなりいらっしゃったようです。主催者さんや発表者さんの半分くらい？も名古屋出身かな。
実は、私も大学と大学院は名古屋なので、親近感がありますねー。
以下、各発表のメモと感想です。発表スライドに無い内容も含め、自分への覚書です。
関数型言語初心者と仕事でF#使ってみた(仮) @bleisさん
■F#なら、.NET Framework 2.0でも開発できる。（3.5や4.0でなくてもOK）
■とある開発でF#を使ってみた。
① 今までやっていた作業を自動化するWebアプリ
② 納期が厳しい
③ .NET Framework 2.0の環境
→ 開発メンバの一人は、F#の経験なし。
→ 「実践F#」という書籍を読んでもらった。（↓かな？）
 | 実践 F# 関数型プログラミング入門 (2011/01/07) 荒井 省三: いげ太 商品詳細を見る |
→ ペアプログラミングで教え、レビュー時間が取れないときは「直しといたから見といて」とコード渡した。
■教えたこと
① 自分でループを書かない方法
② リストの先頭や最後にデータを追加すべきではないのはなぜか
③ nullとNoneの違い
→ 結果、範囲外アクセスや、ぬるぽバグはほとんど出なかった。
→ 関数型初心者がいても、サポートできればなんとかなる。
■F#初心者さんの感想
① 制限が厳しくて、慣れるのが大変
② バグがあんまり出なかった
③ C#とF#だったら、（今の時点では）C#の方が気が楽。
■ある案件では、C#で8000行のものがF#で1600行で済んだ。
■F#は.NET Frameworkが使えるところが良い。Haskellとかだと実際の現場で使うのは厳しいかも。
■F#で性能問題になったことが無い。Visual Studioには性能を調べるツールがある。
■少しでも関数型言語にシフトできるように、手続き型言語のプログラマをもっていきたい。
関数型プログラミングの今昔(仮) @ksknacさん
120901fp key from ksknac
■関数の数学的定義
AからBへの関数は、以下の性質を満たすA×Bの部分集合Fである。
すべての a∈Aに対し、(a, b)∈Fなるb∈Bが１つだけ存在する
→ プログラムでいう関数とは異なる。
■関数か否かは集合次第
・入力の集合を絞れば、入力に対し出力が１つにすることも可能。
■そもそも、「関数型言語」の定義自体が難しい。
（どの言語でも通じる言葉で説明できない）
■では、「関数型」とは？
・プログラミングスタイルへの形容
・言語に関係なく実現可能
■「関数型言語」という単語を、関数型プログラミングがしやすいという意味以外で使ってはいけない
■実は、Red Bullという飲料は、Functional！！ だって、公式Webに書いてあるし。
（エンジニアさんがRed Bull飲んでる姿よく見かけますが、そーだったのですね。。。）
■関数化による効果
・プログラみの見通しの改善
・プログラムの分割・結合が容易
■独自の関数型言語が乱立 → 多くの言語を統一するため、Haskellが開発される
■まとめ
・数学的な意味で関数か否かが重要
・関数型とは、言語でなく記述に対する形容詞
継続開発のススメ Erlang/OTP 編 @voluntasさん
■資料：https://gist.github.com/9ee65f0dfa9b7dd78fde
■仕事でErlangを使っている。
（すみません、ちなみにErlangの読み方、今日初めて知りました。。。アーラン、って発音するみたい）
■エディタ（Emacs or Vim）
エディタはEmacsを使うべき。Erlang/OTP ではソースコードに erlang.el が同梱されている。
■コーディング規約
コーディング基本的には erlang.el に倣う。ただ個性の話になるので、そのたび開発者間で意見をぶつけ合う。
（じゃんけん、という話も。。。）
■開発環境
Macで開発するメリットがほとんど無い。のでLinuxにすべし。
■ビルド
Erlang の開発環境は rebar というビルドツールが出てきたことで激変した。（今まではMakefile）
■バージョニング
ソースコードのバージョンの付け方が大事。バージョニングというのは一番「決めておくべき」事。
・参考：Semantic Versioning 2.0.0-rc.1 日本語版
http://samidarehetima.blog9.fc2.com/blog-entry-182.html
■単体テスト
単体テストはコード書き換えたときの保険で、テストとすら見なされていない。ある意味、自己満足の範囲。
仕様がわかってないとそもそも意味ないので。仕様ミスってたらおわり。
■受け入れテスト
単体テストよりも受入テストを重視し、ブラックボックステストを実施する。
■キャパシティテスト
リリースするソフトウェアは、必ずキャパシティテストする。
■定期アップデート
Erlang VM や依存しているライブラリは、１ヶ月に１回、定期アップデートしてる。やらないと破綻が始まる。
古いままで使い続けて幸せなことはない。後でまとめてアップデートしようとするとコストもかかる。
■ドキュメント環境
・ドキュメントがないと運用に響く。顧客からは確実にドキュメントを求められる。Wordは辛い。。。
・ドキュメントはバージョン管理されてナンボ。
→ Sphinxつかってる。
・見栄えがよいドキュメントが重要。フォントも商用のものを検討。
■自動化
Jenkinsを使って自動化してる。ボタン一発ですべての品質が保証される、ということが重要。
■継続開発
・継続開発は負債になってる。
・継続的デリバリーは、継続的に固定費が発生 → 仕事がとりにくくなる。
・成功すれば成功するほど負債が増える。
・やりすぎはよくないが、やりすぎないと継続開発はできない。
・大事なのは政治力。継続開発するための予算とること。
■レビュー
・仕様を理解してレビューする専任の人がいる。
・レビューとは、「メンテナンスができるようになっているかを確認すること」である。
・知らない状態が生まれるのは許されない。
■CM1
「Learn You Some Erlang for Great Good!」という、「すごいHaskellたのしく学ぼう!」("Learn You a Haskell for Great Good!")のElrang版が出版予定。
---
★感想：
いやー、非常に実践的な発表でした。Erlangを知らない人にも、かなり役立つ内容です。
私も最近は会社でアジャイル開発とかやり始めて、継続開発とか自動化とか意識することが多くなったので、
一つ一つの話が非常に腑に落ちました。是非参考にさせていただきたいです。
「すごいHaskell」を支える技術 @tanakhさん
↑クリックすると発表資料に飛びます↑
■「すごいHaskellたのしく学ぼう!」("Learn You a Haskell for Great Good!")の翻訳をした。
（私が参加してる読書会「スタートHaskell2」のテキストでもあり、良書です）
 | すごいHaskellたのしく学ぼう! (2012/05/23) Miran Lipovača 商品詳細を見る |
■Haskellで詰まったところ（当社調べ）
・1位： モナド 85%くらい
・2位： Cabal 10%くらい
・3位； 特になし 5%くらい
（半分はジョークかと思いますが。。。大体こんなイメージ）
■モナドの謎を解き明かす、のは永遠のテーマ
（ちなみに、ゼノブレイドというゲームにモナドが出てくるらしい。。。）
■「すごいHaskellたのしく学ぼう!」("Learn You a Haskell for Great Good!")は、モナドを理解するためにある、といっても過言ではない。（らしい。。。）
■Typeclassopedia
・日本語訳: http://snak.tdiary.net/20091020.html
・Haskellの型クラスを解説した記事
・Functor -> Applicative Functor -> Monad の階層に従って書かれたもので、わかりやすいと評判。
■モナドを理解するポイント
「Applicative Functor」 and 「Typeclassopedia」
---
★感想：
「スタートHaskell2」でもFunctorやIOが登場する章に突入し始めたので、モナドの謎を解き明かせるか、期待！
HaskellでWebアプリ ～Yesodを使って面白かったこと～ @seizansさん
■Haskellを学べば上手にプログラミングできるようになる、と教えられHaskellを始める。
■Yesodとは
・HaskellによるWebアプリケーションフレームワーク
・Haskellのメリットを活かせるように作られている
■Yesodを使うことの利点
・型システムの恩恵が受けられる
・セキュリティが充実。（SQLインジェクションとかクロスサイトスクリプティングとか防ぐ）
・その他、いろいろあるが、発表資料参照。
■YesodによるWebアプリ開発の詳細
・詳細は↑の資料参照。ハンドラとかも出てくるし、聞く限りどうやらMVCモデルのようです。
---
★感想：
@seizansさん、今日もあいかわらずイケメンでした。
ちなみに私が参加してる「スタートHaskell2」と「TaPL読書会」の主催者さんです。
私はWebアプリケーションフレームワークとしてStrutsを長いこと使ってますが、その経験があれば
比較的楽にYesodの仕組みに馴染めそうな印象でした。
ただ、やっぱHaskellでスラスラとコードが書けないので、そこがネックになりそう。。。
あと、問題はやっぱり保守でしょうね。
アプリケーションは長い間保守しなければならないわけで、現実問題として、Haskellに習熟している
エンジニアはごく一握りなわけで。。。
開発時にHaskellエンジニアを確保できたとしても、保守フェーズに入ると。。。難しい問題です。
F#を学んで感じた関数プログラミング習熟度レベル
+ FSharpxのIteratee @pocketberserkerさん
■関数プログラミングにも習熟度レベルがある？
・再帰が書けるレベル
・再帰を使わずに高階関数を使って書けるレベル
・モナドを使えるレベル
・モナドを自作できるレベル
・etc
■力関係
・再帰 ＞ fold系 ＞ 目的に特化した高階関数
・力の弱いものを使ったほうがコードがわかりやすいので、そっちから使っていくべし
■高階関数
・高階関数に慣れるには訓練あるのみ。
・上達しないのは、手を動かすのが足りないから。
・リファクタリングするにはテストコードが必須。
■モナド
・モナドは、使って慣れるところからはじめる。
・慣れてきたらモナド自作。（まだ見ぬ高み）
■習熟度レベルのまとめ
・FPには習熟度レベルがあるっぽい。
・次に挑戦する段差が何か知ることができれば学びやすいのかも。
・一歩一歩進めばそのうち上達する。
■発表後半：FSharpxのIteratee
・自分の知識が足りず、ついていけなかった部分が大半でした。。。F#のコード読めないし。
・詳細は↑の発表資料参照。
---
★感想：
高階関数や再帰の力関係については、先日の「スタートHaskell」でもちょうどネタになったところでした。
あと、「次に挑戦する段差が何か知ること」というのは、確かに大事ですね。
F#、いつかちゃんと勉強したいな。。。
テストにおける静的型付け函数型 @kyon_mmさん
↑クリックすると発表資料に飛びます↑
■@kyon_mmさんの、ソフトウェアテストの定義：
→ 誰が確認しても一意に定まるもの
■ソフトウェアテストの分類
・テストレベル
・テストタイプ
・テスト観点
・テスト手法
（詳細は発表資料参照）
■まとめ
・静的型付け関数型プログラミングによってテストコードは減らせる
・現状で減らせるのはコンポーネントテストレベル
・結合テストやシステムテストの工数を如何に減らせるかが、ソフトウェア開発でその言語が
使われるようになるための鍵ではないか。
---
★感想：
・発表者さん： 「この中で、テストエンジニアっていらっしゃいますか？」
・会場の皆様： 「（シーン・・・）」
・発表者さん： 「そうですよね～。。。分かってたさ！」
あと、うさみみバンドを付けてプレゼンを行う発表者さん、初めて見たよ。。。
「書いたコードがコンパイルタイムに（IDEなら書いているそばから）エラーを強力に検知する。」という文言がありましが、これ、私もEclipse使ってますがかなりの恩恵ですよね。
テキストエディタとIDEでは、「コーディングのしやすさ」ももちろんですが、「リアルタイムテスト」という観点も見逃せないと再認識しました。
イベントドリブンプログラムの関数型的書き方 @osiireさん
↑クリックすると発表資料に飛びます↑
■イベントドリブンプログラミングは、多くの状態や複雑な条件分岐が登場する、やっかいな状態遷移プログラミング
■代数的データ型とパターンマッチをうまく使うと、管理すべき状態が減り、網羅性もチェックできる。
■第一級のイベントとコンビネーターを使うと、生のイベントを意味イベントに翻訳することができる。
意味イベントと「やりたい処理」を結びつければ、イベントドリブンプログラムはわかりやすくなる。
---
★感想：
自分のキャパ不足もあり、状態遷移の変換について、聴講中に理解しきれない部分がありました。。。
思いつくまま状態遷移をコーディングするより工夫することで改善できることがある、との発表ですが、思いつくままコーディングしちゃった時点で満足して思考を停止しちゃいそうな自分がいて、反省。。。
予定通り、17時半くらいに全セッションが終了しました。
午後は7Fの応用セッションと、2Fのトピックセッションの２会場に分かれましたが、私はずっと7Fでした。
なので、2Fの発表は聞けなかったのがちょと残念です。
しかし、「関数型プログラミング」という同じ方向性を持った人が全国から集まるイベントということで、とても熱気がありました。
なによりも、発表者や聴講者の目が輝いていた、というか、「関数型プログラミング」という夢中になれるものを持っているエンジニアや研究者をたくさん見て、羨ましく感じました。
自分はまだとてもその域に達していないので、勉強あるのみです。
有意義なお時間を提供してくださった運営者様、発表者様、会場提供者様、ありがとうございました。
