「動的言語」って良く使うけど、変数の動的型付けや、スクリプト言語であるか無いかで分類していいのだろうか。Mac, iPhone の Objective-C はガチなC言語がベースでコンパイル言語だけど、なんだか「柔らかい」。
反面、PHPは「動的言語」だけど、「固くて」肩がこって仕方ない。
プログラミングしていて感覚的には、
「柔らかい言語」 --- Ruby, JavaScript, Groovy, Perl, Objective-C
「固い言語」 --- C/C++, Java, PHP
って分けかたもいいのではないかな。
2010年2月20日土曜日
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 の

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 のドキュメントにあるサンプルプログラムを実行して動作確認してみる。特に問題は起きない。
ラベル:
LAMP,
MySQL,
Perl,
PostgreSQL
登録:
投稿 (Atom)