2012-05-04(Fri)
bit.lyで短縮されたURLのクリック数をRuby(Nokogiri)でスクレイピングする
プログラム | | 
bit.lyで短縮されたURLのクリック状況は短縮されたURLの末尾に'+'をつけると知ることができるので、そこからクリック数をスクレイピングしてみようという話。*1
# bitlycun.rb require 'nokogiri' require 'open-uri' url = "https://bit.ly/#{ARGV[0]}+" page = open(url) html = Nokogiri::HTML(page.read, nil, 'UTF-8') html_a = html.search('//span[@class="count"]') tmp = html_a[0].children.text clickcun = tmp.gsub(/(\r\n|\r|\n)/, "") puts "http://bit.ly/#{ARGV[0]} : click count = #{clickcun}"
スクリプトを実行する際、引数にbit.lyで短縮した際の可変部分(http://bit.ly/***** の ***** ) を第一引数に渡せば現在までのクリック数を取得することができる。
% ruby bitlycun.rb IxW4jJ
http://bit.ly/IxW4jJ : click count = 3
*1：ネタとして探したらあちこちにありそうだったけど…（略
2012-04-15(Sun)
2012-04-08(Sun)
REMP Ver.2.5 リリースしました（してました）
REMP Ver.2.5をリリースしました。REMPを利用しているユーザのオンライン状態を確認できるようになり、デスクトップへの通知に対応しました。また操作パフォーマンスも大幅に向上しています。 URL
2012-03-25 23:06:27 via web
と、twitterではお知らせしたのですが、改めて。
見た目上の大きな変更や派手な機能追加は無いのですが、以下の様な点が改善されています。
機能的に新しくなったのはログイン状態表示とデスクトップ通知になります。
ログイン状態表示
REMPの操作画面の左手にfacebookのfriendsが表示されますが、そのリスト表示部分の名前とプレイリスト数の横にログインしていれば緑色のランプアイコンが表示されます。
デスクトップ通知
REMPでは、自分のfriendsに対して自分が見つけたYoutube動画を送ることができるのですが、もし誰から動画が送られた瞬間にログインしている状態であればChromeのデスクトップ通知の機能を利用して画面上にポップアップして通知させることができます。ちょうどイメージ的には、メールソフトでメールを受信したときに表示されるNotifyのポップアップの様なイメージです。
また、自分の友達がREMPにログインして操作開始したことも同様にデスクトップ通知で知ることができます。
設定は、画面左下の歯車のアイコンで設定をすることができます。
あと、細かいところではブラウザサイズを小さくした際にREMPのプレイヤー上部に表示される再生ボタン等のサイズが絶妙に調整される様になっています。細かいところで@hika69のコダワリが出ています。*2
自分が担当したサーバ側の技術的な部分では、通知系にはPUSHERを利用したWebsocket経由でのフックを使っていたり、ログアウト検出用に独自のお手軽メッセージキューを使ったりしていますが、そのあたりはまたブログに書いていきたいと思います。
(PUSHERの話題は、このあたりを参照)
(facebookアカウントが必要です)
2012-03-18(Sun)
unicornを使ってみた(1) - 導入
REMPで今までApacheのリバースプロキシを通してthinサーバでAPIを稼働させていたのですが、稼働時間が長くなるとメモリの利用割合が増える状況が続いていたため、どうしようかと悩んでいたところ会社でmizzyさん(@gosukenator)からunicornだとメモリ利用量が押さえられるという話を伺ったので早速切り替えてみました。
unicornを使ってみた(2) - REMPにおけるメモリ利用量の変化
では、実際に現在のREMPの場合において、どの程度メモリ使用量が変化したのかを確認してみました。
Apacheをフロントのリバースプロキシとして、背後にRack用のWebサーバ(Thin or unicorn)を動かすという挙動はかわらないので、Thinとunicornの両方のサーバを立てて、リバースプロキシ(mod_proxy)で均等に複数のプロセスで起動させているthinサーバとunicornにアクセスする様にして3分毎に実メモリ使用量を監視してグラフにしてみました。
mod_proxyの設定は以下の様な形にしています。以下の様に設定することでthinの1プロセスとunicornへ均等にアクセスがされる様にしています。
<IfModule mod_proxy.c>
(中略)
<Proxy balancer://***>
BalancerMember http://127.0.0.1:4040 loadfactor=10 #thinのプロセス(1/2)
BalancerMember http://127.0.0.1:4041 loadfactor=10 #thinのプロセス(2/2)
BalancerMember http://127.0.0.1:4044 loadfactor=20 #unicornのプロセス
</Proxy>
</IfModule>
で、この様な設定にした状態でREMPの本番環境にしてみたところ、得られた各プロセスが消費しているメモリ使用量の変化は以下の様な具合です。
(赤色の線がThinの1プロセス vs 緑色の線がunicornのマスタープロセス+水色の線がunicornのワーカープロセス で比較すればよいのかな。と。)
少なくてもREMPのAPIサーバ側のSinatraで実装したアプリをThinの上で稼働させた場合とunicornで稼働させた場合を比較するケースでは、単純に見ると半分程度にメモリ使用量を押さえることができる様です。
2012-03-14(Wed)
thinサーバをプロセス別に再起動させる方法
プログラム | |
サーバ上で起動させているThinサーバを再起動させたい場合、
$ thin -C thin.yaml restart
と行うと、yamlでthinのプロセスが常駐する様に設定していた場合、一度全部のプロセスを閉じた後、設定数分のプロセスの起動が行われるため、接続が不可能な状態が一瞬生じます。
せっかく複数プロセスが稼働しているのであれば、一つずつのプロセスで再起動がかけられればよいので、方法を調べたところ --onebyone というオプションを付与することで実現できました。
$ thin -C thin.yaml --onebyone restart
といった具合。
こうすると、以下の様に個々のプロセスの停止と起動が繰り返されます。
$ thin -C thin.yaml --onebyone restart Stopping server on 0.0.0.0:4040 ... Sending QUIT signal to process 12835 ... >> Waiting for 1 connection(s) to finish, can take up to 30 sec, CTRL+C to stop now >> Exiting! Starting server on 0.0.0.0:4040 ... Waiting for server to start ... Stopping server on 0.0.0.0:4041 ... Sending QUIT signal to process 12846 ... Starting server on 0.0.0.0:4041 ... Waiting for server to start ... (以下略)
