@nqounetです。
ずっと気になっていたYeomanを使ってみました。
THE WEB’S SCAFFOLDING TOOL FOR MODERN WEBAPPS
[Yeoman - Modern workflows for modern webapps]
感想を一言で言うと、何故今まで使わなかったんだ!オレのバカ!!って感じです。
今まで特に不自由と思っていなかったことが、実は不自由なことだったことに気づきました。
使いたいと思いながら手を付けなかったのですが、とりあえず個人のサイトでデプロイまでやってみて、色々と楽にできるようになりました。
昨日までの管理方法
個人のサイトはVPS上にnginxを使って公開しています。
サーバの設定は、gitで他のバーチャルサーバと共に管理しています。
ウェブのコンテンツは、コンテンツだけでgit管理して、デプロイはcinnamonを使っていました。
このうち、ウェブのコンテンツの作成とデプロイの部分をyeoman(というかほぼgrunt)で管理できるようになりました。
今日からの管理方法
yeoman一式は、node.jsで動作しています。
だいぶ前にnodeを入れた事はあったのですが、何故かnode自体を管理するのが面倒な思いがあって、その気持ちが一歩踏み出せないところだったかもしれません。
しかし、今回nodeをインストールするために、ndenvを使ってみることにしました。
そして、ついでなのでplenvやrbenvもまとめて管理できるanyenvに変更することにしました。
こういう便利なプログラム(アプリ)を使うと、本当に便利な時代になったなぁと思います。
あ、Windowsではどうすればいいんでしょうね。
あまりコマンドプロンプトを使いこなしていないのでアレですが、nodeを入れるにしてもrubyもperlも全てインストーラを使っています。
記憶が確かならば、vagrantを入れた時にmingwが入ったにも関わらず、rubyをインストールするときに別でmingwが入ってしまうことに非常に嫌な気持ちになります。
Chocolateyを使えばよかったのかもしれませんが、あまり使わないので思い出せませんでした。
それは置いておいて、MacOSXでの環境構築は割と簡単でした。
anyenvのインストールからndenvのインストールまで
anyenvをインストールするときは、これまでに*envを使っている場合は、今までの設定を取り除く必要がありますので注意が必要です。
それ以外については、githubにあるanyenvのINSTALLに書いてあるとおりです。
ndenvをインストールすると、ndenv-buildも自動的に入れてくれるのでbuild環境も手にはいります。
インストールできるnodeのバージョンを見るといろいろ出てきますが、Node.jsの日本ユーザグループによると、マイナーバージョンが偶数のものが安定版のようなので、v0.10.xの最新版を入れることにしました。
|
|
yeomanをインストール
ndenvでnodeを入れると、パッケージ管理のnpmもついてくるので、npmを使ってyeoman一式を入れます。
|
|
オプションに-gを付けないと、そのディレクトリ内にnode_modulesができてそちらにインストールされます。
この辺の潔さは、今風という感じですね。
ウェブサイト(のひな形)を作る
一式が入ったら、新しいディレクトリを適当に作ってジェネレータを起動します。
|
|
起動すると、オプションが選べるので、必要なオプションにチェックを入れておくと(若干)最適化されます。
今回のウェブサイトの場合は、あまり影響がなかったので既存のリポジトリにそのまま突っ込みました。
基本的にコンテンツはappというディレクトリの中で作成します。編集するのはほぼここだけです。
作成中はテスト用のサーバを起動させることができます。
|
|
個人のサイトはindex.htmlだけなので、ファイルの中身を変更したり、rootにあったファイルをappディレクトリの中に移動したりしました。
色々と変更する度にブラウザがリロードしてくれるので、特に画面が広い場合は変更後の状態を常に確認しながら作業できるのが便利です。
詳しい仕組みはわかりませんが、WebSocketか何かでブラウザにリロードするようにしているようです。
今まで深く考えずに手動でリロードして確認していましたが、その手順がなくなるだけでかなり違うのがようやくわかりました。
これは、百聞は一見にしかず、というしかありません。
これを読んで想像する状況よりも遥かに良いです。
公開(デプロイ)まえの一手間
公開するのはappディレクトリをそのまま使っても良いのですが、gruntのコマンドで色々とやってくれるので、そちらも試してみます。
|
|
引数を省略すると、defaultのタスクが実行されます。
JavaScriptの文法も結構細かく見てくれるようで、なかなかうざいこともあります。
エラーで進めなかったら、buildだけにするのも手です。
|
|
Gruntfile.jsを見ていて気づいたのですが、公開用の確認も手元で簡単にできるようになっていました。
|
|
このコマンドだと、buildを実行してから表示してくれるので便利です。(bootstrapを使っていると、フォントが表示されない問題があるようですが、これは、公開ディレクトリにコピーしてくれているフォントファイルのパスが違うからです。分かる人は設定のcopy:distの中を修正すればよいのですが、このへんで躓くとappを公開する感じになるんでしょうね)
公開の状態が問題なさそうだったら、いよいよデプロイです。
gruntでrsyncする
デプロイツールとしては、静的なウェブサイトでもサーバにsshでアクセスできればcinnamonを使っていました。
yo webappで作成すると、公開用のディレクトリdistはgitの管理外になります。
.gitignoreからdistを外してアレコレするような記事があったのですが、それだとプログラムで自動的に変換されたファイルを管理することになるのでイマイチだなと思いました。
なので、必然的にgitを使わない選択しかできません。
今回はファイルを転送するだけで完了するのでftpでも良いわけですが、サーバでrsyncが使える場合はこれを使うのが良さそうです。
検索してみると、ありました。さすがですね。
Gruntfile.jsに手を入れる必要があるのでゾッとしましたが、細かい部分は日本語の情報もあったので助かりました。
npmでインストールします。簡単ですね。
|
|
情報によると、gruntに対してモジュールを(grunt.loadNpmTasks('grunt-rsync')のように)登録する必要があったようですが、最近はそのへんも自動化されているようで、インストールしたあと設定を書くだけで使えるようになっていました。
|
|
余計なオプションもある気がしますが、ひとまずはこんな感じです。
本番前にはdryRun: trueを付けておくと幸せです。
srcは、最後の/が決め手ですね。これがないと、destの配下にディレクトリが作られてしまいます。
パッケージ管理今昔
npmでインストールするとき、--saveしておくと、package.jsonに情報が登録されます。bowerも同じオプションがあります。
npmでインストールするものはpackage.jsonで、bowerでインストールするものはbower.jsonで管理されます。
git cloneした時にcarton installするのと同じようにnpm install && bower installするということですね。
プロジェクト(アプリ)毎のパッケージ管理方法の進化に目が回ります。
昔はこの手のものはインストールするのが大変なイメージがありましたが、今やコマンドを入力してトイレに行って戻ってくれば使える状態になってますね。
Gruntfile.jsを管理するのは大変かもしれませんが、ye webappで作られるものは扱いやすいと思います。
私でも何とかなる程度には親切設計ですよ。
ブラウザの自動リロード機能だけでも十分に使う価値有りです。