「動的言語」って良く使うけど、変数の動的型付けや、スクリプト言語であるか無いかで分類していいのだろうか。Mac, iPhone の Objective-C はガチなC言語がベースでコンパイル言語だけど、なんだか「柔らかい」。
反面、PHPは「動的言語」だけど、「固くて」肩がこって仕方ない。
プログラミングしていて感覚的には、
「柔らかい言語」 --- Ruby, JavaScript, Groovy, Perl, Objective-C
「固い言語」 --- C/C++, Java, PHP
って分けかたもいいのではないかな。
2010年2月16日火曜日
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 で。
試してみたところ、日本語は問題無く表示出来ました。
また、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 で。
試してみたところ、日本語は問題無く表示出来ました。
2010年2月9日火曜日
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 のドキュメントにあるサンプルプログラムを実行して動作確認してみる。特に問題は起きない。
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 のドキュメントにあるサンプルプログラムを実行して動作確認してみる。特に問題は起きない。
2010年2月6日土曜日
まとめてシンボリックリンク
いつも、開発環境として 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
/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
以下にそれへの対処方法があった。
・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 の互換性で問題は起きにくい。
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 の互換性で問題は起きにくい。
登録:
投稿 (Atom)