Cat-sushi Log:IT

【Bluetooth接続断念】AndroidのカーオーディオFMトランスミッタ接続

2009-08-16T20:47:00.000+09:00

少し前になりますが、Android買いましたよ～

併せて16GBのMicroSD Cardを購入したので、手持ちのCD(ogg圧縮済み)は全てAndroidで持ち運べる。
ネットラジオも3G経由で聞けるので、容量関係なく音楽漬け...
TuneWikiとかLast.fmとか機会があれば紹介します。

まあ、そんなに音楽好きでもないのですが、ドライブのときにCDをセレクトして持って行ったり、いちいちCDチェンジするのはちょっとと思いますので、Androidのカーオーデイ化に挑戦です。

先ず考えたのが、Bluetoothで繋ぐこと。
HT-03Aにはなんと物理接続端子がUSB miniBの独自拡張の一つのみ(ステレオヘッドフォン、マイク、リモコンを押し込んでいます。もちろん?充電もここから)。
この潔さは大好きですが、充電用に汎用USBコードを繋ぐとオーディオ有線は無理。

AndroidはBluetooth 2.0 A2DP対応なのでこれがリーズナブルかと思ったの次第。

我が家のカーオーデイオはbluetooth対応でないものの、赤白端子くらいはありそうなので、ここにシガーライター電源のBluetooth受信機を接続すれば終わりかと。

ところろが、そんなものはヨドバシやAmazonを調べても存在しない。
シガーライター電源の赤白端子接続ケーブルはiPod用のものしか...
iPodスピーカーをBluetoothスピーカーにするBluetoothレシーバなるものがあるようなのでこれを組み合わせれば、と思ったのですが、iPodというClosedな仕様を挟まざるを得ない気持ち悪さと、出費が嵩むのことから断念。

それにしても、カーオーディオケーブルといい、スピーカーといい、それ用のBluetoothレシーバといい、いかにiPodが音楽再生機の一大勢力であるかを再認識させられます。

次に考えたのが、接続端子は分岐アダプタで増やすとして、

オーソドックスにFMトランスミッタ接続。

例によってFMトランスミッタもiPod用のものが大半ですが、さすがにステレオminiプラグ+USB充電端子を備えたものを見つけることが出来ました。

これで、カーオーディオ接続完了です(コード邪魔だけど)。

次はAndoroidホルダか?

Firefox Add-onのAuto Pagerにあし＠を登録しました

2009-05-20T00:46:00.002+09:00

Firefoxをお使いでしょうか?
firefoxのAdd-on(拡張機能)にAuto Pagerというのが有るのをご存知でしょうか?

簡単に言うと、

「Googleの検索結果ページのようにページングされ、「次へ」等のリンクで続きを閲覧出来るサイトにおいて、1ページ目の最後に残りのページを動的に次々と追加して行くことで、スクロールのみで無限にページを参照できるようにする」

機能です。
お分かりになられたでしょうか?(これが私の簡単に言う能力の限界です ^^; )

百聞は一見にしかず、ということで、こんな感じです。

原理的にはWeb開発者には比較的慣れ親しんだ機能ばかりを用いています。
具体的には、

正規表現またはGlob形式で指定されたURLのページにおいて、
XPath①で指定された「次へ」ハイパーリンク先ページ内の
Xpath②で指定されたコンテンツ本体(ヘッダ、広告などを除いた)である部品(<div>等)を
1ページ目におけるXpath②で指定したコンテンツ本体である部品の直後にAjax的に挿入

するだけです。

このAdd-onの凄いところは、このありふれた技術を組み合わせたことではなく、
ちょっとしたWeb開発者なら簡単に作成できるような上記の定義を利用者コミュニティーのメンバに気楽に作成させて、共有するところです。

試しに私もみんなの足跡『あし＠』の定義を作成して公開してみました。
確認した範囲では下記のページに対応しているはずです。

読者管理(読者一覧)
MYブログの足跡(最近の足跡リスト)
お気に入り管理(お気に入りブロガー)
受信メッセージ
最近更新したブロガー

Auto Pagerを有効にしてあし@のページを訪れるだけで、上記定義が提示されるはずなので、気が向いたらお試しあれ。

ところで、考えてみると、Firefox自身の魅力は、その技術力の高さやアンチMicrosoftの象徴以上に、Add-onという付加機能機能によってユーザ兼開発者コミュニティを巻き込み、Mozilla自身単独では成し得なかった高機能ブラウザを提供できたこと言えます。
これが、今日のFirefox人気の主要因であり、高速なブラウザ(Chrome、Safari等)が出現してもユーザを離さない要因でしょう。

面白いところは、Auto PagerはそのFirefoxにおける一介のAdd-onでありながら、そのサイト用定義作成を、さらにAdd-onのユーザ兼定義開発者コミュニティーに広く求めることで、Add-on単独では成し得なかった世界中の多種多様なWebページの自動ページめくりを可能ならしめたところです。

なんだか複雑ですが、ちょっと面白くないですか?

古くて新しいOS機能への回帰の動向

2009-05-12T12:00:00.000+09:00

Firefoxの未来形ではタブ毎にプロセスを分ける設計を検討しているそうです。

Firefoxのタブも、Chromeに似たマルチプロセス化へ－＠IT

もちろん、タブごとのマルチプロセス化による恩恵は、グーグルがChromeの発表時に広く宣伝したことで知られるようになったとともに、IE8ベータの影響も大きいようです。

これはある意味、新しくて古いOSの機能への回帰ですが、こういった流れはブラウザの他にもあるようです。

最近流行の(?)JavaVMやサーバ仮想化におけるVM(VMWare等)は、アプリケーションからしてみれば単なるOS層の再定義に過ぎません。しかしこの再定義は、JRockitのような一部の試みを除いて、HV、OS、JVMなどの言語VM、と階層が深くなる一方であり、そのオーバーヘッドも無視できなくなったようです。
これは先に述べたPCのブラウザ環境においてもそうですが、特にAndroidのようなハード制約が厳しいモバイル環境においてはなおさらです。

ここにおいて、Googleの解はOSへの回帰です。

Androidのアプリケーション開発環境は独自のJava環境ですが、その実行環境であるVMはJavaVMを用いずにDalvik仮想マシン, http://ja.wikipedia.org/w/index.php?title=Dalvik%E4%BB%AE%E6%83%B3%E3%83%9E%E3%82%B7%E3%83%B3&oldid=25752724 (last visited 5月 11, 2009).を用いています。

Dalvikの特徴の一つは、アプリケーション毎に異なるVM(Linuxのプロセス)を立ち上げることです。
これによって、OSのメモリ管理の恩恵にあずかれます。

OSのメモリ管理の利点の一つは、強力なアクセス保護機構ではないでしょうか。
これにより、バグやそれを悪用したマルウェアからの不正アクセスや以上終了から守られます。これはPCのブラウザ環境において、マルチプロセスをChrome、IE8が採用し、Firefoxが採用を検討している理由と一致します。

OSのメモリ管理の利点のもう一つは、OSのメモリ回収機構を利用できることでしょう。
これは一般にMMUのようなハードウェアのサポートを受けられることを意味しています(ARMの下位モデル等モバイル環境にはMMUがないケースもありますが)。
つまりJVMにおけるGCの厄介な問題をハード・OSに任せられることを意味します。

Dalvikは先に述べたようにアプリケーション毎にVMプロセスを分離しますので、少なくともアプリケーション終了のタイミングではOSのメモリ回収機構を活用できます。

さらには、アプリケーションプロセスのライフサイクル内におけるGCもDalvikでは特徴的です。
DakvikのGCはdlmallocというGoogle再実装libcにおけるメモリ割り当て機構(?大元はCreative Commons License)における領域サイズ毎に分けて管理されたfree関数そのもののようです。

これにより、シンプルかつ強力なメモリ管理が行われる、と言うことでしょうか。
これらこそ正に新しくて古いOS機能への回帰です。

IPAフォントV3配布開始 (ライセンスがいつの間にか変更)

2009-05-11T18:00:00.002+09:00

IPAフォントの最新版Ver.003.01がリリースされていました。

新バージョンの主たる目的はWindows Vistaでの採用で話題となったJIS X 0213：2004に対応し、文字種が増えたことでしょう。

これに加えて、重要な変更はライセンスの利用条件が緩和されたことです。
Ver.2まではフォントのデザイン変更を認めておりませんとのことでしたので、派生フォントを作ることや、特にそれを再配布することが困難でした。

今回このライセンスが緩和され改変フォントを再配布可能となっています。

オープンソース・ライセンスのIPAフォント公開，改変フォントの再配布が可能に：ITpro
IPAフォントが2009年4月中旬にもオープンソース・ライセンスへ，改変と再配布が自由に：ITpro

この「IPA Font License Agreement v1.0」はOSIにも認定されたれっきとしたライセンスですが、伝染性の観点からGPLやCreative CommonsのCC BY-SAに近いもののようです。
伝染性といっても、文字集合一式のフォントフェースが揃ってなんぼのフォントですので、同一機能の派生フォント集に同一ライセンスが適用されるのはそれほどおかしな話ではないでしょう。触っただけで(ちょっと小さいライブラリをリンクするだけで)感染するGPLのプログラム世界とはやや趣は異なります。
非営利団体が利用促進するためであれば、商用利用も多いフォントはBSD風(CC BY風)のライセンスにすれば良いのに、とは思いますが。

とはいえ、和文フォントの世界にもようやくOSSの風が流れてきたことは歓迎です。

フォントは文書を書く・読むという極めて根源的な活動において必須の要素でありながら、和文においては自由に使えるものが非常に少数です。

欧文フォントは何千種類ものフリーものが出回っていますが、和文フォントではプロプライエタリを含めてメジャーなものは2系統しかないと言っても過言ではありません。

一つはTB系フォント、もう一つはHGです。
それぞれ、基本的に明朝とゴシックしか持っておらず、それぞれ英数字他においてプロポーショナルか否かのバリエーションがある程度です。

定かではありませんが、IPAフォントはTB系フォントのようです。
Wikipediaの古い記述では「製作メーカーは表示されていないが、タイプバンクゴシック・タイプバンク明朝に酷似しているためにタイプバンク製であると言われている。」とありました。

もう一つのHG系フォントはリコーが作成したものです。
WindowsにもHG ゴシック等が標準で入っていますが、これはリコーがMSにライセンスしたものです。
Sun(もうすぐOracle)のStarSuite(OpenOffice.orgの商用版。ただしグーグルから無料で入手可能)に含まれるHG ゴシックB Sun等もこのHG系列です。

以上、これだけです。
# 異論はあると思いますが。

和文でフォントが少ない大きな理由の一つは、文字数が多く作成コストがかかるからでしょう、もちろん。

もう一つの理由は、先に触れたライセンスの問題でしょう。

プログラムの世界でOSSが成功し、巨大なプログラムを多数世に排出意しているように、今後はフォントも多数世に排出されることを期待します。

参考
商用サイトでも無料で利用できる日本語のフリーフォント集 | コリス
欧文フォント一覧 [フォントふぉんと font .com]

アクセスカウンタが破壊：OpenSocialじゃ作れないの?

2009-04-19T17:12:00.002+09:00

アクセスカウンタとして無料のアクセスカウンター！[動くアクセスカウンター]を利用していましたが、なぜかリセットされてしまいました。
カウンタの再生成をすれば事足りるのですが、またリセットされるのも何なので忍者カウンターにしました。
ついでに、Analytics導入時からのセッション数でカウンタをセットしたのでアクセス数がジャンプアップしています、あしからず。

ここからが本題。
OpenSocialの習作としてアクセスカウンタでも作ってみようとも思ったのですが、OpenSocial APIだけでは無理そうなのでちとハードルが高い。

OpenSocialには永続化の手段としてnewUpdatePersonAppDataRequest()がありますが、どうもこれはViewer別かつアプリ別かつOwner別の記憶領域のようです。
そして、更新権があるのはViewerのみ(コンテナによって違うらしいが、仕様上は)。

これでは、アクセスカウンタのようなViewer跨りのデータを管理するものや、GFCのコメント欄、5スター評価のようにアプリ跨りのデータを管理するものには利用できません。

このサイトでも導入しているEiji KitamuraさんのFriendConnect向けあしあとガジェットでは、VIEWERごとに自分のAppData領域にデータを保存する、という技。OWNERの友達のAppDataをまとめて取得という「テクニック」で何とか「みんなのあしあと」という「共有」データを演出しているようです。

しかし、この方法にも限界があり、メンバが増えるとサーバおよびクライアントの負荷が耐えられないような気がします。
また、単なるViewer毎のデータの集約ではない、本当の意味で更新可能な共有データを扱うことができません。

現状、Viewer間やアプリ間で共有・更新するデータを持つアプリを作成しようとすると、外部サーバを立ててgadgets.io.makeRequest() でやり取りを行うのが一般的かつ唯一の方法のようです。

Google Bloggerユーザのように自前サーバを持たない人もGoogle App Engine等を使えば良いようですが、こういった外部サーバを用意するのも一手間ですし、~~FriendConnectは残念ながらmakeRequest未対応だったりします~~(2008.4.20追記:今は出来るそうです。出来るという記述を見つけていませんし、実験も出来ていません、念のため)ので、やはりOpenSocial APIだけで実現できることが望まれます。

newUpdatePersonAppDataRequest()の関数名の意味や、"Person"を特定するものと思われる第一引数に指定できるのが現在VIEWER IDのみという不自然な状況からして、OpenSocalも元々はより柔軟なデータ永続化を目論んでいるように思います。

who can read/write the data を仕様として決定すべきとの意見も出ているようですので、将来的にはより柔軟(でセキュア)なアクセスが可能になるかもしれません。

Google Readerでコメント機能ってShare with noteと何が違うの?

2009-03-15T22:39:00.002+09:00

Google Readerでコメントを共有する機能がリリースされました。

Google Readerの記事をShareすると、記事の最後にAdd commentというリンクが追加され、これをクリックすることで利用できます。

実はShare機能は今まで興味が無かったので知りませんでしたが、Share with noteという今回リリースしたコメント機能と類似の機能があるようです。

両者(ここでは便宜的にcommentとnoteと記述)の違いを少しまとめてみました。

comment

自分はShared itemsフォルダで見える
(ポストの下部に列挙される。名前はyou)

FriendはFrined Shared itemsフォルダで見える(名前は本名)
Shared itemsのパーマネントリンクからは誰も見れない

note

自分はShare itemsフォルダで見える
(ポストの最上位に噴出しとして現れる。名前はyou)

FriendはFrined Shared itemsフォルダで見える(名前は本名)
Shared itemsのパーマネントリンクからは誰でも見れる(名前はニックネーム)

noteよりもcommentのほうが、表示が少し洗練されて、プライバシーが強化されたという感じでしょうか。

ちなみに、Shared itemsのパーマネントリンクでは右側にプロファイルが表示されますが、Friendが見ると本名が、他人が見るとニックネームが見えます。

また、Share with noteでAdd to shared itemsチェックボックスが現れますが、チェックするとそのたびShared itemにコピーが作成されます。
他方でチェックしないと、同様にコピーが作成されますが、これはNotesフォルダからしか見れません。

関連リンク:
グーグル、「Google Reader」に独自のコメントシステムを追加:ニュース - CNET Japan
「Google Reader」，友人とコメントをやり取りできる機能追加：ITpro
GoogleもFriendFeedから開発のヒントをもらうのが好き; Readerが会話機能を導入:TechCrunch Japan

サービス型アプリケーションは本当に危険か?

2009-03-14T23:58:00.003+09:00

先のポスト「障害時の自動代替・修復は高度になるほど良い? (Gmail障害と改善方針について思うこと)」で今回の報道について、言いたいこともありますが、それは別の機会にと言いましたが、丁度良いタイミング(?)で［WSJ］ Gmailでまたも障害発生 - ITmedia Newsしてくれました。

と言うことで、今回も、Gmailの障害をダシに、ちょっと違う話を。

どうも一般的に、GoogleのようなサービスやAmazon.com、Salesforce.comなどが提供しているサービスを使うことは、企業にとってリスクを伴うことも判明しつつある(ITmedia)と言って、イタズラに不安を煽る傾向があるようです。

サービスが危険であるという主張の裏にある理由を推測すると、

相手が信じられない (狭義のセキュリティ的に)
相手のデータ保護が信じられない (耐久性的に)
途中の通信が信じられない (可用性的に)

があると思います。

1.はどうでしょうか。
故意または過失により情報漏洩等が発生した場合、社内情報部門と、サービス提供他社でどちらが強く責任を追及されて社会的制裁を受けるかと言うと、明らかにサービス提供他社でしょう。
必然的に、セキュリティ確保に積極的になるのはサービス提供他社になるはずです。

2.はどうかと言うと、
データの耐久性をあげるには、データを冗長化する必要があります。
災害対策ともなると、冗長化した情報の少なくとも1セットは遠隔地に保管する必要があります。
一般的にこの冗長化はハードウェア、通信コスト、運用の人的コスト等、非常にコストがかさみます。
システムの規模が巨大になれば、または、システムの重要度が金融の勘定系のようにクリティカルになれば、これらのコストが見合うかもしれません。しかし、いくらメールシステムやCRMが重要であると言っても、ユーザ企業がデータの冗長化を徹底するのは困難かもしれません。
それに対して、データの冗長化に関しては規模の経済が生かせるサービス型の方が有利と言えます。

3つの理由のうち、合理性があるのは3.だけでしょう。
システムの構成要素として、過去メール閲覧においてインターネットが追加になります。
構成要素が増えれば、必然的に潜在的な障害ポイントが増えるので可用性の観点では絶対的に不利です。

まとめると、インターネットを利用することによる可用性の低下のデメリットと、他の要因によるメリットを総合的に見て判断すべきでしょう。

個人的には、インターネットを利用することによる可用性の低下を他のメリットが上回るので、積極的にサービス型のアプリケーションを使うべき、と思います。

やや蛇足ですが、メールシステムの可用性について。

今回の2回のGmail障害における障害ポイントはインターネットではなかったので、3.インターネットの可用性の問題には該当しません。
また、メールの場合は元来インターネットからやってくる情報なので、MUAのサービス化に伴うリスクの増大は、MTAを含むメールシステム全体から見ると相対的に少ないものです。
さらに言うなら、メールのようなコミュニケーションツール、すなわち相手あってのシステムの場合、個々のユーザにとってのシステム(MUA/MTA)の可用性が同じなら、起こる障害はみんな同時の方が良いはずです。
自分のシステムだけ元気でも、相手のシステムが不調ならコミュニケーションできないことに代わりがありませんから。
そういう意味でも、多数のユーザが同時に障害に巻き込まれるサービス型の方が有利のはずです(心情的には逆だと思いますが)。

続けて、メールシステムのデータ耐久性(Durability)について。

メールシステムを純粋にコミュニケーションツールとして捉えた場合、可用性が最も重要ですが、今やメールは記録システムになっているでしょう。
この場合、可用性以上にデータ耐久性が重要です。
自社システムのメールサーバ容量の制限から、個人PCのMUAにメールアーカイブを保存している場合と、サービス型のメールMUAを比較した場合のデータ耐久性のどちらが優れているかは、もう説明の必要は無いですよね。

Stainlessで同一サイト複数セッション!

2009-03-08T17:39:00.000+09:00

興味のある記事を見つけました。

Chromeを超えた? 1タブ1プロセスのブラウザ最新版「Stainless 0.5」 | パソコン | マイコミジャーナル

見出しによると、プロセスがタブごとに分かれていることが売りとなっています。
Web/ブラウザがOSになったとか言われていますが、ある意味OSの備えるべき保護機能を普通に地味に実装したと言えます。

これはこれで興味深いのですが、プロセス云々が非機能であるのに対し、
私が注目したのはこちらです。

Google Chromeを含む他のブラウザにない機能の例としては、異なるタブ／証明書を使い1つのサイトへ同時のログインを可能にする新機能「パラレルセッション機能」と、独自のcookie保管機構が挙げられた。

Webアプリは最近少し触れるようになった初心者ですが、ちょうど興味を持っていたところにこのニュースでした。

なぜこんなことが話題になるかと言うと、一重に、
HTTPは元来ハイパーテキストにおいて単にファイル転送を行うために開発されたため、(中略) ステートレスなプロトコルである(HTTP cookie - Wikipedia)
からですね。
これに対してクッキーが導入されブラウザ(プロトコル)がステートフルになったわけですが、こいつがブラウザグローバル。
すなわち(URLでは区別されるが)ブラウザのウィンドウやタブ間で区別されないと言うことです。(IEには例外があるってほんと?)

これがユーザにどういう影響を及ぼすかと言うと、タブやウィンドウを複数開いても、異なる複数のGoogleアカウントのGmailを同時に読むことが出来ない、と言うことになります。

これに対して不満を持っている人も少なからずいるようです。

例に挙げたGmailの通知機能限定ですがFirefoxの有名なアドオンにtLo : Gmail Managerと言うのがあり、複数アカウントのGmailの着信通知や未読件数表示が可能です。
汎用的には、クッキーのセットをタブごとに変更できるアドオンにNektra.com > CookiePie FireFox/Flock/GNU IceWeasel Extensionがあります。(使ってみたところ今ひとつ安定しませんでしたが)
同時ではありませんが、クッキーのセットお手軽に切り替える類似目的のアドオンにCookieSwap :: Firefox Add-onsなんていうのもあります。
また、先の記事では否定されていたChromeですが、プライベートブラウジング(incognito)機能は、オープンな私と慎重な私で多重ログインする機能と見ることも出来ます。

まとめると、
Web/ブラウザが一人前のOSになるには、
複数のステートを管理出来ることが重要だが、
これにはブラウザ側が何らかの対処が必要で、
その一つの解がStainlessであり、
その他アドオンも複数あります、
ということのようです。

ところで、これはブラウザだけの問題ではなく、クライアントをクッキー(とSSLセッション)だけで区別しているプロトコルの問題でもあるように思います。
SSL通信路やCookieによる設定等の状態は共有したいが、案件毎にセッションを区別して管理したいとなると、とたんに破綻します(RESTfullに解決する方法はありそうだが)。

これに対して、WebのOS化に熱心なGoogleあたりが何かしてくるような気もしますが...

今後の動きに注目したいと思います。

# Webアプリ初心者への突っ込み歓迎

障害時の自動代替・修復は高度になるほど良い? (Gmail障害と改善方針について思うこと)

2009-03-01T00:05:00.001+09:00

先日Gmailに大規模な障害が発生したそうです。
各所でこれについて取り上げていますが、今回はGmailや今回の障害自体の話ではありません。

Googleから2/24にGoogle Appsユーザーに向けてレポートが出されました

Google Apps - Gmail Incident Report February 24, 2009

Additional Details
A few months ago, new software was implemented to optimize data center functionality to make more efficient use of Google's computing resources, as well as to achieve faster system performance for users.
Google's software is designed to allow maintenance work to be done in data centers without affecting users. User traffic thatcould potentially be impacted by a maintenance event is directed towards another instance of the service. On Tuesday, February 24, 2009, an unexpected service disruption occurred during a routine maintenance event in a data center. In this particular case, users were directed towards an alternate data center in preparation for the maintenance tasks, but the new software that optimizes the location of user data had the unexpected side effect of triggering a latent bug in the Gmail code. The bug caused the destination data center to become overloaded when users were directed to it, and which in turn caused multiple downstream overload conditions as user traffic was automatically shifted in response to the failures. Google engineers acted quickly to re-balance load across data centers to restore users' access. This process took some time to complete.

これによると、

数ヶ月前に、性能改善のために新しい地理的最適化ソフトウェアを導入した。
Googleのソフトウェアはメンテナンス時にもユーザの影響を回避するための他のデータセンタにリダイレクトされて代替される。
メンテナンス時に、新しいソフトウェアによる最適化の思わぬ副作用がGmailの潜在バグを顕在化させた。
Gmailの潜在バグによって代替先のデータセンタが過負荷になった。
これが更に後段の過負荷をもたらした。

ということのようです。

2の措置は今回の件とは関係なくずっと以前から行っていたと考えるのがGoogleの環境では自然でしょう。
1に関しては、「思わぬ副作用」とは行っているものの不良とは言っていません。
これに対して、3はGmailの潜在バグと明言しており、これを根本的原因と捕らえているようです。

まとめると、
「新しい最適化の思わぬ副作用がGmailの潜在不良を顕在化させ、Gmailの不良よる過負荷障害が連鎖的に拡大した。」
というところでしょうか。

これを聞いて、2003年北アメリカ大停電を思い出しました。
被害が拡大した原因には諸説あるものの、有力な説に送電管理システムのダウンにより連鎖反応を起こしたためというのがあります。

今回のGmailのケースはこれとそっくりではないでしょうか。

残念ながら、この教訓は今回は生かされなかったようですし、今後も生かされるかどうかが不安です。
というのも、先述のようにGoogleは根本原因をGmailの不良と捕らえ、さらには、基盤の自己修復機能を高度化することを良しとしているように思えるからです。

Googleは今回の問題に対する改善策として、

Given the risks associated with maintenance events, we understand that it's a traditional IT practice to limit maintenance events to weekends and evenings. This being said, Google's large distributed global infrastructure makes it impossible to mimic this traditional model because complex maintenance events cannot be completed to fit every user's off-hours. Our goal is therefore to innovate on the technology and process fronts to make our systems as self-healing and self-managing as possible. We feel that we run a very reliable system, but we also believe that there's always room for improvement. To that end, Google engineers work around the clock to make our productionsystems better.

グローバルなインフラであるGoogleは完全にオフラインの間にメンテナンスすることは不可能、と言うことを理由に、自己修復、自己管理技術を革新するとしています。

これには賛同しかねます。
北アメリカ大停電と同様に、今回のGmailの障害も自己修復が障害の連鎖を招き事態を悪化させたのだとしたら、自己修復、自己管理機能を強化することは逆効果かもしれないからです。
(それに、完全にオフラインは無理だとしても休日にすることはできるはずです。)

個人の経験から言える、HA(高可用性)システムのあるべき姿は、

自動代替メカニズムはシンプルに
自動代替はそれ自身でどこかに歯止を
緊急手動停止装置も

というものです。

今回の報道について、言いたいこともありますが、それは別の機会に。

FollowerとFriend Connectが統合!? (続報)

2009-02-27T22:58:00.015+09:00

BloggerのFollower機能にGoogle Friend Connectが統合のコメントにも書きましたが、Follower機能とFriend Connectが統合されたものの、フォロワーリスト(どちらも英語ではFollowersだったと思います)が統合されていません。

The Okano Mail: Followers has been migrated to Friend Connectでも報告されていました。

当初、googleaccount@gmail.comとhttp://cat-sushi.blogspot.comのようにOwnnerが違うのかとも思いましたが、同じActivityが表示されるし、理解できていません。

そのうち完全統合すると推測しますが、それ以前にどうしたらこんな不思議なな状態になるんでしょう??

ちなみに、この例では色と言語が違いますが、見た目も完全に同じで紛らわしくてしょうがありません。
そのおかげで、期せずしてThe Okano Mailのところで2重登録してしまいました。(^^)

やっぱり、Followersの方は出ないようにしておきます。

蛇足

Googleの公式ブログ(?)に統合の記事がありました。
Social Web Blog: Blogger and Google Friend Connect unite
現地時間26日7:05の投稿ですが、先のCat-sushiのポストの1時間前にリリースってこたないですよねぇ。後だしか!?

BloggerのFollower機能にGoogle Friend Connectが統合

2009-02-27T01:01:00.001+09:00

Google BloggerのにFollowers機能(購読者機能)というのがあり、他のBloggerベースのBlogをフォローすることができます。
フォローする(購読者になる)と、その記事をGoogle BloggerのDashboardで確認できたり、Google Readerの特殊な専用フォルダで確認できたりします。
また、逆にフォロされる(購読者が付く)とをフォロワー一覧をブログツールに表示したりすることができます。

今流行のGoogle Friend Connect等と重複するところが多い機能ですが、Google Blogger内に閉じていると言う難点があります。

他方で、Google Friend Connectはオープンで、どんなサイトでも採用できる反面、せっかく他サイト(Blog等)のメンバーになっても、そのサイトの更新のPush配信を受けることができないという難点がありました。
OpenSocialの機能を活用したアプリ(Gadget)を作成すれば可能なような気もしますが、少なくとも標準提供アプリではできません。

ところが、本日BloggerのDashboardに行くと、Google Friend Connectを採用し、自分が参加しているBlogの更新記事一覧が表示されていることに気付きました。

もしや、と思いGoogle Readerも確認したらこちらにも同様に表示されています。

これに関しては、国外のサイト、Blogger Buster: Blogger Followers now Integrated with Google Friend Connectでも紹介されていました。

これで、興味のあるサイトのGoogle Friend Connectに参加するモチベーションが格段にあがったように思います。
更新はReaderで確認し、気に入った更新があったら訪問してあしあとやコメントを残すといった使い方ができそうです。

次はコメント機能の統合でしょうか。

残念なのは、Google Bloggerユーザしか恩恵を被らないことです。
それでも、これに触発されてどなたかがOpenSocialアプリケーションを作成しそうですね。
# 自分は勉強中なのでまだ作れません、あしからず。

ところで、あし＠等には強力な競合が現れたことになります。
構築済みのソーシャルグラフはそう簡単にはGoogle Friend Connectに移行しないと思いますが...

OpenSocialってなに?

2009-02-22T22:01:00.007+09:00

OpenSocialが面白そうなので趣味として勉強中です。

今理解してる範囲では、

SNSとソーシャルアプリ(Gadget)のオープンなインタフェース仕様
既存のSNS内の人の繋がり(ソーシャルグラフ)を透過的、広域的に繋ぐものではない

ということ。(まだ良く分かっていないし、突っ込み歓迎です)

2に関しては、もともと「ソーシャルグラフを繋ぐもの」と勘違いしていたところもあり、正直少しがっかりしました。

勘違いの原因は、

グーグル、SNS向けAPI「OpenSocial」を発表:ニュース - CNET Japan
Googleの声明によると、この取り組みは「複数のソーシャルネットワークにアクセスできる初めての共通API」という。

と言う記事元のような気がします。
よく読むと確かに、「複数...同時にアクセスできる...」とは書いていないので、上記記事の問題ではありませが、ともかく勘違いでした。

したがって、OpenSocialによって結局ソーシャルグラフの覇権争いが解消されるはずもありません。

ソーシャルグラフの勢力図に関して、ちょうど2年前のものですが下記のスライドを見つけました。

Social Graph Platform War

View more presentations from Dave Mcclure. (tags: socialmedia flixster)

要素を減らしてシンプルにすると(無視したSNSさんごめんなさい)、

てな感じでしょうか。
# Googleが大きすぎのような気がしますが...

GoogleとMySpaceが微妙に重なっているのは、ソーシャルOSとして人気を博したFacebookに対する包囲網をOpenSocial連合で作っていると言う意味だと思います。

ところが、Googleが全てのWebサイトをソーシャル化する「Friend Connect」(Google，Webサイトをソーシャル化する「Friend Connect」をベータ公開：ITpro)を公開したことにより、Googleはもはやベン図の丸ではなく、潜在的に外枠のWeb全てになってしまったように思います。
もちろん、一足飛びには行かないので、Google色の濃さは少なくともはじめは薄いでしょうが...

つまりは、下図のようになり得るのでは？と、

さらには、Google，ソーシャル対応サービス「Friend Connect」にTwitterとの連携機能：ITproの様に、既にOpenSocialに賛同を表明しているMySpaceとのソーシャルグラフの相互運用がTender Surrender » オープンなコンタクトリスト仕様、Portable Contacts等の普及により始まると、

のようになると。

つまりは、Tender Surrender » 2009年のソーシャルウェブを占うにある、

GoogleがSNS化
以前にも書きましたが、Googleは着々とSNS化への準備を整えています。SNS化というと語弊があるかもしれません。SNSをプラットフォームとして取り込む、かな。
Google FriendConnectは対応サイトを手軽にSNS化できることが目玉のように言われていますが、僕はもっと違う狙いがあるものと思っています。仮に GoogleがiGoogleをOpenSocialコンテナ化した場合、当然友達リストはGmailのアドレス帳が筆頭になる訳ですが、実は Google FriendConnectで接続したアカウントもその候補なのではないか、とにらんでいます。
もしそうなった場合、複数のSNSに参加している人のアカウントはすべてGoogleに束ねられることになり、他の追随を全く許さない状況になってしまうのではないでしょうか。
(実はGoogleの人にこのことについて聞いたことがあるのですが、そんなevilなことしないよ〜と言ってました)

# ボールドはCat-sushiによる

「複数のSNSに参加している人のアカウントはすべてGoogleに束ねられる」と同じことを言っているのかと思います。

少なくともGoogleの一人の社員はこれを"邪悪"とした上で、そんなことはしないと言っているわけですが、ソーシャルネットワークサービス間の友達リスト交換(Tender Surrender » オープンなコンタクトリスト仕様、Portable Contacts)のようなことになれば、その流れは止められないでしょう。

結局、OpenSocialを実装したGoogle Friend Connectのようなものが、「既存のSNS内の人の繋がり(ソーシャルグラフ)を透過的、広域的に繋ぐもの」に限りなく近い何かになるのでは、と言う話でした。

参考サイト

ソーシャルグラフとは何か？エッジとノードから考える:マーケティング - CNET Japan
グーグル、ウェブからソーシャルグラフの情報を集め、APIを公開
Googleの野心的「OpenSocial」APIの詳細判明―木曜日にローンチへ
Google，ソーシャル対応サービス「Friend Connect」にTwitterとの連携機能：ITpro
Tender Surrender » 2009年のソーシャルウェブを占う
Tender Surrender » オープンなコンタクトリスト仕様、Portable Contacts
Social Graph API - Google Code

あしあと機能を設置しました (Google Friend Connect編)

2009-02-20T23:30:00.000+09:00

こちらで紹介しましたGoogle Friend Connectは、SNSではなく、Blogを含む一般サイトをソーシャル化するものですが、OpenSocialのコンテナ(?)でもあります。

オープンとはソーシャルアプリケーションを誰でも作れる、と言うことのようです。
(他にもオープンの意味がありそうですが。)

と言うことは、きっとだれかが「あしあと機能」とか作っているだろうと思ってあたってみたところ、ありました。

Eiji KitamuraさんがFriendConnect向けあしあとガジェット公開とコード解説にて、ご自身で実装した「あしあと機能」を公開していました。

これがそれです。

恥ずかしかったら、あしあとを削除するボタン(リンク)もあります。

なお、Google Friend Connectを採用している個々のサイトが独立した(?)ソーシャルサイトなので、それぞれにログインしていないと「あしあと」は残せません。
その辺は「あし＠」とかと違いますのであしからず。

Yahoo!が毎日クローリング!...あれ?

2009-02-17T19:13:00.043+09:00

いままでずーと本ブログが嫌われてきたYahoo!ですが、最近毎日のように何ページもクロールしてくれます。

そう、米Yahoo!のことです。

Yahoo! Japanといえば、

だそうです。
はて、最終クロール日時=(UTC)ってどういう意味でしょうか?
もう何日もこんな感じです。

理解できないのは日付表示のみにあらず。
本ブログはYahoo!の強い日本語市場にあって、Yahoo! Japan経由の訪問は相変わらずGoogle経由の3%程度です。

それもそのはず、キャッシュは

だそうですし、
site:cat-sushi.blogspot.comでインデクスを探っても、1/31が最新記事でした。

もう、手動でフィードを再送信するとか言う話でもありません。

また、一時は米Yahoo!に拾われた後に、追随するようにYahoo! Japanに反映されていたのですが、日米の状況から推測するに、それも期待できない状況です。

クロールアルゴリズムが異なると推測されるブログ検索でも、

2件、ですか。

以上、事実をなるべく淡々と述べていますが、これ以上語ると... (^^;

Google Friend ConnectのSocial barを導入 (BloggerのNavbarの位置も修正)

2009-02-15T00:34:00.003+09:00

Google Friend Connectを導入してみましたで導入したGoogle Friend Connectですが、昨日Social barというツールバータイプの統合ガジェットが公開されたので導入してみました。

Google，「Friend Connect」のツールバーを提供：ITpro 他でも紹介されています。

結果はこれです。

コンパクトに機能がまとまっている点が良い感じです。

また、Friend Connectではコメントをページごとに書けるように設定できますが、そうするとブログ全体のコメント一覧を見ることができないという欠点があります。(管理者は見れるんですが)
その場合も、真ん中の一番広い部分をクリックすると、コメントを含むメンバのアクティビティが表示されるのである程度代替になりそうです。

ところで、Social barを本ブログのようなGoogle Bloggerに導入すると一部で不都合があります。
Navbarと呼ばれるこの↓部分とブログのヘッダの一部がSocial Barによって隠れてしまうのでます。

NavbarはBloggerのテンプレートをみても該当する部分が無く、直感的にはいじりようがありません。

しかし、FirebugやHTMLソースで調べてみると、Navbarは
<div id="navbar" class="navbar section">
であることがわかりますので、CSSとして、

#navbar {
margin: 40px 0 0 0;
}

を加えることで下にずらすことができます。

ついでに、よりツールバーっぽく見えるよう、Social barを最上部に固定(常駐)することにしました。

Social bar導入のためのスニペットを見ると、

<div id="div-1234622588636"></div>

という記述があるので、 id="div-1234622588636のdivをいじればよさそうです。

#div-1234622588636 {
position: fixed;
width: 100%;
top: 0;
left: 0
}

を加えることで固定できました。

結果はこれです。

どうでしょうか?

ちなみに、CSSの知識が無かったので、
とほほのスタイルシート入門（基礎知識）
や
CSSレイアウト実践講座
を参考にさせてもらいました。

Googleが邪悪に? 日本法人がPay Per Postキャンペーンを実施

2009-02-12T23:08:00.002+09:00

Googleはこれまで、セキュリティ、特にプライバシーと可用性において少なからずポカをやったり、前者(プライバシー)では意図的とも思える天然の鈍感っぷりを発揮したりしてきました。
# ちなみに、鈍感力 - Wikipediaは2007ユーキャン新語・流行語大賞でした。

しかし、「邪悪になるな(Don't be evil)」という変わった理念を掲げる同社は、個人的にはその理念通り極めて真っ当な組織であるように思います。
一種、ネット界で、いやそれ以外でも神で有り続けたいとしているように思えさえします。

もっとも、その巨大さゆえのアンチの存在や、扱う問題が巨大であるゆえの完全性の欠如や、立場の違いによる反論も相当に有るようで、「Google 邪悪」でググると、「Googleは邪悪である」という意見の方が多いようです(あえて発言をする母集団の中では)。

しかし、今回のPay Per Postキャンペーンの問題は、少しこれらの反論とは異なるように思いました。

Google Japan Blog: Google のマーケティング活動について

Google自身が「邪悪」と認識し、対策に躍起になっている検索スパム行為を自ら行ったと言う事実は、アンチや不完全性や立場の違いとは一線を隔したものと感じます。

いったい、どうしたんでしょうGoogleさん。

Googleファンとしてはとっても残念です。

今回の件はGoogleも反省しているようで(?)、
自身にPageRankペナルティを課しているようです(!?)。
しかし、
YahooでGoogleをググっても(PageRank関係ないし)、Google Japanがトップ、
GoogleでGoogleをググっても(ナンセンスだし)、Google Japanがトップ、
でした。
# ペナルティ意味ねー!

さて、今回は、Google Japanのトップページ変更に関するプロモーションでの出来事でしたが、Google Japan Blogの先のポストの直前のポストが、

Google Japan Blog: Google Japan の新しいホームページ　Version 2

でした。
この改変によって、Google Japanの検索トップページはますます高機能になりましたが、検索に特化したシンプルさを美徳とするUS本家のページとは対照的です。

日本　　　　　　　　　　　　　US

日本ほどではないですが、韓国、中国等も高機能なページになっています。

韓国　　　　　　　　　　　　　中国

# あれ、何かのお祭り？それに、中国はGmail無いの?

グローバル企業のGoogleと言えども、理念や、ポリシーまでは現地法人には伝わりきれない、ってことでしょうか...

そういえば、中国に関しては、米Google、中国政府による検閲の受け入れを公表なんてのも有名ですね。

しっかりしてくださいよ、Googleさん!

IE8自動更新はMSの手違い? →BetaはRCに自動更新

2009-02-03T21:25:00.068+09:00

先日 IE8に自動更新されました。 (本ブログは崩壊!)で自動更新によりIE8を入れました、と言ったのですが、いっこうに正式リリースのニュースが流れてきません。
心配になって、今バージョンを確認してみると、導入されたIE8はRC版でした。

狐につままれたような気分です。

一瞬、自分の意思でダウンロードした?と自分を疑ってしまいました。

しかし、タスクトレイに「更新があります」アイコンがあったのでOSセキュリティ対策だと思いクリックした結果「IE8」だったので、「あぁ、IE8リリースされたのね」と思った覚えがあるので自動アップデートに間違いありません。

とっくんブログ:【Update】Internet Explorer 8 beta→Release Candidate 1 - livedoor Blog（ブログ）

でも

# Windowsの自動更新経由でUpdateしました。

と言っているので私一人でもないようです。

しかし、RCなので当然ですが、

Internet Explorer 8 の自動更新による展開は、2009 年に予定される Internet Explorer 8 の正式リリース後に行われる予定です。

となっており、まだ自動更新はされてはいけないはずです。

~~おそらく今回のIE8の自動アップデートはMSの手違いでしょう。~~
~~だれか他に自動更新された方いますか～~~
正式版かと思ったら、Betaの人向けにRCを自動更新しているようです。

# 正式リリース版でブログが壊れているのを確認するまで何もしなーい

追記:

ベータ版をインストールしている人には自動更新が来るらしいです(未確認情報、とっくんさんはこのパターン)。
でも、インストールしていない、と思う(うろ覚え) 。

追記2:

MSが勇み足すぎる。
MSのトップページからダウンロードタブを選ぶとIE8 Beta(なぜ?)の宣伝入りページが開きます。

ここで、IE7のダウンロードページへのリンクをクリックすると。

IE8のダウンロード?
でも、下のほうにはIE7の使いやすさ、なんていう説明が...

さらに、ダウンロードボタンを押すと、
http://www.microsoft.com/japan/windows/products/winfamily/ie/beta/downloadlist.mspx
なページに飛ばされます。

しかし、ぱっと見正式版ページにしか見えません。
下の方に製品候補版に関する注意事項があったり、バナー部分にマウスカーソルを合わせると製品候補版の文字がバルーンとして現れたりはしますが、

「迷宮へようこそ!」って感じです。

こんな調子で自動更新流したのでは、と疑ってしまいました。
(うろ覚えを棚に上げています、念のため)

追記3:

うろ覚えでしたが、IE8 Betaをインストールしていたようです。
Faviconが表示されない Part 5 (全て解決)でもIE7といっていますが、良く見るとIE8のインタフェースですね。

MSさん失礼しました。

3/9追記

少し前になりますが、XHTMLとCSSを勉強して修復しました。
IE8でも見れるはずです。

Google mail (Gmail)でオフライン機能 (でもAndroid入手まで使わない)

2009-02-01T18:56:00.073+09:00

Google mail (Gmail)でオフライン機能が公開されたことが各種ニュースやブログで一斉に報告されて、ある種のお祭り状態です。
新機能が英語版から提供されるのを見越して、それだけのために英語モードにしている甲斐があり、今回も早々と利用できました。

で、その感想は、「ふーん」です。

モバイル環境を持っていないので、そのありがたみを実感できないというのが正直なところです。

Google Mania - グーグルの便利な使い方さんのGmailのオフライン機能が便利な理由ベスト５でオフラインが便利な理由を紹介していますが、私には残念ながらどれも響きませんでした。

５．Goolge Appsでも利用可能！

残念、個人ユーザでした。

４．ショートカットアイコン

へっ? これ↓を作ってくれることが本当にうれしいの?
"C:\Program Files\Mozilla Firefox\firefox.exe" https://mail.google.com/mail/

３．シンクロ対象範囲
２．添付ファイルまでシンクロ

問題はこれ。
添付ファイルもありがたいのだけれど、インラインイメージを展開して欲しい。
自分が学生だった20年ほど前、メールは受信者が困らないようプレーンテキストで送信するのが一種の美学だった時代がありました。
しかし、時代は変わって、HTML形式のメールが当たり前になってくると、Flaky Connection Modeだからという理由で、イメージが見れないのでは、ありがたさ半減です。

イメージがメッセージデータ容量の大部分を占めるケースはまれではないでしょうから、イメージのダウンロード優先度を下げるのは歓迎ですが、完全シンクロ後もFlaky Connection Modeではイメージが見れないのは何とかしてもらいたいものです。

同じ理由で、Google Readerのオフラインモードもまだ使う気になれません。

１．ネット接続が不安定な場所でも活躍

自宅ADSL環境だとちっともありがたみが...

やっぱり、Android入手後に欲しくなる機能なんだろうな、と思いました。

ところで、日本の事業者はいつAndroid携帯を出してくれるんでしょうか?

IE8 RCに自動更新されました。 (本ブログは崩壊!)

2009-01-31T18:26:00.065+09:00

Ineternet Explorer 8のリリース候補が米国時間1月26日に公開されてから5日も経っていませんが、Windows Updateで自動更新が行われました。

お得意のOSリブート2回を経て無事インストール完了。
IE7のまま?と勘違いするほど見た目の変更はありません。
結局IE8 Betaからのアップデートだったわけですが、それでもIE７ともそっくりです。

そして、目玉である性能向上と標準準拠による互換性向上に期待を寄せ使ってみました。

本ブログを表示すると...

これは、壊滅的に崩壊していますねぇ。

原因として考えられるのは、

このブログのカスタムテンプレートが標準に準拠していない
IE8の互換性が一部でデグレードしている
IE8の単なる初期不良

blogspot.comを利用するGoogle Bloggerは最上部のNavbarと呼ばれるところの[次のブログ]で、ブログサーフィンできますが、これで巡回する限りBloggerのブログでもフォーマットが崩壊しているものは見あたらなそうです。

ということは1か?
でも、FirefoxでもSafariでも~~IE7~~IE8 BetaでもChromeでも大丈夫だったものが、なぜIE8 RCだけで崩壊したんでしょうか?

さて、CSSとか最近ちょっとかじっただけだし、Bloggerテンプレートのフォーマット理解していないし、どうしましょう。
実績のありそうな3カラムテンプレートを拾いなおそうか...

2/2追記

本ポストから丸2日経ちましたが、正式リリースの声は聞きません。
Google Newsで[IE]や[Internet Explorer]で検索して日付順にソートしても一向に...
もしかして、誰かに釣られたんでしょうか??

2/3追記

IE8自動更新はMSの手違い? →BetaはRCに自動更新にも書きましたが、RCでした。
Betaをインストールしている人を対象にRCに自動更新するようです。
そして、IE７と信じていたのはIE8 Beta(2?)でした。

2/18追記

崩壊していたのは、本ブログのカスタムテンプレートが壊れていたからでした。
よくFirefox、Chrome、Safariで同様に表示できた門です。
いまはIE8 RC1でもちゃんと見れます。

FeedBurnerのFeedFlareのComments Count (Blogger)が動作開始!?

2009-01-25T14:13:00.002+09:00

FeedBurnerを利用していますが、そこでFeedFlareという機能を利用して、配信するフィードにAdSenseやら、ブックマークショートカットやらを表示しています。

その中で、AdSenseに並んで重要と思っている機能、Comments Count (Blogger)がようやく使えるようになりました。

Comments Countとはフィード内にブログポストへのコメント数の表示をしてくれて、クリックするとブログコメントフォームへ誘導してくれる機能です。
フィードリーダーでまとめてブログを購読している人にも気楽にコメントしてもらえる便利な機能です。

当初、WordPress専用のComments Countという機能でしたが、FeedBurnerがGoogleに買収されてまもなくBlogger版が登場して使えるようになった、はずでした。

いつも参考にさせていただいているサイトクリボウの Blogger Tipsでは、昨年の5月に紹介されています。

FeedBurner に FeedFlare 「Comments Count (Blogger)」が登場

ところが、本ブログのフィードではなぜかComments Countが表示されていませんでした。

今確認しても、1/21の記事までは↑な感じです。
feedburner.comやfeedburner.jpではなく、フライングでfeedproxy.google.comを使っていたことや、Bloggerのカスタムテンプレートを利用しているのにも関係しているかと思い、いつか調べようと放っていました。
# 後者のHTMLの話は本当はフィードには関係ないと思いつつ...

それにしても、「◆Twit This!」の直前の微妙なスペース(インデントみたいなやつ)は怪しすぎです。

ところが、今日確認すると、

先頭に「◆Post a comment」の文字が!
直後の1/24の2つの記事から付いていました。

さて、この間やったことと言えば、ポストと統計情報の確認のみ。
設定の変更は一切行っていません。

一部のブログだけとは思いますが、Comments Countが表示されない不具合がBloggerかFeedBurnerのいずれかのサーバ側にあったようです。

ちなみに、コメントをすると少しのタイムラグの後、文字通りコメント数の表示に変わりました。

追記

「今確認しても表示されていない」のは、Google Readerのキャッシュでした。
まぁ、表示されていなかった証拠には変わりありませんが...
そのうちキャッシュも更新されるものと...

追記2

そういえば、以前にFeedFlareのBloggerのコメントカウントはCaptchaを無効にしておかないと表示されない?でこの話題を取り上げていました。
コメントのCaptchaは関係なさそうですね。

Googleがまたfaviconを変更 (変えすぎ)

2009-01-11T13:41:00.004+09:00

Googleがまたfaviconを変えたようです。

前回もそう思ったのですが、当初はGoogleお得意の洒落かと思っていました。
しかし、

Official Google Blog: Google's new favicon

によるとどうやら本気のようです。

前回の変更があまりにシンプルなデザインであったので再度Googleらしい色使いのものに変更したかったのでしょう。

先のブログに、「気に入ってもらえるといいな」と書いてありますが結構このアイコンはお気に入りです。

しかし、ブランドのシンボルをそうちょくちょく変更するのもいかがなものかと。
タブやブックマークで一瞬にしてそれであることを判断しているのに、変更直後はそれができません。

トップページのロゴ

がほとんど変更されないのに、どうしてfaviconだけ、なんでしょうねぇ?

個人的には、もう変えないで欲しいものです。

カテゴリタグ&フィード導入しました

2008-12-28T13:35:00.000+09:00

本ブログは、徒然なるままに、とは言ったものの、あまりにも統一感が無くなってきました。

対策として、ブログを分割することも考えたのですが、アクセスの少ないブログを分割しても、管理する対象が増えるだけで、何も良いことがなさそうです。

と言うことで、本ブログにカテゴリタグ(ラベル)と、カテゴリ別のフィードを導入しました。

カテゴリとして用意したのは、これまでのポストの傾向から、

Gardening
主に、ハイドロカルチャー関連
Photo
未熟ながら、Nikon D70他を用いた写真作品&カメラネタを
Social
ソーシャルメディアおよび社会的話題全般を
そのうち両者を分けるかも
IT
IT関連ネタを
特にネット系を

です。

この目的で、カテゴリ用として、「:Gardening」...というタグ(ラベル)を作成しました。

そして、カテゴリラベル対応のフィードをそれぞれ手動でFeedburnerして、これをオートディスカバリさせました。

カテゴリで絞り込んだ画面で自動的にカテゴリのフィードのみをオートディスカバリさせればかっこいいのですが、そんな技術力はありません。

また、カテゴリへで絞り込んだ結果へのリンクと、FeedBurnerのフィードへのリンクも用意しました。

以上です。

ところで、ラベル用フィードをFeedBurnerにリダイレクトできないか、という問い合わせをコメントでいただきました。

リダイレクトはサーバ側がHTTPのステータスコード「302 Moved Temporarily」を返すことによって実現されています。
しかし、Google Bloggerのサーバ側に設定できるのはメインフィードのリダイレクトのみなので、ラベル毎のフィードのフォワードは無理のようです。

この辺りは、クリボウの Blogger Tips: Blogger から FeedBurner へのリダイレクトが可能にが詳しいです。

本ブログでは、メインフィードはリダイレクトしていますが、カテゴリ毎のフィードはFeedBurnerのものを直接オートディスカバリさせています。
新規のフィードですし、FeedBurnerもGoogleの公式サービスですし、私にはこれで十分です。

任意のラベルをFeedBurnしたい場合には、これでは事足りませんね。

ブログタイトル変更 Cat-sushi日記→Cat-sushi Log

2008-12-27T00:19:00.006+09:00

ブログのタイトルを「Cat-sushi日記」から「Cat-sushi Log」に変更しました。

理由は、

毎日書くわけでもないし、
完全に個人的なことを書くつもりもない
だから日記じゃない

と言ったところです。

ところで、一般にブログのタイトルを変えるのはあまりお勧めしません。

お勧めしない理由は、

過去のポストを含めてタイトルが変わってしまう
それに伴いanalytics等の統計の集計も別対象として扱われてしまう
Google、Yahoo等のサイト評価にも影響するかも
Picasaアルバム名も変更になる (リンクを貼り付けたエントリも変更が必要)
フィードバナーのフィードタイトルを変更したくなる
AdSenseの広告のタイトルを変更したくなる
あし＠登録のブログ名を変更したくなる
にほんブログ村登録のブログ名を変更したくなる

です。

あし＠クライアント機能障害?

2008-12-21T22:01:00.000+09:00

今日は夜から「あし＠」のクライアント機能がうまく動いていないみたいです。
本ブログやいつも訪問するあし＠仲間のページで、あし＠クライアントが表示されなかったり、表示されても機能しなかったりしています。

あし＠のサイトに行くと普通に動いているので、
おそらくJavaScriptとcookieを使ってブラウザとサーバとでやり取りする部分で何らかの障害が起きているんでしょう。

ちなみに、こんな記事はブログに書くような内容じゃないと思い、
はじめたばかりのTwitterに書き込んでみましたが、
あし＠関係のつぶやきがほとんど無いので普及していない、またはユーザ層に共通性がないく、
加えて自分がまだTwitterで孤立しているので誰も反応しなさそう、
ということでこちらにポストです。

何かわかったらまとめエントリをポストして本エントリは消すかも。

12/22 0時8分追記

早速直りました。
メンテナンスでもあったんでしょうか...

12/23 0時25分追記

一時的障害があったようです。

あしあっと事務局です。

お問合せについてですが、21日19時～23時の間、
一部サーバーの不具合があり、足跡クライアントが表示されない、
また、アクセスに遅延等が発生しておりました。
現在は、復旧しております。
ご迷惑お掛けしました事、誠に申し訳ございませんでした。

今後もあし＠を宜しくお願い致します。

-----
あしあっと事務局

今はすっかり直っています。

3/8 追記

一度消しておりましたが、迷子リンクが気持ち悪いので復活しました。

Faviconが表示されない Part 5 (全て解決)

2008-12-18T18:08:00.004+09:00

Faviconが表示されない Part 4 (かなり改善)で「それでは、本テーマはこの辺で。」と言ったにもかかわらず、続報です。

~~IE7~~IE8 Betaはその後の確認では、一度は表示されたはずのタブとアドレスバーがIEのアイコンに戻っていて、お気に入りのアイテムにだけカスタムFaviconが表示されていました。

さすがに、IEで表示されないのはちょっと、と思っていじっていたら、結局、Firefox 3.0、Chrome 1.0、Safari 3.1.1、~~IE7~~IE8 Betaで全て問題なく表示されました。

やったことは、

<head>

内の

<b:include data='blog' name='all-head-content'/>

より前を極力シンプルにし(具体的にはGoogle Webmaster Toolsと日米Yahoo! Site Explorerの認証メタタグのみ)、
Faviconの<link>タグのうちicoのもの

<link href='http://xth8aa.bay.livefilestore.com/y1pJPNQ75GxoCcD-dG0ysFMGsZU9vdIELY7h3QkAjEIFatDJM2iiRmXZKLC3rPhXXWisEAjKieq250/Cat-sushi.ico' rel='shortcut icon'/>
<link href='http://xth8aa.bay.livefilestore.com/y1pJPNQ75GxoCcD-dG0ysFMGsZU9vdIELY7h3QkAjEIFatDJM2iiRmXZKLC3rPhXXWisEAjKieq250/Cat-sushi.ico' rel='icon' type='image/vnd.microsoft.icon'/>

を

<b:include data='blog' name='all-head-content'/>

の直後に埋め込んだ、
以上です。

結局pngは使っていません。
複数箇所に重複して指定もしていません。

できてしまえばあっけないもんです。

結論として言えることは、

タグは上書きであり後出が有効
でも、全部パースしないから極力前方に置くべし
all-head-contentにはBloggerのデフォルトFaviconの<link>があるからカスタムFaviconはその後ろに置け
pngタイプFaviconは互換性がいまいち(?)

と言ったところです。