必要に応じてトピックを増やしてください。
この掲示板は誰でも発言できます。関係者以外の方でも、何かご意見やご感想等がございましたら、お気軽にご利用ください。
ファイルを添付できる掲示板も用意しました。ご利用ください。
- 技術的な内容に関する意見交換はこちらで。 -- (せきやひろし) 2010-06-01 21:20:29
- 確かに最初の段階で面倒くさいユーザ管理をしてもしょうがない気がしてきました。リスナー数千人＋シェル上限100体程度の想定で、全員同時通報＋ブラックリスト方式で始めるのが妥当という点に賛成です。この規模なら結局全員がほぼ全キャラの会話を欲しがる、というのもその通りと思います。
●通信帯域について
10MBのシェルは殆どありません。何十というアニメーションパターンを備えた現存最重量級のシェル「毒子」ですら10MB超えません。平均は1.5MBくらいのようです。
シェルは静的ファイルなので、いざとなったらハッシュでsignature付けて、無関係なWebサーバ(シェルマスターの個人サイトとか)に丸投げできると思います。もちろんSourceForge的な管理付きミラーサーバの方がより安全でしょうが。またシェルは遅延DLで良いですが会話には即時性とお祭り時の瞬発力が要るので、会話処理の方が帯域処理が楽ということは必ずしも言えないと思います。まあこれは「将来ユーザが増えたら」の話なので、とりあえず今は考えない、というみかげさんの意見に同意です。
あと会話の帯域がN^2で増えるというのも言い過ぎで、規模が大きくなればなるほどライトなROMユーザの割合が増えるでしょうから、実際はN^1.5くらいな気がしました。特にリスナーが1晩で突然増える可能性は十分考えるべきですが、その場合の負荷の増え方は単純にNに比例です。キャラクターが1晩で突然増える可能性は非常に低いでしょう。
●Twitter連携について
やっぱりサーバ側で処理するのは、そのサーバをブロックされると一発アウトなので、大変よくない気がしてきました(^^;) AIR版クライアントでTwitter投稿予約機能を付けるほうが現実的ぽいので、やるとしてもその方向、ということで…。 -- (naruto) 2010-08-08 21:46:31
- シェルは思ったより容量少ないようですね．平均1.5MBならもう少し楽観できそうですね．いずれにしろスレーブサーバで分散できる構成には早めにしたいところです． (mikage)
- Twitter連携をAIR版クライアントでやる場合，他のクライアントだと投稿できなくなるのがデメリットですね．ただ，クライアントであれば，xAuthが使えるはずなので，IDパスをそのまま入れてもらって連携ができるはず．色々面倒だと思いますし，Twitter側の修正に左右されるのは大変だと思うので，後々で良いとは思います． (mikage)
- シェル・キャストの2重構造は，柔軟にシェルを扱えるメリットはありますが，利用ユーザからすると複雑で，理解しにくいように思います．
- 以下のような形ではどうでしょうか．
- シェルはアップロードしたシェルマスターのみが利用できる．
- オープンシェルとして公開したい場合は，シェルのzipファイル自体を作者が配布すればよい．
- パスワード付きシェルのレベルで公開したい場合，作者のページでこっそり公開するとか，友人のみにzipファイルを配布すればよい．
- クローズドシェルの場合は，zipファイル自体を配布しなければよい．
- シェルは，同じファイルを複数の人がアップロードした場合，別々のIDが振られ，別々のキャラクターとして振る舞う．
- シェルをクライアントがDLする場合は，zipファイルのSHA-1ハッシュ値を元に判断し，同じハッシュ値のシェルをDL済みであったら，そのファイルを利用する．
- この形式では，以下のメリットがあります．
- 仕組みが単純で，キャストになるユーザがやることが明確．
- オープンシェル・パスワード付きシェルの利用者はクローズドシェルに比べれば少ないと考えられるので，システム側で対処するより，ユーザ側に任せた方がより柔軟な管理が可能．また，システム側でオープンシェル・パスワード付きシェルを実装したとしても，ユーザがzipファイルを再アップするような使い方をすれば意味が薄れてしまう．
- zipを配布するという形を取れば，シェルを少しだけ変えて使いたい，といった要望にも対応しやすい．（もちろん最初の作者が修正を許可する場合に限りますが）
- みかげさん案のままでは、キャラクターを作る人はZIPファイルのアップロードなりシェルの能動的なWeb検索なり、僕が想定していたよりかなりハードルが高い作業をこなす必要があります(ゼロからSSPでゴースト作者になるよりはマシですが)。
僕としては、「自作シェルの利用者より公開シェルの利用者がずっと多い」という認識で、Yahoo!のアバターやネットゲームのキャラを作成するのと同レベルの気軽さを考えていました。「キャラクター作成ボタンを押すと、とりあえずオープンシェルの一覧が出て、数クリックで作成完了」という感じです。各種ブログサービスとも似ています。既存のデザインから選んで数クリックで作成するのが普通であり、難しい自作デザインをやる人は全体の1割もいません。ZIPで配布されているデザインテンプレートをWeb検索で求める人など殆どいません。(そこまで気軽にキャラが増えることがそもそも望ましい方向性かという点で認識の統一は必要そうですが)
ただ、みかげさん案は、シェルがアップデートしてもキャラクターは連動しないのでシェルバージョン整合の面倒くささを考えなくて良く、カスタマイズ版のシェルが作れる自由度もあるので、魅力的と思います。シェルとキャラクターを1対多の形でシステム上で縛り付ける構造は確かに悪そうです。
折衷案として以下のような感じはどうでしょう。
・キャラクターはそれぞれ固有にシェルを持つ。SHA-1チェックで重複ダウンロードを避けるなどの負荷軽減はする(これはみかげさん案の通り)
・キャラクター作成時、上級者は直接シェルをZIPでアップロードするが、オープンなものについて公式のシェルセンター(仮称)を作り、そこから検索したり一覧したりZIPファイルを経由せずにインポートしたりできる。HIMAGINE版の「伺かゴーストセンター」にあたる物です。
・シェルセンターからインポートする際にシェルマスターによるパスワード指定もできる。
・シェルセンターからはシェルをZIPとしてDLして上級ユーザがカスタマイズする余地を与える(原作者が許可している場合のみ)。
・シェルセンターはニコニコ動画に対するsmilevideo、みたいな感じで多少別サイトとして後から運用を始めても良い。初期のテスト段階ではひとまずシェルセンター自体要らない。 -- (naruto) 2010-08-10 09:32:16
- なおこの方法で行く場合、PNGやPNAのファイルは全部SQLiteに放り込み、
ファイル名ではなくSHA-1のIDで識別することになると思います。
設定ファイルの文字が1か所異なるだけの微妙なカスタム版シェルや
1枚画像を増やしただけの新版シェルが無数に生まれる恐れがあるのでZIPファイルレベルの
粒度では帯域とストレージ容量がかなり無駄になりそう。
みかげさんには、シェルをZIP丸投げで渡すのでなく、ZIP内容のファイル名＋ハッシュ一覧の提供と、シェル名＋ファイル名を指定しての個別ファイルDL機能の提供をお願いしたいです。 -- (naruto) 2010-08-10 09:58:54
-
では，こんな感じでどうでしょうか．
・ユーザはWebでアカウント登録をすると，シェルの登録もしくはオープンシェルの利用を（複数）選べる．
・シェルの登録の方を選んだ場合，zipでアップロードする．その際，そのシェルをオープンシェルにするか，クローズドシェルにするか選べる．オープンシェルの場合は，利用条件の記載ができるようにする．（zip改変を許可する場合は，zipの配布サイト等をそこで紹介する）
・オープンシェルの利用を選ぶと，アップロード済みのシェル一覧が表示され，その中から選ぶ事ができる．（ゴーストセンターのようなものはHIMAGINEサーバ側の基本機能として実装）
・いずれの場合も，選んだ後にキャラクターのプロフィール等を登録する．
以下の機能はやめます．
・パスワード付きシェル（仲間内の配布はzipで行えばよいし，一覧にパスワード付きシェルがいっぱい出るのはイメージが良くない）
・1つのキャラクターの複数人での管理機能（今のところ需要があまりなさそうなので）
SHA-1でのチェック単位ですが，ファイル単位とするとシェルのファイル数がかなり増えるのが心配です．
アニメーション等で小さなファイルが大量にあると，それはそれでサーバに負荷がかかります．
とりあえず数千とかの単位であったらかなり厳しそうです．
（1000人がアクセスに来たら，100万アクセスになるので…）
シェルというと，結構大量のファイルが存在するイメージがありますが，どうでしょうか．．．
確かにカスタマイズしたものは無駄になりますが，カスタマイズする人はそんなにいないのではないかとも思いますので，どっちをとるかですね．
-- (mikage) 2010-08-10 22:05:08
- だいたいこんな感じの仕様でOKです。
1個のシェルに数十から100個くらいの画像は含まれていますので、
小さな画像を個別にDLする方がむしろサーバーの負荷が高いと
みかげさんが判断するようなら、ZIP単位のDLで構いません。
僕の方でローカルストレージ容量軽減のため、既にSHA-1レベルで同じ画像ファイルが
あるなら2個同じものをHDDに保存しないような仕組みを考えることにしますね。
よろしくお願いします。 -- (naruto) 2010-08-10 22:26:46
-
シェル登録などを以下のように考えていたのですが，いくつか問題がありそうなので，
オープンシェルは別サイト管理にしようと思いますが，どうでしょうか．
■ 想定していた流れ
・ユーザはキャラクターを作成する際に「シェルをアップロードして作成」か「オープンシェルから選ぶ」を選ぶ．
・シェルをアップロードする場合，そのシェルをオープンシェルにするかどうかを選択できる
この流れだと，以下の問題がありそうです．
・オープンシェルにした場合，削除したいと思ったときに問題になる．削除不可にすると，シェルを何度も更新すると古いシェルが残る．
削除はしないけど一覧に出さない，という方法である程度回避はできるけれども，わかりにくい．
・オープンシェルから選ぶ時には，サムネイルくらいは欲しい．しかしzipからサムネイルは難しそう．
また，理想としてはサーフィスをそれぞれ確認できると良いが，それをするためにはFlashを埋め込む必要があるので，
この辺はなるさんに作ってもらった方が効率がよさそう．
■ 別サイト管理の場合の流れ
・別サイトは仮に「オープンシェルセンター」とする．
・オープンシェルセンターでは，シェルにIDを振っておく．
・ユーザはキャラクターを作成する際に「シェルをアップロードして作成」か「オープンシェルセンターのシェルを使用」を選ぶ．
・オープンシェルセンターのシェルを使う場合，オープンシェルセンター側のシェルIDを入力してもらう．（例えば 000-102 とか）
そうすると，サーバはオープンシェルセンター側のファイルを裏で持ってきて，シェルとして登録する．
・そのシェルが削除されるタイミングはキャラクターを削除した時になるので，わかりやすい．
ただし，オープンシェルセンター側でシェルを削除しても，既に利用中のシェルについては関与はできない．
（互換性を考えるとこの方が望ましいと思う）
■ その他
・シェルの削除については，既に利用中のものまで関与できない，という仕様でよいですよね．
・シェルの更新については，各キャラクター単位で，キャラクターの作者がシェルを差し替え可能にすれば良さそうです．
その際，過去のスクリプトについては，差し替え後のシェルで再生される，ということでよいでしょうか．
（シェル差し替え時に，互換性についてはキャラクターの作者の方に対応してもらう）
ランダムトークではなく，即時トークがメインということであれば，過去のスクリプトは
その時点でのシェルで再生できた方が良い，という考え方もありそうです．
どちらも一長一短ですが，どうしましょうか．
-- (mikage) 2010-08-22 11:20:46
- ＞シェルの削除については，既に利用中のものまで関与できない
＞シェルの更新については，各キャラクター単位で，キャラクターの作者がシェルを差し替え
はい、その通りでいいと思います。
基本的にキャラクターに直に関連づけられているのは、登録時シェルセンターに
あったシェルの「コピー」ということで。
なのでオープンシェルセンター側でシェルを削除することについては何ら問題ないですよね?
ただしシェルが更新されたときに通知とか、クリックで確認することで
自動更新くらいはできるようにしてあげたいです。
単にサーフィスが1個増えるだけの更新に、いちいちZIPファイルを
DLさせるようなのは良くないと思います。
＞オープンシェルセンターのシェルを使う場合，オープンシェルセンター側のシェルIDを
＞入力してもらう
できればクリックで済む形になりませんか?
＞過去のスクリプトについては，差し替え後のシェルで再生される，
＞ということでよいでしょうか
個人的には「当時の(差替え前の)シェルで再生させたい」派です。
クライアント内部では、ファイルをZIP単位とかファイル名とかではなく、
一旦SQliteに突っ込んでSHA-1で管理する方針です。だから差分シェルが沢山あっても
PNGファイル単位で共通な部分はストレージ容量を食わずに済みます。
だから昔のシェルの画像セットもずっと持っておいて再生させるのに問題ありません。
そのためにはキャラクターがシェルを更新するごとにそのシェルにリビジョン番号が付き、
発言毎にそのリビジョン番号が対応している必要がありますね。
あと昔のシェルもDL可能である必要がありそう。 -- (naruto) 2010-08-22 12:33:21
- ＞前にzipの中身のファイル一覧が必要とかそういう話があったと思いますが
＞そちらは結局無しで大丈夫になりそうなんでしたっけ．
これは単にDL容量削減の工夫というだけの問題ですから、ひとまずなしでOKかと思います。
ただ伺かのシェルは、極端な場合「毎日ネットワーク更新で1個ずつ画像が増えていく」
みたいなことをされてきた性質のものですから、差分を個別ファイルでDLして更新
できたほうが嬉しいとは思います。
過去ログを過去シェルで再生させる場合にも、当時のシェル内のSHA-1の一覧が手に入ると、
「現在持ってる画像のセットで再生できる」とか「この画像だけ昔のをDLすればいい」
と理解できて、DL容量を数MBから数KBに削減できます。 -- (naruto) 2010-08-22 12:45:23
-
＞なのでオープンシェルセンター側でシェルを削除することについては何ら問題ないですよね?
これは問題なしです．
＞ただしシェルが更新されたときに通知とか、クリックで確認することで
＞自動更新くらいはできるようにしてあげたいです。
なるほど．
シェルが更新されたときは，シェルIDに対して後継シェルIDとメッセージを
登録できるようにしておき，ログイン時にそのシェルIDを利用していたら
メッセージを確認できるようにするのが良いですかね．
で，更新ボタンを押すと，後継シェルIDに差し変わると．
そのことを念頭におきつつ，とりあえずはアップロード方式だけで
作成を進めますね．
アップロードの方での更新の場合は，キャラクターを選んで，
そのキャラクターに対してシェルをアップロードすると，
新しくシェルが登録されて，キャラクターに対応する現行シェルIDが
更新される形にしようと思います．
＞＞オープンシェルセンターのシェルを使う場合，オープンシェルセンター側のシェルIDを
＞＞入力してもらう
＞できればクリックで済む形になりませんか?
オープンシェルセンターでシェルを選んだ後，サーバ側URLに特定のパラメータに
シェルIDを追加したものにリンクしてもらうと，クリック後にキャラクター登録
画面に推移するような感じにしましょうか．
＞個人的には「当時の(差替え前の)シェルで再生させたい」派です。
ではそうしましょうかねぇ．
シェルを差し替えた場合は，シェルIDの方を変えようと思ってました．
シェルの更新は，新しいシェルIDでファイルを登録した上で，
キャラクターのシェルIDを書き換えると行った形です．
発言を管理する際に，発言毎にシェルIDを利用すれば当時のシェル再生ですし，
発言毎にキャラクターIDを利用して，そのキャラクターIDの現行シェルIDを
利用すれば最新のシェルIDになります．
＞これは単にDL容量削減の工夫というだけの問題ですから、ひとまずなしでOKかと思います。
＞ただ伺かのシェルは、極端な場合「毎日ネットワーク更新で1個ずつ画像が増えていく」
＞みたいなことをされてきた性質のものですから、差分を個別ファイルでDLして更新
＞できたほうが嬉しいとは思います。
シェルを更新する場合，新しいシェルと古いシェルの差分はわかりますから，
更新時は前後のzipの中身を比較して，更新がある部分だけzipで固め直した
差分ファイルを用意すると良さそうですね．
この方法ならDLファイルは1ファイルのままで容量を削減できますし，
毎日少しずつ更新するようなケースにはちょうど良さそうです．
-- (mikage) 2010-08-22 12:56:49
- ＞シェルの更新は，新しいシェルIDでファイルを登録した上で，
＞キャラクターのシェルIDを書き換えると行った形です．
その形で大丈夫そうですね。
発言毎に「キャラクターID」と「発言当時のシェルID」の両方があればOKです。
＞更新時は前後のzipの中身を比較して，更新がある部分だけzipで固め直した
＞差分ファイルを用意すると良さそうですね．
必ずしもインクリメンタルに更新されず数世代まとめて更新される可能性もありますし、
過去ログ関連では大昔使われていたシェルIDをピンポイントで指定されることもありえますし、
存在していたサーフィス画像が消える可能性もあるので、
「シェルIDを指定されると、含まれるファイル名とSHA-1の一覧を渡す」
「足りないものをクライアント側が判断して個別に要求する」
という2段階を踏むのが楽のような気がします。世代の差分で管理すると大変そう。 -- (naruto) 2010-08-22 13:06:54
- というか差分方式(update.dau)でやろうとした伺かのネットワーク更新は
人間には非常に扱いづらくて大変そうです。 -- (naruto) 2010-08-22 13:08:26
-
＞必ずしもインクリメンタルに更新されず数世代まとめて更新される可能性もありますし、
＞過去ログ関連では大昔使われていたシェルIDをピンポイントで指定されることもありえますし、
＞存在していたサーフィス画像が消える可能性もあるので、
＞「シェルIDを指定されると、含まれるファイル名とSHA-1の一覧を渡す」
＞「足りないものをクライアント側が判断して個別に要求する」
＞という2段階を踏むのが楽のような気がします。世代の差分で管理すると大変そう。
ファイルをばらばらに要求するとアクセス数が増えてしまう問題があるので…．
ディレクトリ構造を直しました，みたいな場合，数百アクセスが連続で
来る可能性もあると思うので，それは避けたいです．
数世代まとめて更新した場合，それぞれの差分ファイルを全部DLするのは駄目ですか？
複数回の更新で，画像が追加された後，それが消されたり，2回同じファイルが
更新された場合，多少無駄な転送は発生すると思いますが，サイズとしては
そんなに大きくないと思います．
クライアント側としては，以下のような流れでシェルをDLするイメージです．
１．DL済みではないシェルIDの発言が来たら，サーバにシェルIDの情報を要求する．
２．サーバ側は，そのシェルIDの情報を以下のような形で返す．
最新のzipファイルのURL ファイルサイズ
1世代前のシェルID 1世代前のシェルのzipファイルのURL 差分zipファイルサイズ
2世代前のシェルID 2世代前のシェルのzipファイルのURL 差分zipファイルサイズ
※ただし，サーバ側は，差分zipファイルサイズの合計サイズが，最新のzipファイルサイズを
超えるような場合，それ以前の差分のシェルID・URLは返さない．
クライアント側では，応答に既に持っているシェルIDが応答に含まれれば，
そのシェルID以降の全ての差分をDLし，順次適用．
そうでなければ，最新のzipファイルをDLする．
差分のzipファイルはサーバ側で更新前のファイルと比較して自動生成するので，
利用者が意識する必要は無いです．
その点で，伺かの方式みたいなめんどくささはないかと思います．
-- (mikage) 2010-08-22 13:18:29
- ディレクトリ構造やファイル名を変えたとしてもSHA-1が同じ画像ファイルを再要求する必要はありません。
それに、シェルに基本的に深いディレクトリはなかったはず。
また、世代管理だけでなく「あるオープンシェル」「少し違うその亜種」「その亜種」みたいな軸でのバリエーション管理も、ほぼ同じ枠組みで考える必要があり、そっちは差分ZIP準備で対応できません(シェルIDを別物にしているくらいなので、世代軸の更新も亜種軸の更新も内部的にほぼ同一に扱いたいですし)。
さらに、シェルを単に最新に保つだけでなく、ピンポイントである{時点/亜種}のシェルが欲しくなることがそれなりに多いと予想されるので、差分を重ねる方式は(僕が)わけ分からなくなり、結局フルセットを頻繁にダウンロードする羽目になりそうです。
究極的には毎回ツリーの差分を判定してまとめて送信するSubversion的な方式が理想かもしれませんが、面倒です。
一度に数十ファイルも新規画像を追加するような人はかなり稀と思いますし、それでも精々ちょっと凝ったウェブサイトを1ページ表示するのと変わらないと思います。
それでもきついなら、想定されるシチュエーションに対して汎用性が低すぎることを承知の上で、「直前の世代と現世代」という典型パターンのみ差分ZIP更新に「も」対応するのは可能と思いますが。 -- (naruto) 2010-08-22 14:34:50
-
ファイル単位は性能的に厳しいです．
どのくらいの性能かというと
http://blog.mikage.to/mika/2007/07/erlangwebyaws_1c22.html
に記載したくらいです．
同時に１０００人とかからの１００ファイルのリクエストを
受け付けたりするには厳しい数値だと思います．
% シェルの平均ファイル数がわかればもう少し正確な想定ができるかも．
% あと，別ポートで他のサーバを立ち上げれば，もう少し上がる余地はあります．
差分zip方式の場合，過去のシェルについては，多くの場合
フルセットDLになると思いますので，その点は不利ですね．
Subversion的な方法は，１クライアント毎に差分判定が必要に
なると思いますので，これも厳しそうです．
差分zipの場合は，サーバ側で最初に１回判定するだけなので，
その点がメリットですね．
究極的には，Bittorrentプロトコルなどを使って，クライアント
同士でP2Pで配信してくれればと思いますが，Flashではたぶん
無理ですよね．
（UPnP対応とかしないとほとんどの環境で役に立ちませんし）
-- (mikage) 2010-08-22 15:38:38
-
シェルの配布ロジックについて．
シェルを効率よく配布するために，アップされたシェルに対して
installShell コマンドというのを用意していたと思いますが，
これで配布を行うために，シェルをアップしてから利用開始までの
間にどのくらいユーザを待たせても良いでしょうか．
シェルを順次配布すれば，かなり少ない帯域でシェルを配布できます．
シェルUPから利用開始まで1時間待たせて良ければ，
5Mbpsの帯域で2250人に配布できるとも言えます．
もともと一斉にシェルをDLされないように，（時間については後で
考えると言うことにして）installShell コマンドで
順次配布することを考えていましたが，これだと以下のような
ケースで問題になることが考えられます．
深夜など人数が少ないとき，例えば接続者が300人，
アクセスが多い時間帯で接続者が1000人だとすると，
深夜にアップロードされたシェルは，300人に対しては
installShellで順次配布されます．
その後アクセスが多い時間帯に，そのシェルでの発言があると，
一斉に700人がDLすることになります．
700人くらいなら，50Mbpsを2分間で配布できるので
たぶんなんとかなりますが，数が増えるとISPから目を
付けられそうです．(^^;
サーバに接続する時間はばらけると思いますので，
その時間を上手く使って新しいシェルを配布できれば効率的です．
そこで，ログイン時にDL済みのシェルID一覧をサーバに送信し，
それを元にサーバ側がまだDLしていないシェルの installShell を
順次発行するようにすると良さそうですが，どうでしょうか．
新規ユーザは，例えば新しいシェルから，全てのシェルを
DLすることになると思います．
（ランダムトークが1つも登録されておらず，ずっと発言が
無いシェルであればskipしても良いと思いますが）
-- (mikage) 2010-08-22 19:29:09
- ＮＧユーザ機能と、それに付随して、spam通報機能の提案。
HIMAGINEで、ユーザからの送信を可能にするならば、ニコ動のＮＧユーザのような機能が必要になると思います。
投稿者本人に悪意が無くとも、「この人のネタはなんか合わない！見たくない！」と言うのはあるはず。
みんなが楽しめるようにするためには、見たい物だけ見られる、と言う機能はあった方がよいとは思います。
当然、投稿者本人に、誰からＮＧにされているか、などと言うことを通知する必要はありません。
これと関連して、spamみたいなのを防ぐために、NGユーザ機能と合わせて、Twitterで言う「spamとして報告する」機能があると良いかも。
一定件数(10件とか20件とか)以上通報が溜まったら管理者に通知が来て、管理者の判断でIDの凍結、削除を行う、など。 -- (せきやひろし) 2010-06-07 08:28:06
- Wiki全体に関する話題や、その他雑談などはこちらへどうぞ。 -- (せきやひろし) 2010-06-02 18:42:38
- 何となく思いついたので。キャッチフレーズとかコンセプトとか、そういう感じの物。
・無限の自由は無限の創造力を生み、無限の創造力は無限の可能性を生み、無限の可能性は無限の自由を生む。
・とこしえの自由。あふれ出すイマジネーション。限りない可能性。そして、それらの融合。 -- (せきやひろし) 2010-06-05 14:19:17
- 今後起こるであろう様々な話し合いのために、スレッドフロート式の掲示板があると便利かも、と思った。
誰もが簡単にスレッドを作成できて、その中で流れがまとまれば、あとから参照する時にわかりやすさが向上する。
スレッドフロート掲示板は、２ｃｈタイプのが有名だが、他にもそう言うスクリプトはあるので、そう言うのを使えば２ｃｈアレルギーの人も使いやすいだろう。 -- (せきやひろし) 2010-06-09 11:45:48
- 掲示板を仮設置してみた。
http://himagine.hironet.jp/bbs/ -- (せきやひろし) 2010-06-10 12:58:32
- 投稿テスト等はこちらで。 -- (せきやひろし) 2010-06-01 21:20:43
- 改行テスト。
改行テスト。
改行テスト。 -- (せきやひろし) 2010-06-01 21:24:15
最終更新：2010年06月10日 22:41
