とある案件でFuelPHPを採用して構築しました。
デプロイをするにあたり、rsyncでサーバにファイルを配置しようとしたところ
FuelPHPのコアファイルが格納されているcoreというディレクトリが
syncされないということに気づきました。

なぜ、そのようなことがおきたかというと
rsyncのオプションで-Cをつけていたからでした。

-Cオプションは、CVSなどのバージョン管理のファイルなどをexcludeしてくれるオプションです。
このexclude対象に core というものが含まれているのが原因となっていました。

excludeしたいファイルは、–exclude-fromのオプションで
リストアップしたファイルを指定していたので
-Cオプションを外すことで対応しました。

今回は、普段、何気なく使っているコマンドのオプションの罠にハマった格好になってしました。

以上、参考になれば幸いです！

さて、今回は、Twitterの投稿API(statues/update)の不思議な挙動についてのお話です。

事の発端は、とあるプロジェクトで、twitterの投稿APIを利用した際に
エラーが発生して調査をした結果、発覚したものです。

その不思議な挙動というのは、
「/*」
という文字列をPOSTすると直前のtweetがresponseとして返ってくるというものです。
statuses/update APIの通常の挙動だと、エラーが発生した場合は、その旨のJSONが返ってくるのですが
直前のtweetが知らぬ顔して普通に返ってくるのがこの挙動の問題なわけです。

検証をするためにMac App のTwitterアプリに同梱されている開発コンソールを利用しました。

正常な挙動の場合、左下のstatusに入力した値がresponseのtextの値になります。

これが、「/*」と入力するとエラーにもならず直前のtweetが返ってきます。

また、TwitterのWebサイトからも同様に「/*」を投稿したところ、
送信しましたと表示はされますが実際には投稿がタイムラインには反映されませんでした。

Twitter自体のバグであるとは思いますが、
Twitter API を利用するアプリを作る場合には気を付けなければいけない挙動だと思います。
また、バグレポートがされているのかは調べきれていないのですが、
余裕を見つけてレポートされていない場合は、レポートしたいと思います。

以上、参考になれば幸いです。

ただし、これをそのまま使うと変形の起点(transform-origin)がCSS3のtransformと違うため座標にズレが出てしまいます。座標変換コードを書こうと思ったらもうやってる人がいたので紹介します。
jQuery 2D Transformation Plugin

45度回転させるコードは以下のように記述できます。

$('.example').transform({rotate: 45});

他のプロパティも同時に変更できます。

$('.example').transform({
    rotate: '45deg',
    skew: ['10deg', '10deg'],
    scale: [1.5, 1.5],
    translate: ['20px', '20px']
}

jQueryのanimateもhookしているのでtransformのアニメーションも簡単に記述できます。

// 1秒で1回転させる
$('.example').animate({rotate: '+=360deg'}、1000);

類似のjQueryプラグインにjquery-css-transformがありますが、現時点ではIE8以下で動きません。

TwitterのAPIを利用するために、ZendFrameworkをライブラリとして利用しました。
OAuthで認証を行ない、tweetするという挙動を確認して、tweet後の挙動としてsessionを切るために
accountEndSessionメソッドを叩いたところ、sessionは切れずに、返り値としてtrueが返ってきました。

ZendFrameworkのソースを追ってみたところ
内部的には、getメソッドで、APIのエンドポイントを叩いて trueを返しているだけでした。
(ZendFramework 1.11.11で確認しています)

class Zend_Service_Twitter extends Zend_Rest_Client
{

    /**
     * End current session
     *
     * @throws Zend_Http_Client_Exception if HTTP request fails or times out
     * @return true
     */
    public function accountEndSession()
    {
        $this->_init();
        $this->_get('/1/account/end_session');
        return true;
    }

}

なぜsessionが切れなかったかというと、
twitterのAPIが変更になり、APIのエンドポイントとメソッドが変更になっているのが原因でした。

ドキュメントをみるとAPIが変更になったのが、2011-11-04 のようでした。

https://dev.twitter.com/docs/api/1/post/account/end_session

単純に言えば、APIの変更にライブラリの改修が追いついていないだけですが、
これでは使えないので、下記のようにZend_Service_Twitterをextendsしたclassを作って対応しました。

class my_Zend_Service_Twitter extends Zend_Service_Twitter
{
    public function accountEndSession()
    {
        $this->_init();
        $res = $this->_post('/1/account/end_session.json');
        return $res;
    }
}

以上、参考になれば幸いです！

今日はphpの最新バージョン5.3.9を使う際に、気をつけるべきことを記載します。

php5.3.9ではhashdos攻撃の脆弱性に対応するために以下の設定値が追加されています。

max_input_vars

これはGETやPOSTのインプット数を制限する設定値です。
デフォルトでは1000と設定されていて、1000以上のパラメータは無視されます。
hashdos攻撃とその対策については以下の記事に詳しく出ております。

http://blog.tokumaru.org/2011/12/webdoshashdos.html

さて、この初期値1000ですが

1000以上もの値を入力する場面はそうそうないかと思いますがあるパッケージ製品の管理画面において、その数を超える場合がありました。

その際には管理画面においてのみmax_input_varsの設定を変更することで回避しましたが最大値を超えた場合、入力値がただ消えてなくなって見えるので原因の特定に時間がかかりました。

PHP 5.3.9を使用する場合にはちょっと気をつける必要がありますね。

それでは、今日もガシガシコードを書きましょう！

使い方

以下のように書くと5秒放置したときに”idle”と表示されます。
“idle”状態で画面に戻ったりマウスが動いたりすると復帰、”back”と表示されます。

new IdleTimer(
    5000,
    function(){
        console.log('idle');
    },
    function(){
        console.log('back');
    }
);

コード

/*
idletimer.js

author:nakagawa@ville.jp
licence:NYSL
*/

var IdleTimer = function(){
    this.isIdle = false;
    this.timestamp = null;
    this.timerId = null;
    this.init.apply(this, arguments);
}
IdleTimer.prototype = {
    init : function(timeout, onIdle, onBack){
        this.timeout = timeout;
        this.onIdle = onIdle;
        this.onBack = onBack;

        this.setEvents();
        this.setIdleTimeout();
    },
    setEvents : function(){
        var self = this;
        var doc = $(document);
        doc.ready(function(){
            doc.mousemove(function(){ self.active();});
            try{
                doc.scroll(function(){ self.active(); });
            }catch(e){}
            try{
                doc.keydown(function(){ self.active(); });
            }catch(e){}
            try{
                doc.click(function(){ self.active(); });
            }catch(e){}
        });
    },
    setIdleTimeout : function(){
        var self = this;
        this.timestamp = new Date().getTime() + this.timeout;
        if(this.timerId) clearTimeout(this.timerId);
        this.timerId = setTimeout(function(){ self.idle(); }, this.timeout);
    },
    idle : function(){
        var self = this;
        var t = new Date().getTime();
        if(t < this.timestamp){
            this.timerId = setTimeout(function(){ self.idle(); }, self.timestamp - t);
            return;
        }
        this.isIdle = true;
        this.onIdle.call();
    },
    active : function(){
        var t = new Date().getTime();
        this.timestamp = t + this.timeout;
        if(this.isIdle){
            this.setIdleTimeout(this.timeout);
            this.onBack.call();
        }
        this.isIdle = false;
    }
};

僕は、サーバサイドエンジニアで、フロントエンドには余り興味がなく、
残念ながら、非常に薄いHTMLの知識しか持っていません。
モックレベルの構築をしているときには、おもにtableタグで作ることが多いです。

そんな、フロントエンドがわからない人間にとって朗報となるものが
twitter社が2011/8にリリースしたCSSフレームワークのBootstrapです。
githubにおいてあるcssを読み込むだけで、今風な画面に仕上がります。
(細かい調整は、もちろん必要なのですが。)

さらに、Javascriptでalert、tab、dropdownなどを実現できる機能も備わっています。

ドキュメントも英語ですが備わっていますので、そこも安心です。

管理画面など、程々に見た目や機能が必要なものに関しては、実用できるのでは無いでしょうか。

http://twitter.github.com/bootstrap/

すっかり秋ですね。

開発環境を見直すには、もってこいの季節です。

私の使っていたローカルの開発環境は、Windows7(32bit)のVMWare PlayerにLinuxをインストールして、フォルダ共有機能を使って開発を行っていました。環境の構築は、とても楽チンですが、どうも開発・運用しているWebアプリをローカルで実行すると、非常にレスポンス等が遅く、開発リズムがくずれてしまうなど、とてもストレスのたまる状況でした。

この状況を打破すべく、VMWareの設定を調整するなどしましたが、一向に改善せず、同僚からは、あきれられている状況でした。

そこで、過去に使ったことのあったcoLinuxを思い出しました。coLinuxの評価をネットで調べると、VMWareより軽いとうこのが何件かありましたので、使ってみることにしました。

しかしながら、coLinuxで環境を作成するのは、VMWareと比べると骨の折れる作業でした。

ちなみに私は、centOSを使いたかったので、通常より大変な作業となりました。

【参考にさせていただいたサイト】感謝！！

• http://d.hatena.ne.jp/from_kyushu/20071203/1196628743
• http://tm.root-n.com/application:colinux:centos5.6install

上記の２つめのサイトにも記載されていますが、インストールするLinuxのHDDのパーティションをカスタマイズで設定する必要があります。私は、この設定をしていなかった為、coLinuxを起動するとkernel panicが発生してしまうことを繰り返してしまっていました。

coLinuxをインストールしたのち、sambaの機能を使って、windows側とフォルダ共有するのが、有名ですが、coLinuxには、cofsという機能があり、それをcoLinuxの設定ファイルにWindowsのどのフォルダを共有するかを記載し、Linux側からマウントすると使用することが可能になります。

実際にインストールした後の使用感ですが、私の環境では、体感ですが、Webアプリの動きが数倍早くなりました。そして、開発リズムもストレスがなくなり、さらに楽しく開発ができるようになりました。

もし開発環境がVMWareで重くて、悩んでいる方は、開発環境を見直して、coLinuxを一度考えてみてはいかがでしょうか？

以上。

CSS2/CSS3-セレクタ

CSS2-プロパティ

min-width
min-height
max-width
max-height
position:fixed
overflow:visible

IE6以下のCSSバグ

セレクタやプロパティの表現力が高まるだけでなく、IE6以下限定の有名なバグも意識しなくてよくなります。

“doubled margin” bug
floatした要素の横マージンが倍になる

“peekaboo” bug
ボーダーや背景がスクロールしたときに消える

“unscrollable content” bug
画面に収まらないposition:absoluteのボックスがあってもスクロールバーがでない

3 pixel text-jog
インライン要素をfloatさせると3pxのmarginが自動的に付与されるバグ

JavascriptでIE6もカバーする

ここに挙げたCSSセレクタ、プロパティはいずれも“ie7.js”でカバーできます。
IE6は無視したいけどまぁ一応。。という時にはこれを使うのもいいでしょう。
さらに、上に挙げた3つのバグはie7.jsと同時に配布されている”ie7-squish.js”を読み込むと解消されます。

参考サイト

“CSS contents and browser compatibility”

“Web browser CSS support”

さて、村式が共同運営する “iichi“。
“手仕事の新しいマーケットプレイス”として、2011/7/6 にプレオープンしました。

2011/10/5 にグランド・オープンを迎えて英語化され、ついに作家さんの作品を世界へ販売することが可能となりました。

世界へ進出し、今後も成長を目指していくiichi。

インフラには、Amazon Web Services (以下 “AWS”) の多くの製品を採用しています。

このエントリでは、iichiのインフラを少し紹介したいと思います。

インフラの構成図

上が、iichiのインフラ構成の概要図です。
タイトルでは”大半”なんて書きましたが、全部AWSです。
以下のAWS製品を使用しています。

• ELB (Elastic Load Blancing) / ロードバランサー
• EC2 (Elastic Compute Cloud) / WEBサーバー, キャッシュ・セッションストレージ
• RDS (Relational Database Service) / DBサーバー
• S3 (Simple Storage Service) / 画像ストレージ
• CloudFront / 画像配信
• Simple Email Service / メール配信

初動のリソースをとにかくアプリケーションの開発に集中させたいという思惑もあり、積極的にAWSの利用を進めました。
大部分がコントロールパネルからポチポチすれば利用可能な状態にまでもっていけるので、なんとも楽チンです。
上記の構成の中でエンジニアが手を動かしてセットアップしたのはEC2とSESくらいでした。

EC2単体では他のIaaSやVPSで代替可能な部分もありましたが、
ELBのメリットを考えると、EC2を選択せざるを得ません。
SSLターミネーションとか、相当楽チンです。統一することでコントロールパネルも1つにできますし。

ローンチ後が予測できない状態で、IaaSの柔軟性やスピード感はやはり魅力的です。
その中でもAWS製品のフルラインナップは、エンジニアを幸せにしてくれます。（むしろ仕事を奪うかも・・・）
iichiの場合はHA構成など手厚くする余地はありますが、そこを調整していく上でもIaaSの手軽さは助かります。

おわりに

AWSイケテルって話に終始してしまいましたが、あの製品フルラインナップはやっぱり魅力です。
今後、各コンポーネント毎に内情を紹介できる部分があればしていきたいと思います。

それではまた。