残業プログラマの雑記 RSSフィード

2009-06-02 ちょっと頭にきてること。

[] 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が配布しているものに対して大幅な機能変更が加えられているのでソース比較が難しくなっております。純正ソースに対して修正を出す時間的余力がありませんのでコミッターとしての活動は行っておりません。
それ以前に設計段階での問題がちらほらしているので根本的修正はかなり大きな影響が出そうです。
削除しないの?
削除しません。記事が完全に間違っているなどの問題が無いかぎり原則 削除は行わない主義です。

なまえなまえ 2009/07/15 08:06 良い指摘だと思います。
コミッターになって修正してあげればいいんじゃないでしょうか。
https://www.ec-cube.net/comitter/index.php

xxxYukihiroxxxxxxYukihiroxxx 2009/07/15 09:21 オープンソースなんで、コミッターのスキル・テクニックに委ねられると思います。ここまでまとめられているのであれば、情報共有した方がいいと思います。^^

nobodynobody 2009/07/15 17:15 「開発者が料金計算ができない」での計算は間違ってないけど。
http://www.mof.go.jp/jouhou/syuzei/siryou/sougakuhyoji/sougakuhyoji.htm

aa 2009/07/28 11:57 超致命的(赤字)とされているところは、あなた自身の勉強不足、開発者の方が合っています。記事は削除するかちゃんと修正した方がいいですよ。

ああああああ 2009/09/09 09:20 今仕事でEC-CUBEのカスタマイズをやっているのですが…。ほんとひどすぎですね。いくらフリーとはいえ、公開しているんだからそれなりのものにしてリリースして欲しいですね。PHPの練習台ですよ、これじゃ。
DBのテーブルに主キーが無いとか、このレベルのアプリでテーブルの数が100超えるとかありえないですし(涙

rokujyouhitomarokujyouhitoma 2009/09/09 09:55 >あああ氏
PHPの練習台というのは確かにw

きぬききぬき 2009/09/09 10:13 言い出しっぺの法則。
酷いというならそれをどうにかしてあげたらいかがでしょうか。
言うは易し、行うは難し。

parasporospaparasporospa 2009/09/09 13:05 これは氷山の一角なのでしょうね。
EC-CUBEはバグが多いという貴重な情報をありがとうございます。

まさみまさみ 2009/09/09 14:11 この記事のような具体的なダメ出しはオープンソースアプリケーションのクオリティ向上につながる。つまりは各人がアプリケーションの諸要素においてダメ出しやベタ褒めを行う事で、集合知が形成される。

集合知のメリットを理解していない人、例えばaさんが「あなた自信の勉強不足」と書いているが、これは集合知の形成促進を阻害する発言であり、いただけない。

defdef 2009/09/09 14:57 >まさみ氏
ダメ出しはパッチとセットがマナーです。

井伊&志位井伊&志位 2009/09/09 18:53 すばらしく役に立つ記事ありがとうございます。
おつかれさまでした。
おかげさまで手間が省けました。(不採用の意思決定の)

reedomreedom 2009/09/09 22:41 >ダメ出しはパッチとセットがマナーです。
ダメ出しだけでも有用です。
バグは発見されることで修正される機会を得ます。
この場合は、よってたかって直せる機会、ですね。
せっかく集団が存在するのに、一人で抱え込むことはありません。

...というか、アホほどある不具合を発見してしまっても、
パッチと一緒に報告できないなら黙ってろ、とでも?
どれほどの負荷がかかるか、ちょっとでも考えてみたら?
杓子定規もいいかげんになさい。

magatumagatu 2009/09/17 20:33 なんで、こんな関係者っぽいのが湧いてるの?バグだらけなのはそれなりの人がみれば一発でわかるし、バグだしは有益な仕事、パッチとセットなんでアホか。

xross-cubexross-cube 2009/09/19 23:44 >旧世代の遺物が沢山
は笑いました。どうにかしたいな〜と思ってます。

毎度修正して使ってます。
ところでこの記事で言及されているEC-CUBEのバージョンっていくつですか?

Seasoft (EC-CUBE コミッター)Seasoft (EC-CUBE コミッター) 2009/09/26 09:45 (一部ズレた部分もあるものの)全般的には非常に的を得た記事だと思います。
EC-CUBE フォーラムでも話題に上げてみようかな。


> 4. 開発者がSmartyテンプレートエンジンを使いこなせていない。
> * {section} でループ回すんじゃなくて {foreach} 使おうよ。

PHP でも、for や each を使っている箇所で「foreach 使おうよ」って思う部分があります。
コミュニティ版では、いくつか改修しましたが、まだまだ改善すべき箇所は多いですね。

ShiinomiShiinomi 2009/10/20 00:21 感情的でも、残しておいたら?
あなたにとってはそれくらいの勢いをもたせるブツだったということでしょう。
反省材料が残るのは恥ずかしいかもだけど、自分への薬だと思って。

私はこの記事を参考にいれながら導入評価を始めてみようと思います。
この記事のままだったら、不採用確定でしょう。
おそらくはそうなる予感はしていますが、手間わかけてもやっぱり目で確かて納得したいので。

Live CommerceLive Commerce 2009/11/03 19:22 EC-CUBEは色々と問題はあるものの、中小規模で見た目さえ良ければOKなサイトにはうってつけだとは思います。

人から聞いた話ですが、ロックオンの社長は「EC-CUBEにバグがなかったり、機能が充分に備わってしまうと、パートナーさんが食べられないでしょ?」みたいなことを言ってたみたいだし。
あえてこの品質じゃないんでしょうか?

また、プラチナパートナーさんのA社さんも、評判は良くないですよね。
それほど技術力がある訳でもないようですし(経歴見ると素人に毛が生えたような人ばかりだし)。
上で書いたように、見た目さえ良ければOKなクライアントが多いのかも。
プラチナパートナーというだけで、他人からの評価も厳しくなりがちなのでカワイソウではありますが、今後とも頑張って頂きたいです。

それよりも、私はLive Commerceに期待しています。
Live Commerceが公開後、EC-CUBEのシェアガタ落ちにならなければいいですがね。

NGNG 2010/01/14 19:52 EC-CUBEにはプログラム的な問題があるようですが、ネットショップを運営している私から見ると、仕様に致命的な問題があります。致命的ではないけど、通常では考えられないような欠陥も多く、プログラムも仕様も両方とも非常に質が低いと思います。おそらく、仕様を考える段階で、すでにあるECシステムの仕様を調査することすらしていないですね(汗)


特に規格まわりはお店によっては利用不可能といえるほどです。サイズと色の両方が設定される商品を扱うお店は利用できません。(商品管理が地獄のように大変な作業になっても構わなければ別ですが・・)どれほど浅はかな考えで、いい加減な会社のいい加減な人間が作ったのかというのが、中を触ってみると本当によくわかります。国内初のオープンソースECというので必要以上に注目をあびていますが、実際は自社で開発したシステムがゴミだったので、オープンソースにしただけと思います。

EC−CUBEのホームページがもうちょっといい加減なデザインだとよいのですが、一見すごくちゃんとしてそうないい感じのホームページのため、被害者が続出していると思います。

ネットショップオーナーは、中途半端な自由度を求めてEC−CUBEを使うよりも、安くて良いASPのネットショップを使った方が良いと思いますよ。

EC−CUBEが使えるのかどうか調査するだけでも相当大変で時間がかかります。

上に出たプラチナパートナーのA社は、EC-CUBE以外のサービスはやっていないので、相談とかしない方がいいと思いますよ。EC-CUBEという泥舟に乗った会社なので、他のシステムの提案はもちろんありませんし、良いことしかいいません。

EC−CUBEは、色んな意味で非常に低レベルなシステムなので、もっとデメリットを広めるべきですね。どれだけ多くの人の時間と労力を奪っているかを考えると、本当に世の中のゴミだと思います。

今後、もっと具体的にどこがダメなのかを書き出してレポしたいと思います。

NGNG 2010/01/21 02:58 2009.12.01 ライブコマースがリリースされましたね。
http://www.live-commerce.com/

ホームページのデザインはそれほどしっかりした印象は受けませんが、
EC-CUBEのように見た目だけ良くて中身がゴミという前例があっただけに、
逆に好感が持てます!

多言語に対応しているし、ウイッシュリストもあるし
そのほかも、仕様はちゃんと考えられているという印象です。

アホでいい加減なロックオンとは違うようなので、
とりあえず期待します!

ECマーケティング専門ECマーケティング専門 2011/02/16 20:45 セミナーで色々な方に話を聞くと、実はEC-CUBEの品質が非常に低いということは技術者の中では有名みたいですね。

私は5年以上、複数のネットショップを運営しており、自分でいうのは恐縮ですが、SEO・PPC・LPO・モバイルなどのインターネットマーケティングの知識はそれなりに高いレベルにあります。プログラミングも少しですが実務経験があります。
ネットショップの乗り換えを考えた時に、色々なシステムを徹底的に試してみましたが、その中でもEC-CUBEの品質は非常に低いと感じました。(プログラムと仕様の両方)

■以下、私が経験した具体例

1.注文時にマンション・建物名が必須項目になっているため、一軒家に住んでいるお客さんは注文できない(笑)
これで確実に注文を取りこぼすことを考えると、あきれて物も言えません。

2.商品に対してサイズと色の2つが設定されている場合は、ほぼ運営不可能な状態になる。
実際には、SS〜XOまである商品で8色ある場合、在庫画面で縦に48行にもなり、カラーとサイズが豊富なシンプルなTシャツは、お客様が自分が欲しい商品の在庫があるのかないのか探すことが非常に困難。管理側で在庫を登録するときは地獄のようなわかり難さ。さらにプルグラム的にも致命的な欠陥があり、カラーとサイズは商品にひもづいて設定されてないので、ひとつの商品を表示するたびに、全商品のカラー・サイズのデータをイチイチ参照することになります(笑)結果、商品数が多くなると重くて運営不可能な状態に・・・プラチナパートナーにこの問題を指摘したら、カラーごとにわけて商品を登録するように言われました(笑)ショップによってはこれで問題ない場合もありますが、ネットショップの仕様としては最低です。

3.メルマガ機能が重くて動かないので、他社の有料サービスのメルマガを使うように言われました。
メルマガの重要度を考えると、この時点で普通にアウトでした。

4.ドメインの変更が困難。検索エンジンでスパムになったりドメインを変更したいことはそれほど珍しくありませんが、サイトを再構築する必要があるため別途5万円の費用がかかりました。

5.トップページのURLに問題があるため、モバイルサイトが検索エンジンにほぼキャッシュされない。プラチナパートナーに言ったところ、「検索エンジンがアクセスのすべてではないので、ほかの方法で集客してください」とのこと(笑)本当にあきれました。商品にもよりますが、ネットショップの売上の4分の1くらいはモバイルからです。

パッと思い出したのはこの程度ですが、細かい仕様のミスや欠陥は私が見つけただけで数十個にもなりました。
あまりに不完全なシステムだったので、多額の費用と時間を投資したあげく、EC-CUBEを使うことは断念。大きな損出となってしまいました。

2.の問題のようにデータベースの構成に問題がある項目は、改善するのが困難なので、今後も改善される見込みは少ないと思います。ロックオンのズサンな管理体制や根本的な設計ミスを考えると、EC-CUBEに未来はないと判断しました。

ネットで色々と情報を集めてみると、EC-CUBEはそもそもロックオンが自社で販売するシステムとして開発されたが、それを途中で断念したので、無理やりオープンソースにしたとのことです。これではそもそもオープンソースとは呼びませんよね。「うまくいかなかったので、世の中に放出されたゴミ。」(ちょっと言葉が悪いですが・・)この経緯をしると、欠陥だらけの仕様・質の低いプログラム・ずさんな管理にすべて納得できます。

オープンソース(無料・自由度が高い)という言葉に惑わされて、時間とお金をムダにしないように、良いもの悪いものを冷静に判断しなくてはなりません。自由度の高さよりも、最低限の質をクリアしているかをまずは優先すべきです。私の苦い経験がどなたかの役に立てば幸いです。

ECマーケティング専門ECマーケティング専門 2011/02/16 20:54 以前も投稿した者ですが、EC-CUBEはあまりにヒドイので、悪い点を思い出して具体的に書いてみました。

ECう〜べECう〜べ 2011/11/10 16:14 確かにECは本当に酷いです。
「無料ですから」っていうのをいい事にまともなデバッグもせず、2.11.0〜2.11.4まで連続で出す始末。それもまた更にバグやHTMLタグの記述ミスも連発(笑)
スペルミスはもう諦めました。気持ち悪いですが、そのままでいきます。
結局2.11.1のバグやミスや不具合を直し終えたりした頃、既に2.11.4が出てる(笑)
また最初からやり直し(笑)まともに使えないものを出すくらいなら出さないで結構なのに・・・。


「ま、無料ですから、デバッグや不具合とかはユーザーが勝手にやってくださいよ、わかんなければ有償でやりますから」って事でしょ?
本当に酷い(笑)
さすがに腹立ってきた・・・。

なんだかんだで数年経って…なんだかんだで数年経って… 2012/01/03 21:11 それでも、未だに EC-CUBE の一人勝ち。

技術者に嫌われ、店長さんに好かれる。

面白いものですよね。

ECう〜べECう〜べ 2012/02/06 11:51 先ず、デバッグも何もしないでリリースする事自体間違い。
リリースしてから次々とバグ報告が上がっています。その殆どがデバッグ段階で分かるようなもの。
「無料だからいいっしょ?(笑)」程度でリリースしているんでしょうし、また無料だから仕方ないのかも知れませんが、本当に酷い。
挙句の果てには、オープンソースを良い事に、開発者側の会社がカスタマイズ費用を取る始末(笑)
「こんな事したくてこうしましたがエラーが出ました。誰か教えて下さい」とフォーラムに書けば、じゃぁ有料でお教えしましょう。となる。
オープンソースって何?
PHPとかSQLとかDBとか、難しい事は分かりませんが、それ以前に酷いASPですね(笑)

ねぎねぎ 2012/02/13 04:57 ASPじゃねーよ。ECCUBEに限らず、悪い所も全部見せてやってんだろ、生かすも殺すもお好きにどうぞ。ってのがオープンソースだよ。
面倒臭がらずに、完璧目指して全部自分でフルビルドすりゃいいじゃん。

面倒だし、何よりフルビルドの金持ってない客が多いからタダでざっくり動くものならなんでもベースに使うけどね。
そもそも、オープンソースは客からの御指定ばっかなんだよね。

取り敢えずバグは、黙ってタダで直してやってる。金取るのは、客から新しい機能付けてくれとか、こう動くようにしてくれ、と、無い物ねだりされた部分の工数だけだ。
ま、ウチは単価が高いので、その程度のバグ修正は当たり前に黙ってやる。勿論、プロなので、コミュニティや同業者に聞くことも、他人の解決情報の期待もしてない。同業者からバグ改修やカスタマイズ相談されることが多いが、その度に出来ないなら受けてくるなと思う。

ECう〜べECう〜べ 2012/03/24 23:40 べつにあんた(ねぎ)んとこに文句言ってるわけじゃないですよ。
それともあなたECの人ですか?
だったらこういう意見もあるんだなぁと思って受け止めて下さい。
市場とは、売り手の意見ではなく買い手の意見でよしあしが決まるものです。(こういうと絶対にだとか全てがだとか、そういう極論を言う人が居ますがそんな子供ではない事を願います)
新しいバージョンが出る→一斉にバグと不具合と問題が出る→利用者が一生懸命直す→直った頃に新バージョン→また新たな問題が出る→みんなで一生懸命・・・
この繰り返し(笑)
オープンソースってこういうものだったんですね(笑)
知りませんでした。

いくら無料とはいえ、オープンソースだとは言え、最低限のデバッグや不具合は解決してからリリースするのが常識だと思ってたんですが、どうやら間違えていたようでした。
お恥ずかしいです。
ねぎさんには貴重な事を教えて貰ったので、今後はクライアントにもそう説明しますよ。
オープンソースってのは、無料でバグがあろうと不具合があろうと自分で直せないなら手を出さないほうが良いですよって(笑)
ちなみに、ねぎさんの言っているバグをただで直すっていうのは、自身でカスタマイズした分ですよね?
僕が言ってるのはそういう意味じゃないんですよ。

と、そんな事を言う前に今も2.11.1の問い合わせページでメール送信できない原因を探らねばなりません(笑)
これってサーバとECの相性の問題もありそうなんですがどうしたものか・・・。

patapatapatapata 2012/05/24 16:15 バグは確かに多いね。しかし収益形態が違うのであれば致し方ないと思ってます。
タダで配布してるものにコストそこまで避けないだろうし、うちの会社はオープンソースの配布なんぞしてないけど、もしやったとして・・・オープンソースならバグ報告がきても、利用者が直してくれよ!金になんねぇんだからってなるよ。リリース時の検査もあまくなるしね。

またEC-CUBEはアジャイル型モデルの開発形態でしょ。昔のようなウォーターフォールモデルの開発とは別形態。だからこそ成功したといえるし、昔の形態を引きづってる開発者は、不満たらたらだといえる。
(金銭を扱う業務アプリケーションなのに、アジャイル型でいいんか!?とは激しく思うけど・・・私が古い人間なんだろうな。)

そして経験から言えば、サーバーソフトはお客環境がバラバラすぎるので、リリース後に糞みたいなバグが山ほどでるのは、よくあることだと思ってます。
(最近は、サーバー管理者のレベルが低すぎる。)

まぁ問題は、開発者はEC-CUBEを使うリスクを知ってるが、顧客は全然知らないってことだろう。この溝が早くうまりゃいいのにね。

カスタマイズ業者じゃないので知らんけど・・・
こゆオープンソースを使っての開発の時、見積もり書に
※当社対応以外の既存不具合の対応については、別途費用をいただきます。
とか明文しないの?

teptep 2013/06/25 11:02 記事が書かれた日からかなり経ってますが、少しずつキレイになってきている気はしますね。
EC-CUBEが広まってきている分、コミッターも増えてきて、エンバグ、デグレも起きているのがたまにキズです。

>こゆオープンソースを使っての開発の時、見積もり書に
>※当社対応以外の既存不具合の対応については、別途費用をいただきます。
>とか明文しないの?

しますよ。もしくは保守契約結んでもらいますね。

NGNG 2014/06/07 18:18 少しずつ綺麗になってきてるとのコメントがあったので少し確認してみました。

以前は、マンション名の入力が必須でしたので、一軒家に住んでいる人は注文できないというとんでもない仕様でしたが、かろうじて改善されてます。

マンション名の入力が必須なのは変わりませんが、マンション名だけではなく住所自体を2つに分けて入力するように注意書きで対応してますね。

NGNG 2014/06/07 18:53 商品に色やサイズが存在する場合は、商品数が増えたら動かなくなるという、クソほどヒドい仕様は改善されたのでしょうか?

EC-CUBEは、DB設計に初歩的かつ致命的なミスをおかしてしまっているので、

例えば、商品Aの商品ページを表示させる場合、商品A〜Zまでそのショップに登録されたすべての商品の色とサイズを参照してしまいます。

一般的なECサイトの場合、商品Aの色とサイズが 赤・青・黄・緑・白・黒 × SS・S・M・L・O だとしたら 30個の在庫データを参照する必要があります。

しかし、EC-CUBEの場合、商品数が500個だとしたら、たった1ページの商品ページを表示させるために15,000個の在庫データを参照する必要があります。

1日3000人のユニークアクセスがあって、1人あたり10商品見たら、300,000,000個の在庫データを・・・

EC-CUBEは、基本的なDB設計に問題があるため、今後も一生欠陥システムのままです。カラーとサイズがない商材の場合は利用可能ですが・・

しかも、これはEC-CUBEの仕様の欠点の1つに過ぎないというのが、恐ろしいことです。

そもそも人様に提供できるレベルの代物ではないんですよ。

一般的な普通のオープンソースって、こんなにひどくないです。

そもそもEC-CUBEはオープンソースとして作られてないし、ロックオンが自社のサービスとして作ったんだけど、イマイチだから捨てた・・みたいなところから始まってるから

本当に良いものができたらそのままサービスとして提供します。無料で公開したということは、その程度の価値しかにないと自分で理解してるということ。

それでも利用者が多いのは、ネットショップ運営者のリテラシーが他のITの分野と比べて非常に低いからです。

プログラマーはプログラマーでネットショップなんて一度も運営したことないですしね。

作る側と使う側の双方に、圧倒的に知識が足りてないんですよ。だからこんな低レベルなものが世の中にはびこる。

ITという便利なもののせいで、本来、会社経営できるような器なんて持たない人物まで、簡単にお金と力を手にして、質の低い物やサービスを提供してしまう。

突き詰めると、EC-CUBEの質の低さの原因はそういうところにあると思います。

zan-gyozan-gyo 2014/06/21 00:02 EC-CUBEとデータの件数ですが、使用するデータベースに MySQL を選ぶか Postgres を選ぶかで大きく変わります。
PostgresはMySQLで比べて後天的なテーブル構造の変更が難しいので敬遠されがちですが、大量の情報を扱う際の
処理性能については別格です。

私が2008年以降、管理を任されているとあるサイトではPostgresを用いており、まだまだ快適です。
今のところ規格数が64,000、商品情報が315件、在庫データが10万件という具合ですね。

ただしショッピングカート毎にUUIDを発行して規格をあたらしく作り、見積り保存の際に規格に価格を複製して
長期間 過去価格を保持するという変則的なことをやっているので普通のEC-CUBEとはかなり違います(汗

ec-cube最悪ec-cube最悪 2015/03/02 00:43 酷いのは「命名規則」
1. ファイル名の命名規則
2. DB テーブルの命名規則
3. メソッドの命名規則
頭文字が同じだから「頭の中にあるキーワードをタイプして後は Linux や DB クライアントの補完に任せる」ということができない。

あと「MVC になってない」
helper 系が model、pages 系が controller のつもりなのかも知れないけど..
1. controller と view が 1:1 になってない。n:1 になってる。
2. controller に model に書くような addParams 系の処理や DB 処理が書かれてる。

あと「Smarty の独自タグ」
<!--{}--> にする意味ある?書きづらく、読みづらいだけ。

あと.. あー。いっぱいありすぎて書ききれない。

ec-cube最悪ec-cube最悪 2015/03/02 00:46 とにかく、EC-Cube は前時代の代物。
カスタマイズせずそのまま使うなら、今でもかろうじて使えるのかも知れないけど
カスタマイズ前提なら Ruby や Python でフルスクラッチで作った方が早い。
管理画面も含め。

asdfasdf 2015/03/04 15:57 まさかこんな時期にもコメントが更新されるとは
3が製作開始らしいですがどうなるんでしょうね
軽量フレームワークだから結局今の延長線上っぽい気がするけど・・・

hogehoge 2015/03/10 00:28 > まさかこんな時期にもコメントが更新されるとは
それだけ被害を被ってる人が多いってこと。
ロックオン(と、その取り巻きのパートナー会社)の言い分としては「そんなに文句言うなら使うなよ」ってとこだろうけど、被害者は恐らくそのパートナー会社から2次請けしたエンジニア、つまり、無理やり EC-Cube を使わされている人たちだと思われ。

xx 2015/03/11 09:32 EC-Cube3 は Silex 採用??
うーん。。Laravel の方が良くない??

xx 2015/03/11 09:32 EC-Cube3 は Silex 採用??
うーん。。Laravel の方が良くない??

mmmmmm 2015/03/11 13:39 EC-Cube 使うくらいなら PHP 捨てて Spree 使った方がいいよ。
github での評価 (=star)
Spree: 6080
EC-Cube: 64

mmmmmm 2015/03/22 22:25 3がオワコン言語のPHPで制作中ということは、rubyとかでEC-Cube2から簡単に乗り換えられるECパッケージ作ればロックオンに勝てるんじゃない?曲がりなりにも上場企業だからうまくやったら買収してもらえるかもよ、皆さん。

mmmmmm 2015/03/22 22:25 3がオワコン言語のPHPで制作中ということは、rubyとかでEC-Cube2から簡単に乗り換えられるECパッケージ作ればロックオンに勝てるんじゃない?曲がりなりにも上場企業だからうまくやったら買収してもらえるかもよ、皆さん。

ああああああ 2016/06/03 15:49 提供機能以外のことをやりたいなら、PHP、Smarty、Javascript,HTMLがわからないと100%無理。
ちょっとした機能を追加するとしても、相当なプログラム経験とEC Cubeに詳しくないと100%無理。
店舗側の人がかわいそう。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証