Pixel Pedals of Tomakomai

北海道苫小牧市出身の初老の日常

今日は Roppongi.pm #1 の日です

技術

六本木.pm に来ていますので、適当にメモします。

オープニング

  • 吉祥寺.pm + Okinawa.pm = 六本木.pm
  • 六本木で Okinawa.pm やればいいや
  • 飲食自由、フリードリンク
  • ハッシュタグは #roppongipm

ラクダがピンクだった頃の思い出 / @yoshiyuki_kondo さん

  • Cプログラマのためのアルゴリズムとデータ構造、 Javaプログラマのためのアルゴリズムとデータ構造、yaccによるCコンパイラプログラミング なども書いてます
  • Perl4の時代はラクダ本もリャマ本もピンク
  • 訳本には Larry Wall のサインが入っている
  • 1994年の 5.0 で青いラクダになった
  • 常時接続は先進的な大学・企業のみ
    • 小規模な会社はモデム(uucp)
    • usenetとメールを利用。30分毎にポーリング
  • Perl 3 の後期から弄っていた
    • comp.sources.misc
    • perl 4.0 のネットニュース → 36個集めるとソースファイルになる
  • Sun の Sparc Station
    • 16MB, 500MB
    • 3人でPC9801からログイン
    • X window は未使用
    • Emacs(Eight Megs And Constanly Swapping 笑) の日本語版は Nemacs
  • Perl は初めて広く使われたスクリプト言語
  • Cと比べてPerlのよかったとこ
    • s/// は大胆だけど便利
    • <> $_ は慣れると便利
    • コンパイルがいらないのでターンアラウンドが短い
      • BASICを思い出す
    • 標準Cライブラリを一通り使える
    • 別プロセスを起動しないので、早い
  • Perl4の弱点
    • requireしかない(oraperl.pl)、リファレンスがない
    • 日本語の扱い jperl, jcode.pl
  • 当時はオライリーの日本法人がなかった
  • Perl5 になってオライリー・ジャパンから
  • Linux Confrence 200 Fall & Perl/Ruby Conference
    • Larryにアニメの売ってる場所を教えた思い出
    • Ruby 2.0 と Perl 6 はどっちが先に出るか
  • Perl のハッシュ実装は優れている
    • Hashdos : 同じハッシュ値を持つキーを大量に投げて、そのキーへのアクセスを遅くする
    • perlは大丈夫だった : 毎回ハッシュ値の生成方法が違う

Amason::S3::Thin の紹介 / @DQNEO さん

  • AMazon S3
    • KVS的だが永続保存
    • 大きめのファイルを大量保存
    • HTTP REST API
  • Amazon::S3::Thin
    • Thin, Low level, Low learning cost, Signature V4
    • put_bucket , put_object or get_object
  • Thin
    • put_bucket は _compose_request request の組み合わせ
    • HTTPリクエストを作ることしかやってない
    • ステータスコード無視、リトライしない、XMLもパースしない
  • Thin の利点
    • 依存が少ない(XMLライブラリ不要)
    • やってることが透過的にわかる
    • エラー時の挙動を自由に組める
  • Low level
    • put_bucket は API の PUT Bucket と一対一に対応
  • Low level の利点
    • S3 Rest API を知っていれば学習コストが低い
    • aws-cli の aws s3api と同じ感覚
  • 利用実績
    • ブラジル、アメリカのPR、 skaji さんのとこ
  • 動機
    • Net::Amazon::S3, Amazon::S3 が主流だった
    • Perlish Interface が用途に合わない
      • メソッド名が add_key なのに PUT OBject してるとか
      • $bucket オブジェクトの位置づけが直感的ではない
      • $s3->err は文字列じゃないの？ $bucket への呼出が $s3 に保存されたり
      • 抽象レイヤにもやもや → fork した
  • 設計のヒント
    • Symfony (PHP)
      • MVCフレーム枠ではない
      • HTTPフレームワーク。リクエストを受けてレスポンスを返す
    • S3ライブラリの本質はHTTPクライアント
      • Perlで言えば 。
    • Web::Query (by tokuhirom さん)
      • 通信部分とDOM部分が明確に分かれている
    • リクエストを作るだけ。通信はしない
  • 与太話 (PHPer が感じたこと)
    • 日本のPerl Mongersは強い
    • Perl以外にも精通
    • 息をするように CPANize
    • Conference駆動OSS開発
    • インフラ、アプリケーションエンジニアも
    • 小さいツールでものを作る、Test文化、POD文化
    • PODに哲学
    • 車輪の再発明もする
    • 遊び心 Acme::
      • 処理系のソースに指輪物語のセリフが書いてたり

Perl5 と私の歴史 / @tokuhirom さん

  • 2005～2014までPerl、2015～2016までJava
  • Perl 5のまま
  • Text Processing, CGI, mod_perl, Plack と変化があった
    • おじさん「CGI時代はFTPでアップするだけだった・・・」
  • 10年前に考えていた理想のプログラミング言語
    • 速い、楽しい、便利
    • XS、みんなで作るのは楽しい、自分で書けば便利になる
  • 書いたもの
    • Text::MicroTemplate
    • MadEye (Plagger 的なの)
    • HTTP::Session
    • Smart::Args (エグい記法で書けるやつ)
    • Furl (DeNAの人が必要としてた)
    • OrePAN
    • Amon2 : 広く使われている。高速
    • Teng : DBIx::Classより省メモリで高速
      • DevOps的な人が楽をできるようなテクニカルスタッフ
    • Minilla : miyagawa さんが Dist::Zilla ベースでも作ったので２つになった
    • Router::Boom : ルーティングを正規表現にするので速い
    • Localizer
    • Plack : 仕様と実装を分けたかった。miyagawaさんが飛行機に乗ってる間にできた
  • Perl Toolchain Gang になった
    • 日本人だとmiyagawaさんとtokuhiromさん
  • 他
    • perldoc.jp
      • miyagawaさんが飽きたので受け取って、JPAへ
    • METACPAN の API Exporter
    • plenv
  • Perl6 の歴史
    • 10年経っても実用的な速度が出ない
    • Perl 5 を Perl 7 にする派
    • Perl 6 と Perl 5 は別の言語だから仲良くしよう
  • 2015年にPerl6がリリース
    • WAFが作れるようになっているはず
    • 色々を移植 → 速度が出てないので、実用的ではない
  • なぜをJavaを使っているか
    • Fast 、 IDE Support がある
    • Perl を書く人は動的にやってしまいがちなので、IDEがショボい
  • Perl 5 は Plack のあと、 Text Processing 用途に戻ってきた
    • awk などより便利
    • Python には DATA section や <> のような意味不明な機能がない
  • Perl 5 は Plack に向いてない。 Text Processing で使うもの

History from Perl 1.0 to Perl 6 / @AnaTofuZ さん

  • Perl1 ... Perl4 は実在したのか
  • Perl 全部ビルドした
  • Perl 2, Perl 3 のコードは Perl 5 のリポジトリにすべて残っている
    • タグが付けられている
  • 過去のPerlのコードはググっても出てこない
    • man を使う
  • gcc を自前で build する必要がある
  • Perl 1.0
    • 2002年 gcc3 対応（Perlへの誕生日プレゼント）
    • chastai さんのリポジトリ → 消えた
    • サブルーチン、 C 言語スタイルの for loop はある
    • 添字は文字列である必要
    • エラーメッセージが厳しい
  • Perl 2.0
    • local, foreach, sedよりも高速, do で外部ファイルの呼び込み
    • fib が書ける (再帰呼び出しサポート)
  • Perl3.0
    • Perl5の原型ができる
    • 型グロブ、連想配列、 do hoge から &hoge でサブルーチン呼出
    • .. が範囲演算子に
    • 多次元配列がまだ書けない - キーの結合でごまかす
  • Perl4.0
  • Perl5.0
    • オペコードを使ったコンパイル+ インタプリタ型に変更
    • miniperlが登場、 manからpod
    • use, my
    • SV 型ができた
    • typedef の数が9個から 49個へ
  • パフォーマンスは、小さい処理であればオペコードに変換しない分古いPerlのほうが速い
  • Perl6.0
    • 大きいデータを使うと、JITによってJVM版について
    1. GCCは古いものを撮ってくる？
      1. 必要はない。Perlのソースをいくつか弄る

LT

めくるめくB::Cの世界 / @papix さん

  • PerCUDA / Perl で GPGPU を使う論文
  • GPGPUが熱い
  • 問題点 : Perl -> C -> LLVM IR -> PTX
  • Text::Xslate でやってる
  • B::C --force で因すとーる
  • 変換は成功
  • B::C 初華絵ない
    • 普通のC言語のコードが必要
    • PerlとCは似ているから、そのまま変換するといい
  • perlcc を使うとバイナリにできる

サーバレス日本語形態素解析エンジンとの格闘記録 / @Korenari_D さん

  • Perl / awk sed が辛い時に使うもの
  • 実用Perl に Perl で自然言語処理に使うと書いてある
    • NLPのいしづえ
  • 形態素解析
    • 「振り返れ」「ば」「遠く」「へ」「やって」「きた」
  • 形態素解析エンジン + ライブラリ
    • MeCab + IPAdic / NEologd
  • 環境を整えるのがめんどくさい
  • AWS APIGateway + Python Lambda + NEOlogd の発表の構成が良さそう？
    • OSのコンパイルが必要、処理速度が遅い
    • 1,000 文字の解析に 9.1 秒
    • Lambda の起動と S3 からのDockerイメージ読み込みが遅い
  • サーバレスは銀の弾丸ではない
  • API Gateway - Fargate で1秒以内になった

吉祥寺.pmに登壇して○○になろう！ / @setoazusa さん

  • 9/1 付で Microsoft MVP for Developer Technologies (JavaのMVPは日本人初)
  • 吉祥寺.pmに登壇してMMVPになろう
  • PHPとPythonはあるけどPerlはない
  • kuduで入るなら何でも動く、Dockerがある、PerlのMVP
  • 10/8 技術書店に行きましょう

1年間Perlでゲーム作りました / @return520 さん

  • サーバー
    • Amon2 を API サーバとして利用
    • RDS Redis Memcache と通信
    • フロント : AngularJS, Vue.js, Native, Unity
  • EC2インスタンスでAgngular.js と Amon2 で
  • Perl 5.18 で、バージョンをあげようとしている

クロージング

  • YAPC::Tokyo 2019 を 2019-01-26 に開催
  • ブログを書くまでが Roppongi.pm
  • 次回以降は反響次第。話を聞きたい人に声を掛ける方針

"アルゴリズムクイックリファレンス" のノート (2)

技術

p.4 の貪欲法。素朴なアルゴリズムよりこちらの実装のほうが楽に思える。

github.com

前回の遅いアルゴリズムとの速度比較。 variance introduced by outliers が大きくていいのかは気になる。貪欲法の方が 2,000 倍以上速いので、むしろ前回の slow の実装に問題がありそう。

$ stack exec bench-convexhulls -- --output=convexhull.html
points generated
fromList [Point 2.1377835882015472e-2 0.37675969687894406,Point 0.13059550359891225 0.8854193459395515,Point 0.14393294171704973 0.6508550014289608,Point 0.14678966702903884 0.21690928594716652,Point 0.1757711424912075 0.38256258657810427,Point
 0.28131270801990793 0.5923766278106027,Point 0.3174033812169047 2.044354461161324e-2,Point 0.3439496349547865 0.6634254643623526,Point 0.35531986020882733 0.9939481921271572,Point 0.4572955120772927 0.8085648753413374,Point 0.47351659627409937
 0.654837905224889,Point 0.5475827076206295 0.6856510548569369,Point 0.5982120295123295 0.11060895459648956,Point 0.7500144155213943 0.4153833924540856,Point 0.7612610246351973 0.8364323883690482,Point 0.7686159957030524 0.9395602140690221,Poin
t 0.8566170876792828 0.3887263627739349,Point 0.8958593880534803 0.8857736692653796,Point 0.9108407836308833 0.7138539153041928,Point 0.9771895259588333 0.6526386332297055]
benchmarking slow
time                 5.779 ms   (5.547 ms .. 6.036 ms)
                     0.987 R²   (0.975 R² .. 0.998 R²)
mean                 5.858 ms   (5.748 ms .. 6.044 ms)
std dev              407.6 μs   (267.3 μs .. 603.6 μs)
variance introduced by outliers: 41% (moderately inflated)

benchmarking greedy
time                 2.451 μs   (2.413 μs .. 2.495 μs)
                     0.997 R²   (0.992 R² .. 0.999 R²)
mean                 2.452 μs   (2.421 μs .. 2.520 μs)
std dev              148.3 ns   (51.28 ns .. 270.0 ns)
variance introduced by outliers: 72% (severely inflated)

HTMLはこちら。

https://cdn.rawgit.com/hiratara/hs-nutshell-algorithm-examples/master/convexhull.html

降順に並べるときに使う Data.Ord の Down みたいな小技は、知っているとお得感がある。

"アルゴリズムクイックリファレンス" のノート

技術

p.3 の convex hull の素朴解。

https://github.com/hiratara/hs-nutshell-algorithm-examples/blob/master/src/Main.hs

正しいかわからないので、plotしておく(案の定バグってたので修正してある)。

f:id:hiratara:20180908162419p:plain

道具は datahaskell に従った。具体的には、乱数に mwc-probability 、 plot に Chart-diagrams を利用。作ったsvgファイルをブラウザで見るために、 stack install wai-app-static して warp によってweb serverを立ち上げている。。

"The Elements of Statistical Learning" のノート

技術

The Elements of Statistical Learning .

chap. 2

  • supervised learning と unsupervised learning
  • inputs
    • predictors, independent variables, features とも言う
  • outputs
    • responses, dependent variables, targets とも言う
  • quantitative
  • qualitative : 有限集合で表現される
    • classes, categorical, discrete, factors とも言う
  • regression : quantitative outputs を予測すること
  • classification : qualitative outputs を予測すること
  • qualitative and quantitative input variables
    • 予測に使う手法に影響する
  • ordered categorial : categorical だが順番がある
    • 例: small, medium, large
  • qualitative variable はコード上では数値で表現される
    • 0, 1 とか -1, 1 とか
    • dummy variables: 複数個のカテゴリをまとめる
    • K-level qualitative variables
      • K 個の2値変数で同時に2つ以上ONにならないもの
  • input variable は X で表す
    • component は X_j
  • quantitative outputs は Y
  • qualitative outputs は G (group)
  • observed value は小文字で書く
    • i番目に観測したX は x_i
    • scalar or vector
  • 行列は大文字太字
    • \boldsymbol{X}: N \times p, i = 1, ..., N, x_i: \textit{p-vactors}

LTS-12.1でhpack-convertコンパイルできないんすよねー

技術

そんなこともあろうかと、forkして lts-12.1 ブランチ用意しておきましたので。

github.com

まあ、ただの変換ツールなので、古いLTSでビルドしても構わない気はするけど、新しいマシンだと ghc インストールさせたりするのだるかったので。

ということで、手元のリポジトリももろもろ hpack に乗り換えようとしてるのだった。

Haskell入門のサンプルコードのLTS-12.0対応

技術

つい半年前に最新のLTSへ対応したばかりなのに、気がつくと LTS-12.0 が出て、 ghc-8.4 を Stack から使えるようになった。コミュニティが活発で、非常にありがたいことである。

ということで、 Haskell入門 のサンプルもLTS-12.0に対応させたブランチを用意した。と言っても、いくつか Stackge の管理下から外れてしまったパッケージが出てきたのを調整したくらいで、コードは何も変更していない。

github.com

さらに素晴らしいことに、これらのコードはすべてWindows 10の最新の WSL 上で動くことを確認できた。macOS上で試すのと同様に、 Windows 上でも書籍上のコードをそのまま試せる のだ。10章の Spock を使ったWEBサーバも起動して localhost へアクセスして動かすことができる。Windowsが頑張ったのかGHCが頑張ったのかは確認してないが、どちらにしてもHaskellをWindowsユーザでもハマりどころなく触れるようになったのは、本当によい時代が来たなあと思う。

それでは皆様、楽しいHaskellライフを。

今日は第15回 Cloud Application Platformアーキテクチャの日です

技術

今日は第15回 Cloud Application Platformアーキテクチャの日です

第15回 Cloud Application Platformアーキテクチャ にお邪魔しています。

Cloud Application Platformアーキテクチャ / asami224 さん

  • ディスカッション用のスライドです
  • Cloud Application Platformのコンセプト
  • Web DSL
    • DSLという言葉は聞かなくなったが、また戻ってくる
    • アプリバブルは終わった。WEBに戻ってきた
    • WEB開発はGUI開発の歴史を繰り返しそう
    • JSは型がないのでバグがとれない。 lint は限界があるでしょう
    • ロストテクノロジーの再発見
    • markup＋αでアプリを作りたい
  • 関数型プログラミングが大事になってくる
    • 商用の大きいプログラムはすべて関数型になる
    • モナドを使う。フリーモナド。 I/O モナドの拡張
    • フリーモナドを使ってState machineを実装する
  • reactive streams
    • process monadを使ってpure functionalなstate machine
    • 試しに使ってみたらうまく動いた
  • 銀行でさえもクラウドを使おうとする時代
    • AI, IoT : お客さんが欲しいと言ったら提供は必要
    • Distributed, Concurrent/Parallel, Asyncronous, Realtime : 非同期が大切
    • 例: IoT : 大量のイベントを受け取る。ファイルではなくストリームで来る
    • AIの詳細は専門家だが、大規模データを扱う必要がある。データの準備が7割。普通のエンジニアに一番大事
  • Object-Functional Programming
  • Procedural Programming, Object-Oriented Programming, Functional Programming
    • Java = OOP + PP, Lisp = FP + PP (+ Meta), Haskell = FP, Scala = OOP + FP + PP + DSL [+ Meta], scalaz/cats = OOP + FP + DSL [+ PP] [+ Meta]
    • オブジェクト指向がないと難しい
    • APIではなく、DSLとして機能を提供。モデリングが簡単になるのではないか
    • Metaも重要。コンストラクタやエンコーダ周りを自動でやらせたい
    • Scalaは文法がモダンなので、簡単にかけて良い
  • クラウドアプリケーションではFPを使っていくのが重要
    • 10年前から言っててあまり変わっていないとは言え・・・
  • FPにおける重要な概念
  • Scalaは増えてる？
    • 増えてはいる。Pythonが増えすぎた。Javaも残ってる
  • Object-Functional Analysis and Design
    • ビジネスから実装までどうつなげるのか
    • アプリケーションのモデルからプログラムを自動生成したい
    • プログラムの自動生成を受け止められる強力なプラットフォームが必要
    • 2つの伸ばし方 : 「ビジネスの方向」「上流のモデリングからプログラムの生成」
  • 数理モデルと認知モデル(ヒューリスティックモデル)
    • 認知モデル: OOPのモデリングの売り。人間の見たものをそのままシミュレートする
    • 数理モデル: 自動生成に向いている
    • 二本立て。クラウドプラットフォームで実現させるには？？
  • 構造データと半構造データ
    • もともと存在する不定形のデータが先にあり、それを処理するアプリが後
  • Cloud Application のメタモデル
    • UP : Static Structure Model(クラス図など)、Dynamic Model(state machine)、Collabolation Model(interaction model。ユースケースから帰納的にモデル化)
    • OMT(object-modeling technique) : Dataflow Model (FP)
      • UPで一度過去に消えたもの
      • big dataには有効そう
      • FPの台頭
    • Business Rule Model
      • AIの応用。AIはFunctionをプログラミングではなくデータから作る
      • データをどう用意するのか
      • FunctionのInterfaceは大事。ビジネスルール(例: 運賃表)
  • Cloud Application Frameworkの狙い
    • フレームワークは重要
    • 運用コスト、セキュリティ : ここまでは既存のASPと同じ狙い
    • ビジネスの振る舞いを集める
      • ログデータなどを、アプリ間で揃える
      • 最近のBigDataは、データの正規化に時間を取られている
    • 複数企業間の連携を簡単にする
      • DBを共通化する
      • 複数の企業が提携するショッピングモールなど
      • はじめから連携する気ではなかった企業間を、簡単に連携できる
    • ビジネスとエンジニアリングの共通言語
      • 別のプロジェクトから来たエンジニアがすぐ開発に入れる
      • 完全リモート。週に3時間程度しか事務所にいない
      • フルタイムじゃないエンジニアでも、会社に参加できる枠組み
    • アプリケーション開発は設定とDSLの記述だけでやりたい
      • 設定だけでもいろいろなことが表現可能
  • Coreの構成
    • Engine : BaaS + CMS + CRM + EC + Publishing
    • ServiceBus : PubSub(kinesis)によって連携させている
    • 管理コンソール、Zabbix
  • Subsystemの構成
    • JobScheduler(OSS) + ECS : ドイツ製。安定してないので考え直し中
    • PUSHSender, MailSender
    • EAI (ServiceMix/Camel)
    • Data Aggregator : RedShift, Aurola
  • 今後の展望
    • Core, SubSystem以外のシステムもぶら下げる (Application Service (仮称))
    • DMP, DWH, MDM(Master Data Management)
    • Advertisement(ニーズがあまりないのでペンディング)
    • Workflow (ステートマシンの管理に必要。Marketing Automationの基盤ともなる)
      • OSSでもあったが消えていった ... アダプタが必要で、書くのがむずい
      • 統一データにしているので、カスタマイズしなくても利用可能
  • Q). MDMは統一データでは不要なのでは？？
      1. 小売店で同じ商品を扱ってる場合などに必要
    • スター型のデータ構造。プラットフォームのマスタ＋自社データ、という組み合わせで使っていく
  • Q). JOINするなら同じノードに載せる必要があるのでは？
    • 原則はそう。お客さんが嫌がるなら、アプリサイドでJOIN
  • WEB DSL
    • 経緯: アプリバブルが終わってしまった。WEBへ
    • WEBのレイヤでDSLにした
  • モデリングと実装の仕方
    • 今まで: domainモデルに対してMVCのモデルが必要 (RoRなら自動生成)
    • View Modelの導入 : TableやGridといったUIの単位で
      • .jade 形式に、埋め込める
      • ControllerもJSONで書ける。Platformで提供するもので十分なことが多い
      • カスタマイズはCard単位で可能
    • CardとGrid(12分割)でのUIの記述。HTMLより抽象度の高い部品
      • (例: Bootstrap4)
    • markup Engineer がアプリを作れるようにする
      • 簡単なのが売りだったはずが難しくなっている
      • 営業とMarkup Engineerがアプリを作れるのが理想 → PCPで可能になる！(設定だけでバックエンドが動く)
    • Vue.jsとかAngularとか使うとなると本末転倒
  • バックエンドもフロントもコードを書かなくても良い
  • Q). system-infoはどの部分？
      1. これはsinkと呼んでおり、変数名。View Modelを入れる
    • 画面の見た目によった設計にしている。裏のドメインは複雑でも、出せば表・リスト・グリッド
  • 製品で使おうとしたらがWEBエンジニアに拒否された
    • 「PHPのほうが簡単ですよ」
    • 一般に展開するのは難しいのかもしれない
  • Bootstrap4 ベースの creative-tim 社のものを使っている
  • 他のテンプレートの extend も可能 → テーマは切替可能
  • サーバサイドエンジニアのほうが刺さるかも
  • Q). componentでheader明細の表現するのは難しいのでは
      1. レイアウトファイルを定義できる。表示しようとするコンテンツを突っ込める
  • Q). WEB DSLとはJSONのこと？
    • ファイルだけで書けるのがWEB DSL。JSONは好きではない
  • FPで大事な技術はモナド
    • 値・関数に、コンテキストを隠蔽できる
    • コンテキストにはDistributedやParallel、I/Oとか乱数とか時間
    • pure functionalではeffectが扱えないので本来実用的なものが書けない
    • I/Oモナドがlazy evaluationのリストを作る。インタプリタが実行してくれる
    • I/Oモナドでは用途が限られる。Free Monadはそれを拡張したもの
    • Free Monadではinter preterを自分で書ける
  • Unit of Work : transactionのざっくり版
    • unitをfree monadで作ってある
    • commit historyをfree monadで作り、 interpret 時に実行する
    • メリット: DBがなくても、 interpreter テストができる
  • 難しいのでおすすめではないが、実装してみるとわかる
  • sales_order が複雑な状態を持っている
    • confirm(悪質ユーザの除外), shipment, charge
    • charge: クレジットカードと、代引き、コンビニで状態の遷移が違う
      • 内部的に複数のステートラインを持っている
      • DBに状態を持たなければならない
    • 状態変更時に Free Monad を返す
      • transaction 境界を知る必要があると、部品化が難しい
      • transaction 境界を知る必要がなくなる
  • 状態はDBには持ってない。発生したイベントをすべて登録してあるので、状態がわかる
  • Q). 失敗したときにはイベントを残す？
    • この例ではイベントを残さなくていい場合
  • Q). transactionはどう切る？
    • 今はモナド一個で1トランザクション。プリミティブを用意すればできる。free monadのprimitiveにすでにロック管理などはある
    • デバグの難しさ、動きの予測の難しさ、が難点
    • スタックトレースを見ても何もわからない。デバッガは対応してない
  • Q). メモリリソースは？
    • フリーモナドはメモリを使うのでもともと気をつける
    • reactive streamsを使うと、大きなデータをウィンドウとして扱えるので、解決できる
    • エンジンがキャッシュをしている
  • free monad は 非同期や many core がもっと普及してから。5年後に使うかもしれない技術への投資
  • Unit of Work ではトランザクションがあるので、実行方法を変えるのはちょっとむずかしいかも
  • monoidを使うと、計算の順は気にしなくて良い。最適化できるようになる。モナドもモノイドなので
  • 代数的データ型に落とし込めば、数理モデルのいろいろが使えて、良い