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

いくつかのファイルをまとめて tail する簡易スクリプト

やりたいこと

サービスリリース時に、先に局所的なデプロイをして様子を見る際などに使う

(実際に使っている)ユースケース

  • 広告配信サーバーが数百台あり、リリース時には手始めに1台にデプロイして動作確認というフェーズがある
    • この時、該当1台はバランサーから外している
  • 配信サーバーは、以下の3つのプロセスで成り立っている
    • 広告タグが貼られているメディアからのアクセスを受けるエンドポイント的なApache
    • 配信案件の管理し、場合によってRTBプロセスへのリクエストを行うPlackアプリケーション
    • DSPへのRTBやりとり(外部通信)を行う、RTB
    • 処理の流れとしては メディア -> Apache -> Plack -> RTB -> DSP -> RTB -> Plack -> Apache -> メディア となる
  • 先行1台での動作確認時には以下のあたりを確認したい

で、どうやるか?

簡易的なスクリプトを作ってましたが、ちょっとだけ直して外部に切り出してみました

How To Use の項目のままなのですが、clone して make すれば動きます
もうちょっと詳しく書くと、

  • 実態はperl スクリプト
  • make setup で必要なCPAN Module を $REPOS/local 配下にinstall
    • 正しくはcpanm を拾ってくる所からやるべきですが、手抜きしてリポジトリ内に同封してます
  • etc/config.yaml を 編集します
    • path : (必須)tailしたいログファイルのFull Pathを記入。アクセスログ等はローテートすると思いますが、動的な日付部分は POSIX::strftime() 形式で書けます。File::RotateLogsのやり方をパクりました
    • color : (必須)Term::ANSIColor で色付けして出力するための色指定です
    • option : (任意) File::Tail で出力する際のオプション指定
  • 編集したconfig.yaml のフォーマットが正しいか make test で確認できます
  • make run すれば、動きます。無限ループで動き続けるので、 Ctrl + C で切ってください

画面イメージ

f:id:masartz:20160923110540j:plain

まとめ

Term::ANSIColor や File::Tail など、既存のCPAN Moduleを使えてお手軽に作れました
運用上のログ監視はこんなのとは全然違うしっかりした仕組みがあるので、
あくまでリリース時の開発者作業の一助に過ぎません。そのスコープにおいてはこれで十分かと思います

AJITOの風景で写真の構図を勉強する

前置き

こんにちは、この記事は#ajiting Advent Calendar 2015の5日目です。

VOYAGE GROUPの写真サークルに所属する自分が、AJITOで写真の構図を勉強した模様をお伝えします。

構図とは?

写真にはいわゆるいくつかのお決まりパターンがあり、それに沿って撮ることで(きっと)いい感じの絵になります。
プログラムのデザインパターンと一緒ですね!
実は今までちゃんと勉強したことなかったのですが、今回少しだけ学んでみました。

さっそく実践、まずは日の丸構図

文字通り、被写体を真ん中にどんと持ってくるパターンですね
f:id:masartz:20151203004323j:plain:w400
というわけでAJITOのロゴをどーん
何を伝えたい写真なのか一目瞭然ですね

二分割構図

こちらも文字通り真ん中で分割のパターン
垂直に分割するとこうなります
f:id:masartz:20151203001246j:plain:w600
今回は正確には左右非対称です。
ちなみにAJITOの運営としては昼が白のブラインド、夜がさらにその上に濃いブラインドをかけます。
またシンメトリー構図と言って、左右を完全に対称にするパターンがよくありますね。
神社やお寺などの対象物が大きい時に意識して撮ると良いと思います。
タージマハルのシンメトリー構図の写真が超有名で、いつか自分で撮ってみたい1枚です。

三分割構図

だいたいどれも文字通りなのですが、これもそう。
同じく垂直に分割した場合です。
f:id:masartz:20151203010320j:plain:w600
おそらくかなりベーシックな構図で、きっと無意識にやってる事が多いパターンです。
個人的にもこれが一番「よく撮る絵だなぁ」と思いながら撮ってました。

ちなみに水平に分割すると、こうなります。
f:id:masartz:20151203010045j:plain:w600
天井が一番上のレイヤ、頭までが真ん中のレイヤ、残りが一番下のレイヤ、で別れているかなと。
左の壁がなかったらより深みのある写真にできたかもしれません。

対角線構図

これは情報源によって微妙に内容が違う気がするんですが、
パターンAとして、対角線の端と端に撮影物を置いてみます。
f:id:masartz:20151203010918j:plain:w400
奥行きが出ますね

パターンBは、対角線上に並べて(あるいは繋げて)みる f:id:masartz:20151203003327j:plain:w600
お酒のてっぺんを線で繋いで対角線を描くのを意識してみました。
f:id:masartz:20151203015139j:plain:w600
こちらは机の角を対角線に見立てて、区切りをつけた感じ。

勉強してみた結果、、、

やはり写真は奥が深くて面白いですね。
正直今回の撮れたものは自分の中でかなり満足度は低く、まだまだ未熟だなという感想です。

結局、最後に勉強は切り上げて、好き勝手に撮った写真を並べます
f:id:masartz:20151203015436j:plain:w400
水平に2分割してみましたが、これも意外と良い

f:id:masartz:20151203020159j:plain:w600
好きに撮ったと言いつつ、これも3分割方かもしれない、、

f:id:masartz:20151203020614j:plain:w600
AJITOっぽい

最後に

AJITOは

  • 写真の素材にもなる
  • 時にはシックなBarでコーディングが捗る( <- 撮影日は珍しくこのパターンでした)
  • 基本は社内の様々な交流イベントが常時開催されている

場所ですので、写真でもお酒でも興味を惹かれた方はお気軽にお越しください。
それでは少々早いですが、メリークリスマス! f:id:masartz:20151203021653j:plain:w600

明日は急遽無茶ブリで指名されたhahatchが登板します!

sinatra-formkeeperで2つの入力内容が異なることをvalidateする

最近業務で、とあるwebツールを作っており、いわゆる入力画面が必要になった。

今回はRubyのプロジェクトだったので、アプリケーション自体はsinatra
そのvalidatorとしてlyokatoさんのsinatra-formkeeper を使った。

これが大変便利!
さすがFormvalidator::Simpleを作っただけあって、
必要なものは揃っているし、使い方も上述のblogエントリを読めば、ほぼわかる。

ただ、「 入力値A入力値B が異なること」ということをしたい場合にこれをvalidateする機構がなかった。
今回はこれがピンポイントで欲しい機能だったのでサクっとPRを投げて、取り込んでもらった。

github.com

Validatorとしてのコア機能はformkeeperに切り出されているので、PR自体はそちらに対してのものになっている。

さっそくmergeしてもらい、rubygemsからも拾えるようになった。
使い方はこんな感じ。
テストも合わせて貼っておきます。

gist.github.com

実装自体は99%が既存の機能である same のパクリ。
same は上述のブログ例に書かれている通り、パスワード確認の時などに用いられるでしょう。
対して今回の diff は例えば登録しているメールアドレスの更新や、パスワードの定期更新などに用いられる事を想定してます。
(※ パスワードを定期的に更新するセキュリティポリシーとその運用の是非についてはここでは言及しません)

まぁ、今回の業務ではそのどちらでもないケースで必要になったパッチ送ったのですがw
なので、きっと他でも有用なところがある(かもしれない)!

繰り返しになるけど、sinatra-formkeeper 自体がそもそも便利なので、
まとめとしてはそれが便利ということが伝われば良しです。

YAPC::Asia2015で「 Perlがメインじゃない 現場でもPerlを使う (AdTech現場編)」というトークをしてきました

タイトルでほぼ出オチですが、2年ぶり4回目となるYAPC::Asiaでの発表をしてきました

www.slideshare.net

4回目とか言いつつ、内容はまだまだだし、発表自体も緊張しまくりでした。
前週のうちに資料作りと社内リハーサルを終えていたのに、前日とかにで結構な分量の修正してた。。

togetter.com
いくつかコメントも頂いていてありがとうございます。 内容としては、現職での直近業務についてお話しするという感じでした。
はっきり言って地味な業務だし、伝わりづらい内容ではあると思いますが、何かの参考になれば幸いです。

YAPC::Asiaも10周年。
とうとう今回は2000人規模に。自分の発表した会場でさえ、一番小さいのに100人キャパ。
5トラックという並列性も過去最高。とんでもないイベントですね。

自分の発表が2日目午後だったこともあり、2日目のトークは聞けないのもあったりして、 リファクタだったりGoの話だったりは後ほど確認したいと思いました。
例年通りの幅広い内容で充実していたのではないかと。

ビックサイトは何気にほとんど行った事なかったですが、スムーズな運営(無線ネットワーク、通訳、ボランティアスタッフの対応 などなど) のおかげで非常に快適でした、これは例年通り!

今の自分があるのはYAPC(と特にyokohama.pm)が一定割合占めているなと思うと、
来年以降も何かしらの催しが欲しいと素直に思います。

Thanks YAPC::Asia!!

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

TL;DR

書いたcronが意図通りの時間に動くかを簡易的にテストするもののPHP版に元に、Perl版のモジュールを書いてgithubに置きました(未CPAN UP)

追記: CPANにもUPしました

これは何?

意図としてはPHP版と同じです。

PHP版の時には使ったライブラリ(Cron\CronExpression)が 「crontab宣言と基準時刻を食わせると、その時刻より最も直前にcronが動いた時間と最も直近でcronが動く予定の時間を返してくれる」 のでこれとのマッチングをテストしていました。

今回のPerl版はsongmuさんが作成されたParse::Crontabを用いてます
これは「crontab宣言を食わせて、指定時刻渡すと、その時刻にcrontabが動くかどうかを返してくれる」ので、これとのマッチングになります

サンプルコード

サンプル置き場 にも置いてあるのですが、

#!/usr/bin/env perl

use strict;
use warnings;

use Test::More;
use Parse::Crontab;
use Test::Parse::Crontab::Simple;

my $crontab        = Parse::Crontab->new(file => './crontab.txt');
my $crontab_strict = Parse::Crontab->new(file => './crontab_strict.txt');

ok $crontab->is_valid;
match_ok $crontab;

ok $crontab_strict->is_valid;
strict_match_ok $crontab_strict;

done_testing;
*/30 * * * * perl /path/to/cron_lib/some_worker1
###sample 2014-12-31 00:00:00

0 23 * * * perl /path/to/cron_lib/some_worker2
###sample 2014-12-31 23:00:00

0 15 * * * perl /path/to/cron_lib/some_worker3

crontab記述の次の行に
###sample YYYY-MM-DD HH:ii:ss

の形式でそのcrontabが動くと思う時間を書いておくと、
意図した時間にcronが動くかどうかをテストすることができます

match_ok のメソッドを用いた際にはサンプルの時間記述は必須ではありません
記述がなければ該当のcrontabの宣言はテストされずに進みます

一方、strict_match_okのメソッドはcrontab宣言の直後に必ずサンプルの時間記述を求めます
記述がない場合にはテストがfailします

進捗

現時点では、サンプル記述はcrontab宣言ごとに1つしか想定していないため、あくまで簡易的なテストです

* 17 * * * perl /path/to/cron_lib/hourly_worker
###sample 2015-01-01 17:00:00

上記は毎日17時に1回動いて欲しいバッチに対して、それを期待した サンプル記述をしていますが、実はこのバッチは17時台に毎分動いてしまいます
それは意図通りではないのですが、そこまでのテストができてません
PHP版の時には少なくとも2つのサンプルを必要としていたので、上記パターンも 検知しやすかったですが、そういう意味だと今回のPerl版は少し弱すぎるかもしれない。。

この辺は是非フィードバックをいただきたいところです。

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の容量とか仕様のために桁数を検討することは正しい。

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 を並べるのとは仕組みが違う気もするので、今回はこの形に落ち着きました。