EC-CUBE 追記

ご無沙汰してます。EC-CUBEの関連プロジェクトで一息ついたかと思ったら過労が原因で帯状疱疹を発症してしまいました。
おかげで「夜眠れない程度の痛み」が後遺症として残り、睡眠不足の毎日を過ごしてます。まだ30代前半なのに帯状疱疹って(涙

前回のEC-CUBEについての批判、色々な場所からトラックバックを頂いています。
意外と反響が多かったようで戸惑いつつトラバ元を閲覧させて頂いています。

まず思ったのが、

  • 作る (オーダーに応える側) の思い込みって恐ろしいってことですね。

インディゴの研究 様の 消費税の計算方法と総額表示 記事で指摘されていますが、私が前回批判した消費税の端数計算の処理は EC-CUBE現在の仕様で正しいとのことです。

EC-CUBE では消費税の端数処理の方法として

  • 切捨て
  • 四捨五入
  • 切り上げ

の三通りの方法をサポートしています。
とある商品が複数個 購入された場合に端数の累積をどのように扱うかは店舗次第ですが、一般的には購入者側に負担が少なくなるように処理するのが普通かと思います。
ぶっちゃけ、購入者側の負担が少なくなるように処理しないと購入者側からクレームが入ります (クレームを送ってくれるお客様は特別に良いお客様です)。

  • 端数処理を 切捨て で行う仕様の場合は単価毎に消費税の端数処理を行い数量で掛けると金額が少なくて済むのでEC-CUBEの現行の仕様で問題ありません。
  • 端数処理が 四捨五入切り上げ の場合は単価毎に端数処理を行うと誤差が累積します。

今回私が携わったBtoBサイトでは「税抜き価格入力に対する四捨五入」が条件でしたのでお客様の負担を軽減するためには端数処理の計算方法の変更の必要が発生したというわけです。
(これを含めてパラメタで切り替えの行える方式が望ましいのでしょうが、そこらへんは価格演算部分を分離して整理すれば対応できる筈?ポイント消費時の演算も含めて分散しているソースを簡略化したいところですね。)

尚、EC-CUBEには4っつめの端数処理方法が存在します。大抵のBtoCサイトではこの方式を選択してカスタマイズするのが最も安定する方法かと思います。それは

  • 消費税を0%に指定して
  • 単価を税込価格で入力する。

画面表示時に税額を逆算する必要はありますが仕様として押し付けてしまえば一番無難かもしれません。

昔はカード決済時にオーソリデータに商品項目毎の税額を記載する必要がありましたがそれも「総額表示」に伴い不要となりました。それと比べれば便利になったものですね。

EC-CUBEはここが酷い。

最近 EC-CUBE のプログラム修正を仕事でしているわけだが、EC-CUBEのプログラムソースは余りにも酷すぎる。

  1. 開発者が初歩的な英単語を理解していない。
    • 「check」が「cheek」になっている等、スペルチェックをしていない。
    • 税額を加算する関数がなぜか「sfPreTax」だったりする。加算するのに「Pre」は無いだろう。
  2. 開発者が簡単な論理演算ができない。てか変数名のコピペ複写後の名前変更すらきちんとできない。
    • SQL文で 製品ID が特定の値で、 規格ID1 と 規格ID2 のどちらかがゼロで無い場合。
      ×「product_id = ? AND classcategory_id1 <> 0 AND classcategory_id1 <> 0」
      ○「product_id = ? AND (classcategory_id1 <> 0 OR classcategory_id2 <> 0)」
  3. 開発者がPHPのハッシュ配列を使い慣れていない。
    • ハッシュ配列を使えばデータを簡単に整理できるのになぜか各値を格納する配列をそれぞれ別々に定義して値を入れている。
      例: Array('a' => 1, 'b' => 2, 'c' => 3); とすれば済むところを、
      a[0] = 1; b[0] = 2; c[0] = 3; とかにしてる。
      しかもこの状態で配列要素の追加削除のやりくりをしてる。
  4. 開発者がSmartyテンプレートエンジンを使いこなせていない。
    • {section} でループ回すんじゃなくて {foreach} 使おうよ。
  5. 開発者がウェブフォームがPHPに返す値の書式を理解していない。
    • マスターデータを入力するフォームに空行を入れるとデータが丸ごと一行ズレるような致命的バグがある。
  6. 開発者が料金計算ができない。(超致命的!)
    • 複数商品の価格を税別から計算する計算式がなぜか
      [ 端数処理(単価 * 税率) * 数量 ]
      + [ 端数処理(単価 * 税率) * 数量 ]
      + [ 端数処理(単価 * 税率) * 数量 ]
      + [ 端数処理(単価 * 税率) * 数量 ] = 合計
      になっている。
    • 単価に課税処理してから数量で増したら端数処理の差が累積して大変なことに。
    • ⇒ でも求められる仕様はともかく、間違っているわけでも無いようです。 2009.07.30 追記
  7. EC-CUBE 1.x シリーズと EC-CUBE 2.x のプログラムソースが混在している。
    • 旧世代の遺物が沢山
  8. ファイル名や内部パスの隠蔽が不完全。
    • 画像のサムネを参照する際に内部パスがURLにフルパスで記述されていてお茶吹きました。
  9. controllerのクラスを拡張できるようにしているのに処理段階毎にメソッドを細分化していない。
    • process() メソッドにメイン処理とHTML出力を全部詰め込んだらサブクラス化する際にメソッドを全部書き直すしか方法が無い。
  10. 開発者がWindows環境とUNIX系環境でのパス名の扱いの差を検証していない。
    • Windows用のパス補正コードが意味を成していない。
    • Windows環境に対応させろとは要求しないが、ロジックを分析したらまったく効果が無いことぐらいは実行しなくても分かるだろう。
  11. 開発者がデータベース処理を理解していない。
    • ユニークIDの割り当てがユニークIDを割り当てていない。
      • MySQLでお客様に電話で案内しながらウォークスルーをすると短期間に同じような操作した影響で同じ注文番号が両注文処理に割り当てられ、最後の注文確定時にどちらかがコケる (通常はお客様側がコケる)。
  12. 開発者の個人情報保護意識の欠如
    • 秘密の質問に対する答えが平文保存。
    • その他セキュリティ面で改善する点がわんさか。



国産(日本語表記)でフリーで使えてカスタマイズ次第で使い物になるパッケージは大歓迎なのですが、
このバグの多さは異常。

結局はPHPプログラマがいないとまともなサイトは作れないというオチが。









2009.09.10追記
インディゴWeb研究室様よりトラックバック記事を頂いております。合わせてお読みください。

  1. インディゴWeb研究室 消費税の計算方法と総額表示
  2. EC-CUBE 追記
  3. インディゴWeb研究室 続・消費税計算と総額表示

Q&A

「超致命的」となっているところの計算は開発者の方が正しいが…
たしかにEC-CUBEの仕様は正しいですが、端数処理方法が四捨五入や切り上げの場合は端数処理の差が累積してしまい、商売上現実的では無くなってしまいます。仕様として正しくても販売形態に見合っていなければ意味がありません。
なぜコミッターになって修正しないの?
EC-CUBEリリース初期には色々と対応はしていたのですが、現在メインで使っているソースがEC-CUBEが配布しているものに対して大幅な機能変更が加えられているのでソース比較が難しくなっております。純正ソースに対して修正を出す時間的余力がありませんのでコミッターとしての活動は行っておりません。
それ以前に設計段階での問題がちらほらしているので根本的修正はかなり大きな影響が出そうです。
削除しないの?
削除しません。記事が完全に間違っているなどの問題が無いかぎり原則 削除は行わない主義です。

今更聞けないJavaScriptを使用しないCSSマウスオーバー

  • 今仕事で作成しているウェブサイトのマウスオーバー画像として以下のようなスタイルを採用している。
<a href="form.php" id="form"><em>ログイン</em></a>
a#form {
  float: left;
  display: block;
  margin: 0 0 0 0;
  background-position: 0 0;
  width: 44px;
  height: 21px;
  background: url("form.png") no-repeat;
}

a#form:hover {
  background-position: 0 -21px;
}

a em {
  display: none;
}

  • ボタンサイズが 44x21 の場合、ボタン画像は 44x42のサイズで通常の画像とマウスオーバー画像を縦に連結する。
  • width/height で表示画像サイズを固定し、background-position で切り出す位置を指定することにより、CSSだけでマウスオーバーを実現できる。(この際、縦座標はマイナス値を指定する)
    • この手法の利点:
      • マウスオーバー画像の先行読み込みが必要無い
      • JavaScript無効環境でも動作する
      • アニメーションGIFの動きを中断せずにマウスオーバーできる
    • 欠点:
      • 画像サイズ変更時にCSSの変更が必要になる
    • というあたりか。
  • 画像ファイルの連結生成+CSSの生成をスクリプト化して、画像変更時に表示用ファイルを再生成するという手もあるが。
  • emタグを display:none しているのはCSS無効時の案内表示用。
  • もちろん以下のような汎用的な定義を行い、a タグのstyle で width、height、background-imageを指定するのも有効
<a class="css_rollover" style="width: 44px; height: 21px; background: url(form.png) no-repeat;" ><em>ログイン</em></a>
a.css_rollover {
	background-position: 0 0;
}

a.css_rollover:hover {
	background-position: 0 -100%;
}

a.css_rollover em {
	display: none;
}

サルでも出来るマスコミ式発言表

以下2ちゃんねるからのコピペ

妥協して落しどころを探ると・・・・・・・法案は骨抜きだ 
政治に民意を反映させ法案を押し通すと・・一方的だ、独裁だ 
部下に大きな権限を与えて任せると・・・・丸投げで無責任だ 
官邸主導で進めると・・・・・・・・・・・独裁政治は許せない 
決断を下すと・・・・・・・・・・・・・・なぜ急ぐのか、慎重に議論すべき 
保留すると・・・・・・・・・・・・・・・また先送りか 
支持率上がると・・・・・・・・・・・・・人気取りの政策 
  〃 下がると・・・・・・・・・・・・もっと国民の声に耳を傾けよ 
靖国に行くと・・・・・・・・・・・・・・近隣諸国の許可を得たのか?軍歌の足音が聞こえる 
 〃 行かないと・・・・・・・・・・・・国民との公約を破った 
閣僚人事の予想があたると・・・・・・・・新鮮味がない、地味 
 〃  〃はずれると・・・・・・・・・・またサプライズの手法、実務派を使え 
拉致問題に取り組む前・・・・・・・・・・北朝鮮との友好を壊すな、拉致は政治的捏造だ 
 〃  〃  取り組み後・・・・・・・・なぜもっと早くやらなかったのだ 
北朝鮮に強い態度取ると・・・・・・・・・なぜ話し合いで解決しようと努力しないのだ 
  〃  と協調すると・・・・・・・・・弱腰外交はやめろ 
規制緩和すると・・・・・・・・・・・・・競争が激しくなり格差社会を助長する 
 〃 〃 しないと・・・・・・・・・・・既得権益にメス入れろ 
株価下がると・・・・・・・・・・・・・・景気悪くなった、なんとかしろ 
 〃 上がると・・・・・・・・・・・・・格差広がった、すぐに是正しろ 
景気が良くなると・・・・・・・・・・・・企業優遇税制をやめろ、格差社会を是正しろ 
  〃 悪くなると・・・・・・・・・・・景気対策がなおざりだ、社会保障を充実しろ 
景気対策をすると・・・・・・・・・・・・バラまきだ 
  〃  しないと・・・・・・・・・・・政府は日本の景気を底上げするつもりがあるのか 
増税を唱えると・・・・・・・・・・・・・国民をさらに苦しめるつもりか 
 〃 行わないと・・・・・・・・・・・・逼迫した財政をどうするのか 

よくできているもんだ。

Vaio Pを研究してみる。

  • 最近話題のVaio P、どうみてもポケットに安定して入るサイズじゃないのだが。


参考サイト:

ASCII.jp デジタル [http
//ascii.jp/elem/000/000/200/200683/:title=ソニーが送るNetbookキラー? VAIO type P解体天国(前編)]、ソニーが送るNetbookキラー? VAIO type P解体天国(後編):内部構造等について解説あり。そうか、ワイヤレスWAN+GPSモジュールとワンセグは排他なのか。
ホイール欲しい ハンドル欲しい [http
//wlog.flatlib.jp/?itemid=1279:title=2009/01/16 Intel GMA500 の機能と性能と Aero]:いつも拝見させて頂いているDirectX関係のブログにGMA500のスペック分析記事があった。GMA500についての考察なのでVaio Pでは実装状況は異なるだろうが、とても興味深い。
C-TECバックルーム3 [http
//ctec3.blog.so-net.ne.jp/2009-01-09-4:title=みんなの『VAIO type P』オーナーメード]:SonyStyle 専門店 カラーテックさんの店員ブログ。各オーナーメードモデルの注文の傾向など色々なデータがあります。注文時の価格、後日購入時の価格の比較等もあり。「VAIOの話」カテゴリに他にも色々情報が詰まってます。

VBAでVBE(Visual Basic Editor)を編集する。

  • ひさしぶりにMS-Accessでツールを書いているわけですが、RecordSetを直接データシートで表示できないのは面倒。
  • 色々と探していたら驚いたのが Application.VBE 。なんとVBAのエディタをスクリプトできる模様。
  • 詳しくは見ていませんが、VBAや外部アプリを用いて動的にVBAを書いたりできるみたいですね。