１時間でツイッターサービスを作ろう！ http://kray.jp/blog/twitter_service_in_1hours/
会社のブログに書いたエントリーがホッテントリに。しかも人生初の一番上のポジション。びっくり。
記念に。
Posted in 日記 at 7月 24th, 2010. No Comments.
はじめに
美味しそう！を共有するサービス「ラペコ」のリリースから一ヶ月経ちました。
おかげさまで多くの方に利用してもらって、いつも美味しい写真でいっぱいのサービスになっています。
現在の状況
リリースからちょうど一ヶ月間のデータをまとめてみました。
- 登録ユーザー数：約1600人
- 投稿画像数：約2500枚
- セッション数：約26,000セッション
- PV数：約120,000PV
といった状況です。
プロモーションとその効果
今回ラペコで一番気を遣った部分はプロモーションの部分です。
ラペコはアイデアを思いついてから約１か月間でリリースしたのですが、その半分近くはプロモーションの準備に費やしていた気がします。
これまで個人でサービスを作って、公開、誰も使わない、自己満足で終わるというパターンを経験してきて、今度は多くの人に使われるサービスにしたいと思ったからです。
スタート時に、有名ブログ（IDEA*IDEA、ネタフル、かちびと.net）への掲載をお願いして、掲載していただいたおかげで良いスタートを切ることができました。
ついなびへの掲載によって、自分と近い属性（IT、エンジニア系）以外の人たちに広く届いたと思います。自分の作ったものが多くの人に利用される経験は感動的でした。
今後の予定
- iPhone投稿機能（もうすぐ！）
- メール投稿機能（もうちょっと！）
- マイページの充実
- ユーザー間コミュニケーションの充実
を今後の機能として予定しています。
また、ラペコとは別のサービスの開発も始めましたので、そちらも早くお見せできるとよいなと思っています。
美味しい！を共有する「ラペコ」というサービスを作りました。
twitterで美味しそうだなぁという写真に出会うことが多いですよね。
そんな「美味しそうなごはん写真」をもっともっとたくさん見てみたい！そんな気持ちが限界域まで達した結果、こういった形になりました。
twitter上の美味しそうなごはんの写真を収集して人気順に表示したり、自分や他のユーザーの美味しそうなごはん写真をラペコに共有することで、みんなの「美味しそう！」を広げていきます。
特長は
- Twitterのつぶやきから自動的に美味しそうな写真をクロールして集めて、人気順に表示します
- Twitterで見かけた美味しそうなごはん写真付のツイートに、「#rapeco」ハッシュタグをつけてRTすれば、クローラーに拾われるようになり、ラペコ上に共有されます。
- ラペコから直接写真の（twitpicへ）アップロード、twitterへのつぶやきを行えます
- ラペコに共有された写真は、評価したり、リツイートすることが可能です
まだまだ機能的にもこれからですが、フィードバックは@func09までよろしくお願いします。
Twitterの検索APIについて、やっかいな問題にぶちあたりました。（2010年4月29日現在）
APIの結果に、ツイートのfrom_user_idとto_user_idという値が入っています。誰の発言したツイートか（from_user_id）と誰宛のツイートか（to_user_id）という数値で、当然twitterのユーザーIDが入ってくるものだと思っていたのですが、どうもバグがあるらしく、時折いい加減な数字が返ってきてしまいます。。
GET search http://dev.twitter.com/doc/get/search
Warning: The user ids in the Search API are different from those in the REST API (about the two APIs). This defect is being tracked by Issue 214. This means that the to_user_id and from_user_id field vary from the actualy user id on Twitter.com. Applications will have to perform a screen name-based lookup with the users/show method to get the correct user id if necessary.
この問題はすでに報告されていて、現在追跡中です。 ちなみにこのバグは2008年のクリスマスイブに報告されているので・・・。
対応としてはfrom_userとto_userにtwitterのscreen_name（僕のアカウントならfunc09みたいな）が入っているので、それを users/show APIを使って調べてね。とのこと。
twitterはAPIの制限もあるし、全部問い合せるわけにもいかず、超困るんですけど・・。
とりあえず検索APIのfrom_user_idとto_user_idは信用するなということですね。
Posted in 日記 at 4月 29th, 2010. No Comments.
嫁さんがNHKみんなのうたでアニメーションを担当しました。放映期間は４月、５月だそーです。
「Aloha（アロハ） You（ユー） ～きずな～」という曲のアニメーションでして、とってもかわいらしいので是非ご贔屓にしてください。RTとかしまくってください。
「みんなのうた」に！！ミニミニ通信：NHKブログ
http://www.nhk.or.jp/minimini-blog/510/41547.html
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秒後
2回失敗したら次回のリトライは21秒後
3回失敗したら次回のリトライは86秒後
4回失敗したら次回のリトライは261秒後
5回失敗したら次回のリトライは630秒後
6回失敗したら次回のリトライは1301秒後
7回失敗したら次回のリトライは2406秒後
8回失敗したら次回のリトライは4101秒後
9回失敗したら次回のリトライは6566秒後
10回失敗したら次回のリトライは10005秒後
最初の方は１分以内にリトライさせますが、10回目ともなるとリトライは２時間後。
何度も失敗していると、もうこいつアカンわ・・と見捨てられていく感じを良く表現したロジックですねー。
Mitaka.rbの第四回に行ってきました。
今回は吉祥寺のepicesという店を借り切って、美味しいものが食べたけりゃMitaka.rbへおいでってな感じです。
後半はフレンチを食べながらLTを見るという、貴重な体験もできましたよ。
Posted in 日記 at 8月 26th, 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では「エリア」という分類方法を利用します。
エリアにはプロジェクトかタスクを格納しておくことが可能です。
今日やることが、プロジェクトで分割されてリストされています。 職場に居る時はエリア「会社」に属したプロジェクト「A社システム開発」のタスクが一番先にあっても良いですが 家に帰ったら、「引越」や「新規個人サービス開発」プロジェクトのタスクを優先したいでしょう。
そんな時はエリアの優先順位を入れ替えます。
左のエリアで「仕事」を一番下に下げることで、プロジェクトもエリアの並び順に影響されて順番が変わります。 すると今日やることリストのタスクの並び順もしっかりと変わり、家ですべき事が上に表示されるようになりました。
さいごに
RTMを使っていて、どうも上手く管理できていない感じは、タスクをそのタイミングにあった並び順にできない事にありました。 基本「今日やることリスト」しか見てませんので、その中がいろんな立場のタスクでごちゃごちゃになってしまっていたんですね。
それからRTMにくらべて良いなと思った点は、Thingsは終わったばかりのタスクはしばらく表示したままでいてくれることです（だいたい終日）。 これで、あれあのタスク終わったっけ・・？みたいな不安からタスクに集中できないなんてことも減りました。
