denite.nvimとag使い始めた

かの有名な暗黒美夢王ことShougoさん開発中のdenite.nvimを使い始めました。いつもありがとうございます。超速くていい感じです。

install方法とか詳細な説明は以下のエントリが詳しいので割愛。

qiita.com

とりあえずdeniteの設定自体は :h denite に載ってたのをとりあえず8割くらいコピペしました。 fast grepツールとしてagを使ってます。

chaika.hatenablog.com

設定はこんな感じになりました。

call denite#custom#var('file_rec', 'command',
      \ ['ag', '--follow', '--nocolor', '--nogroup', '-g', ''])

call denite#custom#var('grep', 'command', ['ag'])
call denite#custom#var('grep', 'recursive_opts', [])
call denite#custom#var('grep', 'final_opts', [])
call denite#custom#var('grep', 'separator', [])
call denite#custom#var('grep', 'default_opts',
      \ ['--nocolor', '--nogroup'])

nnoremap <silent> <C-k><C-f> :<C-u>Denite file_rec<CR>
nnoremap <silent> <C-k><C-g> :<C-u>Denite grep<CR>
nnoremap <silent> <C-k><C-l> :<C-u>Denite line<CR>
nnoremap <silent> <C-k><C-u> :<C-u>Denite file_mru<CR>
nnoremap <silent> <C-k><C-y> :<C-u>Denite neoyank<CR>

とりあえず :Denite grep :Denite file_rec あたりが快適なのでいろいろ捗ります。

pluginばっかりに頼ってると素のvim, grep, findあたりの使い方が怪しくなってくる。。。

実践Vim　思考のスピードで編集しよう！ (アスキー書籍)

Ruby2.3系での"Missing frozen string literal comment"への対処

Missing frozen string literal comment

Ruby2.3系でRubocopを実行したら Missing frozen string literal comment と怒られました。

ファイルの先頭に以下のmagic commentが必要とのこと。

# frozen_string_literal: true

これによってRubyのStringリテラルが勝手にfreezeされてimmutableになるらしいです。 Ruby3系では基本的にimmutableになる予定なので、その互換のためのようです。便利な上に移行も楽そうですね。

参考:

qiita.com

対処

Rubocopで Missing frozen string literal comment が出てるファイルの先頭行にmagic commentを追記すればよいので、適当なワンライナーで一括対処できます。

rubocop | grep 'Missing frozen string' | cut -d: -f1 | xargs gsed -i -e '1i\# frozen_string_literal: true\n'

BSD系sedのオプション苦手なのでgsed使ってます。

Effective Ruby

Git Large File Storage (LFS)を使う

会社のSlackでGit Large File Storage (LFS)なるものを知ったので適当に使ってみました。

git-lfs.github.com

Git LFSとは？

Gitの拡張です。 画像とか音声みたいなLarge File（BLOB）をGitで管理しようとめちゃくちゃ重くなってきます。 直接BLOBをいじらずにポインタをテキストファイルとしてgitで管理し、BLOBの本体は別サーバに保存してるみたいです。 本体のリポジトリがすっきりする&fetch, cloneが高速になるのがメリットです。

Install

$ brew install git-lfs
$ git lfs install

使い方

とりあえず適当な画像（space_cat.jpg）をリポジトリに配置して試しました。 DocのGetting Startedを参考に。

# track対象のパス確認
$ git lfs track
Listing tracked paths

# track対象に"*.jpg"追加
$ git lfs track "*.jpg"
Tracking *.jpg

# track対象のパス確認
$ git lfs track
Listing tracked paths
    *.jpg (.gitattributes)

# .gitattributesに設定が追記されている
$ cat .gitattributes
*.jpg filter=lfs diff=lfs merge=lfs -text

# あとは普通
$ git add .
$ git ci -m 'aaa'
$ git push

これだけなので超簡単です。

試したやつ

space_catを回転させてPR出してます。プレビューが楽しい。

github.com

仕様

このあたりに書いてあったのであとで読みたいやつです。

github.com

エンジニアのためのGitの教科書 実践で使える! バージョン管理とチーム開発手法 (WEB Engineer’s Books)

Effective Ruby 第五章 メタプログラミング まとめ その1

Effective Ruby 第四章 例外 まとめ - Memento memo. の続きです。

第五章 メタプログラミングについての前半部です。

Effective Ruby

モジュール、クラスフックを使いこなす

• Rubyのイベント通知 -> フック関数の実行は、適切な名前のメソッドを書くだけで実行可能
• 定義できるフックは10種類

hookメソッド	タイミング
included	moduleがincludeされる
extended	moduleがextendされる
prepended	moduleがprependされる
inherited	classが継承される
method_added	method追加
method_removed	method削除
method_undefined	method定義解除
singleton_method_added	特異method追加
singleton_method_removed	特異method削除
singleton_method_undefined	特異method定義解除

• 全てのフックメソッドは特異メソッドとして定義する
• method追加、削除、定義解除系のフックは引数としてメソッド名を受け取る。クラス名を知りたい場合はselfを使う。
• 全てのフックメソッドは自動的にprivateになる
• フックメソッドに関連する以下のメソッドはオーバーライドしてはならない。フックを使うこと。
  • extend_object
  • append_features
  • prepend_features

module PreventInheritance
  class InheritanceError < StandardError; end

  def inherited(child_klass)
    raise(InheritanceError, "#{child_klass} cannot inherit from #{self}")
  end
end

::Array.extend(PreventInheritance)

class ChildArray < ::Array; end
#=> ChildArray cannot inherit from Array (PreventInheritance::InheritanceError)

inherited フックを使うとこんな感じの使い方になります。

クラスフックからはsuperを呼び出す

• hookは他のモジュールで定義されたhookの制御を完全に奪ってしまう場合がある。
• クラスフックメソッド内では必ず super を呼ぶのが行儀が良い。

method_missingではなくdefine_methodを使う

• method_missingを使ってはいけない理由
  • パフォーマンス面でコストがかかる
  • エラーメッセージが分かりにくくなる
  • respond_to? 等のイントロスペクションメソッドが使えなくなる。
• method_missingで本来やりたいことの大半はproxy, decorator patternの実装だが、これらはdefine_methodで代替可能
• proxyの実装

class HashProxy
  Hash.public_instance_methods(false).each do |name|
    define_method(name) do |*args, &block|
      @hash.send(name, *args, &block)
    end
  end

  def initialize
    @hash = {}
  end
end

• decoratorの実装

require('Logger')

class AuditDecorator
  def initialize(object)
    @object = object
    @logger = Logger.new($stdout)

    @object.public_methods.each do |name|
      define_singleton_method(name) do |*args, &block|
        @logger.info("calling '#{name}' on #{@object.inspect}")
        @object.send(name, *args, &block)
      end
    end
  end
end

上記例の用に、オブジェクトの場合は define_singleton_method で特異メソッドを定義できます。

• どうしても method_missing を避けられない場合は respond_to_missing? を併用する。
• respond_to_missing? は repond_to? がメソッドを見つけられなかった場合の最後のチャンスをプログラマに委ねる。

evalの多様な変種間の違いを把握する

• eval, instance_eval, class_eval で直接文字列を評価するのは避ける。
• 代わりに class_exec, instance_exec とブロックを使うと変数のvalidation等が行えるようになる。

参考

secret-garden.hatenablog.com

---

細かいところはメタプログラミングRubyを読む必要がありそうですね。

メタプログラミングRuby 第2版

続きます。

翔泳社の技術書（電子版）が40%オフセールだったので色々買った

技術書は分厚くて持ち歩くのがしんどいので最近は全部電子版を買って読んでます。 翔泳社の技術書はKindle対応してるので最高です。

翔泳社の技術書のセールが始まったらしいので色々買いました。 個人的にメインはDDD本です。

www.amazon.co.jp

買った / すでに持ってた本

エリック・エヴァンスのドメイン駆動設計

DDD本です。結構難しいらしいので頑張って読みたいです。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計

DDDと合わせて読みたいやつです。途中まで読んで力尽きたのでリトライしたいです。

実践ドメイン駆動設計

Spring徹底入門

DIとかAOPの解説が分かりやすい。大判固定レイアウトなので電子版だと読むのがつらかったです。

Spring徹底入門 Spring FrameworkによるJavaアプリケーション開発

Effective Ruby

読むだけでRubyのコーディングの質が上がります。 最近読み終わりました。めっちゃ良かったです。

Effective Ruby

実用Common Lisp

200pくらい読んで挫折しましたが良書です。 全部で1000pくらいあります。

実用Common Lisp

スターティングGo言語

Golangの入門書です。 "みんなのGo言語"より初心者向けのはずです。

スターティングGo言語

エッセンシャル スクラム

スクラム本はいろいろあるんですが、会社の先輩におすすめされたのでこれ買いました。 アジャイルサムライとかもおすすめらしいです。

エッセンシャル スクラム

今回買ってないけど読んでみたい本

ストラウストラップのプログラミング入門

鈍器&名著らしいですが、多分読めないので今回はスルーしました。

ストラウストラップのプログラミング入門

プログラマのためのSQL

結構人気が高いみたいです。 今回はキャパオーバーしそうなのでパスしましたがいつか読みたいやつです。

プログラマのためのSQL 第4版

プログラマのためのDocker教科書

Dockerは日本語良書が少ない上、結構頻繁にアップデートされてる印象です。 公式ガイド読んだりKubernetesの勉強した方がいいっぽいですが一応

プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化

VegetaでPhoenixとRailsの負荷テスト

以前会社の同期とご飯を食べていた時、 HTTP負荷テストツールのVegetaというものを紹介してもらったので試してみました。

github.com

GitHubのプロジェクトページを開くとイカしたサイヤ人の王子が目に飛び込んできます。

Golang製ツールで、CLIで比較的簡単に扱えるのが特徴のようです。 大量のリクエストを投げるコマンドが vegeta attack です。 大量にエネルギー弾を撃ちまくるイメージですね。 ドラゴンボールの負け確フラグです。 "王子戦法"、またの名を"グミ撃ち"というらしいです。

dic.nicovideo.jp

Vegeta で負荷をかける

とりあえず使ってみます。他所のサーバに負荷をかけると本当に怒られるのでやめましょう。自前で用意したサーバかlocalhostに向かって実行しましょう。

負荷テストの対象は最近ハマってるPhoenix (v1.2.1, Elixir 1.2.6)と、比較用のRails (v5.0.0.1, Ruby 2.2.3)です。

手持ちのMBPのローカルでPhoenixとRailsをnewした状態でサーバを立てます。 そしてlocalhostのルートURLに向かってリクエストを飛ばします。

※ 条件は超適当です。

VegetaのREADMEを読みつつ、以下のようなコマンドで rate を変えながら結果グラフを作成してみます。

$ echo "GET http://localhost:3000" | vegeta attack -duration=10s -rate=100 | vegeta report -reporter=plot > rails-100.html

vegeta attack のオプションで以下の内容を指定しています。

• duration=10s ... 10秒間負荷をかける（今回は全試行で固定値）
• rate=100 ... 秒間リクエスト数（変動値）

Rails => Phoenixの順で軽く検証してみます。

Rails

※Rails5のデフォルト設定のままPumaを使っています。
チューニングすればもう少しなんとかなるかもしれません。

30req/s

余裕ですね。20ms付近で安定しています。

50req/s

まだまだいけそうです。

80req/s

ダメになりました。 半分くらいの処理が詰まって10秒遅れて処理されてます。（リクエスト受け付けずにVegetaがRetryしてるんでしょうか？？？HTTPステータスコード等を全く見てないので正確な挙動は不明です。すみません。。。） 通常のレスポンスも70ms程度まで落ち込んでいます。

100req/s

すごいことになりました。

Phoenix

次いでPhoenixです。

30req/s

余裕です。

100req/s

まだまだいけます。Railsはここで死んでました。

500req/s

レイテンシが若干大きくなってますが、概ね100ms以下で捌き切ってます。

800req/s

レイテンシが100ms前後安定してます。

1000req/s

エラーがいろいろ発生し始めました。 最初の2秒くらいは頑張ってますね。

2000req/s

半分くらいエラーになってしまいました。お疲れ様でした。

まとめ

条件は超ざっくりですが、ローカル環境では

• Rails: 50 - 80 req/s
• Phoenix: 800 - 1000 req/s

くらいいけました。Phoenixの方が10倍くらいパフォーマンス良いみたいな通説があるんですが、大体そんな感じの結果です。

分散環境でもPhoenix + Elixirは強いはずなので、高速で大量のリクエストを捌く必要のあるシステム（ソシャゲやtwitter）に向いてる気がします。通信回数控えめなエンタープライズ系だとメリットより導入コスト・リスクの方が上回るような感覚です。

キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置

あと、あまり負荷テストとかやったことがないので、 このあたりもう少し勉強していきたいです。 グラフの解釈等間違っていたらご指摘いただけると幸いです。

プログラミングElixir

PhoenixのChannelを使う

www.phoenixframework.org

Phoenixのガイドを眺めていて一番気になったのがChannelだったので、上記の公式ガイドに沿ってChannelを使ってみました。結構端折っています。

プログラミングElixir

概要をつかむために公式ガイドの一番上のところだけ訳してみます。

Channels are a really exciting and powerful part of Phoenix that allow us to easily add soft-realtime features to our applications. Channels are based on a simple idea - sending and receiving messages. Senders broadcast messages about topics. Receivers subscribe to topics so that they can get those messages. Senders and receivers can switch roles on the same topic at any time.

Since Elixir is based on message passing, you may wonder why we need this extra mechanism to send and receive messages. With Channels, neither senders nor receivers have to be Elixir processes. They can be anything that we can teach to communicate over a Channel - a JavaScript client, an iOS app, another Phoenix application, our watch. Also, messages broadcast over a Channel may have many receivers. Elixir processes communicate one to one.

The word "Channel" is really shorthand for a layered system with a number of components. Let's take a quick look at them now so we can see the big picture a little better.

適当訳:

チャネルはPhoenixの中でも本当に面白くて強力なところであり、簡単にソフトリアルタイム性をアプリケーションに持たせることができます。チャネルはメッセージの送受信という、単純なアイデアに基いています。senderはtopicについてブロードキャストし、receiverはtopicを購読することによってメッセージを受け取ることができます。sender, receiverはいつでも役割を交代することができます

ElixirはMessage Passingに基いているため、どうしてメッセージの送受信に他の仕組みを利用するのか疑問に思うことでしょう。チャネルでは、senderもreceiverもElixirのプロセスである必要はありません。チャネルと通信するものはJavaScriptやiOSでも何だってよいのです。また、Elixirのプロセスが1対1で通信するのに対し、チャネルにおけるメッセージブロードキャスティングはreceiverが複数になり得ます。

"Channel"という言葉は多くのコンポーネットをもった多層システムを簡略に表したにすぎません。 全体像をもっとよくつかめるようになるために、もう少し覗いてみましょう。

以下、各partsの説明（省略）

• Socket Handlers
• Channel Routes
• Channels
• PubSub
• Messages
• Topics
• Transports
• Transport Adapters
• Client Libraries

---

手を動かすのが一番早い理解につながるので、 例の如く適当にプロジェクトとDBを作成します

プロジェクト作成

$ mix phoenix.new channel_sample
$ cd channel_sample
$ mix ecto.create

SocketとChannelの設定

lib/hello_phoenix/endpoint.ex の4行目付近ですでにsocketが定義されています。

defmodule ChannelSample.Endpoint do
  use Phoenix.Endpoint, otp_app: :channel_sample

  socket "/socket", ChannelSample.UserSocket
...

ChannelSample.UserSocket 自体は web/channels/user_socket.ex で定義されています。5行目のコメントアウトを外して、channelの設定をします。

defmodule ChannelSample.UserSocket do
  use Phoenix.Socket

  ## Channels
  channel "room:*", ChannelSample.RoomChannel

Channelモジュールの実装

HelloPhoenix.RoomChannel モジュールはまだ存在しないので、web/channels/room_channel.ex ファイルを作成し、以下の内容でモジュールを定義します。

defmodule ChannelSample.RoomChannel do
  use Phoenix.Channel

  def join("room:lobby", _message, socket) do
    {:ok, socket}
  end

  def join("room:" <> _private_room_id, _params, _socket) do
    {:error, %{reason: "unauthorized"}}
  end
end

（ <> は文字列結合をしています）

認可のために、join/3 関数を定義する必要があります。 今回は"room:lobby" topicだけは誰でも入れるようにし、private_roomのことは考えないこととします。

クライアント側の設定

web/static/js/socket.js に最低限の実装が最初からあるので、中身を確認します。

// web/static/js/socket.js
...
socket.connect()

// Now that you are connected, you can join channels with a topic:
let channel = socket.channel("room:lobby", {})
channel.join()
  .receive("ok", resp => { console.log("Joined successfully", resp) })
  .receive("error", resp => { console.log("Unable to join", resp) })

export default socket

上記のように57行目付近を let channel = socket.channel("room:lobby", {}) に変更します。

また、web/static/js/app.js 末尾行のコメントアウトを外してsocket.jsを有効にします。

import socket from "./socket"

Phoenixがライブリロードされ、ブラウザコンソールに以下のように出力され、 socket通信が確立されていることがわかります。 （Phoenixを起動していない場合は $ mix phoenix.server します）

---

---

web/templates/page/index.html.eex を修正して、入力フォームとメッセージ表示用のコンテナを作成します。

<div id="messages"></div>
<input id="chat-input" type="text"></input>

socket.js ファイルを修正して、socket通信でメッセージの受送信ができるようにします。

...
let channel = socket.channel("room:lobby", {})
let chatInput = document.querySelector("#chat-input")
let messageContainer = document.querySelector("messages")

chatInput.addEventListener("keypress", event => {
  if(event.keyCode === 13){
    channel.push("new_msg", {body: chatInput.value})
    chatInput.value = ""
  }
})

channel.on("new_msg", payload => {
  let messageItem = document.createElement("li");
  messageItem.innerText = `[${Date()}] ${payload.body}`
  messagesContainer.appendChild(messageItem)
})

// let channel = socket.channel("topic:subtopic", {})
channel.join()
  .receive("ok", resp => { console.log("Joined successfully", resp) })
  .receive("error", resp => { console.log("Unable to join", resp) })

export default socket

RoomChannelモジュールを修正します。 socketでメッセージが飛んできた際のフック関数として handle_in を実装すれば大丈夫です。

broadcast! で接続中のクライアント全員にメッセージを送ります。

handle_out ではクライアントごとにフィルタリング処理を行ったり、Interceptor的な役割をもっています。今回は何もしていません。

defmodule ChannelSample.RoomChannel do
  use Phoenix.Channel

  def join("room:lobby", _message, socket) do
    {:ok, socket}
  end

  def join("room:" <> _private_room_id, _params, _socket) do
    {:error, %{reason: "unauthorized"}}
  end

  def handle_in("new_msg", %{"body" => body}, socket) do
    broadcast! socket, "new_msg", %{body: body}
    {:noreply, socket}
  end

  def handle_out("new_msg", payload, socket) do
    push socket, "new_msg", payload
    {:noreply, socket}
  end
end

これでChatができるようになりました。

---

Sample

こちらにChat Appのサンプルがあるようです。

http://phoenixchat.herokuapp.com/

Heroku上で動いています。逆に対応してるPaaSはHerokuだけかもしれないです。

Programming Phoenix: Productive, Reliable, Fast

まとめ

Channelが手軽につかえていい感じです。 当然普通にRails的な使い方もできるのでなかなか汎用性高いのでは？と思いました（小並感）

Effective Ruby 第四章 例外 まとめ

Effective Ruby 第三章 コレクション まとめ - Memento memo. の続きです。

今回はRubyの例外についてです。

例外は、以下の2つの異なる言語機能をまとめたものだと考えられます。

• エラーの説明
• 制御フロー

raiseにはただの文字列ではなくカスタム例外を渡す

• raise に文字列だけを渡さず、例外のクラス名を指定する
• または例外クラスを（パラメータと共に）インスタンス化してraiseに渡す
• カスタム例外クラスにinitializeメソッドを定義するときはsuperを呼び出す

raise("something wrong") # NG
raise(CustomError, "something wrong") # OK
raise(CustomError.new(param)) # OK
raise(CustomError.new(param), "something wrong") # OKだが、第一引数のオブジェクトのメッセージが失われる

• 新しい例外クラスは、標準例外クラス（主にStandardError）を継承し、慣例的に名称をXxxErrorのようにする。
• 1つのプロジェクトに複数例外クラスを作る場合はStandardErrorを継承した基底クラスを作成し、個々の例外クラスはそこから継承する。

出来る限り最も対象の狭い例外を処理する

• 修復プロセスがわかっている特定の例外（DB、NW接続エラー等）だけをrescueで捕まえる
• 限定された例外（詳細度の高いもの）から順にrescueする
• 汎用例外クラスをrescueで補足してはダメ。ensure節を作るか、上流で処理すること。
• rescue節内で例外が発生すると新しい例外が現在の例外を押しのけてしまう。その場合、新しい例外より元の例外をraiseするのが良い。

リソースはブロックとensureで管理する

• メモリはGCで処理されるが、メモリ以外のリソース（オープンしたファイル等）の自動的な開放は保証されない。
• ensure節でリソースを確実に開放する
• ensure節の式はbegin本体と同じスコープだが、変数が初期化されていない可能性に注意する

# ensureによるリソース管理
begin
  file = File.open(file_name, 'w')
  ...
ensure
  file.close if file 
end

• ブロックで抽象化して同等の処理が可能

File.open(file_name, 'w') do |file|
  ...
end

• File::openと同じようなブロック&ensureパターンを独自のリソース管理クラスでも実装すると良い（以下のような実装）

Lock.rb

ensureは最後まで実行して抜ける

• ensure節の中で制御文（return, throw, next, break）などの制御文は絶対に使ってはならない
• ダメ、絶対

retryで回数上限を設け、頻度を変化させ、オーディットトレイルを残す

• 無条件のretryは無限ループに等しい危険性がある
• retry実行の境界変数はbegin節の外のスコープに定義する
• retryを使うときはaudit trail（監査証跡）を作ること。エラーのイベント連鎖を必ずログに残す。
• retry時のディレイはrescue節の中で値を（指数関数的に）増やしていくことを検討する。

retry.rb

スコープから飛び出したいときはraiseではなくthrowを使う

• catchとthrowは例外とは関係ない。gotoの安全versionと考える方が近い。
• 複雑な制御フローが必要な場合はraiseよりthrowを使う。throwの場合スタック上位にオブジェクトを送ることができる。
• ただしthrow、catchを多用してはならない。出来る限り単純な制御構造（return）を使う。

ネストの深いループから一撃で脱出したい場合はthrowすると良いみたいです。ただ、ネストの深いコードは循環的複雑度が高くなっちゃうのでそもそもそういったコードは避けるべきですね。

---

Effective Rubyは八章構成なので、前半戦終わりです。

次はメタプログラミングです。一番重そうな章です。

Effective Ruby

The actor model in 10 minutes [日本語訳]

10分でわかるアクターモデルです。 Erlang, Elixir, Scalaあたりを触るときに理解すべき内容です。

元ネタ: www.brianstorti.com

Introduction

我々のCPUは速くなりません。 CPUには今やたくさんのコアを積んでいますが、 全てのハードウェア資源を利用したければ コードを並行的に走らせる必要があります。 マルチスレッドの利用が進むべき道でないことは、 数十年もの追跡不能バグや開発者の憂鬱が示しています。 しかし恐れることはありません。 素晴らしいいくつかの代替案があります。 今回はその中の一つを紹介しましょう。 それはActor Modelです。

Model

Actor Modelは並行計算を取り扱うための概念的なモデルです。 システムコンポーネントがどのように振る舞い、相互作用すべきかについてのいくつかの原則が定義されています。 Actor Modelを使っている最も有名な言語はErlangでしょう。 Actor Modelがどのように他の言語やライブラリで実装されているかについての話はしません。Actor Modelそれ自体に焦点を当てていきましょう。

Actors

Actorは、計算において最も基本的な（primitiveな）ユニットです。 Actorは、メッセージを受け取り、受け取ったメッセージに基いて何らかの計算を行う"もの"です。

アイデア自体はオブジェクト指向言語のそれによく似ています。 オブジェクトはメッセージを受け取り（method call）、受け取ったメッセージ（call された method）に基いて何かを行います。

Actor ModelとOOPとの最も大きな違いは、 Actorは完全に独立しており、決してメモリを共有しないことです。 注目すべきは、Actorは決して他のActorからは直接書き換えることのできないprivateなステートを維持できる、ということです。

One ant is no ant

Actorは一つでは意味がありません。複数でシステムを形成します。 Actor Modelにおいては、全てはActorであり、Actorは他のActorがメッセージを送るためのアドレスを持つ必要があります。

Actors have mailboxes

複数のActorは同時に走る一方、一つのActorは受け取ったメッセージを連続的に（シーケンシャルに）処理する、というの理解することが重要です。 つまり、3つのメッセージを同じ一つのActorに送ったとして、 受け取った側のActorは単に一つずつシーケンシャルに処理します。 3つのメッセージを並行処理させたい場合は、3つのActorを作成し、それぞれに一つずつメッセージを送る必要があります。

複数メッセージは非同期的にActorに送られるので、他のメッセージを処理している間、それらをどこかに格納しておく必要があります。 メッセージの格納先こそが、メールボックスです。

Actorたちは非同期メッセージを送り合いコミュニケーションを取ります。それらメッセージは、処理されるまでの間、他のActorのメールボックスにしまわれています。

What actors do

メッセージを受け取ったActorは、次の3つのうちのどれか一つを行うことができます。

• 更なるActorを作成する
• 他のActorにメッセージを行う
• 次受け取るメッセージと何をすべきかを指定する

上2つは非常に直感的ですが、3つ目は興味深いですね。 先に述べた通り、Actorはprivateな状態を保持することができます。 "次受け取るメッセージと何をすべきかを指定する"というのは、 より明確にいうと、Actorが状態を変化させる方法です。

計算機のように振る舞うActorがあり、 最初のstateが 0 であると想定してください。 Actorが add(1) というメッセージを受け取った場合、 元のstateを変化させてしまう代わりに、 次受け取るメッセージに対して stateが 1 になるように指定します。

Fault tolerance

Erlangは"let it crash"という思想を取り入れました。 "全ての単一障害点について考えるのは不可能であるため、 起こりうる全ての可能性を予想し、それぞれ対処する方法を見つけるような 防御的プログラミングを行う必要はない"、という考えです。 Erlangの手法は、すぐにcrashさせる代わりに、この致命的なコードを誰か（スーパーバイザ）に監視させることです。スーパーバイザの単一責務は、crashが起きた場合に何をすべきか（例として、crashしたユニットを正常な状態にresetする）を把握することです。 これを可能にしているのがActor Modelです。

全てのコードはプロセス（ErlangがActorと呼んでいるもの）の中で走ります。 プロセスは完全に独立・隔離されているので、プロセスのstateが他のプロセスの影響を受けることはありません。 スーパーバイザ（スーパーバイザもプロセス = Actor）は、 監視対象のプロセスがクラッシュすると通知され、何かの処理を行うことができます。

これらの仕組みにより自己修復(self heal)機能を持ったシステムを作ることが可能です。 つまり、あるActorが何らかの理由で例外的なstateになりcrashした場合、 スーパーバイザはcrashしたActorを再び整合性の取れたstateにすることができます。具体的な戦略はいくつかありますが、一般的なのはActorを初期状態にしてrestartすることです。

Distribution

メッセージを送るActorがローカルに存在するのか、離れたノードに存在するのかについては全く重要ではない、というのが Actor Modelの他の興味深い側面です。

考えてみてください。Actorがメールボックスと内部状態を持ち、メッセージに応答するだけのコード片だとしたら、実際にActorが動いているマシンが何であるかなんて誰が気にかけるでしょうか。メッセージがそこに届きさえすればそれで問題ありません。

おかげで、我々は複数のマシンを使ったシステムを構築でき、一つのノードに障害が起きたとしても、復旧が容易になります。

プログラミングElixir

PhoenixのTemplate Engineを Slime (Slim) にする

Slime

PhoenixのデフォルトのTemplate Engineは erbライクなeexです。 RailsだとerbよりSlimを使うケースも多いと思いますが、 PhoenixでもSlimライクなTemplate Engineが存在しました。

その名もSlimeです。ロゴがスライムっぽいですね。

github.com

多分発音も"スリム"じゃなくて"スライム"だと思います。

Phoenixに適用する

基本設定

適当なPhoenixのプロジェクトの mix.exs に依存関係を追記します。

...
  defp deps do
    [{:phoenix, "~> 1.2.1"},
     {:phoenix_pubsub, "~> 1.0"},
     {:phoenix_ecto, "~> 3.0"},
     {:postgrex, ">= 0.0.0"},
     {:phoenix_html, "~> 2.6"},
     {:phoenix_live_reload, "~> 1.0", only: :dev},
     {:gettext, "~> 0.11"},
     {:cowboy, "~> 1.0"},
     {:phoenix_slime, "~> 0.6.0"} # here
   ]
  end

config/config.exs にも適当に設定書きます。

# Configure slime
config :phoenix, :template_engines,
  slim: PhoenixSlime.Engine,
  slime: PhoenixSlime.Engine

依存関係を追記したので本体をfetchしてきます

$ mix deps.get

watch対象に追加

my_app/config/dev.exs を修正。ライブリロードを有効にするために、slim, slimeのファイルをwatch対象に追加します。

# Watch static and templates for browser reloading.
config :slime_sample, SlimeSample.Endpoint,
  live_reload: [
    patterns: [
      ~r{priv/static/.*(js|css|png|jpeg|jpg|gif|svg)$},
      ~r{priv/gettext/.*(po)$},
      ~r{web/views/.*(ex)$},
      ~r{web/templates/.*(eex|slim|slime)$} # here
    ]
  ]

Generator Tasks

$ mix help | grep -i phoenix

とすると、phoenix関係のmix taskがドバドバ表示されます。

$ mix help | grep -i phoenix
mix local.phoenix            # Updates Phoenix locally
mix phoenix.digest           # Digests and compress static files
mix phoenix.gen.channel      # Generates a Phoenix channel
mix phoenix.gen.html         # Generates controller, model and views for an HTML based resource
mix phoenix.gen.html.slime   # Generates controller, model and views for an HTML based resource using Slime templates
mix phoenix.gen.json         # Generates a controller and model for a JSON based resource
mix phoenix.gen.layout.slime # Generates a default Phoenix layout file in Slime
mix phoenix.gen.model        # Generates an Ecto model
mix phoenix.gen.presence     # Generates a Presence tracker
mix phoenix.gen.secret       # Generates a secret
mix phoenix.new              # Creates a new Phoenix v1.2.1 application
mix phoenix.routes           # Prints all routes
mix phoenix.server           # Starts applications and their servers

出てこない場合は mix compile なり mix phoenix.routes なりすると buildが走って一緒にtaskが生成されると思います。

slime関係で新しくできたtaskは

mix phoenix.gen.html.slime   # Generates controller, model and views for an HTML based resource using Slime templates
mix phoenix.gen.layout.slime # Generates a default Phoenix layout file in Slime

の２つです。

とりあえず動かしてみます。

User users と書いている部分は 単数形 複数形 で入力します。 生成されるcontroller名はrailsと違って単数形ですね。

$ mix phoenix.gen.html.slime User users --no-model
* creating web/controllers/user_controller.ex
* creating web/views/user_view.ex
* creating test/controllers/user_controller_test.exs
* creating web/templates/user/edit.html.slim
* creating web/templates/user/form.html.slim
* creating web/templates/user/index.html.slim
* creating web/templates/user/new.html.slim
* creating web/templates/user/show.html.slim

Add the resource to your browser scope in web/router.ex:

    resources "/users", UserController

見事にslimファイルが生成されましたね。slimeはどこに行ったんでしょうか。

生成されたslimの中身は以下のようになってます。

h2 Listing users

table.table
  thead
    tr
      th
  tbody
    = for user <- @users do
      tr
        td class="text-right"
          = link "Show", to: user_path(@conn, :show, user), class: "btn btn-default btn-xs"
          | &nbsp;
          = link "Edit", to: user_path(@conn, :edit, user), class: "btn btn-default btn-xs"
          | &nbsp;
          = link "Delete", to: user_path(@conn, :delete, user), method: :delete, data: [confirm: "Are you sure?"], class: "btn btn-danger btn-xs"

= link "New user", to: user_path(@conn, :new)

ページの表示

とりあえずメッセージの通りに web/router.ex に resources "/users", UserController を追記します。

--no-model にしたせいかサーバ起動しようとするとめっちゃ怒られるので user_controller の余計なアクションを一旦全部削って以下のようにします。

defmodule SlimeSample.UserController do
  use SlimeSample.Web, :controller

  alias SlimeSample.User

  def index(conn, _params) do
    render(conn, "index.html", users: [])
  end
end

[error] Postgrex.Protocol (#PID<0.212.0>) failed to connect: ** (Postgrex.Error) FATAL (invalid_catalog_name): database "slime_sample_dev" does not exist みたいなエラーが出てきます。 DB作ってないので $ mix ecto.create で作りましょう。

とりあえずこれで

$ mix phoenix.server

して、 http://localhost:4000/users にアクセスすれば、ページが表示されるかと思います。

Railsで作ったアプリケーションをPhoenixに移植するのが捗ります。

プログラミングElixir

Programming Phoenix: Productive, Reliable, Fast

slimeのsyntax highlightのvimプラグインは提供されているようです。

github.com