１．まずはyumのリポジトリをいじる

# vi /etc/yum.repos.d/CentOS-Base.repo
--------------------
（Plusリポジトリをenabled=1にする）
additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplu
s
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4
priority=2
protect=1
--------------------


２．PHP4を消す

# yum remove php

３．PEAR（およびPHP）をバージョン指定してインストール

# yum install php-pear-1.4.11

４．php.iniを編集（してhttpdを再起動）

# vi /etc/php.ini
--------------------
（include_pathを設定＆有効化）
; UNIX: "/path1:/path2"
include_path = ".:/php/includes:/usr/share/pear"
--------------------
（memory_limitを増やす：少ないとImage_Graphインストール時にメモリ割り当てエラーになる）
;memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)
memory_limit = 32M ; Maximum amount of memory a script may consume (32MB)
--------------------
# service httpd restart

５．PHP-GDライブラリ、PEARライブラリをインストール

# yum install php-gd
# pear install --alldeps Image_Graph-alpha

６．PEAR_Info＆PhpDocumentorをインストール

# pear install --force --alldeps PEAR_Info
# pear install --alldeps phpdocumentor

本項は必須ではない。PEAR_InfoはPEAR版のphpinfo()のようなもの。PhpDocumentorはPHPソースのhtmlドキュメント化支援ツール。

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

For documentation on migration for PHP 4 to PHP 5, we would like to point you to our migration guide. There is additional information available in the PHP 5.0 to PHP 5.1 and PHP 5.1 to PHP 5.2 migration guides as well.

PHP 4 end of life announcement [13-Jul-2007]

　おい、おまいら！PHP5がリリースされてから3年もたって、PHP6もそろそろ準備ができてんのに、PHP4なんかメンテできっか！セキュリティ問題だけは2008/8/8まで対応してやっから、そのスキにとっととPHP5にしやがれ、とのこと。
（888は洒落だろうきっと）

　既に多くのblogで言及されている通り、これで喉にひっかかった魚の骨のように残存していたPHP4が一掃され、PHP5への移行がより進むであろうから、それはそれで前向きなことなのであろう。

　少し探した限りでは「ふざけんなゴルァ！」という激しい拒絶反応は見当たらない。（まあ拒絶したところでOSSでは「じゃおまえ自分で直せよソースやっから」で終わるのがオチなので、おこぼれをもらっている凡人は諦めるしかないわけだが）

　これを機に、レンタルサーバもPHP5標準装備の方向へ向かってくれるとうれしいが。（PHP4が根強く残る理由の１つは、レンタルサーバだと思う）

　じっさい自分が使っている限り、クラスまわりとXML関係はちょっと辛いけど、PHPの4から5は、移行しやすいほうだと思う。

　が、さすがに仕事で使っている場合は、一通り試験をしなければいけない（はず）なので、仕事が増える人達も多いだろうな。

　ソフトウェアを作ったり売ったりしている側から見ると、いままでは、サポート切れというのは「更改時期ですよ」ということを促すための販促イベントのひとつでもあったのだが、ここ最近では、Windows XP Homeのサポート期間が延長されたり、Visual Basic 6のサポート終了計画に100社以上から抗議があったり、Red Hat Enterprise Linuxもサポート期間を延長したりと、だんだん「システム屋の脅し文句にはのらねーぞ」というユーザの声を飲まざるを得ない状況が見え隠れしてきている。

　あえてソフトウェア開発屋の立場からいうと、サポート期間は短ければ短いほどよいわけだが、ユーザの立場から見れば、家を買ったけど建てた建築業者も売った不動産屋も面倒見てくれない状態になるわけで、ましてやソフトウェアというある意味「売った時点では未完成品かもしれない商品」を売りつけている以上は、一定期間、ユーザが運用できる状態を維持することも、それはそれで義務ではあるとは思ってるんだけど・・・結局は、お金の問題なんだよね。

　ソフトウェア開発を始める時点で、維持していくためのコスト算出と予算確保、こうしたサポート終了というリスクに対する取り決めを、だいたいにおいてしていることが少ないから・・・

　開発ベンダーとして、ユーザからいわれなくても、こうした「開発費用以外にかかるコスト」をふくめて提案できる能力が求められていると思う。

　そして、ユーザ企業側にも、システム概要設計レベルくらいはできて、ミドルウェアもふくめた主なツールの比較や、開発ベンダーが出してくる提案や見積の良し悪しをつっこめるくらいの人を置け、ということになるのだと思う。

　そういった意味で、最近は、ユーザ企業とソフトウェア開発屋にいる人材の配置がおかしい気がしてならない。もっとユーザ企業側に「業務も技術も分かる素養のある人（あえてSEとは呼ばない）」が移動すべきなんじゃあ・・・

　いずれにしても現状では、ユーザ側に「ソフトウェアは買ったその日から何年経っても同じように動きつづけるもの」という感覚があって、上記のような話が通じにくいことが多々ある。

　もしかすると会計上の扱い方（バージョンアップは修繕扱いなのか？固定資産増なのか？など）等も関係があるのかも知れないが、契約の内容と、締結過程にも問題があるのだろう。（双方における、説明と理解の欠如）

　ソフトウェアの契約に関しては、経済産業省も当然ながら問題意識はあって、ずいぶん前からガイドラインを出したりいろんなことをやってくれているが、そもそも開発と運用の契約が分かれていること自体を、ホントにそれでいいか考え直してみるべきかも、なんて思ったりもした・・・話が発散してきたので今日はこの辺で。

wp@ookawara.sakura.ne.jp宛で、メール表題に調べたい語句を1つ書いて本文なしメールを送ると、Wikipediaで調べた結果を返します。

日頃の生活のなかでも、ふとしたときに分からない言葉が出てきたりしますよね。その場でWeb（iモード）アクセスしてまで調べるほどの状況でもないし、かといって後で調べるかというと、そのまま忘れたり。

そんなときメールだと、ちょっとだけ送信までの手間が少ない＆後でオフラインで読めるので、便利かなと思いまして。

メモ代わりに携帯で自分宛メール送ったりする人もいるみたいなんで、そんなスタイルの使い方を想定しながら作りました。

Googleでも、メール表題にクエリー書いて送ると検索結果を返すメアドとかやってるみたいなんで、それなりにニーズがあると思われるサービス形態なのかな～と思います。

文字化けは、PEAR::Mailに渡す本文データの、改行の間隔が広すぎたみたいです。
それっぽいルールで改行を入れたことによって、だいたい解決したと思います。

あと、検索結果で返ってくるXMLの解析で、部分的にごっそり文章が落ちる鬼バグがあったんで修正しました。

ついでに、H2タグやH3タグの単語に番号をふって、それっぽく整形しました。

HTMLメール使えると、いろいろ装飾ができて、いいのかも知れないですね。でもシンプル勝負なんでとりあえず当面はテキストのままで。
（テキストだとリンクを表現できないのが苦しいが）

関連記事１：オンとオフの中間
関連記事２：メールで辞書：完成
関連記事３：メールでWikipedia：α版
関連記事４：メールで～

記事番号が100。よくまあ戯言を100件も書いたな～。目指せ200件！

wp@ookawara.sakura.ne.jp宛で、表題に調べたい語句を1つ書いて本文なしメールを送ると、Wikipediaで調べた結果を返します。

日頃の生活のなかでも、ふとしたときに分からない言葉が出てきたりしますよね。その場でWeb（iモード）アクセスしてまで調べるほどの状況でもないし、かといって後で調べるかというと、そのまま忘れたり。

そんなときメールだと、ちょっとだけ送信までの手間が少ない＆後でオフラインで読めるので、便利かなと思いまして。

メモ代わりに携帯で自分宛メール送ったりする人もいるみたいなんで、そんなスタイルの使い方を想定しながら作りました。

Wikipediaでは指定した語句に直接説明が紐付いておらず、類似語にリダイレクトされている場合がありますが、それも一応対応しました。

が、文字エンコードの問題があって、文字化けを起こしたりしています。追って調査。

関連記事１：オンとオフの中間
関連記事２：メールで辞書：完成

目的達成手段の1つである .mailfilter が利用者に開放されている、さくらインターネットのサーバーを使うことにした。
この際なので、今後、サービス自体についても、XREA.COMと比較などをしていこうと思う。

さて目的のスクリプトは、すんなりいくと思いきや、PHP5の環境で作ってしまったにも関わらず、さくらインターネットはPHP4しか使えず、http通信やらXML解析やらすべてPEARで書き直したり、さらにPEARで提供されるXML/TreeはUTF-8が通らないため、XML_Tree_Exを探してくるなど、それなりに紆余曲折して実現。

e2j@ookawara.sakura.ne.jp 宛に、タイトルに日本語の意味を知りたい英単語を半角スペース区切りで並べた本文なしメールを送ってもらうと、本文に意味が書かれたメールを返信します。

例外やエラーの処理など超甘ですが、よろしければご活用ください。

この辞書を提供してくれている会社、Wikipediaの検索サービスもあるので、辞書がよさげだったらそれも頑張ってみようかなあ。

というのも、携帯で辞書を引きたい時などは、けっこう電車（しかも地下鉄）移動中だったりするので、オフラインでクエリー入力して、常時接続ではないやり取りで結果を受け取れたら、小便利な気がしたので。

このようなオンとオフの中間みたいなところで、意外と便利サービスがほかにも考えられるかも。

で、辞書で試してみる。

イーストという会社が辞書Webサービスを非商用フリーで提供してくれちゃったりするので、メールSubjectに引きたい英単語をスペース区切りで書いてメールするとサーバー側で辞書を引いて結果をメール返信するゴミプロを作ってみた。

PEAR::Net_POP3とPEAR::Mailと以前作ったhttpクラスを使って2時間もあれば完成！だったのだが、定期受信監視手段でアテにしていたcron設定が、XREA.COMでは最短1時間おきらしいので、ほぼリアルタイムが実現できず！
しまった前提条件の確認を怠った。
（まあそれでもレンタルサーバでcronまで使えるのはありがたいことですが）

というわけで、一応、完成させるも、現在の環境では実用レベルの定期動作環境が作れず。
（Web-CGIで動かす版は作ったのだが、それならフツーに辞書サイト行けばいいじゃん、てことで本末転倒）

XREA.COMさまにはprocmailを使えるようにしてほしいな、と我侭をつぶやいてみる今日この頃。

JavaScript全開で、ERDができるスグレものだ。
こうして、どんどんWeb上で出来ることが増えていくんだね。

全てがWeb上で完結する日も、近いな。

半分「釣り」だよね？そうだよね？そうだって言ってお願い。

確かに「使える」けど「作りにくい」言語であることは認める。けど、それはみんな分かって使ってると思いたい。

やっぱり、これだけメジャー化して、レンタルサーバなんかにも絶対のっていて、おそらく多くの人がWebプログラミング事始めとして使う処理系なのに、PHP4,5がいつまでも併存してしまっている複雑な状況が、いろいろ困った事態をひきおこしているんだろうなあ。

今回は、

• 他人のアーカイブラインと友達ラインを見にいけるようにした
• 画像ファイルを自サーバ上に一旦キャッシュする。かつPEAR::Image_Transform(GD)で縮小する　・・・携帯なんでなるべくちっちゃく。ライン上の表示が2回目以降の人の画像はさらにちっちゃくする
• ついでに2回目以降表示された人はURLにもしない

なんてことをしてみる。このblogを動かしているサーバでPEARが動かせるようになったから試しにやってみた。
PEAR::Image_Transform(GD) 性能はどうだか知らないけど、お手軽さはMAX。結構すごいっす。

おまけ：いろいろテスト中に電車運行情報がTwitterされるサービス？を発見。こいつぁ便利だ。でもこれって文字数オーバーじゃない？
http://twitter.com/train_kanto

関連記事：Twitterモバイル「Mobitter」

彼らがつまずいていたところは、for文とif文を徹底的に教えてみてはどうかと提案した。
なぜなら、printはそういった一つの流れがあって始めて意味を成すものであって、単独でprintする意味というのは確かに理解できない部分もあるからです。

そこで気が付いたんですが、ホームページを作るというスキルが全くない人は、実はprintでつまずく事も無いんです。
彼らがprintを受け入れられない理由はそこにあったのではないかと思う。

感覚的には同感。面談で「PHP出来ます」という言葉をチェックせずに信じた時点で採用側の負けだとは思うが、程度の差こそあれ、昨今似たような境遇に陥ることはよくある。

しかし、こうした人のばあい、ifやfor以前に、まずそもそもプログラムが何故必要か？何のためにプログラムつくるの？ってところから教えるべきなのかも知れない。

事例にあがっている< ?php print "こんにちは";?>ってのは、C言語でいえばK&Rの有名な”Hello, world.”のノリだけど、要するにこれすなわち、プログラムとはなんぞや？ということは知っている前提で成り立つ「事始め」であるということか。

やっぱプログラミング初心者に対していきなりWeb系プログラミングってのは敷居が高いよ。まずはstdin/outを使った処理系でソートや検索のアルゴリズムから教えるのが良いと思う。急がば回れ。