Monthly Archives: March 2014

Safari Readerのコンテンツ抽出処理を調べる

Safari(とiOSのMobile Safari)にはReader機能というのがあって、ブログなどでコンテンツ部分だけを抜き出して表示してくれます。iOSにはあるのは知っていて、PC向けのページを読みやすくしてくれて便利なのでたまに活用していたのですが、PC版でもあるんですね。似た機能はPocketReadabilityにもあります。

でもこのリーダー機能、ボタンが出る時と出ない時があります。まあコンテンツ抽出ができない時は出ないんだろうなっていう推測はできるのですが、どのようにコンテンツ抽出しているのかなと。PerlのモジュールでHTML::ExtractContentというのがあるのですが、似たようなことやっているんだろうなって思っていましたが、しらべるとh1~h6の含まれるブロック要素で文字数が多いものが取られているっぽいとかブロックのサイズが云々とか色々観測結果が書かれていました。

しかし更に調べていくと、新事実が。Safari Reader Source Codeによれば、Safari ReaderはJavaScriptで実装されており、以下の手順を踏めばコードが読める。なんだってー。

  • Safariを一旦終了してブランクページを起動する
  • Readerが有効になるページを開く(ページ内のJavaScript次第でうまくいくページと行かないページが有りましたが、ここで例示されているページではうまくいきました)
  • ページがロードされ終わるのを待ち、WebKit Inspectorを開き、停止ボタンを一度だけ押す
  • リーダーボタンを押す

safari reader source Safari Readerのコンテンツ抽出処理を調べる

おお、よめた!

ということで、JavaScriptで書かれたコードを読むことができます。中を読むと要素のIDやClassに”article”、”body”、”content”、”entry”とか入っていたら可能性が高く、”comment”とか”advertisement”、”breadcrumb”、”disqus”とか入っていたら可能性が低いとか、縦横の表示サイズやエリア面積などなど様々なチェックを行っているようです。

DynamoDB Localでローカル開発環境構築

開発環境をローカルで構築すると、ネットワークのない環境でも開発ができるので非常に便利です。特に昨年は飛行機に乗る機会がとても多く、僕の乗っていた便はまだ機内インターネット接続サービスの恩恵は受けられない便ばかりだったので、飛行機の中でも開発を続けるためには、開発環境とドキュメントをローカルに入れておくのはとても重要でした。VagrantDashにはとてもお世話になりました。

さて最近DynamoDBを使ってサービス作っています。AWSのサービスは非常に便利でよいですが、DynamoDBはElastiCacheやRDSみたいにローカルにMemcachedやRedis、MySQL、PostgreSQLなど入れておけば代用できるわけでもないので、どうすんだろ、と思いました。

もう1点DynamoDBの問題として、DynamoDBの課金体系は保存容量以外に毎秒何回読み込みと書き込みができるかに対してお金を支払いますが、無料枠は、合計書き込み5回/秒、読み込み10回/秒までです。でもDynamoDBではグローバルセカンダリインデックスを用意すると、それぞれにつき少なくとも書き込み、読み込み1ずつ割り当てなければならないので、1つのテーブルが1回/秒で済まないケースもあって、本当にお試しでもない限り、無料枠をすぐ使い切っちゃいます。といっても、月数百円とかですむのですが、油断してて料金発生するのも怖い。

で、DynamoDBの互換のシステムをローカルで構築できる物があればいいのになって思って調べたら、Amazonが公式にDynamoDB Localなるものを公開していて、これを使ったらものすごく簡単にそれができてしまいました。

紹介記事は2013年9月ですがリンクは最新版を指すようになっていてダウンロードされたのは2014年1月8日版でした。2013年12月に発表されたグローバルセカンダリインデックスにも対応。Javaで書かれているのでjarファイルを実行すればサービスが起動してしまう。ポート番号はデフォルトが8000ですが、8000なんてなにか他のものと容易に衝突しそうなんでそこはは変えました。

それで、次はアクセスをしてみるのですが、開発はPythonを使うことが多いのでbotoを使いました。botoってconnectionの際にhostとportを指定できるようになってるんですね。

実際のDynamoDBのようにコンソールが用意されていてテーブル作成できるわけではありませんが、そもそもきちんとテーブル定義はコードとして残しておいたほうがいいですね。

AWSのブログ記事に以下の様なことが書かれています。

  • スループットの指定は無視される。スループット以上にアクセスすることはできてしまう。
  • アクセスキーとリージョンはDBファイル名を生成するときにだけ関係ある
  • シークレットキーは無視される
  • テスト用なので、プロダクション作らないほうがいいよ

ということで、これでとりあえずお金の心配も、ネットワークの心配もせずにDynamoDBで開発ができるようになりました。