Shin x blog

今年もやって参りました年末を彩る PHP Advent Calendar 2012 です。3年目ということですっかり恒例行事となってきましたね。今年も完走目指してみんなで頑張りましょう！

参加枠があとわずかですが残っていますので、いっちょやってみようという方は参加表明をお願いします。

• PHP Advent Calendar

さて、初日は前から書いてみたかったテーマです。

PHPをWebシステム開発言語として使い出してかれこれ12年が経ちました。これだけ長い間使い続けているとうことは何か理由があるわけです。そこで、あらためてその理由を考えてみました。

1. 安定して動作する

まず、なんと言っても大きいのが安定して動作し続けているということです。
規模の大小に関わらず数多くのWebサイトがPHPで動作しているのは周知のとおりです。私がこれまでPHPで構築してきたWebシステムが現在でも動作しており、これまでPHP自体が原因で障害が発生した、ということはほぼありません。

どんなに素晴らしい言語であっても動作環境が不安定では意味を成さないので、これは当たり前ですが大事なことです。

2. 環境構築が楽

Apache と mod_php を入れれば動作します。めちゃ簡単。下記コマンドを叩けばインストール完了。あとはPHPファイルをサーバにアップすれば、それで動きます。

$ sudo yum install httpd php

開発環境限定ですが、PHP5.4以降であれば、ビルトインサーバがあるので Apache すら必要ありません。

$ php -S 127.0.0.1

3. 手軽に書ける

HTMLのテンプレートから出発した言語だけに、HTML内に埋め込んで書くのは何の苦労もありません。

<?php if ($isDisp): ?>
  表示する
<?php endif; ?>

プログラマではないデザイナさんやコーダーさんもPHPであれば多少書ける人が多いです。ビュー側の簡単な改修であれば、わざわざプログラマ側で対応せずともデザインの延長で対応してもらえることが多いです。

また普段使っていると忘れがちですが、日本語を扱うのに何の苦労も必要ありません。実はこれは大きいことで、2000年当時だとPHP3国際化版があったおかげで、日本でPHPが普及したといっても過言ではないと思います。

4. HTTPリクエスト毎にスクラップ&ビルド

PHPではHTTPリクエストを受けて起動するたびにソースコードのコンパイルを行います。コンパイルで生成された実行コードで処理を行い、終了すれば実行コードごと破棄します。各 HTTP リクエストは独立して実行されるので、別のリクエストの処理が干渉することはありません。

これにより、ひとつのHTTPリクエスト内で行う処理に集中して実装することができます。

この一見すると重そうな処理が実用的なスピードで動作しています。

ちなみに apc などのコードキャッシュを使えばコンパイルした結果の実行コードをキャッシュすることができ、パフォーマンスを向上させることができます。デフォルトではアプリケーション内の値はキャッシュされないので、HTTPリクエスト毎の独立性は保たれています。

5. 豊富な機能、ライブラリ、プロダクト

PHPにはWebシステム開発に便利な機能が数多く提供されています。

標準関数の充実っぷりはもちろんですし、PECLで提供されている拡張モジュール、PEARやComposerで公開されているオープンソースのライブラリ、CakePHPやSymfony2、FuelPHPなどのフレームワーク、テスティングツールPHPUnit、WordPressやDrupalなどのCMS、EC-QUBEやMagentoといったECサイト、OpenPNEのようなSNS、他にもWebに特化した数多くのライブラリやプロダクトがあります。

OAuth などの新しい仕組みが登場してもすぐにそれを利用するライブラリなどが登場します。

オブジェクト指向としての機能もあり、いまどきの開発プロセスをこなすことができます。

Webシステム開発で必要な機能はひと通り揃っていると言って良いでしょう。

6. 情報が多い

ユーザが多いからこそですが、書籍やblogなどで数多くの情報が公開されています。

自分が情報やコードを公開した時も多くの反応をもらうことができます。これは使っていくモチベーションになりますね。

7. 仕事に使える

仕事に使える（使っている）のはやっぱり大きいですね。

これには安定性、実績、そして他の人とコラボレーションしやすいなどがあります。

また開発者以外の人にも認知度が高いので導入において支障になることもほとんどありません。

8. 最近のPHP

最近の PHP は言語の機能拡張が盛んで、ここ最近のバージョンでは以下のような機能が追加されています。

• namespace(5.3)
• closure(5.3)
• traits(5.4)
• short array syntax(5.4)
• array dereferencing(5.4)
• generator(5.5予定)
• finally(5.5予定)

もう今となっては当たり前ですが、5.2以前には匿名関数を定義するにはcreate_function()を使うしかなく、これが結構書きづらかったので、closureを自然に書けるようになったのはやっぱり嬉しいですね。

array_walk($values, function($v) {
  echo $v;
});

これらの機能がないと絶対にダメということは無いのですが、やっぱりこういった他の言語で良いとされている機能が盛り込まれるのは単純に嬉しいですし、使うのが楽しくなります。

• 6分でわかる最近のPHP – 2012夏
• 5分でわかる最近のPHP – 2011夏

9. 充実した公式マニュアル

良くPHPの特徴して挙げられますが、やはり公式マニュアルの充実っぷりは素晴らしいです。

日本語への訳も適時行われていますので、頭が下がるばかりです。

www.php.net

10. 慣れている

これを書くとPHPじゃなくてもええやん、という話になりますが、やっぱり慣れているというのは大きいです。

使い方、書き方、ハマりどころ、色々分かっていて、安心して使えるのでやはり選択することが多くなります。

11. PHPの思想

PHPはシステムを作るためのツールの一つとして認識しています。

現状はPHPを選択することが最も良いと思っていますが、状況が変わって、別の言語が良いと思えば、そちらの言語を選びます。何が何でもPHPというわけではなく、置かれている状況から判断して、あえてPHPを選択しています。

PHPコミュニティにいる人はこういった考えの人が多い印象です。

別にPHPしかできないからPHPを選んでいるわけではなく、別の言語も知っているし、書けるけど、PHPを選んでいるというわけです。

また、システムを作る、そしてそれを動かすということにフォーカスしている人は、その周辺の知識（サーバやインフラ、またテストなど）にも明るい人が多いです。プログラミング言語だけを見ているわけではなく、システム全体の中の一部としてPHPを捉えています。
（小さい案件などで全部やらざるを得ないという事もありますが）

これはシステム寄りではなくデザイナさんやコーダーさんも同じで、デザインやサイトの一つのツールとしてPHPを見ているという感じだと思います。

ここでPHPの父ともいうべき Rasmus Lerdorf さんの発言を引用しておきます。下記では、PHPを歯ブラシに例えて、あくまでツールと言い切っています。これはまさにPHPの思想ですね。

PHP is about as exciting as your toothbrush. You use it every day, it does the job, it is a simple tool, so what? Who would want to read about toothbrushes?
Interview – PHP’s Creator, Rasmus Lerdorf

12. コミュニティ

PHP コミュニティもPHPの魅力の一つです。 多様な人がいて、多様な活動をされています。いつも本当にお世話になっていますm(_ _)m

自分がいつも接していて良いなと思うのは、他の言語を貶めたり蔑むような発言をする人がいないということです。プログラミング言語の機能や思想について指摘したり、自分とは合わないといった発言をすることはもちろんあります。好き嫌いなどがあるのも当然です。

ただ、その言語を使っているというだけで晒すようなことはありません。

あくまでプログラミング言語はツールとして割り切っているからという面もあるでしょうけど、これはとても素晴らしいことだと思います。

PHPユーザがあえて煽る言語がPHPという自虐的な場面はたまに見ます:D たいてい愛情表現の一つだと思っていますけど、これからは恥ずかしがらずにPHP好きと言っちゃいましょう。

まだまだPHPです

たまにこんなことを聞かれることがあります。

「まだPHP使っていても大丈夫ですか？」

PHPがWebでメインストリームな時代が長いので、根拠は無くとも漠然とした不安を覚える人がいるようです。

現時点であれば、私ならこう答えます。

「はい、PHPで大丈夫ですよ。」

参考リンク

• PHP開発者 Rasmus Lerdorf氏インタビュー ～PHPは「利己的」な開発者の集まり：NEWS & REPORT｜gihyo.jp … 技術評論社
• Interview – PHP's Creator, Rasmus Lerdorf – SitePoint
• PHP: Dis Is It

「JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)」を献本して頂いたので読んでみました。

普段は PHPUnit でテストを書いているので、その本家とも言える JUnit の本は興味津津でした。

実は、今でこそ PHP 三昧の日々ですが、数年前（JDK1.3 とか 1.4 の時代ですが）は Java で開発していたこともあったので、いまどきの Java、JUnit がどうなっているか知りたくもあり、興味深く読み進めることができました。

読んでみて感じた点を挙げてみます。

1. 圧倒的なボリューム

まず目次をざっと見た時に感じたのがカバーしている範囲の広さです。正直よく一冊に収まってるなあと:D

JUnit の解説からはじまり、JUnit を使ったテストの書き方、ソフトウェアテスト・テスト技法、ユニットテストのパターン、そして JUnit のより発展的な利用方法とつづきます。

さらにより実践的な内容として、モックやスタブ、スパイ（Mockito）、データベース（DbUnit）そしてAndroidアプリのテストの書き方があります。これで十分 JUnit の本となる気がしますが、まだ終わりません。

この後、継続的テストを行うために、Mavenや 各種 VCS 連携、Jenkinsと来ます。

もうお腹いっぱいと思ったところで、とどめにテスト駆動開発、振舞駆動開発が来て、さらに18問にも及ぶ演習問題と開発環境のセットアップやEclipseの便利機能が含まれる付録で締めとなります。

450P でこれだけの内容がギュッと詰まってます。

さらに本書でカバーできない、より深い内容については、ちゃんと参考文献が紹介されています。

いや、ほんとすごい。

2. Eclipse + JUnit 環境構築の解説が嬉しい

日頃、Java を書いてない人間からするとまず面倒なのが環境構築。

本書では JDK から、Eclipse、JUnit、そして QuickJUnit などのインストール方法が付録にまとめられています。たまにしか Java を触らないので、こういうステップバイステップで環境が構築できる解説は嬉しいですね。

迷うこともなく簡単に環境構築ができました。

本書には書いてませんが、Vim 派の人は「Vrapper」を入れると幸せになります。

3. 演習内容が多い

テストの概念や用語の解説といった基礎的な解説はもちろん書かれていますが、それは必要最小限に抑えられており、それよりも実際にテストを書きながら学んでいくということに重点がおかれているように感じました。

普段テストを書いているので、概念的なことはおさらいとしてざっと読んで、実践的な箇所を試して学習していくという流れで読んでいきました。

やっぱりテストは書いて習得していくものだと思うので、これは大事です。

4. いまどきの JUnit

私が知っている JUnit が古いということもあるかもしれませんが、最新の JUnit4 の記法を用いて解説が書かれているので、いまどきのテストの書き方を知ることができました。

これまで大きく変わっていると感じたのは以下です。もしかすると PHPUnit もいずれはこういった変更が行われるかもしれませんね。

4.1. TestCase クラスを継承しない

テストクラスでは、TestCase クラス（PHPUnit なら PHPUnit_Framework_TestCase クラス）を継承するのが当たり前だと思っていましたが、本書のサンプルではどのクラスも継承しておらず、POJO となっていました。

これによりどんなクラスでもテストクラスとして実行することが可能になったので、より柔軟にテストが書けますね。

4.2. assertThat によるアサーション

これまでアサーションメソッドといえば、assertEquals や assertTrue などでしたが、本書では、汎用的に利用できるアサーションメソッドとして assertThat が使われていました。

変わったと感じたのは引数の順番です。

従来（PHPUnit）のアサーションメソッドでは下記のように「期待値」「実際の値」という順番で引数をセットしていました。

$this->assertEquals($expected, $actual);

これが assertThat では一見すると「実際の値」「期待値」という逆の順番になります。（さらに期待値はMatcherオブジェクトを指定します。）

assertThat(actual, is(expected));

これは「assert that actual is expected」という英文となるように、だそうです。

4.3. @Rule アノテーション

JUnit4.7 から追加された @Rule アノテーションについても解説されています。各テストの前処理や後処理などを共通処理として定義できる機構です。

例えば JUnit で提供されている TemporaryFolder を使うと下記のような記載をするだけで、テストメソッド内で利用できる一時フォルダが作成され、テストが終了すると自動でフォルダが削除されます。

これもいずれ PHPUnit に欲しい機能です。

@Rule
public TemporaryFolder tmpFolder = new TemporaryFolder();

5. 18問の演習問題

実際にテストを書いて学べる18問の演習問題が付録に付いています。

この演習問題には、問題だけではなく、テスト対象クラスの設計方法やテストケース、そして実際のソースコード、最後に解説と丁寧に書かれています。

それぞれの問題をこなしていくと JUnitや周辺ライブラリを１つづつ試せるような構成になっているのが心憎いです:D

実際に JUnit で書いてみるのはもちろんですし、さらにこの問題を PHPUnit で書くならどうするか、というような発展的な使い方もできそうです。（そんな勉強会をやっても良いかも）

何問かやってみたのですが、最後の「Hello World のテスト」は下記のように書くと簡潔に書ける気がしました。

ユニットテスト書くなら一読の価値あり

本書は JUnit を題材にした本なので、Java を書く人がメインターゲットだと思うのですが、テストを書くという行為や考え方はどの言語でも共通なので参考になる人は多いと思います。

ここまでテストについてまとまっている日本語の本は少なくとも PHP には無い（あったら教えて下さいm(_ _)m）ので、普段 Java を書かない人も本書でいまどきの Java や JUnit を試してみてはどうでしょう。

あ、Java な人は必読で:D

CentOS5.8 で Postfix + Cyrus SASL で SMTP AUTH を設定したのでメモです。

0. 環境確認

Postfix はあらかじめインストールされていました。

$ sudo rpm -qa | grep postfix
postfix-2.3.3-2.3.el5_6

Postfix でサポートしている認証方法を確認します。。今回は cyrus を使うので ok。POPとアカウントを共有するなら dovecot を使います。

$ /usr/sbin/postconf -a
cyrus
dovecot

Cyrus SASL パッケージは以下がインストールされています。

$ sudo rpm -qa | grep cyrus-sasl
cyrus-sasl-lib-2.1.22-7.el5_8.1
cyrus-sasl-2.1.22-7.el5_8.1

1. Cyrus SASL インストール

Cyrus SASL パッケージはインストールされていましたが、個別の認証処理を担うパッケージがインストールされていなかったのでインストールしておきます。

$ sudo sudo yum -y install cyrus-sasl-md5

PLAIN 認証を使うなら以下もインストールします。

$ sudo sudo yum -y install cyrus-sasl-plain

2. Cyrus SASL パスワード設定

今回は Unix ユーザではなく、Cyrus SASLパスワードファイルで認証するので、saslpasswd2 で、アカウントを追加します。
-c でアカウント追加、-u でドメイン（example.com）、そしてユーザID（user）を指定します。SMTPクライアントからは、ここで入力したユーザIDとパスワードで認証します。
なお -u で指定したドメインは realm として Postfix の設定と揃える必要があります。/etc/postfix/main.cf で $mydomain に指定しているもので良いでしょう。

$ sudo /usr/sbin/saslpasswd2 -c -u example.com user
[パスワードを入力]

パスワードファイルを postfix ユーザが参照できるようにしておきます。

$ sudo chown postfix /etc/sasldb2

3. Cyrus SASL 設定

Cyrus SASL での認証方法を /usr/lib/sasl2/smtpd.conf に設定しておきます。
今回は saslauthd ではなく、Cyrus SASL パスワードファイルを利用するので、pwcheck_method を auxprop に変更します。

$ sudo vim /usr/lib/sasl2/smtpd.conf
#pwcheck_method: saslauthd
pwcheck_method: auxprop

4. Postfix 設定

最後に Postfix で SASL 認証を有効にします。設定は /etc/postfix/main.cf に追加します。

$ sudo vim /etc/postfix/main.cf
# SMTP AUTH
smtpd_sasl_auth_enable=yes
smtpd_sasl_local_domain=$mydomain
smtpd_recipient_restrictions=
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination
smtpd_sasl_security_options=noanonymous,noplaintext

各パラメータの意味は以下になります。

• smtpd_sasl_auth_enable=yes

  SMTP サーバ で SASL 認証を有効にします。

• smtpd_sasl_local_domain=$mydomain

  SASL 認証 realm を指定します。saslpasswd2 の -u で指定したものと同じ値にします。この値が一致しないと認証できません。

• smtpd_recipient_restrictions

  SMTP サーバが RCPT TO コマンドで適用するアクセス制限。指定した制限が有効になります。
  デフォルトでは permit_mynetworks と reject_unauth_destination が有効になっているので、SASL 認証に成功した要求を許可するために permit_sasl_authenticated を追加しています。

• smtpd_sasl_security_options=noanonymous,noplaintext

  SASLセキュリティオプションを設定します。noanonymous では匿名認証を許可しません。noplaintext では平文パスワードによる認証（PLAIN認証）を許可しません。

  （Outlook Express では平文パスワードのみサポートしてますので、クライアントとして利用する場合は noplaintext を削除する必要があります。平文パスワードを利用する場合は TLS 対応を設定して通信経路を暗号化した方が良いでしょう。）

5. Postfix を再起動

設定を有効にするために Postfix を再起動します。

$ sudo /etc/init.d/postfix restart

6. 動作を確認する

telnet で 25 port にアクセスして、SMTP AUTH が有効になっているか確認します。

$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 example.com ESMTP Postfix

EHLO a を入力します。

EHLO a
250-example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5
250-ENHANCEDSTATUSCODES
250 DSN

AUTH 行にて認証方式が表示されます。これで SMTP AUTH が有効になっていることが確認できました。

あとは SMTP クライアントでSMTP AUTH関連の設定をして送信ができるかテストします。

7. エラーメッセージ

設定して動作確認していた際に上手く動作せずに /var/log/mail.log に記録されたエラーです。参考まで。

Cyrus SASL パッケージ不足

warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
fatal: no SASL authentication mechanisms

cyrus-sasl-md5 や cyrus-sasl-plain がインストールされていなかったために発生しました。yum でインストールして解決です。

SASL パスワードファイルの権限不足

warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: Permission denied

SASL パスワードファイル（ /etc/sasldb2 ）に postfix ユーザの読み込み権限が無かったために発生しました。chown で postfix ユーザを所有者にて解決しました。

参考

http://www.postfix-jp.info/trans–2.3/jhtml/SASL_README.html

共著で執筆に参加した「CakePHP2 実践入門」が2012/09/29に出版されました。

2007年に執筆した「CakePHPガイドブック（共著）」から数えて4冊目の書籍執筆となるのですが、執筆の方法やコラボレーションのツールも大きく変わりました。執筆を終えて一息ついた今、執筆環境を振り返ってみたいと思います。

2007年と今回の執筆環境をざっくりと比較するとこんな感じでした。

	原稿執筆	原稿提出	連絡	issue管理	CI
2007年	Word	FTP	ML	ML	なし（Wordで確認）
2012年	Vim + Marked	Github	Facebookグループ	Github	Githubリポジトリをpollingして、Markdown+独自マークアップをHTMLにコンバートなど。

原稿執筆

原稿は Vim で書いて、Marked のプレビューを確認するという形で進めました。

Vim

原稿の形式は、Markdown＋独自マークアップのプレーンテキストだったので、執筆陣は各自好きなツールを使うことができました。

Vim は普段から使っていて慣れていますし、技術本ということでソースコードを読んだり書いたりする場面が多いので同じエディタ上でそれができるのは楽でしたね。

Markdown ということで当初は専用のエディタなども試したのですが、やはり「書く」という行為に関しては手に馴染んでいるものが一番です。

Marked

Marked は Markdown 形式で書かれたファイルをプレビューするツールです。Marked でファイルを開いておくと元ファイルが変更されるとプレビュー側も連動して更新されます。

あくまでプレビューに特化したツールなので任意のエディタと組み合わせて使用することができるのが良いですね。

実は Vim + Marked の組み合わせが気に入ったので、この blog も同じ構成で書いています。

以前は Word だったので、プレビューという点では問題無いのですが、ソースコードが書きにくかったり、差分が取りづらかったりしていました。当時はそれが当たり前だと思っていましたが、やはりプレーンテキストで書けるのは慣れてる分、楽でした。

原稿提出、issue管理

Github

原稿提出やissue管理にはGithubを使いました。

執筆陣は各々原稿を書いて、Github へ push して原稿を提出するという流れでした。

git のメリットは言わずもがなですが、こちらも日常でソースコードを push するのと同じ感覚で原稿を提出できたのは良かったです。さらに原稿がプレーンテキストということで、差分を確認したり、変更履歴を見たりというのもお手のものでした。

今回は章ごとに執筆者が決まっていたので、conflict することも無いだろうということで、ブランチ分けはせずに master へpushしていました。

原稿の修正依頼や査読結果などの issue 管理も Github で行なっています。

Github の issue 管理では、commit ログに issue no を記載することで issue チケットから commit にリンクを貼ることができるので、issue に関する修正が明示できて、これは便利でした。

本書のサンプルコードもGithub上で公開する予定ですので、書籍を購入された方はご参照下さい。

連絡

Facebook

編集の方、執筆陣との連絡には Facebook グループを使いました。

ML でも良かったのですが、メールより気軽に投稿、返信ができたのでやりやすかったです。返信するほどではないけど同意や見たことを現したい時に「いいね！（Like）」で反応できるのは手軽で便利ですね。

ただ Facebook グループだとどうしても過去の発言が流れて行ったり、一つのトッピクについてコメントが大量についたときに見づらかったりするので、もし次回があればchatworkなど別のコラボレーションツールの方が良いかもしれません。

CI

CI 的な機能もいくつか用意しました。

Githubのリポジトリをpollingしており、定期的に自動実行されます。

• PHPコードの自動lint（安藤さん作）
• 原稿中のソースコード自動抽出（安藤さん作）
• 原稿をHTMLへ自動変換、変換ブラウザで閲覧可能に（鈴木さん作）
• 原稿の規約（マークアップや一行文字数等）を検証して、エラーログを出力（鈴木さん作）

特に鈴木さんが用意してくれた原稿をブラウザで確認できるツールはかなり便利でした。書式エラーなどがログとして確認できるので、これを活用して原稿の修正を行いました。いずれ公開されると思うので乞うご期待を。

今にして思うと Jenkins でこういったツール群を管理しても良かったですね。

普段のシステム開発と同じリズムで原稿を書く

今回利用したツールはどれも普段のシステム開発で利用しているもので、ソースコードを書くのと同じリズムで執筆を進めることができました。

執筆期間中に度重なるCakePHPのバージョンアップ（2.0 -> 2.1 -> 2.2）があり、リスケを余儀なくされましたが、原稿のデグレや issue の取りこぼしもなく、無事に書店に並べることができました。

CakePHP は、公式ドキュメントである cookbook が充実しており、和訳も少しづつ進んでいるのですが、日本語で書かれたまとまった情報を望む声が多くありました。この本はそういった機運を受けて執筆されました。みなさんのCakePHP開発の一助になればと思いますので、一度手にとって頂ければ嬉しいです。

最後に、セキュリティ章について丁寧な査読、ご指摘をして頂いた徳丸浩さんにお礼を言いたいと思います。本当にありがとうございました。

TwitterやFacebookは楽しいし便利なんですが、つい見過ぎてしまうのが玉にキズです。PC で作業中はもちろんのこと、外出中でもスマートフォンでついつい見てしまいます。

常に見る必要は全くもって無いので、外出時に持ち歩くデバイスからはアクセスできないようにしてみました。

1. Facebook / twitter に接続できないようにする

まずは、いつも持ち歩く MacBook Air から。

/etc/hosts に以下を追記して保存します。これで www.facebook.com / twitter.com に接続できなくなります。

% sudo vim /etc/hosts

127.0.0.1 www.facebook.com
127.0.0.1 twitter.com

2. スマートフォンからアプリを削除

スマートフォンからも Facebook / Twitter クライアントアプリを削除しておきます。

3. でも投稿はしたいし、Reply や DM くらいは見たい

外に出て何か見つければ投稿したいのが人の常。そんな時に便利なのが yabmin というサービス。

yabmin

メールを使った Twitter クライアントで、メールを送信するだけで投稿したり、Reply や DM がメールで送られてくるという優れもの。

Twitter アプリを開くとついついタイムラインを見て時間が過ぎてしまうから、投稿だけできるというのは便利。

Facebook でもこういうサービスがあると嬉しいな。

Facebook / Twitter は、ほどほどに付き合うのが肝要ですね。あーすっきり。

WebサービスのMVP（必要最小限の製品）を作るのに参考になるTipsがあったのでご紹介。

via How To Create A Minimum Viable Product | TechCrunch

1. Facebook

会員情報を一から作らずに Facebook を利用しましょう。

Facebookユーザでない人をどうするか？という指摘もありますが、元エントリにある「いまどきFacebook使っていない人は保守的だから、（自分たちが作っている）新しいWebアプリは使わないだろう。」という考え方は一理ある気がします。

2. Twitter Bootstrap

手間をかけずにそれなりの見た目になり、レスポンシブにもなるので、素早くサービスを作るために活用したいですね。

Bootstrap

3. クラウド

最近は使うのが当たり前になってきたクラウドです。初期費用無料で、従量課金なのは先が不明確なスタートアップ向きです。

元エントリでは、Amazon S3 や heroku が紹介されています。

IaaS の自由度も良いのですが、できるだけ手間を省くという意味では、やはりデプロイやスケールアウト（アップ）が容易な PaaS が向いてると思います。

4. jQuery

まあこれも普通ですね。スタートアップに限らず多くのWebアプリケーションで使っています。

5. コアの機能にフォーカスする

余計な機能は作らずにサービスとしてコアな機能をまず作ってリリースします。まさに必要最低限の製品（MVP）です。

元エントリでは、実装しようとする機能が必要されているかどうかを確かめる方法として、新機能のリンクだけを用意しておいて、それをクリックした人が何人いるかで判断する方法が紹介されています。

MVP の概念は「リーン・スタートアップ」が参考になります。

6. SaaS

それぞれのニーズに特化した SaaS があるので、それらを活用しましょう。

元エントリでは目的に応じたSaaSが紹介されています。海外のサービスばかりなのですが、考えてみると日本ではこういったサービスは少ない気がしますね。これは提供するチャンス？

請求

• Chargify
• Spreedly
• Recurly
• CheddarGetter

ユーザサポートチャット（ライブチャット）

• LiveChat
• olark
• Zopim
• LivePerson
• SnapEngage

フォーム

• Wufoo
• Google Apps

ウェブ解析

• Kissmetrics
• mixpanel

ユーザサポート

• ZenDesk
• desk.com

データ解析

• GoodData
• RJ Metrics

7. 動画

百聞は一件にしかずです。

サービスの内容や機能をテキストで詳細に書くよりも、実際に使っている動画を見せる方が遥かに分かりやすいです。

最近は色々なサイトで製品紹介の動画が使われていますが、有名なのはDropboxですね。この動画を公開して、ベータ版の予約数が5000から75000に増えたそうです。

クォリティの高い製品紹介動画を自分たちで作るのは大変なので、できれば専門の業者さんに依頼したいとことです。Quora に色々な業者さんの動画と費用が載っていて参考になります。

Where do most startups get their product demo videos made? How much do they cost? – Quora

日本でもこういった動画を作ってくれるところがあると嬉しいですね。

8. Internet Explorer

何かと話題（と手間を）を提供してくれる Internet Explorer ですが、コストと時間を節約するならいっそのこと Internet Explorer 対応をやめてしまうのも手です。

特に製品のターゲットユーザが先進的なユーザなら、chromeやFirefox を使っているでしょうから、全体のシェアよりもこれは合理的な判断かもしれません。

9. 今、必要な機能に絞る

作る側としては便利な機能はどんどん盛り込みたいところですが、本質では無い機能（例えば、ユーザ退会や何か登録の削除など）は初期リリース時は実装せずにメールで依頼してもらって、運営側で対応するという方法も考えられます。

どれだけ使われる機能かも分からないので、ユーザが増えて運営の手間がかかってきた段階で実装する方が良いでしょう。

コアに集中する

ざっと見ると、ライブラリやインフラなどは良く利用しますが 6. の SaaS はウェブ解析以外はあまり使っていませんね。サービスとしてコアな部分以外はできるだけこういった外部のものを利用して効率良くリリースしていきたいです。

お盆休みに最近話題の「リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす
」を読みました。Webサービス、システム開発を行う人間にとって示唆に富む内容だったのでご紹介。

ジャスト・ドゥ・イット型起業からの脱却

「とりあえず製品をリリースして様子を見よう」という方針で進むと、このような問題に悩まされがちだ。私はこの方針をナイキの有名なスローガンにちなんで「やってみよう（ジャスト・ドゥ・イット）」型起業と呼ぶ。

新しい製品やWebサービスの多くはこれまで世に無かったものなので、事前に市場調査を綿密にしていても、実際にリリースしてみないと反応が分からないことが多いです。とくに小規模のベンチャーでは市場調査などを行う人材がいない、リソースが割けないということもあり、まず作ってみようというジャスト・ドゥ・イット型で進めることが多くなります。

これはこれで一理あるのですが、闇雲に機能を実装してリリースしても「下手な鉄砲も数打ちゃ当たる」状態になり、上手くいかなかった場合（多くの場合はこうなる）に得られる学びも少なくなります。

私自身もこれまでいくつかWebサービスやアプリを作って来ましたが、多くはまさにジャスト・ドゥ・イット型の開発でした。時には上手くいくこともありましたが、次の手がうまく打てずに萎んでしまったり、工数をかけてじっくりと作ったわりに鳴かず飛ばずでうまくいかないということもありました。

もちろん、そんな簡単にヒットするものが作れないのは当然です。ただ、運を天に任せて、下手な鉄砲を撃ちまくるのでは、宝くじを買うようなものでいつまでたっても陽の目を見ることができません。

そこで、ジャスト・ドゥ・イット型に科学的手法を取り入れて、もう少し成功の確率を高めていこうというのがリーン・スタートアップです。

リーン・スタートアップとは

リーン・スタートアップは、トヨタのリーン生産方式に基いて考案されたもので、顧客にとってのメリットを提供するものに価値をおき、それ以外のものは全て無駄という考え方です。これは至極当たり前のように思えるのですが、サービスを作る側、とくにエンジニアやデザイナのようにもの作りをしている人間の場合、この点を見過ごしてしまいがちになります。

本来は顧客へ何らかの価値を提供するためにものを作るべきなのに、ものを作ることに重点が置かれてしまい、下手をすれば、ものができてからそれが顧客にどんな価値をもたらすのかを考える、という本末転倒な事態になることもあります。

あくまで重要なのは「顧客に価値を提供する」という点なので、それに寄与しないもの（自分たちが作ったものも！）は無駄なものとしていさぎよく捨てる覚悟が必要です。

仮説、構築、計測、学び

リーン・スタートアップでは、まず顧客にどのような価値を届けるか、届けるとどのような反応が返ってくるかという仮説を立てます。そしてその仮説を確かめるために製品を開発します。製品が完成したら、実際にリリースして計測を行ないます。計測で得られた結果、反応を見て、仮説が正しかったかどうかを検証します。そこで得られた学びを元に次の仮説を立てて、また製品を作っていきます。

この一連の流れを小さく早く回して、顧客の反応を確かめながら進んでいくのが特徴です。

つまり「ものを作る」というのはあくまで仮説を証明する手段にすぎません。よって仮説が証明できれば、機能自体は実装しない場合もあります。

極端なことを言えば、最も簡単に仮説を検証できるのは、顧客に直接聞くという手法です。その製品がターゲットとしている顧客にコンタクトを取って、提供しようとしている製品を話せばすぐにフィードバックを得ることができます。もちろん、実際にものが無いと想像できない場合も多いのですが、少なくともそれを欲している人がいるかどうかくらいは分かります。

本書では、仮説を証明するための必要最低限な製品をMVP（Minimum Viable Product）と呼んでいます。このMVPは仮説が検証できれば良いので、それ以外の機能や品質は不要です。

これは自分でもついやってしまうのですが、こういう機能なら今時はソーシャル連携するだろう、Ajaxになっていないといけないなど、機能の本質では無い余計なものまで作りこんでしまうことがあります。もし、その機能自体が誰からも必要とされていなから、そういった余計なものは全て無駄となってしまいます。

まずは仮説を立てる。そしてそれを確かめるために製品を作る。このアプローチがとても大事です。

開発の現場では当たり前のこと

この一連の流れは視点を変えれば、実は普段からシステム開発の現場ではやっていることと同じです。

例えば、不具合を修正する場合。

不具合の報告を受けて、現象が確認できたら、まずやることは原因を特定することです。原因を特定するには、ここが原因だろうという仮説を立てます。そしてそれを確かめるためにソースを読む、コメントアウトしてみる、テストを書くなどを行ないます。そして実際に動かして仮説が正しいかどうかを確かめます。原因が特定できれば次は修正方法を検討します。そして、修正を行ない、不具合が解消されているかを確かめます。

これはまさに「仮説、構築、計測、学び」のサイクルと同じです。そう考えるとごく自然にこのアプローチが理解できます。

何のために作るかを見つめなおす

やってはいけないことをすばらしい効率で行うことほど無駄なことはない。

有名なドラッガーの言葉が本書でも引用されているのですが、もの作りを行う人間が陥りがちな状況を的確に表しています。誰も求めていない製品を最高の品質で作っても事業としては意味を成さないのです。

自分たちが作っているものは誰のどんな問題を解決するのか、どんな価値が提供できるのか。事業を行う上でも、ものを作る上でもあらためて考えさせられる本でした。

この本ではさらにリーン・スタートアップを行う具体的な手法や実際の事例がふんだんに盛り込まれています。事例には、DropBoxやインテュイット、グルーポンなど馴染みのある企業が登場します。また、アジャイル開発や継続的インテグレーション、Railsなど開発現場で聞かれる単語も登場するなど、自分に近い話として読むことができました。おすすめです。

リーン・スタートアップの原点ともいえるトヨタのリーン生産方式に関する本です。

さて夏がやってきました。夏と言えばPHPということで、昨年に引き続き、最近のPHP事情をご紹介。

1. PHP5.4リリース

PHP5.4が2012年3月にリリースされました。

Traits や Short array syntax（配列の短縮構文）、array dereferencing（foo()[0]） などのPHP言語拡張、PHPコマンドで起動するビルトインサーバ、そしてパフォーマンスの改善など大きな変更が加えられています。

言語自体の機能追加も注目ですが、ビルトインサーバは多くの人にとってメリットになるでしょう。これを使えばPHPアプリケーションの動作確認のためにApacheやnginxなどのhttpdサーバを自分のPCに入れる必要はありません。

下記のようなコマンドを打つだけで、ビルトインサーバが起動します。新しいフレームワークやライブラリ、アプリケーションを試してみたい時に手軽に使えるのが嬉しいですね。

$ php -S localhost 

2012/08/01の最新版は PHP5.4.5 となっています。これから新たにPHPアプリケーションを構築する際は、5.4で動作することを確認しておいた方が良いですね。

PHP 5.4.0 Release Announcement
PHP 5.3.x から PHP 5.4.x への移行
PHP5.4 Advent Calendar 2011

2. PHP標準コーディング規約 PSR–0 / PSR–1 / PSR–2

PHP コミュニティで標準的なコーティング規約が提唱されます。これが PSR–0 / PSR–1 / PSR–2 です。

これまでも PEAR や各フレームワークでそれぞれ独自のコーティング規約が使われていましたが、PHP として標準的なコーティング規約が出来たというのは初めてのような気がします。

すでにいくつかのフレームワークやライブラリはこの規約に従って書かれています。

PHPコードの書き方に迷っている人は一度目を通しておくと良いでしょう。

なお、この規約は提唱されているだけで、従わないといけないということではありません。ただ、できるだけ合わせた方が、多くの人にとって使いやすく、読みやすいコードになることは間違いありません。

PSR–0
PSR–1
PSR–2

PSR–1 / PSR–2 に合わせてコードを自動で修正するツールもあります。

PHPソースをコーディング規約に合わせて修正してくれるPHP Coding Standard Fixer
The PHP Coding Standards Fixer for PSR–1 and PSR–2

3. パッケージ管理システム Composer

PHP のパッケージ管理システムには PEAR があるのですが、現状は新たなパッケージがあまり増えず、盛り上がっているとはいえない状況です。（個人的には PHPUnit 系専用になっています）

そんな PEAR に代わって、盛り上がっているのが Composer です。

PEAR に比べて、導入も簡単ですし、パッケージも手軽に公開できるので、対応パッケージが増えています。

おそらく今後フレームワークやライブラリを導入する際は自然と触ることになると思うので、一度使い方を見ておくとよいでしょう。

Composer
PHPの外部ライブラリの管理にComposerを使う | Ryuzee.com
Composerの使い方を調べたメモ(1) – k-holyのPHPメモ

4. PHP The Right Way

ここまで紹介してきたようなPHPに関する情報を網羅したサイトが登場しました。それが「PHP The Right Way」です。

今風のPHPを使うにあたって参考になる情報が紹介されています。元は英語サイトなのですが、有志によって和訳されていますので、ぜひ一度見てみて下さい。

PHP: The Right Way

5. フレームワーク事情

最後に最近気になるフレームワークなどを。

5–1. CakePHP2 / CakePHP3

CakePHP2が2011年12月に正式にリリースされました。最新版は2.2.1です。

これから CakePHP をはじめる人は迷うこと無く 2 系からはじめましょう。

日本語情報が少ないという声もありますが、公式マニュアル（cookbook）の和訳も進んでいっていますし、2 に対応した書籍も登場してきています。実は執筆に関わっている書籍が来月あたりに出版されるので乞うご期待！

CakePHP
Security Release – CakePHP 2.1.5 & 2.2.1

さらに次期バージョンのCakePHP3の概要が発表されています。CakePHP3はPHP5.4以上を対象としており、新たなCakePHPとして進化しそうです。

3.0: a peek into CakePHP’s future

5–2. FuelPHP

巷で今一番注目されているフレームワークといえばFuelPHPでしょう。

FuelPHPは、PHP5.3以上で動作するCodeIgniterライクな軽量なフレームワークです。規約より設定を重視しており、設定でフレームワークの挙動が変えられるのは、ある意味PHPらしいです。

これからフレームワークを触ってみたいという人にも学習しやすく、パフォーマンスも良いのでアクセスが見込まれるサイトでも使い勝手が良さそうです。

すでに日本語で良質の書籍が2冊登場していますので、FuelPHPに興味がある人は手にとってみて下さい。

FuelPHP › A simple, flexible, community driven PHP5.3 framework

5–3. BEAR.Sunday

こちらも今、注目されているフレームワークです。

リソース指向のフレームワークとされていて、動作対象がPHP5.4以上という最新鋭のフレームワークです。また作者が日本人（@koriym さん）というのも大きな特徴でしょう。

FuelPHPが実用のフレームワークとして注目されているとすれば、BEAR.Sundayは学習のフレームワークとして注目されているように感じます。

現在は開発途中ということで、実用するのはまだ先かもしれませんが、個人的には一度じっくりと触ってみたいフレームワークです。

koriym/BEAR.Sunday
manual – bearsunday – BEAR.Sundayマニュアル – PHP 5.4 Resource oriented framework

次はPHP5.5?

次のPHPであるPHP5.5では、さらに言語を拡張して、ジェネレータやリスト内包表記などPythonのような記法を取り入れる提案がされています。

まだ実装されるかは分かりませんが、PHPはその時流行っている言語の良い所を取り入れる特徴があるので、PHPの新機能を見ると言語の流行りが見えるかもしれませんね。

MacBook Air のセットアップ進めています。

今回はアプリの棚卸の意味を含めて１からセットアップしているのですが、要不要を考えながらインストールしたアプリたちです。

システム環境設定はこちらで。

インストールしたアプリ

1.	Firefox	いわずと知れてた定番ブラウザ。chromeに移りつつもまだメインブラウザにしています。 拡張は以下。パスワード管理には LastPass を利用しています。
2.	Google Chrome	これまた定番ブラウザ。 拡張は以下。
3.	Google 日本語入力	日本語入力にはGoogle日本語入力（IME）を使っています。設定は以下。 「言語とテキスト」「入力ソース」で入力ソースを「ひらがな」のみにしています。 「Google日本語入力」「環境設置」にて、スペースの入力を「半角」に、キー設定の選択を「ATOK」にしています。
4.	Google quick search box	ランチャーです。軽量で余計な動作が少ないので気に入っています。（たまに落ちますが。。。） 起動時にログイン、メニューバーに表示しない、起動コマンドを「command + space」にしています。
5.	Evernote	メモ系はとにかくEvernoteに集約しています。クラウドにデータがあると様々なデバイスからすぐに取り出せるのが便利です。
6.	Dropbox	おなじみクラウドストレージです。設定するとクラウド上のデータを一気にダウンロードするので気長に待ちます。
7.	TotalFinder	Finderを拡張してタブ化するツールです。これがFinderの標準になって欲しいくらいです。 すべてのファイル名拡張子を表示にチェックを入れています。
8.	ClipMenu	拡張版クリップボードで、複数のコピー履歴をペーストすることができます。 デフォルトでは終了時にコピー履歴をファイルに保存してしまうので、セキュリティを考慮しています。
9.	iTerm	ターミナルです。
10.	macvim-kaoriya	日本語での使い勝手が向上しているMacVimです。基本はターミナルから起動して、ターミナル内で vim の代わりに使っています。
11.	CotEditor	軽量なプレーンテキストエディタです。基本機能（複数文字エンコーディング対応、正規表現による検索、置換等）は揃っていて、何かと使い勝手が良いです。
12.	marked	Markdown形式のプレーンテキストを様々な形式で表示してくれるビュワーです。表示しているファイルを常に監視しているので、テキストを変更すると即座に反映されます。Markdownエディタもあるのですが、書く方は普段慣れたエディタを使いたいので重宝しています。 最近は blog を書くときも Markdown で書いて、最後にmarkedでHTML形式での出力に変換して、WordPressに貼り付けています。
13.	XMind	マインドマップ作成ツールです。考えをまとめたいときにとにかく書きなぐって頭を整理します。
14.	FileZilla	FTP/SFTPクライアントです。これがベストかと言われるとそうではないのですが、それほど利用頻度があるわけではないので、なんとなく使っています。良いのがあれば教えて下さいm(_ _)m
15.	Skype	主にメッセンジャーとして使っています。最近は Facebook グループやチャットで用が済む場面も増えてきましたが、まだまだ現役です。
16.	YoruFukurou	定番Twitterクライアントです。
17.	WinArchiver	ファイルアーカイバーです。暗号化されたZipファイルの展開やファイル名の文字化けなど何かとトラブルの多いWindows環境向けのZipファイル作成などを上手くやってくれます。 *.zipファイルへの関連付けです。 zipファイルを選択して右クリックで「情報を見る」を開きます。「このアプリケーションで開く」でアプリケーションに「WinArchiver」を選択して「すべてを変更」とすれば ok です。
18.	VMWare Fusion	OS X 上で Windows を動作させるために使っている仮想化環境です。仕事ではなんだかんだ言っても Windows が必要な場面があるので入れています。
19.	iSTAT MENUS 3	MacBook Air のリソース利用状況をメニューバーを表示するモニタリングソフトです。全てのリソースを表示するとメニューバーが大変なことになるので、CPUと温度、バッテリを表示するようにしています。
20.	Xcode4	Apple謹製の開発統合環境です。iOS アプリ作成の他にターミナル環境でのビルドツールとしても利用します。 MacPortsを利用するので、「Preferences」から「Command Line Tools」を入れておきます。
21.	MacPorts	オープンソースソフトウェアを自動インストールするパッケージシステムです。Homebrew とかありますけど、結局は MacPorts です。
22.	Apache OpenOffice	オープンソースの Office 環境です。LibreOffice も試してみたのですが、Microsoft Office で作成されたファイルの再現性は OpenOffice の方に分があるように感じました。
23.	Growl	各アプリケーションから送られる通知を表示してくれるツールです。Mountain Lionに搭載される「通知センター」が登場すると必要なくなるかもしれません。

…

Ivy MacBook Air 発売日にちょうど東京出張だったので、アップルストア渋谷にてお目当ての 11 インチ MacBook Air ulitimate モデル（Core i7 / 8GB / 256GB / US キーボード）を購入しました。

初アップルストア店頭での購入だったのですが、欲しいモデルがすぐに手に入るのは嬉しいですね。

今回は既存の Air から移行せず、１からセットアップを行いました。まずはシステム環境設定から。

初期設定

いつものムービーが無く、いきなり設定画面に突入しました。

必要最低限の設定（言語やタイムゾーン、コンピュータ名、アカウントくらい）だけ行って、あとは起動後に。

システム環境設定

セキュリティとプライバシー – FileValut

盗難時のデータ漏洩を考慮して、FileValut を入にして、ディスクのデータを暗号化しておきます。

データが少ない時に実施したほうが初期処理が早く終るので、まずはじめに実施しました。

デスクトップとスクリーンセーバ – デスクトップ

デフォルトの壁紙が好みでないので「無地の色」に変更します。

Dock

11 インチ Air は、それほど表示領域が広いわけではないので、Dock 部分も活用したいところです。そこで表示位置を左にして、自動的に隠すようにしました。

Spotlight – 検索結果

ランチャーには Google Quick Search Box を使うつもりなので、起動ショートカットキーを「command + space」から「option + space」に変更しました。

ユニバーサルアクセス

トラックパッドの操作感を変更します。

「トラックパッドオプション」をクリックします。

トラックパッドによる2本指によるスクロールの速さを最速にします。

キーボード – キーボード

キーリピートを最速に、Fxキーをファンクションキーとして使いたい（ATOK風変換をしたい）ので、「ファンクションキーとして使用」にチェックを入れました。

Caps Lock はめったに使わないので、修飾キーの設定で、Caps Lock キーに Control を、Control キーに Caps Lockを割り当てました。

キーボード – キーボードショートカット

フルキーボードアクセスを「すべてのコントロール」に変更しました。これにより、テキストボックスとリスト以外もtabキーでの選択、スペースキーでチェックを付ける、エンターキーで決定ができるようになります。

Windows と違い、Mac の「command + tab」はアプリ切り替えで、同一アプリ内で複数ウィンドウがある場合はこのショートカットキーでは切り替えができません。そこで、同一アプリ内でのウィンドウ切り替えを「option + tab」に設定しました。

入力ソース切り替え（英語<->日本語等）をATOK風に「control + space」に設定しました。

トラックパッド – ポイントとクリック

Windows ノート風に1本指タップでクリックに設定しました。

トラックパッドでのポインタの動きは最速にしています。（一度最速で慣れると、素早く移動できるので快適です）

Bluetooth

Bluetooth はとりあえず使用しないので、切にして、メニューバーにも表示しないようにしました。

共有

デフォルトのコンピュータ名が「〜-no-MacBook-Air」のようにイマイチな名前になっているので、変更しました。

ユーザとグループ

ターミナルでのログインシェルを zsh にしたいので、ログインシェルを変更しました。

まず左下の鍵アイコンをクリックしてロックを解除します。

認証が必要となるので、アカウントパスワードを入力します。

ロックを解除して、「現在のユーザ」で自分のアカウントで右クリック（2本指タップ）すると「詳細オプション」が表示されるのでクリックします。

ログインシェルを「/bin/zsh」に変更します。

設定が終わったあとは鍵マークをクリックして、ロックをかけておきます。

日付と時刻

メニューバーでの日付と時刻表示を24時間表示に設定します。

自分好みにカスタマイズ

久しぶりに１から設定をやって分かりましたが、あまりカスタマイズせずに使っているつもりでも、あれこれ設定を変えてることに気づきました。設定の自由度が高いのも Mac の良さですね。

これから長い付き合いになりそうなので、じっくり育てていきます。