クールなURIタグの投稿

2009-04-30
晴れ

ひたちなか海浜鉄道ウェブサイトが NetCommons 採用で改悪

ゆりこ による 06:08:16 の投稿
カテゴリー: ソフトウェア,鉄道
タグ: , , ,

今年4月で開業1周年を迎えたひたちなか海浜鉄道ですが、同じタイミングで WordPress から NetCommons に変更されていました。リニューアルは、社長の記事に頼ったブログ・スタイルから、多様なニーズに応えられるようにするのが目的だそうで、それは非常に結構なことだと思うのですが、CMS エンジンの変更によって URI 体系が変更になったことが残念でなりません。

まず、「クールなURIは変わらない」の大原則に反しています。もともと、WordPress 構築時代に、デフォルトのパーマリンク (?p=NNN とか ?page_id=NN とかのクエリーを使うタイプ) にしていたのが失敗なんですが、もし、/2009/04/29/1st-aniv/ とかのパーマリンク体系にしておけば、多くのブログツール/CMS エンジンで再現できたはずです。

で、現サイトはどうかというと、各ページの URL は http://www.hitachinaka-rail.co.jp/htdocs/index.php?action=pages_view_main&page_id=18 のように、動的なクエリーを使ったものとなっています。これまた NetCommons の仕様に縛られる URI 体系なわけで、「クールな URI」に反したものとなっています (NetCommons 以外の CMS にしたら、また URI 変更となる)。せっかくリニューアルするんですから、「100年経っても変わらない URI」にしてもらいたかったです。

次に残念なところは、携帯ページが貧弱になったことです。NetCommons 自体は携帯表示機能がありますが、悲しいことに、イー・モバイル音声端末、Windows Mobile スマートフォンやゲーム機等に対応していません (マイナーなので仕方ないとも言えますが、Ktai Style はマイナーなものにも対応しているのです)。さらに、NetCommons の携帯判定が相当ヤバイという問題があります!! PEAR の NET_UserAgent_Mobile をもとに、独自の IP アドレス判別ルーチンを通して、携帯ネットワーク外からのアクセスを除外しています。携帯の契約者 ID などをもとにした簡単ログインを実装するならば、IP アドレスの判別は必須ですが、閲覧だけやID・パスワードログイン機能だけならば IP アドレス判定は余計です。何より、NetCommons の最新版 (2.1.0.1) に同梱されている html/maple/nccore/MobileCheck.class.php の IP アドレスリストは「IPチェック(調査日 2008.04.11)」という代物で、これでは使いものになりません。IP アドレスチェックを機能として盛り込むならば、2か月〜半年に1回はアップデートが必要です。ごく最近では EZweb が2009年3月10日に IP アドレス帯域を削減し、NTT ドコモは今年9月ごろに IP アドレス帯域を増やすことを予定しています。IP アドレスを削減した場合、これらの帯域が ISP などに再割り当てされたときにセキュリティーを担保できません。逆に、追加された IP アドレスからの閲覧者は、携帯電話から見ているにかかわらず PC からと判定されて、パケット量が膨大な PC ページに飛ばされてしまうのです!! これでは安心して閲覧できません。

はっきり言うと、マトモなパーマリンクが作れず、携帯端末判定が正しくできない NetCommons は捨て去った方がいいでしょうね (少なくとも、公開ウェブサイト用としては)。国立情報学研究所だったら「クールな URI」の概念くらい常識だと思うんですが、そんなにセンスないところなのでしょうか?? 内輪向けのグループウェアとして使うならば URI は動的でもいいと思うんですが、NetCommons はもっと広い用途を想定していますよね? あと、定数使いまくり、*.ini というファイルありまくりなのもダサくて仕方ありません。→元が XOOPS らしく、このダサさは XOOPS 起源なのかも?→Maple の仕様が理由っぽいです。

[追記]URL 短縮ハックがあるようです。ただし「html」という拡張子が付くのがいまいちですね ;-) 質問者も、SEO とかじゃなくて URI の永続性についてツッコマないと!!

[もう1つ追記] NetCommonsで作る、魅力あふれる学校サイト (PDF) という論文を見つけたのですが、構築例のブラウザー画面に「アドレスバーがない」というのは、驚きものです。ぜひとも「安全なウェブサイトの作り方」を読んでもらわないと。

2009-03-06
雨

WordPress の携帯表示を Smarty で行う実装

ゆりこ による 19:47:10 の投稿
カテゴリー: WordPressハック
タグ: , , , , ,

ガイドミーというサイトの管理者ブログで、「Smarty を使って WordPress の携帯表示を行う実装」を披露されているのを見かけました (ソースは未公開)。Ktai Style を使わない理由は「PC と携帯で URL が同一だと Google に嫌われる(と作者が思い込んでいる)」からだと思われます(*)。

ウェブログの DB に直接アクセスして携帯表示を作るのは、MT4iwp-ktai.php の手法ですね。はっきり言うと、第1世代の携帯対応のやり方です。Mobile Eye, Mobile Eye+, MobilePressNEO, Ktai Style は、WordPress のテンプレート機構を乗っ取るというやり方で、第2世代と呼べるでしょう。これは単に設計手法の新旧の違いであって、実装の優劣を述べているのではないことに注意してください。優劣があるとすれば、携帯向けサイトの URL が永続的であるかどうか、です (第1世代は携帯閲覧ツールの寿命に左右されるが、第2世代は左右されず永続的です)。

とはいえ、2009年になって、第1世代の実装方法を新規に行うというのは、大胆です ;-) まあ、Smarty を使っているという点を加味すると 1.5 世代と言えるでしょうし、単純な XSS 脆弱性を起こしにくくなるという面ではよい方法だと言えるでしょう。(WordPress のテンプレートタグを XSS を起こさないように使うのはちょっとコツがいる)

ただ、作者の PHP スキルが、「データ中に??などの文字(バイナリデータ?)が存在するのですが、よく分からないので全部削りました」とか「PHP5.2.6 で date("Y年n月j日 H:i"); の『年』が化けるのは PHP のバグ」と言っているレベルなのが不安です。正解は、「年」を Shift_JIS で書くと2バイト目が「N」なので、PHP 5.1.0 で導入された曜日フォーマット文字「N」と解釈されるため、「年」の1バイトが浮いてしまって化けるためなのです。バグというより、date() 関数の仕様ですね。date 関数で文字エンコーディングを指定できるようになるのがあるべき姿だと思いますが、PHP コードを Shift_JIS ではなく、EUC-JP や UTF-8 で書けば回避できるので、仕様変更の必然性は低いでしょう。PHP コードを Shift_JIS で書くこと自体、あまり好ましくないことですし。

あと、au, ソフトバンク向けにも <!DOCTYPE html PUBLIC "-//i-mode group (ja)//DTD XHTML i-XHTML(Locale/Ver.=ja/2.1) 1.0//EN" "i-xhtml_4ja_10.dtd"> という DTD を出力したり、XHTML なのに <HR size="0.5" color="#ccccff"> とか <br> というマークアップがある (大文字だったり閉じタグがない) のもイマイチでしょうか……。今後はこのへんが修正されることに期待ですね。

(*) 作者は「事実だ」と書いていますが、ログから推測される事項はあくまで「意見」であって事実ではありません。いついつにどういうアクセスがあった/いついつの間のアクセス件数はxxだったというのが事実であって、減った/増えたは統計による推論となるからです。

[追記 5月9日] 作者の翌日のエントリーで「サイトを作る目的は多くの人に見てもらうため」と書いておられました。わたしの考えでは、それに必要なことは、まずウェブ標準/各社の規約に従うこと、次にクールな URI を守ること、そして訪問者の立場でデザイン (見栄え・設計両方の意味) をすることでしょう。Ktai Style はそのような方針で作られています。

他人のフレームワークに左右されたくないという下りは実は同感で、わたしの自作プラグインは、「他人のプラグインが信用できない/挙動が来に食わない」から作ったものがほとんどです。PEAR の Net_UserAgent_Mobileなどを使わないのもその理屈です。

2009-03-04
晴れ

葛西区民館のサイトURL変更

ゆりこ による 02:47:46 の投稿
カテゴリー: WordPressハック,ネットワーク
タグ: , , ,

3月1日に東京都江戸川区がウェブサイトをリニューアルしたため、施設を紹介するページの URL が軒並み変更されてしまいました。来たる4月12日に開催される WordCamp Tokyo 2009 の会場である葛西区民館も例外ではありません。

旧URL:
http://www.city.edogawa.tokyo.jp/institution/01kuyakusyo/kuyakusyo03_02.html
新URL:
http://www.city.edogawa.tokyo.jp/shisetsuguide/bunya/kuyakusho/kuminkan/kasai/

WordCamp Japan の公式サイトは変更ずみです。もし、自身のサイトで WordCamp Tokyo 2009 を告知していて、葛西区民館へのリンクを張っているならば、変更されることをおすすめします。

江戸川区がウェブサイトをリニューアルすることは結構なことですが、URL の変更は避けて欲しかったですね。個人サイトならともかく、地方自治体なのですから「クールな URI は変わらない」を実践してもらわないと……。最悪、URL 体系を変更したならば、旧 URL から新 URL へのリダイレクトを実施してもらいたいものです。江戸川区経営企画部広報課に、リニューアルを担当した業者がどこか質問かなあ?? 利用者に迷惑をかけているわけで、URL の変更を是とした業者はサイテーですね ;-)

[追記 2009-03-18] 江戸川区の広報課に電話で尋ねてみました。全職員がウェブ更新できるよう CMS を導入したため、URL の変更が不可避となったとのことでした。CMS 導入にあたっては外部の業者を利用したそうですが、そのときに URL の維持をする検討は、業者・区役所どちらもしなかったようです。あかんやん!! 古い URL からリダイレクトは、サーバーも変わってしまったためできなかったそうです (そんなことはないので単に技術が低いだけって気が……)。URL は電話番号と同じ性格のもので、できれば100年(!)は維持してもらいたいと要望しておきました。結局のところ、業者・区役所ともに「ヘボ」ということに違いなさそうです ;-)

2008-05-24
くもりのち雨

Mobile Link Discovery 仕様書が消えた

ゆりこ による 06:50:03 の投稿
カテゴリー: ソフトウェア
タグ: , ,

Ktai Style 1.50-test2 で他サイトの Mobile Link Discovery (MLD) 検出に対応したのですが、肝心の MLD 仕様書が Not Found になってしまいました。test2 公開時は http://www.sixapart.jp/docs/tech/mobile_link_discovery_ja.html で見られたのですが、きのうあたりには見えなくなっています……。

シックスアパートがサイトリニューアルしたわけでもないですから、ちょっと不思議です。とはいえ、URL が変更になったとしてもそれはそれでダサいですよね (クールな URI は変わらない)。早期の復旧を期待します。

XHTML への MLD 埋め込みはだいぶ前に実装しましたが、RSS や ATOM への MLD 埋め込みはまだなので、対応しようかと目論んだのですが、仕様書が消えてしまったのは困りました……。

2008-05-02

当サイトの FireStats 統計結果

ゆりこ による 07:20:14 の投稿
カテゴリー: ソフトウェア
タグ: , , , ,

2週間ほど前に FireStat をインストールしたのですが、ある程度傾向が見えてきました。

まず、ページビューとビジター数の比率ですが、だいたい 2.5ページ/人程度です。本当は平均値は意味がなくて、最頻値が気になるところですが、それは「1ページ/人」が圧倒的に多いはずです ;-)

サーチエンジンからの流入は Yahoo! が一番多くて「灯火の会」「E03CA」「百度」がそれぞれ100件近くあります。「WordPress 携帯」も50件あります。Google はそれより落ちて、「ステージ」「H11T」が50件ほど、「Ktai Style」が40件程度です。100件オーバーの2つは、他のサイトではなかなか記事がないようで、ウチのサイトが主要な情報源になっているのかもしれません。どこかが「灯火の会まとめサイト」を作れば、そっちにページビューが流れるんでしょうが……。

ブラウザーのシェアは驚くべき結果となりました。1位は Internet Explorer ですが 30% しかありません。2位が Openwave UP.Brower すなわち au 端末で 27%、3位は Netfront (ほぼ SoftBank 端末) で17%、4位にやっと PC ブラウザーが復活して Firefox が 14%、Safari は 3% となっています。したがって、OS シェアは、不明 == 携帯電話が 51%、Windows が 43%、Mac が 5% となっています。なぜか、ドコモからの閲覧は非常に少なく、0.1%程度です。うーん、不思議。

日本では、携帯電話からネットを使う人と、PC でネットを使う人がほぼ半々となっていますが、それを見事に証明した結果となりました。いわば、「携帯版ページを作ったら読者が2倍になった」と言えます。Ktai Style による携帯サイトの提供がうまく機能しているわけです。他の携帯対応プラグイン (Mobile Eye+, MobilePress, MT4i) だとどういう結果になるのかは非常に興味ありますね。

[追記] Google モバイル検索とかでは、めったに MT4i で作ったサイトがひっかからないので MT4i は検索エンジンとは相性が悪いと思っていました。どうやら、「エントリーを追加するごとに個別記事の URL が変わる仕様」なようです。これじゃあ「パーマリンク」じゃないわけで、SEO に弱いのは当然ですね……。Ktai Style, Mobile Eye+ など WordPress の携帯対応プラグインは「PC サイトと同じ URL」なので当然ながらパーマリンクとなっていて、それが検索に強くなっているのかもしれません。このへんは MT4i カイハツシャの奮起を期待でしょう。

[追記 2009-02-22] わたしが大事だと思っているのは SEO よりも URL の恒久性です。たとえ携帯サイトと言えど「クールな URI は変わらない」は金科玉条だと考えています。SEO に有利になるというのは、URI を永続的にした副産物にすぎません。そういう意味では、MT4iTypeCast は「そのソフトウェアが提供する URL」に縛られるため、パーマリンクを維持するためにはソフトウェアと心中する覚悟が必要でしょう。まあ、mod_rewrite を使って新しいパーマリンクに変換すれば「心中」まではしなくて済むかもしれませんが。

2006-10-23
雨

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/ に関してはまるでリダイレクトが設定されていません。ああどうしよう。

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年たっても、そのウェブログツールを使い続けますか??

2006-05-18
くもり

バグ取り完了

ゆりこ による 22:39:00 の投稿
カテゴリー: ソフトウェア
タグ:

参加表明掲示板のバグ ですが、なんとか修正しました。どうやら、データーベースへのアクセス用メソッド (関数) で、いきなり exit() させるとダメなようです。きちんとアクセス用インスタンスに NULL を代入してメモリ開放させておいて exit() すればよくなりました。

通常は、関数を呼びだしたら、呼び出した先で exit() させることはないわけですが、入力エラーやデーターベースエラーなどの場合は、ページのフッタ部分を表示させて exit() させてしまった方が楽ちんです。あまりお行儀のよい書き方とは言えませんが。

ということで、なんとか動くようになり、一通りテストも完了したので実際に稼働させてあります。といっても、現在はまだ動いてないので「掲示板が停止中か、掲示板データベースの不具合のため、表示できません。」の表示が出るだけですが……。

さらに、「お問い合わせ」ページも PHP 化してみました。フォームの入力エラーを、入力欄のすぐ下に表示させる方式にして使い勝手を上げてあります。フォームのあるページ自体も PHP にしたのでできる技です。以前から URI の拡張子を省いてあったので、ページの実体を request.html から request.php に変更しても URI はそのままです。これぞ、「クールな URI は変わらない」の実例でしょう (自画自賛)。

2006-05-10
くもり

ウェブログツールをお試し

ゆりこ による 23:35:00 の投稿
カテゴリー: WordPressハック,ソフトウェア
タグ: , ,

車輪の再発明は避けたいので、とりあえず既存のウェブログツールがどんな感じか試してみることにしました。Movable Typeは、無償ライセンスに制限が多いことと、使っている人が多いというのでパス:-) その他で、日本語対応がしっかりしててカスタマイズがやりやすいものとして、P_BLOG, WordPress ME, Nucleus CMS を試しました。

結論から言うと、WordPress がわたしの要求に一番近いですが、それでも現行の Yuriko.Net の URI を維持できないので導入不可です。クールな URI は変わらないと考えているので、ツールを導入したからといって URI が変わってしまうのは問題です。むしろ、ツール側の工夫で URI を維持できるようにしてもらいたいものです。

さらに、投稿日時と掲載日時をずらすことができないのが難点です。わたしは、ある日 (xx月yy日) の出来事を後日投稿することがありますが、この場合、エントリの収容される日付は xx月yy日とするかわり、記事末尾の投稿日時は実際に書いた日 (xx月yy日より後の日付) にしています。しかし、今回テストしたツールはどれも、そういう技は使えません。ウェブログという仕組みが、そういう使い方を想定してないんでしょう……。あと、プラグインやモジュールで機能追加できるとしても、日付ごとに天気を入れるプラグインは存在しないので自作しないといけないし……。

まず、P_BLOG のサンプルの評価。デフォルトのスキンは非常におしゃれなんですが、これ以外のスキンを使うのはちょっと難しい。マニュアルは整備されているんですが、サイドバーを両側に置くとかできるかどうか不明。あと、Permalink (永久リンク) の URL が動的 URL っぽくてダサいこと。開発者は、「最近の Google は動的 URL でも拾ってくれる」という理由で、URL をかっこよくする予定はないそうです。開発者は「クールな URI」の概念を分かってないんでしょう。

一番困ったのが、管理画面の設定項目はヘルプ文書がないこと!! 「ページャースタイル: ◎ Link ○ Form」というラジオボタンは、どの部品をどう設定するのかちんぷんかんぷん。

次は WordPress のサンプルの評価。スキンはいろいろあって、差し替えも簡単です。ただし、有効にしたスキンに問題があると、サイト全体が画面真っ白になってしまう場合があります。この場合、動作させようとしたスキンをサーバーから削除させないと復活できません。しかし、管理画面も使いやすく、ウェブログじゃないコンテンツとの融合もしやすそうです。

最後は Nucleus のサンプルの評価。「ニュークレアス」と読むらしいこのツールは、プラグインとスキンがめちゃめちゃ充実しています。しかし、管理画面がいまいち分かりにくいです。複数 Blog を編集することに最適化されていて、Blog ごとの個別設定が少し奥深いところにあるからです。あと、トラックバックは標準機能ではなく、プラグインで実現されているのは少し難点です。

他にも細かい問題点などあって、どれも一長一短という気がします。どれか1つ選べと言われたら WordPress にするでしょうが……。とりあえず、これらのサンプルサイトは、当面は公開しますが、しばらくしたら削除してしまう予定です。以前の iWeb お試しのように移設するつもりはありません。コメントやトラックバックをしてもいいですが、いたずらは遠慮願いますです。

[追記 2006-05-11 23:48] これらのツールを使えない理由として「クールな URI」の概念をもとに加筆訂正しました。

[追記 2006-08-10 22:33:48] サンプルを静的HTMLファイルに変換して Yuriko.Net 内に移設しました。