PHPはオワコンらしい

【悲報】PHPがオワコン化。求人オファー数も下降線 : IT速報
http://blog.livedoor.jp/itsoku/archives/40524242.html

人気プログラミング言語PHPはもはや過去の言語？今からやるってどうなの？ | WorkaHolic
http://story-is-king.com/programminglanguage-php

PHP、かつてWebで人気だった言語が下火になりつつある | ReadWrite［日本版］
http://readwrite.jp/develop/12295/


PHPは、私にとって長年泣かされてきたプログラミング言語なのですが、ようやくオンワンだそうです。
PHPをディスりたい気持ちは長年鬱積していたんですが、仕事でPHPを採用する際に「ソースが汚い」以外にこれと言って拒絶する理由がありませんでした。

しかし、ようやく拒絶する時が来たかなと思います。

スマホの普及、近い将来普及するIoTでは、バックエンド・サービス（APIサーバー）の開発と運用は必須ですが、PHPで開発されたWebアプリケーションはパフォーマンスの面で適格とは言えません。
バックエンド・サービスの開発、保守においてもWebフレームワークの採用が必須ですが、PHPでWebフレームワークを使うとかなりパフォーマンスが悪いです。また、PHPにはデファクト・スタンダードのWebフレームワークが未だに無く、乱立状態です。
新規でWebアプリケーションを開発するにあたって、PHPという選択肢はよろしくないかと思います。

XdebugとNetBeansの連携 〜 ライオンと山登り（2）

WordPressの動作確認で基本的なLAMP環境を構築しました。
プリインストールされてるPHPには既にXdebugが利用可能になっています。
前回設定した /etc/php.ini ファイル最後の方に以下のように記述します。

[xdebug]
zend_extension="/usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so"
xdebug.idekey="macgdbp"
xdebug.remote_enable=1

; Local Variables:
; tab-width: 4
; End:

xdebug.so のパスは確認してください。

/etc/php.ini.default
でコメントアウトされた記述を参考にしました。

phpinfo() の表示

XdebugはNetBeansから簡単に使えますね。デバッグボタン押すだけ。
ページ表示するたびにF5ボタンを押すのが面倒ですが、ちゃんとブレイクポイントで止まっています。

PHPの開発環境はここまで出来れば満足だな。

WordPress を動かすまで 〜 ライオンと山登り（1）

新しいMac（MBP Retina） にWeb開発の環境を整備しています。

最初気づいたのは、Mountain Lionには「Web共有」が無い。今となっては、いらない機能なので困りませんが。でもApacheはどこに？と思いましたが、ちゃんと入ってます。PHPも入ってます。

私はXAMPPもMacPortsも使わないのですが、それでもあとMySQLさえ入れればWordPressが動くはずです。

でもMySQLを入れてWordPressを動かすまでちょっとした「険しい道のり」に感じました。「頂はすぐそこ」なんですが、、

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

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

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

で起動する。

起動しない

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

PHPのフレームワーク比較

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

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

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

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 ディストリビューションではパッケージに含まれているので、そのまま入れてもよ良い。

これは便利だ。

PydevのDjango対応

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


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

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って手軽で軽いイメージがあってついつい使っちゃうけど、仕事で使う場合はエンタープライズ版の購入も視野に入れなきゃね。

バイバイ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がいいけど、あとはどうでもいいいや。

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のテーブルが作成可能になった！