1read 100read
2013年01月WebProg177: ガチでオンラインショップ構築ソフトを作ろうと思う (333) TOP カテ一覧 スレ一覧 2ch元 削除依頼
KENT WEB 総合スレ Part2 (939)
【RoR】Ruby on Rails Part15 (945)
セキュリティースレッド (243)
【SG】fusianasanの仕様を考えてみるスレ【SG】 (260)
WebLogic に詳しい人いません。 (623)
PHPで作られた有名サイトってあるの? (702)

ガチでオンラインショップ構築ソフトを作ろうと思う


1 :2007/08/19 〜 最終レス :8)
もちオプソで。
多言語対応。
高セキュリティ。
拡張機能・言語の追加は追加モジュールを入れるだけ。
柔軟なカスタマイズができる料金設定。
オンラインショップってのは、店によって結構細かい違いがでてくるものなんで
カスタマイズ性が必須だと思うんだけど、どうも既存のやつは制限が多すぎる。
自由に設定できないうえに、ソフト会社に頼むと高額な金額を要求される。
そんな人にぴったしなソフトにしたい。
ほかにほしい機能あったら頂戴。
とくに、今オンラインショップを運営しているが
こんな機能がなくて○○はいや!ってな人お願い。
たぶん、俺一人だと思いつかないから。
補足
osCommerce・ZenCartのクソ加減にはうんざりです。

2 :
適当にアイデアを並べていく。
・柔軟な商品タイプの設定
商品タイプとはZenCartにあるやつ。
たとえば、本という商品タイプには属性としてISBNがある。など。
そういうのを「運営者が」(←重要なところ)自由に作成・変更できる。
ZenCartの場合、いちいちテーブル定義して
それに入れたり表示したりとプログラムを変更しないといけない。

3 :

 終 了

4 :
・値段がないもの、値段固定ができる
無料商品、固定価格商品対応。
スーパーの肉・魚みたいに、この商品は3個買った1000円になる

5 :
会員・期間・時間の条件の違いで複数の価格設定ができる。
柔軟なページ修正、特定の商品のページだけ
WYSYWIGエディタで修正することが可能。
特定の商品に限り、はでなPOPを入れるなど。

6 :
こういう類の物はカスタマイズだけでどうこうできないんだよ。
ある程度の大枠フレームワークは作ることができるかもしれないけどね。
大体、業種によってDBのテーブルがまったく異なるのをどうやって吸収するのよ?
あきらめな。

7 :
> こういう類の物はカスタマイズだけでどうこうできないんだよ。
その理由は?
> 大体、業種によってDBのテーブルがまったく異なるのをどうやって吸収するのよ?
DBのテーブルがまったく違うのなら
拡張モジュールで変えれば良いだけの話だろ。
DBのテーブルってプログラムから変更することができるんだぜ?
まさか、知らなかったのか?w

8 :
ようは自分がほしいものを作ってくれスレだべ

9 :
>>8
いいえ。貴方が欲しい機能を書けば私が作ります。

10 :
アイデアぱくっておれすげ〜〜って言いたいだけの小僧ですか

11 :
本気でOSSでやりたいというなら
プロトタイプをSourceForgeなりGoogleCodeHostingなりで公開すればいい
それすらやらないようでは到底無理

12 :
>>10
俺すげーとは言わないので、アイデア下さい。
アイデアというか要望。

13 :
携帯サイトとPCサイトの商品DB連動
佐川、ヤマト用、送り状作成ソフトにインポートできるCSV作成
詳細写真の枚数、自由指定
アフィリエイト機能
特別に作ったHTMLページも利用可能に
30万くらいで作って
zencartの改造でもいい

14 :
>>1が考えているテーブル設計はどんな感じなの?

15 :
>携帯サイトとPCサイトの商品DB連動
連動させない作りのほうがキモいだろ...。

16 :
MVCで作ってれば携帯とPCは両方対応できるな。

17 :
またk.k.プロジェクツか!
とりあえず>>1はコテつけろ

18 :
>>14
商品タイプの部分はクラステーブル継承がいいかなと思っている。
でもJOINの負荷を考えると具象テーブル継承も捨てがたいかなと思っている。
具象テーブル継承だとデータが重複して保存されるから運用時に
商品タイプをいじると大規模なデータ変更(あるテーブルからあるテーブルに
大量にデータコピー)が起こりそうだなぁ。
基本の商品データは商品コードと型情報のみ。(タイトルぐらいあってもいいか?)
そのほかの項目はすべてモジュールで定義。
なんと価格すらもオプション。必須項目ではないのだ。
(だって100円ショップみたいに価格固定だと価格項目は必要ない)

19 :
> 詳細写真の枚数、自由指定
OK OK
ついでに縮小サイズとか自動で作成。キャッシュあり。
携帯の場合もそれぞれにあわせた形式で。

20 :
共有SSLのURL対応
(共有SSLのURLとはhttps://レンタルサーバー/独自ドメイン/的なやつのこと)

21 :
image(
id,
item_id,
path,
file_name,
type,
alt,
del_flg
)

22 :
>>17
恥を知りなさい
>>1
きっと買収します

23 :
無理無理。
何でもかんでも構築ソフト任せだと顧客が痛い目見るってことで実用性はない。

24 :
kkぷろじぇくそと同じ道を歩むスレとなったか

25 :
kk-projectsに憧れます

26 :
コテつけるからアイデアかもんべいび〜

27 :
>>23
根拠はあるの? そうなった実例。

28 :
>>27
多分>>23は市販のWebショップ作成ソフトかosCommerceあたりのWebアプリケーションで
痛い目に遭っただけちゃうか

29 :
あれもこれもと入れ込むよりは、アドインできる仕様にしてAPIを公開
するってのが今時の流れじゃないのか?

30 :
>>29
ですよね。コアはなるべくシンプルに!

で、話は変わりますけど、まあある程度の機能
(たとえばヤマト送り状CSV作成機能)は
アドインでプログラマが作ったプログラムを組み込むのは
仕方ないと思います。
でも商品の項目程度はプログラミング知識の無い運営者でも
管理画面から変更できたほうがいいと思うのです。
こういう場合どういう設計にしましょう?
1.データベーススキーマを動的に変更。
設計としてはシンプルだが、項目の追加・削除とかで問題でそう?
SQLのALTERにはRDBMSごろと制限がいろいろ。
2.商品項目テーブルを作る。
|商品コード|項目名|値|
|1 | タイトル | なんとか|
|1 | ISBN | 4798105538|
|1 | 価格 | 5800|
自由に項目を追加・削除できるが、パフォーマンス(特に検索時)悪そう。
3.商品項目ごとにテーブルを作る。
ISBNテーブル
|商品コード|値|
|1 | 4798105538|
検索自体は早くなるかもしれないが、
JOIN多すぎでパフォーマンス低下&JOINの数制限に引っかかる。
どれもしっくりきません。

31 :
後で追加するようなもんは
そんなにモリモリ検索しないだろうから
辞書にでもしてシリアライズしてテキストにして、つっこんでおけば。

32 :
そもそもDBが本当に必要なほどの商品数があって、売り上げも上がるところなら
作ってもらってる。
楽天をみてもわかるがほとんどのところは商品100個以下。

33 :
>>32
本当にそうだろうか?
DBが本当に必要なほど商品数がある場合は
楽天とか使えずに、また既存のオンラインショップシステムじゃ
重かったり、使い勝手が悪かったりで、仕方なく作るしかない。
が正解では無いだろうか?

34 :
だれかzencartの改造30万くらいでやらない?

35 :
>>34
安すぎ。学生にでもやらせればいいんじゃね?

36 :
じゃあ、やってくれる学生いませんかー?

37 :
>>34-36
どんなビンボー学生でも割に合う仕事と割に合わん仕事ぐらい見分けがつくだろ。

38 :
20万以下でやってくれるだろw

39 :
>>13
>携帯サイトとPCサイトの商品DB連動
Zencart用だったらシェアウェアで出てる
>佐川、ヤマト用、送り状作成ソフトにインポートできるCSV作成
エクスポートとインポートの区別つけてよ
>詳細写真の枚数、自由指定
Zencartでも3枚ぐらい貼れる それで足らんかったらHTMLで書く
wysiwigエディタで画像URL指定で貼れるはず
>アフィリエイト機能
要るか?ホントに勝てる商品ならA8とかに出したほうが良さげ
っていうかコレもシェアウェアで有る>Zencart用モジュール
>特別に作ったHTMLページも利用可能に
Zencartの1.3x系なら追加ページ書けたはず
それで足らんかったらXOOPSモジュール化されたZOXもある
>30万くらいで作って

40 :
とある会社はECと物流のデータ連動できるサイト構築で
イニシャル1900万
ランニング60万とるらしいが高いね

41 :
言語的にはPHPとMySQLで十分だな。楽天もそうみたいだし。
>>1
テンプレート編集機能もいるだろ。プログラマーはプログラムの部分ばかり
考えるが、デザイン面も考えないと、ユーザは食いつかない。

42 :
>>41
> テンプレート編集機能もいるだろ。プログラマーはプログラムの部分ばかり
> 考えるが、デザイン面も考えないと、ユーザは食いつかない。
一応これ↓に含めていたつもり・・・(´;ω;`)ブワッ
> 5 名前:nobodyさん[sage] 投稿日:2007/08/19(日) 22:52:24 ID:???
> 柔軟なページ修正、特定の商品のページだけ
^^^^^^^^^^^^^
そういや前々から思っているんだけど、WYSYWIGエディタはあるけど、
CSSまで含めてWYSYWIGで修正できるものってないよな・・・?
俺としてはテンプレートをWYSYWIGで修正したい!(どうやって!?)

43 :
CMS的な機能もいるよな。
オンラインショップのトップにきたら
決まったように、最近入ってきた商品とか
売れ筋の商品とか適当に表示。
それはそれで考えなくて良いから、便利な点もあるんだけど、
今月の○○特集とか派手なPOPをおいて、
さらに詳細な記事(コンテンツ)書いて、
そして商品の販売につなげるとかやりたいじゃん?
好きなページを作れるのはもとより、好きなブロックを作って
いろんな場所に埋め込める必要があるよな。
ついでに期間限定機能つきで。

44 :
http://xoops.ec-cube.net/modules/xoopspoll/pollresults.php?poll_id=2
あひゃ。要望ぱくりw
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って要望高いんだな

45 :
デザイン面はどのレベルまで持って行けるんだ?
XOOPS以上の見た目は必要だぞ。

46 :
ズープスは最低クラスだな。
ワードプレスくらい自由度あるといい

47 :
>>45
さすがに最低限の機能としてテンプレートは使うので
テンプレート言語かできる程度の知識があれば自由自在。
フレームワークを使うので、必然的にそうなるわけだけど。
最終的には、Ajaxを使って自由にブロックを配置、移動させたいねぇ。

48 :
ところで格安共有サーバーで動かすことを考えるとPHPが一番?
suEXECがあるからセキュリティ的にPerlも気になってはいるんだけど、
あんまり流行っていない気がする。
それにPerl用のフレームワークって実質的にCPAN必須な感じだし。
(CPANは共有サーバーで使えないことも多い)
PHPを使うとしたら、CakePHPが今のところ一番勢いがあるだろうか。
CodeIgniterやAkelosも気になっている。
どれもPHP4でも動いて、PEAR必須じゃないよね?
(PEARも共有サーバーで使えないことがある。手動で入れるのも不可能ではないが
場合によってはかなり面倒なことがあるのでなるべく使わないようにしたい)

49 :
>PHPを使うとしたら、CakePHPが今のところ一番勢いがあるだろうか。
そうなの?ソースとかある?


50 :
テンプレートエンジンはSmartyな。

51 :
>>50
別にかまわない。というか、
拡張モジュールでテンプレートエンジン切り替えられるようにするけど、
個人的には、PHPそのままでもシンプルな状態なら
テンプレートと本質的には変わらないと思っている。
<h1>{$text}</h1>
<h1><?php echo $text; ?></h1>
多少長くなる程度。
問題はビューの部分で複雑なコードを書くのが悪いのであって。

52 :
>>51
Smartyのページキャッシュ使ってDBの接続コスト
減らせばいいんだよ。
どうせ、PEAR使うといろいろと面倒だろ?

53 :
KKprojectsも応援しています。

54 :
SmartyとかPEARとか使ったら、拡張性悪くなるんじゃないか?
>>1はオープンソースとして作りたい分けなんだから、
後からユーザが改造出来る形が良いだろ。
と言うわけで、純粋なPHPのコードだけでいいと思う。

55 :
KKprojectsもそう思います。

56 :
PEARはもう十分に普及してますよ。

57 :
このスレはご覧のスポンサーがお送りしております
提供:K.K.projects

58 :
>>56
いや、普及しているかどうかというより、
PEARのパッケージマネージャを
入れるにはシェルが必要でしょ?

と書いておきながら、go-pear.phpを
入れて普通に動いているような気もするんだけど・・・。
それでも、微妙に不安定な感じもする。よくわからない。
パッケージマネージャを使わないでPEARを入れるのは
経験が少ない人にとっては大変だし。
まあ、使わないでやれるのならそれに越したことは無い。

59 :
てか、あまり普及してるのもセキュリティ的に良くないんじゃないか?
それより独自で関数増やしていく方が、オリジナル性でると思う。

60 :
時間の無駄w

61 :
PEAR使うんなら、同梱しておけばいい。
ライセンス的に大丈夫であれば。

62 :
これOmotiじゃね?

63 :
どうみても本7です。本当にありg(ry

64 :
ぬこえもんなんか言ってよ!

65 :
バカな提案していい?
携帯だけで、ショップ運営。
商品の管理や写真アップや顧客管理など
最初のシステム設置を除くほぼすべてを
携帯電話のみで行えるシステム。
もちろん携帯電話でPC用サイトが見れる
フルブラウザを使うわけではない。
バカらしい? 俺もそう思う。だがしかし、
もしかしたらそういうのを望んでいる人がいるのかもしれない。
もしそういうASPとかあったら教えて。

66 :
今日、「ショップ運営者が自由に商品タイプを作れる機能」について
すばらしい発想がうかんだ。
この方法なら、いろんな商品タイプを作ったうえで、
なおかつ拡張モジュールによる柔軟な拡張を実現できそう。
あとは、検索・ソートをどうにかすれば。
数百、数千程度ならどう作っても問題ないとは思うけど
結構負荷高いだろうからなぁ。特にソートとか。
いろんな商品タイプを作ったうえで、どうソートさせるか

67 :
求められてるのは「かつて無い新機能」ではなくて
「既出機能の全部入り」だと思うなあ
多くの人の不満は「あのソフトにはAと言う機能があるけどBと言う機能が無い」
「このソフトにはBと言う機能はあるけど、Aと言う機能が無い」
あちらを買えばこの機能が立たずみたいなところに尽きると思う。
ここで要望を集めたソフトを作るのも良いけど、それだけだと
既存ソフトにはある機能を実装し忘れた新たな不満を抱えたソフトの誕生になりかねないから
ベースとしてトップシェアのソフト+トップシェアソフトの不満点解消
と言う目標設定があるといいと思う。
はなからこのスレの要望をほとんど満たしたものになるんじゃないかな。
そのジャンルで今トップのソフト買って使ってみてそのスレ見てくる。
※今だとネットショップ・オーナー2かな?
そうすると「後これさえあればとりあえず文句無いのにな」という意見が散見される筈。
つまりトップのソフトの不満を解消したのをサクッと出せば(まあ実際に作れたらの話)
ほとんどの人は満足すると思う。
逆に言えば今トップのソフトと同等以上の「全部入り」が作れないなら
使ってくれる人も少ないだろうから新たに作る意味はあまり無いような気がする。
1:トップシェアのソフトと同等の機能(パクリ上等)+不満点トップ5〜10箇所を解消
2:致命的なバグが無い+新OSやバグ修正にちゃんと対応してくれる。
この二点さえクリアできれば市販ソフトと同等の値段でも買う人多いと思うよ。
後、他ソフトからの商品データがまんま使えるとか自動変換とかあれば完璧かな

68 :
で、>>1さんは何で作るの?
PHPとMySQL?
どうせなら、PDO使ってMySQLとSQLite対応のものにしてよね

69 :
>>67レスどうも
> 「既出機能の全部入り」だと思うなあ
そうかなぁ? osCommerce、Zen Cart、某シェアウェア、と使ったけど、
どれでも、なにかの機能をOFFにするんだよね。
たとえば、レビュー機能なんていりません。ってな感じで。あまりにも機能が多すぎると
初心者の人は使いづらい。管理しなくてはならない事が増えるから。
機能はつける。つけるけど、その大部分は拡張モジュールとしてつけたいんだ。
そして、どういう拡張モジュールの組み合わせでもちゃんと動く。
(現実には完璧にするのは不可能だろうけどなるべくうまくいくように)
そういう柔軟性を持たせたい。
残念ながらosCommerceやZenCartはこれができない。これはこのバージョンとの
組み合わせでしか動かない。またこれとこれは同じファイルを修正する必要があるから
(プログラムができない人には)両方同時に組み込めない。など。
> ここで要望を集めたソフトを作るのも良いけど、それだけだと
要望を集めるのは、実はその要望を実現するというよりか、その要望を後からでも簡単に組み込める
仕組みを提供したいから。だからそこ想定外の要望がほしい。この要望を実現するには
大幅な設計変更が必要じゃないか!と思うぐらいのものを先に洗い出しておきたい。
> 既存ソフトにはある機能を実装し忘れた新たな不満を抱えたソフトの誕生になりかねないから
実装し忘れたなら、その機能を拡張モジュールとして後から組み込めばいい。そういう風にしたい。
完璧を目指してもそれは無理。システムを一枚岩として作るから、あとあと機能を追加しづらくなって
これは○○が足りないといわれる。
> 後、他ソフトからの商品データがまんま使えるとか自動変換とかあれば完璧かな
そういうのはインポートモジュールで。需要があるのなら(自分を含めた)誰かが作るさ。

70 :
>>68
> PHPとMySQL?
> どうせなら、PDO使ってMySQLとSQLite対応のものにしてよね
PDOは使ったことないけど、いまざっと調べたところ、使わないという結論になるだろう。
その理由はPHP5以上じゃないといけないから。
PHP4の出番はまだまだあるとはいえ、サポートも打ち切られる(た?)みたいだから
切り捨てるというのも、悪くはない考えなんだが・・・。
今のところはCakePHPを使う予定。今仕事で使っているのがこれだから俺としては一番実績がある。
CakePHPならPHP4,PHP5でも動くし、データベースもMySQL、PostgreSQL、SQLite、他さまざまなRDBMSに対応。
CakePHPで決定ではないが、何かのフレームワークを使う。ただし、上のほうでも書いたが
PEARやCPAN(言語にPerlを選んだ場合)など入れづらい外部ライブラリに依存するもの。
入れるのにシェルを使用するものは候補外。なるべく多くの環境で動くものを使う。
さすがにRDBMSを使用しないで作るのはキツイが・・・。
フレームワークって大概(全部?)RDBMSを使うように作られているし。

71 :
これから作るのに死亡カウントダウンがいよいよ始まったPHP4かい

72 :
しゃーないじゃん。仕事で使っているサーバーがPHP4で
抜ける許可下りないんだから (T-T)
別にCakePHPならPHP4用として作る必要はないから
問題ないよ。普通に作れば勝手に対応している。

73 :
RedHat エンタープライズとかなんとかのどれかのバージョン。
PHP4が入っているわけだが、そのサポート期間まだまだあるから
たぶん今PHP4を使っているサーバー。しばらくはそのままだと思うよ。(T-T)
混乱とか客の都合とか考えずにずばっとアップグレードしちゃえば良いのに。

74 :
問題ないか?
新規にサバを契約しようとしたら、そろそろRHELは5になろうかと
いう時期だよ。
他人が使おうと思っても、契約できるレンサバがないって話になる。

75 :
ZendFrameworkで希望

76 :
俺もZendが良いな。
それかCI。

77 :
http://www.itmedia.co.jp/enterprise/articles/0702/28/news028.html
> NexenServicesが発表した2006年8月現在の統計では、
> いまだPHP 4が全体の90%を占めており、
> PHP 5の利用はまだ広まっているとはいえません。
いまPHP4のシェアはどれくらいかソースある?
それ次第ではZendFramework選択肢に入れてもいいけど。
> Code Igniter
悪くは無い。

78 :
このソフトで一気にPHP4からPHP5へ移行させるくらいの気概が欲しいもんだな。

79 :
本のISBNってどこかで公開されてる?

80 :
amazonのAPIで良いんじゃないの?

81 :
AmazonはBOOKデータベースから買ってる。
http://www.nichigai.co.jp/newhp/dcs/book_f.html

82 :
ルート権限と鯖だけ売ったらどうだ。
あとはオンラインショップ構築ソフトの紹介だけ。
好き勝手やりたい奴が人様の作った環境を素直に使うとは思えん・・

83 :
>>82
それただのASPw

84 :
要望を書きたいがなんか難しそうな話になってるから
辞退。

85 :
>>84
気にしなくていいと思うよ
このスレだって最初から小難しい話で盛り上がってたわけじゃないんだし

86 :
>>84
かいてくださーい。お願い。
様々な業種に対応できる設計にしたいから
いろんな情報がほしい。
マイナーな要望であればあるほどうれしい。
(その要望を必ず取り入れるわけじゃないので注意)

87 :
ところで前から気になっていたんだけどさ、靴とか服とか
ベースは同じで、サイズや色の違いがあるものあるでしょ?
あれって、商品コード(JANとか)はそれぞれ違うものなんだよね?
だから特に何ってわけじゃないけど。

88 :
オプションという機能をつけよう(つけられるようにしよう)と思う。
服とか買うとき、オプションでサイズを選べるとか
色を選べるとか、ジーンズのすそ上げするかとか、
オプションで値段が変わったり。

89 :
>>88
オプションじゃなく、当然カートについてる機能。

90 :
>>89
たぶん、あなたは勘違いをしている。

91 :
ポテトもいかがですか?機能

92 :
しかしここ最近急にのびてきたね、ここ

93 :
>>92
>>1は作りそうもないのに、伸びてるよな。
って立てたのは俺だけどw
一応予定を言っておくと、11月ぐらいから本格的に開始かな。
今の仕事(同じようなもの作ってる)が終わって
経験つんでから別設計(拡張性・汎用性重視)で作る。
それまで、要望聞いて設計中。
>>91
了解。お勧め機能だね。そこらへんは単純なHTMLから
複雑なphpコードまで、ブロックというかガジェットというか
そういうパーツにして、好きなところにおけるような設計にするつもり。

94 :
方向性としてlベッキーとかWINAMPみたいなのを作るわけか。
アウトルックのスパムメール一括登録できない。
見たいな、なぜその機能がないんだ?みたいな事あっても
1の言うようにプラグイン誰かが作るところがソフトメーカー品よりある意味安心できるところだね。
鶏と卵の関係で
素の核のソフトがそれなりに使えないとプラグインを作る人も少なくなるだろうから、
1の優先順位選択のセンスにwktkする。

95 :
あ、分かると思うけど一応訂正。
1の優先順位選択のセンスにwktkする。

1の要望を取捨選択するセンスにwktkする。

96 :
スキンというのかテンプレートというのか、外観デザインは変更しやすいのが良いね。
EC-CUBEの3rdパーティ製テンプレートをダウソしてみたけど、何でファイルが500個以上あんのかとorz

97 :
CSSでおk

98 :
でさ。ブロックと言うかガジェットというか、
好きなパーツをおけるようにすると、
どうしても外部のWebサービスをおこうとするよね?
それ自体は別にいいんだけど。
そういうことをするとセキュリティ上のリスクがある。
詳しく言うと、外部のWebサービス(JavaScript)を実行するため
そこが信頼できないサイトだとcoockieを奪われたりする。
ここを気をつけないといけないな。
httponlyを使ってcookieをJavaScriptから読み取れないようにする。
iframeをうまく使う。ログインページなどには外部のWebサービスなどを
入れられないようにする。うーん。他にあるだろうか?

99 :
cssじゃデザインまで変わらないでしょw

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼
【SG】fusianasanの仕様を考えてみるスレ【SG】 (260)
くだらない質問でも偉そうに聞いていいスレ (432)
tDiaryスレッド その1 (432)
☆ショッピングカートのCGIを作りたい!Perlで☆ (511)
Zopeってどうよ インスタンス4つめ (383)
(´-`).。oO(なんでだろ?) (435)
--log9.info------------------
暗い歌・沈む歌・侘びしい歌・悲しい歌 (330)
大槻真希を語るスレ (508)
80年代アイドルポップスを語ろう (756)
アグネス・チャン掲示板 (909)
【美しい十代】三田明【夕子の涙】 (910)
20代で中森明菜さん好きな人いる? (714)
【風をあつめて】細野晴臣って・・・・・・誰? (350)
中森明菜 好きな曲 TOP4 (592)
【エレガント】安井かずみさんを語るスレ【ZUZU】 (505)
沢田研二(ジュリー)にカバーしてほしい曲 (435)
【永遠の】高石ともや【受験生】 (353)
[可憐な歌声] とみたゆう子 [実業家] (597)
愛の猛獣こと小柳ルミ子を語ろう・Part2 (791)
ラ〜ラ〜ラララ〜♪由紀さおり☆Part6 (221)
中原めいこ3 (490)
♪史上最強の編曲家は?2 (365)
--log55.com------------------
愛煙でチョソ撃破★2
大ニヒル口煙【男】
大 鼻 煙 鍛 錬
ナイス豪快鼻煙鍛錬
禁煙鬱について Part8
【異常者禁止】珍煙の異常性を語るスレ2
ムヒヒ鼻煙鍛錬
無 慈 悲 鼻 煙 鍛 錬