| @旅行/散歩

パルテノン神殿

2015年6月22日

振り替え便は 8:10 と聞いていたので 6 時に起きて飛行機に乗る準備をした。 7 時前にチェックアウトして空港に向かうと、昨日見た顔の人たちが何人かいた。タクシー代の精算を済ませ、搭乗手続きをして飛行機に乗ると、エーゲ航空のスッチーたちは何事もなかったかのようなにこやかな表情を浮かべていた。

アテネには一時間足らずで着いた。なんとこの日は天気が悪く、アテネ到着時は雨が降っていた。

アテネ到着

前日にアテネの宿を手配できなかったため空港に着いてから空港の無料 WiFi を使って予約しようとしたが、アテネ空港の WiFi は 60 分間しか無料で使えず、結局空港のパソコンを使って予約した。

アテネ空港はギリシャ到着時に食事したときにめちゃくちゃ高くてどうしたもんかと思っていたが、空港の外に出て空港職員等で混雑するサンドイッチスタンドに入ると、 €2.5 で食べ物が買えた。ここでコーヒーを飲みながらほっと一息つくことができた。

その後メトロでアテネの街中へと向かう。アテネ空港は成田と同じで、名前こそアテネだけど全然アテネじゃない場所にある。電車で 40 分くらいかかった気がする。

Athens city view from Acropoli

アテネの市街についてまずびっくりしたのが、街並みのヨーロッパっぽくなさだった。道が広くて路上駐車の車がたくさんあるのはヨーロッパっぽいんだけど、道路の舗装は適当でゴミや動物の糞が散乱しており、マンションのすべての側面には汚らしいバルコニーがくっついていて植物やらなんやらをみんな好き放題外に出しており、非常に猥雑だった。ヨーロッパというより東南アジアにでも来たような景観だった。

Athens

またアテネはサントリーニ島やミコノス島に比べて圧倒的に緑が多く、湿度も幾分か高いようだった。普段は 6 月に雨が降ることはなく異常気象だと泊まった宿の主人は話していたが、モンスーン気候に慣れた身からすると、乾燥の激しいサントリーニ島やミコノス島は過ごしにくく、雨降りのアテネはとても過ごしやすく感じられた。

Athens

アテネの宿はアクロポリスなどといった主な観光地にも歩いて行ける場所にあるものを選んだ。 €107 だったが安くても一泊 €200 オーバーだったサントリーニ島からすると別天地という感じだった。部屋は広く風呂は豪華で、たっぷりと暖かいお湯のシャワーを浴びることができた。

宿にはチェックイン時刻よりも早く着いたので、荷物を置いて観光へ出かけた。レストランに入ってメニューを見るとサントリーニやミコノスの観光地レストランの値段に比べるとずいぶん安い。しかもハンバーガーを頼んだらパンが一枚でハンバーグが二枚のやつが出てきた。ギリシャ人、こんな経済観念だから経済崩壊するのでは、と思いつつ、アテネサイコーと叫びながら子牛のハンバーグを食べた。

パン一枚に肉二枚

食事のあとは街をうろつき、最初携帯の SIM を買った ΓΕΡΜΑΝΟΣ を見つけたのでプリペイド SIM のチャージができるかどうか聞いてみた。サントリーニ島のショップでは、追加チャージはできるが翌月にならないとできない、という説明を受けていた。しかしキャリアの COSMOTE のウェブサイトを見てもどこにもそのような記述はなく、おかしいなぁと思っていたのだった。 €6 で 500MB のチャージを頼み、携帯を出すように言われたので Pocket WiFi を出すと、「その端末ではこの SIM カードを使うことができない」と言われて一瞬雲行きが怪しくなったが、自分たちが持っている iPhone は SIM ロックがかかっていて Pocket WiFi 経由でないとインターネットに接続することができないことを説明すると「OK」と言って追加作業をやってくれ、再びインターネットにアクセスできるようになった。

その後街を散策し、子どもが喜びそうな蒸気機関車型の観光バスを見かけたので乗ってみることにした。大人一人 €5 で、アクロポリス周辺の主立った観光地を周遊でき便利だった。乗り降り自由らしいので乗り降りしてプラカ地区やシンタグマ広場に行ったりすることもできる。我々はその勝手を知らずに漫然と一周してしまってもったいなかった。

アクロポリス バスから見たアゴラ

バスに乗ったあとにパルテノン神殿に上ってみたが、正直なところ圧巻だった。今回の旅行ではアテネはスルーする予定だったがエーゲ航空がキャンセルになったせいでアクロポリスを訪れることができたのはある意味幸運だったかも知れない。

パルテノン神殿

パルテノン神殿を観光していて初めて知ったのだが、パルテノン神殿は風化であのように朽ちているのではなく、 17 世紀にヴェネツィアによる砲撃を受けてあのようになった、とのことだった。当時でもすでに 2000 年以上の歴史を経ていたパルテノン神殿を破壊するなんて罰当たりなことだと思ったが、 Wikipedia によると、当時ギリシャを支配していたオスマントルコは、ヴェネツィアもパルテノン神殿の歴史的価値に敬意を表して砲撃すまいと高をくくって女子どもを避難させ、アクロポリス内に弾薬庫を作って弾薬を貯蔵していたのだそう。しかしヴェネツィアは一切斟酌せずパルテノン神殿に砲撃を浴びせたらしい。

修復中のパルテノン神殿

そのような状況になったパルテノン神殿を修復しようという動きはギリシャ独立後の 19 世紀中頃からあって様々手を加えられているが、 1800 年代後半から戦前にかけての修復は、古代の手法を忠実に再現するのではなく、鉄を使って無理矢理修復するという手法で、そのせいでかえって他の部分に負荷がかかり、現在は 19 世紀から 20 世紀前半にかけて行われた誤った手法の修復で傷んだ箇所を正しい手法で直しているところなのだそう。

修復されたパルテノン神殿

そういえば順調に行けば今頃訪れていたはずのドゥブロヴニクも、一時はヴェネツィアによって支配され、イタリア文化を受容しているのであった。ヴェネツィアとは地中海沿岸でやりたい放題やってたんだなぁ。

パルテノン神殿をゆっくり時間をかけて観光したあとは、一旦宿に戻ってシャワーを浴びて休憩した。三人とも何を食べてもトマトとオリーブオイルとハーブの入っている地中海風の料理に飽きていて、汁付きの麺類が食べたいと、アジア料理の店を探してアテネ一番の繁華街のシンタグマ広場へと向かった。

遅い時間にわざわざやってきたのに嫁さんが目をつけていたアジア料理屋は看板を掲げておらず、あるはずの場所には別の中華屋があって営業していた。店の前でひとしきり夫婦げんかをしたあと、あきらめてこの店に入って中華料理を食べることにした。

この中華屋が正解で、酢豚もチャーハンも中華麺もどれもうまかった。変な香辛料は入っていないし唐辛子辛くもなく、日本人にとって非常に食べやすい味付けだった。青島ビールを三本飲んでも会計は €30 程度で、一食で €70 ほどかかっていたサントリーニ島と大違いだった。しかも店の女将の中国人が非常に親切で店も清潔で、まるで日本に帰ってきたかのようだった。

中華屋の麺

食事を追えて最終一つ前の地下鉄で宿に戻り、倒れ込むように眠りについた。

2015年6月23日

翌朝は宿を出る際に領収書の宛名書きの件で嫁さんが宿のレセプションともめて、そのせいで夫婦げんかをしてしまった。一旦別行動をとることにしたのだけど、一人でアクロポリスのベンチに腰掛けているとなんかいろいろどうでも良くなってしまって、嫁さんから届いていたメールを読んで昨晩食事をした中華屋のあるシンタグマ広場で合流することにした。

昨晩 0 時近くまでいた中華屋には同じ面々がいて店を営業していた。この人たちはよく働くなぁと感心しながら店に入って食事を注文した。ギリシャ人は働かないと日本のマスコミでは言われるけど、アテネのこの中華屋の人たちも、サントリーニ島のホテルの人たちも、朝早くから夜遅くまでとてもよく働いていた。実は EU の中でギリシャ人の労働時間は結構長い方だという記事もある。新聞やテレビで見るのと実際に訪れてみるのではずいぶん事情が異なるなぁという思いを強くした。

昨夜の店内には現地のギリシャ人の客しかいなかったが、この日の店内には中国人だらけだった。

中国人の観光客はギリシャにいっぱいいたが、不思議なことに彼らは昼間はそこかしこにいるのに、夜になると潮が引いたかのようにさっと姿を消す。それは見事なものだった。夜の街を出歩いて中国人の姿を見かけることはないし、盛り場に行っても夜に中国人の姿を認めることはできない。

ミコノス島で二日連続通ったレストランの面白ウェイター氏によると、中国人はあまり良い旅行をしていないそうで、一泊ずつ街を転々とするのだそう。ひょっとしたら毎朝早い時間に宿を出て次の街に向かわなければならないから彼らは夜の街に姿を見せないのかも知れない。

プラカ地区

食事のあとはシンタグマからプラカ地区の土産物屋を冷やかしたりしながら宿のある方向に向かって歩いた。途中土産物を買うため嫁さんとアクロポリスのあたりで別れ、自分は一人で宿まで預かってもらっていた荷物を受け取りに行った。

プラカ地区

地下鉄駅で嫁さんと合流して、再びアテネ空港に戻り、自分が行ってみたかったクロアチアのドゥブロヴニクに向かった。待ちに待ったときが来た、という感じだった。

| @旅行/散歩

フィラの景色

2015年6月15日

14 日夜 8 時に福岡を出発して羽田でカタール航空のアテネ行きに乗る。カタールで乗り換えてアテネに 15 日の昼に到着した。

アテネに着いてまずは現金を引き出そうと ATM に新生銀行の PLUS マーク付きカードを入れてみるが、引き出すことができない。 10 年前にヨーロッパを旅行したときは新生銀行のカードでドイツでもチェコでも、円預金を現地通貨で引き出すことができた。同じようにして現金を引き出そうと思い、 ATM にカードを入れるが、事前にインターネットバンキングかなにかで手続きを行っていないと、海外 ATM での引き出しができないようだった。そういえば一時期新生銀行のカードをスキミングして海外で不正に引き出すという犯罪が横行したので、何も設定してない場合は海外での引き出しができないようなルールに変わったのかも知れない。日本では羽田の三井住友銀行の両替所で €60 両替しただけだったのでユーロを現金でほとんど持っておらず、またギリシャの両替レートは日本で €1 = ¥141 だったものが €1 = ¥151 もして最悪のレートで、到着するや否や空港の到着ロビーで派手に夫婦げんかをした。

Continue reading...

| @技術/プログラミング

公開している Lokka の DB (MySQL) のデータを、手もとの Lokka の DB (SQLite) に取り込むときに毎回やり方を忘れるので書いておきます。

今回は MySQL to Sqlite converter という gist のコメント欄に書いてある以下の方法を試した。

sudo gem install sequel
sudo gem install sqlite3
sudo gem install mysql
rbenv rehash
sequel mysql://user:password@host/database -C sqlite://db.sqlite

これでデータを MySQL から SQLite に変換できた。Lokka をローカルで起動してアクセスしてみるが記事が表示されない。DB の中にはちゃんとデータが入ってるし、管理画面から記事一覧を表示するとちゃんと記事が表示される。どうも Post.published[] を返すみたい。

手でクエリを投げてみると

sqlite> select * from entries order by created_at desc limit 1;
             id = 960
        user_id = 1
    category_id = 5
           slug = eye-pro-is-shit
          title = Eye-Fi Pro を買ったけどクソだった
           body = [hitode909さんの日記](http://hitode909.hatenablog.com/entry/2013/05/24/093749 "hitode909の日記")...
           type = Post
          draft = 0
     created_at = 2013-10-06 07:28:00.000000
     updated_at = 2013-10-06 13:11:23.000000
frozen_tag_list =
         markup = redcarpet

draft = 0 なので表示されそうなもんなんだけど、よくよく調べてみると SQLite には Boolean 型がなくて、DataMapper は SQLite に Boolean 型のデータを保存するときは t/f の文字列で保存するみたい。これは盲点だった。

結局 draft = 0draft = 'f' に変えてあげればすべての記事を表示できるようになった。

| @雑談

会社の若者、夏期休暇期間中に徳を高めまくってた。

自分は徳が高まるようなことは特に何もしてない。コード書いてないしプログラミングの勉強もしてない。すこし .vimrc を触ったくらい。

実家に帰ったほかは、家を買おうとしてるので不動産屋に行ったり住宅メーカーに行ったりしてた。

プログラミングの本、『明解! Ruby』が読みかけになってるので読もうと思ったけど読まなかった。『SQL アンチパターン』も必要に迫られて買ったので夏期休暇で読もうと思ってたけど読めてない。

代わりと言ってはなんだけど歴史の本読み始めた。連休前に以下を買った。

大河ドラマとか見るときに日本史の知識ないと厳しいことがあるので Wikipedia 読むんだけど Wikipedia 読みだすと際限ない感じなるので本を買って歴史を勉強してみようと思っていた。丁度日経プラスワンの特集で紹介されてたので読んでみたくなって手に取った。Amazon でも評価高い。

あと夫婦げんかして家を飛び出して向かった天神のTSUTAYAで以下のような本を買った。

どれも古本なので安かった。『「芸能と差別」の深層』は三国連太郎の話が面白そうだったので買った。『夜這いの民俗学・夜這いの性愛論』を買うとき、レジが女の人じゃないなと良いなと思ったけど女の人になってしまって恥ずかしかった。結果的に痔ろうが再発した。

| @技術/プログラミング

一月くらい前から Lokka の master ブランチを自分のブログ用のブランチに merge してサイトをデプロイすると謎の白画面が出るようになっていて困っていた。現象は極めて謎で、ローカルの開発環境(RACK_ENV='development')では見られず、本番(RACK_ENV='production')だけで発生した。HTTP ステータスコードは 1054 が返ってきたりする。なんか変な gem でも入れてしまったかなと休みの日に動作検証したりしていたんだけどついぞ分からなかった。

SQL 弱者なので気がついてなかったんだけど、2月15日の commit で Site モデルに新しいフィールドが追加されていた(Add default markup in admin/site/edit · 2243dc5 · lokka/lokka ※この機能便利すね)。なので bundle exec rake db:migrate しないといけなかったわけだった。ローカルで動いている開発環境(データベースは SQLite)では Migration なんて行ってないんだけどエラーは出なかった。本番は MySQL で動いていて、こちらでだけエラーが出るようだった。

しかしいざ migrate しようとすると失敗する。

bundle exec rake db:migrate
Upgrading Database...
rake aborted!
Invalid default value for 'updated_at'

のようなエラーが出る。updated_at のデフォルト値がおかしいらしい。このときのテーブルの構造を見てみると以下のような感じだった。

mysql> desc entries;
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| Field           | Type         | Null | Key | Default             | Extra                       |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| id              | int(11)      | NO   | PRI | NULL                | auto_increment              |
| user_id         | int(11)      | YES  |     | NULL                |                             |
| category_id     | int(11)      | YES  |     | NULL                |                             |
| slug            | varchar(255) | YES  |     | NULL                |                             |
| title           | varchar(255) | YES  |     | NULL                |                             |
| body            | text         | YES  |     | NULL                |                             |
| type            | text         | NO   |     | NULL                |                             |
| draft           | tinyint(1)   | YES  |     | 0                   |                             |
| created_at      | timestamp    | NO   |     | 0000-00-00 00:00:00 |                             |
| updated_at      | timestamp    | NO   |     | CURRENT_TIMESTAMP   | on update CURRENT_TIMESTAMP |
| frozen_tag_list | text         | YES  |     | NULL                |                             |
| markup          | varchar(255) | YES  |     | NULL                |                             |
+-----------------+--------------+------+-----+---------------------+-----------------------------+

調べてみたところ MySQL の Mode が NO_ZERO_DATE になっている場合、MySQL は timestamp 型のフィールドのデフォルト値に 0000-00-00 00:00:00 みたいな値を設定することを許さないらしい。 mysql - Invalid default value for 'create_date' timestamp field - Stack Overflow

検証用に別にテーブルを用意して bundle exec rake db:setup してみたところ、以下のような構造のテーブルができた。

mysql> desc entries;
+-----------------+------------------+------+-----+---------+----------------+
| Field           | Type             | Null | Key | Default | Extra          |
+-----------------+------------------+------+-----+---------+----------------+
| id              | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| user_id         | int(11)          | YES  |     | NULL    |                |
| category_id     | int(11)          | YES  |     | NULL    |                |
| slug            | varchar(255)     | YES  |     | NULL    |                |
| title           | varchar(255)     | YES  |     | NULL    |                |
| body            | text             | YES  |     | NULL    |                |
| markup          | varchar(255)     | YES  |     | NULL    |                |
| type            | varchar(50)      | NO   |     | NULL    |                |
| draft           | tinyint(1)       | YES  |     | 0       |                |
| created_at      | datetime         | YES  |     | NULL    |                |
| updated_at      | datetime         | YES  |     | NULL    |                |
| frozen_tag_list | text             | YES  |     | NULL    |                |
+-----------------+------------------+------+-----+---------+----------------+

created_atupdated_atdatetime 型になるらしい。なので以下のような ALTER 文を実行した。

mysql> alter table entries modify column created_at datetime, modify column updated_at datetime;
mysql> desc entries;
+-----------------+--------------+------+-----+---------+----------------+
| Field           | Type         | Null | Key | Default | Extra          |
+-----------------+--------------+------+-----+---------+----------------+
| id              | int(11)      | NO   | PRI | NULL    | auto_increment |
| user_id         | int(11)      | YES  |     | NULL    |                |
| category_id     | int(11)      | YES  |     | NULL    |                |
| slug            | varchar(255) | YES  |     | NULL    |                |
| title           | varchar(255) | YES  |     | NULL    |                |
| body            | text         | YES  |     | NULL    |                |
| type            | text         | NO   |     | NULL    |                |
| draft           | tinyint(1)   | YES  |     | 0       |                |
| created_at      | datetime     | YES  |     | NULL    |                |
| updated_at      | datetime     | YES  |     | NULL    |                |
| frozen_tag_list | text         | YES  |     | NULL    |                |
| markup          | varchar(255) | YES  |     | NULL    |                |
+-----------------+--------------+------+-----+---------+----------------+

これで最新のコードをデプロイしても真っ白画面になることはなくなった。以前遭遇した更新時に created_at の値が更新されてしまう問題 もフィールドの型が timestamp だったのが原因なのだと思う。SQLite から MySQL への移行は一筋縄では行かないことが分かった。

DataMapper はソースコード内の記述内容から動的に Migration を行えるけど、ActiveRecord みたいに $APP_ROOT/db/ ディレクトリに Migration ファイルを作ってくれたりしないので DB スキーマの変更が必要なことに気がつきにくい。便利だけど不便な感じがする。Rails で $APP_ROOT/db/ 以下にアホみたいにファイルが出来ていくの嫌だと思っていたけど、スキーマ変更に気がつかずコードをデプロイしてウェブアプリケーション停止みたいな自体は防げると思った。

ブログ書こうと思ってパソコン開いて「ついでに最新版の変更を取り込むか」とかやるとデプロイできなくなったりして書きたかった記事が書けず残念な感じになる。はてなブログでブログ書いてて画面が真っ白になったらひとでくんさんに不具合報告して直してもらえば良いので楽だと思う。

| @雑談

帰省したときに実家の近所のドラッグストアに行くと、たくさん人が来ていて盛況だ。

酒のコーナーに行くとおっさんがいて、2リットル入りの工業用アルコールのような焼酎や、1リットルの紙パック入りの白岳しろを舌なめずりしながら買い物かごに入れてる姿を見ることができる。

焼酎を買ってるおっさんたちは概して「これからわての週末始まりまんねん」という表情をしている。外に酒を飲みに行くわけでなく家で晩酌をするのだろうけど、すごく楽しみにしている感じが伝わってくる。おっさんのショッピングカートから幸せが溢れそうになっているのが見える。

自分は酒に弱いので焼酎は買わないし飲まない。酒はビールがもっぱらでたまにワインを飲む程度だ。なので舌なめずりしながら大量の焼酎を買い物かごに入れるという経験をしたことがない。

こんな風に酒を買うおっさんたちはどんな気持ちなのだろう。自宅での晩酌でこんなに幸せになるという感覚が分からない。酒に弱いと飲んでも缶ビール2本くらいで前後不覚になって寒気がし始め、布団に入りたくてしょうがなくなる。自宅での晩酌だから、友だちと飲んで猥談をするわけでもなく、家族と話すかテレビを見ながら飲むのだろう。そんなにウキウキワクワクする要素はないと思う。

自分も大酒飲みになりたいわけではないのだけど、ホクホクとした表情で焼酎を買い込むおっさんたちの姿がただただ羨ましい。

| @技術/プログラミング

一個前の記事で書いた「記事の更新時に updated_at ではなく created_at が更新されてしまう」問題、原因はプログラム側にあるのではなく、MySQL の設定の問題だった。

mysql> desc entries;
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| Field           | Type         | Null | Key | Default             | Extra                       |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| id              | int(11)      | NO   | PRI | NULL                | auto_increment              |
| user_id         | int(11)      | YES  |     | NULL                |                             |
| category_id     | int(11)      | YES  |     | NULL                |                             |
| slug            | varchar(255) | YES  |     | NULL                |                             |
| title           | varchar(255) | YES  |     | NULL                |                             |
| body            | text         | YES  |     | NULL                |                             |
| type            | text         | NO   |     | NULL                |                             |
| draft           | tinyint(1)   | YES  |     | 0                   |                             |
| created_at      | timestamp    | NO   |     | CURRENT_TIMESTAMP   | on update CURRENT_TIMESTAMP |
| updated_at      | timestamp    | NO   |     | 0000-00-00 00:00:00 |                             |
| frozen_tag_list | text         | YES  |     | NULL                |                             |
| markup          | varchar(255) | YES  |     | NULL                |                             |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
12 rows in set (0.00 sec)

updated_atcreated_at の設定値が逆になってたのが原因。ALTER 文でカラムの情報を入れ替えておいた。

MySQL に流し込んだ Sqlite3 のデータを dump したやつの CREATE TABLE entries を見ると以下のようになってた。

CREATE TABLE `entries` (`id` integer PRIMARY KEY AUTO_INCREMENT, `user_id` integer, `category_id` integer, `slug` varchar(255), `title` varchar(255), `body` text, `type` text NOT NULL, `draft` boolean DEFAULT '0', `created_at` timestamp, `updated_at` timestamp, `frozen_tag_list` text, `markup` VARCHAR(255));

なんでこれが created_at に対して更新時に現在時間を上書きし、 updated_at は作成時のみ現在時刻が入るようになるのかは分からない。

それにしても日頃 MongoDB ばかり使っていて、データにおかしなことがあるのはほぼ間違いなくコードのせいだと思う癖がついていることが今回よくわかった。データベースのスキーマを見てみるまでに3日くらい時間がかかった。とほほ。

一方でデータベース内のデータ構造のことをあまり考えなくてよく、開発のみに集中すればよい MongoDB はやっぱり便利だなと思った。規模がでかくなったり高速な読み書きをさばかなければならない状況だと MongoDB にも色々問題があるのでしょうけどね。