まとめ
- Rails 4.2 で既存の AssetPipeline にまったく手を加えずに Webpacker を導入しました
- Webpacker は導入から deploy まで簡単でよい
- Webpacker のサイトの情報だけでなく、Webpack も Yarn も（そこそこ）追っておこう
- さすがに Node.js と npm もさすがにね
前提知識
- Webpacker は AssetPipeline とは独立した RailsEngine であり、共存できる
- Webpacker は Yarn で Webpack を入れるのでそれぞれについてある程度知っている必要あり
- （使うだけならインストール方法と簡単な使い方の手引きがあればよい）
決めなきゃいけないこと
- Webpacker で AseetPipeline を置き換えてしまうか否か
決めたこと
- AssetPipeline は AssetPipeline でそのままにする
- /app/javascript/ はさすがに狂ってる気がするので /app/webpacker/ に置くことにした
webpack 管理が webpacker 管理の他に生まれるということは基本的に考えていない。
根拠
- まだ Webpack やモダンJS、モダンCSS に習熟したエンジニアがプロジェクトの中心にいない
- 既存のコードについて は 熟練工がすぐに必要な状況ではない
- ただし、新規では Vue.js を使ったアプリを追加する予定
- これを AssetPipeline + CoffeeScript + jQuery で書くかというとそれはイヤだ
感想
個人的にはこれまで Browserify に寄せててどうしても Webpack と仲良くできる気がしてなかったんだけど、そんな自分でも Webpacker の導入は非常にスムーズに進んだ。
特に deploy について何も気にしなくてよかったのは本当に助かった。ビルドシステムを作ることに頭を使うのは全然やりたいことじゃないので。
ただ、やはり事前に少なくとも Node.js と Yarn の知識はあった方がよい。Webpacker のドキュメントでは Node.js 6.0+ / Yarn 0.25+ って書いてあったけど、Webpack はすでに "The current Long Term Support (LTS) release is an ideal starting point." と言っている。Webpacker はあくまで Webpack と Rails が仲良くする手法の一つなので、あくまで本家情報を大事にしよう。
おまけ
rake ( Rails 5.1- ) webpacker:install と rake webpacker:install:xxx は違う。そりゃそうだ。
- Heroku は package.json の情報を解釈してくれるので engines とかでおk
- CircleCI は package.json を解釈してくれないので circle.yml の中でこんな感じ ( 1.0 の場合 )
参考
- rails/webpacker: Use Webpack to manage app-like JavaScript modules in Rails
- webpack
- Webpackerを使ったRailsでのJavaScript開発 - クックパッド開発者ブログ
- 考え方が参考になる
- Rails & Webpackerでフロントエンド開発環境を整える - Qiita
- 手順が参考になる
- Webpacker 3ではじめるRailsエンジニアのためのモダンフロントエンド入門 〜Sprocketsを使わないRailsプロジェクト試案〜 | blog.tai2.net
- AssetPipeline 捨てるべき論
- Webpackerのディレクトリ構成をRailsから切り離す形に変える方法 - Qiita
- Webpacker独自の場所じゃない方がよくね論
- WebPackを使ってRailsからJavaScriptを楽に良い感じに分離する - Qiita
- ビルドだけ AssetPipeline から分離する
Webpack 2 との比較
終わってみればプログラムは4ネタでとても濃かった
- コードリーディングいいよ。エディタで読むといいよ。Rubyだとrtags使うといいよ。 ( @Yukimitsu_Izawa )
- TDD（パーティの最後尾の攻撃魔法）からATDDへ踏み込んだら「価値」を共有しやすくなって、思っていたものと違うものができるとか、減るかな。ユーザーストーリーっての勉強すればいいの？ ( @wtnabe )
- meetup #6, #7 作戦会議
- コードレビュー
の4ネタ。プラスして例によって参加者独自に自習。
後半の2ネタが結構ヘビーだった。
rtags は gem の 0.9.7 はいきなり SyntaxError で落ちちゃったので自分で 0.9.8 のコード取ってきて install を実行する必要がありそう。この辺、pull-req も投げられてるけど止まってるっぽい。あんまり使われてないのか？
個人的には Intro を含めて2ネタ喋るというのをよくやってるんだけど、今回はどちらも貯金なしからの最新ネタで、とても準備と喋りに気を使って疲れた。（スライドの完成度はともかく）
そしてその流れのまま meetup #6, #7 のビッグイベント、ビッグゲストへ向けて準備開始。
コードレビュー
そしてコードレビュー。
コードレビューの話もあるけど Ruby っぽいコードの話をしたいと前から思っていて、今回はそれなりの長さのコードだったので Ruby っぽさについてたくさんの話ができたように思う。特に破壊的か否かのくだりは個人的にぐっときてて、その流れで each で副作用ベースで処理していたメソッドを map の副作用なしメソッドに直すところまでいけたのはなかなかよかった。（自画自賛）
副作用がなく、長さが短く、名前がはっきりしていて内容が容易に想像できるコードがやはりバグが入りにくいので、そういうことをくり返し言っていたように思う。ブロック内の登場人物（変数）は少ない方がいいのだ。
ということでちょっと睡眠時間が足りないのもあったけど、終わったときは本当に疲れた。
準備
2次会で聞かれたけど、準備は…スライド作るだけなら20時間は掛かってないかな。15時間くらい？ ただしネタの掘り起こし、インプットには結構時間掛かってます。特にATDDとユーザーストーリーの話は自分でそんなことを喋るようになるとはまったく思ってないところからのスタートで、単に The RSpec Book を読み切りたいというだけだったので、読んでから文字に起こして発表の形が見えてくるまでずいぶん時間が掛かってちょっと焦った。結局、3日前に一応形はできたのでスライドできなくて徹夜とかは避けられてよかった。体調をベストに持って行かないと kanazawa.rb はフルで楽しめないからね。
安かった
懇親会は今回 3000 + 2000 + 2000 円で、1時すぎまで呑んで1万円掛かってないとかどういうことだ。
次回 meetup #6 は 2/16(土) 13:00 よりクラウド祭り!!
Meetup #6 冬の金沢クラウド祭り!! - Kanazawarb
です！ 金沢でクラウドの入門から作り方まで聞けちゃうよ！
すっかり忘れていた。
- 少なくとも CentOS では webmaster -> root の alias があるので webmaster アカウントで cron を動かしても webmaster 宛にはメールは来ない
- /etc/aliases をいじったら newaliases を実行しないといけない
- ~USER/.forward は 0600 で
shlauncher を使ってこの辺のメールを投げるような処理もまとめていった方がいいかもなぁ。
起動順を制御したい背景
先日、God + tig.rb 環境に移行したわけだけど1、実際には自分の irc 周りの環境は下の図のようになっている。
twitter
|
internet
|
+----+ +---+--+
|ircd| |tig.rb|
++--++ +---+--+
| | |
+--+ +-+ +---+
| | |
+---+--+ +-+--+-+
|nadoka| |tiarra|
+------+ +---+--+
|
LimeChat ( Mac or iPod )
拙い図だけど四角で囲んである部分は自宅サーバ内で動いているプログラムである。制御したいプログラムだけ抜き出すと、
| tiarra | proxy |
| nadoka | bot |
| tig.rb | twitter gateway |
という構成になっている2。
そしてここからが大事なんだけど、
起動の順番としては tiarra がいちばん最後
である。
God 以前
God 化する前、これらは単に sh スクリプトから順番に起動するだけだった。
nadoka
sleep 2
tig.rb
sleep 2
tiarra
である。サーバサーバなんて偉そうに言っといて中身はこんなもの。途中で何かの拍子にどれかのプロセスが落ちたらそれだけまた起こし直す。全部手動で、厳密には daemon プロセスではなく
ただずっと起きっぱなし
の状態になっていた。サーバ管理的にはあまりに稚拙だが、こと起動順に関しては
書いた通りの順番に起動する
という分かりやすいものだった。しかし God 化してしまうとこうはいかない。
God の起動の流れ
0.8.0 で確認したところ、以下のようになっている。
- God.watch の指定を読み込めるだけ読み込む
- watch の name を key にとる Hash に放り込まれる
- 読み込み終わったら Hash から一つずつ取り出し、autostart を指定してあったら（default で true）ただちにプロセスの起動を行う
ということは少なくとも Ruby 1.8 では
God.load の読み込み順、God.watch の出現順とプロセスの起動順は無関係
である。
はて困ったな。
無理矢理解決してみた。
ここでは単にプロセスの起動順序だけを問題にしたいので tiarra や nadoka など実際に使ったプログラムではなく、先日の xig_installer で動かしやすくなった tig.rb と wig.rb で試したみた。
上の gist のファイルを適当な名前で保存して
god -c CONFIG
で起動すると
必ず wig.rb の方を後で起動することができる。
順番は
ps ax | grep ruby
して PID を確認すると分かる。
ポイント
- あとから起動したいものの God.watch の記述の中で autostart = false を加える
- watch 定義のあとに Thread.new {} の中で無理矢理待ちたいプロセスの起動を待つ
待ちたいプロセスの様子は God.status[NAME][:state] で確認することができる。
実は、こんな書き方でいいのか分かってない。本当はもっといい書き方、正しい書き方があるのかもしれない。探したけどまだまだ God の情報は少ないし、英語になるとどういう言葉でこれを探せばいいのかも分からない。
でも目的は達成できている。
参考 - God.load の流れ
God.load は指定された設定ファイルを読み込むものなんだけど、内部で Dir.glob を使っているので一つずつファイル名を指定しなくても
God.load File.dirname( __FILE__ ) + '/*.god'
なんて書き方でまとめて読み込むことができる。最終的には Kernel.load が呼ばれるので Ruby の文法に則っていないと、この時点で弾かれる。
最初、読み込み順でプロセスの起動順を制御できるかと思ったけど違ったのでこの部分の読み込みはあんまり活かしようがないのであった。残念。
自分でちゃんと確認したわけではないんだけど、どうやらそうらしい。まぁ更新が止まったままだったのでいつかこの日が来ることは分かっていたわけだけどね。
rssh にしかない機能もあるけど、諦めて scponly に移行すべきでしょうな。
我が家のディスクはレコーダ以外は Seagate ではなかった。仕事関係のディスクに Seagate のものはあったけど型番外れ。
しかし knowledge base にしか情報がなくてニュースリリースになってないのはどうなんだろうな。まぁまだ調査段階なのかもしれないけど。
作ってみた。ヘボいモノなのに shell スクリプトがロクに書けないので Ruby になってしまっていますごめんなさい。
ほんとは保存ファイル名もオプションで渡したかったんだけど、「あるオプションだけ取り除いて残りを crontab に丸投げする」という処理をどう書いたものやら、考えるのが面倒くさくなったので決め打ちになってます。
一応機能としては
- すべて crontab コマンドに丸投げする
- -e オプションが与えられた場合は、設定完了後自動的に -e を -l に置き換えて crontab -l > ~USER/.crontab を実行、内容を保存する
ということをやってます。
自分はこれを alias にセットして安心しております。
wtnabe's crontabwrap at master - GitHub
[2010-10-09 追記]
ベタにここに貼るのをやめて github に上げて gem 化しました。
gem install crontabwrap
でインストールできます。
コメントにあった
sudo などで現在実行中のユーザーが変わった場合、~/.crontab が別のユーザーの内容で上書きされてしまう問題
を修正したつもりです。
Re:単一思考の恐怖 ("子ども部屋に侵入したゲーム、ネットという麻薬「脳内汚染」", /.-j)
○○が悪い
というのは何にでも言えるというスレッドの中でスパっと「ゆとり教育」が出てきたので思わず吹いてしまった。確かに一瞬ネタかマジか判断に迷うけど、これはネタでしょ。1
というかゆとり教育なんてものはマスコミのでっちあげであって…げふんげふん ↩
すぐに何かするわけじゃないけど @IT 自分戦略研究所よりメモ。
例によって textfile.org 経由で わかりやすさは、ただの表現技術の問題ではないのだ。
わかりやすさは器用な解説屋さんの小手先テクニックじゃない。もっともっと本質的なものだ。
はいここテストに出しますよ。勝手に言い直すとばか丁寧に書いたって決して分かりやすくはならない。
※ 自分の中でこの日記は「自分が分かるために書く」ものなので、書かれたものは決して分かりやすくはありません。
- 「ページ」をフラットなテキストではなくヘッダとボディに分け、「オブジェクト」として機能するページを構成する
- ZWiki を使ったことがある人には分かりやすいかな？
- こうしておけば認証の設定やページの親子関係、カテゴリなどの情報を簡単に保持できる。もっと簡単な例で言えば alias や URI として現れるページ名と実際のページタイトルを分ける、なども思うまま。（ただしインターフェイスが難しいけど）
- テキストファイルをストレージにする場合はヘッダを YAML とかにすればいいかな？ テキストファイルをストレージにするのは以下のメリットがあると考えている。特に3番を考えると XML 化しちゃうのはなんか邪魔くさいだけのような気がする
- DB が壊れて全部オジャンという事態を避けられる
- バックアップを差分で取るのも簡単にできる
- テキストツールでガリっと内容変更できる
- 記法もストレージも認証方法なども自由に選べると嬉しい
- CMS としての利用を考えると汎用 DIV コンテナを生成できると嬉しい
- もいっちょ静的 HTML の吐き出しも普通にできるとチョーいい
- 現在も Wiki によっては複数の記法をサポートしているけど
Wiki原理とは異なると思うけど、このように思うのは技術ドリブンでいたずらに複雑にすることが目的ではなく、one resource, multi use を志向した結果。要するに「ページ」の持つ情報に冗長性がほしいということ。Wiki はとても便利だが、Wiki 上の情報を Wiki にアクセスしない人間にも提供したいという要求には simple なだけでは応えられない。
ついでに Wiki ベースのユーザーによる編集を想定しない CMS は
Wiki 単体で考えるのではなくリバースプロキシ込みで考えるべきだと思う。やっぱ Wiki って重いんで。
情報共有について考えていたときに ML と RSS を使うのはよさげな方法だと思った。
qwikWeb のような ML + Wiki であればわざわざ RSS を別に使う必要はないかなという気もするが、qwikWeb が Wiki の変更をメールに逐一流すかどうか分からないし、流れてこない方が ML が汚れないという判断もあるような気がする。
要するに目的は作業スペースからの更新情報と、作業スペースより上位のフレームでの議論を手軽にシームレスに扱いたいということだ。これを思いついたのは Thunderbird が RSS リーダを内蔵しているから。1Wiki の変更を補足しつつ ML で内容や方針の議論を行う。これはとてもよい方法だと思う。2blog を書くことだけにフォーカスしていない RSS リーダーの使い勝手は重要だな。今でもよほど感度の高い人でないと RSS なんて使ってないんだよなぁ。blog や技術ネタのサイトばっか見てると全然分からないことだけど。
qwikWeb は特定の WikiEngine にバインドされるから、Wiki 側で様々なユーザー認証を pluggable に実装し、なおかつそれが汎用のフレームに育ってくれるといいのかな？ ML マネージャを別なものにしたいと思う人もいるだろう。難しいなぁ。
実現性を無視して、ほしいツールは「proxy付きWeb付箋（wema3?） + reStructuredText で書ける Wiki + ML」なのかな。ただ、ML も Wiki も案外普通の人には使いこなすのが難しいものだってのがネックだけど。
- http://www.nn.iij4u.or.jp/~tutimura/sitecopy/
- http://www.lyra.org/sitecopy/ 本家
- http://quake2.kuciv.kyoto-u.ac.jp/~ono/sitecopy/
なんかものすごく幅広い対応ですな。これ使って Zope からオブジェクトを引っ張り出すのがいちばんいいのかな。
基本的に古い。