前回の記事「2013年の新卒研修と社内ISUCONやりました - (1) 研修編」に引き続き、新卒研修の最後を飾るイベント、社内ISUCONについて詳しく振り返ります。

社内ISUCONとは

レギュレーションはこちらです。

• 各チーム1台ずつ使用できる仮想マシン上で、お題のアプリケーションを動作させる
• 外部からベンチマークを行って処理できたリクエスト数をスコアとする
• アプリケーション、OS、ミドルウェアなど、どのようなチューニングを行ってもよい
• ベンチマークスクリプトはデータの整合性をチェックするロジックが組み込まれており、アプリケーションとして不整合を起こしていることを検出するとFAIL(スコアなし)
• 10:00〜17:00 までの作業中には適宜ベンチマークを実行できる
• 作業終了後の最終計測でのスコアが高いものが優勝 (FAILしたら失格。17:00以前までのスコアは考慮しない)

参加したのは2013新卒8名が2名ずつで4チーム、先輩は10名を5チームに編成し、合計9チームです。

お題のアプリケーションはいわゆる nopaste (gistのようなもの) です。ユーザ登録、ログイン機能を備えており、投稿と★を付ける機能はログインした状態でないと使えません。サイドバーには最新投稿が100件まで並んでいます。

ソースコードは一式公開しています

ログイン機能があるため、セッション管理が必要になるところが過去2回の本家 ISUCON とは異なるところでしょうか。

新卒チームは昨日まで実際に作成していたアプリケーションをベースに作業できる上、実行するサーバ環境も研修中の実習で使用していたもののため、先輩チームよりは内部の把握に有利です。これはハンデですね。

死闘の始まり

10:00 から本家ばりのオープニングムービーに引き続きレギュレーション説明が行われ、各チームは作業を開始します。

1チームのみ、運営の不手際で仮想マシンに30分ほどログインできない事案がありましたが、これは優勝候補の一角「チーム kameda (handlename, kenjiskywalker)」だったのでハンデということでひとつ勘弁していただきたく…

ベンチマークは CIツール Ukigumo (に少し手を入れたもの) で実行し、スコアを一覧して表示できるようにしていました。

新卒の一撃

競技開始から2時間ほど経過した12時過ぎ、新卒チーム ganbaru (MacoTasu, ichinose) がここまでの最高スコア 13,000 over を叩き出し、先輩チームに動揺が走ります。初期スコアは200程度ですので、この時点で60倍以上の高速化をしたことになります。

社内isuconを終えて - Maco_Tasuの技術ブログによると、この時点でサイドバーで大量に飛ぶクエリの書き換えとindex追加、nginxで静的ファイルをさばくなどのチューニングが行われていたようです。

デッドヒート

なかなかどのチームもブレイクスルーを起こせないまま、しかし着実に先輩チームはスコアを伸ばしていきます。

チーム beer (soh335, Konboi) が 15時前に 20,000 に到達、同じく先輩のチーム kameda と fugu (macopy, 9re) がそれを追いかけます。

しかし午前中に会場の空気を震撼させた ganbaru が 16:25 に 23,000 超えでトップを奪還、激しいデッドヒートを繰り広げる展開となりました。

部長、動く

終了まであと1時間を切る激闘のさなか、2年目のtkuchikiとコンビを組み、あえて自分はコードを書かずにサポートに徹していた部長 syoji がここで満を持して動きます。

しかし詰んだ。

終演

17:00 の競技終了直前、どのチームも作業をしてはベンチマークを繰り返し、計測ホストでは最大4並列でベンチマークが実行され、5分間の平均トラフィックは500Mbpsを超えました。

ここまでトップを争っていたチーム beer は終了直前に FAIL を連発し、焦りを隠せません。対して新卒の ganbaru は最後 16:55 に 22,774 を記録して首位に立ち、そのまま計測終了。

これはまさかの新卒チームの勝利か。入社2週間の新卒に叩きのめされた先輩の威厳はどうなる。

最終計測

競技終了後、最終計測に入ります。

公平を期すため全マシンを一回再起動。運営側がDBを初期データにリセットし、その後各チームが初期化の手作業を行うことはできますが、ベンチマークは実行できません。

そして、競技中のスコアは、最終計測には全く加味されません。

これまでどれだけ FAIL していても、最終計測で成功してスコアを残せばそれが採用。ここまでどれだけ中間スコアが高くても、最終計測で FAIL したら失格、スコアなし。それが ISUCON です。

計測中には、運営側からどんなチューニングをやった？というアンケートなどを行っていました。

結果発表

優勝 team: beer (SCORE 25,133.4)

終了直前にFAIL連発して危ぶまれていた beer でしたが、最終計測を見事にpassして優勝です！

一方、勝利を8割方手中にしたと思われた ganbaru はFAILで失格。2013新卒チームは残念ながら全チームが FAIL でスコアなしという結果に終わりました。

あとから聞くところによると ganbaru はデータリセット後の初期化処理をミスしたそうですが、本番でミスをしないのも仕事をする上での実力のうちですね。

最終結果は以下のようになりました。先輩チームは最終的にはきっちりスコアを出して上位に食い込むあたり、さすがに実戦で鍛えられた力を感じます。

   team     | status  |  score     | members
------------|---------|------------|----------------------------------
beer        | SUCCESS | 25,133.4   | soh335 Konboi
kameda      | SUCCESS | 24,125.33  | handlename kenjiskywalker
fugu        | SUCCESS | 21,768.46  | macopy 9re
syoji       | SUCCESS |  7,623.68  | tkuchiki syoji
ganbaru *   | FAIL    | 19,914.95  | MacoTasu ichinose
ky          | FAIL    |  9,078.29  | tei-you chen-xiao
p_shake *   | FAIL    |  8,806.17  | keishake p_chin
chinatown * | FAIL    |    687.39  | m0t0k1ch1 piyon
gumma *     | FAIL    |    616.7   | gs hosono
* は2013新卒チーム

以下参考記録
------------|---------|------------|----------------------------------
reference   | SUCCESS | 53,977.37  |
acidlemon   | SUCCESS | 24,235.15  |

講評

今回の社内 ISUCON の出題では、最初に提供されるリファレンス実装には意図的にかなり無駄な処理が含まれています。研修の一環ということもあり、特に罠らしい罠は仕掛けていません。初期スコアは200 (1分間のHTTPリクエスト数) 程度ですが、

• DBに適切にindex追加
• サイドバーで100回のループ中に都度発行されるクエリを JOIN に書き換える

だけで 13,000 程度のスコアに到達できるような出題になっています。 つまり、ここまで到達できればほぼ合格点、という水準がスコア 13,000 以上ということになります。

優勝争いはそのあたりを確実にクリアした上で、サイドバーのレンダリングが重いのを部分的に cache するなどの方策を適切に入れることができるか、というのが焦点になったようです。

優勝チームのblogエントリは以下です。おめでとうございます！

• 社内 isucon に参加 - soh335 memo
• 社内ISUCONに参加した。 - Konboi's Memo

(おまけ) 優勝チームの2倍のスコアを出す方法

出題者(fujiwara)はこのアプリを火曜日の夜中に書き、水曜にテストを書き、木曜にベンチマーククライアントを書いて金曜に本戦を行った関係で、どこまでスコアを伸ばせるかを事前に追い込むことができていませんでした。

ベンチマーククライアント側の限界を確認するために、nginx で return 200 するだけのサーバに対して負荷を掛けて、最高100,000程度まで到達できることを確認したのみです。

ということで、競技中に自分もリファレンス実装からどこまでスコアを伸ばせるかチャレンジしていました。

結果、優勝チームの約2倍、53,000のスコアを記録することができましたが、これはベンチマーク計測でどのような整合性チェックをしているか(=どのようにすればチェックをかいくぐれるか) を把握していたからできた手法という感があります。

チェッカーはログインした上で投稿や★をPOSTし、その結果がサイドバーなどに1秒後に反映されているかどうか見てくるのですが、ログインしていないで単に負荷を掛けるだけのクライアントではそのチェックが緩い、という特性を利用します。

具体的には、varnish をフロントに置き、以下のような設定をしました。

• GET 以外は application に pipe (キャッシュしないでそのまま返す)
• Cookieに plack_session=[a-f0-9] が含まれている場合 (ログインしてセッションが維持されている) は application に pipe
• それ以外は静的ファイルまたは application へ lookup (キャッシュする)

しかし、キャッシュ可能な画面でもアプリケーションは Cookie を発行してそれをベンチマーククライアントが維持してしまい、結果 Cookie の有無だけではログイン状態を判別できないという(出題意図にない) 実装が競技中に判明してしまったため、急遽必要ない Set-Cookie ヘッダを削除して Cache 可能にする Plack::Middleware を書くことになりました。

スコアが出せたのは終了13分前。出題者としては優勝チームのスコアに負けるわけにはいかず、相当ギリギリの戦いでした…

ベンチマーククライアントと動かしかたについても公開しています ので参考まで。

まとめ

新卒研修の最後に2013新卒 vs 2012新卒でバトルしたらおもしろいんじゃない？というぐらいのネタで開催することになった社内 ISUCON ですが、参加者の誰に聞いても楽しい(ただしFAILしたチームは悔しい) という、非常に充実したイベントになりました。

普段の仕事ではいろんなしがらみがあって同一条件で競うことはなかなかできないわけですが、そういう事情を一切排除して、公平な条件でガチでぶつかり合うというのはとても楽しいことですね。

みなさんも是非開催してみると想像以上に面白いのでは、と思います。

# ただし、出題者はかなり胃が痛い思いをする可能性がありますのでお気を付けください

これまで弊社技術部では特に技術部としての研修というものを行っていなかったのですが、今年は何かやりたいねということで人事部に7日間確保してもらい、主に acidlemon と2人で新卒8人に研修をすることになりました。

研修の資料などは GitHub でプライベートリポジトリを作って作業しており、それをまとめたものを GitHub上で kayac/newbie-training として公開しています。

どのような内容にするかは事前に昨年度の新卒を含めたエンジニア陣で(社内勉強会でビールを飲みながら)話し合い、

• 現場で実務に追われてしまうと身につきにくい基礎的な内容
• コードを書ける人は多いけどLinuxサーバの操作は不慣れな人が多いので、そのあたりを底上げする内容

をメインに構成してみました。また、7日目の最終日には社内 ISUCON (Webアプリケーション高速化コンテスト) を行い、昨年度の新卒を含む先輩エンジニアとガチで戦うイベントも用意しました。

詳細はリポジトリの方を見ていただくとして、ざっと内容を説明します。

1日目 環境構築・インストール作業

手元のマシンに今後使うであろうソフトウェアの環境を整備してもらいます。Macの人は homebrew などを利用して直接、Windowsの人は VirtualBox で Linux VM を立ててそこにインストールという形を取りました。

社内で boxenのようなものがあればいいのですが、ないので手動で設定してもらいましたがこれで時間を使うのももったいないので何とかしたいところですね。

また、研修中の日報は各自、リポジトリに適当なフォーマット(markdownの人が多数)でcommitしてもらうようにしました。

社内にIRCチャンネルも用意し、GitHubにコミットがあった場合に IRC hook で通知するようにも設定してあります。

2日目 severspecとChefによるサーバ構築実習

1人に1台ずつKVMの仮想マシンを配布し、そのサーバをセットアップする実習です。 最近はサーバの構成管理に Chef を利用しているため、慣れてもらうのも目的です。

serverspec を利用し、事前に作成したテストを通るようにセットアップを行ってもらいます。サーバ構築もテストする時代ですね。

• まず serverspecが通る状態へ手動でセットアップ (メモを取る)
• 通ったらVMをrollbackして初期状態へ戻す
• 今度はChefでレシピを書いてserverspecを通す
• それが通ったらもう一度 rollback
• まっさらな状態から Chef recipe を適用し、テストを通るかどうか確認

3日目 Perl

自社サービスのサーバサイドアプリケーションは Perl がメインのため、最低限 Perl の読み書きができてもらいたいということで Perl に1日あてました。

テキストには、はてなさんが公開されている Perl によるオブジェクト指向プログラミング を利用させていただきました。大変充実したテキストでありがたかったです。

4日目 HTTP・WebApp

Webに携わるエンジニアとして、HTTPはどのようなものなのかを理解することは大変重要です。 ブラウザやWebサーバを単に扱っているだけでは把握しづらい HTTP の生の通信を扱ってもらいます。

• 各自構築したサーバ上で ngrep を使用してパケットキャプチャ
  • HTTPで何が流れているのかを見る
• telnet で手で HTTP を喋って HTTP client になる
• nc -l で手で応答を返す HTTP サーバになる
• PSGI を生で使った Web Application を作る
• それを Amon2::Lite に移植してフレームワークの威力を実感する

5日目 RDBMS・DBを使ったWebApp

データストアとしては最近はいわゆる NoSQL も多いとはいえ、基本的には MySQL を利用しているのでそれの基礎の基礎です。

まず mysql コンソールで操作し、次に Perl + DBI で MySQL を使う演習を行いました。 ここまではセキュリティについて基本的には触れていませんでしたが、外部からの入力を不適切に扱うことでSQL injectionという脆弱性に繋がる話もします。

また、昨日作ってもらった PSGI を直接使う WebApp のコードを見ながら講評をし、実は全員が HTML escape を行わないことによる XSS を作ってしまっていたことにも触れました。

その後、最終日の ISUCON に向けての課題アプリケーション(ログイン機能付きnopaste) の雛形に、実装とテストを追加して仕上げてもらう課題に移ります。

6日目 フレームワークを使ったWebApplicationの作成とテスト

前日に引き続き、Amon2 を使用した nopaste アプリの実装とテスト。

明日の ISUCON にむけて、現在本番で動いているサービスはどのようなサーバ構成になっているのかの講義も行いました。参考 : カヤック流ソーシャルアプリの作り方 インフラ編

7日目 社内ISUCON

いよいよ最終日。

新卒8人を2人ずつで4チーム、先輩エンジニアは技術部長から2012新卒まで10人参加したのでこれも2人ずつで5チーム、計9チームを編成し、昨日までに作成した nopaste アプリケーションを題材にどれだけリクエストを捌けるかのベンチマークで勝敗を競う『社内ISUCON』を開催しました。

ちなみに本家 ISUCON についてはこちらのblogなどをご覧ください

……というところで、次のエントリ「2013年の新卒研修と社内ISUCONやりました - (2) ISUCON死闘編」へ続きます！

もともと私はC++が専門で、SIerの業界にいたのでしかたなくJavaもやっていたという感じだったのですが、Web業界に転職してみたらC++でプログラムを書く人がほぼいなかったということで、今年だけで新規に4言語も手をつけていて環境の激変っぷりに自分でも驚いています。

さて、24日間にわたってお送りしてまいりましたtech.kayac.com Advent Calendar 2012も今日が最終日。2日目にしていきなりJavaScriptでおっぱいが動き始めた時はどうなることかと思いました。しかし、振り返ってみるとDDLをGitで管理したり、Procletで開発中のミドルウェアの立ち上げを超簡単にしたりといった開発を効率よく進めるためのイノベーションや、5年前から続いているWebサービスを時間と技術革新の流れに合わせていったり、ユーザの行動ログを可視化してカスタマーサポートを効率化したりといった、運用を効率よく進めるためのイノベーションなのがありましたね! いやーすごい。

昨日のHokkaido.pmのため22〜24日は北海道に行っていたため遅めのアップロードとなりましたが、最終日のアドベントカレンダーいってみましょうー(よくわからないテンションになっています)。

本題

最初にも書きましたが最近はPerlでサーバを書きつつC#でUnityクライアントの通信部分を書くという二足のわらじ(?)のような生活をしております。

で、Perlは単体テストしやすい言語なので大変感動しているのですが、C#/Unityとなるとなかなか苦痛な感じです。私のプロジェクトにはフロント専門のUnityチームがいるので、私は通信部分とモデル部分のみ書いています。つまり表示部分を全く書かずにロジックだけのコードを書いているため、単体テストを書くのはやはり必須。とりあえず世間的にはUnityの単体テストするならSharpUnitだよねみたいなノリになっているようなのですが、通信部分をテストするにはこれもなかなかつらいものがありました。

というのも、SharpUnitは非同期実行(コルーチン実行)をサポートしておらず、同期実行できるメソッドしかテストできないんです。まぁサーバから来たJSONをパースしてクラスオブジェクトを組み立てるところは同期実行なので別によいんですが、通信が絡む部分はUnityEngine.WWWを使う必要があるためどうしてもコルーチンを実行してyield returnでゆっくり待つ必要が出てきます。

「通信部分なんて単体テストの範疇じゃないじゃん、サーバ側のテストでやれよ」というご意見もごもっともなのですが、だからといってサーバに接続出来ないときのエラー等をテストしないわけにも行かないので、そういうところはクライアント側でちゃんとテストする必要があります。それを自動化したかったわけですね!

SharpUnitを改造したよ

ということで、今回はSharpUnitを改造してコルーチンのテストもできるようにしました。

オリジナルのソースがgithubに上がっているようなのでとりあえずforkして改造したものをgithubにあげています。

大枠の使い方(Unity上での動かしかた)についてはあんまり変わっておりません。以下の記事が大変参考になります。というか私がまず最初に動かして動作チェックをしたときにこれを参考にさせていただきました。ありがとうございます。

• Unity SharpUnitって単体テストツール使ってみた

とりあえずUnity側で必要な作業は、テスト時に動かすシーンに対してTestRunnerというGameObjectを追加して、そこにUnity3D_TestRunner.csとUnity3D_TestSuite.csをアタッチする感じになります。

さてオリジナルのSharpUnitとの差分ですが、具体的には以下のような点を改造しています。

• 従来のTestCaseの使用感は変更せず、それとは別にIEnumeratorを戻り値とする関数をテストできるUnityTestCaseクラスを追加
• TestCaseクラスからITestCaseインタフェースを分離
• TestSuiteクラスを使うのはやめて、Unity3D_TestSuiteクラスを追加。ITestCaseを実装しているTestCaseクラスとUnityTestCaseクラスの両方に対応(ファイルはそのまま残しています)

改造理由についてちょっと触れておくと、TestCaseクラスはコルーチン実行できないテストフレームワークなので、これを元にコルーチンを実行できるUnityTestCaseクラスを作りました。Suite側でTestCaseとUnityTestCaseの両方を同じように扱えるようにするため、UnityTestCase側のインタフェースをITestCaseに分離し、TestCaseをそれに適応するようにTestResultを受け取る部分のインタフェースを変更しています。

これでTestSuiteでTestCaseとUnityTestCaseを同じように扱えるようになったのですが、そもそもTestSuiteからテストケースのコルーチンを実行するにはTestSuite自体がMonoBehaviorを継承してGameObjectとしてシーンにアタッチできるようになっている必要があるため、TestSuiteをベースにUnity3D_TestSuiteクラスを作ってGameObjectとして利用できるようにしています。

C++脳の私はこの辺の再実装は多重継承使ってやればいいじゃーんと思ってたんですが、C#には多重継承の仕組みがなかったのでてっとり速くコピペですませてしまっています。コレ書いててmix-in的なことをやればよかったんじゃねって今思いました。

どんな感じでつかうの?

そもそもSharpUnitを使ったことがある人はこの記事読んでも「へー」くらいで終わるかと思うんですが、Unityで単体テストとかやんねーだろ的な人もいるかと思いますので、具体的な例をこちらに書きます。

たとえば、こんなクラスがあったとしましょう。

class Plan {
    private string _Title;
    private string _Text;
    public string Title { get { return _Title; } }
    public string Text { get { return _Text; } }

    // コンストラクタ
    public Plan(string title, string text) {
        _Title = title;
        _Text = text;
    }
}

このオブジェクトをテストするとなるとこんなコードを書きます。

using SharpUnit;

public class PlanTestCase : TestCase {
    public override void SetUp() {
    }

    public override void TearDown() {
    }

    [UnitTest]
    public void TestConstructor() {
        // ふつうに作る
        Plan val1 = new Plan("Christmas", "Let's play tennis!");

        Assert.Equal(val1.Title, "Christmas", "title ok");
        Assert.Equal(val1.Text, "Let's play tennis!", "text ok");

        // 本文がぬるぽ
        Plan val2 = new Plan("Christmas", null);
        Assert.Equal(val2.Title, "Christmas", "title ok");
        Assert.Null(val2.Text, "text is null ok");
    }
}

ここまでは既存のSharpUnitで可能でした。ここからが問題で、かなり誰得感はありますがPlanをインターネットから取ってきて作るファクトリクラスがあったとしましょう。まーUnityでやる必要性はないですがサンプルなのでそんなもんです。

using UnityEngine;

class InternetPlanFactory {
    private Plan _Plan;
    public Plan Plan { get { return _Plan; } }

    // 特定のURLにアクセスし、1行目をタイトル、2行目をテキストとしてオブジェクトを生成
    public IEnumerator PlanFromUrl(string url) {
        WWW www = new WWW(url);
        yield return www;

        if (www.error) {
            // ノープランだ
            _Plan = null;
        } else {
            // 適当にPlanつくる
            string[] lines = www.text.Split('\n');
            string title = lines[0];
            string text = lines.Length > 1 ? lines[1] : "";

            _Plan = new Plan(title, text);
        }
    }
}

このファクトリクラスをテストするならまぁ大体この2ケースでしょうか(ホントは1行しかなかったときのテストもしたいですね)。

• ふつうにうまくいった
• 接続出来なかったり404とかのエラーが返ってきたりした

が、このファクトリクラスのメソッドはコルーチン実行して結果が帰ってくるのを待たないとちゃんとテストできません。そこで、今回使ったUnityTestCaseを使います。

using SharpUnit;

public class InternetPlanFactoryTestCase : UnityTestCase {
    private InternetPlanFactory factory;
    public override void SetUp() {
        factory = new InternetPlanFactory();
    }

    public override void TearDown() {
        factory = null;
    }

    [UnitTest]
    public IEnumerator TestPlanFromUrlOk() {
        // 普通にうまくいきそうなパターン
        Unity3D_TestSuite runner = GameObject.Find("TestRunner").GetComponent<Unity3D_TestSuite>();
        yield return runner.StartCoroutine(factory.PlanFromUrl("http://www.example.org/example.txt"));

        try {
            Assert.NotNull(factory.Plan, "plan is not null ok");
            Assert.NotNull(factory.Plan.Title, "plan has title ok");
            Assert.NotNull(factory.Plan.Text, "plan has text ok");
        } catch (TestException e) {
            MarkAsFailure(e);
            yield break;
        }

        DoneTesting();
    }

    [UnitTest]
    public IEnumerator TestPlanFromUrlError() {
        // ダメっぽそうなパターン
        Unity3D_TestSuite runner = GameObject.Find("TestRunner").GetComponent<Unity3D_TestSuite>();
        yield return runner.StartCoroutine(factory.PlanFromUrl("http://www.example.org/error.txt"));

        try {
            Assert.Null(factory.Plan, "plan is null ok");
        } catch (TestException e) {
            MarkAsFailure(e);
            yield break;
        }

        DoneTesting();
    }

}

さていくつか普通のTestCaseと違う点が出てきました。1つめはテスト関数の戻り値がIEnumeratorになってることですね。テストを走らせる呼び出し元が yield return StartCoroutine(testMethod); というような感じで呼び出しますのでこれに対応できるようにIEnumeratorにします。これによりテスト関数の中でyield returnを使えるようになるというわけですね。

2つめはAssertをtryで囲んでいることです。普通のTestCaseであればAssertでTestExceptionが飛んだら呼び出し元がcatchしてよしなにエラーレポートしてくれるところなんですが、C#にはtry-catchブロックの中にyield returnを書けないという制限があります。まぁ複雑になるしそれで正解だと思います。が、それによりテストを走らせる呼び出し元でcatchする作戦が使えませんので、テスト関数の中でちゃんとtry-catchして、catchしたらUnityTestCaseが持ってるMarkAsFailure関数でTestExceptionが発生したことをマークしておきます。呼び出し元はyield returnからコルーチンが帰ってきたらTestExceptionがセットされているかをチェックしています。

3つめはStartCoroutineの呼び出し方です。テストはコルーチンとして実行する必要があるのですが、コルーチンとして実行するにもロジックしかないメソッドのためGameObjectがありません。そこで、テストを走らせるためにシーンに追加したGameObjectからUnity3D_TestSuiteクラスのコンポーネントを取得して、こいつをコルーチンランナーとして活用しています。

あとDoneTesting()っていうのを呼んでいるのはPerlでテストを書いている人にはおなじみのdone_testingですね。IEnumeratorな関数である以上適当に途中にyield breakを書いてしまうとそこでテストを中断出来てしまい、テストが全部走らないままパスしたように見えてしまうことがありますので、それの対策にDoneTesting()を呼ばないとFailする機構をいれておいたというところです(まぁあってもなくてもいいとは思いますが、趣味で入れてしまったものです)。

まとめ

かけ足で紹介してきましたUnityでも使えるテストフレームワークSharpUnitの改造版、私はC#歴が浅いため結構これで満足しちゃっているのですが、もし「こうしたらもっと使いやすくなると思う!」などありましたらコメントいただければとおもいます。

それでは皆さん、よいクリスマス、そしてよい新年をお迎えください。カヤック技術部のアドベントカレンダーを購読いただきありがとうございました!

@songmuです。ゲーム作ったりしてると、乱数が必要になってきますがそれについて書きます。

多くの人にとっては当たり前の話も多く出てくるかと思いますがご容赦ください。間違ってる記述があった場合は突っ込みください。

擬似乱数とは何か

計算機は単体では厳密な意味での乱数を生成することができません。実際には一様に分布する乱数の集合を算術的に求めている場合がほとんどです。

その乱数の集合は以下を満たす必要がありますが、そういう小難しいことは偉い人に任せて、巨人の肩に乗って解決してしまえば良いでしょう。

• 偏りがなく一様に分布している
• 途中の出力から未来が予測しづらい
• 高速に算出できるか

つまり？

色々な疑似乱数生成法がありますが、多くの場合、 馬鹿でかい乱数の循環リストがある と考えるとわかりやすいです。

例えばメルセンヌ・ツイスタの場合、2^19937-1という途轍もない長さの周期(乱数列)を持っています。

もちろん、そんな馬鹿でかい配列はメモリ上には持てないので、計算して求める必要があります。

昔のゲームだとメモリやプログラムサイズの制約のため、255くらいの長さの乱数列を決め打ちで持ったり、すごく単純な計算で乱数列を表現していたりするようです。

乱数の初期化

その循環リストのどの位置から数字を取り出し始めるかを決めることが乱数の初期化です。

その初期位置の決定に使う数値をシードと言ったりします。乱数の種ですね。

例えばPerlでは組み込みの乱数の初期化に srand() を使います。以下をターミナルで実行してみてください。

% perl -E 'srand(1);say rand;say rand;'
0.0416303447718782
0.454492444728629

この場合は、1をシードにして乱数を初期化しています。何度実行して同じ結果が返ってくるはずです。

乱数の初期化のジレンマ

じゃあ、この乱数のシードはどうやって決めるんだという話になります。

もちろんシードはランダムに与えたい。ただ、ランダムに与えるには乱数を使う必要がある。鶏と卵みたいな話です。

エポック秒とマイクロ秒とプロセスIDあたりをうまいこと撹拌してそれをシードにするみたいな話もあります。

ただ、それだとエントロピーが少なく初期値があまり分散しない上、予測されやすいという問題も出てきます。

なので、環境が提供している擬似乱数生成器を利用して、それをシードとするのが好ましいです。

Linuxの場合、/dev/randomというものがあります。これはキーボード入力等をもとに作られたエントロピプールから乱数を生成する優れものになっています。

ただ、エントロピプールが空の場合は、乱数を返せず、処理をブロックしてしまいます。 そのへんをうまいことや仕組みとして、/dev/urandomという乱数生成器が準備されています。 そこまでセキュアな要件が必要じゃない場合はこちらを利用すれば十分です。

細かい話はWikipediaの/dev/randomの項でも読んでください。

Perlの組み込み乱数

ちなみにperlの場合、srand()を引数なしで呼び出すと、/dev/urandomからシードを生成してくれます。(/dev/urandomが使える環境の場合)

しかも、randが初回に呼ばれた時に、srandを暗黙的に呼び出して乱数の初期化までやってくれます。すごい！カジュアル！

じゃあ、ここまでの話は必要なかったんやーとかいうと、そういうわけでもありません。

forkの罠

割と注意しなければならないのは、forkした場合に親の乱数シードを使ってしまうという問題です。 以下のような場合です。

#!/usr/bin/env perl
use 5.014;
use warnings;
use utf8;

use Parallel::ForkManager;

rand; # 親プロセスで乱数が呼ばれると同時にシードも決定される

my $pm = Parallel::ForkManager->new(3);
for my $i (1..12) {
    $pm->start and next;

    say "$$ :". rand; # 同じ値が出続ける！！！

    $pm->finish;
}

この場合はちゃんと子プロセス側で、乱数を初期化してやる必要があります。

#!/usr/bin/env perl
use 5.014;
use warnings;
use utf8;

use Parallel::ForkManager;

rand;

my $pm = Parallel::ForkManager->new(3);
for my $i (1..12) {
    $pm->start and next;

    srand; # ちゃんと子プロセスで初期化する！！！
    say "$$ :". rand; # OK

    $pm->finish;
}

forkされる場所に直接手を入れられない場合などのために、POSIX::AtForkを使う手もあります。

#!/usr/bin/env perl
use 5.014;
use warnings;
use utf8;

use POSIX::AtFork;
POSIX::AtFork->add_to_child(sub { srand }); # magic!!!

use Parallel::ForkManager;

rand;

my $pm = Parallel::ForkManager->new(3);
for my $i (1..12) {
    $pm->start and next;

    say "$$ :". rand; # OK

    $pm->finish;
}

シードを固定することのメリット

シードを固定することにはメリットもあります。

規則性があるということは再現性があるということです。

乱数ジェネレータを同じシードで初期化すれば常に同じ結果が出るということです。

以下の例ではMath::Random::MTを使っていますが、常に同じ結果が出るはずです。

#!/usr/bin/env perl
use 5.014;
use warnings;
use utf8;

use Math::Random::MT;
my $rand_gen = Math::Random::MT->new(10); # 10をシードにして初期化

say $rand_gen->rand;
say $rand_gen->rand;
say $rand_gen->rand;

__DATA__
0.771320643136278
0.298761158483103
0.020751946605742

これは何らかのシミュレータを動かす場合には非常に有用です。シードを記録しておけば、何度実行しても同じ結果が得られるからです。

ゲームのリプレイデータファイルなんかにも、その時に使われた乱数のシードが記録されていたりするそうです。

メルセンヌ・ツイスタ

メルセンヌ・ツイスタは、非常に周期が大きく、乱数も均等に分布していて、かつ計算も早いという優れものの擬似乱数アルゴリズムです。そのPerl実装がMath::Random::MTです。

ちょっと複雑な乱数ジェネレータを作りたい場合は、これを使っておけば十分です。

ただ、規則性を持った疑似乱数であることには変わりないので、単体では暗号化技術にはなりませんし、当然のことながら匿名化技術ではありません。

結論

ということでPerlにおける乱数生成のベタープラクティスは以下の様な感じです。

• Math::Random::MTを使う
• シードの生成はsrand()を使う
• forkした場合は、乱数を初期化するのが吉。POSIX::AtFork使うと捗る

CS対応 と 行動ログ閲覧ツール「伊右衛門」

CSとは、カスタマーサポートの事で、
CS対応は、ユーザーさんのお問い合わせの調査の事をここでは指します。

例えば、ソーシャルゲームを運営していると「アイテムを使ってないのになくなっている！」なんてお問い合わせはよくあると思います。
そういう時にアイテムを使ったログが残っていなかったり、検索しにくかったら大変な事になります。

なのでカヤックは、fluentdとMongoDBを使ってユーザーさんの行動ログを保存しています。
その行動ログをブラウザで見えるようにしたのが、伊右衛門です。
→ https://github.com/hisaichi5518/iyemon

この伊右衛門を使えば「そのアイテムはこの時間に使ってます」っていうのがすぐ分かったり、使っていなかった場合はバグだ！というのがすぐ分かって、マジ便利！！！！！！！という事です。

セットアップ & 立ち上げる

Perlを使っています。やっぱりPerlは可愛い。

$ git clone git@github.com:hisaichi5518/iyemon.git
$ cd iyemon
$ cpanm --installdeps .
$ cp common.sample.pl common.pl
$ cat common.pl
{
    'MongoDB::Connection' => {
        host       => 'localhost',
        port       => 27017,
        database   => 'test',
        collection => 'test',
    },
    boostrap => {
        web => ['-p' => 50004],
    },
}
$ vi common.pl # MongoDB::Connectionの設定をよしなに設定する
$ cat common.pl
{
    'MongoDB::Connection' => {
        host       => 'localhost',
        port       => 27018,
        database   => 'test2',
        collection => 'test2',
    },
    boostrap => {
        web => ['-p' => 50004],
    },
}
$ ./boostrap

これでhttp://localhost:50004/にアクセスすれば見えるようになります。

作った時の話

MongoDB

ウッ、MongoDB.pm

# これはちゃんとログが取得できる
my @logs = $mongo->find({uid => 1});
# これだとログが取得できない！！！！１
my @logs = $mongo->find({uid => "1"});

というのがあって、ハゲるかと思いました。
なので頑張っています。

DateTime

DateTime使った事がなかったんですが、MongoDB.pmでは必須だったので使ってます。
今では、ぼくもDateTimeにどっぷり！！！！！！１?(^o^)／

Kossy

元々は違うフレームワークで書いていたんですが、
エエイ！使いにくいわ！書き換えてやる！って事で昨日書き換えました。

Kossyは、 GrowthForecastやHRForecastに使われているフレームワークです。
簡単なアプリを作るのにすごい便利なのでオススメです。

そのKossyに書き換えた事で、導入もしやすくなりました。

まとめ

伊右衛門があるとCS対応が非常に捗るのでオススメ！！！！！！！！！！！！！！！！！
そんなわけで伊右衛門の紹介でした〜

https://github.com/hisaichi5518/iyemon

明日は @songmu さんです！楽しみ！！！１１

みなさん Cocos2d-x で開発してますよね？

当然のことながら Cocos2d-x で開発する際は Lua/JavaScript で開発していますよね？

Q. Lua/JavaScript で開発すると何がうれしいの？

A. スマートフォンの開発サイクルを高速化できます

スマートフォンの開発サイクルって通常以下のフローを回しますよね

1. コーディング
2. ビルド
3. 実機/シミュレータへ転送
4. テスト

このうち、開発の本質でない部分を Lua/JavaScript を使うことでさくっと省くことができます。

Lua/JavaScript を使用した場合のフローは

1. コーディング
2. 実機/シミュレータへ転送（修正したスクリプトのみ）
3. テスト

ビルドがなくなった！！。また、実機/シミュレータへ転送もスクリプトファイルのみになりました。 ゲーム等画像及び音声の多いものを作っている場合は、コード以外のリソースの転送がほとんどなのでスクリプトファイルだけの転送になるのは嬉しいですよね。

Q. じゃあ、どうやるの？

A. Android は SD カードに書き込んで、それを読み出すようにちょっと修正するだけ

---- <PROJECT_ROOT>/Classes/AppDelegate.cpp ----

/* Lua スクリプトの読み込み先を SD カードからに変更する */
#if (CC_TARGET_PLATFORM == CC_PLATFORM_ANDROID)
    const char *pLuaFile = "/mnt/sdcard/genius.lua";    /* 環境に合わせたパスに変更する */
    CCString *pstrFileContent = CCString::createWithContentsOfFile(pLuaFile);
    if (pstrFileContent)
    {
        pEngine->executeString(pstrFileContent->getCString());
    }
#endif

上記のように修正して

$ adb push genius.lua /mnt/sdcard/genius.lua

でスクリプトを更新したら、アプリを再起動するだけ。簡単ですね。 SDカードのパスをちゃんとするなら、jni で以下のようなコードを書きましょう

/* android.os.Environment */
typedef struct {
    jclass klass;
    jmethodID get_external_storage_directory;
} android_os_environment_class;

/* java.io.File */
typedef struct {
    jclass klass;
    jmethodID get_path;
} java_io_file_class;

static void get_sdcard_path(JNIEnv* env, char* dst)
{
    android_os_environment_class environment_class;
    java_io_file_class f_class;
    jobject f;
    jstring j_path;
    const char* n_path;
    environment_class.klass = env->FindClass("android.os.Environment");
    environment_class.get_external_storage_directory
        = env->GetStaticMethodID(environment_class.klass,
                                 "getExternalStorageDirectory",
                                 "()Ljava/io/File;");

    f_class.klass = env->FindClass("java.io.File");
    f_class.get_path = env->GetMethodID(f_class.klass,
                                        "getPath",
                                        "()Ljava/lang/String;");

    f = env->CallStaticObjectMethod(environment_class.klass,
                                    environment_class.get_external_storage_directory);

    j_path = (jstring) env->CallObjectMethod(f, f_class.get_path);
    if(j_path != NULL){
        n_path = env->GetStringUTFChars(j_path, NULL);
        strcpy(dst, n_path);
    }

    env->ReleaseStringUTFChars(j_path, n_path);
    env->DeleteLocalRef(j_path);
    env->DeleteLocalRef(f_class.klass);
    env->DeleteLocalRef(environment_class.klass);
}

Q. じゃあ、SD カードが使えない iOS はどうやるの？

A. iTunes からファイルを転送します

Q. めんどいよ

A. じゃあ、iOS に curl から post して

simple-post-server を使えば curl からファイルを post できます。

iOS のプロジェクトに移動して simple-post-server を追加します。

$ git submodule add git@github.com:KAMEDAkyosuke/simple-post-server.git <PROJECT_NAME>/ios/external/simple-post-server

また、simple-post-server は http-parserに依存しているため、以下を行います

$ cd <PROJECT_NAME>/ios/external/simple-post-server
$ git submodule init
$ git submodule update

xcode の Build Phases の Compile Sources に以下を追加します。

• <PROJECT_NAME>/ios/external/simple-post-server/body-parser.c
• <PROJECT_NAME>/ios/external/simple-post-server/http-parser-helper.c
• <PROJECT_NAME>/ios/external/simple-post-server/intlist.c
• <PROJECT_NAME>/ios/external/simple-post-server/simple-post-server.c
• <PROJECT_NAME>/ios/external/simple-post-server/stringlist.c
• <PROJECT_NAME>/ios/external/simple-post-server/external/http-parser/http_parser.c

サーバの起動と、post されたファイルの保存のコードを書きましょう。

---- <PROJECT_NAME>/ios/AppController.mm ----

/* ポストしたファイルを保存する */
static void simple_post_server_callback(post_content_t* post_content){
    NSArray *documentDirectories = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
    NSString *documentDirectory = [documentDirectories lastObject];

    NSString *path = [documentDirectory stringByAppendingPathComponent:[NSString stringWithFormat:@"%s", post_content->filename]];
    NSData *content = [NSData dataWithBytes:post_content->body
                                     length:strlen(post_content->body)];
    NSFileManager *fileManager = [NSFileManager defaultManager];
    NSError* error = nil;
    if([fileManager fileExistsAtPath:path]){
        [fileManager removeItemAtPath:path error:&error];
        if(error != nil){
            NSLog(@"%@", [error description]);
        }
    }
    [fileManager createFileAtPath:path
                         contents:content
                       attributes:nil];
}

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    /* サーバの起動 */
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0);
    dispatch_async(queue, ^{
        start_server(8080, simple_post_server_callback);
    });
    ...

ファイルの保存はよくあるコード。サーバの起動もわずか 4 行。簡単ですね。

あとは android の場合と同様に読み込む先のスクリプトパスを変更すればいいだけ。

ファイルの転送を便利にするために以下のようなスクリプトを書くといいですね。

---- post_all.sh ----
#!/bin/sh

HOST=$1

for filepath in *.lua; do
    HOGE="curl -F file=@$filepath http://$HOST:8080"
    echo $HOGE
    $HOGE
done

スクリプトの編集が終わったら以下のコマンドで一気に転送しましょう

$ ./post_all.sh <your_ios_ip_address>

Q. iOSでスクリプト簡単に転送できるようになったけど、エラーログってどうやってみるの？

A. /libs/cocos2dx/platform/ios/CCCommon.mm を書き換えましょう

具体的には以下のようにログ出力に NSLog を使用するようにしましょう。

void CCLog(const char * pszFormat, ...)
{
    char szBuf[kMaxLogLen];

    va_list ap;
    va_start(ap, pszFormat);
    vsnprintf(szBuf, kMaxLogLen, pszFormat, ap);
    va_end(ap);
    NSLog(@"%s", szBuf);
}

xcode につながなくても iPhone構成ユーティリティ 使えば見られるのはご存知ですよね。

Q. パフォーマンスは？

A. 弊社のアプリを手元で適当に移植した際は問題なし

いざとなったら C/C++ で書けばいいし。

まとめると

• Cocos2d-x で C++ だけで書いているのはもったいないよ。
• Android は SD カードで簡単にスクリプトだけの更新ができるよ。
• iOS は面倒だから curl からの post を受け取れるサーバを書いたよ。みんな使ってね。
• パフォーマンス困ったら C/C++ で書けばいいから心配しなくてもいいんじゃない？

明日はマヤ暦によると人類滅亡の日です。 人類滅亡が先か@hisaichi5518さんの記事が公開されるのが先か楽しみですね。

そんな独自サービス／アプリを、もっと多くの人に使ってもらえるきっかけとなる（かもしれない） UIActivity という iOS 6 の新機能について書かせていただきます。

あ、申し遅れました、入社３年目にして初めて投稿する、ツツミ（@shu223）と申します。ひたすらiOSアプリをつくり続けております。

UIActivityとは？

iOS 6 から入った、こんなやつです。

FacebookやTwitterに投稿したり、テキストをメールで送信したり、写真アプリに画像を保存したりと、とにかくアプリやサービス連携の総合受付みたいなUIです。

実装は超カンタン

この UI、UIActivityController というクラスを使って実装するのですが、超カンタンです。

- (IBAction)pressBtn {
    UIActivityViewController *activityView = [[UIActivityViewController alloc] initWithActivityItems:@[@"投稿するテキスト"]
                                                                               applicationActivities:@[]];    
    [self presentViewController:activityView animated:YES completion:nil];
}

こんな感じで、なんとたったの２行で UIActivityController を表示できてしまいます。

「Twitter投稿の実装が簡単になった！」と iOS 5 時代に大歓迎された TWTweetComposeViewController とそんなに実装量が変わらないので、私はここ最近はほぼ確実に UIActivity を入れています。

拡張もカンタン

そんな便利な UIActivity ですが、さらに便利なことに、カスタムUIActivityをつくって UIActivityViewController に追加することができるのです。

たとえば、ARChromeActivity という OSS を使うと、UIActivityViewController に Chromeアプリで URL を開くためのアイコンが追加されます。

で、このカスタムUIActivityの追加がまたラクなのです。

たとえば ARChromeActivity を追加したい場合に、上述したコードに追加するコードは1行だけ。

ARChromeActivity *chromeActivity = [[ARChromeActivity alloc] init];

これを、UIActivityController を初期化する際の applicationActivities 引数に渡してやると、

UIActivityViewController *activityView = [[UIActivityViewController alloc] initWithActivityItems:activityItems
                                                                           applicationActivities:@[chromeActivity]];

これだけの変更で Chrome アプリとの連携機能が実現するという優れものです。

カスタムUIActivityのつくりかた

やっと本題です。

このカスタムUIActivityをつくるのもけっこう簡単なので、独自サービス／アプリをお持ちの方は、マイUIAcitvityをつくって Github などで公開しておけば、他の開発者が自分のアプリのUIActivityControllerに組み込んでくれるかもしれません。

つまり、カスタムUIActivityを公開しておくことで、連携アプリが増え、独自サービス／アプリのアクティブ率向上につながる可能性があります。

というわけで、弊社のグループチャットサービス『ナカマップ』のUIActivityをつくってみたので、その際の実装手順を紹介させていただきます。

リポジトリはこちら。（デモアプリつき）
SHNakamapActivity

チャット投稿用のカスタムURL Schemeを1つたたくだけの、最小構成です。

1. アイコンを用意する

周囲を透過にする必要があります。透過にしないとどうなるか、どんな画像を用意すればよいかは、こちらの記事が画像付きでわかりやすいです。

今回は、僕の拙いFireworksスキルで無理やり透過にしたので、こんなのが入っています。

緑っぽい色がついてる部分も、iOS側で UIActivity っぽく処理されます。

ちなみにサイズは

• 43x43
• 86x86
• 55x55
• 110x110

の4種類入れてあります。

2. UIActivity を継承したクラスを新規作成

UIActivity を継承したクラスを新規作成します。今回はヘッダファイルは新規作成時のままとくにいじりません。

3. UIActivityのメソッドをオーバーライド

下記を参考に、サービス／アプリに合わせてよしなにオーバーライドしてください。

- (NSString *)activityType {
    return @"com.kayac.nakamap";
}

- (UIImage *)activityImage {
    return [UIImage imageNamed:@"NakamapActivityIcon.png"];
}

- (NSString *)activityTitle {
    return @"Nakamap";
}

- (BOOL)canPerformWithActivityItems:(NSArray *)activityItems {
    for (id activityItem in activityItems) {
        if ([activityItem isKindOfClass:[NSString class]]) {
            return YES;
        }
    }
    return NO;
}

- (void)prepareWithActivityItems:(NSArray *)activityItems {
    for (id activityItem in activityItems) {
        if ([self openNakamapWithItem:activityItem]) {
            break;
        }
    }
}

4. 連携処理を実装

サービス／アプリとの連携処理を実装します。サービスならAPI、アプリならURL Schemeを呼びます。（アプリ内のフレームワークとかを呼び出すUIActivityもあります）

SHNakamapActivity では、prepareWithActivityItems: で呼んでいる openNakamapWithItem: のところで、ナカマップのチャット用 URL Schemeをたたいています。

- (BOOL)openNakamapWithItem:(id)item {
    NSURL *url = [NSURL URLWithString:@"nakamap://chat"];
    NSString *urlStrWithItem = [NSString stringWithFormat:@"nakamap://chat?message=%@", item];
    NSURL *urlWithItem = [NSURL URLWithString:urlStrWithItem];
    [[UIApplication sharedApplication] openURL:urlWithItem];
    return YES;
}

（上記コードは簡単化のため各種チェック処理は省いています）

できあがり！

呼び出し側はこんな感じで、

SHNakamapActivity *nakamapActivity = [[SHNakamapActivity alloc] init];
UIActivityViewController *activityView = [[UIActivityViewController alloc] initWithActivityItems:@[@"投稿テキスト"]
                                                                           applicationActivities:@[nakamapActivity]];
[self presentViewController:activityView animated:YES completion:nil];

これでナカマップ連携機能がUIActivityControllerに追加されました！

アイコンタップでナカマップアプリが起動し、グループのチャット画面へ移動すると、チャット入力欄に投稿テキストが自動入力されます。（ナカマップが未インストールの場合はAppStoreを開きます）

カスタムUIActivityをまとめたリポジトリ

Dropbox、Instagram、LINEといった著名サービスの UIActivity は、すでにちらほら Github で公開されはじめているので、それらを集めたリポジトリをつくりました。詳細は下記記事をご覧ください。

たった1行でWebサービスと連携！UIActivity のまとめリポジトリをつくりました

その他のiOS6の機能

iOS 6 には UIActivity 以外にもイノベーティブな新機能がたくさんあります。そんな iOS6新機能のサンプルコード／ライブラリをまとめた記事がこちら。

iOS 6 新機能のサンプルコード／ライブラリのまとめ22個

まとめ

個人ブログの宣伝などを交えつつ、カスタム UIActivity の実装方法についてご紹介させていただきました！

明日は@Gemmbuさんの記事です。お楽しみに！

このエントリーは tech.kayac.com Advent Calendar 2012 の18日目の記事になります。

今年の12月で5周年を迎えた某サービスの運用開発をしています。自分が関わり始めてからは4年ほどです。 その間にサービスの成長に伴い溜まった負債を減らす方法をいくつか紹介したいと思います。 （テーマは「2012年のマイイノベーション」ですが特に気にせず書かせて頂きます）

カプセル化

リリース時にコントローラにベタ書きしてしまったコード、開発速度や納期を優先するとよくあります。 このままでは単体テストも書きにくく、品質や機能拡張の障害にもなります。こんな時にはカプセル化をしましょう。

ベタ書きしたビジネスロジックを上図のようなModelクラスを新たにつくって、移し閉じ込めてしまいまいます。 これでコードの見通しも良くなり、単体テストもしやすくなりました。 別のアプリケーション(スマホ/ガラケー)からも重複している処理を呼び出せるようになります。負債の一本化ですね。

並行稼動

長期運用をしていくと当初用意したしたサーバーリソースでは足りなくなってくることがあります。

たとえばWebアプリケーションがJobQueue経由でWrokerに画像ファイル等を保存させるような場合

• 保存先のストレージが容量不足になりそう
• 潤沢な 新ストレージに移行させたい
• サービスは止めたくない

といったことが起きてきます。 そのような時には新ストレージに保存するNew Workerを用意し並行稼動させます。

並行稼動している間に旧ストレージから新ストレージにデータを移していきましょう。 データの移行が完了したら、プロキシサーバーからの参照先を新ストレージに切り替えます。 完全移行後も旧システムを暫く動かし、切り戻し出来るようにしておくと安心ですね。 ファイルベースの管理からS3やKVSなどに移行させる時などにも有効です。これで返済期限が伸びました。

疎結合

単体のアプリケーションに入れていた仕組みを外部に出すことで依存関係を整理し、保守性を高めることができます。

IPアドレスを利用してSPAM対策を行う例になります。

Webアプリケーションから外部のSPAM IP リスト(API)に直接アクセスしチェックを行うようにしていました。 チェックしたIPはKVSに一時保存し次回からはKVSを参照するような仕組みになっています。 ただ問題がないわけではなく

• IP をチェックする箇所がサービス上に複数ある
• SPAMerはIPや手法を頻繁に変えてくる
• 外部のSPAM IP リスト(API)とは非同期に連携したい

といったことがあります。SPAM IP を管理する仕組みはWebアプリケーションから切り離したほうが良さそうです。

そこでシステム構成を以下のように変更しました。

外部のSPAM IP リストとの連携やSPAM IPを判定するロジックをWebアプリケーションから切り離し、新たにSPAM IP Serverを立てて移しています。 今後はSPAM IP Serverを保守していけば良いので、Webアプリケーションの肥大化を防ぐことにもつながります。他のサービスやアプリケーションとも連携を取りやすくなり、効率的にSPAM対策が行えるようになりそうです。

SPAM IP ServerはMemcached-Serverを使ってつくりました。 お手軽にmemcachedプロトコルのサーバーをつくることができ、WebアプリケーションからのIPチェックもgetでチェックするようにしています。面倒な仕事は外部に投げてスッキリ！

名前

コードの混乱により、上であげたような大鉈を振るうことができない場合には メソッド名やマジックナンバーを見直すだけでも十分効果があります。

sub dec24 {
    my $self = shift;
    return 'メリークリスマス';
}

dec24だと流石にわかりにくいので（自分にはわからないので）

sub merry_xmas {
    my $self = shift;
    $self->dec24()
}

としてmerry_xmasでも呼べるようにしましょう。 （人によってはtsuraiの方が分かりやすいかもしれません）

ハードコードしてしまったマジックナンバーも

 use constant {
     XMAS_EVE => 24,
     XMAS => 25,
 };
:
if ( $day == XMAS_EVE || $day == XMAS ) {
    return '定時で帰って酒飲むぞ！！';
}

としておくだけで分かりやすくなります。窓口がカワイイ子に代わるだけで、解決したりするものです。

まとめ

開発から運用フェーズとなると、モチベーションの維持が難しくなる時もあるかと思います。

先に伸ばしがちな仕事は、午前中の意思が枯渇していない時間にやったり（意思は消耗品） 新しい技術は管理画面や直接サービスと関係ない箇所に投入して様子をみるなどして 触れておくと良いかもしれませんね。

借金（負債）を減らして気持よく新年を迎えたいものです。

明日は、@shu223さんの記事です、お楽しみに！

このエントリは tech.kayac.com Advent Calendar 2012 の17日目の記事です。

この2012年は、卒業制作関係でIllustratorを使ったり、企画をひたすら考えたりと多様多種に渡る仕事をした年だったなと思います。

今年のAdvent Calenderのテーマが「私の中のマイイノベーション」ということで、今年、今更ながら知ったGCDについてご紹介したいと思います。

GCD

GCDとは正式名称が grand central dispatchというものでiOS4から導入されたマルチスレッドプログラミングを実現するための技術です。

このGCDが導入される以前からiOSではperformSelectorやNSThreadなどのマルチスレッドプログラミングの方法がもちろんありました。しかし、これらの方法を実現するには少し煩わしいと感じるようなコードを書かなければいけませんでした。

ですが、GCDでは次のコードだけでマルチスレッドプログラミングを実現できます。

dispatch_queue_t mainDispatchQueue = dispatch_get_main_queue();
dispatch_queue_t globalDispatchQueueDefault
  = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_async(globalDispatchQueueDefault, ^{
    //ここで長時間かかる処理・重い処理を記述

    dispatch_async(mainDispatchQueue, ^{
     //メインスレッドで実行させる処理

    });
});

このコードについて簡単に説明すると

dispatch_async(globalDispatchQueueDefault, ^{

このコードでバックグラウンドスレッドに処理を走らせて

dispatch_async(mainDispatchQueue, ^{

このコードでメインスレッドに処理を走らせています。

すごく簡単ですね！

このGCDを利用することでマルチスレッドを誰もが簡単に実装できるようになりました！

GCDを利用するシチューエーションはいくつも考えられますが

私の場合はバックグラウンドでサーバとの通信をし、メインスレッドでローディングを表示させる時などに使用しています。

↑みたいな感じですね。

iOS4で導入されたこの技術をiOS6がでた今更になって騒ぎ始めてしまいましたが、なんだかんだ今年の私にとってイノベーティブな技術でした！

おまけ

私は卒業研究を２つしていてそのうちの１つで、仲間と共にmeglueという旅の思い出共有サービスを制作していました。 iPhone・Android共に2013/01/25に同時リリースですので、是非ダウンロードよろしくお願いします！

明日は

明日は@takihitoさんです！お楽しみに！

振り返ってみると今年もいろいろイノベーティブな出来事があったので思い出せる範囲でまとめてみようかとおもいます。

GNU screen から tmux に移行した

screenとくらべるとtmuxはなかなかベンリでイノベってますね。

• tmux + irssi + canything で Anything 風チャンネル切り替えする
• tmux で pbcopy

みたい記事を書いてたみたいです。意外ととあんまり書いてなかったですね！

mosh を使い始めた

ssh のかわりにいくつかの環境で mosh を利用し始めました。

僕は MacBook Air 一つでいろいろなところで作業をするのですが、ssh だと移動するたびに接続し直しになって面倒だし、 とくに移動中に作業したりする時には、電波が弱い場所やトンネルなどで圏外になるたびに再接続をする必要があり、非常にストレスがたまります。

その点 mosh ではどこに移動してもつなぎっぱなし（のように見える）で、シームレスに作業の続きができるため非常に捗ります。

mosh にかんしては社内でベンリーベンリー騒いでたくらいでとくに記事を書いてはなかったようです。

Redis を使い始めた

Redis というKVSをつかいはじめました。

単純なKVSとしてももちろんつかえるのですが、いろいろなデータ構造をオンメモリで高速にあつかえるため、 向いている作業をまかせると既存のアプリケーションを非常に高速化できたりします。

ISUCONで優勝してきたりもしました。

• Redis布教活動報告 ISUCON 編

また、いろいろなデータ型があってそれに対応するコマンドも多くあるので、 単純に使うとしてもどの使い方が効率的なのか？ ということを考えるのがパズル的で楽しいところも Redis をつかっていて楽しいところですね。

GitDDL まじイノベーティブ

git をつかった開発では各人がカジュアルに作業ブランチをきって作業するため、 それぞれがそこでデータベース定義を変更したりするとたいへんつらいことになってしまいます。

そこで、データベーススキーマ自体もgitで管理しちゃえばいいんじゃないの？ ってなことでうまれたモジュールが GitDDL です。

これを使用すると branch を切り替えた際に、もしテータベース定義が変更されていると差分を git をもとにつくって、よしなに ALTER 文を発行してくれるものです。 これは本当にイノベーティブなのですが、説明するのが非常に面倒なので隣の席の人のエントリを参照ください。

• GitDDLまじイノベーティブ

まとめ

他にもあった気がしますがとりあえず今思い出せるのはこんな感じですね。

どれもいまとなってはかかせないツールですね。 さわったことないなーってものがありましたらぜひお試しくださいませ！

明日はフードファイターマコピー氏です。

このエントリはtech.kayac.com Advent Calendar 2012 12日目の記事になります．

テーマは「私の中のマイイノベーション２０１２」ということで、 今年を色々振り返ってみってみて、かなり地味な内容になりますが、一番効果が高かったなーと感じる「チームでgitを使い始めたこと」をお話したいと思います。

使い始めるまで

今まで自分が関わっていたプロジェクトは（小学生と言われるの覚悟で）subersionを使うのが一般的で、 gitの恩恵にあやかりたいプログラマは"git-svn"を使っていました。

ただ、次のような問題点がありました。

• projectが巨大になるとgit svnが重すぎてツライ
• svn switchが満足に扱えるいいGUIアプリがないため、プログラマー以外branchの切り替えができず、他職種は都度checkoutを強いられてツライ
• @typesterにdisられてチームのモチベがダウンしてツライ

そこで、gitを本格的にチームで運用することを決定しました。

結果的に見て一番大変だったのは「他職種の制作陣の開発環境にgitの環境を整える」ことでした。制作陣の各環境にgitの環境を整えるのですが、ターミナルもあまり触ったことがないという人がほとんどなので、鍵の生成から、gitのツールの利用方法までをレクチャーしました。

なかには（さっき鍵作ったばかりなのに）「パスフレーズ忘れちゃったんですけど」みたいなことを言われちゃったりもしますが、そこを笑って許してあげる度量が必要です（自分にはその度量はありませんでした）。

gitのbranchの切り替えやpull, push, commitの理解などは最近は下記のとてもわかりやすいスライドもあったりして、自分の想定よりもスムーズに導入できたなと感じております。

こわくないgit

利用しているツール

SourceTree

基本的にプログラマー陣はコマンドラインのgitを使っていますが、それ以外の職種はほぼSourceTreeを使っています。

gitの導入を決めたのも、このツールの完成度が高く、しかも無料（ユーザ登録は必要）で使えたためと言っても過言ではありません。 Macのsubersionクライアントにありがちなsvn switchできなかったり挙動が不安定だったりということもありません。

tig

ターミナル上でもうちょっとカジュアルにgitのlogやdiffを確認したいというときはtigを使っています。

デプロイ用のサーバにもインストールしておくと現在本番反映されている内容が瞬時に確認できるので重宝してます。

コンソールから使える git ブラウザ、tig が超便利

IRCとの連携

弊社では一昨年くらいからIRC熱が徐々に高まって、IRCでの情報共有を活発化しようという動きがあります。

現在のプロジェクトでは主だったところでは下記の2つをIRCで共有してます。

• gitへのpush
• 本番環境へのデプロイ

基本的にはどちらも弊社で運用しているircに投稿するnopasteへそれぞれPOSTしてるというシンプルなものです。IRCを利用していなくてもメールなどでこのような情報が流れると情報共有がスムーズにできて素晴らしいですね。

gitへのpushはgitのpost-receiveで下記のスクリプトを実行するようにしてます。

#!/bin/sh

export LANG=ja_JP.UTF-8

# IRC channnel
CHANNEL="#channel"

read IN

OLD=`echo ${IN} | cut -d ' ' -f 1`
NEW=`echo ${IN} | cut -d ' ' -f 2`
REF=`echo ${IN} | cut -d ' ' -f 3`

git rev-list $NEW ^$OLD --reverse | while read COMMITID
do
    MSG=`git --no-pager log -1 --format='%an committed "%s"' $COMMITID`
    DIFF=`git show $COMMITID`

    curl --data-urlencode "summary=${MSG}:${REF}" --data-urlencode "text=${DIFF}" --data-urlencode "channel=${CHANNEL}" --data "notice=1" http://xxxx.kayac.com/nopaste
done

出力例

commit 85b8dcd18c703f156a7408dd17e23529e52189aa
Author: dummy user %lt;dummy-user@kayac.com%gt;
Date:   Wed Dec 12 10:17:57 2012 +0900

    count access num of quiz link

diff --git a/root/tmpl/common/footer.mt b/root/tmpl/common/footer.mt
index 5bff66d..691be9e 100644
--- a/root/tmpl/common/footer.mt
+++ b/root/tmpl/common/footer.mt
@@ -18,7 +18,7 @@
 %lt;nav id="js-embed-content"%gt;
     %lt;!--%lt;h1 class="name"%gt;MENU%lt;/h1%gt;--%gt;
 ? if (models('Schema::Event')-%gt;current) {
-    %lt;div class="specialBnr"%gt;%lt;a href="%lt;?= link_for('/special_practice_event') ?%gt;" onclick="javascript:_gaq.push(['_trackPageview', '/special_practice_event']);"%gt;VS戸成高校%lt;/a%gt;%lt;/div%gt;
+    %lt;div class="specialBnr"%gt;%lt;a href="%lt;?= link_for('/special_practice_event') ?%gt;" onclick="javascript:_gaq.push(['_trackPageview', '/event_banner_cnt']);"%gt;VS戸成高校%lt;/a%gt;%lt;/div%gt;
 ? }
     %lt;ul class="menu"%gt;
         %lt;li%gt;%lt;a href="%lt;?= link_for('/shop') ?%gt;"%gt;購買部%lt;/a%gt;%lt;/li%gt;

本番環境へのデプロイ時にはデプロイスクリプトの最後尾で下記のスクリプトを実行するようにしてます。

#!/usr/bin/env perl

use 5.12.0;

use strict;
use warnings;
use utf8;

use FindBin::libs;

use Try::Tiny;
use LWP::UserAgent;
use Getopt::Long qw/GetOptions/;

use DateTime;
use Git::Repository;
use Path::Class qw(dir);

GetOptions(\%ARGV, qw/
  dry-run
/);

my $now  = DateTime->now(time_zone => 'Asia/Tokyo');
my $home = dir('/home/app/sites');
chdir $home;

my $history_file = $home->subdir(qw/data/)->file('deploy_history.txt');
unless (-e $history_file->stringify) {
    $history_file->touch;
}
my $deploy_history    = $history_file->slurp;
my @deploy_histories  = split /\n/, $deploy_history;

my $warning_comment   = shift @deploy_histories;
my $last_deploy       = $deploy_histories[0];

my ($date, $last_rev) = split /\s+/, $last_deploy;

my $git_repo  = Git::Repository->new(work_tree => $home);
my $rev       = $git_repo->run('log', '--pretty=format:"%h"', '-1');
$rev =~ s/\"//g;

my $diff_stat = "";
if ($last_rev) {
    $diff_stat = $git_repo->run('log', "$last_rev..$rev", "--stat");
}

if (!$ARGV{'dry-run'}) {
    say 'post np.';

    my $ua = LWP::UserAgent->new(agent => 'deployhook');
    my $np_url = 'https://xxxxx.kayac.com/np';
    my $res = $ua->post($np_url, [
        channel => '#dummy-chann',
        summary => "deploy rev $rev",
        text    => $diff_stat,
    ]);
    die $res->content unless $res->code == 302;
}
else {
    say $diff_stat;
}


if (!$ARGV{'dry-run'}) {
    say 'update deploy_history';
    my $next_history = "$now $rev";
    my $fh = $history_file->openw;
    $fh->print(join "\n", ($warning_comment, $next_history, @deploy_histories));
}


say 'done';

出力例

commit 42189e4dfff430efa9afe7e7c52a1a888d6c815e
Author: xxxxxx 
Date:   Wed Dec 12 10:35:10 2012 +0900

    change method of get link click count

 root/tmpl/default/member_top.mt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit 85b8dcd18c703f156a7408dd17e23529e52189aa
Author: xxxxx 
Date:   Wed Dec 12 10:17:57 2012 +0900

    count access num of quiz link

 root/tmpl/common/footer.mt      |    2 +-
 root/tmpl/default/member_top.mt |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

最後に

gitに移行してみて感じたのは、一番大きいのはbranchの切り替えがスムーズになったことにより、 プログラマの効率ももとより、他職種とのやり取りの効率も上がったことですね。 「このbranchにあれをコミットしておいて」みたいなやり取りが以前よりも円滑できるようになりました。

苦労に対して得るものは大きかったので臆せずやるべきだったと感じてます。

とはいえSourceTreeなくしてここまでうまくいかなかっただろうなーということで、 結局一番伝えたいことはSourceTree++ってことです。

明日は若手バリスタのホープ@Keita_Shiyaのお話です。お楽しみに！