そもそもORM使うときはjoinを避けるべきなのか？
パフォーマンスを考えてjoinしないのが常識？
userの持つbookmarkを全て表示する、とかの場合は、UserとBookmarkそれぞれにselectかける？
今まで自分がそういうことするときは、UserとBookmarkをjoinさせてた。
当然環境によって変わるんだろうけど、一般常識なのかなと今更疑問に思った。
DBIx::MoCoと格闘中
DBIx::MoCo触り中。基本的な使い方は分かったが、joinが色々分からない。
いつも通りdbはrailsのマイグレーションで作成。アプリはcatalystで。
ただ今回、行き詰まったのでアプリ使う意味が（まだ）無い。
http://github.com/hirafoo/moco_training/tree/master
DB
親と子と孫。
Oya has_many Ko
Ko has_many Mago
これ以上の説明は不要だよね。
加えて、KoとOyaをjoinするためのクラス、KoOyaを作成。
joinするには、DBIx::MoCo::Joinを継承したクラスを作るようなので。KoOyaというテーブルが存在するわけではない。
あと他の方法でもjoin可。
package Moco::Model::KoOya; use base qw/DBIx::MoCo::Join Moco::Model::Ko Moco::Model::Oya/; use Moco::Utils; use Moco::Model::DataBase; __PACKAGE__->db_object('Moco::Model::DataBase'); #__PACKAGE__->table('ko INNER JOIN oya ON ko.oya_id = oya.oya_p'); __PACKAGE__->table('ko INNER JOIN oya ON ko.oya_id = oya.id'); __PACKAGE__->has_a( oya => 'Moco::Model::Oya', { key => 'id' } #{ key => 'oya_p' } );
join
DBIx::Classのように、joinしたら双方のテーブルの値を持つ新たなオブジェクトを作るのかと思ったら、ちょっと違った。
双方のテーブルの値を持とうとして、同じ名前のカラムが有ったら、上書きする。
例。
双方のテーブルが同じ名前のカラムを持つ場合
- 主キー：id
- 所持カラム：name
my $koya = Moco::Model::KoOya->search(where => "ko.id = 2")->first; p $koya; p $koya->oya;
$VAR1 = bless( { 'oya_id' => '2', 'created_at' => '2009-07-07 21:39:51', 'updated_at' => '2009-07-07 21:39:51', 'changed_cols' => {}, 'name' => 'oya2', 'id' => '2' }, 'Moco::Model::KoOya' ); $VAR1 = bless( { 'created_at' => '2009-07-07 21:39:51', 'updated_at' => '2009-07-07 21:39:51', 'changed_cols' => {}, 'name' => 'oya2', 'object_id' => 'Moco::Model::Oya-id-2', 'id' => '2' }, 'Moco::Model::Oya' );
双方のテーブルが同じ名前のカラムを持たない場合
- 主キー：${TABLE}_p
- 所持カラム：${TABLE}_name
my $koya = Moco::Model::KoOya->search(where => "ko.ko_p = 2")->first; p $koya; p $koya->oya;
$VAR1 = bless( { 'oya_id' => '2', 'created_at' => '2009-07-07 21:56:41', 'ko_p' => '2', 'ko_name' => 'ko2', 'updated_at' => '2009-07-07 21:56:41', 'oya_name' => 'oya2', 'changed_cols' => {}, 'oya_p' => '2' }, 'Moco::Model::KoOya' ); $VAR1 = bless( { 'created_at' => '2009-07-07 21:56:41', 'oya_name' => 'oya2', 'updated_at' => '2009-07-07 21:56:41', 'changed_cols' => {}, 'object_id' => 'Moco::Model::Oya-oya_p-2', 'oya_p' => '2' }, 'Moco::Model::Oya' );
前者ではidとnameのカラムが上書きされている。相当困る。
どう考えても自分が間違ってると思うんだけど、回避策分からず。
has_many
DBICのように $parent->child->id とか出来るはずなんだけど。
kosというメソッドで、Oyaから複数のKoを得られるようにしてみよう。
package Moco::Model::Oya; use base qw/Moco::Model::Moco/; use Moco::Utils; __PACKAGE__->table('oya'); __PACKAGE__->has_many( kos => 'Moco::Model::Ko', { key => 'id' } #{ key => 'oya_p' } );
my $oya = Moco::Model::Oya->retrieve_all; p $oya; my @kos = $oya->kos; p \@kos;
$VAR1 = bless( [ bless( { 'created_at' => '2009-07-07 22:03:20', 'updated_at' => '2009-07-07 22:03:20', 'changed_cols' => {}, 'name' => 'oya1', 'object_id' => 'Moco::Model::Oya-id-1', 'id' => '1' }, 'Moco::Model::Oya' ), bless( { 'created_at' => '2009-07-07 22:03:20', 'updated_at' => '2009-07-07 22:03:20', 'changed_cols' => {}, 'name' => 'oya2', 'object_id' => 'Moco::Model::Oya-id-2', 'id' => '2' }, 'Moco::Model::Oya' ) ], 'DBIx::MoCo::List' ); $VAR1 = [ '' ];
取れない…
最も力を入れてアピールしたい事
どうか誰か俺の間違いを正してもらえませんか。助けてヘルプ。
class::dbiの練習
何か唐突にclass::dbi使ってみた。crudとリレーションしかやってないけど。
リレーションも親<->子だけだけど。多対多は実にめどかったので略。
catalystで作ってたけどsledgeに変更。
http://github.com/hirafoo/class-dbi-crud/tree/master
ブログを書く理由
なんでお金になることをタダで書くの？ - ぼくはまちちゃん！
金になることは書けないけど俺がブログを書く理由。
単純に楽しいから、自分のためになるから。
ブログを書けば誰かの目に止まったり、俺を知ってもらえたり、ありがたいことに間違いを指摘してもらえたりする。書かない場合に比べて、面白い何かが起こるし、勉強になる。
学んだ事をブログにするには、最初から筋道立てて書かなければいけない。これは実にめんどいけど、復習にもなる。
つか何でも金の事考えて行動するってのが何だかなーと。確かに金稼ぐのは大事だけどさーそれゆーたらlinuxをはじめとしたossとかvectorの素敵ソフトとか色んなwebアプリとか無くなるやんけと。
俺は金より面白さ優先で生きてるのでビジネスの世界には合わんかな。
ご飯ごはーん
最近よく柔道家やインフラの人などと積極的にご飯に行ってる。何でかって、転職するからってのもあるけど、まあえーとその、能力の高い人と話すってのは貴重でありがたくて面白くて勉強になると今更ながら分かったからだと。打算くさいけど打算じゃないよ！超楽しいよ！
分かる前とは話す内容が変わった。もちろん以前から面白い話を聞いていたけど、なんというか、自分が疑問や質問をする事が多くなった。以前は、飯の時に真面目な話なんて、って（思っていたわけではないが）感じというか…表現が難しい。まいいや。
だがしかし平等にワリカンさせてもらえないのが。一方的に恩が溜まるばかりですがな。普段お世話になってる分、自分が食った分くらいは出させていただきたく…。
ところで今日の店はなんと水にも金取られましたよ。お冷1杯30円。恐るべし東京。
この方々、ITな能力だけじゃなく、今まで社会人やってきての事、今の立場になるまでの事、正に今やってる事などなど、経験も豊富なのでどっからでも学ぶ事が沢山ある。話してても、指摘されて気付く事や勘違いしてた事、反省する事に教えられる事が毎回山の如し。監督役は必要だし、コードを書くだけではいけない、とか。
プログラムはもちろん、IT全般や自分の視野の狭さや無知といった弱点・欠点、業界のことやエンジニアとして生きるのに必要な考えや姿勢にスキルなどなど、何から何まで教わりっぱなしでした。
人と接するって大事で素晴らしいですね。
にしても。もっと早くこういうことに気付くべきだった。ただ営業から「こんなの欲しい」って言われて、それを作るだけでいいと思ってた。
そんなのいくらでも代わりが居る。今日言われた通り、エンドユーザのことを考えるなり、自分でビジネスモデルを考えて意見出すなりすればよかった。この人たちから教わらなかったら、今もそんな考えだったと思うと情けない。
2年と少し、お世話になりました。ありがとうございました。
恩返しを期待せずにお待ち下さい。
ショートカットキーを覚えよう
今まで押しづらいキーを押しづらいなーと思いつつ打ってきたのは、する必要の無い苦労だった。
ちゃんとマニュアルとかリファレンスとか読まないと、こういう悲しい経験をする羽目に。
素敵なキー達。
I A D C J S cc
ていうのを学んだ。
転職ー
知人にはあらかた伝え終わったので書いとこう。転職します。
先月末から有給消化中。結果、週休五日。気分はニート。俺にはニートは無理だと思い知った。や、なる気は無いけど。
休み中はperlにmixiアプリにjavascriptにsledgeにテストにrubyにsinatraにrailsにcssに、その時々でやりたい事をやりたいようにやってた。節操無し。
とりあえずjsとcssは挫折。mixiアプリはジャンケンもどきが放置中です。ごめんなさい元上司の方。
あとは積読を減らして増やしてを無限ループとか買い物とかドラムとか。電車に乗らなくなってから、本を読む時間がほぼ無くなったので積みまくってた。
せっかく休みが出来ても、当然ながら知人とは週末しか休みが合わないので、皆で馬鹿やれるのは週末だけだったけな。
入社から2年と少しか。入社時に居た、尊敬する人達は次々居なくなってった。転職する人、起業する人、独立する人などなど。もうインフラの人しか残ってない。当然神も居ない。
学生時代とは全然違う勢いで人が居なくなるのが慣れなかったな。会おうと思えば会えるけど、違うクラスになるのとは全然違うしなー。
ここ数ヶ月のこととか。
入社時からずっと開発メインな部署に居たのだけど、その部署が消滅。自動的に異動。で、その異動先が。
特に意味は無いけどブックマークいくつか置いておきますね
http://b.hatena.ne.jp/foosin/20090521#bookmark-13434425
http://b.hatena.ne.jp/foosin/20090527#bookmark-4055
http://b.hatena.ne.jp/foosin/20090616#bookmark-13187962
http://b.hatena.ne.jp/foosin/20090618#bookmark-6383358
動機など。
開発がしたいのと、向上心のある人、能力の高い人、凄い人と仕事したいのが主か。上を見てみたいとか、挑戦したいとか、そんなのも。
外の世界を見ようとしたことがろくに無かったのだけど、セミナーなどで外の世界を見ると、自分が如何に小さいかよく分かった。
や、知ってたはずなのに分かってなかった事を再認識したというか。もっと早くからセミナー出ておけばよかった。
ネットで見るだけと、実際に目にするのとでは全然違った。凄い人を目の当たりにして、感じるものが有った。
IT業界はいいなあ。雲の上の人とでも接点が有る。他の業界だったら、「あの人がどんなサイトを見ているか」とか「どんな仕事をするか（この業界風に言えば、どんなコードを書くのか、とか）」とか分からんだろうし。
あ、刺激を受けた勉強会は某バイナリアンの集いです。
そしてまたブックマーク置いておきますね
http://b.hatena.ne.jp/foosin/20090419#bookmark-11661555
さて。
転職先は非常にレベルが高い。学ぶ事は沢山ある。自分で挑戦したんだから、やることやらんと。
