React で CSS を書く方法の選定；「Tailwind を使うと名前をつけなくてよい」とは何か


Python の機械学習ライブラリ資産を活かしつつ、計算コストの高いロジックを Rust で書くために調べた内容をまとめます。

## PyO3

Rust でビルドしたライブラリを Python から利用可能にするために PyO3 を利用します。まだ安定版ではないので、これ以降の記述は `PyO3 v0.6.0` に基づいていることに注意してください。

競合として rust-cpython というのもあるのですが、rust-numpy が rust-cpython から PyO3 に移行したとのことなので、PyO3 を選択しました。比較については [https://pyo3.rs/master/rust-cpython.html](https://pyo3.rs/master/rust-cpython.html) が参考になります（PyO3 側のドキュメントですが）。注意しなければならない PyO3 の大きなデメリットは Rust の nightly と Python 3.5 以降が要求される点です。逆に rust-cpython の要求は Python 2.7 or 3.3 ~ 3.7, Rust 1.25.0 なので、バージョンに制約がある場合は rust-cpython が有力かと思います。

## インストールと動作確認

公式の string_sum サンプルを動作確認してみます。Rust の nighty が必要です。

```bash
# rustc -V
rustc 1.35.0-nightly (99da733f7 2019-04-12)
```

cargo init して、pyo3 への依存を追加します。crate-type は cdylib とします。

```toml
# Cargo.toml
[package]
name = "***"
version = "***"
authors = ["***"]
edition = "2018"

[lib]
name = "string_sum"
crate-type = ["cdylib"]

[dependencies]
pyo3 = { version = "0.6.0", features = ["extension-module"] }
```

[lib.rs](http://lib.rs) をこんなかんじに書きます。

```
use pyo3::prelude::*;
use pyo3::wrap_pyfunction;

#[pyfunction]
fn sum_as_string(a: usize, b: usize) -> PyResult<String> {
    Ok((a + b).to_string())
}

#[pymodule]
fn string_sum(py: Python, m: &PyModule) -> PyResult<()> {
    m.add_wrapped(wrap_pyfunction!(sum_as_string))?;
    Ok(())
}
```

cargo —release します。mac でビルドするときは `.cargo/config`を作っておく必要があります（[https://pyo3.rs/master/#using-rust-from-python](https://pyo3.rs/master/#using-rust-from-python)）。

```toml
[target.x86_64-apple-darwin]
rustflags = [
    "-C", "link-arg=-undefined",
    "-C", "link-arg=dynamic_lookup",
]
```

ビルド成功すると `target/release/libstring_sum.dylib` ができます。これを `string_sum.so` に書き換えて Python ファイルと同じディレクトリに配置します。Python からはモジュールとして利用可能です。

```python
# main.py
import string_sum
print(string_sum.sum_as_string(2, 3))
```

これで Python から Rust のコードが呼べます。

```
# python3 main.py
5
```

よかったですね。

## うまくいかない場合

### error[E0554]: #![feature] may not be used on the stable release channel

Rust の stable build だとこうなる。nightly をインストールしてください。

```
error[E0554]: #![feature] may not be used on the stable release channel
    --> /Users/kisk/.cargo/registry/src/github.com-1ecc6299db9ec823/pyo3-0.6.0/src/lib.rs:1:1
    |
1 | #![feature(specialization)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
The following warnings were emitted during compilation:

warning: pyo3 was unable to check rustc compatibility.
warning: Build may fail due to incompatible rustc version.

error: Could not compile `pyo3`.
```

### note: Undefined symbols for architecture x86_64:

mac でちゃんと設定をする。

```
error: linking with `cc` failed: exit code: 1
    |
    = note: "cc" "-m64" "-L" (以下略)
    = note: Undefined symbols for architecture x86_64:
            "_PyDict_Size", referenced from:
                pyo3::types::dict::PyDict::len::h05c3fcd816c8b8f0 in libpyo3-d3c73d3aa8dd4f32.rlib(pyo3-d3c73d3aa8dd4f32.pyo3.1i0p2ovg-cgu.4.rcgu.o)
            "_PyObject_GetAttr", referenced from:
                pyo3::object::PyObject::getattr::_$u7b$$u7b$closure$u7d$$u7d$::h34bbd2a48bc53c7a in libpyo3-d3c73d3aa8dd4f32.rlib(pyo3-d3c73d3aa8dd4f32.pyo3.1i0p2ovg-cgu.5.rcgu.o)
                        (中略)
            "_PyObject_SetAttr", referenced from:
                _$LT$T$u20$as$u20$pyo3..objectprotocol..ObjectProtocol$GT$::setattr::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::hd327ab921c0ae35f in string_sum.2259yfgj5etko2a.rcgu.o
                _$LT$T$u20$as$u20$pyo3..objectprotocol..ObjectProtocol$GT$::setattr::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h2fa32525c10b1ed0 in libpyo3-d3c73d3aa8dd4f32.rlib(pyo3-d3c73d3aa8dd4f32.pyo3.1i0p2ovg-cgu.6.rcgu.o)
            ld: symbol(s) not found for architecture x86_64
            clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error
```

### ImportError: dlopen

pyo3 最新版で Python 2 は非対応です。Python3 に移行しましょう。

```
ImportError: dlopen(/Users/kisk/Dropbox/Projects/rust-python-bridge/python/string_sum.so, 2): Symbol not found: _PyModule_Create2
    Referenced from: /Users/kisk/Dropbox/Projects/rust-python-bridge/python/string_sum.so
    Expected in: flat namespace
```

## いろいろな型を扱ってみる

### 数値

sum_string のサンプルは usize でした。f64 と u32 にしてみる。

```rust
fn sum_as_string(a: f64, b: u32) -> PyResult<String> {
    Ok((a + b as f64).to_string())
}
```

普通に使えます。

```python
import string_sum
print(string_sum.sum_as_string(1.4, 2))
```

たとえば u32 の引数に float を渡すとどうなるでしょう。

```python
import string_sum
print(string_sum.sum_as_string(100.0, 3.2))
```

ちゃんとしたわかりやすいエラーが出ます。えらい。

```
Traceback (most recent call last):
    File "python/main.py", line 3, in <module>
    print(string_sum.sum_as_string(100.0, 3.2))
TypeError: 'float' object cannot be interpreted as an integer
```

別のエラーを発生させてみましょう。Python 3 の数値型は long 長を超えられるので、巨大整数を u32 に渡してみます。

```python
import string_sum
print(string_sum.sum_as_string(1, 100 ** 100))
```

OverflowError が発生します。わかりやすいですね。

```
Traceback (most recent call last):
    File "python/main.py", line 3, in <module>
    print(string_sum.sum_as_string(1, 100 ** 100))
OverflowError: Python int too large to convert to C long
```

こういうときに RuntimeError で何も言わずに死んだりしないので安心です。

### 文字列

普通に str で受け取ることができます。

```rust
#[pyfunction]
fn get_length(a: &str) -> PyResult<usize> {
    Ok(a.len())
}
```

### リスト

Vec で受け取ることができます。

```rust
#[pyfunction]
fn multiply_array(a: Vec<usize>, b: usize) -> PyResult<Vec<usize>> {
    Ok(a.iter().map(|v| v * b).collect())
}
```

### タプル

タプルとして受け取ることができます。

```rust
#[pyfunction]
fn multiply_tuple(a: (usize, usize), b: usize) -> PyResult<(usize, usize)> {
    Ok((a.0 * b, a.1 * b))
}
```

### 辞書

`dict` 型は `PyDict` として受け取ります。

```rust
#[pyfunction]
fn multiply_dict(py: Python, a: &PyDict, b: usize) -> PyResult<PyObject> {
    let x_value: &PyLong = a.get_item("x").ok_or(KeyError)?.try_into()?; // PyO3 の Error に書き換える必要がある
    let y_value: &PyLong = a.get_item("y").ok_or(KeyError)?.try_into()?;

    let new_x_value = x_value.extract::<usize>()? * b;
    let new_y_value = y_value.extract::<usize>()? * b;

    let result = PyDict::new(py);
    result.set_item("a", new_x_value)?;
    result.set_item("b", new_y_value)?;
    Ok(result.into_object(py))
}
```

### 日付時刻

PyDate として受け取ります。

```rust
#[pyfunction]
fn get_next_year_date(py: Python, date: &PyDate) -> PyResult<PyObject> {
    Ok(PyDate::new(py, date.get_year() + 1, date.get_month(), date.get_day())?.into_object(py))
}
```

こういう書き方もできるようです。

```rust
#[pyfunction]
fn get_next_year_date(py: Python<'_>, date: &PyDate) -> PyResult<Py<PyDate>> {
    PyDate::new(py, date.get_year() + 1, date.get_month(), date.get_day())
}
```

どういう違いがあるかは正直よくわかっていません。ドキュメントが拡充されることを祈ります。

### メソッド

Python からメソッド（lambda）を受け取り、Rust 側からコールする例です。

```rust
#[pyfunction]
fn call_lambda(py: Python, lambda: PyObject) -> PyResult<usize> {
    let result = lambda.call0(py);
    result?.extract::<usize>(py)
}

#[pyfunction]
fn call_lambda_with_arg(py: Python, lambda: PyObject) -> PyResult<usize> {
    let result = lambda.call1(py, PyTuple::new(py, [123].into_iter()));
    result?.extract::<usize>(py)
}
```

引数がない場合は `call0` , ある場合は `call1` 、キーワード引数もある場合は `call2` を利用します。

### クラス

```rust
#[pyclass]
struct SomeStructInRust {
    pub number: i32,
    pub text: String
}


#[pymethods]
impl SomeStructInRust {
    #[new]
    fn new(obj: &PyRawObject, num: i32) {
        obj.init({
            SomeStructInRust {
                number: num,
                text: "default value".to_string()
            }
        });
    }

    #[getter]
    fn number(&self) -> PyResult<i32> {
        Ok(self.number)
    }

    #[getter]
    fn text(&self) -> PyResult<&String> {
        Ok(&self.text)
    }

    fn concat(&self) -> PyResult<String> {
        Ok(format!("{}-{}", &self.text, self.number))
    }
}
```

クラスは `add_class` を用いてモジュールに登録します。

```rust
#[pymodule]
fn string_sum(_py: Python, m: &PyModule) -> PyResult<()> {
    // 省略
    m.add_class::<SomeStructInRust>()?;
    Ok(())
}
```

Python 側からクラスとして扱うことができます。

```python
print(string_sum.SomeStructInRust(1))
```

Rust-Python 間でクラスを渡したり受けっとたりできます。

```rust
#[pyfunction]
fn get_rust_class(py: Python) -> PyResult<Py<SomeStructInRust>> {
    let result = SomeStructInRust {
        number: 1,
        text: "abc".to_string()
    };
    Py::new(py, result)
}


#[pyfunction]
fn pass_python_class(py: Python, a: PyObject) -> PyResult<usize> {
    let tm = a.getattr(py, "number")?;
    let x_value: &PyLong = tm.extract(py)?;
    Ok(x_value.extract::<usize>()? * 10)
}
```

## まとめ

PyO3 で Python から Rust のモジュールを利用する方法について説明しました。ドキュメントが不足している部分もあり特に `Py` `PyObject` まわりの役割については不明瞭なままですが、syntax はわかりやすいですし、型違いの場合のエラーハンドリングなどしっかりした挙動になっているなという印象です。


PyO3 で Python から Rust を利用する


React Native Web は React Native のコンポーネントや API を Web で動作させるためのライブラリです。
React Native は国内での採用事例も増え[^1]資料も充実しつつありますが、React Native Web についてはサンプルレベルを超える開発資料は未だ多くありません。
本稿では React Native で開発された Android アプリである [puyosim](http://puyos.im) を Web に移植した経験を元に、
React Native Web を採用した理由や移植の手順について解説します。

[^1]: [react-native-jp/react-native-apps-jp](https://github.com/react-native-jp/react-native-apps-jp)

## React Native Web とは

React Native Web は React Native のコンポーネントや API をブラウザで動作させるライブラリです。
そもそも React 自体が Web アプリを開発する技術なので、何が嬉しいのかわからない方もいるかもしれません。
React Native Web は `<div>` や `<a>` などの HTML を記述するのではなく、
`<View>` や `<Button>` のような React Native のコンポーネントをブラウザ上で動作させます。
つまり、React Native で開発したコンポーネントをそのまま Web で提供することができます。

React Native Web は React Native の API を Web 用のものにすり替えることで動作します。
これは webpack の以下のような設定によって実現しています。

```javascript
// webpack.config.js
module.exports = {
  resolve: {
    alias: {
      "react-native$": "react-native-web",
    },
  },
};
```

Web 向けにビルドするときは `react-native` の代わりに `react-native-web` をインポートさせる力技です。
なので `import { View } from 'react-native'` のように普段通りインポートすれば `View` がネイティブでも Web でも動作します。

## なぜ React Native Web を採用したか

開発している puyosim は「ぷよぷよ」の練習用・検討用 Android アプリです。
これの Web 版を開発するにあたって、フィールドを描画するコンポーネントを再実装したくないという思いがありました。
画像を並べて表示するだけのコンポーネントに見えますが、実際は連鎖のアニメーションを実現するため複雑な実装になっています。
また、将来的に操作履歴のツリー表示を実装する予定があり（執筆時点では実装済み）、
こちらもネイティブで開発したものを Web で実装し直すのにコストがかかりそうでした[^2]。

[^2]: 正直にいうとめんどくさかった

![左がフィールドを描画するコンポーネント、右側が操作履歴のツリー表示　](react-native-web/puyosim.png "puyosim のスクリーンショット")

共通化したいコンポーネントはスマートフォン独特の UI に依存していません。
たとえばネイティブのカード UI でスワイプが主要な操作になっている場合、PC ブラウザに対応するには別の UI が求められるでしょう。
puyosim の場合は基本的にフィールドの表示のみを扱うコンポーネントですので、ネイティブ・ブラウザで全く同じ機能を実現することになります。
デザインの面でも Android 固有のものを採用しておらず、そのまま Web に移動しても違和感がありません。
これらの点はコンポーネント共通化に向いているといえそうです。

React Native Web は React Native かなりの部分をサポートしており[^3]、基本的なコンポーネントだけでなく `Animated` API もサポートしています。
puyosim は `Animated` にかなり依存していたので、この部分のサポートが導入の決め手でした。

[^3]: https://github.com/necolas/react-native-web#compatibility-with-react-native

## どのような形で React Native Web を導入したか

### 導入方針

まず、コードどの範囲を共通化するかについて検討しなければなりません。
今回は、Container Component[^4] や全体のレイアウトを決定するコンポーネントはプラットフォームごとに分離し、
それ以外のコンポーネント（フィールドや操作履歴の描画など）は全て共通としました。
また、今回の場合はネイティブと Web で実現したい機能はほとんど変わらないので、コンポーネント以外の部分（Redux の Action や Reducer）も共通としました。

[^4]: https://redux.js.org/basics/usage-with-react#presentational-and-container-components

![おおまかなコンポーネントの包含関係の上で共通化戦略を図にするとこうなる](react-native-web/components.svg "コンポーネントの共通化方針")

`<Simulator/>` と `<History/>` が「大まかなレイアウトを決定するコンポーネント」にあたります。
これらをプラットフォーム固有にすることで、画面サイズの差によるレイアウトの違いを吸収しています。
たとえば Android ではシミュレータと操作履歴は別の画面に表示させていますが、Web では 1 つの画面に同時に表示させています。

### 導入手順

実際に React Native Web を導入したときの手順について説明します。
puyosim は React Native Web 導入前にすでに Android アプリとしてリリースしていますので、まっさらな状態からの導入ではありません。
普通の React Native プロジェクトから段階的に移行しています。

移行の手順としては、次のように行いました。

1. webpack.config.js や index.web.js を設置し、最小限の Web ビルドができるようにする
2. `src/native/` , `src/shared/` , `src/web/` のディレクトリを作成し、全てのソースコードを `src/native/` に移動させる
3. ネイティブで動作する状態を担保しながら、コード 1 つづつ `src/shared/` に移して Web での動作を確認する

全体を一気に移行するのではなく、コンポーネントを 1 つづつ Web に移行して動作確認を繰り返しました。
これは Web 向けに動作させるために細かな修正がたくさん必要になるかと考えたためです。
しかし、想像以上に React Native Web は優秀で、多くのコンポーネントはコードを変えることなく Web で動作させることができました。
また、コンポーネント以外の部分はほとんどネイティブに依存しておらず、そのまま `shared/` に移動して問題ありませんでした。

### ディレクトリ構成

React Native Web 導入後の最終的なディレクトリ構成を以下に示します。

```
.
├── android
│   └── ...
├── assets
│   └── ...
├── index.android.js # これは react-native-navigation の都合で必要
├── index.js
├── index.web.js
├── ios
│   └── ...
├── package-lock.json
├── package.json
├── rn-cli.config.js
├── src
│   ├── native
│   │   ├── components
│   │   └── containers
│   ├── shared
│   │   ├── actions
│   │   ├── components
│   │   ├── containers
│   │   ├── models
│   │   ├── reducers
│   │   ├── sagas
│   │   ├── selectors
│   │   ├── store
│   │   └── utils
│   └── web
│       ├── components
│       └── containers
├── tsconfig.json
└── web
    ├── build
    │   └── ...
    ├── public
    │   └── ...
    └── webpack.config.js

```

### プラットフォーム固有コードの呼び分け

puyosim では上記のように、プラットフォーム固有のモジュールを `src/web/`, `src/native/` に、共通モジュールを `src/shared/` に配置しています。
プラットフォーム固有のモジュールから共通モジュールを利用する場合は `import SomeComponent from '../../shared/component/SomeComponent'` のようにインポートできます。
逆に、共通モジュールからプラットフォーム固有のものを利用する場合ではモジュールを呼び分ける必要があります。
ネイティブ向けにビルドするときは `native/` のモジュールを、Web 向けのときは `web/` のモジュールを参照しなければなりません。

実は、puyosim では `native/` と `web/` を切り替える処理を追加していません。
React Native では `index.js` が、React Native Web では `index.web.js` が最初にロードされますので、
`index.js` から `native/` のコンポーネントを使い、`index.web.js` からは `web/` のコンポーネントを使うことで対応できます。
上図で説明したように、ルート要素に近いコンポーネントはプラットフォーム固有、末端のコンポーネントは共通化としているので、
基本的にはプラットフォーム固有のコンポーネントから共通コンポーネントを利用する状況しかありません。

しかし、`shared` 内のコードからプラットフォーム固有のモジュールを利用したいシチュエーションもわずかながらあります。
たとえば多言語対応のためのライブラリ react-native-i18n は Android 端末の言語設定をみるためネイティブ機能に依存しており、Web では使えません。
以下のようなコードで対応できそうですが、react-native-18n を import した時点で bundler がエラーを吐きます。

```
import I18n from 'react-native-i18n'
if (Platform.OS === 'web') {
  return 'hoge';
} else {
  return I18n.t('hoge');
}
```

このような場合にはファイル名による呼び分けが便利です。
`filename.android.js` と `filename.ios.js` で Android 実装と iOS 実装を切り替えられるように、
`filename.native.js` と `filename.web.js` でネイティブと Web を切り替えることができます。
react-native-i18n の呼び分けなど、1 ファイルで完結する場合に重宝します。以下が多言語対応の例です。

```
// translations.ts
const translations = {
  'ja': {
    chain: '連鎖',
    points: '点'
  },
  'en': {
    chain: 'chain',
    points: 'points'
  }
};
export default translations;
```

上記コードのように各言語の文言を保持しておき、ネイティブの場合は react-native-i18n に渡します。

```
// i18n.native.ts
import I18n from 'react-native-i18n';
import translations from './translations';

I18n.fallbacks = true;
I18n.translations = translations;

export default (key: string): string => I18n.t(key);
```

Web の場合は `navigator.language` をみてどの文言を使うか決めます。

```
// i18n.web.ts
import translations from './translations';

function detectLanguage() {
  try {
    return (navigator.browserLanguage || navigator.language || navigator.userLanguage).substr(0, 2);
  }
  catch (e) {
    return undefined;
  }
}

const lang = detectLanguage() || 'ja';
export default (key: string): string => translations[lang][key];
```

上記のようにしておけば `import translate from '../shared/i18n'` のようにして、共有モジュールからそれぞれのプラットフォーム固有のコードを利用することができます。

### ライブラリ

ライブラリについてはそれぞれのライブラリが React Native Web に対応しているかが重要になります。
今回のプロジェクトで利用しているライブラリは運良く Web に対応していました。
react-native-vector-icons は公式でサポートされていますし、
react-native-svg については非公式ながら react-native-svg-web というライブラリを導入することで対応可能です。
React Native Web に対応していなくて困ったライブラリは react-native-i18n くらいでしょうか[^5]。
これも上で説明したように、薄いラッパを書けば対応できます。

[^5]: react-native-navigation も Web 非対応ですが、これは仕方ない

## まとめ

React Native Web を導入してみて、想定よりも簡単にコンポーネントを Web で動作させることができて驚きました。
レイアウトの修正が多少必要でしたが、ほとんどネイティブ同様の挙動が Web で期待できます。

また、React Native Web を導入した副次的な効果として、コンポーネントをブラウザでデバッグできるようになりました。
実機デバッグだとリロードがうまくいかなかったりすることがあるので、慣れたブラウザと developer tools の上で開発できるのはありがたかったです。

React Native Web を初めて目にしたときは絶対うまくいかないと思い込んでいたのですが、今回のプロジェクトでは最高の効率を得ることができました。
React Native をお使いのみなさまは検討されてみてはいかがでしょうか。


React Native Web


もう何ヶ月も前のことですが技術書典 3 に[サークル参加](https://techbookfest.org/event/tbf03/circle/5679350280093696)していました。
初めての同人活動でした。
参加直後にその時の反省などを書き留めていたので、ここで公開したいと思います。

## 執筆について

### スケジュール

レポジトリの Initial commit が 8 月上旬だったので、だいたい開催日の 2 ヶ月半前に書き始めていたようです。
基本的には平日の終業後と土日を執筆に充てていました。

実は執筆した内容の半分くらい（ポケモン分類）は既存のブログ記事の再実験なので、執筆を始めたときには全体の 3 割ほどが完成している状態でした。
逆にもう半分（地名の可視化）は 0 からスタートしており、実装したり図書館で調べ物をしたりと手間がかかっています。地図や地名に詳しいわけでもない状態で手探りで執筆を進めたので、想定より工数がかかってしまいました。本当はもう 1 つ書きたいトピックがあったのですが、それに着手することはできませんでした。

今回は慣れないテーマについて書いたので失敗しましたが、
手慣れたトピックであれば（もちろん内容と分量によりますが） 2 ヶ月という期間は短くないと思います。

あと細部にこだわりすぎて執筆が停滞するのもよくなかったですね。
次は「がーーーーっと一気に書いて、そこからブラッシュアップ」（[東京ラビットハウスさん](https://rabbit-house.tokyo/blog/techbookfest3/) より）を心がけたいです。

### ツール

Re:VIEW を使いました。
[vvakame/docker-review](https://github.com/vvakame/docker-review) や [TechBooster/ReVIEW-Template](https://github.com/TechBooster/ReVIEW-Template) など先人の資産が公開されており、印刷のときの諸々でつまづきにくくなっています。
PDF だけでなく EPUB などのフォーマットに出力できるメリットがありますが、
今回は数式や図表を配置する都合上 embed ブロックを用いて部分的に LaTeX の記法を使っているため、EPUB への出力は諦めました。

### 書名・表紙

「表紙だけで本の内容が把握できるようにするべき」というアドバイスを頂いたので、表紙に各章のタイトルとサブタイトルを書いています。
これは頒布数を伸ばすのにかなり効果があったのではないかと思います。
ほとんどの来場者は会場を巡回しますが、1 サークルずつ丁寧にみていくわけではありません。なので、サークルスペースを一見しただけで内容が把握できないと、そもそも手にとってもらえません。表紙で訴求することが大事です。

また、書名をキャッチーにしたほうが手にとってもらいやすくなると思います。
今回の頒布物はキャッチーにしすぎて知り合いに配るのが恥ずかしかったので反省しています。

## 印刷について

### 入稿

バックアップ印刷所の日光企画さんに入稿しました。
B5 版 38 ページ、表紙は NP ホワイト 200kg ＋ クリア PP、本文は上質 90kg。
たぶん一般的な同人誌の装丁になっている思います。

入稿データを作るのは難しいので、最初から [TechBooster/ReVIEW-Template](https://github.com/TechBooster/ReVIEW-Template) をベースに作るべきでした。
ノンブルがおかしいとか、フォントの埋め込みとかの問題が一気に解決します。
初めての人は用紙サイズについても気をつけておきましょう。
A4 で作ってしまうと、後々 B5 に変更した時に図表が崩れて大変です。

### PDF 版

PDF（電子版）を頒布するのは正解だったと思います。
名刺サイズに QR コードを印刷して頒布しました。
原価が安いのでたくさん用意できますし、在庫になっても簡単に持ち帰れます。
CONCA や対面電書を使ってみたかったのですが納期の関係で諦め、
単純に PDF ファイルの URL を QR コードにして印刷しています。

### 部数

80 部刷りました。紙の本は 13~14 時に完売しました。
もっと刷ってよかったですね。
ちなみに入稿時点でのサークルチェック数はたしか 30 くらいです。
部数を決めるのは難しく勇気のいることですが、技術書典の熱量を信じましょう。

## 頒布について

### 電子払い

公式決済システム、pixiv PAY 共に利用しませんでした。
しかし「電子払いありますか？」という人は何人かおられましたし、
電子払いの方が財布の紐が緩むという話もあります。

### 立ち読み会場

技術書典 3 では公式の「立ち読み会場」がありましたが、当日すっかり忘れていたため利用しませんでした。
振り返ってみると、立ち読み会場は参加側・頒布側の双方にとってぜひ利用すべきものだったと思います。
頒布スペースの前で立ち読みされる方が多いと通行や隣のスペースの妨げになってしまうからです。
また、スペース前に人がいると場内を散策する人から頒布物が見えにくくなってしまいます。
吟味する人にとっても専用の場所で落ち着いて読めた方がいいでしょう。

### テーブル装飾

本を立てるスタンドやテーブルクロスといった「鉄板」があるので、即売会慣れしてる人が身内にいれば心強いです。
値札は小さいホワイトボードに書名と値段を書いたものでしたが、
もっと目立つ方がいいので次はしっかり印刷したやつを置きたいです。

PDF 版のダウンロードカードをテーブルに置いたとたん PDF 版が売れるようになったので、
テーブルに商品を出しておくことも重要なのかもしれません。

### 金庫

ちゃんとしたミニ金庫があれば会計が楽になると思います。小銭トレーがあると尚よさそうです。
適当な箱をもっていったら小さすぎて 1000 円札が入らなくて困ったし、
100 円玉と 500 円玉が混ざってしまい取り出しづらかったです。

### PDF カードの頒布

紙の本を買ってくれた方には本と一緒に PDF カードもお渡ししたかったので、
現地でカードを本に挟んだのですが、手間なのでやめるべきでした。
別売りにするか、PDF へのリンクを本に印刷してしまうのがいいと思います。

### 体力

思った以上に **疲れました**。
書店バイトの経験がある販売慣れした 2 人での参加でしたが 14 時くらいにはクッタクタでした。
（周りの人たちはそうでもなさそうにみえましたが、参加されたみなさんはどうでしたか？）

- 当日は体調は万全にしてよく寝ておくこと。
- 着脱しやすい服装を選ぶこと（熱気がすごい）。
- 飲料を必ず持っておくこと。
- できれば 2 人で参加すること。

## 感想

自分の書いた原稿が本になって手渡しで売れる体験はめちゃくちゃ面白いです。
サークル参加するのはちょっと勇気がいりますが、気になるのであれば参加登録しちゃえばいいと思いますよ。

## 参考リンク

技術書典 3 の参加報告のなかで勉強になったもの、初参加の人が参考にできそうなものをいくつか紹介させていただきます。

- [O'CREILLY さん](http://3846masa.hatenablog.jp/entry/2017/10/23/222130)
  ハマりポイントとか印刷所の解説が必見。
- [東京ラビットハウス さん](https://rabbit-house.tokyo/blog/techbookfest3/)
  当日持っていくもの、スケジュール、執筆について。
- [みじんこ組 ‏ さんの tweet](https://twitter.com/daphnia_class/status/923751272112537600)
  サークルチェック数の推移グラフ。印刷部数の参考にできる。


技術書典 3 参加の記録と反省


先日 Deep Learning でプログラムのエラー修正ができるという論文の紹介記事[^1]が話題になりました。
他にはすこし前ですが、 DeepCoder[^2] と呼ばれるコード生成の記事もよく見かけました。
若干煽りっぽいタイトルもあって、 Deep Learning によって訪れるコーディング環境の変化やプログラマの未来像に思いを馳せた人もいるのではないでしょうか。
ですが、これらの記事では論文によって実現できたこと、できていないことが明示されていません。
ここではこれらの手法をより具体的に掘り下げて紹介したいと思います。

## DeepFix: Fixing Common C Language Errors by Deep Learning[^3]

上記の「[RNN でプログラミング言語の構文エラーを自動修復する衝撃](https://deepage.net/deep_learning/2017/06/14/rnn-compiler-error.html)」で紹介された論文です。
閉じカッコやセミコロンの書き忘れのような、不注意による文法エラーを自動で修正することを試みています。
現状でも C 言語のコンパイラは文法エラーを検知できますが、プログラムのどこが間違えているのかを正しく指摘することはできません。
コンパイラはプログラムのパースに失敗した箇所を指摘するためです。
この論文は自動的にプログラムのエラー位置を特定し、それを修正する手法を提案しています。

![8 行目にエラーの原因があるがコンパイラの出力は「test.c:15:1: error: expected declaration or statement at end of input」となる](/2017/deep-learning-for-code/code.png)

### 手法

Attention 機構を導入した Recurrent Neural Network (Seq2seq) を用います。
基本的にはエラーを含むプログラムを入力系列とし、エラーが解消されたプログラムを出力系列として学習すれば自動エラー修正が実現します。
しかし、プログラムのように長く、かつ正確性が求められる系列を RNN に学習させるのは難しいようです。
そこで、プログラムを文（sentence）ごとに分割し、行番号を用いて (修正すべき行番号, 修正後の文) のペアを出力とするように学習させます。
入力プログラムに対して修正すべき箇所と修正内容が出力される RNN というわけです。
出力された行番号に対応する部分の入力系列を上書きし、修正済みプログラムとすれば自動修正となります。

この方法では 1 度に 1 つのエラーしか修正できないので、1 つのプログラムを繰り返し RNN に適用する（Iterative Repair）必要があります。
RNN で 1 箇所を修正するごとにコンパイルし、エラーが減るかを確認しながら全体の修正を進めていくので、1 度にすべてのエラーを修正するよりも確実性の高いエラー修正が可能となります。
また、文を修正するだけではなく、新たな行に対して出力したり特定の行に対して空文字列を出力したりすることで文の追加・削除も可能です。

### 実験

エラーのないプログラム 9230 個を編集し、コンパイルエラーが発生するようにしたものを学習データとして用意します。
1 つのプログラムの長さは平均 206 token （FizzBuzz の 2~3 倍くらい？）。
プログラムごとに最大 5 箇所を編集しており、そのうち 1 つめのエラーを修正するように RNN を学習させます。

テストデータは C 言語の授業で課題として提出されたプログラム 6971 個で、プログラム長は平均 203 token、コンパイルすると全体で 16742 個のエラーが発生します。
学習後の RNN を用いて修正した結果、**1881 個のプログラム（27%）を完全に修正**することができ、1338 個（19%）を部分的に修正することができました。
エラー数でいうと全体の 32% が解消されています。

自動修正ではなく、問題のある箇所を指摘するツールとして用いる場合は「修正できたか」の精度ではなく「エラー箇所が特定できたか」の精度が重要になりそうです。
これを人為的な編集でエラーを発生させたデータに対して調べたところ、全体の 78.68% のエラーの発生原因を正しく特定できていました。
候補を 5 つ提示してそのなかに正解があるかを確かめる方式（top-5）だと 87.50% の正解率となります。

## DeepCoder: Learning to Write Programs[^4]

[マイクロソフトの新しい AI は、他のプログラムのコードを拝借してコードを書く](https://www.businessinsider.jp/post-1040) という記事で紹介されている論文です。
「他のプログラムのコードを拝借」とありますが論文によるとプログラムの拝借は一切行われません。
タイトルが煽り過ぎているのでは（もしくは自分が読む論文間違えている可能性もある）。

この論文で扱う問題は "Inductive Problem Synthesis" と呼ばれるもので、
与えられた入出力要件を満たすプログラムを生成する問題です。
競技プログラミングの問題を自動で解くようなイメージです。
ただし問題文のような自然言語による情報は用いず、入出力ペアのみからプログラムを構築します。

DeepCoder は以下のようにプログラムを生成します。

1. 入出力要件を満たすプログラムに必要な制御構文や命令、数値リテラルの出現確率を DNN で予測
2. 予測した出現確率に基づいてプログラムを全探索
3. 入出力要件を満たすプログラムが発見できたら終了

先に紹介した論文では RNN がプログラムを出力するモデルでしたが、
DeepCoder は基本的にプログラムを（深さ有線探索のような）全探索で求めます。
DNN が必要だと判断した言語機能を優先的に探索することで、プログラム生成が高速化できるというわけです。

![入出力要件が入力、構文・リテラルなどの出現確率が出力となる DNN](/2017/deep-learning-for-code/deepcoder-network.svg "DeepCoder のネットワーク")

C 言語などの汎用言語で用いられる構文やリテラルをすべて出力可能にすると探索空間が広いので、
ここでは SQL-like な簡易 DSL を用いています。
この DSL は一般的な言語と比べて記述力がかなり限られており、たとえばループを含むアルゴリズムが記述できません。
探索方法は深さ有線探索や "Sort and add enumeration"、$\lambda^2$ などを実験で試しています。

### 実験

DNN を導入したことによる探索の高速化を実証します。
まず長さ 5 のプログラム（5 命令?）とそのプログラムが満たす入出力を自動生成し、これを学習データとして DNN を学習します。
次に同様の方法で生成した入出力要件から DeepCoder でプログラムを探索し、DNN を用いずに探索した場合とどれくらい処理速度に差があるかを確かめます。
DNN を導入した場合も探索空間は変わらないので（探索順序が変わる）、ワーストケースでは同じ時間がかかることになります。
そこで、論文では 100 個の問題のうち 20%、40%、60% を解くことができた時刻がどれくらい早くなったかを計測することで評価としています。
結果、どの探索方法でも 2~1000 倍の高速化が達成できたとのことです。

実際のプログラミング問題に適用して解けた問題のサンプルが論文にありましたので、ひとつ紹介します。

![DeepCoder が解けた問題（引用元[^3] Appendix. A, Fig.3 より）](/2017/deep-learning-for-code/deepcoder-solved.png "DeepCoder が解いた問題のサンプル")

## まとめ

DeepFix と DeepCoder を紹介しました。

1 つめの DeepFix を実用できるかの視点で考えた場合、プログラムを修正するツールとして使うにはまだまだ及ばないのが現状と思います。
エラー箇所を正しく参照するためのツールとしてなら使えるのかもしれません。
ただし今回の実験は小規模な C プログラムを対象としたものなので、中規模以上のプログラムではどのようになるか不明です。
エラーの原因らしき部分をハイライトするような入門者向けの補助ツールとしては現状でも十分に便利そうです。

疑問点としては、エラーを自動で修正するツールとして見た場合、ロジックが変更されうる修正を採用してしまう可能性が残っていることです。
たとえばエラーがある行を修正ではなく削除してしまえばコンパイルが通るようになることもあると思われます。
このことは論文でも言及されており、詳しくはわかりませんでしたが、Iterative Repair の際にコンパイルの成否に加えテストケースをパスできるかを確かめているのかもしれません。

2 つめの DeepCoder は入出力要件からプログラムを生成する手法でした。
これは「プログラマの職を奪う」ような文脈で語られるのを見かけますが、そもそもプログラマの職を奪うような問題設定になっていない気がします。
入出力要件を満たす機能がほしいのであればそれを満たすニューラルネットを構築して学習させればよくて、わざわざプログラムを生成する必要はありません。
プログラムを生成するのは生成結果が妥当かどうかをプログラマが判断するためのものであるように思います。
やはりプログラマの補助ツールとしての活用に期待するべきものではないでしょうか。
ちょっと考えるのが面倒になるような Rx とかが生成できたら面白いと思います。

紹介した論文はどちらも 2017 年の学会で発表されたものですが（論文が公開されたのはもっと前）、
近年の機械学習の進歩は著しく、さらに発展した論文がすでに現れています。
たとえば "A Syntactic Neural Model for General-Purpose Code Generation"[^5] では、
英文から Python のコード（実際は抽象構文木）を直接生成する RNN を試みています。
プログラミングの環境が一変するような未来は近づいてきているのかもしれません。

[^1]: [RNN でプログラミング言語の構文エラーを自動修復する衝撃](https://deepage.net/deep_learning/2017/06/14/rnn-compiler-error.html)
[^2]: [マイクロソフトの新しい AI は、他のプログラムのコードを拝借してコードを書く](https://www.businessinsider.jp/post-1040)
[^3]: [Rahul Gupta, et al. "DeepFix: Fixing Common C Language Errors by Deep Learning". AAAI Conference on Artificial Intelligence, North America (2017).](https://aaai.org/ocs/index.php/AAAI/AAAI17/paper/view/14603/13921)
[^4]: [Balog, Matej, et al. "DeepCoder: Learning to Write Programs". arXiv preprint arXiv:1611.01989 (2016).](https://arxiv.org/pdf/1611.01989.pdf)
[^5]: [Pengcheng Yin, et al. "A Syntactic Neural Model for General-Purpose Code Generation". arXiv preprint arXiv:1704.01696 (2017).](https://arxiv.org/pdf/1704.01696.pdf)


プログラムを書く Deep Learning の現状


Dynamic Time Warping（DTW, 動的時間伸縮法）を最近知りました。
波形同士のアライメントと差分計算を同時に行い、類似度を求める手法です。
初出は 1960 年代で、音声認識や文字認識などの分野で活発に研究されていた[^1]ようです。
シンプルな手法なので、勉強を兼ねてデモを実装しました。

## デモ

枠の中はマウスドラッグで波形が描けるようになっています。
上の枠と下の枠に波形を描くと、波形同士のアライメント（warping path）が表示されます。

<div style="text-align:center;">
  <script src="dynamic-time-warping/dtw.js"></script>
  <canvas class="dtw" width="520" height="320">
  </canvas>
</div>

## 手法

2 つの波形データ $x$, $y$ の類似度を計算することを考えます。
波形データは、時刻 $t (1 \leq t \leq T)$ における波形の値 $x_t, y_t$ で表されているとします。

一番簡単な類似度の計算は、波形同士の差分を求めることでしょう。

$$
\sum_t |x_t - y_t|
$$

しかし、この差分は波形がずれているときにうまくいきません。
波形の形に応じてアライメント処理を行い、差分を計算する箇所を変化させる必要があります。

### 定義

まず、波形同士のアライメントを表現する記法を説明します。
波形 $x$ の時刻 $t=w^x$ と波形 $y$ の時刻 $t=w^y$ がアライメントによって対応することを
$w = (w^x, w^y)$ とし、波形のアライメント全体を $K$ 個の対応関係の集合 $W$ で表します。

$$
W = \{w_1, w_2, \cdots, w_K \}
$$

$w_k = (w^x_k, w^y_k)$ とおくと $W$ は次の条件を満たします。

1. $w^x_{k-1} - w^x_k \leq 1$ かつ $w^y_{k-1} - w^y_k \leq 1$
2. $w^x_{k-1} - w^x_k \geq 0$ かつ $w^y_{k-1} - w^y_k \geq 0$
3. $w_1 = (1, 1)$ かつ $w_K = (T, T)$

このとき、Dynamic Time Warping による波形同士の距離は以下のように定義されます。

$$
\mathrm{DTW}(x, y) = \min\sum_K^k |x_{w_k^x} - y_{w_k^y}|
$$

### アルゴリズム

数式で書くと添字が複雑ですが、アルゴリズムはシンプルです。
まず、波形同士の距離行列 $D$ を考えます。

$$
D = \left(
    \begin{array}{cccc}
      |x_1 - y_1| & |x_2 - y_1| & \cdots & |x_T - y_1| \\
      |x_1 - y_2| & |x_2 - y_2| & \cdots & |x_T - y_2| \\
      \vdots & \vdots & \ddots & \vdots \\
      |x_1 - y_T| & |x_2 - y_T| & \cdots & |x_T - y_T|
    \end{array}
  \right)
$$

$W$ は距離行列 $D$ 上の経路として捉えることができます。
$D_{0, 0}$ から $D_{T, T}$ までをつなぐ経路です。
たとえば $W=\{(0, 0), (1, 1), (1, 2), \cdots\}$ とすれば、
これは行列 $D$ 上の $D_{0, 0}, D_{1, 1}, D_{1, 2} \cdots$ を通る経路とみなせるわけです。
上述した $W$ の満たす 3 つの条件はそれぞれ経路が

1. 連続である（経路が途切れない）こと
2. 単調である（経路が後戻りしない）こと
3. 経路の始点が $(1,1)$ で終点が $(T,T)$ であること

を意味します。

様々な経路が考えられますが、このうち経路上にある $D$ の要素の総和が最小となるのが最適な $W$ というわけです。
そのときの経路上にある要素の総和が $\mathrm{DTW}(x, y)$ です。
動的計画法で解けますね！

## 実装

擬似コードでの実装は [Wikipedia](https://en.wikipedia.org/wiki/Dynamic_time_warping) が詳しいです。
ここでは上記デモの実装を紹介します。
デモの実装全体は [haripo/DynamicTimeWarping](https://github.com/haripo/DynamicTimeWarping) にあります。

```javascript
var map = [];
var cache = [];

for (var i = 0; i < stream1.length; i++) {
  distance.push([]);
  cache.push([]);
  for (var j = 0; j < stream2.length; j++) {
    distance[i].push(Math.abs(stream1[i] - stream2[j]) + 1);
    cache[i].push(Math.abs(i - j) < 150 ? -1 : Number.MAX_VALUE);
  }
}
```

距離行列 $D$ を二次元配列 `distance` に作って、動的計画法をメモ化するための配列 `cache` を初期化しています。
波形の遠い箇所がマッチングしてしまうのを防ぐため `Math.abs(i - j) < 150` の範囲で探索するようにしています。
このような境界条件をつけることで探索が高速になるほか、実データではロバストになることが分かっています[^2]。

```javascript
var search = null;
search = function (x, y) {
  if (cache[x][y] <= 0) {
    cache[x][y] =
      distance[x][y] +
      Math.min(
        x > 0 ? search(x - 1, y) : Number.MAX_VALUE,
        y > 0 ? search(x, y - 1) : Number.MAX_VALUE,
        x > 0 && y > 0 ? search(x - 1, y - 1) : Number.MAX_VALUE
      );
  }
  return cache[x][y];
};

search(stream1.length - 1, stream2.length - 1);
```

再起関数を使った普通の動的計画法です。1 行目の `var search = null;` がないと `search` 関数中で `search` 関数が未定義状態となるので必要です。
この時点で `cache[stream1.length - 1][stream2.length - 1]` が DTW 距離となります。

```javascript
var x = 0;
var y = 0;
var match = [];
while (x > stream1.length - 1 || y > stream2.length - 1) {
  if (
    cache[x + 1][y + 1] <= cache[x + 1][y] &&
    cache[x + 1][y + 1] <= cache[x][y + 1]
  ) {
    x += 1;
    y += 1;
  } else if (cache[x][y + 1] <= cache[x + 1][y]) {
    y += 1;
  } else {
    x += 1;
  }
  match.push([x, y]);
}
```

今回のデモでは Warping path を表示したかったので、stream1 と stream2 の各点がどの位置にアライメントされるのかを求めます。
`cache` を辿って最短ルートで `cache[stream1.length - 1][stream2.length - 1]` に至るパスを探索しています。

DTW の実装はこれだけです。シンプル。

## おわりに

DTW を紹介しました。
わりと古くからある手法ですが、現在も DTW に関係する論文が出ているようです[^3]。
実装も簡易でわかりやすいですし、時系列データに「とりあえず」で試してみてもいいかもしれません。

[^1]: Senin, Pavel. "Dynamic time warping algorithm review." Information and Computer Science Department University of Hawaii at Manoa Honolulu, USA 855 (2008): 1-23.
[^2]: Xi, Xiaopeng, et al. "Fast time series classification using numerosity reduction." Proceedings of the 23rd international conference on Machine learning. ACM, 2006.
[^3]: [Google Scholar で 2016 年以降の DTW 論文を検索した結果](https://scholar.google.co.jp/scholar?as_ylo=2016&q=dynamic+time+warping)


haripo.com

About

Projects

Articles