Agile Cat — in the cloud

Long Tail World さんから Apple ネタを中心に ・・・

Posted in Apple, Out Of Scope, Weekend by Agile Cat on May 30, 2010

今週も面白い話が満載です!

image

どうやって、こんなに面白い話を見つけ出してくるのやらと、いつも感心してしまう Long Tail World こと Satomi Ichimura さんですが、今週も楽しい話題が満載です。 なかでも、株の世界で損している人 『 No.1 』 が、あの Steve Jobs さんだったとは、読んでみればナルホドなのですが、にわかには信じられない話です。また、iPad の影に隠れて値崩れしまくっている iPhone の話など、米国事情を楽しくお勉強してください。 ーーー A.C.

Long Tail World

May 24, 2010
史上最も株ですった男ジョブズ
The Dumbest Trade Ever = Steve Jobs’ $10B Loss

May 25, 2010
米ウォルマート、iPhone 3GSを8720円で叩き売り
Wal-Mart slashes iPhone 3GS price to $97

May 26, 2010
コンピュータウィルスに感染した人間
First human ‘infected with computer virus’ – BBC

May 26, 2010
アップル、マイクロソフトを抜く
Apple Overtakes Microsoft

May 28, 2010
ハーバード大心理学講師が語る「今日から幸せになれる5つの方法」
Five Ways to Become Happier Today

May 29, 2010
こっちの朝刊にまでギズの被り物が…
Gizmodo Japan staffs on Mercury News

それと、Agile_Cat 的にお薦めなのは、今日から幸せになれる5つの方法です。これまた、読んでみればナルホドです。  、、、というわけで、幸せな日曜日を ど~ぞ。

ーーーーー

<関連>
App Store を凌駕する、Touch Screen Web サイトの成長
Apple は Web-based サービスの重要性を理解していない、、、と Tim O’Reilly
米当局が Apple を反トラスト法で調査? May 3, 2010
歓迎すべきことに、Apple は制空権を失いつつある
Jobs の Adobe 批判って、自爆してません?

メジャー・クラウドの比較テスト Part_1 : 性能は Amazon S3 と Azure が圧勝

Posted in Amazon, Google, Microsoft, Research by Agile Cat on May 29, 2010

End-To-End Performance Study of Cloud Services
DateWednesday, May 26, 2010 at 4:49PM
http://highscalability.com/blog/2010/5/26/end-to-end-performance-study-of-cloud-services.html

image

___space

メジャー・クラウドを並べた、初めてのテストだと思います。性能に関しては、Amazon S3 と Azure が圧勝と書きましたが、あくまでも Many-Wtite-Many-Query の形態のようであり、Write-Once-Read-Many ではありません。 そのため、Google App Engine などは散々な結果となっています。 文中にも、イベンチュアル・コンシステンシーを前提としたテスト(Part_2?)を計画中と書いてありますが、そちらでは別の結果がでると予測されます。 クラウドにおけるワークロード・モデルは 1つでは有りませんが、一般的なエンタープライズ・モデルにおいては、このテスト結果 Part_1 が適用できるはずだと思います。ーーー A.C.

ーーーーー

Cloud computing promises a number of advantages for the deployment of data-intensive applications. Most prominently, these include reducing cost with a pay-as-you-go pricing model and (virtually) unlimited throughput by adding servers if the workload increases. At the Systems Group, ETH Zurich, we did an extensive end-to-end performance study to compare the major cloud offerings regarding their ability to fulfill these promises and their implied cost.

クラウド・コンピューティングが約束するのは、データ・セントリックなアプリケーションのディプロイメントにおける、数多くのアドバンテージである。 最も顕著なものには、ワークロードの増加に応じたサーバーの追加により、pay-as-you-go の料金モデルと、(事実上)無制限のスループットを実現し、コストを削減することも含まれる。 ETH Zurich の Systems Group では、大規模な End-to-End パフォーマンス実験を行い、それらの約束と暗黙のコストを満たす能力について、メジャー・クラウドを比較した。

The focus of the work is on transaction processing (i.e., read and update work-loads), rather than analytics workloads. We used the TPC-W, a standardized benchmark simulating a Web-shop, as the baseline for our comparison. The TPC-W defines that users are simulated through emulated browsers (EB) and issue page requests, called web-interactions (WI), against the system. As a major modification to the benchmark, we constantly increase the load from 1 to 9000 simultaneous users to measure the scalability and cost variance of the system.  Figure 1 shows an overview of the different combinations of services we tested in the benchmark.

この作業におけるフォーカスは、ワークロード(Read / Update)の分析というよりは、トランザクション処理にあった。比較のためのベースラインとしては、Web-shop をシミュレートするための標準的なベンチマークである、TPC-W を用いている。この TPC-W が定義するのは、EB(Emulated Browser)を介してエミュレートされるユーザーと、ページ・リクエストの発行であり、それれは、システムに対する WIPS(Web Interaction Per Second)と呼ばれるものとなる。 このベンチマークに対する主要な修正としては、対象システムのスケーラビリティとコスト相違を測るために、シュミレートされる同時使用ユーザー数を、1~9000 間でリニアに増やせるようにしたことである。  Figure 1 が示すのは、このベンチマークでテストしてサービスの、それぞれの組み合わせに関する概要である。

ETH Cloud Test _1

Figure 1: Systems Under Test

The main results are shown in Figure 2 and Table 1 – 2 and are surprising in several ways. Most importantly, it seems that all major vendors have adopted a different architecture for their cloud services (e.g., master-slave replication, partitioning, distributed control and various combinations of it). As a result, the cost and performance of the services vary significantly depending on the workload. A detailed description of the architectures is provided in the paper. Furthermore, only two architectures, the one implemented on top of Amazon S3 and MS Azure using SQL Azure as the database, were able to scale and sustain our maximum workload of 9000 EBs, resulting in over 1200 Web-interactions per second (WIPS).  MySQL installed on EC2 and Amazon RDS are able to sustain a maximum load of approximate 3500 EBs. MySQL Replication performed similar to MySQL standalone with EBS, so we left it off the picture. Figure 1 shows that the WIPS of Amazon’s SimpleDB grow up to about 3000 EBs and more than 200 WIPS. In fact, SimpleDB was already overloaded at about 1000 EBs and 128 WIPS in our experiments. At this point, all write requests to hot spots failed. Google AppEngine already dropped out at 500 emulated browsers with 49 WIPS. This is mainly due to Google’s transaction model not being built for such high write workloads. When implementing the benchmark, our policy was to always use the highest offered consistency guarantees, which come closest to the TPC-W requirements. Thus, in the case of AppEngine, we used the offered transaction model inside an entity group. However, it turned out, that this is a big slow-down for the whole performance. We are now in the process of re-running the experiment without transaction guarantees and curios about the new performance results.

Figure 2 と、Table 1 ー2 示される主な結果は、いくつかの面で驚きをもたらす。 最も重要なことは、それぞれのクラウド・サービスにおいて、メジャー・ベンダーが異なるアーキテクチャを採用している点だと思われる(たとえば、マスター・スレーブ・リプリケーション/パーティショニング/分散制御/多様な組み合わせなど)。 その結果として、サービスにおけるコストとパフォーマンスは、ワークロードに応じて大幅に変化する。個々のアーキテクチャに関する詳細は、このペーパーで提供されている。 さらに、だた 2つのアーキテクチャである、Amazon S3 と MS Azure(SQL Azure )に実装されたものだけが、9000 EB という最大のワークロードをスケールし、また、維持することが可能だった。 それは、毎秒 1200 WIPS という値に相当する。 Amazon の EC2 と RDS 上インストールされた MySQL は、3500の EB の最大ワークロードを支えることが可能だった。 MySQL Replication のパフォーマンスは、EBS を用いたスタンドアロン MySQL と同等であるため、Figure 2 から削除している。 また、Amazon SimpleDB の WIPS は、最大で約 3000 の EB と、200 の WIPS まで伸びている。 ただし、 私たちの実験では、SimpleDB は 1000 EB と 128 WIPS の辺りで、すでにオーバーロードをきたしている。 つまり、この時点にいおて、ホットスポットに対する、すべての書込みリクエストが失敗している。 Google AppEngine は、500 EB/49 WIPS 辺りで、すでに脱落している。Google のトランザクション・モデルが、このような高度な書込みワークロードに対応していない点に、その要因がある。 このベンチマークを実装するときのポリシーは、最も強固なコンシステンシーを保証するものであり、それは TPC-W 要件に最も近いものとなる。 したがって、AppEngine のケースでは、エンティティ・グループ内にトランザクション・モデルを提供する手法を用いた。 しかし、結局のところ、その手法がパフォーマンス全体を大きくスローダウンさせることになった。 そのため、現時点において、トランザクション保証と従来からの観点を用いることの無い、新しいパフォーマンス結果をもたらすための、再実験を進めているところだ。

ETH Cloud Test _2

Figure 2: Comparison of Architectures [WIPS]

Table 1 shows the total cost per web-interaction in milli dollar for the alternative approaches and a varying load (EBs). Google AE is cheapest for low workloads (below 100 EBs) whereas Azure is cheapest for medium to large workloads (more than 100 EBs).  The three MySQL variants (MySQL, MySQL/R, and RDS) have (almost) the same cost as Azure for medium workloads (EB=100 and EB=3000), but they are not able to sustain large workloads.

Table 1 が示すのは、WIPS に関する 1/1000 ドル単位でのトータル・コストであり、変動する EB に対応する別の指標となる。 ミドルからラージの負荷(100 EB 以上)では Azure が最も低価格なのに対して、Google AE はスモール(100 EB 以下)で最安値となる。 MySQL の 3つの派生物(MySQL、MySQL/R、RDS)は、ミドルの負荷(100~3000 EB)では Azure に等しいが、ラージの負荷を維持できない。

ETH Cloud Test _3

Table 1: Cost per WI [m$], Vary EB

The success of Google AE for small loads has two reasons.  First, Google AE is the only variant that has no fixed costs. There is only a negligible monthly fee to store the database. Second, at the time these experiments were carried out, Google gave a quota of six CPU hours per day for free.  That is, applications which are below or slightly above this daily quota are particularly cheap.

スモールにおける Google AE の成功は、2つの理由による。  最初に、Google AE は固定費を伴わないという、唯一の例外であることが挙げられる。 ただし、データベースをストアするための、微細な月額料金が必要になる。 次に、この実験が実施されたとき、 Google は 6 CPU 時間/日を無償にするという割引を提供していた。  そのため、上下の Table における適用は、通常より低価格となっている。

Azure and the MySQL variants win for medium and large workloads because all these approaches can amortize their fixed cost for these workloads. Azure SQL server has a fixed cost per month of USD 100 for a database of up to 10 GB, independent of the number of requests that need to be processed by the database.  For MySQL and MySQL/R, EC2 instances must be rented in order to keep the database online.  Likewise, RDS involves an hourly fixed fee so that the cost per WIPS decreases in a load situation.  It should be noted that network traffic is cheaper with Google than with both Amazon and Microsoft.  

Azure および MySQL 派生物が、ミドルからラージの負荷において勝者となる理由は、その全てのアプローチにおいて、固定的なコストを償却できるからだ。 Azure SQL Server は、最大で 10GB のデータベースのための USD 100/月への固定コストを伴なうが、データベースが処理する必要のあるリクエスト数は、そこから独立している。  MySQL と MySQL/R では、データベースをオンライン状態に保つために、EC2 インスタンスをリターンしなくてはならない。  同様に、EDS は 1時間単位の固定コストを伴うため、 WIPS ごとのコストが負荷の状況にいうて減少する。ネットワーク・トラフィックに関しては、Amazon と Microsoft よりも Google の方が安価なことが指摘されるべきだ。

Table 2 shows the total cost per day for the alternative approaches and a varying load (EBs). (A "-" indicates that the variant was not able to sustain the load.)  These results confirm the observations made previously:  Google wins for small workloads;  Azure wins for medium and large workloads.  All the other variants are somewhere in between.  The three MySQL variants come close to Azure in the range of workloads that they sustain. Azure and the three MySQL variants roughly share the same architectural principles (replication with master copy architectures). SimpleDB is an outlier in this experiment. With the current pricing scheme, SimpleDB is an exceptionally expensive service.  For a large number of EBs, the high cost of SimpleDB is particularly annoying because users must pay even though SimpleDB drops many requests and is not able to sustain the workload.

Table 2 が示すのは、1日あたりのトータル・コストであり、変動する EB に対応する別の指標となる。 ("ー" は、それらの形態でサポートできなかったことを示す)  この結果から確認できるのは、1つ前の観察と同じでことある。 つまり、スモール負荷では Google が勝者であり、ミドルとラージでは Azure が勝者である。  その他すべては、この両者の中間にある。  MySQL の 3つの派生物は、それらが維持できるレンジにおいて、Azure に近い結果をもたらす。 それら全ては、アーキテクチャにおいて、同一の原則を共有している(マスター・コピーを用いたリプリケーションのアーキテクチャ)。 この実験において、SimpleDB は異常値を呈している。 現行の価格スキームにおいて、SimpleDB は例外的に高価なサービスとなる。  大量の EB における SimpleDB は、たとえ多数のリクエストをドロップし、また、ワークロードを維持することが不可能であっても、ユーザーからの支払いが低減されないため、敬遠される存在になる。

ETH Cloud Test _4

Table 2: Total Cost per Day [$], Vary EB

Turning to the S3 cost in Table 2, the total cost grows linearly with the workload.  This behavior is exactly what one would expect from a pay-as-you-go model.  For S3, the high cost is matched by high throughputs so that the high cost for S3 at high workloads is tolerable. This observation is in line with a good Cost/WI metric for S3 and high workloads  (Table 1). Nevertheless, S3 is indeed more expensive than all the other approaches (except for SimpleDB) for most workloads.  This phenomenon can be explained by Amazon’s pricing model for EBS and S3. For instance, a write operation to S3 is hundred times more expensive than a write operation to EBS which is used in the MySQL variant.  Amazon can justify this difference because S3 supports concurrent updates with an eventual consistency policy whereas EBS only supports a single writer (and reader) at a time.

Table 2 における S3 に目を向けると、そのトータル・コストがリニアに伸びているのが分かる。  この傾向は、pay-as-you-go モデルに基づく期待値を、正確にトレースするものとなる。  S3 おいては、コストに応じたスループットが提供されるが、それにより、大きな負荷での高いコストにも納得できるようになる。この観察結果は、S3 と高負荷における Cost/WIPS 指標とも、きれいに一致している。 そにもかかわらず、S3 は作業負荷に関する大半のケースにおいて、他のアプローチ(除くSimpleDB)より高価である。  この現象は、EB と S3 に関する Amazon の価格モデルにより説明することが可能だ。 実際に、S3 への書出しオペレーションは、MySQL 系で用いられる EB 書出しオペレーションと比べて、100 倍ほど高価になる  S3 はイベンチュアル・コンシステンシーのポリシーを用いて、複数の同時アップデートをサポートするのに対して、EB では 1回に 1つの書き込みだけがサポートされるため、Amazon は違いを正当化できるだろう。

In addition to the here presented results, the paper also compares the overload behavior and presents the different cost-factors leading to the here presented numbers. If you are interested in these results and additional information about the test-setup, the paper will be presented at this year’s SIGMOD conference and can also be downloaded here.

ここで提供される結果のほかに、オーバーロードにおける振舞いを比較し、また、異なるコスト要因を提供するペーパーもある。 もし、それらの結果とテスト環境に関する詳細情報に興味があるなら、今年の SIGMOD カンファレンスで提供されるペーパーも、ダウンロードできるようになる。

ーーーーー

それにしても、素晴らしいテストを行ってくれたものです。 このテストの形態は、性能について、また、価格について、クラウドを測定する際の 1つの指標になるでしょうね。 次に予定されるイベンチュアル・コンシステンシー・テストが楽しみです。 ーーー A.C.

 

カラー と ユーザー・エクスペリエンス _2

Posted in UX by Agile Cat on May 28, 2010

Colors and User Experience _2
http://community.infragistics.com/ux/articles/colors-and-user-experience.aspx

image

初めての方は、その1 を先にお読みください。

Color Deficiencies

When people talk about color blindness they usually refer to the inability of perceiving certain colors. It is more appropriate to call these conditions color deficiencies, because in the majority of cases people are not completely unable to perceive a certain color, but their perception is faulty [3]. Color deficiencies occur when a cone type is either missing or working abnormally. Figure 5 shows the incidence rates for color deficiencies based on the affected L-, M-, and S-cones. 80 out of 1000 men and only 4 out of 1000 women have some sort of color deficiency. Because the curves for the L- and M-cones are close to each other (see Figure 2), the effect of L- and M-cone based color deficiency is similar. When there are problems with L- or M-cones the color appearance is mostly based on blue and yellow hues, the complimentary color pair red-green cannot be perceived correctly.

色盲について語るとき、特定のカラーを知覚する能力の、欠落について言及されるのが一般である。ただし、こうした状態については、カラー欠陥と呼ぶ方が適切だ。なぜなら、そのような人々の大半は、特定のカラーを知覚する能力が、完全に欠落しているわけではなく、その知覚に欠陥があるからだ[3]。 つまり、コーン・タイプが不適切な場合や、正常に機能しないときに、カラー欠陥が引き起こされる。 Figure 5 が示すのは、何らかの影響を受けた L/M/S コーンに基づく、カラー欠陥の発生率である。 1000人のうち80人の男性が、ある種のカラー欠陥を持つが、女性に関しては 4人だけとなる。 Lコーンと M コーン のカーブは近い位置にあるため、それらが原因となるカラー欠陥の影響は、類似したものとなる。 L/M コーンに関連する問題が生じる大半のケースにおいて、それは、青と黄色の色合いに基づいたカラー・アピアランスの問題となる。つまり、赤と緑の組み合わせによる、補足的なカラーの知覚が不正確なものとなる。

UX_2_5

Figure 5: Color deficiencies.

Color deficiencies based on S-cones have the effect that color perception is based on red and green hues, the perception of the complimentary color pair blue and yellow is disturbed. It is a very rare condition though, only affecting 4 out of 100,000 men and 2 out of 100,000 women. The same is true for total color blindness which is caused by the absence of any cone types in the eyes: 3 out of 100,000 men and 2 out of 100,000 women cannot see any color hues, thus their vision is achromatic and solely based on shades of black, gray and white.

S コーンに基づくカラー欠陥は、赤と緑の色合いに基づく影響をもたらす。つまり、青と黄色の組み合わせによる、補足的なカラーの知覚が不正確なものとなる。 ただし、このようなケースは、100,000人のうち4人の男性と、2人の女性という、きわめて稀なものとなる。 また、あらゆるコーン・タイプの欠如により引き起こされる、色盲についても同じことが言える。 つまり、100,000人のうち3人の男性と 2人の女性が、カラー・アピアランスを見ることができない。したがって、それらの人々の視界は無色であり、黒/灰/白をベースにしたものとなる。

Based on the data in Figure 5 the typical person suffering from color deficiency is a man having problems perceiving red and green. The chance that a person has color perception problems other than for red-green is very low. Actually, the chance that a person will suffer epileptic seizures triggered by blinking UI elements on the screen is 400 times higher [6].

Figure 5 のデータから分析すると、カラー欠陥に苦しむ大半の人々は、赤と緑の知覚に問題を抱える男性となる。 したがって、赤と緑を除いたカラー知覚により、問題が引き起こされる確率は、きわめて低くなる。 また、スクリーン上で点滅する UI 要素により、てんかんの発作が引き起こされるという確率は、一般の 400倍以上という、きわめて高いものとなる[6]。

The question is to what extent color deficiency poses a problem for the usability of a product. The answer is that it depends on the nature of the application. In all those cases where colors are used for aesthetic reasons like on most company homepages, the impact of color perception problems is lower than for systems that use color to indicate status of any kind, e.g. control systems and dashboards. In general, it is recommend not to rely on color alone for coding important information. For example, indicating a system status via virtual red and green lights, is a problem for people with red-green color deficiencies. They would have a hard time differentiating between the red and green lights. So it is recommendable to provide a meaningful text label (“OK” vs. “Alarm”) or a symbol (checkmark vs. exclamation mark) in addition to the color coding.

ここでは、プロダクトの有用性に問題をきたさないためには、どの程度までのカラー欠陥が許容されるのか、という論点を掘り下げていく。 その答えは、アプリケーションの性質に依存するものとなる。大半の企業のホームページなどの、色彩感覚が重視されるケースでは、このような問題の生じる可能性は低くなる。しかし、たとえばコントロール・システムやダッシュボードといった、各種のステータスを示すためのカラーは、そうとは限らない。 一般的には、重要な情報を記号化する際に、カラーだけに頼らない方式が推奨される。 たとえば、仮想的な赤と緑のライトによりステータスを示すシステムは、赤と縁のカラー欠陥を持つ人に対して、問題を引き起こしてしまう。 それらの人々は、赤と緑のライトを識別するのに、苦労するはずだ。 したがって、カラー表現のほかに、意味のあるテキスト・ラベル(OK と Alarm)や、シンボル(チェックマーク や 感嘆符)なを提供する方式が推奨される。

Colors and Visual Appeal

Colors are well suited to increase the visual appeal of a software product. We associate certain meanings with specific colors (Figure 6). These color stereotypes can be leveraged when designing a UI. For example, it may make sense to base a clinical software application on white as this color is associated with cleanliness. Another example is the homepage of the United Nations [7] which is held in blue, thus conveying peacefulness.

ソフトウェア・プロダクトを、ビジュアルにアピールするためには、カラーの使い方が適切な要因となる。 そのため、私たちは、特定の意味を、特定のカラーに結びつける(Figure 6)。 こうしたカラーのステレオタイプが、 UI をデザインする際に促進される。 たとえば、白が清潔さと結び付けられるなら、病院用のアプリケーションを白ベースにすることが意味を持つ。 もう 1つの例は、ブルーの色調を保ち、穏やかさを伝える United Nations(国連)のホームページである[7]。

UX_2_6

Figure 6: Western color stereotypes.

It should be noted that the color associations in Figure 6 pertain to western culture. Because color stereotypes are culture-dependent, they can be quite different in other areas of the world. Red, for example, means “Death” in Egypt, “Life” and “Creativity” in India and “Happiness” in China [9].

Figure 6 におけるカラーの組み合わせが、西欧文化に付随している点に注意して欲しい。 カラー・ステレオタイプは文化依存であるため、世界中の個々のエリアにおいて、きわめて異なるものにもなり得る。 たとえば、赤は、エジプトでは死を、インドでは人生と創造力を、そして中国では幸福を意味する[9]。

Appealing UIs feature sets of colors that are coordinated and harmonious. Creating color schemes is a skill that is anything but trivial because there are many factors to consider, including that the company’s brand value has to be communicated and color associations may be needed to be provoked (see color stereotypes above). Care has to be taken that ergonomic issues are considered as well (see contrast effects above).

UI をアピールするためには、調整され調和するカラーのセットが重要となる。 企業ブランドの価値を伝える必要性や、刺激的なカラーの組み合わせを含めて、考慮すべき多数の要因があるため、カラー・スキーマの作成は、きわめて重要なスキルとなる(上記のカラー・ステレオタイプを参照)。 また、人間工学的な視点に関しても、慎重に考慮しなければならない(上記のカラー・コントラストを参照)。

There are a couple of different ways to create simple color schemes without the help of a graphical designer [10]. For example, you can pick any three colors which are side by side on a 12 part color wheel (analogous colors, see Fig. 7). Or you can select colors that lie directly opposite to each other on the color wheel (complementary colors). Remember though that the combination of red and green is critical for people with red-green color deficiencies (see color deficiency above).

グラフィカル・デザイナーの手助けを必要とすることなく、シンプルなカラー・スキーマを作成するための、2つの方式がある[10]。 たとえば、12の領域に分割されたカラー・ホイールから、3つの隣接するカラーを選ぶことができる(類似色・Figure 7を参照)。 あるいは、このカラー・ホイール内の、対極に位置するカラー(補色)を選択することも可能だ。 ただし、赤と緑の組み合わせは、その知覚に欠陥を持つ人々にとって、重大問題を引き起こすことを忘れないで欲しい(上記のカラー欠陥)。

UX_2_7

Figure 7: Color scheme based on analogous colors.

<おわり>

References

[1] ISO 9241-110 (2006). Ergonomics of human-system interaction – Part 110: Dialog principles. Berlin: Beuth.

[2] Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods. New York City: John Wiley & Sons.

[3] Wyszecki, G, Stiles, W.S. (1982). Color science. 2nd edition. New York City: John Wiley & Sons.

[4] Gleitman, H. (1991). Psychology. 3rd Edition. New York City: W.W. Norton & Company.

[5] Kaiser, P. K., Boynton, R. M. (1996). Human Color Vision. Washington, D.C.: Optical Society of America.

[6] Fisher R.S., Harding G., Erba G., Barkley G.L., Wilkins A. (2005) Photic- and pattern-induced seizures: a review for the Epilepsy Foundation of America Working Group Epilepsia, 46 (9), 1426-1441.

[7] http://www.un.org/

[8] Waters, C. (1996). Web Concept & Design. Indianapolis: New Riders Publishing.

[9] Russo, P., & Boor, S. (1993). How fluent is your interface? Designing for international users. INTERCHI ’93. 342-347.

[10] Williams, R. (2008). The Non-Designer”s Design Book. 3rd Edition. New York City: Peachpit Press.

ーーーーー

image

ーーーーー

色を知覚するメカニズムについて、また、それに関連するアクセシビリティ、そして 文化(ローカルな特質)についてまで、とても興味深い内容のコンテンツでした。 以下は、本家ブログの方についているコメントです。

Great article. Color combinations listed in figure 4 provide a quick and efficient checklist.

I found this article very informative. I do defence based work, and work to strange HMI requirements like ‘avoid red text on dark blue background’ etc. After reading this I now understand the theory behind such requirements.

まさに、Great Article です! (面白すぎて朝になっちまったw)ーーー A.C.

ーーーーー

<関連>
カラー と ユーザー・エクスペリエンス _1
ユーザーのためのデータ・ビジュアライゼーション
UX と テキスト の関係を、論理的に解明する

Tagged with: , , ,

米政府の Recovry.gov が Amazon EC2 へ移行する!

Posted in .Selected, Amazon, Government by Agile Cat on May 27, 2010

White House moves Recovery.gov to Amazon’s cloud
by Alex Howard
http://radar.oreilly.com/2010/05/white-house-moves-recoverygov.html

2010年 5月 13日に O’Reilly Rader にポストされた、とても興味深い記事です。 出張中に知りましたが、そのときは 忙しくて読めませんでした。ーーー A.C.

ーーーーー

O reilly

Earlier today in a blog post on WhiteHouse.gov, federal CIO Vivek Kundra announced that Recovery.gov would be moving to the cloud. The Recovery Accountability and Transparency Board’s primary contractor, Smartronix, chose Amazon’s Elastic Compute Cloud (EC2) to host the site. NASA has used EC2 for testing, but this will be the first time a government website — a “.gov” — has been hosted on Amazon’s EC2. Kundra estimated the savings to the operational budget to run Recovery.gov at approximately $750,000, with $334,000 coming in 2010 alone.

今朝(5/13)早くの WhiteHouse.gov のブログ・ポストにおいて、連邦政府の CIO である Vivek Kundra は、Recovery.govクラウドに移行するだろうと発表した。 具体的に言うと、Recovery Accountability と、Transparency Board の主要コンストラクタである Smartronix は、そのためのサイトをホストする環境として、Amazon Elastic Compute Cloud (EC2)を選んでいる。 すでに、NASA でのテストにおいて EC2 は使用されているが、政府の Web サイトである「.gov」が Amazon EC2 上にホストされるのは、今回が初めてとなる。 Kundra の見積りによると、Recovery.gov を運用するためのコストは $750,000 が低減され、2010年の単年度においても $334,000 が削減される。

recovery gov

“This is a production system,” said Kundra, during a press briefing today. “That’s a critical difference from other agencies that have been testing or piloting. We don’t have data that’s sensitive in nature or vital to national security here.”

プレス・ブリーフィングの際に Kundra は「これはプロダクション・システムだ。つまりテストやプロトタイプなどを担当する、他の政府機関とは状況が大きく異なる。 ここには、本質的に機密性の高いデータや、国家機密に関する重要なデータは存在しない」と発言している。

The recovery board plans to redirect more than $1 million in computer hardware and software that were being used to host Recovery.gov to fraud oversight operations. It’s a move that Earl Devaney, chairman of the recovery board, said will help identify fraud, waste and abuse in the recovery program.

このリカバリー委員会が計画しているのは、不正を監視する Recovery.gov のホスティングで用いられる、コンピュータのハードウェアとソフトウェアに関する  $1 million のコストを方向転換することである。 それは移行であり、また、このリカバリー・プログラムにおける、不正/浪費/乱用の識別を促進することになると、同委員会の議長である Earl Devaney は発言している。

Devaney said that after a town hall, Smartronix evaluated the cloud computing options and decided to go with Amazon’s public offering. “In terms of competition, part of what we’re trying to introduce is Darwinian pressure in federal IT, including new entrants in government that haven’t been there before, such as Amazon,” said Kundra.

タウンホール・ミーティングの後で Devaney は、Smartronix がクラウド・コンピューティングの選択肢を評価し、Amazon がパブリックに提供しているものを使用すると発言した。 また、「競争という観点において、私たちが導入しようとする部分は、政府の IT におけるダーウィン説の適用である。つまり、これまでにはなかった、Amazon のような新しい参加者を政府の中に取り込むことだ」と、Kundra は発言する。

He also said this represents one of the “first bricks in the foundation that we’re laying” throughout the federal government, in terms of cloud computing. Kundra pointed to an upcoming forum on cloud computing on May 20 where many of the issues that the National Institute for Standards and Technology has been working on will be addressed, including the relationship between the public and private sector.

クラウド・コンピューティングという観点において、それは、連邦政府全体におよぶ基盤の、最初のブロックになるとも発言している。 Kundra は、NIST (National Institute for Standards and Technology)が対応している様々な問題が、公共/民間の関係を含めて、5月20日に開催されるクラウド・コンピューティングのフォーラムで、取り組まれるだろうと指摘した。

Kundra said that the move to Amazon’s public cloud went through tough cybersecurity vetting. “The board and vendor went through a rigorous process, in terms of FISMA checks and balances,” said Kundra.

Kundra の発言によると、Amazon のパブリック・クラウドへの移行は、厳格なサイバー・セキュリティの調査を介して行われた。FISMA のチェックとバランスに関して、同委員会とベンダーは苛酷なプロセスを体験したとも付け加えている。

The federal government is actively developing cloud computing case studies, like the use of Saleforce.com’s public cloud by the Department of Health and Human Services (HHS). “Case studies are being used for the broader FedRAMP program,” he said. “Look at the Department of Interior: The CIO is considering moving 80,000 emails to the cloud. Look at the investments made at GSA or a recent RFI [Request for Information] around email. Across federal government, you’re seeing a number of agencies putting in a plan.”

Department of Health and Human Services (HHS)における Saleforce.com  パブリック・クラウドの利用のように、連邦政府は積極的に、クラウド・コンピューティングのケース・スタディを作っている。「それらのケース・スタディは、広範囲におよぶ FedRAMP プログラムのために使用されている。Department of Interior を見ると、その CIO は 80,000 のメール・アカウントをクラウドに移行しようとしている。 電子メールに関連する GSA あるいは、最近の RFI [Request for Information ]への投資を確認してほしい。 連邦政府のいたるところで、数多くの機関が計画を実施している」と、Kundra は発言している。

Why move to the cloud now, rather than at the start? “We had concerns about data, pulling it off with hundreds of thousands of feeds,” said Devaney. “We found it prudent to do it the old-fashioned way first, then move to the cloud.”

スタートの時点ではなく、いまになってクラウドへ移行するのは何故だろう? 「私たちは、何十万というフィードを用いて、データを上手く処理することに関心があった。 最初に、それを慎重に行うことは、古いスタイルあることに気づき、続いて、クラウドへ移行することにした」と Devaney は発言する。

On May 20, Kundra said the federal government will release data center numbers as part of a larger project to consolidate IT infrastructure. Based upon those findings, further migration to cloud computing may be forthcoming.

連邦政府は 5月20日に、IT インフラを統合するための大規模プロジェクトの一部として、そのデータセンター数を公表するだろうと、Kundra は発言している。 そこでの結論に基づいて、さらなるクラウド・コンピューティングへの移行が、もうすぐ始まるだろう。

ーーーーー

<関連>
とても重要な NIST のクラウド定義:対訳
総務省 自治体 クラウド ポータル サイトって、これで良いの?
台湾政府のしたたかなクラウド戦略
総務省と経済産業省は共振している: @ytaniwaki 氏のまとめ
経産省の Twitter に掲載された、とても真摯なメッセージ
総務省 スマート・クラウドに対するパブコメと議論 on Twitter (まとめ)

カラー と ユーザー・エクスペリエンス _1

Posted in UX by Agile Cat on May 26, 2010

Colors and User Experience _1

http://community.infragistics.com/ux/articles/colors-and-user-experience.aspx

image

UX_2_0

As the name suggests, GUIs (Graphical User Interfaces) present their features and functions visually. The human-computer interaction is heavily based on seeing things, looking for things and interacting with graphical UI elements. Color is a main characteristic of any visual scene, not only on computer screens, but in any situation where we see something. Because most of what we see and interact with in our everyday life is colored (as opposed to shades of white-gray-black), we are very familiar with colors – maybe so much that we don’t think about them a lot. On the other hand, it does bother us when we need to read a dark-gray label on a black button. So colors have the potential to boost or wreck the user experience. The rest of the article will introduce the concept of user experience and highlight some aspects of colors and color perception together with recommendations for UI design.

その名前が示唆するように、GUI(Graphical User Interfaces)とは、そこに含まれるが特徴や機能を視覚的に表現するものである。 人間とコンピュータのインタラクションは、グラフィカルな UI 要素を用いた、視認と、参照、そして相互作用に大きく依存するものとなる。 色の使い方は、ビジュアルな観点における最大の特質であり、コンピュータのスクリーン上だけではなく、私たちが物を見るという、あらゆる状況においても重要だ。なぜなら、日常の生活で見分けるもの、そして相互に作用するものは、その大部分が色付されているからである(white-gray-black による影の対極として)。それほどに、カラーは私たちにとって馴染み深いものだが、あまり深く考えられていないという面もある。 その一方で、スクリーン上の黒いボタンの上に書かれた、濃い灰色のラベルを読むときに、私たちは悩まされる。つまり、カラーにより、ユーザー・エクスペリエンスは向上することもあれば、劣化することもあり得る。 この記事では、ユーザー・エクスペリエンスの概念を紹介すると共に、カラーに関する側面や、UI デザインで推奨される色彩感覚について取り上げていく。

User Experience

User Experience (UX) is a concept pertaining to the overall – or holistic – encounter between users and interactive technical systems. More concretely, it’s the degree of usability and appeal that a website or application provides to its users. Great usability implies that an interactive product allows its users to efficiently accomplish their goals. Well-known guidelines are provided by ISO 9241-110 [1] and Nielsen’s Heuristics [2].

ユーザー・エクスペリエンス(UX)は、ユーザーと対話型のテクニカルなシステムの間を結ぶ、あらゆる局面に付帯する概念である。 さらに具体的にいうと、それは有用性の度合いであり、また、Web サイトあるいはアプリケーションがユーザーを惹きつける魅力のことになる。 優れた有用性とは、ユーザーによる効率的な目的の達成を実現する、対話型のプロダクトのことを意味する。 広く知られるガイドラインとして、ISO 9241-110 [1] と Nielsen’s Heuristics [2] が提供されている。

Appeal refers to the emotional tie between users and a system they are interacting with. Do users love it? Hate it? Do they think it’s attractive or modern or engaging? Do they feel pride when they interact with it? Although appeal cannot be defined as concisely as usability, it is of equal importance for the success of a product because appealing systems are more enjoyable and desirable which increases their value.

魅力のアピールとは、ユーザーと相互作用するシステムの間の、感覚的な絆のことである。 それを、ユーザーは好むのだろうか? それとも、好まないのだろうか?  ユーザーに対して、素敵だと感じさせ、モダンだと思わせ、とりこにすることが出来るのだろうか? そして更に、それと相互作用するユーザーに、誇らしい気分を提供できるだろうか? 魅力については簡潔に定義できないが、システムの魅力をアピールすることは、その価値を高める感覚的な要因となるため、プロダクトを成功させるという意味で、有用性と同等の重みを持つ。

UX_2_1 Figure 1: User Experience

Colors and the UI

Color is the sensation that is invoked when light of wavelengths between 360nm and 720nm hits our eyes and then is processed by our visual system [3]. Our eyes feature three types of color receptors, each maximally receptive to long, medium, and short wavelengths of light. These are known as L-, M- and S-cones. As it can be seen in Figure 2, a light with a wavelength of 530nm triggers the M-cones most, the L-cones slightly less and the S-cones just a little. The perceived color impression would then be a green.

カラーとは、 360nm~720nm の波長の光が、私たちの目を刺激するときに検知され、続いて、視覚システム[3]により処理される知覚のことである。 私たちの目は、3種類のカラー感覚器官を特徴とし、それぞれが、長/中/短の波長を極限まで受容する。 それらの概念は、L/M/S コーンとして知られている。 Figure2で確認できるように、530nm の波長を持つ光は、その大部分が Mコーンを引きおこし、Lコーンはやや少なく、Sコーンはほとんど無いという状況である。 この波長は、グリーンとして知覚されるだろう。
   

UX_2_2

Figure 2: Color perception is achieved through three cone types (after [4]).

On computer screens colors are defined through the RGB color model (R stands for red, G for green and B for blue). These three colors are called primary colors and correspond to the wavelengths the L-, M- and S-cone are most receptive for. Primary colors cannot be generated by mixing other colors. Instead, by mixing primary colors, all other colors can be generated. Each pixel on a screen shows a color generated by the interplay of one red, one blue and one green light source that are so close to each other that they cannot be distinguished.

コンピュータ・スクリーン上のカラーは、RGB カラー・モデル(R stands for red, G for green and B for blue)を介して定義される。 これらの3つの色は原色と呼ばれ、L/M/S コーンを受け入れる波長に対応する。 他の色を混ぜ合わせても、これらの原色を作ることはできない。 その反対に、原色を混ぜることで、すべての色を生成できる。 スクリーン上の個々のピクセルが識別できないほどに隣接し、また、赤/青/緑のライトが相互作用することで、カラーを生み出す。

Color Contrast

Typically, a colored object or area on a UI is not displayed in isolation, but is adjacent to or superimposed on another colored object or area. This creates contrast effects. Without sufficient contrast, we could not discriminate different parts on our screen. There is a good reason why office applications like MS Word, Powerpoint, Excel, Outlook, etc. are based on a white background with black as a default font color – this provides the maximum contrast and therefore optimum legibility.

一般的に、UI における色付されたオブジェクトやエリアは、個別に表示されるものではなく、別の色を持つオブジェクトやエリアと、隣接したり、重なりあったりする。 それにより、コントラストの効果が引き起こされる。 充分なコントラストが無いと、スクリーン上の個々のパーツを識別できなくなるだろう。 Word や、Powerpoint、Excel、Outlook といった Microsoft Office 製品が、デフォルトとして白い背景と黒のフォントを使う背景には、このような理由がある。つまり、最大のコントラストと、最適化された視認性を提供することになる。

Apart from this, color contrast can be deliberately used to draw the visual attention of users to relevant UI elements that feature important information or require inputs.

それとは別に、たとえば、ユーザーを視覚的に惹きつけ、重要な情報を提供する UI 要素や、入力を要求する UI 要素に対して、意図的にカラー・コントラストを適用することも可能である。

Color contrast also lends itself well to boost the visual appeal of a UI. Empirical studies show that warm colors (e.g. red, yellow, orange) are preferred on backgrounds of cool colors (e.g. blue, green, purple) and vice versa.

カラー・コントラストは、UI の視覚的なアピールを、それ自身で高めるという働きも持つ。実証的な研究では、暖色(たとえば red, yellow, orange)と、寒色(たとえば blue, green, purple)の対比が好まれるという、結果が示されている。

Contrast effects can also be detrimental for the user experience. Two prominent examples are discussed in the following. In general, any region in the visual field tends to induce its complementary color in neighboring areas. For example, a gray square will tend to look greenish when surrounded by red, and reddish when it is surrounded by green. This effect is known as simultaneous color contrast [4]. On UIs it can sometimes be seen that the same control, e.g. a push button, looks strikingly different on backgrounds of different colors.

また、コントラストは、ユーザー・エクスペリエンスにとって有害なものにもなり得る。 2つの顕著な例について、以下に説明する。 まず、一般的に、あらゆる視覚的な領域において、隣接するエリアを補色を誘発するという傾向を持つ。 たとえば、グレーの正方形は、赤に囲まれると緑色っぽく見え、緑色に囲まれると赤っぽく見えるという傾向にある。 この効果は、同時色対比として知られている[4]。 UI においては、たとえばプッシュ・ボタンなどの同一のコントロールが、異なる背景色の上では別のものに見えるという状況が、ときおり確認できる。

Another problematic contrast effect is chromatic aberration [5]. Lenses, including the lenses in our eyes, bend lights of different wavelengths by unequal amounts. The effect is that different colored stimuli are not projected at the same spot at the retina – an effect most noticeable for combinations of violet and red as well as blue and red (see Figure 3), because the wavelengths of violet and blue are at one end of the visual spectrum while the wavelength of red is at other end (see Figure 2).

コントラストにおける、もう1つの問題は色収差である[5]。 私たちの眼球を含めて、レンズは、それぞれの波長の光を、不等な量で屈折させる。 この効果により、それぞれの色による刺激が、網膜上の同じスポットに投影されなくなる。つまり、最も目立つ組み合わせは、violet/red と blue/red (see Figure 3) になるが、その理由は、violet と blue の スペクトルが左端にあるのに対して、red は右端にあるからだ (see Figure 2)。

UX_2_3

Figure 3: The effect of chromatic aberration.

Consequently, the text in Figure 3 looks blurred against the background. Because of this, contrasts of red and violet/blue should be avoided on a UI. Despite this, red-blue color contrasts are pretty common, possibly because the person designing the UI tries to avoid the combination of red and green due to color deficiency reasons (see color deficiency below). Figure 4 shows combinations of background and foreground colors that provide a good contrast.

したがって、Figure 3 のテキストは、背景に対して不鮮明になる。 このような理由から、violet/red と blue/red のコントラストは、UI では避けるべきものとなる。 それにもかかわらず、色覚異常の理由から  red/green の組み合わせは回避される。 そのため、残された blue/red の組み合わせは、UI デザイナーにとって一般的なものとなる。 Figure 4 が示すのは、適切なコントラストを提供する、バックグラウンド/フォアグラウンドの、カラーの組み合わせである。

UX_2_4

Figure 4: Color combinations providing good contrasts.

ーーーーー

References

[1] ISO 9241-110 (2006). Ergonomics of human-system interaction – Part 110: Dialog principles. Berlin: Beuth.

[2] Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods. New York City: John Wiley & Sons.

[3] Wyszecki, G, Stiles, W.S. (1982). Color science. 2nd edition. New York City: John Wiley & Sons.

[4] Gleitman, H. (1991). Psychology. 3rd Edition. New York City: W.W. Norton & Company.

[5] Kaiser, P. K., Boynton, R. M. (1996). Human Color Vision. Washington, D.C.: Optical Society of America.

ーーーーー

<続く>

image

ーーーーー

<関連>
カラー と ユーザー・エクスペリエンス _2
ユーザーのためのデータ・ビジュアライゼーション
UX と テキスト の関係を、論理的に解明する

Tagged with: , , ,

yoshiyuki kanno さんの Apache Cassandra 用語集(日本語版)

Posted in NoSQL by Agile Cat on May 25, 2010

とにかく スバラシイの 一言に尽きます!

http://mocchira.posterous.com/apache-cassandra-glossarys-japanese-translati

yoshiyuki kanno さんが、Apache Cassandra Glossary’s Japanese Translation を、つまり Apache Cassandra 用語集(日本語訳)を提供してくれました。 スバラシイ!

Cassandra Glossary

用語集なので A-to-Z の構成になっていて、Cassandra の概論とかいうものではなく、また、すべてを読む必要はないと但し書きされていますが、頭から順に読んでいくだけでも、この新しいテクノロジーの全体像が見えてきます。

まず、A の項目には Anti-Entropy があり、Amazon Dynamo との関連性などが把握できるようになっています。つまり、Dynamo から継承するものと、Cassandra で新たに考案されたものが分かるようになっています。 また、同じく A の項目には Cassandraの RPC クライアントである Avro も説明されていて、Hadoop からの継承も存在することが分かります。

B の項目には、話題の Bloom Filter ですが、、、難しい! しかし、この日本語用語集の素晴らしいところは、ココは難解だから Wikipedia でどうぞという感じに、yoshiyuki kanno さんによるサゼッションが加えられているところです。涙が出るほど嬉しいです。この他にも、B の項目では、Bigtable と SSTable と HBase の関係なども、さっと把握できる構成になっています。

そして、C の項目には Cassandra 自身の名前の由来や、これまでの経緯などもあります。さらには Commit Log や Compaction といった、Cassandra における重要な概念や Consistency の明瞭な定義などがあり、断片的な情報とは言え、つなぎ合わせて考えていくと、Cassandra の概要が浮き彫りになってくるように思えてきます。

こんな感じで書き連ねていくと Z までたどり着いてしまうので :) 、この辺りに留めておきますが、Apache の整理も素晴らしければ、解り易い yoshiyuki kanno さんの日本語も素晴らしく、しかも、こうしてブログでオープンにして頂くことで、数多くのエンジニアの方々によるエコシステムが構築されいくという、これまた素晴らしい展開が期待されます。

Agile_Cat は以前から Twitter 友達と、『 オープンソースがあるのに、なんで、オープン・トランスレーションが無いのか 』 という議論をしていますが、これは何処にもモデルの無い、私たち日本人が自ら考えていかなければならない、きわめて重要なテーマなんだろうと思っています。

現実に、スケーラビリティの世界では、Hadoop が突破口を開いて、数々の NoSQL がそれに続き、また、この Cassandra は Twitter でも実績を残しつつあります。 しかし、その全てがオープンソースであり、日本語のドキュメントが追いつかないという状況が、現在の日本における大きな問題の 1つなのです。

この、Apache Cassandra Glossary’s Japanese Translation が契機となって、オープン・トランスレーションが進んでいかないかなぁ、、、と期待しています。

ーーーーー

<関連>
Cassandra をサポートする Riptano が始動
Cassandra:6つの迷信と 6つの真実
Cassandra ライブ情報がテンコ盛り – Jonathan Ellis @ Rackspace
Cassandra 分散データベースでの削除とは?
Cassandra プロジェクトと Rackspace
Twitter が Cassandra を選んだ理由 — MyNoSQL
Digg が Cassandra を採用する理由 by John Quinn
Hadoop DFS _ Introduction

アメリカの IT 風景:スナップ 8点

Posted in .Chronicle, Miscs, Network by Agile Cat on May 24, 2010

空港を中心に、2010年 5月の IT スナップです

アメリカ国内を、あちらへ、こちらへと、移動してばかりいた出張でしたが、乗り継ぎ待ちの空港を中心に IT スナップにトライしてみました。こうして並べて見ると、それは、それで、この瞬間の IT 風景を切り取って、表現しているかのように見えてきます。

penn stマンハッタンの Penn ステーションにて ーーー ものすごくインパクトのある比較広告。 NJ 方面への帰路に着く何十万もの人々が、この看板を見ながら地下へ吸い込まれていく。 この駅で、最も高価な広告スペース?
ATTChicago O’Hare 空港にて ーーー 何を言いたいのかよく分からない AT&Tの広告。Verizon に対抗して、アメリカだけではなく中国でも、、、って言うこと? 
boingoChicago O’Hare 空港にて ーーー Official で Boingo と明記。 実際、Boingo はとても便利で、コレがあれば旅行者にとっての WiFi サービスは充分かも。 また、空港だけではなく、スタバやマックでも OK。
gogoflight 
Atlanta 空港にてーーー Newark 行きの Delta 便。 この後にアカウント作成するも、100% サポートではないので、空振り。う~ん。空からの Twitter は、是非とも試したかった。残念!
blackberryAtlanta 空港にて ーーー やはり RIM は強く、iPhone より BlackBerry を多く見かけた。 ここも空港内にしては、かなり本格的なショップという感じ。
newark
Newark 空港にて ーーー 特等席に陣取って、仕事に勤しむ人々。 トーテムポールには、さりげなく Samsung のロゴが。ちなみにホテルの液晶 TV は、3都市とも LG。
yahoo Times Square にて ーーー ダウンタウン方向へ視線を向けると、かなり高そうなスペースに Yahoo が。  kodak
Kodak も凝った広告を展開。こうした老舗が、体質を変えながら時代と同期していこうとする様は、なんとなく感動的。

今回のカメラは、Nokia N900 です。5M Pixels ですが、たとえば Web などを前提にするなら、充分なクオリティかと思います。極端な話、デジカメに インターネット端末が付いているという捉え方もあり得ます。 また、撮ったそばから Evernote で、My クラウドにアップできます。 そして、この出張に関連するドキュメントなどと、タグを共有することも可能ですので、その意味での使い勝手も良いです。 整理がヘタで写真には消極的だった Agile_Cat ですが、このようなサービスが使えると、写真好きに変身するかもしれません :) ーーー A.C.

ーーーーー

<関連>
Boingo で Wifi は OK、そして Twitter の位置補足が・・・(US 出張編_1)
スマートグリッドを Hadoop で (US 出張編_2)
スマートグリッドを Hadoop と OpenPDC で(US出張編_3)
Data Center Knowledge について ご意見を・・・(US出張編_4)
Boingo 接続の勝敗表など(US出張編_5)
Microsoft IT PAC:初の導入は、第二期 Quincy になるのか? (US 出張編_6)
GO GO FLIGHT で空から Twitter (US 出張編_7)

 

Tagged with: , , ,

GO GO FLIGHT で空から Twitter (US 出張編_7)

Posted in Network, Twitter by Agile Cat on May 22, 2010

はたして上手くいくでしょうか?

今回のフライトは Delta なのですが、なんと国内線では機内 WiFi がサービスされる便もあるようなのです。 これまでに何度か見かけたのですが、事前のアカウント取得が必要ということで、試すことができませんでした。 つまり、飛行機に乗るたびに、あっ しまった! を連発してきたわけですが、明日が最後のチャンスということで、先ほど、しっかりとアカウントを作りました :) 明日のミネアポリス行きに、GO GO FLIGHT が付いていれば良いなぁと思っています。

Now you can tweet from your seat, get work done, or have some fun! In-flight Internet access is available across our fleet on more than 1,800 flights daily through our relationship with Gogo® In-flight Internet Access.

image

日本でも、そろそろ新幹線で WiFi サービスが始まると聞いたことがありますが、飛行機も計画があるのでしょうかね? もちろん、離着陸時は NG なんでしょうけど、通信機器に関しては航行時は常に禁止って言っている、アレはいったい何んなのでしょうね? まぁ、こういうサービスが提供されることに文句はありませんので、まったく構わないのですが、飛行機に乗っている間くらい、メールに追いかけ廻されたくない、冗談じゃない! ・・・という人も多いのでしょうね。

話は変わりますが、今回は GSM の有難味を感じる旅でもありました。 モバイルまで転送するメールの量は人それぞれなので一概には言えませんが、(とても少ない)Agile_Cat の場合は、今日までのところで約 100通の MMS を受信して、以下の料金でした。設定いらずで、まったく面倒の無いことを思えば、料金の 4,470 円は仕方ないのかと思います。 予備として持ってきたモベルの SIM は、これでもう、更新しないことになるでしょう。

SB の通信料 世界対応ケータイ(MMS) 4,470円
SB の通信料 世界対応ケータイ(パケット) 2,698円

パケットの方の 2,698 円というのは、アトランタで最初に乗り継ぐ際の、Bolingo につながったつもりで、GSM ローミングから Twitter に接続してしまったときの、痛恨のワンクリックです。 10数時間分のツイートが、ドドッと入ってきたわけですが、この程度で良かったと、ほっとしているところです。 Symbian の Gravity という Twitter クライアントには、接続先を WLAN や特定の AP に限定するオプションがあるのですが、こうした間違いを予防するための機能なのだと、大いに納得してしまいました。

ーーーー 訂正追記 ーーーー

ひと眠りして起きてみたら、以下のような料金に・・・  おそらく、上記のものは途中まで。MMS は 1日あたり 約2,000円なので、最終的には12,000円くらいで、1本 受ける度に100円が消えていく計算? それと、パケットは、Ovi Store か Boingo のクライアントを、それも寝ぼけて2回も DL したときの料金が加算されたもよう。 どうしても PC では落とせなかったんだ(涙) これ以上、パケット代が増えなければ、そういうこと。。。つまり、ちゃんと上手く使えば、0円にできるはず。

SB の通信料 世界対応ケータイ(MMS) 8,180円
SB の通信料 世界対応ケータイ(パケット) 9,414円

シカゴ発、ミネアポリス行きの便ですが、残念ながら GO GO FLIGHT をサービスしていない機種でした。 それにしても、残念!

ーーーー ここまで ーーーー

GO GO FLIGHT みたいなものが国際線でもサポートされると、3G と GSM と WiFi がシームレスつながって、ほんとうの意味でユビキタタスになるのですね。 あちらへ、こちらへと、移動が多くて疲れましたが、動かないと分からないことも沢山あるという、本来の仕事とは別の視点での、収穫の多い出張でした。

ーーーーー

さぁ~て、これでひと眠りして起きれば、明日は帰路につけます。 海苔と梅干と御飯に味噌汁だなっ、やっぱり。 ーーー A.C.

ーーーーー

<関連>
Boingo で Wifi は OK、そして Twitter の位置補足が・・・(US 出張編_1)
スマートグリッドを Hadoop で (US 出張編_2)
スマートグリッドを Hadoop と OpenPDC で(US出張編_3)
Data Center Knowledge について ご意見を・・・(US出張編_4)
Boingo 接続の勝敗表など(US出張編_5)
Microsoft IT PAC:初の導入は、第二期 Quincy になるのか? (US 出張編_6)
GO GO FLIGHT で空から Twitter (US 出張編_7)

Tagged with: , , , ,
%d bloggers like this: