とある５丁目で活動する還暦を過ぎたWebプログラマーの覚え書きです。それとかかってくる迷惑電話や、家業のアパート経営について。
最近経験した、人がプロジェクトを後退させていくことの例。
PHPでプログラムを使っているとPEARやPECLなどのライブラリを知らずして使っています。こんな機能があればということで探すと大抵は見つかります。
先日のプロジェクトの中で、アップロードするファイルの種類を判定する機能がお客様から要望されました。単純にPECL 拡張モジュール Fileinfoで実現すればいいかとテストプログラムを作成しました。これをプロジェクトを一次受けしている会社に提案。しかし、その会社のサーバー管理者から却下となりました。
理由は、サーバーに余計なライブラリをインストールしたくない（面倒のだけ？？）、もしもの場合誰が保証するか（もしものことは起こるか？？）、ということだそうです。いくら説得して説明してもダメ。
サーバー管理者からは、同じ機能を新しく作ればいいの一点張り。結局の所は、お客様に説明して、この機能はなしとなりました。
ライブラリの活用に関しては、この記事を参照のこと。
このページは xfy Blog Editor を利用して作成されました。
久しぶりにあまり使っていない（会社のデザイナーのVista PCですが）を起動したところ、ソフトウェアのアップデートを山ほどしなければいけません。
まずは、Windowsのアップデート。そういえばSP2のアップデートがWindowsUpdateからあがってこない。SP2は、マシンによって時間差なのでしょうか？ 終了したら再起動。
次に、アンチウィルスのアップデート。今回はデータに加えてプログラムも。ここでも再起動。
次に、AppleからiTuneのアップデートの報告。Safariもインストールされてしまいました。おそらく強制ではないかと思いますが、デフォルトはインストールにチェックがついているので、半強制的・・・。ここでも再起動。
いっそのこと、ついでにディスプレイドライバもアップデートしてしまえ～。
アップデートするたびに、再起動・・・。作業が始まるのはいつのことやら。
このページは xfy Blog Editor を利用して作成されました。
自作PC用に一番左のWindows11のパッケージを実際に購入しましたが、問題なくインストールできました。Windowsは使うPCの分だけ正しくライセンスを購入しましょう。
現在、OpenPNEを使った専門家向けのSNSサイトを開発しています。簡単に改造点を言うと、SNS部分はほぼOpenPNEの機能を使って、その上位に専門家が所属する団体でグルーピングするとものです。
OpenPNEのような大きなオープンソースのシステムの改造は普通に考えると難しいと思いますが、OpenPNEに限っていうとそんなに難しくはありません。
これは、OpenPNE独自のフレームワーク（こう言ってしまっていいのでしょうね）がシンプルな考え方（難しいことができないというのではなくて）に基づいているので、とても見通しがよいからです。
どのページがそのプログラムとテンプレートで構成されているかというのは、ページのパラメータをみれば一目瞭然です。ページの出力とその後の処理をきちんと分けられているので、フォーム－＞処理－＞結果表示という一般のWebアプリケーションの自然なフローが、ルールに乗っ取ったファイルの命名方法になっています。
同じオープンソースでもXOOPSとは大きな違い。XOOPSのモジュール改造はとても苦労します。
もし、OpenPNEを使ったサイトをお考えの方がいらっしゃったらご連絡ください。（最後は宣伝モードでした・・・。）
このページは xfy Blog Editor を利用して作成されました。
ポチップなんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。
このブログは、XOOPSのWordPressのモジュール版で動かしていましたが、このたび普通の（？）WordPressに移行しました。
理由は次の通りです。
インストールは簡単。データベースを用意して、設定情報を書いて、後はインストールプログラムを動かすだけ。ほんの5分ほど。
エントリの移行は、RSSファイルを出力して、WordPressのインポート機能で読み込む。読み込めないエントリがあったりで、多少面倒。でも、1時間の作業。
とりあえずテーマは公開されているテーマを設定しました。単純にヘッダにXOOPS側に戻るリンクを設定しただけ。
XOOPSのメインメニューを自動生成していましたが、モジュールではないのでブログのメニューが出てこないため、これをマルチメニューモジュールで作成しました。
問題は、新着エントリがXOOPS側に表示しない。これは、RSS系のモジュールをインストールすることで対応します。
ポチップなんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。
本日の朝、ユーザーからフリーゴルフのサーバーに接続できないとの連絡が入る。試しにゲームを立ち上げてつないでみると、やはりダメ。
データセンターのLAN内からPINGを打ってみると応答がある。サーバーの面倒を見ていただいている会社さんにデータセンターまで行っていただく。ディスクが異常で再起動ができないとのこと。最悪・・・。
サーバーを用意していただくことに。しかし、Windows2000Serverのインストールに手間取っているとのことで、復旧に時間がかかりそう。
仕方がないので、メンテナンスサーバーをゲームサーバーにすることに。ゲームサーバーのバックアップを展開して完了。しかし、あまりパワーのあるサーバーではないので、代替機を用意できたら交換しなくてはいけない。
お盆休み明けにトラブルとは、いいタイミングです。1日早ければ、帰省先からの対応になるところでした。
とても寒いデータセンターにサーバーを置いてあるので、暑さのせいではないとは思いますので、あとはサーバーの寿命でしょうか。
サーバープログラムのバックアップを取ってあって何よりでした。先週、そろそろサーバーの故障が怖いので、ローカルでゲームサーバーを立ててみようという話しがありましたので、これも何かの因縁でしょうか・・・。
このページは xfy Blog Editor?を利用して作成されました。
最近、開発案件が提案フェーズで立ち往生したり、設計フェーズで停滞したりで、新しいことを調べています。今は、CakePHPでの開発に注目。CakePHPはPHPのフレームワークの一つです。
たくさんPHPのフレームワークがあるのに、なぜCakePHPかというと、これから行っていくだろう案件には現実的であるということ。「Railsに冷める」というブログに書かれている方にの意見に納得。
私も、Ruby on Railsを調べて実際にチュートリアルを動かしてみました。すばらしい。しかし、Ruby on Railsには行かないなあというのは正直な感想。そもそもRuby on Railsが動く環境が、手軽に手に入らない。専用サーバーを借りる？ 社内にサーバーを立てる？ そこまで、サーバーの面倒は見られない。今サーバーをレンタルしている会社に相談するも、実績ないとか、サーバーに負荷かかるのでとかでRubyの対応の予定なし。
それでは、今までやってきたPHPのフレームワークを探すのも、ほとんどPHP５対応。現実のレンタルサーバー会社はPHP4なのですよ。まだまだ、PHP5には移行できていない。というわけで、今のお客様になりうる方々にサービスを提供するには、PHP4でも使えるCakePHPなのです。こうこうこういうフレームワークが使うので、こんなサーバーを用意してくださいねというような説明ができればいいのですが、これはおそらく無理。どんなフレームワークを使おうと、こちらの勝手。既にサーバーをお持ちのお客様には、サーバーを変えてもらうのは難しい。PHP4でしたら、ほとんどのレンタルサーバーでサポートされていますので。
青山オフィスで使っているPCのディスクが壊れました。電源を入れるとコンコンって変な音がしていますし、BIOSからもディスクが見えませんので、ハード的な故障でしょう。
データのバックは取っていませんが、たぶん大丈夫。必要なデータはPCのハードディスクには保存していません。メールもIMAPサーバーにありますし、重要なデータはGrooveのワークスペースにありますし、プログラムのソースはCVSかSubversionに入れていますので。それにMyDocumentもファイルサーバーの個人のフォルダに割り当てています。
以上のように、おそらく被害は無いかと思います（本当か？？？）。面倒なのは、Windowsを入れてパッチを当てること。これで半日は潰れるのでしょうね。あとは、必要なアプリケーションをインストールしていくのも面倒ですね。
これは年末のPCの大掃除をしろということなのでしょうか？？
ということで、アンドワークスサイトのライブカメラは更新できませんので、ごめんなさい。たぶん気にしている人はいなかと・・・。
最近、Webシステムのフレームワークとして話題になっているRuby on Rails。先週は、Ruby on Railsの解説本や、そのプログラム言語であるRubyの解説本を買い込んで、サンプルプログラムを打ち込みながら勉強しました。
言われているように、Ruby on Railsは開発工数が少なくなるというのも納得。テーブルの追加変更削除も簡単に実現できるのもよい。データベースが設定ファイルでモデルとリンクしているのもおもしろい。Rubyが綺麗にプログラムできるのもすばらしい。これで、次の案件でRuby on Railsを採用というところですが、しかし・・・。
Ruby on Railsを運用できるサーバー環境というのがないのです。アンドワークスでの案件は、レンタルサーバー（共用）で運用する小規模なWebシステムというのが多いです。なかなかそのようなところでRuby on Railsが運用できるところがないのです。今、アンドワークスで運用しているレンタルサーバー会社に聞いたところ、Ruby on Railsは重いのでダメ、専用サーバーでしたら何とかするよ。という回答でした。今更サーバー会社をRuby on Railsのために変更することも時間的にコスト的に難しいので断念しました。
新しい技術を習得して、案件に活かすことは、とても大きな賭けになります。本当は、どんどん新しいものを取り入れていかなければいけないのですが。
Ruby on Railsの思想を取り込んだPHPのフレームワークがあるということので、今度はこれを調べてみます。開発工数、コストを下げて、顧客が満足できる堅いシステムが提供できるのが一番いいのです。
本日、１件納品しました。ただし、売上的には大失敗でした。
去年の９月からの仕事。ずるずると長引きました。最初は会社案内のサイト。次にメールで注文を受け付け。最後にはフォームを使って受注処理。しかも、商品撮影までやってしまう大盤振る舞い。
再見積りもできずに、ページ辺りいくらの契約。結局プログラムの開発費も取れず、最後まで納品してしまいました。
プログラマの性というか、キチンと作ってしまうのですね。ちゃんとエラー処理からはじまって、入力チェック、商品追加はXMLファイルで・・・。
今回の反省点は、ユーザーの仕様追加と許してしまったことと、ページ数で見積りをしてしまったこと。プログラム開発が途中から出てきても、その見積り説明ができなかったこと、「予算がない」で押し切られたこと・・・・。今回は、反省ばかりです。
でも、今回のサイトは、ユーザーにとってはコストパフォーマンス大です。デザインもシステムも手抜きなしです。 
サポートしているオンラインゲームのフリーゴルフの掲示板が爆発しかけています。ユーザー同士のトラブル。事務局として、火消しに回る。
さて、その掲示板のプログラムの動きがおかしいので、プログラムを解析しました。ファイルの日付を見ると2002年作成。マイクロソフトのIISで動いているASP。しかも、開発元の韓国の会社の手によるもの。プログラムのコメントがハングルらしくて、文字化けしている。
まずは、すべてパラメータのチェックを行うように追加。これがないとセキュリティの大きな問題が。
改めて見直すと、何と致命的なバグが。致命的すぎてこのブログでは書けない・・・・。
あと、自分が書いた記事を編集しようとすると、違う掲示板の同じ記事No．が表示されてしまう。
なんで4年間もバグが見つからなかったか・・・。ユーザーの使い方としては、たまたまコードが実行されてなかったせいか？ 本当に運がいいかもしれません。
開発元では、あまりテストをしていないようですね。4年前のセキュリティレベルがそうしたものか。受け入れる日本側の問題ですが。
ひとまず、すべてプログラムを見直して対応しておきました。
