Advent Calendar 2013 Archive

Shin x blog Advent Calendar 2013 無事に完走できました！ご覧いただいたみなさんありがとうございました。

年の瀬の慌ただしい時期に12/1から12/25まで、毎日 blog を書くという荒行？を行ったのですが、なんとかやり終えて感じたことなどを書いてみます。

ブログ筋を鍛える

この企画をはじめようと思った目的は、書きたいけど書けていないネタを書いてしまいたいということです。

これがメインではあるのですが、裏テーマとしては、もっと早く書けるようになりたいというのもありました。書きたいけど、時間がかかるので敬遠しているという面もあったりするので、何とか早くアウトプットできればなあ、と。

そこで今回は早く書いて公開するためのブログ筋を鍛えるべく、事前にストックは書かずに、ぶっつけで書き始めることにしました。

期間中にお会いした方に「書きためていますよね？」と聞かれたのですが、こういう理由もあったので、用意していませんでした。

まあ、これが後でボディブローのように効いてくるのですが。。。

実際にやってみて分かったこと

実際にやってみて感じたことは、「毎日」公開するということは大変だな、ということです。

ネタに関しては、元々書こうと思いつつ書いていないものがあったので（そもそもはそういった中途半端になったネタを書き上げたいという目的だったので）、そんなに心配していませんでした。

ただ、毎日ちゃんとエントリとして書き上げて、公開するところまで持っていくのは、なかなか骨が折れました。

もちろん本業もありますし、打ち合わせや出張で外出したり、イベントに参加したり、忘年会に行ったりなど、何かと忙しい年の瀬なので、正直もう明日にしようと思うことも何度かありました。

時間に余裕がある日でも、気分が乗らない日もあります。blog を書くことに飽きてきたという日もありました。

ここで肝なのが「毎日書く」ということです。決めたからには、「明日にしよう」は通じないわけです。どうにかこうにか形にして公開しないことにはその日が終わりません。

ストックがあれば書かない日を作ることもできるのですが、「ブログ筋を鍛える」という目標もあったので、できるだけその日に書くようにしました。

ほんと毎日継続して書き続けている人はすごいですね。身にしみて分かりました。

記事の内容

書いた内容ですが、傾向としては、主に技術系と読み物系（経験談 or 思想信条）に分かれています。

技術系は調査や検証が必要になるので書く以上の時間がかかります。この作業は好きなので苦にはならないのですが、いかんせん時間が限られているので、深堀りしきれないことが残念だったネタもありました。ただ、これまでも深堀りしてからと思っている内に「下書き」のまま放置しているエントリもあったりするので、そうなるくらいなら多少浅くても一旦公開して、より深堀りしたければ、その後、別エントリでも追記でも書けば良いのかもしれません。

読み物系は、普段から考えていることや過去の経験を思い出しつつ、気合一発で書きました。わりと、どのエントリの反応を頂けたので書いて良かったです。ここ最近は、読み物系はあまり書いてなかったので、書くのに躊躇するところがあったのですが、今後は、ぼちぼちと書いてみたいと思います。

いずれにせよ、「毎日書く」ということは、期限があるということで、ある意味それを後ろ盾にして、「まだ」「もう少し」と思っている内容でも公開してしまえるという部分はありました。バランスは考えないといけないですが、今回については、わりと良い方向に行ったと思います。

ソーシャルでの反応

期間中に公開したエントリについて、はてブや Facebook などで多くの反応を頂きました。ありがとうございました！

ざっくり集計してみると下記のようになりました。（2013/12/27現在）

• はてブ: 1,842
• Facebook: 2,008
• Twitter: 1,770
• Pocket: 1,980
• Google+: 181

Google+ を除く 4 サービスでは、2,000 前後の数値になっています。一つのエントリが、ものすごくヒットしたというわけではなく、毎日コツコツと積み重ねた結果でした。こういうのは嬉しいですね。

実は、エントリの内容によって、反応が付きやすいサービスとそうでもないものがあります。

例えば、技術系で調査内容を公開したようなもの（資料性のあるもの）は、はてブが多く、Facebook が少なめになります。読み物系は、反対に、はてブが少なく、Facebook が多めになりました。

この傾向が顕著な例としては、前者の場合は「Docker ストレージドライバによる RHEL/CentOS 対応について」で、はてブ=53 / Facebook=6 （はてぶ/Facebook=8.83）です。後者の場合は「「世界を変えたい！」って？」で、はてブ=5 / Facebook=190（はてブ/Facebook=0.03）です。

ただ、こうしてエントリによって、ばらつきがあるのに、総数としては似た数になるというのが面白いところですね。

人気エントリ

今回書いたエントリで、PV が多かったトップ 5 が以下になります。ソーシャルで特徴的だった、はてブとFacebookの数値を記載しています。流入元としては、はてブと Gunosy が特徴的だったので、これについてコメントを書いています。

全体としては、Gunosy からの流入が一番多く、次が、ダイレクトで、その次に、はてブでした。Gunosy の影響力は前から聞いていたのですが、今回あらためて見るとすごいですね。非技術系のエントリでは特に流入が多かったです。ただ技術系に関しては、まだまだはてブの影響力が強く、多くのエントリで、はてブからの流入が最も多かったです。

1. 個人事業から法人化した理由 はてブ:66 Facebook:188

はてブや Facebook のいいね！が突出した値では無いですが、PV に関してはこのエントリがトップとなりました。要因は Gunosy で、いわゆる Gunosy 砲をはっきりと体感できたのは、このエントリでした。目に見えるソーシャルでの数字では一番ではないのに、PV は一番になっているというのが面白いところですね。

2. Mac で Vagrant を GUI で操作できる「VagrantX」をリリースしました はてブ:208 Facebook:348

最終日の 12/25 に公開したエントリが、PV では 2 位でした。はてブ数はほぼトップ、Facebook はトップの数値で、期間を考えるとかなり反響がありました。これはエントリの内容というより、リリースした VagrantX への反応というところが大きいです。（もちろん、それでも嬉しいです）技術系のエントリらしく、はてブからの流入が一番でした。

3. エンジニアは独立した方が良いのか？ はてブ:93 Facebook:176

12/03 に公開して、この企画の弾みがついたエントリです。読み物系のエントリなので、Gunosy からの流入が多く、次に Twitter、そして、はてブとなっています。

4. CentOS 6.5 に Docker をインストールしてみた はてブ:210 Facebook:56

はてブが一番付いたのがこのエントリです。典型的な技術系エントリで、流入元も、はてブがトップ、Gunosy はトップ10 にも入ってませんでした。

5. ざっくり分かる Vagrant 1.4 / Docker Provisioner はてブ:194 Facebook:42

こちらも同じく技術系エントリです。はてブの割には、Facebook は少なく、流入元も、はてブがトップでした。

25日間やってみる

TED の中で好きな発表にマット・カッツ氏の「30日間やってみる」というものがあります。

やってみたいけど、やれていないことを試しに 30 日間やってみようという内容なのですが、この Advent Calendar はまさにこれをやっていました。（25日でしたが;=p）

深い意味は無くとも、やってみたいと思うことを、とりあえず期間限定でやってみる。何もしなくてもすぐに時間は過ぎ去ってしまいます。ならば、まずはやってみようよということです。

さいごに

いま率直に思うことは「終わって良かった」ということです;-p

自分で課したことながら、やはりこの時期に毎日書くのはなかなか大変で、締め切りに追われながら過ごす12月になりました。

ただ面白いもので、例え仕事ではなくてもこうして継続してやっていくことで、エントリを書いて公開する「ブログ筋」は強制的に鍛えられたような気がします。理想としては、もっと早く書けると良いのですが、少なくとも書いて公開することについてはフットワーク軽くなりました。

blog なんてそんな真剣にやるもんじゃないよ、という意見もあると思いますが、そんな真剣にやるもんじゃないことを真剣にやることに面白さがあったりもするので、まあ今回に関してはやって良かったかと。

年末の忙しい中、こんな企画にお付き合い頂き、読んで、反応していただいた方には感謝感謝です。

来年は、、、やらない方向ですが、blog は書いていきますので、引き続きよろしくお願いしますm(_ _)m

Shin x blog Advent Calendar 2013

• 12/01 Mac で集中して文章を書く環境を作るアプリ
• 12/02 55インチテレビとApple TVで、ワイヤレスな快適プレゼン環境
• 12/03 エンジニアは独立した方が良いのか？
• 12/04 6分でわかる最近のPHP 2013年冬
• 12/05 書きかけの blog が延々と溜まっていく６つの理由
• 12/06 とある CMS を使ったサイトに Varnish を導入した話
• 12/07 CentOS 6.5 に Docker をインストールしてみた
• 12/08 Docker ストレージドライバによる RHEL/CentOS 対応について
• 12/09 WordPress を Docker で動かす（ OSX / Vagrant ）
• 12/10 ざっくり分かる Vagrant 1.4 / Docker Provisioner
• 12/11 技術の種を蒔こう
• 12/12 Z80アセンブラでゲームが作れるようになった話
• 12/13 Mac で黒い画面を出す方法
• 12/14 Travis CI を使って PHP コードを HHVM 環境でテストする
• 12/15 CentOS 5, 6 / Amazon Linux で PHP をパッケージインストールする方法まとめ
• 12/16 開発現場で Docker をどこで使うか考えてみた
• 12/17 レゴブロック型プログラミング
• 12/18 Twilio と ChatWork を使って、電話のメッセージをチャットで受け取る
• 12/19 個人事業から法人化した理由
• 12/20 もくもく勉強会をやろう！
• 12/21 PHP 5.6 に採用されるデバッガ phpdbg を使ってみた
• 12/22 「世界を変えたい！」って？
• 12/23 Vagrant に見るインテグレーションのヒント
• 12/24 vagrant-serverspec で TDD ライクにサーバ構築を行う
• 12/25 Mac で Vagrant を GUI で操作できる「VagrantX」をリリースしました

Shin x blog Advent Calendar 2013 の最終日です。

12/1 から毎日書いてきた Shin x blog Advent Calendar 2013 ですが、いよいよ今日が最終日です。

今日は、クリスマスということで、ささやかながらちょっとしたプレゼントを用意してみました:D

VagrantX

GUI で Vagrant が利用できる VagrantX というツールをリリースしました。

http://shin1x1.github.io/vagrantx/

Vagrant は、とても良いツールなのですが、いかんせんターミナル（黒い画面）で操作するものなので、それに慣れていない人にとっては、少し敬遠されている面があります。Vagrantfile を自分で書くような人はターミナルでどんどん使うべきなのですが、用意された Vagrantfile をただ使うだけであれば、vagrant up や vagrant halt など基本的な操作しか行わないので、そのためだけに慣れないターミナルを使うのもどうかなという疑問がありました。

そこで、GUI アプリケーションから、基本的な vagrant コマンドが実行できるよう、このアプリケーションを作りました。

VagrantX は、Mac OS X 向けのアプリケーションで、現在は、10.8 (Mountain Lion)、10.9 (Mavericks) で動作するようになっています。

インストール

VagrantX は、Vagrant を GUI から操作するアプリケーションなので、Vagrant 本体や VirtualBox など Vagrantを通常利用するために必要なアプリケーションは別途インストールする必要があります。

Vagrant も VirtualBox もパッケージで配布されているので、ダウンロードして、インストールするだけです。

• Download Vagrant – Vagrant
• Downloads – Oracle VM VirtualBox

VagrantX は、ZIP ファイルとして GitHub に公開しています。公式サイトにある「.zip」リンクをクリックするとダウンロードがはじまります。

ダウンロードした ZIP ファイルを展開します。VagrantX.app がアプリケーション本体になります。このまま起動して試すこともできますし、必要であれば /Applications フォルダへコピーして下さい。

操作

VagrantX を起動すると下記のような画面が表示されます。

まずは仮想マシンを操作する対象の Vagrantfile を画面右上にある Read ボタンで選択します。選択が完了すると、vagrant status が実行され、現在の仮想マシンの状態が表示されます。

あとは、仮想マシンの起動、停止、破棄などをボタンで実行するだけです。

仮想マシンを起動する際は Up ボタン、停止する際は halt ボタン、破棄する際は destory ボタンをクリックして下さい。それぞれのボタンは、仮想マシンの状態により有効になったり、無効になったりします。（仮想マシンが実行中であれば、Up ボタンは無効など）

現在サポートしている Vagrant コマンドは以下です。

• vagrant up
• vagrant halt
• vagrant destory
• vagrant provision
• vagrant ssh

アンインストール

ダウンロードしてきた VagrantX.app を削除するだけです。

開発の話

VagrantX は、RubyMotion で書いています。RubyMotion といえば、iOS アプリケーションの情報はわりと見つかるのですが、OSX アプリケーションの情報はほとんどなく、結局は、MacRuby の情報や Objective-C の情報を参考にして、開発を進めました。幸い、RubyMotion は、Ruby シンタックスの Objective-C と言っても良いくらい層が薄いので、ずばり RubyMotion ではない情報でも転用しやすいのは良かったです。

アイデアは、夏前頃からあったのですが、開発は、9 月に参加した開発合宿から開始しました。開発合宿は、2 泊 3 日だったのですが、1 日半で、仮想マシンの起動などベースのところは動くところまでいきました。OSX アプリケーションを作るのが初めてだったので、紆余曲折はあったのですが、これまで Windows や Java で GUI アプリケーションを作った経験があり、概念自体は理解していたので、OSX(Cocoa) 固有の問題点を一つづつ潰していきました。

それから隙間時間に序々に改良を進めていき、ようやくリリースすることができました。

と、言えば、聞こえは良いのですが、実は塩漬けになっている期間も長く、このままだと HDD の肥やしになって終わる可能性もあったので、まずは公開してみようと思い、今回リリースしました。（ Chef ゆく年くる年で背中を押されたのもありますね:D ）

基本機能は動いているのですが、まだ不具合や不足機能などがあるので、現在はプレリリースという形にしています。

さいごに

Vagrant は、優れたコマンドラインツールなので、GUI が必要なのか？という疑問も当初ありました。

ただ、Vagrant による開発環境の共有、そしてユーザの広がりを見ると、ターミナルを使わない人にこそ、Vagrant が便利なのではと思うようになりました。

まずは公開してみて、反応を見つつ、今後の開発を進めていきたいと思います。興味がある方は、一度ダウンロードして使ってみて下さい。

http://shin1x1.github.io/vagrantx/

なお不具合や改善点などあれば、GitHub の issue へ投稿をお願いします。

Merry Christmas!

お願い

喫緊の課題として、ロゴデザインがあります。

自分で作ってみたのですが、絶望的に残念な感じなので、もし書いても良いよという奇特な方がいれば、お手伝い頂ければとっても嬉しいです。やってみようかなという方は、GitHub の issue にてコメントをお願いしますm(_ _)m

Shin x blog Advent Calendar 2013 の 24 日目です。

先日リリースされた vagrant-serverspec を使って、テストドリブンなサーバ構築を行ってみました。

vagrant-serverspec

vagrant-serverspec は、サーバ、インフラの状態をテストするツール serverspec を Vagrant のプロビジョナとして実行できるプラグインです。これを使うことで、vagrant コマンドから、serverspec のテストを実行することができます。

詳しくは、@ryuzee さんの下記エントリを参照して下さい。

vagrant-serverspecを使ってプロビジョニング結果をテストする | Ryuzee.com

仕様

今回構築するサーバの仕様は下記です。PHP 5.5.x をインストールして、ビルトインサーバを起動するというものです。（※ちなみにビルトインサーバは開発用途でのみ利用して下さい。）

* PHP 5.5.x を yum でインストール（remi-php55）
* date.timezone を Asia/Tokyo に設定
* ビルトインサーバを Port 8000 で起動

また、環境は下記で動作確認しています。必要であれば、それぞれについてインストールを行なって下さい。

* Vagrant 1.4.1
* VirtualBox 4.3.0
* serverspec 0.13.7
* ansible 1.2.2

vagrant-serverspec インストール

vagrant plugin コマンドで、vagrant-serverspec をインストールします。

$ vagrant plugin install vagrant-serverspec

Vagrantfile 作成

Vagrant で仮想サーバを構築して、このサーバを仕様を満たす形に進めていきます。まず、vagrant init コマンドで Vagrantfile を作成します。

$ vagrant init centos64_ja
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

serverspec-init でデフォルトのテストケースを作成

テストドリブンということで、先に serverspec のテストを作っていきます。

serverspec-init コマンドで、デフォルトのテストケースを生成します。いくつかオプションを選択する必要があるので、下記のように回答しています。

$ serverspec-init
Select OS type:

  1) UN*X
  2) Windows

Select number: 1

Select a backend type:

  1) SSH
  2) Exec (local)

Select number: 1

Vagrant instance y/n: y
Auto-configure Vagrant from Vagrantfile? y/n: y
 + spec/
 + spec/default/
 + spec/default/httpd_spec.rb
 + spec/spec_helper.rb
 + Rakefile

作成されたスペックファイルを元にテストケースを作ります。今回は、PHP に関するテストとなるので、spec/default/httpd_spec.rb を spec/default/php_spec.rb というファイルにリネームします。そして、このファイルにテストケースを書いていきます。

まずは、下記のように、PHP パッケージがインストールされているかだけを確認するテストを書きました。

$ mv spec/default/httpd_spec.rb spec/default/php_spec.rb
$ vim spec/default/php_spec.rb
require 'spec_helper'

describe package('php') do
  it { should be_installed }
end

作成したテストケースが実行されるように Vagrantfile に serverspec のプロビジョニング設定を記述します。spce/default/ 以下の全てのスペックファイルを対象としています。

  config.vm.provision :serverspec do |spec|
    spec.pattern = "spec/default/*_spec.rb"
  end

これで、vagrant up を実行すると、serverspec のテストが実行されます。では、実際にvagrant upを実行してみましょう。下記のように、serverspec プロビジョナが実行され、テストが失敗しました。まだ、PHP はインストールしていないので、これは当然の結果です。

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
(snip)
[default] Running provisioner: serverspec...
F

Failures:

  1) Package "php" should be installed
     Failure/Error: it { should be_installed }
       sudo rpm -q php
       パッケージ php はインストールされていません。
       expected Package "php" to be installed
     # ./spec/default/php_spec.rb:4:in `block (2 levels) in '

Finished in 5.07 seconds
1 example, 1 failure

Failed examples:

rspec ./spec/default/php_spec.rb:4 # Package "php" should be installed

では、PHP をインストールするプロビジョニングをシェルで記述してみます。このプロビジョニングは、serverspec よりも前に実行する必要があるので、serverspec プロビジョニングより上に記述します。

  config.vm.provision :shell, :inline => <<-EOT
    #
    # yum repository
    #
    rpm -ivh http://ftp.riken.jp/Linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
    rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
    yum -y install php --enablerepo=remi-php55
  EOT

  config.vm.provision :serverspec do |spec|
  (snip)

これで、PHP をインストールが行われ、その後に serverspec が実行されるので、テストが通るはずです。vagrant provision コマンドを実行して、プロビジョニングを行うと、今後はちゃんとテストが通りました。

$ vagrant provision
(snip)
[default] Running provisioner: serverspec...
.

Finished in 4.31 seconds
1 example, 0 failures

次に PHP のバージョンが、5.5.x であることを確認するためにテストを追加します。spec/default/php_spec.rb に下記を追加します。

describe command('php -v') do
  it { should return_stdout /^PHP 5\.5\./ }
end

テストを再実行します。次は、--provision オプションで、serverspec のみを実行するようにします。ちゃんとテストが通りました。これで、サーバには PHP パッケージがインストールされており、バージョンが 5.5.x であることが確認できました。

$ vagrant provision --provision=serverspec
[default] Running provisioner: serverspec...
..

Finished in 4.23 seconds
2 examples, 0 failures

date.timezone を Asia/Tokyo に変更する

次に PHP ではお馴染みの date.timezone 設定が Asia/Tokyo であることを確認します。

serverspec では、php_config という、そのままずばり PHP の設定を確認するためのリソースタイプが用意されているので、これを spec/default/php_spec.rb に追加します。

describe 'PHP config parameters' do
  context  php_config('date.timezone') do
    its(:value) { should eq 'Asia/Tokyo' }
  end
end

プロビジョニングを再実行して、今回追加したテストが失敗することを確認します。

$ vagrant provision
(snip)
[default] Running provisioner: serverspec...
..F

Failures:

  1) PHP config parameters Php config "date.timezone" value should eq "Asia/Tokyo"
     Failure/Error: its(:value) { should eq 'Asia/Tokyo' }
       sudo php -r 'echo get_cfg_var( "date.timezone" );'

       expected: "Asia/Tokyo"
            got: ""

       (compared using ==)
     # ./spec/default/php_spec.rb:13:in `block (3 levels) in '

Finished in 5.23 seconds
3 examples, 1 failure

Failed examples:

rspec ./spec/default/php_spec.rb:13 # PHP config parameters Php config "date.timezone" value should eq "Asia/Tokyo"

では、このテストが通るように date.timezone を設定するプロビジョニングを書きましょう。

今回は、php.ini の値を上書きするために zzmyphp.ini というファイルを作成し、ここに date.timezone の設定を記述することにします。

$ mkdir provision
$ vi provision/zzmyphp.ini
date.timezone="Asia/Tokyo"

このファイルをシェルプロビジョニングで、仮想サーバの /etc/php.d/ にコピーします。

  config.vm.provision :shell, :inline => <<-EOT
    #
    # yum repository
    #
    rpm -ivh http://ftp.riken.jp/Linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
    rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
    yum -y install php --enablerepo=remi-php55
    cp -a /vagrant/provision/zzmyphp.ini /etc/php.d/ # <--- 追加
  EOT

これでテストが通るはずです。vagrant provision を再実行します。下記のとおり、テストが通ったので、date.timezone の値が Asia/Tokyo となっていることが確認できました。

$ vagrant provision
(snip)
[default] Running provisioner: serverspec...
...

Finished in 5.12 seconds
3 examples, 0 failures

ビルトインサーバを起動

最後に PHP のビルトインサーバを 8000 ポートで起動します。DocumentRoot は、/vagrant にします。

まずテストから書きます。ここでは簡易的にポート 8000 で Listen しているかを確認します。

describe port(8000) do
  it { should be_listening }
end

プロビジョニングを行なって、追加したテストが失敗することを確認しておきます。

$ vagrant provision
(snip)
[default] Running provisioner: serverspec...
...F

Failures:

  1) Port "8000" should be listening
     Failure/Error: it { should be_listening }
       sudo netstat -tunl | grep -- :8000\
       expected Port "8000" to be listening
     # ./spec/default/php_spec.rb:18:in `block (2 levels) in '

Finished in 6.07 seconds
4 examples, 1 failure

Failed examples:

rspec ./spec/default/php_spec.rb:18 # Port "8000" should be listening

では、シェルプロビジョニングでビルトインサーバを起動するように設定します。ここでは supervisor を使って、ビルトインサーバを起動するようにします。

  config.vm.provision :shell, :inline => <<-EOT
    rpm -ivh http://ftp.riken.jp/Linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
    rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

    yum -y install php --enablerepo=remi-php55
    cp -a /vagrant/provision/zzmyphp.ini /etc/php.d/
    
    # 追加
    yum -y install supervisor
    cp -a /vagrant/provision/supervisord.conf /etc/
    chkconfig supervisord on
    service supervisord start
  EOT

vagrant provision を実行すると、ビルトインサーバが起動され、テストが通りました。これで、ビルトインサーバがポート 8000 で起動していることが確認できました。

$ vagrant provision
(snip)
[default] Running provisioner: serverspec...
....

Finished in 6.07 seconds
4 examples, 0 failures

プロビジョナを ansible に変更

これで仕様どおりに稼働するサーバを構築することができました。すでに仕様を検証する serverspec のテストがあるので、構築するためのプロビジョナを変更しても、要求された仕様を満たしているかを検証することができます。ではプロビジョナを ansible に変えて再度サーバを構築し直してみましょう。

Vagrantfile のシェルプロビジョニングの設定を削除して、代わりに ansible の設定を下記のように書きます。

  config.vm.provision :ansible do |ansible|
    ansible.playbook = "provision/playbook/main.yml"
  end

provision/playbook 以下に main.yml というプレイブックを配置しています。やっている内容は、シェルプロビジョニングとほぼ同じです。

---
- hosts: all
  sudo: yes
  tasks:
    - name: add yum repositories
      copy: src=files/{{ item }} dest=/etc/yum.repos.d/
      with_items:
        - epel.repo
        - epel-testing.repo
        - remi.repo

    - name: add rpm-gpg-keys
      copy: src=files/{{ item }} dest=/etc/pki/rpm-gpg/
      with_items:
        - RPM-GPG-KEY-EPEL-6
        - RPM-GPG-KEY-remi

    - name: install PHP 5.5.x
      yum: name=php enablerepo=remi-php55

    - name: put zzmyphp.ini
      copy: src=../zzmyphp.ini dest=/etc/php.d/ backup=yes

    - name: install supervisor
      yum: name=supervisor

    - name: put supervisord.conf
      copy: src=../supervisord.conf dest=/etc/supervisord.conf backup=yes

    - name: enable supervisor
      service: name=supervisord enabled=yes state=started

では、この ansible プロビジョニングでもテストが通るかを確かめてみます。前回のシェルプロビジョニングで構築した内容が残っているので、仮想マシンを破棄してから、再構築します。

下記のとおり、ansible によるプロビジョニングが実行され、テストが無事に通りました。これにより、要求された仕様が満たされていることが確認できました。

$ vagrant destory -f
$ vagrant up
(snip)
[default] Running provisioner: ansible...

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************                                                                                                                                                      [98/3036]
ok: [default]

TASK: [add yum repositories] **************************************************
changed: [default] => (item=epel.repo)
changed: [default] => (item=epel-testing.repo)
changed: [default] => (item=remi.repo)

TASK: [add rpm-gpg-keys] ******************************************************
changed: [default] => (item=RPM-GPG-KEY-EPEL-6)
changed: [default] => (item=RPM-GPG-KEY-remi)

TASK: [install PHP 5.5.x] *****************************************************
changed: [default]

TASK: [put zzmyphp.ini] *******************************************************
changed: [default]

TASK: [install supervisor] ****************************************************
changed: [default]

TASK: [put supervisord.conf] **************************************************
changed: [default]

TASK: [enable supervisor] *****************************************************
changed: [default]

PLAY RECAP ********************************************************************
default                    : ok=8    changed=7    unreachable=0    failed=0

[default] Running provisioner: serverspec...
....

Finished in 10.62 seconds
4 examples, 0 failures

さいごに

Vagrant と serverspec の相性が良いのは分かっていたのですが、vagrant up の後にいちいち rake spec を実行するのが面倒だなと感じていました。

vagrant-serverspec を使えば、プロビジョニングの後に自動で serverspec が実行されるので、構築とテストを一息で行うことができます。

仕様を決める、テスト書く、vagrant provision 、プロビジョニング書く、vagrant provision の流れはなかなか気持ち良いです。こうして検証済のプロビジョニングは、本番環境など Vagrant 以外の環境でも利用できますし、当然ながらそのテストも serverspec で行うことができます。

サーバ設定はわりと仕様が決まりやすく、テストが書きやすいと思うので、vagrant-serverspec を使って、テストドリブンなサーバ構築を行ってみて下さい。

参考

serverspec

jvoorhis/vagrant-serverspec

AnsibleWorks | Radically simple IT automation

Ansible - Provisioning - Vagrant Documentation

Shin x blog Advent Calendar 2013 の 23 日目です。

今年一年を振り返った時に、一番インパクトがあったのは Vagrnat でした。

昨年までも存在は知っていたものの、本質を理解しておらず、単に仮想マシンをコマンドで扱えるもの程度の認識でした。今年に入り、利用法が分かった後は、開発環境や検証環境などを構築するのに大いに役立っています。

Vagrant はパッケージとしてよく出来ており、それまで一部の人しか扱わなかった仮想化環境を多くの人に解放してくれました。ここでは、Vagrant の構成から、システムインテグレーションを行う上でのヒントを見出してみたいと思います。

既存技術をインテグレーションしたツール

まず、Vagrant で興味深いのは、基礎的な技術要素は、Vagrant 自身では提供しておらず、外部のソフトウェアやサービスを利用しているという点です。

仮想化環境にしても、プロビジョニングツールにしても、以前から存在しており、特段珍しいものではありません。これらを上手く組み合わせて、Vagrant という一つのツールとして扱えるようにしています。

Vagrant を知っても、すぐに触手が伸びなかった人（私も含めて）は、このインテグレーションしている部分が見えず、単に技術要素だけを見ていたのではないでしょうか。もちろん、技術要素が無ければ動作しないのですが、そこだけを見ていると本質を見誤ります。それらを組み合わせて、より良い使い方を提示しているのが Vagrant というツールです。

ある意味、技術要素は上手く隠蔽して、ツールの目的を果たせるような作りにするのが手腕の見せ所なのかもしれません。

実行環境を同梱

Vagrant 1.0.x の頃は、パッケージでのインストールの他に gem でのインストールも可能でした。もともと gem コマンドを使っている人にとっては便利なものですが、そうで無い人にとっては、まずは gem の環境を整える必要があり、インストールの障壁となる場合がありました。また、Ruby や gem のバージョンがユーザ毎に異なるので、その環境固有が問題が生じてしまいます。

そこで Vagrant 1.1 からは、Ruby の実行環境ごと Vagrant にパッケージングして、これさえダウンロードすれば、同じ環境で動くようになっています。これには、Vagrant 開発側が多様な環境をサポートする手間を削減するという面もありますが、ユーザとしても、自分の環境に Ruby があろうが無かろうが、そんなことは気にする必要が無く、ただパッケージをダウンロードして、インストールするだけで良くなりました。

実行環境が同梱できるかどうかはケースバイケースになりますが、ストレージやネットワークがリッチになった今では、こういった方針は、開発側、ユーザの双方にとってメリットになりますね。

メインの操作を vagrant up に集約

Vagrant で、一番行う操作は vagrant up でしょう。

このコマンドを実行するだけで、仮想マシンの構築から、プロビジョニングの実行を自動で行ってくれます。その裏では、Vagrantfile に書かれた情報を読み取って、仮想環境を作り、ベース仮想イメージを取得し、仮想マシンを起動。OS ブートが完了したら、プロビジョニングを実行して、仮想サーバの設定を行っています。

ユーザは、こういった一連の流れを意識することなく、複雑なところは Vagrant が連携するソフトウェアと協調して、良しなにやってくれます。これは非常に分かりやすい方法です。

Vagrantfile を利用するだけの人は、このコマンド（と halt / destroy などの基本的なコマンド）だけを覚えるだけで、Vagrant の恩恵を十二分に受けることができます。

また、Vagrantfile を書く側の人にとっても、操作方法がはっきりしているので、それに合わせて Vagrantfile やプロビジョニング設定の記述することになります。vagrant up するだけで全ての環境構築が完了するように設定を書いていくわけです。記述した Vagrantfile を管理する方法も、プロジェクトのソースコードと同じリポジトリに含めて、git clone して、vagrant up するという流れができるように行います。

こうして、主となる操作がはっきりしているので、使う側はそれだけ覚えれば良く、設定する側もそれに合わせて構築すれば良くなります。

vagrant up を打ち出して、これだけで環境構築ができます！と謳ったのは、Vagrant の本質を伝えるにはとても有効な手法だったと思います。

プラガブルなソフトウェアとエコシステムの利用

先に書いたとおり、Vagrant は多様な技術を組み合わせて使うツールなので、別システムとの連携が必須です。

Vagrant では、そういった外部ツールとの連携処理をプラグインで実装しています。利点は、もし新しい技術が登場した場合、Vagrant 本体は触らなくても、プラグインを追加すれば、利用が可能となるということです。プラグインは、gem パッケージにて配布できるようになっているので、有志によるプラグインが作られています。

gem パッケージで配布されているからといって、ユーザは gem を意識する必要はありません。プラグインのインストールには vagrant plugin というコマンドが用意されており、これを使うことで、プラグインのインストールやアップデート、アンインストールが可能です。

実際、仮想化環境、プロビジョニングツールは、プラグインとなっているので、Vagrant 本体に同梱されているもの以外にも、AWS や Digital Ocean 、Fabric など多くプラグインが公開されています。中には Vagrant 自体のパッケージに同梱されていくパターンもあります。

ソフトウェア自体はプラガブルにして、機能拡張が容易に行えるようにしています。プラグインの配布には、Ruby のエコシステムを利用して、誰もが開発したプラグインを配布できるようにしています。そして、ユーザにはそういった構成を知る必要は無く、単にいつものコマンドを使うだけで良いわけです。

さいごに

同じように既存の技術を組み合わせて、パッケージングしていると感じるのが、Docker です。これも lxc や aufs など、以前からある技術を利用していますが、それらを組み合わせて、コンテナベースの仮想マシンという形を作り上げています。エコシステムに関しては、まだ荒削りな面がありますが、これも次第に成熟が進んでいくと期待しています。

Vagrant が多くの人に受け入れられているということは、ある意味レゴブロック型プログラミングでも上手くやれば、多くの人に使ってもらえるようなものが作れるということを示唆しているように思います。個人的にはこの点でも Vagrnat や Docker は気になるソフトウェアで、今後何かを作っていく時のヒントにしていきたいですね。

Shin x blog Advent Calendar 2013 の 22 日目です。

「世界を変えたいんです！」

インターネット上やイベントなどでたまに見聞きする言葉です。それを聞くたびに何か違和感のようなものを感じていました。

世界を変える？

「世界を変えたい！」というフレーズは、威勢が良く、何か立派な志のように聞こえます。その想いは素晴らしいとは思うのですが、聞いている方からすると結局何がやりたいのかが分からず、「なんかすごいね」程度しか感じなかったりもします。

「世界を変える」ということは、変える前と変えた後の世界があり、その二つの世界には何かしらの差分があるはずです。この差分を作り出すこと = やりたいということであれば、その差分をそのまま伝えたほうが良いのではないでしょうか。

ガンで死ぬ人を無くしたい、飢餓を無くしたい、空飛ぶ自動車を作りたい、人型ロボットを作りたい、みんなが夢中になるゲームが作りたい、なんでも良いのですが、こういった具体的な「差分」ではなく、「世界を変えたい」というのはあまりに漠然としすぎていて、どうにもピンと来ないものがあります。

どの世界を変える？

変える対象の世界はどの世界なのでしょうか。地球上全てなのでしょうか。日本でしょうか。インターネット上でしょうか。それとも自分の会社？学校？コミュニティ？

世界を変える、と聞くと、地球上（で人間が住んでいるところ？）を指すことが多いような気がするのですが、よくよく内容を聞いてみると、実際はもっと狭い範囲だったりもします。

どこの世界をどうしたいのか、これも考えておく必要があります。

世界を変えたいのか、自分を変えたいのか

世界は、自分自身を通して見ているものです。世界という周囲を変えるのではなくて、自分自身が変わることで見える世界が変わるというのも良くあることです。

変えたいのは、世界ですか？自分ですか？

スローガン？

実際のところは、この言葉をスローガンやキャッチフレーズとして使っている例が多いように思います。

会社やコミュニティの代表者などが、一緒にやっている人を鼓舞したり、対外的なメッセージを発する時に使うパターンです。本当は具体的なものはありつつ、それを毎回話すのは大変だし、また意気込み、思いの強さを伝えるために、この言葉を使っているのかもしれません。

これは理解できるのですが、あまりに乱用すると、「結局、何をどう変えたいんだろ。」などと思ったりもします。

さいごに

実は、世界は何もしなくても変わっていきます。変化は少しづつで、かつ自分の望むような形になるかどうかは別にしても、変化はしていきます。

言葉尻だけを取れば、何もしなくたって「世界は変わる」わけです。

「世界を変えたい！」と思うなら、何か具体的に変えたいことがあるのではないでしょうか。もし、そうなのであれば、抽象的な表現ではなく、その具体的に変えたいことを伝えたほうが良いです。

そして、その具体的に変えたいことに向かってアクションを起こしていくことで、結果として、世界は「変わる」ものだと思います。

世界は「変える」ものではなく「変わる」もの、というのが近頃思うところです。

Shin x blog Advent Calendar 2013 の 21 日目です。

第 12 回関西 PHP 勉強会 にて、PHP 5.6 に採用予定の phpdbg をひと足先に PHP 5.5.7 で触ってみました。

phpdbg

phpdbg は、gdb ライクな PHP 用のデバッガです。ブレークポイントを設定して、その時点のコンテキストを確認したり、ステップ実行などができます。

phpdbg | php debugger

インストール

PHP 5.6 から同梱される予定の phpdbg ですが、これ自体はすでにリリースされており、PHP 5.4 から利用することが可能です。インストールには、PHP のソースコードが必要になるので、PHP も ソースからインストールします。

$ sudo yum -y groupinstall "Development Tools"
$ sudo yum -y install libxml2-devel
$ curl -L -o php-5.5.7.tar.bz2 http://jp1.php.net/get/php-5.5.7.tar.bz2/from/this/mirror
$ tar xvf php-5.5.7.tar.bz2
$ cd php-5.5.7
$ ./configure --with-readline
$ make
$ sudo make install

次に phpdbg をインストールします。ソースコードを git clone して、ビルドします。

$ cd /path/to/php-5.5.7/sapi
$ git clone https://github.com/krakjoe/phpdbg
$ cd ../
$ ./buildconf --force
$ ./config.nice
$ make -j8
$ sudo make install-phpdbg

Vagrantfile を gist をアップしたので、試してみたい方はどうぞ。

インストールすると phpdbg コマンドが実行できるようになります。phpdbg コマンドを実行すると、phpdbg のコンソールが表示されます。quit で phpdbg を終了できます。

help コマンドでコマンドのヘルプが表示されます。help run のように、help の後にコマンドを指定すると、そのコマンドのヘルプが表示されます。

phpdbg> help
[Welcome to phpdbg, the interactive PHP debugger, v0.3.0]
To get help regarding a specific command type "help command"
[Commands]
       exec     set execution context
    compile     attempt compilation
       step     step through execution
       next     continue execution
        run     attempt execution
       eval     evaluate some code
(snip)

phpdbg> help run
[Welcome to phpdbg, the interactive PHP debugger, v0.3.0]
Execute the current context inside the phpdbg vm

[Examples]
        phpdbg> run
        phpdbg> r
        Will cause execution of the context, if it is set.

Note: The execution context must be set, but not necessarily compiled before execution occurs
[Please report bugs to ]

簡単なサンプル

簡単な動作サンプルとして、下記の PHP ソースを phpdbg で実行してみます。

phpdbg コマンドに -e オプションを付けることで、デバッガで実行する PHP スクリプトを指定します。

$ phpdbg -e sample.php

まず、この PHP スクリプトのオペコードを表示してみます。compile コマンドで PHP コードをコンパイルします。

phpdbg> compile
[Attempting compilation of /vagrant/sample.php]
[Success]

print exec コマンドを実行するとオペコードが表示されます。exec オプション以外にも class や method などを指定することができます。

phpdbg> print exec
[Context /vagrant/sample.php]
    L0-0 {main}() /vagrant/sample.php
        L2      0x7fb5dfd24c68 ZEND_ADD                       C0                   C1                   @0
        L2      0x7fb5dfd24c98 ZEND_ASSIGN                    $a                   @0                   @1
        L3      0x7fb5dfd24cc8 ZEND_ECHO                      $a                                

次にブレイクポイントを設定してみます。break line コマンドを使って、3 行目にブレイクポイントを設定します。ブレイクポイントには、line 以外にも、func や method 、また特定のオペコードが呼ばれたタイミングでブレイクする op などを指定することができます。

phpdbg> break line 3
[Breakpoint #0 added at line 3]

コードを実行して、ブレイクポイントで停止するか確認します。コードを実行するには、run コマンドを実行します。ちゃんと設定した 3 行目で実行が停止しました。

phpdbg> run
[Attempting compilation of /vagrant/sample.php]
[Success]
[Breakpoint #0 at /vagrant/sample.php:3, hits: 1]
 00002: $a = 1 + 2;
 >00003: e

停止した時点での変数やリテラルを確認することができます。

phpdbg> info vars
[Variables in /vagrant/sample.php (1)]
Address         Refs    Type            Variable
0x7fc36cac3060  1       (integer)       $a

phpdbg> info literal
[Literal Constants in /vagrant/sample.php (2)]
|-------- C0 -------> [1]
|-------- C1 -------> [2]
|-------- C2 -------> [1]

next コマンドを実行するとコードの実行が再開されます。実行はオペコード単位になっているようなので、next コマンドを 2 回実行するとコードが終了します。

phpdbg> next
[Breakpoint #0 at /vagrant/sample.php:3, hits: 2]
 00002: $a = 1 + 2;
 >00003: echo $a . PHP_EOL;
  00004:
phpdbg> next
3

ジェネレータの動きを見る

次にジェネレータの動きを phpdbg で見てみます。PHP コードは下記です。

phpdbg コマンドを実行します。ブレイクポイントには、yield 文のオペコードである ZEND_YIELD を設定します。phpdbg のコマンドは、省略系で指定することができ、下記では、break op コマンドを省略して、b O としています。

$ phpdbg -e generator.php
(snip)

phpdbg> b O ZEND_YIELD
[Breakpoint #0 added at ZEND_YIELD]

run で実行します。設定したブレイクポイントで処理が停止します。

phpdbg> run
[Attempting compilation of /vagrant/generator.php]
[Success]
[Breakpoint #0 in ZEND_YIELD at /vagrant/generator.php:4, hits: 1]
 00003:     for ($i = $min ; $i <= $max ; $i++) {
>00004:         yield $i;
 00005:     }

next コマンドを実行するとステップ実行を行います。コマンドを入力せずにエンターだけを押すと、前回実行したコマンドがそのまま実行されます。この状態で、エンターを繰り返すと next コマンドが実行されます。

phpdbg> n
1
[Breakpoint #0 in ZEND_YIELD at /vagrant/generator.php:4, hits: 2]
 00003:     for ($i = $min ; $i <= $max ; $i++) {
>00004:         yield $i;
 00005:     }
phpdbg>
2
[Breakpoint #0 in ZEND_YIELD at /vagrant/generator.php:4, hits: 3]
 00003:     for ($i = $min ; $i <= $max ; $i++) {
>00004:         yield $i;
 00005:     }
phpdbg>
3
phpdbg>

さいごに

これまでも gdb や xdebug でデバッグを行うことができましたが、別途インストールや設定が必要でした。

PHP 5.6 から、phpdbg が同梱されることで、PHP が入っている環境では、手軽にこのデバッガを利用できるようになります。リモートデバッグにも対応しており、いずれ PhpStorm のような IDE でも対応されるかもしれません。

phpdbg 自体は 5.4 からインストール可能ですので、ちょっと試してみようという方はインストールしてみてください。

Shin x blog Advent Calendar 2013 の 20 日目です。

今年も色々な勉強会やイベントを開催したり、参加したりしたのですが、自分の中で、これが合うかも、という形が見えてきました。

それが「もくもく勉強会」というイベントです。

もくもく勉強会

もくもく勉強会は、もくもく会と勉強会を合わせた造語です。こういったジャンルがあるか分からないですが、もくもく会よりもきちんとしていて、勉強会よりもゆるいというイベントという意味合いで付けました。

実際には、「PHP もくもく勉強会」のように、テーマとする技術やプロダクト名などを付けてイベント名とするイメージです。

何をするかというと、詳細はイベントによって異なるとは思いますが、基本的には、参加者が自分で課題や作業を持ってきて、それをひたすらこなすというだけのイベントです。同じ会場には集まりつつ、みんな「黙々と」作業するので「もくもく会」ですね。

じゃあ、テーマを絞った「もくもく会」じゃないかと思うかもしれませんが、いわゆる「もくもく会」と違うのは、下記の自己紹介と成果発表を行うという点です。

自己紹介

イベントをはじめる際に、まず参加者全員が自己紹介を行います。自己紹介は名前と普段何やってるか程度で良いのですが、大事なのが、その日にどの課題に取り組むかを話すということです。

宣言する内容は、イベントのテーマに沿うものであれば、何でも構いません。ただ自分でやることを決めて、それを宣言します。

これには二つ意味があります。

まず自分自身への暗示です。自分がこれからやることをみんなの前で伝えることで、まずやるべきことが明確になり、何をするか悩んで無駄に時間を過ごすことが無くなります。次に、他の参加者へのアピールになります。正直、初めて合う人の名前だけを聞いても印象に残りにくいですが、これからやろうとする内容（概要）を聞くだけでも、あ、この人はこういった分野に興味があるのか、ということが分かります。もし自分もその分野に興味があったり、今日そのことをやるつもりだったのなら、声をかけるきっかけにもなります。

この自己紹介が、それぞれの人と話すフックというわけです。

あと付け加えると、全員が自己紹介できるくらいの人数が、このイベントの上限ということも言えるかもしれません。

成果発表

各自もくもくと作業をした後、イベントの最後に成果発表をします。

成果発表では、ちゃんとした発表資料など用意する必要はありません。（あっても良いですが）今日取り組んだ成果をデモしたり、ソースコードを出すなりで十分です。書いた blog を見せるでも良いです。読んだ本の感想でも良いです。また、自己紹介で宣言したことができていなかったり、途中で別のことをはじめてたりしても、全く問題ありません。ただ、今日やったことを話すということが大事なのです。

この発表を聞くことで、それぞれの人の印象をより強く付けることができます。その人がやったことが分かるわけですから、その後の懇親会などでも話題にしやすくなります。発表の際は、作業して分からなかったところや詰まったところ、苦労したところなどを加えると、他の人にとっても学びになります。自分ひとりで悩んで解決できなかったことを発表で話したら、アドバイスを貰って、それで解決したということが実際にありました。

作業中も後で成果発表することがわかっているので、ある程度のところまではやり遂げようという目標にもなりますね。

交流を促すきっかけ

こうしたイベントで参加者が一同に介するのは、その技術の話が聞きたい、話したい、知りたいといったことが目的だと思います。

しかし、それほど知らない人同士がただ集まって、話そうというのも中々勇気がいるものです。それなら、実際に作業をしつつ、画面を見つつで技術の話をした方が、格段に話しやすかったりします。「ここ上手くいかないんですけど、これってどうやってます？」と言われたら、コードを見せてもらった方が、話しやすくないでしょうか。

また、常に話し続ける必要も無いので、基本は自分の作業に没頭して、合間に誰かと話す、質問に答えるくらいのスタンスの方が気楽だったりもします。

こうして参加者同士で技術を触りながら、その話ができて、イベントが終わる頃には、自分が取り組んだ成果も残るわけです。いやあ、良いことづくめじゃないですか 😀

さいごに

今年の夏頃に始まった @omoon さん主催の RubyMotion もくもく会 in Osaka の会場として１×１を提供しているので、私も毎回参加しているのですが、これが実に面白いです。

それほど普段 RubyMotion を使っているわけではないのですが、この時ばかりは RubyMotion に集中して取り組みます。イベントの時間中は、これどうやるの？といった RubyMotion 自体の話や Ruby 言語の話はもちろん、開発に便利なツールやサイト、チュートリアルの紹介など、ざっくばらんな話をしながら、作業をやっています。中には「このイベントはスケジュール調整してでも参加します！」という人がいるほどです。

上記で紹介した自己紹介や成果発表は少しづつ形を変えながら現在の形になってきました。

この形は色々アレンジすることができ、時にはセミナーのような発表セッションを入れたり、皆で同じ課題をみんなで取り組むなど他のバリエーションも考えられます。

参加者同士が交流できて、手を動かして、そして何かしらの成果を持って帰るというイベントは楽しいです。わずか数人から開催できるので、気軽にやってみましょう。

Shin x blog Advent Calendar 2013 の 19 日目です。

2000年に個人事業として１×１を開業しました。それから 5 年後の 2005 年に有限会社として法人化（法人成り）を行いました。（その後、組織変更を経て、現在は株式会社です。）

個人事業から法人化した経緯や理由について書いてみます。

法人化への思い

当時、受託開発をメインに行っていました。仕事を受注して、家でこなすというスタイルが多かったのですが、仕事上で法人格を要求されることはなく、個人事業でも困ることはありませんでした。（今にして思えば、その時点で選別されていたのだと思います。）

開業した頃はとにかく食い扶持を稼ぐのに必死で、法人化など考えもしなかったのですが、ある程度、売上が立つようになると、「次のステップ」というのを考えるようになりました。

なんとなく、次のステップとしての法人化を意識しつつ、ただ必然性もそれほど感じないので、実行には至らないという期間がしばらく続きました。

法人化の理由

おかげ様で、色々なところからお声をかけて頂けるようになり、携わる案件もバリエーションが広がっていきました。携帯電話キャリア公式サイト構築やプロスポーツチームのシステム構築など、当時の自分としてはチャレンジし甲斐のある案件をこなすようになりました。

そうしたシステムを作っていると、いつも頭に浮かぶのがこの言葉です。

「もったいないなあ」

こうした面白いシステムを一人で作るのが、もったいなあ、と。

受注していた案件では、アーキテクチャの決定から全て任せて頂けることがほとんどだったので、要件に一番適していると思える技術を利用することができます。また、構築するのは多くの利用者がいるサイトだったので意気も挙がりますし、多数のリクエストを捌くための負荷対策なども行う必要がありました。

こうした経験はエンジニアとして大きな財産となります。座学も大事ですが、技術は適用して、そのフィードバックを得てこそ、身になります。もちろん、大変なこともありますが、そうした経験を積むことで、多角的な視野が広がり、技術を使う引き出しを増やすことができます。

私自身、こうした場を求めていたこともあり、実に多くのことを経験することができました。

一人でこうした経験をするのではなく、共に経験し、成長して、チームとして仕事がしたいと思うようになりました。

そして、チームを作る手段として、法人化を考えるようになりました。もちろん、個人事業のままで、チームを作ることも可能ですが、今ほどそうしたネットワークも無かった（自分は知らなかった）ので、法人化して、スタッフとして参加してもらって、一緒に成長していきたい、と。

つまり、チームとして一緒に仕事をするメンバーを集うために法人化した、というわけです。

さいごに

もちろん、節税のことや、より大きな案件へ対応できる、また自分たちのプロダクトを作りたいなど他にも理由はあったのですが、一番の理由はこれです。

この観点から言うと、今は、社外の人と一緒にチームとして仕事をするいうことがやりやすくなったように思います。これは、色々なことを経験して私自身の考えが変化したこともあるでしょうし、これまでの活動を通じて、多くの人と出会えたというのも大きいです。

チームとして仕事をしたいという想いは今も変わりません。ただ、それは「雇用」という形では無くても良いのではないか、というのが最近考えているところです。

Shin x blog Advent Calendar 2013 の 18 日目です。

ChatWork API のプレビュートークンを頂いたので、早速使ってみました。

今回作ったのは、電話をかけて音声で伝えたい人と、電話はかけて欲しくない、チャットで要件伝えて下さい、という人を繋ぐものです。

Twilio と ChatWork を使って留守番電話

これは、Twilio と ChatWork を使い、電話がかかってきたら、チャットで着信を知り、録音された音声が聞けるというものです。いわば留守番電話をチャットから聞くという感じですね。

全体の流れは下記の図になります。

ソースコードは GitHub にて公開しています。

shin1x1/twilio-chatwork-voice-message

Twilio との連携

まず、かかってきた電話を Twilio で受けます。Twilio では、着信した電話番号に対して、あらかじめ登録した URL へ HTTP リクエストを投げるので、これをこのアプリケーションで受けます。

下記が Twilio からのリクエストを処理するコードです。Twilio へは、TwiML という XML を返すことで、電話に対する操作を指定します。このコードでは、音声メッセージを流して、録音を行うことを Twilio へ指示しています。また、録音が完了すると、recoreder.php へリクエストを投げるようにしています。

ChatWork との連携

Twilio での録音が完了すると下記のコードへリクエストが来ます。このリクエストでは、録音された音声ファイルの URL が送信されてくるので、これを ChatWork API を使って、チャットメッセージとして送信します。

動かしてみる

実際に動かしてみます。Twilio で取得した電話番号に電話をかけます。

録音を促す音声が流れるので、メッセージを電話で話します。伝えたい内容を言い終わったら、# を押して下さい。

すると、着信があったことを伝えるチャットメッセージが、ChatWork へ送信されます。チャットメッセージには、URL が付いているので、これをクリックすると、録音された音声を聞くことができます。

さいごに

Twilio も ChatWork も API が公開されており、連携も簡単でした。

これならば、電話で要件を伝えたい人は電話をかけられ、聞く側は ChatWork で着信を知って、要件を音声で聞くことができます。電話を置かない会社さんでも電話番号を公開できますね;-p

Shin x blog Advent Calendar 2013 の 17 日目です。

「プログラマーには 2 つのタイプがいる。ブロックを作るか、使うか、だ。」

レゴブロック型プログラミング

プログラミングをやるようになって、思ったのは、部品を組み合わせていく感覚が、子供の頃、夢中になって遊んでいたレゴブロックに似ているなあということです。

ブロック（部品）は多数用意されており、それらを組み合わせることで何かを作っていきます。ただプラモデルなどと違うのは、何度でもバラして、また組み直せるということ、そして、ブロックはプリミティブなものであり、組み合わせ方によっては全く異なるものを作ることもできます。

扱う言語や環境によって、そのブロックの粒度は変わっていきます。C がレゴブロックなら、LL は、ダイヤブロックくらいかもしれません。ただ、それらを組み合わせて何
かを作るということは同じです。

ブロックの粒度が大きくなる

ブロックの粒度は次第に大きくなっていきます。構文や標準関数の大きさだったものが、それらを組み合わせたライブラリを大きなブロックとして使うようになります。

次はライブラリとしてではなく、その機能に特化したソフトウェアと連携して動かすようになります。例えば、データの保存処理をライブラリを使って行っていたものを RDBMS に切り出して、それに特化した処理は全て任せてしまうという具合です。

そして現在では、そのソフトウェアを自らセットアップする必要もなくなり、SaaS として提供されるようになりました。データベースであれば、RDS や Heroku Postgres のようなものです。

こうしてブロックの粒度は次第に大きくなり、またその調達コストも低下していっています。

粒度の大きいブロックは組み合わせるパターンがある程度限定されるので、自由度は下がりますが、扱いやすいとも言えます。反対に粒度の小さなブロックは、組み合わせパターンが多くなるため、自由度は上がりますが、その分扱いが難しくなります。

問題にあったブロックを探し、組み合わせる

そこで、解決すべき現実の問題にどのブロックを使い、どう組み合わせるのかという考えが必要になります。

先ほど書いたように、ブロックを調達することは容易です。とくにクラウドサービスの拡充により、以前では考えられないようなコストと時間でブロックを調達できるようになりました。

ただ調達は容易ですが、どのブロックを調達するのかを決めるにはそもそもブロックを知っておき、どの問題にフィットするのかを把握する必要があります。

調達した後も、それをどう組み合わせるのかを考え、時にはブロックを加工したり、フィットするブロックが無ければ、より細かな粒度のブロックを使って作る必要もあるでしょう。

大小様々な粒度のブロックが増えた今だからこそ、ブロックを選定し、組み合わせるのかという技量が重要になってきているのだと思います。

さいごに

冒頭の話でいうと、私は「ブロックを使う」側の人間だと思います。もちろん必要な場合はブロックを作りますが、それより、すでにあるブロックを組み合わせて、問題を解決するという方向が好みです。

総論的なブロックの選定に関する情報はインターネットや書籍でも見つかるのですが、個々の問題を解決するためのブロックをどう見つけるか、というのは当然ながら当事者が個々でやるしかありません。

近頃は、こうした個々の問題にフィットするブロック探しや組み合わせ方の模索を支援する仕事が面白いなあと感じてたりします。