portal shit!

VM 上の Scientific Linux で Jenkins を動かしていて、テスト結果のグラフが表示できない問題に遭遇していた。出るエラーメッセージは以下のようなもの。

Graphics N/A
Unable to access X. You need to run the web container in the headless
mode. Add -Djava.awt.headless=true to VM.

OpenJDK が原因らしい（jenkinsでGraphics N/Aが出た時にしたこと | ミラボ）。

OpenJDK をやめて Oracle の JDK に変えればいいらしいのだけど、 OpenJDK でもグラフ表示できている人はいるっぽいし、ソースから Java を入れるのが嫌なので OpenJDK で何とかする方法を探していた。

もろもろ情報をあさってみたところ、どうもフォントがないのが問題らしい。

Jenkins : Jenkins got java.awt.headless problem

wiki.jenkins-ci.org

Jenkins の wiki にあるとおりに /var/log/jenkins/jenkins.log を漁ってみたら、以下のようなエラーメッセージを発見した。

Caused by: java.lang.Error: Probable fatal error:No fonts found.

これに対して公式 wiki には

Obviously graphics rendering needs access to font metrics. So check java /etc/java-6-openjdk/fontconfig.properties and install missing fonts. OpenJDK refers to DejaVu-Fonts. So type:

sudo apt-get install ttf-dejavu

とあるので、yum search dejavu して dejavu って名前がついてるフォントを片っ端から入れたらちゃんとグラフが表示されるようになった。

お困りの方はお試しください。

最近、会社でリーダブルコードを輪読したり、Fukuoka.rb で Eloquent Ruby を読んだりしていて、メソッドや変数名の長さやコメントについての議論を読む機会があった。

昨日、たまたま 37signals のブログを読んでいたら、Rails の作者である David Heinemeier Hansson もこのトピックについて書いていた。

自分は WEB+DB PRESS で ukstudio さんの書いた RSpec についての記事を読んで感化されて以来、ソースコード中のコメントはすべて悪で、はっきりしたメソッド名、変数名を使えばコメントはいらないという考え方を持っている。DHH もそのような考え方のようだ。

Clarity over brevity in variable and method names – Signal v. Noise

Many programmers have a natural preference for short variable and method names. I doubt many would recognize this preference as a trade of brevity for clarity, but that’s often exactly the result. This is especially true if you subscribe to the ridiculous Church of 80-character Lines. It n…

37signals.com

要点をかいつまむ。

多くのプログラマーは短い変数名やメソッド名を好む。短い命名は明確性や簡潔性を犠牲にしているとみんな気づいてるんじゃないかと疑ってるんだけど、実際のところ短い命名を採用したコードが多い。特に「一行は80文字まで」教の連中に。

しかし最近のプログラミング言語は表現豊かなのだから、短い命名にこだわる必要は無い。

extension を ext と略してあるのを見かけると嫌気がさす。アプリケーション固有の略語を作るのはもっとひどい。そんなの二ヶ月後には絶対忘れてる。

過剰に明瞭な名前は一見するとバカっぽい。処理内容よりもメソッド名の方が長いとかね。でも一発でやってる内容が分かることの前ではそのバカっぽさは霧消する。

最近の Basecamp のコードにはこんなのがある。

def make_person_an_outside_subscriber_if_all_accesses_revoked
  person.update_attribute(:outside_subscriber, true) if person.reload.accesses.blank?
end

def shift_records_upward_starting_at(position)
  positioned_records.update_all "position = position - 1",
    ["position >= ?", position]
end

def someone_else_just_finished_writing?(document)
  if event = document.current_version_event
    !event.by_current_creator? and event.updated_at > 1.minute.ago
  end
end

もし十分に明確な命名をしているのであれば、コードにコメントを書く必要がない。コメントというものは往々にして不明瞭な命名をしているコードの中で必要になる。コメント付きのコードはやばい臭いを放っていると思っといた方がいい。

コメントはいらない

リーダブルコードの中にも「名前は短いコメントだと思えばいい」というくだりがあるけど、基本的にあの本には「いいコメントを書け」と書いてあるような気がする。コメントそのものを悪いとみなしていない。

先々週読んだ Eloquent Ruby の Chapter 8. Embrace Dynamic Typing の中では Ruby という言語の特性も踏まえ、コメントはいらないと書いてあった。

例えば Ruby ではメソッド名の最後にはてなをつけてあると Boolean を返すという慣習がある。だからコードの中に「○×を判定し true/false を返します」というようなコメントはいらない。

def is_longer_than?(number_of_characters)
  @content.length > number_of_characters
end

Eloquent Ruby は Chapter 1 でもコメントについて述べている。そこには「コメントを書くべき理由があるコードもある」と書いてある。そのコードの使い方を指南したコメントだ。「なぜそのようなコードを書いたのか」、「コード内で用いているアルゴリズムの説明」、「どのようにして高速化したか」というようなことは書くべきではないと言っている。この辺はリーダブルコードと正反対だ。リーダブルコードでは「なぜそのような実装にしたのか」を積極的に書くように奨励されていた。

ちょっと前にはてブでホッテントリに入ってた、ソースコード内のコメントでコードレビューをやるというやり方は最悪だと思う。売り物のコードの中でああでもないこうでもないと議論するなんて狂ってる。コードが修正されたときに議論の内容まで適切に修正されるとは思えない。下手をするとコメントとコードの内容が正反対になってしまうかも知れない。コードの背景についてはコード内に書かず、GitHub 使ってインラインコメントでやった方が良いと思う。

皆さんはどう思いますか？

だいぶ前の記事では Jekyll は Git の hook を使って公開してると書いてた。

Gitのhookを使ってDreamhost上のJekyllに記事を公開 - portal shit!

やってみた。以下を参考にした。 http://www.taknado.com/en/2009/03/26/deplo...

tech.portalshit.net

しかし記事の本数が増えてくると、 jekyll コマンドで生成した静的なファイルも Git でトラックするのがだるいと感じるようになった。ので Rakefile に以下のような task を追加して、公開先のサーバーに rsync でファイルを転送するように変更した。

desc "Publish"
task :publish do
  path = File.expand_path("_site")
  if system("rsync -avz --delete #{path}/ portalshit:sites/tech.portalshit.net/_site/")
    puts "Your blog was successfully published!"
  else
    puts "Something went wrong..."
  end
end

だいぶデプロイが手軽になった。

I know why you came here. BECAUSE IT'S HARD TO FIND CONTENT IN GITHUB WIKI!!!

Here is a solution.

My colleague Tomohisa created a nice userscript. It provides you an ability to search GitHub Wiki in pretty easy way.

Install the script from his GitHub repository. It's compatible with Firefox (with Greasemonkey, of course), Google Chrome and Safari (with Nijakit).

github-wiki-search/github-wiki-search.user.js at master · linyows/github-wiki-search

:octocat: Search wiki of the repository on Github. Contribute to linyows/github-wiki-search development by creating an account on GitHub.

github.com

Then you will find search box on right above "Page History" button.

Now search all the wiki content with github-wiki-search.user.js!

Mac の iTerm 2 皆さん使ってますか。コンソール中に現れた文字列をハイライト通知できたりしていろいろ便利らしいですね。でも僕は使っていませんでした。なぜか。

Ctrl + Shift + J によるかな入力変換ができないから。

これが非常にだるかった。宗教上の理由や国外在住でJISキーボードが手に入らないなどの理由のためやむなく英語キーボードを使っている方、おられると思います。そういう人はだいたい Ctrl + Shift + J で英数 -> かなの入力変換を行っていると思いますが（Command + Space の切り換えもできなくはないけどだるいですよね…）、iTerm 上では Ctrl + Shift + J で改行が行われてしまうため、このような操作が行えていませんでした。かなから英数入力に切り替える Ctrl + Shift + * も同様、むなしく ' などが表示されるだけ。標準の Terminal.app ではできるのになんでやねん。

iTermでの日本語入力 - 初学者の箸置 なんかを参考に Send Hex Codes 0x4a するようにしてみたりしたのだけどうまくいかなかった。

しかし先ほど仕事をさぼって iTerm の設定項目を確認していたら以下の設定で使えるようになったのでここに書き記しておきます。

↑のように、iTerm の Preferences -> Profile -> Keys で Ctrl + Shift + J、 Ctrl + Shift + * の項目を追加し、メニューから "Do Not Remap Modifiers" を選ぶだけでオッケー。かな英数の切り換えが快適に行えるようになる。困っている方お試し下さい。

社畜なのでVドメインからMドメインにドメインの管理業者を変更した。そしたらDNSの設定やらなんやらを忘れていて、tech.portalshit.net が死んでた。最近は技術っぽい内容も www.portalshit.net に書いてるしここの存在意義が微妙になってきた。Jekyll、便利ではあるんだけど、rbenv で Ruby のバージョン上げるごとに gem install jekyll gsl とかやるのが若干めんどくさく感じられるようになってきてしまった。ただ記事を書くためだけにそこまでやりたくないかも。

Qiita の Kobito、入れてみた。いい気がする。

プログラミン関連のメモとかは Evernote に書いてきたけど、正直かなりだるかった。シンタックスハイライトできないし、タブ幅とかこちらで指定できないし、コードを入力した部分を選択して固定幅フォントを指定する手間とかもだるかった。

Qiita は基本的に Markdown で書くっぽい。