以下、ぐだぐだととりとめなく。自分用に。

今年一年をふりかえってみたところ、8月の写真がまったくなかった。flickrにアップロードしていない写真すらほとんどなかった。7月と9月はそれでも数枚あり、10月以降はいくらか写真が残っていた。7月あたりから外出していなかったのを実感した。

今年は仕事でもプライベートでも本当にあわただしかった。忙しいときとそうでないときの差が大きかった上に、忙しくなる時期をうまく予見できず実際の仕事量よりも疲労をためこんでしまった。また、浅浮き深沈みを何度か繰り返してしまい、どーんと落ち込んで無気力に陥いった。その度に迷惑をかけてしまったり、頼りまくったり、した。お世話になりっぱなしの一年だった。

今年、新たにやりたいと考えていたことはおおむねできなかった。そのうちの一つについて、なんとかとっかかりだけでもつけようと、この時期になって気力をしぼり出そうとしているような状況。来年は、と考えるのも少々つらい。

でも来年は、というよりできるだけ早い時期にあたりをつけて、その後のことを具体的に考えられるようにしよう。

というのはtypoのバグを放置していた自分のせいである。

最近どうだったのかは分からないが、以前のtypoはtrackbackなどの処理で長い文字列をマルチバイトシーケンスを無視して切り詰めていた。このため不正なマルチバイトシーケンスが生じることがあり、それらの文字列はそのままDBに入れられていた。こうした状況に気付かないままRuby 1.9系に移行してしまったため、特定のページを表示させようとすると不正なシーケンスであるという例外が発生する結果となる。

具体的には"あいうえ\xE3..."といったもので、エンコーディングはUTF-8。不正部分を取り除いて保存し直してやればよいのだが意外と手間取った。

Rubyの多言語機能を使えば、不正なマルチバイトシーケンスを無視してエンコーディング変換させることができる。これにより正しいシーケンスのみを残した文字列を生成できるのではないかと考えた。だが、これは単純には実行できなかった。次のようになる。

str = "あいうえ\xE3..."
str.valid_encoding? #=> false
str.encode('UTF-8', 'UTF-8', :invalid => :replace, :replace => '') #=> "あいうえ\xE3..."

変換前のエンコーディングがUTF-8なのだが、UTF-8→UTF-8では変換が行われないということだ。次のように一度他のエンコーディングに変換すると期待通りとなる。

str.encode('EUC-JP', :invalid => :replace, :replace => '').encode('UTF-8') #=> "あいうえ..."

今回のケースでは、日本語であることが分かっており、まずまずUTF-8→EUC-JP→UTF-8でも問題なかろうという予想もついていた。件数も少ないし、これでもよいといえばよいのだが——やっぱりちょっと手を抜きすぎているように思える。

そこで、同じやり方をIconvで行うとどうなるかを試してみた。

require 'iconv'
Iconv.iconv('UTF-8//IGNORE', 'UTF-8', str).first #=> "あいうえ..."

こちらは期待通りの結果が得られた。Iconvについては「iconv will be deprecated in the future, use String#encode instead」とサポート終了が予告されているのだが、このようなケースではまだ使いでがある。(あまり一般的なケースではないだろうが。)

次に正規表現を使うことを考えた。鬼車のドキュメントによれば[[:print:]]により正しい文字にマッチさせられるはずだ。

str.sub(/\A([\s[:print:]]+).*/, '\1...') #=> ArgumentError: invalid byte sequence in UTF-8

残念。入力に不正なシーケンスが含まれていると扱えないようだ。だが、これに関していろいろ試しているうちに次の動作に気付いた。

str.encode('UTF-8','UTF-8').sub(/\A([\s[:print:]]+).*/, '\1...') #=> "あいうえ..."

変換元、変換先に同じエンコーディングを指定してencodeすることでvalid_encoding? #=> trueとなる。(少なくとも今回のケースでは。)ちなみに変換元を指定しないと「ArgumentError: invalid byte sequence in UTF-8」が発生する。

とまあ、そんなような経緯の後、Iconvを使ってエラー状態から復帰することにした。

追記(一夜明けて)

EUC-JPではなくてUTF-16あたりを介せばよかっただけではないかと今になって気付いた。

"あいうえ\xE3...".encode("UTF-16", :invalid => :replace, :replace => '').encode("UTF-8") #=> "あいうえ..."

それにしてももう少し簡単にできないだろうか。

それはともかく。レビューするとなると、普段ならざっくり飛ばし読みにしてしまうところまでじっくり読むことになる。そういうところも含めて読んでみていてふと思った。この本はwebアプリケーションの「開発」を始めたいという人のための入口にちょうどよいのではないか。

プログラミングの入門書でもweb系の題材が出てくることはおそらく珍しくないだろうと思う。ただ、そういった本の目的は、コードの一行一行を理解させること。だから、と言ってしまうと短絡的すぎるかもしれないが、多くはアプリケーションとして書いたことがきちんと動くというところが到達点になるのだと思う。

この本では、コードの一行一行の理解というところに焦点をあてていない。あ、これは前半のチュートリアル的なパートは、ということなのだけど、この部分においては、具体的なコードの細部について「きっとこのように動かすためのコードだろう」というあたりを付けられれば十分、それよりももう少し広い範囲を理解しようといった雰囲気がある。

本書は430ページほどあって、その半分ちょっとの240ページほどがチュートリアルと、本書を読みこなす上で必要となる最小限のRubyの解説に振り向けられている。そして、その前半部分のおよそ1/3あたりまで(Ruby自体の解説を除けば)コードらしいコードが出てこない。Railsのお約束に従ってアプリケーションを構築するばかりである。そして最初に書くコードはテストだった。

test "product attributes must not be empty" do
  product = Product.new
  assert product.invalid?
  assert product.errors[:title].any?
  assert product.errors[:description].any?
  assert product.errors[:price].any?
  assert product.errors[:image_url].any?
end

あなたが作るアプリケーションは、あなたの手を離れた環境で動作する。コードが単体で動くわけではなく、フロントエンドのHTTPサーバとか、CSSなどの外部ファイル群とか、キャッシュとか、そういった関連の中にあって運用される。そんな中で、Railsを使ってする開発というのは、どんなもので、どういうふうにすればいいのか。それを学ぼうとするのがこの本なのではないか。

このような印象となったのは、この本で扱っているRailsのバージョンが3.1だという点にもよるところがあると思う。Railsが注目されだした当初、フルスタックであるという言い方をされることがあった。その面はより実務的に進んできているように思う。その分、旧来からのRailsユーザの一部(私のような時々Rails者)にはしばしば戸惑いを感じたりもするのだが、それらを拾い集めていくと、最先端ではないにしても、また詳細に理解できるとまではいかないにしても、実際のサービスの場面で必要とされる、あなたの目の前のコード以外の様々なものの様子をとらえることができる——んじゃないかな。と、そんなふうに思った。

オーム社eStore(β) PDF版 2,560円(+税) PDF版+紙版 4,800円(+税)

amazon.co.jp

【送料無料】RailsによるアジャイルWebア... 価格：3,360円（税込、送料別）

コードそのものはCapistranoでdeployできるようにしてある。でも、久しぶりのことなので念のためdeploy:update_codeなど試しておく。typo自体のテストも通してみる。いくつかfailしているが、ざっと見た上で、リリースされていることでもあるから問題ないのだろうということにした。順調。だったから。ここで、ふとRuby 1.9.3化もやってしまうかと考えたのだった。

Ruby Enterprise Edition 1.8.7-2011.03から1.9.3-p0へ。軽く考えていていたのだが、まあ実際のところ、全体的にはそう大変な作業ではなかったと思う。とはいえトラブルはあった。

最初のトラブルはRuby 1.9.3 & Passenger 3.0.9 で「Unexpected end-of-file detected」(ITS: Passenger Ruby)だった。まったく同じ状況になった。が、その分、同じ方法で回避できた。

ただ、こちらの環境はPassenger+Nginxであったため、Passengerの再インストールはNginxの再インストールにもつながり少々めんどうである。Passengerの修正を見てみたところ、ラッキーなことに、Ruby用の拡張ライブラリに対する変更だけであった。そこでこの変更を直接適用し、拡張ライブラリのみrebuildすることにした。(このことを忘れて後ではまるかもしれないが……。)

次のトラブルは文字エンコーディングに関するもの。ほとんど問題なかったのだが、管理画面のうちのサイドバーの設定の部分で例外が発生した。(サイドバーが消えさってしまったので、どうなっているか見ようとしたときに気付いた。)

ビューの中でエンコーディング非互換の例外が起きている。ビューの中にロジックがあるわけではなく、メソッド呼び出しがそのまま埋め込みになる部分だった。そのため何が起きているのか逆に把握し難い。ひとまずその場でforce_encodingして表示できるようにし、何がどのように混じっているのか見てみることにした。すると、typoのサイドバー用のレコードの一部がASCII-8BITになってしまっていること、文字化けが発生していることが分かった。

これらのレコードは1.8.7で運用していたときに保存されたものである。当然、記事データなども同じなのだが、そちらでは問題は発生していない。両者の違いはserializeされているかどうかにあり、つまりYAMLの挙動にもよるようだ。文字化けのほうは、YAML上の"\xE3\x81\x93"のような表現の解釈の違いによる。(この形式のYAMLデータがDBに保存されていた。)

YAMLの挙動を確認してみる。

Ruby 1.8.7

irb(main):001:0> YAML.load("--- \ntitle: \"\\xE3\\x81\\x93\"\n\n")
=> {"title"=>"\343\201\223"}

Ruby 1.9.3

irb(main):001:0> YAML.load("--- \ntitle: \"\\xE3\\x81\\x93\"\n\n")
=> {"title"=>"ã\u0081\u0093"}

Ruby 1.9.3 (YAML入力が!binary形式だった場合)

irb(main):001:0> YAML.load("--- \ntitle: !binary |\n  44GT\n\n")
=> {"title"=>"\xE3\x81\x93"}

問題が発生していることは確かなのだが、その場合でも、文字エンコーディングはUTF-8になる。これがASCII-8BITになってしまったのは、どこでどうしたからなのかよく分からない。はて。(!binary形式の場合、文字化けせず、ASCII-8BITになる。)

と、そうこうしているちに空き時間を使い切りそうになってしまい——結局、問題が起きたレコードがそれほど多くはなかったので、あらかじめとっておいたMySQLのダンプからコピー&ペーストにより上書き再設定を行った。

その後

もう少し調べてみようと思ったのだけど、二つの環境をいったりきたりが意外にめんどうで追求できていない。ただ、YAMLに関してはデータを移行できないケースがあることがわかった。

$ ruby1.8 -r yaml -ve 'YAML.dump("あいう", $stdout)'
ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]
--- !binary |
44GC44GE44GG

(Ruby 1.9.2)
$ ruby1.8 -r yaml -e 'YAML.dump("あいう", $stdout)' | ruby -r yaml -ve 'p YAML.load($stdin)'
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]
"\xE3\x81\x82\xE3\x81\x84\xE3\x81\x86"

(Ruby 1.9.3)
$ ruby1.8 -r yaml -e 'YAML.dump("あいう", $stdout)' | ruby -r yaml -ve 'p YAML.load($stdin)'
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
/home/akira/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/psych.rb:154:in `parse': (<unknown>): couldn't parse YAML at line 3 column 0 (Psych::SyntaxError)
	from /home/akira/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/psych.rb:154:in `parse_stream'
	from /home/akira/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/psych.rb:125:in `parse'
	from /home/akira/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/psych.rb:112:in `load'
	from -e:1:in `<main>'

マルチバイトというか!binaryだとまずいみたい。また、!binaryであっても配列やハッシュの中にあれば例外にはならない。

Foo.where(:name => 'baz')

これはもちろん問題なく実行できる。次のような関連を使う場合でも特に問題は起きない。

Foo.joins(:bar).where(:name => 'baz')

ここでハッシュ表現できないような条件を考えてみる。

Foo.where('name like "baz"')

これももちろん問題ないのだけれど、次のようなのになるとちょっと困ってしまう。

Foo.joins(:bar).where('name like "baz"')

もしもこれを実行しようとするとStatementInvalid例外が上がってくる。SQL文を生成させてみると「WHERE (name like "baz")」となってしまっているのを確認できる。

whereメソッドで指定するSQL片の書き方を変えればこの状況を回避できる。ただ、ここでテーブル名を持ち出すというのには引っかかりあって、これはどうにかならないものかと思ってしまう。table_nameメソッドを使うなどしてテーブル名を書かないようにしてみたりもするが、それも少し引っかかる。

ある時、Rails 3では次のように書けるというのを知った。

t = Foo.arel_table
Foo.joins(:bar).where(t[:name].matches('baz'))

こちらで生成されるSQL文では「WHERE (`foos`.`name` LIKE 'baz')」のようになり、上のような例外は発生しない。

これがArel。Arelを使うと、この他にも、たとえば「or」なんかもSQL直書きをせずにすませられる。次のようにかなり強力である。

Foo.where(t[:name].eq('foo').or(t[:name].eq('bar'))).order(t[:name].asc))
#=> ... WHERE ((`foos`.`name` = 'foo' OR `foos`.`name` = 'bar')) ORDER BY `foos`.`name` ASC

実際、Arelは新しくなったActiveRecordを支えているものの一つであって、Rails 3でおなじみになった次のような書き方もこのArelのレイヤで可能となっている。

c1 = t[:name].eq('foo')
c2 = t[:name].eq('bar')
Foo.where(c1.or c2)

もっともこれらは例のための例といったものでもあって、このような単純なケースであれば次のように書いてしまったほうが早いかもしれない。

Foo.where(t[:name].eq_any %w(foo bar))

詳しくはRuby Freaks Lounge第43回 Rails 3を支える名脇役たち その1 - Arel -を。どんなメソッドがあるのかについては今のところソースコードを見るのかな。(ところでmatchesで生成されるLIKEへのESCAPEを指定する方法はあるのだろうか。)

こうしたとき、まず考えるのはproxyの利用だ。目的のwebサイトにアクセス可能な別のホスト(中間ホスト)でproxyサーバを動作させる。そしてそのproxyを経由して目的のwebサイトにアクセスする。この方法でめんどうなのは、アクセス元(自ホスト)、アクセス先(目的のwebサイト)とは本来関係のないホストで管理・運用作業が発生する点である。今後ずっと、というのでなければ採用しづらい。

次に考えるのはSSHによるポートフォワードを使った方法だ。こうした一時的な状況では、関係各ホストにSSHでならアクセスできることが多い。SSHの機能を使い、自ホストと中間ホストにトンネルを作る。webサイトへのアクセスを、このトンネルへのアクセスに代えることにより関接的なアクセスが可能となる。

ssh -L 20080:www.example.com:80 proxy.exmaple.jp

この例では自ホストの20080ポートへのアクセスが中間ホスト(proxy.example.jp)を経由して目的のwebサイト(www.example.comの80ポート)へとつながっていく。中間ホストで特別な作業は発生せず、手軽でよいのだが、一般的なブラウザでアクセスする際に「http://www.example.jp」でなはく「http://localhost:20080」を指定しなければらない問題がある。単純なところではリンク切れが起きる可能性がある。

通常通りのURLを指定して、かつ、SSHのトンネルにアクセスを導くには、SSHおよびブラウザのSOCKS対応機能を使う。

sshにはSOCKSサーバとして動作する機能がある。また、多くのブラウザは、proxy機能の一部としてSOCKSクライアントとしての動作ができるようになっている。proxy機能であるから、通常通りのURLを指定しても実際のアクセスはSOCKSサーバに振り向けられる。よってURLを「localhost」などと変えなくてもすむ。

ssh -D 21080 proxy.example.jp

ブラウザではSOCKSサーバをlocalhost、ポートを21080とする。この設定したブラウザは、すべての通信を指定のSOCKSサーバを介して行うようになる。となると、目的のwebサイト意外へのアクセスまで含めて中間サイトからアクセスする状況に陥いってしまう。これは通常やりすぎである。

SOCKSサーバの使用をアクセス先によって選択することができないか。FirefoxならFoxyProxy、ChromeならProxy Switchy。これらはまさにそのための拡張だ。ところが、現在のProxy Switchyには問題があるようで、こうした動的なproxy選択の機能が動作しない。この問題の回避方法もあるようなのだが、そのためにはシステムのproxy設定を変更することになる(そもそもそうした動作をするものであるようだ)。そして、そのための設定にはPACと呼ばれるファイルを用いる。

PACには、ブラウザがproxyの使用が必要かどうかを判定するための要件を記述できる。これまでほとんど縁がなかったため考えから抜け落ちていたのだが、前述した拡張を使うまでもなく、適切な内容でPACを作成してシステムに適用すればよい。

PACの書き方については検索すればいくつもの情報が見つかる。けれども、それらの多くで参照している大本のnetscapeのサイトが消失しておりなかなか追求できない。そのため現在ではWikipediaを参照するのがよさそうだ。日本語ではプロキシの自動設定方法やPacファイルによるProxyの指定などを併わせて読むと参考になる。今回のケースでは次のような記述をすれば十分であろう。

function FindProxyForURL(url, host) {
  if (shExpMatch(url, '*://www.example.jp/*')) {
    return 'SOCKS localhost:21080';
  }

  return 'DIRECT';
}

この程度の簡単な内容であれば動作確認は簡単である、と言いたいところだが、実際のところ「()」の書き忘れをするなどということをしてしまい書き換えと確認を何度か繰り返し行った。そこで、w3cのHTML validatorのようなものはないものかと探してみたのだが見付からない。次に、結局のところPACはJavaScriptであるためコマンドラインから実行するツールを探してみたところpactesterが見付かった。

pactesterはJavaScriptの実装であるSpiderMonkeyと、PAC記述のためのサポートスクリプト(JavaScript)およびコマンドそのものとなるPerlスクリプトからなる。SpiderMonkeyとPerlを接続するためにJavaScript::SpiderMonkeyというライブラリを使っている。問題はこのライブラリのパッケージが手元の環境にはない点である。もちろんCPANを使うなどすればよいのだろうが……。

別の実装はないかと探してみたがこれというものを見付けられない。SpiderMonkeyのほうで何かないかと検索範囲を広げていったところ、JavaScriptのテストというテーマの中で発表されたさいきんのJavaScriptテストの資料に行きあたった。同資料の中ではAjaxを含む、というよりそれをメインのターゲットにしたJavaScriptのテストを支えるテスティングフレームワークの興味深い内容に触れられている。そんな中に、今回の状況、PACのテストに使えそうなものがあった。

JohnsonはRubyとSpiderMonkeyを結び付けるライブラリである。前述のJavaScript::SpiderMonkeyがPerlとJavaScriptの中間に立ったように、このライブラリはRubyとSpiderMonkeyの中間に立つ。資料の本題ではEnvjsと組み合わさることでブラウザ上でのJavaScriptコードの動きをコマンドライン上で検証できる様子が示されている。もちろん、ここではそこまで高度なことは必要ない。PACを実行し、その動作が想定通りであることを確認するのが目的である。

前掲のPACのような簡単なものでもJavaScriptの組み込みではない関数が登場する。一般的なJavaScript実装においてPACの動作を検証するためには、これらの関数を何らかの形で実装しなければならない。だが、これを独自に実装するのでは本末転倒である。幸い、先に紹介したpactesterにそのためのJavaScriptコードが含まれている。pac_utils.jsがそのコードであり、もともとはmozillaのコードの一部をもとにしたものだそうだ。

pac_utils.jsがあれば十分かというと、もう少し足りない。Wikipediaの解説にもある通り、さらに二つの関数、dnsResolve()とmyIpAddress()を実行系で使用できるようにする必要がある。pactesterではこの部分をPerlコードとして実装しており、Johnsonを使うのであればRubyコードで実装することになる。このようにしてできたのが以下のPACテスト用スクリプトだ。

pac_file = 'proxy.pac'

tests = [
  # {:url => 'http://example.jp', :expect => 'proxy spec', ... }, ...
  {
    :url => 'http://www.example.jp/',
    :expect => 'SOCKS localhost:21080',
  },
  ...
]

hosts = {
  # hostname => '10.1.1.1', ...
}

require 'uri'
require 'socket'
require 'rubygems'
require 'johnson'

def dns_resolve(host)
  Socket.gethostbyname(host)[3].unpack('C4').join('.')
rescue
  nil
end

runtime = Johnson::Runtime.new
runtime.load('pac_utils.js')
runtime.load(pac_file)
runtime['dnsResolve'] = proc do |host|
  map[host] || dns_resolve(host)
end

failed = false
tests.each do |hash|
  runtime['url'] = hash[:url]
  runtime['host'] = hash[:host] || URI(hash[:url]).host
  runtime['myIpAddress'] = hash[:client_ip] || '10.0.0.1'

  expect = hash.delete(:expect)
  proxy = runtime.evaluate('FindProxyForURL(url, host)')
  unless expect == proxy
    puts "failed: #{hash.inspect} #=> #{proxy} (expected #{expect})"
    failed = true
  end
end

exit 1 if failed

日曜だということもあってか、全体的にさわがしくて気が散らなくてよかった。電源があるかどうかは確認しなかったけど、思いのほかはかどったので電池切れになる前に一段落つけることができた。

いや、実のところ、もう少しで一段落というところで、きつーい香水をこれでもかってほどふりかけてきたらしき中年女性が入ってきて、しばらく気付かなかったのだけど、リアルに噎せかえるというのをやらかしてしまったのだった。もう少し、もう少し、と言いきかせながら息を止めぎみでcommit。一段落させた。

帰りについでに本屋に寄ったら気になる本が三点ばかり。

• 鎌倉・横浜・湘南今昔歩く地図帖 - 古い地図や風景写真と今とを並べて紹介、解説しているという内容。ぱらぱらめくるだけでも楽しかった。今度鎌倉に行くときには買っていこうかな。
• 日本人はなぜ日本のことを知らないのか - 帯に「ここが最古の国って知ってた?」というようなことが書いてあって気になった。前書きをざっとながめたところではあおるようなトーンでもなさそうな感じだった。
• コーヒーもう一杯 - 小説。カフェを開業することになった女性の話、みたい。帰ってからずんずん気になってきて、中身をたしかめてから帰ればよかったなと今になって。

楽天ブックス 鎌倉・横浜・湘南今昔歩く地図帖	楽天ブックス 日本人はなぜ日本のことを知らないのか	楽天ブックス コーヒーもう一杯
Amazon	Amazon	Amazon

帰りにちょっとだけぶらついてみた。ゆっくり歩く。二の酉が明日ということで準備をしているようだった。

好きなまんががちゃんと続いてくれるためにはやっておいたほうが良いのだなと、かなり今更なのだけど思うようになったので。いつもいつもでなくても「これだけは」という連載や読み切りがあったときには送ろうと思う。

ただまあイス取りゲームなんだよね。やっぱり。

PDF版も買ったのは、なんせ紙版はでかくて重いから。ボリュームたっぷりなので検索できるのはうれしいし。紙版を買うタイミングでPDF版もあれば(別に安くなくても)PDF版を買っただろうと思う。もちろん今と同じくDRMなし、つまり特定デバイスしばりなしならば、という条件は付けたろうけど。

ところで、この本を手にすべきかどうか迷っている人は、まずこの本の目次なり紹介なりに目を通してみて、その上で「これは読まなくてよい」と確信できないならば読んだほうがよいと思う。(あ、もちろん、このテーマに興味があるとか業務で関わっているとかというのが前提だけど。)

これから買うなら、PDFで「読書」する環境をすでに整えている人はPDF版がお得だろう。特に今は、ってまあ言うまでもないけど。他方、紙以外での読書になじみがなく、かつ、通読したいという場合にはもしかすると紙のほうが扱いやすいかもしれない。

【送料無料】体系的に学ぶ安全なWebアプリケ-ションの作り方 価格：3,360円（税込、送料別）

やはりいったりきたりしながら読み進めるときは紙のほうがまだ楽かな。指三本くらいはさんでたりとかできるし。もっとも、この本を読むときにそんなに指をはさんでおかなければならないかというと、そうでもないんじゃないかなとも思うけど。

なかなか行けないのは量が多いため。値段も相応に高めではあるのだけど、それでも十分なボリュームがある。具がたっぷり——野菜カレーならどっさり、といった具合い。数年ぶりでも変わりなし。ただメニューは少し増えているような気がする。

食後、めがねの鼻あてがひんまがってしまっていたのを直してもらいに行って、その道中でセール中であることを知ったかずさ屋で雅芋などを買ってきた。

我が家で現役、現存する(おそらく)ただ一つのヒューズ。見えないところには他にもあったりするのかな。

元町通りに入ってしまうとどこも込み合っているだろうから、その少し手前、ちょうどよく空いていたZOULI Cafeでランチをとることにした。ずっと前から知ってはいたけど入るのは初めて。チャーミングセール向けのランチメニューがあったのでそれをたのんだ。前菜にカレーとパスタ、パン、ミニデザートと飲み物がセットで1,000円。デザートのチーズスフレは一口サイズではあったがおいしくて満足。

意外にも、といってよいかどうか、18:00までは禁煙とのことだった。ありがたい。

買い物の成果はというと、セールっぽいものは特に買わず。1ロールケーキで季節限定のロールケーキを買って帰ってきた。

閉店してた(追記 2011-11-04)

先日通りがかったら営業してなくて、休みかな?でも 妙にさっぱりしてるね、などと言っていたところ、今日通りがかったら中身が空になっていた。10月で閉店したとのこと。

IIと比べると液晶の解象度が格段に上がっている。I、IIでの不満はここだったので今回はちょっと欲しい度が高め。今見ててIIIのときに液晶が変わってたことに気付いたんだけど、タイミングとかあれやこれやで見送ったのだったかな。

GR Dはなんだかんだ使い勝手がよくて手離せない。(というのには一眼のレンズがないせいも含まれるかもしれない。)手元のはIIなので一般的なコンデジと比べてもまだまだ遅い。そのせいで猫がいっちゃった、なんてこともちょくちょくあったりする。ただ、なんというか、気持ちの面でいうと「あは、撮れてる」というようなところで、それはそれで。そんな撮りそこねが手元にわりと残っていたりする。

まあ、その一方で、一眼のレンズも欲しいわけなんだけど……。

わりとちゃんとしたファンタジー。感じとしてはマロリオン物語とかリフォトウォーサーガなんかを気に入っている人ならがっつりいけるんじゃないかと思う。

まあ、私がそうだっていう話なんだけど。実際のとこ、マロリオンもリフトウォーも久しぶりに読み返したくなった。ただ両作とも読み返すとなるとどっぷりつかってしまうボリュームなので今はむずむずしつつもガマン中。特にマロリオンはベルガリアードから読み返しにくなるし、このきっかけだとエレニア記やタムール記にまで手がのびそうだし。

逆に「魔法の材料ございます」を気に入った人ならエディングスやフィーストもいけるんじゃないかなと思う。問題はどっちも入手困難っぽいことなんだけど……。

【送料無料】魔法の材料ございます 価格：630円（税込、送料別）

それにしてもこれがデビュー作ってすごい。