方針 Rubyを知っている前提です(前回の勉強会の資料 http://dev.ariel-networks.com/articles/workshop/ruby/) RDBの基礎知識が前提です なるべく手を動かして目に見える形で説明を進めます Ruby on Rails(以下、Rails)全体は巨大なので、ActiveRecord(ORM層)に話を限定します(Web層は次回) Webから切り離してirb or コマンドラインでActiveRecordを使います
query-reviewerはRails用のプラグインで、データベースにMySQLを使っている場合に、不適切な検索が行われていないかどうかを非常に簡単に調べることができる。(MySQL以外ではたぶん動かない。)使い方は非常に簡単で、 git clone git://github.com/dsboulder/query_reviewer.git vendor/plugins/query_reviewer するだけ。設定等はまったくいらない。インストールすると、Railsアプリの左上に「SQL DISABLED」というボタンっぽいのが出てくるので、そこをクリックしてENABLEDに変えてからページにアクセスすると、SQLの実行結果を教えてくれる。 スクリーンショットは開発者のブログで見られる。 大体、以下のような情報が得られる。 SQL EXPLAINの結果 SQLの実行時間 どれだけのSQ
前回のつづき。 前回、SQL文というプログラムそのものを貼り付けたエントリーを書きました。 技術者が見れば下手糞な SQL と思うでしょうし、技術者じゃない人が見たら、訳の判らない文章になるでしょう。 あの SQL文という呪文は、文章を考えたときのまま書いたものです。 つまり、顧客が言い出しそうな変更を考えて、瞬間的にプログラムにし「下手糞なSQLやのう〜」と思いつつ、もっときれいなものが浮かんでも元のまま書きました。 下手糞ではありますが、打合せで話がでた瞬間にプログラムは脳内で完成しているからこそ、私は「出来ます。やります。」と即決できます。 逆に、その下手糞レベルのコーディングが出来なければ、私は怖くて顧客と話が出来ません。 「そんなものが出来るからどうした?」と思う方も大勢いらっしゃるでしょう。 しかし、これは非常に重要なのです。 前回のエントリーでの顧客の依頼を整理すると。 マー
hisyamadaより: XPの導入をしようとした私はすぐに大きな壁に突き当たりました。それは「全員同席」と「ペアプログラミング」でした。全員同席とはユーザ、マネージャ、開発者が一箇所で開発を行うという考え方で、システム開発のスピードを加速させ、利害関係の不和を解消するために考え出された手法です。特筆すべきは顧客と開発者を同席させると言うもので、開発過程で明らかになる不明瞭な要求や仕様を、同席している顧客に即決させる[続きを読む] XPもよいと思うのですけれど、弊社はSQLにこだわっています。 一般的にDB(SQL)のスキルがなさすぎなんですね。 弊社の入社試験の変形型で説明します。 使われるテーブルは 得意先マスタ 得意先コード 得意先名 住所 ・・・ 受注テーブル 受注ID 受注日 得意先コード ・・・ 受注明細テーブル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く