maRkのMyOwn

このブログでプラグインによってページ分割されたページのパラメタが付いているページについて、NOINEXとしたその後の状況についてです。

先月エントリしました、「今月のいらんことしい(2009年6月)」にて触れていました、「カテゴリアーカイブでパラメタ（page=）の付くページはNOINDEXとしてみた」についてですが、その後の経過をみてみました。

確認の方法ですが、Google Analyticsにて、先月（自2009年6月1日,至2009年6月30日）の範囲で「閲覧開始ページ」の情報から、「page=」が含まれるページというフィルタをかけることで確認をおこなっています。

Analyticsのグラフでみたところでは、パラメタによってメタタグ挿入の振り分けを実施したあとから、「page=」の付いているページの数値が減少していることが、ぱっと見ただけで確認できました。

と、言葉だけで示してもピンとこないので、いちおう参考としてグラフを作ってみました。

先述したフィルタ済みの結果をエクスポートして、Excelにて取り込み、「日付」とパラメタ付きページの「閲覧開始数」のデータを基としたグラフです。

補足およびコメント

ExcelへはAnalyticsから、エクスポートの機能で「CSV形式（Excel）」を選び、出力されたファイルからデータはそのままでグラフ作成をおこないました。

考えついた当初は、パラメタのないページは検索結果にインデックスしておき、パラメタ付きのページをインデックスさせないことでタイトルが同じで内容の異なるものがインデックスされないようにするということを目的としていました。

重複するコンテンツの対処としては、rel="canonical"というのがあるのですが、アーカイブページについては目的が異なるような気がしましたために使わないでいます。

全体のアクセスからみていきますと、アーカイブページから（当サイトに）入るケースは減少傾向となりましたが、個別ページはアクセス数はそれなりにあるようでして、全体としては、極端な変化がみられないという感じでした。

Firefoxのアドオン、「Operator」のユーザスクリプトを使って、Twitterにポストするものを書いてみました。

Operatorのユーザースクリプトの「hAtom.js」を利用しますため、あらかじめ、以下のページからコードを入手しておく必要があります。

• Operator User Scripts（Mike's Musings）

hAtom.jsのセットの方法は、わかりにくいものでよければ以下のページに記載してあります。

• Operatorユーザスクリプト、hAtom.js

Operator経由でTwitterにポストするためのコードは、以下となります。なお、コチラがユーザスクリプトの書き方をよく把握してないので、書き方があっているのかどうかは不明なのと、Microformatsが書かれていないと動作できないことから、テストしたページは少ないです。（自分のトコのページだけでは限界が。。）

実用性とかはギモンなのですが、参考程度と個人の覚書ということで晒しておきます。

セットのときは任意のファイル名で拡張子.jsとして保存しておき、Operatorのオプションメニューから登録します。登録のときに、Operatorのオプションメニューの「動作」のtabから、「Submit to Twitter」を追加します。

// Submit to Twitter
var submit_to_twitter = {
  description: "Submit to Twitter",
  shortDescription: "Submit twitter",
  scope: {
    semantic: {
      "hAtom-hFeed": "hAtom-hFeed",
      "hAtom-hEntry": "hAtom-hEntry",
      "hCard" : "url",
    }
  },
  doAction: function(semanticObject, semanticObjectType, propertyIndex) {
    if(semanticObjectType == "hAtom-hFeed"||semanticObjectType == "hAtom-hEntry"){
      var _url = window._content.document.location.href;
      var _title = window._content.document.title;
      return "http://twitter.com/home?status=" + encodeURIComponent(_title) + "%20" + encodeURIComponent(_url) ;
      }
    if(semanticObjectType == "hCard"){
      var _urlvcard;
      var property = this.scope.semantic[semanticObjectType];
      _urlvcard = semanticObject[property];
     return "http://twitter.com/home?status=" + _urlvcard;
      }
  }
};

SemanticActions.add("submit_to_twitter", submit_to_twitter);

ページで、hAtomが埋め込まれていたときは、そのページのタイトルとURI、hCardでURL情報があるときは、単にURLの情報だけをPOSTします。Operator経由であることを示す語句を添えれば、そのページがMicroformatsが埋め込まれているということを知らせることができるカモ（？）。

今月（2009年６月）、サイトのテンプレート等をカスタマイズしたところをまとめた記事です。

今月は、Movable Typeのマイナーアップデートがありました。

このほかには、これといって目立ったところを弄っていないのですが、とりあえず記しておきます。

• 4.25から4.261へアップグレードした
• 各記事ページでコメンテーターのアンカーを付けた
• アーカイブページにAjax検索の仕組みを採用した
• Open Searchプラグインを導入
• カテゴリアーカイブでパラメタ（page=）の付くページはNOINDEXとしてみた

4.26へのアップグレードは順調に問題なく進みましたが、不具合に遭遇。その後、早急に修正ヴァージョン4.261がリリースされました。

コメントされる方のリンクですが、コメントのテンプレートにはもともとIDがMTCommentIDが付与されてましたので、それを利用したというだけです。

アーカイブインデックスですが、詳細は以下にて記載してあります。

• MT：アーカイブインデックスにAjax検索を取り入れて改造した

Open Searchプラグインについては、以下に記しておきました。

• Open SearchプラグインにAjax 検索を

MTPaginateプラグインをカテゴリーインデックスページに採用していますが、 phpでパラメタの付いたページには、metaタグで、下記のような出力となるようにしてみました。

• <meta name="robots" content="noindex" />

アーカイブインデックステンプレートでパラメタのないトップページにはコレがでないように振り分けしてあります。今現在その結果どうなるのか様子を見ているといった状況です。

今月のカスタマイズは以上です。2009年6月のアーカイブは以下から閲覧することができます。

• 2009年6月 Archive

Movable Typeのグローバル・モディファイアのtrim_toを使うとき、エンコードすべき文字の途中でトリムされる場合の検証と対処について

説明がわかりにくいと思うので、いきなりですが、やりたいことをテストテンプレートにて示します。

test template 1

<mt:setvars>data=0123456789&ABCDEF</mt:setvars>
<?xml version="1.0" encoding="<$MTPublishCharset$>" standalone="yes" ?>
<data><mt:var name="data" encode_xml="1" trim_to="11" /></data>

上に示したテンプレートでは、0から&（アンパサンド）までを指定して出力するものです。

このテンプレートをそのまま出力(XMLファイルとして)させてブラウザで見ると、パースエラーとなってるはずです。

では、trim_toの値を15にしてみるとどうでしょうか。これはエンコード後のアンパサンドの文字数を含める数値です。

test template 2

<mt:setvars>data=0123456789&ABCDEF</mt:setvars>
<?xml version="1.0" encoding="<$MTPublishCharset$>" standalone="yes" ?>
<data><mt:var name="data" encode_xml="1" trim_to="15" /></data>

今度は、モディファイアの順番をいれかえして、trim_toを先に記述してみます。

test template 3

<mt:setvars>data=0123456789&ABCDEF</mt:setvars>
<?xml version="1.0" encoding="<$MTPublishCharset$>" standalone="yes" ?>
<data><mt:var name="data" trim_to="11" encode_xml="1" /></data>

この場合だと、問題なく表示されます。

日本語の場合でテストしてみます。下のテンプレートではどうでしょうか。

test template 4

<mt:setvars>data=あいうえお&かきくけこ</mt:setvars>
<?xml version="1.0" encoding="<$MTPublishCharset$>" standalone="yes" ?>
<data><mt:var name="data" encode_xml="1" trim_to="9" /></data>

まとめのようなもの

以上のテンプレートは故意にエスケープすべき場所を指定してトリムをおこなっていますが、普通に記述していて予期しない箇所でパースエラーを引き起こす原因になっていることがありうるかも。

回避の方法としては、先にtrim_toを記述してから、encodeをおこなう形にするか、それが具合悪いのであれば、setvar、getvarで変数に渡してから処理するとか、XMLならば当該箇所をCDATAにするか、でしょうか。

それと、グローバル・モディファイアの処理を先に書いたものが先に実行されるらしいというかそういう仕様っぽいです。

スーパーマーケットでお買い物のハナシ。安い品を求めてあれこれハシゴするより同じ店舗を通い続けるのがいいのかも

景気がよくないと、どうも経済観念がおこってきて、如何にして出費をおさえるかとかばかり考えるようになってしまいました。そのなかで、日々買い物をしていて、スーパーでの買い物は、同じ店に通い続けるのがいいのかな、と思うようになりました。

その主たる理由なのですけど、「そのほうが時間を有効に使えるかも知れないから」って全然経済とか関係ないような理由です。

自分とこは新聞購読してないので、チラシが入ってこない所為というのもあるけど、チラシが見れたらみれたで、Aスーパーは野菜が安くて、Bスーパーは魚が安い、とわかれば野菜はAスーパー、魚はBスーパーで買おう、のように決めることも可能ですよね。

で、敢えてそれをしないというのは、以下のようなことから......

• 店舗移動の時間、清算の時間、あと移動にかかるコストを抑える
• 同じ店に通えば品物がどこにあるかわかるので探す時間が節約できる
• 複数の店舗で、ポイントを作るとポイントが分散してしまう

お店の移動に自動車を使えばその分のガソリンも消費します。まぁこれは仕事の帰り道にスーパーがあるとかいう場合もあるので、それほど重要ではないです。

買いたい品物がどこにあるのかがわかりやすいというのは、自分にとっては大きいメリットと思ってます。「聞くは一時の･･････」というのがあるのですけれども、買うつもりのあるものは聞いたら済むのですが、そうではなく、買うかどうかは実物を見てから決める、というようなものは聞きづらいのですね。定員からみると買いもしないものをどこにあるか聞かれるのは迷惑なことですし。

それと、最近はよく「メモ用紙」片手に買い物をされるヒトをよく見かけます。ワタくシも真似して実践してるのですが、要は必要以上に買わないための知恵みたいなものと思うんですけど、コレ、品物がどこにあるかすぐにわかるとですね、結構買い物時間の短縮につながります。

ポイント制度は毎日のことなので活用できるのなら活用したいところです。どうせ貯めるのならば同じ店舗のほうがいい、ってだけです。ポイントによって、割引につながるとか何らかの還元があるのならば多少は他の店舗より高くてもそれほど気にしなくていいかなと。

いいたいことは以上なのですが、これはひとつの考えでしかありませんので。あと、ナニかの譬えとかで引き合いに出したワケでもないです（コチラがどう読み取レとかも言えないんですが）。コノゴロなんとなくそう感じたので。