「なぜ関数プログラミングは重要か」を要約してみた（その１） - Okapies' Archive
関数型プログラミング (functional programming) の利点を説く際によく持ち出されるのが、QuickCheck の開発者の一人である John Hughes が 1984 年に著した論文 "Why Functional Programming Matters" だ。「なぜ関数プログラミングは重要か」という題名で日本語訳もされているので、読んだことがある人も多いと思う。 要旨としては、冒頭の１章および２章で述べられている「関数型プログラミングが優れているのは、高階関数と遅延評価という、モジュール同士を貼り合わせる強力な『糊』を持っているからだ」という話がほぼ全てで、以降はそれを具体例に基づいて説明する構成になっている。ただ、その具体例として「数値計算アルゴリズム」やら「ゲーム用人工知能アルゴリズム」やらの話が延々と続くし、しかもコード例が Haskell の先祖にあたる
ReactiveX と「普通のやつらの上を行け」の意外な関係 - Okapies' Archive
これは「関数型プログラマのための Rx 入門」の補足記事です（タイトル変えた）。 前編、後編とお送りしてきたこの記事だが、特に後編について「何を言ってるのか分からん」というコメントを何人かの方から頂いた。…なんというか、ごめんなさい。 繰り返しになるが、Rx を使う上で関数型プログラミングの知識は必ずしも必要ではないし、むしろ（関数型のコンセプトが基礎にあるのに関わらず）知らなくても使えるようになっている。ライブラリの作者たちは「過度な抽象化は害になる」ということを弁えているのだろう。 しかし、Rx と関数型プログラミングの関係を把握しておくと、非同期データストリームのビルディング・ブロックの作り方について大いに視野が広がるだろう。もし、貴方がこの記事の前提となる「関数型」のパラダイムに興味をお持ちなら、まずは「関数プログラミング実践入門」をお勧めしたい。 関数プログラミング実践入門 ──
関数型プログラマのための Rx 入門（後編） - Okapies' Archive
前編では、Reactive Extensions (Rx) の機能を関数型プログラミングの視点で読み解いた。続いて後編では、前編で紹介した Rx が関数型的な機能を提供している背景、つまり Observable と他の一般的なコンテナの関係に対してスポットライトを当ててみたい。 あらかじめ断っておくと、本編の話題は、実際に Rx を使う上で理解している必要は（あまり）ない。とりあえず、 Observable は、List や Future と同じくモナドの一種である 以下の表に出てくるコンテナは、隣同士で互いによく似た（あるいは正反対の）性質を持っている: 単数 複数 同期 (pull) T/Try[T] Iterable[T] 非同期 (push) Future[T] Observable[T] …という話だけ記憶に留めてもらえば、ここで回れ右してもオーケー。とはいえ、興味のある人はこの
関数型プログラマのための Rx 入門（前編） - Okapies' Archive
概要 『Observable は単なる非同期データストリームにおけるモナドのインスタンスだよ。何か問題でも？』 まともな概要 つまり、Reactive Extensions (Rx) って何だ？ ということでウェブをガサゴソと漁っていたところ、オンライン講義サービス Coursera の Principles of Reactive Programming に行き当たった。この講座では、Rx の主要開発者の一人である「双対おじさん」こと Erik Meijer 氏自らが一部の章を担当し、Rx の理論的側面を講義している。 この講座の大きな特徴は、Rx を（命令型プログラミングではなく）関数型プログラミング (FP) の側から解き明かしていくことにある。 こう書くと奇をてらっているように見えるかもしれないが、実際には Rx は FRP (Functional Reactive Program
マイクロサービスのための Tumblr 製フレームワーク "Colossus" - Okapies' Archive
この記事は Scala Advent Calendar 2014 の 15 日目です。昨日は id:qtamaki さんの”「関数プログラミング 珠玉のアルゴリズムデザイン」をScalaで実装してみる”でした。 今日は、先日に Tumblr が OSS 化を発表した Scala 製のノンブロッキング I/O (NIO) フレームワーク "Colossus" を紹介したい。”高性能なマイクロサービスを構築するためのフレームワーク”を謳っており、まだ OSS 化されて日が浅いものの Tumblr ではすでに production で使われているとされる。また、Colossus 自体がアクターフレームワーク Akka のアクターとして実装されており、それを使った独自のスレッドモデルを提供している点も興味深い。 Colossus Colossus: A New Service Framework
非同期ストリーム処理の標準化を目指す "Reactive Streams" とは - Okapies' Archive
TL でこんなのが流れてたので少し調べてみた。 Learn about the Reactive Streams initiative & how we're supporting a standard for asynch stream processing on the JVM http://t.co/5wUF0PjTBe— Twitter Engineering (@TwitterEng) 2014, 4月 17 Reactive Streams って？ Reactive Streams ”JVM 上でのノンブロッキングなバックプレッシャーを持つ非同期ストリーム処理の標準の提案”（公式サイトより）。 ざっくり言うと、既にある JVM ベースの様々な非同期ストリーム処理フレームワーク実装の共通部分を括りだして API 化、SPI 化しようというもの。最終的には JSR での標準化を目指
Hadoop/Storm の統合を実現する Twitter の SummingBird - Okapies' Archive
Twitter が SummingBird を正式リリースして早二ヶ月。「日本語の紹介記事がほとんど出てないな」と気付いたので、調査がてらまとめてみました。 SummingBird とは？ MapReduce なプログラムを書くための Scala/Java ライブラリ。最大の特徴は、ひとたび SummingBird で書いたジョブは Hadoop でも Storm でも同じように実行できること。 SummingBird では、Hadoop を使う「バッチモード」と、Storm を使う「リアルタイムモード」に加えて、二つを同時に実行する「ハイブリッドモード」がある。ハイブリッドモードでは、ジョブの作者が特に配慮しなくても、バッチとリアルタイムの処理結果を自動的にマージできる。 ハイブリッドモードでは、同じジョブを Hadoop と Storm で同時に実行できるので、Hadoop の耐障害性
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
