ブログトップ 記事一覧 ログイン 無料ブログ開設

刺身☆ブーメランのはてなダイアリー

2009/04/22(Wed)

JPA seminar #1

Tue Apr 21 18:08:43 2009

at Akihabara UDX conference room


Better Perl Practices

テストしましょう

Test::Class が良いよ!でもコードの書き方を少し変える必要があるよ!(考え方的な部分で)

パッケージベースのテストが書ける、ベースクラスを利用してテストコードを再利用できる、柔軟

ユニットテストとワークフローテストは別のもの

ワークフローテストとは「メール送信する」とか「会員登録する」とかの、ユーザーが実際に行う操作をシミュレートするもの

ワークフローテストが書きづらいということは、ユーザーが操作しづらいアプリ

テストが書きづらいということは、プログラムの設計、 API が悪いので API を書き直していけば良いコードになる

良いコードはタイプ数が少し増える

タイプ数が増えて一見冗長に見えることを恐れてはいけない

つまり良いコードとは短くて難しいコードのことではなく、長くても読みやすいコードのこと

Moose について

(ここはだいたいいつもの Moose イイヨ話)

----

かろうじて呪文ではなく英語であると聞き取れた ... 30%

かろうじて知ってる英単語を聞き取れた ... 20%

かろうじて文章の意味がわかった ... 10% 未満

自分がいかに英語を聞き取れないかがよくわかった

資料の完成度がとても高い。だいたい話者のスピーチと同内容であろう日本語の説明文がスライドの下についている形式の資料なので

あとで読み返せば英語のスピーチを理解できていなくても十分に復習できる。なので安心してスピーチの聞き取りにチャレンジできた。

英語を聞き取れる人ならより集中してスピーチを聞けたのではないか。

もし日本語対訳がなかったら半分も理解できず、とてももったいなかったはず

つまり英語を聞き取れないということはすごく損だと改めて気づいた。

「テストはゼロ、 Moose も使えそうにない、何年も運用してきた歴史のある(必ずしもレガシーではないがモダンでは決してない)コード、プロジェクトがあった場合、

それのベースを維持しつつテストを増やしていきたい、しかし過去の資産があまりに膨大すぎてどこから手をつけていいのかわからず結局何もできていない(テストを書けない増やせない)、

そういう場合は企業の場合多々あると思うがどのようにして改善していけば良いのか?

という質問をしようかどうか迷ったが、やめた。

「出来るところから少しずつやるしかない」し、「場合による」から、こうすればよいという明確なアイデアがあるわけないので、聞いてもなあ...と思ったので。

個人的な課題として、 DB に値を入れる/DB から値を取り出す部分のテストをどう書けば良いのか未だに乗り越えられていないので、

そこをどうにか工夫して良いやり方を見つけられれば俺はもっとテストを書けるはずだ。

MySQL のテストサーバと接続できないとテストできないとか、テストを走らせると開発環境のデータベースに変更が加わってしまうので破壊的だとか、

そういうのをうまくラッピングしたい。

Moose をはじめとするモダン Perl の潮流について

プログラマが個人的にアリだと思っても、仕事で長年使ってきたコードを Moose ベースに書き換えるのはとても大変なはず

ふつうのサラリーマンプログラマにとって仕事のコードに触れる時間はプライベートで好きにコーディングするよりずっと多い

「どうせ職場のコードが use Moose になることはないし、だったら別に覚えなくてもいいや...」となってしまう...

個人で Moose を積極的に学ぶ意志のあるような人は誰が手引きしなくても勝手に会得していく

そうでもない人たちをいかに改宗させるか、というあたりで何かしてほしい

Catalyst 改

プラグインはダメー

Chanied がとても良いらしい(そして github にデモが!)

local::lib がいいよとか(デモあり)

Chanied のサンプルアプリのデモ

サンプルアプリのコードが高度すぎる。。

もっと極々単純なものがないと、正直いって理解できない!

DBIC の $rs をとってくるところの $method を config で指定して云々とか。。

Chanied の root にあたるメソッドでは $rs をとるだけで、具体的な操作は次の Chain にあたるメソッドに任せる、とか。。

高度に抽象化しすぎていて、 Catalyst のイマドキ?フツウ?な使い方を見慣れてないとサッパリわかんない、とまではいかなくともよくわからない。

local::lib を Catalyst app ごとに専用のを用意してそれごと撒く、みたいなのはアリかもと思った

でも XS とかあると微妙かー。実際にはデプロイは makefile だけにして、本番機でそれぞれ make して local::lib の中身を新しくする、みたいなのがいいのかもね。

どっちにしろ古いモジュールのバージョン固定必須とか困った環境じゃ使えないんですけどね。

Test::WWW::Mechanize::Catalyst を使うと app のテストがしやすい

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

トラックバック - http://d.hatena.ne.jp/a666666/20090422/1240330848
Connection: close