2013-12

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

とあるサイトに、Varnish をリバースプロキシとして導入して、半年が経過しました。

導入した経緯やその効果など書いてみたいと思います。

Varnish とは

Varnish は、HTTP アクセラレータです。Web サーバのリバースプロキシとして動作し、キャッシュを生かして高いパフォーマンスを発揮するのが特徴です。また、VCL という独自の設定言語を持ち、これにより状況に応じた設定を柔軟に行うことができます。

導入の経緯

このサイトでは LAMP 構成の CMS を利用しており、インフラには AWS を利用しています。基本、閲覧が中心なのですが、イベント時に多数のアクセスがあります。S3 や CloudFront も検討したのですが、コンテンツを数分おきに更新する必要があるので今回は採用しませんでした。

下記が構成のイメージです。なお図はかなり簡略化しており、実際の構成とは異なります。

こちらでパフォーマンスの問題が発生したので、CMS が生成したページ全体をキャッシュとして高速に返すよう Varnish Cache を導入しました。

当初、nginx の proxy_cache を試したのですが、同一 URL へ多数のリクエストが来ている状況でキャッシュのライフタイムが切れると、バックエンドへ同じ URL に対して複数のリクエストが飛んでしまい、PHP アプリケーション側に負荷がかかるという現象があったので、今回は取りやめました。

Varnish では、同一 URL に対して複数のリクエストがあっても、バックエンドへは 1 リクエストしか飛ばないようになっています。

導入

Varnish Cache は、m1.large インスタンスの Amazon Linux サーバに yum からインストールしました。

$ sudo rpm --nosignature -ivh http://repo.varnish-cache.org/redhat/varnish-3.0/el6/noarch/varnish-release/varnish-release-3.0-1.el6.noarch.rpm
$ sudo yum -y install varnish

もし varnish のプロセスが落ちた場合に自動で再起動するように monit も入れています。varnish は、monit から起動しています。

$ sudo yum install monit
$ sudo chkconfig monit on

$ sudo vim /etc/monit.d/varnish
check process varnish with pidfile /var/run/varnishd.pid
start program = "/etc/init.d/varnish start"
stop program = "/etc/init.d/varnish stop"

$ sudo service monit start

監視

死活、性能監視として Zabbix を採用していたので、Varnish サーバも Zabbix で監視しています。

Zabbix のテンプレートは下記を利用しています。

rdvn / zabbix-templates

効果

Varnish 導入の効果はてきめんでした。

ELB 経由で来たリクエストは全て Varnish を経由しており、キャッシュが有効な期間（3分で設定しています）は、キャッシュを返すだけなので非常に高速です。

またキャッシュが切れた場合も、バックエンドへは 1 URL に対して 1 リクエストしか来ないため、バックエンドへの大きな負荷にはなりません。（ある特定の数ページのみが際立ってアクセスされるサイトなので）

導入前は、ピーク時にはバックエンドの Web サーバが応答を返せない場合があったのですが、それも一切無くなりました。

はっきりいって、下手に CMS を細々チューニングするよりも遥かに効果があります。導入後も安定して動いており、Varnish 起因の問題も発生していません。

参考の数値として、270,000 req/m のリクエストが来た時（Varnish 上位にある ELB の RequestCount）、Varnishサーバ（m1.large）の CPU 利用率は 56% 程度でした。その際の Client requests received（client_req）は 5,000 弱でした。外部からの閲覧に関して遅延など異常はありませんでした。

VCL

Varnish の特徴として挙げられるのが VCL = Varnish configuation Language による設定です。

VCL は小さな DSL となっており、プログラミングのように設定を書くことができます。イメージとしては nginx の設定をよりコードっぽくした感じですね。

例えば、下記は UserAgent を見て、iPhone が含まれていたら、http://sp.example.com/ へリダイレクトさせる VCL です。

if (req.url == "/") {
  if (req.http.user-agent ~ "(?i)iPhone") {
    error 750 "Moved Temporarily";
  }
}

sub vcl_error {
  if (obj.status == 750) {
    set obj.http.location = "https://sp.example.com/";
    set obj.status = 302;
    return (deliver);
  }
}

参考

構築にあたって参考にしたサイトです。柔軟に設定できるので、色々と調べながらの調整になりました。

• Varnish Cache
  Varnish 公式サイトです。

• The Varnish Book
  Varnish Software が提供しているガイドブックです。アーキテクチャからコマンドラインツール、設定パラメータ、VCLなど幅広い情報があります。

• Varnish best practices
  タイトルどおり Varnish のベストプラクティスです。VCL はシンプルに。

• Upgrading from Varnish 2.1 to 3.0
  ネット上には 2.x の情報が多いので、差分を確認。

• Tuning — The Varnish Book
  チューニングについて。

• Varnish » cat /dev/random > /dev/null &
  日本語で Varnish の情報を発信されている @xcir さんの blog です。ありがたや。

さいごに

Varnish は、手軽に導入できるわりに簡単にパフォーマンスを向上させることができます。とくに CMS のような閲覧が中心となるアプリケーションには大きな効果を発揮します。

CMS 自体にもキャッシュ機構などは付いていますが、それよりの上位でキャッシュできるので、バックエンドが負荷に耐えられない構成でもうまく吸収することができます。

個人的には VCL がプログラムっぽく書けるのが設定しやすくて好きです。

アクセス過多でパフォーマンスに問題が出た際に使える切り札として覚えておくと、いつか役立つ日が来るやもしれません。

公式サイトのドキュメントが英語なので、日本語でのまとまった情報があればと思うのですが、詳しい方（ﾁﾗﾁﾗｯ、Kindle とかでどうでしょうか 😀

おまけ Vagrantfile

簡単に Varnish を試せるように Vagrantfile を作りました。

vagrant up して、http://192.168.33.50/sample.php にアクセスすると現在日時が表示されます。こちらがバックエンドアプリケーションの想定ですので、リロードする度に表示される日時は変わっていきます。

Varnish は 6081 port で待ち受けているので、http://192.168.33.50:6081/sample.php にアクセスするとその時点でのページがキャッシュされます。リロードするとキャッシュが返され、日時が変更されていないことが分かるでしょう。

shin1x1/vagrant-varnish

$ git clone https://github.com/shin1x1/vagrant-varnish
$ vagrant up

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

お、これ blog に書こう！と思いついて、書き始めたものの何だか上手く進まない。あーでもないこーでもないと、ちょっと試行錯誤はしてみたけど、結局やる気が無くなってしまい、そのまま放置。。。

てな事がありませんか？

私はわりとあります。

Advent Calendar 中なので、自分に毎日書くことを課しているのですが、それでも中々進まない日はあります。

うーん、なんでだろ。というわけで、blog を書き始めたのに公開していない理由を考えてみました。

1. 内容がつまらない

「これは面白い！」と思って書きだしたものの、内容を掘り下げて考えてみるとどうもつまらないと感じてしまうパターンです。

うーん、まあつまらないならしょうがないですが、もう一捻りしたり、視点を少し変えれば、面白くなるかもなので、諦めるのはまだ早い。

あと公開してみると、思ったより反応が良かったりなんてこともあるので。

2. 書くほどでも無かった

何か新しいことを発見したから、blog に書きだしたけど、どうせこれみんな知ってるよなで、別に書かなくても良いかで止めてしまうパターンです。

同じ発見でも書く人によって、感じることも、視点も違ったりするので最後まで書いてみると良いかも。

ある意味、誰かが書いてたりすることは、自分以外の人も興味を持っていることとも言えるわけだし。

3. 自分なんかが書くのは恐れ多い

その道のスペシャリストや有名人がそのテーマについてもう書いてしまってる場合に自分なりの意見を書き始めたけど、自分なんかがと思ってやめてしまうパターン。

何もテーマが同じなだけで、全く同じ内容になるわけでも無いなら、気にせずに書けば良い。

大丈夫、どうせ大して読まれないし;-p

4. 誰かに怒られるのが怖い

技術ネタなどでは良くあるパターン。もし自分が書いていることが間違ってたり、定石から大きく外れたりで、怖い人からマサカリが飛んできたら（痛烈な批判の比喩です。ほんとにマサカリは飛んできません。）どうしようでやめてしまうパターン。

間違いの指摘や色々な意見を貰うのは嬉しいのですが、人格否定や妙に上からの意見などは正直嬉しくありません。

嫌な想いをしてまで公開する必要は無いですが、思ってるほどそういったことはありません。

大丈夫、どうせ大して読まれないし;-p

5. 調査で満足

よーし、じゃあアイデアを確かめるためにコード書いてみよう。あれ、上手く動かない。ちょっと調べよう。お、こういう方法があるのか。やった！動いた！で、満足してしまうパターン。

わかります。すごくわかります。

特に上手く動かないものが動いたり、そのアイデアを別のことに利用する方法を思いついたときなどはそちらを実現するのに夢中になったりします。

まあ、blog に書かなくても良いか、とも思いますが、簡単でも良いので、調査過程やその結果とだけでも書いておくと、自分の記録としても残るし、同じことをやろうとした誰かの役に立つかもしれません。

6. 飽きた

さあ、半分くらい書けたかな、という時に訪れる「飽きた」。なんでだろ、さっきまで調子良く書いてたし、内容も面白いと思うのだけど、書くことに飽きてしまうパターン。

疲れてるんですよ。まずはPC閉じて、コーヒーでも飲んで休憩しましょ。

さいごに

まあ書きたくなきゃ書かなくて良かったりするのですが、そんなこと言ってるから下書きが溜まるんですよね。

気分が乗らないし、明日にしようができないのが Advent Calendar。

これ読んだら、さっさと書き上げしまいましょう！

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

6分で分かるべく最近のPHP事情をざざざっとご紹介します。

過去のエントリはこちら。

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

1. PHP 5.5 リリース

PHP5系の新しいバージョンとして、PHP 5.5 が 2013年6 月にリリースされました。

新しい機能としては、ジェネレータや finally 句の、パスワードハッシュ関数、OPCache などが追加されています。

2013/12/04 現在では、5.5.6 が最新版となっています。

PHP5.5 のコードキャッシュは APC から Zend OPcache へ
PHP: PHP 5.4.x から PHP 5.5.x への移行 – Manual
PHP 5.5の新機能：さっくり理解するPHP 5.5の言語仕様と「いい感じ」の使い方 (1/2) – ＠IT

PHP 5.5 を yum でインストールするなら、remi もしくは Webtatic リポジトリでインストールすることができます。

CentOSにPHP5.5をインストール – Qiita キータ
PHP 5.5 on CentOS/RHEL 6.4 and 5.9 via Yum | Webtatic.com

ちなみに次期バージョンの 5.6 の新機能については、こちらにまとめられています。

PHP 5.6の新機能 | yohgaki’s blog

2. PHP 5.3 EOL

PHP 5.5 リリースに合わせて、二つ前のマイナーバージョンである PHP 5.3 は EOL を迎えました。
5.3 は、今後セキュリティフィックスのみを行うメンテナンスフェーズに入っており、約 1 年経過した後はセキュリティフィックスも停止する予定です。

最終バージョンは 2013/7 にリリースされた 5.3.27 です。

5.3 は、名前空間やネイティブクロージャなど、現在の PHP へ続く機能が実装されたエポックメイキングなバージョンでした。EOL となったのは名残惜しいですが、いま 5.3 を使っている方は、5.4, 5.5 へのバージョンアップを行いましょう。
（ なおパッケージベンダが 5.3 のパッチサポートを行う場合は無理に上げる必要はありません。）

PHP 5.3.27 Released – PHP 5.3 Reaching End of Life

3. php.net リニューアル

PHP 公式サイトである php.net がリニューアルしました。

いまどきのモダンなデザインに変わっています。個人的にはまだ違和感がありますが、慣れの問題ですかね。

久しぶりに開くとあれ？となるので、心の準備を。

PHP: Hypertext Preprocessor

4. Vagrant

PHP というわけではないのですが、PHP での開発環境構築ツールとして、Vagrant が注目を集めました。

Vagrant は、仮想サーバの構築、起動などコマンドで実行できるツールです。
利点としては「環境を仮想マシンに閉じ込める」「環境構築を自動化」「構築手順の共有」あたりですね。

受託開発などで複数の環境が必要な人や、チームで開発をしていて環境を統一したい場合などに特に有効です。

もう XAMPP / MAMP はいらない！
Vagrant で作る PHP 開発環境
Vagrantで作るPHP開発環境[実践編]をPHPカンファレンス2013で発表してきた
PHP開発環境のサンプルVagrantfile

こちらではPHP 開発環境構築に使える Vagrantfile がまとめられています。

PHPの開発に使えるVagrantfileのまとめ | Engine Yard Blog JP

5. Google App Engine の PHP サポート

Google の PaaS である Google App Engine で PHP がサポートされました。まだプレビュー版ではあるのですが、PHP で Google App Engine アプリケーションが書けるようになりました。

PHP 5.4 が動作するようで、公式サイトでは WordPress を動かすチュートリアルが掲載されています。

最近流行の Immutable Infrastructure の文脈でも PaaS が再評価されているので、Engine Yard や Heroku と共に、PHP アプリケーションを公開する環境として面白そうです。

Google App Engine — Google Developer

6. フレームワーク事情

みんな大好きフレームワーク事情など。

Symfony 2.3 の LTS リリース

Symfony 2.3 が LTS としてリリースされました。

LTS とは Long Term Support の略で、リリースから３年間はバグフィックスが、さらにもう１年間はセキュリティフィックスが行われます。ライフタイムが長いアプリケーションでは、こういった長期サポートが表明されていると安心して使えますね。

Symfony 2.3.0 – 最初のLTS（長期サポート） – がリリースされました | 日本Symfonyユーザー会

Laravel

今年、新たに注目を集めたフレームワークの一つで、Symfonyコンポーネントを利用したフルスタックフレームワークです。

PHP 5.45.3（ tzt さん、ご指摘ありがとうございました！ ） 以上が対象バージョンとなっており、ビルトインサーバによる開発や Composer 対応など最近の PHP らしいスタイルとなっています。

Symfony コンポーネントを利用していますが、その複雑さは上手くラッピングしているので、オブジェクト指向開発にあまり馴染みが無い人でも入りやすいのが特徴のようです。

Welcome! – Laravel PHP Framework
Laravel Advent Calendar 2013 – Qiita キータ

Phalcon

こちらも今年注目を集めたフレームワークです。

Phalcon は PHP 拡張として実装されており、フレームワークのソースコードも C で書かれています。つまり、実行速度の速さが大きな特徴です。

PHP 拡張なので、そもそも拡張がインストールできる環境で無いと使えなかったり、バージョンアップの際に Web サーバや php-fpm の再起動が必要、フレームワークのコードが読みにくいなどのデメリットは考えられますが、かなりキャラの立ったフレームワークですので、フレームワーク自体の実行速度がボトルネックになっている環境では大きな武器になるでしょう。

High performance PHP framework（Phalcon 公式）
PHP Phalcon 噂の爆速フレームワーク、はじめの一歩。
爆速フレームワーク!! Phalcon PHP Framework – Qiita キータ

書籍

今年もいくつかの PHP に関する書籍が登場したのですが、その中で２冊ほど。

PHPエンジニア養成読本

今どきのPHPに関する情報をぎゅっとまとめたムック本です。手前味噌ながら、こうしたPHP最新事情がまとまった書籍は少ないので、ざっくりと知るには良い本だと思います。

いまどきのPHPが分かる「PHPエンジニア養成読本」が出ます

PHP逆引きレシピ 第2版

PHP 逆引きレシピが、現在のPHP事情に合わせた内容となり、第2版として出版されました。

圧倒的なボリュームで、用途ごとに簡単な解説とコードの具体例が記載されており、実際に開発する際に手元に置いておくと参考になりそうです。

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

エンジニアを目指して新卒で就職して早５年。とにかく仕事を覚えたい、先輩に追い付きたい、スキルを上げたいとがむしゃらに開発に没頭してきた。そろそろ仕事はひと通りこなせるようになり、自分がリーダーとして参加するプロジェクトも増えた。

充実した毎日ではあるが、気が付くと自分が会社の中では一番のエンジニアとなっていた。

自分では分かっている。会社の中では一番かもしれないが、外に目を向けると、自分よりすごいエンジニアは山といることを。

「そろそろ、次に進む時なのかもしれない。」

転職すべきなのか、はたまたいっそのこと独立して起業すべきなのか。

---

といった事は、わりと良くある風景なんだと思います。

起業してかれこれ13年、なんとかやってこれたので、こういった状況の人から相談を受けることがあります。そこで、私自身がこれまでやってきた中で感じてきたことを書いてみたいと思います。

なお、ここでの起業はフリーランサーや一人法人で、開発などの実務を自分で行うような形態を想定しています。

起業して良かったこと

まず、起業して良かったこと。

私の場合、そもそも「独立したい」という想いが出発点だったので、それが叶って、なんとか生活できているというのは、目標が達成できたという点で良かったです。

実際にやってみて感じたのは、全てを自分で決めることができるというのは大きなメリットです。

どの仕事を受ける、どんなサービスを作る、どの技術を学ぶ、どこで働く、いつ働く、いくら稼ぐなど多くのことを自分で決めることができます。

これは何でも思い通りにできる、ということとは少し違います。

収入を自分で決められるにしても、来月から月収1億円というわけにはいきません。

置かれた状況で選択できる方法は限られてはきますが、それらの最終的な決定は、自分で、できるということです。

例えば、受託開発にしろ、その仕事を受けるか否かは自分で選択できるわけです。もちろん、仕事が無い状況では、どんな仕事でもやらないといけないかもしれません。そういった状況においても、経済状況など含めて、自分でやるという選択ができるわけです。（反対に言うと、やらないという選択もできる）

もちろん、自分のやり方でその選択肢を増やすこともできるでしょう。

自分の行動は、そのあと何かしらの結果として返ってきます。その結果を自分で受け止められるのなら、どのような決定を下すのも自分次第というわけです。

このあたりの自由度の高さは、やはり自分には合っていると思っています。

---

あとは、「稼いでいる」という感覚を肌で感じることができます。

どのように売上が立って、それがどのように自分の収入となっていくかということを身を持って感じることができるので、仕事に対して前向き（前のめり）の姿勢になります。

いまやっている仕事は、誰かにやらされていることではなく、自ら選んでやっているわけで。

この「稼ぐ」という感覚は、自分で食べる野菜を畑に収穫しにいくような、晩御飯のおかずの魚を釣りに行くような、ドラクエでこつこつレベル上げをするような、なんかしっくりくる表現が思いつかないのですが、なかなか楽しいものです。

別の視点で見ると、自分が立てた仮説を実践してみる自由があるという感じでしょうか。その結果、日々食べる稼ぎを得るような。

まあ、良い点としては「自由」「稼ぐ感覚」でしょうか。

起業して良くないこと

では、反対にあまり良くないことです。

まずは、全部自分でやらないといけないということですね。

なんだ、良かったことと同じじゃないか、と言われそうですが、実際そうです。

本当に全部やらないといけません。

営業から経理、備品の購入、請求書発行、税務申告、事務所の掃除、電話の応対、もう仕事中に関わること全てを自分でやる必要があります。

スタッフを雇用したり、アウトソースするという方法もありますが、その選定、報酬の支払は自分でやらないといけません。

一人でフリーランスとしてやる場合は、一つ一つはそんなに大変なことではないです。ただ、本業以外にこういったことが、うすくですが、ずっとのしかかって来るので意外に時間を取られます。

一日、バタバタと動きまわってきて、仕事した気分になってたけど、実は1円も売り上げていないなんてことがあったりします。

個人事業主の頃は、全て自分でやっていましたが、法人化してからは、スタッフに委任したり、アウトソースするようになりました。

とくに税務関連は、1年目は自分でやって感覚を掴んでおくのは良いと思いますが、翌年以降は専門家に依頼して、本業に専念した方が良いです。これは本当に時間取られます。

---

次は、収入の保証が無いということです。

当たり前ですが、売上が無いと自分への収入もありません。

ただ毎日暮らしていくだけでも実は結構お金が必要です。体感した人なら分かると思いますが、無収入で暮らしてみると、びっくりするくらいお金が無くなっていきます。

このプレッシャーはわりとしんどいものがあったりします。

金銭的な余裕が無いと正常な判断ができなかったりもするので、うまくやりくりしていかないといけないですね。

---

あとは、コミュニケーション不足になりがちです。

会社であれば一緒に働いている人がいるので、良いにせよ悪いにせよ何かしらの刺激を受けて日々を過ごすことになります。

ただ一人でやっているとこれが圧倒的に不足してきます。

「一人が好きなんだ」

まあ、それはそれで良いのですが、他者からの刺激が無いと自分にはあまり関心が無い話題は入ってこなくなり、新しい情報をキャッチアップする機会が減ってきます。

インターネットで情報収集もできますが、どうしても自分が見たいものだけ見る傾向になりがちなので、やはり定期的に人と会って情報交換をする機会は作っておいた方が良いです。

そう考えると技術系勉強会などで、自営の人が多いのは、こういった刺激を受ける場を欲しているからなのかもしれません。

エンジニアは独立した方が良いのか？

何を目的に独立したいと思っているのか次第、ですね。

「好きな技術を使って、もっと技術に没頭したい人」

この目的が多いですね。上昇志向があって、より上を目指していこうという人です。こういった人は、企業に属する方をおすすめします。理由は、自営ではなかなか技術だけに没頭するということは難しいからです。また、企業に属した方がより高いスキルを持った人と一緒に働ける可能性があります。そういった高いレベルの環境に身を置くには企業に属する方が良いです。

「好きな時間に起きて、自分のペースで自由に仕事したい人」

縛られずに自分のペースでやりたいという人です。やってみると想像よりは自由では無いと感じるかもしれませんが、一度独立してやってみるのも良いかもしれません。ただ、上手くいかなかった場合のバックアッププランは考えておきましょう。退職後、失業保険が出ている間に独立後の生活を疑似体験してみるのも手です。

「うるさい、とにかく独立したいんだ！」

はい、頑張って下さい。応援しています。独立する人はわりとこういう人だったりします。他人に言われて止めるくらいならやらなくても良いですし、何を言われてもやってみたい人はチャレンジするものです。

まあ、どちらを選んでも大事なのは、その後ですから。

Shin x blog Advent Calendar 2013 の 2日目です。今日は、１×１の事務所で構築したプレゼン環境についてです。

PCで作った資料を元にプレゼンを行う際に煩わしいのが、プロジェクタなど画面を投影する機械とPCとの接続です。とくに Mac の人だと多くの場合 VGA との接続アダプタが必要になるので、忘れたり、誰かが持っていても接続できないものだったりします。

また、勉強会などで複数人で順番にプレゼンを行う場合、各々でケーブルを持ち回して接続するのに意外に時間を食ったり、ケーブルの近くにいちいち移動しないといけないのも面倒です。

そこで Apple TV を使って、ワイヤレスなプレゼン環境を事務所に作ってみました。

55インチ液晶テレビ SONY　BRAVIA KDL–55HX750

会場で投影する画面です。プロジェクタも考えたのですが、綺麗に投影するならスクリーンが必要になるのと事務所はそれほど広いわけではないので、液晶テレビで十分と判断しました。

液晶テレビの中から、この機種を選んだ理由は、3点です。

1. HDMI接続

AppleTVとの接続にHDMIが必要になります。まあ、これは最近の液晶テレビなら大丈夫ですね。

2. VGAケーブル接続可能

なんかいきなりワイヤレスを否定するような話ですが、残念ながら Apple TV に AirPlay で接続できない場合もあるので、バックアップとしてこれは欲しかったです。

3. 画面の大きさ

55インチと46インチで迷いました。46 インチだと若干、事務所の反対から見た時に小さいかなあと思い、大は小を兼ねる発想と「せっかくだから」精神で結局 55 インチにしました。

55インチにして良かったとは思っていますが、46インチでダメだったかと言われると何とも言えないですね。

液晶テレビスタンド SANWA SUPPLY CR-PL15

液晶テレビを設置するスタンドです。55インチ液晶テレビが置けるように52型〜70型対応のものを買いました。

正直、スタンドがこんなに高いとは知らなかったのですが、壁に付ける、天井から吊るすなどはできないので、購入することにしました。

スタンドの設置自体は一人でできたのですが、液晶テレビを設置する際は、何人かの人に手伝ってもらいました（ありがとうございました！）。これを一人でやるのは危険です＞＜

液晶テレビをスタンドに据え付けるとこうなります。

Apple TV

今回の要。Apple TV ですね。

Mac や iPhone などの資料の表示やデモを行う機器から AirPlay で Apple TV へ繋ぐことで、ワイヤレスプレゼン環境を作ることができます。

なお AirPlay は、最近の Mac や iPhone であれば、専用アプリを入れなくても利用することができます。

Apple TV と接続する機器は同じ WiFi ネットワーク内に接続するようにすれば OK です。

Mac の画面を表示

AirPlay 可能な状態であれば、画面上部メニューバーに AirPlay のアイコンが表示されます。

アイコンをクリックして、Apple TV にチェックを付けると AirPlay 経由で Mac の画面を Apple TV 経由で液晶テレビに表示することができます。

Mavericks 以前は、ミラーリング（Mac で表示しているのと同じ画面を液晶テレビで表示）でしか表示できなかったのですが、Mavericks では別の画面として表示することができるようになりました。

これにより、Keynote などで良く使う表示用画面と発表者用画面を別々に出すことができます。

下の写真では、液晶テレビに表示用画面を、MacBook Air（Mavericks） には発表者用画面を表示しています。

iPhone / iPad の画面を表示

AirPlay 対応した機器なら表示できるので、もちろん iPhone や iPad の画面を表示することもできます。

手元の iPhone 5s では、コントロールパネルにある AirPlay をタップするだけで、iPhone の画面を液晶テレビに表示することができました。

下の写真では、iPhone でカメラアプリを起動して、それを液晶テレビで表示しています。分かりますかね;-p

AirPlay 非対応機種は

AirPlay 非対応の Mac や Windows は、VGA ケーブルで接続するしかないかというと、諦めるのはまだ早いです。

実はそんな環境でも AirPlay ができる AirParrot というアプリがあります。

これを PC にインストールしておけば、AirPlay を使えるようになるようです。（まだ試していないので、使っている方は教えて下さい！）

AirParrot

会議室のディスプレイ（Conference Room Display）を有効にする

いざ会場に来ても、SSID が複数あると、どの SSID に繋げば Apple TV に接続できるか迷いますね。

そこで、Apple TV の設定で「会議室のディスプレイ（Conference Room Display）」を有効にしておくと、Apple TV のスクリーンセーバが表示された際に Apple TV が接続されている SSID と Apple TV の名前が表示されるようになります。

設定は、[設定 – AirPlay – 会議室のディスプレイ もしくは Conference Room Display] を「入」にします。

（荻原さん、情報ありがとうございました！）

実際に使ってみて

この環境を構築したのが今年の２月頃なのですが、これまで打ち合わせの際や勉強会などで利用してきました。

実感したのは、ケーブルの抜き差しが無いだけでも、かなり楽だということ。会話の中で、あ、これ見せたいという時は、テレビの電源を付けて、AirPlay で繋ぐだけです。簡単、楽ちん。

あと便利だったのが、勉強会などで複数人が順番に話す場合でも、みんな自分がいる場所から画面を液晶テレビに表示できるので、無駄な移動がいりません。もくもく会（ハッカソン）のようなイベントでも、各自自分の PC で作業しつつ、相談事があったら、さっと画面を写して「ここどうやります？」みたいな話ができるのが良いですね。

ちなみに AirPlay 接続は、ある機器が接続中でも、その接続を奪うことができるので、誰かが話している最中に割り込んで画面を乗っ取ることもできます 😀

１×１では、この環境で勉強会を開催しています。私が参加できる勉強会であれば、会場をお貸しすることも可能ですので、ご入用の際はご連絡下さい。

さて、はじまりました。Shin x blog Advent Calendar 2013。今日12/1から12/25まで、毎日エントリを書いていきます！

初日は、まず blog を集中して書く環境作りから。

blog を書こう書こうと思い立って、MacBook Air を開くのは良いのですが、ついつい Twitter 見たり、Facebook 見たりして、TL に流れてくるエントリやスライドを眺めているうちに、もう blog 書くことがどうでも良くなって、また今度にしよう、となることがままあります。

書きたい！と思ったネタは、その瞬発力に任せて一気に書き上げられるように集中できる環境を作りたいものですね。

というわけで、Mac で集中して blog を書く環境を作るために役立つアプリをご紹介します。

OmmWriter Dana II for Mac

まずは集中して文章を書ける環境といえば OmmWriter ですね。まさにいま OmmWriter で、このエントリを書いています。

OmmWriterを起動するとフルスクリーン表示となり、雪原が背景として表示されます。そして画面中央の文章を入力するスペースが現れるので、あとはひたすら文章を書いていくだけです。

余計なものが目に入らなくなるので、これはかなり集中できます。

さらにOmmWriterには、BGM機能やキーを入力するたびにタイプライターのキー音などを鳴らすことができるので、テンポ良く文章を書いていくことができます。

あとはひたすら文章を書き綴るだけです。

目に入るものを限定して集中して書くことの効果は意外に大きくて、とくに自分の考えをまとめて吐き出すような文章を書く場合、この環境であればスラスラと文章にすることができます。

OmmWriter Dana II for Mac

Rainy Mood & 多田屋のBGM

OmmWriter にも BGM が付属しているのですが、こちらの BGM もおすすめです。

Rainy Mood は雨の音をひたすら流してくれるサイトです。雨音は規則的なものではなく、自然の雨のように強弱が刻々と変わっていきます。また、ときおり雷鳴の音も鳴るので、本当に外で雨が降っているかのように聞こえます。
雨音は不思議と心が落ち着き、集中することができます。

Rainy Mood

さらにRainy Moodと組み合わせる良いのが、「多田屋のBGM」です。

こちらは単体でも、素晴らしい曲なのですが、Rainy Mood と組み合わせる（両サイトを開いておく）とよりムードが増しますね。

多田屋のBGM
（再生するには、ページを開いて再生ボタンを押す必要があります。）

イヤホンを付けて、両サイトをBGMにすると、雨模様の山間にある素敵なカフェでノンビリとくつろぎがら、雨が草木を打つ音を聞いて、美味しいコーヒーを飲むような気分になります。

SelfControl

これで集中できる環境は万全かと思いきや、いったん集中力が切れるとついついブラウザを開いて、あちらこちらのサイトを見て回ってしまうもの。

そこで、使うのが SelfControl です。

これはあらかめじめ一定時間アクセスをブロックするサイトを登録しておくことで、自らアクセスできないようにするアプリです。

「twitter.com」や「www.facebook.com」「b.hatena.ne.jp」などを登録しておけば、何気にブラウザでこのようなサイトを開いてもアクセスができなくなります。

ちなみに私は以下をブラックリストに入れています。

• faceboo.com
• twitter.com
• api.twitter.com
• b.hatena.ne.jp
• sports.yahoo.co.jp

ブロックできる時間は、15分から最大1日まで15分刻みで設定することができます。

仕様としては、登録したFQDNを /etc/private/hosts に登録して、0.0.0.0 と :: で設定するだけの単純なものです。

# BEGIN SELFCONTROL BLOCK
0.0.0.0 facebook.com
:: facebook.com
0.0.0.0 twitter.com
:: twitter.com
(snip)
# END SELFCONTROL BLOCK

これで、ついついうっかりサイトを開いてしまっても繋がらないので、時間を浪費することはありませんね。

まとめ

集中してやれば少しの時間で終わるようなことでも、つい誘惑に駆られて余計なことをしている内に時間がどんどんと過ぎ去ってしまうものです。

ここにあげたアプリを活用して、明日からもエントリを書いていきます。