Atmoph Windowがやってきた!

f:id:masartz:20161113145412j:plain:w500
kickstarterで申し込んでいた、Atmoph Windowがようやく到着しました!
ようやくと言っても、実は3週間くらい前に届いていたのがこれまで(引っ越しがあったので、新居で && net開通してから)開封できてなかったというのもある

設置手順

とりあえずテーブルと同じ高さで立て掛ける形で配置してみた。
テーブルと併設している引き出しボックスを足場にしていて、その引き出しのポジションの関係で右の一部が宙に浮いてるけど、安定してます。
壁にひっかけるためのフックも東急ハンズで500円くらいで売ってたので買ってきました。開く穴が小さくなるし、3点固定で安定。という触れ込みだったけど、思った以上にピンが太くて、「これ穴わかるだろ、、」ということで、ひとまず使ってません。
代わりに100円ショップで買ってきた耐震用の粘着パーツで足元を強化して、これが割と良い感じです。
f:id:masartz:20161113145435j:plain:w300

セットアップ手順

使用にはWi-FI環境が必要ですが、スマホからのWi-Fi認識させるセットアップ手順もスムーズでした。
本当にスマホを上部におしつけて信号を送ると良さそう(手順の話なので買ってない人はようわからんと思いますが・・)
逆にわかりにくかったのは、MENUの操作方法^^;
スマホ側がレーダー画面になり、スワイプとかクリックとかがAtmoph側に反映されるんですが、Atmoph画面にカーソルでも出れば伝わるのですが、パッと見だとスマホ画面とAtmoph側の画面のポインタ位置がシンクロしてるのがわからなかった。。

感想

使って見ての感想は、4k画質ということで、さすがに綺麗。
おかげでさっきは珍しく自宅でターミナル開いた作業が捗りました!
f:id:masartz:20161113224404j:plain:w500

これ、写真だと伝わらないですが、静止画ではなく動画 なので(窓ですから!)
夜の時間に夜景を見ながらPC作業するのはなかなか雰囲気出て良かったです。
今後は素材が増えたり、ライブストリーミングも追加されるとの事なので非常に期待。
個人的には自分の素材をアップロードできるようになるのが楽しみ。

気になった方はこちらから どうぞ。
新型MacBookProを今から注文しても年内到着しなそうなので、うっかりAtmophをお買い求めいただくのも良いのではないでしょうか。

いくつかのファイルをまとめて 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の容量とか仕様のために桁数を検討することは正しい。