結構、海外のショッピングサイトで買い物する。
インポートブランドの服は海外のサイトだと日本より安く売ってるので、狙い目。
今年の夏のセールでJIL SANDERのアンコンジャケットをBrownsで、LUKE SIMONのチノパンをoki-niで買った。
どちらもイギリスのサイトだが、3-4日であっという間に届いた。
田舎に住んでた子供の頃、月刊のコロコロコミックが3日、週刊の少年ジャンプが1日、東京より発売が遅くて悔しかった。
地球が狭くなったと実感する。
今はTanner Goodsのベルトを買おうか思案中。
無印のメープルラテは旨いと思う。無印行ったら、たいてい買う。
| 内容 | 大手派遣会社仕事情報モバイルサイト開発 |
|---|---|
| 期間 | 2008年1月 – 2008年3月 |
| OS | Linux |
| 言語 | PHP |
| アプリ | Apache, Oracle |
| フレームワーク | 独自フレームワーク |
大手人材派遣会社のモバイルサイトがリニューアルするに当たって、システム開発を行いました。
この案件の主な特徴は以下です。
この仕事で苦労したのは、エンドのクライアントとのやり取りでした。
この案件は、派遣会社であるエンドのクライアントが某ウェブ制作会社に制作を委託し、その制作会社が自分にシステム開発を再委託した、という構図でした。
クライアントとの打ち合わせをするのがウェブ制作会社のディレクターだけなので要件が自分まで上手く伝わらないという問題もありましたが、より困ったのがシステム環境の違いでした。
自分にはクライアントが管理する本番環境へのアクセス権がありませんでした。
開発はウェブ制作会社の提供する開発環境がで行ったのですが、OSはLinuxで本番環境のSolarisと違いました。
DBはウェブ制作会社にOracleのライセンスがない為、開発向けエディションであるOracle XEを自分でインストールしました。
そうした開発環境の制限の為、DBの文字コードが開発DBはUTF8、本番DBはSJISになったのですが、文字コードの違いの吸収はウェブサーバやDBサーバの機能を利用すれば良いのでそのような設定方法をクライアントのエンジニアに示すのですが、コンプライアントが厳しいというか、率直に言ってこちらの説明が理解出来ないようで、そうしてもらえない。
仕方ないので、文字コードの違いの吸収はPHPレベルで解消しました（毎回文字コード変換処理が走るので無駄な負荷が発生します）。
それ以外にもウェブサーバ・DBサーバの設定を変える（現在どのような設定になってるか教えてもらう）依頼は基本的にNGなため、そうしなくても済むように工夫する必要がありました。
また、この案件はPHP4だったのですが、PHP4の標準Oracleモジュールは非常に不安定で頻繁にシステムエラーを起こす為（PCサイトではエラー発生してもブラウザはスルーするので見過ごされてきたようですが、携帯の場合、携帯ブラウザがエラー画面を表示するので標準モジュールは使い物にならなかったです）、oci8モジュールが含まれるようにPHPをリコンパイルせねばならず、その指示書を書いて、クライアントの作業をサポートをしました。
以上のような理由で、開発自体は順調に進捗したのですが、それ以外の部分でひどく工期を取られました。
この案件で学んだ事は、開発環境の構築・システム要件の保証はよく検討して工数にプラスする事、でした。
全面Flashのサイトって見づらいサイトが多いと思うけれど、MARGARET HOWELLのサイトはかなり見やすく出来てる。
画面をロードするのに重い感じがしない。
本国イギリスのサイトと同じデザインだけど、サイトの制作は別のようだ。
| 内容 | ショッピングサイトのパフォーマンス改善開発 |
|---|---|
| 期間 | 2007年2月 − 2007年8月 |
| OS | Solaris |
| 言語 | PHP, JavaScript |
| アプリ | Apache, Oracle |
PC向けのショッピングサイトの開発に、プロジェクトマネージャ1名、プログラマ4名からなるチームにプログラマとして参加しました。
この案件は出自（？）が特殊でした。
クライアント（サイト運営者）が某大手独立系SIerに開発を依頼したものの、納期を過ぎても完成せず、その某SIerは自社開発を諦め、当時自分が参加していたウェブ制作会社に開発を再委託したというものでした。
自分達が委託を受けた時点で画面はだいたい出来ていて各画面の基本的な機能も実装されており、進捗率は高かったのですが、独自フレームワークを採用しており、そのシステム構造が驚く程複雑で設計が悪かったです。
新たな機能を実装しようとすると既存の処理に大量な修正が発生し、高い確率でデグレが発生しました。
すでに動いてる機能もパフォーマンスが低く、クライアントの要求性能を満たそうとすると、当該処理を大幅にリライトしなければなりませんした。
納期はすでに半年以上遅れてどうにもならない状態で、某SIerはギブアップし自分達が開発を引き継ぎました。
どのように設計が悪かったか説明すると、オブジェクト指向が過度だったと言えると思います。
リクエストの度にあらゆる（ビジネスモデリング的な意味での）オブジェクトが生成され、各オブジェクトが複雑に関連していました。
ウェブアプリケーションは、特にこの案件のようなショッピングサイトの場合、基本的に業務アプリケーション（DBアプリケーション）と見なせ、その為オブジェクト中心よりデータ中心でシステム設計をした方が良いと思います。（この辺の話はSE・PG入門「データ中心指向とオブジェクト指向」に詳しいです。）
ウェブでは複雑にオブジェクトを作っても保存する先はDBだからです。
もしオブジェクト指向ならORマッパーを使えばDAOが整理されると思うのですが、この案件のシステム設計ではSQLはDAO内で独自の生成処理を経ており、ちょっと検索項目を変更しようにも、生成処理内にあるSQLの断片（復元すると数十行になる）を追う必要がありました。
また、同じ目的と思われるが微妙に異なるSQLが別のメソッドに散在していて、SQLの記述自体もコピペの繰り返しで冗長化していて、という。
開発の長期化で担当者が変遷し、担当者毎に実装の癖、コーディングスタイルが違うというお決まりの問題もありました。
結局、半年ほどかけて、なんとかもう少しで完成という所まで持って行ったのですが、ある不可抗力な事情からリリース直前に開発が中止になってしまい、案件として強制終了しました。
自分達の会社には損害はなかったのですが、後味の悪い終わりで非常に残念な気持ちがしました。
このような案件は自分の経験でも今の所唯一で、こうなる前にもっとすべき判断があったなと思います。
個人としてはアンチパターン的に勉強になってのですが。