数日がかりで、Zope上のCOREblogで書いた記事をWordPressに移行した。おおざっぱには下のようなステップ。データの変換がとにかく面倒だった。
せっかくだからテーブルの行数をカウントしたところ累積で900記事弱くらいになっており、下らないながらもそれなりに蓄積されたなぁ、と2秒くらい感慨に浸った。 記事が増えたところでカテゴリーはもう少し細目に分類しようかと思っている。
WordPressを使い始めて半年以上経って「使えるツール」だと実感しているので、データを集約したいと思っている(まだ構想レベル)。手持ちの日記データは2種類ある。
このうち2番目の不定型HTMLはあまりに面倒なので先送りしたい。とりあえずCOREblogのデータを取り込めれば満足。
と思って検証し始めたのだが、かなり厳しい。編集画面を見る限りは大差ないのだが、データ構造から見ると別ジャンル。
ZODBからデータを取り出してMySQLなどに移行する作業が必要になる。一番の山はZODBからデータを取り出す、というところ。ZODBがRDBではなく独自のオブジェクトDBなのが難点。
あまり考えたくなかったので、まずはO2DBというツールを使ってみた。が、数時間粘ってダメだった。どうやら現在のO2DB-0-5-8というバージョンはMySQL-python-1.0.0 & MySQL3.xを前提としているらしい。Fedora Core 4だとMySQL-python-1.2.0 & MySQL-4.xなのでうまく動かなかった。 直接の原因はMySQL-python-1.2系でCompatMysqldb.pyが無くなっていること。「じゃあMySQL-python-1.0を手動でインストールするか」と思うと今度はMySQL-4.xとの組合せだとコンパイルが通らない。タイミングの悪い話だ。今後O2DBがMySQL-4.x系に対応してくれれば使えるかもしれないが今回はあきらめる。
次点として手動でデータを取り出すことを考えた。具体的には、COREblogのフォルダでcsv風の出力を行うDTMLを書く。以下、ソースから調べたdtml-varのメモ。
現時点では、ここまでで力尽きた。WordPress側のデータ構造とMySQLへのimport方法を調べないと進めない。 しかも最大の問題は「ここまでして移行する価値があるのか?」というそもそも論。「一回やっときゃ、ずっと使える」という点と「自分で書いたものが資産だ」という点を信じないと価値を見出せない。というわけで、さしあたり優先度を下げることに。 今回、最大の教訓は「Zopeを一回使い始めるとなかなか抜けられない」ということか。
カテゴリーが増えて来てゴチャゴチャしてきたので、レイアウトを整理した。 - トップページの一番上にあった、カテゴリーへのショートカット廃止。 - 各カテゴリーにサイドボックスをつけた。とりあえず今は広告のみだけど、ジャンル別のリンク集をつけたい。 - トップページのRecent Entriesを廃止。あまり意味ない気がするので。
カテゴリーごとのエントリー数が増えて来て、思いっきり縦長になっている。そろそろ収拾がつかなくなってきているのかもしれない。
COREblogを使っている人の参考情報。サイドボックスの幅はスタイルシートで決まっている。具体的には、style_css中の#sideboxのwidthの値。
エントリの数が増えて来て、日記の生成に時間がかかるようになってきたので、ノートPC(Crusoe 800MHz)より高速なデスクトップPC(Duron 700MHz)に移行してみた。いま気付いたけど、CPUのクロックだけみるとノートの方が速いのね。デスクトップもFedora Core2なので、Pythonだけバージョンアップすれば条件はだいたい揃う。ノートPCからZopeのディレクトリとインスタンスのディレクトリを丸ごとコピーしたらあっさり動いた。めちゃくちゃお手軽。
ためしにtimeコマンドで静的HTMLへの変換にかかる時間を計測してみたところ、ノートPCで1分55秒465に対してデスクトップが1分19秒359。4割くらい早いか。
/etc/sysconfig/network-scripts/ifcfg-eth0を編集してlinuxに固定IPを割り振った。普段はDHCPで使っていたが、ゲートウェイにルータのIPアドレスを指定すれば固定で割り振っても問題なく使える。やはりネイティブに比べるとかなり遅い。特にCOREblogを使おうとするとかなり厳しいので、ためしにWindowsのInternet ExplorerからcoLinux上のCOREblogインスタンスにアクセスしてエントリを書いてみた。
するとレスポンスはかなり良い気がする。少なくともエントリを書いている間はIEのフォームに入力しているだけなので普通のスピード。
やや変則的な使い方だけど、Cygwin上でサーバを動かすよりはまともな環境な気もするのでcoLinuxの使い方からすると結構まっとうな構成なのかもしれない。
Ploneが色んな意味で重いので当面はXOOPSに乗り換えたわけだが、良い面と悪い面がある。一番基本的なところで直面してしまったのは、HTML。XOOPSでは機能はモジュールで簡単に変えていけるけど、コンテンツ自体やレイアウトはHTMLとCSSだったりする。
そこまで戻りたくなかった。僕はxxMLのようなマークアップ言語は全々好きではない。何が一番イヤかというと、タグ。タグを打つために沢山シフトキーを押さなくてはいけない。キーボードは文字を入力するためにレイアウトを使っているので、記号も軒並み不自然な位置にある。もっと言えば読みにくいし、前後を挟む仕様のせいで一つの指示に2回もタグが要るし。はっきり言ってマークアップ言語はデザイン不良だと思う。バイナリ同然のものをハックする気にはなれない。
人間はコンピュータの周辺機器ではない。が、測定されてないだけで、コンピュータのために膨大な作業が発生しているのは間違いない。なんとかしたいところだ。
Data.fsがデカくなると良くないらしいので、ジョブテクのDBを分割してみた。DBTabという機能を使うのだが、zope-2.7で本体にマージされている。しかも設定の書式が変わっている。 1. まずzope.confを編集して新たなDBを認識させる(書式は下のURLのDBTab integrationという項を参照)。
zopeを再起動して、ZMIの右上のプルダウンからZODB Mount PointというのをAddする。おそらくzope.confで設定した名前が表示されるので、その名前でAddする。
MainのDBからコピーしたいサイトをごそっとコピーする。
新しいマウントポイントの中でペーストする。
確認のために、”localhost:8080/新しいマウントポイント/サイト名称/manage”というアドレスにアクセスしてみる。
成功していれば、Mainの方のサイトはDeleteする。
MainのDBをControlPanelでPackするとDBの容量が減る。
事前に元のData.fsなどはバックアップしてから作業すべきだろう。分割したら動きが若干軽くなった気がするが、気のせいだろうか。
What’s New in Zope 2.7 (Plope)
使えるレンタルサーバが少ない、この上Pythonを覚えるのか?、など数々のデメリットもあるZopeだが、使ってる理由を考えてみた。Web運宮のためのツールは適材適所だと思っているので、最終的に全部Zopeにはならないかもしれない。まずは使用感からメリットを拾ってみる。アプリケーションが揃っている: COREblog(ブログ)、ZWiki(Wiki)、Plone(ポータル)、Squishdot(参加型掲示板)など、想定される用途のProductは揃っていて、それぞれ良い線ついてるように思う。
敷居は低い気がする: Javaよりはお手軽だと思う。今後どうなるかは分からないけど。
スケーラビリティがありそう: ZEOのような負荷分散機能が組みこまれているので、万一大々的に運宮することになってもなんとかなりそう。その場合は自前サーバ+FTTHになるだろう。
Structured Textが使える: Zopeの独特な機能の中でStructured Textは気に入っている。タグを使わずに見出しや強調などの表現指定をできて、最終的にHTMLに変換される。ある意味新たな言語を覚えてるのと一緒だが、分かりやすさ使いやすさという点で抜けている。
今いちつめきれていないジョブテクのデザインだが、微妙なところでカスタマイズは続けている。Ploneはサイトの一番下にデフォルトで標準準拠のアイコンを表示してるが、カスタマイズしたりしてきっと今や準拠してないので消してみた。/portal_skins/plone_templates/colophonをカスタマイズすれば良い。Plone poweredのロゴだけは残しといた。「Ploneを宣伝してね」というコメントが入っているので。
ついでにCopyrightのフッターも変えといた。/portal_skins/plone_templates/footer。前から「何で自分のサイトでPloneの著作権表示をしなくちゃいかんのだ」とは思ってたけど最初は直し方が分からなかった。
Linux, Zope, Javaの3つのカテゴリーの記事をトップから分離してみた。これらを含んだフルバージョンはページ右上の開発者版に入っている。ついでに英語版の方もリンクしといた。分離した理由は単純で「興味ない人にはノイズでしかない」から。時間のある時にまとめて作業することが多いので、Linuxの話題が固まってたりすると結構つらい気がする。とはいえ別のBlogで分けるとさすがに管理が面倒。
Blogに手を入れれば、カスタムバージョンのページは自動で生成できるので記事を書く時の負担はゼロ。