Twitter 社がTwitter登録商標の利用ガイドラインを公開した。

つぶやきメッセージのことは「ツイート」と表現してください。

引用元: Twitterヘルプ: Twitter登録商標の利用ガイドライン.

また、Twitter の未来について堀江氏が次の様に書いていた。

eメール並みに長生きする可能性は十分ある。

引用元: 堀さんがtwitterに関する面白い記事を書いてたので突っ込みなど｜堀江貴文オフィシャルブログ「六本木で働いていた元社長のアメブロ」by Ameba.

某巨大掲示板と同じ感覚で「もう Twitter に人が来なければ良いのに」という発言を見かけることがある。しかし “ツイート” を “メール” に置き換えて考えると「もう Gmail に〜（ry」となるが、逆にそのような発言をする人は皆無に近いし、同じ様な事が電話にも言えると思う。適当に番号を押せば誰かに繫がって話す事は容易だという点でもツイートもメールもテレフォンも変わりが無い。

パソコン通信からブログ、SNS、ツイッターと進化（退化）したように次の波が来る

引用元: ■グロービス堀義人ブログ: ■ツイッター7つの仮説.

先述の引用した記事を遡って読むと比較対象の条件が利用者側の意思疎通という点に絞っているようだが、Twitter が整備された API を公開している技術的な側面において電子メールが RFC (Request for Comments) に沿った技術仕様を持つように、呟きが郵便や電話と同等に（梅田氏の言葉を借りると）公共のシステムとして使われて行く可能性は十分にある。ただ一つ問題があるとすれば無料サービス故に収益面に不安があって、Google Buzz に駆逐されるのではという懸念がある。そこはメールの様に仕様を共通にして UI で競争するということにすれば良いと思うのだが、主導権争いの状況ではどうなるのかは不透明だ。

加えて、もしそうなれば呟きというシステム／サービスがデジタルの世界から確立されていくことはとても興味深いことで、同年代の友人にいくら勧めても（iPhone を使っていても）未だメールだったり、初老の方は（PC を持っていても）電話だったりするけれど、重要なのは相手によって使う道具を選択できる自由があることだと思う。

注釈：同期的に掛け手の意思を押し付けるという点でチャットは電話を凌駕することはなく、代わりにメールの持つ非同期性をうまく汲み取ったのがツイートだと考えているので、ここでチャットは度外視した。

iPhone アプリで利用している SQLite のスキーマを変更する必要に迫られ開発中に予期せぬ出来事があった。具体的にはテーブルに一列追加する changeVersion という関数を利用する際に必ずバージョンがマッチしないというエラーを出力するというものだ。

success callback である第五引数内でもoj.versionがoldVersionを返すのが気になります、、、。リロードするとようやくnewVersionに変わるんですけれど、これで良いのかなぁ。

引用元: JavaScript++かも日記: 【iPhone】iPhone用 JavaScriptデータベースプログラミング入門 (6).

Safari の JavaScript のデバッガでこの問題を確認し回避策を模索していたところ、Apple の文書に次のような回答を見つけた。

Unfortunately, the only way for your code to see the new version number is by closing the browser window. If you get an error code 2 (see “Error Codes”) and the database version you passed in for the old version matches the version in db.version, you should either assume that the version change already happened or display an alert instructing the user to close and reopen the browser window.

引用元: Safari Dev Center: Safari Client-Side Storage and Offline Applications Programming Guide: Using the JavaScript Database.

結局のところ挙動は問題ないのだけど、ブラウザを閉じるか再読み込みしないと利用者に反映されないということで、次のようなコードにして iPhone の UIWebView 用に移植する前段階として一旦作業を終えることにした。

try {
  if (window.openDatabase) {
  // db = openDatabase("BackgammonPositionsDB", "1.0", "Backgammon Positions DB", 200000); /* 現行バージョンの記述 */
  db = openDatabase("BackgammonPositionsDB", "2.0", "Backgammon Positions DB", 200000);
  （2.0バージョンは開けずエラーをキャッチするので通常の処理は省略）
} catch(e) {
  if (e.code == DOMException.INVALID_STATE_ERR) { // Version number mismatch.
    var prevdb = openDatabase("BackgammonPositionsDB", "1.0", "Backgammon Positions DB", 200000);
    prevdb.changeVersion("1.0","2.0", 
      function(tx){
        tx.executeSql('ALTER TABLE BGPositions ADD COLUMN crawford INTEGER default 0;VACUUM;');}, 
        function(error){ /* SQLエラー処理 */ }, 
        function(){ /* 成功後初期化処理 */ });
    return;
  }
  alert("Unknown error " + e + ".");
}

またこの検証作業に関して SQLite のバージョンを戻す（1.0 に下げる）必要があり、前述した Apple の文書にもある ~/Library/Safari/Databases/ にあるファイルを削除して Safari を再起動するという若干面倒な手続きを取るしか方法がないので、Rails のような管理手法を Automator や AppleScript で作ることが望ましい気がした。

実際の iPhone 上の UIWevView ではどのような挙動になるのか、悩ましいことになるようであれば追って報告しようと思う。