ぱろっと・すたじお

技術メモなどをまったりと / my site : http://parrot-studio.com/

希望の関数と絶望の副作用 (on 2013/08/31)

2013/08/31の「JOSHI会(仮?)」*1で発表してきました(`・ω・´)


ある意味で先日やるはずだった発表の「マイルド版」なのですが、
まだ難しいというか、これ以上かみ砕くとなると、
もう対面でいろいろ説明するくらいしか・・・(´-ω-)

私が一貫して主張したいのは、資料にもある通り、
関数型言語を使えなくてもいいけど、その概念は知った方がいい」ということです

先日仕事でリリースしたシステムが、
まさに今回の話と関連していまして・・・

  • I/Oのみに特化したAPIサーバ群
    • 渡されたデータをスキーマレベルの検証のみで読み書きする
  • 副作用のない、ロジカルな部分だけで構成されたAPIサーバ群
    • 渡されたデータを制御し、加工して返す
  • APIを利用してViewを組み立てるAPサーバ群
    • ロジカルなAPIとやり取りして画面を構築

・・・という設計で構築したのです

要するにそれぞれModel/Controller/Viewなのですが、
アーキテクチャに依存しない抽象的な設計を取ることにより、
APIをモジュール的に組み合わせて使えるようになっています *2

このような設計により、仕様変更がほとんどロジカルなサーバの修正で済み、
開発の序盤こそフレームワークの構築で時間がかかりましたが、
後半からリリース後にかけては、かなり高速に対応できたと思ってます

ちなみに、この実装のヒントになったのは、
実はオンラインゲームの設計だったりしますΣ(・ω・ノ)ノ

オンラインゲームを支える技術  ??壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus)

オンラインゲームを支える技術  ??壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus)

非常に面白い本なので、興味がある方はぜひ

あとはまあ、今回の資料の最大の問題は、
タイトルがいまいちなところですかね・・・
もうちょっとネタか真面目か、どちらかに寄せるべきでした(´-ω-)

*1: 「上毛で・おいしいものを食べながら・ささやかに・話しあう・ITの会」みたいな意味だったはずですが、最終的に何になったんだったかな・・・(´-ω-)

*2: 現時点ではAPI群をPadrinoで構築していますが、Rails4のAPI版が出たらそちらにしたいですね・・・ Viewは古いシステムの都合でPerlになってますが、JSONでやり取りしているので問題ないです