Unixstickersでギークなステッカーを手に入れてみた

最近コードを書いていないので、ちょっと閑話休題。
というか、フリーランスという働き方のためか、ずっとコード書いている訳ではないので書きたくても書け無い時もあるのです。
よく渋谷や原宿辺りのオシャレなカフェやノマドカフェ行くと、オープンエアでMacBookを広げてノマドライフを満喫している方々がいますが、決まってこれまたオシャレなWebサービスのロゴステッカーなんかを貼ってドヤッてますよね。
自分のMacBookにもああ言うのを貼りたいけど、どうせならギークでわかる人にはわかるような素敵なステッカー貼りたいなーと思って探してました。
で、行き着いたのがUnixstickersです。
ここは$0.69〜と安価で種類が豊富、更にVimステッカーまで置いてあります!
とてもとても安価なんですが、結局自分は「あれもこれも」と思いながら色々カートに突っ込んで、大体$30弱買ってしまいましたorz
支払いはPaypalなので問題無し、問題は日本国内届くのかな・・・と思いながら待つ事2週間・・・。
unixstickers
じゃーん、案外簡単に買えました。
頼んでから、Vimステッカー3枚はいらないかなーと後悔しつつ、まぁ布教用にあっても困らないかと思う次第。あとPHPのゾウがいかしてますね。ゾウカワイイよゾウ。
Pythonステッカーはモヒカンな人たちに目を付けられそうなので、目に付かないところに貼ってニヤニヤしたいと思います。

Nginxでgzip化した状態でcacheをしてみる

Nginxのキャッシュはproxy_cacheによって、比較的簡単に取ることができるのですが、できればgzip化された状態でキャッシュしたいなぁと思ってやってみました。
1サーバでNginx + Apacheを想定して設定してみました。
これはあくまでgzip化した状態でキャッシュできるというだけで、パフォーマンスについては調査してません。
これをやってパフォーマンスが低下しても責任はもてませんのであしからず。

下記の設定をみればそのままですが、やってることは結局
(Nginx[80]でキャッシュ) (Nginx[8080]でgzip化) (Apache[10080]アプリケーション)
というだけです。
実際のキャッシュの中身を見ると

KEY: http://www.example.com/
...
Content-Encoding: gzip

めでたくgzip化された状態でキャッシュできました。
以下、端折ってますが設定例です。

http {
    ...
    ...
    proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=zone1:4m inactive=1d max_size=100m;
    proxy_temp_path /tmp/nginx_temp;
    upstream backend {
        server localhost:10080;
    }
    upstream gzip_backend {
        server localhost:8080;
    }
    server {
        listen 80;
        server_name www.example.com;
        location / {
            ...
            proxy_cache zone1;
            proxy_cache_key "$scheme://$host$request_uri$is_args$args";
            proxy_cache_valid 200 60m;
            proxy_cache_valid any 1m;
            proxy_pass http://gzip_backend;
    }
    server {
        listen 8080;
        location / {
            ...
            gzip on;
            gzip_http_version 1.0;
            gzip_vary on;
            gzip_comp_level 5;
            gzip_types text/xml text/css text/javascript application/xhtml+xml application/xml application/rss+xml application/atom_xml application/x-javascript application/x-httpd-php;
            proxy_pass http://backend;
        }
    }
}

Nginxのキャッシュとバーチャルホスト設定で気をつけたい事 メモ

Nginxで複数ドメインを扱う時に、気をつけたい事があります。それはキャッシュの設定。
公式を見る限り、proxy_cache_keyのデフォルトは

$scheme$proxy_host$request_uri

などとなっていますが、この設定を変更せずに複数ドメインを扱うとハマるというお話です。
具体的には以下のような設定の場合

server {
    listen       80;
    server_name  example.com *.example.com;;
    location / {
        ......
        ......
        proxy_cache zone1;
        proxy_cache_key $scheme$proxy_host$request_uri;
        proxy_cache_valid  200 1d;
        proxy_cache_valid  any 1m;
        proxy_pass http://backend;
        ......
        ......

この場合、「http://example.com」や「http://www.example.com」など複数ドメインで同一のキャッシュを参照する様になってしまいます。
実際のキャッシュの中身を見てみると・・・

KEY: httpbackend/

あなおそろしや・・・Nginxのキャッシュは手動で消す(or モジュール入れる)しか方法が無いため、複数ドメインで同じキャッシュが見えてしまう状態になってしまいます。
では、次にproxy_cache_keyを変更してみます。

proxy_cache_key "$scheme://$host$request_uri$is_args$args";

nginxを再起動し、キャッシュをクリアして再度キャッシュの中身を見てみます。

KEY: http://www.example.com/

今度はしっかりとドメイン名でキャッシュできました。
この辺りはハマりどころなので気をつけたいところですね。
ちなみに(複数サーバの)Nginxキャッシュの削除は、Python Fabricで簡単に行えるようにしております、Fabricマジ便利!

yum updateをしたら、タイムゾーンがUTCに戻ってしまった時のメモ Amazon Linux

先日Amazon Linux AMIが更新されて「Amazon Linux AMI 2013.03」になったので、早速yum updateを行ったのだけど、JSTにしたはずが何故かUTCになってしまったのでメモ。

$ sudo yum update

すると・・・

$ date
2013年 3月 31日 日曜日 12:17:00 UTC

何故かUTCになっていました・・・。
tzdataがアップデートされてたので、別のインスタンスで試しにtzdataをyum.confで除外してみました。

$ vim /etc/yum.conf
[main]
・
・
・
exclude=tzdata <- 追加
$ date
2013年 3月 31日 日曜日 12:33:14 UTC

やっぱり変わってしまう・・・。
それで、色々調べてみると、/etc/sysconfig/clockの修正が必要でした。

$ sudo vim /etc/sysconfig/clock
ZONE="Asia/Tokyo"
UTC=false <- trueをfalseに変更
ARC=false

もう一度localtimeを変更

$ sudo cp /usr/share/zoneinfo/Japan /etc/localtime
$ date
2013年  3月 31日 日曜日 22:26:24 JST

ハードウェアクロックがこの設定を見ているのか?
hwclock –debugを実行するとなんか失敗しました。

$ sudo hwclock --debug
hwclock from util-linux-ng 2.17.2
hwclock: /dev/rtc のオープンに失敗しました, errno=2: そのようなファイルやディレクトリはありません.
利用可能なクロックインターフェイスが見つかりません。
既知のどんな方法でも、ハードウェア時計にアクセスできません。

しかし、yum updateした時にどこでlocaltimeが変更されているのかは謎・・・。
もう少し調査してみたいですが、今日はギブアップ。

サーバ上でコマンドラインからWebサイトのスクリーンショットを撮ってみた wkhtmltoimage

Linuxサーバ上で、コマンドラインからWebサイト(Webページ)のスクリーンショットというか、キャプチャーみたいなものが取れないものかと思い探してみたら、
wkhtmltoimageなるコマンドがあったので試してみました。
試したのはAWS EC2のUbuntu Server 12.10(64bit)上
このツールは元々wkhtmltopdfというツールから派生して作成されたようで、APTでインストールする事が可能でした。

$ aptitude install wkhtmltopdf

 
さて、本題のwkhtmltoimageですが、まず下記サイトからDLするのですが、最新Verだとうまく実行できなかったので、古いVerを利用しました。
https://code.google.com/p/wkhtmltopdf/
古いVerのデータが上記サイトから何故か辿れなかったので、とりあえず直接DLします。

$ wget http://wkhtmltopdf.googlecode.com/files/wkhtmltoimage-0.10.0_rc2-static-amd64.tar.bz2

検証したサーバはUbuntu 64bit版なのでこのファイルをDLしましたが、32bit版であれば恐らく下記の物です。
http://wkhtmltopdf.googlecode.com/files/wkhtmltoimage-0.10.0_rc2-static-i386.tar.bz2
次に、落としたデータを解凍

$ tar lxvf wkhtmltoimage-0.11.0_rc1-static-amd64.tar.bz2

すると「wkhtmltoimage-amd64」というバイナリデータが解凍されるので、これを/usr/local/bin等に「wkhtmltoimage」として移動させます。

$ mv wkhtmltoimage-amd64 /usr/local/bin/wkhtmltoimage

 
これでインストール完了、実際にコマンドラインでスクリーンショットを撮ってみましょう。

$ wkhtmltoimage http://www.google.co.jp screenshot.jpg

実際のスクリーンショットはこんな感じに成ります。
screenshot
このツールには色々オプションがあります。

$ wkhtmltoimage -H

にて確認できるので、色々試すのも良いかと。
ちなみに、私の環境だとwkhtmltopdfの方は何故かxvfbが無いと動きませんでした。なので、下記の様にAPTでインストールして、xvfb-runで仮想フレームバッファから実行しています。

$ aptitude install xvfb
$ xvfb-run wkhtmltopdf http://www.google.co.jp screenshot.pdf