2006年10月23日の投稿

2006-10-23
雨

新幹線新駅推進派を当選させた責任は反対市民グループにある

ゆりこ による 00:39:18 の投稿
カテゴリー: 社会問題

22日に実施された栗東市長選挙は、新幹線新駅推進派の国松正一氏が当選したようです。この選挙の情けないところは、対抗候補2人がともに新駅反対で、それら2氏の票を足すと国松氏の得票数を上回ることです。そして、このような「2人足したら新駅反対派が強い」という状況は、事前の下馬評で分かっていたのです。

このへんが、日本の政治のヘタクソなところです。合従連衡すれば相手に勝てるのに、独力で戦って負けてしまうのは、古来から日本が辿ってきた道と言えるでしょう。特に、日本共産党は他の政党と相乗りを好まないようですが、このために、かえって自民党候補を勝たしてしまうという皮肉な結果を産んでいます。ひょっとすると、日共は自民党を応援しているではなかろうか:-)

今回は、明らかに3番手である杉田氏が当選をあきらめて、国松氏と戦えそうな田村氏に相乗りしてしまえばよかったのです。杉田氏が立候補した時点で国松氏の当選確率がアップしてしまったわけで、この候補を擁立・応援した市民グループの作戦負けと言えるでしょう。推進派を当選させてしまった責任の一端は、この市民グループにあると言って過言ではないと思います。

自作ウェブログツールへの道(2)

ゆりこ による 13:18:55 の投稿
カテゴリー: ソフトウェア

Yuriko.Net は紆余曲折を経て、自作ウェブログツールで運営することにしましたが、当初の構想からはだいぶ変更されました。2004年8月に全面リニューアルしたときは、ウェブログ風の見た目を手書き HTML で書くという方針にし、それで十分と考えていたのです。手書き HTML であれば、XHTML/CSS のソースを完全に制御できるので、見栄えやインターフェースを自由に設計できます。また、手元に HTML ソースがあるため公開前にプレビューが容易だという利点があります。

しかし、手書き HTML だと以下のような問題が出てきました。

  • 1つ記事を書いたら、月別アーカイブ、年別アーカイブ、最近の記事一覧、表紙ページの4つを更新する必要がある(!) 更新ミスも起きやすい。
  • そして、更新された HTML ファイルを FTP/SFTP で転送する手間がかかる。モバイルで更新するときは、回線が細くて更新が完了しないこともある。
  • 旅行のリアルタイムレポートのように、少量の記事を頻繁に更新するようなことが非常に困難。
  • コメント・トラックバックが受け付けられない。

ということで、これらを解決するのと、RSS 提供のため2005年4月ごろ Perl スクリプトを導入しました。月別アーカイブの HTML を読み込んで、表紙ページ、RSS を作るスクリプト、RSS を読んで最近の記事一覧を吐くスクリプトの2本です (年別アーカイブは自動化できず)。Perl スクリプトの起動はサーバーに ssh ログインして行っていました。

2005年8月ごろ、コメント・トラックバックを受ける準備として個別記事も提供開始しました。静的 HTML ファイルではなく PHP ファイルとすることで、個別記事自体がコメント・トラックバックを処理できるように構想したのです。Perl で PHP コードを吐くというケッタイな仕様でしたが、当面は拡張子が PHP なだけで PHP コードの実体はありませんでした。

でも、コメント・トラックバックを受け付けるには、データベースのようなものを使わないといけません。単なるテキストファイルでもいいですし、BerkeleyDB や MySQL などのデーターベースシステムを使ってもいいです。で、このとき PHP はまだ理解してなかったので開発が止まってしまいました。

2006年5月ごろになってやっと PHP, MySQL の勉強を初め、トラックバックの実装は行いました。このとき、実際に Perl で PHP コードを生成するようになりました。

ところが、ウェブで記事投稿できる仕組みを作ろうとしたら、静的生成の出発点となる月別アーカイブをどういじればいいか悩みました。記事を追加するだけならまだしも、記事を修正したり、途中の日付に記事を挿入するのは至難の技です。

となると、月別アーカイブを分解する仕様を放棄し、個別記事もデーターベースに持たせた方が楽です。記事の生成、記事の追加・修正は単純な処理で済みます。そうなると、PHP コードを持つ個別記事を静的生成するという変な仕様はやめて、完全動的生成にした方が作りやすいので、その方針で開発を進めて 2006年8月にそのシステムに移行させました。

仕様変更しまくりましたが、自分で使うツールを趣味で開発しているので、こういう回り道も一興でしょう。動的生成にすることで、日付アーカイブ、カテゴリー別アーカイブ、投稿者別アーカイブなども簡単に作ることができたので、結果として正解だったと思います。静的生成だと、これらのアーカイブも事前に作っておく必要があり、再構築に時間がかかるという問題が出てきます (Movable Type の欠点の1つとして有名ですね)。

けっきょく、PHP + MySQL という「よくあるシステム」になってしまいましたが、既存ツールとは違う試みもあるので、時間と余力があれば一般公開してみたいと思います。期待しないで待ってくらはい。

槍先部隊と後方支援

ゆりこ による 14:45:00 の投稿
カテゴリー: ソフトウェア

「槍先部隊と後方支援」といっても、戦争の話ではありません。槍先・後方は軍事用語ですが、危機管理の場面でも使われる概念で、一般的な業務にあてはめて使える言葉です。槍先部隊は主たる業務をする人で、後方支援はそれらを支える人たちです。会社で言うと総務や人事に該当するでしょう。ソフトウェアの場合、槍先はコード自体で、後方はドキュメント・問い合わせ窓口・配布元ウェブサイトなどが該当するでしょうか。

で、古来日本では槍先を重視する傾向にあり、後方部隊が軽視されてきました。だからこそ日本は戦争に負けたのですが、戦後60年たった現在でも軽視されることがあります。ソフトウェアの場合、ドキュメントが不十分だとか、配布元ウェブサイトがダサくてダウンロード方法が分かりにくいとか、そういう状況は後方軽視と言えます。コードだけに目を向けると、槍先は実際のプログラム自体で、後方はテスト用のコードという分類もできます。ウェブログツールの場合、槍先は公開ページを処理する部分で、後方は管理ツールとも言えるでしょう。

余談ですが、日本の機動隊は、佐々淳行氏の働きもあって後方支援がしっかりしているようです。大学紛争の時代には、おにぎり数個だった弁当が、大喪の礼の警備では鰻弁当にまでアップグレードしているそうです。すばらしい。

と、実はここまでは前振りでした;-) そう、Yuriko.Net のシステムは管理画面の作り込みを少しサボってきたのですが、それを反省するのに「後方部隊を軽視してきた」と書くがために、このような説明が必要だったのです。とりあえず「槍先」となる部分はほぼ完成したので、今後はバグ取り、管理画面の完成度アップを計りたいと思います。逆に言うと、閲覧者から見える機能アップは少なくなります。また、一般公開できるようにするには、ドキュメント記述や配布サイトの作成なども必要になってくるでしょう。「後方支援が重要」と書いてしまったからには、これらの手を抜けないわけで、自ら課題を作ってしまいました;-)

ページのタイトルを少し変えました

ゆりこ による 19:35:56 の投稿
カテゴリー: 更新履歴

当分の間は、Yuriko.Net へは機能追加ではなくバグ取りなどを重視することにしましたが、その一環として、過去記事において、タイトル部分 (メニューの下にある緑色の星の背景がある部分) の文言を変えました。従来は「YurikoNet: 2006年10月分」などとなっていましたが、この「Yuriko.Net」という文字列を外しました。ちょっと物足りないかもしれませんが、しばらくすれば慣れると思います。個別記事については「Yuriko.Net 過去記事」から「Yuriko.Net 個別記事」と変えています。

いままで、コード自体で「Yuriko.Net」という文字列を書いていましたが、これでは一般化ができないので、それを外したという次第です。実は内部的にはもっと抽象化を進めていたりします。

FancyURL はクールな URI のための機能

ゆりこ による 23:04:18 の投稿
カテゴリー: ソフトウェア
タグ:

動的生成のウェブログの場合、デフォルト設定だと個別記事やアーカイブ記事の URI がクエリー文字列そのまま (http://example.jp/index.php?eid=99 とか http://example.jp/search.cgi?y=2006&m=10 とか) という場合が多いようです。FancyURL は、動的生成のページなのに静的な URI (http://example.jp/id/99/ とか http://example.jp/2006/10/ とか) として提供する仕掛けのことです。この用語は Nucleus CMS ぐらいでしか使われてなくて言葉としてはマイナーですが、概念としてはわりと一般的でしょう。実装方法は Apache の mod_rewrite 機能を使ったり、環境変数 PATH_INFO をパーズするなどの手法があります。

Yuriko.Net でも FancyURL になっていますが、それは既存の静的 HTML で作った日記の URI 体系を維持するために、必然的にそうなりました。このサイトで何回も引用している「クールな URI は変わらない」を実現したわけです。

なぜか FancyURL は、検索エンジン対策 (SEO) に有効だという解説が多いのですが、むしろ、クールな URI 体系を作るための仕組みだと思います。ウチの場合は静的 HTML の日記から動的生成のウェブログに移行させるために利用しましたが、ウェブログツールを乗り換えたり、ツール利用をやめて静的 HTML として凍結する際にも、FancyURL ならば容易に実行可能です。これがクエリー文字列を含むような URI 体系であれば、ウェブログツールの乗り換えすら難しくなります。

ウェブログツールを採用するだけで SEO はそれなりに実施できているので、FancyURL はクールな URI を実現するための機能だという認識がもっと広まって欲しいものです。10年たっても、そのウェブログツールを使い続けますか??

URI 維持のための尻拭い

ゆりこ による 2006-10-24 00:26:27 の投稿
カテゴリー: ソフトウェア
タグ:

Yuriko.Net は「クールな URI は変わらない」ようにするための努力をしていますが、実のところ、2004年8月のリニューアルで URI 体系を多少いじっています。それ以前は、ふりひら活動記が http://www.yuriko.net/act/ で、はいぱー日記システムによる日記は http://www.yuriko.net/diary/ でした。この2者を融合して http://www.yuriko.net/arc/ に押し込めたのです。

でも、旧 URI でのアクセスを「404 Not Found」にするわけにはいきません。ということで、Apache の Alias 機能でいっぱいリダイレクトを張っています。特別に、ここでその設定を一部公開します。こういう尻拭いをすることで、クールな URI の維持を図っています。

RedirectMatch 301 /act/1999/19990404.* /arc/1999/0404/
RedirectMatch 301 /act/1999/19990620.* /arc/1999/0620/
RedirectMatch 301 /act/1999/19990704.* /arc/1999/0704/
RedirectMatch 301 /act/1999/199910.*   /arc/1999/1009/
RedirectMatch 301 /act/1999/19991114.* /arc/1999/1114/
RedirectMatch 301 /act/1999/19991223.* /arc/1999/1223/
RedirectMatch 301 /act/2000/200001.*   /arc/200001/
RedirectMatch 301 /act/2000/200004.*   /arc/200004/
RedirectMatch 301 /act/2000/200005.*   /arc/200005/
RedirectMatch 301 /act/.*              /arc/
Redirect 301 /profile.html http://www.yuriko.net/prof/
Redirect 301 /links.html   http://www.yuriko.net/links/

あれ? 今ごろ気がつきましたが、/diary/ に関してはまるでリダイレクトが設定されていません。ああどうしよう。