Wiki系(WikiEngine)について語るスレPart2 1 ：
nobodyさん ：
03/08/13 10:46 ID:pknbXO9I FSWiki3.4.2をXreaで設置できた人っていますか?
なんかFSWikiって「開発を停止しようとも思いましたが」とか「CVSが勤務先から使えない」とか、開発者の微妙なやるせなさを感じるこのごろ。
fswikiは3.4.3がリリース準備中らしいので、しばらく待たないとな。
もうちょっとupdate時にユーザに優しい仕様になってほしいな ＞ FSWiki
開発者がunix文化から微妙に外れているのがアップデートのしにくさにつながっているっぽい。
8 ：
nobodyさん ：03/08/13 20:08 ID:N/1VW/Hl
あげちまいました。スマソ
FSWikiのバージョンアップは何度かやってますけど、
>>6 漏れも禿同。
基本的な部分がころころ変わっちゃうからけっこうきついんだよねぇ。
3.4.xから3.5.xもプラグインのAPIが変わっちゃうし・・・
12 ：
nobodyさん ：03/08/13 23:23 ID:05UZOv5m
FSWiki 3.4.3 age
13 ：
nobodyさん ：03/08/13 23:45 ID:/NS185ja
msblaster age
なんか、fswiki3.4.3のリリースでの、コレより前のバージョンへの警告文がえらく控えめに思うのは漏れだけか？
一般的な話題として、
俺は「早急にバージョンアップされることをおすすめします。」の一文と
vis.ne.jpから追い出された一件でとっととUpdateしなきゃヤバイなぁと
思っているが。
但し
>>8 や
>>10 的な理由でUpdateするのも怖かったり・・・(´･ω･`)
ｆｓっと書式が違うから、yuki系に乗り換えるとデータがそのままじゃ使えないんだよなぁ……
Wikiの書式なんて単純に置き換えすればすむでしょ。
FSWiki[うぷ|いんすとろーる]時に関する最低限の要望としては
>>19 > あと個人的にはconfig系のファイルはEUC-JP, LFがいいんだけど、
> これはまぁ別に要望出すほどのもんでもないか。
あ、同意。いろいろ混ざってるから、せめて統一してもらえないかなと・・・。
21 ：
nobodyさん ：03/08/14 14:51 ID:3+yAThCy
Pukiwikiで印刷用にヘッダ・フッタ・MenuBarを非表示にするモードってないですか?
22 ：
nobodyさん ：03/08/14 15:56 ID:SyUXGdwy
堤さやかちゃんの引退記念作です。
これは絶対見るしかないでしょう。
甘えたしゃべりかた、小さな身体に大きなオッパイ、そしてこの顔。
どれをとっても特Ａ級！こんな子がＡＶ女優だったなんて信じられませんね。
無料ムービー観てね
http://www.exciteroom.com/ 今、ふと思ったんだがページ名をすべてアルファベットでネーミングすると処理が軽くなったりする？
ボトルネックによる。
27 ：
：03/08/15 20:56 ID:???
FreeStyleWikiでURLに一々「wiki.cgi」って付くのが野暮ったいので、
>>27 /setup.dat
の
63行あたり
> # CGIスクリプトのファイル名
> script_name = wiki.cgi
を
> script_name = index.cgi
にすれば動くんじゃねーの？
漏れは やってないから想像だけど。
違ってたらスマソ。
29 ：
山崎 渉 ：03/08/15 22:26 ID:???
(⌒V⌒)
30 ：
27 ：03/08/16 00:16 ID:???
>>28 それではブラウザのアドレス欄に「index.cgi」と表示されてしまって
わざわざファイル名を変える意味がないので、/setup.datのその部分を
script_name = ./
に書き替えたところ、ログインできなくなったのでした。
そういうのは.htaccessでrewriteしましょう。
>>31 rewriteしたらlogin出来なくなる筈。
ログインするときのリンクだけwiki.cgiにしておく
質問の意図からは外れてるかもですがコピペ
YukiWikiでの見解
ttp://www.hyuki.com/yukiwiki/wiki.cgi?FaqPage#i39 Q>レンタルサーバに設置して運用してみたいと思っているんですが、サーバに対しての負荷って
どの程度になるんでしょう？ 禁止事項の一つ「巨大なデータを読み込むCGI（負荷のかかる
検索CGI等）」ってのに該当するんでしょうか？(^^;;;
A>負荷を計測したことは無いのですが(1)読み込むデータ量(2)処理内容などからすると、
ちょっと高機能な掲示板程度だと思います。レンタルサーバで使っていますが、
特に苦情はきていません。
ttp://www.hyuki.com/yukiwiki/wiki.cgi?FaqPage#i41 Q>このシステムの場合、理論上の最大ページ数はいくらになるのでしょう？
ディスク容量の制限のみでしょうか？
A>ソースを詳しく読んだ訳ではないが、wiki.cgiだけを見た場合、論理的な制限は明示されていない
ようです。実際の制限としては、保存に関してディスク容量と使用しているDBMライブラリの制限があり、
実行時には検索が一番負荷が高く、タイムアウトなどの制限が付きます。
たとえば数十MBのディスク容量があるとすれば、１ページあたり数kBとして、数千?１万ページ程度となります。
この程度であれば検索以外では問題が発生しないでしょう。
ただ、検索に関しては、すべてのページ内容へのアクセスとなるため、サーバの性能に大きく左右されます。
DBMライブラリやperlのtie、正規表現検索に関する詳しい知識を持っていません。
従って間違いがあるかもしれません。詳しい方、フォローをお願いします(^^;
ただし、YukiWikiDBを使用したWindowsのFAT環境では、データベースの容量が実際の十倍程度
必要となるかもしれません。また、その他多くの環境でWikiNameは一つあたり最大125byte迄となります。
36 ：
nobodyさん ：03/08/17 23:34 ID:Msid6wyL
>>34 具体的にどれがいいとかはわかんないけど、
ちゃんとcacheとかを考慮して設計されたWikiなら
数千、数万はいけると思う。
FSWikiの場合はなんでもモジュール(＝機能は後付け)がコンセプトなんで
cacheの実装が難しくなってて、
それで性能でないとゆー構造的な問題がありそう。
ほしゅ
すんごいページ数が多いのならストレージに DBMS を利用した
40 ：
お気に入り集 ☆http://beauty.h.fc2.com/ ：03/08/18 21:02 ID:ItghO+LV
FSWikiはとりあえず完全復活とみてよいのかな?
>>39 どうしてページ数が多いとDBMSがいいのかわからんのだけど。
検索用のインデックスを作るとかいう話?
うんまぁそんな感じ。
>>44 あ、0.0.3に上がってるや。
FSWikiの3.5.0も、週末くらいのリリースらしいね。
47 ：
nobodyさん ：03/08/20 22:26 ID:W6XZ+n9Z
問題なく認識されてるみたいだけどなぁ。
やったことないから判らない。
>>31 ,33の方法では上手くいかなかったの？
49 ：
無料動画直リン ：03/08/20 23:37 ID:CDzd/BGD
51 ：
47 ：03/08/21 22:13 ID:rLe4JkVs
>>50 なるほど、mod_rewriteを使えばいいのか。
でも2chみたいに REQUEST_URI をCGIに渡す方法が楽だと思うが。
mod_rewrite使えるウェブって少数だし。
>>51 そこまで理解してるなら引数解釈してる部分をさっくり書き換えればいいんじゃないかな・・・
pukiwikiのプラグインアンケートってどこにあるの？
61-25-150-227.home.ne.jpか……
((((((；ﾟДﾟ))))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
どこにIP晒してるよ？
pukiwiki.org のデザインてまだ変わらないの？
59 ：
nobodyさん ：03/08/22 21:06 ID:FlljWygK
54はreimyじゃないよ。
>>60 reimy以外なら誰なんだ？
pukiwiki.org にアクセスした香具師のIPが分かる香具師って何人いるんだ？
FSWiki 3.5.0 age
>>63 全く変更されてないファイルのタイムスタンプが変えられているのは、
勘弁してほしいと思った。
あぼーん
67 ：
nobodyさん ：03/08/25 00:23 ID:rrdaNH0f
>>64 まったくだ。
せっかくプラグイン化してるんだからプラグインごとのバージョンもってほしいなぁと思ってみたり。
CVS Idで管理すればいいのになぁ。
>>67-68 全部本家で言わないと反映されんぞ。
斜めに構えてるだけじゃどうしようもあるまい。
斜に構える
pukiwiki じゃないんだからまだ本家で話通しやすいんじゃないの？ :-)
「広辞苑」から「斜に構える」
>>69 は斜に構えるんじゃなくて、斜めに構えるんだな。
75 ：
nobodyさん ：03/08/26 10:26 ID:LnTVZunD
「射にかまえる」
76 ：
nobodyさん ：03/08/26 16:53 ID:wCfCy0wx
「射にかまえる」
FSWiki3.4.2>FSWiki3.5.0にUpdateしたらまた
>>79 ISPのサーバでZEUSとかってhttpdとPerl5.6が
動いてるみたいです。とりあえず3.4.0と3.4.2は動いてたんですが
今回3.5.0を入れたらPermission denied が出るようになってしまいますた。
(´･ω･`)
>>81 ライブラリやプラグインではなくwiki.cgiそのもので
Permission denied が出ている感じです。
エラーが出た段階で/config以下やwiki.cgi、その他引っかかりそうな
場所のPermissionは確認しているつもりなんですが、
どっか抜けてるのかなぁ。。。
ちなみにこんなのが表示されてます。
Server error
(/wiki.cgi) exec failed: 13: Permission denied
83 ：
nobodyさん ：03/08/28 12:26 ID:SzRaEKGK
ファイルやフォルダが増えてくると、設置し直したときにパーミッションの
なんか、FSWikiのサポート掲示板見てると、
>>85 自分が改造できないから一つ一つ頼み込んでるわけじゃなくて
柔軟に運用できるように設計の根本的変更を求めてるんじゃねえの？
>>85 「これまでCGIやPerlに触れたことがない人間はFSWikiを使うな」
ということでもなければ、おっかなびっくりFSWikiを設置した
Perl初心者が下らない質問をするのも避けられないと思います。
そうした作者の手を煩わせるまでもない初歩的質問に対してこそ
日頃FSWikiを使わせてもらってるお前たちが自分の出来る範囲で
協力して「サポート」していけばいいのだと思います。
猛省して下さい。
>>87 禿同。トップページに大きな赤い文字で
「これまでCGIやPerlに触れたことがない人間はFSWikiを使うな」
と書いてきました。これで作者さんを思うユーザの協力です。
いい仕事をした～
>>88 死ね
まぁ、思わず釣られた俺も俺だが・・・。
91 ：
nobodyさん ：03/08/31 01:51 ID:6GeG39LL
PukiWikiの次はFSWikiか...ここで取り上げられるとろくなことがないな。
別にWiki自体や作者が叩かれているという訳ではないからなぁ。
そろそろこのスレでWiki作れ。
>>94 いや。Hikiで良いじゃん。
Rubyが使えないサーバーを使っている奴が多いのかな?
２ｃｈ製のwikiなんか使ってたら何されるかわかりません（ｗ
確かに。ｗ
98 ：
nobodyさん ：03/09/04 08:47 ID:ZOs+h7P8
YukiWiki あげ
99 ：
nobodyさん ：03/09/07 18:33 ID:l73kgT1X
HikiFarmが何度やっても動かない。
100 ：
nobodyさん ：03/09/09 00:01 ID:fc0tlhxC
101 ：
nobodyさん ：03/09/09 01:19 ID:zgz4ZB3v
ＦＳって何の略？
102 ：
nobodyさん ：03/09/09 01:32 ID:Q+HexSr3
君がネットを使うのは難しい。
103 ：
_ ：03/09/09 01:39 ID:???
FreeStyleWikiでテキスト装飾の入れ子って出来ませんか?
104 ：
nobodyさん ：03/09/09 15:46 ID:FdedfYq4
■2ちゃんねる - Wikipedia
http://ja.wikipedia.org/wiki/%EF%BC%92%E3%81%A1%E3%82%83%E3%82%93%E3%81%AD%E3%82%8B 日本最大のインターネット電子掲示板サイト。
西村博之(ひろゆき)が主宰。
Table of contents [showhide]
1 概要
2 歴史
3 社会の反応
4 主な事件
5 関連項目
6 外部へのリンク
概要
「板」と呼ばれる各分野ごとの掲示板に、話題ごとの「スレッド」が存在している。
匿名での投稿が可能になっており、人々の本音と罵詈雑言、虚実入り混じった情報が渦巻くため「便所の落書き」などと揶揄されることもある。
不適切な内容に対して、常時複数の削除人というボランティア参加者の監視が行なわれている。
削除基準として公人私人によるプライバシーのガイドラインが存在し、削除依頼は公開され圧力に屈したあいまいな対処は行なわないという、言論の自由の保障に対してのポリシーが存在していることにも注目すべきである。
独特の用語「２ちゃんねる用語」や、文字を使って絵を表現するアスキーアートでの、モナー、ギコ猫などのキャラクターを使ってのコミュニケーションを好む傾向がある。
常連ユーザーを2ちゃんねらーと呼び、2ちゃんねる外でも２ちゃんねる用語などが通用すると思って使うような人も少なくない。
利用者は20代が中心だが、10代から60代まで利用しているとも言われ、裾野は広い。
政治思想関係の場所では保守的、かつ強硬な意見が多く見られる。
政策議論も活発で、税制から環境対策、社会政策から地方分権、国防論、果ては核武装まで議論している。
2ch全体の総意、政治思想と言う物は存在しないに等しい。
政治思想を明確に持つ人物とそうでない人物が混在して居り、まさに実際に参加出来るカオスの世界である。
歴史
主な事件
109 ：
nobodyさん ：03/09/10 22:17 ID:YfC0+ah+
age
2chでwikiの文法が使えるように検討中だってさ
111 ：
：03/09/11 00:24 ID:???
>>106 >掲示板群「あめぞう」の閉鎖をうけて、これを引き継ぐという趣旨の下に開設。
間違ってる。
>>114 ここで指摘するより、Wikipediaを直してきた方がよろしいかと…
「悪魔の辞典」という紋切り型ですな
蓮見という紋切り型ですな
おまえﾓﾅｰという紋切り型ですな
言葉とは、まともに自己表現するスキルを持たない連中が、
質問。
スタイルシート(theme)の text-indent。
1.4のリリースはいつ頃になるんですか？
124 ：
nobodyさん ：03/09/15 12:02 ID:HTXpwzcU
amazonプラグインに自分のアマゾンIDいれといてユーザー
さんに使ってもらおうってわけ？ 今のままじゃ、本読まな
い香具師ばっかり集まるよ（ｗ
>>124 さん
どうもWikiっていろいろ乱立してて、わかりにくいです。
とりあえず分かったのは、
言語によっていろいろなwikiが出てる。
perl, php, ruby, など
wikiによってはさまざまな機能が追加されてる。
tdiaryのテーマcssの流用ができるものがある
wikiを使えるwebサービスとしてwikifarmがある。
>>124 もそう。
類似のものに、はてな、関心空間、wikipedia、などがある。
C での実装きぼん。
128 ：
nobodyさん ：03/09/15 22:58 ID:dRH8xq9d
Ocamlで作ってほしいな。
130 ：
126 ：03/09/16 16:35 ID:???
>127
132 ：
126 ：03/09/17 09:01 ID:???
>>131 なるほど、wikiってそんなもんですか。
「wiki初心者の部屋」に、掲示板との比較を書いてみました。
なんかwikiを見てると、用語が日本語としてこなれてない印象があります。
たとえばページ上部に
[ 編集 | 凍結 | 差分 | 添付 ] [ トップ | 一覧 | 最終更新 | バックアップ | ヘルプ ]
と出てますが、かなりわかりにくいです。
[ 書き込む | 書込禁止 | 変更点 | ファイル添付 ]とかならいいの？
>132を例にすると
135 ：
126 ：03/09/18 09:29 ID:???
>>133 そうですね。やはり誰にでも通じる日本語のほうが望ましいと思います。
具体的には小学生やおばあさんでもわかるような。
>>134 何を指してるのわからないですね。たしかに。
どうやったら使いやすいか考えてみました。
[リロード] [ 編集 | 凍結 | 差分 | 添付 ] [ トップ | 一覧 | 最終更新 | バックアップ | ヘルプ ]
[リロード]→ブラウザに更新機能が付いているので不必要
[編集]→[書き込む]
[凍結]→これは管理機能なので、[管理]でいいと思う。
[差分]→[これまでの変更]
[添付]→[書き込む]時の画面に[ファイル添付]が出来るようにする
[トップ]→[トップページへ]
[一覧]、[最終更新]→サイトの情報はどこか別のページにまとめたほうがよい
[バックアップ]→これも[管理]でいいと思う。
[ヘルプ]→そのまま
これで、こんな表示になります。どうでしょうか？
[ 書き込む | これまでの変更 ] [トップページへ] [管理|ヘルプ]
136 ：
nobodyさん ：03/09/18 15:26 ID:cgIX3fCA
見るだけの人にとっては不必要なメニューが一番目立つところ（ページ上部）にあるのが
137 ：
nobodyさん ：03/09/18 16:24 ID:75/Mc5yp
閲覧している人みんなに参加してほしいなぁという思いが
管理者だけがコントロールするべき項目は分けるというのは
いや、
141 ：
nobodyさん ：03/09/18 23:45 ID:vFqGZyyF
>>126 なんでもかんでも「管理」に含めちゃうのは割と違和感あるけど、普通は違うのかな。
>>136 同意。
知り合いのWebデザイナやってる人に見せたら「これって管理ページ？」って反応された。
見たいだけの人にまで編集までできますというのは返って逆効果みたい。
なんとなく、クエリ文字列とかで管理系メニューとか編集系メニューとかの表示を
切り替えてしまう（認証などのアクションを通さずにという意味あい）ほうが
一般受けはするんだろうなという気がする。
なんでもできる、というアプリが結局使いにくいのに似てる。
えー？ 誰かといっしょにいじるから楽しいのにい。見てるだけの人
143 ：
nobodyさん ：03/09/19 02:00 ID:AE7DnXmi
wikiを主にCMSとして使いたいなあ、
と考えてるんで（邪道であるのは承知です）
見るだけの人の事をもっと考えた仕様、
というのは確かに欲しい気がします。
と言っても、自分以外編集禁止にしたいわけではないので
編集したい人にももっと敷居の低い表示は必要ですよね。
>>139 の案は大変良いと思いました。
144 ：
nobodyさん ：03/09/19 04:45 ID:6Cfr+X5L
メニューの話だけどカラーリングを工夫して押さえることもできるね。
↓のサイトはヘッダにとけ込んでページ本文とうまく分離できてると思う。
フッタの方はごっちゃりしてるけど。
ttp://debian.fam.cx/ wikiっていろんな使い方ができるけど、その使い方によって
インターフェースは違ってくるべきかと。
メニューの位置、用語にとどまらず、必要な人に必要なときだけメニューを見せるようにする
っていうような、そういう「インターフェース部」を独立させられたらおもしろいね。
スキンだけでできない部分もあるだろうし。
145 ：
126 ：03/09/19 09:25 ID:???
むーん、いろんな考え方があるんですね。
>>135 >[リロード] [ 編集 | 凍結 | 差分 | 添付 ] [ トップ | 一覧 | 最終更新 | バックアップ | ヘルプ ]
>
> [リロード]→ブラウザに更新機能が付いているので不必要
ファイルの添付などの post 処理のあとはブラウザのリロードではなく
Wiki のリロードのリンクを押した方がよいです。やってみれば分かると思う。
ただ普段はまったく必要ないので、必要なときにメニューではなく本文の方に
表示させるなど、根本的な工夫をした方がよいのは確かだと思う。
でもそうすると本体の方に手を入れざるを得ない。本気出してやるなら
ワークフローそのものを整理して作り直さないとダメだと思うよ、PukiWiki は。
ただ、見るだけの人を考慮するというだけであれば、更新作業には下のアイコンを
使うことにして、上のメニューはばっさりシンプルにしちゃえばいいんじゃないかな。
>>144 は参考になるね。この間見つけて感心してたとこ。
基本的に自分しか更新しないんで、ソースを書き換えて更新関係の
俺は逆。
なかよしゴッコはもうたくさんだ
やらないか？
152 ：
126 ：03/09/19 17:11 ID:???
>>147 リロードはたしかにそうですね。
再送信を要求されます。
アイコンもやはりわかりずらいかなぁ・・・
>>148 そういえばフッタも余分だと思います。いまのところではフッタに以下のメッセージが
ずらずらと出てきて。
Copyrightやバージョンの表記はFrontpageだけにするとか、backstageみたいな
ページを作って、表示させたほうがいいのではないでしょうか。
もちろんCopyrightは尊重しますが、すべてのページに出てくるのもどうかと思います。
Last-modified: Fri, 19 Sep 2003 13:36:42 JST (2h)
Link: MenuBar(2d)
Supported by WikiRoom.com
"PukiWiki" 1.4rc2 Copyright c 2001,2002,2003 PukiWiki Developers Team. License is GNU/GPL.
Based on "PukiWiki" 1.3 by sng
Powered by PHP 4.3.2
HTML convert time to 0.038 sec
Copyrightだったらこれだけ残せば問題無いんじゃない？
154 ：
126 ：03/09/19 17:59 ID:???
>>153 いや、Copyrightって全ページに表記しなきゃいけないものなのか？と思ったので。
というのは文庫本だと、裏表紙にCopyrightが書いてあって、すべてのページに
Copyrightが書いてあるわけじゃないですよね。
Wikiでも同様にbackstageページを作って、そこにCopyright表記をまとめられないかな
と思いました。
サーバサイドプログラムが吐き出すHTMLの末尾に
156 ：
126 ：03/09/19 21:52 ID:???
スクリプトの宣伝を兼ねているからね。 > Copyright
これって自分が既に持ってるページに貼り付けたりとか
159 ：
126 ：03/09/20 09:15 ID:7RoXQbfI
>>155 >>157 さんもおっしゃってますが、ソース内にかかれたほうがいいかと思います。
また文庫本のたとえで恐縮ですが、各ページに「印刷・天概社 製本・洞厳堂製本株式会社」と
印刷や製本の会社名が書いてあるようなものでしょうか。
>>158 掲示板の設置と同じと考えればよいかと思います。
フッタに表示されてる情報の改良案
最終更新時刻、リンク元、HTML所要時間→ページのメタ情報は見たい人だけ見れるようにする。
wikiのcopyright、phpのバージョン→できればbackstageとしてまとめる。もし表示するなら簡素に。
提供元→これはしょうがない。感謝感謝。
むーん・・・
たとえばPukiWikiのCopyrightを見ると
161 ：
nobodyさん ：03/09/20 12:13 ID:fLun8QF0
ちなみに藻前等、コピーライト表記は
162 ：
161 ：03/09/20 12:14 ID:fLun8QF0
© ＝ ＆ｃｏｐｙ；（半角）
>>156 s/ASWiki/AsWiki/
RubyはTikiからの派生になっているが微妙。
HikiはあんまりTikiに影響受けてない。
PukiWikiのあの表示って、Copyrightという言葉とGNU/GPLという言葉が一行に並んでるのが
きみにとって新鮮な概念だったんだねー＞copyleft
>>166 なんで？
まぁ GPL をオープンソースライセンスの一つ、くらいにしか認識してないならそんなもんかもね。
気になるやつは変えればいいんじゃない？ GPL に従ってるなら利用に制限を加えることは
できないはずだし、あそこの表示も変えたいように変えて問題ないと思うよ。そりゃ自分が作った
ように見せるのはまずいけどさ。何使ってるかなんて聞かれたら答えればいいだけのこと。
そんなに盛り上がるネタじゃないと思うぞ。
CGI がブームになったときにパクリだなんだで著作権表示が流行っただけでしょ。
169 ：
126 ：03/09/21 09:06 ID:???
>>164 国産wiki一覧図、訂正しました。
ご指摘、ありがとうございます。
>>165 GPLは著作権にもとづくライセンスですが…。
まあ、落ち着いていきましょう。
174 ：
170 ：03/09/21 17:12 ID:???
>>172 2と4か?
>>168 >
>>166 > なんで？
> まぁ GPL をオープンソースライセンスの一つ、くらいにしか認識してないならそんなもんかもね。
GPLの理念を理解すると
>>165 という認識になるのかね?
ああ，理念の理解どころかGPLを読んでもいないようだが。
> 気になるやつは変えればいいんじゃない？ GPL に従ってるなら利用に制限を加えることは
> できないはずだし、あそこの表示も変えたいように変えて問題ないと思うよ。そりゃ自分が作った
> ように見せるのはまずいけどさ。何使ってるかなんて聞かれたら答えればいいだけのこと。
>
> そんなに盛り上がるネタじゃないと思うぞ。
>
> CGI がブームになったときにパクリだなんだで著作権表示が流行っただけでしょ。
ここらあたりを読めば，GPLを読んだこともないのは明白。
backstageって何？
舞台裏だよん。
copyrightと裏舞台に何の関係があるの？
ttp://www.gnu.org/copyleft/copyleft.ja.html そこで、GNU ソフトウェアをパブリックドメインに置く代わりに、私たちはそ
れに著作権(コピーライト)ならぬ「コピーレフト(copyleft)」を主張すること
にしました。コピーレフトでは、そのソフトウェアを再配布する人は変更の有
無を問わず、配布される人にもそれをコピーし変更を加える自由を与えなけれ
ばならないということを主張します。コピーレフトによって、すべてのユーザ
が自由を持つことが保証されるのです。
180 ：
nobodyさん ：03/09/22 23:18 ID:wUZQv6Dt
>>180 そりゃ提供形態によって消していいか悪いかは変わるだろ。
さらされたのか？そりゃご愁傷様。
確かGPLのCMSでCopyright表示を消してｲｲ／ｲｸﾅｲって論争が無かったっけ？
183 ：
nobodyさん ：03/09/22 23:50 ID:KM57QpHX
難しいことはよくわからないが日本語で
>183
185 ：
126 ：03/09/24 13:37 ID:???
わたしの考えは
>>178 さんのいう通りです。
> PHPのバージョンとか、スクリプトのcopyrightとかは、
> 本の後付とか、映画のスタッフロールみたいに
> 本編とは別のところ(=>backstage)においておきたいね。
> っていう主張だと思うよん。
私もcopyrightやGPLの概念や現在の運用状況に精通してるわけではありませんが・・・
186 ：
126 ：03/09/24 13:39 ID:aSJCoCWT
wikiの読み方教えて下さい
ウヰキ。
190 ：
nobodyさん ：03/09/25 01:03 ID:x/Cq+ATo
>>186 =126
なんとなく、サイト公開のあともスパイラルにデザインだのテンプレだの改造だのは繰り返される気がする。
2chのスレのテンプレって、
>>191 Wikiじゃないけど、そういう風にしてるスレはたくさんある。
いや、もちろん「まとめページ」みたいなのを作ってるスレはたくさんあるけど、
194 ：
126 ：03/09/25 08:30 ID:BxwE0WlU
>>190 どうもです。
一度出来たら、デザインもテンプレもそうそういじらないから、
矢印を加えるものどうなんだろと思って、はずしてました。
いちおう、誰がどこまで編集出来るかは、背景色を分けて表示してあります。
>>193 まとめページのなかでも、解説、FAQ、リンク集、などはメニューバーに表示するんで
wikifarmで並列運用したほうがいいかも。名前空間も衝突しないように。
あと、2chでwikiも趣味系の平和なやつならいいけど、朝鮮ネタとかは荒れそう。
まぁ、需要はあると思うので、スキルがある人は2chテンプレ用wikiにトライしてみたら
いかがでしょうか？
195 ：
126 ：03/09/25 08:32 ID:???
>>189 ウヰキ=uwikiでは？旧字体で表現したいなら、ヰキでは？
普通に読むならウィキ。
こんな意見もあるんで、参考までに。
940 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：03/08/24 16:42
旧字体の人が最近増えてるような気がするんだけど
丸谷才一とかが書く旧字体は読みやすいって言うか自然な感じで読めるのに
ネットで見かける旧字体って何か読みにくいのな。
941 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：03/08/24 17:49
語尾でキャラつけてるのと同レベルだと思う
そっちの方が馬鹿なのを分かってるだけまし
http://pc2.2ch.net/test/read.cgi/esite/1045347004/
196 ：
126 ：03/09/25 16:32 ID:BxwE0WlU
197 ：
nobodyさん ：03/09/25 18:33 ID:0KM/S2Rt
Wikiroom、イイね。
198 ：
nobodyさん ：03/09/25 19:12 ID:Cmclh6F4
何かあったときに罵る相手がいるというのは良いものです。
>>196 きーーー、なんで私のWebSiteが登録されないのーーー？
むかつくーーっっ
>>199 麗美に論破されて根に持ってる人、こんばんは。
麗美ってpukiwikiでSafariを排除した人?
またはじまった。もうやめれ
れいみぃってまだいたの？
sourceforgeってよくメンテナンスで落ちているし、phpの処理速度遅くて
205 ：
nobodyさん ：03/09/26 16:58 ID:bf3rratk
結局今って、正直どのWikiが一番イイ訳よ？
>>205 PukiWikiﾕｰｻﾞの漏れも知りたい（ｗ
>205
208 ：
nobodyさん ：03/09/26 20:27 ID:299XtGRn
>207
やってもうた。小人さんの修正希望。
pukiwikiの整形ルールの目次の項目で
で、C での実装まだー？
212 ：
nobodyさん ：03/09/27 18:12 ID:hwUsVKjL
HTML吐いてくれる うゐきってどっか無いッスか？
>>212 VikiWikiとか？
検索キーワードは Static とか 静的 とかかな。
>>212 既存の Wiki から fopen(path, "w") にあたる部分を検索、
保存処理の後に自分自身にGETを送って保存するように改造。
215 ：
nobodyさん ：03/09/27 23:54 ID:Rt1Laxuq
>>212 FSWikiのToolでもできるんじゃない？
その都度作ってくれるわけじゃないけど。
216 ：
nobodyさん ：03/09/28 06:49 ID:pHYua0rN
PukiWiki1.3のtempleteってこれどうやって使うの？
217 ：
216 ：03/09/28 06:50 ID:???
間違った
218 ：
218 ：03/09/28 09:43 ID:???
★Wiktionary(excite翻訳)
http://www.excite.co.jp/world/url/body?wb_url=http%3A%2F%2Fwiktionary.org%2Fwiki%2FMain_Page&wb_lp=ENJA&wb_dis=2 英語
http://wiktionary.org/ 歓迎 に Wiktionary 自由な多言語の辞書を生産する協力的なプロジェクトおよびすべての言??a言語辞典は、意味、語源および発音で完成します。
Wiktionaryは開いた内容百科事典への語いの相手です。 Wikipedia .私たちは出発し続けました。
12月 12、2002年、またもっと終始加えられ改善されることと共に、英語のバージョンでの8337のエントリーに既に作用しています。
あなたを含む誰でもさえログインする必要なしに、今ちょうどどんな定義も編集することができます。
見る、その Wiktionary FAQ プロジェクトに関するより多くの背景的事項のために、そしてその、Wiktionaryを使用し寄与する方法についての情報のためのページを支援します。
Wiktionaryの内容はカバーされます、その GNU自由なドキュメンテーション・ライセンス どの手段、それは自由で、そのように永久に残るでしょう。
見てください。 Wiktionary:著作権 詳細には。
これがそうであることに注意してください、その 英語 Wiktionary:それがすべての言語の言葉についてすべて記述することを目標としている一方、定義および記述は英語だけであります。
他の言語の同様のWiktionariesは徐々にセット・アップされるでしょう。
英語でない単語を定義する英語のWiktionaryの中の記事の例のために、参照してください、に frei .その単語のドイツの定義を見つけるために、
それが利用可能になる場合、ドイツのWiktionaryに頼ることは必要でしょう。
>218
220 ：
126 ：03/09/29 14:11 ID:yjgy4sRw
>>205 うーん、どうなんでしょうかね。
>>207 さんも言ってるとおりwikiは乱立しっぱなしなのかも
しれません。掲示板のスクリプトがいろいろと乱立してるように。
レンタル鯖にwikiをおきたい人は
・perl、php、rubyなど、鯖でどの言語が使えるか調べる。
・出来れば自分の知ってる言語のを使うのがよい。
あとは配布サイトを見て、自分の使いたい機能が付いてるのを選ぶのがいいのかな～？
221 ：
FreeStyle遊座 ：03/09/29 22:31 ID:VnLpPOe9
最近Pukiってどうなの？
Cで書くか。
>220
Cとかだと、プラグインで機能追加できるようにするのが大変そうだ
一歩進めて、専用ブラウザを作る。と言うのはどうよ？
オープンミッションクリティカルなwikiはありませんか？
「だめなの」ｷﾀ━━━━━━(ﾟ ∀ ﾟ)━━━━━━ !!
blogのTrackBack見てて思ったんですが、自分のwikiから相手のwikiへ
231 ：
230 ：03/09/30 22:01 ID:???
自分は平気で人んところでも書きますけどねｗ
平気でわりこんでくるおばさんが多くて困ってる（ｗ
ライトノベルの書評にハイテンションな雄叫びを入れる腐女子がいて困っている（ｗ
>>228 オープンミッションクリティカルって何ですか？
>>236 を読む限りでは、オープンミッションクリティカルと処理の重さは密接な関係はなさそうだが
>>238 少なくとも最近はwikiより一般的だ……オレの世間が狭すぎかもしれんが。
>>225 専用プラウザには、インクリメンタルサーチがほしい。
っていうか、ほんとに作っている人はいないの？
pukiwiki を C で書いてくれる人きぼんぬ。
最近C全く使ってないなぁ
ただでさえ、Cなんかで書くのはめんどくさいのに
>>244 君がネタにマジレスしているということですかね？
ただの利用者でプログラミングのことなんて知らないけど、
Cで書かれたとしてただの利用者がコンパイルできるのか？
>>249 できません。もちろんwindowsみたいにコンパイル済みのフリーソフト
として公開してくれるんでしょ？
バカかお前は・・・
「pukiwiki の利用者は、C で書かれたプログラムをコンパイルできない」
釣られてやるか。
>>248 みたいなただの利用者はきっとわかってると思うよｗ
>>241 Wikiで専用ブラウザって必要なのかな？
汎用のWebブラウザならともかく、専用となると使用するWikiの種別は
限定されちゃうよね。Wikiテキストの文法が違うわけだし。
まぁでもその部分をカスタマイズ可能にしておけば、それはそれで使えるかも。
Wikiテキストがわからん人は、領域選択してツールバーのボタンをクリックすると
変更可能で、結果は即反映、って感じを期待してるのか？
256 ：
252 ：03/10/05 22:27 ID:???
>>253 説明乙。
釣られたついでに、Perl とか Ruby とか PHP とかを利用した場合と、
コンパイル済バイナリを利用した場合の、鯖の負荷についても論じてみれば?
257 ：
241 ：03/10/05 22:50 ID:???
>>255 すまない。
>>225 の気持ちはわからない。
個人的には、Web上の機能の置き換えではなくて
Wikiと同じデータを使いつつ、
辞書ソフトのように高速なインクリメンタルサーチができるものや、
クリップボードを監視して、内容を随時貼り付けていくもののような、
よりユーザーに密着したものを作りたい。...んだけどなぁ。
Wikiで培った情報を生かせる手段はいろいろあると思う。
>>253 ご苦労さま。
258 ：
255 ：03/10/06 00:19 ID:???
>>257 ローカルのWikiデータベースを直接操作する専用アプリってことかな。
インクリメンタルサーチとか、ネットワーク経由では厳しいし、
ローカルもしくはLAN運用で自前の情報データベース用として
Wiki使っている人向けになりそうだけど、そういうことかな？
スマン、ちょっと短絡的すぎた。
クリップボード監視で自動貼り付けってのは面白いかも。
単独で常駐アプリとしてならちゃっちゃと作れそうだな。
>>257 どこかで「PalmWikiのデータとシンクロできる」ってのを見た覚えが……。
>>258 そんなところです。
必要に応じて、内部キャッシュをもって他のWikiの情報を保持してもよいと思う。
emacsにwikiモード欲しい。
emacs-wikiは普通にあるわけだが。
>>259 ただのviewerとしての機能だと将来的には通信速度の上昇によって
無意味になってしまうかも。
でも、最近話題のデバイスに応じた特殊な情報（GPSとか)を自動入力できる機能は面白いですね。
携帯電話に組み込んで、誰と話しているときに取ったメモか残るとかいいかなと思ったり。
個人では作れませんけど。
264 ：
nobodyさん ：03/10/08 13:26 ID:Ac4OXa+F
PUKIWIKIの検索って全ファイル見てるみたいだけど何ファイルくらいいけるの？検索時間
だいたいページ数に比例するんじゃない？
で、pukiwiki の C での再実装まだ～？
>>267 連休明けにリリースする予定。しばし待たれよ。
269 ：
126 ：03/10/12 16:09 ID:QNlcdHg4
270 ：
nobodyさん ：03/10/12 21:00 ID:P0gcdO8H
>>267 まずは Perlで書かれた Cのコンパイラが必要なんだよ。
そじゃないと、一般ユーザはサバでコンパイルできない。
サーバー上でgccでも使えばいいと思うが。
>>270 >>268 が作っているんだから、そっとしとき。
でも、環境くらいは提示してあげないと、作ってもらっても
動かせないってなりかねないね。
>>267 は。
バイナリ配布すりゃいいじゃん。
まあ、製作者ががんばってくれるなら、それで結構ですね。
SolarisといってもCPUのアーキテクチャによって変わるんだが。
へい、 sparc でやんす。
277 ：
274 ：03/10/12 23:33 ID:???
あ、俺は特に必要としていないんで本当に対応しなくていいですよ。
hiki-mode.elってのがあるんだね
279 ：
nobodyさん ：03/10/13 19:11 ID:TV7M2AvY
FSWiki3.5.1 age
さっきバージョンアップした。
>>279 バージョンアップでトラブル今のところ無し。
うちは3.5.0からずっと開発版追っかけて使ってるからかな。
ただ、3.4系から3.5系は以前なんか問題なかったっけ？
リネームプラグインとかは便利だな。
まぁ後から変えたい名前のページ作って移し替えればいいって話もあるんだろうが、
添付ファイルとかついたページだとﾏﾝﾄﾞｸｾ('A`)し。
ありきたりな答えだが、追加機能とかバグ修正に意義を感じたら
バージョンアップすれ。安定していて特に困らないならそのまま。
中身は全く変更されてないファイルまで
つーか、また繰り返しになっちゃうけど。
本気で CVS にしてほしいならここで優しく CVS 指南するというのはどうだろうか？
285 ：
284 ：03/10/14 15:04 ID:???
PukiWiki は前から CVS 使ってたけど、1.4 の追っかけがしんどくなってきたんで
>新・たけぞう瀕死の日記
>ここで反応するのもアホらしいけど、リリースするたびに同じことを書かれるのも
>気分が悪いので反応しておきます。
>3.5.0からSourceForgeのCVSを使っています。ソースは更新した分だけをスクリプトで抽出して
>持ち運んでいます。なので稀にコミット漏れが発生します。何度も書くようですが、
>日中はHTTPとHTTPSしか外に出れません。自宅でstoneとかありましたが、そんな資金はありません。
>あと、タイムスタンプが更新されているのはリリース用のスクリプトでソースを若干加工しているためです。
>リリースされたソースは前のバージョンと変わっていないように見えるかもしれませんが、
>CVSに入っているものとは違います。まあ、これは改善の余地ありかもしれませんが、タイムスタンプ見て
>更新されていたものだけアップデートではうまくいかないこともあるので、
>素直に入れ換えてください、ということで。
はて、stoneでどうして資金が必要なんだろうか。
SSL証明書の資金ということか?
自己証明書ならゼロ円だけど。
前にこの話題が出たとき、日記のコメント欄に
http://wiki.spc.gr.jp/tunnel/?FrontPage http://wiki.spc.gr.jp/tunnel/?DigByStone の解説ページが張ってあったけど。
結局、読んでいなかったということか。ヤレヤレ。
常時接続する踏台鯖なり金すらない貧乏人ってことじゃないの？
叩くなよ・・・
いや、叩いているのは、事実でもないことをいいわけしているからだよ。
何に時間と金を費やすかは個人の自由と思うけど。
>>290 >diff すらまともに使えないのに、なにを偉そうなことをいっているのかと。
これ、どっちに言っているのか?
あと、開発者がちゃんとリリースエンジニアリングすれば、苦労は(n x 1)で済むが、
ユーザーがいちいちdiffを取ると、苦労は(n x ユーザー数)になる気もするが。
>>287 っていうかstoneを使ってHTTPS越しにsourceforge.jpにcvs+sshしろって事だと思うよ。
別に自宅に常時サーバーか無くたっていい。
もちろん別にCVSROOTを持っていたほうが気楽だというのはあるけど。
>>293 sourceforge.jp の shell 鯖は鯖プロセスだめだったはずなので、
stone を使って cvs over ssh over https するには、
必ず中継地点が必要だよね?
> 常時接続する踏台鯖なり金すらない貧乏人ってことじゃないの？
なんだ。タグ打っているならsourceforge.jpからcvs updateでバージョンアップできるじゃん。
（･∀･）ﾆﾔﾆﾔ
オマエがstone/cvs用常時接続鯖用意して提供しろ
すくなくとも、CVSでほしがっている奴のうちの一人が
リリースエンジニアと開発者が同一人物じゃなくてもいいわけだし。
YukiWiki改造系の方々の涙ぐましい努力に比べれば
>>300 みっともないからやめなよ
自分の意見にさからう奴を開発者と決め付けるのも、言い逃げするのも
だいたい作者にもの申すっていうなら、公式サイトに行って直接やり合えばいいじゃん。
IE6使ってるんですがいつからか忘れましたが、
>>304 「Wikiっての」といわれても種類があるし、カスタマイズして使っている人も多いので
具体的にサイトを示してもらわないと何とも。
てゆーか、おかしいのは Wiki だけ?
306 ：
284 ：03/10/16 13:16 ID:???
>>303 だなぁ。
というか、誰かにこれまでと違うことをしてもらうと説得することがどれだけ
大変かってのが分かってないのかな。
開発しかしてなくて人間の相手してないとか？ 学生とか？
そんな邪推しちゃうね。
あんまいい態度じゃないように見えるのは確かだよ。
「終わりー」っていってるのにグダグダ続けるのは粘着
308 ：
304 ：03/10/16 17:56 ID:???
>>305 過去ログとかぐぐったりしてみたところ、
同じWikiを使っているところ(と、思われるサイト)でも見れるとこと見れないところがありました。
ヤフーで検索できる所では
www.wikiroom.com/
www.wikiroom.com/wikinovice/
この辺りは見れません。
文字化け具合ですが、半角英字はきちんと表示され、全角が「□」に化けてしまっているようです。
ですが下のサイトの
＞Wikiはルーズリーフに鉛筆書き
＞ ・ページを付け足せる
＞ ・他の人が書いたのを消せる
のようにテーブルの中の文字はなぜか化けずに表示されます。
おかしいのは恐らくWikiを使っている所だけだと思います。
例えば自分のサイトを含め、htmlを作っている所や2chのような掲示板はきちんと見れています。
>>307 そうすっと 2ch のたいがいのスレは粘着スレだな
あほくさ
>>308 ちゃんとシフトJISを使っているWikiを選びましょう。
311 ：
310 ：03/10/16 20:47 ID:???
お答えありがとうございます、がシフトJISを使うというのはどういうことでしょうか？
本体が EUC で、スタイルシートに意味も無く Shift-JIS を指定しているから？
う、一応が重なっている...頭悪そうな文章だ。
IEのバグで、スタイルシートのフォント指定が悪いと日本語が化けてしまう。
wikiroom広告でかくなった。
316 ：
nobodyさん ：03/10/16 22:55 ID:4pmlU2Gf
いかん、最近違ったWikiの楽しみ方をしてしまう。
317 ：
FSWiki遊座 ：03/10/21 21:15 ID:WjL7Ggsu
3.5.1にすげ替えようかなぁと思ってたんだけど、サポート掲示板見ると
C言語版Wikiどうなったの？
320 ：
126 ：03/10/22 20:22 ID:rCXNXcK0
Wiki ＝ 大学の～と
Wikiってなんて読むの？
324 ：
３２２ ：03/10/23 12:53 ID:???
>>323 「うぃき」でいいみたいですね(^^)
ありがとうございますm(_ _)m
いいからさオマイラ
>>325 灯台もと暗しの青い鳥
実は身近なところ…そう、きみの頭の中にあるのだ
だからチョー カッケー スキンを自分で作りなせい
>>326 美術1とった人間に言いなさんな・・・・
チョーカッケェーの ほしいよーーー
しかし、正直なところ、Wikiやらblogやらxoopsを便利だからって使ってる人増えてきたよね
そうだね、css配布サイトは需要あるかも
2ちゃんねるパワーの結集して、css配布サイトつくってください。
332 ：
nobodyさん ：03/10/24 18:40 ID:jnaWJk1v
333 ：
nobodyさん ：03/10/24 19:24 ID:gg9i5PMK
そのスキンは、どこからパクって来ましたか？
>332
操作だからwikiの編集について書いてんじゃない?
>>332 ファイル添付ほどには一般的ではないかもしれないけど、
Wikiによってはページ削除やページタイトル変更機能を持つものが
あるんじゃないかな。
でもそんなの載せるとかえって混乱するから、あくまで基本だけを押さえるつもりなら
だいたいこれで充分かと。
>>335 wikiの操作という書き方では、閲覧が抜けていると思うのも無理ないと思うよ。
wikiの編集操作とでも書けばいいのかな？
337 ：
126 ：03/10/25 15:30 ID:???
ご意見ありがとうございます。
338 ：
126 ：03/10/25 15:41 ID:???
他人が作ったページも触れるという意味で、元の ccc を別人が作ったという
341 ：
nobodyさん ：03/10/25 19:18 ID:MLAWrLZG
Hikiって、もしかして開発止まってる？
>>339 編集のとこちょっと矢印を変えてみました。
こんなかんじでどうでしょう。
>>342 cccとかccxの文字がページ名のことなら、ページ名変更ってことになって、
ページの書き換えとは意味が違うぞ。
やっぱり同じページに対して双方向の矢印を書かないと、書き換えってことには
ならないんじゃないか？
書き換え（ページに事実上所有権が無くて、好きな箇所を好きなように
書き換えられるというWikiならではの概念の説明になるよね、多分）の話は、
別の図とか説明に分けた方が良いと思われ。
お勧めのWiki系教えてくれ
>>344 全部試して自分の用途に合うモノをつかってくれ。
いや、煽りじゃなくて。
お前さんの必要とする機能が判らない以上そうとしか答えられんだろう？ 違うか？
とりあえず
>>1 からたどれるところのWikiでヘルプ見ながら
SandBox(or 練習場など)で試してみれ。
347 ：
126 ：03/10/26 22:30 ID:???
>>343 いちお、ページ内容を表したつもりだったんですが、たしかにタイトルと
まぎらわしいですね。
この図はこれにして、書き換えの概念図をもうひとつ作ろうと思います。
348 ：
126 ：03/10/26 22:35 ID:???
>>344 >>207 さんの意見が参考になるかと思います。
「おすすめの掲示板を教えてくれ」っていう質問に近いかと。
このスレでは Pukiwiki が人気あるみたいです。
よく知らないんだけど,
wikipediaって、日本語url(で、いいのかな?)が使えますよね。
http://ja.wikipedia.org/wiki/日本語 みたいなやつ。
wikiって日本語だと
1.ページ名が長くなる
2.urlとページ名の関連がわかりづらい
けど、この日本語urlを使えばかなりイイんじゃないか。
で、今使ってるWalWikiを改造して対応させてみようかと思うけど、
結構難しいものですか?プログラムさっぱりなんだけど、頑張れば何とかなりますか?
352 ：
351 ：03/10/27 18:54 ID:???
353 ：
351 ：03/10/27 19:00 ID:???
ああ、スレ汚しだ…。
そんなに卑屈にならなくても...
英語だとwikiのpageがそのままわかるけど、日本語だと
URLをそのまま辞書的に使うなら意味があるかもしれないね。
今YukiWikiを試験運用してるんですが、画像とファイルの添付ができません。
358 ：
ム○カ ：03/10/28 17:15 ID:???
そこまで広まっていないんじゃないかな。
スパムのロボットはロボットよけ効かないんじゃないか？
スパムのロボットはロボットよけ効かないんじゃないか？
ダミーの認証かけとけばいいんじゃないの？
賢いスパムなら、Googleの上位に出てくるサイトを狙って
携帯から書いたら二重投稿になってるよｽﾏｿ...
>>363 スパムのロボットに編集ページ（というか入力フォーム）を見せない（入れない）か、
あるいは投稿してきた内容をはじくという方法でしか防御策はないもんですかね。
最近のスパムメール対策でよく使われるベイズフィルタを投稿時のフィルタに
使うようになったらどうなんだろ。
誤検出を起こしたり「検閲だー！」と騒がれるだけかな。
Wikiは今もマイナーな地位で安定しているから、スパマーとしては
フィルターは有効でしょうね。
367 ：
nobodyさん ：03/10/31 08:20 ID:L5mKWy+T
>>341 別に止まってないよ。開発者がちょっと忙しいだけ。
自分の編集をcommitする前に誰かが変更を加えてたらdiff表示して修正を促すやつありますよね
hidden でなにか識別子を送るのが普通ですけどね。
372 ：
nobodyさん ：03/11/03 19:06 ID:3fDmIbYO
age
373 ：
370 ：03/11/04 16:55 ID:???
MD5ハッシュをhiddenで送ってるようです
社内でwiki導入しようと目論んでいます。
僕の拙い文章でも、表示される内容が変わりますか？
>>374 表示される内容を変えるってどういうこと？
>>376 投稿者別に表示したり、カテゴリー別に表示したりしたいんです。
>>377 その投稿者別やカテゴリー別に表示したいものはなに？
ページ？ パラグラフ？
投稿者やカテゴリーというとウェブロのツールのほうが近いのではないだろうか。
>378
スマンが簡単でいいんで例を示して欲しいな。
382 ：
nobodyさん ：03/11/09 22:58 ID:C9pR4RJr
全削除や微妙な偽情報書き換えのような荒らしへの対策はどうなってるんでしょうか？
>>382 特に具体的な対策はないから、ログからの復旧がメインになるでしょうね。
バージョン管理機能と連動できるタイプのWikiだと、いじられる前の状態に戻すのは
楽でしょう。PukiWikiならできるんじゃなかったっけ？
もともとWikiはそういうの全然考えないシステムですからね。
あとは、同じWiki使っている人が相互に修復し合う（掲示板のログ復旧にみんなで
ログ持ち寄って直すみたいなもの）なんてのもあるようですが。
それ以前に、そういうコトするようなアフォはWikiに書くことさえ出来なかったり
Wikiコミュニティにそんな奴はあまりいなかったり…らしいです、今んとこ。
スクリプトで全削除しようと思えばできますな
>>384 やろうと思えば…ね。
更新の衝突チェックをかいくぐるためには、編集画面のフォームをパースしなけりゃならない。
Wikiエンジンごとに埋め込まれている値も名前も違う。
そこまでの手間をかける暇人は、まあいるかも知れんなｗ。
悪さをする時のヒントまで書いてくれる君達ってステキ。
387 ：
385 ：03/11/11 21:09 ID:???
編集画面への遷移がリンクじゃなくボタンになっていれば、手数は倍になる。
>>387 いずれにせよ、WikiでSPAMは今のところ手間をかけるほどの価値はないと
SPAM業者に思われてるから、そういう意味で救われてるんだろうね。
どっかの暇人がスクリプト書いて配ったら
なんにでも言えることだが、広まってくると、厨が寄ってくる。
「崇高なWikiの思想」って何だろう？
One for All All for One.
崇高とかいってんじゃねーよ。アホか。
コンピュータなんてもんは、弾道計算という崇高な目的のために
どんなユーザーグループがつくかで将来が決まるからな。
わかんなーい。
「産めよ増やせよ地に満ちよ」
399 ：
nobodyさん ：03/11/15 17:51 ID:3ulv6R5u
WikiName なんてものは、WazaWaza 意識して使わないといけないわけだから、
>>399 悩むおまいさんはWikiなんか使わなくていい。以上。
401 ：
399 ：03/11/15 18:18 ID:???
>>400 私は、悩む必要がないと思っていますが。
文章を正しく解釈していらっしゃいますか？
追記ばかりで推敲しないやつが多くて辟易しとる今日この頃。
>>401 400は398にレスするつもりだったのではあるまいか
なんだなんだ、どうなってるんだ。
いいじゃん簡易HPエディタで。実際そういう運用しているところ少なくないし。
HTML直書きするよりは楽だってんで、業務とかで運用されているケースもあるっていうしさ。
自分でも、なんだかテキストだけ書きたいのにレイアウトやら装飾やら考えて
ページ作るのがﾏﾝﾄﾞｸｾ('A`)ってんで、Wiki使ってるよ。
タグ使えないから装飾が…とかレイアウトが自由にならないと、とかいう人は、
ちまたのWeb作成ツール使えばいいわけで。そういう使い方はWiki向きじゃないだけ。
HTMLタグ使えるWikiもあるから、それを使って頑張ってもいいけど。
もちろん、WikiNameが持つ、閲覧者をページコンテンツ作成への誘導するってのも
それなりに意味はあるのもわかるけど、それだけのためにWikiがあるわけじゃないわな。
…ってゆーかさ、
>>390 の崇高って言葉が一人歩きしてるような気がする。
誰でも自由に書けてコンテンツの質を高めていけるコラボレーションツールとしての側面の
ことを言っただけなんだろうが、少し言葉が過ぎてるっていうか、大げさというか。
本当に崇高なものに出会ったことがないんだろ。
>>405 「本当に崇高なもの」の具体例きぼん。
釣りもいい加減に汁。
本当に崇高なものって何よ？神様か？
熱いな
神様か wiki 開発しかないんですか？
じゃあ、あれだ。KAKASIとかの日本語区切りツールと連携して、
411 ：
410 ：03/11/16 14:02 ID:???
>>398 > がんがんページを増やしていくウチに思わぬつながりを見いだすことで新しい発想を生む
僕は個人的には、勝手につながるという偶然はあまり信じていません。
Wikiの肝は検索機能にあるとWiki Wayにも書いてあるし。
ノンジャンルになんでもひとつのWikiに突っ込む実験期はもう過ぎ去ったわけ
で、Farm機能を使って特定用途のWikiを複数立ち上げるというのが今のやりか
たでしょう。
ところで、ページ内にスクリプトを書いて実行するっていう方向性についてはどうよ？
>>410 WikiNameの自動抽出も、個人的には度を超すと"?"がウザくなるで、考えどころです。
最近はもっぱらWikiName機能を眠らせて、[]でキーワードにする機能のみで使ってるし。
まぁ、だからこそ、キーワードにするかどうかを選別する機能は必要ってコトですか。
>>412 ノンジャンルで行くのは初期のWikiの実験的な運用時代の話でしょうね。
それで行くのももちろんアリだけど、やっぱり何か書くなら方向性がないと書きづらいっす。
雑談なら掲示板に特化しているシステムの方がやりやすいかな。
>>413 今のところ個人的には必要性を感じてないですけど、
パターン化する部分が多くなるようなら必要かなぁ？
>>417 wikipedia の発想はいいんだけどさ。サーバーまわりは日本人の管理者が
いじれないんだろ？結局、ぜんぶアメリカ様にお伺い立ててるだけ。
対応もすげー遅いし、小回りが利かない。
しかも、その日本人で運営してるやつらがあまりにイケテナイ。
読売の記事見ればわかるけど。この顔じゃダメだろ。
419 ：
nobodyさん ：03/11/21 22:11 ID:yvCKkE5i
顔かよ
顔だろ。
当サイトを「掲示板」と勘違いし、仲間内の連絡用に使う不埒な輩が出没しておりますが、
>>420 顔か…。
すげーな、最近では顔がWebの雰囲気に反映されるんだな。
わっ、びっくり（棒読み）
FreeStyleWikiの開発版wiki3_5_2dev3.zipの存在を確認
>>421 相変わらず暴れてますな。どうしてそう燃料投下がうまいんだろね。
Pukiwiki本家だろ。もう元に戻ってるよ。
wiki系で作ったデータのバックアップって、どうしています?
431 ：
nobodyさん ：03/12/02 21:18 ID:kcqp3//r
>>429 sshごしに mysqldump > ~/bkup/20031202.sql
ああっぶたないで
いっそEmacsWikiを…
入力するソースの見易さを意識したようなwikiって無いですかね。
>>431 ファイル名の長さ制限の問題。
パソコンのOSで、ファイル名の長さが31バイトだとしたら、31バイト以上のデータ名の場合、FTPでダウンロードすると、先にダウンロードした31バイトまでの同じファイルへ上書きされてしまうのです
>>434 つうか、Wikiってもともとそういうもんじゃねえのか？
'見にくい'拡張があれこれされてるヤツラが邪道なだけ。
まあ、特殊文字にASCII文字しか使わないせいで、
日本語圏の文化とはマッチしてない、ってのはあるかもしれんな。
ある種のFTPサーバには、 'ディレクトリ名'.tar.gz をRETRするとディレクトリ以下をtarballにした
438 ：
nobodyさん ：03/12/03 23:08 ID:9KPHdWnj
>>434 Hiki/plain2でも調べて見れ
・・・ってサイトがなくなってる？
>>437 それ便利だな
>>437 wu-ftpdは設定がされていれば出来る。
>>436 そういえば、Wikiテキストのルールをカスタマイズできる奴が
あったような気がしたんだが…。
単にそういうのがあるといいなっていうアイディアが書かれてた
だけかもしんないけど。
使用する文字を置き換えるくらいなら、
ソース眺めて自分で書き換えるくらいたいしたことないかもしれないけど、
ルールまでカスタマイズするのはめんどくさそう。
wu-ftpd って、ﾀﾞﾒﾎﾟな香具師だったような・・・。
（いわゆる旧）MacOS?
いや、昔大穴があいていて、VineLinux からも外された大物。
まあそれくらい当時は普及していたんだ wu-ftpd は
RedHatのAdvancedServerでは最新の2.1でも
446 ：
nobodyさん ：03/12/04 21:49 ID:gZmG/Wo2
FSWikiなんだけどエラーが出て設置出来ない。
448 ：
nobodyさん ：03/12/04 22:25 ID:gZmG/Wo2
普通はエラーを元に原因を探るものであってだな・・・
>>446 それだと
「ケーサツに捕まったんだけどなんで？」
って言ってるのと同じだから……。
ナニをしたのか、ナニを言われたのかを教えてくれんと
なにも判らんぞ。
正面から見ても、横から見ても、斜め下から見ても
>>447 が正だしい。
452 ：
nobodyさん ：03/12/05 00:48 ID:wbQSvdqW
とりあえず446はもちついて何のエラーが起きているのかとか、環境とか書け。
454 ：
nobodyさん ：03/12/05 22:58 ID:f1/WtJJb
forked version がたくさんあるんだからさ、
>>452 確かに解決しない原因ではあっても、エラーの原因では無いね。
;; でも、設定ミスが理由ならやっぱり原因か？
456 ：
nobodyさん ：03/12/07 06:42 ID:2OE0+dcl
★★★★★常時接続の方におすすめビジネス★★★★★
１日二時間ネットを利用する人だと１ヶ月20000円は稼げます。
ネットサーフィン中に広告バナーを表示させているけでお金になります。
ネットサーフィンだけでなくワープロソフトやホームページビルダーなどを使って
お仕事していてもバナーを表示させていれば課金されます。
広告バーの使用時間は無制限。極端なことを言えば、１日24時間稼動させてもＯＫ。
紹介制度も8段階あり頑張れば１ヶ月50万以上も可能です。もちろん登録も無料。
今までクリック保証のビジネスやメール受信をしましたがこれが一番お金になりました。
英語が苦手な方もホームペーシに解り易く登録方法を載せましたので登録できると思います。
ぜひ登録してみてください。確実に稼げます。
http://members.goo.ne.jp/home/taizou326
457 ：
nobodyさん ：03/12/07 17:28 ID:L4fFLeRc
YukiWiki2.1 plugin機能が目玉らしいage
>>457 YukiWiki久しぶりにアップデートっすか。
他のWikiよりPerlモジュールへの依存度が低いから、期待している人は結構いるんじゃないかな。
おおおっ。YukiWiki派生のwikiを使用してるから、何か便利になるかもな。
フィルタ機能を使えばサイドバーを出せるみたいだな。
某Wikiから乗り換えようかなぁ＞YukiWiki2.1
>某Wiki
TeXのように数学記号が使えるWikiってありますか？
あるよ。
465 ：
463 ：03/12/09 02:39 ID:???
>>464 ありがとうございます。
早速一つづつ試してみたいと思います。
ゼミのまとめページとか議論用ページを
作ってみたいと思っていたので助かります。
Wikipediaで使ってるwikiもそうだね。
467 ：
461 ：03/12/09 13:11 ID:???
>462
TikiWiki使ってるヒトっている？
なんかWikiRoomがおかしなことに・・・。
もうダメポ
攻撃されてんのか?
WikiRoomに何かあったの？
>>473 キャッシュでもみてるのでは?
FrontPage以外にはいると以下のように誘導される。
>WikiRoom が大変なことになってしまいました。
>どうなっちまったのか、レンタルサーバ会社に問い合わせ中です。
>とりあえず、こちらからアクセスしてください
編集すりゃページが消えちまうは、カウンタはリセットされて以後回ってねーは
476 ：
nobodyさん ：03/12/10 03:00 ID:j5nXQPDL
wikiの設置を試みてるのですが、どのwikiでやっても失敗します。
477 ：
nobodyさん ：03/12/10 03:08 ID:PLOGHFES
> Maybe you didn't strip carriage returns after a network transfer?
478 ：
nobodyさん ：03/12/10 03:16 ID:j5nXQPDL
>>477 読めますがどういう事なのかわからないです。
carriage returnsってCR（改行）の事ですよね。
480 ：
126 ：03/12/10 04:07 ID:???
うちのサイトもカウンタが壊れとる。
481 ：
nobodyさん ：03/12/10 04:59 ID:j5nXQPDL
>>479 親切に有り難う御座います。
あした１日頑張って格闘してみようかと思います。
数々のサーバー使ってきましたが導入出来なかったのは初めてなので少し焦ってます。
今週頑張って出来なかったら移転しようかと思います。
それは今までが運良く出来ていただけの話のような。ちゃんとドキュメントを読み理解するということを身に付けないと
483 ：
??? ：03/12/11 00:41 ID:rAVcEnTp
>>470-475 WikiRoom復旧
http://www.wikiroom.com/?FrontPage レンタルサーバ会社の容量制限を越えていたため、ページの更新・追加ができなくなっていました。
現在は問題なくご利用いただけますが、容量をオーバーしているときに更新したページのデータが消えている可能性がございます。
誠に申し訳ありません。
今後は、容量制限に注意して、このようなことが起こらないように努めたいと思います。
WikiRoom の方は Google のキャッシュからHTMLをみて少し復旧できました。
なるほど、容量制限肥か
485 ：
nobodyさん ：03/12/11 03:06 ID:fWoUo0v4
PukiWikiの昔のバージョンって1.3までしか入手できないのかな？
486 ：
nobodyさん ：03/12/11 05:26 ID:GfNpeaRw
自分の Wiki なら、ふつーに CSS 書き換えればいいんじゃないの？
487 ：
nobodyさん ：03/12/12 21:00 ID:glxH2pfT
>>486 シンプルなWikiを自分で作ることにするわ
489 ：
487 ：03/12/13 13:43 ID:???
できますた。
脳内ならイラネ
492 ：
487 ：03/12/14 02:29 ID:EgrMEA3Z
>>491 一から作るより、YukiWikiMiniをPHPに移植してから
自分で作りこむ法が早いね。 サンクス。
ちなみに 489は俺じゃない
493 ：
nobodyさん ：03/12/14 06:08 ID:OJ4D7cD2
>>492 Perl で書かれているものをわざわざ PHP に書き直す理由は何だろう。
>>492 YukiWikiMiniをベースにするのはやめたほうがいい
それだったら一から自分で組んだほうがマシ
YukiWikiを移植するところから始まったPukiWikiも
基本骨格をひきずって相当苦しんだ
きれいにモジュール構造に分割する書き方をわかってて
必要に応じてリファクタリングできるなら止めないが
WhatsNew - WikiRoom
http://www.wikiroom.com/?WhatsNew 2003-12-13 -- 2003-12-21(日)から最終更新トップ20店子リストを表示するようにします。
もし公開したくない方はプロテクトをかけますので、support@wikiroom.com までメールください。
WikiRoomに、"おかしな人"が住み着いてるね。わざとやってるのか
>>497 なんか確信犯のような気がするけど、単に分かってないだけなのか。
あのままシカトぶっこくならそうだけど、素直に謝って引き下がるかな？
WikiRoomの問題は、普通にWikiを運用しているので
トップレベルの本来管理人しか編集できないエリアまで
一般人の編集を許してしまっているところにあるのだけど、
どうにかならないもんですかね。
WikiRoomの場合、ウェブログの本に取り上げられたっていうから、
分かってないだけの人からアフォまでいろんなのが来るんだろう。
そうなるとユーザ管理が必要なのか。
>>497 割れ窓理論とかで同類がワラワラ寄ってきそうだから、管理人さんに厳しく
対処してもらいたいんだけどなぁ。ユーザ同士で削除し合ってても切がない
し。
今の所、管理者による対処じゃなくて、まさにユーザ同志による数の論理で荒らしを圧倒しよう
>>500 んじゃ、とりあえず管理人さんの警告でもコピペしてみるか。
PukiWikiで特殊な整形ルールだけをなし（限りなく普通のテキスト）に
>>502 行頭にスペースを入れると整形済みテキスト（限りなく普通のテキスト）に
なるけど、そういうことではない?
<pre>～</pre>が枠で囲まれたりするのが嫌だという話なら、skin/default.ja.css (skin/defalt.en.css) の
<pre>
{
～
}
をいぢれば？
pre
Software Design に Pukiwiki が紹介されてる。
508 ：
502 ：03/12/18 23:24 ID:???
行頭にスペース入れるとpre要素でマークアップされるけどさ。
>>509 PukiWiki 1.4系では出来ますが…。
Pukiwiki使ってんだけど、データって簡単にほかのWikiに移行できるんかな？
>>511 プラグインとか使ってなければ YukiWiki あたりに移行できるかと。
つーか、YukiWiki のプラグインの文法変態すぎ。
>>512 PukiWikiの文法とどこが違うのかと小一時間…(ry
PukiWikiも &inlineplugin(arg,...); とか
Pukiwiki 1.4.2でamzonのプラグインを使うとばけるのはおれだけか？
1.4.2でamazonプラグイン使ってるけどなんの問題もないっすよ。
>>517 情報どうもです。しかし、何が悪いんだろう？
FreeStyle Wiki 2.5.2リリースを確認。
HikiってなんかtDiaryと似て閉鎖的な感じがするのはヲレだけですか
PukiWikiで日本語名を含んだInterWikiをアクセスしたら、文字化けでアクセスできません。
<?php echo rawurlencode('PukiWiki/プラグイン/1.4') ?>
で、FreeStyleWiki の複数文法対応まだ～？
レス遅れて申し訳ない。
>>525 > <?php echo rawurlencode('PukiWiki/プラグイン/1.4') ?>
PukiWiki%2F%83v%83%89%83O%83C%83%93%2F1.4
どんなもんでしょう？
なんだ %83v とか %83O て。気にならんのかぃ。
>528 はスクリプト自体が SJIS になっとるな。
EUC-JPなら
>>528 と同じで
PukiWiki%2F%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3%2F1.4
になる筈。
この様子だと mbstring.internal_encoding と
PukiWiki の文字コードが一致してないとかじゃ ?
その辺り確認しても判んなかったら mbstring の設定晒して。
>>531 >
>>528 はスクリプト自体が SJIS になっとるな。
正解でした・・・何やってるんだ俺_|￣|○
PukiWiki%2F%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3%2F1.4
です、すんません。まぁ、問題は解決してませんが・・・。
んで、
http://tsuttayo.sytes.net/php/char_trn/を参考にして 、
<?php phpinfo() ?>
を実行してみましたが、
Warning: phpinfo() has been disabled for security reasons in /usr/home/free/home/***/public_html/test.php on line 2
_|￣|○
・・・これはサーバーローカルの問題として相談した方がいいのかな？
LinuxZaurusでFSWikiって動きますか？
でも、これだと書式ごとの非互換性とか足りない情報とかはどうするんだろう？
実装する気なんか無かったりして。
541 ：
536 ：04/01/04 14:18 ID:???
>>537 サンクスコ!
FSWiki で見出しの表記方法が逆なのはなんとかして欲しい。
544 ：
nobodyさん ：04/01/06 17:14 ID:b7wlaMSU
Wikiのみんなでつくっていく感じ（Wikipediaとかまさしくそう）は大好きなんだけど、
>>544 もちろんUIはテンプレートファイルやソースを変更することにより、
ユーザーの皆様の好みに合うようにカスタマイズすることが可能となっております。
また、GPLライセンスの元で再配布を行うことも可能ですので、我こそはと思う方は
是非、再配布を行ってすぐれたUIを広めて頂きますようお願い申し上げます。
547 ：
nobodyさん ：04/01/07 03:14 ID:/Rexsqi+
>>544 左側のメニューはサイトの情報なんだからそうがないわな。
上のメニューに限らず、状態とかによる表示のコントロールとかって
こなれてないんだよねぇ。
結局、メニューを一生懸命作って対処することになっちゃう。
>>545 ソースいじっってカスタマイズなんてViewの独立になんてなってねえ。
右上文字列すぐ慣れちゃったけど、一見さんには馴染まないよね
＞ 書き込む d | 検索 | TopPage | ページ一覧 | 最新50
出力部分を、XOOPSみたいにWebでいじれるといいんだけどね。。
>>550 対応するコードを書けば、簡単じゃないの?
YukiWiki 2.1 まだぁ？
つまり今日はまだ2003/12/40なんです
555 ：
：04/01/10 01:03 ID:???
555get, zuzaa
みんなWikiをどんな風に使ってる？初めて使ってみたんだけど、どうも効果的な利用方法が思い浮かばなかった。
wikiがどういう使われ方してるかはグーグルでwikiと検索すると山ほどでてくるよ
漏れの場合は、ローカルでHTML書いてFTPでアップロードして表示確認して、
561 ：
nobodyさん ：04/01/11 21:37 ID:SKq039uA
私は個人的な残しておきたいメモ書き代わりに使っているけど、
画像ファイルをコピペって…GUIなHTMLエディタみたいにか？
563 ：
nobodyさん ：04/01/11 22:07 ID:ccGEJBVE
>>561 いくらなんでも無理だろ・・・
PHPはサーバサイドスクリプトなんだから
なぜに PHP ?
Javaならやれるべ。
2ch的Wiki文法を決めればいいじゃん。
Wikiが終わりつつある今日この頃。次のホットな話題はなに？
blogっていうやつ
え？終わりつつあるんだ。
blog はさらに枯れているね。
WikiWordへのリンクは
ｂｌｏｇって、トラックバックとかRSSとかあっても、やっぱり独白です。
>571
niftyとかNTTがblogで儲ようとしているから
知り合いでblogでビジネスできないかと模索中の頭の弱い香具師がいる
>>561 後半はずっと考えてるんだけど難しいねぇ。
Flashをフロントエンドにしてうまく出来ないかってぼんやり
思ってたところにNOTAってのを知って試してみようと思ったら
移転準備中だって ＿|￣|○
>>571 面白いけど虹色はやめて欲しいかも・・・
だんだん色が薄くなるとかでグラデーションくらいがいいな。
WikiNameなんだけどページがないときは別系統の色、
と言う感じで。
新旧よりも、もしかしたらアクセス数で色変えたほうがいいのかも？
blogがどういうものかあまり知らずにwikiに来た俺は少数派
>>576 テキストボックスじゃなくて、やっぱWordみたいなフロントエンドいるねえ。
せんようのエディタが必須になるかな？
これからはhowmだよ。
584 ：
wiki導入検討中 ：04/01/15 01:23 ID:poYBH+K6
wiki初心者なのですが、wikiで作成した一連のページを、閲覧目的に何らかの汎用
pdfに出力したい場合はFSWikiかな？
>>585 FSWikiのPDFはきれいに生成されるんで、結構使えると思う。
あと、FSWikiには試験的ながらHTMLやPDFへのコンバート用スクリプトtoolsがあるね。
>>559 逆に、いろんな記述形式に対応したらどうだろう?
保存はある代表形式かxmlなりなんなりにして、
編集の時にはいろんな形式の中から好きな形式を選択する。
まあプログラム作成が大変だけど……。こういうwikiがあってもいいかもと思う。
>>587 プログラムの話は置いておいておくことにしたとして、
編集のときの動きが難しそうな。
ログインを前提としないWikiだとどの形式で書きたいのかが決まらない状態で
既存のページの編集ページ開かなきゃいけなくなるわけで。
毎度毎度編集ページで書き込み形式切り替えるのは絶対面倒だよ。
Cookieに覚えさせるのもまあ選択肢の一つだろうけどね。
なんかいい案はないもんかねぇ。
Cookie で何か不満なのだろうか。
「WikiRule」とか言う特殊ページを作って、InterWikiNameみたいに
データをXMLで持っておくんなら、それが全てだと思う。
592 ：
wiki導入検討中 ：04/01/15 23:42 ID:P76KYW8n
>>585 .
>>586 ありがとうございます。なるほど。FSWikiが良さそうですね。調べてみます。
594 ：
nobodyさん ：04/01/16 01:22 ID:ZzgAth+b
>591
595 ：
590 ：04/01/16 01:35 ID:???
>>593 スマンな。正直オレは現状で困ってないから、この件に関しては動く気無いんだ。
次からは黙って見てることにするよ。
>>590 既存記法とのコンフリクトをどうしようねぇ。
今ってどの記法が先に評価されるかが見えないような気がしてるんだけど
これ取り込んだら余計見えなくなるような。
でも、WikiRuleみたいなページ作ってそこで記法定義するってのは
面白いアイデアかもね。記法じゃないとこで使いたいところ。
>597
600 ：
597 ：04/01/18 11:18 ID:???
>>599 ほんとだ、今見れないや。
概略はPukiWikiのUI（読み書き）にFlashをという話なんだけど
602 ：
nobodyさん ：04/01/20 00:27 ID:cYR+KzuA
603 ：
602 ：04/01/20 00:37 ID:cYR+KzuA
wikipedia の宣伝すんなよ。スラドでも宣伝しすぎ。
>>606 navi2ch-article-message-filter-by-message-alist
Wikipediaの中の人ですが……。
>>608 Wikipedia自体はだいすきよー
でももう散々貼られまくった2chやスラドより、もっと多くのライトユーザーの
目にふれるとこで宣伝できればいいのになーって思うよ。
人が多ければ多いほどコンテンツが増えていく、っていう2chと同じ状態まで
もっていけるといいよね。
( ´_ゝ`）フーン
612 ：
の ：04/02/04 13:59 ID:???
>>612 WalWikiはすでにwal.4版から「部分編集」という名前で、同機能が実装済み。
便利に利用してます。
オレはこの、編集パートがインラインで表示されるのにちょっと感動。
615 ：
の ：04/02/04 20:39 ID:???
>>612 これ面白いね。
もうちょっとこなれたUIができるともっと面白そうなんだけど、
なにかいいアイデアはないものか。
>>614 長いのはともかく、画像は確かにそうだよねぇ。
ブロードバンドでも画像の位置が変わると結構鬱陶しくなるし。
617 ：
の ：04/02/05 01:14 ID:???
>614
今FSWikiを使っているのですが、
Yuki、Walはできたような記憶。
FSはインライン要素の解釈がなぜか内側から行われていて
２ちゃんウィキってまじですか。厨が自分とこにきそうでやだなあ。
なんで2chがWikiをやると厨が
>>621 の所に行くのかわからない。
>>622 wikiの使い方を知っているやつが増える＞wikiを見かけると書き込みしたくなるやつが増える＞
その中の何割かは厨だ＞……ということですが。
結構、有名なところなのか、2chでさらしているのか、
>>624 もっと長いスパンで考えてくださいな。wikiなんて今じゃ誰も知らないと
言ってもいいくらいだけど、２ちゃんの影響で知られちゃったら、
わたしのとこみたいなヘタレサイトにだって厨はきますよ。
>>625 それは、あなたのサイトが既に「厨」臭いからでしょう。
現在の一般的な掲示板に対する2厨による荒らし行為についても
ネット上の全ての掲示板において現れる普遍的現象では決してなく、
「厨」を引き寄せる独特かつ一種異様な雰囲気を醸し出している
ごく一部の掲示板にのみ現れているに過ぎません。
だから何なのよ？
630 ：
621 ：04/02/07 00:51 ID:???
いやあ、624さん＝626さんの断定は切れ味がすばらしいなあ。
631 ：
：04/02/07 01:29 ID:???
>>631 ええ、ご紹介のページに書いてあることは一般論としてもちろん理解しています。
うちはユニーク１００人規模でwikiをたちあげてから１年近くたちますが、「ノイズ」
なるものは皆無に近いどころか本当に「皆無」なんですね。
しかし、「シグナル」を強く出し続けるのはしんどいですよ。あの「一般論」は日本では
まだ実地検証されていませんね。
おまえが今このスレで今一番大きいノイズなわけだが
634 ：
632 ：04/02/07 23:08 ID:???
>>633 そんなことないでしょう。あなたとほぼ同じノイズだと思いますよ。
>>632 ならいいじゃん、そのまんま続けていれば
１００人いて１００人全員がシグナル『だけ』を出し続けて1年続いたんなら
これからだって大丈夫だろうよ
俺はそんなWikiは怖くて編集できなそうだが
嫌がってんならそれなりの対策採ったらいいだけじゃん。
>>620 あんまり深く考えたことなかったなぁ
作者が見た目にこだわったことにあんまり気を回してないみたいなので
最初に思いついたほうを採用しているだけとか？
インラインの入れ子ができて、さらに食い違いは起こらないようなのはありますか？
>>638 Wikiなのだから、それぐらい後から直せばよい。
640 ：
nobodyさん ：04/02/09 13:35 ID:tITeQ1n0
HTML は兎も角 CSS を埋め込めるメリットがいまいち。
642 ：
640 ：04/02/09 18:35 ID:tITeQ1n0
>>641 CSSを埋め込めるようにしたのは整形ルールを極力減らすというポリシーを
実現するためでした。 結果、非常に強力な表現力を持つことができるよう
になり、見た目を提供するための整形ルールを定義せずに済みました。
XSSは本当に頭の痛い問題ですが、自前のサニタイザーでなんとかできる
範囲ではないかと思っています。 ちなみに、レイアウトを壊せる程度の
ものは脆弱性とは思っていません。
ご意見どもー。
自前のサニタイザーですか。
644 ：
nobodyさん ：04/02/09 22:50 ID:+xMbnVr8
個人的にはWikiにHTMLタグって？？と思うところがある。
誰も知らない俺ルールの独自タグを作られるよりも
646 ：
nobodyさん ：04/02/09 23:34 ID:tITeQ1n0
>>644 そもそもWikiってWYSIWYGじゃないと思います。
例えば色を変えたい時は PukiWiki なら &color(foo) { hogehoge } ですが
それが GrooveWiki では <span style="color: #foo;">hogehoge</span>
となるだけです。 ここに、それほどの差があるとは思えません。
WikiEngineに依存する文法を覚えるよりHTML/CSSの方が何かと都合が
いいと思っていますが、どうでしょう。
647 ：
nobodyさん ：04/02/09 23:43 ID:Xv3/2vcC
HTML（っていうかXMLやSGML）って記述が案外面倒。
Wikiには多機能より単機能がお似合いなんだけどなぁ。
脆弱性の話はまた別なんでとりあえず置いておこう。
650 ：
640 ：04/02/10 05:17 ID:???
みなさん、書き込みの前にwebサイトの方は見てると思いますが、勘違い
してると思われる書き込みが多いので一言。
GrooveWikiにも整形ルールはあります。 具体的には、強調、リスト、
見出し、リンクなど。 必要最低限の簡易整形ルールです。 なので、別に
無理して HTML を使う事はありません。 実際、テストサイトの方で、HTMLを
使っているページはほとんどありません。
なので
>>649 >要するに、文法がHTMLと全く同じのWiki。
ではありません。
さらに、機能を増やさないというポリシーの観点から言えば
>そもそも、「文字の色を変えたい」なんて機能、Wikiにいるんだろうか。
>（個人的にはそのこと自体に否定的）
というのは、むしろ褒め言葉として見えます。
651 ：
648 ：04/02/10 08:58 ID:???
>>640 整形ルールを減らす目的でCSSを使えるようにする。というのはひとつの方向だと思ふ。
だけど、整形に関する機能はなんかもういいやとも思ふ。
整形以外の方向でなんかないかなぁ。
ドラッグ＆ドロップ(JavaScriptによる)を利用するともっと面白いことができないか思案中。
FSWikiの本家で、クリップボードから画像をうｐしたいとかゆ～投稿もあったな。
文字色なんかはもっとシンプルに
654 ：
644 ：04/02/10 13:29 ID:???
>646
655 ：
640 ：04/02/10 15:57 ID:???
>>654 >そこが根本的な違いですね。
何との違いですか？
> 表現力をあげると整形ルールが複雑になるから、却って議論の邪魔になる
ビューと文法の話が混ざってませんか？
>Textスタイルでできる範囲の整形ルールを目指したのがWikiスタイルで、
>何でもかんでも表現できるようにしているわけじゃないと思います。
すみません、おっしゃる事の意図がよくわかりません。 Wikiでは視覚的
表現の実現は不可能であるべきだと言う主張でしょうか？
>「強調」「もっと強調」「すごく強調」「バカみたいに強調」
>といったようにして、それを表現するのに色を指定するほうがいいでしょうね。
それこそ、まさにCSSの使いどころです。 あらゆる整形ルールは最終的に
HTMLに変換されるので、その属性として指定します。
>負担が増加するということには変わりはないです。
何に対して(増加する|変わる)のでしょうか？
>そのHTMLを理解する必要がありますよね？
プレインテキスト以外の全ての形式は文法を理解する必要があります。 ごくご
く初歩的なWiki文法さえもも例外ではありません。 しかしながら、文法を知らな
い人にとって、新規に記述する事は不可能でも編集は可能ではないかと思い
ます。 目的の文字列を見つければ良い訳ですから。 これは、Wiki的文法とか
HTMLとかは関係ないと思います。
(挑戦してる訳じゃないんですけど、気に障ったらすません)
656 ：
640 ：04/02/10 16:00 ID:???
繰り返しになりますが、無理してHTMLで表現をする必要はありませんし
ええやん、分かる人はHTML使う
分からん人はWikiの文法使う
編集者の選べる手段が増えたってダケっしょ？
>>640 は頑張ってバグ潰してくださいな
タグの閉じ忘れ程度でおかしくなっては使う気になれないんで
日本語でだって「正しい原稿用紙の書き方」を知らない人がいるくらいだから、
659 ：
nobodyさん ：04/02/10 22:09 ID:nbsbpZYc
660 ：
654 ：04/02/11 00:59 ID:???
ちょっと、一問一答になってしまいましたが……
＃これこそ2chじゃなくてWikiだよなぁ
>655
>何との違いですか？
おっと、失礼。
「640さんの考えているWikiの整形ルール」と、
「Wikiのコンセプトに従った整形ルール」の違いです。
Wikiの基本は「議論のためのツール」なので、できるだけ
議論に集中できるように、簡単なものにするべきでしょう。
＃定義リストとか不要だよなぁ……
参考：
http://c2.com/cgi/wiki?WhyDoesntWikiDoHtml 個人的には、WYSIWYGだともっと簡単になるので、整形ルールは
テキストベースでWYSIWYGでも考慮すべきかと思います。
> ビューと文法の話が混ざってませんか？
>すみません、おっしゃる事の意図がよくわかりません。 Wikiでは視覚的
>表現の実現は不可能であるべきだと言う主張でしょうか？
視覚的表現を嫌っているのではなく、複雑なルールを嫌っているだけです。
Wikiの場合、「参加者全員が編集者」という重要な特徴があります。
参加者全員が編集者となるためには、編集するための敷居（含む整形ルール）
はできるだけ低くする必要があります。
整形ルールが複雑化する／HTMLを採用することにより、編集するための敷居は
確実にあがるので、特に必要がなければ採用しないほうが良いかと思います。
661 ：
654 ：04/02/11 01:00 ID:???
662 ：
654 ：04/02/11 01:06 ID:???
>ところでWikiってBlog的な使い方、もっと言えばオンライン版
Wikiの整形ルールがマークアップじゃないと思い込んでいる人がいるね
664 ：
654 ：04/02/11 01:21 ID:???
>663
俺様な整形ルールを好きなだけCookieに保存。
>>665 俺ルールを最初に設定して、それをCookieに保存。
で、次回からはエンジンがCookie読んで勝手に解釈してくれってこと？
内部データはXMLかなんかで適当にやってくれやって感じ？
なんかどっかで無理がでそうだ。 アイディアとしては面白いけど。
>>654 はWYSIWYGって言葉をちょっと拡大解釈使ってないか？
WYSIWYGって文法が見やすいとかって話じゃなくて、ワードみたいな
編集方式を指すんじゃないの？ What You See Is What You Get
>>652 クリップボードから画像うぷは欲しいねえ。
でも、安全装置がないとどでかいファイルを上げちゃったりしてちょっと怖いかも。
なんとなく、Wikiへアプロードしたよと通知する機能とFTPの機能
（できれば、JPG/PNGへの変換と大きさ、サイズ修正を含むコンバータ機能）を
もった独立したツールの方がいいかなと思う。
特定のWikiにべったりで作った方が、そのWikiにとって売りにはなるのだけどね。
yukiwiki2.1あげ
670 ：
654 ：04/02/11 22:41 ID:???
>667
簡単にすることと、複雑にすることにはそれぞれ意味があるんですよね。
>>670 なんか誤解してる気が
もまいの言ってるのは拡大解釈のほうだろうが、
それは「見たまんま、そのまんま表示される」ものではないよな？
「書いたとおりに（レンダリングして）表示される」ものだよな？
WYSIWYGってのは、
http://www.interactivetools.com/products/htmlarea/ こんな感じにまさに見たまま編集するものだよ。
イメージのコピペとか考え始めるとこの手のもので編集させたほうが
まっとうな気がするんだよなぁ。
ただし、これを使ったものはもはやはWikiではないと思う。
誰でも編集できるというのはWikiのひとつの大きな特徴だろうが、
プレーンテキストの入力がほどほどにHTMLに変換される部分ってのも
捨てられない特徴だと思う。
とかぼんやりと考えてみたりして。
とりあえず、原点に戻って、「Wiki Way」を読み返してみなよ。
674 ：
nobodyさん ：04/02/12 02:20 ID:qKb16FBy
すでにあるHTMLソースをpukiwikiソースに変換するような
675 ：
654 ：04/02/12 03:15 ID:???
>672
>>674 変換支援、程度なら html2pw.inc.php でどう？
>>660 あげ足とるようですまんが、Wikiはコラボレーションのツールであって、
議論のためのツールではないと思うよ。Wikiが議論に向いてないってのは
あちこちでさんざん言われているとおりで。
>>675 >>640 は、
必要最低限のWiki的整形ルールは用意しているわけで。
その上で、より多くの表現力が必要ならHTML使ってね、ってことでしょ？
複雑なルールではないと思うんだけど。
そのプラスアルファの部分でほかのWikiみたいに独自文法増殖させるより
いいと思うなあ。
678 ：
_ ：04/02/12 14:40 ID:???
>>675 HTMLさえ理解できない奴がWikiの整形ルールを理解できるとも思えないが?
それに、その程度の人間が下手にWikiの整形ルールを覚えてしまうと、
YukiのルールでFSに書き込んだり、FSのルールでPukiに書き込んだりと、
却って鬱陶しいことになる恐れがある。
それならば、既に存在しているHTMLを活用した方が、より無難で安全。
>>678 HTMLが理解できてなくてもWikiを使ってる人もいるよ。
HTMLより先にWikiっていう世界を知った、という感じ。
少数派なのは事実だけど。
一応、そこだけ補足
>678
「HTMLの箇条書き」ってそんなに難解なのかな？
「XMLウゼェ→YAMLとか作る/使うしか！」って奴らがいることを見ても、
Wikiの記法が統一されていないことが、
684 ：
傍観者 ：04/02/12 22:01 ID:???
なんか、平行線だな
685 ：
654 ：04/02/13 01:39 ID:???
http://c2.com/cgi/wiki?WhyDoesntWikiDoHtml の最初の段落を超訳してみたなり。全然正確じゃないんで、原文も参照してね。
なンでWikiはHTMLでやらないの？
「なんでWikiはHTMLでやらないの？」と、新しくWikiにやってきたヤツらは
しょっちゅう言う。もう耳にタコだ。
取りあえず、これにはいくつもの答えがある。
1. Wikiの整形ルールは「それが機能するもののうちで最も簡素になるような
ルール」になるように設計しているんだ。
2. Wikiで重要なのはそのページの内容だ。どう表示するかじゃない。
簡素なマークアップルールにしておけば、参加者は、彼（彼女）等の
アイディアを飾りたてることではなく、アイディアそのものを表現することに
注力するだろう。
3. HTMLで書き込む、特に表のような複雑なタグを打ち込みながらじゃ、
マトモな考えはまとまらないよ。
4.WikiNameのような部分はコードでも読めなきゃね。当然、Wikiページの
生テキストでも同様。編集時に、その内容は簡単に識別可能じゃなきゃならない。
<><><><><><>の海の中で見失うなんてことは言語道断。
5. HTML全てを許すと、ページは多様なフォント、色、その他もろもろにより
混乱する傾向にある。もし単に考えをやりとりしたいだけならば、
「どうせいらないもンだ」から、窓から投げ捨てろ。
6. 全てのHTMLを許すことは、JavaScript等を通してセキュリティホールを
あけると言うことだ。（ただし、これは簡単に修正できる。JavaScriptを有効にした
Wikiについての議論を見てくれ）
7.25,000ページにもおよぶページや、それを動かしているスクリプトを
変換することはとてつもない作業であるにもかかわらず、変更したからといって
何のメリットも無い。つまり、うまく動いてんだし、壊れていないんだから
そのまま放っとけ。
686 ：
673 ：04/02/13 01:45 ID:???
もう一度言う。
>>685 「新しくWikiにやってきたヤツら」という言い回しに象徴的なように、
『Wiki Way』とか読んじゃうWiki信者の皆さんの中には、
Wikiを手段ではなく目的と捉える向きが少なからずあるわけで
"整形ルールにHTMLが使える"をメリットと捉えるかデメリットと捉えるかは人それぞれ。
689 ：
654 ：04/02/13 02:34 ID:???
>686
手段とか目的とかの話をするのが好きでつね。
691 ：
654 ：04/02/13 02:50 ID:???
692 ：
686 ：04/02/13 03:19 ID:???
タイムスタンプを見ればわかると思うけど、
あー今思い出したけど
>>691 『Wikiについて語る』スレだからといって、
変な方向にこだわって kitty-guy になる必要はないわけだが。
695 ：
とほほ ：04/02/15 15:31 ID:???
696 ：
とほほ ：04/02/15 15:34 ID:b14uvP2A
という質問は野暮すぎれつか?
使えるところもあります。
javascriptの書けるWikiなんかあったら面白いんだろうな
展示場も何も最初の一つしか動かないから意味ないじゃん。
>>699 落ちるやつが悪いものなの?
落ちるように作られてるから、落ちるのが正しい動作なんだと思ってた。
ありがとう
すんまそ．．．
Amazon 用のリンクなんて、どの Wiki 使っても簡単に実現できるものじゃないの？
>>703 2ch互換の「ぜろちゃんねる」ってのはどうでつか？
2chブラウザから簡単にアクセスできますです。
>703
今、Ｗｉｋｉクローンで一番便利なのって、どれよ？
素人向きには、PukiWiki(PHP)/FreeStyleWiki(Perl)/Hiki(Ruby)。
苦労人向きには？
aaacafeに設置しているpukiwikiに軒並み新規ページ作成ができないんですが、
>709
>>711 漏れは普通にaaaで動いてるぞ
自動設置は使ってない
どうせパーミッションのミスとかだろう
PukiWikiって、フォーラム作れんのか？
ん？ファームの間違いじゃないの？
forum フォーラム
>>717 farm ファーム
ということで．．．
>>717 こっそりfromも混ざってれば面白かったのに
>>710 今のPukiWikiってかえってわかりにくい気がするんだよね。
reimyが管理し始めた辺りから魅力がなくなってしまった
こんな漏れはFSWikiだけど、気に入らない部分を改造しまくってたら
自分で作ったほうがいい気がしてきた。
721は麗美に論破された奴だろ。放っとけ。
wikiroomの新規登録止まってるね。
俺は最近Swikiが気になるお年頃。
Hikiのサイトって、なぜどこも糞重いの？
>>729 ほとんどの場合refererの解析がネック
731 ：
nobodyさん ：04/02/19 06:38 ID:YcYwm3ap
>>727 SwikiはデフォルトでHTML使える
JavaScriptも使える
実は、使えるようにしてしまった方がプログラミングは楽とかって思わない？
734 ：
640 ：04/02/20 08:13 ID:PDLbbn/9
>>734 XSS対策で悩みそうなもんだが、それでも楽？
対策しないなら楽なのは判りきってるが。
対策する必要って本当にあるのかな
ここ最近、aaa で、Wikiを導入したものですけど
誰か、PukiWikiの設定が初心者でも分かるように
>>739 機能の少ないWikiから入った方が良いんじゃ？
>>735 シンプルなWikiなら全部エスケープしちゃえばいいんだけど、
プラグインが入ったりして、エスケープすべき文字列としてはいけない文字列が
入り交じると大変。たいてい、バグの温床だったり。
そんなんだったら、プラグインも含めて使用可能なタグと属性値を決めてしまって、
最後の出力前に一括して無害化してしまった方が楽で安心。って考え。
>>740 いや、分かりやんした．．．
俺様の勘違いですた．．．
でも、むちゃ、うれしい！！
俺様、Wiki初体験です！！
PukiWiki設置サイトのリストって、誰か知ってる？
>>743 google で "Based on PukiWiki 1.3 by sng" と入れて検索をかける。
>>743 1.4.2に改造やらパッチ当たりまくりVer.
盗難されるとまずいようなクッキーを使ってるサイトはもちろん対策しないといけないけど、
>>747 クッキー盗まれるってのはひとつの例にすぎない。
起こり得る幾多の被害をちゃんと想定できないなら、
素直にXSS対策したほうがいいよ。
>>747 XSSが出来るのは「即座に駄目」でしょ。
色々機能が使えて利便性も高い、しかもXSS対策も出来てる→最高
正直Javascriptは手に負えないのでカットしてます＞俺
とはいえIEだと融通きかして実行しちゃったりするので、なかなか完璧には。
クローズドで、利用者の気心が知れた仲間内で使うWikiなら
XSS対策の労力は掛けなくて良いと思うけど、サイト公開してたり、
対策なしのソースを断り書きもなしで公開しちゃったりするのは、どうかと。
他に開発したモノ、全体の品質まで疑われかねんよ。
初心者なんですけど、Ｗｉｋｉを始めるにあたって
キリスト教に抵抗が無いなら「結城浩のWiki入門」がよさそう。
だれかXSSのテストケース作ってくれんかな。
そこでもうブチ切れですよ。
XSSってブラウザのバグだったんだ
>>754 勉強しなおせ。プラウザノバグに依存するから対策が難しいんだろうが。
つか、話が戻るけど、XSSによる危険の可能性と、(X)HTML/CSSを許容するメリットとを
>>757 XSSによる危険の可能性 と (X)HTML/CSSを許容するメリット
を考えたときに、一律にどちらかに傾く訳ではないので、
メリットがあると思ったものについては、生で使わせるのではなく
独自タグとして拡張して使わせてる。見栄えに関して許容してるのは
「後から静的なコンテンツでまとめる」をある程度省きたいため。
ただJavascriptに関しては、自分ところではメリットが上回らないんだけど、
積極的にJavascriptをOKにしてる人らは、どの辺りの機能が欲しいの？
DHTMLの捉え方だとは思うんだけど。
760 ：
nobodyさん ：04/02/21 23:15 ID:Z1C/v0oT
>758
761 ：
nobodyさん ：04/02/21 23:31 ID:Z1C/v0oT
基本的なWikiの整形ルールだけで満足してる人って少数派なのか？
俺は満足してるよー。箇条書き、引用、整形済みテキスト、テーブルの４つで充分。
ほんとに基本的なルールしかもたないWikiクローンがいくつある？
>764
> 満足できないから、みんなゴテゴテ整形ルールを追加するんだろう。
(拡張を頑張っている)整形ルールなんぞ80-20の20のうちなんだよなあ。
>>764 最低限のXSS対策をした上で、の話だよね？
なんか見てると、HTML+CSSなひとはXSS対策を全くする気がないように見えるんだけど・・・
あとあんたが基本ルール以上に実現したい事ってなんだ？
整形ルールがそこまで複雑なWikiって、俺は知らないんだが・・・
具体例をだしてもらえるとわかりやすいんだけど。
769 ：
nobodyさん ：04/02/22 12:53 ID:4VwGou+7
>764
770 ：
nobodyさん ：04/02/22 12:57 ID:4VwGou+7
>764
整形ルールを追加するのはいいんだが、設置するときに簡単に無効化できるように
764ではないが。
>>768 ,769
前に書いたように、XSS対策は厳密にPLUGINの実装をした方が難しい。
限定されたHTMLを許すことのほうが楽。
整形ルールが複雑なWikiなんてPukiWikiを筆頭としていくらでもあると思うけど。
そもそも、リンクにしたって[[hoge>hoge]]なんかが単純だと感じているのは
Wikiに順応しているからでは？
自分はルール確認が面倒なのでどのWikiに書くときもURL直書き。
オリジナルルールに則っていれば単純だという意見ならそれまでだけど。
オリジナルルールについて検討したことはあるのかな。
>>770 すべてをおなじ簡単さにあわせようというコンセプトがデザインの違いなのでは？
また、HTMLと複雑なWikiルールの難しさは50歩100歩に見える。
実際には、どちらも作ったことがない/使ったことがないのでわからないけど。
HTMLに関しては不足したタグを補うくらいの機能はライブラリで提供されている言語が多いし
あえて、独自タグを使うメリットはHTMLのベタテキストを書きたい時くらいかな。
>>771 選んでねっていっても、ちゃんと選ぶひとがどのくらいいるかは謎だね。
すくなくとも書いた字面と異なった表示をするのなら整形ルールじゃないの？
775 ：
769 ：04/02/22 14:13 ID:???
769-771はオレだから一括するね。
ありゃ。俺はてっきり、文の見た目を整形するルールだけの話だと思ってたよ。
>>776 「信じられない」というのなら、まずは根拠をきぼんぬ。
根拠を出してもらわないと話にならないね。
単純にHTML+CSSだけでコメント機能やらを再現しようと思ったら、まず
なぜ、複雑なルールは必要か。
1. 初心者にアピールするため。
残念ながら、初心者の皆さんはWikiの理念に共感してくれている訳ではない。
単純に、”便利そう”と思ってやってくる。だから、見栄えが良いとモテる。
ただ、実際にはそういった機能は使われないことが多い。
2. 可視化のため
適切に構成されたデータは見やすい。
表現力の最大値はHTMLで書くことである。
だから、HTMLを認めれば、最大限の表現力を確保することができる。
しかし、それだけでは読み書きに手間がかかり現実的ではない。
したがって、別途マクロ機構を組み込めばよい。
HTMLを許可するからって実際にHTMLですべて書くこともあるまい？。
ただ、HTMLとかわらない複雑さをもつマクロは本末転倒だね。
XSS対策については
>>741 を参照のこと。
ごくろうさん。
(参考になる +1)
とりあえず作ってみてもらえんか？それを。
783 ：
769 ：04/02/22 20:23 ID:???
>779
1. 初心者にアピールする必要はあるのか？
「Wikiを設置してもらえやすくなる」というのならば、アピールの方向が
間違っていると思います。Wikiを設置／運用する管理者はある意味
Wikiというプロジェクトを管理するマネージャーです。管理者／マネージャーは
「過度の（ユーザーの）自由」を嫌いますので、実際に使われない機能の
ために(XSSなどの)リスクを負いたくはない、というのがマネージャーの
本音かと思います。
＃少なくとも私はそうします。
「設置したWikiサイトにユーザーが集まりやすくなる」というのであっても、
やはりアピールの方向が間違っていると思います。Webの見栄えが
「モテる」要因だというならば、その重要な生命線をユーザーに任せて
しまうのは非常に危険ですね。（しかも本質じゃないし）
見栄えについてはCSSなどで管理者が調整できるように手元に残しておいた
ほうがいいと思います。
……Wikiの理念（メンバー同士の共同作業）に共感しないのなら、そもそも
Wikiを設置して意味あるのかな？個人で使うならBlogだし……
2. 可視化の詳細を記入者にコントロールさせる必要があるか？
最近のHTMLのトレンドもそうですが、コンテンツとデザインを分離し、
同じコンテンツを様々に使いまわすことが重要視されています。
可視化の詳細を記入者にコントロールさせるということは、結局、デザインを
コンテンツに埋め込むということであり、コンテンツとデザインの分離を
困難なものとしますので、あまり望ましくありません。
# >761でも引用されているサイトも参照してちょ。
#
http://www.hotwired.co.jp/webmonkey/2002/45/index3a_page2.html >>783 779ではないですが。
たとえば部署内の情報共有にWikiを使いたいと思ったとき、Wikiに馴染み
のない人を釣るエサは多くてもいいと思います。往々にしてそういう人た
ちは文書の論理的構造よりも「フォントの色が変えられる」のほうに興味
を示すわけで。
堅苦しい「Wikiの理念」を押しつけて、導入しても誰もそのWikiを使わな
いより、少しでも初心者にアピールできるほうがいいと思うのは軟弱なん
でしょうか。
初心者にアピールすることが目的なら、勝手に入門講座 Web とか
フローの情報はノーツがあるので、ストック系の情報共有に使いたいのですが、
>>787 世の中、そんなもんでしょう。
つーかね、Word や Excel を使わないと行けない場面では、
Wiki ならではの強みなんてないかと。
789 ：
769 ：04/02/22 22:04 ID:???
>784
1.
>>789 > 「こんなに簡単にWebページができるんですよ！！忙しいプロジェクトリーダーでも
> 議事録メール書き込む手間でまとまりますよ。みんなで編集できるし」
Word や Excel が全てだと思っている人に対しては、
Web ページを作る必要なんかないかと。
Word でもみんなで編集できるじゃん。
> DocBook勉強しろ
勉強したところで、内容が良くなるわけじゃないんだよね。
勉強する理由きぼん。
Ｗｉｋｉ、今回初めて導入した初心者ですけど
シンプルなWikiは今でもありますよ。そちらを使ってはいかがでしょうか。
796 ：
769 ：04/02/22 22:17 ID:???
>787
最近流行の7行Wikiとか。
なんか話がループしているよ。
>>796 > ・ミスって消しても（過去の変更履歴から）すぐに修復できる
全ての Wiki が履歴を持っているわけではないんだよね。
> ・変更内容がすぐに反映される
Word や Excel で保存しても同じでは？
> ・Webベースなので、他の情報（WebページやWikiページ)の連携／参照が簡単
> ・Webにアクセスできるところならどこでも参照できる
Word や Excel で満足している人々に対しては、
Web ベースに移行する必要ないかと。
> ・電子メールと同じぐらいのお手軽さ
んなことぁない
> むしろこのケースならWikiにWord+Excelファイルを添付できるようにして
そんなん、二度手間だろう。
電子掲示板みたいに、やることは簡単だが出来ることはいろいろ制限有りってのでも、
まあ、思うのは自由だわな。
ユーザーインターフェースの問題もあるんじゃないの？
>>799 >> ・変更内容がすぐに反映される
>Word や Excel で保存しても同じでは？
これ普通にファイル共有できるサーバ環境がないとできないよな。
イントラネットならいいけど、インターネット上に共有フォルダを設置するのは
正気の沙汰とは思えん。
Word/Excelのファイルをそのまま設置して、自由に編集できる環境って
そんなに安全で手軽にできるモノなの？
>Word や Excel で満足している人々に対しては、
>Web ベースに移行する必要ないかと。
Word/Excelが使えない環境でも使える。
ま、OOoなどフォーマット互換なオフィスソフトもあるから
必ずしもWebでないといけないということはないかもしれんが。
あー、携帯も含めるならWebベースでないと難しいかもね。
804 ：
784 ：04/02/22 22:44 ID:???
>>789 > 部署内で使う場合は、部署全員に使ってもらうよう仕向ける必要があるわけで、
>「こんなに簡単にWebページができるんですよ！！忙しいプロジェクトリーダーでも
> 議事録メール書き込む手間でまとまりますよ。みんなで編集できるし」
>と、初期コストが小さいことの方がメリットが大きいと思うんだけど。
それがどんなに面倒で不自然で無駄が多かったとしても、人は未知のツール
よりもそれまでのやりかたを好むものだと思います。一般論として。
「簡単ですよ」は興味をそそる呼び声ではないと思います。
> 「Wikiの理念」が堅苦しく感じるのはむしろWikiサイトの管理者でしょう。
良くわかりません。何故そう思われるのでしょう？
>>803 > イントラネットならいいけど、インターネット上に共有フォルダを設置するのは
インターネット上に共有フォルダを置かないといけないような組織って、
どのくらいの規模？常識で考えようよ。
> Word/Excelが使えない環境でも使える。
屁理屈ですか？
サーバ機やその他特殊な用途でない限り、大抵の場合 Windows に Word と Excel は
入ってますが。
> あー、携帯も含めるならWebベースでないと難しいかもね。
今の所、手頃に買える携帯の画面サイズって QVGA だよね？
そんな画面で情報を共有している人がいるか考えた上で発言して欲しいね。
実際の導入例としては会議の回数が減った。
>>806 「実際」どういう組織で、どういう会議を行っていて、どういう意見を述べていた
現状があったのか書かない限り「会議の回数が減った導入例」にはならないよな。
「管理者が他人の書き込みにマーク付け」も具体的に書かないとさっぱりだし。
>>805 >インターネット上に共有フォルダを置かないといけないような組織って、
>どのくらいの規模？常識で考えようよ。
元の文ではインターネット上に共有フォルダを置くことはないだろうという意味も含めたつもりだったけど、
文がおかしくて伝わらなかったか。スマン。
まぁ常識で考える範囲で共有フォルダ置くわけ無いよな。
ということは、Word/EcxelファイルをWikiのように自由に編集可能な状態にはできないと。
ファイルの交換が必要では、随時最新の内容を参照や編集はできない。
>サーバ機やその他特殊な用途でない限り、大抵の場合 Windows に Word と Excel は
>入ってますが。
Windowsならね。それでもごく一部互換オフィスソフトに置き換わってきてるけど。
あと、クラサバモデルは標準ではオフィスソフト入ってない。
オプションでライセンスを買うから結局一緒だけど。
Linuxとか他のOSはどうよ…と思ったが、そもそもそんなケースはレアだったな。
>今の所、手頃に買える携帯の画面サイズって QVGA だよね？
>そんな画面で情報を共有している人がいるか考えた上で発言して欲しいね。
まさかいないとでも？携帯とかPDAでも社内の情報共有するケースはあるよ。
てゆーかなんでそんなにムキになっているのかわからん。
誰か「Wikiは万能でWord/Excelなんぞいらん」とでも言ったっけ？そんなわけないよな。
809 ：
769 ：04/02/22 23:14 ID:???
>790
> ということは、Word/EcxelファイルをWikiのように自由に編集可能な状態にはできないと。
> ファイルの交換が必要では、随時最新の内容を参照や編集はできない。
>>787 からの流れで、どうしてそういう思考ができるのかが理解に苦しむのだが。
> Windowsならね。それでもごく一部互換オフィスソフトに置き換わってきてるけど。
ごく一部の話はしていませんが。
> オプションでライセンスを買うから結局一緒だけど。
そういうことなら、わざわざ書く必要ないよね？
> まさかいないとでも？携帯とかPDAでも社内の情報共有するケースはあるよ。
そういうケースはあるだろうね。
通信コストがかかる現状では、特殊なケースとは言わないのかい？
このスレ、現在、Ｗｉｋｉ、ＢＢＳ、ブログなどを比較して
812 ：
806 ：04/02/22 23:23 ID:???
>>807 導入したのは、YukiWiki2を改造したもの。
特に、最上段メニューの項目を減らした点は特筆しておく。
最初は、段落の書き方だけ覚えてもらうために、
リストやらリンクやらのルールを一切教えずに始めた。
次の段階としてブラケットネームを教えた――という具合。
組織に関する事項は、書けることと書けないことがある。
知りたいことを具体的に聞いてくれれば、答えられるもののみ答えるよ。
814 ：
769 ：04/02/22 23:49 ID:08sECAcN
>791-
>Word や Excel が全てだと思っている人に対しては、
>Web ページを作る必要なんかないかと。
そりゃそうだけどさ。むしろ、「議事録メール」て書いているように、
ホワイトボード的に電子メール（特にML）の肩代りに使うのが吉じゃない？
＃電子メールにわざわざWordの週報を添付する人間もいるけど……
あとは >798でも指摘されているように、インクリメンタルな内容に向いていると思う。
あと、以降でも指摘されているけど、HTTP/HTTPSでテキストを使っている
ということで、利便性／セキュリティが随分向上していると思う。
>799
>全ての Wiki が履歴を持っているわけではないんだよね。
Wiki本家で
http://c2.com/cgi/wiki 「ミスっても過去の履歴があるからすぐ直せる。気にせずどんどん編集しろ」
といっているように、過去の変更履歴はWikiの必須機能だと思う。
>800
禿同。
>802
UIは非常に重要。ブラウザのエディタがもっとよければなぁ。Javaで実装するしか
ないのかなぁ……
815 ：
769 ：04/02/22 23:50 ID:???
>804
>812
>>814-815 > UIは非常に重要。ブラウザのエディタがもっとよければなぁ。Javaで実装するしか
ないのかなぁ……
ブラウザに何を求めているのかと。
> ユーザーの底辺に合わせる形で、機能を制限していかなくてはならないから。
> ＃底辺といっても、コンテンツ作成では非常に重要な役割を果たしたりしますので
「コンテンツ作成では非常に重要な役割を果たしたりする」ユーザを
「底辺」と言えるセンスって素敵だと思う。
その思考で、何か新製品を金が絡む市場に出してみてくれよ。
> 多分、随分と良くなると思う。文書（というか書籍）がどのような構造に
> なっているかがわかるようになるから、文書作成の参考になるよ。
> 文章表現の引出しも増えるし。
Word と Excel を組み合わせる使い方を教えても、実際には
昔のワープロ専用機で文章を書くように Excel でダラダラと書く人がいるよね。
書籍の構造なんか理解したところで Excel をワープロ専用機として使う事と
似たような結果になるのではないかな？
820 ：
812 ：04/02/23 01:14 ID:???
2chでは、組織を特定できるような事項は答えられないということ。
それが不満なら、仕方ないよ
>>816 前にも同様のレスがあったけど、ツールの向き・不向きは要検討。
うちでは、部門内で決議すべき事項をWiki（部門内限定公開）に挙げ、
既決は静的なHTMLファイルに変換（Perlスクリプトで自動化）する方式だったよ。
資料としてのスプレッドシート等はリンクでダウンロードという形にしておいて、
静的なコンテンツに変換する際に、画像に落とし込む形式。
静的なファイルからなるサイトは他の部署にも公開する方針で運用しますた。
特に、Wikiに慣れていない人は、検索を使いこなせなかったりするので、
従来の階層型構造のサイトの方が解りやすいみたい。
メールでのやりとりをWikiに置き換えるのもできなくはないでしょうけど、
むしろ816の案件ではアップロードの面でFTPとの連携がネックになるかも。
HTTP経由のアップローダかファイル共有サーバとシームレスに繋がればよさそう。
821 ：
nobodyさん ：04/02/23 01:15 ID:2clWlbXi
情報の出し惜しみｳｾﾞｰ
822 ：
769 ：04/02/23 01:18 ID:???
>817
>「底辺」と言えるセンスって素敵だと思う。
ああ、視点の説明が抜けていたね。多角形をある方向から見たら、他の
ある部分は底辺になったりする、つうこと。
「デザインテクニック／プログラム（？）力」という頂点から見た場合の底辺
ですな。ただ、その三角形をひっくり返して「コンテンツに対する知識」とかの
頂点から見た場合は、底辺が頂点に近かったりするわけだけどね。
>818
>
>>817 >>ブラウザに何を求めているのかと
>こんなの。HTMLArena
>
http://kengo.preston-net.com/archives/001158.shtml 方向／目的は違うけど、そんな感じかな。これで論理構造記述に特化した
ようなのが欲しいなぁ。
824 ：
816 ：04/02/23 01:31 ID:???
>820
Google って、そんなに重要だっけ？
826 ：
769 ：04/02/23 01:38 ID:???
>823
828 ：
816 ：04/02/23 01:43 ID:???
>825
829 ：
812 ：04/02/23 01:48 ID:???
>>824 他部署絡みの案件もWikiを考えましたが、
慣れてもらうまでの教育コストが馬鹿にならないと思い、やめました。
Wikiはまだマイナーなので、部署ごとに質問に答えられる人材を置けなかったのです。
そういう観点から、あまり高機能なものは避けるという考え方もあります。
こんなんヘルプ見たら、中学生でもすぐ使えそうやけど・・・
あ、導入時の話ね>830
>>830 人は自分が理解している物は過小評価する。
そして、自分が理解していない物は過大評価する。
それを知ってから、人をバカにするのはやめた。
833 ：
816 ：04/02/23 02:13 ID:???
>830
834 ：
816 ：04/02/23 02:20 ID:???
ちょっと補足です。
100人のうち1人がわからないなら別に労力はないが、
836 ：
812 ：04/02/23 02:38 ID:???
>>830 はおれでした。
人数の問題ももちろんあるけど、部署によっては上司を説得するとか、
人あたりのよい教育係を選ぶとか、本質的でない問題もあったりします。
そういった外堀を埋める作業も馬鹿にならないのです。
まず自分の部署で実績を作って、段階的に他部署と連携をとるのも悪くないはずです。
837 ：
812 ：04/02/23 02:50 ID:???
なんなんだ、この流れは
CVS ベースで日本語リンクの貼れるものを探しています。
CVS ベースの Wikiシステムって BitChannel (
>>583 )
しかないんでしょうか？
840 ：
830 ：04/02/23 09:23 ID:???
このスレの人は簡単なものをわざと難しくしたいようにしか見えへんな。
841 ：
830 ：04/02/23 09:32 ID:???
ちなみに俺が社内に導入したときは、
>>841 勉強になります。よろしければ、もうすこし詳しく教えてください。・社内情報は、Wiki導入以前はどういう形で共有されていたのですか？・情報の移行は830さんが一人でやられたのでしょうか？またそれにかかった コストはどれぐらいでしょうか？
> 使えないと仕事にならないから、
なんか、性格の問題もあるような気がしてきた。
「Wikiを使えないと仕事にならない」ような状況に追い込むのは
wikiスレの話題を整理したwikiが欲しくなってきたよ(苦笑)
>840
848 ：
126 ：04/02/23 15:24 ID:???
>>847 理解する能力の話であって、そんなPC全般の話持ってこられても困る。
>849
意味わからんから無視しとく。
こんだけレスが進んでると、読む気しねぇなぁ…
ついでに書く気も失っていただけるとありがたい。
>851
>>855 え、マジで？マジでわからんの？え？ちょっと、え？マジで？ﾁｮｳｳｹﾙﾝﾀﾞｹﾄﾞｰ
857 ：
nobodyさん ：04/02/23 21:19 ID:2clWlbXi
はいはいよかったね。
858 ：
nobodyさん ：04/02/23 23:49 ID:cwDUcHbI
859 ：
858 ：04/02/23 23:51 ID:???
860 ：
816 ：04/02/24 00:55 ID:???
>840
・・・(;´Д`)
>>806 Notesで情報共有用のDB作ってそこの文書の更新権限を部署の全員に
渡すのとどっちが運用楽？
昔Notes使ってた感じではWikiよりよっぽど楽なんだけど。
部署内でNotes使っているような環境の整った場所ではWikiにこだわる
理由がなさそうな気がしちゃうんだが。
試しに動かそうと思ったってローカルにDB作るだけで済むよね？
Wikiではそうは行かない。
そんなことを考えてみると、Emacsで使えるhownみたいに、クライアント限定の
ツールのほうがWikiらしいのかなぁとか感じる。
>>816 >>854 の言うようにBBS＋uploaderか、WebDAVみたいなのがいいんじゃない？
漏れの考えるWikiのファイルサーバと比較したメリット
・エクスプローラに比べてブラウザのほうがアクセスしやすい（気がする）
・InterWikiのおかげでWikiが乱立しててもクリックひとつで情報に行き着く
・ブラウザさえ開いておけばWordなんかよりさくっと情報が得られる
・（たいていは）ファイルの検索よりもページの検索のほうが速い
>>840 今の職場では、我々下っ端が特定のアプリに依存しない方向で考えていたところ、
それで大丈夫なのかと懐疑的なメンバーが結構いた。
うち特有の問題かもしれないけど、ブランド信仰の強い上司や会議好きの古株がいまだに存在するので、
導入にはそれなりに気を遣ったということ。
結局、時間をかけて覚えてもらう過程で上司にも使えることを納得してもらえたから、
うちのようなところでも導入できた。
要は、職場の環境に合わせて、導入計画が必要になる場合もあるってこと。
>>862 Notesの話を出したのは、以前の職場での経験談と比較しての話。
今の職場には、Notesは導入されていなかった。
Notesで不満なく回るのなら、無理してWikiに移行する必要もないんじゃない。
BBSについては、後日文書化するのがつらいので、連絡用と割り切った方がよいかも。
>>862 なんでもかんでもWikiってのは無理があるよね。
結局それぞれ適切なツールを見繕って使っていくしかない。
ローカルにWiki動かしてメモ用にするってのは俺も個人的にやってるけど、
便利に思えたり不便に思えたり、いろいろだな。
ベタテキストのメモ作ってた時期もあったけど、文書構造を表しやすい分Wikiの方が整理しやすい。
箇条書きとか「・」のかわりに「-」とかで済むからね。
ただ、インターフェースが基本的にブラウザのフォームってところがどうも使いにくい。
Wiki専用のエディタでも作ったろかと思っちゃうくらい。
追加。
NotesとWikiのどちらを選択するかは、最終的な出力に何を考えているかが大きいかも。
>>820 に書いたけど、最終的にHTMLにまとめる方針だったので、Wikiが選択肢として残った。
印刷文書を想定するなら、Notesの方が向いているだろうね。
Wiki なんか ｽﾃ ということで ﾌｧｲﾅﾙｼｰｻｰ?
wikiの良さはダーっと書けば済むこと。
869 ：
nobodyさん ：04/02/24 10:42 ID:vV8Z/thu
>>868 いや、だから、866に示したように、
>>820 を読んでくれよ。
ブラッシュアップ後の文書をどうするかという話なんだけど。
あと、念のために書いとくけど、一般論として述べているわけではなくて、
あくまで実例の一つに過ぎないわけで、各人の所属組織に応じて、
Wikiを導入するメリット・デメリットや使い方が異なってくるはずなので、
その辺は臨機応変に読み替えておくれ。
871 ：
640 ：04/02/24 12:28 ID:+QrsWOJz
ユーザー教育の話がでてるみたいっすね。
Wiki初心者数人と話しして感じた事は「文書構造」なるものが理解され
にくいって事でした。 具体的にはブロック要素だとかインライン要素だ
とか。 これ、HTML的な表現を知らない人には難しいと思うんですよ。
多くの人の理解は「こう書くとこう見える」程度で 「文書の構造なんて
見た目でわかるじゃん」と思ってるのかなーと漠然と感じています。
また手前味噌なんですが、GrooveWiki では <p>のような構造表現は
とっぱらってみました。 どうしても欲しければHTMLでどうぞといった
感じで。 (文法ではなく)意味としてのHTMLという観点からは邪道な
感じがするのは否めませんが、どうでしょう？
872 ：
640 ：04/02/24 12:49 ID:???
Wikiっていうと、どーも、みんなイメージが違うようなので、これからは
文書構造というか、考えをある程度論理的単位に分割し、並べる、ということ
ブロック要素とかインライン要素ってHTMLが作り出した概念ですよね。
>>871 ブロック要素とかインライン要素って文書構造？
文書構造ってのはもうちょっと意味づけされてそうな印象なんだけど。
章タイトルとか本文とか。
文書構造を構成する要素（ブロックだのインラインだの）を理解しろってんなら
>>874 のいうようにHTMLから出てきた概念なんだからそっちから教えたほうが
いいかもね。
でも、けっきょく
>>873 の言うように使う人によって構造なんてすぐ壊される。
やっぱりツールとして適当においておいて（自分が正しいと思う構造を）ひたすら
書き続けるのが教育の近道だと思うんだけどな。
現状からの変化は嫌がっても、新しいものへは手本探したがるだろうし。
で、DocBook を勉強すると「文章表現の引出し」が「増える」んですかね？
文書構造の考え方って、是非小学校で教えてほしいなぁ……。
>>877 「文書構造」は具体的には何を表しているのでしょう？
HTML ベースとか、何かの規格に依存したの構造ならいらないよね。
>878
HTMLもマークアップ言語。
Wiki に文書構造もへったくれもない気がするが...
段段国語のお勉強の話になりそうだ。
883 ：
640 ：04/02/25 08:38 ID:AvDTPXRh
ペーパーメディアの場合、良くも悪くも「場所」と「装飾」で、それがどういう意味
をなすのか理解できてしまうってのがありますよね。 だから Wordみたいなソフ
トでも「見出し１」を選択してからタイトルを書く奴はほとんどいなくて、太字＋
フォントサイズを変更…で済ませるんだと思います。
そう考えると、それで意味が通じるなら、場合よっては安くない教育コスト
を払ってでも Wiki 上で意味を定義させる価値があるのだろうか?とも考え
てしまいます。 小中学校で論理的な作文を教えるのは大賛成ですが
「マークアップって何？」ってレベルの人(←ほとんどの人)に本当のホワイ
トボードのように使ってもらうには、教育コストを下げる事は重要かなと。
>>875 >ブロック要素とかインライン要素って文書構造？
初級者には理解が難しいってのは、もっと低レベルの概念の事でした。
言葉足らずですません。 でも、dt/dd/dl要素みたいな地味でインパクトの
薄いやつも覚えてくれない(=理解されない)んすよ。
# hotspot って便利だなー
>>883 自分や身内だけなら<p>なしでもよいかもしれないけど、
インターネットの場合は利用者が特定できないからやっぱりまずいと思うな。
<p>なんて空行を挟むだけで日本語メールと同じだから、教育コストが高いとも思えないし。
紙の文書とHTMLを同列に論じてしまうのは、物理マークアッパーが常に陥る罠で、
HTMLならではの使いやすさを追及すべきだと思う。
まず理念的なものを再考してみたら、どうでしょう。
ttp://www.kanzaki.com/docs/html/htminfo10.html辺りを参考に 。
Wikiであっても、書き込みに比べて、ただの閲覧の方が数としては多いはずだし、
ブラウザのエラー訂正は実装依存なので、「不思議マークアップ」文書を読めないものがあってもおかしくはないわけで。
逆に、WikiのHTML変換が問題なければ、たとえ段落をリストとしてマーク付けしたとしても、
HTMLの文法エラーではないから、ほとんどの環境では読めるはず。
そんなのは、小人が修正するという手もあるし。
初心者 = 物理マークアッパー
>>884 「思える」「思えない」「はず」等、推測や憶測だらけの文章は、
ご自分の日記に書かれたらどうですかね。見苦しいですよ。
>>896 自分の意見を言う流れのところでそんな因縁吹っかけて何をしたいのかとりあえず説明が欲しいです。
文書の論理的な構造を理解できない人でも、Wikiは使える。
>>887 根拠の無い意見なら誰でも言えるわけだが。
>>868 それならＮｏｔｅｓ使え。
そっちの方がよっぽどいい。
892 ：
884 ：04/02/25 23:01 ID:???
>>886 個々のブラウザに依存するバグや文法エラー訂正については「はず」としか言えない。
そもそも、現存するブラウザだけ視野に入れればよいわけでもないし。
だからこそW3Cが勧告を出しているってことを理解できているか？
>>888 Blogはそういう流れ。
Wikiでも、PukiWikiだけではなく、他のWiki Cloneを正しいHTMLを吐くように
改造するケースが徐々に出てきている。
だから、水を差して欲しくはないんだよね。
894 ：
888 ：04/02/26 00:22 ID:???
>>884 水を差してるように見えたらごめんなさい。
正しいHTMLを吐くというのは良いことだと思いますが、
もともと
>>883 の主張はそこではなく、初心者に論理構造
教えるのって難しいよね、という話だと思ったので。
HTML 等における論理構造なんか気にしてる奴に限って、
>>895 さすが自分の事は良く分かっていらっしゃる
897 ：
884 ：04/02/26 00:52 ID:???
>>894 ごめん、書き方が悪かった。
自動化や省力化できるところをツールに任せるという点では、同意しているのね。
「水を差す」というのは、884に向けたのではなくて、
<p>を出力しない等の（時代に逆行した）方針に対して言いたかったのです。
Wikiにしろ、Blogにしろ、ツールを使えるものにしようと努力している動きがあるのだから、
安易な方向に逃げないで欲しいなあということ。
論理構造を教えるのが難しいのなら、
HTMLを出力する前にツール側で適切に補う方法を考えるのが本筋。
皮肉の応酬ばかりして、おまえらは平安時代の貴族かw
論理構造なんか考えた所で、<p> で「改行」しようが <br> で改行しようが、
では関係ない私が違う話をして水を差そう。
>>899 その場合、出力から取り除くべきは<p>ではなく、<br>だろう。
ノートを読むのは人間だから、人間が誤解しない程度に好きにすればよい。
HTMLを読んで解釈するのはユーザエージェントだから、
UAが誤解しないようにする必要がある。
>>899 確かに大切なのは情報そのものなんだけど、だらだらと長文を隙間無く並べるよりは、
段落とか改行とか、ある程度整理されている方が読みやすいんじゃないかと。
読みやすくすることが情報の価値を高めるのかよ、と突っ込まれそうだけど、
読みにくくて活用しづらい情報よりはいいんじゃないかな。
>>900 >著述作業の簡易さと情報の統合とを両立する点が、Wikiのコアな特徴の
>一つであると実感した。
確かに。
比較的容易な記述でハイパーリンクによる関連づけをしやすいのも便利。
いちいちキーワードをブラケットで囲むのは面倒だけど、キーワードテーブル作っておけば
自動的にハイパーリンクになるWikiを使えば楽にできるね。
>>900 禿同
見ながら、考えながら、修正しながら、また見ることができるのは嬉すぃ。
無限の広がりをもつホワイトボードみたいに。
正直、HTML はめんどい。考えることに集中したい。
直観的な文法で簡単なこと（箇条書とかセクションとか）が実現できれば十分だし。
ただ、Wiki は仕様もバラバラだし、 Wiki で閉じてる感じも強く、
他の処理系との連携がめんどうなのがイマイチかなぁ...
904 ：
640 ：04/02/26 08:01 ID:n5Nb41OP
<p>に関しては結構悩んだんですよ。 というのも、初心者にPukiWiki使わせて
観察したんです。 そしたら、デザインの都合でいろいろな事するんですよ。
例えば、一行毎に空行を入れたり、見出しと文章の間隔が気に入らないから
改行とか。 さらには、「段落」と言えるかどうか微妙な文字列の塊があったり。
結果、#br だらけになってしまいました。 ついでに「めんどくさくて、直感的じゃ
ない」って言われました。 それでも無理して<p>でくくると、それこそ不思議マ
ークアップになってしまう可能性があります。(見た目は margin と padding を
0px にする事により同じにする事ができますが)
多くの場合、空行を区切りとして<p>でくくるというのは正しい選択でしょうし
折角CSSが使えるWikiEngineを開発しているなら、一行毎に改行なぞやめ
させて、CSSで行間設定するように教育しろって意見も至極まっとうだと思い
ますが、ユーザー的には「そんなんどうでもいいからさ、もっと簡単にしてよ」
で終わってしまうんです。 つまり、内部構造などどうでもよくて(っていうか知
らない)、どう見えるかが重要だと。 そして、<p>でくくる事による、具体的な
メリットを示す事が私にはできませんでした。
HTMLへの理解は、それなりにあるつもりですが、構造の厳密さとユーザーの
視点、どちらを優先すべきかと言えば、私はユーザーの方を選びました。
もちろん、PukiWikiみたいな「正しさ」は素晴らしいと思いますが、ちょっと
ターゲットが違うんでしょうね。
>>884 ところで、文法エラーってなんの事ですか？ ブラウザのエラー訂正？
タグ開きっぱなしとかって話なら、それなりに対策はしてありますし、LINT
的にはHTML4.0 Strict に準拠させてます。
>>904 PukiWikiを使わせたら、面倒で直感的でない、と言われた、と。
で、640の作ったWikiへの反応は？
>>904 初心者がこだわりたがったのは行間だけ？
であればなんとなく見た目の行間いじれるだけにしたらよかったのではとちょっと思う。
（ユーザごとにスタイル設定できるようにして行間のCSS吐くだけなら単純そう）
>>900 こういう成功事例は参考になるね。
ファイルサーバを（Windowsで）作ったうえで、UNCでのリンクも貼れるようにしとくと
かなり便利になりそうな気がした。
最近wikiを知ったのだが、改行に関しては気になった。
ブラウザのデフォルトが行間狭すぎるというのが原因だよね。
空の改行を入れるのは、Web上で読む文書が流し読みされがちであるという点と関係する
910 ：
640 ：04/02/27 08:01 ID:???
>>905 >>907 が言うように <br> を自動挿入にしたり、半角スペースを複数入れても
その数だけ が入るなど、メモ帳的アナロジーを導入したお蔭で、それ
なりに好評いただきました。 PukiWikiに比べて、明らかに機能は劣っています
が、まだ彼らはそれを使いこなせるレベルにないので気にならないようです。
>>906 ,908
それが、どうも問題は行間だけではないようなんですよ。 それに、私の見た
ケースでは、一行開けて書いてある部分は、そのページの一部だけで、具
体的に言うと、その部分は「詩」でした。 他には、なんというか「侍魂」的な
レイアウトって言ったら通じるでしょうか。 不定の間隔があるような。
総じて言うとデザインの都合って奴です。 やっぱりEnter押してるのに改行
されないってのが「変だ」と思うところなんじゃないでしょうか。
それらは、本来CSSで処理すべき問題ですが、自動化はなかなか難しそ
うな気がします。 かといって、ユーザーにいちいち入力させるのは嫌がる
と思うんですよ。 初めての人への教育も大変そうですしね。
>>900 Wikiを紹介するのに最適な事例っすね。 すばらしー。
改行に関しては整形済みテキスト (多くのWikiでは行頭スペース?) を使うべきなのだろうが、
>>910 ああ。自分にもよく分かるよそれ。
例えばHTMLなら<P>だけでは満足できなくて、途中<BR>入れて
間空けたくもなるのよね。
また空白もそう。適宜スペース入れて間空けたくなる。
これらはパターンが決まってないのでCSSではどうもうまくな
いのよね。
なんてゆーか。オーバーな話だけど、WikiにQuarkみたいなモ
ノを求めているような気がしないでもない。最終的にHTMLで
出るから色々制限あるのにね。
結局自分がｺｿ-ﾘ使ってるWikiは、デフォルトで全体が<PRE>で
囲まれるようにしてしまった。
掲示板の延長で考える人が多いのかなあ。
理解できないというより、理解するのがめんどくさい。
>>912 デフォルトで全部<pre>にしてしまうと、不都合の方が多くない？
Wikiってそもそも何だろう？という疑問の元にこのサイト見たけど
>>916 掲示板は原則として時系列順に追記する。
何かに対して反応することになるが、書かれたものを訂正することは（多くの場合）しない。
Wikiはページ全体を複数人で作る。
書き込まれたものをところかまわず修正できる。
UIはこの際関係ないね。
>>912 >なんてゆーか。オーバーな話だけど、WikiにQuarkみたいなモ
>ノを求めているような気がしないでもない。最終的にHTMLで
>出るから色々制限あるのにね。
こういう人たちはHTMLにもQuark的なものを求めてるよ、きっと。
WYSIWYGってのはやっぱり直感的なんだよね。
>>910 > 具体的に言うと、その部分は「詩」でした。
詩は散文と組版ルールが違うじゃん。
一緒に扱おうとするのが無理。
詩文Wiki？
>>915 preモードと普通のを切替えられたらいいね。
スラッシュドットの投稿欄みたく「ホントのテキスト形式」も
あるといいな。
>>921 YukiWiki なら %infobase に情報を持たせるようにすればカンタンにできるやん。
漏れは Wiki なんか使う気はないから patch 書くつもりはないけど。
923 ：
nobodyさん ：04/02/29 19:21 ID:MvJ1SEzu
関関同立とかを見難くしてるやつって
924 ：
nobodyさん ：04/03/01 08:12 ID:uBxLe30P
関関同立って何?
関西大学、関西学院大学、同志社大学、立命館大学。
いや、一応レベル順じゃなかったか？
関西ローカルの大学にレベル順もなにもないっしょｗ
東京の私立でも慶応早稲田以外は関東ローカルだからね。
リスト構造などの見栄えをページによって変えたいのですが、
いや、reimyおじさんに聞いても無理でしょ
強制的に同一レイアウトになることが利点でもあり欠点でもある。
携帯からの閲覧に適したwikiってないですかね？
>>934 PukiWikiは携帯対応のはずだ
実際に見た事はねぇが
>>935 うちで動かしてるのを他人の携帯でちらっと見てみたことがある。
なかなか良いよ。
メニュー (編集とか) は英語で表示面積削減してるんだったかな?
ていうか、携帯からもちゃんと編集できるように (たぶん) してるのが
スゴそうだった。
編集しないけどね。
937 ：
nobodyさん ：04/03/03 19:30 ID:fiYuiU04
>>934 CSS弄ったところで、携帯用になるとは思えないのは気のせい？
939 ：
934 ：04/03/03 21:47 ID:???
レスありがとう
>>935-936 pukiはなんとかなりそうな気はするんですが
ブラウザのＵＡを偽装して閲覧してみたんだけど
ＵＡがうまく解釈されてないような気がするんですがどうでしょう？
// 携帯端末
$agents = array(
array('name'=>'jphone','pattern'=>'#^J-PHONE.+(Profile/)#'),
array('name'=>'jphone','pattern'=>'#^J-PHONE#'),
array('name'=>'i_mode','pattern'=>'#DoCoMo/(1\.0)/(?:[^/]+/c([0-9]+))?#'),
array('name'=>'i_mode','pattern'=>'#DoCoMo/(2\.0) [^(]+\(c([0-9]+)#'),
array('name'=>'i_mode','pattern'=>'#DDIPOCKET;JRC/[^/]+/(1\.0)/0100/c([0-9]+)#'),
);
この部分だと思うんですが全キャリアうまく解釈されるにはどうしたらよいのでしょう。。
auとかはダメポなんですかね。
>>937 liteとかありますね。今度試してみます。
>>938 ｽﾏｿ..関係ないね(恥
AUはHDMLじゃないといかんのじゃなかったっけか?
古いな、おい。
うちのダサい A5401CA 君なんかは普通に html 解釈してくれますが。
おー奇遇。A5401CAです。Googleとか文字化けします。utf-8はダメ？
944 ：
942 ：04/03/04 00:58 ID:???
そなんすか。
「でつ」って言い方気持ち悪いって周りの人に言われない？
でつ <- スヌーピー
てかリアルでそうそう言う人もおらんだろうに。
でつ。
スヌーピーよりもウッドストック君に見えるような気も。
951 ：
944 ：04/03/04 02:38 ID:???
うれしいでつ。
でつ
俺には おむかえでごんす＠手塚キャラ に見える＞でつ
そろそろ次スレお願いします。
この進み方の差の激しさが人口の少なさを暗示していてやな感じですね。
957 ：
nobodyさん ：04/03/06 11:23 ID:nLQ8peOe
ROM含めて80人くらいか...
質問ですが、
PukiWiki（にかぎらず、本家があるWiki)に関する質問は、ご本家にてお願いします。
質問です。
別にFSWiKiでなくてもいいんですよ。CGIWrapで使える子WiKi機能がるものなら何でも。
いいwikiが見つからなければ
966 ：
nobodyさん ：04/03/13 18:23 ID:HB2GuAbW
967 ：
http://chbox.com/ ：04/03/13 23:05 ID:sltX1YFT
「質問がだめ」の「だめ」が何に係るのかは置いといて。
970 ：
http://ruitomo.com/~gulab/s.cgi?k=ウィキ&o=r ：04/03/16 18:43 ID:ZZVmlIUI
あれ？次スレはまだっすか？
972 ：
nobodyさん ：04/03/19 14:39 ID:AjYkjR0J
973 ：
nobodyさん ：04/03/19 14:46 ID:EZrO0R0f
php+mysql Wikiきぼんぬ
いーから早く次スレ
