Rails5でenable_dependency_loading = trueするのはどうなのか
Ruby on Rails5では，production環境でのautoloadが廃止されました．
Upgrading Ruby on Rails — Ruby on Rails Guides
Rails5では，その代わりにeager_loadを行なっていて，これはデフォルトでは，autoload_pathsにデフォルトで指定されているファイルと同じファイルをアプリケーション起動時に全て読み込んでおくということになっています．
よく lib 以下を config.autoload_paths << Rails.root.join("lib") といった風に追加しているのを見かけるし，実際に自分もやっています．
ここで問題になるのが， autoload_paths に lib 以下を追加しているので，もちろんproduction環境時にlib以下が読み込まれなくなってしまうということです．
ここでさっきのGuideを読むと，
For the vast majority of applications this change needs no action. But in the very rare event that your application needs autoloading while running in production mode, set Rails.application.config.enable_dependency_loading to true.
「圧倒的大部分のアプリケーションは何もする必要がない．puroduction環境で実行中にautoloadingする必要のあるとてもめずらしいアプリケーションの場合は， Rails.application.config.enable_dependency_loading = true にしてください」と書かれています．
じゃあRails.application.config.enable_dependency_loading = trueすれば良いんだ，ということではないです．
圧倒的大部分のアプリケーションでは何もする必要がなく，trueにするのはメチャクチャまれだとかなり強調して言っています．ここは，ちょっと調べないといけないなと思うわけなんですが，面白いissueがあります．
色々議論されているんですが，eager_loadの場合も，autoloadingしていてスレッドセーフじゃないということなんですが，スレッドセーフの問題があったようです…．
If developers follow our guidelines of not changing autoload_paths, adding directories to app for autoloading code and explicitly requiring code in lib then Rails will be threadsafe.
threadsafeにするには，私たちのガイドライン（非公式）に従ってautoload_pathsを変更せずに，明示的にrequireすると良いとかかれています．
とにかくautoloadするのはスレッドセーフの観点から良くないということがわかります．
なので解決策としては，
1. app以下にlibを持っていく
読み込まれる必要のあるコードをapp以下にlibディレクトリなどを作って，置いておく
2. とにかくrequireする
3. lib以下をeager_load_pathsに追加する
autoload_paths同様にeager_load_pathsが指定できるので，ここで lib以下を指定する方法ですが，Rakeタスクなどあると思うので良くない
4. 必要なファイルを適宜requireするか、eager_load_pathsに追加する
まあ良い
あたりがあるのではないかと思われます．
自分も知らねーという感じだったし，こういったことは公式でドキュメントにすべきだというissueが立つも完全スルーのまま終わったり，
Upgrading guideもスレッドセーフなどには触れずにかなり曖昧な説明にしているあたりに特別な何かを感じるのだが，これは一体
ニコニコ検索APIクライアントのnpmパッケージを作っている
ニコニコ検索APIのパッケージは結構あるんですが，古いエンドポイント使ってたり，Promiseベースじゃなかったりするので，作りました．
ニコニコ検索APIのドキュメントがどこにいってしまったのかリダイレクトされるようになってて謎なんで，これは後で調べて直すと思います．
Electronで開発しているニコ生のコメビュも兼ねたデスクトップクライアントの開発で使うために作っているので執筆現在，まだニコ生の検索しか実装できていません．
これはalminを使っていて面白いのですが，それはまた落ち着いたら書こうと思います．
HTTPクライアントにaxiosを使っています． 色々ライブラリを見てみたのだが，クラス化してHTTPクライアントのインスタンスを初期化して保持したいというのとPromiseということを考えるとaxiosが良いのではないかという感じです．
気が向いたのでesdocを真面目に書いてみたのですが，中々キレイにわかりやすく出力されるので，書くのもモチベーションが上がって良いです．
npmパッケージはおそらくまともなものは書いたことなかったんですが，題材にAPIクライアントは良さげで，普段業務でJS書いたりもするので，実際に趣味でゼロから書くと実は抜けている知識とかあったりするので良かった，yarn使ってみたりも良かった．
ニコニコ関連のアプリを作るときに検索する必要がある方は，他サービスにまだ対応できていないですが，良かったら使ってみてもらえたらと思います．
ユーザーストーリーマッピング読んだ
- 作者: Jeff Patton,川口恭伸,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/07/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (7件) を見る
結論から言うと、大変良い本だった。
内容的には、アジャイルやリーンスタートアップなどに多く言及しており、デザイン的な話よりもサービス作りにおいてユーザーに使われるサービスをいかに作っていくのかということが書かれている。
モノづくりにおいてつい忘れがちな基本的なマインドとか、チームでいかにして、ユーザーにとって使われる必要なモノを、共通理解を確認しながら同じ方向に向かって、作って、そして改善していくのかということが書かれている。 いくつかのプラクティスの実際の例はあるが、それはそれで参考にしながら適当にするとして、それ以上に学びがあったのは、サービスの中身を作っていくにあたってのこういったマインドの持ち方だと思う。
以下にメモのほんの一部を抜粋する。この本は結構ボリュームがあるので、引っかかるワードがあれば幸いです。
- ストーリーは、要件を形式に落とし込むためのものではない。言葉と絵を使いながらストーリーを話すのは、共通理解を築くためのメカニズム
- ストーリーは要件ではない。会社、顧客、ユーザが抱える問題の解決についての議論であり、何を作るかについての意見を一致に導くもの
- 異なるタイプのユーザーをリストアップした。彼らがどのような利益を手にするのか、彼らがなぜその製品を使うのか、彼らがそれで何をすると思っているのか
- 目標とする成果、獲得しようとしている特定のメリットがわかっていなければ、優先順位付けはほとんど不可能だ
- オポチュニティ
- 大きなアイデアとは何か？
- 顧客は誰か？
- この製品を買いそうな会社はどこか？
- ユーザーは誰か？
- それらの会社でこの製品を使いそうなのはどういうタイプの人々か？彼らは製品を使って何をするか？
- 彼らはなぜ製品を使いたいと思うか？
- 顧客、ユーザーは、今解決できないどのような問題を解決しようとするか？
- なぜ私たちはそれを作るのか？
- この製品を作り、製品が成功を収めたら、それが我が社にとってどのような意味を持つか？
- 解決しようとしている問題が、本当にあるかどうかを確かめよう
- すべてのリリースを実験として扱い、何を学びたいのかを忘れないようにしよう
- いつもターゲットの顧客、ユーザーと、望んでいる成果を忘れないようにしよう
- あらゆるタイプのユーザーから、同じすばらしい成果を得るのは本当に難しい。だから、対象を絞るのだ
- 偉大な芸術に完成はない。あるのは途中で投げ出されたものだけだ。 - レオナルド・ダ・ビンチ
- ストーリーにおける会話とは、双方が理解している問題をもっともよく解決する方法に到達するために共同作業をすることだ
- [ユーザータイプ] として、私は [これこれの結果を得る] ために、[これこれを] したい
- 構築する価値のあるソリューションを見つけるのである。このとき、ソリューションを最小限に抑えることを忘れてはならない
- あなたのソリューションを使うはずの顧客とユーザーは誰か？
- 彼らはあなたのソリューションなしで今どうやってニーズを満足させているのか？
- あなたのソリューションが作られると彼らにとって世界はどのように変わるのか？
- あなたのソリューションはどのような形に見え、どのようにふるまうのか？
- あなたのソリューションの構築にはどれくらいの期間がかかるのか？
- 優れたプロダクトオーナーは、自分が良い判断をするために必要な人々をまわりに集めている
- プロダクトマネージャーの仕事は価値があり、使いやすくて、実現可能な製品を見極めること
- 私たちはほとんどの場合間違っている
- デザイン思考
- 共感
- ユーザー、顧客と直接話そう。彼らのために解決したい課題を実際に経験しよう
- 定義
- これから重点的に取り組む「特定の人々」および「特定の問題」を選ぶ
- ユーザーの苦痛ポイントとユーザーが求める褒美の理解に注力しよう
- 1つまたはごく少数の問題だけに本当に絞り込みをかけ、それらを具体的に実現する
- アイデア創出
- 最初の自明なソリューションは、要するに自明なので、イノベーティブなソリューションを考えることが大切なら、自明なアイデアを越えて考えなければならない
- プロトタイプ
- シンプルなプロトタイプを作って最もすぐれたソリューションを研究しよう
- さらにプロトタイプを改良して、ユーザーと顧客の問題が本当にソリューションによって解決されるかどうかを、ユーザーと顧客自身が評価できるくらいまで、プロトタイプを改良しよう
- テスト
- あなたの製品を買ったり使ったりするかもしれない人々の前にソリューションを置いてみよう
- 最初から成功すると思ってはならない
- 反復的に改良していこう
- 共感
