約 557,482 件
https://w.atwiki.jp/12kokuki/pages/59.html
ビューを作る 最初は通常のテーブルだけで作るつもりだったけど、SQLを書くとき……というより、プログラムにSQLを埋め込むときに面倒になりました。サイト情報から可変の項目を外に出したため、どうしたってクエリは多くなるし、当然ながらプログラムソースも長くなるから。多少のパフォーマンスの劣化は、本当に必要なマスタだけ検索対象とするよう細やかに設定すれば何とかなったけど。 で、プロトタイプを作っていて、サイトごとのカップリングテーブルから組み合わせの集計結果を得るときついにブチ切れ。 データテーブルでは、サイトごとに攻めキャラと受けキャラの組み合わせで登録するため、そこからたとえば「景麒×陽子(10)」（括弧内は登録サイト数）という結果文字列を引っ張ってくるには、キャラマスタとサイト情報テーブル、カップリングテーブルだけではどうしてもSQLが冗長になりますから。というかSQLを書くだけならともかく、それをプログラムに書くのがめんどい。 そこで「ビューだ！ ビューを持ってこーい！」と叫ぶことに。 ただSQLite側でうまくいっても、CGIとして（今のところはApacheのモジュールとして動かしてるけど）動作させると動かないSQLがあり、かなりはまりました。今回、データベースを設計しなおしていて、「あれ、動かないなぁ。プロトでは動いたのになぁ」というのが多々あり。このWikiを作る前にとりあえず作ってみたプロトタイプと見比べてみたら、CREATE VIEW 文の GROUP BY 句の違いのせいでした。 データを取得できなかったSQL CREATE VIEW V_SUM_MEDIA AS SELECT S.MEDIA AS ID, M.NAME AS NAME, COUNT(S.ID) AS TOTAL FROM D_SITE S, M_MEDIA M WHERE S.MEDIA = M.ID GROUP BY ID; データを取得できた、プロトタイプのSQL CREATE VIEW V_SUM_MEDIA AS SELECT S.MEDIA AS ID, M.NAME AS NAME, COUNT(S.ID) AS TOTAL FROM D_SITE S, M_MEDIA M WHERE S.MEDIA = M.ID GROUP BY S.MEDIA; 違いは最後の GROUP BY 句だけ。 でもさー、なんで？ 同じような指定をしていた他のビューは動いてるし、コマンドラインからsqlite3.exeで動作させると、最初のヤツでも普通に動くんだよね。Firefoxのアドオン「SQLite Manager」でも。 まあ、SQLの仕様として正しいか否かというのは知らないので、そのせいかもしれないけど――釈然としない……。前者だとPHPのPDO Query()では結果がFalseになるだけで、いったい何がいけないのかわからないから、原因を突きとめるのに何時間もかかってしまったし。 何にしてもビューがらみは、sqlite3.exeでは動くのに、CGIとして動かすとこれまでも期待した挙動にならないことはありました。PDO execute()でパラメータを埋め込んでいるはずなのに、特定のビューだけクエリに失敗したり。おかしいなぁと思って、問題のカラムはINTEGERで、execute()で渡すとすべて文字列として扱われるらしいからそのせいかなとも思ったけど、他のビューでは成功するんだよね。だいたいSQLiteでは、文字列として渡しても中身が数値なら数値で判断してくれるはず。 最終的に苦肉の策で、lower関数を通すことでカラムを文字列として扱ってみたらクエリが動くようになりましたが……これも釈然としない……。 追記 もしかしてSQLの書き方を間違ってた……？ どうもOracleの方言とごっちゃになって、どっちつかずのSQLを書いてたみたいで、本当はこうやって外部結合を書かないといけない……の、かな……。 SELECT S.SITE_TYPE AS ID, M.NAME AS NAME, COUNT(S.ID) AS TOTAL FROM D_SITE S LEFT OUTER JOIN M_SITE_TYPE M ON S.SITE_TYPE = M.ID GROUP BY S.SITE_TYPE; あれ？ 今さらだけど、この場合は外部結合じゃなくて内部結合でいいんじゃん？ まあ、データが不正にならなければ結果は同じか……。ということはパフォーマンスが良いほうを取ればいいのかな。 というか、最初のJOINを書かない奴だと交差結合だった……のかな……。 追記2 そもそもカラムの別名は、GROUP BY、HAVINGでは使えないみたい？ てことは、動いちゃうSQLiteがおかしいのかな。 2010/09/07 14 04 00
https://w.atwiki.jp/12kokuki/pages/57.html
マスタを作る こういうのってデータ構造を決めてしまえば、どういうプログラムにするかはおのずと決まってくるもの。なのでまずはデータの持ち方を考えることに。 最初はテキストファイルとか考えていたけど、そもそもSQLの勉強も兼ねたかったので順当にDBにしました。それもMySQLにしよっかな、と安易に考えたものの、いろいろ調べていったらSQLiteの存在を知り、用途的規模的に十分使いものになりそうということでこれに決定。 サーチシステム自体の設定値を格納する基本マスタテーブルもだけど、まずは十二国記関連の基本情報を格納したマスタが要りますね。国マスタとか、キャラマスタとか、そういうの。たとえば一番簡単と思われるマスタはこんな感じ。 ※対象を特化したスクリプトなので、汎用的に全部同じテーブルに突っ込むというのはなし。そっちのほうが簡単にメニュー項目を増減できるけどね。 テーブル名称：国マスタ テーブル名：M_COUNTRY PRIMARY KEY 名称 データ型 NOT NULL 内容 ● ID INTEGER ○ SORT_KEY INTEGER 表示制御用 NAME TEXT ○ 名称 LONG_NAME TEXT ○ 長い名称 DATEとかVARCHARとかも一応指定できるけど、SQLiteのデータ型は実際には限られた数個しかないため、ここで使うのはINTEGERとTEXTにします。SQLiteの場合は桁数を指定しなくても大丈夫だし、何よりレコードは可変長とのことなので省略。他のDBとの兼ね合いでデータ型をそろえたり桁数を指定して「VARCHAR(10)」みたいに書いたほうがいいかもしれないけど、どっちにしても試行錯誤中だし。 国マスタの場合、いったん作成したら作り直す必要はない＆ユーザではなく管理者が設定するので、UNIQUE制約とかはなし。数が限られている上に普通にデータを入れればどうしたってユニークになるし、こんな小さなテーブルで余分なINDEXを作ることもないし（ユニークにすると自動的にINDEXが作成される）。NOT NULL制約の場合は、自分でカラムの性質の意図を忘れるのを防止できるのであったほうがいいけど IDは、国マスタの場合は1からの連番。裏で持っていて検索時に使うとか、他のテーブルに外部キーのようなものとして格納するので、人間にわかりやすくする必要なし。 SORT_KEYは画面表示用のオプション。検索時、ORDER BY句で使うのを想定。必要がなければNULLにしておく。IDと違って厳密じゃなくていいので重複可。項目を作っておけば表示順を変えるときにSQL（ソースコード）に手を入れる必要はないし、値に何を入れても、クエリの結果順にしか影響を及ぼさないのがミソ。 NAMEは通常の表示名。慶国なら「慶」、雁国なら「雁」。 LONG_NAMEはフルネーム。慶国なら「慶東国」、雁国なら「雁州国」。 ちなみにINTEGER型のカラムを（単独で？）プライマリキーにすると、SQLiteでは自動的にオートナンバー型になるそうです。とはいえ一般データならそれでもいいんでしょうが、マスタだと再構築の際に何かと問題ありなので、INSERTの際に明示的に指定することにします。 なおDBの文字コードはデフォルトのUTF-8とします。CGIでも何かと面倒がないし。 あと、テーブル名やカラム名に日本語も使えるらしいし、ローカルで試したらうまくいったけど、トラブったらイヤなので普通に英数字で。日本語だとSQLの斜め読みできそうで便利は便利なんですけどね。日本語を使うと名称がどうしても長くなりがちというのもあります。 追記 DBの初期化機能作成後、文字列だった日付データをユリウス日（浮動小数）で持つよう変更しました。DBの型もTEXTからREALに変更。 文字列で持とうとしたのは、まぁ、SQLiteに型がない＆深く考えてなかったのと、レコードを目で見たときにわかりやすいほうが楽だったから。というか最初はあまりまともな物を作れるとは思わなかったし……そもそも早い段階で飽きて放置するかと(^^; でもまあ、それでもいろいろ作っていたら、WHERE句での指定でユリウス日のほうが面倒がないとか、多分REALのほうが速いんじゃないだろうかってのがあって。何より文字列だと「これってUTCだっけ？ localtime？」等々紛らわしいけど、ユリウス日なら区別する必要なし。で、表示時だけ任意の形式＆ローカル日付でフォーマットする、と。 2010/10/14 18 29 21更新
https://w.atwiki.jp/12kokuki/pages/64.html
テストデータを作る 検索まわりのテーブルは作ったので、とりあえずテストデータを入れてみることに。 最初はテストのバリエーションも兼ねて自分で作っていたけど、なんかパターンの作成が面倒になったのと、実データに近いほうが得るものがあるだろう（あれは考慮してなかった、こういうケースもあるのか等々、いろいろ出てくる）と思ったのとで、実際のサーチで登録されているデータ70件ほどを参考にしました。 でも、テーブルが多いだけにさすがに大変。特に項目の多いサイト情報テーブル。 なので最終的にはOpenOfficeのCalcで入力、INSERT文を記載したSQLファイルをマクロで自動生成しました。おかげで初めて実用的なOOoのマクロを作っちゃった（Excelにしなかったのは、Excelが入っていないマシンでも作業するため）。 ただOOoのマクロは、文字コードを考慮したファイル出力はできないようですね。なのでいったんShift_JISで出力、エディタを使って手作業で文字コードを変換することに。ほとんどは数値データのテーブルとあって、変換が必要なのはサイト情報と更新履歴くらいだから、大した手間じゃないけど。 文字コードと言えば、苦労したのはマスタのINSERT文のほう。 こっちはスタティックなデータだからエディタで直にファイルを作ったけど、普段使っているサクラエディタだと、UTF-8でもキャラマスタで桓魋の字が化ける上、実際に文字データも壊れるんだよね……。Notepadだとちゃんと表示・編集できるけど、こっちは保存するとき勝手にBOMがついちゃう。 とにかくデータが壊れてはどうしようもないので、結局はNotepadで編集→バイナリエディタでBOM削除、というアホな手順にしました（その後、Meryという軽量エディタで乗り切ることに）。 ちなみにテーブルやビューのCREATE文もファイルにまとめてあるため、テスト用のデータでデータベースを作り直したくなったら、それらSQLファイル群を順に流すだけ。最初はSQLiteで使えるSQLを確認しながらだったこともあって、頻繁にエラーも出したし面倒だったけど、環境が整ってきたらかなり省力化できるようになりました。 プロトタイプとはテーブル名やカラム名が微妙に違うので、それに合わせてPHPコードを修正、登録サイトがある項目のみメニューに表示、当該メニュー項目に張ってあるリンクをクリックして該当するサイト情報を整形表示、までは動作することを確認。 もっともサイト情報は100件もないため、当然ながらあっという間に表示されるけど。 検索結果 せっかくなのでヘッダのHTMLも作り、メニューにもちゃんとスタイルを指定して検索を実行した画面がコレ。 なおデバッグ中なので、その辺の余計な情報も出してます。 まあ、悪くはないと思うけど……本当はフレームにしたくないので、その辺が不満。 最初のイメージだと単一のページにして、小さな画面を使っている人に配慮してコンテンツ表示の最大幅を700px前後に留め、上部にヘッダ、メニューは右、検索結果は左、というレイアウトにしたかったんだよね。メニュー項目リンクのクリックによる実行だとPOSTでデータを送るわけじゃないため、ページに埋め込んだメニューの再表示時にユーザの入力状態を復元できなくてあきらめたけど。 ……まあ、リンクに見せかけたSUBMITボタンにすれば不可能ではないんで、どうするかなぁ。 あと当然ながらHTMLは表現が限られるので（JavaScriptは極力使わない）、どうしても冗長になりがちというのがねー。 更新履歴一覧 サイト情報に付随するテーブルは全部作ったため、テストデータを入れてしまえば後は何をどのように検索するかだけだから、こんなのも思いつきで簡単に作れちゃいます。 なんか、こうやってスクリーンショットを出すとほぼ完成に見えるけど、検索結果についてはページ切り替え（１ページにつき表示上限数までしか表示せず、前後リンクでページを切り替えられるようにする）を実装していなかったりするし、ここまでなら、ちょっとプログラミングができる人なら誰でもできるようなレベルだったりします（ページ切り替えは、まず全体の件数を取得してから、実際に表示する範囲のデータを取得する等々しなきゃいけないので何かと煩雑）。 それよりはるかに面倒というかキモなのは、ユーザの認証と、それに付随する管理画面の機能。ユーザが管理画面から自分でサイト情報（複数サイト登録可）をメンテできるようにしたいんで。違反報告とかも、まずは当事者（指摘する閲覧者と、相手のサイト管理人）で匿名でやりとりしてもらって、それでも指摘側が不満だった場合のみサーチ管理者に申し立てできるようにしたいため、その辺の機能の作りこみがかなり面倒だったりします。 2010/09/07 20 50 08
https://w.atwiki.jp/12kokuki/pages/58.html
データテーブルを作る サイトに付随する登録データのうち、要素が可変のものは別テーブルに。そうすればサイト情報自体には入れなくていいから「カテゴリ用カラムをいくつ入れよう？」などと悩む必要もなくなります。 重要度（PRIORITY）を指定できるようにしておけば、サイトごとにそれでソート可能だし、登録数が多いようなら上限を設けて、一覧には一定数しか出さないようにすればいい（詳細情報ページには全部出す）。 したがって各種登録データを格納するテーブル群は、ユーザ情報とサイト情報以外はほとんど各マスタの値を保存するだけとなり、かなり小さなテーブルに。 たとえばこんなサイト情報（D_SITE）と基調（D_MOOD）が登録されていたとして、 ID NAME MEDIA 1 ほげほげ 0 2 ほにゃらら 1 3 ふにふに 0 SITE_ID MOOD_ID 1 1 1 3 2 1 こんなクエリを発行すれば、基調ごとの登録サイト数がわかります。 SELECT M.ID AS ID, M.NAME AS NAME, COUNT(D.SITE_ID) AS TOTAL FROM M_MOOD M, D_MOOD D WHERE M.ID = C.MOOD_ID GROUP BY ID ID NAME TOTAL 1 シリアス 2 3 ラブラブ 1 もっとも実際にはビューにするので、引っ張ってくるときにソート順をどうするかを考えるだけです。 メディアごとの登録サイト数は、これは他のテーブルではなくサイト情報自体が持っているデータなのでこんな感じ。 SELECT S.MEDIA AS ID, M.NAME || 向け AS NAME, COUNT(S.MEDIA) AS TOTAL FROM D_SITE S, M_MEDIA M WHERE S.MEDIA = M.ID GROUP BY S.MEDIA ID NAME TOTAL 0 PC向け 2 1 携帯向け 1 それにしても長年SQLを適当に書いてきたんで、どう書くのが正しいのかよくわからなかったり(^^; たとえば上記のSQLだと、別名をつけなくても結果のヘッダはID、NAMEになるように見えるのに、PHPで取得するときはその名前じゃアクセスできないんですよね。なので単純にするためにすべてASをつけたけど……本当はどうするのが正しいんだろ？ 2010/09/06 10 54 08
https://w.atwiki.jp/mh4_yumi/pages/91.html
強走薬のページ、「弓師」（弓を作る人）ではなく「弓士」（弓を使う人）では？ ネタなのかも知れませんが… -- (名無しさん) 2014-01-14 04 11 42 ↑どこでも使われてるネタじみたもんですねｗ ちなみに弓師っていうと弓を作る人のこと、弓を使う人は弓使いか射手（いて）っていうはずです。 -- (名無しさん) 2014-01-14 21 02 06 怪力の丸薬のページに種の説明が書いてありますね 編集できる方、お願いします。 -- (名無しさん) 2014-02-07 19 26 44 ↑修正しました。 ついでにページがなかったアイテムも一部追加しました。 -- (名無しさん) 2014-03-22 18 18 43
https://w.atwiki.jp/yarumi_gamemaker/pages/81.html
やる実がゲームを作るようです一覧 001【腹筋】やる実がゲームを作るようです【しろよ】 002【STG】やる実がゲームを作るようです【作りたい！】 003【ロック】やる実がゲームを作るようです【オン！】 004やる実がゲームを作るようです：フォース ウィズ ユウ！ 005【何を】やる実がゲームを作るようです【今さら】 006やる実がゲームを作るようです 007やる実がゲームを作るようです7 -宿命の対決！- 008やる実がゲームを作るようです８ -どうしてゲーム作ろうと思ったの？- 009_1やる実がゲームを作るようです 009_2やる実がゲームを作るようです 009_3やる実がゲームを作るようです 009_4やる実がゲームを作るようです 009_5やる実がゲームを作るようです 010_1やる実がゲームを作るようです 010_2やる実がゲームを作るようです 010_3やる実がゲームを作るようです 010_4やる実がゲームを作るようです 011_1やる実がゲームを作るようです 011_2やる実がゲームを作るようです 011_3やる実がゲームを作るようです 011_4やる実がゲームを作るようです 012_1やる実で学ぶレギュラーエクスプレッション 012_2やる実で学ぶレギュラーエクスプレッション 012_3やる実で学ぶレギュラーエクスプレッション 012_4やる実で学ぶレギュラーエクスプレッション 012やる実で学ぶレギュラーエクスプレッション/URLにリンクを張る 012やる実で学ぶレギュラーエクスプレッション/カウントダウン 番外編001 やる実は曲がり角でイケメンと激突するようです 番外編002 やる実がC++でプログラミングするようです 前編 番外編003 やる実がC++でプログラミングするようです 中編 番外編004 やる実がC++でプログラミングするようです 後編 番外編005 やる実が餃子を作るようです 番外編006 やらない子がシナリオはダイヤモンドなようです 目次
https://w.atwiki.jp/clubutakata/pages/171.html
豆腐にならないように家を作る教科書を作ってみました。 基本として部品部品をちがうブロックにして分けます。 柱は柱、壁は壁、屋根は屋根という風にわけます。 豆腐にならないためには段階をわけて凹凸を付ける必要があります まずは基礎づくり 適当な大きさで地盤をつくりましょう。この場合は偶数でつくってます。 次に梁（ﾊﾘ）をつくる。 梁は飛びださせて飛び出しブロックをつくりましょう！これがポイントとなります。 屋根を作る 屋根の端っこは丸石、石レンガがおすすめです。 屋根の色は派手な色がおすすめです。今回はダークオークにしてみました。 屋根の側面はこのような形です。必ず１ブロック飛び出させましょう。飛び出しブロックは大切です。 外装を作る。 外装で以下に凹凸を作るかがポイントになります。 窓の下に階段を逆さにつけて凹凸をつくってみました。 トラップドアは開いた時の窓のようにしてます。それっぽくなるのでおすすめ あとは自由にカスタマイズするだけです！
https://w.atwiki.jp/fightsle/pages/14.html
頑張ってウィキを作るスレ観察調 2008/01/15(火) 頑張ってウィキを作るスレ観察調 2008/01/16(水) 頑張ってウィキを作るスレ観察調 2008/01/17(木) 頑張ってウィキを作るスレ観察調 2008/01/18(金) 頑張ってウィキを作るスレ観察調 2008/01/19(土)
https://w.atwiki.jp/btbuilder/pages/16.html
Create a closed loop track サーキットなど一周するコースを作る際に使います。 これの場合1本しか作れません 公式ページにチュートリアル動画(英語)があります Tutorials-First Trackをご覧ください http //www.bobstrackbuilder.net/videos.aspx Create an open track 一本道のラリーコースやピットレーン、別の分岐などを作る際に使います。 これの場合は何本でもコースを作ることが出来ます。 Optionの欄でDefault Curve TypeをCardinalに選んだ場合はコースの形にクリック。 Bezierを選んだ場合はクリック＆ドラッグでコースの形にしてください。
https://w.atwiki.jp/shop-rule/pages/14.html
お店のサイトを作る お店のサイトを作る商品の販売方法を決める 出納帳の準備 ＢＢＳの設置 サイトの種類ｗｉｋｉ ショッピングカート ブログ ホームページ 開店する為には＜お店の要件＞を満たすサイトを作らなくてはいけません。 最低限必須なのは「スタッフリスト」「ＢＢＳ」「設定」「資産」の４個です。 ｆ：お店の要件 ＝ スタッフリスト、ＢＢＳ、顧客との連絡手段（ＢＢＳ、チャット、メールフォーム等）、設定、保有する資産を持ち、かつ、これらを最新の状態に維持すること。 スタッフリストはお店のメンバーを国民番号付きでリストアップしておけば問題ありません。 ＢＢＳはレンタルＢＢＳを借りることで、簡単に用意できます。顧客との連絡手段もＢＢＳが一つあれば要件を満たすので、大丈夫です。 設定はどこの藩国にあるか、とかの文章設定や、店舗や組織のアイドレスとその設定などです。最初は立地など、簡単な物で良いと思います。 資産は金庫番が管理してくれます。お店は金庫番に申請する為の売上履歴や作業報酬分配リストを作る必要があります。 このほかにも、ショップ系なら「商品」と「商品のリスト」、サービス系なら「企画の公示場所」「企画を実行した後のまとめ」などが必要になってきます。お店の活動内容に必要なページを追加していってください。 △ ページの先頭へ戻る 商品の販売方法を決める ショップ系企画の場合、どういう手続きで商品を購入するのか考えなくてはいけません。それによって必要なツールも変わってきます。 ショッピングカートには元々「お客様が購入を決定する」と、「お店に誰が何を購入したか知らせる」という機能があります。そういう機能を持たないサイトで商品を販売するなら、何か方法を考えなくてはいけません。 何を買うかＢＢＳに書き込んでもらう wikiやブログのコメント欄に書き込んでもらう 購入決定用のＷＥＢフォームを用意する etc ざっと見渡すと、ＢＢＳに書き込んでもらうのが主流のようです。 また、商品を購入していただいた時、根拠になるログを用意して各組織へ報告することになります。詳しくは商品の売買と報告についてを一読してください。 どのような形で「いつ誰が何をいくらで購入した」と記録するかはお店によります。ＢＢＳのログをそのまま使うお店もいれば、情報をまとめてｗｉｋｉに載せるお店もあります。管理しやすい方法を選んでください。 △ ページの先頭へ戻る 出納帳の準備 実は、金庫番が管理してくれますので、無くてもやっていくことができます。ですが、報告するまでの控えとして売上や納付の記録をつけておいたほうが何かあった時にわかりやすいです。 売上を順に記録するだけのものから、お店の商品に必要なリソースも含めて管理するものまで様々です。貴方が管理しやすい出納帳を作って下さい。 参考：広告代理店ＮＭＤ 出納帳 △ ページの先頭へ戻る ＢＢＳの設置 様々な機能のＢＢＳがあります。個別の記事に返信、画像のアップロード、ツリー表示、新規投稿をメールで通知、等など。貴方のサイトに欲しいのはＢＢＳはどんな機能を持ったＢＢＳですか。 無料でレンタルできるＢＢＳがたくさんあります。種類もいろいろです。広告が出たり、機能に制限があったりしますが、充分使えます。比較サイトで調べるか、藩国やお店で使っているＢＢＳのレンタル元ページを見に行って借りてみましょう。 自分でＣＧＩを設置できる人は無料配布ＣＧＩのＢＢＳを設置してみてはどうでしょう。ＣＷＴＧは自分で設置するタイプのＢＢＳを使っています。広告はありませんし、自由にカスタマイズする事も出来ます。 レンタルＢＢＳ比較Googleで「無料 BBS 比較」を検索。比較サイトがたくさんあります。 掲示板改造支援サイトＣＷＴＧで使っている改造版Web ForumのＣＧＩ配布サイトです。 KENT WEB様々なＣＧＩを配布しています。改造前のWeb Forumはこちらの配布物です。 △ ページの先頭へ戻る サイトの種類 お店のサイトを作る時に利用可能なＷＥＢサービスをいくつか紹介します。 アイドレスで主流なのは wiki ですが、ショッピングカートも人気があります。もちろんブログやホームページでお店のサイトを作っても問題ありません。 サービスのレンタル元、配布元サイトにはサンプルページや使い方が載っています。気になるサービスがあったなら、そのサービスのレンタル元、配布元サイトに行って、サポートページをチェックしてみてくださいね。 △ ページの先頭へ戻る ｗｉｋｉ 複数の人が編集できる。 携帯に対応している物もある。 デザインがＷｉｋｉに依存。 ｗｉｋｉの書き方を勉強する必要がある。 商品を販売する手順を考えないといけない。 アイドレスの藩国サイトやお店でも良く見かけるｗｉｋｉ。編集のしやすさが魅力です。商品の配置にも様々な趣向を凝らす事ができます。企画の表示もしやすいです。 ｗｉｋｉの種類によって少しずつ書き方のルールが違うのですが、一つ覚えれば、他のｗｉｋｉの編集も楽にこなせるようになります。 ちなみに、このサイトは＠ｗｉｋｉを利用しています。 ＠ｗｉｋｉアイドレスで一番利用されているｗｉｋｉです。 livedoor Wikiライブドアのｗｉｋｉです。色々なテンプレートが用意されています。 FC2 WIKI様々なｗｅｂサービスを無料レンタルしているＦＣ２のｗｉｋｉです。 WikiFan Wiki無料レンタルサイトについて様々なレンタルｗｉｋｉの機能比較を行っています。 △ ページの先頭へ戻る ショッピングカート 陳列した商品が見やすい。 携帯に対応している物もある。 デザインがカートに依存。 商品の管理をしやすい。 購入手続きが出来上がっている。 何かを販売する為のサービスなので、購入手順がわかりやすく決まっていてお客様も迷いません。商品管理も簡単ですし、商品一覧を見やすく配置する事もできます。 レンタルショッピングカートは本格的で有料なものが多く、無料で利用できるのはＦＣ２ぐらいでしょうか。自分でＣＧＩを設置できる環境があるなら、無料配布のプログラムを使ってみるのも手です。 また、商品表示以外の説明や明細を載せる場所が無いカートも多いですが、これは他のｗｉｋｉやホームページと組み合わせて使うことで回避できます。 FC2 レンタルショッピングカート無料レンタル。ＣＧＩを設置する手間はありません。 Web Cart Professionalアイテムショップなどで利用されているＣＧＩ。細かい所までカスタマイズできる高性能なＣＧＩです。 ショッピングカート機能比較Googleで「無料 ショッピングカート 比較」を検索。比較サイトがいくつかあります。 △ ページの先頭へ戻る ブログ 工夫しないと商品が見にくい。 携帯に対応している物が多い。 デザインがブログに依存。 特に書式を覚えなくても良い 商品を販売する手順を考えないといけない。 何よりも、更新が楽です。携帯に対応している物も多いです。 商品表示に難がありますが、カテゴリ機能を使って商品や企画を分類表示するなど工夫すれば、わかりやすい陳列もできます。 ウェブリブログテンダイスが使用しているブログです。 So-net blogＧＰＯのブログデザインを使用できます。 無料ブログ比較Googleで「無料 ブログ 比較」を検索。比較サイトがたくさんあります。 △ ページの先頭へ戻る ホームページ お勧め商品を強調したり、見やすく並べたりできる。 工夫すれば携帯対応できる。 デザイン自由自在 一番自由度が高いですが、作成からアップロードまで全て手動になるため、更新がものすごく面倒くさいです。また、携帯に対応するには、別にページを作ったり、様々な工夫をする必要があります。ＨＴＭＬ／ＸＭＬを書くのが好きな方や、デザインに懲りたい方は、ホームページを作るのも良いかも。 ショッピングカート等とあわせて使うことも出来ます。 無料ホームページ比較Googleで「無料 ホームページ 比較」を検索。比較サイトがたくさんあります。 △ ページの先頭へ戻る