Silent Power: 2012

2012年11月13日火曜日

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では文字コードに悩まされることが多々あって、みんなよく我慢してるものだと思っていたので、この変更はとてもうれしい。

2012年10月27日土曜日

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/

2012年10月13日土曜日

Solr 4.0 がリリース

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

早速使ってみなくては。

2012年8月21日火曜日

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ファイルを開くと色がつくようになります。

2012年7月26日木曜日

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の使い方を覚えつつ、使ってみようと思う。

2012年7月19日木曜日

最近読んだ本、読んでいる本

グーグル　ネット覇者の真実

600ページを超える大作。ものすごく面白かった。

ラリー・ペイジやサーゲイ・ブリンの天才ぶりと、常識にとらわれない自由な発想が印象に残った。
2人とも子どもの自主性を重んじる「モンテッソーリ教育」を受けたそうで、その影響が大きいのではないかと。

Don't be Evilという標語の誕生と、その標語で苦しむことになるいくつかのエピソード（中国、ブックサーチ、プライバシーの問題など）も書かれているが、基本的には善意の会社なのだと思う。ラリー・ペイジが外部の批判に苛立つ気持ちは少しわかるような気がした。

Googleってやっぱり特別な会社なんだなと改めて感じていると、この本にも何度も名前の出てくるマリッサ・メイヤーが、米ヤフーのCEOになるという。日本では考えられない人事。
この特別な会社で、エンジニア至上主義の中でリーダーとしてやってきたマリッサ・メイヤーが、CEOとしてヤフーを立て直せるのかどうか、とても興味深い。

スターバックス再生物語

これも面白かった。

この前の本（～成功物語）も少し読んだのだけど、こちらのほうが読みやすかった。
なんとなくはじめたわけでもお金のためだけにはじめたわけでもなくて、コーヒーや「サードプレイス」というビジョンに情熱を持っていたからこそ、世界規模の企業になれたんだろうなと思った。
ただスタバは食べ物の品質に向上の余地があると思わなくもない。

「週４時間」だけ働く。

これも600ページを超える分厚い本。
少し俗っぽい気もするが、仕事の取り組み方を考えるきっかけになるかも。

インドなどに個人的な用事をアウトソースすることで時間を浮かすというのは、検討してみたいと思った。

Webのサービスのような知的労働は世界のどこでもできるわけで、うまく新興国の力を使えるように仕組み化できたら、みんなハッピーになれるのではないか。
機会があれば化けるはずの眠れる才能があると思うともったいない。

情報検索の基礎

PDFが公開されているIntroduction to Information Retrievalの日本語訳。
自分で検索エンジンを作りながら検索技術を勉強しようかと。
章を進むにしたがって難しくなるが、なんとか読み切りたい。
学生時代にもう少し勉強しておけば…と思ってしまうが、今からでもがんばろう。

2012年6月26日火曜日

『Eloquent Ruby』を読む Chapter 2. Choose the Right Control Structure

Eloquent Ruby

Chapter 1

Chapter 2. Choose the Right Control Structure
（正しい制御構造を選ぼう）

この章は簡単に。

・if not ～ではなく　unless ～を使おう

・一行のときは後ろに置こう

・for ～ end ではなく、each do ～ end を使おう（Rubyのイディオム的に）

・caseについて…は省略

・Rubyでfalseになるのは、false と nil だけ
→0も 'false' (String) もfalse ではない

・?: （三項演算子）がRubyではよく使われる
→fileの値は、allがtrueなら'specs'、falseならlatest_specs'。

・最後はこれ

→@first_nameがfalse（falseかnil）なら''（空文字）が入る。falseじゃなければ、そのまま。

奇妙な構文に見えるが、
count += 1
が
count = count + 1
であるように、

@first_name = @first_name || ''
の省略形だと思えばいい、とのこと。

よく出てくるので自然と覚えます。

Chapter 3.　はRubyのCollection、配列とハッシュについてです。

Eloquent Rubyを読む（インデックス）

2012年6月20日水曜日

『Eloquent Ruby』を読む Chapter 1. Write Code That Looks Like Ruby

Eloquent Rubyを読んでいきます。

Chapter1. Write Code That Looks Like Ruby
（Rubyらしいコードを書こう）

第１章はコーディングスタイル。
一般的なことなので、Rubyを勉強した人は軽く読めばいいかも。

・意図の分り易いコードを書こう（Great code shouts its intent）、
・簡潔に書こう（good code is not just clear, it is also concise）

というようなことがまず書かれていて、あとはコーディングスタイルについて。

最初はインデントの話から。

・インデントは two space
タブは厳禁（→環境によって崩れるから。）

この本を通してこのDocumentというクラスを使うことになりますので、軽く眺めておきます。

・# でコメント
in-line　で置くこともできる
return 0 if divisor == 0 # Avoid division by zero

コメントでは、何をしてるかは基本的には書かない（コード自ら語るようにする）
good code is like a good joke: It needs no explanation.

・クラス名はcamel、その他はsnake（Camels for Classes, Snakes Everywhere Else）
定数はCamelにするか、ANTLERS_PER_MALE_MOOSEのように書くか。（この本では後者）

・かっこ（parentheses）は省略できる
引数がない場合は普通省略する（上記Documentのwordsメソッド）

・ブロックは一行のときは{ } 、複数行のときはdo ～ end

In the Wild

各章のIn the Wildというコーナーでは、実際のRubyコードでは勉強したことがどう使われているかということが書かれています。

この章では、Ruby standard libraryのset.rbで、コメントがどう使われているかなどが紹介されています。

内容もまだまだ基本的なことですので、このあたりで英語にしっかり慣れておきます。
平易な英語なので、英語がまだまだの自分でもなんとか読めました。

Chapter 2はControl Structure（制御構造）です。

Eloquent Rubyを読む（インデックス）