このブログをオレオレDocker基盤「Pocker」に載せ替えました 2014-10-22 15:25

近年はtutumとかDigitalOceanとか組み合わせてオシャレにDocker〜, という風潮になりつつありますが, そこに敢えて(?)逆らって(?), VPS上でDockerのコンテナをよしなに立ち上げられるようにする「Pocker」というプロダクトを作りました.

...ので, このブログをPocker上に載せ替えました. 近日中に, スライド公開基盤「Symphogear」とか, 「突然の死API」とかも, 適宜Pocker上に載せ替えていく予定です.

前の環境では, わざわざRijiのサーバを立ち上げて配信していたブログを, Pockerに載せ替えるついでに静的ファイルで配信するように変更したのですが, その結果, なんかこの記事とかこの記事とか, あとこの記事とかの静的ファイルが出力されなかったりしてちょっと焦りましたが, なんとかなったので無事移行完了, 普通に見れるようになっている... のではないでしょうか.

Pockerについては, 今週末に開催の「PerlCasual #6」のLTで紹介する予定ですので, お楽しみにして頂ければ幸いです. ちなみにLTのオチについては, 「大多数の人はこういう目的であればKayacさんのmirageを使っておけば良いと思います!」になる見込みです!


WerckerでPerlのWebアプリのテストをする 〜テスト実施編〜 2014-10-06 13:40

というわけで, 前回の記事ではWerckerでテストをする上で必要となってくる, Wercker用のBoxを作る方法について解説しました. 今回は, 実際にそのBoxを使って, Amon2で書かれているWebアプリをテストするまでの手順を紹介したいと思います.

設定ファイル

まず, Wercker向けの設定ファイルを用意します. 設定ファイルは, テストを実行したいリポジトリのルートディレクトリに, wercker.ymlという名前で設定します. この辺りは, Travis CIと似ていますね.

box: papix/perl5.18@0.0.1
services:
    - wercker/mysql
    - wercker/redis
build:
    steps:
        - script:
            name: Restore cache
            code: |
                sh .wercker/restore_cache.sh
        - script:
            name: Install modules
            code: |
                cd app
                carton install --deployment
        - script:
            name: Store cache
            code: |
                sh .wercker/store_cache.sh
        - script:
            name: Run test
            code: |
                cd app
                rm .proverc
                PLACK_ENV=wercker carton exec -- prove -r t
    after-steps:
        - hipchat-notify:
            token: $HIPCHAT_TOKEN
            room-id: XXXXXX
            from-name: 'Wercker Bot'

boxは, お察しの通り前回作成したような, Wercker用のBoxの名前を指定する部分です. ここには, 自分で作ったBoxだけでなく, 他人が作ったBoxも指定することができます(Boxの検索はこちらのページで出来ます).

次のservicesですが, Box内で利用するミドルウェアを指定します. 現在利用出来るミドルウェアの一覧はこちらにある通りで, MySQL, PostgreSQL, MongoDB, RabbitMQ, Redisが使えます.

Werckerのクセというか, WebアプリのテストをWerckerで実行しようと思った時に詰まるのがこのミドルウェア周りで, Werckerではこのservicesで指定したミドルウェアしか利用することが出来ません. つまり, テストの中でTest::mysqldやTest::Redisを利用して, テスト用のMySQLやRedisを立ち上げることができないのです.

このWebサービスでは, テスト時のMySQLはApp::Prove::Plugin::MySQLPoolを使って立ち上げていたのですが, これが内部でTest::mysqldを使っているので, そのままWerckerで動かせませんでした. そのため, 後述しますがWercker向けの設定ファイルを用意して, Werckerが用意する1つのMySQLサーバを使ってテストを実行するようにしています.

buildでは, 実際のテストの流れを書いています. ここで重要なのは, 「Restore cache」と「Store cache」の部分です.

今回のテスト対象はWebアプリなので, かなりの量のCPANモジュールに依存しています. これを毎回インストールしてからテストを実行していると, テストの実行時間よりもモジュールのインストールにかかる時間の方が長い, という状況に陥ってしまいます.

そこで, このWebアプリのテストでは, Werckerのキャッシュ機能を利用することで, モジュールのインストールにかかる時間を削減しています(キャッシュ機能については, こちらのページの「Using wercker cache」の辺りに書かれています). キャッシュ機能を使うことで, 環境変数$WERCKER_CACHE_DIR(通常は, /cacheのようです)で指定されたディレクトリに設定されたファイルを一定期間の間保存し, 再度テストを実行した際に使いまわす事が出来るようにしています. 今回の場合, carton install --deploymentを実行した際に生成される, localディレクトリをキャッシュしてやれば良いでしょう.

まず, localディレクトリをキャッシュする為のstore.shの中身を見てみます.

if [ -d "$WERCKER_CACHE_DIR/local" ] ;
then
    rm -rf $WERCKER_CACHE_DIR/local
fi
sudo cp -r local $WERCKER_CACHE_DIR/local

キャッシュディレクトリにlocalがあれば, 一旦それを削除してからcarton install --deploymentで生成されるlocalディレクトリをコピーしています.

次のテストでは, このキャッシュしたlocalを利用してテストを実行します. これを復元するスクリプト, .wercker/restore.shの中身は次の通りです.

if [ -d "$WERCKER_CACHE_DIR/local" ] ;
then
    echo "Found in cache"
    sudo -u $USER cp -r $WERCKER_CACHE_DIR/local local
else
    echo "Cache not found"
fi

$WERCKER_CACHE_DIRlocalディレクトリがあれば, それをリポジトリのルートディレクトリのlocalに移動しています. こうすることにより, 前回のテスト時のcarton install --deploymentで生成されたlocalディレクトリを, 別のテスト間で使いまわしています.

テスト結果の通知

stepsで指定したフローが全て成功すればテストは成功, 1つでも失敗すればテストは失敗として扱われます. 通常, これらの結果はWerckerのWebサイト上で確認することができますが, WerckerのHipChat通知機能を使うことによってHipChatにテスト結果を通知することが出来ます.

    after-steps:
        - hipchat-notify:
            token: $HIPCHAT_TOKEN
            room-id: XXXXXX
            from-name: 'Wercker Bot'

テスト結果のHipChat通知は, after-stepshipchat-notifyを設定することによって可能になります. tokenにHipChatのAPI Auth Tokenを, room-idに通知を送る部屋を, そしてfrom-nameに通知時に使う名前を指定します. token$HIPCHAT_TOKENになっていますが, これはwercker.ymlに直接トークンを記述するのではなく, Werckerの環境変数を使って設定している為です.

環境変数の設定

Werckerの環境変数は, 次のようにして設定することができます.

環境変数を設定したいアプリケーションのトップページから, 「Settings」タブを選び, 「Pipeline」の「Add new variable」をクリックすれば設定することができます. 「name」に環境変数の名前を(今回の場合, 「HIPCHAT_TOKEN」), 「value」の中に環境変数の中身を(今回の場合, HipChatのAPI Token)入力すればOKです. 最後に「Save」をクリックすれば, それ以降のテストで環境変数を利用できるようになるはずです.

今回のような, あまり一般的に見られたくない中身が格納された環境変数は, 「Protected」のチェックを入れておけば, より安心でしょう.

Webアプリの設定ファイル

先述した通り, WerckerではMySQLやRedisなどのミドルウェアは, Wercker側が最初に立ち上げたものしか起動することができません. そこで, 今回はWercker用の設定ファイルwercker.plを用意し, テスト実行時にPLACK_ENV=wercker carton exec -- prove -r tのような形で指定することによって, Werckerが立ち上げたMySQLやRedisを利用するように設定しています.

+{
    dbi => [
        "dbi:mysql:database=$ENV{WERCKER_MYSQL_DATABASE};host=$ENV{WERCKER_MYSQL_HOST};port=$ENV{WERCKER_MYSQL_PORT}", $ENV{WERCKER_MYSQL_USERNAME}, $ENV{WERCKER_MYSQL_PASSWORD},
        {
            mysql_enable_utf8 => 1,
        },
    ],
    redis => $ENV{WERCKER_REDIS_URL},
};

WERCKER_MYSQL_DATABASEなどの環境変数には, Wercker側が用意したMySQLやRedisに接続する為のパラメータが格納されているので, これを利用して接続します. どのような環境変数が提供されているかについては, 先ほど紹介したWerckerで利用できるミドルウェア一覧のページに詳細があります.

...ここまで準備出来れば, Werckerを利用したCI環境の構築はほぼ終わったようなものです. 後は, Boxの作成時と同じように, WebアプリのリポジトリをWerckerのアプリケーションとして登録すれば, リポジトリにコードがpushされる度にテストが走るようになります.

まとめ

前回の記事で作成したWerckerのBoxを利用して, Amon2のWebアプリのテストをWerckerで実行する方法について紹介しました. ミドルウェア周りなど, 若干クセがある部分がありますが, それでも慣れてしまえば導入は楽ですし, 何より現在無料で利用出来るので, 試行錯誤も非常にやりやすいので, 外部サービスを利用したCIを検討している方は, 一度使ってみてはいかがでしょうか.

参考情報

この記事を準備するにあたり, 次のブログ記事を参考にさせて頂きました. ありがとうございました.


WerckerでPerlのWebアプリのテストをする 〜Box準備編〜 2014-10-03 23:42

最近... というかだいぶ前の話なのですが, 現在所属しているチーム(割と社内でも技術的挑戦を進めている部署なので, 対外的宣伝(?)の為にチーム名を決めようか, という話も出たり出ていなかったりしています...)のCI環境として, Werckerを導入しました.

Werckerは, Travis CIのようなCIの仕組みを提供するサービスの1つです. このような, CI環境を提供する系のウェブサービスは最近流行っているようで, これ以外にもdrone.ioCircleCIなどが有名です.

通常, CI環境を用意するのであれば, 自分たちでJenkinsUkigumoなどを整備するのが一般的ですし, 最初はそのような形で検討していたのですが, 自分たちのチームのようにチームメンバーが少数(4人)の場合, これらの環境を構築し, 保守するのは結構なコストでは? という考えに至りました.

そこで, 多少の金銭的コストと引き換えに, CIの環境を外部サービスに任せよう! という結論に至った訳です. 数多のCIサービスの中から, 自分たちのチームがWerckerを採用したのは, 主に次の理由からでした.

  • 現在, ベータ版のためプライベートリポジトリでも無料で使える
    • 会社のプロダクトは流石にプライベートリポジトリで開発したいので, プライベートリポジトリでも無料で使える(検証出来る)のは嬉しいです
    • 制約としては, 「1ビルド25分以内」という所くらい, のようです
  • BitbucketでもGithubでも使える
    • 今の会社はGitリポジトリは全てBitbucketで管理しているので, この条件は必須でした

チームや上長と相談した結果, 「無料なので, 検証として使ってみよう!」という結論に至ったので, チームで開発中のPerl製WebアプリケーションのCI環境を, Werckerを使って構築することになりました.

WerckerのBox

...で, 早速詰まったのがWerckerのBox周りの環境でした. Werckerには, 「Box」という概念があります. 一言で言えば, VagrantのBoxのようなもので, Werckerでビルドをする際は予め構築しておいたBoxから仮想環境を作り, そこでテストを走らせる... という形になります.

Boxについては, 公式が提供している他, ユーザ自身がテスト対象に最適化したBoxを作る事も出来るので, 早速WerckerのサイトからPerlのBoxを探してみたのですが... ない, 1つもない! RubyやPython関連のBoxはたくさんあるのに, Perl関連のBoxは1つもありませんでした... ので, Perl 5.18.2 + App::cpanminus + Cartonという環境を提供するperl5.18.2というBoxを作りました.

...ちなみにその後, 5.18.4が出たので, 別途perl5.18というBoxを作ってあります. Boxを作る為の設定ファイルは全てGithubにあるので, perl5.18-wercker-boxのリポジトリ等を参考にして下さい.

作り方は公式ヘルプのCreating your own boxes with Bashなどに書かれていますが, 英語ですので簡単に解説したいと思います.

リポジトリの用意

GithubかBitbucketに, Boxの設定ファイルを設置するリポジトリを用意します. Boxの設定は, リポジトリにwercker-box.ymlというファイルにYAML形式で記述していきます.

先ほど紹介した, perl5.18というBoxの設定ファイルは, このようになっています.

name: perl5.18
version: 0.0.1
inherits: wercker/ubuntu12.04-webessentials@1.0.4
type: main
platform: ubuntu@12.04
description: wercker box for perl 5.18
keywords:
  - perl
  - perl5
script: |
  sudo apt-get update -y

  # install perl
  curl https://raw.githubusercontent.com/tokuhirom/Perl-Build/master/perl-build | sudo perl - 5.18.4 /opt/perl-5.18/

  # install cpanm
  curl -L http://cpanmin.us | /opt/perl-5.18/bin/perl - --sudo App::cpanminus

  # install carton
  sudo /opt/perl-5.18/bin/cpanm Carton
env:
  PATH: "/opt/perl-5.18/bin:$PATH"

nameは実際にWercker上で使われるBoxの名前です. そしてinheritsplatformで, ベースとなる環境の指定をしています. 今回の場合, Ubuntu 12.04をベースにPerl環境が構築されたBoxを作っていく, という形になります.

後は, scriptの部分に, 作りたい環境を構築するためのシェルスクリプトを書いていけばOKです. ここでは, Perl::Buildを使ってPerlを/opt/perl-5.18に導入し, そこにApp::cpanminusとCartonを導入しています.

最後のenvでは, 任意の環境変数を設定することが出来ます. ここでPATHに対して"/opt/perl-5.18/bin:$PATH"と書いておけば, 自動的に/opt/perl-5.18にパスが通り, 導入したPerlが利用できる, という訳です.

それでは次にこの設定ファイルからBoxを作っていきます.

アプリケーションの作成

まず, Boxを作成するための設定ファイルを設置したリポジトリを, Werckerのアプリケーションとして登録する必要があります. Werckerにログインした後, ページ左側に出現するバーの「Apps」というボタンの右側にある「+ Add」というボタンをクリックし, リポジトリをアプリケーションを登録する画面を開きます.

設定ファイルを設置したリポジトリがGithubかBitbucketのどちらに設置したかを選ぶと, 自動的に選択したサービスに存在する全リポジトリの一覧が表示されますので, 先ほど準備したリポジトリを選択し, 「Use selected repo」をクリックします.

次のConfigure accessはそのまま(wercker will checkout code without using an SSH keyを選択した状態)で「Next Step」を押し, そのまま次のSetup your wercker.ymlの「Next step」もクリックします. 最後の「Make my app public」のチェックボックスをオンにして, 「Finish」ボタンを押せば, アプリケーションの準備は完了です.

ビルドの実行とデプロイの設定

この段階で, 設定したアプリケーションのページに遷移します. 今後は, 左側のバーの「Apps」を選択すれば, 自分が登録した/関連する全てのアプリケーションを閲覧することが出来るので, こちらから遷移していきます.

さて, このページでは, ページ上部辺りで「Builds」, 「Deploys」, 「Settings」と書かれたタブを選択することができます. 初期状態は「Builds」を開いており, ここに「Build now」というボタンが設置されています.

Boxを作る為に, まず「Build now」ボタンを押して, ビルドを実行します. ビルドが終わると, 「Builds」タブにその詳細が表示されますので, 「#8a00b61...」のようなハッシュをクリックし, ビルドの詳細画面へ移動します.

右上の「Deploy to」ボタンをクリックし, 「ADD DEPLOY TARGET」をクリックすると「Settings」タブに遷移するので, そのページの「Add deploy target」をクリックし, 「wercker directory」を選択します. 「Deploy target name」は適当に(自分の場合, boxと指定しています)入力し, auto deploy successful builds toのチェックを入れ, branch(es)にはmasterを入力し, 「save」をクリックします.

デプロイの実行

ここまで終われば, 準備したwercker-box.ymlに従ってBoxを作成し, Werckerが使えるように設定(デプロイ)することができます.

再び「Builds」タブに戻り, 先ほどと同じ手順でビルドの詳細画面へ遷移します. 「Deploy to」をクリックすると, 「box」という選択肢が増えている(ここの名称は, 「Add deploy target」をクリックした後の「Deploy target name」に指定したものになります)ので, それをクリックし, 「Start deploy」をクリックすると, デプロイが始まるはずです.

このデプロイが終わったタイミングで, 左側のバーの「Explore」や「Boxes」などで, 設定したBoxが検索/利用できるようになるはずです. 今後は, 先ほど「auto deploy successful builds to」のチェックを入れてさえおけば, リポジトリが更新される度に自動的にビルドとデプロイが走り, Boxが作成されるようになります.

まとめ

...というわけで, 文字ベースでWerckerのBoxを作成する方法を説明してみました. スクリーンショットを準備するのが面倒だったという怠慢で文字ベースの説明となっていますが, 「よくわからん!」という場合, スクリーンショットを整備していきたいと思うのでご連絡頂ければと思います.

ちなみに次の更新では, 今回作成したWerckerのBoxを使って, 実際にPerlで書かれたWebアプリケーションのテストを実施する方法や, その設定をする上で得たTIPSというか小手先のテクニック的なものを紹介したいと思っています.

参考情報

この記事を準備するにあたり, 次のブログ記事を参考にさせて頂きました. ありがとうございました.


ISUCON4で惨敗してきました 2014-09-30 16:35

ISUCON初日, 同期のほと氏(@hoto17296)とタケウチ氏(@T_akms)と一緒に, 「カエルとクマと中年」チームで出場してきました. 結果は... まあ, 控えめに言っても惨敗! としか言い様がない非常に不様な敗北で, 周囲からは「ふざけているとしか思えない」等の厳しいお言葉を頂いても致し方ない結果になっておりました.

※...なお, 結構多くの方が自分のチームを初日2位だった「チームフリー素材」と勘違いされていたようですが, papixと「チームフリー素材」とは一切関係ありませんのでご注意下さい.

今日は, 実際に惨敗してみて感じた所, 反省点や「こうしておきたかった!」というポイントを, 赤裸々に(?)綴ってみようと思います. 来年, ISUCON5があった時に参加してみたい! という方は是非反面教師にして頂ければ幸いです.

今回, ISUCON4の予選を終わってみてつよく感じたのは, 「下準備の大切さ」と「考えるな, 計測せよ」という言葉の重さ, そして「どんな時でも, いつもやっている事以上の事は出来ない」... の3つでした.

下準備の大切さ

もちろん, 自分たちのチームもミーティングを開いたり, リハーサルをやったりして準備はしていたのですが, やはり抜けというか, 「ここも準備しておけば良かった...!」という点が多かったです.

例えば今回の場合, 自分はミドルウェアチューニングということでNginxやMySQLをいじっていたのですが, 割と行き当たりばったりに変更していて, かなり右往左往していました. 他チームの感想ブログを読んでいると, 「NginxやMySQLに慣れていないチームメイトがいたので, パラメータについては予めカンニングペーパー(のようなもの)を作っておいた」といった記述を見つけ, ここまで準備出来ていれば, もう少しスムーズにチューニング出来たのではないか... と思いました.

また, 実際に当日10時になって, ISUCONが始まってから実際に諸々を触り始めるまでの下準備も結構大切だと思いました. 一度アプリの各機能をしっかり使ってみて, 各ミドルウェアのログを見て, 傾向を掴んで... くらいやらないと, チューニングするにも「どこをチューニングすればいいんだ!?」となります. そして, 機能や挙動の理解が中途半端なままチューニングをすれば, ミドルウェアチューニングであれば適切なパラメータを見つけるまでに時間がかかるでしょうし, アプリケーションの書き換えであればバグを埋め込んでしまって, 作業するだけ無駄になってしまったりします.

その辺り, 「しっかりやろう!」と言っていたにも関わらず, 本番という焦りがあったのか, そういう下準備が必要最小限で終わってしまい, 中途半端になってしまったのも敗戦の原因だったと思います. 来年は「開始からXX分は一切のチューニングをしない, アプリの観測とチューニング方針をしっかりやる!」という所を徹底してもいいのかな, と思いました.

考えるな, 計測せよ

「下準備の大切さ」とも繋がりますが... ここも, 今回自分たちのチームが中途半端だった所の1つです. 勘に基づいたチューニングやリファクタリングは時間の無駄が大きいので, もっともっとアプリやミドルウェアが出力するログをうまく活用するべきでした.

ログファイルを見るのが面倒(苦手)であれば, fluentdやらElasticSearchやら導入して, グラフの形で可視化したり, 検索しやすくしたり... という所も, 予め検討して良かったと思っています. ちなみに, songmuさんは実際にMackerelを導入して, サーバの様子を計測してみたりしていたそうです...

どんな時でも, いつもやっている事以上の事は出来ない

正確に言えば, 「いつもやっている事+αしか出来ない」という感じで, つまりは「慣れていない事をISUCONでやろうとしても, 出来る訳がない」と. もちろん4月に会社に入社して以来, 新人研修や実際の業務の中で, アプリの高速化やミドルウェアの最適化という所も徐々に徐々に経験は積んではいます... が, やはり毎回おっかなびっくりというか, 四苦八苦しながら取り組んでいるのが現状です.

社内でいろいろ任せてもらっている... というか, 幸いにしていろいろ自由に挑戦出来る環境にいるので, 来年のISUCONで健闘したいのであれば, ISUCONでやるような高速化, 最適化の施策を, もっと事業の中で, 会社の中で「当たり前に」出来るように, 挑戦していかないといけないなあ... と思いました.

まとめ

反省点と悔しい所はたくさんでしたが, 今回も多くの事を学ばせて頂きました. 社内でも「社内ISUCONをやってみよう!」という声も出てきたので, 社内外の取り組みを通して, 来年は善戦出来るように頑張って行きたい次第です...

改めて, LINE株式会社さま, 株式会社データホテルさま, クックパッドさま, 貴重な機会をありがとうございました!


「Fukuoka Perl Workshop #2」へ行ってきました! 2014-09-29 17:34

Gotanda.pmに引き続き, 先週の9月20日に開催された「Fukuoka Perl Workshop #25」に参加してきました.

今回は「YAPCレポート」がお題(?)ということもあって, YAPC::Asia 2014を主催した@yusukebeさんや, 運営スタッフの1人としてイベントホールでのイベントを大成功に導いた上にPHPでベストトーク賞を受賞した@uzullaさんのトークでは, 結構赤裸々な感じでYAPC::Asiaの運営の側面(?)的なお話を聞くことが出来て, 非常に満足感のあるイベントでした.

今回は僕も発表時間を用意して頂いたので, YAPC::Asiaのレポートというお題をガン無視して, 最近業務の中で取り組んでいる自動化や効率化についての話をしてきました.

内容的には, 入社してからの半年で取り組んできたことの集大成のような発表で, Gotanda.pmやMishima.pm辺りで話したネタをまとめた感じになっています. そのため, uzullaさんの手でいつの間にか配信されていたUstreamを見ていたmoznionさんから, こんな事を言われていたりしました.

moznion

そろそろ会社も新しいクォーターに入ってくるので, そこでまた新たな施策をスタート出来れば, 新しいネタもどんどん出てくると思います. 引き続きご期待頂ければ幸いです!


...以下, 写真で振り返るFukuoka.pm的な感じで.

「ふとっぱら」という居酒屋にあるラーソーメン. 以前のFukuoka.pmで, 某Perl Monger氏がたいそう気に入ってわんこそばのように食べていった, というエピソードがあるらしく, それ以降Fukuoka.pmの二次会はふとっぱら! という流れが定着したとかしないとか...

ラーソーメン, 個人的にすごい大好きで, 「福岡に来たならこれ食べて帰らないと満足できん!」という感じになっているので, 今回も食べれて良かったです.

帰りに乗った便で「JAL Sky Wi-Fi」というサービスが使えたので, それを使って機内から投稿した写真がこれ.

ちなみにスピードテスト試してみたら, 結果はこんな感じだった.

料金は福岡〜羽田便(だいたい1時間半くらい?)の場合, 1フライトまるまる使えるフライトプランならスマートフォンの場合500円, ラップトップやタブレットの場合700円で使い放題, 時間制プランは30分で400円... といった感じ. Pressoで紹介されている記事を読んだり, LineやSlack, もちろんYanchaでコミュニケーションしたりする程度なら十分実用的だったので, 「JAL Sky Wi-Fi」が使える便に乗って, 「やることなくて暇だー」という方は使ってみては如何でしょう.


「Gotanda.pm #2」へ行ってきました! 2014-09-19 17:44

17日に五反田のMobile Factoryさんで開催された「Gotanda.pm Perl Technology Conference #2」に参加して, ついでにLTをしてきました.

Werckerで爆速(?)テスト環境構築

自分が今所属しているチームは, インフラ部署の組織改編的なものでごく最近(半年くらい前?)に立ち上がった部署で, チーム文化やチームの開発基盤(環境)など, いろいろな部分を構築している途上にあります. その一環として最近取り組んだ, Werckerを利用したテスト環境構築(+ GaiaChanによる自動デプロイ)についての話です.

社内向けCI環境について最近思う事

現状, 社内で使うCI環境の準備となると, JenkinsやUkigumoなどを自社のサーバに構築する... というのが主流なのかなー, と思います. ただ弊社のように, 大規模な主軸サービスがなく, 中規模〜小規模のサービス(事業)が集まっている会社の場合, 事業がJenkinsを使ったCI環境を構築して保守する... というのは結構なコストになるのでは? と感じています. 「最初はJenkinsを使ったCIを回してたけど, ある日Jenkinsおじさんが突然死してしまって, 蘇生する時間が取れずにCI環境がなくなってしまった...」という事例もたまに聞いたりします.

というわけで, WerckerのようなCIを提供するサービスは, 「低い(準備|運用)コストで, CIを回し続ける」ための解決策の1つとして, これからもっと需要が高まってくるのではないか, と思っています. 現在, Werckerはベータ版ということで無料で使えていますが, 価格次第では正式版になって有料になっても使い続けたいね, という話はチームでも出てきています.

WerckerでPerlのWebサービスをテストする為のノウハウについては, 近々ブログにまとめたいなー, と思っています! ...まあ, その前にYAPC::Asia 2014のブログを書いて, 自分の中でのYAPC::Asia 2014を終わらせなければ...

最後に

主催の@karupanerura先生(Perl Tiger), 会場提供のMobile Factoryさん, どうもありがとうございました.

ちなみに, 同じ五反田にあるGaiaXという会社もエンジニアとか募集しているそうですよ. papixと一緒に働いてみたい, という奇特な方がいらっしゃいましたら是非ご応募下さいー.


25歳になってました. 2014-08-17 23:58

...というわけで8月17日に25歳になりました. いよいよ, いわゆる「アラサー」と呼ばれる領域に片足突っ込む感じですね.

それはさておき, FacebookやTwitter, チャット等でお祝い頂いた皆様, 本当にありがとうございました. 「給料三倍」を合言葉に, これからも精進していきたい次第であります.

なお, Amazonのウィッシュリストはこちらとなっておりますのでご確認下さい. ちなみに@hide_o_55さん(黒霧島を送って下さいました!)がこのウィッシュリストを評して曰く「妙に生活感ある」とのことでした.


Perl::Lintを使ってみた 2014-08-13 11:26

TL;DR

moznionさんが書かれたブログ記事を見る方が早いです: Released Perl::Lint as underdevelopment

Perl::Lintとは?

開発版ではありますが, 遂にPerl::Lintがリリースされたようです.

Perl::Lintは, @moznionさんの提案がTPF(The Perl Foundation)の助成金プログラムに採択された結果, 開発が始まったプロダクトです.

moznionさんの提案は, Perlのコードを静的に解析するPerl::Criticの高速化. Perl::CriticはPPIを利用して実装されていますが, Perl::Lintでは@goccy_54さん製のCompiler::LexerCompiler::Parserを利用しています.

全てPerlで実装されているPPIと違い, Compiler::LexerやCompiler::ParserはXSで実装されている為, 静的解析を実現する上で必須となる字句解析や構文解析が早くなり, 結果全体の高速化が期待できる... という訳です.

...さて, それでは早速使ってみましょう!

Perl::Lintのインストール

この記事を書いた段階でのPerl::Lintの最新版は, 0.01_01です(余談ではありますが, Perlのモジュールにおいてバージョンに_が入っているものは開発版として扱われます. CPANのPerl::Lintのページを見てみても, 「DEVELOPER RELEASE」と書かれていることが確認できると思います).

開発版のモジュールをインストールする場合, cpanm--devというオプションを与えましょう.

$ cpanm --dev Perl::Lint

Perl::Lintを使ってみる

というわけで早速Perl::Lintを使ってみましょう. 今回は, 会社の業務と趣味の狭間で開発をしているGaiaChanのコードでPerl::Lintを試してみたいと思います.

ひとまず, GaiaChan.pmで試してみます. コードは以下の通り.

package GaiaChan;
use 5.010;
use strict;
use warnings;
use utf8;

our $VERSION = 0.01;

1;

で, Perl::Lintを使ったテストはtディレクトリに, 99_perl_lint.tというファイル名で, 次のような形で置いてみました.

use strict;
use warnings;
use utf8;

use Perl::Lint qw/ lint /;

my $target_files = [qw(
    lib/GaiaChan.pm
)];
my $violations = lint($target_files);

use DDP { deparse => 1 };
p $violations;

Perl::Lintには, 現時点ではPerl::Criticに対するTest::Perl::Criticのようなモジュールは存在していません. なので, 今回はPerl::Lintがチェックした結果をそのままDDPで出力する, という若干強引な手法で確認してみることにします.

それではテストを実行してみましょう.

$ perl -Ilib t/99_perl_lint.t
\ [
    [0] {
        description   "",
        explanation   [
            [0] 45,
            [1] 46
        ],
        filename      "lib/GaiaChan.pm",
        line          7,
        policy        "Perl::Lint::Policy::NamingConventions::Capitalization"
    },
    [1] {
        description   "Code before strictures are enabled",
        explanation   [
            [0] 429
        ],
        filename      "lib/GaiaChan.pm",
        line          2,
        policy        "Perl::Lint::Policy::TestingAndDebugging::RequireUseStrict"
    },
    [2] {
        description   "Code before warnings are enabled",
        explanation   [
            [0] 431
        ],
        filename      "lib/GaiaChan.pm",
        line          2,
        policy        "Perl::Lint::Policy::TestingAndDebugging::RequireUseWarnings"
    }
]

...いろいろ出てきましたね.

1つ目は, 「description」が空欄なので何とも言えませんが... our $VERSION = 0.01;の行を指していて, policyがCapitalizationになっているので, 変数名が大文字になっているのが云々... という警告かなぁと.

で, 2つ目と3つ目は, use strict;use warnings;の前にuse 5.010;があるのが原因... なんだと思います. 実際, use 5.010;を後ろに持って行くと, 2つ目と3つ目の警告は出なくなりましたし.

感想

Perl::Lintをリリースした件ついてmoznionさんが書かれたブログ記事には, 「ご存知の通りこのモジュールは未完成です.このモジュール (の吐き出す結果) と俺を信用しないでください.」と書かれています. 実際, 「description」が空欄だったりと細かい部分がカバーできていない所が(先程の例でも)見受けられましたし, 未実装の部分だったり, バグがある部分等々もいくつかあるのかもしれません.

ただ, この段階でもPerl::Lintの利点というか, 可能性を十分感じる事ができました. それは実行速度の違いです. 今回, 比較対象としてPerl::Criticを使って同様のコードに対して静的解析をかけてみましたが, Perl::LintはPerl::Criticに比べて体感で倍くらい早い感じがしました(恐らくmoznionさんもPerl::LintとPerl::Criticの実行時間の差を比較していると思うので, いずれブログで紹介されるのではないでしょうか).

書いたコードのテストとしてPerl::LintやPerl::Criticを使う場合, テスト対象となるファイルが増えれば増える程, 1ファイルあたりの実行時間の差が積もっていき, 最終的な実行時間に大きく差が出てくるはずです. この点については, Perl::LintとPerl::Criticを比べた時の大きな利点になるでしょう.

Perl::Lintの今後に超期待ですね!