「http://d.hatena.ne.jp/idesaku/20080622」が参考になります。
さらに仕事に使うRuby(後藤 謙太郎(ごとけん))
Hiki、Redmine、影舞、Fastladder を多用との事。さらに、Fastladder で RSS を取ろうにも出してない所は、Rubyで取ってきて RSS作ってしまえ。
これらのセットを案件毎顧客毎に設置する。ごとけんさんのお仕事中に割り込みで新規案件用の設置作業が入ってくるので大変。少しずつ自動化してて、完全自動化まであともう一歩との事。
erbを偲んで(関将俊
別に偲んだりしてないです。
erb、eRuby 或いはテンプレートと View の話し。よくデザイン(デザイナー)とプログラム(プラグラマー)の分離(分業)っていうけど理解できない。
View は環境とか、モデルと一緒にいて初めて意味がある。それらは二つになってるけど、互いに相手をちゃんと知ってないと(意識してないと)意味が無い。グラフィックプログラムで、座標指定なんかを別場所に括りだしてロジック周りをすっきりさせるのと一緒。
大体 ERB をテンプレートエンジンとしてだけ使うのも変で、ERBオブジェクトを Rubyコード中で使いまわすのが基本でしょう。ERB#def_method でメソッド化したり、或いはモジュール化クラス化も出来るし。
考え方として一歩先にいってるというか、大変基本的な所に立ち返っていて参考になる。しかし、Railsプログラマーだったとして Railsの枠内ではどうしたら良いのだろう。
日本Rubyのリファレンスマニュアル2008・初夏(青木峰郎)
Tk、SOAP を除けば結構良いとこまで来てる、組み込みライブラリは殆どカバーしたし、来夏には標準ライブラリもカバーできるのではないか(二つ除く)。
また、クラス・メソッドの解説だけじゃなく、言語仕様についての方も出来るような体勢にしてきてる。
ということです。
REST信者から見たRuby on Rails 2.0(山本陽平)
RESTの4原則は原則であって必ず全部守らなくちゃいけないという物でもない
- アドレス可能性
- 接続性
- 統一インタフェース
- ステートレス性
それに軽重もある。
ステートレス性はあんまり気にしなくていい、認証情報をセッションとかクッキーで持ち歩くとかは否定しない、今はそのまま続けてて良いと思う。とか
Real-World Enterprise Ruby(大場光一郎・高井直人)
CTC 伊藤忠テクノソリューションズで Ruby を使うようにした/なった経緯というか道筋。多分十年前に Javaを導入したときも同じような事があったんだと思うし、将来何かまた新しい何か(言語/フレームワーク/アーキテクチャ/何か)を導入するときにも同じような事を為すのだろう。
経営層に提案し、営業用の資料を作り、見積り方法や根拠を示し、教育体制を整え、(余所で)開発実績を積み、検証センターは地味な検証を沢山たくさん。
先々月 Rails' Wiki - Rails勉強会＠東京第29回に行ったとき、「前半セッション「ログローテートどうしてますか? (運用ノウハウ)」 - Rubyとか Illustratorとか SFとか折紙とか」というセッションで沢山お話し頂いた、それは凄く参考になっている。その背景にはこんな大きな意図があったんだ。意識というか覚悟というか。ただ実験や検証、分析をきちんとやってるというのではなく、何のためにそういう行動をしているかが見えてくるとその意味が全然変わって捉えられようになる。
なんか照れくさいけどその事に凄く感動した。
スケーラブル Rails
- Developing and scaling iKnow!(Zev Blut)
- Inside Tabelog's Backend(京和崇行)
- Using Ruby to Build a Scalable Startup(Alex Kane, Tunecore.com)
夫々に特徴はあるけどどれもスケーラブルになっていった事例紹介。Railsでも普通にこれくらいいけますよと。
前二者はサーバ構成はフロントのWebサーバ(ロードバランサー)2台、アプリケーションサーバ(Rails)数台、DBサーバ2台といった構成。それにファイルサーバがあったり、DBにバックアップ兼予備機とか。
後者は、音楽等の仲介サービス(演者 <-> iTune とか複数の配信サービス)なんだけど、その片方側はアマゾンEC2の仮想マシンとアマゾンS3のストレージを使ってるとの事。安価でもスケーリングの心配は軽い。
それでもきちんと監視・分析・チューニングしてけば普通に大変大きなトランザクションも何とかなるという話し。落とし穴は一杯あるけど。
