■ [tDiary][ruby] tDiary-3.1.2.20120328 日記とコメントデータの Heroku 対応(PostgreSQL 対応)に続いて日記の erb コンパイル済みデータ等のキャッシュを memcached に保存する仕組みを作った。これで heroku でもだいたい満足行く性能で動くはず。あとテスト用のアプリケーション名を変更した。 http://tdiary.herokuapp.com http://anonymous.hsbt.org どっちでも同じ物が表示される。 memcached に保存できるようにしたついでにキャッシュを保存する仕組みを tDiary のビューでありモデルである TDiaryBase というクラスから切り離したので、memcached だけではなく Redis のような KVS にも簡単に保存できると思う。Heroku, またはローカル
![[tDiary][ruby] tDiary-3.1.2.20120328 - HsbtDiary(2012-03-29)](https://cdn-ak-scissors.b.st-hatena.com/image/square/0c371c9279d343258b25d1dc22553b5a8889b64b/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fwww.hsbt.org%2Fdiary%2Ftheme%2Fogimage.png)
■ [git][github][tDiary] master ブランチで pull request していいのは小学生までってこともない GitHubへpull requestする際のベストプラクティス - hnwの日記を読んで感じたこと。 このエントリではmasterブランチで pull request していいのは小学生までと言われているけど、少なくとも tDiary ではどうでも良いからパッチ送れとしか思わないなあ。 具体的には master ブランチで作業したものを pull request しても別にコードの内容に問題がなければがんがん取り込むし、コンフリクトがひどかったり、なんじゃこりゃというのは差し戻すのでパッチを投げる側は気にする必要はない。繰り返すけど、Gitのお作法よりもコードの内容の方が重要ってことを頭に置いた方が良い。 もちろん、件の記事のようにちゃんと Git を
■ [github][git][tDiary] github に tDiary の svn リポジトリのミラーを作った 某所で要望があったので作ってみた。 http://github.com/hsbt/tdiary/tree/svn/trunk http://github.com/hsbt/tdiary/tree/svn/stable refname が適当なので上のようなパスになってしまっているけど、世間一般的にはどういう名称にしているのかなー。 ひとまず、github の master は角谷さんとオレとでがりがりいじっている experimental として使っていて、上の svn/trunk はオレが svn リポジトリに入れるつもりなコミットを突っ込む場所として使っているつもり。
■ [sappororubykaigi01][ruby][tDiary] 札幌 Ruby 会議 01 で発表してきた 発表してきた。発表資料は使う使う詐欺状態だった rabbit で作った。興味がある人は下からどうぞ。 わたしとtDiary rabbit のソース 詳しくは後で書く。 ちょっと自分の発表中の動画は見ていないので、外から見た振り返りというものはできないんだけど、やってて発表部分で思ったことをつらつらと。 前日に声に出して読むのはいいね。 rabbit の亀機能はとても便利。時間を見て確認しておくというのも手ではあるけど、プログレスバーのようなモデルで確認できるのは発表中にあわわとなっている状態では丁度いい。 20分の発表で68枚はぎりぎりだったかも。最初の自己紹介がぐだぐだすぎて、最後の人材募集の部分をはしょってしまった。 全員が tDiary を知ってるという前提だったけど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
