DEV Community: gumi TECH Blog

React入門 03: JSON形式の配列から複数データを取り出してページに表示する

gumi TECH — Wed, 15 Jan 2020 10:14:51 +0000

ページに表示するデータは、サーバーなどから得ることが多いでしょう。その場合、JSON形式が扱いやすく、APIから返すデータなどにもよく使われています。今回は、データのやり取りは置いておき、変数に納めた配列から取り出したデータを、コンポーネントのテキストとして表示してみます。手を加えるのは、「React入門 02: ライブラリMarkedでMarkdownの機能を加える」で書いたアプリケーションのモジュールです。

配列にまとめたJSONデータを子コンポーネントに渡す

データのテキストはJSONのかたちにして、大もとのコンポーネント(src/App.js)のクラス(App)のプロパティ(data)として、つぎのように配列要素として納めます。その値は、テンプレートの子コンポーネント(CommentList)のタグに同名の属性(data)として与えましょう。これで、子コンポーネントはプロパティから値が参照できます。



function App() {
  const data = [
    {author: "ヘンリー・キッシンジャー", text: "チャンスは__貯金__できない。"},
    {author: "マーク・トウェイン", text: "禁煙なんてたやすい。私は*何千回*もやった。"}
  ];
  return (
    <div className="App">
      <h1>コメント</h1>
      {/* <CommentList /> */}
      <CommentList data={data} />

    </div>
  );
}

複数データからテンプレートをつくる

子コンポーネント(src/components/CommentList.js)が親から引数オブジェクトに受け取るプロパティ(data)は配列です。配列要素すべてをコンポーネントに表示するには、その数だけテンプレートが必要になります。

そこで、関数コンポーネントの中で、以下に抜き書きしたコードのようにArray.prototype.map()メソッドでJSXテンプレートから要素をつくって変数(commentNodes)に配列で納めます。これを波かっこ{}に入れてテンプレートに加えれば、配列の要素すべてが差し込まれる仕組みです(「複数のコンポーネントをレンダリングする」)¹。これで、配列要素のデータが取り出されてページに表示できます(図001)。

なお、要素には一意の値をkey属性として与えなければなりません。Reactが要素の変更をkeyにもとづいて識別するためです。



// const CommentList = () => {
const CommentList = (props) => {
  const commentNodes = props.data.map((comment, id) => (
    <Comment author={comment.author} key={id}>
    {comment.text}
    </Comment>
  ));
  return (
    <div className="CommentList">
      {/* <Comment author="ヘンリー・キッシンジャー">
      チャンスは__貯金__できない。
      </Comment>
      <Comment author="マーク・トウェイン">
      禁煙なんてたやすい。私は*何千回*もやった。
      </Comment> */}
      {commentNodes}
    </div>
  );
};

図001■配列のJSONデータが取り出されて子コンポーネントに表示される

書き改めたコンポーネントふたつのJavaScriptコード全体は、つぎのとおりです(コード001および002)。

コード001■`src/components/CommentList.js`



import React from 'react';
import Comment from './Comment';

const CommentList = (props) => {
  const commentNodes = props.data.map((comment, id) => (
    <Comment author={comment.author} key={id}>
    {comment.text}
    </Comment>
  ));
  return (
    <div className="CommentList">
      {commentNodes}
    </div>
  );
};

export default CommentList;

コード002■`src/App.js`



import React from 'react';
import CommentList from './components/CommentList';
import CommentForm from './components/CommentForm';
import './App.css';

function App() {
  const data = [
    {author: "ヘンリー・キッシンジャー", text: "チャンスは__貯金__できない。"},
    {author: "マーク・トウェイン", text: "禁煙なんてたやすい。私は*何千回*もやった。"}
  ];
  return (
    <div className="App">
      <h1>コメント</h1>
      <CommentList data={data} />
      <CommentForm />
    </div>
  );
}

export default App;

Vue.jsではテンプレートに特別な属性(ディレクティブ)v-forを加えることで、データの数だけテンプレートがつくられて差し込まれます(「Vue.js入門 03: データから動的にリストをつくる」01「項目のデータを複数にする」参照)。つまり、JavaScriptコードでテンプレートをつくる必要はありません。

Angularも、ほぼ同じ構文のディレクティブ*ngForを備えています(「Display a Heroes List」「List heroes with *ngFor」参照)。 ↩

Elixirメタプログラミング 02: マクロ

gumi TECH — Fri, 20 Dec 2019 08:53:00 +0000

本稿はElixir公式サイトの許諾を得て「Macros」の解説にもとづき、加筆補正を加えて、Elixirにおけるマクロの定義方法についてご説明します。

はじめに

Elixirには、マクロをできるだけ安全に使える環境が整えられています。とはいえ、マクロでクリーンなコードを書くことは開発者の責任です。マクロをつくるのは、通常のElixirの関数を使うより難しいといえます。むやみにマクロを用いるのは、避けた方がよいでしょう。

Elixirには、データ構造や関数によりわかりやすく読みやすいコードを書ける仕組みがすでに備わっています。コードは黙示的より明示的に、短くよりわかりやすくすべきです。マクロはどうしても必要な場合にお使いください。

はじめてのマクロ

Elixirのマクロはdefmacro/2により定めます。本稿では、コードを基本的に.exsファイルに書いて、elixir ファイル名またはiex ファイル名のコマンドで実行しましょう。

簡単なマクロを書いて、動きを確かめてみましょう。モジュールはmacros.exsに定め、マクロと関数を加えます。コードの中身はどちらも同じです。反転した条件に応じて、引数の式を実行します。

defmodule Unless do
  def fun_unless(clause, do: expression) do
    if(!clause, do: expression)
  end

  defmacro macro_unless(clause, do: expression) do
    quote do
      if(!unquote(clause), do: unquote(expression))
    end
  end
end

関数は、受け取った引数をif/2に渡します。けれど、マクロが受け取るのは内部表現です(「Elixirメタプログラミング 01: 内部表現ー quote/2とunquote/1」参照)。そして、それを差し込んだ別の内部表現を返します。

前述で定義したマクロを試すために、このモジュールでiexを開きましょう。

$ iex macros.exs

マクロを使うには、その前にrequire/2でモジュールを要求しなければなりません。そのあと、関数と同じように呼び出せます。

iex> require Unless
Unless
iex> Unless.macro_unless(true, do: IO.puts "this should never be printed")
nil
iex> Unless.fun_unless(true, do: IO.puts "this should never be printed")
this should never be printed
nil

マクロも関数も戻り値(nil)は同じでした。けれど、マクロはIO.puts/2に渡した文字列が出力されません。文字列が関数で出力されたのは、値を返す前に引数が評価されるからです。これに対して、マクロは渡された引数を評価しません。引数は内部表現として受け取られ、別の内部表現にされるのです。今回、定義したmacro_unlessマクロは、ifの内部表現になります。

前掲macro_unlessの呼び出しは、引数につぎのような内部表現を用いたのと同じです。

iex> Unless.macro_unless(
...>    true,
...>    [
...>      do: {{:., [], [{:__aliases__, [alias: false], [:IO]}, :puts]}, [],
...>       ["this should never be printed"]}
...>    ]
...> )

さらに、マクロの定義も内部表現に展開すると、つぎのようになります。

{:if, [context: Unless, import: Kernel],
 [
   {:!, [context: Unless, import: Kernel], [true]},
   [
     do: {{:., [],
       [
         {:__aliases__, [alias: false, counter: -576460752303422719], [:IO]},
         :puts
       ]}, [], ["this should never be printed"]}
   ]
 ]}

引数の内部表現は、quote/2で確かめられるでしょう。さらに、その内部表現を展開するのがMacro.expand_once/2です。

iex> expr = quote do: Unless.macro_unless(true, do: IO.puts "this should never be printed")
{{:., [], [{:__aliases__, [alias: false], [:Unless]}, :macro_unless]}, [],
 [
   true,
   [
     do: {{:., [], [{:__aliases__, [alias: false], [:IO]}, :puts]}, [],
      ["this should never be printed"]}
   ]
 ]}
iex> res  = Macro.expand_once(expr, __ENV__)
{:if, [context: Unless, import: Kernel],
 [
   {:!, [context: Unless, import: Kernel], [true]},
   [
     do: {{:., [],
       [
         {:__aliases__, [alias: false, counter: -576460752303422719], [:IO]},
         :puts
       ]}, [], ["this should never be printed"]}
   ]
 ]}
iex> IO.puts Macro.to_string(res)
if(!true) do
  IO.puts("this should never be printed")
end
:ok
iex> IO.puts Macro.to_string(expr)
Unless.macro_unless(true) do
  IO.puts("this should never be printed")
end
:ok

Macro.expand_once/2は内部表現を受け取って、現在の環境に応じて展開します。前述の例では、マクロUnless.macro_unless/2が展開されて呼び出され、結果が返りました(__ENV__については後述します)。さらに戻り値の内部表現をIO.puts/2で文字列に出力して確かめたということです。

なお、内部表現をコードの文字列表現として確かめたいときは、つぎのように書くと簡単です。

iex> expr |> Macro.expand_once(__ENV__) |> Macro.to_string |> IO.puts
if(!true) do
  IO.puts("this should never be printed")
end
:ok

以上が、マクロの基本的な働きです。内部表現を受け取って、別のものに変換するという役割を果たします。実際、Elixirのunless/2の実装はつぎのようなものです。

defmacro unless(clause, do: expression) do
  quote do
    if(!unquote(clause), do: unquote(expression))
  end
end

unless/2やdefmacro/2、def/2、defprotocol/2などの構文、その他公式サイトのガイドに掲げられているコードは、純粋なElixirに加え、マクロで実装されているものも少なくありません。言語を構築している構文は、開発者がそれぞれ開発しているドメインに言語を拡張するために用いることもできます。

関数やマクロを用途に応じて定め、さらにElixirに組み込み済みの定義を上書きすることもできます。ただし、Elixirの特殊フォームだけは例外です。Elixirで実装されていないため、上書きができません。特殊フォームに何があるか、詳しくは「Kernel.SpecialForms」をご参照ください。

マクロの健全さ

Elixirのマクロは、あとで解決されます。つまり、マクロで定められた変数は、マクロが展開されるコンテキストに定義された変数と競合することはないということです。

たとえば、つぎのようにマクロと関数を、それぞれ別のモジュールに定義したとします。

defmodule Hygiene do
  defmacro no_interference do
    quote do: a = 1
  end
end

defmodule HygieneTest do
  def go do
    require Hygiene
    a = 13
    Hygiene.no_interference
    a
  end
end

関数が変数に値を定義したあと、呼び出したマクロが同名の変数に異なる値を与えても、関数の変数値は変わりません。

iex> HygieneTest.go
13

あえて、マクロが呼び出されたコンテキストに影響を与えたいときには、var!/2を使ってください。

defmodule Hygiene do
  # defmacro no_interference do
  defmacro interference do
    # quote do: a = 1
    quote do: var!(a) = 1
  end
end

defmodule HygieneTest do
  def go do
    require Hygiene
    a = 13
    # Hygiene.no_interference
    Hygiene.interference
    a
  end
end

マクロがvar/2に与えた変数は、呼び出されたコンテキストに上書きして定義されます。

iex> HygieneTest.go
1

上書きされたもとの変数値は使われません。そのため、コンパイル時に、それを告げる警告が示されます。

warning: variable "a" is unused

変数のコンテキストは、内部表現の第3要素のアトムで示されます。そして、モジュールからquote/2で引用された変数は、そのモジュールをコンテキストにもつのです。そのため、他のコンテキストを汚すことなく健全さが保たれます(「健全なマクロ」参照)。

defmodule Sample do
  def quoted do
    quote do: x
  end
end

iex> quote do: x
{:x, [], Elixir}
iex> Sample.quoted
{:x, [], Sample}

Elixirはインポートとエイリアスにも、同じ仕組みを与えます。マクロはもとのモジュールのもとで動作し、展開された先と競合することはありません。あえて、影響を及したいときに用いるのが、var!/2やalias!/1です。ただし、健全さが失われ、使われる環境を直接変えることになりますので、ご注意ください。

Macro.var/2を使うと、動的に変数をつくることができます。第1引数が変数名で、第2引数はコンテキストです。

defmodule Sample do
  defmacro initialize_to_char_count(variables) do
    Enum.map variables, fn(name) ->
      var = Macro.var(name, nil)
      length = name |> Atom.to_string |> String.length
      quote do
        unquote(var) = unquote(length)
      end
    end
  end

  def run do
    initialize_to_char_count [:red, :green, :yellow]
    [red, green, yellow]
  end
end

iex> Sample.run
[3, 5, 6]

環境

前述「はじめてのマクロ」の項でMacro.expand_once/2の第2引数に__ENV__を渡しました。戻り値はMacro.Env構造体のインスタンスです。構造体にはコンパイル環境の有用な情報が納められています。たとえば、現在のモジュールやファイル、行番号、現在のスコープのすべての変数などです。import/2やrequire/2で加わったものも含まれます。

iex> __ENV__.module
nil
iex> __ENV__.file  
"iex"
iex> __ENV__.requires
[IEx.Helpers, Kernel, Kernel.Typespec]
iex> require Integer
Integer
iex> __ENV__.requires
[IEx.Helpers, Integer, Kernel, Kernel.Typespec]

Macroモジュールの多くの関数は環境を与えて呼び出します。詳しくは、「Macro」をご参照ください。また、コンパイル環境については「Macro.Env」で解説されています。

プライベートマクロ

Elixirはdefmacrop/2で、プライベートマクロが定義されます。プライベートな関数になりますので、マクロを定義したモジュールの中で、コンパイル時にしか使えません。

defmodule Sample do
  defmacrop two, do: 2
  def four, do: two + two
end

iex> Sample.four
4

そして、プライベートマクロは、使う前に定義されていることが必要です。マクロは展開されてから、関数として呼び出せます。そのため、定義の前に呼び出すと、エラーが生じるのです。

defmodule Sample do
  def four, do: two + two  # ** (CompileError) macros.exs: undefined function two/0
  defmacrop two, do: 2
end

責任のあるマクロを書く

マクロはできることが豊富な構文です。Elixirはさまざまな仕組みで、責任のあるマクロが書けるようにしています。

健全: デフォルトでは、マクロ内で定義された変数は、使う側のコードに影響を与えません。さらに、マクロのコンテキストにおける関数呼び出しやエイリアスも、ユーザーコンテキストからは切り離されます。
レキシカル: コードやマクロをグローバルに差し込むことはできません。マクロが定められたモジュールを、明示的にrequire/2またはimport/2で使う必要があります。
明示: マクロは明示的に呼び出さなければ実行できません。言語によってはパースやリフレクションなどといった仕組みも用いて、開発者が外からわからないように関数をすっかり書き替えられたりします。Elixirのマクロは、呼び出す側がコンパイルのとき明示的に実行しなければならないのです。
明確: 多くの言語にはquoteやunquoteに省略記法が備えられています。Elixirではフルに入力することにしました。マクロ定義と内部表現をはっきりと識別できるようにするためです。

このような仕組みはあるものの、マクロを書く責任の多くは開発者が担います。マクロの助けがいると判断した場合、マクロがAPIではないことは頭においてください。

マクロの定義は、内部表現も含めて短くしましょう。つぎのように書くのは、よくない例です。

defmodule MyModule do
  defmacro my_macro(a, b, c) do
    quote do
      do_this(unquote(a))
      ...
      do_that(unquote(b))
      ...
      and_that(unquote(c))
    end
  end
end

つぎのように書けば、コードは明確になり、テストや管理もしやすくなります。関数do_this_that_and_that/3は直接呼び出してテストできるからです。また、マクロに依存したくない開発者向けのAPIを設計するのにも役立つでしょう。

defmodule MyModule do
  defmacro my_macro(a, b, c) do
    quote do
      # マクロに書くのは最小限に
      # その他の処理はすべて関数に
      MyModule.do_this_that_and_that(unquote(a), unquote(b), unquote(c))
    end
  end

  def do_this_that_and_that(a, b, c) do
    do_this(a)
    ...
    do_that(b)
    ...
    and_that(c)
  end
end

React入門 02: ライブラリMarkedでMarkdownの機能を加える

gumi TECH — Mon, 09 Dec 2019 12:52:39 +0000

「React入門 01: コンポーネントを組み立てる」(以下「React入門 01」)では、簡単なコンポーネントを組み合わせて、シンプルなSPAのページをつくりました。今回は、Reactで差し込む要素のテキストを、Markdownで書いてみます。MarkdownのテキストをHTMLの記述に変えるために使うのは、JavaScriptライブラリMarkedです。また、Reactで生のHTMLコードを差し込む場合の特別な仕組みについてもご説明します。

Markdown記法とMarkedのインストール

「Markdown」は、テキストの書式を定める簡易な記法です。HTMLコードよりも簡単な書き方で、文字や段落の表記が整えられます。JavaScriptライブラリMarkedは、npmでReactアプリケーションのディレクトリにつぎのようにインストールします。



npm install marked --save

`marked()`関数でMarkdownをHTMLの記述に変える

「React入門 01」で書いたJavaScriptコードに手を加えてゆきましょう。まず、src/components/CommentList.jsのテキストにつぎのようにMarkdown記法を加えます。*(アスタリスク)と_(アンダースコア)は同じ働きです。それを確かめるために、あえて両方用いました。記号ひとつで文字を挟めば強調・斜体(<em>)、ふたつなら強い重要性・太字(<strong>)になります。



const CommentList = () => {
  return (
    <div className="CommentList">
      <Comment author="ヘンリー・キッシンジャー">
      チャンスは__貯金__できない。
      </Comment>
      <Comment author="マーク・トウェイン">
      禁煙なんてたやすい。私は*何千回*もやった。
      </Comment>
    </div>
  );
};

テキストは子コンポーネント(src/components/Comment.js)が受け取りますので、MarkdownテキストをHTMLの記述に変換するコードは、項目のコンポーネント(Comment)に書き加えます。Markedライブラリからimportするのは関数marked()です。引数に渡したMarkdownのテキストをHTMLの記述にして返します。なお、引数は文字列でなければならないので、childrenで得た子要素はtoString()メソッドで文字列にしておきましょう。

ところが、JavaScriptコードをつぎのように書き替えて、marked()関数の戻り値をそのまま差し込むと、タグがテキストとして示されてしまいます(図001)。



import marked from 'marked';

const Comment = (props) => {
  return (
    <div className="Comment">

      {marked(props.children.toString())}
    </div>
  );
};

図001■タグがテキストとして表示される

`dangerouslySetInnerHTML`によりHTMLのコードを差し込む

生のHTMLコードが差し込めてしまうと、「クロスサイトスクリプティング」(XSS)による攻撃を受けるかもしれません(「クロスサイトスクリプティング対策ホンキのキホン」参照)。そのため、ReactはHTMLのタグは、そのままでは加えられないようにしたのです。テキストをHTMLとして差し込むためには、dangerouslySetInnerHTMLプロパティを用いなければなりません(「ReactのdangerouslySetInnerHTML使ってみた」参照)。与えるのはオブジェクトで、プロパティ__htmlにHTMLコードを値として定めます。

もっとも、dangerouslySetInnerHTMLプロパティにオブジェクトを直に与えるのは安全といえません。別に定めたメソッド(rawMarkup())を呼び出し、その本体でHTMLコードをつくって返すのがよいでしょう。そこで、コンポーネント(Comment)はさらにつぎのように書き替えます。プロパティに与えるメソッドの呼び出しは、波かっこ{}でくくってください。こうすれば、コンポーネントの要素にはメソッドから返されたコードが、HTMLとして描かれるはずです(図002)。



const Comment = (props) => {
  return (
    <div className="Comment">

      {/* {marked(props.children.toString())} */}
      <span dangerouslySetInnerHTML={rawMarkup(props.children.toString())} />
    </div>
  );
};

const rawMarkup = (markup) => {
  const rawMarkup = marked(markup);
  return { __html: rawMarkup };
};

図002■MarkdownテキストがHTMLとして描かれる

書き改めたふたつのコンポーネントのJavaScriptコードは、それぞれ以下のコード001と002にまとめました。

コード001■`src/components/CommentList.js`



import React from 'react';
import Comment from './Comment';

const CommentList = () => {
  return (
    <div className="CommentList">
      <Comment author="ヘンリー・キッシンジャー">
      チャンスは__貯金__できない。
      </Comment>
      <Comment author="マーク・トウェイン">
      禁煙なんてたやすい。私は*何千回*もやった。
      </Comment>
    </div>
  );
};

export default CommentList;

コード002■`src/components/Comment.js`



import React from 'react';
import marked from 'marked';

const Comment = (props) => {
  return (
    <div className="Comment">
      <h2 className="CommentAuthor">
      {props.author}
      </h2>
      <span dangerouslySetInnerHTML={rawMarkup(props.children.toString())} />
    </div>
  );
};

const rawMarkup = (markup) => {
  const rawMarkup = marked(markup);
  return { __html: rawMarkup };
};

export default Comment;

Elixirメタプログラミング 01: 内部表現ー quote/2とunquote/1

gumi TECH — Tue, 02 Jul 2019 12:18:13 +0000

本稿はElixir公式サイトの許諾を得て「Quote and unquote」の解説にもとづき、加筆補正を加えて、Elixirで使えるメタプログラミング技術のうち内部表現の扱いについてご説明します。Elixirプログラムを独自のデータ構造で表す機能は、メタプログラミングの基本です。そのデータ構造は内部表現(quoted expression)と呼ばれます。

quote/2による式の表現

Elixirのプログラムで式は、3要素のタプルで組み立てられます。式をタプルで返すのがマクロquote/2です。たとえば、関数sum(1, 2, 3)の呼び出しは、つぎのタプルで表されます。

iex> quote do: sum(1, 2, 3)
{:sum, [], [1, 2, 3]}

タプルの第1要素は関数名、第2要素がメタデータを含むリスト、そして第3要素には引数がリストで示されます。

関数だけでなく、演算子も3要素のタプルで表せます。

iex> quote do: 1 + 2
{:+, [context: Elixir, import: Kernel], [1, 2]}

マップも同じく3要素のタプルになります。

iex> quote do: %{1 => 2}
{:%{}, [], [{1, 2}]}

さらに、変数の宣言もタプルで示されます。ただし、第3要素はアトムです。

iex> quote do: x
{:x, [], Elixir}

より複雑な式も3要素タプルの組み合わせで表せます。そのとき、タプルが入れ子のツリー構造になることも少なくありません。たとえば、変数に値を代入したときです。

iex> quote do: x = 1
{:=, [], [{:x, [], Elixir}, 1]}

多くの言語ではこのような表現を抽象構文木(AST)と呼びます。Elixirの用語では内部表現(quoted expression)です。

iex> quoted = quote do: sum(1, 2 + 3, 4)
{:sum, [], [1, {:+, [context: Elixir, import: Kernel], [2, 3]}, 4]}

内部表現をもとのコードの文字列表現にしたい場合もあるでしょう。そのときには、Macro.to_string/2をお使いください(第2引数は関数でデフォルト値がfn _ast, string -> string end)。

iex> Macro.to_string(quoted)
"sum(1, 2 + 3, 4)"

quote/2から返されるタプルの3要素は、つぎのような形式です。

{atom | tuple, list, list | atom}

第1要素: アトムまたは3要素のタプル
第2要素: メタデータを納めたキーワードリスト
- たとえば、数値やコンテキスト
第3要素: 呼び出された関数の引数リストまたはアトム
- アトムの場合タプルは変数を意味する

つぎの5つのElixirリテラルは、quote/2の引数に渡したとき、タプルでなく値がそのまま返されます。

リテラル	例
アトム	:sum
数値	1.0
リスト	[1, 2]
文字列	"string"
2要素のタプル	{key, value}

ほとんどのElixirのコードは、内部表現として表すことができます。たとえば、式のツリー構造が組み合わさった例です。

iex> quote do: String.upcase("foo") 
{{:., [], [{:__aliases__, [alias: false], [:String]}, :upcase]}, [], ["foo"]}

if/2マクロの構文は、do/endブロックを使わずに、ひとつの式で表せます。この場合、内部表現はつぎのとおりです。

iex> quote do: if(true, do: :this, else: :that)
{:if, [context: Elixir, import: Kernel], [true, [do: :this, else: :that]]}

do/endブロックを使った場合も、内部表現は変わりません。

iex> quote do
...>   if true do
...>     :this
...>   else
...>     :that
...>   end
...> end
{:if, [context: Elixir, import: Kernel], [true, [do: :this, else: :that]]}

unquote/1による式の値の取り出し

quote/2が返す内部表現は、ひとまとまりのコードを表します。たとえば、値が納められた変数を用いたとき、内部表現に示されるのは識別子です。

iex> number = 13
13
iex> Macro.to_string(quote do: 11 + number)
"11 + number"

しかし、場合によっては変数値を確かめたい場合もあるでしょう。値を取り出して式に差し込むときに使うのは、unquote/1です。なお、このマクロはquote/2とともに用いなければなりません。

iex> Macro.to_string(quote do: 11 + unquote(number))
"11 + 13"

関数に変数を渡して呼び出すと、内部表現の中に変数が入れ子のタプルで示されます。

iex> quote do
...>   sum(1, number, 3)
...> end
{:sum, [], [1, {:number, [], Elixir}, 3]}

この場合も、変数をunquote/1に渡せば、変数値を取り出して内部表現に差し込めるのです。

iex> quote do
...>   sum(1, unquote(number), 3)
...> end
{:sum, [], [1, 13, 3]}

また、アトムをunquote/1に渡して、名前をつけた関数が表せます。

iex> func = quote do: unquote(:hello)(:world)
{:hello, [], [:world]}
iex> Macro.to_string(func)
"hello(:world)"

リスト内に別のリストの値を加えて、内部表現にしたいこともあるでしょう。この場合、unquote/1で差し込んだリストは、入れ子として示されます。

iex> inner = [3, 4, 5]
[3, 4, 5]
iex> Macro.to_string(quote do: [1, 2, unquote(inner), 6])
"[1, 2, [3, 4, 5], 6]"

リストから要素を取り出して内部表現に加えたいとき用いるのが、unquote_splicing/1です。

iex> Macro.to_string(quote do: [1, 2, unquote_splicing(inner), 6])
"[1, 2, 3, 4, 5, 6]"

このマクロは、リストだけでなく関数の引数としてリスト要素を加える場合にも使えます。

iex> Macro.to_string(quote do: sum(1, 2, unquote_splicing(inner), 6))
"sum(1, 2, 3, 4, 5, 6)"

unquote/1とunquote_splicing/1は、マクロを扱うときにとても役立ちます。マクロを書く開発者が、ひとまとまりのコードを受け取って、そこにまた別のコードが差し込めるからです。コードを変換したり、記述して、コンパイル時にコードを生成するために用いられます。

Macro.escape/2によるエスケープ

内部表現は、3要素のタプルを基本とします。たとえば、マップはそのままでは内部表現として使えません。4要素以上のタプルも同じです。そうした値は、内部表現に変えなければならないのです。

iex> quote do: %{1 => 2}
{:%{}, [], [{1, 2}]}

Macro.escape/2を用いても内部表現は得られます。

iex(23)> Macro.escape(%{1 => 2})
{:%{}, [], [{1, 2}]}

また、Macro.escape/2を使えば、変数から取り出した値が内部表現にできるのです。

iex> map = %{hello: :world}
%{hello: :world}
iex> quote do: map
{:map, [], Elixir}
iex> quote do: unquote(map)
%{hello: :world}
iex> Macro.escape(map)
{:%{}, [], [hello: :world]}

マクロは内部表現を受け取り、内部表現を返さなければなりません。しかし、マクロの実行時に値を扱わなければならないことがあります。そのとき、値と内部表現はよく区別してください。Elixirの標準の値(リストやマップ、プロセス、参照など)と内部表現は分けて扱うことが大切なのです。

整数やアトム、および文字列は、その値を表す内部表現があります。そのほかに、たとえばマップは内部表現に変換しなければなりません。あるいは、関数や参照は値を内部表現にはできないのです。quote/2やunquote/1などについて詳しくは「Kernel.SpecialForms」、またMacro.escape/1と関連する関数は「Macro」モジュールをご参照ください。

React入門 01: コンポーネントを組み立てる

gumi TECH — Tue, 25 Jun 2019 01:42:03 +0000

ReactはFacebook社により開発が進められている、もっとも注目度の高いJavaScriptフレームワークのひとつです。DOM(Document Object Model)の要素をデータと関連づけて(データバインディング)、データの変化に応じてページを動的に構成します。

そして、アプリケーションの機能は小分けして、それぞれのデータの処理とテンプレートをまとめたものがコンポーネントです。小さなコンポーネントを組み合わせて、ひとつのシステムがつくられます。コードはコンポーネントごとに確かめればよいので、読みやすく、メンテナンスもしやすくなるのです。

ただ、なじみの少ない構文の知識や準備が求められるため、初めての方には少し始めにくいかもしれません。本稿では、簡単なコンポーネントを組み合わせて、シンプルなシングルページアプリケーション(SPA)をつくってみます。

Create React Appでアプリケーションのひな形をつくる

「Create React App」は、シングルページアプリケーション(SPA)のひな形をつくってくれる開発環境です。このひな形に手を加えて目的のアプリケーションにします。

まずは、Create React Appのインストールです。予めNode.js(npm)が入っていなければなりません。コマンドラインツールからnpmでつぎのコマンドを打ち込んでください。

npm install -g create-react-app

npx create-react-appまたはcreate-react-appコマンドにつづけてアプリケーション名を入力すると、その名前でフォルダとアプリケーションのひな形がつくられます。

npx create-react-app react-comment-box

ひな形がつくられたら、アプリケーションのディレクトリに移って、npm startとコマンドを打てば、ローカルサーバーでひな形のページが開きます(図001)。

cd react-comment-box
npm start

図001■Reactのひな形アプリケーションページ

アプリケーションのディレクトリには、つぎのようなファイルがつくられます(図002)。この中で手を加えるのは、src/App.jsとsrc/App.cssです。

図002■アプリケーションのディレクトリにつくられたファイル

アプリケーションに子コンポーネントを加える

src/App.jsは大もとになるコンポーネントです。ひな形アプリケーションには、ほかのコンポーネントはまだありません。つぎのJavaScriptコードの抜書きが、軸となる枠組みです。まず、スタイルシートのファイル(App.css)をimportしています。コンポーネント(App)を定めるのは、関数です(「関数コンポーネントとクラスコンポーネント」参照)。そして、JSXで定められたDOMのテンプレートを返さなければなりません(JSX の導入」参照)。

import React from 'react';
import './App.css';

function App() {
  return (
    <div className="App"><!-- JSXのテンプレート -->
      <!-- 中略 -->
    </div>
  );
}

export default App;

JSXのテンプレートは、基本的にはHTML(XML)の書き方に添います。ただし、class属性はclassNameに替えなければなりません。classがECMAScript 2015の予約語になっているためでしょう。また、テンプレートは必ずひとつのルート要素にまとめてください。

src/App.jsのコードはつぎのように書き替えます。importに加えたのは、このあとにつくる子コンポーネント(CommentList)です。これを、テンプレートにタグとして加えています。なお、ファイルsrc/logo.svgは要らなくなりましたので、フォルダから削って構いません。

import React from 'react';
import CommentList from './components/CommentList';
import './App.css';

function App() {
  return (
    <div className="App">
      <h1>コメント</h1>
      <CommentList />
    </div>
  );
}

export default App;

子コンポーネントはsrc/components/CommentList.jsとして、つぎのように定めます。枠組みの記述は同じで、コンポーネントをアロー関数式で定めたのとテンプレートにテキストの要素が加わっただけです。

import React from 'react';

const CommentList = () => {
  return (
    <div className="CommentList">
      <h2 className="CommentAuthor">
      ヘンリー・キッシンジャー
      </h2>
      チャンスは貯金できない。
    </div>
  );
};

export default CommentList;

CSSファイルsrc/App.cssは、つぎのコード001のように書き替えましょう。あとで使うクラスも、すでに加えてあります。ブラウザで読み込み直すと、ページが描き改められるでしょう。子コンポーネント(CommentList)のテキストが表示されるはずです(図003)。

コード001■`src/App.css`

h1 {
  border-bottom: 1px solid #ddd;
}
.App {
    margin-left: 20px;
    margin-right: 20px;
}
.CommentList {
  margin-bottom: 10px;
}
.CommentForm {
  margin-top: 20px;
}
.CommentForm input {
  font-size: 12px;
}
.Comment {
  margin-bottom: 10px;
  font-size: 16px;
}
.CommentAuthor {
  border-bottom: 1px solid #ddd;
  margin: 0;
}
.CommentText {
  display: flex;
  align-items: center;
}

図003■ページに子コンポーネントのテキストが表示される

さらにコンポーネントに切り出す

コンポーネントsrc/components/CommentList.jsのテンプレートに加えた<div>要素(className属性CommentList)は、複数リストにするつもりです。そのために、この部分は別のコンポーネント(Comment)に切り出しましょう。そして、<h2>要素に加えるテキストは、タグに属性(author)として与えます。この値は、子コンポーネントから取り出すことができるのです。

import Comment from './Comment';

const CommentList = () => {
  return (
    <div className="CommentList">
      {/* <h2 className="CommentAuthor">
      ヘンリー・キッシンジャー
      </h2>
      チャンスは貯金できない。 */}
      <Comment author="ヘンリー・キッシンジャー">チャンスは貯金できない。</Comment>
      <Comment author="マーク・トウェイン">禁煙なんてたやすい。私は何千回もやった。</Comment>
    </div>
  );
};

切り出す子コンポーネントsrc/components/Comment.jsの定めは、つぎのコード002のとおりです。親のテンプレートから与えられた値は、子コンポーネントの関数が引数(props)に受け取ります(「関数コンポーネントとクラスコンポーネント」参照)。属性値は属性名で、子要素はprops.childrenで、つぎのコード002のように波かっこ{}にくくって参照してください(「子要素の出力 (Containment)」参照)。{}の中はJavaScriptコードとして評価されます。

コード002■`src/components/Comment.js`

import React from 'react';

const Comment = (props) => {
  return (
    <div className="Comment">
      <h2 className="CommentAuthor">
      {props.author}
      </h2>
      {props.children}
    </div>
  );
};

export default Comment;

子コンポーネントをもうひとつ加える

子コンポーネント(CommentForm)をもうひとつ、大もとのアプリケーション(src/App.js)に加えましょう。

import CommentForm from './components/CommentForm';

function App() {
  return (
    <div className="App">

      <CommentForm />
    </div>
  );
}

src/components/CommentForm.jsに書くのは、つぎのコード003のとおりで、まだダミーの状態です。

コード003■`src/components/CommentForm.js`

import React from 'react';

const CommentForm = () => {
  return (
    <div className="CommentForm">
      CommentFormを表示
    </div>
  );
};

export default CommentForm;

これで、コンポーネントに切り分けたコメントがふた組と、あとから加えたコンポーネントのダミーのテキストがページに表示されます(図004)。

図004■ふた組みのコメントとダミーテキストがページに表示される

以下に、手直ししたsrc/App.js(コード004)とsrc/components/CommentList.js(コード005)をまとめて掲げます。

コード004■`src/App.js`

import React from 'react';
import CommentList from './components/CommentList';
import CommentForm from './components/CommentForm';
import './App.css';

function App() {
  return (
    <div className="App">
      <h1>コメント</h1>
      <CommentList />
      <CommentForm />
    </div>
  );
}

export default App;

コード005■`src/components/CommentList.js`

import React from 'react';
import Comment from './Comment';

const CommentList = () => {
  return (
    <div className="CommentList">
      <Comment author="ヘンリー・キッシンジャー">チャンスは貯金できない。</Comment>
      <Comment author="マーク・トウェイン">禁煙なんてたやすい。私は何千回もやった。</Comment>
    </div>
  );
};

export default CommentList;

MixとOTP 10: 分散処理のタスクと設定

gumi TECH — Tue, 11 Jun 2019 01:29:52 +0000

本稿はElixir公式サイトの許諾を得て「Distributed tasks and configuration」の解説にもとづき、加筆補正を加えて、タスクの分散処理とアプリケーションの設定についてご説明します。

今回は、kvアプリケーションにルーティングのレイヤーを加えます。リクエストをプロセス名にもとづいてノード間でやり取りできるようにするのです。ルーティングレイヤーは、つぎのような形式でルーティングテーブルを受け取ります。

[
  {?a..?m, :"foo@computer-name"},
  {?n..?z, :"bar@computer-name"}
]

ルータはプロセス名の最初のバイトをテーブルで確かめ、それにもとづいて適切なノードに配信します。たとえば、文字"a"で始まるプロセスは、ノードfoo@computer-nameに送られます。なお、?aは文字"a"のUnicodeコードポイントです(「Elixir入門 06: バイナリと文字列および文字リスト」「UTF-8とUnicode」参照)。

マッチングするエントリーがリクエストを評価しているノードに当たるときは、ルーティングはせず、そのノードが要求された操作を実行します。マッチングするエントリーが別のノードを示すときは、要求をそのノードに渡します。ノードは自身のルーティングテーブル(はじめのノードとは異なるでしょう)を見て、それに応じて動作します。マッチングするエントリーがなければエラーです。

ルーティングテーブルで見つかったノードに、要求された操作を直に実行はさせません。ルーティングの要求をノードに渡して処理するのです。上記のような単純なルーティングテーブルであれば、すべてのノードで共有してもよいでしょう。けれど、ルーティングの要求を渡すかたちにすれば、アプリケーションが拡大したとき、ルーティングテーブルが簡単に小さく分けられます。ある程度大きくなったら、foo@computer-nameはプロセスに要求をルーティングさせる役割だけを担い、要求を扱うプロセスが他のノードに送られることになるでしょう。そうすれば、bar@computer-nameは変更については知らずに済みます。

本稿では、ひとつのマシンでふたつのノードを使います。同じネットワークで、複数のマシンを使うことも可能です。その場合には準備が要ります。第1に、すべてのマシンにファイル~/.erlang.cookieがあり、その値はまったく同じでなければなりません。第2に、epmdがブロックされていないポートで動いていることを確かめます(epmd -dでデバッグ情報が得られます)。さらに詳しくは、「Learn You Some Erlang for Great Good!」の「Distribunomicon」の章をお読みください。

分散処理のコードを書く

Elixirには、ノードに接続して互いに情報をやり取りする機能が備わっています。実際、分散環境でプロセスやメッセージの送受信には同じ考え方が用いられます。Elixirのプロセスは、場所を問わないからです。つまり、メッセージを送るとき、受け手のプロセスが同じノードかどうかは問いません。VMはどちらであってもメッセージを届けます。

分散処理のコードを実行するには、VMに名前をつけて起動しなければなりません。名前は短く(同じネットワークの場合)も長く(完全なコンピュータアドレス)もできます。IExをつぎのように開始してください。

$ iex --sname foo

プロンプトの表示が少し変わります。ノード名のあとに@つきで示されるのはコンピュータ名です。

Erlang/OTP 21 [erts-10.0.5] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe] [dtrace]

Interactive Elixir (1.7.3) - press Ctrl+C to exit (type h() ENTER for help)
iex(foo@computer-name)1>

シェルでモジュールをつぎのように定めます。

iex> defmodule Hello do
...>   def world, do: IO.puts "hello world"
...> end
{:module, Hello,
 <<70, 79, 82, 49, 0, 0, 4, 60, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 140,
   0, 0, 0, 15, 12, 69, 108, 105, 120, 105, 114, 46, 72, 101, 108, 108, 111, 8,
   95, 95, 105, 110, 102, 111, 95, 95, 7, ...>>, {:world, 0}}

同じネットワークの別のコンピュータにErlangとElixirがインストールされていれば、別のシェルを起動できます。そうでない場合は、IExのセッションを別のターミナルから開けばよいでしょう。どちらでも、つぎのように短い別の名前をつけます。

$ iex --sname bar

新たな別セッションからは、先ほど定めたモジュールの関数は呼び出せません。

iex(bar@computer-name)> Hello.world
** (UndefinedFunctionError) function Hello.world/0 is undefined (module Hello is not available)
    Hello.world()

けれど、Node.spawn_link/2を用いて、bar@computer-nameからfoo@computer-nameに新たなプロセスがつくれます(ノード名の中のcomputer-nameはプロンプトに示された名前に置き替えてください)。

iex(bar@computer-name)> Node.spawn_link :"foo@computer-name", fn -> Hello.world end             
hello world
#PID<10577.117.0>

Elixirは別ノードにプロセスをつくり、そのPIDが返されました。そして、コードは関数が定められている別ノードで実行され、関数は呼び出されたのです。関数の出力が示されたのは、現在のノードで、別ノードではないことにご注目ください。つまり、メッセージは別ノードから送り返され、それが現ノードに出力されたということです。これは別ノードにつくられたプロセスが、現ノードと同じグループリーダーをもつからです(「Elixir入門 12: 入出力とファイルシステム」「プロセスとグループリーダー」参照)。

Node.spawn_link/2が返すPIDを使えば、メッセージを送って、さらに受け取れます。

iex(bar@computer-name)> pid = Node.spawn_link :"foo@computer-name", fn ->
...(bar@computer-name)>   receive do
...(bar@computer-name)>     {:ping, client} -> send client, :pong
...(bar@computer-name)>   end
...(bar@computer-name)> end
#PID<10577.119.0>
iex(bar@computer-name)> send pid, {:ping, self()}
{:ping, #PID<0.106.0>}
iex(bar@computer-name)> flush()
:pong
:ok

分散処理を行うには、処理のたびにNode.spawn_link/2でリモートノードにプロセスを生成すればよいということがわかりました。けれども、監視ツリーの外にプロセスをつくるのは、できるだけ避けるべきです。今回の実装でNode.spawn_link/2を用いるより望ましいやり方は3つ考えられます。

Erlangの:rpcモジュールを使うと、リモートノードの関数が実行できます。たとえば、シェルから:rpc.call(:"foo@computer-name", Hello, :world, [])とすれば、別ノードの関数Hello.world/0が呼び出せます。
GenServerのAPIにより他のノードでサーバーを起ち上げれば、要求が送れます。たとえば、GenServer.call({name, node}, arg)によりリモートノードのサーバーが呼び出せます。第1引数はリモートプロセスのPIDにしても構いません。
Taskを用いて、ローカルとリモートの両ノードに生成することもできます(「MixとOTP 08: タスクとgen_tcp」参照)。

:rpcとGenServerを使うと、要求はひとつのサーバーにシリアライズされます。他方、Taskはリモートノードで効率的に非同期処理されます。シリアライズされるポイントは、スーパーバイザーによる生成だけです。今回のルーティングレイヤーでは、Taskを用いることにします。けれど、他のやり方でも問題はありません。

async/await

これまでは、開始したTaskは単独で実行しました。また、戻り値も確かめていません。しかし、タスクで値を処理し、あとで結果を見ると役立つ場合があります。そのために、Taskに備わっているのがasync/awaitバターンです。

async/awaitは、値を同時に処理するシンプルな仕組みです。それだけでなく、async/awaitを同じTask.Supervisorで使うこともできます(「MixとOTP 08: タスクとgen_tcp」「タスクスーパーバイザー」参照)。Task.Supervisor.start_child/3の替わりにTask.Supervisor.async/3を呼び出して、あとからTask.await/2で結果を読み取るだけです。

task = Task.async(fn -> compute_something_expensive end)
res  = compute_something_else()
res + Task.await(task)

タスクの分散処理

タスクの分散処理は、タスクの監視と基本的に変わりません。違いは、スーパーバイザーにタスクをつくるとき、ノード名を渡すことです。:kvアプリケーションのlib/kv/supervisor.exを開いて、init/1のchildrenリストの最後につぎのようにTask.Supervisorを加えてください。

def init(:ok) do
  children = [
    {DynamicSupervisor, name: KV.BucketSupervisor, strategy: :one_for_one},
    {KV.Registry, name: KV.Registry},
    {Task.Supervisor, name: KV.RouterTasks}  # 追加
  ]
  Supervisor.init(children, strategy: :one_for_all)
end

改めて、名前つきのノードを起動します。ただし、:kvアプリケーションのディレクトリから開いてください。

$ cd apps/kv
$ iex --sname foo -S mix

もうひとつのノードについても同様です。

$ iex --sname bar -S mix

これで、スーパーバイザーによりひとつのノードから、もうひとつのノードに直接タスクがつくれます。つぎの分散処理タスクは、タスクが実行されているノード名を取得します。

iex(bar@computer-name)> task = Task.Supervisor.async {KV.RouterTasks, :"foo@computer-name"}, fn ->
...(bar@computer-name)>   {:ok, node()}
...(bar@computer-name)> end
%Task{
  owner: #PID<0.140.0>,
  pid: #PID<15195.164.0>,
  ref: #Reference<0.1065362951.4240965635.67142>
}
iex(bar@computer-name)> Task.await(task)
{:ok, :"foo@computer-name"}

上のコードではTask.Supervisor.async/3に無名関数を与えました。けれど、分散処理ではモジュールと関数および引数を明示的に与える方が望ましいです。無名関数では、ターゲットノードが呼び出しもととまったく同じコードバージョンをもたなければなりません。Task.Supervisor.async/4を用いれば、引数に渡したモジュールにアリティの合致する関数があればよいので、より堅牢といえます。

iex(bar@computer-name)> task = Task.Supervisor.async {KV.RouterTasks, :"foo@computer-name"}, Kernel, :node, []   
%Task{
  owner: #PID<0.140.0>,
  pid: #PID<15195.165.0>,
  ref: #Reference<0.1065362951.4240965635.67197>
}
iex(bar@computer-name)> Task.await(task)
:"foo@computer-name"

ルーティングレイヤー

ファイルlib/kv/router.exにルーターのモジュールKV.Routerをつぎのように定めます。なお、computer-nameはローカルマシン名に書き替えてください。

defmodule KV.Router do
  @doc """
  与えられた`mod`の`fun`に`args`が渡された要求を
  プロセス`bucket`にもとづいて適切なノードに送る。
  """
  def route(bucket, mod, fun, args) do
    # バイナリの最初のバイトを得る
    first = :binary.first(bucket)

    # table()からエントリーを探してなければエラー
    entry =
      Enum.find(table(), fn {enum, _node} ->
        first in enum
      end) || no_entry_error(bucket)

    # エントリーが現ノードの場合
    if elem(entry, 1) == node() do
      apply(mod, fun, args)
    else
      {KV.RouterTasks, elem(entry, 1)}
      |> Task.Supervisor.async(KV.Router, :route, [bucket, mod, fun, args])
      |> Task.await()
    end
  end

  defp no_entry_error(bucket) do
    raise "could not find entry for #{inspect bucket} in table #{inspect table()}"
  end

  @doc """
  ルーティングテーブル
  """
  def table do
    # computer-nameはローカルマシン名に置き替える
    [{?a..?m, :"foo@computer-name"}, {?n..?z, :"bar@computer-name"}]
  end
end

ルーターの動作をテストで確かめましょう。test/kv/router_test.exsに、つぎのふたつのテストを書きます。

defmodule KV.RouterTest do
  use ExUnit.Case, async: true

  test "route requests across nodes" do
    assert KV.Router.route("hello", Kernel, :node, []) ==
           :"foo@computer-name"
    assert KV.Router.route("world", Kernel, :node, []) ==
           :"bar@computer-name"
  end

  test "raises on unknown entries" do
    assert_raise RuntimeError, ~r/could not find entry/, fn ->
      KV.Router.route(<<0>>, Kernel, :node, [])
    end
  end
end

はじめのテストでは、Kernel.node/0の呼び出しにより、実行ノード名を得ます。プロセス名として“hello”と“world”を渡しているので、ルーティングテーブルからそれぞれfoo@computer-nameとbar@computer-nameが返されるでしょう。

ふたつ目のテストは、知らないエントリに対してエラーが起こるかどうか確かめます。

はじめのテストを走らせるには、ノードがふたつ実行されていなければなりません。ディレクトリapps/kvに移って、テストに使われるもうひとつのノードをつぎのように起動してください。

$ iex --sname bar -S mix

そして、もとのノードから、つぎのようにテストを実行すると、正しくとおるはずです。

$ elixir --sname foo -S mix test

テストのフィルタとタグ

前項のテストはとおりました。けれど、テストの構成はもっと込み入ってくるでしょう。実際今も、mix testで試すと、失敗してしまいます。他のノードへの接続を求めるテストが含まれているからです。

1) test route requests across nodes (KV.RouterTest)
    test/kv/router_test.exs:4
    ** (exit) exited in: GenServer.call({KV.RouterTasks, :"foo@computer-name"}, {:start_task, [#PID<0.169.0>, :monitor, {:nonode@nohost, #PID<0.169.0>}, {KV.Router,:route, ["hello", Kernel, :node, []]}], :temporary, nil}, :infinity)
        ** (EXIT) no connection to foo@computer-name
    code: assert KV.Router.route("hello", Kernel, :node, []) ==
    stacktrace:
      (elixir) lib/gen_server.ex:924: GenServer.call/3
      (elixir) lib/task/supervisor.ex:377: Task.Supervisor.async/6
      (kv) lib/kv/router.ex:21: KV.Router.route/4
      test/kv/router_test.exs:5: (test)

幸いにも、ExUnitにはテストにタグづけする機能が備わっています。特定のコールバックだけ実行したり、タグにもとづいてフィルタリングすることもできるのです。なお、:capture_logのように予めExUnitに定められているタグもあります(「MixとOTP 09: DocTestとwithのパターンマッチング」「コマンドを実行する」参照)。

そこで、test/kv/router_test.exsにつぎのようにタグづけしましょう。@tag :distributedは@tag distributed: trueと書くのと同じです。

@tag :distributed  # 追加
test "route requests across nodes" do
  assert KV.Router.route("hello", Kernel, :node, []) ==
          :"foo@computer-name"
  assert KV.Router.route("world", Kernel, :node, []) ==
          :"bar@computer-name"
end

テストに正しくタグづけしてあれば、ネットワークにノードがあるかどうかNode.alive?/0でテストのときに確かめればよいでしょう。なければ、分散処理のテストを省きます。そのために、:kvアプリケーション(apps/kv)のtest/test_helper.exsにつぎのように書き加えてください。

exclude =
  if Node.alive?, do: [], else: [distributed: true]  # 追加

# ExUnit.start()
ExUnit.start(exclude: exclude)

これで、mix testが失敗なく走るようになります。ExUnitが分散処理のテストひとつを省くからです。

$ mix test
Excluding tags: [distributed: true]

......

Finished in 2.0 seconds
7 tests, 0 failures, 1 excluded

ノードbar@computer-nameが使えるときは、つぎのようにテストすると分散処理も含めてとおるでしょう。

$ elixir --sname foo -S mix test
.......

Finished in 2.0 seconds
7 tests, 0 failures

mix testコマンドには、タグを動的に含めたり、除いたりすることができます。たとえば、mix test --include distributedと入力すれば、test/test_helper.exsの設定にかかわらず、分散処理のテストが含められるのです。あるいは、コマンドラインに--excludeを渡すと、特定のタグが除けます。さらに、つぎのように--onlyを用いて、特定タグのテストだけ実行することもできます。

$ elixir --sname foo -S mix test --only distributed
Including tags: [:distributed]
Excluding tags: [:test]

.

Finished in 0.06 seconds
7 tests, 0 failures, 6 excluded

フィルタについて詳しくは、ExUnit.Caseモジュールの「Filters」をお読みください。

アプリケーション環境と設定

ルーティングテーブルはKV.Routerにつぎのように直打ちしてありました。このテーブルを動的にしましょう。そうすれば、開発とテストあるいはプロダクションの設定だけでなく、異なるエントリで動いている異なるノードをルーティングテーブルに加えることもできるようになるのです。OTPにはまさにその機能があります。それがアプリケーション環境です。

def table do
  # computer-nameはローカルマシン名に置き替える
  [{?a..?m, :"foo@computer-name"}, {?n..?z, :"bar@computer-name"}]
end

環境はアプリケーションごとにあり、固有の設定がキーに与えられます。たとえば、ルーティングテーブルを:kvアプリケーション環境に納めることができます。これがデフォルト値となり、他のアプリケーションは必要に応じてテーブルが変えられるのです。

apps/kv/mix.exsを開いて、関数application/0の戻り値につぎのように書き加えてください。アプリケーションに与えたのはキー:envです。これがアプリケーションのデフォルト環境となります。エントリーがキー:routing_tableで、値は空のリストです。これで、アプリケーション環境は出荷時に空のテーブルとなります。使われるテーブルは、テストと開発の構成によって変わります。

def application do
  [
    extra_applications: [:logger],
    env: [routing_table: []],  # 追加
    mod: {KV, []}
  ]
end

アプリケーション環境をコードで使うには、KV.Router.table/0の定めをつぎのように書き替えてください。Application.fetch_env!/2は、:routing_tableは:kvの環境の中のエントリーを読み込みます。アプリケーション環境の操作について詳しくは、「Application behaviour」をご参照ください。

def table do
  # [{?a..?m, :"foo@computer-name"}, {?n..?z, :"bar@computer-name"}]
  Application.fetch_env!(:kv, :routing_table)
end

ルーティングテーブルが空になったので、分散処理のテストは失敗するはずです。改めてテストを実行して確かめましょう。

$ iex --sname bar -S mix

$ elixir --sname foo -S mix test --only distributed

1) test route requests across nodes (KV.RouterTest)
    test/kv/router_test.exs:5
    ** (RuntimeError) could not find entry for "hello" in table []
    code: assert KV.Router.route("hello", Kernel, :node, []) ==
    stacktrace:
      (kv) lib/kv/router.ex:27: KV.Router.no_entry_error/1
      (kv) lib/kv/router.ex:14: KV.Router.route/4
      test/kv/router_test.exs:6: (test)

アプリケーション環境のよいところは、現行のアプリケーションだけでなく、アプリケーション全体にも設定できることです。全体の設定は、config/config.exsで行います。たとえば、apps/kv/config/config.exsを開いて、つぎのコードを最後に加えてください。これは、IExのデフォルトプロンプトの定めです。

config :iex, default_prompt: ">>>"

$ iex -S mix
Erlang/OTP 21 [erts-10.0.5] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe] [dtrace]

Compiling 5 files (.ex)
Generated kv app
Interactive Elixir (1.7.3) - press Ctrl+C to exit (type h() ENTER for help)
>>>

同じように、apps/kv/config/config.exsファイルに:routing_tableをつぎのように定めることができます。

# computer-nameはローカルマシン名に置き替える
config :kv, :routing_table, [{?a..?m, :"foo@computer-name"}, {?n..?z, :"bar@computer-name"}]

改めてノードを起動して分散処理をテストすれば、今度はとおるはずです。

:kvアプリケーションはアンブレラプロジェクトの中のひとつでした。Elixir v1.2から、アンブレラアプリケーションはconfig/config.exsの設定を共有します。プロジェクトルートのconfig/config.exsのつぎの記述により、すべての子の設定が読み込まれるからです。

import_config "../apps/*/config/config.exs"

mix runコマンドは--configフラグを加えると、必要に応じた設定ファイルが与えられます。異なるノードを起動して、それぞれに異なる設定ができるのです(たとえば、ルーティングテーブルを変えるなど)。

アプリケーション設定のために組み込まれた機能により、アンブレラアプリケーションをデプロイするときにさまざまなやり方が考えられます。

アンブレラアプリケーションをノードにデプロイして、TCPサーバーとキー/値データ保存の両方に使う
:kv_serverアプリケーションをデプロイしてTCPサーバーにのみ使い、ルーティングテーブルには他のノードの指定のみさせる
:kvアプリケーションだけをデプロイして、ノードはデータ保存にのみ使う(TCPアクセスはしない)

今後アプリケーションが増えても、デプロイの粒度は同じくらいのレベルに保つことができます。プロダクションのとき、どのアプリケーションをどの設定にするか検討してください。

複数のリリースをビルドするときは、Distilleryのようなツールを使うことも考えられるでしょう。アプリケーションと設定を選んで、現行のErlangとElixirも含めてパッケージにできます。そうすれば、ターゲットシステムにランタイムがインストールされていなくても、アプリケーションがデプロイできるのです。

今回のようなキー/値データ保存の分散処理をプロダクションで使うときには、Riakがお勧めです。RiakもErlang VMで動作します。子プロセスは複製され、データを失うことが避けられます。ルーターの替わりにコンシステントハッシュ法を用いて、プロセスはノードにマップされるのです。このりアルゴリズムは、プロセスを保存するノードが新たに加わって、データを移行しなければならなくなっても、その量を抑えるのに役立ちたます。

MixとOTPもくじ

MixとOTP 09: DocTestとwithのパターンマッチング

gumi TECH — Tue, 28 May 2019 00:55:54 +0000

本稿はElixir公式サイトの許諾を得て「Doctests, patterns and with」の解説にもとづき、加筆補正を加えて、DocTestによるテストとwithを使ったパターンマッチングについてご説明します。

DocTest

Elixirサイトでは、ドキュメントは言語にとって重要な役割を果たす(first-class citizen)と述べています。たとえば、コマンドラインツールでmix helpと入力するとMixのコマンドが一覧できますし、IExコンソールではh Enumでモジュールの説明が見られます。

本稿では、コマンドの解析機能を実装します。そして、ドキュメントを加えて、DocTestにより最新状態であることを確かめましょう。このテストで、ドキュメントのコード例を正確に保つことができるのです。

lib/kv_server/command.exにコマンド解析の関数parse/1をつぎのように定めて、DocTestを実行してみましょう。DocTestのためにドキュメントのテキストに加えるコード例は、スペース4つのインデントにプロンプトiex>を添えて、そのあとに記述してください。コードが複数行にわたるときは、IExと同じく、...>が使えます。続く行に加えるのが期待される結果です。空白行か新たなiex>プロンプトで、コード例が区切られます。

defmodule KVServer.Command do
  @doc ~S"""
  与えられた`line`をコマンドとして解析する。

  ## 例

    iex> KVServer.Command.parse("CREATE shopping\r\n")
    {:ok, {:create, "shopping"}}

  """
  def parse(_line) do
    :not_implemented  # 未実装
  end
end

ドキュメントのテキストを@doc ~S"""で始めました。大文字シギル~Sを用いたのは、テストのとき\r\nが改行と復帰に変換されてしまわないようにです。

DocTestを実行するファイルは、test/kv_server/command_test.exsにつくります。そして、KVServer.CommandTestモジュールからdoctest KVServer.Commandを呼び出すのです。

defmodule KVServer.CommandTest do
  use ExUnit.Case, async: true
  doctest KVServer.Command
end

mix testを行うと、DocTestによるつぎのようなエラーが示されます。parse/1関数がドキュメントのとおりに実装されていないからです。

1) doctest KVServer.Command.parse/1 (1) (KVServer.CommandTest)
    test/kv_server/command_test.exs:3
    Doctest failed
    code:  KVServer.Command.parse("CREATE shopping\r\n") === {:ok, {:create, "shopping"}}
    left:  :not_implemented
    right: {:ok, {:create, "shopping"}}
    stacktrace:
      lib/kv_server/command.ex:7: KVServer.Command (module)

DocTestをとおすには、parse/1関数をつぎのように実装すればよいでしょう。1行のテキストをホワイトスペースで区切ったリストに変えて、コマンドとマッチングさせています。String.split/1は、連続したホワイトスペースはひとつの区切り文字列として扱います。

# def parse(_line) do
def parse(line) do
  # :not_implemented
  case String.split(line) do
    ["CREATE", bucket] -> {:ok, {:create, bucket}}
  end
end

DocTestのコード例をさらに増やしましょう。新たなコマンドとエラーになる記述を、つぎのように書き加えます。

@doc ~S"""
与えられた`line`をコマンドとして解析する。

## 例

  iex> KVServer.Command.parse("CREATE shopping\r\n")
  {:ok, {:create, "shopping"}}

  iex> KVServer.Command.parse("CREATE  shopping  \r\n")
  {:ok, {:create, "shopping"}}

  iex> KVServer.Command.parse("PUT shopping milk 1\r\n")
  {:ok, {:put, "shopping", "milk", "1"}}

  iex> KVServer.Command.parse("GET shopping milk\r\n")
  {:ok, {:get, "shopping", "milk"}}

  iex> KVServer.Command.parse("DELETE shopping eggs\r\n")
  {:ok, {:delete, "shopping", "eggs"}}

定められていないコマンドや数の合わない引数はエラーになる。

  iex> KVServer.Command.parse("UNKNOWN shopping eggs\r\n")
  {:error, :unknown_command}

  iex> KVServer.Command.parse("GET shopping\r\n")
  {:error, :unknown_command}

"""

これらのドキュメントの例に応じてparse/1関数を実装したのが、つぎのコードです。コマンド名と引数の数をマッチングさせているため、いくつもの条件判定の構文なしにすっきりとコマンドが解析できています。

def parse(line) do
  case String.split(line) do
    ["CREATE", bucket] -> {:ok, {:create, bucket}}
    ["GET", bucket, key] -> {:ok, {:get, bucket, key}}
    ["PUT", bucket, key, value] -> {:ok, {:put, bucket, key, value}}
    ["DELETE", bucket, key] -> {:ok, {:delete, bucket, key}}
    _ -> {:error, :unknown_command}
    end
end

DocTestは7つ数えられています。これはコード例ごとにテストが行われたからです。

==> kv_server
.......

Finished in 0.06 seconds
7 doctests, 0 failures

もしコード例の間に空白行を入れないと、ExUnitはひとつのテストとみなしてコンパイルします。

iex> KVServer.Command.parse("UNKNOWN shopping eggs\r\n")
{:error, :unknown_command}
iex> KVServer.Command.parse("GET shopping\r\n")
{:error, :unknown_command}

DocTestは名前が示すとおり、ドキュメントが主でテストは従の位置づけです。テストに替わる機能ではなく、ドキュメントを最新に保つことが目的とされています。DocTestについて詳しくは「ExUnit.DocTest」をお読みください。

with

コマンドの解析はできました。KVServer.Commandモジュールには、実行のためのrun/1関数を仮置きしておきます。

@doc """
与えられたコマンドを実行する。
"""
def run(_command) do
  {:ok, "OK\r\n"}
end

そして、実行するロジックの実装です。lib/kv_server.exのKVServerモジュールを書き替えましょう。まずは、serve/1関数です。case/2でコマンドの解析や実行の結果に応じて処理を進めます。

defp serve(socket) do
  # socket
  # |> read_line()
  # |> write_line(socket)
  msg =
    case read_line(socket) do
      {:ok, data} ->
        case KVServer.Command.parse(data) do
          {:ok, command} ->
            KVServer.Command.run(command)
          {:error, _} = err ->
            err
        end
      {:error, _} = err ->
        err
    end

  write_line(socket, msg)
  serve(socket)
end

つぎに、read_line/1関数です。

defp read_line(socket) do
  # {:ok, data} = 
  :gen_tcp.recv(socket, 0)
  # data
end

そして、write_line関数はコマンドによりやるべきことが変わります。

# defp write_line(line, socket) do
defp write_line(socket, {:ok, text}) do
  # :gen_tcp.send(socket, line)
  :gen_tcp.send(socket, text)
end

defp write_line(socket, {:error, :unknown_command}) do
  # 予め定めたエラーはクライアントに書き込む。
  :gen_tcp.send(socket, "UNKNOWN COMMAND\r\n")
end

defp write_line(_socket, {:error, :closed}) do
  # 接続が閉じたらきちんと終了する。
  exit(:shutdown)
end

defp write_line(socket, {:error, error}) do
  # 不明なエラーはクライアントに書き込んで終了する。
  :gen_tcp.send(socket, "ERROR\r\n")
  exit(error)
end

書いたコードはまだ大枠だけです。けれども、サーバーを起ち上げて、動きを確かめることはできます。

$ mix run --no-halt

00:00:00.000 [info]  Accepting connections on port 4040

今のところ、コマンドと引数の数が正しければ「OK」、そうでないときは「UNKNOWN COMMAND」が示されるはずです。

$ telnet 127.0.0.1 4040
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
CREATE shopping
OK
HELLO
UNKNOWN COMMAND

ここまでの動きは正しくできています。けれど、serve/1関数がcase/2の入れ子になっていて、見やすくありません。このようなときに使えるのが、Elixir v1.2から備わったwith構文です。条件でなく、パターンマッチングにより処理が進められます。

withは<-の右辺が返す式の値を、左辺のパターンとマッチングさせます。そして、合致したらつぎの式に進むのです。合致しなかったときには、その値がそのまま返されます。case/2の条件をwithの式で組み立て直したのが、つぎのコードです。{:ok, x}と合致しない式があれば、ただちにwith構文を抜けて合致しなかった値が返されます。詳しくは、ドキュメントのwith/1の項をお読みください。

defp serve(socket) do
  msg =
    # case read_line(socket) do
    #   {:ok, data} ->
    #     case KVServer.Command.parse(data) do
    #       {:ok, command} ->
    #         KVServer.Command.run(command)
    #       {:error, _} = err ->
    #         err
    #     end
    #   {:error, _} = err ->
    #     err
    # end
    with {:ok, data} <- read_line(socket),
         {:ok, command} <- KVServer.Command.parse(data),
         do: KVServer.Command.run(command)

  write_line(socket, msg)
  serve(socket)
end

コマンドを実行する

残るは、KVServer.Commandモジュールのrun/1を実装することです。引数のコマンドにより異なるサーバーの操作を、複数節の関数で定めます。それぞれの関数節が、KV.Registryのサーバーに適切な処理を行うのです。サーバーは:kvアプリケーションが起ち上がるときに登録されます。そして、:kv_serverは:kvアプリケーションに依存します。したがって、アプリケーションのサービスに依存することは問題ありません。

# def run(_command) do
#   {:ok, "OK\r\n"}
# end
def run(command)

def run({:create, bucket}) do
  KV.Registry.create(KV.Registry, bucket)
  {:ok, "OK\r\n"}
end

def run({:get, bucket, key}) do
  lookup(bucket, fn pid ->
    value = KV.Bucket.get(pid, key)
    {:ok, "#{value}\r\nOK\r\n"}
  end)
end

def run({:put, bucket, key, value}) do
  lookup(bucket, fn pid ->
    KV.Bucket.put(pid, key, value)
    {:ok, "OK\r\n"}
  end)
end

def run({:delete, bucket, key}) do
  lookup(bucket, fn pid ->
    KV.Bucket.delete(pid, key)
    {:ok, "OK\r\n"}
  end)
end

defp lookup(bucket, callback) do
  case KV.Registry.lookup(KV.Registry, bucket) do
    {:ok, pid} -> callback.(pid)
    :error -> {:error, :not_found}
  end
end

run/1関数はdef run(command)だけで、本体がありません。本体のないヘッダだけの関数には、デフォルト引数が宣言できます(「Elixir入門 08: モジュールと関数」「デフォルト引数」参照)。けれど、ここではデフォルト値は与えませんでした。引数を明らかにするために用いているのです。

前掲KVServer.Commandモジュールには、共通に用いられるプライベートなlookup/2を加えました。目的のプロセスを探して、見つかればそのpid、なければ{:error, :not_found}を返す関数です。すると、KVServerモジュールのwrite_line/2にも、対応した関数節をwrite_line(socket, {:error, error})の手前に加えなければなりません。

defp write_line(socket, {:error, :not_found}) do
  :gen_tcp.send(socket, "NOT FOUND\r\n")
end

これで、コマンドがそれぞれ実行できるようになります。

$ telnet 127.0.0.1 4040
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
CREATE shopping
OK
PUT shopping milk 1
OK
PUT shopping eggs 3
OK
GET shopping milk
1
OK
DELETE shopping eggs
OK

サーバーの機能はほぼでき上がりました。まだ手をつけていないのがテストです。テストをどのように行うかは考えなければなりません。

KVServer.Command.run/1は、コマンドをKV.Registryという名前のサーバーに直に送るように実装しました。サーバーは:kvアプリケーションが登録します。つまり、サーバーがグローバルになるということです。すると、もしふたつのテストが同時にメッセージを送ったら、テストは互いに競合します(失敗するかもしれません)。そこで決めなければならないのは、ユニットテストにして同時実行できるように切り離すか、グローバルな状態の上で動作する統合テストを書くかということです。ここでは、アプリケーションのフルスタックを実行して、本番システムのテストにしましょう。

KVServer.Command.run/1を単体でテストできるようにするには、コマンドを直にKV.Registryのプロセスに送るのでなく、サーバーは引数として渡すように実装しなければなりません。たとえば、関数のヘッダをdef run(command, pid)とします。そして、続く関数節はこれに応じて書き直すのです。
def run({:create, bucket}, pid) do
  KV.Registry.create(pid, bucket)
  {:ok, "OK\r\n"}
end
# 他の関数節も同様。
このように書き替えた場合、KV.Registryのインスタンスをつくって、run/2の引数として渡すことになります。グローバルなKV.Registryに依存しませんので、状態を共有することなくテストは非同期にできるのです。

統合テストは、グローバルなサーバー名に依存して、TCPサーバーから子プロセスまでスタック全体を実行します。テストがグローバルな状態に依存するので、同期していなければなりません。統合テストでは、アプリケーションのコンポーネントがどのように連携しているかわかる反面、テストのパフォーマンスに影響します。通常使われる場面は、アプリケーションのおもなフローのテストです。たとえば今回のコマンド解析で、細かな条件に応じた実装を確かめるのには向いていません。

統合テストの実装はtest/kv_server_test.exsに以下のとおりです。TCPクライアントを用いてサーバーにコマンドを送り、意図した応答が得られたかどうか調べます。統合テストが確かめるのは、知らないコマンドや見つからないエラーも含め、サーバーとのすべてのやり取りです。そして、ETSテーブルやリンクしたプロセスのように、ソケットを閉じなくてよいことにご注目ください。テストプロセスが終了すると、ソケットは自動的に閉じるからです。

defmodule KVServerTest do
  use ExUnit.Case

  setup do
    Application.stop(:kv)
    :ok = Application.start(:kv)
  end

  setup do
    opts = [:binary, packet: :line, active: false]
    {:ok, socket} = :gen_tcp.connect('localhost', 4040, opts)
    %{socket: socket}
  end

  test "server interaction", %{socket: socket} do
    assert send_and_recv(socket, "UNKNOWN shopping\r\n") ==
           "UNKNOWN COMMAND\r\n"

    assert send_and_recv(socket, "GET shopping eggs\r\n") ==
           "NOT FOUND\r\n"

    assert send_and_recv(socket, "CREATE shopping\r\n") ==
           "OK\r\n"

    assert send_and_recv(socket, "PUT shopping eggs 3\r\n") ==
           "OK\r\n"

    # GET returns two lines
    assert send_and_recv(socket, "GET shopping eggs\r\n") == "3\r\n"
    assert send_and_recv(socket, "") == "OK\r\n"

    assert send_and_recv(socket, "DELETE shopping eggs\r\n") ==
           "OK\r\n"

    # GET returns two lines
    assert send_and_recv(socket, "GET shopping eggs\r\n") == "\r\n"
    assert send_and_recv(socket, "") == "OK\r\n"
  end

  defp send_and_recv(socket, command) do
    :ok = :gen_tcp.send(socket, command)
    {:ok, data} = :gen_tcp.recv(socket, 0, 1000)
    data
  end
end

今回は、テストがグローバルデータに依存しているので、use ExUnit.Caseにasync: trueは与えません。さらに、テストがつねに新たな状態で行われるように、テストごとに:kvアプリケーションを終了して起動し直します。実際テストすると、:kvアプリケーションの終了が、ターミナルに警告として加わるでしょう。

00:00:00.000 [info]  Application kv exited: :stopped

テストのときログメッセージが示されないようにするために、ExUnitに備わるのが:capture_logの機能です。テストごとに@tag :capture_logをテストの前に加えるか、テストモジュール全体に対して@moduletag :capture_logを定めると、ExUnitはテストが実行されている間のログを自動的にキャプチャします。そして、テストが失敗したときに、キャプチャされたログがExUnitレポートに加えて出力されるのです。

@moduletag :capture_logは、use ExUnit.Caseのあとに書き添えてください。

use ExUnit.Case
@moduletag :capture_log

そして、もしテストが失敗すると、たとえばつぎのようにレポートが示されます。

1) test server interaction (KVServerTest)
    test/kv_server_test.exs:17
    ** (RuntimeError) oops
    stacktrace:
      test/kv_server_test.exs:29

    The following output was logged:

    00:00:00.000 [info]  Application kv exited: :stopped

この統合テストは単純なのに速くありません。テストが同期的に実行されているうえ、アプリケーションをテストごとに終了して起動し直すという負荷の高い設定になっているからです。そのため、つぎのようにタイムアウトでエラーになるかもしれません。

1) test server interaction (KVServerTest)
    test/kv_server_test.exs:16
    ** (MatchError) no match of right hand side value: {:error, :timeout}
    code: assert send_and_recv(socket, "DELETE shopping eggs\r\n") ==
    stacktrace:
      test/kv_server_test.exs:43: KVServerTest.send_and_recv/2
      test/kv_server_test.exs:33: (test)

タイムアウトを避けるには、:gen_tcp.recv/3の第3引数に渡すタイムアウトのミリ秒を調整してください。

defp send_and_recv(socket, command) do
  :ok = :gen_tcp.send(socket, command)
  {:ok, data} = :gen_tcp.recv(socket, 0, 3000)  # 1000)
  data
end

最適なテスト戦略は、アプリケーションに応じて決めなければなりません。コード品質と信頼性、そしてテスト全体のランタイムなどをバランスさせなければならないのです。たとえば、はじめはサーバーだけを統合テストしてもよいでしょう。サーバーがその後のリリースで拡張し続けたり、アプリケーションの一部にたびたびバグが起こるようになると、テストの分割を考えなければなりません。統合テストのように重くないユニットテストを書いて、集中的にテストすることができます。

MixとOTPもくじ

Elixir: PhoenixでWebsocketをつないで簡単なチャットアプリケーションをつくる

gumi TECH — Fri, 24 May 2019 06:57:30 +0000

Phoenixは、Elixirでつくられたwebフレームワークです。Channelの機能を使えば、リアルタイム通信ができます。昨年のgumi Inc. Advent Calendar 2018の「Elixir/PhoenixとReactをWebsocketでつないでみる」
では、Websocketをつないだ簡単なチャットアプリケーションが紹介されました。本稿はその前半部分、Phoenixプロジェクトによるチャットルームのつくり方について少し説明を加えます。今回は、Elixir 1.8.0とPhoenix 1.4.2を使いました。

Phoenixプロジェクトをつくる

Phoenixのインストールについては、公式サイトの「Installation」をお読みください。まずは、mix phx.newコマンドでPhoenixプロジェクトをつくります(プロジェクト名chat)。--databaseオプションはEctoに用いるデータベースアダプタの定めです。今回はmysqlとしました(デフォルト値はpostgres)。なお、このチャットアプリケーションでは、データベースの機能は使いません。



mix phx.new chat --database mysql

アプリケーションがつくられ始めると、Fetch and install dependencies? [Yn]と尋ねられます。Yを入力すると、依存関係もインストールされるのでお手軽です。



Fetch and install dependencies? [Yn] y
* running mix deps.get
* running mix deps.compile
* running cd assets && npm install && node node_modules/webpack/bin/webpack.js --mode development

イントールの終わりに、ローカルサーバーでアプリケーションを立ち上げる手順が示されます。指示にしたがってコマンドを入力したあとhttp://localhost:4000を開けば、ひな形のページが表示されるでしょう(図001)。



cd chat
mix ecto.create
mix phx.server

図001■Phoenixプロジェクトのひな形ページ

`channel`を使う

Phoenixプロジェクトのlib/chat_web/endpoint.exには、つぎのようにPhoenix.Endpointビヘイビアを用いてすでにエンドポイントが加えられています。



defmodule ChatWeb.Endpoint do
  use Phoenix.Endpoint, otp_app: :chat

  socket "/socket", ChatWeb.UserSocket,
    websocket: true,
    longpoll: false

end

そして、エンドポイントのモジュールChatWeb.UserSocketを定めているのが、lib/chat_web/channels/user_socket.exです。Phoenix.Socketビヘイビアが使われています。このモジュールで、メッセージを適切なChannelにルーティングしなければなりません。そのために、channel/3が呼び出されるコードのコメントアウトを外してください。



defmodule ChatWeb.UserSocket do
  use Phoenix.Socket

  ## Channels
  channel "room:*", ChatWeb.RoomChannel  # コメントアウトを外す

end

これで、クライアントから"room:"ではじまるトピックでメッセージを送れば、ChatWeb.RoomChannelモジュールにルーティングされます。

クライアントの接続を認証する

チャットルームのメッセージを管理するChatWeb.RoomChannelは、lib/chat_web/channels/room_channel.exとして新たに定めます。モジュールはPhoenix.Channelビヘイビアを用い、クライアントがトピックに接続することを認証しなければなりません。認証のために実装するのが、join/3です。

チャットルーム"room:lobby"には、誰でも接続できるようにします。そのほかのチャットルームは、プライベートです。実際には、データベースなどによる認証を行うことになるでしょう。ここでは、エラーを返すだけにします。接続を認証する戻り値は、{:ok, socket}です。拒否する場合には、{:error, reply}を返します。これで、Channelの準備は整いました。



defmodule ChatWeb.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: "authorized"}}
  end
end

Phoenixプロジェクトは、assets/js/socket.jsにソケットを実装した簡単なクライアントが定められています。接続するには、正しいルーム名("room:lobby")に書き替えるだけです。ソケットの接続について詳しくは「Socket Connection」をご参照ください。



socket.connect()

// Now that you are connected, you can join channels with a topic:
// let channel = socket.channel("topic:subtopic", {})  // 以下に修正
const 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

connect(): ソケットに接続します。
channel(): 第1引数のトピックのChannelを初期化します。第2引数はChannelに渡されるパラメータです。
join(): Channelに接続します。戻り値はPushです。
receive(): 第1引数のステータスに対して、第2引数のコールバックを呼び出します。

ソケットへの接続準備が整いましたので、アプリケーションのassets/js/app.jsにimportします。コメントアウトされているつぎのコードを有効にしてください。



import socket from "./socket"  // コメントアウトを外す

これで、クライアントとサーバーが接続されます。ブラウザのコンソールには、"Joined successfully"と示されているはずです。channel()の第1引数に渡すトピックを違う名前に書き替えれば、"Unable to join"というエラーが表示されるでしょう。

チャットメッセージを送る

チャットができるように、ページにテキスト入力フィールドを加えます(図002)。テンプレートは、lib/chat_web/templates/page/index.html.eexです。もとの中身はすべて消してしまって構いません。つぎのコード001の2行に置き替えます。<ul>要素は、送られてきたメッセージをあとで加える場所です。

コード001■`lib/chat_web/templates/page/index.html.eex`



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

図002■テキスト入力フィールドが加わったページ

assets/js/socket.jsには、サーバーとやりとりするためのコードを以下のように書き加えます。テキスト入力フィールドで[return]/[Enter]キーが押されたら、push()メソッドでメッセージを送ります。第1引数はイベント名で、第2引数のオブジェクトが入力フィールドのテキストを納めたメッセージ本文です。

on()メソッドは、メッセージを受け取ります。第1引数にやはり待ち受けるイベント名を与え、第2引数のリスナー関数で受け取ったメッセージの処理を定めます。とりあえず、console.log()メソッドで中身を確かめることにしました。



const channel = socket.channel('room:lobby', {});
// 追加↓
const chatInput = document.querySelector('#chat-input');
const messagesContainer = 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) => {
  console.log(payload.body);  // 確認用
});

Channel経由で送られてきたメッセージを扱うのはコールバックhandle_in/3です。第1引数のイベントでパターンマッチングし、第2引数にマップでメッセージ本文を受け取ります。第3引数はPhoenix.Socketです。コールバックはlib/chat_web/channels/room_channel.exに以下のように定めます。

handle_in/3から呼び出しているbroadcast!/3は、リスナーにイベントを送ります。第1引数はソケット、第2引数がイベントで、第3引数は送るメッセージです。



defmodule ChatWeb.RoomChannel do

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

ページのフィールドに入力したテキストをクライアントから送ると、handle_in/3が呼び出すbroadcast!/3によりイベントとして配信されます。すると、assets/js/socket.jsでchannel.on()により定められたリスナー関数が呼び出されるのです。メッセージとして送られた入力フィールドのテキストがコンソールに出力されるでしょう。lib/chat_web/channels/room_channel.exの中身は、つぎのコード002にまとめました。

コード002■`lib/chat_web/channels/room_channel.ex`



defmodule ChatWeb.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: "authorized"}}
  end

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

assets/js/socket.jsのリスナー関数を完成させましょう。channel.on()の第2引数に渡すアロー関数式を、確認用のステートメントからつぎのコード003のように書き替えます。動的につくられた要素にメッセージ本文のテキストが加わって、ページに差し込まれ、簡単なチャットアプリケーションの動きができ上がりました(図003)。

コード003■`assets/js/socket.js`



// Now that you are connected, you can join channels with a topic:

// let channel = socket.channel("topic:subtopic", {})  // 以下に修正

const channel = socket.channel('room:lobby', {});

// 追加↓

const chatInput = document.querySelector('#chat-input');

const messagesContainer = 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) => {

  const messageItem = document.createElement('li');

  messageItem.innerText = [</span><span class="p">${</span><span class="nc">Date</span><span class="p">()}</span><span class="s2">] </span><span class="p">${</span><span class="nx">payload</span><span class="p">.</span><span class="nx">body</span><span class="p">}</span><span class="s2">;

  messagesContainer.appendChild(messageItem);

})

// 追加↑

channel.join()

  .receive("ok", resp => { console.log("Joined successfully", resp) })

  .receive("error", resp => { console.log("Unable to join", resp) })

図003■入力フィールドから送ったテキストがページに加わる

MixとOTP 08: タスクとgen_tcp

gumi TECH — Tue, 14 May 2019 02:26:47 +0000

本稿はElixir公式サイトの許諾を得て「Task and gen_tcp」の解説にもとづき、加筆補正を加えて、Erlangの:gen_tcpモジュールによりリクエストをどのように処理するかについてご説明します。また、Taskモジュールの使い方もご紹介します。

エコーサーバー

まずはエコーサーバーを実装して、TCPサーバーを起ち上げましょう。リクエストで受け取ったテキストを、レスポンスで送ります。少しずつ改善を重ねて目指すのは、監視を受けながら複数の接続が扱えるサーバーです。

TCPサーバーは、大きくつぎの手順を踏みます。

ポートが使えるまで待ってソケットを保持します。
そのポートにクライアントが接続するのを待って受け入れます。
クライアントのリクエストを読み込んで、返すレスポンスを書き込みます。

これらの手順を実装しましょう。apps/kv_serverアプリケーションに移って、lib/kv_server.exを開きます。モジュールKVServerをつぎのように書き替えてください。

require Logger

defmodule KVServer do
  def accept(port) do
    # オプションの機能はつぎのとおり:
    #
    # 1. `:binary` - データをバイナリとして受け取る(リストでなく)
    # 2. `packet: :line` - データを1行ずつ受け取る
    # 3. `active: false` - データが受け取れるようになるまで`:gen_tcp.recv/2`を待たせる
    # 4. `reuseaddr: true` - リスナーが落ちたときアドレスを再利用できるようにする
    #
    {:ok, socket} =
      :gen_tcp.listen(port, [:binary, packet: :line, active: false, reuseaddr: true])
    Logger.info("Accepting connections on port #{port}")
    loop_acceptor(socket)
  end

  defp loop_acceptor(socket) do
    {:ok, client} = :gen_tcp.accept(socket)
    serve(client)
    loop_acceptor(socket)
  end

  defp serve(socket) do
    socket
    |> read_line()
    |> write_line(socket)

    serve(socket)
  end

  defp read_line(socket) do
    {:ok, data} = :gen_tcp.recv(socket, 0)
    data
  end

  defp write_line(line, socket) do
    :gen_tcp.send(socket, line)
  end
end

KVServerモジュールは、accept/1の呼び出しによりサーバーを起ち上げます。引数はポート番号で、渡す値は4040です。accept/1はまずポートを監視して、ソケットが使えるまで待ちます。つぎに呼び出すのはloop_acceptor/1です。ループしながら、クライアントの接続を待ち受けます。そして、接続があるたび呼び出すのはserve/1です。

serve/1もループ処理です。1行ずつソケットから読み込んでは、書き戻します。serve/1関数がこの処理の流れを、パイプ演算子|>で組み立てていることにご注目ください。パイプ演算子の左辺の値を右辺の関数が第1引数に受け取り、その戻り値はつぎのパイプ演算子によりさらに右辺の関数に渡されます。

socket |> read_line() |> write_line(socket)

通常の引数の書き方では関数の入れ子になる処理が、パイプ演算子を用いるとわかりやすく書けるのです。

write_line(read_line(socket), socket)

read_line/1はソケットの読み書きを、:gen_tcpモジュールの関数により実装しています。読み取りが:gen_tcp.recv/2、書き込みは:gen_tcp.send/2です。

serve/1はずっとループして実行され続けます。すると、この関数を呼び出したloop_acceptor/1の本体は末尾呼び出しにたどりつかないので、ループしなくてもよいのではないでしょうか。けれど、あとでserve/1を別のプロセスに分けるため、末尾呼び出しが必要になります。

これでエコーサーバーはできました。kv_serverアプリケーションの中でIExのセッションをiex -S mixで起動してください。そして、KVServer.accept/1をつぎのように呼び出します。

iex> KVServer.accept(4040)

00:00:00.000 [info]  Accepting connections on port 4040

サーバーが起ち上がると接続待ちの状態になります。ここでは、Telnetクライアントを使ってサーバーにアクセスしましょう。コマンドラインツールでつぎのように入力してください。他のクライアントでも、入力するコマンドラインはほぼ同じです。

$ telnet 127.0.0.1 4040
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

エコーサーバーは入力待ちになります。キー入力して[enter]キーを押せば、そのテキストがつぎの行に表示されるはずです。

hello
hello
world
world

Telnetを終了するには、[control]/[Ctrl] + ]でコマンドモードに切り替え、quitに続けて[enter]を入力してください(終了の仕方はクライアントにより異なります)。Telnetが閉じると、IExのセッションにはつぎのようなエラーが表れるでしょう。:gen_tcp.recv/2がデータを受け取ろうとしたところ、クライアントの接続が閉じてしまったからです。この問題は、あとでサーバーを改定するときに扱うことにします。

** (MatchError) no match of right hand side value: {:error, :closed}
    (kv_server) lib/kv_server.ex:33: KVServer.read_line/1
    (kv_server) lib/kv_server.ex:26: KVServer.serve/1
    (kv_server) lib/kv_server.ex:20: KVServer.loop_acceptor/1

差し当たり、先に直さなければならないのは、TCPアクセプタがクラッシュした場合の問題です。サーバーにはまだ監視プロセスがありません。すると、サーバーが落ちたら再起動されないので、そのあとリクエストは扱えなくなります。ですから、サーバーは監視ツリーに移さなければなりません。

タスク

AgentやGenServer、そしてSupervisorは、いずれも複数のメッセージを扱い、状態が管理できました。けれど、やりたいことが簡単なタスクのときは、Taskモジュールが使えます。

たとえば、引数に渡した無名関数を新しいプロセスの中で実行し、監視ツリーに加えるのがstart_link/1関数です。lib/kv_server/application.exを開いて、start/2関数につぎのように書き加えてください。いつもは、子のリストに2要素のタプルを渡します。その代わりに、Task.start_link/1をタスクとして呼び出すのです。

def start(_type, _args) do
  children = [
    {Task, fn -> KVServer.accept(4040) end}  # 追加
  ]

  opts = [strategy: :one_for_one, name: KVServer.Supervisor]
  Supervisor.start_link(children, opts)
end

これで、サーバーが監視ツリーに含められ、アプリケーションとともに起動します。アプリケーションは、mix runコマンドでつぎのように起ち上げてください。

$ mix run --no-halt

00:00:00.000 [info]  Accepting connections on port 4040

$ telnet 127.0.0.1 4040
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
say you
say you
say me
say me

上のコードでは、ポート番号は直打ちしました。たとえば、つぎのように書き替えると、アプリケーションが起ち上がるとき、ポート番号をシステム環境から読み取ります。

port = String.to_integer(System.get_env("PORT") || "4040")
children = [
  # {Task, fn -> KVServer.accept(4040) end}
  {Task, fn -> KVServer.accept(port) end}
]

ポート番号は、アプリケーションを起動するmix runコマンドにつぎのように変数で加えてください。

$ PORT=4321 mix run --no-halt

前掲ポートの設定にはデフォルト値(4040)を与えました。ですから、ポート番号を省くと、その番号で接続を待ちます。

$ mix run --no-halt

00:00:00.000 [info]  Accepting connections on port 4040

Telnetクライアントを増やすとどうでしょう。ひとつ目のクライアントを接続したまま、もうひとつTelnetクライアントを開いてみてください。ふたつ目のクライアントは、エコーが示されません。

$ telnet 127.0.0.1 4040
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hello
hello?
HELLOOOOOO?

これは、リクエストを同じプロセスで扱っているからです。ひとつのクライアントが接続されると、つながっている間は、別のクライアントは受け入れられません。

タスクスーパーバイザー

サーバーが同時接続を扱えるようにするには、ひとつのプロセスをアクセプタとして、別につくったプロセスにリクエストを処理させなければなりません。ひとつ思いつくのは、KVServer. loop_acceptor/1でTask.start_link/1を使うように書き替えることです。これで、アクセプタのプロセスからリンクしたタスクが開始します。

defp loop_acceptor(socket) do
  {:ok, client} = :gen_tcp.accept(socket)
  # serve(client)
  Task.start_link(fn -> serve(client) end)
  loop_acceptor(socket)
end

けれど、serve(client)のタスクをアクセプタにリンクしてしまうのはいただけません。リクエストの処理が落ちると、アクセプタまで巻き込んで、その結果すべての接続が切れてしまうことになるからです。

そうならないための方策は、プロセスごとにスーパーバイザーを設けることでした(「MixとOTP 05: ダイナミックスーパーバイザー」参照)。暫定のタスクをスーパーバイザーに開始させ、監視ツリーに加えるのです。KVServer.Applicationのstart/2関数を改めてつぎのように書き替えましょう。

def start(_type, _args) do
  port = String.to_integer(System.get_env("PORT") || "4040")

  children = [
    {Task.Supervisor, name: KVServer.TaskSupervisor},  # 追加
    {Task, fn -> KVServer.accept(port) end}
  ]

  opts = [strategy: :one_for_one, name: KVServer.Supervisor]
  Supervisor.start_link(children, opts)
end

これで、Task.SupervisorがKVServer.TaskSupervisorという名前で起動します。アクセプタはこのスーパーバイザーに依存することにお気をつけください。つまり、スーパーバイザーは先に開始しなければならないのです。そこで、KVServerのloop_acceptor/1は、Task.Supervisorがリクエストを扱うように書き替えます。

defp loop_acceptor(socket) do
  {:ok, client} = :gen_tcp.accept(socket)
  # serve(client)
  {:ok, pid} = Task.Supervisor.start_child(KVServer.TaskSupervisor, fn -> serve(client) end)  # 追加
  :ok = :gen_tcp.controlling_process(client, pid)  # 追加
  loop_acceptor(socket)
end

：gen_tcp.controlling_process/2の呼び出しに気づいたでしょうか。これは子プロセスをクライアントソケットの「制御プロセス」にします。そうしないと、アクセプタがクラッシュしたとき、すべてのクライアントを落としてしまいます。ソケットは、受けつけられたプロセスに結びついているからです(これはデフォルトの動作です)。

改めてサーバーを起ち上げると、Telnetクライアントが同時にいくつも開けます。ひとつのクライアントを閉じてもアクセプタは落ちないので、他のクライアントの接続は生きているでしょう。

$ mix run --no-halt

00:00:00.000 [info]  Accepting connections on port 4040

スーパーバイザーが加わり、監視戦略は正しく定められました。アクセプタがクラッシュしても、すでにある接続を落とすことはありません。また、タスクスーパーバイザーがクラッシュしたとき、アクセプタを落とす必要もないでしょう。

もうひとつ考えなければならないのは再起動戦略です。タスクはデフォルトでは:restartの値が:temporaryに設定されています。これは再起動しないということです。Task.Supervisorが開始した接続については適切といえます。失敗した接続を再開する意味はないからです。けれど、アクセプタが落ちたら、再起動させるべきでしょう。

ひとつのやり方は、新たに定義するモジュールでuse Taskを使い、restart: :permanentとしてstart_link関数を呼び出すことにより、タスクを再起動することです。けれど、他の開発者のライブラリと統合するときは、エージェント、タスク、およびサーバーの定義方法は変えられません。そこで、子プロセスの仕様を動的にカスタマイズすることにしましょう。そのためには、KVServer.Applicationのstart/2でSupervisor.child_spec/2を呼び出すように書き替えます。

def start(_type, _args) do
  port = String.to_integer(System.get_env("PORT") || "4040")

  children = [
    {Task.Supervisor, name: KVServer.TaskSupervisor},
    # {Task, fn -> KVServer.accept(port) end}
    Supervisor.child_spec({Task, fn -> KVServer.accept(port) end}, restart: :permanent)
  ]

  opts = [strategy: :one_for_one, name: KVServer.Supervisor]
  Supervisor.start_link(children, opts)
end

Supervisor.child_spec/2は、モジュールやタプルから子の仕様がつくれます。さらに、子の仕様をオーバーライドすることもできるのです。これで、アクセプタはつねに動作します。そして、一時的なタスクプロセスを、つねに動作しているスーパーバイザーのもとで開始できるのです。以下にKVServer.ApplicationとKVServerの定義を掲げましょう。

defmodule KVServer.Application do
  @moduledoc false

  use Application

  def start(_type, _args) do
    port = String.to_integer(System.get_env("PORT") || "4040")

    children = [
      {Task.Supervisor, name: KVServer.TaskSupervisor},
      Supervisor.child_spec({Task, fn -> KVServer.accept(port) end}, restart: :permanent)
    ]

    opts = [strategy: :one_for_one, name: KVServer.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

require Logger

defmodule KVServer do
  @doc """
  定められた`port`で接続の受け入れを始める。
  """
  def accept(port) do
    {:ok, socket} =
      :gen_tcp.listen(port, [:binary, packet: :line, active: false, reuseaddr: true])
    Logger.info("Accepting connections on port #{port}")
    loop_acceptor(socket)
  end

  defp loop_acceptor(socket) do
    {:ok, client} = :gen_tcp.accept(socket)
    {:ok, pid} = Task.Supervisor.start_child(KVServer.TaskSupervisor, fn -> serve(client) end)
    :ok = :gen_tcp.controlling_process(client, pid)
    loop_acceptor(socket)
  end

  defp serve(socket) do
    socket
    |> read_line()
    |> write_line(socket)

    serve(socket)
  end

  defp read_line(socket) do
    {:ok, data} = :gen_tcp.recv(socket, 0)
    data
  end

  defp write_line(line, socket) do
    :gen_tcp.send(socket, line)
  end
end

MixとOTPもくじ

Elixir: パターンマッチングを使う

gumi TECH — Thu, 09 May 2019 12:25:10 +0000

パターンマッチングはElixirの強力な構文です。基本的な使い方については、gumi TECH Blog「Elixir入門 04: パターンマッチング」に説明されています。本稿では、この記事の中で扱われていないコード例をいくつかご紹介します。

キーワードリストとマップ

前出「Elixir入門 04」には、リストにパターンマッチングを用いるコードは説明されています。もちろん、キーワードリストでも使えます。けれど、要素の数とその順序までマッチしなければなりません。そのため、実際に用いられることは少ないでしょう。

iex> [a: a] = [a: 1]
[a: 1]
iex> a
1
iex> [a: a] = [a: 1, b: 2]
** (MatchError) no match of right hand side value: [a: 1, b: 2]
iex> [b: b, a: a] = [a: 1, b: 2]
** (MatchError) no match of right hand side value: [a: 1, b: 2]

キーワードリストとは異なり、パターンマッチングはマップではとても役立ちます。リストと比べて、マップのキーにはつぎの特徴があるからです。

どのようなデータ型でも使える
順序は問わない

マップのパターンは、サブセットとマッチします。つまり、パターンの中に含まれるキーさえマッチしていればよいのです。したがって、空のマップ%{}はすべてのマップにマッチします。

iex> %{} = %{:a => 1, 2 => :b}
%{2 => :b, :a => 1}
iex> %{:a => a} = %{2 => :b, :a => 1}
%{2 => :b, :a => 1}
iex> a
1
iex> %{:c => c} = %{:a => 1, 2 => :b}
** (MatchError) no match of right hand side value: %{2 => :b, :a => 1}

参照やパターンマッチング、あるいはマップに加えるキーには変数が使えます。

iex> n = 1
1
iex> map = %{n => :one}
%{1 => :one}
iex> map[n]
:one
iex> %{^n => :one} = %{1 => :one, 2 => :two, 3 => :three}
%{1 => :one, 2 => :two, 3 => :three}

条件

case/2で条件に合うかどうか決めるのは、パターンマッチングです。残るすべての場合を引き受けるには_を用います。

defmodule MyCase do
  def get_result(tuple) do
    case tuple do
      {:ok, value} -> value
      {:error, error} -> "error: " <> error
      _ -> :others
    end
  end
end

iex> MyCase.get_result({:ok, "success"})
"success"
iex> MyCase.get_result({:error, "something wrong"})
"error: something wrong"
iex> MyCase.get_result({:oops})                    
:others

関数

関数の定めには、ガードと複数の句が加えられます。複数の句は、Elixirが上から順に試し、マッチした句を実行するのです。引数がいずれにもマッチしなければ、エラーになります。

defmodule Math do
  def zero?(0) do
    true
  end

  def zero?(x) when is_integer(x) do
    false
  end
end

IO.puts Math.zero?(0)   #=> true
IO.puts Math.zero?(1)   #=> false
IO.puts Math.zero?([1]) #=> ** (FunctionClauseError)
IO.puts Math.zero?(0.0) #=> ** (FunctionClauseError)

つぎのコードは、関数のデフォルト値とパターンマッチングを使った例です。Enum.join/2は、リスト(Enumerable)要素の間に第2引数の文字列を挟んで、バイナリ(文字列)につなげます。

defmodule Greeter do
  def hello(names, language \\ "en")

  def hello(names, language) when is_list(names) do
    hello(Enum.join(names, ", "), language)
  end

  def hello(name, language) when is_binary(name) do
    phrase(language) <> name
  end

  defp phrase("en"), do: "hello, "
  defp phrase("ja"), do: "こんにちは"
end

iex> Greeter.hello("alice")
"hello, alice"
iex> Greeter.hello(["alice", "carroll"])
"hello, alice, carroll"
iex> Greeter.hello(["桃太郎", "金太郎", "浦島太郎"], "ja")
"こんにちは桃太郎, 金太郎, 浦島太郎"

再帰

つぎの関数はリスト要素の数値を2乗して、それらが要素に納められた新たなリストとして返します。このようにリスト要素を取り出して、新たなリスト要素に納めて返す処理はmapアルゴリズムと呼ばれ、関数型プログラミングの重要な考え方のひとつです。

defmodule Sum do
  def square([]), do: []
  def square([head | tail]), do:
    [head * head | square(tail)]
end

iex> Sum.square([1, 2, 3])
[1, 4, 9]

つぎの関数は、リストが空になったら引数の合計値を返して、再帰呼び出しは終わります。空でなかったらふたつ目の関数が、テイルと合計値を引数に再帰呼び出しして、ヘッドの値を加えます。つまり、再帰のたびにヘッドの値を合計値に加えていくことになるのです。リストから要素を順に取り出して、ひとつの値にまとめる処理はreduceアルゴリズムと呼ばれます。

defmodule Sum do
  def up(list, accumulator \\ 0)
  def up([], accumulator), do: accumulator
  def up([head | tail], accumulator),
    do: up(tail, head + accumulator)
end

iex> Sum.up([1, 2, 3])
6
iex> Sum.up([4, 5], 6)
15

適切でない引数にエラーを出す

クエリ文字列から特定のキーの値を得たいとします。そこで書いてみたのが、つぎの関数です。パターンマッチングは使っていません。なお、使われている関数は、つぎのとおりです。

String.split/3: 第1引数の文字列を第2引数の区切り文字列で分け、分けられた文字列を要素とするリストにして返します。第3引数はオプションです。
Enum.find_value/3: 第1引数の列挙型データを順に取り出し、関数の条件に合った要素を処理して返します。第2引数がオプションです。
Enum.at/3: 第1引数の列挙型データから、第2引数のインデックスの要素を取り出して返します。第3引数はオプションです。

defmodule Token do
  def get(string, token) do
    parts = String.split(string, "&")
    Enum.find_value(parts, fn pair ->
      key_value = String.split(pair, "=")
      Enum.at(key_value, 0) == token && Enum.at(key_value, 1)
      end)
  end
end

関数に文字列とキーを渡せば、その値が取り出されて返されます。けれど、クエリ文字列のかたちを正しくキーと値の組みにしなくても、値は返されてしまうことがあります。

iex> Token.get("name=fumio&city=tokyo&lang=elixir", "name")
"fumio"
iex> Token.get("name=fumio=nonaka&city=tokyo&lang=elixir", "name")
"fumio"
iex> Token.get("name&city=tokyo&lang=elixir", "name")             
nil

そこで、クエリ文字列の中にキーと値のふたつの組みでないものが含まれていたら、エラーを返したいと思います。このときは、つぎのようにリストでパターンマッチングさせればよいのです。要素数がマッチしなければ、エラーが返されます。コードも上の関数よりすっきりしました。

defmodule Token do
  def get(string, token) do
    parts = String.split(string, "&")
    Enum.find_value(parts, fn pair ->
      [key, value] = String.split(pair, "=")
      key == token && value
      end)
  end
end

iex> Token.get("name=fumio&city=tokyo&lang=elixir", "name")
"fumio"
iex> Token.get("name=fumio=nonaka&city=tokyo&lang=elixir", "name")
** (MatchError) no match of right hand side value: ["name", "fumio", "nonaka"]
iex> Token.get("name&city=tokyo&lang=elixir", "name")             
** (MatchError) no match of right hand side value: ["name"]

パターンマッチングには、取り出すデータを絞り込んだり、条件や場合分け、データの確認など、さまざまな使い方があります。ぜひ活用してみてください。

MixとOTP 07: 依存関係とアンブレラプロジェクト

gumi TECH — Thu, 09 May 2019 10:10:48 +0000

本稿はElixir公式サイトの許諾を得て「Dependencies and umbrella projects」の解説にもとづき、加筆補正を加えて、Mixで依存関係をどう管理するかについてご説明します。

これから実装するのは、kvアプリケーションのリクエストを処理するサーバーです。けれど、アプリケーションにコードを書き加えるのではありません。kvアプリケーションのクライアントとなるTCPサーバーを、別のアプリケーションとして構築します。ランタイムとElixirのエコシステムは全体として複数のアプリケーションが扱えます。したがって、プロジェクトを大きなひとつのアプリケーションにしなくて構いません。小分けしたアプリケーションがまとまって動くようにつくればよいのです。

新たなアプリケーションをつくり始める前に、Mixが依存関係をどのように扱うのかご説明しましょう。普段実際に扱う依存関係はふたつあります。内部的な依存と外部的な依存です。Mixはこれら両方に対応するメカニズムを備えています。

外部依存関係

外部依存というのは、ビジネスドメインに結びつかない関係です。たとえば、分散アプリケーションにHTTP APIが必要な場合は、外部依存関係としてPlugプロジェクトが使えます。

外部依存関係のインストールは簡単にできます。もっとも一般的なのは、Hexパッケージマネージャを使うことです。依存関係はmix.exsファイルのdeps関数の中にリストして加えます。

つぎの依存関係は、HexにプッシュされたPlug 1.0以降の最新バージョンを表します。バージョン番号1.0の前に添えられた~>が「以上」の意味です。バージョン要件の定め方について詳しくは、「Version」モジュールのドキュメントをご覧ください。

def deps do
  [{:plug, "~> 1.0"}]
end

通常は、Hexにプッシュされるのは安定版です。開発中の外部関係に依存したい場合、MixはGitの依存関係も管理できます。

def deps do
  [{:plug, git: "git://github.com/elixir-lang/plug.git"}]
end

プロジェクトに依存関係を加えると、Mixは繰り返しビルドができるようにmix.lockファイルをつくります。lockファイルはバージョンコントロールシステムの管理下に追加しなければなりません。すると、そのプロジェクトを使う人はすべて同じ依存バージョンを用いることが保証されるのです。

Mixには依存関係を扱う多くのタスクが備わっています。mix helpで示されるリストのうちmix depsで始まるのがそれらのタスクです。

$ mix help
# mix depsのみ抜粋
mix deps              # Lists dependencies and their status
mix deps.clean        # Deletes the given dependencies' files
mix deps.compile      # Compiles dependencies
mix deps.get          # Gets all out of date dependencies
mix deps.tree         # Prints the dependency tree
mix deps.unlock       # Unlocks the given dependencies
mix deps.update       # Updates the given dependencies

もっともよく使われるタスクは、mix deps.getとmix deps.updateです。取得された依存関係は、自動的にコンパイルされます。depsについては、mix help depsで説明が示されます。さらに詳しくは、Mix.Taskモジュールのドキュメントで「mix deps」をお読みください。

内部依存関係

内部依存は、プロジェクト固有の関係です。プロジェクト/会社/組織の範囲外では意味がありません。多くの場合、技術や経済あるいは経営的な理由により非公開とされます。

内部依存関係がある場合、Mixには対応方法がふたつあります。Gitリポジトリとアンブレラプロジェクトです。

たとえば、kvプロジェクトをGitリポジトリにプッシュするときは、depsのコードのリストに加えて使わなければなりません。

def deps do
  [{:kv, git: "https://github.com/YOUR_ACCOUNT/kv.git"}]
end

リポジトリが非公開の場合は、プライベートURLのgit@github.com:YOUR_ACCOUNT/kv.gitを指定してください。いずれであれ、適切な権限さえあれば、Mixは依存関係を取得できます。

内部依存関係にGitリポジトリを用いることは、Elixirではあまりお勧めできません。ランタイムとElixirエコシステムが、すでにアプリケーションの考え方を示していました。たとえひとつのプロジェクトでも、コードはたびたびアプリケーションに小分けされ、それらを論理的にまとめてゆくのです。

ところが、アプリケーションごとにGitリポジトリを別プロジェクトとしてプッシュすると、メンテナンスが難しくなり、コードを書くことよりGitリポジトリの管理に多くの時間が割かれてしまいます。

このため、Mixは「アンブレラプロジェクト」をサポートしているのです。アンブレラプロジェクトは、まとまって動く複数のアプリケーションをひとつのリポジトリで構築するために用いられます。アンブレラプロジェクトが目指すスタイルについてはつぎの項でご説明しましょう。

アンブレラプロジェクト

新しいMixプロジェクトをつくりましょう。名前はkv_umbrellaです。このプロジェクトはすでにつくったアプリケーションkvと新たなkv_serverのふたつをもちます。でき上がるディレクトリはつぎのとおりです。

+ kv_umbrella
  + apps
    + kv
    + kv_server

kv_umbrellaはkvとは別のプロジェクトです。kvプロジェクトの中につくらないようお気をつけください。アンブレラプロジェクトをつくるときは、mix newコマンドに、--umbrellaオプションを渡します。

$ mix new kv_umbrella --umbrella
* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating apps
* creating config
* creating config/config.exs

Your umbrella project was created successfully.
Inside your project, you will find an apps/ directory
where you can create and host many apps:

    cd kv_umbrella
    cd apps
    mix new my_app

Commands like "mix compile" and "mix test" when executed
in the umbrella project root will automatically run
for each application in the apps/ directory.

通常のプロジェクトと比べて、つくられるファィルは少ないです(図001)。mix.exsファイルの中身も、つぎのように異なっています(コメントは除きました)。

defmodule KvUmbrella.MixProject do
  use Mix.Project

  def project do
    [
      apps_path: "apps",
      start_permanent: Mix.env() == :prod,
      deps: deps()
    ]
  end

  defp deps do
    []
  end
end

図001■アンブレラプロジェクトでつくられるファイルとフォルダ

アンブレラプロジェクトを特徴づけるのは、projectに定められたapps_path: "apps"です。アンプレラプロジェクトには、ソースファイルもテストもありません。けれど、それぞれに依存関係がもてます。子のアプリケーションは、ディレクトリapps内につくらなければなりません。

では、appディレクトリに移って、アプリケーションkv_serverを構築しましょう。子アプリケーションは手動でつくらず、mix newコマンドに--supオプションを添えて生成してください。すると、Mixにより自動的に監視ツリーができ上がります。

$ cd kv_umbrella/apps
$ mix new kv_server --module KVServer --sup
* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating config
* creating config/config.exs
* creating lib
* creating lib/kv_server.ex
* creating lib/kv_server/application.ex
* creating test
* creating test/test_helper.exs
* creating test/kv_server_test.exs

Your Mix project was created successfully.
You can use "mix" to compile it, test it, and more:

    cd kv_server
    mix test

Run "mix help" for more commands.

つくられた子アプリケーションのファイルは通常のMixプロジェクトと似ています(図002)。

図002■つくられた子アプリケーションのファイル

mix.exsを開くと、アンブレラの子アプリケーションには追加がふたつあります。ひとつはproject関数に加えられた親プロジェクトの構造を示す4つのパスです。これはkv_umbrella/depsにチェックアウトし、ビルドはまとめられ、config.exsとmix.lockが共有されることを示します。依存関係の取得とコンパイルは、アプリケーションごとでなく、アンブレラの構造全体で行われるのです。

def project do
  [

    build_path: "../../_build",
    config_path: "../../config/config.exs",
    deps_path: "../../deps",
    lockfile: "../../mix.lock",

  ]
end

もうひとつの追加は、application関数のmod: {KVServer.Application, []}です。mix newコマンドに--supオプションを渡したことにより、KVServer.Applicationがアプリケーションのコールバックモジュールに定められました。このモジュールが、アプリケーションの監視ツリーを開始するのです。

def application do
  [

    mod: {KVServer.Application, []}
  ]
end

apps/kv_server/lib/kv_server/application.exのKVServer.Applicationモジュールの記述はつぎのとおりです。アプリケーションコールバックモジュールは、use ApplicationによりApplicationビヘイビアを実装しなければなりません。必要とされるのは、コールバック関数start/2です(「The application callback module」参照)。この関数は、KVServer.Supervisorという名前でスーパーバイザーを定めています。なお、スーパーバイザーについて詳しくは「Supervisor behaviour」をご参照ください。

defmodule KVServer.Application do
  # See https://hexdocs.pm/elixir/Application.html
  # for more information on OTP Applications
  @moduledoc false

  use Application

  def start(_type, _args) do
    # List all child processes to be supervised
    children = [
      # Starts a worker by calling: KVServer.Worker.start_link(arg)
      # {KVServer.Worker, arg},
    ]

    # See https://hexdocs.pm/elixir/Supervisor.html
    # for other strategies and supported options
    opts = [strategy: :one_for_one, name: KVServer.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

この子アプリケーションはapps/kv_serverディレクトリからテストできます。ここでは、アンブレラプロジェクト全体をテストするために、ルートのkv_umbrellaに移ってmix testを実行しましょう。

$ mix test
==> kv_server
Compiling 2 files (.ex)
Generated kv_server app
==> kv_server
..

Finished in 0.04 seconds
1 doctest, 1 test, 0 failures

Randomized with seed 930276

アンブレラプロジェクトの中の依存関係

kv_serverには、kvに定めた機能を使うつもりです。そのために、アプリケーションの依存関係にkvを加えなければなりません。アンブレラプロジェクトでは、Mixがアプリケーション間の依存関係をつくれるように明示的な定義が求められます。apps/kv_server/mix.exsのdeps/0関数に、以下のように書き加えてください。

これで:kvは:kv_server内の依存関係として使えるようになり、サーバーが起動する前にkvアプリケーションは自動的に起ち上がります。

defp deps do
  [
    {:kv, in_umbrella: true}
  ]
end

そして、アプリケーションkvをアンブレラプロジェクトのディレクトリappsにコピーしてください(図003)。

図003■アンブレラプロジェクトのappsに依存アプリケーションをコピーする

さらに、apps/kv/mix.exsには、apps/kv_server/mix.exsと同じように、アンブレラプロジェクトの構成パス4つが必要です。apps/kv/mix.exsのproject/0関数に、つぎのように書き加えてください。

def project do
  [

    build_path: "../../_build",
    config_path: "../../config/config.exs",
    deps_path: "../../deps",
    lockfile: "../../mix.lock",

  ]
end

これでアンブレラプロジェクトのルートから、mix testで両方のプロジェクトのテストが走らせられます。

$ mix test
==> kv
.....

Finished in 2.0 seconds
5 tests, 0 failures

Randomized with seed 857698
==> kv_server
..

Finished in 0.03 seconds
1 doctest, 1 test, 0 failures

Randomized with seed 857698

服従はしなくてよい

アンブレラプロジェクトは、複数のアプリケーションを整理して管理するのに便利です。アプリケーション間の分離の程度があるものの、まったく切り離される訳ではありません。同じ設定と依存関係を共有するとみなされるからです。

同じリポジトリに複数のアプリケーションを含めるパターンは「モノレポ」(mono-repo)と呼ばれます。アンブレラプロジェクトはこのパターンを最大限に活かして、複数のアプリケーションを一度にコンパイルしてテストし、実行することができるのです。

同じ依存関係のアプリケーションごとに設定を変えたいとか、あるいは異なる依存関係のバージョンを使いたいといった状況になったときは、コードベースがアンブレラプロジェクトの扱える範囲を超えて拡大している可能性があります。

そういうときも、アンブレラを分けるのは難しくありません。アプリケーションをアンブレラプロジェクトのappsディレクリの外に出すだけでよいからです。最悪の場合は、アンブレラプロジェクトとそれに関連する設定((build_pathやconfig_path、deps_path、lockfile)を破棄することになるかもしれません。それでも、すべてのアプリケーションをそのまま同じリポジトリにまとめておけば、「モノレポ」パターンが引き続き活用できます。アプリケーションは、それぞれの依存関係と設定をもつことになります。アプリケーション間の依存関係は、:pathオプションを用いて明示的にリストすることもできるのです(:gitとは対照的です)。

まとめ

kvはサーバーがなくても動くのに対して、kv_serverはkvに直接依存します。それぞれを別のアプリケーションとして分けることで、開発やテストはより進めやすくなるのです。

アンブレラアプリケーションを使うとき、切り分けをはっきりさせることが大切です。開発するkv_serverは、kvの定めた公開APIにのみアクセスしなければなりません。アンブレラアプリケーションにその他の依存関係は、Elixirそのものも含めて存在しないのです。アクセスできるのは、公開されドキュメント化されたものにかぎられます。依存関係の中の非公開の機能に触れることは避けるべきです。バージョンが改められたとき、コードが破綻してしまう原因となります。

アンブレラアプリケーションは、最終的にコードベースから切り出すアプリケーションの手始めとして利用することもできます。たとえば、ユーザーに「プッシュ通知」を送らなければならないwebアプリケーションがあるとします。「プッシュ通知システム」全体は、独自の監視ツリーとAPIにもとづき、アンブレラの中で別アプリケーションとして開発できるのです。すると、他のプロジェクトでプッシュ通知システムが求められた場合、システムをプライベートリポジトリやHexパッケージに移せるでしょう。

アンブレラプロジェクトは、開発者が広いビジネス領域を分けるために用いることもできます。確かめておかなければならないのは、領域が互いに依存しないことです(循環依存とも呼ばれます)。そうなってしまった場合には、アプリケーションが互いに分離されていないことを意味します。構造や設計を再検討しなければなりません。

アンブレラプロジェクトのアプリケーションで大切なのは、すべてが同じ設定と依存関係を共有することです。アンブレラの中のアプリケーションの間で、依存関係の設定が大きく異なったり、違うバージョンを用いなければならない場合は、おそらくアンブレラがもたらす利点を超えて大きくなりすぎたのでしょう。そういうとき、アンブレラを止めても、「モノレポ」にもとづく利益は得られます。

MixとOTPもくじ

Elixir: Elixir 1.9に備わった新機能

gumi TECH — Thu, 09 May 2019 10:03:34 +0000

2019年4月29日付でPlataformatec blogに公開された「What’s new in Elixir – Apr/19」で、v1.9.0-devに加えられた新機能が紹介されました。本稿は、その記事に公式ドキュメントなどの情報を補ってご説明します。

`mix release`の追加

新たにmix releaseが備わりました。基本的なリリースに加え、ランタイム設定、テンプレートファイルによるカスタマイズ、カスタムステップなどがサポートされます。

mix releaseは現行のプロジェクトの自己完結したリリースを組み立てます。

MIX_ENV=prod mix release
MIX_ENV=prod mix release NAME

リリースがつくられると、ターゲットに向けてパッケージ化し、デプロイできます。ターゲットは、同じオペレーティングシステム(OS)のディストリビューションおよびバージョンで、mix releaseコマンドが実行されたマシンで動かしておかなければなりません。

リリースは、mix.exsファイルのdef projectにおいて:releasesキーにより設定できます。

def project do
  [
    releases: [
      demo: [
        include_executables_for: [:unix],
        applications: [runtime_tools: :permanent]
      ],

      ...
    ]
  ]
end

`mix new`で設定ファイルをつくらない

まず、mix newでconfig/config.exsをつくらなくなりました。設定ファイルに依存することは、ライブラリやその作者にとって望ましくないとされてきたからです(「Avoid application configuration」)。つぎに、mix new --umbrellaは、子アプリケーションごとの設定はつくりません。すべての設定は、アンブレラプロジェクトのルートで宣言することになります。理由については「No longer generate config for mix new」をご参照ください。

Elixirに新たな`Config`モジュールを追加

リリースは独自の設定がされるかもしれません。また、ビルドツールのMixに依存するのは望ましくないでしょう。そこで、use Mix.Configはやわらかな非推奨(soft-deprecated)となります(やわらかな非推奨については「Elixir: バージョン間の互換性と非推奨」参照)。これからは、Elixirに新たに備わったConfigモジュールをimport Configとしてお使いください。

つぎのふたつの部分で互換性が破られます(「Add config providers」参照)。

設定モジュールの追加
- Config
- Config.Reader
- Config.Provider
リリースにConfig.Providerのサポートを追加

旧	新
use Mix.Config	import Config
Mix.Config.merge/2	Config.Reader.merge/2
Mix.Config.read!/2	Config.Reader.read!/2
Mix.Config.eval!/2	Config.Reader.read_imports!/2
Mix.Config.persist/1	Application.put_all_env/2

ロガーのパフォーマンス向上

ロガーは、メッセージが破棄されるときの処理を効率化しました。また、Erlang/OTP v21.2以降により、全体のパフォーマンスが向上しています。

その他の新機能

`~U`シギルの追加

UTC DateTimeをつくる~Uが加わりました(「Add ~U sigil for UTC date times」参照)。なお、~uはありません。

新たな関数

設定ファイルを簡単にできるように、つぎの3つの関数が新たに加わりました(「Add support for a default value in System.get_env/1」参照)。

細かな変更

細かな変更については、「Changelog for Elixir v1.9」をご参照ください。

DEV Community: gumi TECH Blog

React入門 03: JSON形式の配列から複数データを取り出してページに表示する

配列にまとめたJSONデータを子コンポーネントに渡す

複数データからテンプレートをつくる

図001■配列のJSONデータが取り出されて子コンポーネントに表示される

コード001■src/components/CommentList.js

コード002■src/App.js

Elixirメタプログラミング 02: マクロ

はじめに

はじめてのマクロ

マクロの健全さ

環境

プライベートマクロ

責任のあるマクロを書く

React入門 02: ライブラリMarkedでMarkdownの機能を加える

Markdown記法とMarkedのインストール

marked()関数でMarkdownをHTMLの記述に変える

図001■タグがテキストとして表示される

dangerouslySetInnerHTMLによりHTMLのコードを差し込む

図002■MarkdownテキストがHTMLとして描かれる

コード001■src/components/CommentList.js

コード002■src/components/Comment.js

Elixirメタプログラミング 01: 内部表現 ー quote/2とunquote/1

quote/2による式の表現

unquote/1による式の値の取り出し

Macro.escape/2によるエスケープ

React入門 01: コンポーネントを組み立てる

Create React Appでアプリケーションのひな形をつくる

図001■Reactのひな形アプリケーションページ

図002■アプリケーションのディレクトリにつくられたファイル

アプリケーションに子コンポーネントを加える

コード001■src/App.css

図003■ページに子コンポーネントのテキストが表示される

さらにコンポーネントに切り出す

コード002■src/components/Comment.js

子コンポーネントをもうひとつ加える

コード003■src/components/CommentForm.js

図004■ふた組みのコメントとダミーテキストがページに表示される

コード004■src/App.js

コード005■src/components/CommentList.js

MixとOTP 10: 分散処理のタスクと設定

分散処理のコードを書く

async/await

タスクの分散処理

ルーティングレイヤー

テストのフィルタとタグ

アプリケーション環境と設定

MixとOTPもくじ

MixとOTP 09: DocTestとwithのパターンマッチング

DocTest

with

コマンドを実行する

MixとOTPもくじ

Elixir: PhoenixでWebsocketをつないで簡単なチャットアプリケーションをつくる

Phoenixプロジェクトをつくる

図001■Phoenixプロジェクトのひな形ページ

channelを使う

クライアントの接続を認証する

チャットメッセージを送る

コード001■lib/chat_web/templates/page/index.html.eex

図002■テキスト入力フィールドが加わったページ

コード002■lib/chat_web/channels/room_channel.ex

コード003■assets/js/socket.js

図003■入力フィールドから送ったテキストがページに加わる

MixとOTP 08: タスクとgen_tcp

エコーサーバー

タスク

タスクスーパーバイザー

MixとOTPもくじ

Elixir: パターンマッチングを使う

キーワードリストとマップ

条件

関数

再帰

適切でない引数にエラーを出す

MixとOTP 07: 依存関係とアンブレラプロジェクト

外部依存関係

内部依存関係

アンブレラプロジェクト

図001■アンブレラプロジェクトでつくられるファイルとフォルダ

コード001■`src/components/CommentList.js`

コード002■`src/App.js`

`marked()`関数でMarkdownをHTMLの記述に変える

`dangerouslySetInnerHTML`によりHTMLのコードを差し込む

コード001■`src/components/CommentList.js`

コード002■`src/components/Comment.js`

Elixirメタプログラミング 01: 内部表現ー quote/2とunquote/1

コード001■`src/App.css`

コード002■`src/components/Comment.js`

コード003■`src/components/CommentForm.js`

コード004■`src/App.js`

コード005■`src/components/CommentList.js`

`channel`を使う

コード001■`lib/chat_web/templates/page/index.html.eex`

コード002■`lib/chat_web/channels/room_channel.ex`

コード003■`assets/js/socket.js`

`mix release`の追加

`mix new`で設定ファイルをつくらない

Elixirに新たな`Config`モジュールを追加

`~U`シギルの追加