ゆーすけべー日記
ユーザーからのPOST等された入力値の妥当性をチェックする Validation をどこでやるか問題が個人的にありまして〜、DBを使わないケースならばいわゆるFomrValidator::*を使ってControllerでやればいいのですが、Modelを経由するようなアプリだとControllerだけじゃ不安よねぇ〜、Modelだけ使う時もあるし、Model単体のテストで再現出来ないよね〜なんて思ってます。で、実際の実装をControllerではFormValidator::Lite、Modelの一部にData::Validatorを使っているのですが、なんかコレも効率悪い感じしてたんで、ちょいと実験的に理想の一つを実装してみました。 こんな条件です。 エラーメッセージを簡単に設定したいのでValidationモジュールにはFormValidator::Liteを使う 色々錯誤していたらOR
ゆーすけべー日記
ここ最近の僕の開発で指標になっているのは「システムとしてのクオリティを上げるか」であり、それって当然のごとく行われているかもしれなくて、いわゆる Quality Assurance = QA なんて言葉があったり、某社では Test Engineer の方がいたりするわけです。ただ、あまりにも僕としては「ずさんな」ところが多々あると考えています。「よしAを変更した → デプロイ → Bがエラー出てる」なんてことがないように「機能が望むように動作しているか」をテストコードで担保しようと努めている次第です。例えば、先日サービス内で使用している Flickr API の一部メソッドが正常に機能しない（ どんなに一般的な語彙で探しても検索結果が空で返ってくる ）なんてことがありましたが、テストコードのおかげで問題の切り分け、つまり、これは本当に Web API が壊れているのだ！ということがテスト
ゆーすけべー日記
__papix__ 君が主催をして開催している Perl入学式 というイベントがあります。Unix/Linux/OSXの環境構築から始まり最終的にはWebアプリケーションをつくるハンズオン形式の勉強会を今年は年6回に分けて開催しているようです。かなり丁寧にPerlを教えているという印象があって、それがどんな雰囲気か以前から気になっていたのですが、昨日「Perl入学式 in 東京 #2」にサポーターとして途中から参加させてもらいました。 簡単に感想を述べると「これはすごくいい」。肝は最適な練習問題が所々出され、するとみんな黙々とコーディングし始めるんだけど、それが終わると、参加者同士でコードを見せ合って「これで合ってるかな？」「私はこんな風に書いたよ」と言うようなコミュニケーションが生まれてたりしているのです。正直その様子を見て感嘆しましたよ。 ＊追記「Perl入学式の補講があるらしいよ！」
Devel::KYTProfのログをファイルに書き出して、I/Oのボトルネックを知る - ゆーすけべー日記
Webアプリケーションが遅いとか感じる時って、僕の場合、I/Oがボトルネックなケースが多いのです。つまり、MySQLへクエリーを投げて返却を待つとか、memcachedにget/set等のメソッドを発行した時の待ち時間が長くかかってたり... とかです。そうすると計測して原因を突き止めたくなります。PerlのプロファイラはDevel::NYTProfとか色々ありますが、こうしたI/Oに関しての計測は「Devel::KYTProf」が便利です。適当な場所にて use Devel::KYTProf; するだけで標準エラー出力に「空気読んで」ウマいこと色付きで、I/O周りのかかった時間とどこの箇所か？を表示してくれます。 ただ、この「標準エラー出力に表示」ってのは開発時にターミナルで確認する分には便利なのですが、例えば本番環境などで一時的にパフォーマンスを計測するためにはちょっと不便なことがあり
ゆーすけべー日記
Perlの祭典とも言うべきイベントYet Another Perl Conference = YAPC 。去年はYAPC::Asiaでベストスピーカー賞をいただきまして、その副賞が「YAPC::NA または YAPC::Europe へ派遣」というモノでした。YAPC::Europeは今年キエフでの開催でちょいと行くのが大変。なので、アメリカはオースティンで開催されるYAPC::NAへ行かせてもらえることになりました。ぶっちゃけ究極ネガティブに捉えると「俺英語出来ないし、オースティン遠いし、これなんて罰ゲーム？」みたいな感じですが、勇気を振り絞って（というか、いただいたからには行く流れになったのですがw）、先日の YAPC::NA 2013へ参加してみたら、ものすごい楽しかった！！ せっかくUSへ行くのだからと、経由するサンフランシスコにも帰りに2泊してWeb関係の有名企業を見学したりしつ
地域コミュニティが熱い！？Kansai.pmに行ってきました #kansaipm - ゆーすけべー日記
先日の土曜日2月23日、大阪駅のすぐ近くYahoo!さんの会議室にてKansai.pm第15回ミーティングが開催されました。僕はJPA＝Japan Perl Associationさんの支援を受けてゲストスピーカーとして参加させていただいた次第です。大阪に行くのは高校の修学旅行で立ち寄った（確か...）以来。「大阪駅-梅田駅の地下とかがダンジョンで迷いやすい＞＜」なんて情報を事前に仕入れていたのでビクビクしつつも行ってきました。その報告をしつつなんとなく地域コミュニティとしてのKansai.pmについての考察、感じた事をまとめます。 僕の発表 どんなトークをしようかなーと悩んでいたのですが、後ほど盛大にフューチャーするpapix君から Kansai.pm はスキル的に幅が広いのでなるべく全員に刺さるような発表を！ みたいなことを言われ、テーマを決めました。題目はズバリ 「Webサービスのつ
CSS Frameworkを持つ - ゆーすけべー日記
例えば、Webサービスのフロントエンドのコードを書き始める時にまず何をするでしょうか？ デザインスケッチや画像を元にHTMLとCSSを記述していくことになると思います。 少なくとも僕はそうですね。 理論的にはHTMLだけでもWebサービスを作ることはもちろんできますが、 見た目を少しでも調整したいとなるとCSSが必要になります。 例えばCSSを使わないHTMLの場合、いくら単純なレイアウトだとしても、 デフォルトのリンクの色を変えたかったり、フォントを変更したかったり、 要素ごとの余白をどうにかしかったりと最低限の要望が出てきます。 こうした最低限のCSSに対するニーズは共通化して自分なりのCSS Frameworkとして持っておくとよいと思います。 近頃、一からCSSを記述しなくなったのもこうした考え方のおかげです。 今Web上で配布されて利用可能なCSS Framworkが非常に増えて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
