メモがてら。
data形式で入れる場合はこんな感じで入れる。
my $loader = DBIx::FixtureLoader->new(dbh=>$dbh); $load_fixture->( [ {id=>1,name=>"bioshock"}, {id=>2,name=>"amnesia"}, ], {table=>"game"}, );
中身のお話。
DBIx::FixtureLoaderは、insertするデータをSQL::Makerに渡している。
my ($sql, @binds) = $self->_sql_builder->insert_multi($table, $data, $opt ? $opt : ());
で、SQL::MakerのSYNOPSYSを確認するところ。
( $sql, @binds ) = $builder->insert_multi($table, \@rows);
これ。
だので、それにデータ形式を合わせるとなると。
一番上の方法ということになる。
と思う。
DBD::Mockは、名の通りDBのモック。
DBD::Mock - search.cpan.org
先ずは、DBD::Mockの説明。
my $dbh = DBI->connect("DBI::Mock:"); $dbh->{mock_add_resultset} = { sql => 'SELECT foo, bar FROM baz', results => [ [ 'foo', 'bar' ], [ 'this_one', 'that_one' ], [ 'this_two', 'that_two' ], ], } my $result = $dbh->selectall_arrayref("SELECT foo, bar FROM baz");
って感じで。
$resultには、上のresultsの
[ [ 'foo', 'bar' ], [ 'this_one', 'that_one' ], [ 'this_two', 'that_two' ], ]
が入っている感じ。
で、この時注意しないといけないのが、
mock_add_resultsetに入れてあるsqlと全く同じものじゃないとresultが返ってこないんです。
大文字小文字も、同じにするくらいにね。
※ mock_add_resultsetに、参照配列を渡すこともできます。
この時は、sqlのチェックを無視して、値を返してくれます。
ここで、問題なんです。
ORマッパーを使うと、まぁクエリが自動で生成されます。
そんなもんで、大文字小文字も気にするくらい合わせないといけないのでちょっと手間だなぁという。
ちなみに、自分はTengとDBD::Mockで試していたのですが、
Tengでは、FROMやWHERE、LIMITで改行が入るので、改行もDBD::Mockのsql内に含めないと動かなかったです。
ということで、DBD::Mock自体はシンプルに書けるところはよいのでそういう時に使いましょう。
新しすぎる!!
｢リーン駆動 x 漫才｣で検索を掛けたらノーヒットだったという!!
(今なら、リーンキーワード駆動漫才が引っかかるけどね!)
内容もさることながら方法が新しい!!
漫才を織りまぜてやるなんて!!
ファンタスティック!!
本当に、衝撃でした!
例えば、
| ジャイアン | トップページ作成 |
| のび太 | 会社紹介ページ作成 |
でもまだ、｢残タスクに、IRページ作成だったり、採用情報ページ作成だったりあってタスクが沢山だよー!!締め切り間に合わないよー｣
って時には、｢ホワイトボードマーカー!｣
| ジャイアン | トップページ作成 |
| のび太 | 会社紹介ページ作成 |
| のび太 | IRページ作成 |
| のび太 | 採用情報ページ作成 |
｢名前をいくつも増やせばいいんだよー!｣
っていうね!衝撃ですよ!!
みんなで一緒に進むのは、確かにそうだけれど。
ラグビーを今一度思い出して。
個々人がいけるところまで進んで誰かにパスをする。
みんなそれぞれで動いてゴールを目指す。
このお話LTだったんですけれど、地味に響いてくる。
スキルセットが違う人達が集まって、
それぞれの責任をこなすわけだからバラバラではあるんだよな。
ただゴールは一緒というだけで。
こう、書き出してみるとそらそうだよな。
と思うんだけれど。
参加してから1ヶ月が丁度経った。
けど、果敢にまとめておくぜ!!
KPTってやりっぱなしで放置されることがよくある。
毎日目に届くところに置くか、朝会で共有するかしないとあっというまに形骸化する。
設計、作る。設計、作る。とを繰り返しているとどこかで破綻してやり直しの連続。
プロトタイピングをして全体観を見てもらってそこからフィードバックを得ながら進める。
役割として、考える人と書く人。
クォリティを担保するためにも良い。
取ったメモは、残り2/3程度あるぜ!!
仕様やドキュメントなしで開発することは、アジャイルじゃないんやー。
(そもそもそんなのは"なんちゃって"とか言われる類のものだろうけれど…。)
と、それは置いておいて。
いろいろ試してきたけれど、やっと今日しっくりいった。
自走していると思っていたチームに物足りなさを感じていたんだ。
それは、こういうことだったのだ。
アジャイルの手法を取り入れていって上手くいっていたと思うんだ。
けれど、ある時期にカイゼンが進まなくなったような感じがするようになったんだ。
仕様があってそれにスケジュール通りに応える。
だけれど、もっと出来るんじゃないかと思ったんだが"もっと"という方向にはいかなかった。
きっと、手法を取り入れて(なんとなく)上手くいっていて、それに満足していたんだろう。
本当に必要なのは、ミッション(for user)に対するモチベーションだったんだろうな。
ミッション達成の為に手法が必要で、手法を取り入れることでカイゼン出来ると思っていた。
そして、カイゼンされたことが現実になったら、そこで満足してしまったんだろうな。
(ある意味、そのチームの完成だったのかもしれない。)
けれど、ミッションの本当の目的を忘れてしまっていたんだろう…。
たぶんここでインセプションデッキを確認出来ていれば、また違っていたんだろうな。
悩んだりしたら、やってもいい。
忘れないように定期的にやってもいいだろう。
今まで何故か、途中でインセプションデッキをやるのに躊躇っている気持ちがあったんだ。
途中で方向性が変わってしまうんじゃないかって。
でも、アジャイルってその変化を許容しながら調整して進むことじゃないか!!
だから、インセプションデッキはいつやってもいいんだ!
tips メモ
アジャイルサムライ再入門という感じで、見落としがちだったところを再確認できた。
"手法"に拘らないように考えていたけれども、言葉に出さないようにしていたというだけで、結局"どうやろうか"というところを考え過ぎていたのかなと。
その為に、チームメンバーの"モチベーション"について意識が疎かになっていたと思う。
だので、調整していこうっと。
#!/usr/bin/perl #myapp.pl use Mojolicious::Commands; Mojolicious::Commands->start_app("MyApp");
みたいなスクリプトを書いて。
$ perl ./myapp.pl routes
とかするとSTDOUTに、tree上に表示される。
こっちでもよかった。
#!/usr/bin/perl use Mojolicious::Commands; Mojolicious::Commands->start_app("MyApp","routes");
小並感ですけれどね。
大変よかったです。
ずーっと幸せな感じがでていてとてもよかったです。
幸せすぎて、自転車のシーンとか橋爪さんと吉行さんとが別々に行動するシーンとかになると、
なんか事故にあって嫌な感じになるのかと緊張したりしましたが、
終始、家族愛に包まれていてとても良かったんですよぉ。
みんないい人ばかりでなんだか、穿ってみてしまう感じもあるんですけれど、とはいっても幸せな感じがとても羨ましくてイヤじゃないんですな。
そして、いい俳優さんばかりなのですが、なかでも蒼井優さんが素晴らしいんですね!!
素晴らしいというか好きなだけなんですけれどね!
最後にそっと手で顔を覆うところなんかもうね!!
いやあー久しぶりに堪能した!
