portal shit!

MacBook Air すごく速くて使いやすいけど、自分のものではなくて家庭の所有物みたいな感じになっててあまり使わせてもらえなかった。悔しいので3年前に買った MacBook Pro 15” の HDD を外して SSD に入れ換えてみた。嘘みたいに速くなった。買ったのはこれ。いまは 512GB のやつも3万円くらいで買える。

一緒にディスクケースも買ったけど、間違って SATA じゃなくて IDE のやつを買ってしまって買い直さないといけなかった。あとポリカ MacBook の頃はトルクスドライバーは T8 でよかったのに（本当は恐ろしいMacBookのHDD換装）、最近の MacBook Pro は T6 じゃないとダメらしいので注意が必要。折角 SSD が手もとに届いたのにトルクスドライバーが無いために換装作業が出来なくて悶々としてしまった。

取り換え作業自体はそんなに難しくない。ただし光学ドライブ外して SSD と HDD の二ストレージ構成とかにしようとすると難しいと思う。TimeMachine からの復旧は NAS からやったら信じられないくらい遅かったし（300GB のデータ転送に三日くらいかかった）、Adobe 製品のライセンシングが機能しなくなってものすごくめんどくさいことになったのでオススメしません。ポリカ MacBook で HDD の換装やったときのデータの取り込みは、ディスクケースに入れて USB 接続した旧 HDD からやったけどこういう問題には遭遇しなかった。こっちの方が速くて安全だと思う。

ちなみに円高終わるっぽいので換装を考えてる人は早めに SSD 買った方が良いですよ。

使った道具

きっかけ

今年の三月、持病の経過観察で京都に行きました。病院の合間に下鴨神社と上賀茂神社にお参りしたり、六波羅の平家ゆかりの寺、六波羅蜜寺に行って平清盛像を鑑賞したりしました。帰る日の夕方にはヒトデ９０９さんのありがたい法話を聞きながら銅製のタンブラーでビールを飲みました。しかしこのとき僕はすでに肛門近辺の痛みのためまっすぐ座ることが出来ず、お尻の左半分で椅子に腰掛け、右半分は空中に浮かせていました。ヒトデ９０９さんのありがたい法談も半分くらいしか耳に入っていませんでした。

僕が痔ろうを発症したのは恐らく京都に行った前の週に参加した故郷での同窓会です。同窓会は阿蘇いこいの村という宿泊施設でとり行われました。阿蘇いこいの村はテニスコートがありますので、学生時代にテニスサークルで痴情をもつれさせていた紳士淑女のみなさんは泊まってみるといいと思います。

僕は当初二次会には参加せずに帰ろうと思っていたのですが、参加者が少ないので協力して欲しいということで二次会に参加してしまいました。しかしこれが間違いでした。僕はインターネットの人と会ったときは饒舌なのですが、中学や高校の同級生と会ったときは寡黙になってしまいます。二次会では会場の隅っこに立って一人で延々キャラメルのリキュールを牛乳で割った液体を飲んでいました。これが全然酔わない。酔わないし手持ちぶさたなのでどんどんキャラメル牛乳酒を飲んでしまいます。これがまずかった。翌朝、下痢をしてしまったのです。

若い頃は飲み過ぎると吐いていました。しかし30歳になったあたりから酒を飲み過ぎると下痢をするようになりました。アルコールが体から抜けるまで下痢は治まりません。まぁ吐くよりかは楽なのですが、下痢は恐ろしいことに痔ろうの原因になるのです。

痔ろうはいきなり痔ろうにはなりません。まず最初、肛門周囲膿瘍というやつになります。お尻の穴の近くにおできが出来るのです。しかしこれは単なるおできではなく、肛門と直腸の間にある肛門陰窩というくぼみに下痢ピー状態のうんこが入り込んでしまい、そこが化膿してお尻の穴の近くまで膿を内包した袋が延び、肛門近辺におできを作ります。こいつがすこぶる痛い。38度程度の熱が出ます。このおできのことを肛門周囲膿瘍といい、おできから直腸のあたりまで繋がっている状態を痔ろうと言います。

告知

関西から夜の飛行機で帰ってきて眠りにつきますが、翌朝目が覚めたときには体がだるく、ただならぬ状態であることを悟りました。会社には遅れる旨連絡を入れ、天神近辺にある肛門科を探しました。

肛門科では見るなり肛門周囲膿瘍である旨告げられました。切開をして膿を出さない限り心の平安は訪れないそうです。僕は承知をして切開してもらいました。熱は下がりましたが、これからが地獄でした。

排膿したので熱は引きますが、傷口は相変わらず痛みます。傷口のろう管にガーゼを詰め込まれました。そしてさらに上からガーゼで傷口を圧迫される。僕は会社用と自宅用に円座クッションを二つ購入しました。会社では岡村製作所のバロンという上等な椅子に座らせてもらっているのに、この上に円座クッションを載せて座っていてなんだか残念な感じになっていました。

傷口はお尻の穴の近くなので当然お尻の穴の上もガーゼに覆われています。最悪なことに大便でトイレに行くたびにガーゼの張り替えをしなくてはなりません。お尻の穴なんて自分では見えませんから、ガーゼの張り替えは困難を極めます。当然シャワーを浴びた後もガーゼを張り替えなければなりません。僕は毎日月経中の女性のように小さなポーチを持って個室トイレに入り、ガーゼを交換していました。

手術

切開から一ヶ月が経つ頃には傷口は落ち着き、ろう管に詰め込まれたガーゼも取り出してもらえます。通常の生活ができるようになった！ しかしこれはつかの間の喜びなのです。切開後一ヶ月ないし二ヶ月を目安に、痔ろうを根治するための手術をしなければなりません。痔ろうとは放っておいても直らない病気なのです。

痔ろうは昔から多くの人を苦しめました。夏目漱石も痔ろうだったと言います（日本人編 近現代｜じなび - 痔の総合情報サイト -）。昔は痔ろうの手術のために肛門を切り開いてろう管をそぎ取ったりしていたそうですが、最近はシートン法というものがあり、手術のために入院する必要はなくなりました。しかしこれもすこぶる痛かった。

シートン法とは肛門と痔ろうの管を輪ゴムのようなもので縛り、ゆっくりゆっくりと肛門周辺の組織を切り取っていく治療方法です。手術自体は局所麻酔と内視鏡で終わりますが、術後に地獄のような日々が待っています。せっかく傷口から膿が出なくなっていたのに、ゴム紐で肉をゆっくりと切っていくため出血したり膿が出たりします。異物が体に入り込んでいるので椅子に腰掛けるのは不可能になります。自宅では無印良品の体にフィットするソファに覆い被さるような姿勢で過ごさざるを得ませんでした。

しかも最悪なことにシートン法のゴム紐は一週間に一度締めなければなりません。ゴム紐は肉を切っていくので、だんだん締め付けが緩くなっていきます。定期的に締め付けを強くしないと治療が進まないのです。この締めるときがまた痛い。ある日昼休みに病院に行って締めてもらったら、あまりの痛さに耐えられなくなってしまって午後から会社を早退してしまいました。

結局、3月初旬に排膿のための切開をしてから6月まで地下鉄で椅子に座ったことがありませんでした。外出するときも歩き疲れたからと喫茶店に入って休むということが出来ず（お尻が痛いので椅子に座って休憩することができない）、かなりのスリルをあじわいながら生活していました。梅雨入り前の暑い日、出来心で海まで歩いて行ったのですが、炎天下に歩き続けて疲れて歩けなくなったらどうしようと気が気ではありませんでした。疲れ果ててもう歩けないと思っても、ケツが痛いためタクシーに乗ることが出来ないのです。まさかこんなことでは救急車なんて呼んでもらえないだろうしのたれ死ぬしかありません。

シートン法のゴム紐がとれたときには涙が出るほどうれしかったです。そのときのツイートです。

【速報】ケツのゴム紐がいつの間にか落下しケツが復活【号外】

— ゴニーモンザレス (@morygonzalez) June 10, 2012

ゴム紐がとれたことがうれしくて、ワイフと二人で大ライスを食べて祝いました。

大ライシング twitter.com/morygonzalez/s…

— ゴニーモンザレス (@morygonzalez) June 12, 2012

まとめ

僕はラーメン二郎のことは愛していますが、痔ろうのことは大嫌いです。

この記事は拡散お願いしますアドベントカレンダー2012の13日目の記事でした。

明日は @fuba さんです

最近、会社でリーダブルコードを輪読したり、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

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

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

自戒エントリー。

自分は Mongoid を使って開発してるんですけど、時間の境界値のテストが不十分で問題に遭遇したのでメモっておきます。

Mongoid には Date 型や DateTime 型があるけど、データベースにデータを保存するときには Time 型に変換されます（MongoDB に Date とか DateTime がないから？）。Mongo Shell で DB の中の値を見ると Time 型の値が入ってる。

だからクエリを生成するときに Date.today はなるべく使わない方がいい。Date.today では時間を 00:00:00 として扱い、月末のデータの取得に失敗する可能性が高いから。Rails console で確認すると、以下のようになります。

pry(1.9.3-p194)> 1.month.ago.end_of_month
# => Fri, 31 Aug 2012 23:59:59 JST +09:00
pry(1.9.3-p194)> Date.today.prev_month.end_of_month.to_time
# => 2012-08-31 00:00:00 +0900

上記は二つとも「先月末の月の終わり」を検索していますが、後者では時間が 00:00:00 になっています。例えば以下のような Mongoid でのクエリでは、8月31日の午前0時0分1秒以降に作成された Document を取得することが出来ません。ナンテコッタイ！！！

Model.where(:created_at.lte => Date.today.prev_month.end_of_month)

「Date.today を時刻の生成の起点にしたとしても、to_time してあげればいいのでは？」と思う方もいるでしょう。確認してみましょう。

pry(1.9.3-p194)> Date.today.prev_month.end_of_month.to_datetime
# => Fri, 31 Aug 2012 00:00:00 +0000

#prev_month メソッドが呼び出された時点のオブジェクトの型は Date 型なので、Date 型に対して時間の操作を行って最後に DateTime 型に

結論

時刻まで考慮した時間の範囲でクエリを作るときは以下に留意すると良いでしょう。

• Date.today は使わない
• DateTime.now か 1.month.ago などを使う

ここにはっつけるコードのシンタックスハイライトには Google Code Prettify をこれまで使ってたんですけど、どうもいまいちでした。有名な SyntaxHighlighter も好きになれなかった。はてなブログのように綺麗なシンタックスハイライトさせたい！ ということで作った。

GitHub - morygonzalez/lokka-pygmentize: Syntax highlighter for Lokka

Syntax highlighter for Lokka. Contribute to morygonzalez/lokka-pygmentize development by creating an account on GitHub.

github.com

かなりシャレオツな感じにシンタックスハイライトできるようになったと思います。拾ってきた Monokai スタイルの CSS を当てています。

動作環境

裏側で使っているのは Python の Pygments。JavaScript オンリーで色付けするやつよりもこいつの方が圧倒的に綺麗でした。なのでこのプラグインを使うには Python と Pygments が必要です。Heroku では動くんでしょうか。動作未確認です。

使い方

HTML の pre タグのクラス名を lexer として Pygments に渡します。Ruby のコードを書くのであれば以下のようにします。

<pre class="ruby">
  <code>
  class Book
    def off
      "all your book is 10 yen"
    end
  end
  </code>
</pre>

やってること

JavaScript で pre タグを探してサーバーにコードの中身と pre タグのクラス名を投げると、Pygmentize された HTML が返ってくるようになっております。そいつを JavaScript で拾って pre タグの中身を入れ替え。

当初は

```ruby
class Book
  def off
    "all your book is 10 yen"
  end
end
```

みたいな感じで GitHub 風にしたいと思っていて、以下のような JavaScript を書いていたんですが JavaScript 力が低すぎて断念。

$('.body').each(function() {

  var Pygmentize = function(lexar, snippet) {
    var result;

    $.ajax({
      type: 'POST',
      url: '/pygmentize',
      async: false,
      data: {
        lexar: lexar,
        snippet: snippet
      },
    }).done(function(data) {
      result = data;
    });

    return result;
  }

  var entryBody = $(this).text();

  entryBody = entryBody.replace(/```(.+?) ([sS]*?)```/g,
    function(whole, lexar, snippet) {
      return Pygmentize(lexar, snippet);
    }
  );

  $(this).html(entryBody);
})

※Ajax なのに async: false とかしててイマイチ感ありますね。

とはいえ、汎用性の高い pre タグのクラス名を拾ってくる、という形での実装にしたので、 Markdown でなくても HTML でも Textile でもハイライトできるので結果オーライとします。

ちなみに Kramdown でクラス名を指定したいときは以下のようにするみたいです。

> hogehoge
{: .hoge }