このところすっかり Apple / iPhone ネタばかりで、明後日にも iPhone 3GS が発売となるが、昨年徹夜して並んだ組には機種変更の負担が大きいので諦めている。注目はするが指をくわえて横目で見ていることに決めた。
2009年7月22日 皆既日食の情報 （国立天文台）
というわけでスケールの大きい話題。1ヶ月足らず後に、日本全域で日食を見られるそうだ。東京では9時55分から12時30分に掛けて、最大 74%の部分日食となる。
静岡で、1997年3月9日に部分日食を見たときは、フィルムの黒い部分を何枚も重ねて観察できた。昼間なのに空がオレンジ色になり、とても不思議な光景だった。
ただし、国立天文台のページによるとフィルムの端を使ってはいけないらしい。もうフィルムカメラもフィルムも持ってないけど。
次の日食は26年後。世紀の天文イベントに向かって何か準備するか。
Twitter の TL を眺めていたら大変なことになっていたようだが、日本時間の 6/18 2:09 あたりから 3.0 のダウンロードが解禁された。3.0 自体は数ヶ月前にアナウンス済みだったこともあり注目されていたようだ。
日本の普通の携帯では、リリース済みの携帯のファームウェアの更新など、不具合対応にしか使われない。購入前に気づかなかった使いにくさやわかりにくい仕様、微妙な不具合などは対応されずに製品寿命を迎えることになる。
iPhone の場合は2年前に発売された初代 iPhone から昨年の iPhone 3G, そしてもうすぐ発売の iPhone 3G S まで、同じバージョンの OS に無料でアップグレードできる。大変ありがたいことだ。2年くらいのソフトウエア保守がついてるようなものだ。購入時のコストや通信料の高さだけが取りざたされるが、半年も経つと物理的に使えないサービスを登場させ、無駄な買い換えを煽る日本の携帯業界はちゃんと見習って欲しい。かつて互換性のない 8bit マイコンが乱立し、日本独自の 98 とかいう互換性を微妙になくしていく規格で囲い込まれ、最終的に AT 互換機に流れをさらわれたことを思い出す。
さて、3.0 で追加された機能で個人的に嬉しいのは MMS かな。去年、かみさんをディズニー携帯 (SoftBank) にして家族割を組んだものの、携帯でいうところの Eメール、SoftBank でいうところの S! メール は iPhone が未対応だったため、「ただ友」にならなかった。iPhone 側は定額 MAX が当たり前だったので気にならないが、普通の携帯はそこまで行かないので SoftBank 同士メールが無料 (ホワイトプラン) がとてもありがたい。そして携帯と同じ @softbank.ne.jp アドレスの取得ができるようになった。
MMS は、SMS の通知をトリガーにして端末側がサーバにメッセージを取りに行く規格なので、Apple の Push Notification Service とは無関係にリアルタイム着信できる。これでようやく写真付きメールが SoftBank 同士無料、着信通知付きで使えるようになった。ただ残念ながら着信メロディはデフォルトの中からしか選択できないので、特定の相手からの着信音を変えるといった設定はできない。日本だけなのか、ここにこだわってるのは。
3.0 ファームウェア自体は、手元の iPhone および iPod touch 共にアップデートできた。所要時間 20分程度。1時間コースという情報もあったが、事前に動画等を削っておいたのがよかったのかもしれない。
今朝から 3.0 対応のアプリケーションアップデートラッシュが始まったようだが、iTunes のサーバが混んでいてエラーが発生する。
候補までは表示されるが、ダウンロードサーバがパンク気味なのかもしれない。しばらく待つしかなさそうだ。
Update: 各クライアントも細かく障害が出ていたようで、続々と対応バージョンがリリース。
昨晩書いた Twitpocalypse 問題。今朝 (6/13) 9:00 の段階では既に臨界点を越えていた。いろいろクライアントを試してみた。
一番使っていたクライアントだけが使えなくなったのががっくり。
ついでに、いろいろ試していたら、Twitter の時間あたりの取得制限にひっかかって全く読めなくなった orz
という記事が公開されている。なんでも Twitter メッセージの ID が 32bit 符号付き整数 (32bit signed int) で解釈された場合、この週末あたりで
2,147,483,647 (= 01111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111)
を越えて負の値になってしまうそうだ。 現在の ID をカウントするサイト
が末期的雰囲気を醸し出している。一部では Twitter が崩壊するぐらいの勢いで噂されている。
‥‥が、どうもおかしい。本当に致命的な不具合だったら本家サイトで何らかの大がかりなアナウンスがあってもよいように思える。そこで、本当のところどうなのか少し調べてみた。
データが化けそうな（丸めや変換による劣化が起きそうな）ポイントとしては大きく3つに分けられる。
このうち、Twitter 側サーバ内の ID の取り扱いについては以下のような明快な回答が公開されている。
http://twitter.com/twitterapi/status/2048659057
Valid points by @cwichura& @ NickMoline: we’re using a unsigned 64-bit bigint internally to store status_ids. You should, too. ^DW
(我々は status_ids の格納に、内部的に 符号なし 64bit 整数を使っている)
従って、Twitter サーバ側では既に対処済みである。Twitter の Web サイトのみを使っている場合はおそらく大丈夫。
次に、サーバから送られる Twitter のフォーマットについては、次の資料を見ていけばわかる。
Twitter サーバのデータフォーマットは xml, json, rss, atom の4つの形式から選択できる。いずれもテキストフォーマットであり、バイナリを含まないため、フォーマット自体には桁あふれや解釈の違いによるデータ化けは原理的に発生しない。
Twitpocalypse のサイトで指摘しているのは、３つめのクライアント側の処理である。API では変数の bit 長や最大値、型は指定されていないので、クライアント側で十分大きい値を受けられる変数に格納できているかで勝負が決まる。またはパーサの仕様により全ての数値を読み取られるようになっているか。
32bit 符号付き整数型 (C言語でいうところの signed long int) で格納した場合、2,147,483,647 に 1 を足すとオーバーフローを起こして -2,147,483,648 となる。前回読んだつぶやきから最新のつぶやきまでを表示するというタイムラインの処理の場合、前回の つぶやき ID を保存しておいて、ダウンロードしたつぶやき ID と比較する処理を行うはず。負の値になると上下が逆転するのでそれ以降のつぶやきは表示されないかもしれない。
また、Reply を送信する場合、相手のつぶやき ID を in_reply_to_status_id に格納して送信する仕様になっているが、Twitter クライアントが負の値で文字列にしてしまうと、サーバ側で ID と異なる数値を受け取るので、受け取ってもらえないかエラーになる可能性がある。
さて、手元には何種類もの Twitter クライアントがある。Mac 用には Tweetie, Twitterific, iPhone 用は Twitterfon, Twittelator Pro, Tweetie, Twitterific Premium, Fasttweet。Adobe AIR アプリの TweetDeck もある。
今のところ、6/13(土) の日本時間 16:30 ごろに 2,147,483,647 を越える見込み。どのクライアントが生き残るのか、直前にアップデートされるのか、全滅なのか、実は全く問題がないのか。注目していよう。
iPhone3GSを追加で買ってきた時の月々の支払の一覧を作ってみた。
という記事を見つけた。これは SoftBank の公式見解ではないのでなんとも言えないが、
という前提に基づいた試算表が公開されている。
この通りだとすれば、頭金０，月々＋960円で新機種が使え、来年の8月には旧型の支払いが終わるので今より下がる計算。ホントかなあ。
P.S. 表の見方が間違っていた。月々割が2重に効くわけがないので、純粋に 3GS を追加購入した分の 2,880円がそのまま増える、という計算なようだ。ここままのプランだと高いので諦める以外ないが、機種グレードアップキャンペーンを貼ってくれることを期待しよう。
最近のコメント