サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
都知事選
blog.livedoor.jp/susatadahiro
5 Rails Plugins to Help Optimize Your MySQL http://blog.purifyapp.com/2010/06/15/optimise-your-mysql/ 気になったところは、gitにある各プラグインのドキュメントを読んでみてください。 Bullet http://github.com/flyerhzm/bullet/ ActiveRecordで :include句を使うと紐付いたレコードも一度にまとめて取得できるようになる。で、実際にアプリ内のどのmodelで:includeを使ったほうがいいよ、とかそういう情報を出してくれるのがこのプラグイン。 ーあと、カウンターキャッシュ(子レコードの件数を親側のmodelで持つことで、子のテーブルをselect count(*)しなくて済むやつ)やらeager loadingがちゃんと使えてるかの情報
http://www.matthewpaulmoore.com/ruby-on-rails-code-quality-checklist まずは見出しの部分だけ、ざっと。 本文を読むと、もうちょっと適切な訳になるかも。 ---- Ruby on Rails Code Quality Checklist 1. Each controller action only calls one model method other than an initial find or new. (Make custom .new or .update methods in the model with all necessary). ... コントローラーの各アクションはデフォルトで生成されるfindやnew以外のモデル生成or取得メソッドを1つだけ実行する。 ( 本当に必要な時だけ独自に実装したnewやu
Load Balancing in Amazon EC2 with HAProxy http://agiletesting.blogspot.com/2009/02/load-balancing-in-amazon-ec2-with.html 全体的に ■設定ファイルの書き方 かなり普通な感じの書き方。mod_proxy_balancerの書き方と雰囲気は似てる。というか、普通な感じ。 ■maxconnの値 デフォルトで2000になっている。 それを超えるとキューされる。 25,000くらいがいいと思うよ、とのこと。 ■だいたいの性能 かなりいい。 20,000コネクションくらいのアクセスが来てるとき、ec2のsmallインスタンスでCPU使用率1%くらい。 これ以上のアクセスが来たら、HAProxy以外の部分がボトルネックになってるだろうから、これで十分だよね。 メモ:smallインスタ
http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/ Nginx and Memcached, a 400% boost! NginxはWebサーバなんだけど、アプリサーバに振り分ける前に、使えるキャッシュがないかMemcachedを調べるモジュールがある。このモジュールが活きると、アプリサーバでの処理が省けるので、レスポンスが低処理コスト、高速レスポンスになる。 キャッシュヒットせずにアプリサーバで処理した場合、それをMemcachedサーバに登録すると、Nginxが次回からそっちを使ってくれる。 URLをうまく使うための方法など。
(2009/12/20追記) この記事が世間に嘘をばらまいている気がしないでもないので、さらにアップデートしました。 やっぱり、ちゃんとやり直さないといけなかったようです。 gitがおかしくなってportでインストールしようとしたらコンパイルエラーのようなモノが出て、そのときのメッセージで下記のアドレスが表示されました。i386とx86_64で違うから↓の手順で直してね、と。 http://trac.macports.org/wiki/Migration **Reinstall Xcode and MacPorts xcodeのDVDでツール類を入れる。 **To reinstall your ports: *** Save the list of installed ports: port installed > myports.txt *** Uninstall all install
■業務仕様書は、1つ1つの独立した業務仕様(ページ)の集合体である。 業務仕様書は、何十ページも連続したドキュメントではなくて、ひとつの仕様を1ページに書いていったものの集積された状態がベストなんじゃないか、という感覚があった。 ■業務仕様では「用語(キーワード)」が重要 業務仕様(書)では、単語、キーワードが非常に重要な役割を果たす。 ■キーワードにもっと注目させる方法 キーワードを活かすには、「はてな」が自動で行うキーワード抽出&自動リンクがぴったりなのではないかと、ふと思った。 自動でやってくれるところがポイント。そしていつでもクリックして、その用語説明に行ける。要件定義が進むにつれ、逐次、加筆されていく。しかも、それは複数人で次々と加筆できる。 未定義語は自動リンクされないので、一目でわかる。つまり、その用語の定義を書かなくちゃいけないことがわかる。 ■業務仕様書は、常に不完全な状
追記(2010/01/25) [memo]アメリカの創業ベンチャーキャピタルの秘訣=「系列」 http://blog.livedoor.jp/susatadahiro/archives/52422708.html ==== 日本のベンチャーとアメリカのベンチャー たぶん構造というか対応関係が違うだけで、似てるんじゃないかと思ったので、それについて書いてみる。 かなり適当な聞きかじり知識満載なので、あしからず。 数値の裏付けを取る作業も、もちろんやってないです。薄い記憶を引き出しただけです。 つまり、検証する前の ただの仮説です。 --------- ■車会社の場合 トヨタ 年1兆年を研究開発に投入している。もちろん人も。 それまでの主力商品ガソリン車に対抗してしまう存在であるハイブリッド車、電気自動車にリソースを大量に投入して開発している。 エンジンを否定してしまう電池、モーターにリソース
気分とか情以外の分を、仮説、仮定、仮置きを多用して推測していきます。 -------------------- 全株式のうち 50%:ベンチャーキャピタル等 50%:会社で働く人 ↓このうち 25%:幹部 25%:一般従業員 上場の目安は年間売り上げ10億円という話をかつて聞いたことがあるので、近頃の厳しさも加味して 上場時の年間売り上げ:15億円 企業買収の目安として、 時価総額=年間売り上げ * 5年分 という目安をかつて聞いたことがあるので、 上場時の時価総額:75億円 一般従業員の総持分:75億円*25%=19億円 1人あたり1200万円の売り上げと仮定すると 年間売り上げ / 一人あたりの売り上げ = 従業員数 15億円/1200万円=125人 ざっくり割ると 19億円/125人=1520万円 上場直後に全部売る権利があって、かつ全部行使した場合 約1500万円 ----- ベン
このくらいの年俸を提示しないとダメっぽいなぁ ■spec コア人材 メンバーを率いることが出来る。 設計の出来る人 現在の設計に加えて、ある程度の先の見通しというか展開も考慮した設計。 すべてを読み切れ、というわけではなくて、どうい道筋で進めていくかについての筋の良さみたいなものがある。 インフラ担当 とはいっても結構上のレイヤーもわかるor学習可能であること ソフトウェアのこともわかる 例えて言うなら、Railsでいうとセッション情報の保存場所をDB, memcached、cookieのどれにするのか。今はcookieが推奨なんだけど、どういう経緯でそうなったのか、を理解する意思があり、また理解できる素地がある。とか。 ■待遇 現時点で、どう少なく見積もっても年俸800万円〜は貰ってるはず。きっと。 これに、不安定というベンチャープレミアム(+20%)を乗っけて ---- 800×1.2
http://developer.amazonwebservices.com/connect/entry.jspa?entryID=915&ref=featured SQS(Queue)とEC2を使って インスタンス(on EC2)を動的に増減するやり方が載っていた。 オンライン業務の負荷分散(いや、車のCVT的。階段状ではない、処理能力の変更)に使えるのかと思ったけど、そうではないようだ。 ※--- 携帯対応を考えると、「突沸」に対応できるかは重要だとおもう。 携帯は処理1回あたりのサーバ負荷は高くないんだけど、うまくいくと、伸びがすごいことになる。 (人気が持続するか否かは別問題だけど) PCサイトの場合はそうなった時に、ある程度のパフォーマンスを維持できずにパフォーマンスも機能拡張も停滞してしまってダメになるケースが多い(と一般には言われてる) ---※ この処理方式は純粋なバッチか
このページを最初にブックマークしてみませんか?
『blog.livedoor.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く