WEB+DB Press vol.96 の Perl Hackers Hubに寄稿しました

gihyo.jp

この度、id:songmu さんにお話をいただいて、WEB+DB Press vol.96 の Perl Hackers Hubに「大規模広告配信でのCPANモジュール活用」と題して寄稿しました。
内容は今勤めている fluct社のSSPサービスfluct の配信サーバー周りについてです。

fluctのPerlは広告配信という、いわゆるMVCのフレームワークでWebサイトを作るのとは違った役割を持っていておもしろい面がありますが、
スマホのクライアントアプリを受けるAPIサーバーとかだと作りが参考になる部分もありそうですし、
広告ならではの設計もあります。案件情報を取得する部分は（Perl要素薄いですが）おもしろくてオススメ読みポイントです。

初めての執筆活動

実は、本を出すことはおろか、寄稿するというのも初体験でした。
こんな貴重な機会をいただいた id:songmu さんには大変感謝しております。

やってみて、どうだったか？

すげー大変でした！

普段とても意識していることに「言うことは3行で、簡潔に」というのがあります。
この原則は前職の上司に求められたことで、とにかく如何に短くするかを考えた上で、結論を先にまとめて言うようにしています。
これは少ない時間で本質から逸れない意思決定をするためにとても大事な事だと思ってます。

しかし、記事というものは「起承転結」と構成・流れ があり、それが基本かつ核になります。
執筆にあたっては、まずアウトラインを決めるのですが、個人的にはこれがその後の本文書くより難しかった、、
アウトラインだけで流れがわかるかどうか、がポイントなのですが校正で指摘してもらってもどうして良いかわからず。。
初っ端からかなり躓きました。

その後においても、初期のコンセプトが緩かったために 何を伝えたいのかわからない 文章になってしまったり、技術評論社の稲尾さん、監修の牧さんには執筆の過程で、多大なご迷惑をおかけしました。

結局、書けたの？

最終的には、しっかりと仕上げました。 そう言えるのは理由があって、実は来年(2017年)の頭に、fluct及びVOYAGE GROUP を辞める事にしました。

というわけで、本エントリは「退職エントリ」ではなく、「退職しそうなエントリ」です。

執筆のお話をいただいた時点で、転職先は決まっていなかったものの気持ちの中では辞める意志は固まってました。
だからこそ、今回の記事はキッチリ書こうと決めていました。

所属していれば、例えその記事の内容が不十分でもあとでblog等で補足できるかもしれません。
あるいは同僚がフォロー・サポートしてくれるかもしれません。

しかし、そこを辞める人間が書いた記事がイケてない内容だったら
外の人には、どうせ辞めるから適当に書いたんだろうと思われるかもしれないですし、
残る中の人からは、適当なこと書きやがってと恨まれるかもしれません。

そう思わせないような記事にしなければと思いながら書きました。
もちろんアーキテクチャは変わっていくと思うので、普遍的に正しい情報ではないですが、2016年末の状態は表せています。

自分としては、約2年携わって、記事を寄稿できるくらいシステムを理解したし、むしろ書ききれなかった事の方が多いです。
それはページ数が理由なだけでなく、fluctの環境の中でPerlが稼働している部分はあくまで一部であるためです。
サービスの中にいくつものドメインがあり、リポジトリと稼働する言語が複数ある、というのは前職と全然違くてやりがいのある環境でしたが、そのほぼ全てになんらか手をつけられて理解することができたのは良かったです。

また、記事の次のページで fluctの求人インタビュー広告が載っています。 このインタビューも、自分も参加する案もあったのですが断っていました。それも辞めると決めていたから。
さすがに求人しておいて、もし仮にそれに惹かれてくれた人がいて縁があった場合、「入社してみたら惹かれた人がいなかった」なんて事になったらそれはヒドいと思うのが理由です。

決して、「オススメできない環境だから求人に協力しなかった」訳ではないので、自分は違う道を選ぶけど、fluct及びVGがマッチする人はきっといるだろうし、いてほしいと思う。

話を戻すと

そんなこんなで、俺の卒業論文かつPublic公開な引き継ぎ資料であるWEB+DB Press vol.96 は16周年号として内容盛りだくさんとなっておりますので、是非ともお手に取っていただければ幸いです。

個人的にはかなり大変でしたが、とても良い経験になりました。
正直辞めるつもりで業務を整理しはじめていたので、執筆に割けるリソースがあったけど、通常の業務をこなしつつ執筆される方々は本当にすごい。
そういう時にどこまでできるかわからないけど、また機会があればぜひチャレンジさせていただきたい！

求人告知

fluct及びVGはPerlを始めとして様々な技術を使った事業開発会社です。
ことPerlに関して言うなら、客観的に見てそこまで使用割合は多くない。
おそらく今回の記事内容相当のPerl製のプロダクトはないと思いますが、全く違うアーキテクチャでおもしろいプロダクトはあります。
興味があれば、「ajito で話聞きたい」とつぶやけば誰かが反応するでしょうし、どうしてもであれば俺に連絡もらえれば、繋ぎますのでお気軽にどうぞ！

Atmoph Windowがやってきた！

kickstarterで申し込んでいた、Atmoph Windowがようやく到着しました！
ようやくと言っても、実は3週間くらい前に届いていたのがこれまで（引っ越しがあったので、新居で && net開通してから）開封できてなかったというのもある

設置手順

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

セットアップ手順

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

感想

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

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

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

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

やりたいこと

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

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

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

で、どうやるか？

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

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 で切ってください

画面イメージ

まとめ

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

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版は少し弱すぎるかもしれない。。

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