基礎からはじめる Haskell Programming #2 を開催しました #umekitahs

umekitahs.connpass.com

今回は Haskell Programming の「Chapter 2 Hello, Haskell!」を読みました。

まあ、「Hello」レベルですから平易な内容でした。ずいぶん丁寧に書かれていると思いました。

しかし、英語かつページ数が多いということもあって、Chapter 2 全部を1日で読み切るのはわりと大変ではありました。

また、normal form とか irreducible form とかいった言葉がしれっと出てくるので、人によっては驚くこともあるのかも、などと思いました。日本語にすると「正規形」とか「既約形式」とかいった感じのお堅い言葉になってしまう用語です。Chapter 1 がラムダの話から始まったことを思えば自然ではありますが。

次回は「Chapter 3 Strings」を読みます。まだまだ難しくないはず。

umekitahs.connpass.com

関西モバイルアプリ研究会 #16 に参加しました #関モバ

kanmoba.connpass.com

発表資料

speakerdeck.com

所感

水曜日に恒例の関モバに参加しました。

プログラミング寄りの話をするかデザイン寄りの話をするか迷いましたが、後者の話をしてみました。普段の仕事は、管理職でもプロジェクトリーダーでもないエンジニアです。業務時間の8割は、コード書いてたりデバッグしてたり何かしらプログラミングの仕事をしています。残りの2割が、勉強会とか(雑多な事務とか)。今日の話は、その2割の範囲の社内勉強会に関する話でした。

結果的に、他の人はプログラミングな話が多かったので、違う話が混ざったのは良かったと思っています。

UIStackView は本格的に使いたいところですね。iOS 8 のサポートはもう終了ですよね〜。まあどうしてもって言われたらバックポート系のライブラリを使うのは手かもしれません。機会があればちゃんと検討してみよう。

Xcode 8、Swift 3、iOS 10(それに macOS 10.12)は、実はいまちょっと追いきれていないので、話を聞けてありがたいです。頑張って追いつこう。

それにしてもポケモンGOのプレイ率は高かったですね。まあ僕も通勤の合間にちょこっとやってますが。

備考

今回の発表は、来月の iOSDC に応募していたネタのひとつ(エンジニアとデザイナーとがうまく連携して良いアプリを生み出すために | iOSDC Japan 2016)を元にゆるい感じの LT にしました。 iOSDC に当選したらそこではちゃんとまとめた発表をする予定でしたが残念ながら落選しました(30分枠のみの応募はちょっと無謀だったか)。

iOSDC では、もうひとつ応募していた以下の話をする予定です。

iosdc.jp

基礎からはじめる Haskell Programming #1 を開催しました #umekitahs

umekitahs.connpass.com

水曜日に Haskell の勉強会を行いました。今回から Haskell Programming を読み始めました。

それほど安いとは言えない本ですし、英語ですし、ページ数も多いです。大変そうに感じられるかもしれません。しかし、実際に読んでみると、そんなに難しい英語ではありません。また、1ページの分量がそれほど多くないので、気づくと何ページも進んでいる感じでした。

内容ですが、Chapter 1 のタイトルは「All You Need is Lambda」。最初はラムダ計算の話から始まります。

おいおい Haskell の話じゃないんかい。この章は飛ばすべきか、という考えが頭に浮かびます。そんな考えは筆者に見抜かれていました。ちゃんと最初の方に書いてあります。「あなたは、Haskell はどこへ行ったのだと思うかもしれない。この章を飛ばそうと考えるかもしれない。しかし、飛ばしてはならない。」

まあ実際、ラムダ計算は大事なんですね。Haskell は純粋関数型言語であり、Haskell のやることはラムダ計算なんだ、という話。そう思うと、Haskell はある意味シンプルな言語なのかもしれません。

章末の練習問題で、紙とペンを使って手を動かしてラムダ式の簡約の計算をしていると、学生時代を思い出しました(ちなみに大学では数学専攻でした)。この本、楽しいかも。

そういえば、僕は Haskell と数学とが未だにうまく結びついていなくて、Haskell が数学っぽいと言われても「ええ、そうかなあ?」とスッキリしない気分がありました。この本を読みながら、その辺のモヤモヤ感を多少なりとも解消できたらいいなあ、と思います。

次回は、「Chapter 2 Hello, Haskell!」を読みます。おお、ようやく Hello するのね。

umekitahs.connpass.com

「基礎からはじめる Haskell Programming」を開催します #umekitahs

umekitahs.connpass.com

umekita.hs でこれまで読んでいた並列並行プログラミングの本は、正直言ってちょっと内容が難しすぎたので、初心に帰って Haskell の入門的な本を読みながら勉強していきたいと思います。

Haskell Programming という本を読んでいきます。新しめの本であり、読みやすそうで良いと思います。英語なのが多少ネックではありますが、分かりにくい箇所があれば日本語の本(例えば、すごい Haskell 本とか)を参照したりすると良いのではないかと思います。

最近は #umekitahs の参加者が減っていたので、これを機に参加者が増えると嬉しいです。

Haskellによる並列・並行プログラミング読書会 #17 を開催しました #umekitahs

umekitahs.connpass.com

Haskellによる並列・並行プログラミング」を読み進めてきましたが、ようやく第15章、最後の章を読み終わりました。

15章「デバッグ、チューニング、外部コードとのインターフェース」

デバッグやチューニングの話はもう少し前の章でやってほしかった感じ。本書の後半を読み進める前にこの章を見ておけば良かったかも。

15.1 並行プログラミングのデバッグ

GHC.ConcthreadStatus 関数でスレッドの状態が取得できます。通常の制御で利用するためのものではなく、デバッグ用。

GHC-eventlog オプションをつけてビルドすると、プログラム実行時に eventlog ファイルが出力されます。イベントログの内容を見るのは、この本で何度も出てきた ThreadScope を使います。あるいは、ghc-events というツールでも見ることができます。このとき、labelThread 関数や traceEventIO 関数を利用すると、イベントログが見やすくなって便利です。

また、前の章でも出てきましたが、GHCデッドロックを自動検出してくれます。しかし、検出できないデッドロックもあるので注意。

15.2 並行および並列プログラムのチューニング

GHC のスレッドは OS ではなくランタイムシステム内で管理される軽量スレッドです。生成にかかる時間、メモリ使用量、コンテキストスイッチの性能、どれも優秀なようです。さらに、RTS オプションによってランタイムシステムの微調整が可能です。

スレッド間でデータを共有する場合に、MVarTVarIORef の3種類のコンテナがあります。それぞれ一長一短で、状況によって選択することになります。

15.3 並行性と外部関数インターフェース

Haskell から C の関数を呼んだり、C から Haskell の関数を呼んだりする話。あまり詳しいことは書かれていません。

C の関数を呼び出す場合、Haskell のスレッドでなく OS のスレッドが使われます。

場合によっては、特定の OS スレッドを使う必要が出てきます(1つは GUI ライブラリのように、メインスレッドで呼ぶ必要があるもの。もう1つは OpenGL のように状態をスレッドローカルに持つもの)。このために、束縛スレッドという仕組みが用意されています。

次回以降の予定

Haskellによる並列・並行プログラミング」を読み終わったので、次回からは違う内容を始めたいと思います。

JXUG Xamarin もくもく会 大阪 に参加しました #JXUG

jxug.connpass.com jxug.connpass.com

土曜日、Xamarin もくもく会フェンリルの大阪の会議室と東京の会議室で開催されました。2箇所で開催されたもくもく会テレビ会議でつないで、その状態でもくもくするという謎なシチュエーション(意外と悪くなかった)。

今回僕は、Realm Xamarin のお勉強をしました。まずは Xamarin Blog の Cross-Platform Development with Xamarin.Forms and Realm の記事の内容をやってみて、その後で周辺のことを調べてみる、ということをしました。

Realm は、Objective-C 版と Swift 版は使ったことがあります。今回は Xamarin 版でしたが、基本的な考え方はだいたい同じで、同様に使いやすくて良いと感じました。

Realm Xamarin の BeginWrite

ちょっと面白いなと思ったのが、Realm Xamarin は Realm.BeginWrite()Transaction という IDisposable を返す点です。

Realm Swift で Realm.beginWrite() を使う場合だと次のようなコードになります。

realm.beginWrite()

// realm への操作...

realm.commitWrite()
// または realm.cancelWrite()

これが Realm Xamarin だと次のようになります。

var transaction = realm.BeginWrite();

// realm への操作...

transaction.Commit();
// または transaction.Rollback();

transaction.Dispose();

Xamarin Blog の記事では、この transaction を遷移先の画面に渡し、遷移先の画面で Commit()Dispose() を行うという構造になっていました。その記事の設計が良い設計なのかどうかは判断に迷いますが、少なくともそういった芸当が可能な点で、Realm Xamarin は柔軟であると感じました。

雑感

大阪東京ともに参加者が意外と多くて、Xamarin が注目されてきているんだな、と改めて感じました。また、もくもく会やりたい。

Haskellによる並列・並行プログラミング読書会 #14 #umekitahs

umekitahs.connpass.com

スレッドを用いた並列プログラミング

本書の前半は「並列」を、後半は「並行」を扱ってきました。13章では、並行プログラミングの技術(つまりスレッド)を使って並列プログラミングをする話です。

純粋な並列プログラミングが使えない問題は、「I/O をしなければならない問題」「内部的な非決定性に依存するアルゴリズム」があるとのこと。

まあ、スレッドによる並行処理を複数の CPU コアで動かすというだけの話かなと思います。ただ、スレッドをむやみにたくさん作ってもオーバーヘッドが大きくなって性能向上にならないので、そこを解決する必要があります。

例題:ファイル探索

ファイルシステムを検索して特定の名前のファイルを見つける find プログラムが題材です。

最初に「直列版」の findseq.hs が出てきます。これが基本形で、これをどう並列にするか。

findpar.hs : Async を使って素朴に並列化したもの。サブディレクトリごとに Async を生成するのでパフォーマンスが悪い。

findpar2.hs / findpar3.hs : スレッド数を制限したもの。制限をかけるためにセマフォを利用している。findpar2 は MVar でセマフォを実装していてあまり効率が良くない。findpar3 は IORef でセマフォを実装していて効率が良くなっている。

findpar4.hs : Async バージョン(findpar.hs)で、Async の代わりに ParIO モナドを活用したもの。パフォーマンスが良い。

後の方で「実はこんな簡単で便利なものがあるんだよ〜」と出してくるのは、この本の定番パターンですね。

ただ、ParIO はエラー処理がないという問題があり、エラー処理をどうするかは読者への課題となっています。とは言っても、それに対応したサンプルコード findpar5.hs は用意されていますが。

今後

並列並行本も、あとは 14 章と 15 章だけになりました。最後まで読み終えたら、Umekita.hs として次に何をやるかは未定です。もう少し参加者が増えてほしい・・・。

つらつらと案を考えてみる。

興味ある方はご意見ください。