NoGood曰く、"Perl で書かれた軽量志向の Wiki、wifky! のバージョン 1.0.0 が公開され、ついいに正式リリースとなった(ダウンロードはこちらから)。wifky の最大の特徴は“1ファイルのみで完結し、外部ライブラリを必要としない”という点であり、機能の拡張等はプラグインで導入するスタイルである。タレコみ人も自らのサイトで利用させていただいており、日頃からその簡にして要を為す造りには必要十分の感があり、作者の hayamatta 氏には感謝と賛辞を惜しまない。"
感謝。 (スコア:3, 参考になる)
でも、作者しんじゃったんですか。。。 残念。:(
--PS. 昔あった4行 Wiki [c2.com]を思いだしました。
こんなの。Re:感謝。 (スコア:0)
意味が解らないのですが、、？
Re:感謝。 (スコア:1)
こういう裏活動に反応しているという解説はやぼ？
# 広い意味で本人は死んだ気がする。
Re:感謝。 (スコア:0)
higonの言いたかったことはたぶん、タレコミ文中の、
の が orzストイック (スコア:2, 参考になる)
のように自分の長所をしっかりとらえて、
あえてストイックに進むことのできる人はエライと思います。
qmail も、つい最近まではエライと思っていました。
Re:ストイック (スコア:1)
Re:ストイック (スコア:0)
Re:ストイック (スコア:1, 参考になる)
integer overflow などの問題ならちらほらと。
ulimit しろ、とか言ってるらしいけど。
読んでみたけども (スコア:0)
一見よさげだけど (スコア:2, 参考になる)
プラグインで何とかなるかも知れないけど、Wikiの基本機能ですから
ほしいなぁと思いました。
Re:一見よさげだけど (スコア:4, すばらしい洞察)
とのことだそうです。
このような、シンプルさを売りにしてるソフトの場合、
「このソフトは非常に良い。ただひとつだけ欲を言えば、
××機能さえ追加すれば完璧になるのに」といった声を、
開発者がいかにはねのけるかが、成否の鍵を握って
いると言えます。
Re:一見よさげだけど (スコア:1)
たとえばPalmが成功したのも、そういう哲学をもって設計をしたためですし。
ただ、やはりその機能は欲しかった! と私は思いましたし
この件がそうだとはいいませんが、Simple is Bestを言い訳にして
必要な機能を実装しないケースはあります。
#経験者談。
Re:一見よさげだけど (スコア:0)
見る人によって「あの機能さえあれば」の部分は違うし、それぞれを満たしていけばさらにそれに付帯する「あれさえあれば」が無限に広がって必然的に重く複雑になる。
昔、お菓子を食べていたときに、ばあちゃんに「あと１つだけ食べたいな、と思ったときにやめなさい」と言われた。しみじみ。
------------------------------------------
Que du lemero De ra Soldene! 思考は嗜好の試行なり
LuCanにいるのでAC
Re:一見よさげだけど (スコア:2, 参考になる)
#らしいです。え、違うって？
Re:一見よさげだけど (スコア:0)
Re:一見よさげだけど (スコア:4, 参考になる)
44のWikiクローンのリストで、履歴の機能(Page History)の項目を確認したところ、
41件が「Yes」(つまり機能あり)で、1件がOptional(オプション)、2件が「No」(機能なし)でした。
履歴機能がないものは、TiddlyWiki と MicKI でした。
このリストにないものもあるかと思いますが、一応の目安にはなるかと思います。
このリストに限っていえば、9割の実装率なわけで、これをもって「基本機能」と
いえないことはないと思います。
反論がありましたら、何か具体的な数字をあげてみてください。
Re:一見よさげだけど (スコア:3, 興味深い)
そのWikiMatrixは、プラグインなども含めての実装を検証しています。また、取り上げられているWikiも、それほど多くありません。そもそも、Wiki Matrixのねらいは、大規模Wiki中心です。
で、翻って日本のYukiwiki派生Wikiって、履歴機能は基本機能ではなく、オプション扱いなんですよ。それも自動ではなく、手動で。
なので、「履歴保存機能が基本機能である」というのは、どういうWikiを念頭においてそうおもったのかなぁ、と。今、「Wiki」って言葉から連想されるWikiは、どのようなWikiなのか、ってのに興味があります。
Re:一見よさげだけど (スコア:2, 参考になる)
あるでしょう。いきなり先の自分の投稿を否定するような話ですが、
まぁ実際純粋な意味での基本機能となるとこの点に絞れると思います。
そしてその上で、「編集」を円滑に行うための様々なサポート機能のうち、
履歴を保持しておく機能はごく一般的に用意されているものだと
思います。そういう意味で広義の「基本機能」だと思っていますし
先にあげたWikiMatrixで紹介されているWikiクローンではほとんどの
もので実装されているようです。
で、Yukiwiki派生タイプは、日本発の wiki クローンリスト [yamdas.org]
およびその２ [yamdas.org]に載っているものを
確認すると、(KbWikiはちょっと開発状況分からなかったですが)
どれも履歴管理機能があるようです。
その機能をオプション扱いでしかも手動でセットするタイプのものが
どれかは私には分かりませんでした。
と、ここまで書いて、もしかしてと思いましたが、自分は
「一つ一つのページの更新の履歴(と差分管理)」という意味で履歴機能を
取りざたしてきましたが、そちらは「最近更新されたページの一覧を
提供する機能」について書かれていますかね?
#しかしどんどんオフトピ化しているような気が。
Re:一見よさげだけど (スコア:1)
言ってみれば、オンライン編集はWikiのアイデンティティに関わる機能で、履歴管理は基礎的機能であるということでしょうかね。
# テレビはカラーで表示できる、とか。
That is not dead which can eternal lie,
And with strange æons, even death may die.
Re:一見よさげだけど (スコア:1)
> プラグインなども含めての実装を検証しています
各プロジェクトのメンバーが(利用者が簡便に
比較できるよう)他の実装の書き方とズレがない様に
工夫しながら項目を書いているだけで、
特別な検証はありません。
WikiMatrix自体の公平性、公共性、網羅性、正確さ
などは各自で各プロダクトを確認して初めて
磨かれます。何かあればforumなどにツッコミを
入れて下さい。
> 取り上げられているWikiも、それほど多くあり
> ません。
そう爆発的には増えないと思います。
現状はWiki専門の比較システムとして項目が
洗練されきっているわけでもないため、
一件追加するだけでも色々例外事項や注文が
発生して、システム管理の人は何かと
大変でしょう。
(例えばPukiWikiはXHTML 1.1を含めいくつかの
項目を要求した)
> Wiki Matrixのねらいは、大規模Wiki中心です。
そんな事はないでしょう。
WikiMatrixは元々DocWikiが、他のWikiと機能を
比較するために作ったWikiページが元になって
います。
http://wiki.splitbrain.org/wiki:compare
何をもって大規模とするか、という話もありますが
実際に掲載されているWikiを見回ってみて下さい。
> 連想されるWikiは、どのようなWikiなのか
日本ではYukiWiki/PukiWiki型Wikiやそのクローン
が多いでしょうね。
それらのユーザーをターゲットにした国内の
ブログサービスやWikiサービスが状況をさらに
後押ししていると思います。
Re:一見よさげだけど (スコア:0)
Re:一見よさげだけど (スコア:0)
基本的に日本産のWikiって、ファイルベース、履歴なしが主流なんです。こういうところ [que.ne.jp]とか辿ってみると良いです。
他のWikiが稼動しているのを見ていたら、教えてくれますか?
Re:一見よさげだけど (スコア:1)
多いですし、私の知らないものもあります。
日本産のものはだいたい網羅されているのではないでしょうか。
<a href="http://ishii.mydns.jp/modules/bwiki/index.php?B-Wiki">BWiki</a>は載ってないですが、PukiwikiをXOOPSのモジュールにしたものですが、
ほぼそれだけなので載ってないのかもしれません。
あとあえて言うと、Livedoor Wikiは載ってないようですね。
オープンソースでないから載ってないだけですかね。
日本産のWikiと限って言えば、確かにDBを使用しないでファイルベースで
データを保存しているものが多いですね。これがDBが使えない開発者が
多いのか、単に規模の問題でファイルベースで十分だからDBは使わない
という話なのか、私は多分後者だとは思いますが。
で、履歴機能の件は、このリストでは正直全部をすぐには確認できないので
(だからすぐに確認できて説得力ありそうなWikiMatrixを引き合いに
出しましたが)、数字を出して断言はできませんが、小規模な
プロジェクトだと実装されていないのも多いかも知れません。
そうなると私の主張は半日経たずして崩壊します。
結論は、私の要求する機能は、どちらかというと大規模プロジェクトでは
機能が豊富だからほぼ実装されているだろうけども、小規模なものだと
そうならないこともある、ということですかね。
でもって、大規模プロジェクトでの基準を、必ずしも小規模なもので
適用できるものでもないと。
Re:一見よさげだけど (スコア:0)
ことに気づく罠。
Re:一見よさげだけど (スコア:1)
1. 既存のWikiからその機構をはぎとっても
それはWikiとして動作します。
(設定で機能を無効にしても同様)
履歴機能はWikiのコンセプトとして必須ではないし、
それゆえに基本機能とは思われていないでしょう。
2. もう少し別の切り口から言うと、
Page History の実現手法は実装ごとに千差万別です。
(基礎概念、入れ物、データの格納方法、UIを含む
提供方法等)
Yes/No(など)の割合は傾向を読み取るには有効とは
思いますが、それ以上の何かではないでしょう。
Re:一見よさげだけど (スコア:0)
基本機能っておっしゃってますが、全てのクローンが実装していないという時点で「基本」じゃないと考えます。
Q.E.D.
Re:一見よさげだけど (スコア:0)
たとえ他の実装系のほとんどについている機能であっても、
開発者が、この機能はいらないと言えば、それはそういう意見なのですから、
どうしても受け入れられないとしても、意見の相違ということで
引き下がるしかないと思います。気に入らなければ別のを使えばいいし、
今回はオープンソース（修正BSDライセンス）なのですから、自分で改造して
使っても、forkしても全然かまわないのですし。
もちろん、開発者の主観が、世間からものすごくずれていて、その主観の
正当性をうまく説明することができなければ、誰も使ってくれないと
いうことになるでしょうが、それは開発者の自己責任です。
逆に言うと、世間の普通の考え方からずれている、新しい常識を
打ち立てたいと思ったり、打ち立てる必要に迫られたり、ということは、
オープンソースプロジェクトを立ち上げようとする動機のひとつだと
思いますよ。他と同じようなものを新たに作っても仕方がないですし。
Re:Good job! (スコア:0, オフトピック)
>＞とんちんかんを振りまく不思議さんですから。
>こんな素敵な敗北宣言を残していきましたよ。
それは私がWikiMatrixでの実装比較について書く前に投稿されてますので
私の投稿を受けての敗北宣言ではなく、ただの妄想でしょう。
Re:一見よさげだけど (スコア:0)
Re:一見よさげだけど (スコア:2, 興味深い)
「基本機能とは何か？」
という問いに対して、「全体の９割で実装されている機能は基本機能である」
と明言されているのは、少なくとも wiki を使っている感覚としては納得はできます。ただし、９割という数字に対して、別の AC は
「残り一割が実装していないんだから、基本機能ではないという」
お話をされていて、これはこれで、納得できる話ではあります。むしろ、基本機能の定義に関していえば、
「全てのcloneで実装されていないならば、それは基本機能ではない」
という定義の方がスマートです。そのACさんが、Q.E.D. と表現する気持も分かります。証明という意味では、けなされているそのACの方が、客観的で理にかなっています。ただ、それをして、Q.E.D. と表現するのが、子供じみているというか、反感を買うのはあたりまえで、そのおかげでスマートさが消えています。
ただ、定義としてスマートであるからと言って、現実に即しているか？というのは疑問があります。だから、この Q.E.D と書かれた AC はあまり支持されないわけです。
ともかく、９割も実装されているからそれは基本機能であるという表現をすると、その９割という数字の根拠が非常に主観的になります。つまり、８割ならばそれは基本機能なのか？じゃ、７割実装されていたらどうなのか？という、何割の実装が基本機能と認める境界であるか？という発想が欠如していて、根拠という意味では主観的に感じます。５割を越えたら基本機能なのか？その９割という数字が基本的能を満たす条件であるという証明・根拠が欲しいのですが、それは「９割も実装しているんだから、それがなきゃ基本機能じゃないだろう」というあくまで主観に基づいた判断なわけです。
でも、だからこそ、９割には納得しやすいんです。WIKIユーザーの民意を反映している。僕も９割も実装されている機能で、も身近で使っている WIKI でほとんど装備されているその機能は必須だと思いますし、「WIKI らしさ」の一つだと思います。
ただ、論拠とか論破とか証明とかいう言葉が飛び交うと、非常に安っぽいですし、とたんに嘘っぽくなります。
「９割も実装しているんだから、基本機能の一つなんじゃない？」
くらいの表現だと、たいへん納得できます。
でも、さきの、Q.E.D. 発言と同じく、正直「反論・・・」などと喧嘩腰な、無駄な一言のために、感情的になる人が多発するので、貴重なご意見を自ら汚していると思います。
ついでにいうならば、最初の Elbereth 氏のご意見に対して、ご意見をされた #900051 の意見は非常に落ち着いた、よいご意見だと思います。別に、Elbereth 氏の意見にいきなり反論をされたわけでもないし、つまらない突っ込みでもない。
「シンプルさを売りにしているソフトウエア開発で重要なこと」
「＊＊機能さえ・・・という意見をいかにはねのけるか」
という、シンプルさを売りにするソフトウエア開発の視点からたったいい意見だと思います。それほど喧嘩腰な言葉は言っていませんし、落ち着いていると思います。そして、例の Q.E.D. の人も、発言の仕方はともかく、「定義」するならば、一番スマートですし、現実に即した「まともな」ご意見ならば、Elbereth 氏のご意見はまとこにごもっともです。
Re:再命名:一見よさげだけど (スコア:0)
Elbereth 氏の意見は、データはきちんと引用していて、一般論として参考にはなるものだけど、それ以上ではなく、その解釈はむしろ私見であり、「周りが持ち上げるようには」論理的でも正しいわけでもない、ということでしょう。
# ここにかぎらず多くの彼のコメントはそうなっているし、別にそれはそれでいいですが。
Re:再命名:一見よさげだけど (スコア:1)
>参考にはなるものだけど、それ以上ではなく、その解釈はむしろ私見であり、
>「周りが持ち上げるようには」論理的でも正しいわけでもない、という
>ことでしょう。
実際それはその通りで、データを分析してそこから結論を導き出す
というよりは、自論を補強する材料として、適当にぐぐって拾ってきた
説得力ありそうなデータを提示している傾向が私にはあります。
まぁその自論がなるべく人の参考になればいいんですが、たまに
はずすこともありまして(たまに!?)。
1ファイルのみで完結 (スコア:1, 興味深い)
空目。(激しくおふとぴ) (スコア:1, おもしろおかしい)
配布ページが移転しました。 (スコア:1)
よろしくお願いいたします。
Re:恐くて使えない (スコア:0)
与太飛ばすだけの一行コメントなんて要らんから。
Re:恐くて使えない (スコア:2, 興味深い)
すげー怖いんだけどどうかな。
インデントぐらい統一して欲しいと思った。
てかこのファイルがボトルネックになって
折角のオブジェクトが死ぬのではと思えるのだが・・・
御指摘ありがとうございます→Re:恐くて使えない (スコア:4, 興味深い)
>> インデントぐらい統一して欲しいと思った。
統一はしていたつもりなのですが…。TABコード=8桁で編集したテキストであるため、インデントが乱れているように見えまたのでしょうか？それとも、出力 html の方でしょうか？(こちらは確かに汚い…)
>> てかこのファイルがボトルネックになって
どのファイルでしょうか？ mkdir されるディレクトリでしょうか？ あるいは、設定ファイルでしょうか？
mkdir は初回起動時に一回作成するのみです。設定ファイルは…確かに毎回読み込みますので、ボトルネックになりうるかもしません。よい解決法はありますでしょうか？
ディレクトリへの書き込み属性については
・CGI実行ユーザとファイルを配置する際の FTP ユーザとの関係が、サーバ環境によってまちまちであるため、下手にプログラムでガチガチにして、メンテナンス不能に陥いることを避ける(CGI実行ユーザとFTPユーザが other の関係であることもあるので)
・たいていの環境では umask が働くから、mkdir の引数どおり、そのまま 0777 のパーミッションとなるわけではない(umask 022 なら 0755 になるはず)。
という理由による判断なのですが、このあたり、見当違いなことを書いているようでしたら、すみませんが、御指摘ください。
Re:御指摘ありがとうございます→Re:恐くて使えない (スコア:2, 興味深い)
・5行目～
何故グローバル変数をmain package($::○○)に置くのでしょうか？
strictへの対策であればvarsプラグマを使ったほうがいいのではないでしょうか？
・52行目～
(検証してませんが)/cgi-bin/wifkyのように拡張子無しで設置した場合に
自身の書き換えをしようとしてしまいませんか？
(当然エラーが発生すると思いますが)
また、ここに限らず$0の参照を行っている箇所が複数ありますが
AliasやScriptAliasに対応できるように
$ENV{SCRIPT_NAME}を利用したほうがいいのではないでしょうか？
・ファイル入出力
wikiの場合多人数の読み書きが前提になるかと思いますが
ファイルロックの仕組みが見つからなかったのですが問題ないのでしょうか？
(ロックの仕組みを見落としてたらすみません。)
・インデント
TABとスペースが混ざってます。
Re:御指摘ありがとうございます→Re:恐くて使えない (スコア:3, 興味深い)
本来、/.jp で取り上げていただくほどのソフトウェアで
もないので、数々の御指摘、誠に耳と胃が痛いところです。
>> ・5行目～
>> 何故グローバル変数をmain package($::○○)に置くのでしょうか？strictへの対策であればvarsプラグマを使ったほうがいいのではないでしょうか？
すみません。実は、単に定石を知らなかっただけです。
>> ・52行目～
>> (検証してませんが)/cgi-bin/wifkyのように拡張子無しで設置した場合に自身の書き換えをしようとしてしまいませんか？
それは大想定外でした。CGI での利用なので、拡張子は必ず .cgi あるいは .pl とされるものとしか考えておりませんでした。
>> また、ここに限らず$0の参照を行っている箇所が複数ありますが AliasやScriptAliasに対応できるように
$ENV{SCRIPT_NAME}を利用したほうがいいのではないでしょうか？
なるほど。$ENV{SCRIPT_NAME} については存在は知っておりましたが、そういうメリットについては知りませんでした。$0 を使うのには、それほど大きな意図はありません。(ローカルで文法チェックするのに、ちょっと手間が省けるくらいです)
>> wikiの場合多人数の読み書きが前提になるかと思いますがファイルロックの仕組みが見つからなかったのですが問題ないのでしょうか？
(1) Wiki と言いつつも、実は個人ユース指向が強いこと(そういう意味では、Wikiに似た「ただの CGI」という認識でも誤解とはいえません)。
(2) 「出力の際、オープン→全内容一気に書出し→クローズと間を置かず一瞬で行うようにさせているので、衝突頻度が低い。一方、下手にロックさせると、逆にオープン中の時間が長くなり、頻度が上がる」と考えました。
…が、自分で書いてみても、ちょっと認識が甘いことと認めざるを得ないですね。今まで衝突事故が全然報告されてなかったため、ヨシとしておりましたが、まだまだ 1.0.0 は時期尚早だったのかもしれません。
>> ・インデント
>> TABとスペースが混ざってます。
vi で「:set sw=4 ts=8」(タブ幅8桁・インデント4桁)で編集しておりましたら、自然とこのように。環境によって桁数が変わるタブなど使わず、全て、スペース化しておくべきでしたね。。
Re:御指摘ありがとうございます→Re:恐くて使えない (スコア:2, おもしろおかしい)
次のリリースで2.0にすれば、今風で大丈夫です。
#何が
Re:御指摘ありがとうございます→Re:恐くて使えない (スコア:0)
いやどっちかって言ったら全てtabのほうが良くない？
--
この辺は宗教戦争になる予感がするのでAC
Re:御指摘ありがとうございます→Re:恐くて使えない (スコア:1)
Re:御指摘ありがとうございます→Re:恐くて使えない (スコア:0)
どこでみても同じインデントレベルは同じ下げ量になる。
混在させちゃうと環境によってガタガタになる。
Re:御指摘ありがとうございます→Re:恐くて使えない (スコア:0)
では、エヴァンゲリストとして一言。
私は幅2スペースでかつ、一行80文字以内(なるべく)、ですね。
テキストビューアが、常にtab文字数を変えられるとは限らないわけですから。具体的に言うと、ウェブブラウザです。ま、ブラウザでソースを読む事なんて一生ねーよ、って方にはどうでもいい話ですけどね。直接テキストを表示させなくても、昨今はブラウザ経由でソースを読む機会が、ホントに多いんですよ。その際、デフォの8でめちゃくちゃになる事がよくあります。
Re:御指摘ありがとうございます→Re:恐くて使えない (スコア:0)
ちうか、ブラウザでソースコード表示した時に不便なのはインデントだけじゃない（強調表示されない、ジャンプも出来ない）ので、普通エディタにコピペする物だと思ってますが。
逆に、強調表示もジャンプも自動でつけられるんならインデントだって融通が利くはず。
設定ファイル名は固定？ (スコア:1)
セキュリティに関するページを見ても「__0716373777f6274」ファイルの扱いに苦心されているようですし。
ざっとソースを見させていただいたところ、title2fname の中で、空の$_をキーに名前を生成しているように思います。
どうしてこの様になっているんですか？
空の$_の代わりにグローバル変数をひとつ割り振ってやれば、プラグインからも触ることができて、ハッピーな感じになると思うんですよ。
試しに自分のところで設置する場合は、この部分には手を入れたい（設定ファイル名を変えたい）と思っているのですが、もしかしたら試行錯誤の結果この様な形になっているのかと思い、ちょっと伺ってみたいな、と思いました。
Re:設定ファイル名は固定？ (スコア:1)
「空の$_の代わりにグローバル変数をひとつ割り振ってやれば」ということですが、そのグローバル変数の値をどうやって決めればいいのか、よい考えが浮びませんでした。「設定ファイルのありかは、設定ファイルに書かれている」(=箱の鍵は箱の中)では意味がありませんし。。
ということで、結局、最初に決めた適当な名前がずっと続いている状態です。このあたり、いいアイデアがあればよいのですが。。
Re:恐くて使えない (スコア:0)
$`、$'などの部分でEmacsがご認識しているみたいです。この場合、
1)Emacsでちゃんと表示できるようにソースを変える
2)Emacsがちゃんと表示できるようにPerl-modeのソースをいじる。
のどちらが正解でしょうか？