Fedora Core 4 + Perlな環境でMySQLを操る準備
はじめに
このエントリーでは、Fedora Core 4 + Perlな環境でMySQLを利用できるようにするための方法を説明します。
最近私は、はてなの開発者と同様に、アジャイルなWebアプリケーションの構築を可能とするMVCフレームワーク「Catalyst」に注目しています。CatalystではModelの所で、Perlにおける人気のO/RマッパーであるところのClass::DBIが登場します。ModleにClass::DBIを必ず使わなければならないというわけでは無いようですが、まずはClass::DBIを利用できるスキルを身に付けた方が良さそうです。
ともかく、PerlでMySQLが使えないと話しが進みませんので、今回PerlでMySQLが使えるように必要最小限の環境設定をしてみることにしました。
Fedora Core 4で遊ぶようになったきっかけ
最近、Redhat 9にid:jkondoさん作のText::Hatenaをインストールしようとしたのですが、Perlのバージョンが古くてインストールできませんでした。最新のPerlを別途インストールしてもよかったのですが、時間的にも厳しく面倒だったので、Fedora Core 4をインストールして、色々と遊んでみることにしました。Fedora Core 4にインストールされているPerlだと、Text::HatenaはCPANシェルですんなりインストールできました。Redhat 9だと、Perlのバージョンや各種ライブラリのバージョンの問題でうまくインストールできなかった多くのCPANモジュールが、Fedora Core 4では問題なく簡単にインストールできるみたいですね。
PerlでMySQLが使える環境にする
さてさて、CPANモジュールのインストールのトラブル率が激減したFedora Core 4の環境で、MySQLをインストールします。yumの設定がまだちゃんとできていないので、yumではなくRPMで手動インストールしました。
MySQLのダウンロードサイトからゲットしたRPMを、以下のようにインストールするだけでMySQLのインストールは完了です。ソースからmakeしていた頃が懐かしいです。RPMで一瞬にしてインストールできてしまうと、makeで苦しんでいた自分があほらしくなっちゃいますね。(笑
[ysano@fedora ~]$ sudo rpm -ivh MySQL-server-4.1.14-0.i386.rpm [ysano@fedora ~]$ sudo rpm -ivh MySQL-server-4.1.14-0.i386.rpm [ysano@fedora ~]$ sudo rpm -ivh MySQL-devel-4.1.14-0.i386.rpm
ここでMySQL-devel-4.1.14-0.i386.rpmをインストールしておくのがポイントです。これをインストールしておかないと、後でDBD::mysqlをCPANシェルからインストールしようとする時にうまくインストールできないので注意が必要です。MySQLのドライバをコンパイルするためには、MySQL-devel-4.1.14-0.i386.rpmでインストールされる各種C言語のヘッダーファイルと、ユーティリティープログラムが必須なようです。
さて、残るはDBD::mysqlのインストールです。以下のコマンドを打てば、問題無くインストールできました。
[ysano@fedora ~]$ sudo perl -MCPAN -e 'install DBD::mysql'
DBIでPerlからMySQLにクエリーを投げるテスト
無事、PerlでMySQLを利用するための環境が整いました。そこで実験としてPerlに標準インストールされている「DBI」を使ってMySQLにクエリーを投げるPerlスクリプトを書くことにしました。DBIを使えばデータベースをSQLで簡単に操作できます。
MySQLのrootユーザーのパスワードの変更は、まだ行っていないのでパスワードは空の状態です。実験として、データベースにはMySQLのインストール時に用意される「test」データベースを用いることにします。ちなみに、「test」データベースにある「testaa」テーブルのスキーマと、格納されているデータは以下の通りです。idが6と7の行が、「?」になっているのはなぜだかよくわかりません。。。
[ysano@fedora ~]$ mysql -u root test mysql> desc testaa; +-------+----------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+----------+------+-----+---------+-------+ | id | int(11) | | | 0 | | | name | char(64) | YES | | NULL | | +-------+----------+------+-----+---------+-------+ mysql> SELECT * FROM testaa; +----+---------------------+ | id | name | +----+---------------------+ | 1 | Alligator Descartes | | 3 | Jochen Wiedmann | | 2 | Tim Bunce | | 4 | Andreas Kg | | 5 | NULL | | 6 | ? | | 7 | ? | +----+---------------------+
[ysano@fedora perl]$ vi dbi.test.pl #!/usr/bin/perl -w use strict; use DBI; my $dbh = DBI->connect('dbi:mysql:test', 'root', '', { RaiseError => 1, }) or die DBI::errstr; my $sth = $dbh->prepare('SELECT * FROM testaa WHERE id < 5'); $sth->execute; print "id | name\n" . "-" x 30 . "\n"; while ( my @row = $sth->fetchrow_array ) { printf "%2d | %s\n", $row[0],$row[1]; } $dbh->disconnect;
このPerlスクリプトを実行すると、以下のような結果が得られます。
[ysano@fedora perl]$ ./dbi.test.pl id | name ------------------------------ 1 | Alligator Descartes 3 | Jochen Wiedmann 2 | Tim Bunce 4 | Andreas Kg
さいごに
ということで、Fedora Core 4 + Perlな環境でMySQLを操る準備ができました。これからは、時間がある時にClass::DBIのトレーニングをしていきたいと思っています。そしてCatalystの勉強も同時に行いながら、前からPerlで作ってみたかった「秘密のアプリ」を作ってみたいと思います。(ないしょです)
最近の はてなについて考えてみる
id:jkondoさんの「自分の頭で考える」のエントリーで紹介されていた「「日本版Googleを目指す」はてな近藤氏、Web広告研究会トークセッション」というページを見て、最近の はてなについて少し考えてみました。
「日本版Googleを目指す」と回答したのは近藤氏。今では世界企業となったGoogleだが、はてなの目指すGoogleとは何だろう。当初は少人数で開始したはてなだが、現在は14人とスタッフが増えつつある。同時に、これまでの5、6人であれば「今日はこれをやろう」と仕事を進められたが、現在は組織的に動かないと全員の仕事を把握することも難しくなりつつあるという。
「Googleは1,000人規模の大企業になっても、僕らがスゴイと思えるようなサービスを提供している。はてなには、大企業で好きなことができないからといった理由で集まった技術者もいるが、30〜50人ぐらいの規模になっても、アイデアがいろいろな人から絶え間なく生まれる環境を作りたい。そのためには、既存の大企業のような手法で組織化するのではなく、ユーザーに提供するサービスのつもりで仕組みを作っていく。」
はてなスタッフの増加で、はてな内での仕事の進め方が変わりつつあるようですね。スタッフが増加しても、確実にタスク管理や全員の仕事を把握できるような仕組み作りを真剣に考えていく必要があるように思います。現時点で「あしか」によるタスク管理が、まだうまく機能しているのか、ちょっと心配です。「あしか」は本当に少人数でのタスク管理には有利かもしれませんが、スタッフの増加で限界に近づきつつあるように思うのは私だけでしょうか?
最近のはてな技術発表会ではPerl::Criticで推奨されているコーディング作法を、はてなの開発者の中で順番に勉強されているようです。この流れから、それぞれの開発者のコーディングスタイルのばらつきを減らすことで、はてなの開発者が増えても、仕事がスムーズにできるようにしていこうという動きを感じます。この試みは結局、システムのメンテナンス性につながり、サービスの改善やトラブル発生時の対応の「アジャイルさ」を保ち続けるための重要な作戦の1つとなりそうですね。
記憶に新しいid:naoyaさんによるCatalystの実演からも、「アジャイルさ」というのが、最近のはてなの重要な課題になっている気がします。
はてなには、ユーザーオリエンテッドな視点を忘れずに、これからも大きくなっていってほしいですが、決して大企業病にはかからないことを願っています。大企業病にかかってしまうと、はてなに魅力を感じなくなってしまいます。これからのはてなの技術的動向に加えて、はてなの組織作りも目が離せませんね。