Agile Cat — in the cloud

Microservices の調査:Amazon.com におけるマイクロサービス・アーキテクチャとは?

Posted in Amazon, DevOps, On Monday by agilecat.cloud on May 11, 2015
Microservices: The Rise of the Minimal Component Architecture
By Dick Weisinger – May 8th, 2015
http://formtek.com/blog/microservices-the-rise-of-the-minimal-component-architecture/
_ formtek
Microservices are lightweight fine-grained services that can be deployed with middleware or brokers.  The idea behind the approach has been around for some time, but a convergence of technologies, like the cloud, containers and REST/JSON services is making the approach more possible to achieve.
 
Microservices とは、ミドルウェアやブローカーを用いてデプロイすることが可能な、軽量で粒度の細かなサービスのことである。このアプローチの背景となる発想は、ときおり目にすることができるが、クラウドおよびコンテナや REST/JSON といった集約型テクノロジー (convergence of technologies) を、より現実的なものにするための方式だと言える。
 
Rather than build monolithic applications using “big balls of mud with tangled spaghetti code“, a microservice architecture builds many small and focused components that can easily communicate with each other.
 
Dali_11つまり、「もつれたスパゲッティ・コードによる大きな固まり」を用いて、モノリシックなアプリケーションを構築するのではなく、コンポーネントにフォーカスした Microservice アーキテクチャにより、小規模なコードを構築することで、簡潔に相互通信させていこうという考え方に基づいている。
 
Owen Garrett, head of product for Nginx, recently described how Amazon is using microservices.  ”When you go to Amazon.com and type in Nike shoe, over 170 individual applications get triggered potentially from that search — everything from pricing to images of the shoes to reviews of the shoes to recommendations of other products you may want to purchase. Each of those were individual services or subfeatures, if you like, of an application or an overarching experience, and all those were connected via HTTP. Each might be built in different languages. Each of those may have different requirements in terms of the data store, in terms of scaling and automation. Those were the attributes that we saw that were the fundamental anatomy of microservices architecture.”
 
最近のことだが、Nginx の Head of Product である Owen Garrett が、Amazon も Microservices を活用していると記している。具体的に言うと、「 Amazon.com で Nike shoe とタイプすると、170 種類以上のアプリケーションが、起こりうる検索のためにトリガーされる。それにより、探しているクツの価格や画像といった情報から、購入する可能性のあるプロダクトに関するレビューやリコメンデーションに至るまでの、あらゆる可能性がカバーされることになる。 つまり、それぞれのトリガーされたコンポーネントは、あなたの好みのものを探すための、アプリケーションもしくは包括的なエクスペリエンスにおける、個々のサービスやサブ機能といったものであり、そのすべてが HTTP を介して接続される。また、それらが、同一の言語で構築されているとは限らない。さらに言えば、データストアの観点や、スケーリングと自動化の観点において、それぞれの要件を有する可能性もある。それらは、私たちが確認できる特性であり、また、Microservices アーキテクチャの基本的な解剖学だ」と述べている。
 
Benefits of the microservices approach include scalability, agility, and greater resilience.  More specifically, microservice benefits include:
 
Microservices アプローチのメリットそしては、スケーラビリティとアジリティに加えて、高度な弾力性が挙げられる。 それらを具体化すると、以下のようになる。
 
  • Individual components have simpler architecture and design
  • Each component can be built using the right tools and language for the task
  • The design promotes loose coupling and easier maintenance
  • Promoted distributed independent parallel product development
  • Works well alongside new technologies, like Docker
 
  • それぞれのコンポーネントは、シンプルなアーキテクチャとデザインを有する。
  • それぞれのコンポーネントは、そのタスクに応じた適切なツールと言語で構築できる。
  • そのデザインにより、疎結合の考え方と、容易なメンテナンスが促進される。
  • さらに言えば、自律分散型の開発が、平行していて進められるようになる。
  • そして、たとえば Docker のような、新たなテクノロジーとの協調が実現される。
 
Eric Knorr, writer at InfoWorld, wrote that “the payoff [of microservices] is manifold: Services can be updated individually, new applications can be built quickly from existing services, and management actually has greater visibility into who is responsible for what.”
 
InfoWorld のライターである Eric Knorr は、「 Microservices から得られるものは多様である。 つまり、それぞれのサービスを個別にアップデートすることが可能であり、また、既存サービスから新しいアプリケーションを迅速に構築することが可能であり、誰が何に対して責任を負うかという意味で、可視性の高い管理が可能になる」と記している
ーーーーー
On Mondayたしかに、Amazon で探しものをしていると、かなり昔の探しものとの関連性や、ちゃんとカテゴライズされた関連性が生きているという感じで、レビューやリコメンデーションが登場してくるので、ちょっと驚くことがありますが、それが Microservices の威力なのでしょう。 もちろん、それは以前から言われてきた考え方であり、理屈の上で優位性が論じられてきたものなのですが、このように説明してもらえると、とても分かり易いですね。_AC Stamp
ーーーーー
<関連>
Cloud Developer の調査: あなたは DevOp 派? Coder 派? それとも RAD 派?

Comments Off on Microservices の調査:Amazon.com におけるマイクロサービス・アーキテクチャとは?

Facebook エンジニア と Android ローエンド:積極的に使ってアジアを知る!

Posted in Asia, Facebook, Mobile by agilecat.cloud on January 23, 2015
Why Facebook Forces A Bunch Of Its Engineers To Use Terrible, Low-End Phones
http://wp.me/pwo1E-8e2 
Jillian D’Onfro – Dec. 7, 2014
http://www.businessinsider.com/facebook-low-end-phones-bad-network-conditions-2014-12
 
_ Business Insider
 
You might not expect to find many flip phones in the high-tech and free-food laden Facebook offices, but your expectations would be wrong.
 
ハイテクとフリー・ランチが自慢の Facebook オフィスで、数多くのフリップ・フォン(折りたたみ)を見かけるなんて想像もしないだろうが、それは間違った思い込みだ。
 
Facebook is creating a special lab filled with low-end Android smartphones,”crappy old flip phones,” and weak networking to help the company study the computing conditions in parts of the world like rural India that either have limited internet or none at all.
 
Facebook が立ち上げた特別なラボは、ローエンドの Android スマホと、安くて古いフリップ・フォン、そして、脆弱なネットワーキングで構成されているのだ。それにより、たとえばインドの農村のような、インターネットが供給されるにしても、きわめて制約が多いという世界における、コンピューティングの条件を調査することが可能になる。
 
Facebook with old Android
Not actually
Facebook employees
 
Developers have to try to use Facebook’s apps on super-old versions of Android so they can understand what it’s like for people in areas without good network connection.
 
ここでの開発者たちは、きわめて古いバージョンの Android で、Facebook アプリを使用しなければならない。したがって、条件の整ったネットワークに接続できない地域の人々のために、何をすれば良いのかを理解できるようになる。
 
“It’s easy to not have empathy for what the experience is for the majority of people in the world,” Facebook CEO Mark Zuckerberg told Time’s Lev Grossman of Facebook’s employees.
 
「 この世界の大多数の人々のために、どのようなエクスペリエンスを持つべきかと言っても、それに対して容易には共感してもらえない」と、Facebook の CEO である Mark Zuckerberg が、一人の従業員である Lev Grossman に語った。
 
So, the team manufactures empathy.
 
そして、このチームは、その共感を作り出すことになった。
 
“I force a lot of the guys to use low-end phones now,” Javier Olivan, Facebook’s head of growth, says. “You need to feel the pain.”
 
Facebook の Head of Growth である Javier Olivan は、「 私の役割は、より多くの従業員にローエンド・スマホを持たせることだ。 そうすれば、痛みを共有できる」と発言している。
 
And Facebook employees aren’t the only ones getting the terrible-phone treatment.
 
そして、いまでは、そんな旧式フォンの面倒を見るのが、Facebook の従業員だけではなくなってきている。
 
“We brought in some phones, like very low-end Android, and we invited guys from the Valley here—the eBay guys, the Apple guys,” Olivan says. “It’s like, ‘Hey, come and test your applications in these conditions! Nothing worked.”
 
Olivan は、「 私たちは、このラボに、きわめてローエンドの Android などの、いくつかのフォンを持ち込んでいる。 そして、eBay や Apple の、つまりシリコンバレーの仲間たちを招待している。ここに来れば、そこらじゃ有り得ない、特殊な条件でアプリをテストできるという感じで誘っている 」と述べている。
 
That pain is of one of the things motivating Zuckerberg’s work on Internet.org, an initiative which aims to bring internet access to everyone in the world. Facebook recently released apps in Zambia and Tanzania with content like Wikipedia, Google Search, and AccuWeather that local people can get and use for free.
 
ここで言う痛みとは、Zuckerberg が Internet.org を立ち上げた、動機の1つでもあるのだ。 この組織は、世界のすべての人にインターネット・アクセスを提供することを目標としている。 最近のことだが、Facebook は Zambia と Tanzania の人々に、Wikipedia/Google Search/AccuWeather などを使用できるアプリをリリースしている。 そして、それらの地域の人々は、それらを無償で利用できるのだ。
 
Read the rest of Time’s profile of Zuckerberg and Internet.org here.
ーーーーー
facebookタイトルには「アジア」キーワードを使ってしまいましたが、それ以外にも、南米やアフリカのマーケットもあります。 低品質のネットワーク環境で、Facebook を使う貧しい人々のことを考えると、Menlo Park のキャンパスで、こうした取り組みが進められていることが、とても嬉しく思えてきます。 そして、以前にポストした「Facebook が語るモバイル・チューニングの極意:これで途上国のインターネットも OK!」や、「Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!」といった抄訳を読み返すと、心から拍手を送りたくなってしまうのです。_AC Stamp
ーーーーー
<関連>
Facebook と Mark の途上国戦略:Coca-Cola スタイルの長期スパンで考えていく
Zuck が Cook に 一発かました:もっと Apple は、自分の顧客を大切にすべきだ!
iOS から Android へ : Facebook は優先順位を切り替えるのか?
2012年:ネイティブの Facebook App for Android が、最終テストの段階らしい!
2012年:Droid フードって Cat フードよりも 不味いの? Facebook さん・・・
2014 Agile Cat:大人になった Facebook の マトメ

Comments Off on Facebook エンジニア と Android ローエンド:積極的に使ってアジアを知る!

Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC by Agile Cat on December 11, 2014

Facebook Mobile Drops Pull For Push-based Snapshot + Delta Model
http://wp.me/pwo1E-85F
Monday, October 20, 2014
http://highscalability.com/blog/2014/10/20/facebook-mobile-drops-pull-for-push-based-snapshot-delta-mod.html

We’ve learned mobile is different. In If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong we learned programming for a mobile platform is its own specialty. In How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks we learned bandwidth on mobile networks is a precious resource.

私たちは、モバイルが別の世界のものであることを学んできた。If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong では、モバイル・プラットフォームのためのプログラミングが、独特のものであることを知った。そして、How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks では、モバイル・ネットワークの帯域幅が、きわめて貴重なリソースであることを学習した。

Given all that, how do you design a protocol to sync state (think messages, comments, etc.) between mobile nodes and the global state holding servers located in a datacenter?

それら、すべてのことを考慮して、ステート(メッセージやコメントなど)をシンクさせるためのプロトコルを、どのようにデザインすべきなのだろうか? ここでは、複数のモバイル・ノードと、データセンターのサーバーに置かれたグローバル・ステートの、同期について考えていく。

Facebook recently wrote about their new solution to this problem in Building Mobile-First Infrastructure for Messenger. They were able to reduce bandwidth usage by 40% and reduced by 20% the terror of hitting send on a phone.

最近のことだが、Facebook の Building Mobile-First Infrastructure for Messenger というポストにおいて、この問題に関する彼らの新しいソリューションが紹介されている。それによると、帯域幅の使用率が 40% まで、そして、スマホでの送受信を阻害する要因が 20% まで、削減できたという。

That’s a big win…that came from a protocol change.

それは、素晴らしい成功体験であり、また、プロトコルの変更にもたらされたものである。

<関連> Facebook が語るモバイル・チューニングの極意

Facebook Messanger went from a traditional notification triggered full state pull:

The original protocol for getting data down to Messenger apps was pull-based. When receiving a message, the app first received a lightweight push notification indicating new data was available. This triggered the app to send the server a complicated HTTPS query and receive a very large JSON response with the updated conversation view.

Messenger がデータをダウンロードする際の、オリジナルのプロトコルは Pull ベースのものであった。 このアプリはメッセージを受信するとき、新しいデータがあることを示す、ライトウェイトなプッシュ通知を最初に受信する。それは、アプリに対するトリガーであり、その結果として、サーバーへ向けて複雑な HTTPS クエリーを送信し、また、アップデートされた会話を取り込んだ、きわめて大規模な JSON レスポンスを受信することになる。

To a more sophisticated push-based snapshot + delta model:

Instead of this model, we decided to move to a push-based snapshot + delta model. In this model, the client retrieves an initial snapshot of their messages (typically the only HTTPS pull ever made) and then subscribes to delta updates, which are immediately pushed to the app through MQTT (a low-power, low-bandwidth protocol) as messages are received. When the client is pushed an update, it simply applies them to its local copy of the snapshot. As a result, without ever making an HTTPS request, the app can quickly display an up-to-date view.

私たちは、前述のモデルに代えて、Push ベースの SnapShot + Delta モデルに移行することを決めた。 この新しいモデルでは、クライアントは自身のメッセージに関する、イニシャルの SnapShot を取得する(一般的には、これまでの HTTPS Pull のみとなる)。 続いて、Delta アップデートが読み込まれるが、それはメッセージを受信した直後に、MQTT(リソースと帯域において負荷の少ないプロトコル)を介してアプリに Push されるものである。また、クライアントからアップデートが Push されるときには、ローカルに保持される SnapShot に、その内容がコピーされる。その結果として、これまでのような HTTPS リクエストを必要とすることなく、アプリはアップデートされたビューを表示できるようになる。

We further optimized this flow by moving away from JSON encoding for the messages and delta updates. JSON is great if you need a flexible, human-readable format for transferring data without a lot of developer overhead. However, JSON is not very efficient on the wire. Compression helps some, but it doesn’t entirely compensate for the inherent inefficiencies of JSON’s wire format. We evaluated several possibilities for replacing JSON and ultimately decided to use Thrift. Switching to Thrift from JSON allowed us to reduce our payload size on the wire by roughly 50%.

さらに、私たちは、メッセージと Delta アップデートから、JSON エンコーディングを切り離すことで、このフローを最適化した。もし、開発者のオーバーヘッドを最低限に抑えたかたちで、ヒューマン・リーダブルで柔軟なデータ転送を実現するなら、JSON は素晴らしいソリューションとなる。しかし、JSON における送受信の形式は、きわめて効率が悪い。 圧縮により、いくつかの問題は解決するが、JSON の固有の非効率性を、完全に補完することは不可能だ。私たちは、JSON を置き換えるための、いくつかの可能性について評価し、最終的には Thrift を使用することにした。JSON から Thrift へ移行することで、転送における実質的なサイズを、およそ 50% に低減できた。

On the server side Facebook also innovated:

Iris is a totally ordered queue of messaging updates (new messages, state change for messages read, etc.) with separate pointers into the queue indicating the last update sent to your Messenger app and the traditional storage tier. When successfully sending a message to disk or to your phone, the corresponding pointer is advanced. When your phone is offline, or there is a disk outage, the pointer stays in place while new messages can still be enqueued and other pointers advanced. As a result, long disk write latencies don’t hinder Messenger’s real-time communication, and we can keep Messenger and the traditional storage tier in sync at independent rates. Effectively, this queue allows a tiered storage model based on recency.

Iris は、メッセージングのアップデート(新しいメッセージやメッセージ・リードによるステートの変化など)で用いる順列キューのことであり、Massenger アプリに送信された最新のアップデートと、伝統的なストレージ階層において、別々のポインタを持つことが可能になっている。ディスクおよびスマホへのメッセージ送信が成功すると、それに対応するポインタが前進する。もし、スマホがオフラインであったり、ディスクに障害が発生した場合には、対象となるポインタを所定の位置に留めながら、新しいメッセージをキューに保持し、他のポインタを前進させることができる。その結果として、ディスクへの書き込みなどの、大きなレイテンシが発生しても、Messenger のリアルタイム通信を妨げることはない。 そして、Messenger のレベルと伝統的なストレージ階層を、それぞれの頻度で同期させることも可能だ。このキューの効率性により、新しい階層型ストレージ·モデルが実現する。

Delta based syncing strategies are very common in Network Management systems where devices keep a north bound management system in sync by sending deltas. The problem with a delta based approach is it’s easy for clients to get out of sync. What if changes happen at a rate faster than than deltas can be moved through the system? Or queues get full? Or the network drops updates? The client will get out of sync and it won’t even know it. Sequence numbers can be used to trigger a full sync pull if there’s an out of sync situation.

Delta ベースの同期ストラテジーは、ネットワーク・マネージメント・システムにおいて、きわめて一般的なものである。 そこでは、デバイスが Delta を送信することで、上位階層のマネージメント・システムとの同期を維持する。 Delta ベースのアプローチにおける問題点は、その同期のメカニズムから、クライアントが容易に逸脱してしまうことである。 何らかの変更が Delta よりも速く、対象となるシステムを介して移動することが、実際に起こり得るだろうか? また、キューが溢れると、どうなるだろうか? さらに言えば、ネットワーク上でアップデートが失われたら、何が起こるだろうか? いずれにせよ、クライアントは同期から逸脱し、起こっていることを知ることもできない。そのような場合には、シーケンス・ナンバーを用いる。 それにより、完全な同期を引き起こし、同期から逸脱している状況を解消できる。

It’s also good to see Facebook got rid of JSON. The amount of energy and bandwidth wasted on moving and parsing fat JSON packets is almost criminal.

Facebook が JSON から離れることは、別の観点でも歓迎すべきことだ。このような巨大なシステムが、重たい JSON パケットを解析して転送するために、膨大なエネルギーと帯域幅を消費することは、きわめて罪作りなことでもあるのだ。

ーーーーー

先日にポストした「Facebook が語るモバイル・チューニングの極意」に続いて、今回も Todd Hoff さんの記事を紹介することができました。途上国におけるモバイル通信の状況を前提とした、ストレスを最小限に抑えた環境を提供したいという、Facebook の一貫したストラテジーが見えてきますね。 ただ、これは、途上国だけの問題ではなく、たとえば日本においても、モバイル・トラフィックの大幅な削減という、大きなメリットをもたらすはずです。 そして、私たちが使用している大半のサービスは、① モバイル・デバイス、② モバイル・インターネット環境、③ バックエンド・テクノロジー、④ データセンター・インフラのバランスの上に成り立っているわけですが、とりわけ途上国においては、① と ② のケアが不可欠なのでしょう。

ーーーーー

<関連>

iOS から Android へ : Facebook は優先順位を切り替えるのか?
Facebook が キャリアの協会に参加 : 狙いは Internet.org だ!
Mark Zuckerberg と Internet.org : コネクティビティが社会経済をバランスさせる
Facebook とモバイルの巨人たちが、Internet.org を立ち上げた!
Facebook に続け : 10億に挑む Android と iOS

Comments Off on Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!

Twitter の Trend API は、XML から JSON-Only へと移行する

Posted in API, Twitter by Agile Cat on September 1, 2011

Twitter API Ditches XML For Trends: New Features Are JSON-Only
Adam DuVander, August 26th, 2011
http://blog.programmableweb.com/2011/08/26/twitter-api-ditches-xml-for-trends-new-features-are-json-only/

_ ProgrammableWeb

Twitter is embracing the trend where 1 in 5 new APIs do not support XML. The trend is playing out, appropriately enough, with Twitter’s endpoint for accessing global and local trending topics. It follows a move in late 2010 where Twitter Streaming went JSON-only. All signs point to no XML support for new Twitter features.

Twitter は、新しい 5つの API のうち、1 つが XML をサポートしないという流れを容認しようとしている。 こうした傾向においても、グローバルおよびローカルで流行っている、トピックにアクセスするための Twitter エンドポイントを、充分に機能させることが可能である。 そして、こうした方向性は、Twitter Streaming が JSON だけに対応するようになった、2010年後半から継承されている。 Twitter の新しい機能では、XML をサポートしないという方向へ、すべてが向かっているようだ。

imageThe move to JSON is brought on by Twitter’s consolidation of the three separate endpoints for accessing trends into a single endpoint. The one solution is built off of Yahoo’s WOEIDs (Where on Earth IDs). WOEIDs have been the basis of location-related Twitter calls since Twitter originally released location trends nearly two years ago. The identifiers were also central to the Mixer Labs’ GeoAPI acquired by Twitter in late 2009. Global trends will still be available using a WOEID of 1.

こうした JSON への移行は、シングル・エンドポイント内のトレンドにアクセスするために、3つのエンドポイントをコンソリデートさせるという、Twitter の考え方に応じたものとなる。 1つのソリューションは、Yahoo の WOEID (Where on Earth ID)から構築される。 約 2年前に Twitter が独自のロケーション・トレンドをリリースした時から、それに関連する基本として WOEID が利用されている。 この識別子は、2009年後半に Twitter が買収した Mixer Labs の、GeoAPI の中心にもなっている。 グローバル・トレントに関しては、依然として WOEID の 1 と用いることが可能である。

注記:http://developer.yahoo.com/geo/geoplanet/guide/concepts.html
http://4rapiddev.com/php/get-woeid-of-a-city-name-from-ip-address-with-php/

Twitter’s Jason Costa explained why Twitter is removing XML:

As well as standardizing the trends URL we are also planning to switch the trends API to JSON only. The reason for this is because the use of XML on the trends API is significantly low and removing support would allow us to free up resources for other developments.

Twitter の Jason Costa は、XML を排除していく理由につ体、以下のように説明している:

トレンド URL を標準化することに加えて、それらの API を JSON only に替えることを計画している。 その理由は、トレンド API 上での XML の利用が、きわめて低レベルのものであること、そして、サポートの負荷を減らして、他の開発にリソースを振り向けることにある。

Running down the data formats supported by Twitter’s various APIs, there is still plenty of XML support (as well as RSS and Atom), but some of the newer features are JSON-only.

Twitter における各種 API がサポートするデータ・フォーマットを調べると、依然として XML(RSS と Amtom も)が数多くサポートされているが、いくつかの新しい機能は JSON only になっている。

Twitter API Data Formats

image

As we wrote then the JSON-only Streaming API was announced, it seems clear that XML does not have much future at Twitter, at least with new features. Since so many applications count upon some of the oldest Twitter functionality, such as the core timeline, we’d expect XML to be supported for awhile, if not indefinitely. That said, Twitter hasn’t shied away from forcing developers to make updates before. After several delays, Twitter shut off basic authentication one year ago. Most recently the company implemented changes for applications accessing direct messages.

JSON only の Streaming API が発表されたと、私たちの記事に書いたときから、少なくとも Twitter の新しい機能においては、XML が 将来に渡って利用されることは無いと思われる。 しかし、Twitter のコアである TimeLine など、従来からの Twitter 機能を、数多くのアプリケーションが利用している。したがって、無期限ではないにしてもに、しばらくの間は、XML がサポートされることを期待するだろう。 しかし Twitter は、アップデートに先行して、デベロッパーたちに更新を強いるようなことはしない。1年前にも、数日の猶予の後に、基本的な認証を止めてしまった。また、最近においても、ダイレクト・メッセージにアクセスするアプリケーションを、Twitter は変更している。

ーーーーー

TAG indexこと、API に関しては、XML も徐々に役割を減じていくのでしょうかね。 ともあれ Twitter の API が最新の技術により更新されていくは、様々なデベロッパー・コミュニティに影響を与え、また、そこでのスキルも蓄えていきます。 いろいろな意味で、Twitter と API には、がんばって欲しいですね。 ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter の 圧倒的な API 消費量は、Facebook や Google の 3倍に達する
5 つのエクセレントな、クラウド開発コミュニティ
最新のミュージック・マッシュアップ API とは?
USA Today が提供する、アメリカ国勢調査の分析 AP

Comments Off on Twitter の Trend API は、XML から JSON-Only へと移行する

USA Today が提供する、アメリカ国勢調査の分析 API

Posted in .Selected, API, DaaP, Government by Agile Cat on June 23, 2011

Analyze 2010 U.S. Census Trends With the USA Today Census API
Allen Tipper, June 9th, 2011
http://blog.programmableweb.com/2011/06/09/analyze-2010-u-s-census-trends-with-the-usa-today-census-api/

_ ProgrammableWeb

The US Census is a treasure trove of valuable information for many people. From salesmen trying to market to curious people trying to learn about new cultural trends, the Census is a great source of information. Accessing this data in a computer readable form is sometimes difficult, however. The USA Today Census API simplifies the process, at least for the 2010 census.

アメリカ国勢調査は、数多くの人々にとって貴重な情報の宝庫である。たとえば、新しい傾向などに興味のある人々に対して、セールスの作戦を考えるとき、この国勢調査は素晴らしい情報源となる。 ただし、このデータを、コンピュータでアクセスして、読みだすことが難しいときがある。 しかし USA Today Census APIでは、少なくとも 2010年の国勢調査位について、このプロセスを単純化している。

From USA Today’s announcement:

clip_image001Since its founding, USA TODAY has focused on covering the entire country, not just one region or group of people. We cover who the American people are and how they live no matter where they live. One way we do this is to pay a lot of attention to demographic data. Our reporters analyze it constantly and talk to many people about what it means.

That’s why we’re excited to share the USA TODAY Census API. It’s a simple way to pull highlights from Census 2010 for tens of thousands of places. For these data points, we also have data available from Census 2000 to allow comparisons (though open access here is limited to 2010 data, please contact us at api@usatoday.com if you are interested in full access). Data includes basic demographics, such as population totals, and ready-to-use percentages for subjects such as race and housing vacancy.

USA Today のアナウンスメント

USA TODAY は創立時から、特定の地域や人々のグループだけではなく、この国の全土と、すべての人々にフォーカスしてきた。どこに住み、どのような生活していても、その人がアメリカ国民であれば、私たちは注目していく。 それを可能にする 1つの方法は、人口統計データの詳細にまで注意を払うことである。 私たちのリポーターは、それを常に分析し、また、その意味を多くの人々に説明する。

そこに、USA TODAY Census API を共有し、また、嬉しく思う理由がある。 つまり、数えきれないほどの地域について、Census 2010 からのハイライトを引き出すための、シンプルな方式が提示される。 それぞれのデータ・ポイントにおいて、Census 2000 から得られる情報を比較できる(オープンまアクセスは、2010年のデータに制限されるが、フル・アクセスに興味があるなら api@usatoday.com まで連絡して欲しい)。このデータには、基本的な人口統計が含まれており、選挙や空き家探しといった用途に、ただちに対応できる。

You can search info about Population, Race, and Housing for any area you choose, using intelligent keywords. You can get all of the data about a place, or just one of those, with different calls. Access to population history is available, but requires contacting them, and most likely paying an unspecified amount. Even with just the 2010 data, one could figure out a lot of useful things.

あなたは、インテリジェントなキーワードを用いて、人口、人種、住宅などの情報を、あらゆるエリアから検索できる。 また、ある地域の全データを入手することも、特定のデータを入手することも可能である。 人口の履歴へのアクセスも可能であるが、事前に確認して、データ量に応じた対価を支払うことになるだろう。 ただし、2010 年のデータだけであっても、有用な情報を得ることができる。

image

It would be great to see this API integrated into CityClash (pictured above), which I covered in April in a best new mashups post. CityClash provides city ratings and rankings by people.

この API を統合している CityClashは、適切な事例となるだろう。それは、4月の Best New Mashups Post でカバーされている。 CityClash は、人口データを用いた、都市の評価と順位を提供している。

The Census API is one of 8 USA Today APIs. Like the others, this one is RESTful. The Census API uses a mildly nonstandard JSON format, but most parsers should be able to deal with it. You will need an API key, which you can get at USA Today’s developer site. Although this one is free, be sure to read their Terms of Use, which include the need to give proper attribution when using their API. After jumping through those hoops, however, there’s a lot of great data there.

Census API は、USA Today が提供する 8種類の API の 1つである。 その他のと同様に、RESTful を使用している。 Census API は、標準とは言えない JSON フォーマットを使用するが、大半のパーサーにおいて、その取り扱が可能であるべきだ。 あなたは、API キーを必要とするようになるが、USA Today デベロッパー・サイトから入手できる。 それは無償であるが、必ず Terms of Use を読んで欲しい。そこには、この API を利用する際に必要となる、正式な権利関係が記されている。 それらの関門を潜り抜ければ、大量の素晴らしいデータが利用できるようになる。

ーーーーー

The USA Today って、アメリカでホテルに泊まると、毎朝 ドアの下から放り込まれる、あのタブロイド紙のことですよね。 これまで、手にとって眺めるということも、ほとんど有りませんでしたが、この記事を読む限り、言っていることと、やっていることが、キチッと噛み合っている新聞なのですね。 また、最近では 『 Facebook でプライバシーを護るための、8種類のプロテクション 』という記事が、USA Today からのものだったので、驚きました。というわけで、早速 Tech Blog を iGoogle に RSS フィードです。 ーーー __AC Stamp 2

ーーーーー

<関連>

すべてが API になるべきだという、FCC の主張とは?
Data.gov が存続の危機! Data 2.0 カンファレンスは救えるのか?
New York City の地下鉄では、クラウド API が吊り広告に?
2011 年の クラウド API について、5 つのポイントを予想する

 

Comments Off on USA Today が提供する、アメリカ国勢調査の分析 API

2011 年の クラウド API について、5 つのポイントを予想する

Posted in .Selected, API, HTML5 by Agile Cat on January 11, 2011

5 Predictions for APIs in 2011
By Shanley Kane Dec. 31, 2010, 10:00am PDT
http://gigaom.com/cloud/5-predictions-for-apis-in-2011/

_ Gigaom

In 2010, the rapid growth of the application- and mobile-driven Internet brought APIs to the spotlight, both in the web and the enterprise. Fueled by new device platforms and cloud computing, 2010 saw a two-fold increase in new APIs per month over the previous year. ProgrammableWeb’s API directory now includes more than 2,600 APIs.

2010年に急成長した、アプリケーションとモバイルがドライブするインターネットにより、Web とエンタープライズの双方における API がスポットライトを浴びることになった。 新しいデバイス・プラットフォームと、クラウド・コンピューティングからの需要により、2010 年における新規 API は、前年比の 2倍という勢いで毎月伸びてきた。 ProgrammableWeb の API ディレクトリは、いまでは、2,600 種類以上の API を取り込んでいる

At Apigee, which provides enterprise API management technology and free developer tools, we’ve seen the API market not only grow, but diversify, in 2010. APIs have given developers access to important data sets from government data to geolocation, and powerful services from semantic analysis to 3-D. As we head into 2011, here are five predictions for what’s next in APIs:

エンタープライズ API マネージメント・テクノロジーおよび、無料のデベロッパー・ツールを提供する Apigee では、API マーケットびが成長だけではなく、その多角化が 2010年の特徴として確認された。行政から地図にいたるまでの重要データ・セットへのアクセスや、文脈から 3D にいたるまでのパワフルなサービスなどが、API を介することでデベロッパーからのアクセスを実現した。2011年も継続して進んでいくとき、API に関する 5つの予測が浮かび上がってくる:

1. APIs Go Real-time, Big-time

“Real-time” was hot in 2010 as innovations in the API space brought the real-time web closer to reality. The PubSubHubBub protocol, which allows services to “push” notifications rather than forcing clients to poll for events, was implemented by the YouTube API team. Additionally, the high-profile launch of Twitter’s streaming API showcased market desire for APIs that allow real-time access to data.

API 空間のイノベーションとして注目された “Real-Time” が、リアルタイム Web の実現をたぐりよせた。 イベントのポーリングをクライアントに強制するのではなく、サービスからのプッシュを実現する PubSubHubBub プロトコルが、YouTube API チームにより実装された。 さらに、 Twitter のストリーミング API の提供開始が注目を集め、また、データへのリアルタイム・アクセスを実現するAPI に関する、マーケットの要求を明確にした。

The real-time web is currently led by innovative platforms like Notifo, a mobile notifications API that pushes notifications from many services to phones. In 2011, we can expect to see APIs take front and center in pushing real-time from the bleeding edge into the everyday.

このリアルタイム Web は、現在のところ Notifoなどの先進的な プラットフォームにより推進されており、多様なサービスからモバイル・デバイスへ向けて、通知などをプッシュするモバイル API を実現している。 2011年には、リアルタイムを最前線から日常へとリアルタイムをプッシュするための、テクノロジーの中心に API が居座るのを、私たちは見ることになるだろう。

2. Developers Will Adopt HTML5

This year, HTML5 was a new development darling. HTML5 makes it possible to create a better user experience — like the ones we expect from apps — in the browser. It also means developers don’t have to write new code to reach multiple platforms. With modest requirements for loosely connected devices in a time when reaching many devices is a strategic necessity, HTML5 combines the power of APIs with the ubiquity of browser access to provide a modern app experience that easily crosses platforms.

今年(2010)は、 HTML5 が開発者の話題をさらった。HTML5 は、これまでのアプリケーションから推測できる、より良いユーザー・エクスペリエンスを、ブラウザの中で実現する。さらに、それぞれのプラットフォームごとに、デベロッパーたちは新しいコードを書かなくてもよくなる。 ビジネス戦略的に多様なデバイスへのアクセスが欠かせないときに、それらを疎結合していくという適切な要件が生じるとしよう。 そのような場合において、容易にクロス・プラットフォームを実現する HTML5 は、最新のアプリケーション・エクスペリエンスを提供するために、ユビキタスなブラウザ・アクセスを用いて API を接続していく。

OpenAppMkt, an HTML5 app store, is an early indicator of HTML5 growth. We can also expect to see HTML5 support added on low-price-point, consumer electronics.

HTML 5 アップストアである OpenAppMkt は、 HTML5 の成長の先行して指し示している。 さらに、HTML5 サポートが、低価格のコンシューマ家電にも追加されると予期できる。

3. JSON Rises, XML Wanes

One of the biggest emerging stories in the API market is the ongoing debate of JSON vs XML support. JSON and XML are the two primary ways APIs exchange data. While many APIs have historically supported both, 2010 marked a turning point as both Twitter’s streaming API (sub req’d) and the Foursquare API ended XML support.

API マーケットに浮上している最大の話題は、JSON 対 XML という、サポートについて継続されている議論だ。 JSON と XML は、API によりデータを交換する際の、2つの主要な方式である。 歴史的に見て、数多くの API が双方をサポートしれきたが、 Twitter streaming API(sub req’d)と、Foursquare API が XML のサポートを終了させたように、2010 年は転機として捉えられている。

Why JSON? JSON is easier to use in JavaScript, an increasingly popular language for app developers. It is also lighter, requiring less processing, and is more readable by humans. As a result, developers often find it easier to use.

なぜ、JSON なのだろうか? JSON は、JavaScript 内での利用が容易であり、また、アプリケーション開発者の中で支持を高めている。 つまり、軽量であり、大量のプロセスを必要とせず、ヒューマン・リーダブルである。 その結果として、その活用が容易であることを、多くのデベロッパーが見いだしている。

In 2011, we can expect to see more API providers switch to JSON only. There are still benefits to XML, which means it won’t go extinct anytime soon, but for today’s app developer, the tides are turning toward JSON. Savvy API providers will be giving developers what they want – not just for the holidays, but for the whole year.

2011年には、さらに多くの API プロバイダーが JSON へ向けて、スイッチすると予期できる。 まだ、XML にはメリットがあり、近いうちに絶滅するというものではないが、いまのアプリケーション・デベロッパーたちは、JSON へ向けて流れる潮流に乗っている。 物事に精通している API プロバイダーは、デベロッパーが望むものを提供するだろう。 しかも、短期的なスパンではなく、長期的にだ。

4. More Companies to Redo their APIs — The Right Way

2010 saw several high-profile efforts by large companies – both consumer and enterprise – to offer more performant, usable APIs that conform to the REST principles that developers love. Salesforce.com launched a new REST API and made it a focal point of its Dreamforce conference. Foursquare also launched a new version of its API focused on speed, consistency and usability.

いくつかの、2010 年で注目すべき点は、コンシューマとエンタープライズにおける大手企業が、さらなる効率を求めて努力を惜しまなかったところにある。その結果として、デベロッパーに好まれる、REST の原則に準拠した有用な API が登場することになった。 Salesforce.com は新しい REST API を立ち上げ、それをDreamforce カンファレンスの焦点に据えた。 そして、さらに、Foursquare は、スピードとコンシステンシーとユーザビリティにフォーカスした、API の新しいバージョンを立ち上げた。

As developer adoption becomes a competitive necessity, more and more companies must re-focus on offering APIs designed for adoption: simpler, RESTful APIs that are easier to learn and implement. This will be especially significant in the enterprise as it adapts to the new standards of “web 2.0” development. Finally, as more and more API-centric companies (e.g., SimpleGeo and Twilio) prove that APIs are a product in themselves, API design that lowers the barrier to entry becomes tablestakes.

デベロッパーによる採用において、競合が避けられなくなるに連れて、それらの企業は、利用される API の再考を余儀なくされた。 つまり、RESTful API の学習と実装が、容易であるということだ。 そして、Web 2.0 による開発で、それらの企業が新しいスタンダードを採用するとき、RESTful API が特に重要になるだろう。 最終的に、より多くの API セントリックな企業(たとえば SimpleGeo や Twilio)が、自身のプロダクトとしての API を証明していくにつれて、参入障壁を引き下げる API デザインが、数珠つなぎになっていく。

5. API Frameworks Flourish

Although well-designed APIs make it easier to create apps, there’s still a market need for better ways to build APIs. 2010 marked several notable language-specific API frameworks that aim to help developers create usable APIs, including Grape for Ruby and FRAPI for PHP.

適切に設計された API によりアプリケーションは容易になるが、さらに良い方式で API を構築したいという、マーケットからの要求は依然として存在する。 2010 年の特色は、いくつかの言語に固有の API フレームワークであり、Grape for Ruby や FRAPI for PHP を含む有用な API の、デベロッパーによる作成を支援することになった。

In 2011, we’ll see this grow with dedicated API frameworks for node.js, Python, Java, .NET and more. These frameworks will be especially significant in language communities like Ruby that have seen a boom of adoption in the age of cloud services. The $212 million acquisition of Heroku by Salesforce.com reinforces that making life easier for these developers is key, and finding better ways for developers to build APIs, is a ripe opportunity for 2011.

そして 2011年には、node.js/Python/Java/.NET などに特化された、API フレームワークの成長を目にするだろう。 これらのフレームワークは、Ruby などの言語コミュニティで特に重視され、クラウド・サービスの時代に相応しい利用例を示していくだろう。  Salesforce.com が $212 million を投じた Heroku の買収は、デベロッパーが主体となる状況の容易な実現と、API 構築のための容易な方式の発見を際立たせていくだろう。つまり、2011 年は成熟のときとなる。

ーーーーー

Shanley Kane is on the product team at Apigee, dividing her time between the developer platform, community evangelism and enterprise API consulting. She helps organize several developer and hacker events in the Bay Area and is an avid gamer, novice coder and Carnegie Mellon graduate.

Shanley Kane は、Apigee のプロダクト・チームに在職し、デベロッパー・プラットフォームおよび、コミュニティ、エバンジェリズムに従事し、エンタープライズ API コンサルティングとしても活躍している。彼女は、何人かのデベロッパーを組織化し、Bay Area におけるハッカー・イベントを支援しているが、熱心なゲーム愛好家であり、また、初心者コーダーであり、Carnegie Mellon の卒業生でもある。

ーーーーー

@fhide さんから、以下の重要な情報をいただきました・・・

記事の冒頭に紹介されている「Apigee」ですが、無料サービスは米国内向けに公開されているため、日本からアクセスすると非常に「遅く」感じてしまうと思います。決してApigeeサービスの性能が悪いわけではありませんが、お気を付けください。

・・・ Fhide’s Blog もご参照ください: http://fhide.wordpress.com/

ーーーーー

お正月から ずっと気になっていた記事ですが、Mobile サイトの構築があったり、それが終わると Facebook 騒動や、Bob Muglia さんの辞任があったりして、なかなか手がつけられないというモヤモヤ状態にありました。 しかし、それも、スッキリ解消です 🙂 期待に違わず、とても面白い内容で、訳せてよかったと思っています。 ーーー  __AC Stamp 2

ーーーーー

<関連>
2倍に成長した 2010年の クラウド API – トレンドは Social と Mobile

 

%d bloggers like this: