読者です 読者をやめる 読者になる 読者になる

どこぞのエンジニアなマネージャーのブログ。

Perlとかviとかcssとかjavascriptとか(rubyとか)git >> https://github.com/rozary hatenaIDがrozrayなのはtypo

vimのウィンドウ操作コマンドをマップしていて<silent>で困った。

自分のvimrcの中から付きのmap行をコピペして

"ウィンドウ最大化
nnoremap <silent>wm :<C-w>_

みたいなのを作ったんですよ。
けど、期待通り動かなくて。
とかやってもだめだし。
そもそも"_"こいつが?
とか
いろいろと余計なことをしてたんだけれど。

ウインドウ操作のmapをしている人のvimを眺めてたら。
みんなsilentがないではないか!

ということで

"ウィンドウ最大化
nnoremap wm <C-w>_ 

ってやったら動いたよ、やったねタエちゃん!!

Test::mysqldをmacに入れてみた。

結論

mac "ports"で入れたmysqlで、Test::mysqldは入れない方がよいかと思われます。
portsで入れていたとしても、以下より改めてmysqlを入れなおしたほうがよいと思われます。

MySQL :: Developer Zone

理由は、portsで入れた場合のmysqlのインストール先がTest::mysqldの具合のいい場所にないのです。
だので、パスの設定をしなければいけなくなってしまい面倒な為です。

パス通すからportsでいれたまんまのmysqlで行きたい!というのであればそれはそれで可能です。
ということで…。

以下やったこと。

パスを通す1(Test::mysqldとして)

  • mysql_install_db
  • mysqld

この2つがTest::mysqldで必要らしく内部で。

$ which mysql_install_db
$ which mysqld

をやってくれています。

しかし、パスが通ってないのでTest::mysqldはエラーを表示してとまります。
だので、なんとか見つけ出す!

portsで入れた場合は/opt/local/この配下辺りにあります。
/opt/local/lib/mysql5
というのがあったので、ここを見ていくと、
/opt/local/lib/mysql5/bin
の中に上記2つのファイルがあると思います。
ということで、bashrcに以下を記述。

export PATH=/opt/local/lib/mysql5/bin:$PATH

パスを通す2(mysqlとして)

mysql_install_dbが/opt/local/lib/mysql5/binにあることで、
--basedir='/opt/local/lib/mysql5として、mysqlを起動しようとします。

が、/opt/local/lib/mysql5/share/englishを探したけれどerrmsg.sysが見つかりませんというエラーをmysqlが表示してくれます。
そして、その他にも3つほどエラーが表示されて。
まとめると、以下の4つのファイルを求められます。

ということで以下4ファイルを探す。

  • errmsg.sys

/opt/local/share/mysql5/mysql/english/

  • fill_help_tables.sql

/opt/local/share/mysql5/mysql/fill_help_tables.sql

/opt/local/share/mysql5/mysql/mysql_system_tables.sql

/opt/local/share/mysql5/mysql/mysql_system_tables_data.sql

たぶん、それぞれこの辺りに在ります。

で、/opt/local/lib/mysql5/shareこの辺を探しましたっていうので、
そこからリンクを作っちゃう。

で、こんな感じにしました。

$ cd /opt/local/lib/mysql5/share/
$ ls -l
english -> /opt/local/share/mysql5/mysql/english/
fill_help_tables.sql -> /opt/local/share/mysql5/mysql/fill_help_tables.sql
mysql_system_tables.sql -> /opt/local/share/mysql5/mysql/mysql_system_tables.sql
mysql_system_tables_data.sql -> /opt/local/share/mysql5/mysql/mysql_system_tables_data.sql

あとはTest::mysqldを使いましょう。

パスを通すことしかしていないので、もっとスマートな方法があると思います!
ひとまず、適当にパスを通しました。

こんな話をしていたらmysql-buildこんなのが在るよ。
と教えてもらったので、今度試してみようと思いまっす。

自分スクラムonスクラム。

話すこと

対話しやすい環境づくりの方法として、
チーム構成を考えてみる。

自己紹介

お屠蘇気分も抜けずに、すっかりAdvent Calendarを忘れていました!!
大変申し訳ございません!
正月から反省していますi47_rozary(あいよんなな、ろざりー)です。

現在、某ゲーム会社にて働いております。
主に自社サービスです、開発と運用両方をおこなっています。

自分としては、ソフトウェア開発は10年ほど、
ここ数年はマネジメントをやっております。
直近ですと開発プロセスとかCI環境構築について、
いくつかのチームを跨いだ業務をおこなっております。

アジャイルに関しては、勉強とか実践とか通してここ3年くらい関わらさせて頂いております。

チームビルディングについて勝手におもってること。

1チームは、6、7人が適切、最大でも10人。
しかし、納期に寄ってはエンジニア、プランナー、デザイナー2名ずつとか厳しい。
そんなときは、チームの人数を増やし、そして各チームリーダーを立て、チームを分割させる。
そして、各リーダーとコミュニケーションを取ることでプロジェクトを進める。

メンバーチームの上にリーダーチームが在るという感じですね。
これをアジャイルでいうと、スクラムonスクラムと言ったりします。

ということで、今回はチーム構成についてのお話。

開発期間とメンバー

  • 開発期間は、3ヶ月。
  • メンバーは20人(最初から揃っているわけでなく順々に増員。)

自分の現場の課題

ここで課題なのですが、20人もいるのになんとリーダー経験者がいないんです!
(経験があっても1、2年と浅い…。)
けど、リーダー経験者をアサインするあてもなく…。
でも、そのまま20人も集まっていると会議がただの報告会だったり、朝会なんかただ言っているだけになったりと、まるで意味がありません…。
そういった場所は、互いのタスクを確認して連携をとりやすくする場所だと思うんです。

そして、確認がされなければ、全体像の共有もされなければ、個々のタスクもわからないという感じ…。
そうなれば、プロジェクト全体の進捗もどこまで終わっていて、何が残っているのかわからない。
納期が近づいた時に終わってないからといって、なし崩し的に納期が伸ばされるといったことになりかねません。

そんなんじゃよくありませんよね?

で、今やっていること

ということで、自分スクラムonスクラム。

それぞれのチームにリーダーを立てはするのですが、
リーダーをフォローしながら、メンバーに対しても自分がファシリテートをするようにしました。

そんな作業を通して、リーダーの立場にいた人は次第に、
何をどのようにすればよいのか把握して実践をしていってもらえればなと考えてやっております。

そして、いつしか自分スクラムonスクラムが、
目指すべきスクラムonスクラムになるのではないかと考えております。

まとめ

メンバーが対話をしあう環境づくりの方法は、多種多様かと思います。
その中の一つの方法として、適したサイズのチーム構成をすることもあるんじゃないかと考えています。

まぁ、この方法が合ってるかどうかはわかりませんが、
この方法がいいかもしれないあの方法がいいかもしれない、と考えて行動しつづけねば。
そう思うんであります。

次回のAdvent Calendarは、みやざわさまでございます。
よろしくおねがいしまっす!

DBIx::FixtureLoader(0.11)でload_fixtureにdataを渡す場合は。

メモがてら。

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);

これ。

だので、それにデータ形式を合わせるとなると。
一番上の方法ということになる。

と思う。

ORマッパーとDBD::Mockは、あまり相性が良くない??

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自体はシンプルに書けるところはよいのでそういう時に使いましょう。

たてらぶ〜DevLOVE現場甲子園 完結編〜に行ってきた。

リーンキーワード駆動漫才!!

新しすぎる!!
「リーン駆動 x 漫才」で検索を掛けたらノーヒットだったという!!
(今なら、リーンキーワード駆動漫才が引っかかるけどね!)

内容もさることながら方法が新しい!!
漫才を織りまぜてやるなんて!!
ファンタスティック!!
本当に、衝撃でした!

例えば、

ジャイアン トップページ作成
のび太 会社紹介ページ作成

でもまだ、「残タスクに、IRページ作成だったり、採用情報ページ作成だったりあってタスクが沢山だよー!!締め切り間に合わないよー」

って時には、「ホワイトボードマーカー!」

ジャイアン トップページ作成
のび太 会社紹介ページ作成
のび太 IRページ作成
のび太 採用情報ページ作成

「名前をいくつも増やせばいいんだよー!」

っていうね!衝撃ですよ!!

キーワード

  • 再見積もりもスケジュールの中に入れ込む。
  • パワポ。デザインのページ設定をA4にすると印刷するとき綺麗!
  • 問題解決能力も大事だけれど、問題発見能力も大事。

スクラム

みんなで一緒に進むのは、確かにそうだけれど。
ラグビーを今一度思い出して。
個々人がいけるところまで進んで誰かにパスをする。
みんなそれぞれで動いてゴールを目指す。

このお話LTだったんですけれど、地味に響いてくる。

スキルセットが違う人達が集まって、
それぞれの責任をこなすわけだからバラバラではあるんだよな。
ただゴールは一緒というだけで。

こう、書き出してみるとそらそうだよな。
と思うんだけれど。

ヒトリゴト

最悪10人超えたらスクラムonスクラムだなぁ。
ただ、それぞれのチームにはスクラムマスター的な動きが出来る人でないとやはり駄目だよなぁ。

振り返りをスクラムonスクラムにしたら。
朝会ももするべきだな。

DevLOVE現場甲子園2013に行ってきた その2

参加してから1ヶ月が丁度経った。
けど、果敢にまとめておくぜ!!

デイリーのスタンダップミーティングで前回のKPTを確認する。

KPTってやりっぱなしで放置されることがよくある。
毎日目に届くところに置くか、朝会で共有するかしないとあっというまに形骸化する。

プロトタイピングで全体観を伝える。

設計、作る。設計、作る。とを繰り返しているとどこかで破綻してやり直しの連続。
プロトタイピングをして全体観を見てもらってそこからフィードバックを得ながら進める。

ペアプロ

役割として、考える人と書く人。
クォリティを担保するためにも良い。

アジャイルを始めるのに壁が高い人へ

  • 小さく始めたら、現場も少し変えられる。
  • 「朝会はじめよう!」じゃなくて、「すいません、今日のタスク確認させてください。」にする。

UI/UXは、伝えるではなくて伝わるもの。

  • 個別のUXではなくて、全体のUXで見られるようにする。
  • ペーパープロトタイピングは、ディティールに拘らない。
  • UIScope(思考発話法でテストしてくれるサービス)

取ったメモは、残り2/3程度あるぜ!!