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

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

NECの安サーバーを買ってサーバーを作ってるんですけど、SSHでエラーが出て困ってます。OSはUbuntu Server 10.04.1 LTS。

まずSSHのおさらいを。クライアント側で

$ mkdir -p .ssh
$ ssh-keygen -t rsa （以下略）

したのち、サーバー側の /etc/ssh/sshd_config の PasswordAuthentication を on にし、パスワードでSSH接続できるようにして

$ scp id_rsa.pub username@hoge.com:.ssh/authorized_keys

するか、あるいはUSBフラッシュメモリで鍵をサーバーに移す。その後サーバー側で .ssh/ と .ssh/authorized_keys のパーミッションをそれぞれ700と600に変えてあげるわけですよね。

いっぺんクライアント側で id_rsa.pub を作ってたらそれ以降は単純にこれを接続先のサーバーにコピーしてあげればおｋ。ここまで合ってますかね？

前から使ってる職場内だけで使うサーバーにも同じUbuntu Serverを入れてるんですけど、こっちでは全くトラブルがない。それなのに新しいサーバーでは

Permission denied (publickey).

というエラーが頻繁にお出になるのですよ。

しかしこのエラー、常に出る訳じゃないんですね。サーバーを直接操作して

$ sudo /etc/init.d/ssh restart

してあげると消える訳ですね。そんでしばらくクライアントからSSHで接続したり切断したりを繰り返していると、あるとき突然、

Permission denied (publickey).

となるわけです。まじでストレスフル。つか、このサーバーは公開用に使うものなので、こんな感じでSSHが不安定だとかまじで困るんですけど。

前述の PasswordAuthentication を on にしとけば、公開鍵認証に失敗した後もパスワードで認証することができるんですが、パスワード認証はなんだか怖いので使いたくないのですよね。どいうしたものか。

ググったらSSHのプロトコルを1と2併用にしたら解決するという情報が出てきたのですけど、これやったら "Disabling protocol version 1. Could not load host key" というエラー？が出てしまったので多分僕の環境では意味なし。「RSAキーやめてDSAにしたらエラーでなくなった」（ぷらぷらブログ | OpenSSH を導入。接続に四苦八苦！）という情報もあるけど面倒くさいのでまだ試していません。

この前、さくら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に指定しておかないと意味ないけどね。

昨日と一昨日の二日間、TDD Boot Camp 福岡に参加した。

参加しようと思ったわけ

勤めている会社にはテストがない。いや、テストはある。エクセルにテスト項目をたくさん書き出していって手動テストだ。テストコードがない。人力で三人くらいが夜なべしてテストする（だいたいスケジュールには遅延が発生する）。これはどうしたっておかしい。開発前に要件定義書、設計書を書いて開発して、開発が終わったらエクセルで長大なテストシートを作成し、手動テストを行う。そしてバグや思わぬ不具合が発見されるとプログラムに改修を加える。欠陥や不都合が発見される度に連動して設計書にも修正・変更が加えられ、Do Repeat Yourselfな感じになってる。毎日毎日ドキュメント作成などの開発以外のタスクに時間を割かれるので新しい技術に触れる機会がないし、遅くまで残って仕事してから帰宅するので趣味プログラミングで知見を広めることもできない（福岡に来てからのこのブログの更新状況を見ればおわかりいただけるかと）。この状況をなんとかしたいと思っていて、藁をもすがる思いでTDD Boot Campに参加した。

感想

一日目は『プログラマが知るべき97のこと』の監修やTDDで有名な @t_wada さんのレクチャーで、TDDとは何かが説明された。以下印象に残った点。

• 良いテスト
  • 自動化されている
  • 徹底している
  • 何度でも実行可能
  • 独立している
  • プロのコード
  • テストコードもプロダクトコードと同じ品質であることが求められる（リファクタリング、DRY原則の貫徹など）
• TDD三原則
  • 単体テストコードを書く前に製品コードを書いてはいけない
  • 適切に失敗する単体テストコードができるまで、次の単体テストコードを書いてはならない
  • 単体テストコードに対応する以上に製品コードを書かない
• なぜTDDするのか
  • 自分が完璧ではないことがわかっているから
  • 最初から思い通りにコードを書けるほどに私たちは賢くない
  • 最初から思い通りに動作するほど対象は単純ではない
  • 素早く対象に近づき、フィードバックを得て方向修正をしながら開発を行う必要がある
• テストの目的は健康
  • 変化に対応できるのは健康体のコードだけ
  • 変化に対応できるのは健康体のチームだけ
  • 毎日残業する、毎日レッドブル飲んだりしていてはダメ
• TDDの導入効果
  • MSやIBMでTDD導入後、欠陥の割合が4割から9割削減された。
  • コード実装時間は15%から35%増加した。
  • しかし結果的にはバグが激減するので開発工数自体は減る。
• TDDは才能ではなくスキル
  • 練習すれば習得可能
  • 量は質に転化する
  • 写経しましょう！
  • PCにGitをインストールし、ページをキープできるブックスタンドを買って、ケント・ベック本をひたすら写経。ビルドを実行する度にコミットする。

テストのみならず、自動化やバージョンコントロールの重要性が説かれた。

二日目には @bleis さんによるGitの効果的な利用方法やJenkinsを利用した継続的インテグレーションの実践例、 @akineko さんによるOMakeを利用した自動ビルド、自動テスト、自動コミットの話など。

ペアプログラミングを体験した

ペアプログラミングを生まれて体験した。 @mallowlabs さんとRubyでペアプログラミングをさせてもらった。講師陣が出題する課題を解いていくというもの。当然テスト駆動。テスティングフレームワークにはRSpecを利用した。

WEB + DB PressなどのRSpec特集を写経したことはあったけど、時間制限がある中で、他の人とペアを組んでプログラムを書いていく作業はかなりエキサイティングだった。

ただ自分のRubyスキルおよびVimのスキルが著しく劣っていたため、@mallowlabs さんの足を引っ張っていた感は否めない。正直申し訳なかったです。

全般的に、自分の知識のなさ、スキルのなさが実感できた

以下、初日に行ったFizzBuzz問題と主に二日目に取り組んだTwitterのタイムラインをカテゴリ分けするという課題の成果物。

TDD Boot Camp 福岡 — Gist TDDBC でペアプロした結果です — Gist

TDDをいかにして根付かせるか

勉強会に参加していきなりコードが書けるようになるわけでは当然ないので、継続的な勉強が必要だと感じた。いっぱい本を紹介してもらったので積ん読本を何冊か片付けたら『レガシー・コード改善ガイド』と『テスト駆動開発入門』を買おうと思った。