こんにちは、松本です。
3月の最終エントリ以後、暑すぎて ダラダラし過ぎました。Blogをちゃんと書くようにします。

今回はperlのフレームワーク "Sledge" でテンプレートエンジンの "Text::Xslate" を使います。

Template-Toolkitについて

Sledgeで利用するテンプレートエンジンは TT（Template-Toolkit） がデファクトスタンダードであります。
（HTML::Templateも使えますが・・・）

TTは、テンプレートエンジンとして非常に柔軟性が高く、大変に使いやすいのですが何せ、処理が重いです。

6A（シックス・アパート）のBlogサービスの、VoxもTemplate-Toolkitを利用しているらしいのですが

Template Toolkit: profile. Wow! Template Toolkit takes 60% of the request time.

との事で、リクエストの処理全体の6割をTTが占有してしまっているという驚愕の事実らしいです。

弊社でも ClearSilver 、 Text::MicroTemplate 、 Tenjiin などを Sledge に組み込めるか、試行錯誤してみたのですが
TTと全く違う文法で記述されたHTMLテンプレートが、プロジェクト毎に混在するとなると、運用面で人的負荷や稼動コストが増える可能性があったため、見送っていました。

• （参考）How we build Vox - SlideShare
  • http://www.slideshare.net/miyagawa/how-we-build-vox
• （参考2）Sledgeから利用する各種テンプレートエンジンの設定例 - ありんく Tech Wiki
  • http://www.alink.co.jp/tech/wiki/index.php?Perl%2F%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%EF%BC%88MVC%EF%BC%89%2FSledge#rfeaae0e

Text::Xslate

Text::Xslate は、藤 吾郎さん が CPAN で公開されているモジュールで、精力的にUPDATEされているテンプレートエンジンです。

TTとほとんど同一の文法でHTMLテンプレートを記述することができ、更に高速動作するモジュールでして
先の 6割の処理の部分を抑える事ができるのでは？と期待大です。

• Text::Xslate
  • http://search.cpan.org/dist/Text-Xslate/
• Text::Xslate 公式ページ
  • http://xslate.org/

TTの文法により近づけるために Text::Xslate::Bridge::TT2Like モジュールも併せて利用します。

インストール

cpanm で さっくりインストールです。

cpanm -S Text::Xslate Text::Xslate::Bridge::TT2Like

Sledgeのテンプレートクラス

ズバリ、以下のテンプレートクラスをPages.pmから呼び出しています。

Prog/Pages.pm （一部）

シンタックスハイライトを付けてある、全コードは こちら

sub create_template {
    my ($self, $file) = @_;
    my $tmpl = Proj::Template::Text::Xslate->new($file, $self);
    return $tmpl;
}

Proj/Template/Text/Xslate.pm

シンタックスハイライトを付けてある、全コードは こちら

package Proj::Template::Text::Xslate;

use utf8;
use strict;
use warnings;
#use base qw/Sledge::Template/;

use Text::Xslate;
use Scalar::Util;

use vars qw($Tx);
$Tx = '';

sub new {
    my($class, $file, $page) = @_;
    bless {
        _options => {
            filename => $file,
        },
        _params  => {
            config  => $page->create_config,
            r       => $page->r,
            session => $page->session,
        },
    }, $class;
}

sub add_associate       { Sledge::Exception::UnimplementedMethod->throw }
sub associate_namespace { Sledge::Exception::UnimplementedMethod->throw }

sub output {
    my $self = shift;
    #my %config = %{$self->{_options}};
    #my $input  = delete $config{filename};
    my $input  = delete $self->{'_options'}->{'filename'}
                           || Sledge::Exception::TemplateNotFound->throw(
                                   "No template file detected. Check your template path.",
                              );
    if(!$Tx) {
        my %config = %{$self->{_options}};

        $config{syntax}    = 'TTerse';
        $config{header}    = [ qw/commons.inc/ ];
        $config{module}    = [ qw/Text::Xslate::Bridge::TT2Like/ ],
        $config{path}      = [ $self->{'_params'}->{'config'}->tmpl_path, $self->{'_params'}->{'config'}->tmpl_path . '/includes' ];
        $config{cache}     = 1;
        $config{cache_dir} = $self->{'_params'}->{'config'}->cache_dir . '/text_xslate_cache';
        $config{type}      = 'text';
        $config{function}  = {
            nl2br      => \&Text::Xslate::Bridge::TT2Like::html_line_break,
            uri_escape => \&Text::Xslate::uri_escape,
        };
        $Tx = Text::Xslate->new(%config);
        #warn "[ CREATE TX ]";
    }
    unless (-e $input) {
        Sledge::Exception::TemplateNotFound->throw(
             "No template file detected. Check your template path.",
        );
    }
    $input =~ s@/path/to/proj/view/@@;
    my $output = $Tx->render($input, $self->{'_params'});
    $self->finalize;
    return $output;
}

sub param {
    my $self = shift;
    if (@_ == 0) {
        return keys %{$self->{'_params'}};
    }
    elsif (@_ == 1) {
        return $self->{'_params'}->{$_[0]};
    }
    else {
        while (my($key, $val) = splice @_, 0, 2) {
            $self->{'_params'}->{$key} = $val;
        }
    }
}

sub finalize {
    my $self = shift;
    for my $key ($self->param()) {
        if( ! ref( $self->{'_params'}->{$key} ) || $key eq 'session' || $key eq 'r' || $key eq 'config') { next; }
        if (!Scalar::Util::isweak($self->{'_params'}->{$key})) {
            #warn "[ WEAKEN ] ".$key;
            eval { Scalar::Util::weaken($self->{'_params'}->{$key}) };
        }
        delete $self->{'_params'}->{$key};
    }
}

1;

速度比較

Template-ToolkitからText::Xslateに変更することで、大よそ 150% ぐらい、リクエストの処理速度が向上しました。

今まで 100req/sec だったものが 150req/sec に高速化された形です。

気になった点、ハマッた点

• mod_perlのプロセスサイズが 120%ぐらい増えました。 メモリが少ない環境では要注意かも。

ハマッた点

Docsにも書いてある点がほとんどなので、ちゃんと読め！という部分なのですが・・・

• [% INCLUDE "header.inc" %] など、 "（ダブルクォーテーション）でファイル名を囲まないといけないです。

• TTのオプションに存在する、"ABSOLUTE" が使えないので INCLUDE内のファイルに明示的に変数を渡さなければならないので

  [%- INCLUDE "header.inc" WITH
      FOO = 'ふー'
   -%]

  などとWITHで記述します。

• TTでいう、PROCESS、INSERT は使えないです。

• マクロを呼び出すときに、[% macro_func %] でなく、[% macro_func() %] と () を付ける必要があります。

• render($file,$param) で指定する $fileは path で指定された以下のファイルパスを指定します。（絶対パスではないです）

• TTの PRE_PROCESS は Text::Xslate の new時に渡す引数の header に相当します

まとめ

Template-Toolkitとほとんど同一の記法で、基本差し替えるだけで
Webアプリ全体の処理速度が向上しますので、是非ご利用されてみてはいかがでしょうか。

150%の処理速度向上が見込めましたので、次回プロジェクトでは試行してみたいと思います。

peclでは memcacheモジュール が有名どころでありますが、 memcachedモジュール （"d"が最後にくっついた）というものもあり、こちらは libmemcached をベースにしたモジュールとの事です。

memcachedモジュールは digg の中の人が作成されたモジュールとの事で、リリース後まだ1年ぐらいですが
get_multiをサポートなど今後の期待大のモジュールです。

ということで早速インストールしてみます。

libmemcached のインストール

http://tangent.org/552/libmemcached.html
libmemcached 本体をDLします。

現時点（2010.3.18）では0.38が最新版ですのでこれをDLします。

※CentOS4でのインストール時には、gccのバージョンが違うためでしょうか、make時にエラーになりました。この場合にはlibmemcachedのバージョンを落として利用しました。（今回は0.32に落としたら通りました）

wget http://download.tangent.org/libmemcached-0.38.tar.gz
tar xvzf libmemcached-0.38.tar.gz
cd libmemcached-0.38

32bit環境だとそのままのconfigureでエラーが発生するので、configure で若干の指定を追加します。
※こちらのBlog を参考にしました。

64bitの場合 （そのままで指定なし）

./configure

32bitの場合

./configure -disable-64bit CFLAGS="-O3 -march=i686"

make -> インストールします。

sudo make install

pecl memcached をインストール

以下から最新版のをDLします

• http://pecl.php.net/package/memcached

※github版はこれですかね・・？

• http://github.com/digg/php-memcached

※memcached モジュールはdiggの中の人が作ったらしいです

• http://codezine.jp/article/detail/3535

pecl コマンドでインストール

一発でインストールです。楽ですね

sudo pecl install libmemcached

ソースからインストール

wget http://pecl.php.net/get/memcached-1.0.1.tgz
tar xvzf http://pecl.php.net/get/memcached-1.0.1.tgz
cd memcached-1.0.1
phpize
./configure
make install

PHPに認識させる

/etc/php.ini に以下を追加します

[memcached]
extension=memcached.so

mod_php でも認識させるため Apache(httpd)を再起動させます

sudo service httpd restart

確認する

phpinfoでmemcachedモジュールとlibmemcached のライブラリが認識されているか確認します

$ php -R ' phpinfo(); exit(); ' | grep memcached

memcached
memcached support => enabled
libmemcached version => 0.38
Registered save handlers => files user sqlite memcached tokyo_tyrant

ブラウザ越しに mod_php での挙動も確認します

<?php
phpinfo();

サンプルプログラム

弊社ではCacheクラスを作り、それをインスタンス化して利用しています。

コマンドラインでのスクリプト

きちんと実行されれば、 "hoge" と "array" をキーにした値が表示されると思います。

#!/bin/env php
<?php

ini_set('memory_limit','-1');
set_include_path(".");

include_once('./Proj_Cache.class.php');

define('MEMCACHED1_HOST','localhost');
define('MEMCACHED1_PORT','11211');

$cache = Proj_Cache::get_instance();

$cache->set('hoge','ほげ');
$cache->set('array',array(1,2,3,4,5,6,7,8,9,10));

var_dump($cache->get('hoge'));
var_dump($cache->get('array'));

Cacheクラス

<?php
class Proj_Cache {

    private static $singleton;
    private static $memcache;

    private function __construct() {
        $this->memcache = new Memcached();
        $this->memcache->addServer(constant('MEMCACHED1_HOST'),constant('MEMCACHED1_PORT'),0.1);
        if(defined('MEMCACHED2_HOST') && defined('MEMCACHED2_PORT')) {
            $this->memcache->addServer(constant('MEMCACHED2_HOST'),constant('MEMCACHED2_PORT'),0.1);
        }
    }

    public static function get_instance() {
        if (!is_object(self::$singleton)) {
            self::$singleton = new Proj_Cache();
        }
        return self::$singleton;
    }

    public function get ($key) {
        // error_log("[ GET CACHE ] key:".$key);
        $var = $this->memcache->get($key);
        return $var;
    }

    public function set ($key,$value,$exp=60) {
        //error_log("[ SET CACHE ] key:".$key." exp:".$exp);
        $var = $this->memcache->set($key,$value,$exp);
        return $var;
    }

    public function remove ($key) {
        //error_log("[ REMOVE CACHE ] key:".$key);
        $this->memcache->delete($key);
    }

    /* @throws RuntimeException */
    public final function _clone() {
        throw new RuntimeException ('Clone isn now allowd against '. get_class($this));
    }

}

いかがでしょうか、ほとんど自分の覚え書きだったりもするのですが・・・
お役に立ちますと幸いです。

関連リンク

• pecl-memcached
  • http://pecl.php.net/package/memcached
• 新しいPHP用memcached拡張を diggが公開 PECLでバージョン0.1.0をリリース （codezine）
  • http://codezine.jp/article/detail/3535

• libmemcachedライブラリ
  • http://tangent.org/552/libmemcached.html
• libmemcachedライブラリの configure 時のエラーへの対処法など
  • http://redbeardtechnologies.wordpress.com/2010/01/2…

• PHPのワンライナープログラム（phpinfoなどの確認でこの方法を良く使っています）
  • http://d.hatena.ne.jp/hnw/20090621

こんにちは、松本です。
熱かったり寒かったり 中々でありますが、いかがお過ごしでしょうか。
TwitPepper（ツイットペッパー）の解説も完結しない中、perl案件をこなしつつ、PHPで動的にJSを書いていると中々なカオスであります。

PHP5.3.2のリリース に伴い、早速にアップグレードしまして メモがてらインストールログです。

configure

configureは CentOS5.3 で PHP5.3をインストール（YUM風オプションで） に倣いまして、yum風な設定にしています。

x86_64（64ビット）

以下をコピペしてお使い下さい

./configure –with-apxs2=/usr/sbin/apxs –build=x86_64-redhat-linux-gnu –host=x86_64-redhat-linux-gnu –target=x86_64-redhat-linux-gnu –program-prefix= –prefix=/usr –exec-prefix=/usr –bindir=/usr/bin –sbindir=/usr/sbin –sysconfdir=/etc –datadir=/usr/share –includedir=/usr/include –libdir=/usr/lib64 –libexecdir=/usr/libexec –localstatedir=/var –sharedstatedir=/usr/com –mandir=/usr/share/man –infodir=/usr/share/info –cache-file=../config.cache –with-libdir=lib64 –with-config-file-path=/etc –with-config-file-scan-dir=/etc/php.d –with-pic –with-bz2 –with-curl –with-exec-dir=/usr/bin –with-freetype-dir=/usr –with-png-dir=/usr –enable-gd-native-ttf –with-gettext –with-gmp –with-iconv –with-jpeg-dir=/usr –with-openssl –with-pcre-regex=/usr –with-zlib –with-layout=GNU –enable-exif –enable-ftp –enable-magic-quotes –enable-sockets –enable-sysvsem –enable-sysvshm –enable-sysvmsg –enable-wddx –enable-ucd-snmp-hack –enable-shmop –enable-calendar –with-libxml-dir=/usr –enable-pcntl –enable-mbstring –enable-mbregex –with-gd=shared –enable-bcmath=shared –enable-dba=shared –with-db4=/usr –with-xmlrpc=shared –with-mysql=/var/lib/mysql –with-mysql-sock=/var/lib/mysql/mysql.sock –with-mysqli=shared,/usr/bin/mysql_config –enable-dom=shared –enable-soap=shared –with-xsl=shared,/usr –enable-xmlreader=shared –enable-xmlwriter=shared –with-pdo-mysql=shared,/usr –enable-zip –enable-zend-multibyte –with-mcrypt

i386（32ビット）

以下をコピペしてお使い下さい

./configure –with-apxs2=/usr/sbin/apxs –build=i386-redhat-linux-gnu –host=i386-redhat-linux-gnu –target=i386-redhat-linux-gnu –program-prefix= –prefix=/usr –exec-prefix=/usr –bindir=/usr/bin –sbindir=/usr/sbin –sysconfdir=/etc –datadir=/usr/share –includedir=/usr/include –libdir=/usr/lib –libexecdir=/usr/libexec –localstatedir=/var –sharedstatedir=/usr/com –mandir=/usr/share/man –infodir=/usr/share/info –cache-file=../config.cache –with-libdir=lib –with-config-file-path=/etc –with-config-file-scan-dir=/etc/php.d –with-pic –with-bz2 –with-curl –with-exec-dir=/usr/bin –with-freetype-dir=/usr –with-png-dir=/usr –enable-gd-native-ttf –with-gettext –with-gmp –with-iconv –with-jpeg-dir=/usr –with-openssl –with-pcre-regex=/usr –with-zlib –with-layout=GNU –enable-exif –enable-ftp –enable-magic-quotes –enable-sockets –enable-sysvsem –enable-sysvshm –enable-sysvmsg –enable-wddx –enable-ucd-snmp-hack –enable-shmop –enable-calendar –with-libxml-dir=/usr –enable-pcntl –enable-mbstring –enable-mbregex –with-gd=shared –enable-bcmath=shared –enable-dba=shared –with-db4=/usr –with-xmlrpc=shared –with-mysql=/var/lib/mysql –with-mysql-sock=/var/lib/mysql/mysql.sock –with-mysqli=shared,/usr/bin/mysql_config –enable-dom=shared –enable-soap=shared –with-xsl=shared,/usr –enable-xmlreader=shared –enable-xmlwriter=shared –with-pdo-mysql=shared,/usr –enable-zip –enable-zend-multibyte –with-mcrypt –enable-mbstring

インストール

sudo make install

以下のコマンドでPHPのバージョンが"5.3.2"と表示されればOKです。

$ php -v

PHP 5.3.2 (cli) (built: Mar  6 2010 20:49:38)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

httpd を再起動してPHPを読み込み直します。

# service httpd restart

eAcceleratorをインストール

eAccelerator をデフォルトで利用しています。
こちらも make し直して、新規にインストールします。

cd /usr/local/src
wget http://bart.eaccelerator.net/source/0.9.6/eaccelerator-0.9.6.tar.bz2
tar jvxf eaccelerator-0.9.6.tar.bz2
cd eaccelerator-0.9.6
phpize
./configure --enable-eaccelerator=shared
export SED=sed
sudo make
sudo make install

php.ini に記述追加

※zend_extension は eaccelerator.so のインストール先を指定します。

※eaccelerator.cache_dir の指定先ディレクトリは予め作成しておきます。

[eaccelerator]
zend_extension="/usr/lib/20090626/eaccelerator.so"
eaccelerator.shm_size = "32"
eaccelerator.cache_dir = "/var/php-cache/eaccelerator"
eaccelerator.enable = "1"
eaccelerator.optimizer = "1"
eaccelerator.check_mtime = "1"
eaccelerator.debug = "0"
eaccelerator.filter = ""
eaccelerator.shm_max = "0"
eaccelerator.shm_ttl = "86400"
eaccelerator.shm_prune_period = "0"
eaccelerator.shm_only = "0"
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"
eaccelerator.keys     = "shm_and_disk"
eaccelerator.sessions = "shm_and_disk"
eaccelerator.content  = "shm_and_disk"

phpのバージョンを再度確認

以下のコマンドでPHPのバージョンが"5.3.2"と表示され、eAccelerator がその下に記述されていればOKです。

$ php -v

PHP 5.3.2 (cli) (built: Mar  6 2010 20:49:38)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
   with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by eAccelerator

eAccelerator を使う環境で VirtualHost をする

eAccelerator を使う環境で VirtualHost をする場合、httpd.conf の 同 VirtualHost 内の セクションに以下を記述します。

name_space 名は、他と重複しなければ何でも良いです

   php_value eaccelerator.name_space "project_name"

メモがてら程度の簡単なログですがお役に立てますと幸いです。

関連リンク

• PHP本家
  • http://php.net/
• eAccelerator本家 ※0.9.6 がリリースされています。
  • http://eaccelerator.net/

こんにちは、松本です。寒い中 いかがお過ごしでしょうか。

1月冒頭に 年始の抱負 を書いた後、忙しさにかまけ、jQuery と PHP の新バージョンに心踊らせるのに精一杯で、Corei7の低TDP版 "Corei7-860S" の登場にも気付かず今日気づきました。
ついに Core2 Quad シリーズも世代交代か・・・と考え始めております今日この頃です。

今回弊社のサービス"TwitPepper（ツイットペッパー）"の技術面から見た中身についてご紹介したいと思います。

TwitPepper（ツイットペッパー）とは

TwitPepperとは、Twitterのデザインを外部から簡単に変更できるサービスを提供しているサイトです。

Blogサービスのスキン変更のように、自分もTwitterページをお手軽に色々なデザインに変更することができます。詳しくは TwitPepper内の解説ページ をご覧下さい。

遅ればせながらなのですが、昨年12.21にリリースしまして本年冒頭にプレスリリース、1月末に月間カレンダーシリーズをリリースしまして、好評頂いておりますサービスです。（3月分のカレンダーももうすぐアップされると思います。）

TwitPepperのWebアプリケーション概要

TwittPepperは、いわゆるLAMP構成で構成されています。LAMP構成の詳細は以下になっています。

• L・・・Linux (CentOS 4 i386)
• A・・・Apache 2.2 + Apache 1.3
• M・・・MySQL 5.0
• P・・・Perl（mod_perl）

それぞれの概要を記述していきます。

L・・・Linux (CentOS 4 i386)

TwittPepperのサーバは、さくらインターネットの専用サーバ を使っています。OSはCentOS4（i386/32bit）を利用しています。現在はまだそれほどのトラフィックが発生していないので、いわゆる10Mスタンダード がデフォルトで付いていますのでそちらを利用しています。
※サーバを借りた時期がやや以前なので、旧ネットワークプランにリンクしています。

さくらさんでは、OSは他にUbuntu、FreeBSDなども選択可能 ですが、弊社では新規のサーバは全てCentOSで統一しています。

また、バージョンは基本5、で i386（32bit）を選択しています。
（今回借りているサーバはやや以前に借りたサーバなので、バージョン4ですが、現在はデフォルトでバージョン5を選択しています。）

搭載するメモリ量について

x86_64（64bit）を選択しない理由は、64bit化するとWebアプリケーションのプロセスサイズが肥大化し、メモリ増強が必要になります。なのですが、さくらさんではメモリが月額料金にのっているため、月々のランニングコストに乗ってしまいます。

ランニングコストの内訳は以下になります。

弊社ではできるだけランニングコストを抑えたいので、メモリサイズを最小で運用できるi386（32bit）で運用し、まずはデフォルトのメモリ2Gで運用。その後メモリが必要であれば+2G（月額2,100円追加）で最大4G(2G+2G)に拡張し、32bitOSの上限値までメモリを利用できる形で1つのWebアプリケーションを完結させています。

ノウハウ集約のためにOSを統一

もちろん、案件によってはメモリ8Gを必要とするサーバの構築もありますので、そういった場合は x86_84（64bit）のOSを積み、そもそもメモリ4Gの壁が存在しない形にしています。

以前はFreeBSD、RedHaｔLinux、FedoraCoreが混在していたのですが、CentOS以降は書籍・ネット上の資料がCentOSが一番多いと判断しまして、ノウハウの集約をする為にも、OSは統一しています。

自分は以前からFreeBSDをずっと使ってきていて、慣れている部分も多かったのですが・・・ yumの利便性と、案件によってはJavaが動作する環境が必要だったため、Linuxに移行しました。

関連リンク

• さくらインターネット・専用サーバTOP
  • http://server.sakura.ad.jp/
• さくらインターネット・専用サーバ サービス仕様
  • http://server.sakura.ad.jp/dedicated/specification.html

A・・・Apache 2.2 + Apache 1.3

WebサーバはApacheを利用しています。こちら、表記が2つあり Apache 2.2 と Apache 1.3 の2つが存在しています。
これは、"リバースプロキシ（Reverse Proxy）" という技術を使ってWebアプリケーションを運用しているため、1つのサーバに2つのWebサーバが混在しているという形になっています。

リバースプロキシ（Reverse Proxy）とは

"リバースプロキシ（Reverse Proxy）" という技術は色々な場面で使われています。
弊社では主に "Webサーバを多段構成にする事で、負荷軽減を狙うための技術" として用いています。
とても簡単な図解なのですが、以下の様に構成しています。

• リバースプロキシ（Reverse Proxy）の構成例
  

Proxy側（フロント）・・・Apache2.2

Proxy側（フロントエンド）は yum 経由でインストールできる、 Apache2.2 を利用しています。 yum が使えない場合はソースコードからApache2.2をインストールします。

• yum から Apache2.2をインストール

  sudo yum install httpd

• ソースコードから Apache2.2をインストール

  ./configure --enable-mods-shared=all
  --enable-so
  --enable-proxy
  --enable-proxy-connect
  --enable-proxy-http
  --enable-proxy-balancer
  --enable-ssl
  --enable-dav
  --enable-cache
  --enable-disk-cache
  --enable-mem-cache 
  
  sudo make install

Apache2.2 を利用している理由は、まず Apache2.x 以上のApacheは SSLの扱いが簡単という点と、Apache2.2 以上ではmod_mem_cache / mod_disk_cache と、 mod_proxy_balancer が使える点が大変に大きいです。

この2つが最初から使えることで、後々スケールアウトの必要が出てきた場合も柔軟に対応できます。

※＜参考＞Apache 2.0 のインストール
何らかの事情でApache 2.2 ではなく、Apache 2.0 をインストールしなければならない場合は以下のように configure のセッティングを行っています。
prefix の指定は、今後Apache2.2がインストールされたとしてもインストールディレクトリ先が重複しないための措置です。

• Apache 2.0.x 本体のインストール

  ./configure --prefix=/usr/local/apache20
   --enable-mods-shared=all
   --enable-so
   --enable-proxy
   --enable-ssl
   --enable-dav

App（アプリケーション）側・・・Apache1.3

アプリケーション側は Apache1.3を利用しています。
TwitPepperでは mod_perl を利用しています。Apache1.3 のmod_perlを利用するために
必要なミドルウエア、モジュールをソースからインストールします。

• Apache 1.3 本体のインストール

  ./configure
   --enable-shared=max
   --enable-module=all
   --disable-module=auth_dbm
  
  sudo make install

続いて mod_perl をインストールします。 mod_perl 自体のダウンロードは こちら から行うことができます。
今回はApache1.3用のmod_perlですので、 "For use with Apache 1.3.x " の "Download" のリンク先をダウンロードします。

• Apache 1.3 に mod_perlをインストール

  wget http://perl.apache.org/dist/mod_perl-1.0-current.tar.gz
  tar xvzf mod_perl-1.0-current.tar.gz
  cd mod_perl-1.31
  
  perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/apache/bin/apxs EVERYTHING=1
  
  make install clean

APXSの指定先はApache 1.3をインストールしたディレクトリを指定します。
今回はデフォルトのprefixですので "/usr/local/apche/" 以下の "bin/apxs" になります。

Proxy 側（フロント）側の設定

Proxy（フロント）から、バックエンドのアプリケーションサーバにリクエストを飛ばすために、Proxy（フロント）のhttpd.confに以下のように記述しています。

/usr/local/apache2/conf.httpd.conf に記述

ProxyRequests Off
ProxyPreserveHost On
RewriteRule ^/(.*)/([a-z_]+)-([0-9]+).html$ http://localhost:xxxx（ポート番号）/project_path/$1/$2?id=$3&%{QUERY_STRING} [P,L]
RewriteRule ^/(.*).html http://localhost:xxxx（ポート番号/project_path/$1?%{QUERY_STRING} [P,L]
RewriteRule ^/(.*) http://localhost:xxxx（ポート番号/project_path/$1 [P,L]

• 1行目・・・フォワードプロキシサーバとしての動作を無効化しています ProxyRequestsについての詳細はこちら
• 2行目・・・HTTPヘッダのHost:行をProxy側と同じものをApp側にも飛ばすための設定です。ProxyPreserveHostについての詳細はこちら
  これを行わないと、Host部での解釈ができないためApp側でのVirtualHostが有効に働きません。
• 3行目～5行目・・・Proxy条件・設定です。この部分で記述した書式に従い、Proxy先にリクエストを飛ばします。
  各行の最後に "[P.L]" と終わっていますが、これはmod_rewriteの書式で"Proxyして（P）、条件定義はこの行で終了（L）" という意味になります。

App（アプリケーション）側の設定

App側は基本的には、リクエストがReverseProxyかどうかを判別する必要はありません。なのですが、REMOTE_ADDR（リモートアドレス・接続元）が全てProxy元（今回は同一サーバなので、127.0.0.1＝ローカルホスト）になってしまい、アクセスログにも全てProxy元のIPアドレスが記述されます。

アプリ的、ログ解析的にも特に気にしない場合はいいのですが、やはり、アクセス状況を知りたいという場合が来るケースが多いと思いますので
Proxy元が受けたREMOTE_ADDRと同じ値（ユーザーのIPアドレス）をProxy先にもとどくよう、設定します。

設定には mod_extract_forarded モジュールを使います。
（配布されている方のURLをリンクしようと思ったのですが、現在サーバが存在していないようです。もう1.3用のモジュールの配布は終了されてしまったのでしょうか？）

mod_extract_forarded を Apache1.3に適用するには以下のようにしています。

• mod_extract_forarded をインストール
  ※mod_extract_forwarded.c が存在するディレクトリに移動して、

  /usr/local/apache/bin/apxs -i -a -n 'extract_forwarded' mod_extract_forwarded.so

• /usr/local/apche/conf/httpd.conf の設定
  以下を追加

  LoadModule extract_forwarded_module libexec/mod_extract_forwarded.so
  
  AddModule mod_extract_forwarded.c
  
  <IfModule mod_extract_forwarded.c>
      RemoveAcceptForwarder all
      AddAcceptForwarder all
  </IfModule>

※＜参考＞ Apache2 の mod_extract_forwarded
Apache 2.x 用の mod_extract_forwarded については、以下からダウンロードできるようです。
（Apche2.0.x 用と書いてありますが、Apache 2.2 でも一応インストールできました。）

• http://www.cotds.org/mod_extract_forwarded2/

関連リンク

• Apache 公式
  • http://httpd.apache.org/
• mod_perl 公式
  • http://perl.apache.org/

M・・・MySQL 5.0

MySQLは全て、yum経由の 5.0.x を利用しています。 現在主流のMySQL5.1 も利用したいのですが、 yum で簡単にインストールできるという部分が、マニュアル化・アプリ全体の品質の統一に大変有効だと思いまして、現在は yum でのインストールのみを利用しています。

yumでのインストールは簡単です。perl用のDBDドライバも同時にインストールします。

yum install mysql mysql-server perl-DBD-mysql

sudo service mysqld start

起動後、すぐにRootのパスワードを設定します。

mysqladmin -u root password 'xxxxxxxxxxx'

MySQLのUTF8対応

MySQLをUTF8対応するために /etc/my.conf で以下のように記述しています。

• [client] に以下を追記

  default-character-set = utf8

• [mysqld] に以下を追記

  default-character-set = utf8
  character-set-server=utf8

mysql に接続して、以下のように表示されれば、UTF8での扱いはほぼ問題ないのでは無いかと思います。

mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

mysql は chkconfig にも登録して置き、 boot時に起動するように設定しています。

sudo config add mysqld
sudo chkconfig mysqld on

P・・・Perl（mod_perl）

App側の動的処理は 全て mod_perl で書いています。弊社では案件によっては PHPを利用するケースもありますが、ほとんどの場合は mod_perl でソリューションしています。
特に自社内システムは100％ perl/mod_perl で動いています。

mod_perl 自体のインストールは先ほど書いたとおりになります。

mod_perl の上に乗せて動かすアプリケーションですが、コーディングルールの統一化を図るため、MVC（フレームワーク）を利用しています。
弊社では mod_perl用のフレームワークは Sledge を利用しています。
通常のSledge は、基本 EUC-JP を前提としているのですが、弊社ではデフォルトがUTF8ですので、UTF８で動かすためにカスタムモジュールを追加しています。

このSledge を mod_perl 上で扱い、その上に DB との通信するためのORマッパー（今回は Class::DBI ）、そしてテンプレートとして template-toolkit を利用しています。

参考リンク

• Sledge (sourceforge)
  • http://sourceforge.jp/projects/sledge/releases/
• SledgeのApache2（mod_perl2）対応＋UTF8
  • http://www.alink.co.jp/tech/blog/2009/06/19/sledge%E3%81%AEapache2%EF%BC%88mod_perl2%EF%BC%89%E5%AF%BE%E5%BF%9C%EF%BC%8Butf8/
• Class::DBI
  • http://search.cpan.org/perldoc?Class::DBI
• template-toolkit
  • http://template-toolkit.org/

次回に続きます。

少々記事が大きくなってしまいまして・・・ mod_perl ＋ Sledge + Class::DBI + TT(template-toolkit) については
"TwitPepper・Webアプリの中の人（その2）" に続きます。

memcached などもカリカリ使っていますので、こちらに付いても書きたいと思っています。

明けましておめでとうございます、寒すぎます。松本です。

年末年始はちょっとコードを書きながら、魚介類をサバいて終えました。たまには駅伝をみながらまったりお雑煮を食べたいです。

今年の目標

今年はプログラム技術力、Webアプリケーションを開発する技術力を向上させ
もっと効率的に柔軟なシステムを作れるようになりたいと思っています。

Perl/mod_perl

弊社で利用しているプログラム言語は mod_perl なのですが、これをベースにSledgeというMVCを使い、Webアプリケーションを開発する事が主です。

mod_perlもSledgeも非常に高速で、素晴らしいアプリケーションなのですが、これの上にのせていくORマッパやその他モジュールが相当にメモリ食いで、[雑感] ありんくTech的2009年まとめ でも言及していますが、利用するモジュールによって、メモリ消費っぷりがエラく違います。

結果的に1台のサーバで処理出来る量が、メモリの使用量によって左右されることの無いように省エネでエコなプログラムを意識して参りたいと思います。
CPUはもうQuadCore任せで。

参考リンク

• [perl] Sledgeドキュメントまとめ
  • mod_perlのMVC"Sledge"についてリンクをまとめています
• [perl] mod_perl起動時のstartup.plでの便利な手法
  • httpdの起動時に共通するモジュールを読み込む事により、プロセス毎に共有メモリを効率的に扱える手法です

PHP

弊社でperl以外に扱っているプログラム言語が PHP です。

PHPは5.3.x以降を利用するようにしていて、perlと同様ですがメモリ消費を抑えたいと思い、ガベージコレクションの恩恵に預かりたいという意図であります。

PHP5.3の最新バージョンは 5.3.1 ですが RCバージョンの5.3.2 も登場し、安定性のある形になってきていると思います。
必須ツールである、XDebug、APC も5.3に対応しています。

※memcache モジュールが memcached1.4のDELETEの仕様変更に対応していないので、こちらが惜しまれるのですが・・・

その他のプログラム言語

サーバサイドはperl/PHPですが、フロントエンド側の JavaScript CSS/HTML も引き続きやっていきたいと思っています。

特にCSSついては、ブラウザの種類が増えるほどに意識しないといけない事が増えていきますので
常にいじり続けたいと思っています。

JavaScriptはもうjQuery以外はほとんど扱っていません。jQueryは多分今年1.4がリリースされると思いますので、更に便利になると思います。
※jQueryについては tech-wiki にまとめてあります。

ActionScriptもトライ＆エラーしたいのですが、先にiPhone/iPod用に対するWebアプリケーションの学習が発生しそうな予感です。

次の振り返りは多分5月末の35歳になりましたエントリ辺りの予感です。

ということで、今年もどうぞよろしくお願いいたします。

こんにちは、松本です。
tech-logで2009年の総括をまとめるつもりで、ずるずるしていまい、大晦日にまとめてみました。

"34歳になりました＆抱負"の記事 で書いていた事を全ては実践出来ず、若干に心残りではありますが、やれた事はおおよそ以下です。

TwitPepperのリリース

12月中順に　TwitPepper（ツイットペッパー） をリリースしました。Twitterのデザインを簡単に変更したり、シェアリングできるサイトなのですが、とりあえず、まず1つサービスを定義する事ができた事が大変に良かったです。

本ブログの本格化

2009年3月より本ブログを本格的に書き始め、最低でも毎月2回程度は更新できました。お陰さまで色々な人に見て頂くことができました、ありがとうございます。

CPANやGoogleCodeでのプログラム公開

CPAN にモジュールが公開できたのも大変に嬉しかったです。
自分はmod_perl + Sldegeを使う機会が多いので、Sledgeのモジュール中心ですが、こちらもお役に立てると大変に嬉しいです。

GoogleCode では、jQueryのプラグインをUPしました。

Perlの高速・軽量なORマッパの学習

DBIx::Skinny や Data::Model 、 DBIx::MoCo など、Perlの軽量なORマッパがリリースされた事が大変インパクトが大きく感じました。（MoCoの最終更新は2008年ですが・・・）

実際に今までプロダクション環境では Class::DBI（CDBI） を使うことが大変多かったのですが、 DBIx::Class（DBIC）は、移行するにはモジュールの規模が大きすぎたり、ちょっともっさり過ぎなどオーバーヘッドを相当に感じたため、躊躇していました。

それもあり、省エネ・軽量のORMに注目しています。この中で特に DBIx::MoCo を学習していて、使い方としては一番CDBIに近いのかなと感じています。
saveメソッドだけが、CDBIのUPDATEと大きく違うのでここの取扱がまだ慣れていないです。

ORMごとのメモリ消費量

現在メインで使っているCDBIを含め、ほぼ同じ動作をする際のメモリ消費量を比べてみました。
メモリ消費量の計測は おいぬま日報さんのgtop.pl を使用させて頂きました。

※メモリ消費量は1の位で四捨五入しています。
※DBIx::Class（DBIC） は対象に入れていません。（そもそもメモリ食いなので）

64bit環境と、32bit環境でのメモリ消費量の違いも格段に目立ちますが、それでも DBIx::Skinny の省エネっぷりは目を引きます。

ORMはその習得自体のラーニングコストが結構にかかるため、ある程度目星をつけてからのトライ＆エラーの方が望ましいとは思います。
が、DBIx::MoCo に慣れつつある昨今、それにしても DBIx::Skinny のメモリ消費の少なさに驚き、いきなり食いついてしまった次第であります。

参考リンク

• DBIx::Skinny - JPerl Advent Calendar 2009
  • http://perl-users.jp/articles/advent-calendar/2009/dbix-skinny/
    DBIx::Skinnyに関するHowToが大変詳しく掲載されています。
• Data::Model Track - JPerl Advent Calendar 2009
  • http://perl-users.jp/articles/advent-calendar/2009/data-model/
    Data::Modelに関するHowToが大変詳しく掲載されています。

jQuery1.3を早々に利用開始できた

jQuery1.3 のリリースで、セレクタの速度向上とliveイベントの新機能が大変便利になったと感じました。

liveイベントは本当に便利で、例えば既存のエレメントのノードに新しいエレメントを追加し、同じ挙動を適用させたい場合、
以下の様に書いていました。

//イベントハンドラの定義
var event_function = function(){ /* event function */ };
// 既存のクラスにイベントハンドラを適用
$('.hoge').click(event_function);
//エレメントの作成
var $element = $('<div class="hoge">NewElement</div>');
//イベントハンドラの追加
$element.click($event_function);
//エレメントの追加
$('#old_element').after($element);

これをjQuery1.3（実質は1.3.2）では、イベントハンドラとエレメント作成を完全分離できるので
以下の様に定義出来ます。

// イベントハンドラの定義
$('.hoge').live('click',function(){  /* event function */ });
//エレメントの作成→追加（イベントは自動で定義）
$('#old_element').after('<div class="hoge">NewElement</div>');

動的なエレメント追加にもイベントが追いかけてくれますので非常にシンプルに実装できる点が大変魅力です。
jQuery1.2.x環境から 1.3.2に移行しましたが、jQueryUIのライブラリ周りで若干ハマる程度で、jQuery本体は差し替えても
ほぼ綺麗に移行できるはずです。

蛇足ではありますが、jQuery1.4ではこのliveイベントでほぼ全てのアクションが定義できるようになるため、さらに便利になります。
※jQuery1.4については「jQuery1.4のα版がリリースされたようです」の記事で更に詳細を書いています、よろしければご覧下さい。

参考リンク

• jQuery色々まとめリンク（ありんく tech-wiki）
  • http://www.alink.co.jp/tech/wiki/index.php?jQuery

PHP5.3.x の利用開始

すでに PHP5.3.1 がリリースされているPHPですが、5.3のリリースで 無名関数、staticコール、ガベージコレクションが実装されたのが相当にインパクト大でした。

現在は全てのPHPを利用する環境のVerを5.3にすべく、調査している段階です。

弊社HPのiPhone版のリリース

弊社HP（http://www.alink.co.jp/）で、同一URLでiPhoneからのアクセスの時だけ
iPhone様のデザインでのサイトをリリースしました。

iPhone様のHTMLはCSSのfont-sizeの感覚が違ったり、UIの想定する動作が指（マウスではない）などでやや詰まりますが
全体としてそこまで難易度は高くなかったと思います。

ざっと考える限りは以上の様な具合です。

本当に歳を経るほど、時間の流れが速く感じまして
やろうと目標に掲げた事の半分も実践出来なかったような体感っぷりです。

来年は35歳になります。時の流れはどんどん高速になって行きますが
PGとして定年にならないよう、もっとソースコード自体をきちんと書き、保守性の高い、品質の良いプログラムを書けるように精進したいと思っています。

来年もどうぞ 株式会社ありんく をよろしくお願いいたします。

2009.12.31 松本 修士

こんにちは、松本です。またまた雨で、悩ましい雨雲の動き であります。

jQuery1.4のアルファ版がリリースされたようです。

• jQuery 1.4 Alpha 1 Released - jQuery Blog

まだα版ではありますが、jQueryはバージョンアップ毎に処理が高速化されているので、大変楽しみです。まだ Downloadのページ には記載がありませんが、 同Blogの記事内 からダウンロードできます。

ダウンロード

• こちらから ダウンロードできます。
  ※まだα版（試験版）ですのでご利用には十分ご注意ください。

主な変更点は以下のようです。（適当日本語訳です。）
※下記英語記述は jQueryBlog より引用しています。

変更点1 : live eventsの大幅な強化

live 機能が大幅にオーバーホールされました。submit、change、mouseenter、mouseleave、focus、blurがサポートされました。

jQuery1.3以降、 live events という機能が追加されました。これは動的処理などで新しく加えたHTMLのノードに対して、予めイベントハンドラを定義しておく機能です。　詳しくは こちら をご覧下さい。

jQuery1.3.2までは、この機能は click、dblclick、mousedown、mouseup、mousemove、mouseover、mouseout、keydown、keypress,、keyup に対して定義されており、submit、change、mouseenter、mouseleave、focus、blur のイベントには定義されていませんでした。jQuery1.4a 以降は全てのイベントでlive eventsが使えるようです。

表にすると以下のような具合です。（※ jQuery日本語リファレンス・live(type, fn) を参考にさせて頂きました）

live events が機能するイベントハンドラ

変更点2 : append prepend周りなどの最適化

append prepend その他（の機能）は相当に最適化されています。

"その他"が何を意味するのかが大変気になりますが、少なくとも append/prepend 機能が最適化されています。

私見ですが、ここでいう最適化とは、ブラウザでのレンダリングスピード＋メモリの省エネ効果を表していると推測しています。

変更点3 : add の返り値の調整

add は常にドキュメントの中の列内のエレメントを返すように調整されました。

変更点4 : その他の最適化

find、empty、remove、addClass、removeClass、hasClass、attr、css　の機能が大幅に最適化されました。

変更点2の「その他」に該当する部分でしょうか、上記機能が最適化されているようです。

さらにその他の変更点

という感じです。その他の様々な変更点は こちらをご覧下さい との事で、見ていたのですが・・・ jQuery1.3.3 もリリースされる予定？？

ｊQueryUIや各種プラグインの対応状況が気になるところではありますが、jQuery本体が毎回大幅にチューニングされていますので、移行しない手は無いと思います。
今回も正式リリースがされ次第、移行Todoに入りたい所存であります。

関連コンテンツ

• ありんく tech-log / カテゴリ / jQuery
  • jQuery1.3の新機能「live events」

外部リンク

• jQuery本家
  • jQueryBlog

• jQuery日本語リファレンス （いつもお世話になっています）
  • jQuery日本語リファレンス（live eventsについて）

こんにちは、松本です。やはり雨でした。

弊社ではperlのORマッパーは CDBI をメインに使ってきましたが、最近では DBIx::MoCo をよく利用しています。

DBIx::Class も検討したのですが、依存するモジュールの量が多く、またラーニングコストも若干高く感じ、現在まだ使っていません。

DBIx::MoCoは はてな 製のORマッパーでCDBIに構造が良く似ています。

なのですが、1点 before_update/after_update の挙動が違いまして、以下となっています。

• CDBI
  • UPDATEするSQL文を発行する前後でHookが実行される。
• DBIx::MoCo
  • カラムの要素を更新した際にHookが実行される。

DBIｘ：：MoCoでもCDBIでいう「before_update/after_update」を実現するために、追加モジュールを作成しました。

• DBIx::MoCo::SaveTrigger （ソースコードはこちらになります）

このモジュールをuse すると save メソッド（UPDATE文の実行）前後に「before_save/after_save」を実行してくれます。
独自のCacheをかけていたり、UPDATEする際に必ず更新するカラムが存在する場合など、またCDBIからの移植でも
便利になるかと思います。

使っていただけますと幸いです。

• DBIx::MoCo::SaveTrigger

こんにちは。寒くてプラモも作れません、松本です。

PHP5.3.1が今日未明（2009-11-19）にリリースされていまして、早速インストールしてみました。
インストール時のconfigure周りの設定などは CentOS5.3 で PHP5.3をインストール（YUM風オプションで） （過去の記事） をご覧下さい。

インストール作業自体は何の問題も無く行えました。
アップデートした後のアプリケーションの挙動も特におかしな点はありませんでしたので、
運用しているシステムのアップデートもすんなりいけそうな予感です。

APCやeacceleratorの対応具合が若干気になります。

PHP5.3.1について

5.3.1 はメジャーバージョンのリリース後、最初のマイナーバージョンアップだけあって相当な数のバグ取りや調整などが行われています。
まずは安定化への第一歩という感じです。

PHP本家のサイトのアナウンスによると

一回の処理でアップロードできるファイル数の設定を定義する

max_file_uploads

の値のデフォルト値が20と定義されたようです。

1つのページでアップロード数を20個以上定義するのはgmailぐらいしか思いつかないのですが、そういう方向性という事で。

その他、特に目立った機能追加はないようでして、ほぼほぼがbugfixといった具合に見受けられます。

PHP自体の雑感ですが、引き続きSmartyは捨て、PHP＝テンプレート＋ロジックという認識でありまして、Gmagickやhidef周りをもうすこしいじってみたい所存であります。

久しぶりに雨ですが、こんにちは、松本です。

今年度が半分過ぎましたが、Web技術周りはトレンドの入れ替わりが激しいです。
なのですが、メンテナンスを継続している案件もあり、一概に新しいものだけを追い続けるわけにもいかない現状でして
古いものと新しいものが混在するのが世のDEVの方々の常だと思います。

新旧混ぜつつ、ここ最近でありんくのWeb技術まわりでトレンドであったり、特に注力していたりする事柄をつらつらと挙げてみます。

mod_perl

• http://perl.apache.org/

もう何年もお世話になっているモジュールです。適度に枯れていて、バージョンアップの頻度もぼちぼちといったところでいい感じに運用できます。
今まではずっとApache1.3系で利用してきているのですが、いい加減2.0系の方がいいのかな？と思いまして
1.3系と2.0系を比較してみました。

自分の比較テストでは1.3系、2.0系ともにほぼ同様の結果がでており、であれば

使い慣れた1.3系でまだまだ行ってもいいんじゃないかな？

という感じです。

絶版になってはしまいましたが、Apache拡張ガイド（上/下）は、mod_perlの日本語で解説された貴重な書籍です。（これも1.3系）

2.0系は洋書（Practical modp̲erl）ではあるようなのですが、まだ読んでないです。

perl

• http://www.perl.com/

CentOS5のYUMに依存したUPDATEをするような体制を作っていますので、Perl自体の管理もYUMです。
なので、バージョンは5.8.8で、これを使い続けています。

もうperl 5.10.1もリリースされ、5.8.x/5.9.xからの移行も本格化しそうなのですが、
これはOSマター（というかyumに頼って）で行いたいと思っています。

perlORマッパー

メンテナンス対象のシステムではClass::DBIを継続しての利用が多いです。これはもうママにメンテを続けていく方向で。

新規に作る分に関してはDBIx::MoCo を使っています。
拙作なのですがDBIx::MoCo::Pagesetでページング処理もらくらくです。

perlテンプレートエンジン

Template-ToolKit（TT）

• http://template-toolkit.org/

6Aがサービスされている、「Vox」もmod_perlで構成されているようなのですが、

TTの処理が全体の60%になっている

ということで、TTの重さに愕然とします。

なのですが・・・あまりの便利さ＆融通の利きやすさゆえに、離れる事ができず、ずっとTTを利用する形になっています。

Text::MicroTempolate や Tenjin もちょっと調べつつあるのですが微妙です。
TTより数倍速いのは速いっぽいのですが、mod_perl環境ではコンパイルができるため、TTに比べ、そこまでの速度の差は出ませんでした。

TT便利すぎます。

PHP

• http://php.net/

PHPは、メンテの対象となっているサービスはママそのバージョンを継続なのですが
今後は基本、PHP5.3をベースに考えたいと思っています。

ORM共通の悩みの、リファレンスカウントがそのまま＆メモリリークなどという部分を
gc_collect_cyclesでばっさりソリューションしてくれるのかしらという、淡い期待を持っています。

またPHPで特にやっかいなのが、YUMのPHPのバージョンが5.1.6であるという部分で、相当古いです。最低でも5.2系を使いたいところで。

こればっかりは仕方ないのでYUM風のオプションを持ったPHP5.3をソースコードからインストールしています。

アクセラレータ

PHP5.3に対応したアクセラレータを探して右往左往していたのですが、一応APCに落ち着いています。
eAcceleratorは、後から自分の環境ではいきなりhttpdがCoreDumpしたりしてやや不安定でした。

PHPのORマッパー

自作していますので、そのうちUPします

PHPのテンプレ

Smartyはやめました、もう素のPHP＝テンプレ。

OS

CentOS

弊社ではデフォルトで利用するOSです。
Fedoraはバージョンアップが激しいので何とも。

そろそろ5.4が出るのでしょうか 基本ド安定で素晴らしすぎます。
あとはReadTekのNICのドライバをきちんとフォローアップしてくれるととてもうれしい感じで。

FreeBSD

昔はメインで利用していたOSです。

最近はもっぱらCentOSで、FreeBSDで作られたシステムはだんだん少なくなってはいます。

やっぱりJavaが動かないのがなんとも。＜Solrまわりなど。

WindowsXP

別にサーバーで使っているわけではないのですが、クライアントPCはずっとXPです。
普段はFireFox＋Firebugで、IETesterでIEみる感じで。

最近BootCampでWin7を立ち上げられれば移行したいなーという感じです。

ミドルウェア

MySQL

これもCentOSのyumマターで管理しているので 5.0.x系です。
DBIなどのライブラリ周りも一括で管理できる辺りが楽で・・・

Memcache

• http://www.danga.com/memcached/

絶対使いましょう。

Memcache使いまくりです、使って損することはまったくありません。

Tokyo Tyrant

• http://1978th.net/

1200万件のレコードからLIKE検索で０．ｎ秒という数値がでまして、今今で検証中です。
相当にすごいミドルウェアかと。

フロントエンド

CSS

YUI のCSSをベースに使っています。
特にRecet.cssは大変便利です

コーディング時はなるべくCSSスプライトを用いて、Apacheへの負荷を削減しています。

Clearfixはこちらのエントリの通りで、おおよそ同一の書き方が多いです。

JS

おおよそ jQuery を使っています。
jQueryは全てバージョンアップを行い最新の1.3.2を利用しています。

ドラッグ＆ドロップなどのウィジェット機能もすべて jQueryのプラグイン や jQueryUI を利用しています。

JSはheadタグに入れるとオーバーヘッドが大きすぎるので、すべてHTMLの終了部分に近い場所に配置します。
＝HTMLとCSSのレンダリングが終了してからJSを実行させるためです。

つらつらと書きすぎですが、現状の流行はこのような感じです。

ネットブックでのPCルーター作成 や LVS をネットブックで運用なども非常に突っ込んでみたい所存であります。

こんばんは松本です。

PHP5.3.0がリリースされてから3ヶ月経ちましたが、だいぶ使い勝手にも慣れて来ました。
PHP5.3.1でのBugFixの数もすごいですが、ガベージコレクトやstatic属性など、便利機能が多いですので是非。

自分は CentOS5 x86_64 で利用しているのですが、PHP5.3を導入するにあたり、ソースコードからインストールしています。
できるだけ、標準のPHP（5.1.6）のオプションを踏襲した形でPHP5.3をインストールしました。

既存のPHP（5.1.6）をアンインストール

yum remove php*

付随する php-common などのライブラリも全てアンインストールします。
自分の環境ではYUM経由のPHP関係のライブラリをフルフルに入れていましたので、以下がアンインストールされました。

アンインストールされたYUMライブラリ

php
php-bcmath
php-cli
php-common
php-dba
php-devel
php-eaccelerator
php-gd
php-imap
php-jpgraph-docs
php-ldap
php-mbstring
php-mysql
php-ncurses
php-odbc
php-pdo
php-pear
php-pear-Date
php-pear-File
php-pear-HTTP-Request
php-pear-MDB2
php-pear-MDB2-Driver-mysql
php-pear-Mail-Mime
php-pear-Net-Sieve
php-pear-Net-Socket
php-pear-Net-URL
php-pear-date
php-pear-db
php-pear-file
php-pecl-Fileinfo
php-pecl-memcache
php-pecl-session_mysql
php-pgsql
php-snmp
php-soap
php-xml
php-xmlrpc

必要なライブラリのインストール

phpをソースコードからインストールするための必要となるライブラリをyumでインストールします。
※レポジトリにはrpmforgeも入れています。
後からpeclのmemcacheも利用しますので、memcached自体もインストールしています。

yum -y install ncurses*
yum -y install gcc-c++
yum -y install flex
yum -y install libxml*
yum -y install gdbm-devel
yum -y install gd gd-devel freetype freetype libpng libmng* libtiff* libjpeg* libc-client* giflib*
yum -y install httpd httpd-devel
yum -y install pcre-devel
yum -y install unixODBC-devel
yum -y install net-snmp-devel
yum -y install openssl*
yum -y install bzip2*
yum -y install curl*
yum -y install gdbm*
yum -y install db4*
yum -y install gmp*
yum -y install libc-client*
yum -y install openldap*
yum -y install libmcrypt*
yum -y install mhash*
yum -y install mysql*
yum -y install freetds*
yum -y install aspell*
yum -y install readline*
yum -y install libtidy*
yum -y install libxslt*
yum -y install libtool*
yum -y install curl*
yum -y install memcache*

PHPのソースコードをダウンロード

php.net　からPHPのソースコードをダウンロードします。ダウンロードは　こちら　から。

wget http://jp2.php.net/get/php-5.3.0.tar.gz/from/this/mirror
tar xvzf php-5.3.0.tar.gz

configure

一番面倒なconfigureですが、自分の環境では以下を通しました。
x86_64（64bit環境）の指定と yumでインストールしたapxsのパスあたりがキモです。

./configure \
--with-apxs2=/usr/sbin/apxs \
--build=x86_64-redhat-linux-gnu \
--host=x86_64-redhat-linux-gnu \
--target=x86_64-redhat-linux-gnu \
--program-prefix= \
--prefix=/usr \
--exec-prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--sysconfdir=/etc \
--datadir=/usr/share \
--includedir=/usr/include \
--libdir=/usr/lib64 \
--libexecdir=/usr/libexec \
--localstatedir=/var \
--sharedstatedir=/usr/com \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--cache-file=../config.cache \
--with-libdir=lib64 \
--with-config-file-path=/etc \
--with-config-file-scan-dir=/etc/php.d \
--with-pic \
--with-bz2 \
--with-curl \
--with-exec-dir=/usr/bin \
--with-freetype-dir=/usr \
--with-png-dir=/usr \
--enable-gd-native-ttf \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=/usr \
--with-openssl \
--with-pcre-regex=/usr/local \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-sysvmsg \
--enable-wddx \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--with-libxml-dir=/usr \
--enable-pcntl \
--enable-mbstring \
--enable-mbregex \
--with-gd=shared \
--enable-bcmath=shared \
--enable-dba=shared \
--with-db4=/usr \
--with-xmlrpc=shared \
--with-mysql=/var/lib/mysql \
--with-mysql-sock=/var/lib/mysql/mysql.sock \
--with-mysqli=shared,/usr/bin/mysql_config \
--enable-dom=shared \
--enable-soap=shared \
--with-xsl=shared,/usr \
--enable-xmlreader=shared \
--enable-xmlwriter=shared \
--with-pdo-mysql=shared,/usr \
--enable-zip \
--enable-zend-multibyte \
--with-mcrypt

make ～ インストール

configureが通ったらmakeします。

sudo make install

php -v で以下のように正常にでればとりあえずOKです。

$ php -v
 PHP 5.3.0 (cli) (built: Jul 20 2009 20:59:23)
 Copyright (c) 1997-2009 The PHP Group
 Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

あとはphpinfoで詳細を確認します。

PECLをインストール

peclはコマンドからインストールします。
自分は以下のPECLを利用しています。

pecl install memcache
pecl install APC-3.1.3p1
pecl install imagick
pecl install tokyo_tyrant-beta
pecl install hidef-0.1.2
pecl install xdebug-2.1.0beta1

それぞれのPECLの設定方法については、また後述していきたいと思います。

いかがでしょうか。さらっとした覚え書きではありますが、お役に立てますと幸いです。

弊社では、Webアプリケーションの開発をperl/PHPで行っています。
特にperlでの開発の場合、ほとんどがmod_perlを使っています。

mod_perl上で動くフレームワークは Catalyst などが有名どころではありますが、使い慣れている点もあり長らく Sledgeを利用しています。

以下、Sledgeについての自分がよく見るサイトのまとめです。

Sledgeについて

• Sledgeについて 概要など
  フレームワーク、MVCについて詳しく書かれています
  • http://itpro.nikkeibp.co.jp/members/LIN/oss/20030919/1/
• Sledge内部のセッション管理やテンプレートシステムについてなど
  • http://www.thinkit.co.jp/cert/tech/9/1/1.htm

• Sledge内部APIのドキュメント
  • http://blog.livedoor.jp/nipotan/archives/50293736.html

• SledgeをUTF8で動かす
  • http://hori-uchi.com/archives/000419.html

• SledgeをUTF8で動かす＋Apache2
  • http://www.alink.co.jp/tech/blog/2009/06/19/sledge%E3%81%AEapache2%EF%BC%88mod_perl2%EF%BC%89%E5%AF%BE%E5%BF%9C%EF%BC%8Butf8/
    ※Dispatcherなどの使い方も含む

• Sledge-Session-Memcached
  • http://sourceforge.jp/projects/sledge/releases/15552

SledgeのSessionストレージをMemcachedに持たせるモジュールです。必須。
永続化をするならTokyoTyrantでも使えると思う。

mod_perl

mod_perlリファレンス（mod_perl クイック・リファレンス (1)）

• http://multix.jp/html/memo/030526.html

mod_perl1 Apache1.3系のmod_perlのリファレンスです。
mod_perlベースでのWebアプリケーション開発時には必ず見ています。（というかAPIを覚えられないんですよね・・・）

Sledge関連の書籍

• まるごとPerl! Vol.1
  Sledgeの使い方が一通り掲載されています。Sledge以外の部分も役に立つ知識が多いです。
  • http://www.amazon.co.jp/dp/4844322893

※以下はSledgeは載っていませんが、Sledgeを使うために必須となる部分が載っています。

• 続・初めてのPerl 改訂版
  リファレンス、パッケージなどが分かりやすく解説されています
  • http://www.amazon.co.jp/dp/4873113059/

• 図解・標準 最新Perl/CGIハンドブック
  相当わかりやすいですこれ。＜絶版なんですね・・・
  • http://www.amazon.co.jp/dp/4798002070/

TemplateToolkit

• http://www.hakoniwa.net/tt/

TTは Sledgeから扱う Templateモジュール自体の使い方と、Templateシステム内のシンタックス（表記法）の2つが混在しています。

• Templateモジュール自体の使い方
  • use Template;（今日のCPANモジュール）
• シンタックス（表記法）のドキュメント
  • http://www.hakoniwa.net/tt/
  • CPANでの最新版（英語）
    • http://search.cpan.org/perldoc?Template::Manual::Directives
• またperl固有なのですが、utf8フラグの有り無し判別が中々大変でこれを解決するために、Template側でラッパする方法も公開されています。
  • いまさらTTをutf8環境下で何も考えずに扱えるモジュールを書いた

Class::DBI

参考までにORマッパーのリンクも。
未だにCDBI？という感じではありますが、メンテナンスを続けているサイトもあります関係でこのような感じに。

• http://perldoc.jp/docs/modules/Class-DBI-0.96/lib/Class/DBI.pod

• http://retailcomm.jugem.jp/?eid=34

こんにちは、松本です。

前回のwebエンジニア必携のツール10選に続きます、今回はサイト編です。
Webアプリケーションそのものも含みますので、純粋にサイトだけではないのですが、その辺はいい感じに。

1.Gmail(Webメール)

• http://www.gmail.com/

いきなりwebアプリケーションですが、
前回のエントリでクライアントPCでのツール10選を出しています。この10選で、メーラーが完全に抜けているのですが
それも全部Gmailに移行しているためです。

以前はthunderbirdなど、スタンドアロンのメーラーを使っていたのですが
オンラインが当たり前になった現在、全てオンラインでの処理で良いのかなという判断で、Gmailを利用しています。

自分は持っていないのですが、iPhoneでもGmailが超便利と聞いています。

2.スケジューラー(Googleカレンダー)

• http://calendar.google.com

続いてGoogleカレンダーです。
社内のメンバーのスケジュール共有はこれもすべてオンラインで行っています。
iCalのデータをインポートできるので livedoor 天気情報の iCal天気 を利用しています。これも便利。

3.RSSリーダー

• http://reader.google.com

RSSリーダーで効率的に情報を収集します。慣れないうちはとまどうのですが、慣れると中々便利です。
普通にWebサイトを巡回するよりも相当速くチェックできます。
自分はメジャーどころでは以下のRSSを登録しています。

• mixi Engineers' Blog
• ウノウラボ
• search.cpan.org
• PECL: Latest releases
• livedoor ディレクター Blog(ブログ)

趣向がばらっばらなのですが・・・ｗこんな感じです。

Googleリーダー以外でもどのWebアプリケーションでも、使いやすいものをご利用されて良いかと思います。

• http://reader.livedoor.com/
• http://reader.goo.ne.jp/
  gooはスタンドアロンタイプもありますので、これも便利かと。

4.php.net

• http://php.net/

やっとGoogle以外のサービスなのですが、
PHPの開発を行う際に、関数のドキュメントを検索したりなど、常に開きっぱなしで利用します。
特にPHPは関数によって、引数の順番がいきなり変わったりしますので、無用なハマりを回避するためにも、ちょっとでも疑問をもったら都度検索がベストです。

5.CPAN

• http://search.cpan.org/

CPANもよく利用しています。Class::DBIやDBIx::MoCoのドキュメントを見るときにもよく利用しています。

6.TemplateToolkit

• http://www.hakoniwa.net/tt/

Perl（mod_perl）ベースでの開発時には、非常によく利用します。現在弊社で利用しているPerlのテンプレートシステムは全てtemplate-toolkit(TT)を利用しています。
TTの日本語でのドキュメントは中々少なく、上記サイトは非常に重宝しています。

[参考]TemplateToolkitの参考サイト

TTは mod_perl上で扱う Templateモジュール自体の使い方と、Templateシステム内のシンタックス（表記法）の2つが混在しています。

• Templateモジュール自体の使い方
  • use Template;（今日のCPANモジュール）
• シンタックス（表記法）のドキュメント
  • http://www.hakoniwa.net/tt/
  • CPANでの最新版（英語）
    • http://search.cpan.org/perldoc?Template::Manual::Directives
• またperl固有なのですが、utf8フラグの有り無し判別が中々大変でこれを解決するために、Template側でラッパする方法も公開されています。
  • いまさらTTをutf8環境下で何も考えずに扱えるモジュールを書いた

[参考2]DateTimeモジュールの参考サイト

• http://iandeth.dyndns.org/mt/ian/archives/000619.html

DateTimeもよく利用するモジュールの1つです。APIがやや難しく、忘れがちですので上記サイトを常に見ていたりします。

7.fixdap

• http://fixdap.com/

Todoをオンラインで使える貴重なWepアプリケーションです。
細かいタスクはメールではなくBTSベースで行うと漏れがありません。
非常に便利です。このような便利系アプリケーションを弊社でもサービスしたい所であります。
SSL対応になるとより吉ですね。

8.ソーシャルブックマーク（Yahoo!ブックマーク）

• http://bookmarks.yahoo.co.jp/snks00
  ソーシャルブックマークははてなブックマークやdeliciousなどが有名ですが、
  自分は以前からYahoo!ブックマークを利用してきた経緯もあり、継続して利用しています。

Y!ブックマークはsymfonyでできているのらしいのですが、レスポンスが重いのが何とも・・・

9.jQuery用ドキュメント

• http://semooh.jp/jquery/

ｊQuery用のドキュメントです。相当に詳しく載っていまして毎回お世話になっております。m(_ _)m

10.mod_perlリファレンス（mod_perl クイック・リファレンス (1)）

• http://multix.jp/html/memo/030526.html

mod_perl1 Apache1.3系のmod_perlのリファレンスです。
mod_perlベースでのWebアプリケーション開発時には必ず見ています。（というかAPIを覚えられないんですよね・・・）

いかがでしょうか。
他にもevernoteやGoogleDocsなども激しく便利です。

次回は更に掘り、mod_perlを扱う上での便利サイト10選、PHPを扱う上での便利サイト10選などをしてみたいと思っています。

[番外]Twitter

• http://twitter.com/

おなじみのTwitterです。自分のつながりのある方たちの状況がおおよそ把握でき、また直接口頭では話さないような趣向が分かったりと中々これはこれで便利であります。

Twitterを利用される場合、TwitterFoxというFireFoxのアドオンがあるのですが、これが大変便利です。メッセンジャーの様に入力できますし、まさに"つぶやく"といった感じです。

ありんくのTwitterも公開しています。よろしければご覧下さい

• http://twitter.com/alinkdev

松本個人のTwitterは以下でございます。こちらもよろしければどうぞ、技術面以外の事が多いですが・・・

• http://twitter.com/snks00

[番外2] GoogleBooks

立ち読みでさらっと確認したい系のものなど、特に専門書を買うときには強烈に便利です。
自分はオライリーの洋書を見るときなど、よく使います。

• http://books.google.com/books?id=1l6dLAW5o3UC&lpg=PP1&dq=template%20toolkit&as_brr=3&hl=ja&pg=PP1#v=onepage&q=&f=false

こんにちは、松本です。

弊社でwebシステムを開発する上で、よく利用しているツール、アプリケーションを10個挙げてみます。
例えば "出先でネットに繋がるノートPCで作業する" といった場合など、
どんな環境でもこれさえあれば、一通りの作業は何とかできるかも・・・というあたりです。

自分は下記ツール、アプリケーション群をどのパソコンにもインストールしています。

基本、全てWindowsXPをベースにしています。ご了承下さい。

1.FireFox

• http://mozilla.jp/firefox/
  何は無くともFireFoxです。アドオンの便利なツールは必須です。

FireFoxアドオン3選

1. FireBug
   https://addons.mozilla.jp/firefox/details/1843
   超必須です。特にJSの開発時にはこれが無いと、事実上開発ができないぐらいです。
2. Y!Slow
   https://addons.mozilla.org/ja/firefox/addon/5369
   ブラウザでのキャッシュやサーバサイドのExpireっぷりを確認するために利用します。これも必須かと。
3. Firecookie
   https://addons.mozilla.jp/firefox/details/6683
   Cookieを確認する必須ツールです。これも必須で。

2.PuTTY ごった煮版

• http://yebisuya.dip.jp/Software/PuTTY/
  ターミナルで接続しての作業時には必携のツールです。こちらもTeraTermやPoderosaなど、自分の好きなものであれば何でも良いかと思います。
  自分はプログラミングの99%をターミナルを通して行いますので、一番利用するツールであります。
  ※Macをお使いの方はiTermあたりでしょうか。デフォルトのターミナルは文字コードを変更できなかったのでちょっと辛かったです。

3.TortoiseSVN

• http://sourceforge.jp/projects/tortoisesvn/releases/
  ソースコードなど、開発物は全てSubverionで管理していますので、エンジニアに関わらず、全ての現場スタッフで必須のツールです。

4.FFFTP

• http://www2.biglobe.ne.jp/~sota/ffftp.html
  こちらも必携です。これが無いと、FTPへのアップ、ダウンロード自体ができません。

5.サクラエディタ

• http://members.at.infoseek.co.jp/sakura_editor/
  テキストエディタは何でもアリだとはおもうのですが、メモ帳以外で使いやすければそれで。他にはTerapadなどでしょうか。

6.IETester

• http://www.my-debugbar.com/wiki/IETester/HomePage
  この数年間、webエンジニアを大いに悩ませるのがInternetExplorer（IE）です。
  IEはバージョンによって挙動の変化が激しく、またW3Cに準拠していない部分も多いので

  FireFoxで開発していて、久しぶりにIEで挙動を確認したら思いっきり崩れてた。

  なんていうこともザラです。
  また、シェアが落ちたとは言え、”IE6でも動く”サイトが最低限の基本になっていますので、
  VistaやIE7/8をインストールしたXPでも確認できるようにと、利用しています。
  ※Win7にも対応しているっぽいので一安心です。

7.WinSCP

• http://www.tab2.jp/~winscp/
  サーバーにSSHでアップロードするための必須ツールです。
  最近はほとんどFTPは使わず、基本WinSCPでアップしていたりします。

8.cassava

• http://www.asukaze.net/soft/cassava/
  CSVの確認、編集時には必須ツールです。UTF8やEUCなどSJIS以外の文字列を読み込んだり、
  ケタ数のフローがないので大変便利です。

9.インスタントメッセンジャー

• http://messenger.yahoo.co.jp/
  弊社内では全員必携のツールです。あらゆる開発フェーズで多用します。
  他社様のお話を聞くと、スカイプの利用が多いですね。
  windowslive（MSN）メッセもよく利用しています。

10.GIMP

• http://www.geocities.jp/gimproject/gimp2.0.html
  ※公式サイトではありませんが、GIMPについての非常に情報が整理され見やすいサイトです。
  グラフィックツールです。ちょこっとした画像の修正やGIF→JPGなどへのフォーマット変更、
  またCSSスプライト時にベースとなる画像作成など、エンジニアサイドも利用できる多機能なツールです。
  フリーソフト（GPL）というのも大変吉です。

いかがでしょうか。ごくごく基本的なツール、アプリケーションかと思います。
メールの送受信をするメーラーについての言及が抜けていると思いますが
thunderbirdなどのメーラーを使わず、全てオンラインに移行しています。
このあたりは、"webエンジニア必携のサイト10選"に続きます。

[番外] 10選とはやや関係ないですが、パソコンのハードウェア

作業用のPCの選定は、CPU自体の速度を結構重視します。

実際の作業ではFireFoxを開いてFireBugで確認しながら、FlashでActionScriptを書いて・・・
というケースも多く、結構なCPUの負荷を食います。

複数のアプリで同時に処理というケースが多いので
Celeronなどの廉価版は避け、Core2Duo以上が搭載されているPCを選んだほうがベストと思います。

このあたりは柔軟に対応できるように、また自分のノウハウ蓄積のためにも自作PCを利用しています。
自作はもう12年ぐらい続けています。

また、モニタも広めの21.5インチワイドタイプを利用しています。
※最近のモニタは安いですね・・・・1万円台で22インチタイプが購入できます。

メインPC

パソコンはメインではデスクトップを利用しています。構成は以下です。

• PC本体
  • 自作PC (Core2DuoE8500、メモリ４Ｇ、HDD500G)
• モニタ
  • LCD-MF221X

    HDMI付きなのでPS3も接続できますw

• キーボード
  • 東プレ

サブPC

サブPCはノート型で、ThinkPadです。
長年HPを利用していたのですが、
あまりのキータッチの素晴らしさにLenovoに移ってしまいました。

• ThinkPad X200

PHP5.3自体のインストールについては
[PHP] CentOS5.3 で PHP5.3をインストール（YUM風オプションで）をご覧下さい。

こんにちは、松本です。シルバーウィークの天気 も全く関係ない引きこもり状態で、だらだらと経過中です。

PHP5.3.0 もリリースされて少し経ちましたが、早くも PHP5.3.1-rc1 がリリースされ、例によって矢継ぎ早にアップデートされそうな予感です。

前回に引き続き、PHPのアクセラレータ導入です。

PHP5.3で利用できるアクセラレータ

PHP5.3系のアクセラレータは、eAccelerator 、 APC 、 XCache などが対応しています。

一番気になる速度面ですが、どのアクセラレータもそこまで大きな違いはありません。
自分では、eAcceleratorをよく利用しています。

PHP5.3ではありませんが、お祭りコム 、 リラックスライト でも eAcceleratorを導入しています。

なぜ eAccelerator なのか？ という部分ですが、自分で実測した限りでは APC よりも eAccelerator の方が httpdのプロセスサイズが小さく見えました。

また、VPSなどのメモリ容量が小さい環境での運用でもshmとdiskをどちらも併用できる eAccelerator が、ある程度の可用性を保つ面でも良いかなと思い採用しています。

前回の導入時にややハマった PHP5.3でのAPCの導入 ですが、現在は APC-3.1.3p1 がリリースされ、PHP5.3でもハマらずにインストールできました。

eAccelerator

eAcceleratorの公式サイト から、ソースをダウンロードします。
サイトの下部にバージョン別のリリースがありますので、一番新しいものを選択します。

PHP5.2までは 0.9.5.3 でも動作しますが、PHP5.3以降は 0.9.6-rc1 以降のバージョンでの動作となります

コンパイル→インストール

phpizeが入っていない場合、前もってインストールしておきます。

yum -y install php-devel

ソースコードからコンパイルしてインストールします

mkdir /usr/local/src
cd /usr/local/src
wget http://bart.eaccelerator.net/source/0.9.6/eaccelerator-0.9.6-rc1.tar.bz2
tar jxvf eaccelerator-0.9.6-rc1.tar.bz2
cd eaccelerator-0.9.6-rc1

phpize
./configure --enable-eaccelerator=shared
export SED=sed
sudo make install

インストールが完了したら、キャッシュ用のディレクトリを作成します。

# mkdir /var/php-cache/eaccelerator
# chmod 777 /var/php-cache/eaccelerator

php.iniでの設定

次にphp.iniに設定を定義します。

vim /etc/php.ini

※ XDebugをインストールしている場合、XDebugの記述より以前に記述します。

[eaccelerator]
zend_extension="/path/to/eaccelerator.so"
eaccelerator.shm_size = "32"
eaccelerator.cache_dir = "/var/php-cache/eaccelerator"
eaccelerator.enable = "1"
eaccelerator.optimizer = "1"
eaccelerator.check_mtime = "1"
eaccelerator.debug = "0"
eaccelerator.filter = ""
eaccelerator.shm_max = "0"
eaccelerator.shm_ttl = "86400"
eaccelerator.shm_prune_period = "0"
eaccelerator.shm_only = "0"
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"
eaccelerator.keys     = "shm_and_disk"
eaccelerator.sessions = "shm_and_disk"
eaccelerator.content  = "shm_and_disk"

zend_extentionは eAccelerator がインストールされたディレクトリをフルパスで指定します。

APC

APCも試しています。前回の記事に引き続きですが、検証しまくりです。eAcceleratorを入れるよりもプロセスサイズが大きめに出るのが気になりますが・・・

あと、これは自分の環境だけかもしれませんが、APCが効いている状態で、ファイルを書き換えると（statが変わると） httpdがCoreDumpしていまして、そちらも原因を追っているところです。

インストール

APCのインストールも簡単です。
peclコマンドでも可能ですが、ここではeAcceleratorと同様にソースをダウンロードし、インストールします。

cd /usr/local/src
wget http://pecl.php.net/get/APC-3.1.3p1.tgz
tar xvzf APC-3.1.3p1.tgz
cd APC-3.1.3p1

 phpize
 ./configure --enable-apc

sudo make install

php.iniでの設定

大体以下のような感じでしょうか。上記eAcceleratorと同等の機能を定義しています。

vim /etc/php.ini

[APC]
extension=apc.so
apc.mode = shm
apc.check_compiled_source = 1
apc.check_mtime = 1
apc.enabled=1
apc.shm_segments=1
apc.shm_size=30
apc.num_files_hint=100
apc.user_entries_hint=640000
apc.ttl=86400
apc.user_ttl=86400
apc.gc_ttl=86400

またまた久しぶりの更新です。

募集は終了致しました。たくさんのご応募ありがとうございました。

※以下は2009年8月31日現在の情報になります。

以前に、転職活動で自己アピールしよう! 「Webプログラマー編」などという記事を書いている手前もありますが、やはり　”何ができるか・何をしたいか”　を簡潔にまとめている方がスムーズにやり取りが出来て大変よろしい感じです。

今までは”Perl! Perl! Perl!”な技術アーキテクチャだったのですが、最近はPerlとPHPを適宜利用した方向性に変わってきています。
特にPHPは5.3系がリリースされ、メモリ管理も効率されていることもあり今後は積極的に利用していく予定です。

プログラミング言語以外でノウハウを貯めしつつある技術は以下のような感じです。

• Tenjin（Perl版）
• Tokyo Tyrant
• MogileFS
• Solr
• ActionScript3

また最近はClass::DBIライクなPHP用ORマッパーを開発しています。
（こちらはFix次第、GoogleCodeでUPする予定です）

これ以外にも、引き続き Sledge:+mod_perl+Template-Toolkit は引き続き利用しています。

LAMPを使った開発で、ガリッガリにWebアプリケーションを作ってみたい方！
近い将来にまた募集をかけさせていただくかもしれまませんが、
その際には是非ご応募下さい、お待ちしています。

PHP5.3自体のインストールについては
[PHP] CentOS5.3 で PHP5.3をインストール（YUM風オプションで）をご覧下さい。

大変お久しぶりの更新です、DQ9をする暇も無く天変地異と闘っています。

PHP5.3がリリースされ、1ヵ月半が経ちましたが、PHP5.2までには無かった機能が山盛りですごい事になっています。
LL言語の中では今一番注目しています。

とくに 「遅延静的束縛（Late Static Bindings）」と「ガベージコレクション」にドキドキしつつ、以下2つの点に大注目しています。

遅延静的束縛（Late Static Bindings）

クラス関数で、継承先のクラスを参照できるので、ORマッパでCDBIっぽい動きを直接指定できます。

今までは、継承先で継承元のクラス関数を使うためには

$blog_article = new Data::Blog::Article;
$blog_article_entries = $blog_article->retrieve_by_user($user);

などのような書き方をしていましたが、

"static"キーワードを利用する事で

$blog_entries = Data::Blog::Article->retrieve_by_user($user);

等の様な書き方が出来るようになります。

ざっくりしすぎな説明なので、次回もう少し深く解説したいと思います。

ガベージコレクション

ORマッパやMVCなどで特に起こしやすい、メモリリークですが
PHP5.3ではいい感じに処理してくれている模様です。

PHP5.3をインストールしてあるデフォルトの状態で有効になっており、
メモリリークを起こしている処理をある程度貯まった段階で開放しているようです。

また、新たに加わっている関数 gc_collect_cycles ですが、明示的にGC（ガベージコレクション）を開放してくれるとのことなので、
現在MVCの最後の処理（1サイクルが終わるタイミング）で毎回実行させるようにして、効果測定を行っています。
こちらはもう少し調査したらUPする予定です。

APC

アクセラレータのPHP5.3対応状況

PHPのアクセラレータは主に eaccelerator、APC、XCache 等かと思います。

eaccelerator

eacceleratorは最新版の0.9.6-rc1 を試してみたのですが、インストールはできるのですが、PHPの起動でエラーになってしまい、ベンチマークまでいけませんでした。

公式ページでは Support for PHP 5.3. となっているのですが・・・自分の環境がおかしいのかもしれません。

APC

pecl のRSSFeedに本日登録された APC3.1.3 ですが、
make時に apc_bin.h が無いと怒られます。

peclのサイトからダウンロードできるtgzのパッケージには確かに該当するファイルが無く、makeが通らないので
PHPのsvnサイトから apc_bin.h apc_bin.c の2つをダウンロードして利用しました。
（※何故か同一バージョンのsvn管理下にはあるようです。）

cd /usr/local/src/APC-3.1.3

wget http://svn.php.net/viewvc/pecl/apc/tags/APC_3_1_3/APC_3_1_3/apc_bin.h?revision=287245&view=co apc_bin.h
wget http://svn.php.net/viewvc/pecl/apc/tags/APC_3_1_3/APC_3_1_3/apc_bin.c?view=co&content-type=text%2Fplain  apc_bin.c

phpize
./configure --enable-apc
sudo make install

これでhttpdを再起動して phpinfoに

apc

と、3.1.3が表示されればまず抱え込めている状態になります。

APCの前のバージョンでは、原因不明なCoreDumpに悩まされたので・・・今回は少し調査しつつやってみたいと思います。

XCache

XCacheはまだ試してないですが、公式サイトではPHP5.3のサポートのアナウンスがあっているようです。

Zend Optimizer

APCではないのですが、 Zend Optimizer もPHP5.2までの対応となっているので、5.3の対応が待たれます・・

Apache2.2系で安定して動作し、プロダクションレベルでも運用が可能になりつつある「mod_disk_cache」です。

mod_cache + mod_disk_cache

ありんくのホームページのトップでは、 mod_cache 、 mod_disk_cache を利用してキャッシュさせています。

squidのような効果が期待でき、且つApacheの設定内で調整できますので、以下のような構成の場合
スタティックであまり更新が無いものに関してはフロント側でCacheをかける事ができます。

• フロント（Proxy）
  • mod_proxy_balancer + mod_cache&mod_disk_cache
• アプリケーション（mod_perl）
  • mod_perl (Sledge)

他にも例えば動的に生成する画像コンテンツなどもこのCacheを使う事で高速化することができると思います。

設定例

httpd.conf内の設定例は以下です。

• Apacheのモジュールをロード

  LoadModule cache_module modules/mod_cache.so
  LoadModule disk_cache_module modules/mod_disk_cache.so

• mod_cacheとmod_disk_cacheの設定例

  <IfModule mod_cache.c>
    CacheDefaultExpire 86400
    CacheMaxExpire 259200
    CacheIgnoreCacheControl On
    CacheIgnoreNoLastMod On
    CacheIgnoreHeaders Set-Cookie
    CacheStoreNoStore On
    CacheStorePrivate On
    <IfModule mod_disk_cache.c>
      CacheRoot /path/to/cache
      CacheEnable disk /
      CacheDisable /tech
      CacheDisable /inquiry
      CacheDirLevels 6
      CacheDirLength 3
    </IfModule>
  </IfModule>

各ディレクティブの解説はまた後ほど追記します。

参考ページ（外部リンク）

• mod_cache,mod_disk_cacheで高速化
• mod_proxy_balancer + mod_disk_cache on Apache 2.2.3

mod_perlとプロセスサイズについて検証してみました。

前提

MVC（Sledge）を使って検証

TT、CGI、DateTimeなどの大きいモジュールは startup.pl でloadしています。

各Appsも File::Findで use しています。

DBをDBIx::MoCoで読み込んで、100件をTTで表示という処理を行います。

サーバーは Q6600 メモリ8G

検証結果

mod_perl1 と mod_perl2(prefork)ではスピード、メモリ消費量共にほぼ同じ。

ORマッパ（DBIx::MoCo）を抱えると大きくなる。多分CDBIとかDBICとかだと更に大きくなる。
単純な処理でも大体1プロセスサイズが50Mになる（共有メモリ含む）

各プロセスが抱えるhttpdの共有メモリはおおよそ2/3。
起動時は90%以上 → だんだんプライベートメモリが増えていきます。アプリによっては50%を切る場合もあります。

かりっかりにstartup.plで抱え込むことができれば 共有メモリ70%ぐらいで推移していきます

同じURLに対して局所的に集中するようなアクセス（F5連打など）には強いと思います。

abによるベンチでは、以下になった。それぞれでプロセス単位でのメモリの増減はあまり無いです。

DBへのアクセス無し
250 req / sec

DBへのアクセスあり（Memcached）
50 req / sec

DBへのアクセスあり
10 req / sec

結論

WebシステムはMemcachedありきが良いです。

preforkモデルでは mod_perl1 mod_perl2 共に同じでした。
趣味でどちらでもという感じです。

• mod_extract_forwordedのバージョン違いに注意。

mod_perlはメモリを食います、メモリを多めに搭載できるサーバでないと厳しいと思います。
メモリ搭載量にもよるけど、MaxRequestPerChildは大体 100以下が現実的。

チューニング具合にもよるけど、大よそ総メモリ2G以下のシステムではSwapを起こすのでは。

Apache::Registry（ModPerl::Registory）を使っているシステムだと FastCGI、SpeedyCGIも検討の価値があると思います。

そもそもなのだけど、プログラムをメモリ上に確保するということは

システム全体のコード量が大きくなっていけばいくほど、
1プロセス辺りのメモリ消費量が増していくことになるので

「細かく異なる複数のperlモジュールが大量使われる」というシステムは
ロード＆コンパイルするperlモジュールが多くなり、プロセスサイズが大きくなります。
→こういう使い方には向いてないんじゃないだろうかと・・・

シンプルなページを高速に処理するのであればとても向いているソリューションだと思います。

※Mixiは実現できているじゃないかというアレもあるのですが、どうやっているのかなあ。
URL（機能）ごとにmod_perlのサーバを分けたりしているのかな、L7バランサみたいな。
もしくは 「.pl」で終わっているURLに単純にハンドラがリライトしているだけだったりして。

ということでPHP（mod_php）も検証してみたいと思います。

mod_perl2+Sledgeでテストを繰り返しているのですが、各プロセスでのメモリ消費量が激しく気になります。
特に多くのperlモジュールをロードする場合、プロセスサイズが肥大化するので随時チェックしています。

mod_perlのメモリ消費状況を知る

今回は INCDiffを使って、startup.plを精査しつつ mod_perl2を抱えたhttpdのメモリ消費量をチェックしました。

httpd.confの設定

httpd.confはpreforkモードで使っていてプロセスの塩梅は以下です

   StartServers      20
   MinSpareServers    20
   MaxSpareServers   50
   ServerLimit      1000
   MaxClients       1000
   # MaxRequestsPerChild  100
   MaxRequestsPerChild  1000

MaxRequestPerCHildがやや多めなのですが、mod_perl2 のメモリ消費量検証用ということで多くしています。
コメントアウトしていますが、常用では100を設定しています。

httpdが「起動」している状態の メモリ使用状況

# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 4672652 373464 1781576    0    0     0     1    2    2  0  0 100  0  0

httpdを停止します。

# service httpd stop
httpd を停止中:                                            [  OK  ]

httpdが「停止」している状態の メモリ使用状況

# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 5610844 373464 1781332    0    0     0     1    2    2  0  0 100  0  0

httpdが抱えていたメモリを逆算します。

freeが 4672652 から 5610844 に増えていますので、httpdが抱えていたメモリは

938192 （約916.2MB）

この916.2MBをどう使っているのか。

重要な点は共有メモリか、各プロセスが独自にそれぞれメモリを消費しているかで、効率の度合いが変わってくる点です。
共有メモリの利用率が高ければ 効率的にメモリを使えますので、起動プロセス数を増加できます。

共有メモリか、プライベートなメモリかを測定するperlスクリプトを利用して計測します。

• perlスクリプトはこちら（Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる）
  • ※上記ブログに「Perl には Linux::Smaps という /proc/PID/smaps のデータをプログラマブルに扱えるモジュールがあります。…」という部分があり、その下にプログラムがあります。

このプログラムを利用して、メモリを計測すると以下の結果が出ました。

# shared_memory_size.pl `pgrep httpd`

PID     RSS     SHARED
4719    57988   46392 (80%)
4721    69024   46260 (67%)
4722    67740   45948 (67%)
4723    69256   45276 (65%)
4724    68772   45948 (66%)
4725    68360   45884 (67%)
4726    68276   46188 (67%)
4728    68972   46260 (67%)
4729    69924   45944 (65%)
4730    69564   45884 (65%)
4731    69728   46260 (66%)
4732    68712   45948 (66%)
4733    68748   46260 (67%)
4734    68792   46256 (67%)
4735    70572   45948 (65%)
4737    69092   46188 (66%)
4738    68412   45948 (67%)
4739    69696   46184 (66%)
4740    69004   46256 (67%)
4744    67352   46188 (68%)
4746    67116   45948 (68%)
4751    66608   45948 (68%)
4752    66892   45948 (68%)
4755    65280   46260 (70%)
4782    64092   46260 (72%)
4785    63876   46260 (72%)
4786    63720   46260 (72%)
4788    62784   46260 (73%)
4790    61736   46260 (74%)
4791    63404   46260 (72%)
4794    61432   46260 (75%)
4797    60604   46188 (76%)
4799    60648   46260 (76%)
4804    58880   46288 (78%)
4808    60236   45900 (76%)
4815    58368   46228 (79%)
4816    58940   46228 (78%)
4829    57608   46228 (80%)
4842    55128   46228 (83%)
4843    55124   46224 (83%)
4844    55128   46228 (83%)
4845    55128   46228 (83%)
4848    55124   46224 (83%)
4849    55128   46228 (83%)
4850    55128   46228 (83%)
4851    54780   46156 (84%)
4855    54696   46156 (84%)
4856    54608   46232 (84%)
4857    54604   46232 (84%)
4858    54604   46232 (84%)
4859    54604   46232 (84%)

それぞれ、「プロセスのID」、「各プロセスの全体メモリ」、「その中の共有メモリ」、「プロセス内の共有メモリの割合（％）」になります。

内訳は

• 共有メモリ
  • 85.6MB
• プライベートメモリ
  • 830.5MB

になります。

httpdの起動数が最大50ですのえ、これを細かく計算すると　(830.5 / 50)　1プロセス辺り、平均で

16.61MB

のプライベートメモリを利用している計算になります。

4GBのメモリを搭載しているサーバで、webサーバ専用であれば、このプロセスサイズのhttpdを扱う場合

• OS、その他のメモリ 1GB
• httpd用のメモリ 3GB

と仮定し、

3GB = 共有メモリ（約100MB） +  ( プライベートメモリ（＠16.61MB） x  174 )

になるので、最大プロセス数を174までは理論上は起動できることになります。

※174という数字は参考値として捉えています。この数値ですと、全く余裕がない設定なので、実際はプロセス数を50前後から少しづつ増やしていっています。

まとめ＆mod_perlはメモリを食います

mod_perlの設定では、perlモジュールのロードによるメモリ消費量が一番クリティカルだと思います。
このコントロールを意識しないと、どんなに良い性能のサーバでもスワップが起こってしまいます。

対象方法としては、以下でしょうか。

なるべく共有メモリを使う

• startup.plでのモジュール読み込みで共有メモリになるべく多くのモジュールをロードさせます

プライベートメモリの肥大化を防ぐ

MaxRequestPerChildの方は、防ぐというよりも増加したメモリを強制的にkillしています。

• （当たり前ですが） strict を宣言して、グローバルで変数を使わないようにします
  • 全ての pl/pm ファイルで use strict するようにしています。 no strict もよっぽどの例外でない限り禁止しています。

    package App::Pages::Some;
    use strict;
    .
    .
    .

• Config、Cacheコネクションなどの毎回同じものはInstance化する

• MaxRequestsPerChild を少なめに設定し、リクエスト処理数の増加とプロセスサイズ増加にLimitをかけます
  • 通常は最大リクエスト数を100程度で設定してから調整を行っています。

    MaxRequestsPerChild  100

プロセス数の増加を防ぐ

プロセスの増加自体がメモリを消費するベースになります。無駄な増加は増やさないようにします。

• KeepAlive をOFFにする
  • Apacheをフロントとバックエンドの2つに分けて バックエンド側でmod_perlだけのリクエストを処理します。
    この際にバックエンド側では

    KeepAlive off

    を設定し、フロントからのコネクションを無駄に占有させることが無いようにしています。

但しAPIを多用するようなサイトの場合、KeepAlive On での設定の方が効率的な場合があります。

KeepAlive On
MaxKeepAliveRequests 10
KeepAliveTimeout 2

この場合の「MaxKeepAliveRequests」は、ブラウザで1ページを表示させる際に必要とする mod_perlへのリクエスト数を
割り当てます。

また、KeepAliveTimeoutを短く設定することで、フロントサーバからのコネクションを無駄に発生させないようにしています。

参考リンク

• SledgeのApache2（mod_perl2）対応＋UTF8
• Apacheについて（ありんく tech-log）

Sledgeというperl用のフレームワーク（MVC）があります。

このMVCは主に Apache1.3+mod_perlで運用されることが多いのですが、
今回 Apache2（mod_perl2）に対応させました。且つUTF8にも対応させます。

mod_perlはApache/Apache2のAPIの仕様が全くと言っていいほど互換性が無いため、
そのAPI周りの記述方法を変えた、別パッケージ群を作成しています。

Sledge自体はCompatを通さず、mod_perl2のみを利用し、UTF8コードを前提としています。

• 詳細はこちら

既存部分からの変更点

既存に存在するコードをミックスさせて作成しました。

SledgeのUTF8化について

• Bundle::Sledge::I18Nをインスパイアし、Apache2に対応した環境を作ります。

Apache2の対応について

• おいぬま日報(不定期) - Apache2 + mod_perl2.0.1 + Sledge-1.11をインスパイアしました。

Dispatcherについて

• Sledge::Dispatcherを元にApache2(mod_perl2)のAPIに対応させます。

利用法・ソースコードなどはSledgeのApache2（mod_perl2）対応＋UTF8 （ありんく tech-wiki） をご覧下さい。

mod_perl2などのインストールについて

Apache1、2について　（ありんく tech-wiki） をご覧下さい。

※CentOSを利用しています。できるだけyum（rpm）扱いにするようにしています。

mod_perl2の参考ドキュメント

• おいぬま日報(不定期) - Apache2 + mod_perl2.0.1 + Sledge-1.11
  • SledgeをApache2で動かした方
• mod_perl 2.0 Documentation（英語）
  • 数少ないmod_perl2のドキュメント。mod_perl1とのAPIでの相違点などを調べる
• mod_perl クイックリファレンス
  • こちらは日本語版。mod_perl1と2の相違点などが明確。
• mod_perl環境下による高速化 SourceForge.JP

参考リンク

• mod_perl2 インストール
  • Apache2のhttpd.conf周りの設定が詳しい
• MENTA（mod_perl2に対応しました）
  • handerに渡しているので、コードを読むと勉強になります。
• 10分で完了、mod_perl 2.0 で Hello, World! （naoyaのはてなダイアリー）
  • コンテンツハンドラを作るまでの流れ。
• mod_perl 2.0.4 httpd.conf 設定メモ
• mod_perl 2.0 の Server Life CycleCommentsAdd Star
  • mod_perl2の設定についての詳細

SledgeでSessionをCookieで制御する場合
デフォルトだと、Cookieの有効期限は

ブラウザを閉じたときまで保持

だと思います。

Formに持たせる情報など、一時的なものであれば全く構わないのですが、
ログイン情報など、半永続的に持たせたい情報の場合はCookieの有効期限を調整できた方が何かと便利です。

ということで、ブラウザを閉じてもSessionを維持できるようにCookieを少し変更しました。

変更点

Sledge::SessionManager::Cookieで、Cookieの有効期限をコントロールできるように変更しました。

$options{'-expires'} = $config->cookie_expires if $config->cookie_expires;

以下の場所に追記しています。

.........
$options{'-domain'} = $config->cookie_domain if $config->cookie_domain;
++ $options{'-expires'} = $config->cookie_expires if $config->cookie_expires;

my $cookie = CGI::Cookie->new(%options);
.........

これにより、Config内で

$C{COOKIE_EXPIRES} = '+100d';

のように設定しておけば、SessionのCookieの有効期限を自由に設定できます。

※MemcachedをSessionに設定している場合、Memcached自体のExpireを
Cookieと同じか、それ以上に設定しておく必要があります。

patch

一応ですが、 diff を取ってPatch化してみました。

牧大輔 さんの名著 モダンPerl入門 を熟読している最近なのですが、熱いです。実務に直結したノウハウが満載です。

弊社もPerlをメインに開発を行っています。開発の過程で色々と方向性などのキメを繰り返してきているのですが、大体同じ方向になるよう、緩やかな決まり事を作っています。
「モダン」という言葉にちょっとあやかってみて、弊社内の決まり事をまとめて「ありんく的モダンPerl」を挙げてみます。

といっても、MooseやCatalystゴリゴリでという方向ではないです。昔からある手法やモジュールを使っててもよいですし、最新のモジュール利用もしています。

ポリシー

ざっくりとしたポリシーは、おおよそ以下でしょうか。

• プログラムが高速に動作する
• ハードウェアやOSに依存しない
• 後からも読みやすい。可読性が高い
• 頻繁に仕様変更しているモジュールに極度に依存しない
• 1つのサブルーチンの中は15ステップまで

Perlに限った話でなく、どの言語でも言える事ですね。永遠のテーマかも。

スタイル

ウェブアプリケーションの開発以外にも、統計データの解析や資料用データの作成の業務などもあるのですが、ほとんどをPerlでコーディングします。
使い捨てスクリプトから大規模アプリケーションまでベースとするスタイルは共通化させています。

• 強制的な指定がない限り、文字コードはUTF8で書く
• Perlのバージョンは5.8.8
• shebang は #!/usr/local/bin/perl
  • /usr/bin/perl にPerlが存在する場合は、シンボリックリンクを張る
• 以下3つの宣言は必須

  use utf8;
  use strict;
  use warnings;

• インデントは"タブ"ではなく"半角スペースx4"
• 全てのスクリプトはsubversionなどのバージョン管理システムに登録する

use utf8 させていますので、スクリプト自体にutf8フラグが立った状態になります。

利用するモジュールなど

• 文字コード変換にはEncodeを利用する
  • Jcode.pm、jcode.plは使わない
• 日時計算まわりはDateTimeモジュールを利用する
  • timelocal、Time::Piece、Posixは使わない。
• Class::Accessor::Fast、Cache::Memcached::Fast など、シンプルでオーバーヘッドが小さいモジュールを利用する
• Cache接続用のinstanceを作成する場合は、必ずsingletonにする
• XSがある場合はXS対応のモジュールを使う
  • Text::CSV_XS、JSON::XS URI::Escape::XS XML::LibXMLなど
    • ※XSをインストールできない場合はそれぞれのPurePerl版を利用する

Webアプリ用フレームワーク

• Sledge を利用する
  • ※UTF8に対応する必要があります

O/Rマッパー

• DBIx::MoCo を利用する
  • まだ仕様変更が多いため DBIx::Classは使っていない
  • ※昔のプロジェクトではClass::DBIを未だに利用しています。
• PagerはPagesetを利用する
  • Class::DBI::Pageset
  • DBIx::MoCo::Pageset
• DBとのやり取りは全てDBIを経由して行い、SQLもDBに依存した書き方をしない。
  • なるべくMySQL、PostgreSQLで同じに動作するようにする。（SQLiteも含みますが・・・）

テンプレート

• TemplateTookit を利用する
  • TTマニュアル（和訳）
  • Temlateモジュールの詳細情報
• プログラム冒頭にTemplate->newでインスタンスを初期化し、以降はなるべく最初にインスタンス化したTTを利用する。
• 必ずコンパイルする
• メール送信用のテンプレもTTを利用し MIME::Lite::TT::Japanese を利用する

まとめ

非常にざっくり過ぎるのですが、おおよそこの形でコーディングを行っています。
大してモダンなスタイルでもないのですが、この形であれば極端に遅くなることもないかと思います。

利用しているOSがCentOSとFreeBSDですので、WindowsのActivePerlは考慮していません。

画像処理周りなど、思いっきり落としていますね・・・・
多分他にも書き忘れている部分が多々あるので、追記していきたいと思います。

転職活動で役に立つかもしれない知識その2です。（その1はこちら）

転職活動で自己アピールしよう! 「Webプログラマー編」その1では、下調べや想定するためのノウハウをご紹介しましたが、今回は実際の面接時での「仕込み」についてご紹介します。

今回もWebプログラマーの場合限定ですので、多少偏った表現があるかもしれませんが、ご容赦下さい

面接は「能力を発揮できない場」

面接までたどり着いたら、あとは50％人柄、50％技術力です。
なのですが、そのどちらも理解してもらうためには口頭では限界があります。

理解してもらえないと、結局伝わったことにはなりませんが
緊張した状況ですので、自分を十分には発揮はできない場と想定する方が自然です。

ですので、事前にできるだけ仕込みをします。

仕込む資料

資料は自分が落ち着いて望むための資料と、相手により理解してもらうための資料の2つを作成します。

カンペを作る

履歴書・職務経歴書を提出し、（事前に郵送を求める企業もありますが）履歴書・職務経歴書を見てもらいながら
いままでの経歴を口頭で説明します。
この時に、履歴書に記載したことをつらつらと述べるのではなく
要点を絞って、アピールしたい点を重点的に説明する必要があります。

できれば全て暗記してから望むが理想的なのですが
中々覚えられるものでもありませんので、言いたいことを箇条書きに書いておくと大変役に立ちます。

例えば以下のようなものです。
自分はこの箇条書きをもって行き、面接官からは見えないようにしてカンペを利用しました。

• 数十万PV/日のサイトを０から設計＆構築した
• PerlとPostgreSQLを使っている
• 極端にPVが上がる日、集中するコンテンツがあるので日々チューニングしている

システム構成例の資料を作る

自分が携わったプロジェクトに近い構成のモデルを用意します。

私の場合は、PCサイトとケータイサイトで連動したシステムを作っていましたので
以下のような資料を構成しました。

システム構成例（PPT） ※クリックするとPPTがダウンロードできます

とても簡単な、概念そのものでしかない資料ではあるのですが
こういった資料があると、こちらを見てもらいながら話すことができますので、落ち着いて望めます。

ソースコードのサンプルを作る

webプログラマーの場合、当然ですがプログラムを作成しますので、面接の担当者としては
「どれぐらいのプログラムの素養・スキルを持っている人物なのか」が気になります。

これは、面接時に話をする過程でおおよそのことは分かってきます。特に、どれぐらいの規模感でおこなってきたのか、どれぐらいの分量をさばいてきたのかなどは、口頭での説明でよく見えてきます。

私も以前、面接官として望んだことがあるのですが（ありんくの以前です）
質問する時は必ず、以下の3つの事を聞いていました。

1. プログラムを書く上で気をつけている事は何ですか？
2. 開発している過程で困ったことはありませんでしたか？
3. プログラム以外の部分で何かしていますか？

１で、そのプログラム言語をどれぐらい理解しているのかが分かります。
2で、想定するケースがどれぐらいあるのか（場数をどれだけ踏んでいるか）が分かります。
3で、ApacheやDBを意識した開発をしているか、サーバー自体を扱うことができるのかなどがわかります。

しかし、これ以外の部分は実際のソースコードをみてみないと分からない部分もあり
サンプルコードを見せることで、より理解してもらえます。

私のケースでは、面接する先の会社ではPerl/mod_perlがよく利用されていたため、
WebアプリケーションとしてPerlを利用する場合、最も高速に動作するmod_perlハンドラを例にして、サンプルコードを見せました。

CSS Minify!!などもmod_perlハンドラで構成されています。このサービスのソースコードを公開していますのでご覧下さい。

• CSSMinify!!のソースコード（ありんく tech-wiki）

このソースコードを見せながら、実際に苦労した点、工夫した点などを説明しました。
mod_perlで書かれていますので、mod_perlならではの点を伝えることもできます。

あとは、これらをどのような流れで、どれだけの期間で作成したのかを伝えれば、おおよその持っているスキルは伝わると思います。

まとめ

いかがでしょうか。先のエントリの 転職活動で自己アピールしよう! 「Webプログラマー編」その1 と併せて読んで頂けるとうれしいです。

今までの経験では資料を持って行って、見せる事を断られたケースはありません。また、そういったケースを聞いた事もないので積極的に見せた方が良いかもしれません。

面接は筆記試験ではなく、本当に「面」と向かって「接」触する場ですから、
なるべく自分に有利になる、自分が落ち着けるものを持っていく方がいいと思います。

書類選考や下調べに関しては転職活動で自己アピールしよう! 「Webプログラマー編」その1をご覧下さい。

ありんくtech-logは wordpress を使って作成しています。

wordpressはプラグインの設定が簡単でして、このブログでも

• Custom Posts Per Page
  • ページごとに投稿するページ数を変更する
• Dean’s Code Highlighter
  • GeSHiを使ったコードハイライター
• Flexible upload
  • 画像をイイ感じにアップロードしてくれるプラグイン
• Pukiwiki
  • XOOPSのwordpress用のpukiwiki文法でのレンダー
• WP Multibyte Patch
  • WordPress のマルチバイト文字の取り扱いに関する不具合の累積的修正と強化を行うプラグイン

を使っています。

これに加え今回、WordPress Mobile Plugin を追加しまして、モバイル用のページを作成しました。
URLは変わらず http://www.alink.co.jp/tech/blog/ です。

QRコードはこちらです

インストールは他のwordpress用プラグインと同様に簡単です。

cd /path/to/wordpress/plugin/
wget http://wordpressmobile.mobi/download.zip
unzip download.zip

展開した後に、CMSのプラグイン画面で「Wordpress Mobile」のプラグインを使用開始します。
これで、モバイルからのアクセスではモバイル用の画面に最適化されます。

※WordPressのpukiwikiプラグインを利用しているため、コンテンツ自体をWikiの文法で記述しているものが多いです。
モバイル版ではまだWiki文法に非対応のため一部のコンテンツでは本来の表示ではない状態になっております。
ご迷惑をお掛けしますが 追って対応したいと思っています。

私事ですが、34歳になりました。

Web業界は技術の進化やトレンドの変遷の流れが激しく、付いていくのが中々大変なのですが
34歳になった現在も、まだまだプログラムを書いたり、サーバをいじったりと最前線で技術をさせてもらっています。

33歳の活動

去年から今年（33歳～34歳）にかけては、業務の中で勉強させて頂いた事多かったと実感しています。
ざっとなのですが、以下のような仕事をさせていただきました。

• mod_perlを使った案件
• ネットワークからフロントエンドのCSS/XHTMLまでを幅広く担当
• jQuery/Ajaxを使った複雑なJavaScriptと、連動するAPIの開発
• ピーキーな負荷を抱えるサイトへのコンサル
• Intelの新CPUにあわせたサーバ選定

新しい試みや、既存の経験を踏まえた別の案件などが目立っていたと感じています。

また、Web技術者としての活動もそこそこ行えました。

• 本Blogの本格始動
• CPANへのPerlモジュールアップ
• googleCodeでのjQueryライブラリのリリース
• 他社とのWeb技術勉強会の開催、プレゼン発表

34歳の活動（抱負）

ハードウェアなど

ルータ/FW機器の性格を持つサーバ周りの知識の習得を更に意識したいと思っています。

これから先の1年はSSDが更に安価になり、普及してくると思います。
且つ、サーバー1台あたりの価格と性能の比較は「ムーアの法則」にならいより進化していきますので

• SSDのDiskIOの性能で運用できるサーバはほとんどがSSDで構築

になって来ると思っています。

デスクトップの値段にどんどん近づいているノートPCを利用して
バッテリーでバックアップできる自作PC的な扱いができる、

• ノートPCそのものでサーバ構築
  も、相当に流行ってくると予想しています。

ですので、DiskIOが発生し難い＝書き込みが少ないアプリ・ミドルウェアをのせるサーバが
を重要視していまして、特には、

LVS、mod_proxybalancer、perlBalなどを利用したロードバランサーをSSDの上に構築

などです。これらを更に学びたいと思います。

CPUはTDP65WのQuadが出始めているので、
今年～来年にかけては Quad普及時期になってくると思います。

アプリ/ミドルウェアなど

他には PHP5.3/6.0 のプロダクションリリースやperl5.10の標準yumでのリリースも有り得ると思っていまして
PHPもネイティブにコーディングできるスキルを身につけたいと思います。

JSはjQueryが今年1月にVer１．３が発表されました。当分はjQueryでいけると思います。

jQueryのチェーンメソッドがコーディングスピードを増していて、大変効率的だと思います。
prototype.jsはちょっとOOPしすぎているのと
YUIは3.0がでてフルチェンジするまでは 重いライブラリ群のように見えます。

苦手なAS3をぼちぼち手をつけないと・・・という焦りもあります。

ミドルウェアでは Solr、Memcached、MySQL5.1、Tokyo Tyrant、
テンプレエンジンでは Tenjin、ClearSilver 、Text::MicroTemplate
に注目しています。

ありんくの開発サイクル

大・中企業ではシステムエンジニア（SE）とプログラマ（PG）は分けられていたりもするのですが、
弊社では、そもそも「システムエンジニア」という職種は存在しません。

技術者はプログラムを書ける事が前提で、その上でハードやネットワークの設計を行います。具体的には

• ヒアリングを行いながら、コンテンツの想定を行い
• 全体の設計を考えつつ、プログラムの枠組みを決め
• プログラムをコーディングしながら負荷状況を想定し、ハードウェアやネットワークの選定をする
• そしてまたヒアリングを行い微修正を繰り返していく

というサイクルを繰り返しています。
このサイクルを分業するのではなく、各人が全てを担当する事を重要視しています。

現在の弊社の状況ではこれが最善だと思っていますので
今後ともこの方向性を強化したいと思っています。

「プログラマ35歳定年説」はありえない

全員で常に最前線で仕事をしている事も大きく影響しているのですが
よくある「プログラマ35歳定年説」は単なる都市伝説だと思っています。

「35歳になったからプログラマはできない」はずは無く
今までの経験を生かして、よりよいプログラムを書けるようになるはずだと思います。

サーバやハードウェアの選定や設計はプログラムを動作させる上で色々と想定するので
良いプログラムをかければ、良い選定や設計ができるようになるはずです。

データベースサーバなどは特にプログラムに影響するミドルウェアですので、
プログラムの知識が無いとDBの設計・構築は難しいと思っています。

また、良いプログラムというものはおおよそ見通しが効く、きれいなプログラムですので
もっと広義のプログラム（＝フレームワークなど）を踏まえた設計もできるようになるはずです。

こういった経験を踏まえていくことで、素晴らしいシステムを効率的に開発できる、良いエンジニアに成長できると思っています。
イコール、35歳以上でも最前線でバリバリに戦えるエンジニアになるのではないでしょうか。

まとめ

ということで、35歳でも45歳でも55歳でもプログラムを書き続けたいと思っています。

毎年の進化の中でどこからかアタリを付けて知識を掘り下げていくスタイルは
昔からとっていることでもありまして、結局は粛々と頑張っていく事を続けたいと思います。

また、各種Web技術勉強会に積極的に参加し、知識や体系の脳内での整理をしたいとも思います。

弊社では簡単なCGIから、コンサル、大規模サイト構築まで、おおよそのことはご相談頂ければ
回答差し上げる事ができます。

ご相談ベースでも大歓迎です、システム的なお悩みがありましたら是非ご相談下さい。

perlのテンプレートエンジンは TT（template-toolkit が有名です。
他にも HTML::Template や Mason などがメジャーどころとしては存在するかと思います。

弊社では通常はTTを利用していますが、今回はそれとは別のテンプレートエンジン tenjin を試してみます。

2009.07.28
CPANにUPされたみたいです。下記インストール方法ではなく

cpan > install Tenjin

でインストールした方が良いです

Tenjinについて

Tenjinは kuwata-lab.com 様で作成されている テンプレートエンジンです、perl/PHP/ruby他、JSなども対応しています。

PHPやJSPのようにHTML内にスクリプトを埋め込むスタイルで、レンダリングの高速性を特徴としています。

• Tenjin is a very fast and full-featured template engine available in several script languages.
  • Tenjinはとても高速で、各種言語でフル機能を実装したテンプレートエンジンです
• 3 times faster than Smarty.
  • Smarty （PHPのテンプレートエンジン）より3倍速いです
• 5 times faster than Template-Toolkit.
  • TemplateToolkit よりも5倍速いです

との事なので 非常に興味が沸きます。TTより5倍も速くなるのでしょうか？！

ダウンロード・インストール

perlのバージョンを確認

今回は CentOS5.3 にPerl 5.8.8 が入っている状態を想定します。perlが無い場合・perlのバージョンが低い場合は

# yum update perl

で最新版に更新できます。

Tenjin をダウンロード

ダウンロードサイト（sourceforge） から perl版のTenjin（pltenjin） をダウンロードします。
現在の最新版は 0.0.2 ですので、こちらをダウンロードします

# cd /usr/local/src
# wget http://ncu.dl.sourceforge.net/sourceforge/tenjin/pltenjin-0.0.2.tar.gz

インストール

解凍し、中にある lib/Tenjin.pm と bin/pltenjin をコピーします。
今回は Tenjin.pmはperlのライブラリのディレクトリに、 pltenjinは /usr/local/bin 以下にコピーしました。

# tar xvzf pltenjin-0.0.2.tar.gz
# cd pltenjin-0.0.2
# cp lib/Tenjin.pm /usr/lib/perl5/site_perl/5.8.8/Tenjin.pm
# cp bin/pltenjin /usr/local/bin/pltenjin

この辺りはインストーラーがあると作業がシンプルになるかもしれないですね。

ベンチマーク

では、実際に同じようなテンプレートでTTと速度を比べてみます。
ベンチマークを行うソースは以下です。

bentch.pl

テンプレートは以下です

bench.tt (TT用)

bench.plhtml (Tenjin用)

ベンチマーク結果

上記スクリプトを実行した結果です。TTのオーバーヘッドはやはり大きいのでしょうか、シンプルな反復処理だけですが、
相当な違いが結果として出ています。

./bench.pl

Benchmark: timing 1000 iterations of TT, TT(Compiled), Tenjin(Compiled)...
        TT:  9 wallclock secs ( 9.10 usr +  0.02 sys =  9.12 CPU) @ 109.65/s (n=1000)
TT(Compiled):  5 wallclock secs ( 4.15 usr +  0.08 sys =  4.23 CPU) @ 236.41/s (n=1000)
Tenjin(Compiled):  0 wallclock secs ( 0.61 usr +  0.01 sys =  0.62 CPU) @ 1612.90/s (n=1000)
                   Rate               TT     TT(Compiled) Tenjin(Compiled)
TT                110/s               --             -54%             -93%
TT(Compiled)      236/s             116%               --             -85%
Tenjin(Compiled) 1613/s            1371%             582%               --

ちょっと極端な例かもしれませんが、Tenjinの速度は
通常のTTと比べて13倍以上、TTコンパイル版と比べても5倍以上のスピードが出ています。

ただ、TTが便利な点も多く、
ハッシュとオブジェクトの区別や、ループ処理時はloopオブジェクトが自動生成されるなど
非常に運用しやすい形態になっています。

例えば
TTでは以下は同じ文法かと思います。

[% hash.key %]
[% object.method %]

しかしTenjinでは素のPerlコードをそのまま書くため、

[=$hash->{'key'}=]
[=$object->method=]

と記述が変わるあたりが不便といえば不便でしょうか。

しかしそれにしても中々のスピードですね・・・

記述方法や応用例などをもう少し調査したいと思います。

私はWebプログラマーを自分の生業（なりわい）として久しいのですが、転職の経験があります。
中途採用という形で採用して頂いたのですが、この時に私自身が気をつけたことや 実行した事を書きたいと思います。

新しい職場に就職するまでには、ほぼ必ず

応募 → 書類選考 → 面接（数回） → 給与などの条件交渉 → 内定

のステップを踏むと思います。

応募～書類選考

応募するとその会社の人事担当者や現場のリーダーが応募した情報や文章を読みます。
この内容を元に、実際に会って面接するかどうかを決定します。

応募書類というものは、文面でしか相手にアピールできませんので、他の応募者との差別化が難しいです。
しかも最近は、Webフォームで応募という形式も多いですので、「履歴書を丁寧な文字で書く」などといった
昔ながらの方法も通用しにくいです。

今回は特にWebプログラマーにフォーカスしていますので、必然的にWeb技術面を重要視した文面を作ることになります。

面接

面接では履歴書を持って行き、直接話してやりとりをするのは当たり前なのですが
話題の中の1つとして、これまでの成果を具体的に資料としてまとめると効果的です。

特に自分から話して自己アピールする時、物理的に紙の資料があると
相手の視線が自分だけに行かず、資料も見ながら接してくれますので、気持ちも楽に面接に望むことができると思います。

私は以前、就職活動で応募する際に「mod_perlで作成されたRSSリーダー」を作成し、
面接の時にはそのソースコードと、アプリケーション全体の構成をPPT（パワーポイントの資料）で起こし、
プリントしてもっていきました。

その会社で採用している技術を使える・使っている？

Web技術者を中途採用するということは、採用する側は即戦力としての力を求めます。
ですので、応募する会社が採用・運用している技術を自分が使える・使っていることがもっとも効果的です。

応募する文面も面接時の資料でも、その会社が望んでいる技術に近しい技術の方が 当然ですがつかみやすいです。

企業が採用しているWeb技術は ネット上である程度の情報は調査できますので
自分自身のスキルアップの方向性も 応募する企業が求める技術に近い方が効果的かもしれません。

以下、Yahoo!、Mixi、楽天のネット上で公開されている、Web技術についての情報です。

Yahoo!の場合

Yahoo! Japanでは、最近色々な所で技術情報が公開され、PHP at Yahoo! JAPANなど、PHPのカンファレンスでも言及されているとおり、

• FreeBSD
• Apache
• MySQL
• PHP

で多くが構成されているようです。

Yahoo!Inc（アメリカのYahoo!）では、Yahoo!の技術変遷の資料もあり、非常に細かい部分まで公開されています。

• 「Yes, we’re still using Apache 1.3」 （私たちはまだApache1.3を使っているんです！）
• 「Why not Perl?（なぜPerlじゃないの？）」
• Y!INCのYahoo!Bookmarkでは ウェブフレームワークにsymfonyを採用
• Y!INCで採用する際にPHPの技量をチェック

など、Y!INCは積極的にPHPを利用しているようです。

Yahoo!のような大企業の場合、使われている技術も多岐に渡っていると思いますが
特に FreeBSD、Apache、MySQL、PHPの技術は必須と思われます。

Mixiの場合

MixiのWebエンジニア採用情報 では
以下のような条件が明記されています。

【歓迎する経験】
・LAMP (Linux， Apache， MySQL， PerlもしくはPHP) 環境でのウェブ開発の経験
・ウェブフレームワークを利用した開発経験
・MVCパターンの開発経験

【当社の環境】
(Linux 2.6，Apache 2.0，MySQL 4.0/4.1/5.0，Perl 5.8) 

ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」 （ITPro）など、Mixiのアーキテクチャは色々なところで公開されています。

見ても明らかな通り、応募する際にはLAMPの経験・実績と
「PerlもしくはPHP」とはありますが、Perlの、特にmod_perlやFastCGIなどのWebアプリケーションとしての成果物の実績が必要だと思われます。

Perl/mod_perl は弊社でも採用している技術です。この技術の上に構築されているウェブフレームワークは

• Sledge
• Catalyst
• CGI::Application

などがあります。

厳密にはフレームワークではありませんが、mod_perlの使い方としてメジャーな

• ModPerl::Registry (Apache 2.x用）
• Apache::Registry（Apache 1.x用）

なども存在します。

こういった技術を使って、サイトを作っている、前職で作っていたなどとアピールするのが重要だと思います。
（ちなみに ありんくのコーポレートサイトはSledgeを使って構成されています）

楽天の場合

楽天の場合はプレスリリースでも紹介されていますが、Ruby On Rails を採用しています。

• 「Ruby on Rails」を用いたサービスの開発および提供を開始 （楽天のプレスリリース）
• 楽天、Ruby on Railsで会員ページを刷新 （ITメディア）

会員ページなどのコアな部分でRubyOnRails（RoR)を採用していますので、今後楽天内の各サービスも順次対応していくと思われます。

自分の経験

当時私がアピールできるレベルでの持っているWeb技術は、以下でした。

• 1日数十万PVのサイトの運用経験
• FreeBSD/Linux(RedHat) 上での運用経験
• Apacheの設定チューニング経験
• PostgreSQLでのデータベース構築経験
• PerlでのWebアプリケーション開発・運用経験

私は当時行きたい企業が明確でしたので、その企業が採用している技術を調べました。

もちろんマッチしないWeb技術が上記には含まれますが、アピールできるポイントも限られるため
持っているWeb技術を元に応募する企業に会わせて望ましい資料を作成し、サンプルアプリケーションを開発し、ソースコードを紹介しました。

当時はまだPHPは新しい言語だったため、採用している企業は少ないという世情でした。

なので、PHPには特に言及せず、

Perlをメインとし、日数十万PVのサイト全体のバランスを見ながら Apacheの設定をチューニングし
DBとWebアプリケーションをうまく連動させたサイトを作っていました

とアピールしました。

まとめ

ネット企業であれば、そのシステムのおおよそのケースでLAMPが使われていると思います。

LL（LightweightLanguage) の言語はPerl/PHP/Rubyなど、企業によってまちまちですが
Linux（FreeBSD)、Apache、MySQLについては、上記3つの企業ではどれも採用しています。

この3つについては必須、スクリプト言語は自分の行きたい企業が採用しているものか、もしくは自分が得意な言語から入っていき、スキルアップするのもいいかもしれません。
または自分の得意な言語をメインに採用している企業にフォーカスするのも良いかと思います。

応募の際にはその企業の採用している技術をよく調べ、なるべくマッチングするポイントを自分で定義することが大変重要です。

次回は面接時に見せるための資料作成の例と、それを見せながらのWeb技術面を口頭で説明するポイントについて書きたいと思います。

追記

• 2009/05/31
  • 転職活動で自己アピールしよう! 「Webプログラマー編」その2を公開しました。資料構成の例などを掲載しています、ご覧下さい。

細かいプロジェクトが積み重なってくると、プロジェクトによって色々な文字コードが混在する状況になりがちです。
ありがちなパターンなのですが、ちょっと昔のプロジェクトだとEUC-JP、最近のプロジェクトはUTF-8で構成している場合などです。

別々のサーバで開発ができれば、それぞれのサーバの文字コードをキメ打ちすればいいのですが
開発サーバが1台で、それぞれのプロジェクトを共有する場合、1台で文字コードを使い分けないといけなくなります。

意識するのが以下の3点です。

• シェル
• MySQLなどのDBサーバ
• Webアプリケーション

特に「デフォルトがUTF8で、イレギュラー扱いでEUC-JP」というパターンが多いのですが
弊社ではこれらについて以下のように対応しています。

シェル

シェル本体

個人的にですがデフォルトでzshを使っています。イレギュラー扱いでbashを起動させるようにしています。

デフォルトシェルをshに設定して、以下のように分けます。

• UTF-8の場合

   → putty(UTF-8)  → shでログイン → zshを起動

  • .zshrc に以下を設定しています

    .zshrc
    export locale=ja_JP.UTF-8

• EUC-JPの場合

  →putty(EUC-JP) → shでログイン → bashを起動

  • .bashrc に以下を設定しています

    .bashrc
    export locale=ja_JP.eucJP

※利用するシェルを指定しているわけではありませんので、csh tcshなどのシェルを利用しているエンジニアもいます。

.vimrc

vimは通常 ~/.vimrc を読み込みますがオプションで別のconfigファイルを読み込むことができます。
これを利用して bash（EUC-JP）側では違う.vimrcを読み込ませ、文字コードを強制的に認識させます。

※本来は自動認識が一番スマートなのですが、うまいこといかず・・・

• zsh + UTF-8の場合

  .vimrc
  
  set encoding=utf-8
  set fileencoding=utf-8
  set ambiwidth=double

• bash + EUC-JPの場合

  .vimrc-euc-jp
  
  set encoding=euc-jp
  set fileencoding=euc-jp

これらを設定して .bashrc でエイリアスを設定しています

alias  vim="vim -u ~/.vimrc-eucjp"

.screenrc

screenコマンドも文字コードを明示的に分けています

• zsh + UTF-8の場合

  .screenrc
  
  defencoding utf-8
  encoding utf-8 utf-8

.zshrc でエイリアスを設定しています

alias screen="screen -U -c ~/.screen"

• bash + EUC-JPの場合

  .screenrc-euc-jp
  
  defencoding eucJP

.bashrc でエイリアスを設定しています

alias screen="screen -c ~/.screenrc-eucjp"

MySQL

MySQLはサーバとクライアントで文字コードがごちゃごちゃになりがちですが、
以下のようにルール付けしています。

my.cnf

my.cnfでは明示的にutf8を指定します。
ただしskip-character-set-client-handshakeは使用していません。ujis（EUC-JP）時に強制的にUTF-8になってしまうからです。

/etc/my.cnf

[client]
 default-character-set = utf8
[mysqld]
default-character-set = utf8
character-set-server = utf8

データベースの作成（CREATE DATABASE）

データベースの作成（CREATE DATABASE）時に、そのDBでデフォルトとなる文字コードを指定します。
これにより、 load data infile xxx などの外部CSVのインポートでも　文字コードが正しく認識されます。

UTF-8

mysql> create database database_name default character set utf8;

EUC-JP

mysql> create database database_name default character set ujis;

テーブルの作成 （CREATE TABLE）

テーブルの作成 （CREATE TABLE）時も明示的に利用する文字コードを指定します。

UTF-8

CREATE TABLE ex_table (
  ....
) default charset=utf8;

EUC-JP

CREATE TABLE ex_table (
  ....
) default charset=ujis;

mysqlクライアント

接続時にEUCの場合に default-character-set オプションをつけます。

毎回は面倒なので .bashrcに以下のエイリアスを設定しています。

UTF-8

alias mysql-connect="mysql -uuser -p --default-character-set=utf8"

EUC-JP

alias mysql-connect="mysql -uuser -p --default-character-set=ujis"

ウェブアプリケーション

PHP

PHPでのコーディングではシェルとターミナルの組み合わせをしっかり指定しておけば
文字化け自体の問題は特には無いと思います。

EUCの場合のみ、DBへの接続はプログラム側で最初の接続時に

set names ujis;

とSQLを発行させています。

Perl

UTF8フラグと戦わないといけません・・・
弊社ではUTF8フラグをonにした状態をデフォルトと想定しています。

#!/usr/local/bin/perl

use utf8;
use strict;
use warnings;
.
.
.

などです。

DBI経由でMySQLに接続するときはデフォルトで/etc/my.cnfを読み込みます。

EUC-JPで読み込みたい場合は、文字コードセットがデフォルトですとUTF8に設定していますので、別途アプリ用のcnfを作成しています。

• /home/proj/config/dbi.my.cnf

  [client]
  default-character-set=ujis

接続クライアントの文字コードを指定しただけです。
このファイルをDBIの接続の都度読み込ませます。

• DBIで接続

  $dbh = DBI->connect('dbi:mysql:dbname;host=localhost;mysql_read_default_file=/home/proj/config/dbi.my.cnf', $user, $password);

dsnに mysql_read_default_file というファイルを読み込むオプションを追加しています。

大体このような形で運用しています。
非効率な部分もあるかと思いますが、ご意見を頂けますと幸いです。

参考リンク

perl EncodeモジュールとUTF8の扱いについて

• use Encode; - 今日のCPANモジュール

memcachedの詳細な稼働状況を把握するためにはせいぜい

ps aux | grep memcached

などで、おおよそのメモリの使用量をチェックする程度しかしていませんでした。

PHPでmemcachedをいじるために色々調べ物をしていたのですが、
memcachedの稼働状況をチェックするのに便利なツールを見つけました。（去年のエントリだったんですね・・）

memcache.php stats like apc.php

• http://livebookmark.net/journal/2008/05/21/memcachephp-stats-like-apcphp/
• ダウンロードはこちら（memcachephp.zip）

apc.php（APCの稼動状況チェックツール）のように稼動状況を視覚化してくれるスクリプトです
GDモジュールがインストールされていると、さらにグラフ化までしてくれます。

設定など

※あらかじめmemcachedをインストールしておく必要があります。

memcache.php を設定します

Webから認証させて見るために、以下の部分のユーザー名・パスワードを設定します。

以下の部分を対象とするホスト（localhostなど）とポート（11211など）に書き換えます

サンプル

ご参考までに、弊社のあるサーバの稼働状況を出してみました。

監視ツール系の1つとしていかがでしょうか。

参考リンク

memcache.phpのページ

• memcache.php stats like apc.php

APCについて

• APC（Alternative PHP Cache）再び
• APC(Alternative PHP Cache)

YSlowとは

サイトの表示スピードをクライアントサイドでチェックできるYSlowの新バージョンの2.0がリリースされました。（4月30日）

Firefoxのプラグインとして簡単に使えます。Firefoxで、YSLOWのダウンロードサイトを開き、モジュールをダウンロード（Add-on）すれば簡単に利用できます。

ブラウザの右下に「YSlow x.xxxs」という表示が出ますので、これをダブルクリックすると詳細なツールを利用できるようになります。

サイトの体感速度をランク化したり、通常では分かりづらいキャッシュのかかり具合などを測定してくれます。

YSlow1.0からの変更点など

今回のバージョンアップでUIやYSlow自体のデザインが大きく変わっていますが、
大きなポイントはやはりGradeでのチェック項目の追加でしょうか。

追加項目

以下が新規に追加されたチェック項目です、見落としがちなところばかりですね。

• Avoid CSS expressions
  • CSS expressionsは避けよう。 マイクロソフトが「CSS expressionsはIE8ではサポートせず」とアナウンスしています
• Remove duplicate JavaScript and CSS
  • 重複したJavaScropt、CSSファイルは無しで。特にIEは2重のリクエストが発生します
• Use GET for AJAX requests
  • AjaxではGETメソッドでリクエストしよう。
    POSTだとキャッシュをかけにくい事に起因するかと思いますが、キャッシュを絶対にさせない場合はPOSTの方が望ましいかもしれません。
• Make AJAX cacheable
  • 普段使いのAjaxリクエスト先のAPIはキャッシュがかかるようにしよう
    上記と関連する項目ですが、Y!のブログでは「Ajaxリクエストで更新データを確実にFEEDするにはGETでクエリにタイムスタンプをつけて渡そうよ！」という解釈です。
• Reduce the number of DOM elements
  • DOMエレメント数（HTMLのタグのノード数）は最小限に切り詰めよう
    Y!のブログでは「Y!のページはDOM数は700以下にしている」そうです
• Avoid HTTP 404 (Not Found) error
  • 「ページが見つかりません」404エラーは避けよう
    Not Foundのリクエストはそれ自体がWebサーバに負担をかけます
• Reduce cookie size
  • クッキーの（文字列を含む）全体のサイズは最小限に
• Use cookie-free domains
  • スタティック画像などにはクッキーは付けないでおこう
    （マスタドメインにクッキーを付けるとこの辺は厳しいですね。スタティック画像は別ドメインで切り分けた方が無難なのでしょうか）
• Use cookie-free domains
  • スタティック画像はクッキー無しで。上記「Use cookie-free domains」に関連する項目です
• Do not scale images in HTML
  • IMGタグは画像の大きさをそのまま使おう。必要以上に大きな画像は避けよう
• Avoid AlphaImageLoader filter
  • AlphaImageLoaderはIEがフリーズするので避けよう（そうなんですね・・・）
• Make favicon small and cacheable
  • faviconを作ろう。小さくコンパクトにキャッシュをかけて。404エラーも防げます

ありんくトップページをチェック

ありんくのトップページをチェックしてみました。

クライアントの体感速度の状況

キャッシュやHTMLの構成など、総合的に判断されます。ありんくトップページはグレードがBとDの間を行ったり来たりしています。

コンポーネントのキャッシュ状況

expireヘッダなどを使ったキャッシュ状況や、gzipでの圧縮具合の概況を表示。おおよそキャッシュできているようです。

コンポーネントのダウンロード状況

Firebug本体にも同様の機能がありますが、こちらは更に詳細にチェックできます。

いかがでしょうか、非常に便利なツールですので、是非試してください。

昨日（5月4日）にFreeBSD7.2がリリースされました。
RCが外れて、プロダクションリリースになったようです。

7.1が4月中旬だったので、えらくはやいバージョンアップです。

FreeBSD 7.2-RELEASE Announcement

• http://www.freebsd.org/releases/7.2R/announce.html

昨年のいまごろ、丁度FreeBSD7.0をいじっていました。
最初からIntelNICを使っていれば良かったのですが
MBにオンボードのRealtekのNICにこだわってしまい、不具合で遭えなく撃沈しました。

FreeBSDに限らずCentOS（Linux）でもそうなのですが、
やはりNICはIntel製のものを使った方がベターです。
（ということはマザーもIntel製の方が安く上がったりするのですが・・・）

プログラマが一番さわるPCのデバイスはキーボードです。
キーボードは一旦気になり始めると凝ってしまうものでして、私も色々使ってみては他のキーボードといった具合に変遷を辿っています。

ということで、ここ4～5年で使ったキーボードと使用感です。

HP純正キーボード（2004年～2005年）

HPのPCを使っていましたので、まんま純正で付いてくるキーボードです。
キーストロークが短かったので、タイプが楽だった記憶があります。
いわゆる普通のメンブレン方式のキーボードですね。市場価格は1000円～3000円ぐらいでしょうか。

PFU Happy Hacking Keyboard Lite2 （白）　（2006年～2007年）

有名なPFUのキーボードです。コンパクトなので非常に使いやすく、ずっと使っていました。
会社用と自宅用など白と黒を2つ買ってしまってます。

本当は無接点方式のProfessional 2が欲しかったのですが、高かったので（確か24,000円ぐらい）、廉価版のLite2にしました。

Lite２は6000円ぐらいなのですが、メンブレン方式なのでProfessional 2とは使用感が違います。
Professional 2はさすが値段の分だけあると思います。

英字配列のものを使っています。日本語/英語の切り替えが「alt+`」です。
キーボードの配列が日本語のものと若干違うので違和感がありますが、なれると英字配列も使い易いです。

白は会社用で使ってます。打ちすぎてもうキートップがツルツルです。

PFU Happy Hacking Keyboard Lite2 （黒）　（2006年～2007年）

黒は自宅用です。
白もそうなのですが、背面にUSBハブが付いているのですが、これが微妙に便利。

ノートPCのキーボードの上にこれを置いて使ったりしています。

エレコム tk-up87mpbk （2008年～）

たまにいきなりパンタグラフ方式（ノートPCで使われているキーボードの方式）のキーボードを使いたくなってこのキーボードを使っています。
EnterキーとBSキーが大きいのでPutty/teratermなどのターミナルでの作業では非常に使いやすいです。

値段は大体4000円ぐらい。キータッチがちょっと硬いかなーという感じです。

CapsLockキーはレジストリエディタで書き換えてCtrlキーとして使っています。

Lenovo ThinkPad（2008年～2009年）

ThinkPad X60やX200を使っています。
キーボードそのものではないのですが、ノートPCをメインで使うときはほとんどThinkPadを使っています。

キータッチが独特で使い易いです。

東プレ Realforce 86キー（2009年～）

値段が20,000円（！）なのですが、無接点方式の最高に使い心地ががいいキーボードです。
タイプミスがほとんどなくなりました、すごいですこれ。

今後買いそうなもの

東プレのキーボードはかなり素晴らしいので、今後すぐに乗り換えは無いと思うのですが
以下2つは悩ましいです。

ThinkPlus USBトラベルキーボード

ThinkPadのキータッチがデスクトップでもそのまま使えるキーボードです。

Happy Hacking Keyboard Professional JP

カーソルキー付きのHHKです、相当使いやすそうな・・・・

mod_perl の起動時に startup.pl というスクリプトを読み込むことで、
初回ロード時に必要なモジュールをhttpdに取り込み、あらかじめコンパイルできるという機能があります。

mod_perlを利用している httpd.conf （Apacheの設定ファイル）に
以下のように記述します。

PerlRequire /path/to/startup.pl

「startup.pl」のファイル自体は例えばこのように記述できます。
perlを実行しますので、perlでかけることはほぼ何でも書けます。

use strict;
BEGIN {
   use Apache ();
}
use Apache::DBI ();
use DBI ();

また、自家製のperlモジュールをstartup.plで取り込む場合、
1つ1つ書いていくのも中々面倒ですし、メンテナンス性の面からも避けたいところです。

こういった、動的にモジュールが増えていく中でそれらをstartup.plに取り込めるようなスクリプトを
マツモブログさんが開発されています。

startup.plに書いておいた方が良い事。 （マツモブログ）

サイト用のモジュールのパッケージ名をベッタ～とstartup.plに書いてたんですが、
モジュールを追加したり、削除したりいくうちにstartup.plのメンテナンスが追いつ
かなくなってきました。こりゃいかんという事でもう一発で読み込んでしまおうという
事で次のように書いてます。　（マツモブログより引用）

File::Findを使ってディレクトリ内を調べ、*.pmファイルを requireする構造です。

この手法だと、いくらモジュールが増えても矛盾することなくstartup時にモジュールをロードできます。
激しく便利ですね。

是非お試し下さい。

関連リンク

• mod_perlで親プロセスとのCopy on Writeな共有メモリを増やす方法。
  startup.plでのモジュールを共用している状況を調べることができる「INCdiff.pm」がとても便利です。
• モジュールをuseした際のメモリ使用量(増加量)を調べてみる
  モジュールの記述方法によって、初回ロード時の取り込み方が変わるという比較です。こちらもとても便利です。

FedoraやCentOSの古いバージョンにはdiskcheckというツールがありまして、
ディスクの利用状況を監視し、設定した数値以上の利用量になるとアラートメールを出してくれるものです。

こちらのツールですが、yumやRPMが無く、CentOS2のSRPMしかありませんので、
SRPMからのインストールが必要になります。

以下、このツールの導入をモデルにした、SRPMをビルドし、CentOS5にインストールするチュートリアルです。

SRPMのインストールの流れ

SRPMは

• ソースを展開し（＝SRPMのインストール）
• そのソースを元にビルドし
• できたパッケージ（RPMファイルなど）をインストールする

という流れになります。

SRPMのダウンロード

SRPMをダウンロードします。
ディレクトリ名からして、CentOS2用でしょうか。

• http://ftp.yz.yamagata-u.ac.jp/pub/linux/centos/2.1/source/i386/SRPMS/diskcheck-1.1-1.src.rpm

 wget http://ftp.yz.yamagata-u.ac.jp/pub/linux/centos/2.1/source/i386/SRPMS/diskcheck-1.1-1.src.rpm

ソースを格納するディレクトリを作成

ソースをインストールするために格納用のディレクトリを作成します。
（既に存在するのであれば、作成は必要ありません）

今回は該当のディレクトリが無かったので作成します

# mkdir /usr/src/redhat

続いてSRPMファイルをインストールします。

# rpm -ivh diskcheck-1.1-1.src.rpm 

SPECファイルの修正

/usr/src/redhat 以下にインストールされるのですが
昔のSPECファイルは現在のものと書式が異なり、このままビルドしてもエラーが発生します。

/usr/src/redhat/SPECS/diskcheck.spec を修正します。
「Copyright」の部分を「License」に変更します。

vim /usr/src/redhat/SPECS/diskcheck.spec 

-- Copyright: GPL
++ License: GPL

rpmbuildの確認

CentOSにSRPMをBuildする「rpmbuild」がインストールされていなかったのでインストールします。

「rpmbuild」をインストールするためには「rpm-build」のパッケージが必要です。
※間に「-（ハイフン）」を必要とします

# yum install rpm-build

rpmのビルド

全て揃いましたので、diskcheckをインストールします。

# rpmbuild -ba /usr/src/redhat/SPECS/diskcheck.spec

完成したRPMパッケージをインストール

BuidされたのでRPMパッケージをインストールします。

# rpm -ivh /usr/src/redhat/RPMS/noarch/diskcheck-1.1-1.noarch.rpm

Preparing...                ########################################### [100%]
   1:diskcheck              ########################################### [100%]

以上でSRPMからのインストールが完了しました。

diskcheckについて

2つのファイルがインストールされました。

/etc/diskcheck.conf
/etc/cron.hourly/diskcheck

/etc/cron.hourly以下にインストールされ、
1時間おきにcronのタスクとして実行されます。（diskがチェックされます）

diskcheck.confの設定は以下のサイトで詳細が掲載されています（外部リンク）

• http://www.atmarkit.co.jp/flinux/rensai/linuxtips/737diskcheck.html

diskcheckはpythonで動作しています。perl版のdiskcheck.plはこのツールをperlに移植したものです。
（若干機能削減していますが・・・・）

サーバのディスク使用量は中々把握しづらく、MRTGやMuninなどでグラフ化して監視する方法などがあるのですが、
弊社では diskcheck.plというスクリプトを作成し、これを cronのジョブに登録しています。

• diskcheck.plのダウンロード
  • ソースコード

アラートメールの送信先、アラートの対象とするディスク使用量のしきい値（パーセント）、サーバ名を設定すると
しきい値以上の使用量になった場合、利用状況をメールで知らせてくれます。

アラートメールの例

hostname www01.example.com

/dev/mapper/VolGroup00-LogVol00 ( / ) is 2 % full -- 3.9G of 287G used, 269G remain

----
-- df result
----
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00  287G  3.9G  269G   2% /
/dev/hda1              99M   13M   82M  14% /boot

弊社ではこれをcronに登録していまして、1時間おきに動作し、ディスクの使用量をチェックしています。

cronの登録例

0 * * * * /usr/local/bin/diskcheck.pl > /dev/null 2>&1

または、同スクリプトを /etc/cron.hourly 以下に設置することでも同様に動作します。

お使いになってみてはいかがでしょうか。

ありんくTOPページをSledgeで作り直しました。

• http://www.alink.co.jp/

弊社ではWebアプリケーションを開発する際にはほとんどのケースでMVCをベースに開発しています。
Perlの場合はSledgeかCGI::Applicationが多いですが、今回はSledgeで書き換えて作り直しました。

今までが完全スタティックなHTML＋CGIでしたので、MVC（TT)に変更になり、かなり運用が楽になったと思います。

主な仕様（というか利用方法なのですが・・・）は以下の通りです。

SledgeをUTF8環境で利用するために、Bundle::Sledge::I18Nを利用しながら、諸々仕込んでいます。

CSS圧縮をしたかったのですが、圧縮後のCSSファイルがどうもうまく動かず・・・
再度調査してトライ＆エラーをしてみたいと思います。

文字コードをUTF8で作成していますので、Perlならではの「utf8フラグが有ったり無かったり・・・」周りで少々ハマりました。

また、FormValidator::Simpleがとても便利です。こちらのモジュールについては、別途Wikiにまとめたいと思います。

弊社ではメインのJSフレームワークとしてjQueryを利用しています。
なのですが、jQueryを選択するまでには、
Prototype.js、MooTools、YUIなど他のフレームワークの使用感や実行速度などを計測し
総合的にjQueryを選択するに至りました。

同じようなプログラムを違うフレームワーク間で速度を計測するのはなかなか面倒です。
全てのJSフレームワークで細かいプログラムを作らないといけないのですが
そのような面倒な手間をかけることなく、一気に計測してくれるツールが公開されています。

http://dante.dojotoolkit.org/taskspeed/

basic task test for frameworks.

との事ですので、自分のブラウザでの動作スピードを確認してみてはいかがでしょうか。

自分で試してみたところ、jQueryはおおよそのケースで速い部類に入っていましたので一安心です。
特にjQuery1.2.6よりもjQuery1.3.2の方が飛びぬけて速いケースもあったのが気になります。

（未だにjQuery1.2.6から移行できずにいます・・・早くしないと！）

jQueryプラグイン"easyStrValidate"

テキストフォームの入力文字数の制限を簡単にかけることができる、
jQuery用のeasyStrValidateプラグインをリリースしました。

• jQueryでテキストの入力文字数を制限する（ありんく tech-wiki）

easyStrValidateについて

文字数の入力制限をかけたいテキストフォーム・テキストエリアに対して適用することで、以下の機能を実装できます

• 文字を入力する都度アラートメッセージが動的に変化
• 文字数の大小を満たさない限り、submitボタンはdisable
• 文字数の大小を満たさない限り、form自体が送信できない

動作サンプル

• 別ウィンドウで開く場合はこちら

サンプルコード・ダウンロード

以下の様に書きます。この場合は「text」というIDのテキストフォームが対象になります

詳しくはこちらのドキュメントをご覧下さい

$('#text').easyStrValidate({
               maxLength : 20,
               messageID : 'valid_message'
});

• ダウンロードはこちらから。
• パラメータなどのオプションについてはこちら

詳しくはこちらのドキュメントをご覧下さい

• jQueryでテキストの入力文字数を制限する（ありんく tech-wiki）

memcachedをdaemontoolsから使うドキュメントを公開しています。

弊社ではキャッシュサーバとしてmemcachedをよく利用しています。

memcached公式ページ

memcachedとはデーモンがメモリーを確保し、その中に変数の情報を格納できる仕組みです。大変高速に動作し、Mixiでも採用されていたりと、非常に信頼性の高いキャッシュシステムです。

使い方はごくシンプルで、キーを元に値をセットします。
ファイルキャッシュではなく、メモリ上に値を持つので、オブジェクトをそのままセットできます。（シリアライズされません）

Memcachedのインストール

CentOS（Linux）とFreeBSDでインストールします

CentOS（Linux）

yumで一発でインストールです

# yum install memacached

デーモンを起動します

# service memcached start
Distributed memory caching (memcached) を起動中:           [  OK  ]

以下のようなプロセスが起動されると思います。

memcached -d -p 11211 -u nobody -c 1024 -m 64

memcachedに渡すオプションを変更する場合は

/etc/rc.d/init.d/memcached

を編集します

FreeBSD

/usr/ports/databases/memcached
sudo make install

※FreeBSD6系でしか試していませんが、多分他のバージョンでもports以下は同じディレクトリかと思います。

デーモンを監視するツール（daemontools）

service コマンドでの起動でも十分ではあるのですが

弊社ではMemcachedがストップするという状態を２，３度経験しまして、
慎重を期すために、以後はdaemontools経由でmemcachedを取り扱う事にしています。

Mixiの場合でもdaemonotoolsを使っているようでしてdaemontoolsでの起動スクリプト例があります。

※daemontoolsについては次回の記事で解説致します。

• ありんく tech-wikiでドキュメントを作成しています。

perlから使ってみる

perlから使うためにはCPANモジュールの「Cache::Memcached::Fast」をインストールします。

# perl -MCPAN -e 'install Cache::Memcached::Fast'

データのset、getをしてみます。

このプログラムを実行すると、きちんとmemcachedが起動している状態であれば

http://www.yahoo.co.jp

と表示されます。

PHPで試してみる

PHPではpeclライブラリの「php-pecl-memcache」をインストールします

# yum install php-pecl-memcache

string(32) "[GET CACHE ] http://www.php.net/"

と表示されれば成功です

Memcachedの使いどころ

実際のWebアプリケーションでは主にページのキャッシュ、DBの抽出結果のキャッシュなどに使われています。

次回のMemcachedの記事ではperl上でのDBの抽出結果のキャッシュの実装について書きたいと思います。

関連リンク

• memcached公式ページ
• ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」（YAPC::Asia 2006） Tokyo （外部リンク）
• 第5回　memcachedの運用と互換アプリケーション
  • トラフィックがすごいです、400Mとか平気で行ってます。
• memcached（株式会社フィードフォース技術チームのサイト）
  • memcachedの起動オプションが詳細に記載されています。

自作DOS/VによるPCサーバ

自作PCを使ってPCを組み、それにサーバ用のOSをインストールして、サーバとして利用する手法ですが
弊社ではごく一般的な手法としていまして、サーバ構築の際は1つの選択肢としています。

パーツ同士の相性のリスクや、アンチエイジングのテストが微妙というデメリットもありますが
個別に細かくカスタムできる点は大きな魅力です。

元々、PCパーツは値段が下がっていく傾向ですし、構築するタイミング（時期）により構成の仕様が大きく変わりますので
都度その時に合わせて性能・値段面でもベストな構成でサーバーを構築しています。

今回、ある案件で近々に自作DOS/VのPCサーバを構築する予定でして、サーバスペックや詳細情報などを定義する機会がありました。

以下がサーバに求める条件になります。

• 省スペース
• 静音性（ファンの動作音が小さい）
• メモリをたくさん積める
• メタルラック（スチールラック）の上にどんどん乗せていく。

2009年4月現在での費用対効果を考えた構成は以下になりました。

サーバースペック （2009年4月現在）

ケース、ケースファン、電源など

ケース

Thermaltake/サーマルティク LANBOX Lite(VF6000BWS)

「省スペース性」を求めるのですが、1Uハーフサーバなど、ラックマウント型の省スペース型のサーバはコストがかかります。
また資材を簡単に調達できる事や、配線周りのメンテナンス性も考えますと、管理が楽なキューブ型のMicro-ATXを選択しました。

このケースはサイドにメッシュ状の穴が開いており、ここからも吸気させることができます。
例えば価格コムでの同ケースに側面ファンをつけた例（その１）や同じように取り付けた例（その２）が大変参考になります。

電源

ENERMAX LIBERTY ELT400AWT-ECO

電源は効率のいいものを適当に選んでいます。
昔はseven teamをよく利用していましたが、最近はENERMAXかever greenを利用しています。
サーバ用ですのでビデオカードなどは使いませんので400Wの電源で十分です。

＜参考リンク＞
同ケースを利用した自作PC作成例

• 完成例-LANBOX Lite VF6000BWSを使用したPC

CPU

• Intel Core 2 Quad Q8200(2.33GHz)

サーバーのCPUとしてはCore2Quadが最適だと考えています。やはり、平行処理の能力はサーバとのCPUとして大変魅力です。
QuadCoreのSシリーズ（省電力バージョン）もリリースされていますが、まだまだ値段が高いのと、
Q8200（TDP95W）とQ8200s（TDP65W）では消費電力がほとんど変わらないという結果もでています。

比較的省電力で動作するQuadCoreとしては、Q8200がコスト面・性能面からみると現時点ではベストと判断しました。

尚、CPUファンは純正を利用しています。特に変更する理由が無かったためです。

マザーボード

• Gigabyte GA-EG41MF-S2H (Intel G35+ICH8 4スロット/最大8GB)

Micro-ATXのケースを選び、IntelのCPUを選んでいますので、まずMicro-ATXのIntelCPU対応のマザーの中から選んでいます。
Core2を選択していますので、更に「LGA775」（CPUをマザーに乗せる基盤の形）に対応したものになります。

それと、DIMMスロット（RAMをさせるスロット）は必ず4本付いているものを選びます。

メモリはDDR2-800を選択しています。
4本あれば2Gのメモリを4枚（計8G）さすことができます。

メモリはヒートシンクが付いているUMAXの2G-DDR2-800のメモリを4本刺します。

オンボードのNICがRealtek 8110SCですので、CentOSでは少々注意が必要です。
（CentOS5.1のインストール時に標準でドライバが付いておらず、別途インストールを必要としたケースがありました）

HDD、その他

HDDはSATA2で1TBを選んでいます。

SSDもよいのですが、未だにコストパフォーマンスが微妙なのと、MLCではコントローラの挙動がこれまた微妙な問題がありまだちょっと様子見です。

ざっとですが、以上のような構成で構築する予定です。

ネットワークを組む際に詳細を書きたいと思います。

＜参考リンク＞
自作PCでサーバを組むためのパーツ選び

DIVタグを使った段組ではCSSでカラムの回り込みを設定します。

この際に以下2カラム構成の場合、以下のようなHTMLを書いた場合

HTMLソースコード

以下のような表示になり、赤い枠で囲っている領域から「子DIVタグ：カラム1」「子DIVタグ：カラム2」がはみ出している状態になります。

ブラウザでの表示

※赤い枠線内に青い枠線のDIVを入れたいが、はみだしてしまっている。

このような書き方ですと、親DIVが高さを定義できず、子DIVがあふれてしまうという状態になります。

これは親DIV内の全ての子DIVタグがfloatのスタイル属性を持っており、CSSの仕様上なのですが親DIVが子DIVの高さを考慮した計算行わないために起こっている現象です。

子DIVにheightのスタイル属性を持たせることで、親DIVが考慮することもできるのですが、高さは動的に変わるケースも非常に多いため、毎回高さを計算することは現実的に難しいと思われます。

以上を踏まえて、実現したいことは以下になります。

floatのスタイル属性をもっている子DIVの高さを考慮して、親DIVの高さを動的に確保したい。

これを実現するために「clearfix」といわれる、CSSハックを使用します。

CSSハック

「CSSハック」とはInternetExplorer（IE）、FireFox、Safariなどブラウザによって実装されているレンダリングエンジンの違いや、ブラウザのバグを逆手にとって、それらの違いを利用した形でCSSを適用させるテクニックです。

clearfixはCSSハックの中でも代表的な手法で、多くのサイトで利用されているテクニックです。

書き方も色々あるのですが、弊社では以下の形を取っています。（最も一般的な形だと思います）

この記述をCSS内でクラスとして定義し、DIVの構成ではみ出してしまう親の要素に適用させます。

DIVによる2カラム構成にclearfixを適用

では、上記で定義したクラス「clearfix」を適用させます。

具体的には1行目のDIVタグに「class="clearfix"」を入れるだけです。

clearfixの記述を加えると、今まではみ出していた青い枠の2つの子DIVが親DIVに内包されるようになり、
これにより、DIVの中でDIVの段組を行った場合、親DIVからはみ出すということを防ぐことができるようになります。

普通のCSSデータですのでもちろん、外部からの読み込みで対応することもできます。

ブラウザでの表示状態

青い枠のDIVが赤い枠の親DIVに内包されています。

いかがでしょうか。
非常に簡単な方法ですのでぜひお試し下さい。

perlでのファイルの入出力の基本である、open->print->close までの
一連の流れをまとめてみました。

• open/closeを使ったファイル入出力 （ありんく tech-wiki）

ある条件（この場合は入力ファイルの先頭に「000000」が入っている場合）を満たす行は、
出力の対象から外すということをルール付けしています。

今年1月にjQuery1.3がリリースされてから約3ヶ月経過しました。

これまでのシステムでは jQuery1.2.6をメインとして利用していたのですが
そろそろ 1.3への移行を検討しないと・・・と考えています。

jQuery1.3の機能の中で特に目新しいのが「live events」という機能です。

live events概要

公式サイトのリリース（ http://docs.jquery.com/Release:jQuery_1.3 ）やjQuery日本語リファレンス内でも書かれているのですが、

live eventsとは、あらかじめ定義されたセレクタに対して動的に（リスナーとして）監視する設定を行い、ドキュメント全体で全てのイベント発生時にチェックします。そして、該当するエレメントが存在すれば登録したイベントを実行する機能です。

利用例

例えば、「onLoad後に JSで動的に生成されたHTML」と「静的なHTML」の中で同一クラスのエレメントが混在している場合

$('.classname').click(function(){ ... });

をonLoad時に行うと、「静的なHTML」にしかイベントが登録されません。
（onLoad後に「JSで動的に生成されたHTML」は生成されるためです。）

こういったケースで「JSで動的に生成されたHTML」にもイベントを登録させたい場合は

jQuery1.3では

$('.classname').live("click", function(){ ... });

という書き方で対応できます。

• live eventsのサンプルコードはこちらです。

関連リンク

下記のページで jQuery1.2から1.3への変更点について詳細に書かれています。

• jQuery1.3 リリース（jQuery日本語リファレンス）

※jQuery1.2.6までのjQueryをお使いの場合、livequery（jQueryプラグイン）を利用する事でも同様の効果を期待できます。

jQuery1.2.6以前の場合

上記と同じケースで jQuery1.2＋livequeryプラグインでのコードは以下になります。

$('.classname').livequery('click',function(){ ...});

livequeryの詳しい使い方はこちらです。

弊社では、自作パソコンのパーツを組み立て、開発・実験用のサーバを立てています。

全てのパーツを個別に買っているのですが、この際のTIPSを少しご紹介します。

※下記の情報は2009.04現在のもので、変動性のある情報です。

構成する際のポリシー

現在はコストパフォーマンスの点でIntel系が望ましいと判断しているため、以下Intel系を中心にして書いていきます。

CPU

まずはIntel系、AMD系に分かれると思います。

現在Intel系、AMD系のプラットフォームによる障壁は事実上存在せず、どちらも利用しています。

設置場所

オフィス内に設置するため、静音性も重視します。iDC用のサーバのような音が大きいものは避けます。

※PCパーツの組み合わせはトレンドが変化しやすいため、2009.04現在での動向を踏まえたケースになります。

マザーボード

フォームファクタはほぼ全てのケースでMicro-ATXを利用し、Intel純正のマザーボードを選んでいます。

また、DIMMスロットは4本が必須です。

最近ではCore2Duoを利用する場合、Intel DG33BUC（Intel G33+ICH9DH）、Core2Quadを利用する場合DG35ECをよく利用しています。

マザーボードのNICについて

マザーボード自体の性能はASUS、GIGABYTE、MSIなど主要メーカーでも全く変わらないのですが、NIC（LANなど）のインターフェースでハマりました。

IntelはIntel純正のNICを使っており、他メーカーはおおよそLeadTekのNICを使っています。
（Intelよりチップセット自体の料金が低い＝コストパフォーマンスが良いからだと思います。）

LeadTekのNICのドライバはLinuxではデフォルトでは対応しておらず、別途カーネルに組み込む必要があります。
また、FreeBSD7でのインストール時では、認識はするのですが時間が経つにつれてスループットが落ち、最終的に「NICの認識はするが、スループットが0」という悩ましい状態になりました。

Windowsではドライバの対応がされているのですが、Linux/FreeBSDでは微妙な状態にあります。
ですので、初期インストール時のトラブルや工数を最小限にするためにIntelの純正マザーを利用しています。

他チップセットについて

x33、x35チップ系はメモリの上限も8Gまであり、余力をもった設計ができます。

x31系はメモリの上限が2G/4Gなどが多く弊社のサーバで利用するメモリ上限に達してしまうため利用していません。

また、x41、x45以上のGPUがリッチなマザーボードはそもそもサーバでの利用にグラフィック機能は必要ありませんし、オンボードの機能が多く、余計な電力を消費するため対象外としています。

また、メモリを16G搭載できるAMDのマザーもありますので、メモリの利用量を目的にしてマザー・CPUを選択するのも全くアリだと思います。

CPU

一番気になる部分です、そして一番お金がかかりやすい部分でもあります。

最近ではCore 2 Quad Q8300（2.5GHz 4MB）を利用しています。

開発サーバは往々にして負荷をいきなり掛けたり、複数のプロジェクトを1つのサーバに同居させたりしています。
この際に複数プロジェクトのバッチ処理も1つのサーバで行うため大変な負荷が一気にかかる場合があります。
なので、瞬間的な処理速度ももちろんですが、同時平行処理の能力も大変重視します。

ですので、並行処理に強いQuadCoreを利用したいのですが、安くなったとはいえまだまだハイエンドのモデルは高いのが実情です。

一応現在の価格帯では安い部分に入り、且つ45nmで生産されている、Core 2 Quad Q8300（2.5GHz 4MB）を選択しています。

また、QuadCoreは消費電力が大きく（TDP95w）消費電力がより少ないs版（TDP65w）のQuadCoreも選択できるのであればよいかと思います。

※QuadCoreの省電力版（型番の最後に"s"がつくもの）は消費電力がCore2DuoのExxxxと同じため、サーバのCPUとしてはかなりオススメです。

ただこちらは同性能でも単価が高いので、予算との相談になるかと思います。

CPUファンは純正のものを利用しています。

メモリ

メモリはDDR2-800の2Gモジュールを利用しています。
メーカーはノーブランド（バルク）です。

これを搭載できる限界のスロット数（ほぼ4つ）に搭載し、
2Gx4=8Gのメモリを積んでいます。

DDR2のメモリは流通量も多く、品切れの可能性もあまりないため
すぐに購入できるスペックのものを選んでいます。

また、性能を最大限に利用するために、スロットに指すメモリは、なるべく同一製品の同時期に生産されたものを利用しています。

HDD（ハードディスク）

SATA2の1TB3.5インチを利用しています。

意外と開発環境のサーバはディスクを利用するということもあり
現在の主なHDDの最大容量を選択しています。
（WesternDigitalでは1.5TB、2TBのHDDも発売されていますが、単価が高いため現段階では見送っています。）

2.5インチはコストがかかるのと、ディスク容量も少ないため見送りました。

SSDも大変良いのですが、現実的に買える値段のMLCでは
ディスクのコントローラ自体にプチフリーズするという問題がある製品もあり、こちらが解決すれば導入すると思います。
SLCに関しては未だ値段が高いので導入は少々難しいと考えています。

PCケース

キューブ型ケースで、電源無しのものを利用しています。
メーカーは特にはないのですが、大きさをなるべく合わせるようにはしています。

キューブ型は省スペースな割りに12cmファンを搭載できるものが多く
静音で大排気量を持つファンを搭載できるものも多いです。

吸気側にファンが無いものも多いのですが、サーバとして利用するため
吸気側にも（大体8cm）ファンを付けています。

電源

電源は、SilverStoneかENERMAXを利用しています。どちらもメーカー自体に電源のラインナップ数が多く、選択肢が豊富なためです。

また、静音性も重視しますので、静かで効率的な電源であればどのメーカーでも構わないと思っています。

NIC

マザーにオンボードで乗っているNICとは別に、
PCI・PCIEで別売りされているインテルのNICを1つ指しています。

違うセグメントのIPアドレスも定義する場合や、PCルータとして使う場合もあるためです。

以上を踏まえて、サーバ1台を作るとしたら・・・・以下のようになります。

大体このような形で、ミドルスペックの開発サーバができるのではないでしょうか。

このPCにOSをインストールし、サーバとして機能させます。

※OSのインストールにつきましては別途記事を書く予定です。

掲示板やお問い合わせなど、フォームを使ったWebアプリケーションを作る機会は多々あるかと思います。

このようなWebアプリケーションでフォームの2重送信を防ぎたいというケースが多々ありまして、
jQueryで利用できるプラグインにしました。

• jQueryでsubmit（送信）ボタンの2度押しを禁止する
  • プラグイン（disableDoubleSubmit.js）のダウンロード

使い方

使い方は簡単です。
以下のようにFormを指定して、プラグインを実行すれば submitボタンの2重送信を防ぐことができるようになります。

$("form").disableDoubleSubmit(1000);

サンプルはこちら

詳しくはjQueryでsubmit（送信）ボタンの2度押しを禁止する（ありんく tech-wiki）をご覧下さい。

jQueryでラジオボタンを押した際に、動的にプルダウンが変わるというコードのサンプルです。

jQueryでプルダウンを動的に変更（サンプル）

フォームのCMSを開発する際によくあるケースですが、
選択されている親カテゴリによって、子カテゴリのプルダウンの項目を動的に変更したいときがあります。

こういう場合、jQueryでは以下のように書けます。

$("#team input[type=radio]").click(function(){
  var $pulldown = $("#pulldown");
  $pulldown.empty();
  $option_entries = new Array();
  $.each(team[this.id],function(i){
    $option_entries.push('<option value="' + i + '">' + this + '</option>');
  });
  $pulldown.append($option_entries.join());
});

本来は Optionオブジェクトを追加するような形で

$pulldown.append(new Option(html,value) );

という形が分かりやすいのですが、IE上では動作しません。

ですので、一旦 optionのHTMLを配列として受け取り
それを1つの文字列に束ねてプルダウンにappendする形を取っています。

詳しくはtech-wikiにまとめています、ご覧下さい。

関連リンク

• jQueryでプルダウンを動的に変更する（ありんく tech-wiki）
• jQueryでプルダウンを動的に変更（サンプル）

うるう年と"2月29日"の処理は非常に面倒です。
この面倒な部分の処理の時、よく使われるのが

$year % 4 == 0

なのですが、1900年などは実はうるう年ではなく、上記の条件では処理できない年があったりもします。

perlではDateTime、Time::Piece、Date::Simpleなど各種モジュールがあるのですが、
root（管理者権限）で操作できない環境ではperlモジュールをインストールできないため
自分の作業可能なディレクトリに設置して操作できるperlモジュールを利用します。

モジュールのインストールについてはこちら

• Date::Pcalcモジュールのインストール（ありんく tech-wiki）

※Date::PcalcはPurePerl（C言語などで構成されたXSモジュールに依存していない形態）なので
レンタルサーバなど、制限がある環境でも動作します。

このモジュールを利用したプログラムのサンプルコードが以下になります。

• Date::Pcalcを利用したうるう年の計算（ありんく tech-wiki）

CSSの圧縮と同様、JavaScriptも圧縮することができます。
ブラウザでのJSの実行速度が変わるので、特にIE6などの比較的レガシーなブラウザで
より効果を感じることができます。

• JS Minify!! (JavaSciprt圧縮ツール)

CSS Minify!!でもJSを圧縮することができなくもないのですが、CPANでアップされている、

JavaScript::Minifier::XSを利用して、JS用として改めて作ってみました。
使ってみて下さい。

• 参考リンク
  • CSS Minify!!（CSS圧縮ツール）

ClearSilverというテンプレートエンジンが存在します。
非常に高速に動作するテンプレートエンジンで、trac+mod_pythonなどでも使用されているらしいです。

mod_perl環境では、もっぱら Template-Toolkit か HTML::Templateなどがメジャーどころとして利用されてきましたが、ClearSilverを利用した超高速の処理は中々の魅力です。

ざっくりと比較すると下記のような感じでしょうか。
ClearSilverはセットできる内容・ルールがシンプルな分、高速に処理されます。

今回、特にSledgeから利用する部分をまとめてみました。

• Sledge上でのClearSilverについて（ありんく tech-wiki）

ClearSilver自体の文法やHDFの取り扱いなど、まだ調べきれていない部分がありますが、
随時追加していきたいと思います。

CSSの圧縮をコマンドラインで行っていたのですが、どうもわずらわしいことが多く、
Web上でCSSの圧縮ができるサービスを公開しました。

• CSS Minify!!

CSS Minfy!!で使っている、CSSファイル（css_minify.min.css）自体も
同サービスの「CSS Compressor(Java)」の方で圧縮したものを利用しています。

※CSSの圧縮についての詳細はCSSの圧縮と"CSS Compressorをご覧ください。

履歴

• 2009.03.25
  • 入力したCSSファイルと出力したCSSファイルの差分が分かるようにしました。
• 2009.03.30
  • JavaScriptを圧縮できる JS Minify!! をリリースしました。

Apache 1.3とmod_perl 1.30をCentOS(Linux)にインストールし、
mod_perlハンドラでWebアプリケーションが動作する環境を作ります。

まずは"Hello, World!"を表示させるというステップまで進みます。

mod_perl（モドパール）について

昔からWebアプリケーションの言語として利用されているPerlですが、「Perl=CGI（遅い）」という認識が未だに多く、
mod_perl（モドパール）の存在はあまりメジャーではないかもしれません。

しかし、安定性や速度の面でも非常に評価が高いモジュールで、大規模サイトでの運用でも利用されています。
例えばはてな、Mixi、livedoorではmod_perlで構築されたWebサイトのシステムが運用されています。

mod_perlは普通のCGIペースでのPerlプログラムとは、根本的な動作概念が異なります。

まず、初回のロードでソースコードを読み込んでコンパイルし、コンパイル状態のプログラムをメモリ上に保存します。

次回からはそのメモリ上に存在するプログラムを参照するので、
毎回ファイルからプログラムを解析して実行するインタプリタ方式のCGIに比べて高速に動作します。

サーバーの環境や、プログラムの動作にもよりますが、普通のCGIでの動作に比べて数倍～数十倍の速度で動作します。

Perl自体、元々20年近くもの歴史があり、モジュールも豊富です。CPAN（Perlモジュールをダウンロードできるサイト）からダウンロードし、様々なモジュールを利用する事ができます。
言語としても枯れており、安定して動作します。

mod_perlハンドラはCPANにアップされている様々なモジュールを利用し、高速なWebアプリケーションを作ることができます。

mod_perlのバージョンによる差異について

mod_perlはバージョンが1のものと、バージョンが2のものが存在します。

それぞれのバージョンでモジュールの名称が異なり、mod_perlハンドラ自体の互換性は事実上ありません。
今回はバージョン1（mod_perl 1.30）を対象としますが、追ってバージョン2系も追記する予定です。

話題性という面ではmod_php（PHP)や、mod_ruby（Ruby）に押されがちなmod_perlですが、使い勝手が非常に良いため、弊社ではメインの言語として利用しています。

Apache（Webサーバ）のインストール

Apache 1.3をソースコードからインストールします。

Linuxのrpm/yumでもApache（httpd）をインストールできますが、バージョンが2系になってしまうため、今回の対象であるApache 1.3はインストールできません。

Apacheの本家のサイト（httpd.apache.org）からApacheのソースコードをダウンロードします。

今回はmod_perl 1.30を利用する事が前提ですので、Apache 1.3を選択します。

Apacheのインストール

1. ページの左カラムの "Download!" という部分に"from a mirror"というリンクがあります。このリンクをクリックします。
   クリックするとダウンロード用のページに遷移します。

• ダウンロードページでは、地域に合わせて近しいと予想されたサーバがデフォルトで選択されています。
• HTTP経由でのダウンロードとFTP経由でのダウンロードがありますが、ダウンロードできるものであれば、内容は同じですのでどれを選択されてもかまいません。

1. ページ中部に "Apache 1.3.41 is also available" という部分があります。
   ここの下に "Unix Source: apache_1.3.41.tar.gzというリンクがあります。
   これを右クリックして "リンクのURLをコピー" (IEの場合は"ショートカットのコピー"）を選択し、ダウンロード用のURLをコピーします。

   ※Apache 1.3.41のバージョンの部分（41など）は今後マイナーチェンジされる都度変更になりますので、ご注意ください。

2. コピーしたURLを Putty、teratermなどのターミナルに貼り付けダウンロードします。
   ソースからインストールする際には"/usr/local/src"にソースコードを置くようにルール付けしていますので、ダウンロードする際には、そのディレクトリでダウンロードします。

   > cd /usr/local/src
   > wget http://ftp.riken.jp/net/apache/httpd/apache_1.3.41.tar.gz

3. ダウンロードしたファイルを解凍します。

   > tar xvzf apache_1.3.41.tar.gz

4. make（コンパイル）してインストールします。
   初期設定を決める"configure"を実行します。
   今回は、インストールする先はデフォルトの"/usr/local/apache"、Apache内部で利用するモジュールはとりあえずおおよそのものは一括でインストールします。

   > cd apache_1.3.41
   > ./configure --enable-shared=max --enable-module=all

   root（管理者）権限でインストールします

   # make install

   メッセージがずらずらと表示され続け・・・最後に以下が表示されればインストール完了です。

+--------------------------------------------------------+
| You now have successfully built and installed the      |
| Apache 1.3 HTTP server. To verify that Apache actually |
| works correctly you now should first check the         |
| (initially created or preserved) configuration files   |
|                                                        |
|   /usr/local/apache/conf/httpd.conf |
|                                                        |
| and then you should be able to immediately fire up     |
| Apache the first time by running:                      |
|                                                        |
|   /usr/local/apache/bin/apachectl start
|                                                        |
| Thanks for using Apache.       The Apache Group        |
|                                http://www.apache.org/  |
+--------------------------------------------------------+

• 2009.04.29追記
  CentOS 4.4 i386の最小構成の状態へのApache1.3.41のインストールでは、yumで以下のインストールが必要でした。

  yum install gcc*
  yum install db4*
  yum install gdbm*

  また、configureのコマンドも若干変更になります。

  CLFAG=/usr/include/gdbm ./configure --enable-shared=max --enable-module=all

mod_perlのインストール

Apacheで利用するための、mod_perlモジュールをダウンロードします。

Apacheのソースコードをダウンロードしたディレクトリと同じディレクトリ（/usr/local/src）で行います。

ダウンロード後に解凍します。

> cd /usr/local/src
> wget http://perl.apache.org/dist/mod_perl-1.0-current.tar.gz
> tar xvzf mod_perl-1.0-current.tar.gz

作成されたディレクトリ内でmod_perlをコンパイルし、ApacheモジュールのDSOライブラリとしてインストールします。

> perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/apache/bin/apxs EVERYTHING=1

root（管理者権限）でインストールします

# make install clean

Apache上でmod_perlの動作を確認

インストールしたApacheの上でmod_perlが正常に動作するかチェックします。

Apacheの設定情報（httpd.conf）の確認・変更、mod_perlのステータスをチェックする設定を行います。

Apacheの設定情報（httpd.conf）の確認・変更

Apacheをインストールしたディレクトリ（/usr/local/apache）以下に「conf」というディレクトリが存在します。

この中に「httpd.conf」という、Apacheの動作を定義するファイルがありますので、こちらを変更・修正します。

 > vim /usr/local/apache/conf/httpd.conf 

まず、mod_perlのモジュールがロードされる設定になっているか確認します。
以下の2つの設定が有効になっていればOKです。

ほとんどの場合、mod_perlのインストール後に自動で設定が上書きされているかと思いますので、特に修正しなくても良いかと思います。

　LoadModule perl_module libexec/libperl.so

　AddModule mod_perl.c

httpd.confの一番最後に以下の記述を追加します。
mod_perlの動作状況を確認するApache::Statusを動作させる設定を行います。

<Location /perl-status>
   SetHandler perl-script
   PerlHandler Apache::Status
   ORDER deny,allow
   deny FROM all
   allow FROM ＜自分のIPアドレス＞
</Location>

allow FROM は自分のIPアドレスを定義します。

3行目の「ORDER…」から、5行目の「allow FROM…」にかけては、閲覧制限の設定です。

この設定を行うことで、他者から不用意に閲覧されることを防ぎます。

自分のIPアドレスが分からない場合は診断くんなどで、表示されるIPアドレスを入力すれば良いかと思います。

上記設定を行い、httpd.confの保存後に Apacheを再起動します。

Apache上でmod_perlの動作を確認

Apacheを再起動させる前に、httpd.confが適切な文法で記述されているか、チェックします。

/usr/local/apache/bin/apachectl configtest
Syntax OK

"Syntax OK" が出ていれば設定情報の文法的な記述ミスはクリアできたのでOKです。

Apacheの再起動を行います。

 # /usr/local/apache/bin/apachectl stop
 # /usr/local/apache/bin/apachectl stop: httpd stopped
 # /usr/local/apache/bin/apachectl start
    /usr/local/apache/bin/apachectl restart: httpd started

「apachectl restart」について

※mod_perlはメモリ上にコンパイルしたデータを保存するため、apachectl restart での再起動では以前の情報を完全にクリアできません。

apachectl restart のコマンドでは rootで動いているApacheは再起動せず、子プロセスのみを再起動させます。
このためrootのプロセス上に残っているメモリはそのままの継続する状態になり、
mod_perlハンドラの変更箇所が反映されないという事になります。

きちんとメモリ上からクリアするために、上記のapacheの再起動では

apachectl stop → apachectl  start と2回コマンドを実行させています。

実際の運用では、毎回2回コマンドを実行させるのも面倒ですので、

以下のようなシェルを作成し

 # /usr/local/apache/bin/apachectl-restart

と打つことで、Stop->Startの2回実行させるようにしています。

#!/bin/sh
 /usr/local/apache/bin/apachectl stop
 /bin/sleep 5;
 /usr/local/apache/bin/apachectl start

CSSファイルは圧縮することができます。改行コードやコメント・無駄なインデントなどを削除し、必要最小限の状態にすることを圧縮と呼んでいます。

2009.03.25 CSSの圧縮を行うWebサービス「CSS Minify!!」を公開しました。

CSS圧縮には様々なメリットがあります。

• CSS圧縮とは？
• CSS Compressorのインストール
• CSS Compressorの実行
• perlでのCSS圧縮プログラム
• CSS圧縮の結果を比較
• Apache（httpd.conf）の設定例
• 結論

CSS圧縮とは？

CSS圧縮とはブラウザがCSSを読み込む時に生じる無駄な処理をなるべく少なくするために、記述方法をブラウザに対して最適化する事を指します。実際には改行コードやコメント・無駄なインデントなどを削除し、細かい部分での最適化を行っています。

CSS圧縮を行うことで、CSS自体のファイルサイズが小さくなるため、特に中規模～大規模なサイトではネットワーク帯域の節約を行うことができます。

また、ブラウザでのレンダリングスピードの向上も期待できるため、IEなどのレンダリングが遅いブラウザではサイトの描画速度の向上も期待できます。
（もちろんレンダリングが速いブラウザではより速くなります。）

ですので、小規模サイトから大規模サイトまで、CSSは圧縮した方が良いことが多く
弊社ではリリース時にCSSの圧縮を行い、プロダクション環境（本番環境）のCSSは圧縮した物を使っています。

これまではPerl/CPANモジュールのCSS::Minifierを使って圧縮していました。

なのですが、それ以上に効率的に圧縮するという、圧縮だけじゃない。CSSを解析した上で圧縮する「CSS Compressor」のブログを見て、早速ですがCSS Compressorを試してみました。

今回のCSS Compressorでは、YUIのCSS圧縮ツールをベースにして更に最適化されているので、現在利用しているPerlモジュールでの出力結果と比べてみました。

※CSS Compressorを利用するにはJava version 1.5/5.0 以降のJavaが必要です。詳しくはJavaのインストール、動作環境の構築をご覧下さい。

CSS Compressorのインストール

ユーティリティー系のツールは自分のホームディレクトリ内に"bin"ディレクトリを作って
そこにおくようにしていますので、今回も同様に行います。

> cd ~/bin
> mkdir css_compressor
> cd css_compressor

jarファイル（Java上で動く実行ファイル）をダウンロード

> wget http://www.andy-roberts.net/software/csscompressor/releases/1.0/CssCompressor-1.0.zip

zip圧縮されているのでunzipコマンドで解凍

> unzip CssCompressor-1.0.zip

解凍されたディレクトリ内にjarファイルが存在するかを確認

> cd CssCompressor-1.0
> ls
CssCompressor.jar LICENSE.txt README.txt lib

このCSSCompressor.jarをJavaから実行させます。
README.ｔｘｔに書いてありますが、実行形式、主なオプションは以下の通りです。

java -jar CssCompressor.jar [オプション] [入力するファイル]

使い方: java -jar CssCompressor-x.y.z.jar [オプション] [入力するファイル]
オプション
-h, –help 使い方を表示します
–charset 入力するファイルの文字コードを明示的にセットします。（例：utf-8）
–line-break 指定されたカラム番号の部分で改行を入れます
-v, –verbose 処理時にメッセージ、警告を表示します
-o 出力する先のファイル名を指定します（指定なしだと標準出力に表示します）

元ファイルの指定がない場合、標準入力を読み込みます

※フォント指定で、"MS P ゴシック"など、日本語の表記をCSSの設定内に入れていると思いますので必ず文字コードは指定してください。
（指定なしだとマルチバイト文字は"??????????"みたいに文字化けしてしまいます）

CSS Compressorの実行

インストールが終了したら、実際に圧縮してみます。今回は、このBlogのCSSファイル（styles-site.css）を圧縮します。

一応warningやnoticeがあった場合に表示されるよう、verboseオプションを指定しています。
また、UTF-8の文字コードですので、 –charsetオプションも指定しています。
ファイル本体の命名規則は ファイル名と拡張子の間に "min"を入れるようにルール付けしています。

java -jar ~/bin/CssCompressor-1.0/CssCompressor.jar –charset=utf-8 -o styles-site.min.css -v styles-site.css

これで、 styles-site.cssと同一ディレクトリにstyles-site.min.cssが出力されます。

この圧縮されたCSSファイルとPerlモジュールのCSS::Minifierで圧縮したCSSファイルを比較してみました。

perlでのCSS圧縮プログラム

CSS::Minifierを使ったPerlでの圧縮プログラムを以前から使っていました。プログラムのソースコードは以下になります。

#!/usr/local/bin/perl

use strict;
use warnings;
use CSS::Minifier qw(minify);

do_task(@ARGV);

sub do_task {
my $input_filename = shift;
my $output_filename = $input_filename;
$output_filename =~ s/.css/.min.css/;
open(INFILE, $input_filename) or die;
open(OUTFILE, '>'.$output_filename) or die;
minify(input => *INFILE, outfile => *OUTFILE);
close(INFILE);
close(OUTFILE);
}

このプログラムを実行し圧縮したCSSを作成します。

./css_minify.pl styles-site.css

CSSの圧縮結果

CSSをCSS Compressorで圧縮したもの、Perlモジュールで圧縮したもの、元のCSSファイルを比較してみました。

だいぶ違いますね。やはりCSS Compressorを使ったものが一番小さく最適化されるようです。

今後はPerlベースのモジュールではなく、CSS Compressorを使ってCSSを圧縮したいと思います。

Apache（httpd.conf）の設定例

弊社では、本番環境のサーバでは、"/css/" と "/css-min/"を同一階層に用意していて、それぞれ元のCSS、圧縮したCSSを同一のファイル名で保存しています。

この構造を利用して"/css/" へのアクセスがあった場合、サーバ内部の実体は"/css-min/"を参照させるようにrewriteしています。

RewriteRule ^/css/(.*)$ /path/to/css-min/$1 [L]

結論

上記の結果から、今後は CSS Compressorを使って、CSS圧縮かけたものを
本番環境で運用することが望ましいかと思います。

メリット・デメリットとして、以下が挙げられます。

　・ネットワーク帯域を節約できる
　・ブラウザのレンダリングスピードを向上できる

　・ファイル管理が複雑になる

”ファイル管理が複雑になる”という面は特に、本番環境と開発環境で物理的に違うCSSを参照するため、デプロイ時には注意する必要があります。

Java環境のインストールをしないと動かない面もありますが、環境さえ整えてしまえば非常にいい事ずくめなので、かなりお勧めです。

• CSS Minify!!（CSSの圧縮を行うWebサービス）
• Javaのインストール、動作環境の構築
• JavaScript::Minifier::XS（JavaScriptの圧縮について）

圧縮だけじゃない。CSSを解析した上で圧縮する「CSS Compressor」をインストールしたくて、Linux（CentOS）上で動作する、Javaの動作環境を構築しました。
以下インストール記録です。

Javaのライブラリをダウンロード

以下のURLから必要なライブラリをダウンロードします。
Java（JavaSE）のダウンロードページ

今回は "Java SE Development Kit (JDK) 6 Update 12 " を選択しました。

Java SE Development Kit (JDK) 6 Update 12

Java SE Development Kit (JDK) には、Java Runtime Environment (JRE) に加えて、
アプレットやアプリケーション開発に有用なコマンドライン開発ツールが含まれています。

とのことです。

この項目の右側の”ダウンロード”ボタンをクリックします。

ダウンロード画面で

I agree to the  Java SE Development Kit 6 License Agreement

をチェックしてプラットフォームのOSを選択します。

CentOS5を使っているのですが、普通の32Bit版(x86)と、64Bit版(x86_64)のどちらも運用しているので
Platform: のプルダウンでは

• Linux
• Linux x64
  の2つをそれぞれダウンロードしました。

wget(fetch)で、/usr/local/src にダウンロードし ls で確認します。

ls /usr/local/src/jdk*
jdk-6u12-linux-i586.bin  jdk-6u12-linux-x64.bin</blockquote>

Javaのインストール

通常のインストール（rpm無し）

rpmを実行し、インストールするため実行権限を追加します

chmod +x jdk-6u12-linux-*

管理者権限で 上記の実行属性をつけたバイナリファイルを実行します

sudo ./jdk-6u12-linux-i586.bin

※sudoコマンドが実行できない場合は
su root
# ./jdk-6u12-linux-i586.bin

上記のバイナリファイルを実行させると、数回の確認画面が続きます。
すべて Y（yes）を選択します。
↓

more(less)経由でライセンスに対する規約の同意画面が出てくるので、確認後に "q" でライセンス画面終了。
↓

その後に同意に対してのメッセージがでるので、同意する場合"yes"を選択。

Do you agree to the above license terms? [yes or no]
yes

インストール作業が続き、しばらくすると

Press Enter to continue.....
[ Enterキーを入力 ]

Done.

Doneでインストール完了です。

/usr/local/src/jdk1.6.0_12 に展開されているので /usr/local 以下に移動させました。

sudo mv ./jdk1.6.0_12 ../

※sudoコマンドが実行できない場合は
su root
sudo mv ./jdk1.6.0_12 ../

RPMを使ったJavaのインストール

RPM版は普通のバイナリよりも簡単にインストールできます。

Javaのダウンロードサイトから 先ほどのダウンロードページで” rpm.bin”で終わる同名のファイルをダウンロードし、
同様に実行属性を付け、実行します。

sudo ./jdk-6u12-linux-i586-rpm.bin

※sudoコマンドが実行できない場合は
su root

あとは同様に"yes"や"Enterの入力"を進めていけばインストール完了です。

Javaの実行環境の設定

JavaのPathを設定

zshを使用しているので、.zshrcに以下を追加します。

• 通常のインストール（RPM無し）の場合

  JAVA_HOME="/usr/local/jdk1.6.0_12"

• ※RPMでインストールした場合
  実ディレクトリはシンボリックリンクが張られますので /usr/java/latest というディレクトリに対してPathを通します。

JAVA_HOME="/usr/java/latest"

また、exportするPathを以下のように変更します。

• 変更前

  export PATH=$PATH:/usr/local/pgsql/bin

• 変更後
  ※"${JAVA_HOME}/bin"を先頭に追加しています。

  export PATH=${JAVA_HOME}/bin:$PATH:/usr/local/pgsql/bin

環境変数を読み直し、javaのPathが通っているか、確認します。

　source ~/.zshrc

　which java
　/usr/local/jdk1.6.0_12/bin/java

versionはインストールしたものになっているか確認します。

java -version
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode)</blockquote>

これでJavaの環境は一通り完了しました。

＜参考リンク＞

• J2SDKインストール・PATH設定

技術セミナーに行ってみました。
今までそういうのに行ったことが無かったので。

## —————– ##

2009.2.7（土） 15:00～ 18時半ぐらい
Webデベロッパの祭典＋ちょっとアキバ気分で。＠東京
http://www.pasonatech.co.jp/event/index.jsp?d=on&no=1215

観た内容は以下の3つ。
・Webエンジニアの視点 ～開発現場からの視点で～
・PHPの最新動向 －5.3の新機能を中心に－
・プログラミングの楽しさと仕事としてのプログラミング

弾さんとか高橋さんとかが出てた。

## —————– ##

＜Webエンジニアの視点 ～開発現場からの視点で～＞

日本Rubyの会会長の高橋さんのセッション
見事な高橋メソッドによるプレゼンテーションの資料でした。

htmlの取り扱いは、デザイナーだけかDEVも扱っていいかとか。
業務アプリはDEVもおｋ、コンシューマサイトはデザイナだけがいいんじゃないかしらというご意見でした。
→うーん、JSが隆盛を極めている昨今はコンシューマサイトでもCSSまでPG側で持った方がいい事が多そうな気もするが。

その後にはジョエル・スポルスキの"5つの世界"を紹介しつつ
独自定義の"4つの世界"という、ソフトウェアを開発

"5つの世界"とは
http://japanese.joelonsoftware.com/Articles/FiveWorlds.html

で、Webアプリを作る上で重要な概念を再認識されたのが以下の"4つの世界"。

自社開発と受託開発の2つに分け、それぞれ業務系アプリ、メディアに区分される。

"業務"とは、最初にガッチリ仕様を決めてxx日までにテスト→xx日にローンチとか全部が決まっているもの。スピードは決まった期間、予算はやや大めなイメージ。

"メディア"とはコンシューマ向けのサイト（一般サイト）で、不特定多数にWeb上でのサービスを提供するというもの。仕様や内容が恒常的に変わるのでXPでアジャイルっぽい進め方の方がマッチングするというもの。
スピードは速めのイメージ（なるはやとかがほとんどだがｗ）、予算はあまり無い方向。
"自社開発"はママね。

"受託開発"の業務では用件管理が難しく、特に業務系とメディア系ではお客さんの意識の持ち方（特にスピード感・予算感）が全然違うのでお客さんの意識にちゃんと合う形で提案をできる感じだとスムーズに行きますねという感じ。

完全にスピード感を優先するなら当然"自社開発"がよろしいんだが、常にリソースを抱え込むリスクを考えると、必要な時だけに確保すればよい"受託開発"もよろしいね。

ああそう意味では、現在の弊社のメイン業務は"D"の"受託開発のメディア"だなぁ、でも企画部分から含む案件も多いので"C"の性格もありつつなので何とも区分がむずいね。
DEVだけに限ってみるなら、リソースの掛かり方では
"C" == "D" >>>>>> "B" == "A"
かな。

あと、言語間の宗教論争では業務ORメディアのどちらを意識しているかで違う意見になりがちになり、すれ違いが生まれやすいとのこと。確かにそうね。

そのあとはWebアプリを作る上でのプログラムの言語の変遷

～2000年頃 Perl/CGI ASP
～2005年頃 Java(Struts) PHP
2006年以降 Ruby(On Rails) あと各種Webアプリ用フレームワーク

というくくりで、特に2006年以降は業務系アプリとメディア系アプリが言語レベルでは融合しつつありますねという感じでした。

mod_perlには触れなかった感じでｗ

＜PHPの最新動向 －5.3の新機能を中心に－＞

ごめん、PHPあまりわからないのでアレなんですが
5.3のverUPでネームスペースができたり、クロージャができるようになったり、オブジェクトが動的にメソッドを実行させたり、JSみたいに動的に関数を作ったりするとか。

＜プログラミングの楽しさと仕事としてのプログラミング＞

遊びと仕事のプログラミングを分けていないパネラーの方がほとんどでした。

今年はちょっと気持ちに余裕を持ちつつ、お勉強しつつコミュニティーに参加したほうがよろしいよ。

その後はマックでちょっと雑談で解散。

一応proftpdのhookとして mod_exec をご紹介。
mod_exec
http://www.castaglia.org/proftpd/modules/mod_exec.html

地震速報とかはこれをhookにしたいなあ。

画像サーバがすごいことになってDiskIOがやたら増えてしまって
困るわけですよ。

で、Apache2.2使ってるのでmod_disk_cacheを使ってcacheさせてたんですが
内部のDiskにCacheされたDIRやらファイル群を定期的にお掃除するのが面倒で。

一応mod_mem_cacheを使ってみようかなとは思います。

• Apache 2.2でWebサイトをパフォーマンスアップ！ <- mod_mem_cacheの使い方が載ってる。

でもmod_mem_cacheは挙動が怪しいからなぁ。

• mod_disk_cache と mod_mem_cache のこと
• mod_mem_cache のはまりどころ？

もう少し調べよう。

• prototype.jsの本家にminifyがなかったのでminify版を作成しました。

JavaScript::Minifier::XSを使って作成します。

js_minify.pl <元のjsファイル>

と叩くと元のjsファイルと同じところにminifyされたjsファイルが（ファイル名.min.js）が出来上がる予定です。

ソースコードは以下になります。

#!/usr/local/bin/perl
use strict;
use warnings;
use JavaScript::Minifier::XS qw(minify);
use File::Basename;
use FileHandle;

do_task($ARGV[0]);

sub do_task {
my $filepath = shift || die "[ USAGE ] js_minify.pl ";
my $fh = FileHandle->new($filepath)
|| die "[ WARN ] file-open fail. $filepath";
my $content = join("",$fh->getlines);
my $minified_content = minify($content);
my $output_filepath = sprintf("%s/%s-min.js",dirname($filepath) || '.',basename($filepath,'.js'));
my $output_filehandle = FileHandle->new($output_filepath,'w')
|| die "[ WARN ] file-open fail. $output_filepath";
$output_filehandle->print($minified_content);
warn "[ WRITE ] seed file $filepath" . " output file $output_filepath";
}

minify結果

都合、ファイルサイズは大体3/4ぐらいに縮みました。

※JSのminifyは同モジュールを使ったJS Minify!!（JS圧縮ツール）がご利用いただけます。

関連リンク

• prototype.js の開発者向けメモ
• Prototype系ライブラリ サンプルプログラム
• prototype.js逆引きサンプル集

これは強烈に悩ましいな。

rc1なんだがYUI3。
http://developer.yahoo.com/yui/3/examples/dd/portal-drag_source.html

prototype.jsで安定してそうだけどメンテナンスしてなさそうな↓。
http://blog.xilinus.com/prototype-portal/test/index.html

ちなみに interface.js @jQueryでもできたんだが、
jQuery1.2.xに対応しとらんっぽいのでやめよう。

perlfuncに書いてあるとおり確かに

You can effect a sleep of 250 milliseconds this way:

select(undef, undef, undef, 0.25);

で、0.25秒のsleepになるそうです。

とりあえずSELECT時のSQLっぷりをみたいだけなので、

use base qw(Class::DBI);
.
.
.
__PACKAGE__->add_trigger(
select => sub {
my $self = shift;
$self->db_Main->trace(1);
},
);

これで DBI->traceな感じで。

TTのFilterで
Template::Plugin::Filter::VisualTruncateというのがリリースされた。　
長い文章などを途中で切ってくれるモジュール。

早速つかってみる。

[%- USE Filter.VisualTruncate 'euc-jp' -%]

としておいて、

[% body = '1234567890123456' %]
[% body | visual_truncate(10,'') | html %]

で、実行結果は当然

1234567890

全角文字だと

[% body = '０１２３４５６７８９' %]
[% body | visual_truncate(10,'') | html %]

で、実行結果は

０１２３４

ん？バイト数で計算してる？

もうちょっと調べてみる。

DBIx::Classでちょっと困った。

当然といえば当然なのだが、あるレコード結果をmemcachedなどのキャッシュに保存した場合、
belongs_toで定義したカラムが含まれ、それを参照するとエラーになる。

TTで

[% article.category.name %]

とかしたくても、articleとcategoryがbelongs_toの関係の場合
Memcache化（キャッシュを参照するとエラーる）できないので、もう少し調査してみる。

※belongs_toを使わないで、別schemaのresultsetを参照できればそれでもいいんだが。

大変役に立つ Sledge::Plugin::Validator ですが、

例えば数値などの入力で良くあるケースが

　・都道府県（1～47とか）をプルダウンで入力させたい
　・ラジオボタンなどで value が 0、1、2 のいずれかを選択させたい

などだと思います。

S::P::Validatorでマッチするようなのが見つけられなかったので
追加してみました、こんな感じですかね。

Sledge::Plugin::Validator::range

package Sledge::Plugin::Validator::range;

use strict;
use vars qw($VERSION);
$VERSION = '0.01';

sub load {
my $self = shift;
$self->set_function(
RANGE => &is_RANGE,
);
}

sub is_RANGE {
my $value = shift;
my $min = shift;
my $max = shift || $min;
if($value >= $min && $value <= $max) { return 1; }
return 0;
}

1;

で、Validator でこれを利用できるようにしておいて（Sledge/Plugin/Validator.pm の40行目辺り）

# チェック定義
#
$self->{valid} = Sledge::Plugin::Validator->new(
#LOAD_FUNCTION => [qw(default japanese)],
LOAD_FUNCTION => [qw(default japanese range)],
MESSAGE_FILE => eval {$self->create_config->validator_message_file},
);

で、Pagesクラスで以下のような書き方で。

sub valid_index {
my $self = shift;
$self->valid->check(
'pref_id' => [qw(NOT_NULL UINT), ['RANGE',1,47], ],
);

DBIx::Classをいじっているわけですが、
Class::DBIみたいに、パッケージに自分を生成するクラスメソッドを作りたかったんですよ。

こんな感じにしたい

$schema->resultset('Sample')->recent_entries;

DBIx::Class::ResultSetManagerでResultSetにメソッドを追加 の素晴らしい事例を見て納得、なるほど。

こんなのがテーブルにマッピングしたモジュールにあって、呼び出したらイテレータなどが返ってくるという感じ。↓

package Schema::Sample;

use base qw/DBIx::Class/;

__PACKAGE__->load_components(qw/
ResultSetManager
Core
/);
__PACKAGE__->table(’sample');
__PACKAGE__->add_columns(qw/id title body timestamp/);
__PACKAGE__->set_primary_key('id');

sub recent_entries : ResultSet {
my $class = shift;
return $class->search( undef, { order_by => [ qw/timestamp/ ] } );
}

で、resultsetから直接 recent_entries を実行できました。

Sledge::Plugin::Validatorです。

テンプレ側で function（NOT_NULL）とかを指定しなくても
現在Validチェックで引っかかっている何かしらのエラーの文言を返すメソッドがほしかった。

[% valid.error_message(valid_param) %]

とテンプレで書いておけば、適当なValidメッセージがかえってくるような。

で、Sledge::Plugin::Validator に以下のメソッドを追加。

sub error_message {
my $self = shift;
my $param = shift || return;
my @valid_key = %{ $self->{ERROR}->{$param} };
$self->get_error_message($param,uc($valid_key[0]));
}

あと Sledge::Plugin::Validator::range とかも作ってみたので
あとから書く予定。

search_literal
http://d.hatena.ne.jp/nekokak/20070118/1169108107

search_literal いいね。

$rs->search({id => { '>' => 5}},)

が

$rs->search_literal('id >= ?', 5)

非常にシンプル

Catalystみたいに stash に変数を突っ込める、Sledge::Plugin::Stashですが、自分とこのサーバではうまい事動かなかったので同ソースをちょっと修正。

/usr/local/lib/perl5/site_perl/5.8.8/Sledge/Plugin/Stash.pm

BEFORE_OUTPUT —> AFTER_DISPATCH に変更。

$pkg->add_trigger(
AFTER_DISPATCH => sub {
#BEFORE_OUTPUT => sub {
my $self = shift;
$self->tmpl->param( %{ $self->stash } );
}
);

ちなみにSledge::Plugin::BeforeOutputはこちらからcoできるみたいです

↓Class::TriggerとSledge::Plugin::BegforeOutputの組み合わせに注意
Sledge-Plugin-BeforeOutput で嵌る

Image::Magickで半透明な画像を乗せたくて、探してみるものの日本語Docsが中々見つからず。
結局公式Docsを参照して以下のやり方をみつけた。

use Image::Magick;

my $image = Image::Magick->new;
$image->Read('upopo.jpg');

my $image_base = Image::Magick->new;
$image_base->Read('image_base.jpg');

$image->Composite(image=>$image, compose=>'Dissolve', x=>0, y=>0,opacity=>'60%');

$image_base->Write('output_sample.jpg');

Compositeのオプションを追っていくと他にもいろいろありそうだ。

compose=>'Dissolve'とopacity=>'**%'の組み合わせにたどり着くのが長かった。
↓の画像のように透明な感じに乗せることができます。

お天気ページを作るとき、よくある日本地図の上にお天気アイコンが描画されているアレ。

livedoor 天気情報 とかにあるこの画像ですが、今までGIFをプロットして、透明部分（例えば＃FFFFFF）とかを定義して、その色だけを抜くような事をしてました。
なので、輪郭にアンチエイリアスがかからないで、ドットもくっきりはっきりで。

↓こんなんとかね。
晴れとか雲とかの周りの白い縁取りがギッチリみたいな。

今更感モリモリなんですが、PhotoShopでドロップシャドウのような半透明処理を行った画像でも（GIFじゃなく）PNGで保存しておけば半透明のまま綺麗にプロットできるという真実。

ImageMagickを使うコードは大体↓のような感じです。ほとんどが重ね合わせの用途ですな。

#!/usr/local/bin/perl

use Image::Magick;

$image = Image::Magick->new;
$image->Read(shift);

$over = Image::Magick->new;
$over->Read(shift);

$image->Composite(image=>$over, compose=>'Over', x=>100, y=>100);
$image->Write('outout.jpg');

ちゃんとする事にします。

PerlのautoloadとPHP5の__autoloadて全然違うんじゃ？と思いまして、
とりあえず@ITのPHP5関連記事などを参考にしつつ
PHP5のそれを試してみました。

Momo.php（読み込まれるクラス）

<?PHP

class Momo {

private $upopo;
public $muhoho = 'むほほ';

public function __construct() {
$this->upopo = 'うぽぽ';
}

public function upopo() {
return $this->upopo;
}
}

?>

Hoge.php（実行する側）

#!/usr/local/bin/php
<?PHP

function __autoload($class) {
if ( file_exists($class.'.php') ) {
include_once($class.'.php');
} else if ( file_exists($class.'.class.php') ) {
include_once($class.'.class.php');
}
}

function do_Task() {
$var = new Momo();
echo $var->upopo();
echo $var->muhoho;
}

do_Task();

?>

実行結果

Hoge.php
うぽぽむほほ

__autoload は動的にクラスファイルを include する用途が
ほとんどなんではないでしょうか。
というか、他の使い方ってあるんだろうか。

Perlのいわゆる「autoload」はPHPでは「__call」になってますね。

DB_DataObjectなどのORマッパー周りやMVCの
BaseClass辺りで便利に使えそうです。

Text::Trim の ltrim とか rtrimを使ってみました。

whitespaceをいい感じに削除してくれるので、validationを通過したデータなどを
DBに突っ込むときに便利です。

use Text::Trim;

Project::Data::BBS->create(
name => trim($q->param('name')),
body => trim($q->param('body')),
);

いい感じス

pearがインストールできんかった。

PHPがSafeModeになってたので、includeできるディレクトリに制限がかかってた。
FreeBSDのPortsでインストールした場合、 /usr/local/etc/php.ini の初期設定で SafeMode? = Onになっているので注意。

で、/usr/local/etc/php.ini を編集

– safe_mode = On
++ safe_mode = Off

ついでに pear upgrade-allをしようとしたらmemoryが足りんといわれたので

– memory_limit = 8M
++ memory_limit = 100M

で、一応解決した。

httpsな環境を作らないといかんようになったので、とりあえず勉強。

apacheでSSL環境を実現するための選択肢は

apache1.3 + Apache-SSL
apache1.3 + mod_ssl
apache2.x + mod_ssl

で、apache2.x系の方がインストールが簡単っぽかったので apache2.x + mod_ssl をセレクト。

Continue Reading ->

proftpdで一悶着。

外からconnectすると 認証時にもっさりなるんですが、
ローカルからconnectするといい感じにスパスパ繋がってたので調査。

proftpd.confのリファレンスを見ながらいい感じに設定。
↓
IdentLookupsがデフォルトでOnになってた。

– IdentLookups On
++ IdentLookups Off

IdentLookupsは以下の様な事をしとるらしい。

IdentLookups

Syntax: IdentLookups on|off
Default: IdentLookups on
Context: server config, <VirtualHost>, <Global>
Compatibility: 1.1.5 and later

普通、クライアントが proftpd に接続すると、リモートユーザ名を確認するために ident プロトコル(RFC1413)が使われます。これは IdentLookups directive によるコントロールを可能にします。

Offにして再起動。daemontoolsで起動させているので、該当プロセスをkillするだけ。

sudo kill ＜proftpdのプロセスID＞

で完了。

apache2.2.3をインストール。
2.2.x以降で使える mod_proxy-balancer をいつかいじる予定です。

configureの設定はとりあえず以下。

apache1.3ではインストールが面倒くさいmod_sslも一発で導入できてしまう。
例によって使いそうなものはとりあえず全部インストール。

ちなみに

は無くなって

で、上手い具合にラッパしてくれている模様。

本日、2006年9月1日より株式会社ありんくに就職致しました。
がんばりますのでよろしくお願いします。