FindBinモジュールの使い方

FindBinモジュールはスクリプトの実行ファイルやディレクトリを変数に格納するモジュール。
以下のコマンドを実行してみるとわかりやすいかと。

vim /hoge/test.pl
で以下のファイルを作成。
use FindBin;
print "Bin: $FindBin::Bin\n";
print "Script: $FindBin::Script\n";

コマンドを実行。
perl /hoge/test.pl

実行結果：
Bin: /hoge
Script: test.pl

cpanサイトはこれ。
http://search.cpan.org/~rjbs/perl-5.18.2/lib/FindBin.pm

Path::Classモジュールの使い方

Path::Classモジュールの使い方がよくわからなかったので調べていたら、CPANのSYNOPSISを見るのが一番わかりやすいという結論になった。
このモジュールはWindowsでもLinuxでもディレクトリやファイルのパス名をよしなに生成してくれるモジュールのようだ。
以下のワンライナーを実行してみればわかりやすいかと。

perl -MPath::Class -e '
my $dir  = dir('foo', 'bar');
my $file = file('bob', 'file.txt');
print "dir: $dir\n";
print "file: $file\n";
'
出力結果：
dir: foo/bar
file: bob/txt

これがwindows環境で実行すれば
dir: foo\bar
file: bob\txt

となるというのがこのモジュールを使うメリット。

cpanサイトはこれ。
http://search.cpan.org/~kwilliams/Path-Class-0.33/README.pod

Setting locale failedの対処法

サーバーでPerlのコマンドを打つたびにこのような表示が出て困っている。

$perl -e 'print "hoge"'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "*******"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

どうやら以下の手順で直すことができるようだ。

$vim ~/.bashrc
でファイルに下記を記載する。
export PERL_BADLANG=0

$source ~/.bashrc

これで直った。

スクリプトの終了コード11のエラー

最初ググり方がわからなくて当惑したのでメモ。
このエラーはSignal 11、segmentation faultとして知られているエラー。
つまり割り当てられていないメモリを参照しようとしたときに起きるもの。下記参照。
http://linuxjf.sourceforge.jp/JFdocs/GCC-SIG11-FAQ/sig11faq.html
http://sonic64.com/2005-04-19.html
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1288299487

テーブルの正規化のメモ

この記事が第5正規形まで簡単にまとまっていてわかりやすかった。
素早く正規形を見抜く実践テクニック

下記メモ。ビジネスロジックを入れなければ第3正規形までで正規化は完了するらしい。


正規化
・1事実1箇所のポリシー
非正規形（※正規形ではないが、第1正規化の対象を非正規形という）
第1正規形（1NF）
第2正規形（2NF）：部分関数従属性の排除
第3正規形（3NF）
ボイスコッド正規形（BCNF）
第4正規形（4NF）
第5正規形（5NF／PJNF）

重複更新(特定テーブルのデータ更新時に複数箇所を更新する必要が生じる)

関数従属性：商品IDが決まれば商品名は一意に決まる
注文明細テーブルが下記の形式だと商品名が変わったら同じ商品IDのデータをすべて更新しなければならなくなる
注文番号、商品ID、商品名、フォーマット、単価、数量

部分関数従属性：複合キーのいずれかに対する関数従属性がある
注文番号、商品IDの複合キーになっているが、商品名とか商品IDに紐付いているよね
注文番号、商品ID、商品名、フォーマット、単価、数量

推移関数従属性：主キー以外のフィールドに関数従属性がある
名前、住所、電話番号って顧客IDに紐付いているよね
注文番号、注文年月日、顧客ID、名前、住所、電話番号、支払い方法

ボイスコッド正規形：非キーからキーへの関数従属性を取り除く
学生、科目が主キーのテーブル。だが講師が決まれば科目も決まるという非キーからキーへの関数従属性がある
学生、科目、講師
↓
講師、科目
学生、講師

ただし、この分解をすると一人の学生が一つの科目を複数の講師から履修できないという制約が失われてしまう。つまり後者のテーブル構造にはそういった登録が可能になってしまう。

ちなみに実際使うとなると上記の分け方は気持ち悪いから、授業フィールドを作ってこうするだろうなとは思う。
学生、科目、講師
↓
学生、授業
授業、科目、講師


第4正規形、第5正規形はキーだけで構成される対照表が対象
多値従属性：チームが決まればメンバーが決まる
チーム名、メンバー名

チーム名、メンバー名、道具名
↓
チーム名、メンバー名
チーム名、道具名
この正規化をしないとチームにまつわる道具が変わったらテーブルの全ての値を更新するハメになる

下記だとチーム名、会場、ダンスの全てが揃わないとデータ登録ができない
チーム名、会場、ダンス
↓
チーム名、会場
チーム名、ダンス
会場、ダンス

テーブル構造からビジネス構造を排除すると第3正規化までで正規化が完了する

専門の人が書いたスライドもあるけど、ちょっと用語がわかりにくい。
http://www.slideshare.net/nippondanji/db-engineerstudyanim?ref=http://nippondanji.blogspot.jp/2013/11/db.html

httpd.confの設定に関して

この記事がわかりやすいのでメモ。
httpd.confについて調べたのでまとめたよ

個人的に必要な部分をメモ。
httpd.confはCenｔOS系だと/etc/httpd/conf/httpd.confにある
ServerRoot：Apacheがあるパス

Github と Pull Request とコードレビューって当たり前じゃなかったのか...

メモ。
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー

てっきり当たり前の開発手法だと思ってた。
この手法を導入するためにやることは2つ。リポジトリ管理をGithubにすることと
Jenkinsを導入し、テスト用サーバーを用意してテストを回し続けるようにすることだけだ。

開発者としてやることは
・開発をする
・テストを書く
・Pull Requestを飛ばして誰かにマージしてもらう
の3つだ。

Jenkins導入とテストを書くことのメリットだが、これをやることで糞コードが減る。
Jenkinsは特定ブランチにコードがコミットされるたびにテストが実行されるので、
テストが通らないおかしなコードがコミットされるとエラーを吐いて知らせてくれる役割をする。
テストを書くことでなぜ糞コードが減るかというと、テストが書きやすいようにコードを
分割するようになるので、メイン関数にすべてのコードをベタ書きするような、
あの誰も触れないコードを書くような事象を構造的に減らせるというわけだ。

重要なのはそこなので、カバレッジは別に100%じゃなくても構わないと思う。
最悪分岐の多い関数だけ書いておいてもいいわけだし。
バッチとかはメインロジックはそこに書かずにそこで呼び出すモジュールの方に
書いておけばテストもしやすい。

Pull Requestを飛ばしてだれかにマージしてもらうのは、コードレビューを構造的に
組み込むという意味で優れていると思う。これは本番用のブランチにマージする際に
自分でマージするのではなく、他の人にマージしてもらうということだ。
ここでレビューが入ることで、明らかにおかしなコードは入りにくくなるわけだ。

ちなみに設計などはwikiにドキュメントを残して開発チームでレビューを行う仕組み。
ここも属人化を避けるために複数人でミーティングを行っている。