2009年5 月1日  |  Written by matsumoto  |  under 未分類 Yahoo!ブックマークに登録    はてなブックマーク - キーボード変遷あれこれ

プログラマが一番さわるPCのデバイスはキーボードです。
キーボードは一旦気になり始めると凝ってしまうものでして、私も色々使ってみては他のキーボードといった具合に変遷を辿っています。

ということで、ここ4~5年で使ったキーボードと使用感です。

HP純正キーボード(2004年~2005年)

HPのPCを使っていましたので、まんま純正で付いてくるキーボードです。
キーストロークが短かったので、タイプが楽だった記憶があります。
いわゆる普通のメンブレン方式のキーボードですね。市場価格は1000円~3000円ぐらいでしょうか。
http://h10010.www1.hp.com/wwpc/jp/ja/sm/WF06c/A1-329290-69998-329254-329254-411044-411047.html

PFU Happy Hacking Keyboard Lite2 (白) (2006年~2007年)

有名なPFUのキーボードです。コンパクトなので非常に使いやすく、ずっと使っていました。
会社用と自宅用など白と黒を2つ買ってしまってます。

本当は無接点方式のProfessional 2が欲しかったのですが、高かったので(確か24,000円ぐらい)、廉価版のLite2にしました。

Lite2は6000円ぐらいなのですが、メンブレン方式なのでProfessional 2とは使用感が違います。
Professional 2はさすが値段の分だけあると思います。

英字配列のものを使っています。日本語/英語の切り替えが「alt+`」です。
キーボードの配列が日本語のものと若干違うので違和感がありますが、なれると英字配列も使い易いです。

白は会社用で使ってます。打ちすぎてもうキートップがツルツルです。
http://www.pfu.fujitsu.com/hhkeyboard/lite2/spec.html

PFU Happy Hacking Keyboard Lite2 (黒) (2006年~2007年)

黒は自宅用です。
白もそうなのですが、背面にUSBハブが付いているのですが、これが微妙に便利。

ノートPCのキーボードの上にこれを置いて使ったりしています。

http://www.pfu.fujitsu.com/hhkeyboard/lite2/spec.html

エレコム tk-up87mpbk (2008年~)

たまにいきなりパンタグラフ方式(ノートPCで使われているキーボードの方式)のキーボードを使いたくなってこのキーボードを使っています。
EnterキーとBSキーが大きいのでPutty/teratermなどのターミナルでの作業では非常に使いやすいです。

値段は大体4000円ぐらい。キータッチがちょっと硬いかなーという感じです。

CapsLockキーはレジストリエディタで書き換えてCtrlキーとして使っています。

http://www2.elecom.co.jp/peripheral/full-keyboard/tk-up87mp/

Lenovo ThinkPad(2008年~2009年)

ThinkPad X60やX200を使っています。
キーボードそのものではないのですが、ノートPCをメインで使うときはほとんどThinkPadを使っています。

キータッチが独特で使い易いです。

http://shopap.lenovo.com/SEUILibrary/controller/e/jpweb/LenovoPortal/ja_JP/catalog.workflow:category.details?current-catalog-id=3634951826AE4D3881BFFF1AC5FCD957&current-category-id=5F3D323E86B74590ADD714AAD4CB5F99

東プレ Realforce 86キー(2009年~)

値段が20,000円(!)なのですが、無接点方式の最高に使い心地ががいいキーボードです。
タイプミスがほとんどなくなりました、すごいですこれ。

http://www.topre.co.jp/products/comp/index.html

今後買いそうなもの

東プレのキーボードはかなり素晴らしいので、今後すぐに乗り換えは無いと思うのですが
以下2つは悩ましいです。

ThinkPlus USBトラベルキーボード

ThinkPadのキータッチがデスクトップでもそのまま使えるキーボードです。

http://www-06.ibm.com/jp/pc/option/obi/nob06/31p9514/31p9514a.shtml

Happy Hacking Keyboard Professional JP

カーソルキー付きのHHKです、相当使いやすそうな・・・・

http://www.pfu.fujitsu.com/hhkeyboard/lineup/pdkb420w.html

2009年5 月5日  |  Written by matsumoto  |  under FreeBSD Yahoo!ブックマークに登録    はてなブックマーク - FreeBSD7.2リリース

昨日(5月4日)にFreeBSD7.2がリリースされました。
RCが外れて、プロダクションリリースになったようです。

7.1が4月中旬だったので、えらくはやいバージョンアップです。

FreeBSD 7.2-RELEASE Announcement

昨年のいまごろ、丁度FreeBSD7.0をいじっていました。
最初からIntelNICを使っていれば良かったのですが
MBにオンボードのRealtekのNICにこだわってしまい、不具合で遭えなく撃沈しました。

FreeBSDに限らずCentOS(Linux)でもそうなのですが、
やはりNICはIntel製のものを使った方がベターです。
(ということはマザーもIntel製の方が安く上がったりするのですが・・・)

2009年5 月5日  |  Written by matsumoto  |  under CSS, JavaScript, web技術 Yahoo!ブックマークに登録    はてなブックマーク - YSlow2.0の使い方

YSlowとは

サイトの表示スピードをクライアントサイドでチェックできるYSlowの新バージョンの2.0がリリースされました。(4月30日)

Firefoxのプラグインとして簡単に使えます。Firefoxで、YSLOWのダウンロードサイトを開き、モジュールをダウンロード(Add-on)すれば簡単に利用できます。

ブラウザの右下に「YSlow x.xxxs」という表示が出ますので、これをダブルクリックすると詳細なツールを利用できるようになります。

サイトの体感速度をランク化したり、通常では分かりづらいキャッシュのかかり具合などを測定してくれます。

YSlow1.0からの変更点など

今回のバージョンアップでUIやYSlow自体のデザインが大きく変わっていますが、
大きなポイントはやはりGradeでのチェック項目の追加でしょうか。

追加項目

以下が新規に追加されたチェック項目です、見落としがちなところばかりですね。

  • Avoid CSS expressions

  • 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の間を行ったり来たりしています。
http://www.alink.co.jp/tech/blog/wp-content/uploads/2009/05/alink-grade.gif

コンポーネントのキャッシュ状況

expireヘッダなどを使ったキャッシュ状況や、gzipでの圧縮具合の概況を表示。おおよそキャッシュできているようです。
http://www.alink.co.jp/tech/blog/wp-content/uploads/2009/05/alink-statistics.gif

コンポーネントのダウンロード状況

Firebug本体にも同様の機能がありますが、こちらは更に詳細にチェックできます。
http://www.alink.co.jp/tech/blog/wp-content/uploads/2009/05/alink-components.gif

いかがでしょうか、非常に便利なツールですので、是非試してください。

2009年5 月6日  |  Written by matsumoto  |  under PHP, サーバー Yahoo!ブックマークに登録    はてなブックマーク - [memcached] PHPでmemcachedの稼働状況をチェック

memcachedの詳細な稼働状況を把握するためにはせいぜい

ps aux | grep memcached

などで、おおよそのメモリの使用量をチェックする程度しかしていませんでした。

PHPでmemcachedをいじるために色々調べ物をしていたのですが、
memcachedの稼働状況をチェックするのに便利なツールを見つけました。(去年のエントリだったんですね・・)

memcache.php stats like apc.php

apc.php(APCの稼動状況チェックツール)のように稼動状況を視覚化してくれるスクリプトです
GDモジュールがインストールされていると、さらにグラフ化までしてくれます。

設定など

※あらかじめmemcachedをインストールしておく必要があります。

memcache.php を設定します

Webから認証させて見るために、以下の部分のユーザー名・パスワードを設定します。

define('ADMIN_USERNAME','ANYUSERNAME');    // Admin Username
define('ADMIN_PASSWORD','ANYPASSWORD');    // Admin Password

以下の部分を対象とするホスト(localhostなど)とポート(11211など)に書き換えます

$MEMCACHE_SERVERS[] = 'mymemcache-server2:11211'; // add more as an array

サンプル

ご参考までに、弊社のあるサーバの稼働状況を出してみました。
http://www.alink.co.jp/tech/blog/wp-content/uploads/2009/05/memcache-php.gif

監視ツール系の1つとしていかがでしょうか。

参考リンク

memcache.phpのページ

APCについて

2009年5 月8日  |  Written by matsumoto  |  under PHP, Perl, サーバー Yahoo!ブックマークに登録    はてなブックマーク - UTF8とEUC-JPを1つのサーバで混在させるときは

細かいプロジェクトが積み重なってくると、プロジェクトによって色々な文字コードが混在する状況になりがちです。
ありがちなパターンなのですが、ちょっと昔のプロジェクトだと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の扱いについて

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

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

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

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

応募~書類選考

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

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

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

面接

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

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

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

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

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

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

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

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

Yahoo!の場合

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

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

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

など、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 は弊社でも採用している技術です。この技術の上に構築されているウェブフレームワークは

などがあります。

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

  • ModPerl::Registry (Apache 2.x用)
  • Apache::Registry(Apache 1.x用)

なども存在します。

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

楽天の場合

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

会員ページなどのコアな部分で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年5 月24日  |  Written by matsumoto  |  under Perl Yahoo!ブックマークに登録    はてなブックマーク - [perl] TTより5倍速い?テンプレートエンジン"Tenjin"を試す

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

弊社では通常は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.

との事なので 非常に興味が沸きます。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

#!/usr/bin/perl
use strict;

use utf8;
use Benchmark qw/timethese cmpthese/;
use Template;
use Template::Stash::ForceUTF8;
use Template::Provider::Encoding;
use Tenjin;
use Encode;

my $title = 'テンプレートエンジン・ベンチマーク測定';
my $entries = [
    { name => 'ヤフージャパン',   url => 'http://www.yahoo.co.jp/' },
    { name => 'ライブドア', url => 'http://www.livedoor.com/' },
    { name => 'ミクシィ',     url => 'http://mixi.jp/' },
    { name => 'はてな',   url => 'http://www.hatena.ne.jp' },
    { name => 'Goo',      url => 'http://www.goo.ne.jp' },
    { name => 'google',   url => 'http://www.google.co.jp/' },
    { name => 'youtube', url => 'http://www.youtube.com/' },
    { name => 'ニコニコ動画',     url => 'http://www.nicovideo.jp/' },
    { name => 'flickr',   url => 'http://www.flickr.com/' },
    { name => 'Delicious',      url => 'http://delicious.com/' },
];

my $bench = timethese(1000, {
    'TT' => sub {
        my $tt = Template->new({
            LOAD_TEMPLATES   => [ Template::Provider::Encoding->new({
                DEFAULT_ENCODING => 'utf-8',
                ABSOLUTE => 1,
                RELATIVE => 1,
                TRIM => 1,
            }) ],
            STASH => Template::Stash::ForceUTF8->new,
        });
        $tt->process('bench.tt', { title => $title, entries => $entries }, my $out);
    },
    'TT(Compiled)' => sub {
        my $tt = Template->new({
            LOAD_TEMPLATES   => [ Template::Provider::Encoding->new({
                DEFAULT_ENCODING => 'utf-8',
                ABSOLUTE => 1,
                RELATIVE => 1,
                TRIM => 1,
                COMPILE_EXT => '.ttc',
                COMPILE_DIR => './ttc',
            }) ],
            STASH => Template::Stash::ForceUTF8->new,
        });
        $tt->process('bench.tt', { title => $title, entries => $entries }, my $out);
    },
    'Tenjin(Compiled)' => sub {
        my $engine = new Tenjin::Engine();
        my $out = $engine->render('bench.plhtml', { title => $title, entries => $entries });
        $out = encode("utf8", $out);
    }
});
cmpthese($bench);

テンプレートは以下です

bench.tt (TT用)

[% title | html %]

<ul>
[% FOREACH e IN entries %]
<li><a href="[% e.url %]">[% e.name | html %]</a></li>
[% END # FOREACH %]
</ul>

<ul>
[% FOREACH e IN entries %]
<li><a href="[% e.url %]">[% e.name | html %]</a></li>
[% END # FOREACH %]
</ul>

<ul>
[% FOREACH e IN entries %]
<li><a href="[% e.url %]">[% e.name | html %]</a></li>
[% END # FOREACH %]
</ul>

[% title | html %]

bench.plhtml (Tenjin用)

[=$title=]

<ul>
<?pl foreach my $e (@$entries) { ?>
 <li><a href="[==$e->{url}=]">[=$e->{name}=]</a></li>
<?pl } ?>
</ul>

<ul>
<?pl foreach my $e (@$entries) { ?>
 <li><a href="[==$e->{url}=]">[=$e->{name}=]</a></li>
<?pl } ?>
</ul>

<ul>
<?pl foreach my $e (@$entries) { ?>
 <li><a href="[==$e->{url}=]">[=$e->{name}=]</a></li>
<?pl } ?>
</ul>

[=$title=]

ベンチマーク結果

上記スクリプトを実行した結果です。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倍以上のスピードが出ています。

Rate TT TT(Compiled) Tenjin(Compiled)
TT 110/s -53% -94%
TT(Compiled) 236/s 115% -86%
Tenjin(Compiled) 1613/s 1371% 582%

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

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

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

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

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

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

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

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

2009年5 月29日  |  Written by matsumoto  |  under web技術 Yahoo!ブックマークに登録    はてなブックマーク - 34歳になりました&抱負

私事ですが、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月にVer1.3が発表されました。当分は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から、コンサル、大規模サイト構築まで、おおよそのことはご相談頂ければ
回答差し上げる事ができます。

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

2009年5 月30日  |  Written by matsumoto  |  under モバイル Yahoo!ブックマークに登録    はてなブックマーク - tech-log モバイル版を公開しました。

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

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

を使っています。

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

QRコードはこちらです
http://www.alink.co.jp/images/qrcode/alink_tech_log.gif

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

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

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

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

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

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


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

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

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

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

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

仕込む資料

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

カンペを作る

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

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

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

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

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

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

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

システム構成例(PPT) ※クリックするとPPTがダウンロードできます
http://www.alink.co.jp/tech/blog/wp-content/uploads/2009/05/system_sample.ppt

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

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

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

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

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


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

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


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

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

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

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

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

まとめ

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

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

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

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

私はチーム・マイナス6%です