2015-02-20

MySQLのint(3)とかint(10)とかint(50)とか

今日ふと見たschemaで、

letter varchar(16) DEFAULT NULL,

みたいのがあった時に、違和感があった。

この(16)っていう桁数って意味あるんだっけ・・？
なんか使われる領域は結局同じだったような・・？

結論から言うと、これは勘違いでした。
この違和感はint型の時のやつでした。

以下、実験コード。

gist0a701d3a4ba4c6c10331

create database test_lengthしてから
mysql -u root test_length < length_test.sql で食わせてください。

結果は

mysql> select * from varchar_length;
+----+------------------+-------------------+
| id | letter016 　　　　| letter256　　　　　|
+----+------------------+-------------------+
| 1 | 1234567890123456 | 1234567890123456 　|
| 2 | 1234567890123456 | 12345678901234567 |
+----+------------------+-------------------+
2 rows in set (0.00 sec)

こっちは、ある意味想定通り。
16桁のところには、17文字目以降は入らない。
一方int型の

mysql> select * from int_length \G;
1. row
id: 1
number03: 100
number10: 100
number50: 100
number03_fill: 100
number10_fill: 0000000100
number50_fill: 00000000000000000000000000000000000000000000000100
2. row
id: 2
number03: 1000
number10: 1000
number50: 1000
number03_fill: 1000
number10_fill: 0000001000
number50_fill: 00000000000000000000000000000000000000000000001000
2 rows in set (0.00 sec)

違和感は原因はこの時のやつでした。
MySQLのint型の時には別に領域はそのままで表示の桁埋めのための表記ということ。
int(3) にしても1000は入るし、int(50)なんてのもできてしまう。

「MySQL createtable int zerofill」あたりでググると色々でてくる。

戻ってまとめると、varcharの容量とか仕様のために桁数を検討することは正しい。

2015-02-03

phpのsyntax checkとperlのuse check テスト

リポジトリ配下のファイルの内容を最低限保証するためのテストを書きました。
PHPで調べたところ、syntaxをチェックするそれっぽい関数がない。

正確に言うと、過去にはphp_syntax_checkというのがあったようだけど、5.0.5という結構な昔に廃止された模様。
代わりにコマンドラインから php -l hoge.php が推奨らしい。

なるほどーと思いつつ、推奨されてるならその通りに従って書いてました

php syntax check test

libというディレクトリ配下全般をチェックする前提です。
ファイル一覧を取得するのは1個前のエントリと変わらず。

ちなみにPerlでやろうとすると、perl -wc hoge.plになるんだろうけど、
リポジトリ配下に対してというアプローチの場合、pmファイルを対象としているハズ。
pmファイル群つまり各モジュールがloadできるかをチェックしたいという意図になると思うので、それに対しては Test::Moreの use_okによって実現できる

perl module use_ok test

本当はPHPの場合もロードが正しくできるかをチェックしたかったのだけど、前述のだとそこまでは見られない。
ただ、PHPにおいては vendor/autoload.php でドバっと読み込むのが主流っぽい気もするし、 Perl のように各個ごとに use を並べるのとは仕組みが違う気もするので、今回はこの形に落ち着きました。　

2015-01-23

PHPでcrontabを意図通り書けているか確認するテストを書く

以下の環境と状況を前提にします

あるリポジトリにcrontabに設定したい内容をtxtファイル( cron.txt)を含めてコミットしている
コミットされたファイルがデプロイされるとその内容に基づいてデプロイ先サーバーでcrontabが設定される

よくある構成かと思います。
ここでコミットされているファイルに以下のような記述がありました。

* 13 * * * php hoge.php

この設定を書いた意図は、「毎日13時に hoge.phpを起動したい」でした。
しかし実際の挙動は「毎日13時台に毎分 hoge.phpが起動する」になります。

これに気づかないままコミットしてデプロイされてしまうと、本番サーバーに異常な負荷がかかったり、データ不整合が起こる可能性があります。

このリスクを少しだけ減らすためのテストを書きました。

php_cron_test

cron-expressionというパーサーがあったのでこれを用いています。
便宜的に $PROJECT_ROOT/cron_file 配下に cron.txt(群)がある想定とします。
その上でcron.txt内のcrontabの宣言の次に以下の2行を追加します。

###prev YYYY-MM-DD HH:ii:ss
###next YYYY-MM-DD HH:ii:ss

まず、「cron宣言の後にこの2行がないと落ちる」テスト項目が書かれています。
なので、ファイル内のすべてのcron宣言の後に2行追加する必要があります。
追加した2行には「2015年1月1日 0時0分0秒」から見て、

prev : 最も直前にcronが動いた時間
next : 最も直近でcronが動く予定の時間

を書きます。前述のパターンの場合だと、こんな感じです。

* 13 * * * php hoge.php
###prev 2014-12-31 13:00:00
###next 2015-01-01 13:00:00

つまり、「メモ書きを追加することで『設定した時間が意図通りか』をある程度まで自己確認すること」を目的としたテストです。
実際に、prevの設定値を「2014-12-31 13:59:00」にするか、
cronの宣言を「0 13 * * * php hoge.php」にしないとテストが落ちます。

試しに作ってみた系なので、色々問題はあるかと思っています。

cron.txtが汚れる
- 嫌がる人は嫌がる
意図とはズレていても結果的に期待値が同じprevとnext指定になるケースもきっとある
- cron-expressionが指定時間からの前後時間を返すメソッドを用意してるためそれに合わせた仕様にしたのでこれは許容
基準日だったり、パース用のprefixは割と適当
- なので変更してもらって構わない

PerlだとTest::Crontab::Formatがあり、これはcron.txtに余計な記述をすることなくcrontabのformatをチェックできるので便利です。
最初はこれっぽいものを探していたのですが、見つからなかったのと今回遭遇したケースは「意図と違う時間の設定 = うっかりミス」だったので、こういうアプローチにしてみました。

2014-09-01

YAPC::Asia 2014に行ってきました

bloｇに書くまでがYAPCです。
ここまで2個下から一緒。

もはや、YAPC専用blogになってる。。

今年はスピーカーではなく、イチ参加者（個人スポンサーになってみた！）
として参加してみました

単純な感想はうーん、なんだろう。
あまり楽しめなかったかなというのが率直な所。
きっとそれは個人の問題だと思うので、イベント自体に何か問題があったという訳ではないです。

客観的に見て良かった所
・安定のネットワークインフラ
・無限コーヒー＆レッドブル
・HUB貸し切り！
・何気に空調コントロールも良かった。微妙な天候・気候の中で不特定多数の空間をコントロールしていたのにずっと適温だった気がする
・若い人も結構いた気がする

さて、内容についての感想を述べると、
トークの中には「既にブログなどで発表・公開している内容」に留まってしまうものもあります。
それに至る経緯とか今後の話とか、なんかしらの補足を聞ければ良いんですが、そうならない場合もある。
もちろん、イベント駆動開発ってあるし、それは良い事だと思うので、「作ったよ・やったよ」っていう事を
言うのが価値があるというのもある。
もしくは知らなかった人には当然価値のある新情報としてリーチすることができる、など良い面もあると思います。
要は誰向けに話すか、なんのために話すか、という事でどちらも正解なので難しい。

また今回は応募したトークの数もこれまで以上に多かったようですし、そのためにリジェクトされたものもあったようです。

そういう意味では、「世界最大規模のYAPC」では1対多の形式（セッショントーク形式)では話す方も聞く方も
嗜好とニーズが多様すぎるのではないか、という気がする。
多様さを許容するには並列数を上げる事になるけど、現状の3並列以上も現実的に厳しいだろうし。。

個人的にはトークでいうとlyokatoさんのが一番でしたが、「Perlあるある」のイベントが最も楽しかった。多対多のイベントをもっと多くして欲しいなという気がしました。
Perl入学式がどうだったのかは見られていないので、そこの成果も是非聞いてみたい
「2対多」の形式の「Mobile Application Development for Perl Mongers」も同じく聞けなかったのでわからないけど、
このような「(2|3|4|5...)対多」もっと言うと「多対多」のものがあっても良いと思う

「世界最大規模のYAPC」の魅力は著名な人から初めての人までが参加するイベントであることだと思います。
割と、「あの人最近来てないけどどうしてるんだろう」という事が少ない気がして、
「YAPCに来ればあの人に会える」と思える事のが多いのも良い事だと思う。

まとめると、
・複数人で募集できるトーク（そういえば昔の miyagawaさんとtokuhiromさんの「Plack作ってる」のセッションは楽しかった）の仕組みはどうか
・スポンサーセッションを設けるとまたアレがソレかもしれないので、スポンサー企業のエンジニア同士でディスカッションすればスポンサー側も旨味があったりするのでは。「大規模トラフィックについて」というテーマだけでもそこそこのスポンサー企業の中の著名人引っ張ってこれるのでは。
・どうせ皆餃子食う（この響きも懐かしいけど）んだから、「適当に集まるスペースだけ作ればいいじゃん」というのはさすがにオーガナイズできないだろうし、成果も見えない（イベント行う上でこれも大事）ので言いません。
が今年の感想です。

などなど書きましたが、特に運営の皆様、今年のYAPCもお疲れさまでした。
上の感想は別として、また来年の開催を楽しみにしてます。

2013-09-24

YAPC::Asia 2013に行ってきました

blogに書くまでがYAPCです。
ここまで1個下のエントリと一緒。

結局1年間何も書かなかったということに・・・

各トークの内容は例によってgihyoさん記事とスピーカー自身によるエントリにお任せ。
自分のスライドもSlideShare経由でYAPCのトークページに埋め込んでおきました。

トークした経緯は去年に引き続きgoccyに「喋らないんですか！？」って突っ込まれたから。
今年も人様の作業を堂々とパクる、という芸を見せてきました。

時間がギリギリだったので質問のタイミングがなく、どのように伝わったかわかりませんが
感想・ご意見などありましたらご連絡いただければと思います。

懇親会で「Perlのバージョンアップはホントにあんなすんなり行ったのー？」と聞かれました。
多少過去の出来事 && 一部のみ関わってた立場ということもあり、把握してない苦労など
あったとも思いますが、lestrratさんのトークからも「mod_perlからの脱却の方が大変」
と感じました。そしてそれは未知の部分なので、その差かもしれません。

他の方のトークで印象に残ったのはkazeburoさん、myfinderさん、yappoさん、lestrratさん、ikasam_aさん
と並べると見事にミーハーっぽいチョイスになってる。

kazeburoさんは昔からですが、話がわかりやすく、易しい所から難しい部分まで丁寧に触れられていて
すごく頭に入ってくる内容だった。近年のPerlにおける必須項目Plack周りを知りたい方はまずこちら、という内容でした。
ベストスピーカー賞第3位おめでとうございます。

myfinderさんのは、内容的には弊社内でも全く同じ取組をしています。
tech hills vol.6 においてgoccyが発表しているのでその資料を参考にしていただけると良いと思います。

発表のポイントとして「スケールしていく開発環境にどう対応するか」という所を触れられていて、
実は1日目の懇親会の時に「プロダクトや開発人員が膨らんでいくとテストがボトルネックになりがちですね」という話を
複数人でしていて、そこを重点的に話すというまさに作戦通りのベストスピーカー賞2位おめでとうございます。
bonnuさんの資金でお祝いにいきましょう。

yappoさんの「コピペイクナイ」のコンセプトは素直にステキで、コードレベルだと皆わかってることなのに、設計やプロジェクト運用などスコープが広がるとついついやってしまう事。新しい取り組みを始めた社内でも散見される事象かなと思います。もちろん確立された手法だったり、どうしてもスピードが求められるケースだったり、とか例外はあると思いますが。

lestrratさんのトークは、自分も似たような話をしたハズなのに、全然違う内容に感じるなど
発表方法として学ぶ部分もすごい多かった。mod_perl周りの話は前述のとおり。
発表時間がより短い中で、さらにその一部分で触れていただけなので厚みに差があるのはまぁ当たり前なのだけど、
どちらのが伝わりやすかったかと考えると明らかかなと。

ikasam_aさんのは何度か聞いているSWETグループの立ち位置と取り組みが興味深い。
Testをエンジニアリングするというのがクールだし、その過程で出る問題とかもっとあるだろうなと思うので、
その辺含めて今後も聞ける機会があると良いかと思いました。非機能要件にアプローチするという点では
今の仕事と通じる部分があると思っていて、それがおもしろかったです。

聞けなかったトークだと、soh335の話。
自分の発表の真裏だったので物理的に不可能でした。後夜祭でお話しさせていただいて、
改めて資料チェックしようと思います。

自分の発表資料の中で、Test::UselessModuleというのを紹介しましたが、
そのあとタイムライン見てたらたまたま Test::UsedModuleというのを知ったので見てみたら
完全に元々やりたかったことが実装されてる内容になってるっぽいですね。
作者のmoznionさんとお話しする機会を密かに狙ってたんですが開催中に会えなかったのが残念でした。

内容が被っているという意味では、nekokakさんのLTで出ていた共通モジュールの話もそう。
まさにたんぽぽ的な取り組みですね、という印象で他にも同じような取り組みをしているorこれからする
所はあるんじゃないかと思う。共通なものを作ったあとに、呼び箇所をスムーズに置き換える所にも
工夫してる部分あるんですが、その辺をどうしてるのかとかも気になりました。

YAPC::Asia 開催全般で言うと、運営の方々の安定感もあり、特に困る事はありませんでした。
メイン会場の電源が確保されていたり、ネットワーク環境が整備されていたり何不自由なく過ごせました。
スポンサー企業のご協力でサービスしていただけた部分（懇親会とか）、ボランティアの方々、
もろもろ含めてお疲れ様でした＆ありがとうございました。

ここまで完成されたイベントが来年からどうなるか楽しみ以上に不安な部分も大きいですが、
ぜひとも継続して開催してほしい、いやしていくのに協力したい、と思いました。

皆様お疲れ様でした、来年もお会いしましょう。

2012-10-01

YAPC::Asia 2012に行ってきました

blogに書くまでがYAPCです。
今年もYAPC::Asia 2012に前夜祭含めて参加してきました。

例によってトークの細かい内容はgihyoさんの記事や
各スピーカーの方々が資料をアップしてくれるのにお任せしたいと思います。

今年は、2年ぶり2回目のスピーカーとしての参加でしたので、その辺メインで。

トークしようと思ったきっかけは、同じチームの人が喋るから、っていうのに
引っ張られただけで特に強い意図があったわけではなく・・・
ここ最近の会社の取り組みで、他人が頑張った事をさも自分の功績の如くエラそうに喋る。をしてきました。

資料はSlideShareにアップしましたが、YAPCのトークページからでも閲覧可能です。
（動画もそのうちあがるはず）

会場で質問いただいた中で、ちょっと上手く答えられなかったかなという部分について補足します。
「既存のuseして呼び出しているメソッドをServiceProcedure経由に置き換える場合にデグレをどう担保しているのか？」
という質問をいただいた（と記憶してます）

これにつきましては、ServiceProcedure呼び出しは新しいパブリックなI/Fの提供を行う、
という仕組みなので必ずしも既存の呼び箇所がすべて同時に置き換わる訳ではありません。
つまり「呼び換え漏れ」というものはなく、それはただ移行段階であると言えます。
既存のメソッドに手を入れる訳ではなくAdapter層を設けているため新旧I/Fの併用が可能なためです。

ここからは会場で返答した部分ですが、呼び換える際に、I/Fが変わる事はちょいちょい起きます。
特にレスポンスの部分は元々がオブジェクトを返すような形式だった場合、ServiceProcedureはplainなデータを扱うと規定しているため、呼び側でオブジェクトを期待しているコードは修正する必要があります。それに合わせてテストの修正が必要になることもあるかと思います。
plainデータに縛っているのは、そこでオブジェクトを返してしまうと結局呼び側が他の名前空間のモジュールを意識（=管理）することになってしまうためです。

2年前にトークした時には質問とかいっさいなかったので、質問をいただけるということは嬉しいことですね。
リハしたら毎回30分近くかかるものが、20分にきっかり収まってたので、どんだけ早口だったのかどんだけ言い漏れしてたのかは動画がアップされてから反省したいと思います。。

今年もいろんな方とお話しさせていただきまして、個人的に嬉しかったのは1日目の懇親会の時にlyokatoの計らいで、mizzyさんに通われている大学の授業について聞くことができました。
実は同じように大学に通いたいと考えていたので、どんな感じの授業なのかとても参考になりました。1日平均で4時間くらいは勉強されているということで、かなり甘く見てたのを思い知りましたが。。

YAPC全体としては、パネルディスカッションの時にも話が挙がっていましたが、ここ最近のYAPCでは技術的に新しくてみんなが「オォー」ってなるものは出ていない気がします。（2008年のMoose、2009年のPlackくらいまで）
例年ベストトーク賞などの優秀賞は会社の内容や業務に近い話をされている方が受賞されている傾向が多いようにも見えます。
（2日目の後夜祭で、「初めてYAPCに来た人とかだけが真面目に投票して、そういう人達に刺さるのが会社系トークなんジャマイカ」っていう会話をした記憶もありますが、それはさておき・・）
なので、まだ発表されてない方で、発表内容に困っている方でもどんどんトークすればいいんじゃないかと思いました。
かく言う俺も（賞とか貰ってないけど）まさにそれ系のトークですし。
逆にパネルの時に予見されていた「そろそろまた『新しい何か』が出てもいい頃」の方に踏み込むのももちろんアリではないかと。

いきなりYAPCは、と思った方は来月開催される予定のyokohama.pmに参加してみてはいかがでしょうか。

最後になりますが、牧さん・941さんをはじめとする運営スタッフ＆ボランティアの皆様お疲れ様でした。
慣れ親しんだ東工大から離れて大変な面もあったかと思いますが、例年に近いくらい快適でした。
お陰様で安田講堂を写真に収め、近くにあった生協で東大シャーペンと東大ノートも買えました。
経理担当のJPA理事さんもお疲れ様です。
来　年　も　楽　し　み　に　し　て　い　ま　す

今年もお土産写真を掲載して締めます。Thank you very much, Larry!

2012-07-10

Params::Validate をuseする時「use Params::Validate qw//;」と書くのを推す理由

社内のコードレビューで、Params::Validateのuseの際に、

use Params::Validate qw//;

と後ろにおまけをつけてもらうようお願いしていました。

たまたま、「そういえばなんで qw//; をつけるんですか？」と質問されたので、口頭では簡単に説明したんですが、メモの意味でこちらにも書いておきます。

と言っても、コードがあった方が早いので、以下の３つのファイルを用意しました。

package YAPC::Asia2011;
use strict;
use warnings;

use Exporter qw/import/;
our @EXPORT_OK = qw/ is_hold /;

sub is_hold{
    print "YAPC::Asia 2011 has already held  2011/10/13 - 15 \n";
}

1;

package YAPC::Asia2012;
use strict;
use warnings;

use Exporter qw/import/;
our @EXPORT = qw/ is_hold /;

sub is_hold{
    print "YAPC::Asia 2012 will hold 2012/09/27 - 29 \n";
}

1;

#!/usr/bin/perl 
use strict;
use warnings;
use lib "./lib";

use YAPC::Asia2011 qw/is_hold/;
use YAPC::Asia2012;

is_hold();

exit;

これで、最後のplを実行してみると、

YAPC::Asia 2012 will hold 2012/09/27 - 29

と出力されるはずです。use の順番を2011と2012で逆にすると、

YAPC::Asia 2011 has already held  2011/10/13 - 15

になるはず。

useしたモジュールが@EXPORTに関数を突っ込んでると、自動的にその関数を使えます。
そんなモジュールはたくさんあるし、必ずしもそれが悪い事ではないのですが、
Params::Validateの場合は「validateとvalidate_pos」が@EXPORTに入ってるので、
特に前者は思わぬところでバッティングしたらイヤだなぁという思いから、これを抑止したかったため
冒頭のお願いに繋がりました。

サンプルのplでも

use YAPC::Asia2012 qw//;

と書くことで、useが後だとしても

YAPC::Asia 2011 has already held  2011/10/13 - 15

になるはずです。

モジュールを作る際には、@EXPORTと@EXPORT_OKどちらに突っ込むかは考慮して作成する必要があると思いますし、使う側としても、適切なもののみ選んでimportする方が良い派です。

そんなこんなで、YAPC::Asia今年も楽しみですね！