にこらとてすらの反省会

cloudControllっていうところ(Google App EngineみたいなPlatform as a Service)のアカウントを取ってみました。PHPやらMySQLやらが使えるので、無料枠でどこまで使えるものか、試しにWordPressをインストールしてみました。

すくりや

ちょっと機能の豊富なブログが欲しいと思っていたのでぴったりですね。ドメイン長くてアレですが。

まだ新しいサービスなのでちゃんと使えるかどうか様子を見ながらですが、気に入ったらここのブログの引越しも考えてみます。

駄デベWikiの方に書こうと思ったけどSPAM扱いされて編集できなかった。困る。

なのでここでご報告

SoSiReMiが一昨日くらいから壊れてました（気付くの遅っ）。新規にnarをアップロードしてくださった方のnarをうまく処理できず固まってました。現在は対策を施して、不完全な状態でアップロードされたnarを一旦管理者権限で削除しました。もう別の配布場所をご用意されたようですが、こんな不安定なアプロダでよろしければまた使ってやってください。ほんとすみません…。

2011年東北地方太平洋沖地震を受けて、伺か関係者の安否情報を扱うWikiのページが開設されました。

伺か安否情報書き込み板

今までに伺かに携わった経験を問われて否定できない人は、安否情報に自分が無事である旨を書きこんでおきましょう。

あなたの無事を知らない人を不必要に不安がらせる可能性はとりあえず無くしましょう。

ドウメキ不具合調査中の思考経路垂れ流しまとめ

昨日うにゅう＠もどき板ゴースト製作上の質問スレでドウメキの不具合相談がありまして、問題は解決したのですが、特定の現象の解決法そのものよりも、その解決に至るプロセスの方が多くの人にとって価値があると考えたため、その過程を思い出しながらまとめてみました。

不具合の原因の特定に至る時間の節約に役立てれば幸いです。

以下、その時の脳内ダダ漏れ

※SSP固有の機能を利用した部分に【！】マークを付けています。

報告内容

これを起動して開発パレットのスクリプト入力から、

\h\i[79]\e

というスクリプトをおくると40秒ほどでアニメーションが止まってしまいます。

ドウメキ起動

• 【！】Ctrl+S
• "\h\i[79]\e"と打つ
• 数十秒待つ
• 再現した。(通常のバグ報告の場合ここまで来れば90%解決したも同然です)

• surfaces.txtをさらっと眺める
• 数十秒でアニメーションがとまるような記述は見当たらない

※SSPはSHIORIイベントを投げて返ってきたSakuraScriptを再生するだけの装置である
※SSPが勝手に判断してゴーストを制御することは（原則として）ない

【！】SSPのログ起動

機能＞スクリプトログ

• もう一度再現手順を繰り返す
• アニメーション停止と同時に"\0\s[0]\1\s[10]\e"再生キタ！(ここで99%解決したも同然です)
• こいつが原因だ。SHIORIが"\0\s[0]\1\s[10]\e"を投げ返すきっかけとなったイベントは何だ？

【！】SSP SHIORIログをとる

機能＞開発用パレット＞「SHORIログを取る」にチェック

• もう一度再現手順を繰り返す
• ゴーストディレクトリ内のssp_shiori_log.txtを開いて"\h\i[79]\e"で検索
• その次に来る"\0\s[0]\1\s[10]\e"を検索
• イベント名確認
• OnSurfaceRestoreと判明(ここで99.9%解決したも同然です)

=====send=====
GET SHIORI/3.0
ID: OnTranslate
Charset: Shift_JIS
Sender: SSP
SecurityLevel: local
Reference0: \h\i[79]\e\e


=====response=====
SHIORI/3.0 204 No Content
Charset: Shift_JIS

...(略)

=====send=====
GET SHIORI/3.0
Charset: Shift_JIS
Sender: SSP
SecurityLevel: local
ID: OnSurfaceRestore
Reference0: 0
Reference1: 10


=====response=====
SHIORI/3.0 200 OK
Value: \0\s[0]\1\s[10]\e
Charset: Shift_JIS

脳内中間報告

里々がOnSurfaceRestoreで"\0\s[0]\1\s[10]\e"を返していることが原因だった

OnSurfaceRestoreで何も返さない(204 No Contentを返す)ようにすれば直るはず

解決策の模索

• 「何も返さない」ことを明記して基底の処理をオーバーライドする必要がある(どうやるんだっけ？)
• 里々Wikiで"204"で検索
• ＄今回は喋らない【タブ】有効
• 直った！！！！(100%解決)

＊OnSurfaceRestore
＄今回は喋らない【タブ】有効

おしまい

【！】でマークした部分を駆使すれば、今まで闇雲にバグ潰しにかけていた時間がかなり節約できるかもしれません。

何よりも今回は90%解決済の状態で報告が上がっていたので解決は容易でした（要点を得ない、再現しないものは解決不能）。再現のため単純化したNARを添付するのは再現性を確実にする上、原因の絞り込みを容易にするための模範的なレポートだと思います（自分一人でデバッグする際も大事なことです）。ということで勝手にご紹介させて頂きました。

SiReFaSoとSoSiReMiのコードを一般化

ゴースト更新捕捉システムと、ネットワーク更新に対応したアップローダーのソースコードを公開しました。

• DAU-Crawler
• NAR-Station

今後、SiReFaSoはDAU-Crawlerを利用したサイトの一つ、SoSiReMiはNAR-Stationを利用したサイトの一つ、という位置づけになります。

個人的なバックアップが主目的ですが、アップローダーの方は個人利用の需要があるかも知れないので、詳細な設置方法など暇を見て駄デベWikiなどに書いていこうと考えています。

rel="canonical"属性

URLの末尾に?マークに続いてクエリ文字列が付加されたものを目にする機会も多いことと思います。サイト内検索結果だったり、ページングなどに利用されたりする場合があるわけですが、基本的に独立したページとして検索エンジンには認識されます。

SiReFaSoでもページングなどに利用しているのですが、ちょっと好ましくない状況を目にしました。

下のリンクは /?page=1 というURLで独立したページとしてインデックスされてしまっています。これはTOPページと同じ内容であり、並べて表示してもらっても困ります。

こういった状況を修正するには301リダイレクトが王道であり、検索結果を改善することが可能です。

ところで、重複コンテンツといえばそうなんだけど、ちょっとだけ違う、そんなクエリ結果もあると思います。印刷用ページであるとか、テーマの色が違うとか、ソート順が違うとか。こういったケースでは301リダイレクトは使えません。検索クローラだけでなく閲覧者までリダイレクトしてしまっては別ページを用意した意味がありません。でも別ページとしてインデックスされたくない、そんなケースもあると思います。

そんな状況のために考案されたのがrel="canonical"属性です。詳細はGoogleの解説サイトが参考になります。これによって重複するコンテンツの元となるページを検索エンジンに教えることができます。

というわけで、 /?page=1 の時はTOPページをcanonicalページとして指定するよう変更してみました。クエリ結果としては正当なものですし、リダイレクトは適切ではないな、という判断です。効果が反映されるまでは時間がかかるかもしれないのでしばらく様子を見てみることにします。

余談

canonicalの歴史

主要な検索エンジンがサポートすることを発表したのがおよそ２年くらい前のようです。まだ歴史が浅いんですね。なので利用されている例もまだ多くなく、効果の程も未知数で、今後ガイドラインの変更などもあり得るかもしれません。過大な期待はしないほうがよさそうです。

インデックスされた経緯

/?page=2 で前のページと次のページへのリンクを表示していたのですが、単純に1引いた数を指定していたため、 /?page=1 がインデックスされてしまったのでした。現在は1ページの時だけクエリを省くよう修正済です。サイトのURL初期設計って大事ですね。

ステータスコードとは

HTTPリクエストという言葉を聞いたことがある方も多いと思います。Webサーバーに対して「ファイルくれ」と要求する行為を指します。このページを見ているみなさまがお使いのWebブラウザーも「HTMLくれ」とウチのサーバーにリクエストし、返されたHTMLを適切にレンダリングして表示しているわけです。この時サーバーからは 200 OK(もしくは304 Not Modified)というステータスコードが返されています。わかりやすくいうと「お持ちいたしました、ご主人さま。」という意味です。

200以外にもステータスコードはたくさんあります。メジャーなものを以下に列挙します。

200 OK

お持ちいたしました、ご主人さま。

204 No Content

了解いたしました、ご主人さま。（何も持ってこない）

301 Moved Permanently

当店は以下のアドレスに移転致しました。

302 Found

臨時で以下のアドレスで営業中でございます。（再びここで営業再開する予定）

304 Not Modified

前回申し上げた通りでございます。（変更はありません）

400 Bad Request

日本語でおk。

401 Unauthorized

こちらは会員制となっております。

402 Payment Required

先にお支払いをお願い致します。

403 Forbidden

承諾いたしかねます…。

404 Not Found

ご注文の品はございません。

410 Gone

いままでありがとうございました。

500 Internal Server Error

はわわ、失敗しちゃいました＞＜

503 Service Unavailable

少々お待ちくださいませ＞＜

200,204,400あたりはSHIORI/3.0やSSTPのプロトコルでも利用されています。SSTPはHTTPを模して作られた仕様なので当然ですね。

ファイルが存在しない場合は 404 Not Found を返すのがインターネットのルールなわけですが、 200 OK を返しつつ「ファイルが存在しません」と書かれたHTMLを返す行儀の悪いサーバーを最近３つも見つけたので憤りを禁じえずこんな記事を書いてみました。

なぜファイルがないのに 200 OK を返すのか

「サーバーの中の人が設定を間違えたから」ではないです。レンタルサーバー屋さんたちが示し合わせたようにそろって間違えるはずがありません。理由は他にあります。

調べ物をしているときに、「はてなキーワード」が検索で引っかかることを経験したことがある人も多いのではないでしょうか。そしてページに飛んでみると「このキーワードはまだ作成されておりません」みたいなことが書かれていて大いに不評を買った時期があります。検索エンジンは200 OKが返されたページはインデックスし、404 Not Foundが返されたページはインデックスを削除する、というよく考えれば当たり前な挙動をします。「まだ作成されていない」のに200 OKを返していたためにインデックスされ、しかもはてなはSEO術に長けているため上位表示を獲得し、Spammyな状態を作り出してしまったわけです。

私が想像するに、内部の状態を無視して200 OKを返しまくるサーバーは、検索エンジンにインデックスされること(かつ削除されないこと)を目的としているのだと思います。 そしてクリックすると「ファイルが存在しません」の周囲に表示される大きな広告画像の数々。これが真の目的であると推察します。言うなればWorld Wide Webに対するスパム行為です。ビジネスモデルを考慮するとそうしたくなる気持ちもわからなくはないですが…。

逆に検索エンジンにインデックスされたくない場合は200 OK以外のステータスコードを返しましょう。「現在メンテナンス中です」とHTMLで表示する場合は、併せてステータスコードを503 Service Unavailableにしておきます(.htaccessが使える場合ですが)。 こうすると検索エンジンはそのページの最新の状態を更新することをしません。「現在メンテナンス中です」というタイトルがインデックスされ検索結果に表示されたはずかしい状態のサイトを時々見かけますが、このようなことを防止できます。

ということで、普段ブラウジングしているときに意識はしませんが、ページのステータスコードは大事だよ！というお話でした。

アクセスしてもらうためのrobots.txtの使い方

先日.htaccessでアクセスコントロールという記事を書いたわけですが、今日は逆に検索クローラを丁寧におもてなしするためのrobots.txtの活用法を、実際にSiReFaSoで試してみたのでその結果と共にご紹介してみようと思います。

要するに検索エンジン最適化(Search Engine Optimization)ですが、あやしい方法では無いのでご安心を。「伺か」と言えば「広める条項」(cf.「広める」条項 - さとーのweb日記)で有名ですが、自分のゴーストを広めたい場合に知っておいて損はない知識であると思います。

サイトマップとは何か

sitemaps.org - ホームより引用します。

サイトマップを使うと、ウェブマスターはサイト内のクロールされるページを検索エンジンに簡単に知らせることができます。

サイト内のコンテンツ全てにアクセスできるようにリンクが適切に張られている場合は必要ないですが、目的のページまで何回もクリックしないと辿り着けないような場合はGoogleさんも大変です。SiReFaSoの場合はもっと深刻で、500以上のコンテンツが存在するにも関わらず数十ページも先を読みに行かないと辿り着けません。

そんなサイトが検索クローラに対してクロールして欲しいURLを提示出来る仕組みがサイトマップです。書き方は上述のサイトをご参考頂くことにして、私が書いてみた例を晒してみます。

<?xml version="1.0" encoding="utf-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <url>
        <loc>http://sirefaso.appspot.com/</loc>
        <lastmod>2011-01-21T20:10:51+09:00</lastmod>
        <changefreq>hourly</changefreq>
        <priority>0.8</priority>
    </url>
    <url>
        <loc>http://sirefaso.appspot.com/ghost/</loc>
        <priority>0.6</priority>
    </url>
<!-- 中略 -->
    <url>
        <loc>http://sirefaso.appspot.com/ghost/Nikola_Tesla/</loc>
    </url>
</urlset>

実際は動的に出力しています。500件も書きだすと負荷が掛かるので工夫が必要です。

そして、このファイルのURL自体を検索クローラに知らせる必要があるわけですが、そのために使われるのがrobots.txtなのです。アクセス拒否の意思表示の役割だけではないんですね。

robots.txtとは何か

今更ですが、一応参考リンクを張っておきます。

The Web Robots Pages

アクセス制限に関する仕様がまとめられていますが、サイトマップのURLを知らせる場合は以下のような感じで記述します。何処に書いてもOKでUser-agent指定は無視されます。

Sitemap: http://www.example.com/your_sitemap.xml

実験

今日の01:00頃にサイトマップを設置して8時間後くらいからのログを見ていますが、Googlebotさんが一時間毎くらいの頻度でアクセスしているのが確認できます。全てインデックスされるまでには時間がかかるだろうと思っていますが、さっき何気にサイト名でぐぐったら以下のような変化が見られました。

サイトリンクと呼ばれる赤で囲まれた部分が現れています。ブランド名とかでぐぐると企業のサイトのナビゲーションリンクと共に表示されるアレです。クリック率が上がるというので業者さんが出し方を研究しているくらいのレアなアレが出てる…(　ﾟдﾟ)

ということで、サイトマップの効果かどうかはわかりませんが、伺かのユーザさんを自分のサイトに迷うこと無く誘導できるようなサイトの構造なりデザインなりの改善を検討されている方は、検索ロボットに対してもフレンドリーな設計を意識してみてはいかがでしょうか、というお話でした。

余談

他にもテクニック的なものは聞きかじった教養程度に心得ているつもりで、SiReFaSoにも実践していたりします。

ページタイトル

いわゆる<title>タグですね。そのサイトの特徴を表し、検索での来訪者がひと目でどんなサイトかわかるものが望ましいです。このサイトがダメな例ですね。SiReFaSoはその反省を踏まえて「伺か」というキーワードを加えました。可能であればURLにもキーワードが含まれると良いですが、日本語圏では難しいです。Wikiなどはこの点強いですがURLが長いので今度はユーザフレンドリーではありません。

最近は記事のタイトルにしれふぁその文字を意識的に含めないようにしていますが、ノイジーになるのを防ぐための検索避けです。最近はしれふぁそでぐぐると深瀬さんのブログが上位表示されますね。それくらい強力です。

HTMLの構造

Validであることは当然ながら、やはり意味を伴う構造をきちんとマークアップした方が良いです。先日の改装でこの点を大幅に改善しましたが、その後明らかにGoogleさんがデレました。まだ勧告されてないHTML5でマークアップしていますが、それなりに意味も解釈しているのではないでしょうか。

Pretty URLs

http://example.com/?year=2011&month=1&day=21&tag=sitemap,robotstxt よりも http://example.com/2011/01/21/sitemap-robotstxt の方が有利であるという人もいたり、Googleの中の人はいやいや前者の方も同等に見ますよと言っていたりですが、実際に自分で試すと効果の違いはやはりあるように感じます(以前はTOPページと検索だけでした)。ディレクトリの階層を綺麗に見せることは人間の目にも優しいものです。

階層は浅く

URLの階層は浅いほうが良いという話は聞きますが、深いサイトから浅くするビフォー・アフターはやったことが無いのでわかりません。あまり深いURLは人間にも優しくないとは感じます。

上記に例示したものは内的SEOと呼ばれます。Webのルールを良く理解して来訪者（機械を含む）に優しいサイト作りを心掛ければいずれも自然とそうなるべきものです。

内的に対し外的SEOというものもあります。いわゆる被リンクの獲得ですね。アンカーテキストにキーワードを含めてもらうと良いとか、ページランクのアルゴリズムとか、興味はありますがあまり深入りしない方がいいかなと思っています。

最後に一つ、リンクを張りたいけど検索エンジンにはリンクとみなして欲しくない場合のオプションをご紹介します。

<a href="http://example.com/" rel="nofollow">example.com</a>

ソーシャルサイトではリンクを張りまくるスパムへの対策として、 rel="nofollow" 属性を付加して被リンク獲得行為を無効化するのが一般的となっています。気になる人はTwitterなどのソーシャルサイトのHTMLソースを見てみましょう（はてなブックマークは付けてないそうですけど）。

なんだか余談のほうが長くなってしまいましたが、何よりも大事なのは来訪者にとって魅力的なコンテンツを充実させることです。伺かのゴーストをより多くの人達に知ってもらうための一助になれば幸いです。

:only-child と :only-of-type

iPhoneではマウスオーバーが使えないのでSiReFaSoでゴーストの立ち絵が見れません。でも全部表示したら邪魔そうです。それでもどうしても見たいので、個別URLでは見れるようにしました。

HTMLは共通で利用したいし、JavaScriptは使いたくない。CSSだけでトップと個別URLで表示のON/OFFを切り替えるために、要素が一つだけの時に適用するCSS疑似クラスを覚えたのでメモしておきます。

div:only-child {}
div:only-of-type {}

only-childは自身が親要素に対して唯一の子要素である場合、only-of-typeは自身と同一の要素が兄弟要素にいない場合です。

SafariはCSS3使い放題で良いですね。これで個別URLの他に、検索で一件だけヒットした場合も適用されます。あとはブラウザでゴーストが動作すれば完璧ですね。

SiReFaSoの仕様を駄デベWikiにまとめました。robots.txtが設置できない場合の意思表示方法にinstall.txtを使うことにしました。今後仕様に変更があったらこちらに追記していこうと思います。

Don/SiReFaSoの仕様 - 駄でべろぱの小ネタWiki

アクセス拒否とか削除とかいう機能ばかり追加しているのも悲しいので、もっと楽しいことをやろうと思います。

適用するCSSを切り替えてiPhoneでも見やすくしてみました。外出先でもゴーストの更新をチェック！…する必要があるかどうかはわかりませんが、とりあえずCSS書くのは楽しいですね。