dnsimple ではAPIからのDNSレコードアップデートができるので、簡単にダイナミックDNSがつかえる。

手順は以下の通り。

1. 普通にdnsimpleでAレコードを登録する
2. 登録したレコードのrecord idをしらべる。 record id は管理画面のURL https://dnsimple.com/domains/example.com/records/<record id>/edit をみればわかる。
3. レコードを更新するスクリプトをcronに登録する。 スクリプトは http://developer.dnsimple.com/ddns/ でダウンロードできる。 RECORD_IDには上記の値、DOMAIN_IDにはApexドメインを設定する。

TCPについて調べてたら、skeeterとbubbaという謎のオプションを見つけた。 調べてみたところ、TCPを策定した人達の黒歴史らしい。

• TCP options: Bubba and Skeeter

以下意訳です。

あー、これは忘れられそうもないんだけど黒歴史だね。

ben levyとstevと私¹ がFTPをやってたときにつくったものなんだ。 Bridghan²とstevがけしかけたんだけど、アイディアはシンプルで、鍵管理システムなしに暗号化できるように、デフィー・ヘルマン鍵共有をtcpで直接するためのものだった。 それには認証の仕組みは想定してなくて、パスワードみたいなものが共有されている前提だったんだ。 シンプルな実装で大体は動いてたんだけど、介入者攻撃には脆弱だったのが欠点だった。

なんで"skeeter"³ と"bubba"⁴ かって？それはstevに聞いてくれ。

なかなかセンスのあるネーミングですね。気になる人はstev氏に聞いてみてください。

参考

• Transmission Control Protocol (TCP) Parameters
• Re: [tcpm] IANA TCP options registry ...

このブログはgithub pages上に構築していますが、github pagesに引きずられて自分のブログも重くなるということが時々ありました。

がんばってブログを書いた次の日にアクセスできなくなってたりすると悲しいので何とか高速かつ安定した配信をする方法ないかなーと思って調べてみたところ、なんとgithub pagesに置いたコンテンツをCDNから配信させることができるようになったらしいです!

Faster, More Awesome GitHub Pages

どういうドメインでgithub pagesを配信しているかによって対応方法は違うので以下を読んで各自適切な設定をして下さい。

目次

デフォルトのgithub pagesのドメイン( username.github.io ) を使用している場合

既に対応しています。 なにもやる必要はありません。

カスタムサブドメイン ( www.example.com ) を使用している場合

CNAMEの向き先をusername.github.io に向けるだけで対応できます。

Apexドメイン ( example.com ) を使用している場合

Apexドメインというのはサブドメインでない基本のドメイン部分のことで、そこを直接github pagesにIPに向くようにAレコードに設定している場合です。

この場合はDNSのプロバイダがALIASレコードをサポートしていれば、ALIASが username.github.io を向くようにすることで対応できます。

ALIASレコードに対応していない場合は残念ながらCDNを有効にできません。ちなみにお名前.comはALIASには対応していないので、その場合は他のDNSプロバイダに移行するしかありません。

お名前.comからDNSimpleに移行する場合

このブログは残念ながらお名前.comでApexドメインをgithub pagesのIPに向けていたのでDNSimpleに移行することにしました。以下はお名前.comからDNSimpleに移行した際の手順です。

なお、この場合はタイトルに反して無料ではありません。

(ちなみにここではドメインの移管はせずに、DNSの設定だけをDNSimpleに移しました)

1. DNSimpleに登録する

DNSimpleはユーザビリティに主眼を置いたDNSサービスのようで¹ 、APIでDNSレコードを更新したりAWSやHerokuやgithub pagesといったクラウドサービスとの連携が簡単にできます。

DNSimple

登録時に対象ドメインを聞かれるので、そのとき移行したいドメインを入力します。

ちなみに月額3ドルから² ですが30日は無料でつかえます。誰かを紹介すると、紹介した人とされた人の両方の無料期間が伸びます。上のリンクにはキャンペーンコードが埋め込まれているので、この記事を読んだ人はぜひ上のリンクから登録してください。

登録が完了するだけで一通りのUIが使えるようになりますが、DNS機能が有効になるのは決済情報を入力してからです。

2. DNSimpleでgithub pagesとの連携を開始する

dnsimpleの管理画面 に行くとServicesというボタンがあるのでそこからgithub pagesと連携を開始します。

3. ネームサーバの設定をする

お名前.com の以下のページの「他のネームサーバーを利用」からDNSimpleのネームサーバを指定します。

https://www.onamae.com/domain/navi/ns_update/input?btn_id=navi_menu_domain_nsupdate_leftmenu_12

登録するサーバは以下です。

• ns1.dnsimple.com
• ns2.dnsimple.com
• ns3.dnsimple.com
• ns4.dnsimple.com

参考 - DNSimple Name Servers

この段階ではお名前.com側で設定しているAレコードはそのまま残しておきます。変更するのはネームサーバのみです。 そうしておかないと、ネームサーバの変更が伝搬するまでの間にお名前.comに問いあわせが来た場合NXDOMAIN扱いになってします。

4. dnsの更新を確認する

更新前は以下

% dig mojavy.com
mojavy.com.             259     IN      A       207.97.227.245

もしくは以下

% dig mojavy.com
mojavy.com.             259     IN      A       204.232.175.78

のようになっていたはずですが、反映が完了すれば上記とは違うIPが返ってくるはずです。 反映までには時間がかかるので気長に待ちます。完全に反映されるには3日ほどかかるようです。

% dig mojavy.com
mojavy.com.             3600    IN      A       103.245.222.133

% dig taksatou.github.io
taksatou.github.io.     2973    IN      CNAME   github.map.fastly.net.
github.map.fastly.net.  15      IN      A       103.245.222.133

5. CDNの確認

webpagetest のような計測ツールを使ってもいいですが、CDNからのレスポンスはX-xxxのようなヘッダがつくようなのでcurlでも確認できます。

% curl -v mojavy.com 2>&1  > /dev/null  | grep 'X-'
< X-Served-By: cache-ty67-TYO
< X-Cache: HIT
< X-Cache-Hits: 5
< X-Timer: S1392104522.668435574,VS0,VE0

もう完全に反映されたと思ったらお名前.com側で設定しているAレコードは無効にして大丈夫です。

その他参考

• https://help.github.com/articles/setting-up-a-custom-domain-with-pages

まとめ

• github pagesをつかえば無料でCDNから配信できる!
• Apexドメインは慎重に使うべきだったという教訓を得た
• DNSimple便利

目次

候補の選定方法

候補を選定するにあたって、以下の特徴をもっていることを前提とした。 LuceneやGroongaを使えば何でもできるが、ここでは対象としない。

• ウェブベースのインターフェースを持つ
• インデックスの更新はほぼリアルタイムに反映される
• スケールアウトが容易

Solr

https://lucene.apache.org/solr/

Luceneをバックエンドにした全文検索システム。バージョン4になってから大幅に機能が増強された。

長所

• 実績が十分ある
• 機能豊富

短所

• クラスタを構築して運用するには手間がかかりそう
• SolrCloudはzookeeperに依存するためサーバ台数もかさむ

Elasticsearch

http://www.elasticsearch.org/

Solrと同じくLuceneをバックエンドにした全文検索システム。開発者の言¹によると、Solrより洗練された分散モデルで² 、使いやすいAPIを備えている。

長所

• アーキテクチャやUIが今風
• クラスタの構築が簡単
• KibanaやLogstashと連携できる
• Percolate APIというpush通知のような機能を簡単に実装するためのものがある

短所

• 後発な分ノウハウの蓄積にやや不安が残る
• 未実装機能がいくらかある(あった。現時点(2014-02-09)では機能的にはほぼ追いついているように見える http://solr-vs-elasticsearch.com/ )

Amazon CloudSearch

http://aws.amazon.com/jp/cloudsearch/

AWS上で提供されている全文検索システム。EC2と同じく時間とトラフィックで課金される。現時点ではまだベータ。

長所

• 自動的にスケーリングしてくれる(エントリ数、リクエスト数に応じてインスタンスが自動的に増える)
• pdfやdocをそのまま送るだけでも適当にうまくやってくれる
• DynamoDBのデータをそのまま流してインデックスできる

短所

• 現状では東京リージョンがない
• テキスト解析のカスタマイズが限定的。現状、Stemming, Stopwords, Synonymsのみカスタム可能。
• N-gramとか形態素解析は自前で処理してからアップロードする必要がある
• ヒット位置を取る方法がない
• テキスト本文をインデックスと一緒に格納することはできない

比較項目別のまとめ

拡張性

SolrもElasticsearchもLuceneをバックエンドにしているので、Luceneでできることは基本的にはどちらでもできるはず。 Amazonは現状ではあまり拡張性はない。

性能

基本性能はSolrもElasticsearchも大差はなさそう。 Amazonは自動的にノードが追加されるので性能の問題はなさそう。ただし、ノードが自動追加されるタイミングとその時の挙動は未確認。

安定性

数年先行している分Solrがよいと思われるが、Elasticsearchも既に十分本番稼動実績はある。 Amazonはベータなので未知数。

リアルタイムデータ更新

いずれもほぼリアルタイムに更新できる。

日本語対応

SolrとElasticsearchはほぼ同等。kuromojiやmecabをつかえば形態素解析もできる。 Amazonはそれ自体では対応していないが、Luceneのtokenizer等を使って自前で前処理することで対応は可能。

スケーラビリティ

Amazonは完全に自動的にスケールアウトしてくれる。 Elasticsearchはインデックスのシャード数を作成時に決めておく必要があるが、スケールアウトは容易だと思われる。 Solrはv4からはElasticsearchと大体同等のスケーラビリティを備えるようになった。

参考リンクまとめ

• http://stackoverflow.com/questions/10213009/solr-vs-elasticsearch
• http://stackoverflow.com/questions/2271600/elasticsearch-sphinx-lucene-solr-xapian-which-fits-for-which-usage
• http://blog.kakipo.com/trouble-with-fluentd-and-elasticsearch/
• https://github.com/atilika/kuromoji
• http://www.elasticsearch.org/blog/percolator/
• http://blog.feedbin.me/2013/11/10/powering-actions-with-elasticsearch-percolate/
• http://docs.aws.amazon.com/cloudsearch/latest/developerguide/text-processing.html
• http://blog.mikemccandless.com/2011/06/lucenes-near-real-time-search-is-fast.html
• https://wiki.apache.org/solr/Solr4.0
• http://www.slideshare.net/kucrafal/battle-of-the-giants-apache-solr-vs-elasticsearch

所感

後発な分Elasticsearchが一番洗練されているように思います。 Solrは無難に導入できそうですが、スケールアウトが必要になったとき手間がかかりそうです。 Amazonはメリットも多いですが、現状では制限が多いので使いづらいと思います。

追記

• 2014/02/12 23:59:13： ElasticSearch → Elasticsearchに直しました

The Web engineer's online toolboxというまとめ記事が便利そうだったので、実際に試しつつ抄訳してみました。(一部のコメントと体裁は変えています。)

目次

一覧

RequestBin

httpリクエストを保存するエンドポイントを作ってくれる。

Create a RequestBin のボタンをクリックするとURLが表示されるので、そこをHTTPクライアントからたたくとRequestBin側にリクエスト内容が記録される。 ソースも公開されてるのでローカルで立ちあげることもできる。

githubのwebhookのhelpも参考にどうぞ。

Hurl

httpリクエストを実行してくれる。パーマリンクも作ってくれるので、POSTリクエストもコピペで他の人と共有できる。

• 類似サービス: REST test test , Apigee console

httpbin

HTTPリクエスト側でレスポンスのHTTP status codeやレスポンスやリダイレクト、cookieなどを制御できる。HTTPクライアントのテストに便利。

• 類似サービス: UrlEcho

REDbot

HTTPのリソースをチェックしてくれる。問題を検出したら改善案のサジェストもしてくれる。

• 類似サービス: HTTP lint

WebGun

webhookを簡単に作るためのAPIを提供している。現在はまだベータっぽい。

Apify

ウェブページをスクレイピングしてJSON API化してくれる。 CSSセレクタかxpathに名前をつけて設定するだけでよしなにやってくれる。

試しに元記事をAPI化してみた

Unicorn

前述のREDbotはHTTPをチェックしてくれるけど、こちらはHTMLドキュメントがW3Cに準拠してるかをバリデートしてくれる。

• 類似サービス: HTML lint

Feed validator

こちらはRSSとATOMフィードをバリデートしてくれる。

Link checker

リンクを再帰的にたどって、重複やリンク切れをチェックしてくれる。

Host tracker

ウェブサイトのモニタリングサービス。定期的にpingして、問題があった場合はメール通知してくれる。

• 類似サービス: Down for everyone or just me, Pimgdom ping service

Pingdom Full page test

ウェブページのロード時間を計測、解析してくれる。リクエストを実行するサーバは米国しかないので国内だとちょっと使いづらい。 類似サービスのWeb page testならTokyoが選べる。

HAR viewer

HTTP tracking toolsで生成されたHTTP Archive (HAR)形式のログをビジュアライズしてくれる。

CORS proxy

クロスドメインでjsを実行できるようにヘッダを追加してレスポンスしてくれるプロキシ。

Browserling

ブラウザ上で動くインタラクティブなクロスブラウザ。メジャーなブラウザは大体サポートされている。 動作は重いけど表示確認くらいになら無料のままでも使えそう。

WebSocket Echo Test

WebSocketをテストできるエコーサーバ。

YQL

ウェブサービスからとってきたデータをSQLっぽい言語で整形できる。

Yahoo Pipes

ウェブサービスをGUIでマッシュアップできる。

Apiary

良い感じのREST APIドキュメントをインタラクティブなインスペクタをつかってジェネレートできる。まだベータ。

• 類似サービス: Swagger

おわりに

• いくつかのツールはサーバに負荷をかけてしまう可能性があるので注意してつかってください。
• 他にもなにかあれば教えてもらえるとうれしいです。

最近twitter apiをつかっているサービスで以下のようなエラーがでた。

{"errors":[{"message":"Sorry, that page does not exist","code":34}]}

twitterのデベロッパフォーラムによると、先週くらいにバージョンがついてないエンドポイントは /oauth を除いて廃止されたらしい。また、ドメインもapi.twitter.comに統一されたらしい。

つまり、api.twitter.com/account/verify_credentials.json とか twitter.com/1/account/verify_credentials.json とか twitter.com/account/verify_credentials.json ではだめで、api.twitter.com/1/account/verify_credentials.json を使えということ。

ログイン直後にverify_credentialsをつかってるアプリは多いと思われるが、その場合ログインに失敗したように見えるので認証まわりをライブラリ任せにしてると原因がわかりにくいかも。

とりあえずtwitterの開発ブログまめにチェックしたほうがよさそう。

参考

• https://dev.twitter.com/blog
• https://dev.twitter.com/discussions/11595

とりあえずウェブサーバがたちあがりさえすればいいときは、pythonのSimpleHTTPServerを使うのが便利です。 起動したカレントディレクトリ以下のファイルをブラウズできるので、テスト用のスタティックなスタブデータを一時的に配置したいときとかにも使えます。最近の一般的なlinuxディストリビューションであればデフォルトではいってるpythonで使えると思います。

$ python -mSimpleHTTPServer 3333

デフォルトポートは8000ですが、引数で指定することもできます。
ちなみにrubyでもwebrickを使って同様のことができますが、こちら で紹介されているwebrickのワンライナーは長すぎて覚えられないのでいつもpythonを使ってます。

でもリクエストに応じたロジックを入れたい場合はrubyのsinatraの方が便利です。

$ ruby -rsinatra -e 'get("/"){sleep 3}'

ポートを変更する場合は以下のようにします

$ ruby -rsinatra -e 'set :port,3333; get("/"){sleep 3}'

参考

• コマンド1つで今すぐWebサーバを起動させるためのワンライナー(Ruby or Python)