ARKitの動画再アップ / magicien　

以前ニコニコ動画にアップしていた（その後削除した）ARKitの動画を再アップしました。


もはや今更な感じがするけれども。
Xcodeをバージョンアップしたら、UIColorの仕様がちょっと変わっていた。というかNSColorとほぼ同じになっていた。これでOSによる分岐が無くせるかも。むしろ今まで微妙にインタフェースが違ったのは嫌がらせか何かだったのか。

　Heroku/Node.js/ExpressでGitHub AppsのInstallation認証 / magicien　

GitHub Appsとしてリポジトリの操作が必要な場合は、Installation認証が必要。
ユーザは無関係の認証なので、サーバ・GitHub間だけで完結する。

ソースはこんな感じ。
Installation IDは、ユーザ認証のときに取得する必要がある。
ユーザとは無関係に操作できてしまうので、操作を要求しているユーザが対象のInstallationのアクセス権を持っているか確認が必要。

　新iPhone！ / magicien　

既に色々と情報がリークしていましたが、ようやく新iPhoneが発表されましたね。

iPhone9が欠番になっちゃいましたが、8sの代わりに9が出たりするのかなぁ。Xも出ちゃったので以降のネーミングはmacOSみたいな感じになりそうですね。

個人的にはAnimojiが一番気になりました。顔認証技術をそうやって使うのかと。
そのうちMacBookにも同じ機能が付くのかなぁ。MMDの表情モーションを自分で演じて作るというのも面白いかもですね。
Dot Projectorというパーツが増えていたので、Kinectと同じようなことをしているんでしょう。Microsoftと何らかのやり取りがあったんでしょうか。ここら辺の技術はどこが持っているのか。
（追記：2013年にAppleがイスラエルのPrimeSenseという会社を買収していたようですね。Kinectのセンサーを作っていた会社らしいです。4年前からFaceIDの開発が進められていたってことですかね。対してKinectは生産終了...うーむ。iPhoneのDot Projectorで姿勢検知までできるようになると良いですね。）

もう一つ気になったのは、Apple TVとiPhoneのHDR対応。ディスプレイ側がHDRに対応するとなると、シェーダはどうやって書けば良いんでしょう。HDR対応有無でシェーダ書き分けるのとか面倒そう...

そういえば、Touch IDで他人がロックを解除できる確率は1/50,000とか言っていたけれど、結構確率高くないですか。まぁiPhoneに限らず、指紋認証機能を使っていると、自分の指なのになかなか認証が通らなかったり、他の人の指で解除できてしまったりということが多々あったので、あんまり信用できないか、精度を上げようとするとお金がかかる技術なのかなぁという印象があったのですが。
Face IDは、人工マスクでもロック解除できないことをテストしました、ということでしたが、サーモグラフィでも見ているんですかね。そのうち例によって顔認証をハックしちゃう人たちが現れるでしょう。

　Heroku/Node.js/ExpressでGitHub Appsのユーザ認証 / magicien　

HerokuでGitHub Appsのユーザ認証をするサンプルコード。
OAuth2を使ったユーザ認証だけ。JWTを使ってリポジトリを操作するのは別途。

• セキュリティに関わるコードはなるべく自作しないのがセオリーということでpassport-github2を使ってみる。
• client_id、client_securityはHerokuの環境変数に設定しておく。
• GitHubStrategyのオプションに state: true を設定し忘れると、はまちちゃんが遊びに来る。
• stateには24文字のランダムな文字列が設定される。
• Herokuの場合、sessionのオプションは secure: 'auto'、proxy: true にしないとCookieが発行されない。参考：connectのセッションミドルウェアのcookieのsecure属性について
• 各モジュールのバージョン：
  • express：4.15.4
  • express-session：1.15.5
  • passport：0.4.0
  • passport-github2：0.1.10

　GitHub AppsでOrganizationにリポジトリを新規作成する / magicien　

GitHub Appsでは、今のところユーザ用リポジトリの作成ができない。Organization用であれば作成できるようなので、作成までの手順をメモしておく。

事前準備

Appの作成とJWT生成の準備は「GitHub Appsでリポジトリにファイル追加・更新」と同様に済ませておく。

操作対象のOrganizationを決める

これも前回とほぼ同じなので流れだけ簡単に書いておく。

ユーザを判別する

ユーザに下記URLへアクセスしてもらう。
https://github.com/login/oauth/authorize?child_id=ChildID&redirect_uri=自分のサイトのどこか&state=ランダムな文字列

戻ってきたリダイレクト先でcodeを取得する。
https://自分のサイト/どこかのページ.html?code=1234567890abcdef&state=先ほどのstate

アクセストークン生成

curl -X POST -d "code=先ほどのcode" -d "client_id=ClientID" -d "client_secret=ClientSecret" https://github.com/login/oauth/access_token

応答からアクセストークン取得
access_token=アクセストークン&scope=&token_type=bearer

ユーザが管理していてAppをインストール済みのOrganizationを取得する

取得方法はユーザのリポジトリを見つけるときと同じ。
curl -H "Authorization: token アクセストークン" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/user/installations

Organization用のInstallationは、target_typeがOrganizationになっている（ユーザ用はUserになっている）。

{
  "total_count": 1,
  "installations": [
    {
      "id": 56789,
      "account": {
        "login": "Organization名",
        中略
      },
      中略
      "integration_id": 1234,
      "app_id": 1234,
      "target_type": "Organization",
      中略
    }
  ],
  "integration_installations": [
    {
      "id": 56789,
      "account": {
        "login": "Organization名",
        中略
      },
      中略
      "integration_id": 1234,
      "app_id": 1234,
      "target_type": "Organization",
      中略
    }
  ]
}

installations[i].app_id が一致し、target_typeがOrganizationのものを見つける。 必要なのは、id（installationのid）とaccount.login（Organization名）。

Installationとしての認証

ここは前回と同じ。
curl -X POST -H "Authorization: Bearer JWTのトークン" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installations/先ほど取得したinstallationのid/access_tokens

応答も同じ。

{
  "token": "アクセストークンその２",
  "expires_at": "2017-01-01T00:00:00Z"
}

リポジトリを生成する

公式の説明はここ。
最低限必要なパラメータはnameだけ。
curl -X POST -H "Authorization: token アクセストークンその２" -H "Accept: application/vnd.github.machine-man-preview+json" -d '{"name": "リポジトリ名"}' https://api.github.com/orgs/Organization名/repos

おしまい！

　GitHub Appsでリポジトリにファイル追加・更新 / magicien　

GitHub Appsでリポジトリにファイル追加・更新する手順メモ。ゲームエディタの編集データをGitHubに保存したいと思ったので。手元のMacBook Airの空き容量は500MBくらいで虫の息。シンクライアント的な使い方しかできない状態なのです。

はじめに。GitHub Appsで新規リポジトリを作ろうとしたけどだめだった。ユーザ側でAppを使うリポジトリを決める必要があるので、App側で勝手にリポジトリを追加することはできないのかも。OAuth Appsなら作成できるはずなので、やるとすれば、一旦OAuthで作成してから、GitHub Appでそのリポジトリをアクセス対象に追加する感じかな（Appが2つ必要だとするとユーザ側の操作もかなり面倒なことに...）よくよく見たら、APIの説明に「Currently, only the organization endpoint is enabled for GitHub Apps.」って書いてあったぁぁぁ。Organizationで試してみたら問題なくリポジトリ作れたぁぁぁ。ゲームエディタ用Organization作ってそこでリポジトリ管理することにしよう。その方が安全だし。

GitHub Apps作成

ここら辺はずいぶん前の話で忘れてしまったため適当。

Developer Memberに登録

事前にメンバー登録が必要だったと思う。登録に手間取った記憶がないので、要求されたものを入力しただけだったはず。

App作成

ここの手順通りに実施したはず。
登録手順の前に、GitHub AppsとOAuth Appsの二種類があって、こんな違いがありますよーみたいな話が延々と書いてあって手順を見つけるのに苦労した。

App情報を確認

「Setting > GitHub Apps > アプリ名」を選ぶと、アプリ情報の一覧が表示される。最下部にある「OAuth credentials」の「Client ID」「Client secret」を認証に使うので覚えておく。
「Private key」も必要なので、「Generate private key」ボタンを押して生成、覚えておく。

認証用トークン生成準備

認証には JSON Web Token（JWT）なるものを使うので、それを生成する何らかの仕組みを用意する必要がある。
JWTのページにライブラリがたくさんあるので、良さげなものを選ぶ。
自分はサーバでPHPを使っているので、lcobucci/jwtにした。
JWT生成コードはこんな感じ。 Private Keyはボタンを押して生成したものを貼り付け。setIssuerに指定するIDは「Settings > GitHub Apps」で見られる。
有効期限は最大10分なので、手動でのんびり実行していると時間切れになってしまう。

作ったAppのインストール

もしかしたらアプリ生成の時にインストール先を選択済みかも。インストールしていない場合は、
「https://github.com/apps/アプリ名」にアクセスすると、インストールできる。

操作対象のリポジトリを決める

ユーザを判別する

まずは誰がAppを使おうとしているのか判別する。公式の説明はここ。
ユーザに下記URLにGETでアクセスしてもらう。（child_idはApp登録時にメモしたもの）

stateはリクエストフォージェリ対策で付けておくと良さげ。何か情報を受けわたす為に使っても良い、とのこと。
https://github.com/login/oauth/authorize?child_id=ChildID&redirect_uri=自分のサイトのどこか&state=ランダムな文字列

すると、アプリが認証を要求してるけど？というページが表示される。ユーザが「良いよ！」ということであれば、redirect_uriで指定したURLに戻ってくる。が、この時、codeパラメータが追加されている。stateが先ほど付けたものと同じかどうかをチェックすると良さげ。
https://自分のサイト/どこかのページ.html?code=1234567890abcdef&state=先ほどのstate

アクセストークン生成

ここから先はサーバ・GitHub間でゴリゴリする。
先ほど返ってきたcodeを使ってアクセストークンを生成する。（JWTを使った認証とは別なので要注意）

curl -X POST -d "code=先ほどのcode" -d "client_id=ClientID" -d "client_secret=ClientSecret" https://github.com/login/oauth/access_token

一応、redirect_urlで次のリダイレクト先を指定できるけど、クライアント側からclient_secretを送ることは無いと思うので使い道なさげ。stateも指定できるけど同じ理由で使い道無さげ（GitHub側でcodeとstateの組をチェックしている様子は無かった）。応答はこんな感じで返ってくる。
access_token=アクセストークン&scope=&token_type=bearer

ユーザが使っているApp（Installation）のIDを取得する

Github AppのIDとは別に、ユーザ・App毎にIDが割り当てられているので、それを取得する。
現状、Acceptヘッダを付けないと怒られるけど、そのうち要らなくなるはず。
curl -H "Authorization: token アクセストークン" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/user/installations
応答はJSONで返ってくる。

{
  "total_count": 1,
  "installations": [
    {
      "id": 56789,
      中略
      "integration_id": 1234,
      "app_id": 1234,
    }
  ],
  "integration_installations": [
    {
      "id": 56789,
      中略
      "integration_id": 1234,
      "app_id": 1234,
    }
  ]
}

installations[i].app_id が一致するものを見つけて、installations[i].id を取得する。integration_installationsに全く同じ情報が入ってるんだけど、どっちを見るべきかよくわからん。

アクセスできるリポジトリ一覧を取得する

先ほど取得したinstallationのidを使って、リポジトリ一覧を取得する。
アプリとしては、ユーザに一覧を表示して選んでもらう感じになると思う。
curl -H "Authorization: token アクセストークン" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/user/installations/さっき取得したinstallationのid/repositories
応答はJSONで返ってくる。今回は repositories[].full_name が分かれば良い。

{
  "total_count": 1,
  "repositories": [
    {
      "id": リポジトリID,
      "name": "リポジトリ名",
      "full_name": "ユーザ名/リポジトリ名",
      中略
    }
  ]
}

Installationとしての認証

これ要る？公式の説明はここ。
先ほど取得したアクセストークンだとリポジトリ操作ができないようなので、Installation用のアクセストークンを別途取得する。
最初の方で準備しておいたJWTのトークンを生成して、次のコマンドを実行する。
curl -X POST -H "Authorization: Bearer JWTのトークン" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installations/先ほど取得したinstallationのid/access_tokens
応答はJSONで返ってくる。

{
  "token": "アクセストークンその２",
  "expires_at": "2017-01-01T00:00:00Z"
}

ファイルを追加する

ようやくファイルを追加する。公式の説明はここ。
curl -X PUT -H "Authorization: token アクセストークンその２" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/repos/ユーザ名/リポジトリ名/contents/ファイルパス -d '{"path":"ファイルパス","message":"commitメッセージ","content":"ファイルの内容"}'
オプションでcomitterの情報も付けられる。デフォルトだと、Appのbotがcomitterになる。branchでブランチの指定も可。
contentはbase64にエンコードしないといけないので、base64コマンドを使うなりして変換しておく。

ファイルを更新する

ファイルを追加する場合とほぼ同じ。唯一の違いは、元のファイルのshaを指定すること。

元ファイルのshaを取得する

認証トークンは特に要らない。
curl https://api.github.com/repos/ユーザ名/リポジトリ名/contents/ファイルパス
応答はJSON形式。

{
    中略
    "sha": "ハッシュ値",
    中略
}

ファイル更新

curl -X PUT -H "Authorization: token アクセストークンその２" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/repos/ユーザ名/リポジトリ名/contents/ファイルパス-d '{"path":"ファイルパス","message":"commitメッセージ","content":"ファイルの内容", "sha":"ハッシュ値"}'

　Undo/RedoできるCanvasを作った / magicien　

まーた言ったそばから脇道に逸れているわけ。
HTMLCanvasElement (CanvasRenderingContext2D) に undo/redo機能が欲しいな、と思ったので作りました。
undo-canvas（デモページ１／２）

CanvasRenderingContext2Dのプロパティに片っ端からフックをかますという荒技を使い、変更したプロパティ、呼び出したメソッドを全て記録しています。
副産物として、上書きしたメソッドを prototype で定義されているものに戻す reset-object を別モジュールとして作りました。

使ってみたい人は、scriptタグでundo-canvasを読み込んでください。

<script src="https://cdn.rawgit.com/magicien/undo-canvas/v0.1.2/undo-canvas.js"></script>

ブラウザ向けnpmモジュールを作っている人は、npmコマンドでインストールできます。

npm install --save undo-canvas

jsファイルを読み込むと、グローバル変数として UndoCanvas が定義されるので、

const canvas = document.getElementById('myCanvas')
const context = canvas.getContext('2d')
UndoCanvas.enableUndo(context)

こんな感じで、UndoCanvas.enableUndoにコンテキストを引数として渡してください。contextに undo/redo 関数が追加され、以降、このcanvasに対する操作が記録されていきます。
undo/redoしたくなったら、

context.undo()
context.redo()

で行ったり来たりできます。
undo/redoが必要なくなったら、disableUndoで無効化できます（記録されていた操作履歴は全て消えます）。

UndoCanvas.disableUndo(context)

その他機能はGithubの記載を更新していくので、そちらを参照してください。

undo/redoを実現する仕組みはOracleのようなDBの考え方をぱく参考にしたのですが、思いの外うまくハマったので、気が向いたら解説記事でも書くかもしれません。

さて、今度こそエディタ制作作業に戻ろう...

　React/Reduxでゲームエディタを作る時のメモ / magicien　

色々と脇道に逸れていたけれど、ゲームエディタを作り始めることにした。
フレームワークは勉強も兼ねて React/Redux を使ってみることにする。この選択が正しいかどうかは分からない。間違っていたら作り直せば良いので気楽に行こう。

以前Reactをほんの少し触ったことはあったけれど、存在意義も含めほぼ理解できずに終わったので、今回は1から勉強し直す。以下、困ったことリスト。回答とか感想とかは未来の自分に任せることにする。React/Reduxの正しい設計が知りたくて見に来た人は参考にしてはいけない。

モジュールのバージョンは？

とりあえず最新のものを使おう。React v15.6.1、Redux v3.7.2。それと、React Routerがバージョンによって大きく挙動が変わるみたい。現状最新の React Router v4.2.0 を使う。色々試した結果、react-routerを使わずに、redux-first-routerを使うことにした。モジュールは随時最新化していくことにする。

デザインをどうするか

色々探してみたけれど、結局Bootstrapを使う。というか、他に選択肢が見つからなかった。自由度も良い感じに制限されていて迷わなくて済むし、もうこれで良いんじゃないかな。デフォルトだとボタンの余白が大きいのが少し気になる。スマホ向けには良さそうだけど、PC向けにはもうちょっと小さくしたい。

各国語対応はどうするか

後になってi18n対応するのは大変そうなので、予め設計を考えておく。react-boilerplateがi18n対応していたので、それを参考に実装する。ソースコードに日本語を埋め込むのも微妙だし、デフォルトの文言は英語にしよう。英語用のメッセージ一覧は無くても良いけれど、他の言語に翻訳する時にメッセージ一覧があった方が便利なので用意する。というか自動生成したい。

ルーティングはどうするか

最初、react-routerを使っていたけれど、URLに応じてコンテンツを変更しようと考えたときに、redux-first-routerの方が楽だということに気づき、乗り換えることにした。そのページを表示する直前・直後に実行する処理も書けるし便利。
redux-first-routerを使うと、ページを移動時にURLに応じたactionがdispatchされるようになる。逆に、actionをdispatchすることでページを移動させることも可能。このactionを使ってURLとstoreをうまいこと同期させてあげれば、コンポーネント側でURLを気にしなくても良くなる。いちいちdispatchしなくてもurlのリンクを書いておけばそれに応じたactionが実行される。便利。
この変更によって、redux-sagaは要らなくなってしまった。

データのフェッチはどうするか

react-boilerplateでredux-sagaを使っているので、それに倣ってみる。どうやらGeneratorで実現しているようだ。Sagaの定義はStore/Actionと一緒に置いておく感じかな。actionをdispatchする前にsagaをrunしておく必要があるけど、全ページで全sagaをrunするのは無駄かな。全部runするか、ページ毎に対象を指定するか、うまい方法が無いかは実装しながら考えよう。

今のbabelの設定だと、async/awaitが使えるので、そっちの方が良い気がしてきた。Sagaをrunするとactionの受け取り手が無駄に増えちゃったりするし。GeneratorでもPromiseでも使えるみたいなので、async/awaitに全て移行してしまおう。

テストはどうするか

boilerplateだと各jsファイルの横にtestsディレクトリを作ってテストを書いているようだ。モジュールはJestを使っている。この構成も倣ってみよう。使い方はmocha/chaiとほとんど同じかな？

Undo/Redoはどうするか

これも後から対応するの大変そうだから先に考えておきたい。
大部分のデータは、redux-undoで実現できそう。undo/redoしたい粒度でデータをhistory/futureにとっておく。問題はどういう粒度で何のデータを保存しておくか。エディタのメイン画面はマップエディタにしたいと考えていて、マップの地面の高低はheightmapのテクスチャという形で保存したいと考えている。
この場合、画像編集のデータをどう保存すれば良いのか。画像を丸ごと保存してしまう？グレースケールだから行けそうか...でも変更箇所の差分だけ取っておく方が良いよなぁ。それだとredux-undoの使い方にはマッチしない。Photoshopの実装がどうなっているか知りたい。DBみたいに適当なタイミングでチェックポイント（画像丸ごと保存）を作って、そこからredoが妥当かなぁ。よくよく考えたら、動画フォーマットもそんな感じだよね。でも実装がめちゃくちゃ複雑になりそう。→ Undo/RedoできるCanvasを作った

データの保存はどうするか

一時保存は localStorage IndexedDB へ、永続化はGithubへ、という感じにしたい。Github APIはまだ動作確認中。→GitHub Appsでリポジトリにファイル追加・更新
クライアント側で何を使うかも悩みどころ。IndexedDBはそのままでもシンプルかつ高機能なので、特にラッパー無しでもいけそうな予感。まさか仕様としてブラウザ上にDBが実装されるようになるとは。

ファイル構成をどうするか

Action/Reducer/Selector/Storeを1ファイルにまとめる

React/Reduxの実装例とか見ると、ほとんどの例でファイルが粉々に分割されていて非常に読み辛かった。なので、ducks-modular-reduxを参考に一ファイルにまとめてしまうことにした。テストするときに困るだろうか。

ContainerとグローバルのStateを分離する

ContainerとAction/Reducer/Stateが一対一で対応している例が多かったけれど、その構成のままContainerを100、200と増やしていくと地獄と化すのが目に見えているので、分離することにした。（実装例の規模が小さすぎて1組ずつしか無かっただけかもしれない）
Containerとデータ構造・操作をくっつけると再利用性が上がるのってReduxを使っていない場合の話だよね...？同じデータを複数のContainerで使う時にどう実装すべきか分からない。ContainerにStateを管理させると、設計がぐちゃぐちゃになって拡張が難しくなるようにしか思えない。

最上位のContainer（ページ）は別ディレクトリに分離する

Container同士にも親子関係があるので、同一ディレクトリにフラットに並べると分かりづらい。各画面の最上位のContainerは別ディレクトリに分けることにした。後でページ毎にwebpackするjsファイルを分けるのにも便利じゃないかと思う。

jsのファイル名はindex.jsにする

importするときにファイル名まで書かずに済むから楽なんじゃないかと。

ファイル構成（暫定）

app
├index.html　HTMLの外枠。
├app.js　　Storeの生成、Router、i18nの仕込み。
├pages　　最上位のContainer（ページレイアウト）置き場。
│└pageA
│　├index.js　react-helmetでヘッダ上書き。必要に応じてconnectする。
│　├Component.js　そのページ専用のコンポーネントは一緒に置いてしまう。
│　├messages.js　翻訳対応するメッセージ一覧
│　└tests
│　　├index.test.js　index.jsのテスト
│　　└Component.test.js　Component.jsのテスト
├containers　各ページ共通で使えそうなパーツ置き場
│└containerA　i18n用コンテナとか。
│　├index.js　React.Component等。必要に応じてconnectする。
│　├messages.js　翻訳対応するメッセージ一覧
│　└tests
│　　└index.test.js　index.jsのテスト
├components　各ページ共通で使えそうなパーツ置き場
│└componentA　ボタンとか。
│　├index.js　React.Componentか関数。connectしない。
│　├messages.js　翻訳対応するメッセージ一覧
│　└tests
│　　└index.test.js　index.jsのテスト
├redux
│├configureStore.js　Storeを生成。Middleware、Reducer取り込み。
│├reducers.js　modulesからreducerを一括でロードする。
│├routesMap.js　URLとpagesのマッピングを書く。
││　　　　　　　ページ毎のデータフェッチとかアクセス制御（誘導？）とかも書いておく。
│├modules　ActionType/Action/Selector/Reducer置き場
││└moduleA
││　├index.js　全部まとめて一ファイルに。reducerをexport defaultする。
││　└tests
││　　└index.test.js　index.jsのテスト
│└tests
│　├configureStore.test.js　
│　└reducers.test.js
├translations
│├en.json　英語用メッセージ。自動生成したい。
│└ja.json　日本語用メッセージ
├config
│└index.js　convictを使って説明とか型とか書いておく。
└tests
　└app.test.js　app.jsのテスト

Code Splittingはどうするか

webpackするときに、ページ毎のjsと共通のjsをそれぞれ別ファイルにしたい。
「React + Reduxを使った大規模商用サービスの開発」だと、require.ensureを使っていたけれど、例によってReactRouterの仕様変更によりそのままでは使えなかった。
でもReactRouterのページにCode Splittingの方法が書いてあったので、それをそのまま使うことにした。bundle loaderがうまいことやってくれるらしい。生成されるjsファイルは、0.[ハッシュ].chunk.js、1.[ハッシュ].chunk.js みたいになっていて、ページ数が増えると数字がずれたりする。上の資料だと、モジュールの並び順を制御してハッシュ値が変わらないよう工夫していたけれど、今回はそこまで神経質にしなくても良いかな。
react-routerを使うのをやめたので、代わりにuniversal-importを使うことにした。大してコード修正せずにそのまま乗り換えられたので一安心。

Stateに溜まったゴミはどうすればいいのか

画面遷移を続けていくと、Stateにゴミデータがどんどん溜まっていく。データの後処理はどうするのが良いのかな？これもReduxを使うが故の悩みだろうか。

ネット上の情報はいろんなバージョンのReactを使っていてよく分からない

バージョン間の差異が大きすぎる。どうしたらいいんでしょうか。とりあえず半年以上前の記事は話半分で読むことにする。

参考になったもの

React + Reduxを使った大規模商用サービスの開発

画面とかStateとか大量にある場合の設計の実例。実サービスとして作っただけあって、実践的。本格的に作り始める前にこの資料を見つけられて本当に良かった。性能測定はどうやっているのだろう。

ducks-modular-redux

action-types/actions/reducersを別々のファイルにしてもあんまり意味がないから一つのファイルにまとめちゃおうという提案。自分も同じ疑問を持っていたので、しっくりきた。

react-boilerplate

実際にReact/Reduxのアプリを作る上で最小限必要なものが一通り揃っている。i18n対応しているのが非常に素晴らしい。Herokuへのデプロイに対応しているのもポイント高い。React Router v3だったので、残念ながらそのまま使うことはできなかったけれど、大いに参考になった。

wp-calypso

WordPressのReact/Redux実装。大規模アプリの実例として参考になった。規模が大きすぎる気がしなくもない。ライセンスがGPLなので要注意。