クックパッド開発コンテスト24に参加した思い出

クックパッド開発コンテスト24に参加しました。(去年の夏だけど)

そこで Happy Bottle というWebサービスを作り、今でも個人的に使っています。
今ふりかえってもすごく良い体験だったなぁと思ったので、コンテストが終わった直後に書いた感想文をブログに載せておこうと思いました。

HappyBottle
http://happy-bottle.herokuapp.com/

      • -


ある日、@tricknotesさんに一緒に「クックパッド開発コンテスト」やろう、と言われてとても嬉しかった反面、本当に自分ができるだろうか足をひっぱらないかととても不安な気持ちがいっぱいでした。まぁ、不安なのはいつものことですが。


お題はとても難しく思えましたが、今まで自分が作りたいと思っていた「幸せ箱」のアイデアとうまく結びつき、取っ掛かりのネタとして@tricknotesさんも合意してくれて方針が確定ました。


幸せと感じた出来事を瓶に入れて流すイメージで「HappyBottle」と名付け、まずは骨格部分のプロトタイプを作ってみようということになりました。最初は@tricknotesさんと交互にペアプロをして開発のリズムをつけ、途中から分業して開発を進めました。Rails4を触ったのは初めてだったので、ほとんどが僕へのレクチャーみたいになってしまい申し訳なく思いました。


すぐ隣にいて認識を随時合わせながらの共同作業はとても小気味良く進みました。ソースはGitHubのプライベートリポジトリを通して共有化。
git pull --rebase を使うとほとんど衝突なく更新ができたのはとても勉強になりました。タスク管理はGitHub の issue で、優先度はかんばんりすと for GitHub issuesで共有しました。


３時間ほどでいちおう動くところ(ログイン、入力、メール通知)まで実装できましたが、触ってみると最初のイメージよりも物足りなさを感じました。プロダクトの性質上、ユーザアクションに対するレスポンスが乏しく、継続して使っていこうというモチベーションになりにくいというのが大きな課題として挙げられました。その後、インセプションデッキを書いてみたり拡張アイデアを検討してみましたがアイデアが煮詰まってきたので、一旦方針転換を検討しました。


原点のお題に立ち返り、二人ホワイトボードに向き合って２時間くらいあーだこーだとアイデア出しをしてみましたが、「これ」という案もでず、うまく頭が切り替わらず、別案も浮かばずで時間だけが過ぎていくばかり。この時は本当にモノをリリースできるのか心配になってきました。


ある程度時間が経ったところでHappyBottleの完成度を高めていく方針に戻り、類似サービスとの差別化という観点から機能を考え直しました。主にパートナーとの限定サービスというところにフォーカスを当てて継続して使うことで楽しめる仕組みを検討し、届いた瓶の断片をタグクラウドとして表示するアイデアを実装しました。これは個人的にはなかなか良かったと思います。届いた瓶のをそのままいつでもはっきりとふりかえられるというよりは、「かけら」として言葉の断片を眺めることで相手が大切だと思うことを再発見できるのではと思ったからです。そうやってお互いの大切にしている部分をこっそり再認識しながらゆるりと生きていけたらいいなぁ、と純粋に思いました。

技術的には@tricknotesさんが主導してくれたので様々なライブラリを試せたのは大きな収穫となりました。rails4,haml,jqcloud,mecab,twitterbootstrapなどなど。開発の流れも基本はissueでタスクを担当しつつ細かい気がついたところを声掛けしつつ修正し、比較的大きなハマリも無くスムーズに進めていけたと思います。


サービスとしても heroku で本稼働できるところまで実装できたので、元々の目標であった「作りきってリリースする」というとろこまでは達成できてよかった。


個人的にはずっと実現したかったアイデアを形にできたのはとても嬉しかったです。一人では絶対参加しようとは思わなかった開発コンテスト24に参加できたのも良かった。
そして何よりも、優秀な技術者である@tricknotesさんと２４時間という限られた時間を共有してアイデア出しから試行錯誤を経て実装までの一つの動くサービスを作りきったという経験はとても得がたい貴重なものだと思います。

「札幌市中央区Ruby会議01」で発表しました

2014/02/08 に開催された「札幌市中央区Ruby会議」で「趣味プロダクトで楽しいコードライフワークを送る」という題で発表してきました。

自分にとっては初めてこういったイベントでの発表だったので、正直、@tricknotesさんから発表の依頼を受けてから内容をどういう方向に持って行こうかすごく悩みました。

RubyやRailsの技術的な話は自分にはできないし、自分に話せることは自分が実際にやっている趣味プロダクトの話しくらいかと。今ではライフワークのようにほぼ毎日コードに触れて趣味プロダクトを楽しんでいますが、そもそもなぜ自分はこうしているんだろうと思い始めました。

趣味プロダクトを続ける理由はいくつか思い当たりました。純粋にプログラムを書いて動くのが楽しい、モノづくりが楽しい、自分が作ったもので誰かの役に立てるのが嬉しい、モノづくりを通していろんな技術に触れられるのが楽しい、チームに貢献できて嬉しい、など。

そう思い始めたきっかけは最初に作った「かんばんりすと」という趣味プロダクトを通して得られた経験が大きかったのかと思います。自分のために作ったものが予想外に他の人の役にもたったり、仕事の中で使うことでやり甲斐を感じたり、そして気が付くといろんな技術やノウハウが身についていたり。

Githubやherokuなどの基盤インフラもそれを後押ししてくれました。Githubでコードを公開しながらコミットを重ね、並行して heroku でデモサイトを公開することで、興味を持ってくれた人がすぐに動くものを触れることができてもし気に入ったら clone して自分用に使える。そんなことを簡単にさせてくれるこれらのツールやサービスのおかげで、様々な人からフィードバックを貰いましたし、そこから来るモチベーションの向上も大きかったと思います。他言語化なんて全くしていないアプリなのに、外国の方からも問い合わせや嬉しい言葉を貰えました。

自分が思うプログラマというのは、仕事とか趣味とか関係なくプログラミングを純粋に楽しいと思える人なのかなと思います。なぜかはわかりませんが自分は運良くそう思えたので、仕事として「食べるためにコードを書く」だけじゃなくて何の制約も無い場でプログラミングによるモノづくり自体を楽しんだり、自分の身の回りのちょっとしたことを豊かにする為にコードをもっと書きたいと思いました。

自分が好きで作ったものは例え他人から見て大したこと無いようなものでも、それを作る過程の苦労やその中で得られた経験があるのでとても愛着が湧きます。完璧じゃない自分が作ったものなので良い所もあれば悪いところもあるので、なるべく短所を減らして少しはマシにしてあげようと日々手をかけて育ててくのも楽しいです。

どう育てていくかは全て自分が決められるのでその可能性は無限大です。細部にこだわって見た目を改善していくか、思い切って構成を変えて中身を綺麗にしていくか、機能をどんどん追加して便利にしていくか。昔ルナティックドーンというゲームがあって、基本的に固定のストーリーは無く自分でやりたいミッションをひたすらやっつけていくあの感じに似てるなぁと思います。自由度の高いゲームは最初は取っ付きにくいけどハマれば飽きにくい。そしてクリア(完成)はない。一旦できた！と思って一区切りしても、1ヶ月後に改めてみたら改善点がたくさん見えてくることもある。

趣味プロダクトを継続していると自分のできる事が増えて見える世界も日々変わってくるので、前に作ったものがその先ずっと100%満足した状態を保つことは起こりにくいのかと思います。そんな時はチャンスだと思います。早速気になった点を issue に上げて、当時では思いつかなかった改善を施してあげるようにしています。

また、別の見方をすれば趣味プロダクトはプログラミングの良い練習場になると思います。コードに関する本などで勉強を進めていくと、サンプルコードだけではなく実際のコード上で試したくなります。そんな時に自分が作っている趣味プロダクトがあると便利です。自分が作っているのでドメイン知識の理解は不要ですし、ただのサンプルコードではない現実の具体的な課題を解決するために書かれた程よいレガシーコードになっているはずなので、コードのことを集中して考えるための題材としてはなかなか適していると思うのです。やったことがないことをいきなり仕事で試すのはリスキーなので、可能な限り趣味プロダクト上で試して経験値を貯めておくのはプログラマのスキルアップとしても有効かと思います。


最初、趣味プロダクトのことを発表しようと思った時、上で書いたような自分が良いと思うことを(まだまだありますが)全体的に説明しようかと思いましたが、話が抽象的になってわかりにくいかなと思い始めました。それに、あくまでもこれらは自分がある程度趣味プロダクトを継続してきて気づいた点なので、まだやっても居ない人には共感しにくいし、もしかしたらそれ以前のハードルで立ち止まっている人が多いのかなと思いました。

なので実際に自分が趣味プロダクトを始めた時のなんてことのない経験談を具体的な事例として紹介し、それを継続するための心がけ的なことを幾つか紹介することに話題を絞ることにしました。あと最後に自分が趣味プロダクトを続けてきたことによって起こったいくつかの想定外な嬉しい出来事も紹介することにしました。これは「趣味プロダクト」はどちらかというと個人で行う内向きな活動のようにも取れますが、実はその活動を媒介として外界のエンジニアと繋がっていくこともできるんだよ、ということが言いたかったからです。そしてこれらの活動は、自分のような名もない「ふつうのプログラマ」でも出来ることなので、プログラミングを楽しみたいという気持ちさえあれば今すぐにでも始められることだと思います。

そんな気持ちが少しでもこの発表で伝わればいいかな、と思ってスライドを作りました。
少しでもプロダクトを作ることの楽しさとかやり甲斐を感じてもらえたら嬉しいです。

札幌Ruby会議2012に参加しました

ruby

2012/09/14 〜 16 の3日間で開催された札幌Ruby会議2012にスタッフとして参加してきました。

Join

私はレポート班として参加しました。

とはいってもスタッフとしてJoinするまでには結構時間がかかって、というか、気がついていたら時間が経っていて、参加したいという気持ちはあったけれどなかなかタイミングがつかめない状況でふわふわしていました。


そんなあるとき、前鼻さん等と飲む機会があってJoinできました。６月頃だったかな。丁度かくたにさんが来札されたときに僕は初めて打ち合わせに行って、自分が所属するのがレポート班というのがわかって、文章を書くのがあまり得意ではないんだけどその時点から力になれるとしたらレポート班かなと思ったのでがんばろうと思いました。

事前特集号

最初の仕事はCFPから事前特集号を書くというものでした。分量もそれほど必要なかったので書くこと自体はそれほど難しくはなかったのですが、まつもとゆきひろさんのはあまり情報がなくて結構悩みました。しかも２日目だと思っていて期限に余裕を見ていたときに、Keynoteは一回目の事前特集号に載せるというのを締め切り後に教えてもらって急いで書きました。よく連絡事項を読んでいなかった自分が悪いです。前鼻さんすみませんでした。

そうやって毎週毎週事前特集号を書いていくうちに、自分がレポートする人のこれまでの経緯というか人となりというかいろいろわかっていって面白かったです。正直、まつもとさん以外は今まで知らなかった人だったんですけど、みなさんそれぞれ活躍していて、こんなすごい人達がたくさん来るんだなぁ、と改めて実感しました。

いよいよ当日

そして当日です。直前まで自分の転職やらなにやらでバタバタしていたというのは言い訳にならないかもしれませんが、あまり練習などできず準備OKという感じではありませんでした。そこで初めてバディの hokkai さんと出会いました。なんというか、若いのにとても落ち着いていて堂々としていて頼りになる男でした。けっこう年下なはずなんですけどこういう時は全然関係ないですね。

初日は一コマですが最後の時間帯だったので時間があり、かなりそわそわしてました。セッションのメモをEverNoteに書こうと思っていたのでそこにテンプレートなど作って見なおしたりと繰り返したり。どちらかというと、他のレポート以外のスタッフとはあまり絡めず僕はレポート部屋に篭りっきりでした。そして初回のセッションでまるでスポーツのようにメモを取り、まとめる間もなくオープニングパーティに行きました。その時点でかなり焦りがありました。でもお酒を飲んでしまうと概ね忘れてしまいましたが・・・。

スタッフ宿で少し清書などしながら眠りにつきました。前鼻さんとほっかいさんと一緒で修学旅行みたいで結構楽しかった気がします。その感じで二日目、三日目とセッションでメモをとりつつすぐにレポートを書き続けるというストイックな時間を過ごしました。

レポート班は主に９会議室に陣取っていたので、そこからメンバがセッションに旅立っていく際にはなんともいえない送り出し感がありました。戦場に旅立つ感じのなんとも言えない感じの。そしてだいたいみなさんボロボロになって帰ってきていたような気がします。地味ですが、レポート班って裏で命を削っていた気がします。ちょっと大げさ過ぎますかね。でも大変だったんです。

三日目も終わり、打ち上げパーティも終わりましたが、レポート班は終わりません。僕は間違って朝まで飲んでしまったので、次の日の午後から急いで残っていたレポートを２つ仕上げました。休日だったのが幸いです。書き上げたところでとりあえず私のレポート班はここで終了しました。４日間レポートを書き続けたという特別な体験をできて、辛かったですがとても勉強になりました。札幌でRuby会議を３日間も行うという、実はものすごいイベントに少なからず協力できたのがなによりも嬉しかったです。

懇親

期間中、ひたすらレポートをやっていたのであまりRuby会議の雰囲気を味わう余裕はありませんでしたが、懇親会などで楽しかったいくつかの思い出があります。特に２日目の懇親会で外国の方と話したり永和の人と話したりそらさんと話したり咳さんにソースを見せてもらったりと。

たしかその後は前鼻さんと万葉の田中さんとほっかいさんでスープカレーを食べに行きました。田中さんがすごく気持ちのよい人だったなぁ、というのを覚えています。

kaja

そしてレポートとは関係ないですが、私をRuby kaja に選んでいただいて、Ruby会議の場に自分の名前がスクリーンに映ったのは最大の思い出です。

コードを書くのは好きですが、大した綺麗なコードも書けずRailsも見よう見まねで書いているようなレベルの私ですが選んでいただいて本当に感謝しています。kajaに選ばれていたのは事前に知っていたのですが、当日実際にスクリーンに自分の名前が出ているのを見てなんとも不思議な気持ちになりました。ホントにいいのかなと。

kajaの名に恥じぬよう、たくさんコードを書いていこう。

熱意

自分はレポート班として参加したRuby会議ですが、開催までのスタッフのMLには膨大のメールが流れていました。準備に関わる膨大な作業をみなさんそれぞれ仕事を持っている中で粛々と行なっているのを目の当たりにしてただただ関心していたというか、そんな言葉では表しきれない気持ちで見ていました。

そこに関わるやりとりを見ていると、とにかくこのイベントを成功させたいというみなさんの熱意が伝わって来ました。なんなんだろう、この情熱。すごいなぁ、と。当日、あれだけの人数の参加者がいる中で大きな問題もなく無事会議をやりとげられたのはあの綿密なやりとりがあったからなのかなと事後に思っている次第です。

最後に

とにかくRuby会議に関われてよかったです。ちょっと前までは自分がスタッフとしてこういうイベントに参加するなんて夢にも思いませんでしたから。そこに至るまでのすべての出逢いやきっかけに感謝します。

うまく結びの言葉は見つかりませんが、みんなすごい人達でプログラミング好きな素敵な人達でした。僕ももっとプログラミング好きになれるようがんばろうと思いました！

追記

技評さんのレポートがFixしました。

ちなみに僕が書いたレポートは、増井さん、まっつさん、LT、三村さん、長永さん、でした。

「コタれん」にOAuth認証機能を追加してみた

rails Heroku

OAuth認証を試したいと思い、コタれんにOAuth認証機能を追加してみた。

コタれんでは既に devise による認証機能を持っていることを踏まえ、やりたいことは以下とする。

  • devise で既に登録されているユーザの emailアドレスと OAuth認証でログインした時の emailアドレスが一致すれば同一ユーザとして扱いたい

　devise 1.4.9 (あれ、古い?!)

Facebook にアプリを追加

  • 上記サイトでOAuth認証させたいアプリを追加する。
  • 後に「App ID/API Key」と「アプリのシークレットキー」を使うのでメモったりしとく。

ソースコードを修正

サーバ起動時にエラー

  • wikiに書かれている変更をひと通り実施し、ローカルでサーバを起動しようとするとエラーが発生。
    • oa-core gem が足りないらしい。
  • 対処
    • Gemfile に追加して bundle 
gem 'oa-core'

ログインでエラー

  • 「Sign in with Facebook」のリンクをクリックして Facebook へリダイレクトされるはずがエラー発生。
  • heroku のログを見ると以下が出力されていた
Started GET "/users/auth/facebook" for 127.0.0.1 at 2012-06-22 00:52:03 +0900
NoMethodError (undefined method `info' for nil:NilClass):
  • 対処
    • config/initializers/omniauth.rb を追加し以下を追記。
  OmniAuth.config.logger = Logger.new(STDOUT)
  OmniAuth.logger.progname = "omniauth"

Facebookからのリダイレクト時にエラー

  • ユーザの検索でエラーになっているらしい
  • 対処
    • 既に登録されているユーザを email アドレスで判定したいため以下のように修正。
    • app/models/user.rb
  def self.find_for_facebook_oauth(auth, signed_in_resource = nil)                                                     
    user = User.find_by_email(auth.info.email)                                                                         
    unless user
      user = User.create(name:auth.extra.raw_info.name,                                                                
                         email:auth.info.email,
                         password:Devise.friendly_token[0,20]                                                          
                        )
    end
    user                                                                                                               
  end

ログイン成功！　Facebookに登録していある email と同じIDが既に存在すればそのユーザ情報でログインできるようになった。

本番環境にデプロイ時の注意事項

  • heroku にデプロイ時にFacebookに登録したアプリ情報の「App ID/API Key」と「アプリのシークレットキー」を環境変数として設定する必要がある。
$ heroku config:add FACEBOOK_APP_ID=xxxx --app kotaren
$ heroku config:add FACEBOOK_APP_SECRET=yyyy --app kotaren
  • あとはいつも通り push する。
$ git push heroku master

おまけ：アイコンのURLを取得する

  • ログインした後の曲一覧画面で、Facebookのユーザに紐付くアイコンを表示したくなったので認証時に Facebookから取得できる情報を調べてみた。
 provider: facebook
 uid: "xxxx"
 info: !map:OmniAuth::AuthHash::InfoHash
   nickname: xxxx
   email: xxxx
   name: xxxx
   first_name: xxxx
   last_name: xxxx
   image: http://graph.facebook.com/xxxx
   urls: !map:Hashie::Mash
     Facebook: http://www.facebook.com/xxxx
   verified: true
 credentials: !map:Hashie::Mash
   token: xxxx
   expires_at: xxxx
   expires: true
 extra: !map:Hashie::Mash
   raw_info: !map:Hashie::Mash
     id: "xxxx"
     name: xxxx
     first_name: xxxx
     last_name: xxxx
     link: http://www.facebook.com/xxxx
     username: xxxx
     gender: xxxx
     email: xxxx
     timezone: 9
     locale: ja_JP
     verified: true
     updated_time: xxxx
  • アイコンのURLは user.rb の self.find_for_facebook_oauth() にて「auth.info.image」で取得できることがわかる。後は user モデルにアイコンURL用のカラムを追加するなどして保持しておき、Viewに表示するようにする。


前にRuby勉強会でコタれんのレビューをしていただいてから、ずっとOAuth認証が気になっていたのでやっと実現できてよかった。次は twitter とかにもチャレンジしてみたいな。

herokuのステージング環境を作る

rails Heroku

幸いにもかんばんりすとやコタれんを使ってくれている人がいるのでとても嬉しいのだけど安易に本番環境に変更を加えるのが恐い今日この頃。トラブってせっかく使ってくれている人に迷惑をかけてはいけない。

変更を加えた時はローカル環境でもちろん動作確認はしているけれど、厳密には heroku 上の環境と違うのでローカルで動いていてもいざ heroku にアップロードしたら動かないなんてこともよくある。そういう場合は heroku 環境に依存した問題であることが多いので解決まで多少時間がかかるし、本番環境がエラーを抱えたままだとプレッシャーになって落ち着いて解析ができなくなってしまう。本当に心臓に悪い。

そんなわけで今更ながら heroku 上に一旦動作を確認する為のステージング環境を作ってみたのでその覚書。
以下はコタれんの例。

ステージングの作成

  • heroku 上に作りたいアプリのステージング環境を作成。-staging など付加するとわかりやすいかも。
$ cd kotaren
$  heroku create kotaren-staging

stackを変更しつつステージング環境を作成するには

  • 本番環境が最新の stack を使っていない場合はステージング環境も本番と同じ stack で作っておいた方がいいと思う。
  • 本場環境の stack を調べておいて --stack を付加して create で実施。(例は bamboo-mri-1.9.2 を指定)
$  heroku create kotaren-staging --stack bamboo-mri-1.9.2

リモートブランチに追加

  • 作成したステージング環境のリポジトリをリモートブランチに追加する。作成時に表示される git@〜　を使用する。
$  git remote add staging git@heroku.com:kotaren-staging.git

アプリをアップロード

  • master の内容をそのままアップロードしたい場合は以下
$  git push staging master
  • branch をアップロードしたい場合は以下。
    • 大きな変更をする場合は大抵ブランチで作業していることが多いので master にマージする前に直接ブランチをステージング環境にアップロードして動作確認するのが良いと思う。
$  git push staging a-branch:master
  • ちなみにアップロードで失敗になったら -f で強制的に上げる方法もある
$  git push -f staging a-branch:master
  • migrate や seed は --app を使ってアプリ名を指定する
$  heroku rake db:migrate --app kotaren-staging
$  heroku rake db:seed --app kotaren-staging
  • 再起動しとく
$  heroku restart --app kotaren-staging

これでステージング環境に指定したブランチのアップロードが完了。思う存分動作確認できる。

使い終わったらメンテナンスモードに切り替える

  • 使わない時は外に晒さないようにメンテナンスモードをONにしとくといいかも。
$ heroku maintenance:on --app kotaren-staging

もう大きな変更をするのも恐くない！

よく使う mongodb のコマンドメモ

mongodb
  • mongo DB シェルへのログイン
$ mongo
MongoDB shell version: 2.0.4
connecting to: test
  • データベース名のリスト表示から選択
> show dbs
devhub_chat_db 0.0625GB
local (empty)
test (empty)

> use devhub_chat_db
switched to db devhub_chat_db
  • コレクション名の表示
> show collections
chat_log
latest_text
system.indexes
text_log
  • コレクション内のデータを表示
> db.chat_log.find() 
データの内容・・

  • 詳細はこちら

http://www.mongodb.org/pages/viewpage.action?pageId=5537874

node.jsアプリで heroku から mongoLab に mongodb で繋ぐ方法

javascript mongodb node.js

node.jsを使って作成したチャットアプリ(DevHub)を mongodb に対応した時の覚書。

DevHub

https://github.com/volpe28v/DevHub

やりたかったこと

  • 一つの DB を複数の Model から利用したい
  • Model からはそれぞれのテーブル名を定義してデータ保持したい
  • Model 間の依存関係を減らしたいので Model はそれぞれライブラリ化したい
  • 各Model は DB 名を意識したくない。知っているのは自分のテーブル名のみ

heroku側の設定

・heroku から mongolab を使うには heroku 上で addon を verify しておく。クレジットカード番号などが必要
・アドオンをインストールする

$ heroku addons:add mongolab:starter

package.json に mongodb を定義

  • mongodb は最新では heroku 上でのインストールでエラーになったので、とりあえず 0.9.8 では上手くいった。(2012/03/28 時点)
{
  "name": "DevHub",
  "version": "0.0.1",
  "dependencies": {
    "express": "~> 2.5.1"
  , "commander": "~> 0.5.2"
  , "ejs": "~> 0.4.3"
  , "socket.io": "~> 0.9.2"
  , "mongodb": "0.9.8"
  }
}
  • npm install する。

mongodb への接続ロジック

  • DBへの接続の仕方は、ローカルでは open() で良いが、heroku では connect() を使う
  • ローカルか heroku の判定は process.env.MONGOLAB_URI が存在するかどうか
  • ローカルの場合は open() のコールバックで db を取得する
  • heroku の場合は connect() のコールバックで db を取得する
  • 受け取った db を使いたいオブジェクトに設定してあげると、db 経由で db.collection() などが叩けるようになる。

コードイメージ

  • まずは db を取得する為のライブラリを作成。(lib/mongo_builder.js)
var mongo = require('mongodb');

module.exports.ready = function(db_name, callback){
  if ( process.env.MONGOLAB_URI ){
    // herokuの場合の処理
    mongo.connect(process.env.MONGOLAB_URI, {}, function(error, db){
      callback(db);
    });
  }else{
    // localの場合の処理
    new mongo.Db(db_name, new mongo.Server('127.0.0.1', mongo.Connection.DEFAULT_PORT, {}), {}).open(function(err,db){
      callback(db);
    });
  }
};
  • 呼び出し側のコード。ready()で取得した db を利用者(Model)に渡す。
var mongo_builder = require('./lib/mongo_builder');
var chat_log = require('./lib/chat_log');

mongo_builder.ready(db_name, function(db){
  chat_log.set_db(db);
});
  • 利用者では受け取った db に対してテーブル名を指定しつつ書き込みなどを行う。(lib/chat_log.js)
var db;
var table_name = 'chat_log';

// db を受け取ってローカルに保持
module.exports.set_db = function(current_db){
  db = current_db;
};

// チャットメッセージ保存処理
module.exports.add = function(data){
  db.collection(table_name, function(err, collection) {
    collection.save( data, function(){} );
  });
};
  • このような作りだと、利用者が増えても ready() のコールバックに設定することで同一 db の利用が容易にできる。
var mongo_builder = require('./lib/mongo_builder');
var chat_log = require('./lib/chat_log');
var text_log = require('./lib/text_log');  // 利用者を追加

mongo_builder.ready(db_name, function(db){
  chat_log.set_db(db);
  text_log.set_db(db);  // 利用者へ db 設定処理を追加
});

おまけ

  • ちなみに、heroku 上で日本時間にするには以下を叩く。
$ heroku config:add TZ=Asia/Tokyo