railsのfind_by_sqlでselect * ... join ... ってやるときちょっと注意

sql文を使ってデータベースからデータを取得するときに、

samples = Sample.find_by_sql(["select * from samples inner join others on samples.id = others.sample_id ...])

ってやると、joinする側とされる側に同じ名前のカラムがあると、うまくデータが取れないことがあるみたいです。
例えば2つのテーブルのカラムにidというカラムが含まれている場合、どっちのidなの？ってことで分からないみたいですね。
ちゃんと、samplesテーブルのデータですよということを明記して

select samples.* from samples inner join others ...

と取得するテーブル名を明記するようにしましょう。

バグ修正において気をつけなくてはいけないこと。

バグが報告され、それを修正するときに気をつけなくてはいけないこと。


１．可能な限り同じ条件でバグが再現することを確認する

２．バグが発生した原因を特定する

３．バグフィックス

４．最初に行った条件と同じ条件でバグが再現しないことを確認する


バグが報告される現場は、自分の開発環境と基本的には異なる。
よって、バグが報告された環境と全く同じ環境にてバグを確認することはできない。
できないなりにもできるだけ同じ環境でやった方がいい。

ユーザーのいるシステムである場合にはそのユーザー権限にて確認するくらいの方がいい。
すぐに２．や３．から始めがちだったり、違う条件でバグの確認をしがちなので注意。


最後に本当にバグは治ったの？
という問いにこたえられなくなる。

デバッグにおいて注意すべきことのまとめ

ほんの些細なことで丸1日つぶれた。
そんなことにならないためにも体系的なデバッグの仕方を定着させておいた方がいい。

ということで、今回学んだデバッグにおいて注意すべき点のまとめ。

1. エラーの場所を特定する。
基本中の基本ですね。特定しないことには何も始りません。
ただ、特定する場合も、action名を特定するだけではなく、より具体的に場所を特定しましょう。

2. パラメータを追っていく
基本的にはrailsのプログラムなどはステートレスにパラメータを渡したりしています。そのため、あっちへ行った入りこっちへ行ったり。
その途中で変な値が入る可能性があるので注意しましょう。

3. フィルタを見る
アクション、コントローラには、フィルタがあります。
特定のアクションが実行される前に実行されるアクションです。
見落としの内容にしっかり確認しましょう。

4. ログを見る
これが基本という方もいるみたいですが、重要です。
パラメータを追っていくよりログを見て実際にどのような動きをしていたのかを確認しましょう。

5. 同じ環境・同じデータで確認する
これも基本です。
不具合が報告された場合には同じ環境・同じデータで確認をしましょう。

6. 違う環境・違うデータで確認する
これはイレギュラーなケースかもしれませんが、ひょっとすると特定のデータ・特定の環境が悪いのかもしれません。
その可能性も否定できないので別の環境でも試してみましょう。



それにしても、HTTPのGETリクエストで

?ids[]="12345"

となるパラメータを渡したとき、

ローカル環境のrails君は{:ids => ["12345"]}と解釈したのに対して、
テスト環境のrails君は{:ids[] => "12345"}と解釈したのだろう？

誰か原因がわかる方いらっしゃいましたら教えてくださいm(_ _)m

泣いて喜びます。

テスト駆動開発がちょっといいみたい。

開発を進めていて、あれやったっけ？これやったっけ？
あーわからん！バグが出た！

と、ならないためにもテスト駆動開発というものがいい気がする。
テストケースのスタックの場として
自分の思考プロセスのスタックの場として
非常にうまく機能すると思われる。


以下テスト駆動開発について自分の知識の定着としてまとめ。

◆テスト駆動開発の3つの手順
1. 失敗するテストを書く
2. できる限り早く、テストがパスするような最小限のコード本体を書く
3. リファクタリングをする

細かくテストを書いて細かく実装し、全体の整合性が取れないところは後で修正しろって話か。

◆テスト駆動開発の利点
1. Clean code that works.の実践。まず動く。あとできれいに。
2. 後戻りしない
3. テストコード自体が設計書となる
4. 欠陥やバグが少ない


◆テスト駆動が適用しにくいもの
※人の判断がはいるもの　→　後戻り処理が入るため
グラフィカルユーザインターフェース (GUI) を扱うもの
　分散オブジェクト
　データベーススキーマ
　サードパーティコードや、外部ツールで自動生成されるコード
　BNFからコンパイラやインタプリタなどを製品レベルの品質で作ること


タスク的なプログラム処理にはもってこいだね。

【情処本勉強中】2分探索木

2分木については知っていたけど、どうやって探索するのかについては知らなかったのでメモ。

・2文探索木
[再編成処理]
2文探索木のノードが削除された場合の再編成処理
①削除されたノードから見て、左にある最大値を削除されたノードに入れる
②削除されたノードから見て、右にある最小値を削除されたノードに入れる

追加は左の子は右の子よりも大きな値を持つようにする。

[2分木探索]
①行きがけ順(先行順)深さ優先探索
逆ポーランドのなぞり方で先に探索する
②帰りがけ順(後行順)深さ優先探索
逆ポーランドのなぞり方で後に探索する
③通りがけ順(中間順)深さ優先探索
逆ポーランドのなぞり方でノードの中間を探索する
④幅優先探索
配列を先頭から順番に探索

2分木にヒープというものがある。
親要素が常に2つの子要素より大きくならない（またはその逆）構造になっている木。

そのヒープを用いたソート方法。
降順ヒープソートの手順
①親と子を比較。
②親よりも小さな子があれば交換。(ヒープの構成)
③最後のデータと根を交換。
④最後のデータをソート対象から外し、①に戻る。

入れ替えてはソート対象を外しヒープの構成を行う。これを繰り返す。

【情処本勉強中】待ち行列理論

基本モデルはM/M/1の待ち行列モデル。
特徴
①トランザクションの発生はポアソン分布・処理は指数分布。
②窓口数は1
③待ち行列の長さに制限なし

■用語と公式
平均到着率　　　　どの程度・頻度で到着するか　
平均到着時間　　　どの程度の間隔で到着するか　　1/平均到着率
平均サービス率　　単位時間何件処理できるか　
平均サービス時間　1件処理するのにかかる時間　　 1/平均サービス率
利用率　　　　　　窓口を占有している時間　　　　平均到着率/平均サービス率
平均待ち時間　　　待ち行列の待ち時間　　　　　　(利用率/(1-利用率))*平均サービス時間
平均応答時間　　　待って処理が終わるまでの時間　平均待ち時間+平均到着時間

う～ん、分かりにくい。すっきりこれで十分かと↓

■用語と公式
平均到着時間　　　どの程度の間隔で到着するか
平均サービス時間　1件処理するのにかかる時間
利用率　　　　　　窓口を占有している時間　　　　平均サービス時間/平均到着時間
平均待ち時間　　　待ち行列の待ち時間　　　　　　平均サービス時間*(利用率/非利用率)
平均応答時間　　　待って処理が終わるまでの時間　平均待ち時間+平均到着時間

【情処本勉強中】回帰直線と相関係数

目下基本情報の勉強中。
使ってる参考書はこちら。


とりあえず第1章基礎理論終了。
だいぶ前に勉強したところで忘れてるところが結構あって勉強になった。
知らないところもあったので今後調べていこう。

今回は回帰直線と相関係数について。
統計情報を扱うには非常に重要な項目。意外と回帰直線の傾きと相関係数について見落としポイントがあったのでまとめ。

--
回帰直線は、散布図に描かれる各データと、回帰直線との差である偏差を最小にする直線。
相関係数とは2変数に密接な関連があるか否かを示す係数。-1～1の範囲をとる。
1に近ければ正の相関。-1に近ければ負の相関。0に近ければ無相関。

相関係数の値が異なっていても同一の回帰直線が求められることがある。

回帰分析は単回帰分析と重回帰分析に分けられる。
単回帰分析は1変量。重回帰分析は2変量以上。

単回帰分析はいわば体系化のための分析法。
構造化のための分析法にクラスタ分析(データを類似のグループに分割する)がある。
--


ちなみに。
回帰直線はサンプルデータの1次関数近似として表現できる。
この1次関数は、サンプルデータと1次関数の偏差の総和を1次関数のパラメータで微分してあげると簡単に求めることができる。
多変量の場合に難しいかと言われればそうでもなくて、1次関数が単に多変量になっただけで1変数の場合と同様に近似関数のパラメータで偏微分してあげるといい(微分とはチョイ違う)。

さらには1次関数だけでなく複雑な関数でサンプルデータを近似することができる。
ただ、微分がちょっとだけ面倒になることがネックかも。

この辺の話を公式として覚える際には1変量、1次関数近似が限界だけど、微分の手法を覚えれば多変量、複雑関数でも何でも適用できる。