2013/03/15(金)TwitterAPIがApplication-only authenticationを公開。これを使うと検索API等の一部回数制限が大幅に緩和される。
2013/03/15 11:24
■Do applications dream of authenticated requests?（英語）
https://dev.twitter.com/blog/application-only-authentication
■Application-only authentication（英語）
https://dev.twitter.com/docs/auth/application-only-auth
名前の通り、アプリケーションだけがAPIを叩く場合に使える認証方法です。
どういうことかと言うと、クライアントのように多くのユーザに配布して各々がAPIを叩くわけではなく、アプリケーション自身のみが唯一APIを叩く場合に利用できる認証方法というわけです。
OAuth2.0を使っており、ユーザごとに認証するわけではないので仕組みが単純になっています。
で、この「Application-only authentication」を使うと、一部のAPIの呼び出し回数制限が緩和されます。
例えば検索APIの場合、通常の認証では15分に180回ですが、Application-only authenticationでは15分に450回叩けます。また、タイムライン取得APIも15分180回から15分300回へと緩和されます。
Application-only authenticationを使った場合の詳しい利用回数は下記にまとめられています。
■REST API v1.1 Limits per window by resource（英語）
https://dev.twitter.com/docs/rate-limiting/1.1/limits
API 1.1でいろいろと厳しくなったことが反発を呼びましたが、APIをもっと使いたいという開発者側の声に一部とはいえTwitter側で答えてくれたものと思います。この点は大変ありがたいです（クライアントアプリにはあいかわらず厳しい感じですが）。
特に検索APIを使っている場合はApplication-only authenticationに切り替えた方が断然いいです。15分450回は2秒に1回なので、かなり自由に使える感じではないでしょうか。
1.1への切り替え完了後の発表なので、作る側としてはもう少し早く出してくれれば何度も修正しなくて済んだのにというタイミングの悪さはありますが、仕組み自体が以前より単純化しているのでそれほど手間ではありません。
Perlでの具体的な実装方法を日本語でまとめてくれている方がいらっしゃったので貼っておきます。
■TwitterのApplication-only authenticationをperlで試す。
http://www.macminiosx.com/2013/03/twitterapplication-only_authen.html
ちなみにこの認証方法とは関係ないですが、リスト関連のlists/statusesの呼び出しが15分15回から180回に引き上げられたりと、わりとTwitter側で譲歩する動きはあるようです。今後も期待したいところです。
ではではご参考まで。
2013/02/08(金)phpmyadminでinformation_schemaをクリックするのが危険過ぎる
2013/02/08 17:41
管理情報を取得するためにデータベース全体にロックがかかるのかもしれない。
詳しい理由はよくわからないが、とにかく間違ってクリックしただけで問答無用でフリーズするので危険過ぎる。
というわけで、クリックしないよう、そもそも表示しないようにした。
phpMyAdminのconfig.inc.phpに下記を入れるだけです。
$cfg['Servers'][$i]['hide_db'] = '(information_schema)';
下記を参考にしました。
■phpMyAdmin で information_schema と test を非表示にする方法
http://www.hxp.jp/blog/2013/01/26/phpmyadmin_information_schema_test/
この件、調べても困ってる人いないんだけどうちだけなのかしらん。
データ量が多いからか？
2012/10/07(日)Androidブラウザでautofocusを使うとタップのたびにフォーカスされてしまう？
2012/10/07 13:25
フォームのオートフォーカスというのは、サイトを開いた時に検索ボックスに自動的にカーソルが当たるようにするやつです。JavaScriptやautofocus属性で指定します。
ユーザの方から、スクロールが勝手に先頭に戻ってしまうという指摘が以前からあって、原因がわかってなかったのですが今日わかりました。
僕が使っているAndroid用Operaではそんなことないので標準ブラウザだけの症状かと。
ご参考にどうぞ。
2012/09/03(月)Solrメモ書き2
2012/09/03 17:39
でもやっぱり日本語情報が少ない。というわけで実戦投入までに調べたことを公開メモ。バージョンは3.x系です。
前のメモはこれ。
Too many open filesエラーが出る
このエラー出まくった。ファイルを大量に開くようなので、ファイルディスクリプタ（システムが開けるファイル数）の上限を65536とかにしておく。
普通は /etc/security/limits.conf あたりで指定するみたいだけど、サービスとして起動させておくプログラムに対しては有効にならないっぽい。
詳しくは下記記事参照。
■ファイルディスクリプタ数の上限変更とlimits.confの罠
http://yumewaza.yumemi.co.jp/2010/07/limitsconf.html
というわけで、/etc/security/limits.conf は使わず、起動スクリプト（/etc/init.d/solr）上でulimit -n 65536とか記載しておく。
下記参考に。
■Tomcat - Too many open files が出る問題
http://www.matsuaz.com/matsumotojs/2010/12/24/1293117835413.html
定期的にoptimize。autocommitはよくない。
追加したデータをインデックスに載せるためにはコミットが必要なのだけど、コミットするたびにファイルの断片が増えていくので、定期的にoptimizeしないと重くなる。あと上記の開きすぎエラーにもつながる。定期的って一年に一回とかかと思ったら、どんどん重くなったのでかなり頻繁に必要らしい。本だと5回コミットしたら1回optimizeとか書いてあった。スケジューリングが面倒なのでもうコミットするたびoptimizeするようにした。
で、最初は楽そうだからautocommit（自動コミット）使ってたけど、コミットは処理が重いのでちゃんとスケジューリングして深夜にまとめてコミット＆オプティマイズするとか、計画的に実行した方がいい。後述の再起動とも関連。
2014/12/16 追記
Solr4.0以降だと特に定期的にoptimizeする必要はなくなったぽい。
ログファイルを軽くしたい
ログにあらゆる情報が出力されていてすぐでかくなるので、エラーだけ出力するように起動スクリプト上でフィルタした。java -Dsolr.solr.home=multicore -DSTOP.PORT=8079 -DSTOP.KEY=これが良いやり方かどうかはわからん。-jar start.jar 2>&1 | grep --line-buffered "Exception" >> ＜LOG_FILE＞ &
標準出力とエラー出力はわかれてないっぽいのでこんなやり方になった。
ロックファイルが残る
コミット中に再起動するとロックファイルが残って書き込めなくなる。logroteが再起動させるので、その時間にはコミットさせないようにすること。
autocommitはここでも危険。
使用メモリ？
使用メモリの設定とかあるのかと思って調べたけどよくわからない。javaの-Xmxオプションで指定する？-Xmx4096mとかやってみたらかえって重くなったので結局いじってない。いじってなくても十分捌けてる。以上。
誰か公式マニュアル翻訳して欲しい。
2011/12/09(金)Alexaのグラフで4年前までのデータを取得できた。
2011/12/09 14:24
例）
r=に期間を指定。u=でドメインを指定。
6ヶ月
http://traffic.alexa.com/graph?r=6m&u=twitter.com
52ヶ月
http://traffic.alexa.com/graph?r=52m&u=twitter.com
せっかくなのでCeronのサイト情報ページには52ヶ月を貼っておくことにしたよ！
http://ceron.jp/site/twitter.com
Ceronのサイト情報ページは
http://ceron.jp/site/＜ドメイン＞
で見られます。
2011/12/08(木)オープンソースの全文検索エンジンSolrについてメモ
2011/12/08 13:19
Solrってのがなんか良さそうだったのでインストールしたりしてみた。
オープンソースの全文検索エンジンにはいろいろあって、有名なのはNAMAZUとかSenna。
NAMAZUは小中規模向けっぽい。
SennaはMySQLを置き換える格好になるのでちょっと使いたくないなと思ってた。
で、Solrは単独で機能する上にかなり大規模までいけるらしい。20億インデクスくらいいけるとどっかに書いてあった。
ちなみにエンジンのコアはLuceneというやつで、それにいろいろくっつけて便利にしたのがSolr。さらにGUIとクローラーまでくっつけたFessというのもあって、これは日本人が作ってたりする。クローラー付きのものにはNutchという海外産のものもある。
でもどれも全体的にドキュメントが少ない。今回試してみたけど、結局よくわからん部分も多く、実戦投入まではいきませんでした。Ceronの全文検索とかまかせられればよかったんだけど。
Nutchは「Googleに代わるオープンな検索エンジン」を標榜してたりするので、サイト内検索とかじゃなくネット全体の検索エンジンも作れそうな気もするけど実際のところ負荷的にどうなんですかね。期待もあるけど気軽に試すレベルでもないしなあ。20億インデクスじゃ足らなそうだけど。
で、以下、Solrをインストールして稼働させるまでに調べたことを備忘録でメモしておきます。ご参考まで。殴り書きですすいません。
・基本、ダウンロードして解凍するだけ。お手軽。
・サーバにサービスとして認識させるために起動シェルを登録。
http://ochien.seesaa.net/article/153105901.html
http://d.hatena.ne.jp/fat47/20110920/1316505461
init.dまわりの説明はこちら http://www.usupi.org/sysad/031.html
・そのままだと日本語対応してないので形態素解析とか入れる。
以前はSenが主流だったけど開発終了。いまは日本語検索にはGoSenを使うらしい。
http://d.hatena.ne.jp/lettas0726/20110711/1310375789
http://d.hatena.ne.jp/hjym_u/20110620/1308578328
・速度的にもSolr優秀。Sennaより成績いい。
http://thinkit.co.jp/book/2008/11/25/211
・PerlインタフェースとしてWebService::Solrがある。
けど、ちょっと巨大すぎ？依存モジュールがやたら多い。自作したほうがよさげ。
・基本マルチコアにする。
各コアにlibディレクトリを作り、それぞれに日本語トークナイザーを入れる。
・Solr自体がWebサーバ（jetty）を持ってて管理画面はその上で動く。Apacheと連携させちゃったほうが管理面で何かと便利そう。
http://www.atmarkit.co.jp/fjava/rensai4/safetomcat_01/safetomcat_01_2.html（理屈はここの中盤のTomcatの場合と同じ）
→でもなんかうまくいかなかった！！！未解決！
以上。
追記（2011/12/9）
ちなみに本は下記を買いました。これ一冊で基本的な部分は困らない。
Apache Solr入門
追記（2012/6/17）
ログの出力先の設定がググっても出てこなくて迷ったが、上記起動シェル内で設定していた。これで/var/log/以下にsolr.logが出てくるので、logrotate.dでログローテーションの設定をすればいい感じになる。
2011/10/21(金)Google PageRankが取得できなくなった
2011/10/21 11:41
こちらを参考にどうぞ。
http://www.picolix.jp/blog/search/909/
Perlモジュールの
WWW::Google::PageRank
を使ってるんだけど、モジュール内のURLの記述を書き換えたら普通に取得できるようになりました。