この間フラっと電気屋にMacBookAirを見に行った。
ちょっと触ってみて思ったこと。
・軽い
・薄い
・筐体が綺麗(無駄な突起が全然無いね)
・速い(Dockのアイコン選択してワンバウンドするかしないかで、アプリが起ち上がる)
とここまではみなさんレビューでよく言ってること。
僕もそれは感じたけど、他にも
・何気に専有面積デカイ(13inchは小さいカバンに入らねーんじゃねーか？)
・11inchは小さいけど、バッテリーがなぁ…
・13inchは1.3kgぐらいあんのね。重いわ。(あのルックスからは1.1kgぐらいであって欲しかった)
・Thunderbolt Display欲しくなってしまうなぁ…でも家では使わんなぁ…
・何か細かいとこよくよく見ると、微妙に安っぽいなぁ(まぁ実際安いけど)
他にも、と言いつつ大した感想は無かったですね(^^;)
でも筐体の重さを気にしなければ、うちのMacBookSSD化で我慢できるんではないだろうか。
確かに、Air触って一番魅力に感じたのは、アプリの起ち上がりの速さ。
あれはHDDの時とは本当に別次元。
HDDでクリーンインストール直後でも2バウンドくらいでSafariが起ち上がる。
Airはウィンドウ隠してあっただけで、起ち上げて無いんじゃないかって思うくらい速かった。
やっぱしばらくはMacBookにSSDでいいや。
僕は毎朝JRで通勤しています。
降車駅には中央口に50台近くの改札機があります。
そこをicocaでピッとタッチして改札を出る度に思うことがあります。
JRのicocaシステムはスゲェ。
ラッシュ時は一つの改札機だけでも1秒間に1～3トランザクションくらいはあると思う。
その中でリアルタイムでエラーチェック、エラーハンドリング、履歴蓄積をしてる。しかも履歴蓄積とかは並列で。
中央口だけで50台近く、その他の出入り口で20～30台あって、多分合計150台くらいあるんだと思う。
それに一斉に通勤客がなだれ込み、全体で1秒間に150～450トランザクションあることになる。
それを遅れること無く処理していく。スループットが半端ない。
興味が出てさわりだけ調べてみた。
icocaカードには直近50件の使用データが蓄積されているらしい。
ピッとタッチした瞬間にカード側に履歴データが読み書きされるっぽい。
定期の期限切れ等のエラーハンドリングはこのデータを基にしてるんだろう。
問題は、料金計算、乗り越し精算、料金エラーだ。
どこから乗ってどこで下りて。その金額はコレだ！みたいなのをタッチした一瞬で算出せにゃならん。
区間料金データってどこに保持されてるんだろう。 改札機だろうか、改札機のある駅の末端サーバだろうか。icocaカード内だろうか。
しかも区間料金が出てからしか、料金エラーは判別できないし。。
また、カード以外にも使用履歴は残さないといけないだろうから、JR側で保持する履歴データの保存も必要だろう。
さすがにリアルタイムでicoca使用データの中央管理サーバに書き込みに行ってるとは思えないから、多分各駅毎に末端サーバがあるんだと思う。
あの改札を出る瞬間のピッとの一瞬で、
1.入場記録のチェック
2.定期か通常料金かのチェック
3.定期の場合、期間、区間のチェック→そのまま７へ
4.通常料金や定期で乗越の場合、区間から乗車金額を算出(定期で乗越の場合、定期区間は省いて算出)
5.残金のチェック
6.残金データの書き換え
7.使用履歴データの更新
8.使用履歴データのサーバ保存
上記の1～5の中でエラーがあると、キンコーンってハンドリングしなきゃならない。
それをあのトランザクション数で行うってのはバケモノだ。
普段何気なく使ってるけど、あのシステムはほんと凄い。よく出来てるなぁ。
特に区間料金算出辺りの設計を見てみたい。どうなってるか想像がつかん。
ちなみに、僕の予想では、利用履歴データは日次バッチとかで中央サーバに送られて、保存されるんじゃないかなぁ。
もしかすると探せば詳しいシステムの解説とかあるのかもだけど、想像するのが楽しい。
降車駅には中央口に50台近くの改札機があります。
そこをicocaでピッとタッチして改札を出る度に思うことがあります。
JRのicocaシステムはスゲェ。
ラッシュ時は一つの改札機だけでも1秒間に1～3トランザクションくらいはあると思う。
その中でリアルタイムでエラーチェック、エラーハンドリング、履歴蓄積をしてる。しかも履歴蓄積とかは並列で。
中央口だけで50台近く、その他の出入り口で20～30台あって、多分合計150台くらいあるんだと思う。
それに一斉に通勤客がなだれ込み、全体で1秒間に150～450トランザクションあることになる。
それを遅れること無く処理していく。スループットが半端ない。
興味が出てさわりだけ調べてみた。
icocaカードには直近50件の使用データが蓄積されているらしい。
ピッとタッチした瞬間にカード側に履歴データが読み書きされるっぽい。
定期の期限切れ等のエラーハンドリングはこのデータを基にしてるんだろう。
問題は、料金計算、乗り越し精算、料金エラーだ。
どこから乗ってどこで下りて。その金額はコレだ！みたいなのをタッチした一瞬で算出せにゃならん。
区間料金データってどこに保持されてるんだろう。 改札機だろうか、改札機のある駅の末端サーバだろうか。icocaカード内だろうか。
しかも区間料金が出てからしか、料金エラーは判別できないし。。
また、カード以外にも使用履歴は残さないといけないだろうから、JR側で保持する履歴データの保存も必要だろう。
さすがにリアルタイムでicoca使用データの中央管理サーバに書き込みに行ってるとは思えないから、多分各駅毎に末端サーバがあるんだと思う。
あの改札を出る瞬間のピッとの一瞬で、
1.入場記録のチェック
2.定期か通常料金かのチェック
3.定期の場合、期間、区間のチェック→そのまま７へ
4.通常料金や定期で乗越の場合、区間から乗車金額を算出(定期で乗越の場合、定期区間は省いて算出)
5.残金のチェック
6.残金データの書き換え
7.使用履歴データの更新
8.使用履歴データのサーバ保存
上記の1～5の中でエラーがあると、キンコーンってハンドリングしなきゃならない。
それをあのトランザクション数で行うってのはバケモノだ。
普段何気なく使ってるけど、あのシステムはほんと凄い。よく出来てるなぁ。
特に区間料金算出辺りの設計を見てみたい。どうなってるか想像がつかん。
ちなみに、僕の予想では、利用履歴データは日次バッチとかで中央サーバに送られて、保存されるんじゃないかなぁ。
もしかすると探せば詳しいシステムの解説とかあるのかもだけど、想像するのが楽しい。
全然知らなかったんだけど、一部のブラウザでAjaxのクロスドメインが実装されてるとか。
XMLHttpRequest Level 2として仕様策定が進んでる。
セキュリティ的に心配になる部分もありながら、便利になったなぁと実感。
少し調べてみる。
Firefox,Safari,ChromeなどW3C準拠のJavascript実装では、特に実装内容変える必要ないそうだ。
今まで通り、XMLHttpRequestが使える。実装変えなくていいのはありがたい。
問題はIEさん。
ActiveXObject("Microsoft.XMLHTTP")では不可の模様。
新しく実装されたXDomainRequestなるものを使えとな…
独自仕様に走るからこんなことになるんだよ。めんどくせーなーorz
メインブラウザOperaさんではその辺は全く実装されてないみたい。
W3C準拠大好きなOperaにしては珍しいな→よく見たらまだDraft版だからか。正式策定されないとOperaは動かないのね。
さて、IEは完全無視として、大半のブラウザではJavascript実装は変更する必要がない。
が、
クロスドメインAjaxを実現するには、サーバ側の設定も必要となる模様。
Access-Control-Allow-Originなる情報をHTTPレスポンスヘッダに付加する必要がある。
便利かも知れんけど、セキュリティの事なんかを考えると、利用用途は限られるかも。
XMLHttpRequest Level 2として仕様策定が進んでる。
セキュリティ的に心配になる部分もありながら、便利になったなぁと実感。
少し調べてみる。
Firefox,Safari,ChromeなどW3C準拠のJavascript実装では、特に実装内容変える必要ないそうだ。
今まで通り、XMLHttpRequestが使える。実装変えなくていいのはありがたい。
問題はIEさん。
ActiveXObject("Microsoft.XMLHTTP")では不可の模様。
新しく実装されたXDomainRequestなるものを使えとな…
独自仕様に走るからこんなことになるんだよ。めんどくせーなーorz
メインブラウザOperaさんではその辺は全く実装されてないみたい。
W3C準拠大好きなOperaにしては珍しいな→よく見たらまだDraft版だからか。正式策定されないとOperaは動かないのね。
さて、IEは完全無視として、大半のブラウザではJavascript実装は変更する必要がない。
が、
クロスドメインAjaxを実現するには、サーバ側の設定も必要となる模様。
Access-Control-Allow-Originなる情報をHTTPレスポンスヘッダに付加する必要がある。
便利かも知れんけど、セキュリティの事なんかを考えると、利用用途は限られるかも。