ちょっとプチ贅沢な2,000円台のワイン

　ブログタイトルを入力すると、ワインをサジェストされることに気がついた今日ころ頃です。昨年末にワインネタを出したところかなり好評だったので、今年も少し紹介します。今回は2,000円台のワインです。ちょっとプチ贅沢したい時に、いかがでしょうか？この価格帯だと、お店で飲むと7,000〜10,000円位するので、家飲みのお得感ご出てきますね。
　選定の基準としては、私の好みです。殆ど赤しか飲みません。また、ピノ・ノアールよりカベルネ・ソーヴィニヨンとか、ジンファンデルのような、割としっかり目のワインが好きです。その辺りを考慮の上で見てください。

シャトー・モンペラ

---

　神の雫で一躍有名になったワインです。割と手に入りやすく安定して美味しいです。

NIKKEIプラス1　何でもランキング第3位！【初出し特価】シャトー・モンペラ[2011]（赤ワイン）[Y][J][E]

ケンダル・ジャクソン

---

　こちらもカベルネ・ソーヴィニヨンです。濃いので肉と一緒にどうぞ

ケンダル ジャクソン ヴィントナーズ リザーヴ カベルネソーヴィニヨン[2012] ≪お一人様3本限り≫KENDALL JACKSON VINTNER'S RESERVE CABERNET SAUVIGNON[2012]

ベイビーバッドボーイ

---

　ラベルが特徴的で、覚えやすいです。上の二つに較べて軽くて口当たりが良いので、女性に人気のようです。ら

[2010] ベイビー・バッド・ボーイ 750ml 1本 Baby Bad Boy

カレラ　ピノ・ノワール

---

　カリフォルニアのピノ・ノワール。通称カリピノ。ブルゴーニュに比べると、手軽で飲みやすいのが多いです。女性に人気の一本だと思います。

【正規品】カレラ　セントラルコースト　ピノノワール[2012]≪お一人様３本限り≫　Calera Central Coast Pinot Noir [2012] △

レンウッド　ジンファンデル

---

　アメリカのジンファンデル。2,000円台でかなりボリュームがあって美味しいです。赤ラベルのが2,000円台でお手頃です。しかし、ネットで売っているところを見つけられませんでした。ヴィノスやまざきで、在庫豊富だと思います。
http://kitadaya.co.jp/shopdetail/001000000056/

レイヴェンスウッド　ナパヴァレー　ジンファンデル オールドヴァイン

---

　もう一本、カリフォルニアのジンファンデル。ジンファンデルといえば、Ravens Wood というぐらい、ジンファンデルで有名なワイナリーです。レイバンズウッドは1,000円台でも美味しいですが、やはり2,000円台だと1ランクあがります。

レイヴェンスウッド　ナパヴァレー　ジンファンデル オールドヴァイン[2011]レーヴェンス Ravens wood Napa valley　Oldvine Zinfandel[2011]△

デヘサ・ガゴ

---

　スペインの鬼才、テルモ・ロドリゲスのワインです。もう1ランク上の、ガーゴも美味しいですが、デヘサ・ガゴも捨てがたいです。ちょっと酸っぱい系ですが、それもまた良しです。

テルモ・ロドリゲス・コレクション　デヘサ・ガゴ　 （スペイン・トロ地区産・赤ワイン）750ml

ラ・アタラヤ

---

　スペインのワインです。オーク熟成でバニラのような香りがします。味の傾向としては、カロン・セギュールのような感じです。かなりお勧めです。

ラ アタラヤ [2012] 赤 750ml -スペインワイン-

まとめ

　飲んだ記録をロクに取っていなかったので、有名ドコロしか思い出せませんでした。反省。2,000円台だと、かなり美味しいのが増えてきます。外で飲み食いすると、これくらいの値段は簡単に超えてしまうので、家でちょっと良いワインというのも面白いのではないでしょか？
　あと、いいワインあったら教えてください。

See Also:
ワインの品種。まずは3つだけ覚えておけば大丈夫
私が旨いと思う、普段飲みの1,000円台のワイン
身も蓋も無い1,000円台のワインの選び方

クローラー／スクレイピングのWebサービス 「Kimono」のユースケース

　クローラー／スクレイピング Advent Calendar 2014の8日目です。あと、全部俺Advent Calendarも開催中です。

　クローラー/スクレイピングをするのであれば、是非知っておいて欲しいサービスが「Kimono」です。Kimonoは、KimonoLabsという会社が作ったクローラー/スクレイピングを行うWebサービスです。特徴としては、プラグインを入れてブラウザの操作のみでスクレイピングができることです。操作を覚えれば、ITエンジニアでなくても充分使いこなせると思います。
　Kimonoの使い方については、プログラミング・レスで5分でサックリWebスクレイピング「kimonolabs」というエントリーで紹介しています。今回は取得したデータの利用方法とユースケースを考えてみたいと思います。

Kimonoで収集したデータの利用方法

---

　Kimonoで収集したデータは、API経由で参照できます。基本的には、APIを利用して表示用のプログラムを作成するという形になります。しかし、KimonoLabsが参照用のテンプレートを作成しているので、それを活用するという方法もあります。現在、KimonoLabsが提供しているテンプレートは、以下の６種類です。

1. メール送信
2. WebHooks
3. MobileApp
4. Embed
5. Google SpreadSheet
6. WordPress

　MobileAppとEmbed、WordPressは基本的には同じです。URLもしくはHTMLが吐き出されるので、任意の場所に埋め込むという形です。MobileAppの場合は、URLをアプリとして登録するといった形になります。興味深いのが、Google SpreadSheetとWebHooksです。Google SpreadSheetについては、同じくChromeの拡張を入れた上でKimonoからスプレッドシートに関する操作権限を付与することで、データを取得したタイミングで直接書き込めるようにします。WebHooksについては、データ取得に任意のURLを呼び出すという機能です。呼び出された先の方で、リクエストをキーに処理を書いておけば基本的には何でもできます。
※ちなみに、Google SpreadSheetについては、メインのアカウントで使うには少し怖いのでまだ試していません。そのうちに、Kimono用のアカウントでも作って試そうかと考えています。

Kimonoのユースケース

---

　上記機能のユースケースとして考えられるのは、まずは可視化です。単純な例でいうと、グラフや時系列で見えるようにすることです。そういう意味で、GoogleのSpreadSheetに直接流し込めるのは、非常に面白いです。自分ならどう使うかというと、WebHooksを利用して後続処理を何らか作ります。図にすると次のような形ですね。

　今の御時世だと、全部サーバレスで作れそうな勢いです。GoogleのBigQueryもいい加減試してみたいのですね。

まとめ

---

　AWS Lambdaが登場して、サーバ不要でバッチ的な処理が実行できるようになってきています。そして、Kimonoのように最近のWebサービスは、システム間を疎結合でつなぐ為の方法を当たり前のように出してきています。そうなると今までのように、自前のサーバで１から１０まで全部実装するという考え方は、確実に時代遅れになってきています。この辺りの流れに上手く乗っかれば、小さな労力で面白い仕組みが作れるようになっていると思います。チャレンジしたいものですね！！
※大ヒットしたら最初のアーキテクチャでは耐えられないという場合もあるでしょうが、そうなってから考えれば充分です。

See Also:
KimonoLabsと今後のサービスのあり方のはなし
プログラミング・レスで5分でサックリWebスクレイピング「kimonolabs」

参照：
クローラー／スクレイピング Advent Calendar 2014
全部俺Advent Calendar

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

AWSのアカウント管理の話

　　AWS Advent Calendar 2014の7日目です。あと、全部俺Advent Calendarも開催中です。

　運用絡みで何か書くと宣言したので、AWSのアカウント運用について書いてみます。テクニックや技術より、考え方の面での整理です。

AWSのアカウントの種類

---

　AWSで利用するアカウントは２種類あります。AWSアカウントとIAMアカウントです。AWSアカウントは、マスターアカウントと呼ぶこともあって大元のアカウントになります。AWSにサインアップ時に作るものが、AWSアカウントで１つだけ存在します。それに対して、IAMアカウントはユーザアカウントです。AWSの管理コンソールから、個々のユーザ向けなどに作成します。

AWSアカウントの取扱について

---

　AWSアカウントは、全権限を持っています。強力すぎるアカウントで、日常の運用に利用するには危険すぎます。日常の運用には使わないというのが基本となります。また、デフォルトではメールアドレスとパスワードのみで認証となります。アカウント作成した段階で、二要素認証の導入を強く推奨します。
　AWSでの二要素認証には、ハードウェアまたは仮想MFAデバイスを利用できます。ハードウェアについては、AWSのページから購入可能です。現在は、キータイプのものとカードタイプのものの２種類が購入可能です。仮想MFAデバイスについては、スマホやPCにインストールして利用します。iOSであれば、GoogleのAuthenticatorなどがあります。PCの場合は、Chromeの拡張などを利用すると便利です。
　AWSアカウントのMFAの選定については、どのような利用をするかがポイントになります。何故ならAWSアカウントには、接続元のIPアドレス制限が出来ません。その為、特定の場所からのみしか接続できないという運用を確実に行うには、物理MFAを設定して持ち運べないようにする必要があります。具体的なアドバイスとしては、金庫を買って放り込んでおくのが確実です。

IAMアカウントの取扱について

---

　IAMについては、IAMユーザとIAMグループ、IAMロールがあります。IAMユーザは個々のユーザに配布するもので、上の方でIAMアカウントと呼んでいたものです。IAMグループは、IAMユーザに所属させることにより一括で権限管理が出来るようになります。IAMロールはインスタンスに紐付けるものです。
　AWSを運用する上では、IAMの利用が基本となります。まずIAMユーザとグループの使い分けですが、組織で利用する上ではIAMユーザには基本的には認証の情報のみ設定し、権限に関する情報を付与しない方が良いと思います。理由としては、ユーザごとの設定で漏れなどを発生する確率を少しでも下げるためです。またそれ以前のAWSの仕様として、IAMユーザに付与できるポリシーのバイト数がIAMグループより小さいということがあります。その為、IAMユーザには複雑なポリシーを付与しにくいです。図でまとめると次のような形になります。

IAMのポリシー設計について

---

　IAMで利用できるリソース等をIAMポリシーと呼びます。ポリシーについては、許可（Allow）/禁止（Deny）を組み合わせて記述します。記述の際には、３つの原則を理解しておく必要があります。

1. 初期状態では、どの機能も利用することが出来ない（デフォルト拒否）
2. 許可を付与することで、指定されたリソースが利用できる
3. 同一の条件で、許可と禁止の両方を指定された場合は禁止になる（明示的拒否の優先）

　マトリックスにすると、次のようになります。

　じゃぁ必要なものだけ単純に許可していけば良いかというと、そうでもなかったりします。例えば、EC2やS3といったサービスレベルであれば、それでも問題はないです。しかし、EC2のネットワーク機能を除いてといったことをすると、途端にややこしくなります。方法としては、EC2の機能を全部許可した上でネットワークに関するアクションを明示的に拒否していく（Allow-Deny）か、ネットワーク以外のアクションを許可していくということで実現できます。許可制の場合であれば、アクションが増える度に追加していく必要があり面倒くさいです。かつ、アクションが増えても明示的にアナウンスされることはないです。それならば、Allow-Denyで行くかというと都合が悪いケースもあります。
　例えば、機能単位でグループを作っていって、複数のグループに所属させることによってユーザの権限の強弱をつける場合があります。この場合のメリットとしては、個々のグループのポリシーをシンプルに保てるという点にあります。しかし、この方法だと拒否優先の原則が有るために、グループ重ねの効力が発揮されないケースが出てきます。

　そんな時に重宝するのが、NotActionです。NotActionは、指定されたものを反転して許可します。Allow-Actionでec2を指定した場合は、ec2が許可されます。Allow-NotActionでec2を指定した場合は、ec2以外の全てのリソースが許可されます。ややこしいので図にすると次のような形になります。

　それぞれのポリシーは、次のような形です。

{
  "Statement":[
    {
      "Effect":"Allow",
      "Action":"ec2:*",
      "Resource":"*"
    }
  ]
}
{
  "Statement":[
    {
      "Effect":"Allow",
      "NotAction":"ec2:*",
      "Resource":"*"
    }
  ]
}

IAMのポリシーの管理について

---

　ストレートにCloudFormationで記述して、Gitなどのバージョン管理システムで管理しておきましょう。ポリシー自体をExcel等で管理しようとすると大変です。（ポリシー設計をExcelで管理するのは、別に構わないと思います。）

まとめ

---

　NotAction便利だよと書きたかっただけです。あまり日本語の情報はありません。ちょっとでも知られるキッカケになればと思います。後は、セキュリティを高める為には、やはりアカウントの適切な運用が第一歩だと思います。その辺りについての知見が共有されるようになればと思います。

See Also:
クローラーとAWSが出会ったら？第3回Webスクレイピング勉強会@東京
Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き
アプリケーション・サーバのセッションの保存先の話

参照：
AWS Advent Calendar 2014
IAM Policy Statementにおける NotAction / NotResource とは？ : Developers.IO
Permissions and Policies - AWS

Ruby+Mechanizeで対話型のスクレイピング

　クローラー／スクレイピング Advent Calendar 2014の6日目です。あと、全部俺Advent Calendarも開催中です。

　リクエストがあったので、Mechanizeを使ったスクレイピング方法についてです。Mechanizeは、対話型の処理を得意とするスクレイピングの補助ツールです。対話型とは、例えばIDとパスワードを使ってログインするようなサイトなので、それぞれ項目に入力して次のページに遷移するような行為です。

Mechanizeのサンプルソース

---

　下記は、Amazonアソシエイトサイトから売上を取得するサンプルです。

require 'mechanize'

uri=URI.parse('https://affiliate.amazon.co.jp/')
agent = Mechanize.new
agent.user_agent_alias = 'Mac Safari'
page = agent.get(uri)
next_page = page.form_with(:name => 'sign_in') do |form|
  form.username = 'your_username'
  form.password = 'your_password'
end.submit
puts next_page.search('//*[@id="mini-report"]/div[5]/div[2]').text

　Mechanizeのオブジェクトを作成し、ユーザエージェントなどの属性情報を指定します。次に対象のURIを指定して、ページを開けます。ページを開くと、入力する対象のフォームを探します。幾つか探し方はありますが、今回はフォーム名で探しています。そして、フォーム中のユーザ名とパスワードにそれぞれ入力しサブミットしています。
　次のページでは、xpath形式で取得対象の情報を指定してデータを抜き出しています。Mechanizeも、データのスクレイピングにはNokogoriを内部的に利用しています。

Mechanizeが得意とする処理と苦手とする処理

---

　Mechanizeの基本は対話型の処理になります。その為、ページごとに必要な処理を記述する必要があります。その為、認証が必要なページやPOST送信が必要な場合には、絶大な威力を発揮します。反面、サイト内をくまなく巡回して、全てのリンクを取得するといったような処理は苦手とします。出来ないことはないですが、記述する処理量が多くなり非効率となります。

感想

---

　Mechanizeは、Rubyによるクローラー開発技法でも少し取り上げています。しかし、あまり詳しくは書いていない為、もっと色々書いてというリクエストを受けます。根強い人気なんだなぁと度々実感しています。今回はホンのさわり部分だけなので、いつか掘り下げて取り扱おうと思います。

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

賃貸物件でも食洗機！！

　一度食洗機付きの物件に住んでから、その便利さの虜になっています。そんな中、今年の7月に引っ越しました。当然といえば当然なのですが、引越し先の物件には食洗機がついていませんでした。ということで、食洗機を取り付けられるよう色々動きました。

不動産屋経由でオーナーに設置の確認

---

　不動産屋経由で確認したのですが、今住んでいる物件のオーナーは高齢の人らしく、そもそも食洗機はという状態だったようです。そこで、食洗機の写真や蛇口の改修についての説明資料を送りました。蛇口の根本部分を交換するだけなので原状回復可能ということを強調したら、あっさり許可が取れました。

食洗機の選定

---

　許可が取れたので、次は食洗機の選定です。食洗機は主に据置型とビルトインタイプがあります。後者はシステムキッチンと一体なので、さすがに賃貸では導入は難しいです。そこで、据置型を選びました。据置型の食洗機なのですが、選択肢としてほぼPanasonicしかありません。だから選定としてはサイズと型を選ぶくらいしかありません。
　食洗機の選定としては、機能より大きさが重要になります。つまり一度にどれだけの量を洗えるかがポイントですね。店頭で実物を見るのが一番良いのですが、食洗機は意外に大きいです。しかし、大きくても洗える量は少ないです。だから、台所における範囲で一番大きなものを選ぶのがベストだと思います。他の作業スペースの圧迫など、トレードオフとの戦いになります。私は、「食器洗い乾燥機 NP-TR7-W」を選びました。

設置ビフォー・アフター

---

　こんな感じの流しです。

　まず蛇口部分に分岐をつけます。

　あとはドンと置くだけです。

食洗機の購入先の選定について

---

　Amazon大好きな私ですが、食洗機はヤマダ電機で買いました。理由としては、蛇口等の取り替えが必要なので、それに合う規格の部品を見繕ってもらう必要があったからです。ヤマダ電機の場合、一度下見に来て取り付け可能および部品の見積もりを行ないます。他の家電量販店でも恐らく同じプロセスをとると思います。

感想

---

　食洗機最高！！賃貸の人も諦めずにチャレンジしてみてください。Amazonのページから、パナソニックに直接電話で相談できるみたいなので、近くに量販店がない場合も電話で聞いてみるのもありかもしれません。

See Also:
賃貸でも工事なしで付けられるワイヤレスドアモニタ　パナソニックのドアモニ　VL-SDM110
賃貸でも工事無しでパラボナアンテナをつける方法。
プログラマになりたい Advent Calendar 2014

パナソニック 食器洗い乾燥機 NP-TR7-W ホワイト

パナソニック(Panasonic) 食器洗い乾燥機用分岐栓 CB-SXH7

除菌ハイウォッシュジョイ ボックス 700g

Ruby+Nokogiriでスクレイピング入門

クローラー／スクレイピング Advent Calendar 2014の5日目です。あと、全部俺Advent Calendarも開催中です。

　Webからデータを取るためにスクレイピングする際は、Rubyを使うことが多いです。理由としては、Nokogiriが手軽で簡単だからの一点です。Rubyによるクローラー開発技法でも随所に紹介しています。随所というレベルではなく、手を変え品を変えNokogiriでデータ取っているだけじゃねぇかと批判を受けるのではと、懸念するレベルかもしれません。Nokogiriは手軽で便利なので、ちょっと使い方を覚えておくだけで楽できるケースが一杯あります。ということで、Nokogiri入門編です。

Nokogiriの使い方

---

　Nokogiriは、Rubyで実装されたHTML/XMLの構文解析器（パーサー）です。Rubyの中では、デファクト・スタンダードと言っても差し支えがないでしょう。XPathやCSSセレクタを利用して、目的の要素を特定し抜き出します。このデータを抜き出すことをスクレイピングと呼びます。Scrape（削る）という意味ですね。
　下記の例は、nokogiriの公式サイトから、ページ中のリンクを全部取得している例です。

scrape.rb

require 'nokogiri' 
require 'open-uri'
doc = Nokogiri.HTML(open("http://nokogiri.org/")) 
doc.css('a').each do |element| 
    puts element[:href]
end

　実行すると次のようになります。

$ ruby scrape.rb 
/
http://rdoc.info/github/sparklemotion/nokogiri
https://github.com/sparklemotion/nokogiri
/tutorials/installing_nokogiri.html
/tutorials/
/tutorials/getting_help.html
/tutorials/installing_nokogiri.html
/tutorials/parsing_an_html_xml_document.html
/tutorials/searching_a_xml_html_document.html
/tutorials/modifying_an_html_xml_document.html
/tutorials/ensuring_well_formed_markup.html
/tutorials/getting_help.html
/tutorials/more_resources.html
//github.com/sparklemotion/nokogiri.org-tutorials
//octopress.org/
//github.com/coogie/oscailte

ソースの解説
　requireで、nokogiriの他にopen-uriというモジュールを呼び出しています。nokogiriはあくまでテキストの文章からデータを抜き出すだけなので、Webからhttp通信でデータを取得することはできません。そこで、open-uriを利用します。open-uriはopenを拡張し、ファイルと同じような形でURLを扱うことが出来ます。
　その習得したHTML文章を、Nokogiri.HTMLで開いて、Nokogiriのドキュメント形式に変換したオブジェクトを作成しています。このオブジェクトはHTMLデータを内包しているので、Nokogiriのメソッドを利用して様々な切り方でデータを取得することができます。

doc.css('a').each do |element| 
    puts element[:href]
end

　この例では、CSSセレクタを利用してaタグのものを全部抜き出しています。それを順次elementという変数に格納しています。そして、elementの中から、href属性の値を取り出して表示しています。Nokogiriには多数のメソッドやエイリアスがありますが、基本的には全てこれと同じことをしています。

1. 取得する切り口を決定（xpath,cssセレクタ等）
2. 取得する対象を決定（パス、id、クラス指定等）
3. 取得したデータに対する操作

検索色々。id指定とclass指定、上位からのタグ指定などがよく使うのではないでしょうか？

#class指定でh2タグを検索
puts doc.xpath("//h2[@class='title']")

#id指定でdivタグを検索
puts doc.xpath("//div[@id='copyright']")

#カスタムの属性値でdivタグを検索
puts doc.xpath("//div[@data-component-term='tweet']")

#id指定で全てのタグを検索
puts doc.xpath("//*[@id='copyright']")

#絞込検索
puts doc.xpath("//div[@id='copyright']//ul")

#上位からのタグ指定
puts doc.xpath("//html/body/article/p[34]")

　かなり簡単な説明でしたが、Nokogriを使ったスクレイピングの入門編です。以前、内部の構造含めてもう少し詳しく説明したエントリーを書いたので、興味があればそちらの方も読んでみてください。色々な言語でスクレイピングしましたが、Nokogiriはかなり使いやすい部類だと思います。それでは、迷惑を掛けない範囲で楽しんでください！！
　あと宣伝になりますが、クローラー／スクレイピングの作り方をこってり解説したRubyによるクローラー開発技法という本も書いています。初心者〜中級者向けですので、興味があれば是非ご覧ください。

See Also:
RubyでWebスクレイピングの話をしてきました。第1回Webスクレイピング勉強会@東京
Ruby製の構文解析ツール、Nokogiriの使い方 with Xpath
あらためてRuby製のクローラー、"anemone"を調べてみた
オープンソースのRubyのWebクローラー"Anemone"を使ってみる

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

何故JSONPでJavaScriptのクロスドメイン通信ができるのか？

一人Advent Calendarの3日目です。

　JSONPを使って外部のAPIを呼び出して、結果を取り込むということは色々なところで行われています。しかし、そもそもJavaScriptを利用した場合、クロスドメイン通信が使えないという前提があります。JSONPだったら、何故そこを回避できるのでしょうか？あまり詳しく考えたことが無かったので、簡単に調べてまとめてみました。なんというか4周くらい遅れている話題ですが、気がついた時に整理するとスッキリします。

JSONPの動作原理

---

　Wikipediaさんをみてみると、そのものずばりのことが書かれています。scriptタグ内のsrc属性は別ドメインのURLを指定できるという点と、そのレスポンスはJavaScript関数呼び出し形式になるという点をついたのが、JSONPの動作原理です。なんというか、仕様の考慮不足を利用した仕組みだと思います。
JSONP - Wikipedia

ブラウザなどに実装されている「同一生成元ポリシー」という制約により、Webページは通常、自分を生成したドメイン以外のドメインのサーバと通信することはできない。 しかし、HTMLのscriptタグのsrc属性には別ドメインのURLを指定して通信することができるという点を利用することによって別ドメインのサーバからデータを取得することが可能になる。
JSONPでは、通常、上記src属性のレスポンスの内容はjavascript関数呼び出しの形式となるため、src属性に指定するURLにその関数の名前をクエリ文字列の形式で付加する。一般的な方法では、この時に指定する関数名はWebページ側ですでに定義されているコールバック用の関数の名前になる。

　しかし考えてみたら、他のサイトに設置されたJavaScriptを呼び出して使うというのは、当たり前のようにやっていますよね。

<script src="http://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

JSONPはそれに対してデータを返す形式を、呼び元と呼び先でお互いに決めておくことで成り立っています。
図にすると、こんな感じだと思います。

jquery.xdomainajax.jsの謎

---

　両者のお約束の元に成り立っているのがJSONPです。一方で、どんなサイトからでもデータをとってこれるという謎のプラグインがあります。jquery.xdomainajax.jsです。スクレイピングで利用されることが多いのですが、どうやってるのかなぁと思っていました。JSONPの原理を理解した上でソースを見ると、一目瞭然でした。 Yahoo! Pipesをかまして、JSONP形式に変換しています。

　Yahoo! Pipesの太っ腹さに依存したライブラリです。外部サービスに依存したモジュールという異色の存在なのかもしれません。

感想

---

　長年何となく気になってて放置してたものを、ちょっとだけ調べてみました。10分くらいの調査で直ぐ解るので、気になったことはちゃんと調べるに限りますね。もし理解が間違っていたら教えて下さい。

See Also：
プログラマになりたい Advent Calendar 2014