カルテットコミュニケーションズの開発部で仕事をし始めて、そろそろ2ヶ月になります。ここでの私の仕事は、バリバリ開発もしながら、チームメンバーにメンタリング（おせっかい？）したり、ソリューションの提案をしたりすることです。 このなかで、開発について私のやったことを、私の考え方を断片的にでも伝える目的で、開発日誌としてブログ記事にしておきます。

カルテットコミュニケーションズの開発部の中心的な業務は、リスティング広告運用のための総合支援ツール Lisketの開発です。一口にリスティング広告の運用といっても、Google/Yahooがそれぞれ検索連動型広告とディスプレイ広告を提供しており、最低でも4種類の広告プラットフォームを相手にすることになります。そして、それぞれのプラットフォームで必要な作業手順が微妙に異なっている上、扱う情報がかなり大量になるため、運用業務の様々な局面において、ソフトウェアの補助がかなり効果を発揮します。Lisketは、運用を総合的に支援する様々なツールで構成されています。

Lisketの中には、Google/Yahooへの広告入稿に必要な、いわゆるアカウントデータを扱うツールが複数あります。私の最初の業務は、既存のアカウントデータ（CSV）に対して、ちょっとしたルールで入札価格を調整するツールの開発でした。（社内向け専用ツールにつき現時点では非公開となっています）
このツールの開発は、コンポーネント化などまでは踏み込まなかったこともあって、わりとあっさり完了しました。

その後既存ツールの修正・改善などのチケットをこなしつつ、Lisketの中では古株であるアカウントCSVチェッカーというツールの再実装をやることになりました。 チェッカーの再実装には、CTO @ttskch さんの以前からの目論見でもある、アカウント用モデルの再構築プロジェクトも付随していました。

Lisketは現時点でGoogleとYahooのデータに対応していますが、この2つで入稿に使うCSVの形式はだいぶ異なっています。しかし、データ構造的にはほぼ同じです。両方のデータをうまく扱えるモデルが1つあれば、それで何でもできるというのが @ttskch さんの構想でした。ただ、いろいろな事情があってこれまでのLisketの実装では着手できておらず、個々のツールごとに微妙に異なるクラス群が作られ、使われていました。

この記事執筆時点では、アカウントモデルの形がある程度まとまって、読み込み関係の処理などもできてきたところです。この記事を書いている5月末時点で、この関連で以下の7つのパッケージを作成しました。

component1

  • quartet/common
    • 全体的に汎用なクラス等。元からLisketにあった「CSVファイルを読み込む」クラスの他、「AbstractCollection」「SubtypedCollection」などがある。
  • quartet/haydn
    • 配列をいい感じに集合演算したりするレイヤー／クラス。まだ活躍を見ないが、地味に効いているｗ
  • quartet/contextual-validator
    • コンテキスチャルなバリデーター。後述のアカウントCSVチェッカーのために作った。
  • lisket/account-model
    • アカウントデータの統合モデル。カルテットの開発メンバーといろいろ議論して良い形になった。
  • lisket/account-csv-reader
    • アカウントデータ（CSVから読み込んだもの）をアカウントモデル（オブジェクト構造）へロードする。Yahoo/GoogleのCSVのフィールド定義などもこのパッケージにまとめてある。アカウントCSVチェッカーなど別ツールとのインテグレーション用に、アカウントロードの各時点をイベントによりフック可能。
  • lisket/account-csv-checker
    • アカウントCSVのフォーマットエラーをアカウントモデルベースでチェックする。読み込みなどの処理はこのパッケージにはまったく定義されておらず、各フォーマットに対するチェックルールの定義と、イベントへ仕込む処理等があるだけになっている。
  • lisket/sample-data
    • さまざまな状況（正しい／間違い）のデータをツールの開発時に利用するが、データ作成そのものが手間なので、共有のために作ったデータリポジトリ。いくつかのCSVファイルや、行ごとにユニットテストするために使う配列定義（PHP）がある。

これらのパッケージ間の依存関係は、次のようになっています。

component2

このパッケージ階層を常時行き来しつつ

  • チェッカーを作る
    • 状況依存バリデーションが必要（contextual-validatorを作る）
    • リーダーを作る
      • アカウントモデルを作る
        • Commonパッケージを作る
        • 確認用にサンプルデータを作る

こんな感じで深い階層まで行っていたところを、今週ようやくチェッカーの階層まで戻ってきて、定義したバリデーションが動く！というところまできました。

contextual-validatorやhaydn等、個々のパッケージについてや、これだけパッケージを分ける開発の意義などは、気がノッたらまたブログ記事にしたいと思います。

それにしても歳のせいか、一度にたくさんのパッケージを行ったり来たりする開発で、毎日脳がオーバーヒート気味でした。しかし、オーバーヒートするほど脳をフル活用して仕事ができるというのは、これほど幸せなことはありません！