reveal.jsを使ったWebプレゼンツールはもうあった

数ヶ月前に、Markdownでプレゼンを作成できるツールを探していて見つけたreveal.js。

せっかくブラウザでプレゼンを表示できるなら、Web上で作成から表示まで完結できるようにしたらいいのにと思い、Herokuに作りかけたまま放置していたRailsアプリがありました。
http://webslides.herokuapp.com/

最近reveal.jsがやや注目されているのかなと思っていたところ、なんとrvl.ioというreveal.js作者さんによるオンライン版が既に公開されていることを、こちらのブログで知りました。

さすがに、とてもよくできています。

ということで、作ろうと思っていたRailsアプリはこれ以上開発する必要がなくなりましたが、せっかくなのでソースコードを公開しておきます。
https://github.com/hiroki23/WebSlides

アプリ的には、ActiveRecordではなくMongoDBを使っていること、SlimというHamlのようなテンプレートエンジンを使っていること、decent_exposureというgemを使っていることなどが特徴です。

decent_exposureについては、このあたりがわかりやすいです。
RailsCasts#259
http://blog.remarkablelabs.com/2013/01/how-to-decrease-coupling-in-your-controllers-views-with-decent_exposure-for-better-maintainability

Twitterログインなどで利用したomniauthも、RailsCastsを参考に実装しました。
RailsCasts#241

GitLab CI

今やプライベートなGitリポジトリ管理の定番のひとつになりつつあるGitLab。
そのGitLabと連携するCIサーバーが公開された。

Continuous Integration Server From GitLab
http://blog.gitlabhq.com/continuous-integration-server-from-gitlab/
https://github.com/gitlabhq/gitlab-ci

GitLabの開発速度やクオリティには本当に驚かされるが、同じ開発者が手がけるGitLab CIもすごいソフトウェアになりそう。

Ruby 2.0では（UTF-8なら）マジックコメントが不要になるか

何気なくRailsのコミットログを見ていたら、こんなコミットが。

Ruby 2.0.0 defaults source encoding to utf-8 so we need to specifically tag this file with us-ascii
https://github.com/rails/rails/commit/8f3f50a3cca98a322083269562d446498825ad5f

ぐぐってみるとRubyのsvnログ（11/6）を発見。

set default source encoding as UTF-8 instead of US-ASCII
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=37485

Ruby2.0では # encoding: utf-8 というマジックコメントは書かなくてよくなるかもしれない。
Ruby1.9では文字コードに悩まされることが多々あって、みんなよく我慢してるものだと思っていたので、この変更はとてもうれしい。

SlimかHamlか、Rails Rumbleで使われたGem

Slim

Railsのテンプレートでは、ERBにするかHamlにするかという選択になるのが一般的ですが、比較的新しいSlimという、Hamlに似た優れたテンプレートがあります。
まだまだ十分に知られていないようなので、もっと普及させるべく、紹介したいと思います。

まずは見てみましょう。Slimはこんな感じ。
http://slim-lang.com/

Hamlはこんな感じになります。
http://haml.ursm.jp/

一見してわかるように、SlimはHamlによく似た、インデントによってHTML構造を表すテンプレート言語です。
一番の違いはタグに%（パーセント）がつかないこと。
行の先頭はタグの扱われるため、%をつける必要がありません。
その代わり、先頭にテキストを書く場合は |（パイプ）が必要です。

細かい文法の違いがあり、後発であることからSlimのほうが少し洗練されているようにも思いますが、それほどの違いではありませんので、Hamlを使っていた人はすぐに使えるでしょう。

Slimのほうが書きやすく、読みやすいのではないかと思いますが、%がついたほうがタグということが視覚的にわかりやすいという人もいますね。Slimの場合は、シンタックスハイライトが特に重要になってきそうです。

僕としてはHamlの%が、Perlの$と同じように人を寄せつけない雰囲気をもっていて、特にデザイナーに受け入れてもらいにくいのではないかと思っているので、Slim推しでいきたいなと今のところは思っています。

GitHubのリポジトリを見ると、Starが1,440（2012/10/27時点）ついていますし、開発も十分活発なようです。
https://github.com/slim-template/slim

Railsテンプレートの選択肢として、Hamlとともに検討してみてはいかがでしょうか。

Rails Rumbleで使われたGem

Ruby5を聞いていたらRails Rumbleで勝者が使っていたGemをまとめたブログが紹介されていました。とても興味深かったので紹介します。
http://www.dwellable.com/blog/Rails-Rumble-Winners-Gem-Teardown

なお、Rails Rumbleというのは4人までの少人数で、48時間以内に一気にRailsアプリを作り、その出来を競うイベントのようです。

勝者10チーム中10チームがjQueryを使い、9チームがCoffeeScript、Sassを使用。
Twitter Bootstrapの使用が6チーム。

テンプレートでは、Hamlが5チーム、先ほど紹介したSlimが3チーム。
Rails Rumbleに出るようなチームは先進的だと思われるので、Slimは今後もっと普及してくるのではないかと期待しています。（ただし、SidekiqでSlimが必要になるからかもとの注意書きがあります。）
HamlとSlimは兄弟のようなものなので、Haml系が8チームとも言えます。エンジニアだけで一気に作ろうというところでは、ERBのようなテンプレートよりも、よりプログラマーフレンドリーなHamlやSlimのような言語が使われるのでしょう。

DBでは、MySQLが5チームに対して、MongoDBが3チームというのも面白いです。
僕も自分のプロジェクトでMongoDBを使いはじめていますが、スキーマがないというのはとても快適です。

テストはRSpec。
DHHがRSpecを好きじゃないようなのでRailsのデフォルトにはなかなかなりませんが、そろそろ現実にほとんどの場合でRSpecが選ばれているということを受け入れてもいいのではと思いますね。

そしてバックグラウンドジョブの仕組み。
GitHubのdefunktが作ったResqueが定番かと思っていましたが、SidekiqというGemが今後の定番になるのかもしれません。

ちなみにSidekiqでもSlimを使ってるみたいです。
https://github.com/mperham/sidekiq/blob/master/web/views/layout.slim

Slimのシンタックスハイライト

SlimではVimやEmacsのシンタックスハイライトは用意されているのですが、ひとつ残念なのがGitHub上でのシンタックスハイライトが効かないこと。

上記SidekiqのGitHubリポジトリを見てもわかるとおり、Slimテンプレートはハイライトされていません。

対してHamlはシンタックスハイライトが効きます。

GitHubクローンの定番GitLabでも同様です。

GitLabではシンタックスハイライトに、PygmentsというPython製のライブラリを利用する、pygments.rbというGemを使っていますが、それがSlimに対応していないのです。

Slim向けのlexerというのを自分で書いてPygmentsに取り入れてもらえれば、GitLabでも（もしかするとGitHubでも）シンタックスハイライトされるようになるはずなので、このあたりを読んで勉強しようと思っています。

http://pygments.org/docs/lexerdevelopment/

Solr 4.0 がリリース

しばらくの間ベータ版だったSolr 4.0がついに正式版になったようです。
http://lucene.apache.org/solr/solrnews.html

早速使ってみなくては。

VimのScalaシンタックスハイライトをVundleでインストール

Scalaを使い始めていますが、Vimでシンタックスハイライトするまで少し躓づきました。

2.9.1以前はscala-tool-supportというのが添付されていたので、そこから
vim関連のファイルをコピーしたりしていましたが、2.9.2からはなくなったそうです。

http://d.hatena.ne.jp/xuwei/20120508/1336424085

ここからコピーしてもいいのですが、Vundleでvimスクリプトを管理しているので、
できればVundleでインストールしたいところ。

これが評判よさそうだったので、Vundleで入れました。
https://github.com/derekwyatt/vim-scala

.vimrcに以下のように記述して、

Bundle 'derekwyatt/vim-scala'

:BundleInstall

で無事、インストール完了。
.scalaファイルを開くと色がつくようになります。

GitLabをインストールしてGmailでメール送信まで

[2012/12/1 記]　4ヶ月ほど前の記事ですが、既にかなり進化していますので、
やはり本家のWikiを見て設定するのがいいと思います。

もはやバージョンコントロールといえばsubversionよりもGitらしい（参考）。
そしてGitといえばGitHub。
privateなプロジェクトで使用するために、GitHubの有料リポジトリを借りてもいいのだけど、まずはGitHubクローンのようなものを使って慣れていこうということで、一番人気の高そうなGitLabを使ってみた。

インストール

GitLabは開発がとても活発で変わる可能性が高いため、プロジェクトページの手順を見るのが一番だと思うけど、少し違う手順でインストールしたところもあるのでメモしておく。
サーバーはさくらVPSのCentOS 6.2。

CentOS6にGitLabをインストールする方法

を主に参考にした。

Gitインストール

さくらVPSには最初から入っていたと思う。なければyumでインストール。

sudo yum install git

ユーザーを作成

gitoliteとgitlabのユーザーを分けずにgitというユーザーだけ作って設定した。
権限を気にするところが減って少し楽だった。

useradd git
passwd git

パスワードを設定したら、gitでログイン。

su - git

git configも必要になるようなので、設定しておく。

git config --global user.email "gitadmin@example.com"
git config --global user.name "gitadmin"

Gitolite設定

以降だいたいgitユーザーで作業。
ソースを持ってきて、

git clone git://github.com/sitaramc/gitolite

SSHキーを作成。

ssh-keygen -t rsa -P "" -f ~/.ssh/gitadmin

ファイル名（-fで指定してる）は何でも。

gitolite/install
gitolite/src/gitolite setup -pk ~/.ssh/gitadmin.pub

~/.gitolite.rc
のUMASKを0077→0007へ変更。

~/.ssh/configを

Host localhost
  HostName localhost
  IdentityFile ~/.ssh/gitadmin

のように作成し、保存。

chmod 600 ~/.ssh/config

で権限を変更しておく。

Rubyインストール

1.9が必要。今回はrvmでインストールした。
途中、readlineがないと言われたので、

rvm pkg install readline

でインストールした。

パッケージ

自分の環境ではこのあたりが必要だった。
足りない場合はあとでbundle installするとき注意されるからわかるはず。

sudo yum install libxml2-devel libxslt-devel libicu-devel sqlite-devel redis

redisをyumでインストールするにはEPELが必要。
yumじゃなくてもいいけど、yumの方が簡単。

redisを起動

一応、自動起動を設定しておく。

sudo /sbin/chkconfig --level 2345 redis on

サービス起動。

sudo /etc/init.d/redis start

GitLabをインストール

masterから入れたが、安定性を求めるならstableを入れたほうがいいだろう。

git clone git://github.com/gitlabhq/gitlabhq.git

移動して、bundle install。

cd gitlabhq
bundle install --path vendor/bundle

足りないパッケージがあるとここで注意されると思うので入れる。

DBはMySQLにした。

cp config/database.yml.mysql config/database.yml

して適切に編集。

cp config/gitlab.yml.example config/gitlab.yml

gitユーザーを作ったので、git_hostのところはそのままでよかった。
ユーザー名など違う場合は変更する。
web、emailのところを編集した。（emailは以下メール設定を参照）

bundle exec rake gitlab:app:setup RAILS_ENV=production

DBセットアップや初期データ作成が実行される。

bundle exec rake gitlab:app:status RAILS_ENV=production

で設定が正しいかどうか確認できる。
（ただし、UMASK for .gitolite.rc is 0007のところはチェックの方に問題があるようで、正しく設定されていてもエラーになった。）

passenger

passenger + apacheで動かした。apacheが入っていなければ、

sudo yum install httpd-devel

で入れておく。

rvmでrubyをインストールしたので、

rvmsudo gem install passenger

でpassnger gemをインストールして、cdでホームディレクトリに移動し、

rvmsudo passenger-install-apache2-module

でpassengerをインストール。（ホームディレクトリじゃないとgemを見つけてくれなかった。）

あとは手順どおりにすればOK。

メール送信の設定

新しいissueが登録されたり、wallに書き込まれたりしたときはメールが飛ぶはずなのだけど、
どうやって飛ばせばいいかわからず苦労した。

メール送信には、jobキューを処理するresqueが使われていた。resqueを起動していなくても
logにもどこにもエラーが出ないので気づかなかった。

GitLabのようなアプリにresqueを使うのはオーバーな気がするんだけど、なんで使ってるのだろう？

1.メール設定

メール送信にはGmailを使った。
config/gitlab.yml
を以下のように編集。
（config.action_mailer.smtp_settingsなどを設定する必要はないみたい）

email:
  from: notify@local.host  # なんでも。メールのFromに書かれるアドレス。
  address: smtp.gmail.com
  port: 587
  user_name: yourname@gmail.com   # @gmail.comは省略できるはず
  password: yourpassword

authenticationやdomainは指定しなくても動いた。

Gmailじゃなくて普通のメールでも同様に、通常Action Mailerで
config.action_mailer.smtp_settingsを設定するような項目を書けばOK。

2.resqueを起動

gitlabhqディレクトリで、

./resque.sh

を実行。

resqueを起動したままでgitlab.ymlの設定を変えても反映されないので注意。
変更したあとresqueを起動し直す。
stopの仕方がわからないので、プロセスをkillしてから、./resque.shでまた起動しなおしたりした。

もうひとつ注意点。resqueを動かしていないと、未実行のキューがたまったままになっている。
Adminでユーザーの新規作成をしたとき、本来飛ぶはずのメールが飛ばないと、new_user_emailという名前でキューにたまっているのだけど、そこでパスワードが見えてしまう。（通常はメールに初期パスワードがメールに書かれて飛ぶ。）

初期パスワードは変えるようにということなのかもしれないが、知らないとちょっとこわい動作だ。ちなみにDBには、パスワードはちゃんとハッシュ化されて保存されている。

その他

プロジェクトごとのWikiで、「New Page」のようなボタンがないから新しいページを作れないんじゃないかと思ってしまったが、そんなことはなかった。
編集画面に表示されるとおり、
 [Link Title](page-slug)
の形で書けば新しいページが作れた。
[新しいページ](新しいページ)みたいに日本語でもいける。

まだ使い始めたばかりだが、軽快だし機能も充実していて、かなり好印象。
このあたりを見てGitの使い方を覚えつつ、使ってみようと思う。