Grails 1.2 , 1.3 の GORM ドメインクラスでカラムのindexを作成出来ない件

Grails 1.2 , 1.3 の GORM ドメインクラスでカラムのindexを作成出来ない。

公式リファレンスではドメインクラスでカラムのindexを作成できるはずなのだが、、
5.5.2.6 Database Indices

class Person {
  String firstName
  String address
  static mapping = {
      table 'people'
      version false
      id column:'person_id'
      firstName column:'First_Name', index:'Name_Idx'
      address column:'Address', index:'Name_Idx,Address_Index'
  }
}

う〜ん。本番環境に最初にデプロイしたときはcreateでDBにつなげて、それ以降のデプロイはupdateにすれば良いのかな。あとからindexの追加がしたければ手動でやるしかない。

以前の記事の訂正（2） MySQLのライセンス

修正とは言えないが、MySQLの商用ライセンスについて。
MySQLはGPLと商用のデュアルライセンスである。

以前の記事の訂正（1） Grails on GAE/J - NetBeansを使って

以前、

Grails on GAE/J - NetBeansを使って

って記事を書いて、

アプリケーションの停止と起動の問題、つまり、GAEのSpin Up/Down時のアプリケーションの停止を回避するのに、定期的にcronで自身のアプリケーションにアクセスすることにしました。

cron設定時は、再起動に伴う cron 実行の失敗も1日数回程度で済んでいたのですが、翌日以降、１日数回、数分〜数十分程度、Spin Up/Down時にアプリケーションが停止しているようです。頻度は日によって違うようです。

オブジェクト指向と個人差

これまで仕事したプログラマーの同僚にもC++よりCを好んで使う人、Perl 、PHPで開発をしているのにクラスを作ることを好まない人っていた。
オブジェクト指向が好きな私からは見ると、まるで石器時代の生活をしているように見えた。「この人はどうしてこんな便利ものを使わないんだ？」って。

私がオブジェクト指向が好き好んで使っている理由は、オブジェクト指向でない開発を行った場合、グローバル変数と関数の記述位置を上手く把握出来くなるからである。「あの変数ってどこに書いていたっけ？」ってことが良くあるし、スパゲッティーコードに陥りバグの修正に四苦八苦する。
私個人の傾向として「単純記憶」が苦手だ。それを補うために関連性を記憶の動機付けに利用する。"BAR"っていうグローバール変数をどこで書いたかを覚えておくより、"FooクラスのBarメンバー変数"って憶えていたほうが忘れずにすむし、より多く把握しておける。結果的にオブジェクト指向でプログラムの設計を行うようになる。プログラムの規模が拡大した場合、記憶力だけでは全体を把握出来ないので、思考力で対応している。

オブジェクト指向を好まない人って、どんなにソースコード長くてもファイルが多くても、グローバル変数と関数の記述位置を細かく把握していているみたいだ。なおかつバグも少ない。「単純記憶」が得意なんだと思う。

各々のプログラマーがオブジェクト指向を好むか好まないかは、単純な好き嫌いの問題だけでなく、「記憶力」や「思考力」の個人差も要因なので、オブジェクト指向を好まない人を単純に非難するのは良くないと思う。

ubuntu の「ファイアウォールの設定」が起動しない

多分X11かgnomeがディスプレイの利用を許可しない不具合。なぜかほかのシステム管理ツールは起動する。（Ubuntu 8.04）

$ sudo /usr/bin/python /usr/share/gufw/gufw.py

で起動する。

起動しない

あ、gufw ってパッケージをダウンロードして自分で入れたんだったな..

PHPのフレームワーク比較

PHPにはフレームワークがあって、大きく３つ、ZendFramework, symfony, CakePHPがある。
どれを使うかは悩ましい。

PHPフレームワークの機能比較 - PHPプロ！

ってページがあるのだが、２年以上経って状況が変わってきてるし、自分なりにPHPのフレームワーク比較してみた。

Flash と HTML5

Apple は HTML5 が Flash に代わりゆる技術と考えているようだ。


Apple - HTML5
http://www.apple.com/html5/


私の考えとして、Flash の開発ツールの値段は高い。だから HTML5 は歓迎だ。


プログラミングしていても単体の Flash Profesional だけでなく、結局 Adobe Crative Cuite を買うはめになる。グラフィックデータ効率よく Flash に取り込むには、Photoshop や Illustrartor が必須で、プログラマーの私でも作業効率の面で Flash Profesional 単体では辛くてCrative Cuiteを購入しなければならない。


Adobe Crative Cuite は20万以上して Microsoft の開発ツールに匹敵する高額な出費を強いられる。
大企業にいても開発部門でもコーディングを行う Flash Profesional と Flex 以外の購入申請は通りづらいし、個人や中小企業でも高額すぎてすぐには購入できない。なかなか満足出来る開発環境で Flash を使った開発が出来ないが現状だった。


HTML5 って言っても HTML には変わらないから、Ajax や CSS のテクニックの延長で、目新しさには欠けるけど。

でも、"Apple - HTML5" ってページ、Chrome じゃ開けんじゃないか！

Apache 2.2 と Tomcat mod_proxy_ajp で

Java のWebアプリのベンチマークテストをしようと思って、久々に Apache と Tomcat の連携をしてみた。サーバーOSには CentOS (RedHat) 5 を使うだろうから、Apache はバージョン 2.2 以降の使用を前提に考えた。

Apache バージョン 2.2 以降では、Tomcat との連携に mod_proxy_ajp を利用する。

mod_proxy_ajp って Apache 2.2 本体のソースに含まれていたんだぁ。mod_jk の時みたいに別途ソースコードが配布されているんだと思って、Apache プロジェクトのサイトで探してしまった。

mod_proxy 同様に Apache を ビルドするときに、configure オプションに追加して導入する。mod_proxy_ajp は Tomcat 自体はビルドの際にはいらない。

最近の Linux ディストリビューションではパッケージに含まれているので、そのまま入れてもよ良い。

これは便利だ。

旧日本軍と在日米軍 二大政党制とファシズム台頭の不安

安倍、鳩山。3年の間に二人の首相が米軍絡みの問題で辞めた。


話は変わるが、戦前の日本の内閣は軍部と意見が合わなくなると、陸軍大臣あるいは海軍大臣が辞任して、軍部は次の大臣を内閣に送らず、結果、総理を辞職に追い込めた。
軍部は首相を辞めさせる権限を持っており、その事が軍国主義の台頭、大日本帝国の滅亡につながってしまった。（軍部大臣現役武官制）


今は米軍がその権限を握っているようだ。インド洋自衛隊派遣、普天間基地移設、日本の世論が米軍の意図と反対に向かい出すと、政権を米軍と国民世論の板挟みにして、遂には首相を辞任に追い込む。つまりハラキリ。
日本人はハラキリに同情的なのをアメリカ人は知っている。首相が腹を切れば、吹き上がった反対世論は収束する。


現代においても、旧日本軍が米軍に変わっただけで、日本の政権の安否は軍に握られている。こんなことで日本は民主主義国家と言えるだろうか？しかも外国の軍の圧力だ。
こんな調子だと戦前みたいに、いつか日本はファシズムに支配されると思う。「独自戦力による防衛」は多くの日本人の希望であると思うが、強力な独裁者が出てこない限り、米軍を追い出して、憲法改正も解決して独自戦力による防衛までに進めることは出来ない。
実際、度重なる首相の辞任で、一部の日本人は独裁者の出現を期待している気がする。すでに地方では鹿児島の阿久根市のように独裁的な首長が出て来ている。


バブル後の日本の政治は、第一次大戦後の流れにどこか似ていて心配してしまう。
「歴史に学ぶ」ことが大切である。

PydevのDjango対応

最近（2010年６月時点）、EclipseのPythonプラグイン PydevがDjangoに対応して、新規プロジェクトの作成や "manage.py" でのコマンド実行が簡単に行えるようになった。


GAEでDjangoを試そうかと思っていたので、これはありがたい。

ScalaはHaskellっぽいJava

Scala ってどうもとっつきづらくて、サンプルソースを見ていて「この記号ってどういう意味よ？」って考え込んでしまう。Java っぽいけど Java とは別の思考が必要なのだ。

ふと思ったことは、「Scala って Haskell っぽい Java」なんだってこと。ネットを見ていいて、Scala に熱狂的な人を見かけるんだけど、そういう人って Haskell を触ってそれを気に入っていた人なのかなって思う。Haskell を実務で必要とする機会は皆無なのだけど、それが JVM 上で動くとなると、Scala に熱狂してしまうんだと思う。

確かに、Scala の Actor は魅力的で、Twitter が採用したのは納得できる。Twitter のようにメッセージ処理が主要な機能のシステムには良いが、小・中規模のWebアプリケーションにはActorのようなメッセージ処理は必要無い。

Scala は実務で採用しても開発メンバーの生産性が向上するまで数ヶ月はかかるはずだ。動的言語としては既に Ruby, Python, Groovy があるし、習熟度による生産性の問題を考えれば、そちらの方が良いと思う。

でも、Haskell 大好きな人たちからは、Scala はあまり好意的でも無いようだ。

「Haskell 大好きっ子から見ると Scala は気持ち悪いことこのうえない言語である」 http://madscientist.jp/~ikegami/diary/20080512.html

NetBeans で Maven ソースの文字コード

Scala と lift で開発していて気づいたこと。
NetBeans 6.8 だと標準で Maven プロジェクトを開くことが出来て便利だが、プロジェクトのデフォルトのソースコードの文字コードの指定の方法が分からなかった。ファイルを新規作成して保存するとShiftJISで保存され、コンパイルの際にエラーになった。
デフォルトのソースコードの文字コードを UTF-8 にしたかった。


プロジェクト -> [右クリック] プロパティー -> ソース

このダイアログで、「ソース/バイナリ形式」 のバージョンと「エンコーディング」の文字コードを指定出来る。ここで、何回「エンコーディング」を "windows-31j" から "UTF-8" にして「了解」ボタンを押しても、再度ダイアログを開くと元の「windows-31j」に戻ってしまう。


そこで、POMファイルの "maven-compiler-plugin" の記述を以下のようにしてみた。

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>2.0.2</version>
  <configuration>
    <encoding>utf-8</encoding>
    <source>1.6</source>
    <target>1.6</target>
  </configuration>
</plugin>

再度、ダイアログを開いてみてみると、ちゃんと、「ソース/バイナリ形式」が "1.6" に「エンコーディング」が "UTF-8" に変わっていた。


要はPOMファイルに従うということ。

アップル 時価総額でマイクロソフトを抜く

おお！


この前Google抜いたと思ったら、マイクロソフトも抜いちゃった。
Appleって株式時価総額で全米２位か。
まだ景気が良くないから他の会社が良くないのと、iPad 予想以上に売れちゃったせいか。


でも Mac ってそんなに普及してないんだけど。Mac OS X も使いやすいことだし、法人の購入も、もっと増えないかな。


米アップル株の時価総額、２０年ぶりＭＳ逆転
http://news.goo.ne.jp/article/yomiuri/business/20100527-567-OYT1T00552.html

アップル、株式時価総額でマイクロソフトを抜く
http://japan.cnet.com/news/biz/story/0,2000056020,20414086,00.htm

Java のスクリプト言語サポート

今更ながら、まとめ。

Java（JVM上）でスクリプト言語が動くのは Java SE 6 以降。

ただし、
・Ruby や Python は Java SE 6 以前から動作可能であった。
・Scala はコンパイルしてバイトコードにしてから実行するので、スクリプト言語サポートの機能を利用しているわけではない。
・JDKに組み込まれていて、すぐ使えるのは JavaScript（Rhino）だけ。

確認してみたら、Javaで動作するスクリプト言語って、かなり前からあったんだな。


安藤幸央のランダウン これは使える！Java風スクリプト
http://www.atmarkit.co.jp/fjava/column/andoh/andoh10.html

MySQLのライセンス

商用でのいかなる場合でも、グレーな気がする。
開発言語が何であれ、クライアントライブラリーやドライバーをアプリケーションに組み込んでいるので、商売で使ってる以上商用ライセンスが必要という解釈が出来る。


MySQL ライセンスで頭が痛い
http://d.hatena.ne.jp/kurosaka/20071214/p1

MySQLのラインセンスについて
http://oshiete.goo.ne.jp/qa/2530620.html?ans_count_asc=20

MySQL 商用ライセンス
http://www-jp.mysql.com/about/legal/licensing//commercial-license.html

MySQLが特に必要なければPostgreSQLで良いと思う。最近はVACUUMも自動で出来るし。
MySQLって手軽で軽いイメージがあってついつい使っちゃうけど、仕事で使う場合はエンタープライズ版の購入も視野に入れなきゃね。

Grailsプラグインのインストール時間が遅い

grails install-plugin hoge とかすると、公開されているプラグイン情報の読みに時間がかかり過ぎる。

grailsのバージョンは1.2.2

何とかならないかな。

GrailsアプリケーションとIDE

私はNetBeansとEclipseを場合によって使い分けている。
これまでJavaのアプリケーションの開発ではプロジェクト作成の際に、NetBeansではプロジェクトディレクトリーのなかに"nbproject"ディレクトリー、Eclipseの場合は".project"と".classpath"ファイルが出来て、プロジェクトの管理がされていた。
最近、Grailsでの開発をはじめて気がついたのだが、NetBeansでGrailsアプリケーションのプロジェクトを作成した場合、"nbproject"ディレクトリーが出来ていないのに気づいた。Eclipse(STS)ではこれまで同様に".project"と".classpath"ファイルが出来ている。
また、"grails create-app"コマンドでGrailsアプリケーションのプロジェクトを作成した場合も".project"と".classpath"ファイルが出来ている。内容もEclipseで作った時と同様。
ということは、同じプロジェクトディレクトリーをNetBeansとEclipse両方で開発出来るということ。メンバー間ででバージョン管理でプロジェクトを共有していて、各メンバーの好みでNetBeansもEclipseも使っているという場合に便利だ。

バイバイcygwin

職場で使うマシンはWindowsばかりだったのでcygwinにはお世話になった。cygwin無しではWindowsで仕事が出来なかったと言っても過言ではない。
特にPostgreSQLをWindows上で稼働させるにはcygwinはどうしても必要だった。CGIの開発もcygwin上のApacheとPerlを使えば、スクリプトの実行パスの記述を変えなくてもローカルマシンで動かせた。

PostgreSQLもMySQLもWin32ネイティブ版がリリースされて、cygwin上で実行するより高速で、何よりインストールが簡単なそちらを使うようになった。PostgreSQLもMySQLも、いつしかcygwinのsetup.exeでインストールしたり、ソースコードからビルドすることは無くなった。

Perlはシェルコマンドと連携させるちょっとしたスクリプトを書くことが多くてcygwinのPerlを最近までづっと使い続けてきたけど、DB連携のモジュール（DBD::Pg, DBD::mysql）のインストールがどうしても面倒になってActivePerlを入れてしまった。

スクリプト言語の実行環境、PerlもPHPもPythonもWin32ネイティブ版のほうが扱いやすくなった。
それにVMwarePlayerが普及して、本当のLAMP環境で開発したければ、仮想マシンでやれば良くなった。それに日本じゃまだまだだけど、GoogleやSunのような大手企業の開発者のあいだでも、仕事でもMacという人が増えた。MacはUNIXだからLAMP環境の導入が楽々。

そー言えば、cygwinはWindowsNT 4.0のころから使っているから、もう１０年以上になる。
そろそろcygwinも積極的に使う時代では無い。Win32ネイティブのLAMP環境、スクリプト言語の実行環境も充実した。VMwareも無料で使える。

cygwinで使いたい機能
・bash
・tailコマンドでログ表示。さらにsed, awkコマンドとの組み合わせ。
・sshとscp, rsync
・vim
・csv, subversion, gitをコマンドで使いたい時。

これだけはcygwinがいいけど、あとはどうでもいいいや。

CakePHPってRailsに比べたら

CakePHPってRailsに比べたら、やっぱ面倒。
開発時間は Rails : CakePHP = 1:1.5 って感じ。
素のPHPだとRailsの2倍以上開発時間がかかることに比べればましだけど。
コードを書いていて、CakePHPだと連想配列を介してオプション指定したり、モデルデータへのアクセスをしなきゃいけない点がネックになってしまう。
array('foo' => 'bar')って書いたり、data[foo][bar]って次元の深い配列書くの辛い...
せめて Ruby のように連想配列の引数が扱いやすければ良いのだけど、PHPだからあきらめるしかない。

redirect_to :controller => "user", :action => "home"

みたいにいかないかな。

クロージャーやMixinがPHPで使えればなあ...　クロージャーは PHP 5.3 から使えるか。
CakePHP の後継（Lithium）に期待！

もうPHPってイヤで仕方ないんだけど、仕事上使い続けるしかないんだね。
PHP へのフラストレーションがあってブログに書いてみた。

コンステレーション計画の馬鹿さ

ブッシュとNASAの幹部は60年代のアメ車（アポロ）とデロリアン（スペースシャトル）の技術を利用してプリウス（アレス）を作ろうとしていたようだ。
また自動車に例えて、最新のプリウスの技術（電子制御、フライバイワイア）でトラバント（低コストで頑丈なソユーズ）を作ろうとしても、そんなに安くは作れない。
コンステレーション計画の宇宙船は安物のアポロって感じで違和感があったけど、結局中止。

NetBeans 6.8 Mac でメニューのニーモニックキーを消したい

日本語Zipファイルをダウンロードしたのは良いものの、どう展開していいのか迷うのでメモ。
バージョン 6.8 に限らず他のバージョンでもやり方は同じなはず。

コンステレーション計画が中止

またかって感じ。
先月の話ですが、2010年2月4日、オバマ政権がコンステレーション計画の中止を発表。
コンステレーション計画 (Constellation program) とはスペースシャトルの後継機の開発と、さらには月・火星への有人旅行の実現のための計画。

Wikipedia
http://ja.wikipedia.org/wiki/コンステレーション計画

もともと、スペースシャトルの後継機として「ベンチャースター」開発計画があったが、2001年に中止されてしまった。（具体的にはX-33実験機の開発中止）

Grails on GAE/J - NetBeansを使って

ようやく動作確認が出来た。
Grails AppEngine plugin の英語の説明をよ〜く読めば出来るのだが、、正しく手順を踏むことが重要。

Grails AppEngine plugin の説明
http://www.grails.org/plugin/app-engine

これでようやく、Grails のアプリケーションを GAE/J で動かせる。

柔らかい言語

「動的言語」って良く使うけど、変数の動的型付けや、スクリプト言語であるか無いかで分類していいのだろうか。Mac, iPhone の Objective-C はガチなC言語がベースでコンパイル言語だけど、なんだか「柔らかい」。
反面、PHPは「動的言語」だけど、「固くて」肩がこって仕方ない。

プログラミングしていて感覚的には、

「柔らかい言語」 --- Ruby, JavaScript, Groovy, Perl, Objective-C
「固い言語」       --- C/C++, Java, PHP

って分けかたもいいのではないかな。

STS + Google Plugin for Eclipse で Groovy on GAE/J

Eclipse で Groovy, Grails を扱う場合、素の Eclipse に Groovy-Eclips プラグインを入れるより、STS (SpringSource Tool Suite) を別途導入したほうが、Grails もすんなり使えて便利だ。
また、Google App Engine (GAE) 向けのWebアプリケーションも Groovy, Grails で開発することで、Java (GAE/J) でも Python 以上の開発効率を期待できる。
ただ、Grails on GAE/J はもう少し Grails の "Grails AppEngine plugin", "GORM-JPA Plugin" や関連するプラグインの成熟を待って取り組んだほうが良いと思っている。

今回は、STS と Google Plugin for Eclipse を使って Groovy で GAE/J 向けのWebアプリケーション開発を試してみたのでみたので、その要点を以下にまとめている。

・STS
STSはプラグインではなく、単体で導入してみた。
http://www.springsource.com/products/sts

・Google Plugin for Eclipse
Google Plugin for Eclipse は STS にインストールした。
http://code.google.com/intl/ja/appengine/docs/java/tools/eclipse.html

・Groovy で GAE/J 向けのWebアプリケーション (Groovy on GAE/J)
CodeZine の記事を元に試してみた。
「GroovyとGoogle App Engineでアプリ開発」
http://codezine.jp/article/detail/4192

CodeZine の記事に従って試せばOKだけど、STS + Google Plugin for Eclipse の場合はもう少しすんなり開発ができる。

・GAE/J Webアプリケーション用のプロジェクトを Groovy 対応にする
Google Plugin の ボタンで GAE/J Webアプリケーション用のプロジェクトを作成したまでは良いが、これは Java のプロジェクトなので Groovy 対応にする。
STS には Java のプロジェクトを Groovy 対応にさせる機能があるので、これを利用する。
パケージエクスプローラーでプロジェクトを右クリックすると下のほうに、"Configure -> Convert to Groovy Project" と出るので、これを選択すれば良い。

CodeZine の記事のようにビルドスクリプトを実行しなくても、javaファイル同様に "src" ディレクトリ以下の groovyファイルが自動でコンパイルされるようになる。

・実行ライブラリに Goovy ランタイムライブラリーを追加
groovyファイルのコンパイルは可能だが、実行の際にクラスパスが Goovy ランタイムライブラリーに通っていないので、このままでは Groovy で記述したプログラムをローカル、サーバーで動作出来ない。
実行時のクラスパスは "war/WEB-INF/lib" ディレクトリ内のjarファイルをを参照するので、ここに Goovy ランタイムライブラリー をコピーする。
Goovy ランタイムライブラリーは Grails の "groovy-all-x.x.x.jar" を利用した。

↓コピー後

これで、Groovy で記述したプログラムをローカル、サーバーともに利用できるようになる。

・Groovlet, gsp での日本語
あと、Groovlet, gsp での日本語はそのままだと文字化けするので、"war/WEB-INF/appengine-web.xml" ファイルの "system-properties"に以下のようにプロパティーを追加。

もちろん、Groovlet, gsp の記述は UTF-8 で。
試してみたところ、日本語は問題無く表示出来ました。

DBD::Pg, DBD::mysql のビルドとインストール

Mac OS X にてソースコードからLAMP環境を構築する場合、Perl のDBD::Pg, DBD::mysql をインストールする時にいつも面倒なのでメモしておく。

PostgreSQL, MySQL ともにソースコードからビルドしてインストール。
Linuxディストリビューションのように PostgreSQL, MySQL が /usr 以下にそれぞれインストールされていれば CPAN経由で DBD::Pg, DBD::mysql のインストールが簡単に出来るが、それぞれ /usr/local/pgsql や /usr/local/mysql にインストールした場合はパスが当然通らないのでビルド出来ない。
そこで、ソースコードのアーカイブをダウンロードして、データベースサーバーのインストールされたパス指定したうえで、手動でビルド、インストールを行う。

・DBD::Pg
PostgreSQL は /usr/local/pgsql 以下にインストールしてある。
perl -MCPAN -e shell とかせずに、CPANのサイトから直接ソースコード (DBD-Pg-x.tar.gz) をダウンロードして、これをビルドする。
make の前に環境変数で PostgreSQL のインストールされたパスを指定する。

$ export POSTGRES_HOME=/usr/local/pgsql
$ perl Makefile.PL
$ make
$ make test
$ sudo make install

・DBD::mysql
DBD::mysql の場合は perl Makefile.PL を行う際にオプションを付けてパスの指定を行う。

$ perl Makefile.PL \
--libs="-L/usr/local/mysql/lib/mysql -lmysqlclient -lz -lm"  \
--cflags=-I/usr/local/mysql/include/mysql \
--mysql_config=/usr/local/mysql/bin/mysql_config
$ perl Makefile.PL
$ make

Mac OS X の場合、make test はうまくいかないので行わない。

$ sudo make install

make test しなかったので、CPAN の DBD::mysql のドキュメントにあるサンプルプログラムを実行して動作確認してみる。特に問題は起きない。

まとめてシンボリックリンク

いつも、開発環境として perl をインストールする際、ビルドの際に --configure.gnu prefix=/usr/local/perl として、/usr/local/perl 以下にperlの実行環境一式を入れる。
/usr/local 以下だと、perl をバージョンアップ したい時に「上書き」出来ても「差し替え」が出来ない。バージョンアップ（入れ直し）したい前に、ディレクトリ /usr/local/perl をリネームしておけば、古い環境を温存出来る。

ただ、実行ファイルのパス（$PATH）はデフォルトで /usr/local/bin は通るのだが、/usr/local/perl/bin にパスを追加するのはいちいち面倒だ。
/usr/local/perl/bin/* を /usr/local/bin 以下にまとめてシンボリックリンクを張りたい。

# ln -s ../perl/bin/*
とすると当然うまくいかないので、

# cd  /usr/local/bin
# find ../perl/bin -type f -print0 | xargs -0 -I % ln -s %
でうまくいく。
(xargs に -I オプションを付けるのは、Mac OS X が BSD系だから）
（Linux - Ubuntu でもうまくいく）

逆に、/usr/local/perl/bin 以下のファイルを参照するシンボリックリンクをまとめて削除したい場合、
# cd  /usr/local/bin
# find /usr/local/perl/bin -type f -print0 | xargs -0 basename | xargs rm
とすれば良い。
（Ubuntu では # find /usr/local/perl/bin -type f -exec basename {} \; | xargs rm ）

※find, xargs コマンドの連携方法はCodeZineのTipsを参考にした。
find／grep／xargsコマンドを使いこなす　業務で楽するためのUNIXテクニック集「検索」編
http://codezine.jp/article/detail/3279

Snow Lopard にて PHP 5.3.1 のインストール

Snow Lopard (Mac OS X 10.6) で PHP 5.3.1 をソースコードからビルドする際に問題がかなり多かった。
以下にそれへの対処方法があった。

・iconvの問題
http://blog.chibiegg.net/2009/11/13_22_432.htm

・resolvの問題
http://moudamekamoshirenai.g.hatena.ne.jp/onumerane/20090905/1252137013

・phpコマンド（cli）がなぜか"php.dSYM"になっているのでのでシンボリックリンクにする
$ cd /usr/local-x86_64/php-5.3.1/bin/
$ sudo ln -s php.dSYM php


実際にビルドしてみた環境とconfigureオプションは以下のとおり。

Apache 2.2.14
MySQL 5.1.42
PostgreSQL 5.3.1
GDは導入せず

$ export LIBS="-lresolv -liconv" ./configure --prefix=/usr/local-x86_64/php-5.3.1 --with-apxs2=/usr/local-x86_64/httpd/bin/apxs --enable-cli --with-zlib-dir=/usr --enable-exif --enable-ftp --enable-mbstring --enable-mbregex  --enable-sockets --with-iodbc=/usr --with-curl=/usr --with-openssl-dir=/usr --enable-soap --enable-ssqlite-utf8 --with-mysql=/usr/local-x86_64/mysql-5.1.42 --with-pgsql=/usr/local-x86_64/postgresql-8.44.2 --enable-pdo --with-pdo-sqlite=share --with-pdo-mysql=/usr/local-x86_64/mysql-5.1.42 --with-pdo-ppgsql=/usr/local-x86_64/postgresql-8.4.2 --with-iconv=/usr/local-x86_64

Snow Leopard でLAMP環境の構築（32bit-64bit の互換性）

Apache や PHP, MySQL, PostgreSQL はソースコードからビルドすると、Leopard までは32bitアプリケーションとしてビルドされていたが、Snow Leopard からは64bitアプリケーションになった。
Leopard の時にインストールした Apache(32bit) に対して、Snow Leopard にしてから新たにPHPなどのApacheモジュールをソースコードから組み込むと64bit用にコンパイルされてしまい動作しない。
また32bitのMySQL, PostgreSQLに対して、PHPをビルドしようとしても make の際にデータ型の互換性でエラーが出てビルド出来ない。

結論として、ソースコードからのLAMP環境の導入は Snow Leopard 上で一から行わないといけない。

開発環境としてはビルド時のconfigureの調整を行ったものを利用したいので、LAMP環境私はソースコードから導入しているが、、OSに組み込まれている Apache, PHPに関しては Leopard の頃から64bit化されており32bit-64bit の互換性で問題は起きにくい。

MySQL 5.1 で innodb も有効にしてビルド、インストール

Mac OS X のバイナリも配布されているが、これまでローカルマシンのLAMP環境はソースコードからビルドしていたので、今回もそうしてみる。

バージョン4 以降 innodb を有効にしてインストールするのに失敗していたが、MySQLでのトランザクションの検証には必須なので、再度 innodb 導入にチャレンジ。

・mysqlユーザー

以前からLAMP環境があったので既にmysqlユーザーは作成済み。

・MySQLホームページからダウンロード

http://dev.mysql.com/downloads/mysql/

ソースコードは"Generic Linux (Architecture Independent), Compressed TAR Archive"とある。Linuxでは無いけど、アーキテクチャーに依存しないっていうことか。

・展開してビルド

./configure --prefix=/usr/local-x86_64/mysql-5.1.42 --with-charset=utf8 --with-extra-charsets=complex --with-plugins=max --with-mysqld-user=mysql

v5.1以降、"--with-plugins=max" とすると innodbが利用出来る。

以前のバージョンでは "--with-innodb"や"--with-plugin-innobase" としていた。

(http://yossieworld.com/yossie/entry/mysql_5_1_34)

・make install

・設定ファイルのコピーと編集

開発用サーバーなので support-files/my-small.cnf を"インストールディレクトリ/lib"以下にコピー

$ sudo cp /usr/local-x86_64/src/mysql-5.1.42/support-files/my-small.cnf /usr/local-x86_64/mysql-5.1.42/lib/

$ sudo mv /usr/local-x86_64/mysql-5.1.42/lib/my-small.cnf /usr/local-x86_64/mysql-5.1.42/lib/my.cnf

DBのディレクトリも指定しておく

$ sudo vi /usr/local-x86_64/mysql-5.1.42/lib/my.cnf

[mysqld]

...

thread_stack = 128K

datadir = /usr/local-x86_64/mysql-5.1.42/var

...

・初期化

ここでもDBのディレクトリを指定しておく

# bin/mysql_install_db --datadir=/usr/local-x86_64/mysql/var --user=mysql

・起動と停止

必ずmysqlユーザーで行わないといけない。

sudo -u mysql /usr/local-x86_64/mysql/bin/mysqld_safe >/dev/null 2>&1 &

sudo -u mysql /usr/local-x86_64/mysql/bin/mysqladmin -uroot shutdown

innnodbのテーブルが作成可能になった！