Railsで非同期処理？
railsで非同期処理をやる場合、最近はdelayed_job がメジャーらしい ですね。
以前はbackgrounDRbが定番だったようだけど、EngineYardが「友達にBackgrounDRbを使わせるな 」とまで書いているので、そこまで言われると使う気になりませんでした。実際リソース食いだったし。
使い方参考ページ
使い方はそんなに難しくないので、ここで説明することは放棄します。
README とRailscastsのエピソード171 でなんとかなると思います。
再試行のロジック
いろいろとすっとばして本題、キューの再試行のロジックが変だなぁと思ったのでメモです。
Delayed::Job::max_attempts
delayed_jobには試行回数上限があって、この上限値を超えるまでリトライしつづけます。
デフォルトは25回で、Delayed::Job::max_attempts という定数に設定されています。
Delayed::Worker::sleep_delay
ワーカーが起動するインターバルです。デフォルトは5秒。
例えば絶対に失敗するキューがあった時、
キュー失敗、５秒待機、キュー失敗、５秒待機、（以下25 回失敗するまで繰り返し）
キューが失敗した時の再スケジューリング
キューが失敗すると、次に実行する予定時刻を決めます。そのロジックが
On failure, the job is scheduled again in 5 seconds + N ** 4, where N is the number of retries.
となっています。
「トライした回数の4乗に5秒足した時間」後にリトライをするよう再スケジューリングするので、失敗すればするほどインターバルが開いていきます。
1回失敗したら次回のリトライは6秒後
最初の方は１分以内にリトライさせますが、10回目ともなるとリトライは２時間後。
Posted in
ruby on rails ,
日記 at 12月 15th, 2009.
No Comments .
Mitaka.rbの第四回 に行ってきました。
今回は吉祥寺のepicesという店を借り切って、美味しいものが食べたけりゃMitaka.rbへおいでってな感じです。
後半はフレンチを食べながらLTを見るという、貴重な体験もできましたよ。
Posted in
日記 at 8月 26th, 2009.
No Comments .
サーバに引越に伴い、
の３つのサービスを数日間停止させていただきます。
大変ご迷惑おかけしますが、何卒ご了承ください。
Posted in
Webサービス ,
日記 at 8月 5th, 2009.
No Comments .
先月づけで株式会社Syun を退職しました。
Syunは千葉県柏市にある小さなシステム会社で、僕が在籍している間には、こんなこと やあんなこと をしていました。
「IT業界の名工」をうたっているのですがまさにそんな会社で、効率化よりもいかにお客さんに技術で応えるかという理念の基に仕事をしていたなぁと思います。技術だけでなくお客さんに対する誠意という面でたくさん学ぶことがありました。
Syunの皆さん、ありがとう。これからもがんばってください。
さて、退職後しばらくfunc09としてフリーランスのお仕事をぼちぼちやっていきます。無職になったらドラクエ９やるぞーと思っていたのですが、おかげさまでそんな余裕がない程度にお話が来てます。みなさんありがとう。
それに伴いというか、今週中に千葉から三鷹近辺に引越、２年ぶりに中央線人になります。
どうやら中央線沿線以外では生きて行けないらしいというのが、僕の結論なのでこの先中央線から出て行くことはないと思います。三鷹・吉祥寺ラヴ！
それでもって、千葉の時は行きづらかった勉強会やコミュニティに積極的に参加したいとも思っています。何度か参加している三鷹プログラマーズカフェやMitaka.rbはもちろんのこと、Rails東京や、Flash、デザイナーさんのコミュニティにも顔を出したいです。
なのでオススメの勉強会やらがあったら是非twitter なりで声を掛けてくださーい。
Posted in
日記 at 8月 2nd, 2009.
2 Comments .
ToDo管理何つかってますか？
手帳？付箋？OutLook？Remember The Milk ？
いろんな選択肢がありますが、この度RTM からThings へ移行し、とってもGoodなのでメモがてらオススメします。
RTMを辞めた理由
RTMはとても素晴らしいToDo管理ツールだと思います。
僕はプロアカウントでiPhoneアプリも利用するほど気に入っていました。
しかし、プロジェクト単位のタスク管理にどうしても不満が消えませんでした。
そこで始めからGTD用ツールとして設計されていて、プロジェクト単位のタスクも管理できるMacのThings へ移行してみました。
Things
Thingsでわかったタスク管理の肝
Thingsを使ってみてわかったのは、プロジェクト管理も重要だけど、それ以上に大事なのはタスクを「立場」で分類するという事。
１人の人間でもタスクは「立場」にぶら下がっていると考えられます。
例えば
企画書を仕上げる
古本をブックオフに持って行く
Thingsのオススメエントリーを書く
というようなタスクがあったとして、これらは全部同じ人間のタスクですが
実際には実行する立場が異なりますね。
企画書を仕上げる（会社員としての自分）
古本をブックオフに持って行く（家庭人としての自分）
Thingsのオススメエントリーを書く（個人としての自分）
こんな感じです。
これらがひとつのタイムラインにばーっと並ぶと、一見次にすべきことを上から順にこなせばいいようにも思いますが
実際には１日のうちで、自分の立場はコロコロ変わるので、立場によって優先順位も変わるはずです。
例えば職場で仕事している時に「古本をブックオフに持って行く」タスクが上位に存在したら、集中して仕事できないでしょう。
Thingsでは「立場」を「エリア」として扱える
そこでThingsでは「エリア」という分類方法を利用します。
エリアにはプロジェクトかタスクを格納しておくことが可能です。
今日やることが、プロジェクトで分割されてリストされています。
職場に居る時はエリア「会社」に属したプロジェクト「A社システム開発」のタスクが一番先にあっても良いですが
家に帰ったら、「引越」や「新規個人サービス開発」プロジェクトのタスクを優先したいでしょう。
そんな時はエリアの優先順位を入れ替えます。
左のエリアで「仕事」を一番下に下げることで、プロジェクトもエリアの並び順に影響されて順番が変わります。
すると今日やることリストのタスクの並び順もしっかりと変わり、家ですべき事が上に表示されるようになりました。
さいごに
RTMを使っていて、どうも上手く管理できていない感じは、タスクをそのタイミングにあった並び順にできない事にありました。
基本「今日やることリスト」しか見てませんので、その中がいろんな立場のタスクでごちゃごちゃになってしまっていたんですね。
それからRTMにくらべて良いなと思った点は、Thingsは終わったばかりのタスクはしばらく表示したままでいてくれることです（だいたい終日）。
これで、あれあのタスク終わったっけ・・？みたいな不安からタスクに集中できないなんてことも減りました。
Posted in
mac ,
日記 at 8月 2nd, 2009.
No Comments .
嫁がFlashアニメで賞金を荒稼ぎしている件 - func09
http://www.func09.com/wordpress/archives/596
でも紹介したうちの奥さんのアニメが山手線のモニターで今流れているそうです。
もう見た人とかいますか？
gaya-anime: その後のその後http://gaya-gaya-gaya.blogspot.com/2009/06/blog-post_15.html
Pickles weblog | ガヤアニメさんのが山手線で流れていた。http://www.pickles.tv/weblog/sb.cgi?eid=711
Sandisk様、filmo様、Pickles様、ありがとうございます。
Posted in
日記 at 6月 19th, 2009.
1 Comment .
三鷹プログラマーズカフェに参加しました。
http://atnd.org/events/735
阿佐ヶ谷ギークカフェ計画から端を発した中央線ギークカフェプロジェクトが
ysakaki さん、kuippa さん、kclab さん、そしてまちづくり三鷹 さんのおかげで現実のものとなりました。
大きな会議室を借り切って、各々テーマ別にテーブルを付き合わせて作業したり、談笑したり、営業したりと、様々だった模様。
僕はもくもくグループで、趣味のコード を書いてました。Rubyで言語内DSLを書くお勉強です。
同じもくもくグループの中に来週のGoogle Hackathonに参加する人が６人中４人だった、というのが興味深かった。
三鷹プログラマーズカフェは毎週木曜に開催しているそうなので、お近くの方は参加してみてはいかがでしょうか？
Posted in
日記 at 6月 5th, 2009.
1 Comment .
DBに配列やハッシュのデータを保存したいなと思って調べました。
ActiveRecord.serializeで実に簡単に実現できるんですね。http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M002229
If you have an attribute that needs to be saved to the database as an object, and retrieved as the same object, then specify the name of that attribute using this method and it will be handled automatically.
The serialization is done through YAML. If class_name is specified, the serialized object must be of that class on retrieval or SerializationTypeMismatch will be raised.
このメソッドでオブジェクトとして保存・取得したい属性の名前を指定すると、自動的に処理されるようになる。
YAMLでシリアライズされ、class_nameオプションが指定されると格納できるオブジェクトのクラスを制限できる。あるいはSerializationTypeMismatchの例外となる。
ポイント
シリアライズしたいカラムの型をtextにする
serializeメソッドでカラムを指定する
格納できるクラスを指定可能
内部的にはYAML
実例
さて、やってみます
まずマイグレーション内で、text型のdataというフィールドを用意する。
class CreateItems <ActiveRecord::Migration up text :datadown
そしてモデル内でシリアライズするフィールドを指定。
class Item <ActiveRecord::Base
script/consoleなどをおもむろに起動し、本当にオブジェクトが保存できるのか確認します。
# 配列を代入するcreate :data => [ 1 ,2 ,3 ] find ( :all) .last data #=>[ 1 ,2 ] data .class #=>Array
ちゃんと配列として取得できました。めでたしめでたし。
どうなってるの？
DBに格納する際にオブジェクトをYAML化しているようです。
検索したい場合
findしたい場合は、オブジェクトではなく文字列として評価されてしまうので
Object#to_yamlを使うことになります。
Item.find_by_params ( [ 1 ,2 ,3 ] ) # => これではレコードが見つからないfind_by_params ( [ 1 ,2 ,3 ] .to_yaml ) # => 見つかる
使い勝手が悪い。。
格納する型を限定する
このままだとオブジェクトならなんでも格納できてしまいます。
そこで格納するクラスを指定してやります。
class Item <ActiveRecord::Base
script/consoleで試してみます
# 配列の格納は成功create :data => [ 'bob' ,'alice' ] 1 , data: [ "bob" , "alice" ] >create :data => { :name => 'bob' } SerializationTypeMismatch : data was supposed to be a Array, but was a Hash
これでかなり使い勝手が良くなりましたけど、配列の中身までは保証できないので、精神的安定のために使う程度でしょうか？
最後に
DBにシリアライズしたデータを保存しなければならない状況は無いにこした事は無いと思いますので
設計レベルで回避できる場合はそちらをおすすめします。
Posted in
ruby on rails ,
日記 at 5月 21st, 2009.
No Comments .
mixiアプリ第１弾として「傘いる？」を作りました。http://platform001.mixi.jp/view_appli.pl?id=1907
地域を設定しておけば、今日あなたが傘を持って出かける必要があるのか？ないのか？それだけを教えてくれるツールです。
お天気データの取得にはlivedoor天気のWeather Hacksを利用させてもらっています。Weather Hacks
JavaScriptだけで完結して、複雑なUIを必要としない、すぐできる題材として作ってみました。
ソースコードはgithubに置いてありますhttp://github.com/func09/kasairu-opensocial-mixi/tree/master
Posted in
OpenSocial ,
日記 at 5月 4th, 2009.
No Comments .
