on Rails : 第5回Rails勉強会@関西
ちょっとした個人的なまとめ．録音したい．だれかポッドキャストしてくれないかな．他力本願過ぎて泣ける．
アジャイルにデータモデリング
- 業務システムに使用するには，Railsには不十分なとこがあるよね
- 業務システムはこーゆーもんだからこーゆー風に改善して欲しいな，みたいな
業務システムの典型
- 財務システム
- 人事・給与システム
- 営業管理システム
これで企業が出来てる感じ．上の２つは，ほとんどの企業がパッケージで入れてる．問題は，「営業管理システム」．コレをうまく作ると，事業の足を引っ張らない，その程度でしかない！(事業がウマくいって売り上げが上がるとかではない．)
具体的には，販売管理システム，生産管理システム，契約管理システムetc...こういうものを，事業を問わず，事業を支援するものとして営業管理システムがある．
営業管理システムの，OSやゲームなどのソフトウェア開発と違いは，以下のような事が上げられる．
- DBが中心
- 社会的な広がり
業務システム三つのキーワード
- 簿記(これがわかんないと，業務システムの世界に入っちゃ行けない)
- モデリング
- 個々の業務知識
簿記はまぁ3級で良い．2級は別に要らん．SEがしなくて良いような，馬鹿馬鹿しい事までしないといけない:p財務システムとのインタフェースがわかってないと，何もできない．だから，簿記とか会計システムの構造を学ばないといけない．
モデリング
- データベース
- アプリケーション
- ユーザ
それぞれのあり方をモデリングしないといけない．今回は，その中でデータベースに関することの話です．業務システム→営業管理システム→モデリング→データベース．
XEAD
XEADで検索すれば，いろいろでてくる．その中の，コンセプトウェア．コンセプトウェア財務管理．
やばい，どんどん話がわからなくなってきた．
デカイものを作る時，モデリングの技術を駆使しないと訳が分かんなくなる．何はともあれ，画面がスゴいことになってたけど．XEAD，タダでダウンロードできるんだけど，その前に簿記を勉強した方が良いよ．
論理と実装
モデリング=論理設計．実装は，物理制約と論理要件の両方の影響を受ける．
- データ構成
- 機能構成
- 業務構成
それぞれにおいて，論理制約にはモデルが，物理制約にはそれぞれ
- データ構成:ストレージ技術，DBMS
- 機能構成:PGM言語，実装技術，通信技術
- 業務構成:社風，評価制度，実組織
が存在し，それぞれの実装がそれぞれの制約の影響を受ける．
最外殻には業務モデルが，その内側に機能モデル，中心にデータモデルが存在し，レイヤーになってるイメージ．業務モデルからデータモデルは直接参照できない感じ．
関数従属性
懐かしい言葉！って前期にじっくり勉強したばかりだよ．
例)会員Noがわかれば会員名がわかる．しかし，会員名から会員Noが求められるとは限らない．
会員名 = f(会員No) = テーブルTの会員Noを持つ，会員名の値
これぞRDB．
f(a) = b，a → b
bはaに関数従属する．
- a:識別子
- b:従属子
てゆーか，だいたいが授業の復習だな．参照関係とか多重度とか．さすがにわかる．そして，図ばっかりだから，ちょっと書けない．
ActiveRecordておかしいぞ
複合キーが使えないっちゅうのは勿体ない．それと，やっぱり多対多の関係は気持ち悪い．
1:1ってのも不安定．でも，外部キー使っちゃえば良いんじゃネーノ？
Rails Chat
Rails本体にはそんなに関係無いそうで．Rails Chatで検索すればわかる．
Juggernautの説明
タイガーバームクーヘン
artonさんがそれをゴニョゴニョ→Tigerbaumkuchen
ジャガーノートは名前がカッコいいけど中身があんまり→タイガーバームクーヘンは名前がアレだけど中身がカッチリ．
Rails pluginとして配布．
ジャガーノートのあまり嬉しくない点を改良！
- ping/pong:自動切断対策
- クライアント単位の送信用スレッド:安定性を向上
- メッセージの追い抜きを防止
Rails Chatの開発
オフレコモードや過去ログがあったりする．すげぇ．コードを書き込むと，そのコードがダウンロードができたりして便利そう！
Rails Chatの動作原理
Rails ChatはPush ServerとRailsで動いてる．クライアントはFlashとJavaScriptで．
FlashとPush Serverが通信し，FlashがJavaScriptを呼びにいく．新しいユーザがやってきたことをJavaScriptがRailsに教えて，RailsがPush Serverに新しいユーザがやってきたことを教える．で，Push ServerがクライアントのFlashに新しいユーザのことを一斉配信する．
ぐるぐる回る感じだな〜．
このシステムのキモは，クライアントのFlashとPush Serverのコネクションが維持され続けるってこと．HTTPって感じじゃないな．
Rails 初心者レッスン第２回 - ActiveRecord入門
配布されたレジュメは，はじめようRoRのAR的内容．何だかんだでよくできているAR．モデルが単数系，テーブルは複数形っていう規約，Personに対しPeopleに，Mouseに対しMiceなるのは，何かしらそういうテーブルがあるようです．以下Tips．
find
- idで検索してヒットしなければ例外
- firstで検索してヒットしなければnil
- allで検索してヒットしなければ[]
idで検索してヒットしなければ例外か，begin-rescueでエラーメッセージをブラウザに表示しないようにしないと，ちょっと恥ずかしいよな．nilが返ってくるのも同様に，nilクラスにメソッドが無いよエラーが出ないようにしないと，こちらも恥ずかしい．まぁその辺はnil?を使えば良いよな．[]にしても同じだ．empty?を使えば良い．
find_by_hoge
これは良くできてると思う．find_by_name_and_emailとか，動的にメソッドを生成しているのかな．ARすげーな．
update
hoge = Hoge.find(1) hoge.fuga = 'piyo' # まだ変更されない hoge.save # ここで変更される
findでインスタンスを作成し，値を変更しただけではテーブルは更新はされない．値の変更と同時にテーブルを更新したい場合は，
Hoge.find(1).update_attribute(:fuga, 'piyo')
複数の値を同時に変更したい場合は，
Hoge.find(1).update_attributes(:fuga => 'piyo', :foo => 'bar')
とする．attribute's'で複数形なだけなのな．一応ハッシュで渡すことになっているので，厳密には
Hoge.find(1).update_attributes({:fuga => 'piyo', :foo => 'bar'})としたほうが美しそうだ．
delete or destroy
- destroy:まずインスタンスを作成し，そのインスタンスのdestroyメソッドを呼ぶ．before_saveなどのコールバックも呼ばれる→安全ってことかな．
- delete:インスタンスを作成せずに削除．before_saveなどのコールバックが呼ばれない．
レジュメにはこんな感じに書かれているのだけれども，これはクラスメソッドの事だよな．インスタンスメソッドにdeleteは無いものな．
hoge = Hoge.find(1) hoge.destroy # これで削除される hoge.fuga = 'piyopiyo' # destroyしたインスタンスは変更できない何故なら hoge.frozen? => true # 凍結されてるから．
かといって，freezeしても削除はできる．
>> dummy = Person.create(:name => 'dummy', :email => 'dumm') >> dummy.freeze >> dummy.destroy >> Person.find(dummy.id) ActiveRecord::RecordNotFound: Couldn't find Person with ID=3 # 以下略
destroyした所でインスタンスは変更されないからだろうな．インスタンスが変更されなくてもテーブルから消せさえすれば良いのだから．・・・これって脆弱性とかじゃ無いよね．
以上，ARでDRADでした．
