portal shit!

関連記事表示

Jekyllで関連記事を表示するようにした。jekyllを実行するときに jekyll --lsi とするんだけど、Classifierというgemが必要。ただしClassifierを入れてるだけだと似てる記事を探すのにすんごい時間がかかるので、gslというgemを入れる。しかしこれはただ単に gem install gsl しただけでは以下のようなエラーが出る。

Fetching: narray-0.5.9.9.gem (100%)
Building native extensions.  This could take a while...
Fetching: gsl-1.14.7.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing gsl:
        ERROR: Failed to build gem native extension.
        /Users/morygonzalez/.rvm/rubies/ruby-1.9.2-p136/bin/ruby extconf.rb
checking gsl version... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/Users/morygonzalez/.rvm/rubies/ruby-1.9.2-p136/bin/ruby
extconf.rb:237:in `rescue in <main>': Check GSL>=0.9.4 is installed, and the command "gsl-config" is in search path. (RuntimeError)
        from extconf.rb:138:in `<main>'

GSL（GNU Scientific Library）が入ってないのがダメらしい。Homebrewでインストールする。

$ brew install gsl

そんでもう一回 gem install gsl するとうまく入った。 _config.yaml に lsi: true という記述を追記して jekyll を実行すると関連記事が表示されるようになった。

最近の記事表示

ついでに見た目を調整した。サイドバーに全部の記事が表示されてたのがうざかったので10件だけ表示するようにした。

8c72..2c84ea5 100644
--- a/_layouts/post.html
+++ b/_layouts/post.html
7 +69,7 @@

         <h3>Latest Posts</h3>
         <ul>
-          {`% for post in site.posts `%}
+          {`% for post in site.posts limit:10 `%}
           <li><a href="{{ post.url }}">{{ post.title }}</a></li>
           {`% endfor `%}
         </ul>

(↑Liquidでエスケープする方法がわからんかったので {`% とかなってますけど、正しくは {% です)

Liquidでは配列に対して {% for post in site.posts limit:10 %} という書き方をすることでループ処理の回数をコントロールできるみたい。

全体的に見やすくなりすっきりした。

確認ダイアログを出しながらディレクトリやファイルを削除するスクリプトを書いた。大したコード書いてないし逆引きRubyに載ってたコードをまるパクリしてるところもあるけど便利だと思う。

そのディレクトリにあるファイル/ディレクトリ一覧を取得した後、「このファイル/ディレクトリは作られてから何日経っています。削除しますか？ (y/n)」というダイアログ（英語）を表示する。y が入力されると削除を行う。地味に使える。

RubyのFileUtilsはすごく便利だと思う。シェルスクリプトでしこしこ書くのがアホらしくなる。RubyがPerlなみにあらゆるuni*x系のサーバーに入るようになったらさぞかし便利だろうと思う。

iTerm 2が素晴らしいということなのでiTermをぼちぼち使ってるんですけど、Vimを起動したときに矢印キーで移動できないことが分かった。「Vimで矢印キーでカーソル移動とか小学生かよ」みたいなご意見もあるでしょうけど、入力モードのときに移動したくなったら j, k, h, l じゃ移動できないでしょ？ そこで矢印キーですよ。

iTermでVimを使っているときも矢印キーでカーソル移動できないものかと、軽くググってみたところ次のような記事に遭遇した。

MacBookのiTermでVimを使う時矢印キーで移動が出来ないときの解決方法 - Nobody is perfect.

解決。 export TERM=dtterm http://d.hatena.ne.jp/mitsygh/20070708/1183906416 スクリーンのときは [ $SHLVL -eq 1 ] && export TERM=dtterm としなければいけないらしい。

d.hatena.ne.jp

これを参考にとりあえず以下のように .zshrc に書いた。

case "${TERM_PROGRAM}" in
iTerm*)
  export TERM=dtterm
esac

しかし、これはちょっと自分的にはいただけなかった。

export TERM=dtterm

ってやると、termcap的な何かの作用で、Vimを閉じたときにコンソールを復元できなくなる（参照： Vimで編集を終了した後、元のコンソールの状態を復元したい）。僕はVimを閉じた後はコンソールを復元したい派なので、このやり方は受け入れられなかった。

.termcap に何か書くことも考えたけど、 .termcap で条件分岐する書き方が分からなかったのでさらにググってみた。すると外人が「iTermの設定で何とかできる」みたいなことを書いてるのを発見した。

Help2Go - free computer help and advice - Using Arrow Keys in iTerm with vi

How to get the arrow keys to work in iTerm and vi or vim Help2Go provides free computer help, advice, tutorials, and spyware help.

www.help2go.com

なるほど、 .vimrc とか .zshrc とか側で回避する方法ばかり考えていたけどiTermで回避する方法を考えればよいわけか。

で、iTermを開いてみたところ、iTerm 1の頃から引き継いでいるBookmarkのDefaultの設定がよくなかったみたい。具体的には矢印キーそれぞれに ^[[A とか ^[[B みたいなキーが割り振られていて、このせいで矢印キーが使えなくなっていたわけだ。

Load Presetから "Use xterm Defaults" を選んでみたところ、無事矢印キーでカーソル移動できるようになった。めでたしめでたし。

一個前の記事（Rubyがエレガントだって言われるのがわかってきたような気がする | tech.portalshit.net - CakePHP, Rails, JavaScript）をcxxさんに添削してもらったところ、Rubyの方のコードには問題があったらしい。Rubyでは変数を宣言だけして終わりみたいな初期化をしちゃダメだそうで、必ず何かを代入しないといけないらしい。

そういうわけで正しくは、

class Hoge
  def initialize
    @a = ""
  end

  def hoge
    @a = "hogehoge"
  end
end

fuga = Hoge.new
puts fuga.hoge

と書くそうです。

ところでなんで自分は前回、 @a というインスタンス変数を使ったのかがよく分からない。Railsでコードを書いていて、Controllerで定義した変数をViewで使うときにインスタンス変数を使うので、そういう風に思い込んでいるのかな。上のコードでは別にインスタンス変数を使う必要はなくて、

class Hoge
  def initialize
    a = ""
  end

  def hoge
    a = "hogehoge"
  end
end

fuga = Hoge.new
puts fuga.hoge

でも同じ結果を出力しますね。

インスタンス変数と普通の変数の違いが分かってなかったので、たのしいRuby（第2版）を開いて復習してみたところ、以下のような記述があった。（たのしいRuby 第2版 pp.123-124）

@ で始まる変数は インスタンス変数 といいます。ローカル変数とは違って、このメソッドを抜けてもその値は保存されますが、インスタンスごとに違う値を割り当てられる変数です。（たのしいRuby 第2版 pp.123-124）

なるほど！ 例えば上のコードを引数つきのものに改造したとしましょう。

class Hoge
  def initialize(b="")
    @a = b
  end

  def hoge
    print @a, "
"
  end
end

fuga = Hoge.new("Fuga")
piyo = Hoge.new("Piyo")

fuga.hoge
piyo.hoge

で、これを実行すると

Fuga
Piyo

と表示される。こんな感じで、一つのクラスから複数のインスタンスを生成するときに使うのがインスタンス変数って理解でオーケーなのかなと思います。

この前、さくらVPSに入れているUbuntuのzshで ls とか cd とか打ったとき、変なエラーメッセージが出るようになった。原因不明。しょうがないのでzshをインストールしなおそうと、chsh してbashとかに切り替えずに sudo apt-get remove zsh してしまった。そこで混乱してしまって Ctrl + D しちゃったもんだからSSH閉じてしまって、なんとUbuntuにログインできなくなってしまった。

Ubuntuは root というアカウントがなくてなんでも sudo するか、 sudo su で無理矢理rootになるしかないので、rootでログインしてchshしてやるという救済手段がとれず、にっちもさっちもいかなくなってUbuntuを再インストールした。

ちょっと調べたら、こういうアクシデントを防ぐために、/etc/shells にzshを足さず、chshでデフォルトシェルにもしないという人もいるみたい。.bashrc に次のように書くそうだ。

if [ -f /bin/zsh ]; then
  exec /bin/zsh
fi

これだと何かのトラブルでzshが起動しないことがあってもbashでログインできるということらしい。zshがちゃんとしてるときはzshでログインするという理屈だ。

GT Nitro: カーレーシング・ドラッグレーシングゲーム - Google Play のアプリ

この高速ドラッグレースアドベンチャーゲームで、スポーツカーをゴールに向かってブーストし、本格的なカーレースのレーシング体験と車勝負の興奮を堪能しましょう！

labs.unoh.net

しかしこれには結構重い副作用があるみたい。

.bash_profileに「exec /bin/zsh」と書くのはやめたほうがいい - Humanity

zsh を使いたいが、ログインシェルにするのはちょっと怖い…。 .bash_profile に exec /bin/zsh と書いて代用する、というのはよく使われるテクニックですが、実はこの記述だと /bin/zsh が消えてしまった場合にログインできなくなります。 [ -x "/bin/zsh" ] && exec /bin/zsh だと /bin/zsh が消えたときには exec が行われなくなるので、安全です。… と思って使っていたのですが、先ほど自分のサーバを再起動したら帰ってこなくなりました。 exec /bin/zsh を .bash_profile に書くと mdmonitor…

d.hatena.ne.jp

一理ある。

というわけでUbuntuやrootでsshできない環境ででzshを使う場合は、何らかのトラブルでzshが起動しない、シェルにログインできなくなることを想定し、保険として普段はまったく使わない非常用のアカウントを作っておくと良いと思った。もちろんsudoersに指定しておかないと意味ないけどね。

先週、九州産業大学で行われたWordCamp Fukuoka 2011に行った。仕事でWordPress使う機会はないけど、福岡のWeb業界がどんな感じなのか知りたくて行ってみた。

WordPressは ゴンゴンの見た映画 で使ってて、前職場でもウェブサイトにブログを付けるときによく使った。また友達のホームページにも導入したことがある。以下そのときに書いた過去記事から引用だけど、

WordPress 2.7やMovable Type 4とかもそうですけど、ブログのなかで読者が触れる部分っていうのはここ数年のアップデートの中でもそうそう変化なくて、書き手が触れる部分、書き手にしか見えない部分がえらく進化してます。サーバーにインストールして使うタイプのブログツールでも、外部のフィードを取ってきて管理画面に他サイトの更新状況や人気のプラグインが表示されたりしますし、まるでレンタルブログサービスを利用しているかのようです。いかに書き手を書く気にさせるか、ってのが今日のブログツールの潮流なのかなーって感じました。これ大事なことですよね。

portal shit! : Twitterのフィードを加工して自サイト内にマイクロブログを作る

このように、WordPressは管理系の機能が非常に進化しているように思う。バージョン2.7から、自動アップグレード機能がついて、何も知らん人でもWordPress本体をサーバーにアップロードして、MySQLにデータベース一個つくればそれで使えるようになる。面倒くさいアップグレードとかもボタン一つで完了、さらに世界中のデザイナーがデザインしたWPテンプレートが使える。

WordCamp Fukuoka 2011は “Publish” がテーマだったけど、本当に誰もが簡単に “Publish” できるようになりつつあると思う。開発者とデザイナーとユーザーがそれぞれたくさんいて、非常に活気があると感じた。それゆえにユーザーの声が反映されて、使いやすい管理画面（ダッシュボード）になってきてるんじゃないだろうか。一人でブログを書いてるのに、一人じゃないのがWordPressの良いところだと思う。後ろにオープンソースコミュニティが付いている感じ。

一方、かつてはブログツールの代名詞的存在だったMovable Typeは、Six Apartの買収などのいざこざがあり、アメリカの親会社から日本法人に権利が売却されてしまっていた。

なんでMovable Typeがダメになったのか。WordPressと異なり、元々オープンソースじゃなかったのが原因だろう。2007年にオープンソース化されたけど、そのときにはWordPressとの勝負には決着がついていたように思う。そもそもMovable Typeは、個人がPublishするためのツールというより、企業のホームページを管理するためのツールを指向していた。公式サイト（ウェブサイト管理の新標準。Movable Type 5 - Six Apart）を見れば、右上の目立つ位置に「ご購入はこちら」のボタンが配置してあり、基本的に有償のソフトウェアであることが分かる。

WordCampの活況とMovableTypeの身売りがあまりにも対照的で、コミュニティのあるなしで、ブログプラットフォームの盛衰が左右されることを実感した。一人で黙々とブログやプログラムを書いていてはダメで、何かしらで外とつながってなきゃいけないのだと思う。

昨日の続きのようなもの。LokkaをUbuntu上で動かそうといろいろやってます。passenger入れて、 passenger-install-nginx-module を実行しようとしたらエラーが出た。お前はrootじゃないからnginxインストールできひんわ、みたいなメッセージが出る。sudoったりrootになってインストールしようとすると今度はpassengerなんていうgemはないわ、って怒られる。sudoしたときには.rvm内のgemパッケージではなくシステムのgemパッケージを見ようとするっぽい。またrootになるとRVMではなくシステムのRubyが実行されるので同じくpassengerなんてgemないわ、って怒られる。システムのRubyは1.8.7だし、なるべくなら使いたくない。RVMのRubyを使ってpassenger + nginxな環境作れないのかよ、とググってたら以下のような記事を発見した。

http://www.blog.bridgeutopiaweb.com/post/install-rvm-passenger-nginx-and-rails-3-on-ubuntu-lucid-lynx/

www.blog.bridgeutopiaweb.com

なんと、RVMには rvmsudo というコマンドがあるらしい！ 試しに

$ rvmsudo passenger-install-nginx-module

を実行してみたところ、お前はroot権限がないんじゃ〜とエラーが出ていたところも無事通過してnginxをインストールできてしまった。以前、sudoで無理矢理nginxをインストールしたときは、 nginx.conf 内で、

passenger_root /home/morygonzalez/.rvm/gems/ruby-1.9.2-p136/gems/passenger-3.0.2;
passenger_ruby /usr/bin/ruby1.8;

となっていて大変気持ち悪かったし、Passengerも「PassengerとRubyの本体でバージョンの不整合があるだろヴォケ」みたいな警告出してた。それが rvmsudo のおかげで nginx.conf に書き込まれる値も以下の通りとなるので、とりあえずPassenger（RubyGems）とRubyのバージョンが異なるというような問題は回避できる。

passenger_root /home/morygonzalez/.rvm/gems/ruby-1.9.2-p136/gems/passenger-3.0.2;
passenger_ruby /home/morygonzalez/.rvm/wrappers/ruby-1.9.2-p136/ruby;

ただ、なんでか分からないのだけどnginxがうまく動いてくれなくて、無事Webサーバーを起動できてない感じです。

それにしてもRVMは、本当にきもいと思う。readlineとかまで.rvm内にインストールできるできるし、いったい何考えてるんでしょうかね。きもすぎて便利です。