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

前置き

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

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

構図とは？

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

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

文字通り、被写体を真ん中にどんと持ってくるパターンですね

というわけでAJITOのロゴをどーん
何を伝えたい写真なのか一目瞭然ですね

二分割構図

こちらも文字通り真ん中で分割のパターン
垂直に分割するとこうなります

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

三分割構図

だいたいどれも文字通りなのですが、これもそう。
同じく垂直に分割した場合です。

おそらくかなりベーシックな構図で、きっと無意識にやってる事が多いパターンです。
個人的にもこれが一番「よく撮る絵だなぁ」と思いながら撮ってました。

ちなみに水平に分割すると、こうなります。

天井が一番上のレイヤ、頭までが真ん中のレイヤ、残りが一番下のレイヤ、で別れているかなと。
左の壁がなかったらより深みのある写真にできたかもしれません。

対角線構図

これは情報源によって微妙に内容が違う気がするんですが、
パターンAとして、対角線の端と端に撮影物を置いてみます。

奥行きが出ますね

パターンBは、対角線上に並べて（あるいは繋げて）みる
お酒のてっぺんを線で繋いで対角線を描くのを意識してみました。

こちらは机の角を対角線に見立てて、区切りをつけた感じ。

勉強してみた結果、、、

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

結局、最後に勉強は切り上げて、好き勝手に撮った写真を並べます

水平に2分割してみましたが、これも意外と良い

好きに撮ったと言いつつ、これも3分割方かもしれない、、

AJITOっぽい

最後に

AJITOは

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

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

明日は急遽無茶ブリで指名された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 は例えば登録しているメールアドレスの更新や、パスワードの定期更新などに用いられる事を想定してます。
（※ パスワードを定期的に更新するセキュリティポリシーとその運用の是非についてはここでは言及しません）

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

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

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

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

YAPC::Asia2015 from Masaru Hoshino

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

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をチェックできるので便利です。
最初はこれっぽいものを探していたのですが、見つからなかったのと今回遭遇したケースは 「意図と違う時間の設定 = うっかりミス」だったので、こういうアプローチにしてみました。