もちオプソで。
多言語対応。
高セキュリティ。
拡張機能・言語の追加は追加モジュールを入れるだけ。
柔軟なカスタマイズができる料金設定。
オンラインショップってのは、店によって結構細かい違いがでてくるものなんで
カスタマイズ性が必須だと思うんだけど、どうも既存のやつは制限が多すぎる。
自由に設定できないうえに、ソフト会社に頼むと高額な金額を要求される。
そんな人にぴったしなソフトにしたい。
ほかにほしい機能あったら頂戴。
とくに、今オンラインショップを運営しているが
こんな機能がなくて○○はいや！ってな人お願い。
たぶん、俺一人だと思いつかないから。
補足
osCommerce・ZenCartのクソ加減にはうんざりです。
適当にアイデアを並べていく。
・柔軟な商品タイプの設定
商品タイプとはZenCartにあるやつ。
たとえば、本という商品タイプには属性としてISBNがある。など。
そういうのを「運営者が」（←重要なところ）自由に作成・変更できる。
ZenCartの場合、いちいちテーブル定義して
それに入れたり表示したりとプログラムを変更しないといけない。
・値段がないもの、値段固定ができる
無料商品、固定価格商品対応。
スーパーの肉・魚みたいに、この商品は3個買った1000円になる
会員・期間・時間の条件の違いで複数の価格設定ができる。
柔軟なページ修正、特定の商品のページだけ
WYSYWIGエディタで修正することが可能。
特定の商品に限り、はでなPOPを入れるなど。
こういう類の物はカスタマイズだけでどうこうできないんだよ。
ある程度の大枠フレームワークは作ることができるかもしれないけどね。
大体、業種によってDBのテーブルがまったく異なるのをどうやって吸収するのよ？
あきらめな。
> こういう類の物はカスタマイズだけでどうこうできないんだよ。
その理由は？
> 大体、業種によってDBのテーブルがまったく異なるのをどうやって吸収するのよ？
DBのテーブルがまったく違うのなら
拡張モジュールで変えれば良いだけの話だろ。
DBのテーブルってプログラムから変更することができるんだぜ？
まさか、知らなかったのか？ｗ
>>8
いいえ。貴方が欲しい機能を書けば私が作ります。 アイデアぱくっておれすげ〜〜って言いたいだけの小僧ですか
本気でOSSでやりたいというなら
プロトタイプをSourceForgeなりGoogleCodeHostingなりで公開すればいい
それすらやらないようでは到底無理
>>10
俺すげーとは言わないので、アイデア下さい。
アイデアというか要望。 携帯サイトとPCサイトの商品DB連動
佐川、ヤマト用、送り状作成ソフトにインポートできるCSV作成
詳細写真の枚数、自由指定
アフィリエイト機能
特別に作ったHTMLページも利用可能に
３０万くらいで作って
zencartの改造でもいい
＞携帯サイトとPCサイトの商品DB連動
連動させない作りのほうがキモいだろ．．．。
またk.k.プロジェクツか！
とりあえず>>1はコテつけろ >>14
商品タイプの部分はクラステーブル継承がいいかなと思っている。
でもJOINの負荷を考えると具象テーブル継承も捨てがたいかなと思っている。
具象テーブル継承だとデータが重複して保存されるから運用時に
商品タイプをいじると大規模なデータ変更（あるテーブルからあるテーブルに
大量にデータコピー）が起こりそうだなぁ。
基本の商品データは商品コードと型情報のみ。（タイトルぐらいあってもいいか？）
そのほかの項目はすべてモジュールで定義。
なんと価格すらもオプション。必須項目ではないのだ。
（だって100円ショップみたいに価格固定だと価格項目は必要ない） > 詳細写真の枚数、自由指定
OK OK
ついでに縮小サイズとか自動で作成。キャッシュあり。
携帯の場合もそれぞれにあわせた形式で。
共有SSLのURL対応
（共有SSLのURLとはhttps://レンタルサーバー/独自ドメイン/的なやつのこと） image(
id,
item_id,
path,
file_name,
type,
alt,
del_flg
)
無理無理。
何でもかんでも構築ソフト任せだと顧客が痛い目見るってことで実用性はない。
>>27
多分>>23は市販のWebショップ作成ソフトかosCommerceあたりのWebアプリケーションで
痛い目に遭っただけちゃうか あれもこれもと入れ込むよりは、アドインできる仕様にしてAPIを公開
するってのが今時の流れじゃないのか？
>>29
ですよね。コアはなるべくシンプルに！
で、話は変わりますけど、まあある程度の機能
（たとえばヤマト送り状CSV作成機能）は
アドインでプログラマが作ったプログラムを組み込むのは
仕方ないと思います。
でも商品の項目程度はプログラミング知識の無い運営者でも
管理画面から変更できたほうがいいと思うのです。
こういう場合どういう設計にしましょう？
１．データベーススキーマを動的に変更。
設計としてはシンプルだが、項目の追加・削除とかで問題でそう？
SQLのALTERにはRDBMSごろと制限がいろいろ。
２．商品項目テーブルを作る。
|商品コード|項目名|値|
|1 | タイトル | なんとか|
|1 | ISBN | 4798105538|
|1 | 価格 | 5800|
自由に項目を追加・削除できるが、パフォーマンス（特に検索時）悪そう。
３．商品項目ごとにテーブルを作る。
ISBNテーブル
|商品コード|値|
|1 | 4798105538|
検索自体は早くなるかもしれないが、
JOIN多すぎでパフォーマンス低下＆JOINの数制限に引っかかる。
どれもしっくりきません。 後で追加するようなもんは
そんなにモリモリ検索しないだろうから
辞書にでもしてシリアライズしてテキストにして、つっこんでおけば。
そもそもDBが本当に必要なほどの商品数があって、売り上げも上がるところなら
作ってもらってる。
楽天をみてもわかるがほとんどのところは商品100個以下。
>>32
本当にそうだろうか？
DBが本当に必要なほど商品数がある場合は
楽天とか使えずに、また既存のオンラインショップシステムじゃ
重かったり、使い勝手が悪かったりで、仕方なく作るしかない。
が正解では無いだろうか？ だれかzencartの改造３０万くらいでやらない？
>>34
安すぎ。学生にでもやらせればいいんじゃね？ >>34-36
どんなビンボー学生でも割に合う仕事と割に合わん仕事ぐらい見分けがつくだろ。 >>13
＞携帯サイトとPCサイトの商品DB連動
Zencart用だったらシェアウェアで出てる
＞佐川、ヤマト用、送り状作成ソフトにインポートできるCSV作成
エクスポートとインポートの区別つけてよ
＞詳細写真の枚数、自由指定
Zencartでも3枚ぐらい貼れる それで足らんかったらHTMLで書く
wysiwigエディタで画像URL指定で貼れるはず
＞アフィリエイト機能
要るか？ホントに勝てる商品ならA8とかに出したほうが良さげ
っていうかコレもシェアウェアで有る＞Zencart用モジュール
＞特別に作ったHTMLページも利用可能に
Zencartの1.3x系なら追加ページ書けたはず
それで足らんかったらXOOPSモジュール化されたZOXもある
＞３０万くらいで作って
とある会社はECと物流のデータ連動できるサイト構築で
イニシャル1900万
ランニング60万とるらしいが高いね
言語的にはPHPとMySQLで十分だな。楽天もそうみたいだし。
>>1
テンプレート編集機能もいるだろ。プログラマーはプログラムの部分ばかり
考えるが、デザイン面も考えないと、ユーザは食いつかない。 >>41
> テンプレート編集機能もいるだろ。プログラマーはプログラムの部分ばかり
> 考えるが、デザイン面も考えないと、ユーザは食いつかない。
一応これ↓に含めていたつもり・・・(´；ω；｀)ﾌﾞﾜｯ
> 5 名前：nobodyさん[sage] 投稿日：2007/08/19(日) 22:52:24 ID:???
> 柔軟なページ修正、特定の商品のページだけ
^^^^^^^^^^^^^
そういや前々から思っているんだけど、WYSYWIGエディタはあるけど、
CSSまで含めてWYSYWIGで修正できるものってないよな・・・？
俺としてはテンプレートをWYSYWIGで修正したい！（どうやって！？） CMS的な機能もいるよな。
オンラインショップのトップにきたら
決まったように、最近入ってきた商品とか
売れ筋の商品とか適当に表示。
それはそれで考えなくて良いから、便利な点もあるんだけど、
今月の○○特集とか派手なPOPをおいて、
さらに詳細な記事（コンテンツ）書いて、
そして商品の販売につなげるとかやりたいじゃん？
好きなページを作れるのはもとより、好きなブロックを作って
いろんな場所に埋め込める必要があるよな。
ついでに期間限定機能つきで。
http://xoops.ec-cube.net/modules/xoopspoll/pollresults.php?poll_id=2
あひゃ。要望ぱくりｗ
1位 12 % (135)
共有SSL対応
2位 12 % (127)
ダウンロード商品販売機能
3位 10 % (112)
納品書発行
4位 9 % (97)
ポイントシステムをON・OFF可能に
5位 7 % (81)
クーポン券を発行機能
6位 4 % (43)
合計金額に応じた代引手数料
7位 3 % (38)
ギフト対応
8位 3 % (35)
クレジットカード決済機能
9位 3 % (35)
アフィリエイト機能(1〜3段階ティアコミッション)
10位 2 % (31)
非会員購入の顧客管理機能
共有SSLって要望高いんだな デザイン面はどのレベルまで持って行けるんだ？
XOOPS以上の見た目は必要だぞ。
ズープスは最低クラスだな。
ワードプレスくらい自由度あるといい
>>45
さすがに最低限の機能としてテンプレートは使うので
テンプレート言語かできる程度の知識があれば自由自在。
フレームワークを使うので、必然的にそうなるわけだけど。
最終的には、Ajaxを使って自由にブロックを配置、移動させたいねぇ。 ところで格安共有サーバーで動かすことを考えるとPHPが一番？
suEXECがあるからセキュリティ的にPerlも気になってはいるんだけど、
あんまり流行っていない気がする。
それにPerl用のフレームワークって実質的にCPAN必須な感じだし。
（CPANは共有サーバーで使えないことも多い）
PHPを使うとしたら、CakePHPが今のところ一番勢いがあるだろうか。
CodeIgniterやAkelosも気になっている。
どれもPHP4でも動いて、PEAR必須じゃないよね？
(PEARも共有サーバーで使えないことがある。手動で入れるのも不可能ではないが
場合によってはかなり面倒なことがあるのでなるべく使わないようにしたい）
>PHPを使うとしたら、CakePHPが今のところ一番勢いがあるだろうか。
そうなの？ソースとかある？
>>50
別にかまわない。というか、
拡張モジュールでテンプレートエンジン切り替えられるようにするけど、
個人的には、PHPそのままでもシンプルな状態なら
テンプレートと本質的には変わらないと思っている。
<h1>{$text}</h1>
<h1><?php echo $text; ?></h1>
多少長くなる程度。
問題はビューの部分で複雑なコードを書くのが悪いのであって。 >>51
Smartyのページキャッシュ使ってDBの接続コスト
減らせばいいんだよ。
どうせ、PEAR使うといろいろと面倒だろ？ SmartyとかPEARとか使ったら、拡張性悪くなるんじゃないか？
>>1はオープンソースとして作りたい分けなんだから、
後からユーザが改造出来る形が良いだろ。
と言うわけで、純粋なPHPのコードだけでいいと思う。 このスレはご覧のスポンサーがお送りしております
提供：K.K.projects
>>56
いや、普及しているかどうかというより、
PEARのパッケージマネージャを
入れるにはシェルが必要でしょ？
と書いておきながら、go-pear.phpを
入れて普通に動いているような気もするんだけど・・・。
それでも、微妙に不安定な感じもする。よくわからない。
パッケージマネージャを使わないでPEARを入れるのは
経験が少ない人にとっては大変だし。
まあ、使わないでやれるのならそれに越したことは無い。 てか、あまり普及してるのもセキュリティ的に良くないんじゃないか？
それより独自で関数増やしていく方が、オリジナル性でると思う。
PEAR使うんなら、同梱しておけばいい。
ライセンス的に大丈夫であれば。
バカな提案していい？
携帯だけで、ショップ運営。
商品の管理や写真アップや顧客管理など
最初のシステム設置を除くほぼすべてを
携帯電話のみで行えるシステム。
もちろん携帯電話でPC用サイトが見れる
フルブラウザを使うわけではない。
バカらしい？ 俺もそう思う。だがしかし、
もしかしたらそういうのを望んでいる人がいるのかもしれない。
もしそういうASPとかあったら教えて。
今日、「ショップ運営者が自由に商品タイプを作れる機能」について
すばらしい発想がうかんだ。
この方法なら、いろんな商品タイプを作ったうえで、
なおかつ拡張モジュールによる柔軟な拡張を実現できそう。
あとは、検索・ソートをどうにかすれば。
数百、数千程度ならどう作っても問題ないとは思うけど
結構負荷高いだろうからなぁ。特にソートとか。
いろんな商品タイプを作ったうえで、どうソートさせるか
求められてるのは「かつて無い新機能」ではなくて
「既出機能の全部入り」だと思うなあ
多くの人の不満は「あのソフトにはAと言う機能があるけどBと言う機能が無い」
「このソフトにはBと言う機能はあるけど、Aと言う機能が無い」
あちらを買えばこの機能が立たずみたいなところに尽きると思う。
ここで要望を集めたソフトを作るのも良いけど、それだけだと
既存ソフトにはある機能を実装し忘れた新たな不満を抱えたソフトの誕生になりかねないから
ベースとしてトップシェアのソフト+トップシェアソフトの不満点解消
と言う目標設定があるといいと思う。
はなからこのスレの要望をほとんど満たしたものになるんじゃないかな。
そのジャンルで今トップのソフト買って使ってみてそのスレ見てくる。
※今だとネットショップ・オーナー２かな？
そうすると「後これさえあればとりあえず文句無いのにな」という意見が散見される筈。
つまりトップのソフトの不満を解消したのをサクッと出せば（まあ実際に作れたらの話）
ほとんどの人は満足すると思う。
逆に言えば今トップのソフトと同等以上の「全部入り」が作れないなら
使ってくれる人も少ないだろうから新たに作る意味はあまり無いような気がする。
1：トップシェアのソフトと同等の機能（パクリ上等）+不満点トップ5〜10箇所を解消
2：致命的なバグが無い+新OSやバグ修正にちゃんと対応してくれる。
この二点さえクリアできれば市販ソフトと同等の値段でも買う人多いと思うよ。
後、他ソフトからの商品データがまんま使えるとか自動変換とかあれば完璧かな
で、>>1さんは何で作るの？
PHPとMySQL？
どうせなら、PDO使ってMySQLとSQLite対応のものにしてよね
>>67レスどうも
> 「既出機能の全部入り」だと思うなあ
そうかなぁ？ osCommerce、Zen Cart、某シェアウェア、と使ったけど、
どれでも、なにかの機能をOFFにするんだよね。
たとえば、レビュー機能なんていりません。ってな感じで。あまりにも機能が多すぎると
初心者の人は使いづらい。管理しなくてはならない事が増えるから。
機能はつける。つけるけど、その大部分は拡張モジュールとしてつけたいんだ。
そして、どういう拡張モジュールの組み合わせでもちゃんと動く。
（現実には完璧にするのは不可能だろうけどなるべくうまくいくように）
そういう柔軟性を持たせたい。
残念ながらosCommerceやZenCartはこれができない。これはこのバージョンとの
組み合わせでしか動かない。またこれとこれは同じファイルを修正する必要があるから
（プログラムができない人には）両方同時に組み込めない。など。
> ここで要望を集めたソフトを作るのも良いけど、それだけだと
要望を集めるのは、実はその要望を実現するというよりか、その要望を後からでも簡単に組み込める
仕組みを提供したいから。だからそこ想定外の要望がほしい。この要望を実現するには
大幅な設計変更が必要じゃないか！と思うぐらいのものを先に洗い出しておきたい。
> 既存ソフトにはある機能を実装し忘れた新たな不満を抱えたソフトの誕生になりかねないから
実装し忘れたなら、その機能を拡張モジュールとして後から組み込めばいい。そういう風にしたい。
完璧を目指してもそれは無理。システムを一枚岩として作るから、あとあと機能を追加しづらくなって
これは○○が足りないといわれる。
> 後、他ソフトからの商品データがまんま使えるとか自動変換とかあれば完璧かな
そういうのはインポートモジュールで。需要があるのなら（自分を含めた）誰かが作るさ。 >>68
> PHPとMySQL？
> どうせなら、PDO使ってMySQLとSQLite対応のものにしてよね
PDOは使ったことないけど、いまざっと調べたところ、使わないという結論になるだろう。
その理由はPHP5以上じゃないといけないから。
PHP4の出番はまだまだあるとはいえ、サポートも打ち切られる（た？）みたいだから
切り捨てるというのも、悪くはない考えなんだが・・・。
今のところはCakePHPを使う予定。今仕事で使っているのがこれだから俺としては一番実績がある。
CakePHPならPHP4,PHP5でも動くし、データベースもMySQL、PostgreSQL、SQLite、他さまざまなRDBMSに対応。
CakePHPで決定ではないが、何かのフレームワークを使う。ただし、上のほうでも書いたが
PEARやCPAN(言語にPerlを選んだ場合）など入れづらい外部ライブラリに依存するもの。
入れるのにシェルを使用するものは候補外。なるべく多くの環境で動くものを使う。
さすがにRDBMSを使用しないで作るのはキツイが・・・。
フレームワークって大概（全部？）RDBMSを使うように作られているし。 これから作るのに死亡カウントダウンがいよいよ始まったPHP4かい
しゃーないじゃん。仕事で使っているサーバーがPHP4で
抜ける許可下りないんだから (T-T)
別にCakePHPならPHP4用として作る必要はないから
問題ないよ。普通に作れば勝手に対応している。
RedHat エンタープライズとかなんとかのどれかのバージョン。
PHP4が入っているわけだが、そのサポート期間まだまだあるから
たぶん今PHP4を使っているサーバー。しばらくはそのままだと思うよ。(T-T)
混乱とか客の都合とか考えずにずばっとアップグレードしちゃえば良いのに。
問題ないか？
新規にサバを契約しようとしたら、そろそろRHELは5になろうかと
いう時期だよ。
他人が使おうと思っても、契約できるレンサバがないって話になる。
このソフトで一気にPHP4からPHP5へ移行させるくらいの気概が欲しいもんだな。
ルート権限と鯖だけ売ったらどうだ。
あとはオンラインショップ構築ソフトの紹介だけ。
好き勝手やりたい奴が人様の作った環境を素直に使うとは思えん・・
要望を書きたいがなんか難しそうな話になってるから
辞退。
>>84
気にしなくていいと思うよ
このスレだって最初から小難しい話で盛り上がってたわけじゃないんだし >>84
かいてくださーい。お願い。
様々な業種に対応できる設計にしたいから
いろんな情報がほしい。
マイナーな要望であればあるほどうれしい。
（その要望を必ず取り入れるわけじゃないので注意） ところで前から気になっていたんだけどさ、靴とか服とか
ベースは同じで、サイズや色の違いがあるものあるでしょ？
あれって、商品コード（JANとか）はそれぞれ違うものなんだよね？
だから特に何ってわけじゃないけど。
オプションという機能をつけよう（つけられるようにしよう）と思う。
服とか買うとき、オプションでサイズを選べるとか
色を選べるとか、ジーンズのすそ上げするかとか、
オプションで値段が変わったり。
>>88
オプションじゃなく、当然カートについてる機能。 >>92
>>1は作りそうもないのに、伸びてるよな。
って立てたのは俺だけどｗ
一応予定を言っておくと、11月ぐらいから本格的に開始かな。
今の仕事（同じようなもの作ってる）が終わって
経験つんでから別設計（拡張性・汎用性重視）で作る。
それまで、要望聞いて設計中。
>>91
了解。お勧め機能だね。そこらへんは単純なHTMLから
複雑なphpコードまで、ブロックというかガジェットというか
そういうパーツにして、好きなところにおけるような設計にするつもり。 方向性としてｌベッキーとかＷＩＮＡＭＰみたいなのを作るわけか。
アウトルックのスパムメール一括登録できない。
見たいな、なぜその機能がないんだ？みたいな事あっても
1の言うようにプラグイン誰かが作るところがソフトメーカー品よりある意味安心できるところだね。
鶏と卵の関係で
素の核のソフトがそれなりに使えないとプラグインを作る人も少なくなるだろうから、
1の優先順位選択のセンスにwktkする。
あ、分かると思うけど一応訂正。
1の優先順位選択のセンスにwktkする。
↓
1の要望を取捨選択するセンスにwktkする。
スキンというのかテンプレートというのか、外観デザインは変更しやすいのが良いね。
EC-CUBEの3rdパーティ製テンプレートをダウソしてみたけど、何でファイルが500個以上あんのかとorz
でさ。ブロックと言うかガジェットというか、
好きなパーツをおけるようにすると、
どうしても外部のWebサービスをおこうとするよね？
それ自体は別にいいんだけど。
そういうことをするとセキュリティ上のリスクがある。
詳しく言うと、外部のWebサービス（JavaScript）を実行するため
そこが信頼できないサイトだとcoockieを奪われたりする。
ここを気をつけないといけないな。
httponlyを使ってcookieをJavaScriptから読み取れないようにする。
iframeをうまく使う。ログインページなどには外部のWebサービスなどを
入れられないようにする。うーん。他にあるだろうか？
>>96
フレームワークを使うとビュー（見た目）は分離されているので
それだけでもある程度は変更しやすい。CSSも使うし。
ただ、もう一段階上がほしいよね。
理想としては管理画面からデザインをGUIで変更したい。
CSSはデザインを変えやすいけど、やっぱり素人が使うものじゃない。
まあ大変だろうなぁ。
ファイルはなるべく少なくする方向で。格納場所は一箇所で。
俺も嫌いだよ。ごちゃごちゃ沢山あるのは。
ホームページビルダーとかで作ったHTMLを変換して使えるようにするのもありか？ >>99
出力する（X)HTMLがちゃんと考慮されており
classとかがきちんと設定されていれば、がらりと変えることは可能。
(X)HTMLがちゃんと考慮されていればCSSだけで、
1カラム、2カラム、3カラムのレイアウトに変えることも可能。
でもやっぱり限界あるよね。どうしても同じようなデザインになってしまう。
技術的な限界というか、汎用性のある(X)HTMLにしようとすると、
むしろ人間的に、うぎゃーってなってくる。
あー。それでも、デフォのXHTMLを用意して、(もちろんvalid)
CSSである程度は変えられるように作るけどね。 間抜けなﾂｯｺﾐｽﾏｿ
POSレジdata => PC data => web data => PC data 在庫管理autoなもの
tech.自慢なprogは、オンライン店舗運営者を選んでしまう。
敷居が低ければok
> POSレジdata => PC data => web data => PC data 在庫管理autoなもの
PC dataがなんのことかわからんが、
CSVでファイルアップロード＝> web data =>Web上で在庫管理 もしくはCSVファイルでダウンロード
なら考慮事項に入っている。
ただCSVファイルといっても、そこに含まれるデータは決まった形でないといけない（決まったフィールドがないといけない）
だからPOSレジのdataをそのまま使えることはないし、外部の在庫管理ソフトでそのまま使えたりはしない。
一度変換が必要になる。業界共通のデータ形式というものが存在しない（はず）のだからこればかりはどうしようもない。
有名なPOSレジや在庫管理ソフトなら、それ専用の取り込み・出力ツールやデータ形式変換ツールが作られ、
場合によっては付属するかもしれないけど、少なくとも俺は有名なPOSレジや在庫管理ソフトがあることを知らないな。
あったとしても、それが手に入れにくいもの、金がかかるものなら俺は作らない。俺以外の誰かが作る可能性はあるだろうけどね。
あと念のためにいっておくと、excelファイルを直接アップロードしたりには対応できないよ
（対応しないのではなく、対応することができない）
なぜならexcelファイルはデータ形式が柔軟すぎる上に、内部形式が非公開だから問題を起こさないようにするのがきわめて難しい。
phpでexcelファイルを読み書きするライブラリはあるがこれも完璧ではなく、特に日本語がはいっていたり、
セルを結合したりいろいろ変更していると不具合が発生する。まあexcelでCSVファイル扱えるから、問題ないと思うけど。
>>103
> tech.自慢なprogは、オンライン店舗運営者を選んでしまう。
どのソフトをさしてtech.自慢なprogといっているのか知らないけど、
tech.自慢なprog と オンライン店舗運営者を選んでしまう ことには
なんの関係もないよ。
tech.自慢をしているわけじゃないが、オンライン店舗運営者には、
オンライン店舗なりの最低限の知識は必要。
FTPに関する知識とかSSLに関する知識とかバックアップに関する知識とか
もし、その程度の最低限の知識も持たずに、このソフトは難しい。
tech.自慢しているだけだ。と思っているのならお帰りください。 tech.自慢なprog で使いにくいソフトはあるかもしれないが、
少なくとも、使いやすいソフトというものは、tech.自慢なprog でないと実現不可能ですから。
■■■■■■■■■■■■■■■■■■■■終了■■■■■■■■■■■■■■■■■
ところで会員機能など個人情報を取得する場合
SSL必須でいいかな？
>>110
どこの常識だよｗ
GETであってもURLは暗号化されるっちゅーの >>109
いいんじゃね？
個人情報は暗号化されないといけないものだし、
SSLも使っていないショッピングサイトは失格。 >>113
・最近作り始めたくせにEUC。
・設計が古臭い。フレームワークが使われていない。
･ソースコードのSQL文がうざい。↓こんなコード嫌い。
// postgresqlとmysqlとで処理を分ける
if (DB_TYPE == "pgsql") {
$order_id = $objQuery->nextval("dtb_order","order_id");
}elseif (DB_TYPE == "mysql") {
$order_id = $objQuery->get_auto_increment("dtb_order");
}
・多言語対応さが感じられない（日本語メッセージ埋め込み。メールのヘッダにiso-2022-jpという文字を直書きなど）
・共有SSLに対応していない。
・JavaScript OFFで買えない。
・なんとなくソースコードに不吉なにおいを感じる。文字列連結いっぱいだし、
たとえば非表示商品（管理画面でのみ見れる）でも、urlにadmin=onをつけると見れちゃうわけだが良いのか？
でもまあ、全体的に物は良くできてるんじゃない?
これだけの機能を作るには相当時間かかるし、このままの仕様（＋少しソースコード修正）で
使えるという店なら、osCommerceやZenCartの代わりに使うというのはありでしょう。
でもやっぱり、一枚岩。いろんな機能が絡み合っていて、何か機能を追加、削除しようと思ったら
ソースコードに手を加えなければ行けない。これでは俺が求めるレベルの柔軟性は達成できないだろう。 あー。ほーらいわんこっちゃない。
あんなに文字列連結していると絶対入り込むんだ。
しかもJavaScript盛りだくさん。
ちょっと通報してくる。
少し期待してスレ見たけど、開発プロセスが甘いんじゃない？
SSL必須とか、気持ちは理解できるけど意味不明で、
ナニゆえ必要か明確でない機能は、開発初期で盛り込まないほうがいい。
というか、SSL利用部分(追加機能)は積極的にモジュール化すべきじゃね？
納品先が決まってない場合の利用サイドでは、必ず、
「とりあえず動かす」という要求があるはずだし。
# ZenCartのインストーラを思い出してくれ
それ以前の開発ポリシの話題だが、要件定義をしっかりやって、
実現可能性に近似な言語とフレームワークを使うのがよさげ。
DOM、BOMを利用しようと思えばJavaScript利用も仕方ない。
サーバサイドMVCとクライアントサイドMVCは下手に混在させないで
別けて考えた方がいい。
SSLとJavaScriptの考え方だが、
未だにWin95/98ユーザは馬鹿に出来ない数が居るし、
機能的クレーマの大半はコイツ等だったりする。
# Win98なんだけど、どおやったら良いの？
# ．．．みたいな、ダメっぽい前提をそもそも知っている顧客
こういう低レベルなリテラシしか持たないユーザに対し
どのような誘導策を考え、実現するか、が、
-互換性の無いJavaScriptを排除する
-SSLを必須としない(または、54bitSSL 対応、非SSL 許可)
という考え方に結びついている。
# 古いMacのIE5.2とか、普通に使うヤツの神経を想像してみてくれ
もちろん、対応OS、ブラウザを指定するのは重要だと思うが
アプリ機能の実現可能性とは直接的に関係が無い。
なんかえらそうに低レベルとか語ってるけど、結局大した事言ってないよなｗ
なんかえらそうに語ってみたが、どんなレベルの情報が必要だったんだい？
＞未だにWin95/98ユーザは馬鹿に出来ない数が居るし
いつのネタだよ。
すでに無視していい5%を切ってるよ。
> 少し期待してスレ見たけど、開発プロセスが甘いんじゃない？
開発プロセス？ なんのこと？開発なんてまだ行われてないけど？
> SSL必須とか、気持ちは理解できるけど意味不明で、
> ナニゆえ必要か明確でない機能は、開発初期で盛り込まないほうがいい。
何ゆえ必要かって、それはお客さんの個人情報を守るためだよ。
> 納品先が決まってない場合の利用サイドでは、必ず、
> 「とりあえず動かす」という要求があるはずだし。
冗談はやめてくれ。どんな納品先であれ、”会員機能など個人情報を受け取る場合は”
通信内容の暗号化は必須だろ。「とりあえず動かす」なんて素人のシステムだよ。
> DOM、BOMを利用しようと思えばJavaScript利用も仕方ない。
BOMってなんだ？爆弾か？ それはさておき、
それこそ「ナニゆえ必要か明確でない機能」であり
積極的にモジュール化すべき部分だろ？ 言っていることが矛盾してるぞ。
> SSLとJavaScriptの考え方だが、
> 未だにWin95/98ユーザは馬鹿に出来ない数が居るし、
> 機能的クレーマの大半はコイツ等だったりする。
JavaScriptは使わないほうが、より多くの人に対応できるんだが？
SSLに関しては、古いブラウザでも対応しているわけで、必須だからといって、
Win95/98ユーザが見れないことにはならない。他のシステムだが、IE5.01でもテスト済み。
オンラインショッピングで一番重要なこと。
それは運営者の都合や無知のために、脆弱なシステムで運営することじゃないのか？
一番重視するのは顧客の安全、個人情報を守ることじゃないのか？
運営者が無知なのは、まあ仕方がない。だからこそ安全側に倒したシステムであるべき。
そうは思いませんか？
どうしても納得がいかないのなら、オープンソースなので、
勝手に危険なシステムにダウングレードしてください。
あぁ、BOMってBrowser Object Modelのことなのね。
そこは俺が知らなかった。すまん。
サイト運営者からしたら、
「SSL？それなんのこと？難しいことわかんない。
とりあえず売れればいい。」なのだろうが、
そんな客のことを考えないやつが、ネットショップなんてやるなと言いたい。
そもそも、SSLなんてオープンソース提供者側が、考慮する物なのか？
>>127
うん。当たり前。
まあ、ウェブサイト全体をSSLする、つまりhttpsにで始まるURLしか
存在しないのなら話は別だが、Amazonとか見ればわかるように普通はあまりしない。
SSLはサーバーの負荷が高いからね。重いサイトになってしまう。
ついでにいうと、ウェブサイト全体をSSLにするを選んだ場合、共有SSLだとせっかくドメインとっても
全部が https://レンタルサーバーのドメイン/自分のドメイン/ ってなるから悲しいぞｗ
さらに技術的な話になるが、共有SSLだとドメインが違うため、別サイトと認識されセキュリティ上の理由で
cookieを渡せないためセッション（同一人物であるか）を保つのに一工夫しないといけない。
でないとカートに商品を入れていって、いざ住所などを入力する共有SSL画面になるとカートが空になっちゃう。 >>128
よくわからんが、SSL対応のページと非対応のページのURLを
初回セットアップの時にDBに登録して、
決済が入る部分はそのURLを参照する、のは駄目なのか？
俺は普段そうしているけど。もっと考えなきゃいかん話しなのか？ ひとつ足りなかった。
共有SSLでなく、独自SSLの場合で、httpとhttpsが混在する場合、
Amazonなどの大手が使っている方法。
これは対応するのは、比較的簡単なんだが、
それでも、httpでのアクセスで送ってもいいcookie、
httpsでのアクセスでしか送ってはいけないcookieにように
ちゃんと考慮して作らないといけない。
いずれにしろ、難易度の大小はあれ、ソフト開発者が
考慮しないといけないということ。
ちなみにhttpとhttpsが混ざるサイトでの共有SSL対応は一番難易度が高いです。
>>129
そりゃ、設置する人はそれだけでいいいけど、
それだけでいいように作るのは大変なんだぞ。
車走らすのには、アクセル踏めばいいだけだが、
アクセルを踏んだら車が走るような
仕組みを作るのが難しいのと同じで。
ここはWebProg板。作る人たちの板ですので。 >>131
作る側の意見で答えているんだが、間違っているのか？
他のオープンソース見ても、そうしてると思うんだが。 >>132
あんたの意見は、公開されている
スクリプトをダウンロードして
サーバーにアップロードして
簡単な設定をしてインストールしているだけだ。
それ以外のなにをやったことがある？ >>133
あんた、何が言いたいか良くわからんのだが、
SSLに対応させるべきか否かというのが論点だろ？
で、俺は>>129みたいにすればどうだ？っと答えたわけだ。
それに対してソースをみてダウンロードしたとかどうとか言ってるが、
そういう問題なのか？ていうか、オープンソースのシステム作るのに、
今まで誰もやったことのない方法でシステムを組むべきなのか？ > あんた、何が言いたいか良くわからんのだが、
そりゃそうだろうねぇ。内部の仕組みを何もわかってないでしょ？
>>129みたいにするって意味不明なんだが。
お前、ユーザーがSSLのアドレスを設定すれば
それだけで、勝手にSSL対応が完成すると思ってるだろ？
>>135
もしかして、あんたの言うのは「サーバのSSL機能を使いましょう」
ではなく、「システム側でSSLの機能を持ちましょう」
と言うことか？俺は前者だと思ってたんだが、後者なら読み違えた。悪かった。 >>136
つかれるやつだな。本来なら話ができる最低レベルの知識に
達していないから出てくるなといいたいところなんだがな
> 「サーバのSSL機能を使いましょう」
そういう意味だよ。
HTTP（HTTPS含む)というのはセッションステートレスなの。
つまり、一度目にアクセスした人と二度目が同じ人であるかわからない。
サーバーから見れば、誰かがカートに商品を入れた。誰かがカートを見た。
ということしかわからない。カートを見たのがAさんなのかBさんなのかわからない。
それを区別するために（他にもあるが通常は）クッキーを使う。
最初にサイトにアクセスしたときにセッションID（管理番号）を発行する。
その管理番号によってカートを見たのがAさんなのかBさんなのか区別している。
逆に言えば管理番号が奪われてしまえば他の人になり済ませてしまう。
そのためにSSLを使う。SSL使った場合、通信内容が暗号化されるから、
通信を傍受しても管理番号はわからない。
しかし、Amazonがそうであるように、常にSSLを使っているわけではない。
SSLを使わない状態でカートに商品を入れている。SSLを使わない以上管理番号が傍受される。
はい、ここからで問題。管理番号が盗まれます。さてどうやってこれを解決しているのでしょうか？
あなたがプログラマならここからが、あなたの仕事です。やってください。 まぁ、大きな問題じゃないだろ。
開発途中でいくらでも変更可能だし
>>137
>つまり、一度目にアクセスした人と二度目が同じ人であるかわからない。
ホスト名かIPアドレスを保存するのは？
>>はい、ここからで問題。管理番号が盗まれます。さてどうやってこれを解決しているのでしょうか？
お前はSSLは「サーバの機能を使う」っと答えたよな？
じゃ、サーバの機能（SSL）を使わない奴の面倒まで見るのか？
また、管理番号の件だが、ログイン毎に新しいセッションIDを発行すれば？
Amazonの例ならログインするのはメルアドとパスワードが必要だ。
その時にアクセス用のセッションIDを発行する。
顧客情報にはセッションIDを保存し、そこから顧客情報を参照する。
当然ログアウト後はセッションIDが消えるから、例えセッションIDが
盗まれたとしても、他人がそれだけでログインすることは出来ない。 > ホスト名かIPアドレスを保存するのは？
ﾎﾟｶｰﾝ。
むしろ、それではだめな理由を二つ以上答えなさいのネタだろｗ
>>140
がんばって調べてきたんだろうなぁ。
> お前はSSLは「サーバの機能を使う」っと答えたよな？
> じゃ、サーバの機能（SSL）を使わない奴の面倒まで見るのか？
まーた、的外れなことを言う。Amazon見たか？
SSLを使うページと使わないページがあるんだよ。
客が使わないんじゃない。システム的に使わないページがあるの。
> また、管理番号の件だが、ログイン毎に新しいセッションIDを発行すれば？
はいそうだね。それじゃ次いこうか？
ログインした。新しいセッションIDを発行した。
その後で別の商品をカートに入れるために、
ログアウトせずに、非SSLページに移動した場合どうするか。
カートに入れる処理は、非SSLページという設計なのだから、
当然それは傍受される。
プログラマってのはね、君が考えているよりも多くのことを考えているんだよ。
つぎの、あなたの仕事です。
当然それは傍受される。
↓
当然新しいセッションIDは傍受される。
>>141
駄目な理由。
みんな固定IPじゃないから。必ずしも同じPCからアクセスするわけじゃないから。
>>142
Amazonみてねぇよ。調べてねぇし。
てかな、俺が知識不足なのは認める。お前の方が偉いわ。
でもな、そこまでSSLにこだわる必要あるのか？ってのがいいたいわけ。
突っ込んでるのも俺だけじゃないだろ。 >>143
特定時間を過ぎると、保持されているセッションIDが有効とならない方法もあるね。
で、「当然傍受される」って言うけど、実際に傍受される確率はどのくらい？
あんたみたいなプログラマ様が余計な機能付けるお陰で
コストや手間が増えまくるって予測できないかな？？？ > でもな、そこまでSSLにこだわる必要あるのか？ってのがいいたいわけ。
こだわらないという考えもいい。
ただし、それはSSLをちゃんとわかっている人だけが言うことを許されるセリフだ。
知らないやつが言って良いセリフではない。
>>146
> で、「当然傍受される」って言うけど、実際に傍受される確率はどのくらい？
それは、SSLを全否定していることにつながっているわけだが
わかっているか？
> あんたみたいなプログラマ様が余計な機能付けるお陰で
> コストや手間が増えまくるって予測できないかな？？？
客の個人情報を守るためのコストをかけたくないと、そういいたいのですか？ >>147
>知らないやつが言って良いセリフではない。
うんそうだね。じゃ、オープンソース使いたい奴、ひいては利用ユーザは
君ぐらいSSLに長けている人間なのかな？？
他のレスでもあったけど、「別にSSLなんて関係ないぜ」みたいに
思っている奴の方が多いだろ。あんたは単に自己を押しつけてるだけ。
高い金出してベリサインと契約して、そんなに効果あるとはおもえん。 >>148
全否定はしないが、疑問視はしてるな。
>客の個人情報を守るためのコストをかけたくないと、そういいたいのですか？
コストをかけるのは俺ではなく、カート設置者だろ？
設置者がいらないと思えばいらないだろ。 > うんそうだね。じゃ、オープンソース使いたい奴、ひいては利用ユーザは
> 君ぐらいSSLに長けている人間なのかな？？
なにが言いたいのかわからん。まあ、SSLに長けている人間ではないだろうな。
SSLに長けている人間ではないから、○○○←ここにどういうセリフを入れるつもりだ？
> 高い金出してベリサインと契約して、そんなに効果あるとはおもえん。
安い共有SSLでいいだろ。
もう寝るからSSL信者様にひとつ。
あんたは利用者、金出す奴、実際に設置しようと思う奴の声に
もう少し耳を傾けた方が良い。家でパソコンばっかりしてないでさ。
実際に会社で客と打ち合わせする奴らならわかるだろ。
SSLなんて大抵疑問視されてるよ。どんだけ必要性を説いてもな。
それでも「あればいいや」って言うぐらいな気持ちで付けるんだ。
どうせSSL付けても流出する時はする。大手を見てみろ。
ま、SSLにこだわればいいさ。SSLを導入してないと
使えないぐらいなシステムにすればいい。そんなの誰も使わないだろうけどな。
>>150
> コストをかけるのは俺ではなく、カート設置者だろ？
> 設置者がいらないと思えばいらないだろ。
つまり、客の安全よりも、店の利益。
それも、年、たった数千円程度を優先するといいたいのだな？ >>152
> あんたは利用者、金出す奴、実際に設置しようと思う奴の声に
> もう少し耳を傾けた方が良い。家でパソコンばっかりしてないでさ。
あんたは、オンラインショップを運営するのなら、
そこで買う客のことを考えたほうが良い。 >>152
SSLが疑問視されているというのなら、
その証拠を挙げてもらいたい。
SSLをつけていても流出するという理屈は、
それは、シートベルトをつけていても交通事故を起こすといっているのと同じ
それでシートベルトはするべきじゃないという理由にはならんだろ。
つまりへ理屈だ。
> それでも「あればいいや」って言うぐらいな気持ちで付けるんだ。
それはSSLを理解していないからだ。 たまーにいるよな、SSLイラネっていうヤツ。
実際SSL導入してなくて事故ったっていう事例が少ない（ない？）からだと思うが、
起きてからじゃ遅いって事が何故わからんのか。
SSL利用しないでオンラインショップの経営なんて
自動車保険に入らないで運転してるヤツとなんら変わらん。非常識そのものだ。
SSLについてこれだけ語りながら、メールはどうしてるんだろうなｗ
公開カギ使ってんだろうな？
メールはメールでちゃんとやればいいだけの話だろう。
メールに関しては別件であり、いま語る内容ではない。
論点をずらそうとしているな。
それとも、ショップを利用するお客様の個人情報を守るための
ショッピングシステムの設計について語りたいのかな？
それならそれで意見を言おう。
基本的にメールで個人情報は送らない。
メールで送るのは「注文された商品を発送しました」など
（具体的な内容は店のポリシーによる）
そして、メールのに詳細を確認するにはコチラをクリックしてください。
とかき、当然その先はSSLで暗号化された顧客情報ページ。
define("SSL_URL","http://hoge.com/");
//define("SSL_URL","https://hoge.com/");
みたいな感じでどっちでもOKにしておけば問題ないんだよ。
もっと柔軟になれよ。
セッションはsession_regenerate_idやっておけば、完ぺきではないが
危険性は減る。それでもうだうだ言うやつは自分で作ればいいじゃない。 >>159
だれが客との間のメールの話してんだよ。
鯖と運営者の間の話だ。 >>160
それは、httpsのアドレスを設定しているだけであって、
肝心の処理が書いて無いんですが？ >>161
サーバーの運営者の間でも同じだろ。
メールで（客の）個人情報を送受信しない。
個人情報を扱うときはブラウザからやればいい。
っていうか、サーバーと運営者の間に
メールなんてつかわないでいいだろ。
注文が入ったって知らせてほしいのなら
メールの内容は「注文が入りました」だけでOK >>160は、定数SSL_URLを設定すれば、それだけで、
どんなソフトでもSSLの対応が完了するって考えてるんだろ？ｗ
ところでSSL_URLでググるとEC CUBEばっかりでてくるなｗ >>162
処理？HTTPもHTTPSも処理は同じだろうが。
>>164
実際問題そうだろ。HTTPSに渡せばSSLじゃん。 >>165
お前ダメダメじゃん。
>>137でも読んでから出直してくれ。
ヒントをあげると、確かにhttpsページにアクセスすれば
そのページに限っては暗号化される。
しかし、多くのオンラインショップでは、ある理由により
カートに入れるときはhttp、決済の時はhttpsと使い分けている。
カートに入れるときと決済時のセッションIDは同じでないと
同一人物であると区別できない。
セッションIDが漏れると大変なことになる。
カートに入れるときと決済時のセッションIDは同じと言うことは
決済時には漏洩の心配が無くても、カートに入れるときに漏れる。
ここまでいえばわかるよな？ 顧客管理機能が無い、小規模向け
ショッピングカートCGIレベルの話してるんじゃねーの？
顧客情報を入力したらメールで運営者のところに送られてくるだけ。
そう考えれば、メールの話を持ち出してきていることも説明がつく。
想定している規模がぜんぜん違うから話がかみ合わないわなｗ
>>165
おまえこそ、大丈夫か？
session_regenerate_id()で再生成も引き継ぎも可能なんだぜ。
PHPのセッションについて10回読んで顔洗って出直してこいよ。
くそむし。 >>168
で、お前、それを使った、サンプルコードかけるの？
当然、どのタイミングで、session_regenerate_id()を
実行するのかぐらいは答えられるよね？ >>168
サンプルコードってｗ 1行だろうがｗ 頭悪すぎｗｗｗｗ
カート操作の度に再生成と破棄をしておけばいいんだよ。クズ.
HTTPSになってからは念のため、入力操作(POST)があった後、再生成しておけ。
これでカートを乗っ取る荒業できる奴なんてほとんどいないよ。
>>171
バカじゃないの。
おまえは1回もセッションIDを付加させちゃいけないとでも思ってるのか？
生き方反省しろ。
>>170
頭が悪いのはあんたですね。
毎回発行するのなら、
httpのセッションIDを奪った人が、本人よりも早く
httpsページに入るだけで、簡単に個人情報奪えますね。
それともhttpsに入るたびに毎回パスワードを要求するように
するつもりですか？ カートと決済ページを行き来するたびに
パスワード。使いにくいショッピングサイトですねｗ
それからPOSTにしようが何の関係もありません。 >>173
session_regenerate_id()の一行を発行するだけと貴方は言いました。
ドメインが違うと、セッションIDが送られてこないのに、
session_regenerate_id()の一行だけでどうやって対処するつもりですか？
> define("SSL_URL","http://hoge.com/");
最初は、これだけやればいいといっていたわりに、
どんどんコードが複雑になりそうですねｗ クッキーで商品情報を保存。
sslに入るときはPOST。
認証はsslに入った後に行なう。
まったく、セキュリティが簡単なコード一つでどうにかなるわけないだろｗ
SSL_URLだって、session_regenerate_id()だって、
セキュリティを保つための一連のコードの中で使う一行でしか過ぎないんだよ。
>>177
そうそう。そういったコードが必要。
まだ足りないけどね。
一行、二行でできるもんだいじゃない。 やれやれ、何年前の話してるんだか・・・
オナニーばっかでコードも書けない屑ばかりじゃねぇかｗ
共用SSLだろうが、セッションID付加させれば問題ないんだよ。
>>181
そんな大量の資料出したら、
SSLのアドレスを設定するだけ
session_regenerate_id()実行すればいいだけと
言っていたやつが泣く >>181
あと、それらに加えて共有SSLではドメインが一致しないため
単純にcookieだけでセッションのやり取りが出来ないって問題があるね。 Web制作の料金はいくらが妥当？7案件目
http://pc11.2ch.net/test/read.cgi/hp/1189071609/50
50 名前：Name_Not_Found[sage] 投稿日：2007/09/08(土) 21:52:59 ID:???
>>35-36
いいか、冷静に考えろ。試しに15の内容をWebPro板でも持っててみろ。
「お前、10時間もかかるのかよwww」って笑われるのがオチだぞ。
今やフレームワーク使って、既存ライブラリもあるだろうし、
管理画面のデザインもあらかたCSSで基礎は作ってるだろ。
仕様書はディレクターが客から要望聞いて作ってくるだろ。
15程度の内容なら、要件定義も少ない。DB構造すら既存の構造でOKだろ。
煽る前に冷静に考えろって。15程度の案件、どう考えても3桁いかん。
学生PGがバイト感覚でやるレベルだろ。
スレ違いではあるんですがオンラインショップがらみということで
こんなことをいってるちょっと面白い奴が上のスレにいるんで遊びにきてください。 1回作ったら、2回目以降ははやくやすくできるのは当たり前。
それやって稼がないとソフトハウスはおいしくないわな。
当たり前だが客に安くしないよ。ｗ 内部的に安くあげるという話。
それは当たり前だが、10時間とかアフォだろｗ
1から作るって事は、たいてい何かやりたいことがあるわけで、
その打ち合わせだけでも（ｒｙ
こいつはhttpsにしたら自動的にSSLになると思ってるに違いない！
いや、httpsにしたらそのページに限っては自動的にSSLにはなるが、
SSLを使っていても、ちゃんとした使い方でないと情報を防げるわけじゃないし、
その状態でセッション管理やら共有SSL対応やらhttpとhttps間の
情報のやり取りを、安全に行うするには、それなりに大変ということ。
タイムリーだなーｗ
SSLを使っていても、ちゃんとした使い方をしないとこういう問題がおきると。
っていうか、Google、Microsoft、Yahooもアウトかよ。
世の中ダメダメジャンｗ
Googleなど大手サイトのcookie転送に問題発覚、認証かわされる恐れ
http://www.itmedia.co.jp/news/articles/0709/10/news007.html
それによると、cookieを使って認証を行っているWebサービスの中には、
最初にユーザーネームとパスワードを入力してログインするときには
暗号化されたhttpsセッショャ唐ﾅ認証用cookieを設定していても、
セッション全体が暗号化されておらず、その後そのcookieをhttpで
転送しているサイトがある。 共有SSLなんてものがあるんだな。昔はこんなものなかったよね？
で、自分なりに調べてみたけど、これってシステム開発者
にとっては面倒このうえないな。
SSLそのものの存在意義も犯されるような気がするんだが、
そのあたりについて考察してるような記事とか、
どこかにころがってないかね？ちょっと見つけられなかったので。
個人的には、少なくともセキュリティが気になるのであれば
共有サーバ上でオンラインショップをやること自体があり得ない
んでは？と思う。「共有サーバ上でオンラインショップやりたいから
共有SSL対応してよ」というのはセキュリティ意識が
高いんだか低いんだかよくわかんないな。
共有SSL自体はかなり前からあるきがするよ。
本当に面倒きわまりない。しかし、EC-CUBEでも共有SSL対応が要望第一位だったりする・・・
> SSLそのものの存在意義も犯されるような気がするんだが、
本当にｗ でもSSLも取ろうと思ったら簡単に取れるようだし、独自SSLも今となっては
存在意義が薄れてるきがするね。そしてEV-SSLなんてものも出てきた・・・。
高いんだよこのやろう。そのうち、金が出せる大手はEV-SSLが標準になって、
中小企業のSSLは注意扱いにされてしまいそう。誰か裏で糸引いて無いか・・・？
話は戻して共有SSLだけど、これ本当に厄介だよな。
でも、ちょっとアクロバット的なことをすることになるだろうけど、
httpとhttpsが混ざっている独自SSLサイトと同レベルのところまではいけそうな感じ。
ドメインにレンタルサーバー名が入る所はもちろんどうしようもないけど。
（というかドメイン名がこんなんで変に思わないんだろうか？詳しくない人は
ドメイン名なんて気にしない。詳しい人は共有SSLだとわかる。ということだろうか？
> 個人的には、少なくともセキュリティが気になるのであれば
> 共有サーバ上でオンラインショップをやること自体があり得ない
> んでは？と思う。
まったく持ってその通り。でも専用サーバーにすると、サーバー管理者
もしくはマネージメントサーバーにさらに金がかかる罠。
> 「共有サーバ上でオンラインショップやりたいから 共有SSL対応してよ」
小さい突っ込みだが、共有サーバーでも独自ドメイン＋
独自SSL（普通は別途費用がかかる）は使える。
金が無いところは、素直に楽天とかASPでもを使っていてくれと言うところだが、
それなりに使えるショッピングカートがオープンソース（無料）であるばかりに・・・
>>190
超正論だけど、共用でショップやるのは許してやってくれ。
EV-SSLなんていうものもあったのね。
時代についていってないなorz
まぁ、ぱっと見は、共有SSLで
>ドメインにレンタルサーバー名が入る所はもちろんどうしようもないけど。
>（というかドメイン名がこんなんで変に思わないんだろうか？詳しくない人は
>ドメイン名なんて気にしない。詳しい人は共有SSLだとわかる。ということだろうか？
有名なレンタルサーバ名（？）であるなら
それを見て「あぁ、共有SSLに飛んだのか」とわかるだろうってこと？
えっ、ちょいとおまいさん。。。
第三者にとっては、
共有SSLサイトなのか
フィッシングサイトなのか区別がつかない
ってことも意味してるのかい？
であるなら、恐るべし共有SSL・・・
>> 「共有サーバ上でオンラインショップやりたいから 共有SSL対応してよ」
>小さい突っ込みだが、共有サーバーでも独自ドメイン＋
>独自SSL（普通は別途費用がかかる）は使える。
当然そうですよねorz
>>192
あっ、すんません。
実地では正論が常に通用するものではないとは
わかってるつもりです。
共有サーバー上のショップを全否定するつもりはありません。
どのような方法であろうとメリット、
デメリットあるでしょうし。
ただ、共有SSLの可能性というか限界を知っておきたいな
という気がしたものですから。
共有SSLの限界。簡単なところから。
・独自ドメインでhttps運用できない。
・レンタルサーバーのドメインでいいのなら、すべてhttpsで運用することはできる。
（つまり、https://レンタルサーバーのドメイン/自分のフォルダ/ 以下のみで運用)
・レンタルサーバーのドメインでいいのなら、httpとhttpsが混在するサイトを、
独自ドメインの場合と同じように運用できる。
（つまり、http://独自ドメイン/ と https://独自ドメイン/ というよくあるhttpとhttpsの混在構成は、
http://レンタルサーバーのドメイン/自分のフォルダ/ と https://レンタルサーバーのドメイン/自分のフォルダ/ の混在と同等）
結局のところ、http://独自ドメイン/ と https://独自ドメイン/自分のフォルダ/ というドメインが違うものの混在が
http://独自ドメイン/ と https://独自ドメイン/ の同じドメインでの混在と同レベルのセキュリティを
達成できるかという話になるかと思うがどうだろうか？ けっきょくなんも作ってない口だけ野郎だったってわけか
あと、携帯からだと、共有SSLはダメである場合が多いね。
>>198
ベリサインかジオトラストなら大丈夫だけど、安いのは難しい。 別に最初から完璧なモノを作る必要は無いんじゃないの？
まずは簡単にオンラインショップ（的な何か）を作れる所から始めて
ｾｷｭﾘﾃｨやその他問題は、後から頑張るって方向で。
設計的に問題がある場合は後から一度大破壊して1から作り直し。
いつまでもスレ消費して議論で10スレ使うよりその方が早い
>>199
ジオトラストは、ドコモ以外があやしくね？
っちゅうか、ベリサイン以外は、対応が端末でバラバラだからな。
金額でいくとthawteのSGCだけど、海外送金になるし。 >>201
まぁ、あいまいな部分はあるよ。
auはたぶんジオトラストは大丈夫なはず。
しかし、au端末はSSLページを強制的にShift_JISに変換してしまうのが難点だな。 唐突だが、ページ変移ってユーザーフレンドリーにしようとすると難しいな。
トップページ
↓
検索結果ページ（あるキーワードでの商品一覧）
↓
商品詳細
↓
カートに入れる
↓
さっきの検索結果ページ（あるキーワードでの商品一覧）
一見簡単そうに見えるが、商品詳細ページのURLに
検索クエリーの情報が入る（つまり同じ商品詳細ページが
いくつもあることになる）とか商品詳細ページを開いたまま
新たな検索をしたらとか、商品詳細で戻るを押しても
検索結果ページにもどるとか、ユーザーがブラウザの戻るを押したとか
いろいろ考えるときりが無い。
他のサイトもいろいろ見ていると、面白いね。
あるところは、戻るが無くて、もう一度検索してくださいとか
ebookoffは複数開いたり、ブラウザの戻るで戻ってから
ページの戻るをクリックすると、ページが戻りすぎるとか。
いろいろ考えたり工夫したりしたんだろうなぁ。
>>205
商品の詳細を開いたまま、別の検索をして、
商品の詳細を・・・といろいろ商品を出してみて、
いろいろ見比べてからカートに入れると。
まあ、どういうことをしようとしても、
そんなことするやつは例外！ってことになると思うんだけど、
さて、どこまでやれるのだろうか？ 1.検索結果A
2.詳細A
3.カート
4.検索結果A
5.検索結果B
6.詳細B
この流れでカート以外を逆に辿れるって事？
ならセッションに条件を複数保存して、条件へのkeyをURLに入れとけばいけそうじゃない？
セッションの肥大化による弊害を気にしなきゃならんとは思うが。
1は名前欄に1と書いてくれないかなあ。
分かりにくいよ。
デザインをシステムに影響を与えないで、
htmlやcssを知らない人でも
編集できる方法のアイデアってないかな？
なるべくデザイン変更の自由度が高い方法で。
>>211
そうなんだよね。
あれくらい簡単にどうにかできないかな？
一ページのデザインは絵を描くように作れて、
そこにカートの項目をそこに乗せる感じにすれば良いのか？
ぶっちゃけ、絵をjpgででも書いてそこに乗せるだけ。
うーん。簡単そうで何かすっきりとしない。
なぜみんな、デザインのカスタマイズに
テンプレートやhtml、css書き換えという方法を
使っているのだろうか。
いや、俺だってテンプレートというものはわかる。Smartyだって使ったことはある。
でも、ほらこう。デザインいじくるだけなら単純に絵を描けばいいだけじゃね？
結局いつぐらいに初版は完成しそうなの？
今日明日作れってわけじゃないけど全く先の分からないのを待つのはしんどい。
>>214
正直言って、もし早く使ってみたいと思っているのなら
待たないほうが良いぞ。 出てこないと、テストも改良も参加できないじゃん。
結局、餅か．．．。
なんだか、少し業務でECサイトのシステムを触った？ことがあるレベルで、
完全に技術屋なだけの発想で作ってるな。運用フェイズを経験してないんじゃないかな。
本気で売ったりするなら、考えないといけないのは、マーケティングの部分。
データとして購入履歴のログなどから、購入時間とかが表示出来るのは
既に念頭に置かれてると思うが、それだけでは不十分過ぎる。
運用の人間が見たいと思うのデータは、「買ってくれた人間」よりも、
「もうすぐ買いそうな人間」「迷って買わなかった人間」だったりする。
前者のデータももちろん必要だけれどね。
・どの商品がどのページでどんなワードで検索されてどこに表示されたのか。
・ページ内でユーザがどういった遷移をしているのか。
→ページ別滞在時間、リンクをクリックしたリンクのある位置など
・商品検索があるなら、どういったワードで検索されているのか及び、
検索結果が適切なものだったかどうかの効果測定
また、全てのデータが各時系列において測定可能であったり、
前後との比較（先週の土曜と今週の土曜、とか）が可能であることも必要。
そういった部分は、特にAmazonで、リンクのURLとか、
Cookieを監視してると、どんな情報がマーケとしてとられていて、
使われてるのか見えてくる。
ここまで踏まえた作りになってくると、本格的で売りモノにもなると思うので、
頑張ってくださいね。
>>218
高機能アクセス解析ソフトでほとんど事足りそうだが・・・・ >>218
> 完全に技術屋なだけの発想で作ってるな。
なんで、要望を聞いているだけなのに、技術屋なだけの発想で作ってるなって話になるの？
マーケッティング系の要望がまだ出ていないっていうだけの話でしょ。
ちょっと失礼なんだけど。
システム開発者が「本気で売ったりするならマーケッティングの機能が必要なんです！」と
決め付けるのはただの押し付けでしょ？ もしそれが有料ならぼったくりじゃん。
だから開発者として機能を決めたりせずに、あえて要望聞いているんだけど。
あなたが書いた内容を「要望です」って書いてくれれば、それを組み込みやすい設計にするよ。
でもそれはコアに入れる内容ではないね。まあもともとほとんどの機能をコアに
入れるつもりはないけどね。コアに入れないだけで標準拡張モジュールで提供はありだけど。
なぜコアに入れないかというと、それらの機能はたとえばGoogle Analyticsなどの
アクセス解析で十分という人もいるだろうから。何がその人にとって必須かは
人それぞれなわけで、あなたの言ったマーケティングの部分が必要ないという人もいるだろう。
いらん機能を、グテグテとコアに入れてしまって機能を追加しようにも削除しようにも
一手間かかってしまう悪しき例が、osCommerce、ZenCart、EC-CUBEだと思ってる。
ああいうのは作りたくないわけさ。 >>221
それなら、さっさとログイン認証とカート部分だけコアとして作ってあとは拡張でいいだろ。
ｇｄｇｄ言ってないでさっさとコア部分作れよ。 拡張モジュールで機能追加できるようにしようにも
どのような場合にどういう風に機能を追加するかわからんと
インターフェースの用意しようがないので。
要望が無ければ、拡張させるためのインターフェースも
決められないのですよ。
>>224
それじゃあ、最初から拡張モジュールありきの設計じゃん。
コアと拡張で分ける意味ねーじゃん。 世の中に拡張モジュールありきの設計は沢山ありますが、
コアと拡張で分かれていないものなんてないですよ？
>>227
osCommerceのコントリビュートみればわかるよ。
ちょっと違うだけのバージョンが大量発生している。
それを複数組み合わせて組み込んだことがあれば
拡張できる仕組みがない不便さがわかるはずだけどね。 まぁ、一番良いのは
自分一人で自分のショップをイチから作ることだけどね。
いるっちゃぁいるんだが、要望を聞くのなら、EC-CUBEのフォーラムを
見れば十分かなぁと思っていたりする。
もうそろそろここも潮時か？
なんか面白そうな話が出たらレスするよ。
まず誰も>>1が本当に作れるとは信じてないところに問題があると思うんだ だって>>1はスレ立てしただけなんだもん
信じろといわれてもなぁ >>1は鳥付けるべきだと思うけど。
異様にレベルの低いレスがあり過ぎて、本気かネタか区別できん。
というか、SSLの話題追う限り単なる釣堀かとｗ もし、近い将来、すばらしいオンラインショップ構築ソフトがでたら
それは俺が開発したと言うことですよ。
それがネタではないことの証明でもある。
俺も何か書いておこう。
えーと、今後発売されるNDSのゲームでミリオンヒットを飛ばすものがあったらそれを作ったの俺だから。
・・で、一体誰が信じるんだ？
釣堀だったわけねｗ
まぁ、ぶっちゃけiTMS作ったのはオレなんだけどね。
実はZenCartのプロジェクトを立ち上げたのは俺なんだけどね
実はインクリメントＰのネタ集めだったてのが真相だったりして。
>>231
お前がそんな感じだからこんな現状になってると言うのはわかってるのか？ >>1が満点の夜空にひときわ大きく輝くショップの星となることを・・僕は信じてる。 初めてこのスレ見たんですが、質問
今現在、複数のASPサービスや、OSSが世の中にあると思うんですが、
使用しているショップ運営者の皆さんはこれらに不満があるんでしょうか？
AにはあるけどBにはない。
BにはあるけどAにはない。
みたいな状況で全部入りが欲しいみたいな感じ？
いまどき新興のサービスやOSSが需要あるのか正直よくわかんないんですよね。
取りあえずショップやるなら楽天（審査あるけど）で出来るし、
少しだけPCの知識があるならOSCやzencartで事足りそうですし。
> 少しだけPCの知識があるならOSCやzencartで事足りそうですし。
間違い。
プログラミングができなければoscやzencartは使い物にならないよ。
まあ、標準状態で使い物になると言うのなら話は別だけど。
>>249
もの凄くユトリ発想ですな。
向上心とか持ってないの？ 何か言うとすぐ「ゆとり」って言い出す
ステレオタイプなやつにもうんざりだがな
「ゆとり」
と同意語なのは
「最近の若い者は」
「最近の若い者は」と言うと自分がおっさんということになってしまうため、
それを回避する用語として「ゆとり」が用いられるようになった。
オンラインショップ構築ソフトってのは
そんなに需要あるのか？
需要があったとしても、結局俺俺オンラインショップなんて
信用力ないから商品売れないんじゃない？
なんでも百貨店で買うおじいちゃん、おばあちゃんじゃあるまいし。
百貨店、専門店、量販店、現金問屋もわからない人を発見しました。
flash(ActionScript)未経験でショッピングカート作ってみたけど二週間ぐらいで
できたな(データはMySQL&PHPと連携）。
画面遷移を伴わないのでユーザビリティもすぐれていると思う。
似たようなやつ探したけど意外に見当たらなかった。コンポーネント使って
既存のものと変わらないようなやつはあったけど。
htmlやcssに抵抗があるんだったら残された選択肢はFLASHしかないんじゃないか。
Ajaxでも同じようなことが出来るが（商品をドラッグドロップでカートに入れるとか）
そういうのをいまだにほとんど見かけないのはやっぱ敷居が高いんだろうな。
>>262
で、誰が、HTMLとCSSに抵抗あるって言ったんだ？
むしろ、FLASHのほうが・・・ たいてい回線の細い人のことを無視した読み込みなんだよなｗ
Flashじゃね。検索エンジンに引っかからないの。
そうするとSEOどころじゃなくて
ますます売れません。
生きてるよ。
きっと生きてるよ。
きっと、きっ・と・・・・・・・。
生きてるよ。3月には開発、開始できそう。
でもそこから数ヶ月はクローズドで作るから
公開はまだまだ先だね。あとこっそり公開するのでぐぐってねｗ
時間かかりすぎだなｗ
ねずみのごとく小回りが利いてなんぼなのに。
そのころには世の中が変わってると思
>>274
zencartやoscommerceやec-cubeを見てみろ
この世界、何年も前から、ぜんぜん変わらない。 何が変わった？ oscommerceなんて何年も3.0がでてないし、
zencartも細かいバグフィックスばかり。
ec-cubeは問題外だし、
他は、ちょろちょろと、オープンソースで開発初期段階・ベータ版・
アルファ版があるかどうかって感じだろ。
会員の届け先保存とか、商品を分割して発送するとか
AmazonみたいなショッピングカートCGIってどっかにない？
有料無料問わず。
ここは作るスレだけど
もしかして君が作る前に類似製品があるかどうか調べているっていう意味かな？
phpのでかい奴(OsC,zen)はよくみかけるけど
javaやrubyやperlで有名ででかいのないの？
AmazonやYouTubeは、それぞれどのフレームワークを使ってるんですか？
それとも、独自開発したオリジナルのものを使っているのですか？
>>285
最初から全部部品があるんだよ。
知らないの？？ あとはデザインするだけじゃん．．．。
お前、大丈夫？
よし、鉄筋とコンクリートを手に入れた。
あとは、家のデザインだけだ。
ハリボテ作ってんの？ｗ
どうでもいいが、>>1さんは今どうしてるんだろう？ >1 を見る限り
青い鳥症候群に罹っているとしか思えない
>>293
（会社の）仕事が終わらんとですよ・・・
開発終了近いのに、基本テーブル設計の変更ですよ。
休みなのに今日一日大幅なリファクタリングですよ。
仕事のシステムに「オンラインショップ構築ソフト」の設計の一部をフィードバックｗ
まあ、テストコードをちゃんと書いて自動化していたので、思ったより時間かからず。
おかげさまでユニットテストにかなり慣れてきたので、
今度からは、できればTDDで進めていこうかなと。無理かなと。慣れないね。ありゃ。
えーと1が無謀にもlispでなんかするスレはここですか。
なぜosCommerce、ZenCartが糞かというと、
プラグインによる拡張が（一部を除き）出来ないということ。
似たようなものでコントリビューションというのがあるが、
これは要するにパッチであり、生のosCommerceに組み込むのなら
上書きでいいが、複数のコントリビューションを組み込む場合
同じファイルを更新することが無いかチェックしなければならない。
同じファイルを更新していればコードレベルで融合しなければならない。
プログラマ以外にはコントリビューションの複数組み込みは
不可能と考えていい。
それは無理とか、プログラマしかできないとか○○が必須とか、あーだこーだ、
カタチになる前から細かい！！細か過ぎる。
小難しい話はいいから、仕様を詰めていこうよ。
もともと、仕様とか要望くれっていうスレじゃないの？
こういうものが欲しい、こういうものが要らないというのは、プログラマとかシステム側だけで考えることじゃないよね。
もっと柔らかくいこうよ。
そもそも、一般の人が自由に使えるレベルって、実現できるのかな。
だって、オーナーになりたい人っていうのは基本的にそんなに
パソコンとか判らない人たちでしょ。
機能とかじゃなくて、見た目とか、顧客としか言えない人たちのためだけの
現実的にぶっ飛んだニーズが多いし全てのニーズに対応するソフトなんてできないんじゃないかな？
例えば、デザインテンプレが、一個のベースを買っておけば後から購入しても
ボタンひとつで入れ替えられて（これはありえる）
CMS的な部分もオーナー側で自由に設定できて、HTMLとか、CSSとかいじらなくても良くて
管理画面で何でも解決できて、新しいモジュールができたら購入すれば管理画面から一発で組込めて
スイカとかパスモとか増え続ける電子マネーや支払いがらみに即対応できて
困った時のサポートが手厚くて、初歩的なことも聞けて
マーケティング機能がサイトを運営しているだけで稼働して
あと、ここみたいな、検索方法が実現できて。。
http://imagine.bookmap.info/index.jsp
ギフト機能だけでもすごいニーズが細かいよ。「のし」がつけられるようにしたいとか
メッセージカードにお客様が入力したものを入れてあげたいとかショップ側でそれをカードにプリントアウトできるようにしたいとか。
7割、不可能だと思ってますが、、、応援してます。 >>301
なんか勘違いしていないか？スレタイを良く見てくれ。
オンラインショップソフトそのものを作るんじゃなくて、
オンラインショップ”構築”ソフトを作るんだぞ。
オーナー固有であろう要望を満たす、つまり
現実的にぶっ飛んだニーズを組み込むようなことはしない。
ただ、組み込もうと思った場合、簡単に組み込めるような
仕組みを持たせて、オンラインショップを”構築”することが
できるソフトを目指している。 >>301
と思ったが、
> 例えば、デザインテンプレが
これ以降はすばらしいレスだ。
こういうのがあれば、「あー、それを実現するにはこういう
仕組みが必要だなぁ」ってのがわかる。 >>301
>例えば、デザインテンプレが、一個のベースを買っておけば後から購入しても
>ボタンひとつで入れ替えられて（これはありえる）
>CMS的な部分もオーナー側で自由に設定できて、HTMLとか、CSSとかいじらなくても良くて
>管理画面で何でも解決できて、新しいモジュールができたら購入すれば管理画面から一発で組込めて
>スイカとかパスモとか増え続ける電子マネーや支払いがらみに即対応できて
>困った時のサポートが手厚くて、初歩的なことも聞けて
>マーケティング機能がサイトを運営しているだけで稼働して
大事なことが抜けとる
そのシステムを導入するだけで売り上げが上がってくれないと困る
建築屋に、店を作るだけで、売り上げが上がってくれないと
困るとかいわれても筋違いｗ
システムだけで売り上げを上げようと思うのなら、
独自性のあるシステムをカスタマイズしろ。
システムにどんな機能を搭載しても、
それがオープンで作られるもの＝誰でも同じ機能を手に入れられるのなら
独自性のあるシステムになりようがない。
独自性のあるシステムがほしいのなら、それは自分で作るかどこかに頼むしかない。
すこしは、常識で考えて。
まだ、システム作るだけで売り上げが上がると
思っている奴がいるのか・・・
売り上げを上げるのに必要なのは営業努力だよ。
つまり、ページをまめに更新したり、ブログを書いたり、
なんらかのキャンペーンをしたりすること。
そういうのは運営者の仕事だよ。
い前ら！ケツの割れ目の、しかも谷底に肛門があるのは、
ちょっと漏れてもパンツに付かないようにする為だぞ！
別に謝らなくてもいいよ。
その誤爆、違和感全然ないし。
Zen Cart にCSVファイルからインポートできるモジュールを探しています。
ご存じの方は教えていただけないでしょうか。よろしくお願いします。
GW暇だからAptana Cloud使って作ってみるかｗ
ここのスレ主、昨日他所で質問しておもいっきりDQNに叩かれてたっしょ？ｗ
俺も今までいろんな質問したことあるけど、2ちゃんは昔に比べてかなり厨化して、
ただの知ったか厨の弱い物いじめの場と化してるよ。日頃社会に認められない
引きこもりや仕事にあぶれた暇人が欲求不満しているからな。
はっきり言って、答えてくれる知識者や実務かじってる人に出会えたらかなりラッキー。
それより、秋葉原とかの本屋で専門書実用書経営戦略本とかあさった方が
時間（＝金・人生）の無駄遣いを回避できてたりする。2ちゃんは特に、無駄な時間を
過ごしているのに気づきながら引きづり込まれる場合が多い。本末転倒でしょ？
そしてやっぱり、2ちゃんより、普通にネットを検索した方が真摯な答えが転がってる。
3,500円出せば正しいヒントが手に入ると思う。って一昨年の夏のスレかいorz
じゃあもうマーケット戦略立てなおしたり、開発じゃなくて運営や経営で多忙かな。。。
>>1
> 多言語対応。
> 高セキュリティ。
> 拡張機能・言語の追加は追加モジュールを入れるだけ。
> 柔軟なカスタマイズができる料金設定。
全部余裕で対応してる
既存の脆弱性に細かく対応
マルチ言語対応
マルチ端末対応
マルチ通貨対応
スキンはパーツ化されていて必要なら何層でも入れ子状に配置できる
ほぼすべての機能がプラグイン
プラグインからプラグインが何度でも繰り返し呼び出せる
カスタマイズ料金がかなり安いと昔から定評がある
CAFEMILK SHOPPING CART V5
http://cafemilk.milkcafe.to/
標準スキンがしょぼくてそのままでは使えないのが難点。 技術者なら他のアプリをクソ呼ばわりしないで、良いところは素直に利用するのが良い。
自分の作ったものをクソ呼ばわりされたら切れるくせにな。
こうゆう奴が一番関わりたくないわ。
一流は誰もが認め本人も誰をも認め地道な探求を怠らない謙虚な人間である
二流はうぬぼれて鼻にかけ他を無視し上位に対して異常なコンプレックスを持つ小物が多い
三流は必死に背伸びし自慢し嘘もつきコンプレックスの固まりなのをおくびにも見せない世間によくいるタイプである
四流以下は二流以下が謙虚さを忘れ傲慢になって他を馬鹿にすることに終始する人間である
人間は謙虚さを忘れ傲慢になったとき進歩をやめるだろう
このスレのSSLの話は勉強になりますね、上げておきます。
☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
KPVN99805I
