PukiWikiスレ Part2
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
05/02/06 00:57:49ID:gotC1R3r公式 http://pukiwiki.org/
開発 http://pukiwiki.sourceforge.jp/dev/
ML http://sourceforge.jp/mail/?group_id=166
PukiWikiスレ Part1
http://pc5.2ch.net/test/read.cgi/php/1084907353/
0458447
05/02/23 07:34:24ID:???その閲覧認証(read_auth)で書いても、認証かけられなかったので。
/cmd=list/とか/cmd\=list/みたいにかいたのですが。
0459nobodyさん
05/02/23 12:13:43ID:???ちょっと、あんたのやりたいことがつかめない。
漏れの脳内補完によると
-?cmd=listで一覧を見られたくない（特定のページ名だけでなく全て？）
-ページごとの閲覧認証をかけてみたけど、上手くいかないっぽ
-$nolistは試してない？
なら、ページ閲覧認証なら「ページの一覧」を対象に加えればいける希ガス
試してないからわからんけど。
それか、listプラグイン自体を削除なり、リネームなり、すればよいのでは？
0461nobodyさん
05/02/23 14:21:21ID:???function plugin_list_action()
{
global $vars, $_title_list, $_title_filelist, $whatsnew;
// Redirected from filelist plugin?
$filelist = (isset($vars['cmd']) && $vars['cmd'] == 'filelist');
if(read_auth(':dummy',true,false)){
return array(
'msg'=>$filelist ? $_title_filelist : $_title_list,
'body'=>plugin_list_getlist($filelist));
}
else{
return array('msg'=>'認証エラー','body'=>'ページ名一覧の表示は許可されていません。');
}
}
中身は何でもいいので:dummyというページを作成。
ページの閲覧・編集認証（ページ名で）をオンにして:dummyを認証の対象に加える。
どうでも良いけど「ページの一覧」なんてページは無いし
$nolistなんてパラメータも無い。($non_listね)
0462nobodyさん
05/02/23 14:32:51ID:???0463nobodyさん
05/02/23 14:38:40ID:???プラグインを呼び出す側で一喝してチェックして、不適当なケースではプラグインを呼び出さないようにするべき。
つまり
普通のプラグインは規制状態では本体が最初から呼び出さない。
特権をもつプラグインを登録制にして、特権をもつプラグインは規制状態でも本体はノーチェックで呼び出す。
特権をもつプラグインの作者はプラグイン自身の責任で規制が突破されないように作る。
普通のプラグインは、プラグイン側で規制の有無に神経を使う義務はないようにする。
こういうのが設計のセンスだと思うんだけどねｗ
0464nobodyさん
05/02/23 15:07:57ID:???君の脳内にしか「特権をもつプラグイン」の定義が存在していないと思われるので、
「特権をもつプラグイン」の定義を明らかしてくれんかね。
0465nobodyさん
05/02/23 15:22:00ID:???上の文章でそれが分からない人間は、この先一生分からなくても生きていく上で差し障りないから、
気にしないことだ。所詮あなたが知ったところで、他人に対する絡みのネタにしか活用できないだろうから。
0466nobodyさん
05/02/23 15:23:51ID:???それが2chでは「自分には分からない」ことをむしろ相手への攻撃材料にしているのだから
恐れ入る。つまり頭の悪い人間ほど強いというわけだ。厨房がのさばるわけだ（ｗ
0467nobodyさん
05/02/23 16:28:38ID:???0468nobodyさん
05/02/23 21:47:24ID:8TSWGbo4とはいっても、ここには数人しかいそうにないが。
表の世界では客寄せ必死な割には、ここはいい加減だな。
ちょっと使う気なくしたぜよ。
0469458
05/02/23 21:59:38ID:???>459
一覧ページ自体を認証の対象にしたいのです。
で、閲覧認証にあの正規表現(?)で追加してもだめだったということです。
>461
さんくすです。
ページの一覧とはこれを指してました。
ttp://pukiwiki.org/index.php?cmd=list
$non_listと共にためしてみます。
0470nobodyさん
05/02/23 22:34:55ID:???0474nobodyさん
05/02/24 02:28:33ID:???> なあ、PukiWikiユーザって仲悪いのか？
PukiWikiユーザーが仲が悪いのではなく、人は皆この程度に仲が悪いものなのだよ。
PukiWikiユーザーだけ平均よりも中が良かったら、その方が特殊であり不気味だと思うよ。
この程度に仲が悪いというのは良くも悪くもPukiwikiは（結束力の強い）一部の特殊なユーザーだけが
使っている段階から卒業し、広く一般に使われ始めたということ。
0476全然分からない人
05/02/24 15:20:25ID:???/wikiフォルダにあるデータのファイル名、例えば
FrontPage.txt → 46726F6E7450616765.txt
みたいになんか変換されて居るんですけど、これを
任意に変換したいときは何をどうすればよいのでしょうか…
関連ツールとかそれっぽいのを検索してみたんですがさっぱりです。
スクリプトでできますよね、で終わってる文章とかそんなのばっかり…
0477nobodyさん
05/02/24 15:28:41ID:???それってWIKIの宿命じゃないの？
URLが長くなるとか。
0478nobodyさん
05/02/24 17:48:21ID:???0480476
05/02/24 21:05:59ID:???レスありがとうです
えっとですね…
たとえば***0001.txt〜***0999.txtというテキストファイルが手元にあったとして、
それを一回ずつweb上でコピペしてページにするのではなくて、
ファイル名をPukiwikiで読めるように変換してそのまま/wikiフォルダにつっこめば
ページとして認識してくれる？のかなと思いまして…
0481nobodyさん
05/02/24 22:21:34ID:???***0001.txt〜***0999.txtの
***の部分が同じ？
ならPage→50616765、みたいに実際に作ってファイル名見て、、、
後の0〜1の数字部分はそれぞれ 0→30 1→31 ... 9→39だから
0001→30303031 〜 0999→30393939 ってリネーム。
エンコードされたファイル名なら/wikiフォルダにぶっこめば読むみたいで。(当然
要は、0→30みたいな置換ができるリネームツールがあればできそう。
プログラムとかはできない人間なのでこんな原始的な方法しか思いつかないorz
0482nobodyさん
05/02/24 22:27:28ID:???sub make_filename {
my $key = shift;
my $enkey = '';
foreach my $ch (split(//, $key)) {
$enkey .= sprintf("%02X", ord($ch));
}
return $self->{dir} . "/$enkey.txt";
}
0483nobodyさん
05/02/25 00:01:52ID:???ツール使ってできたらうれしいね
俺秀丸マクロで似たようなの作ろうと思ったけどできなかった
(文字コードを文字になおす関数が秀丸になかった)
0484nobodyさん
05/02/25 00:19:13ID:???もうhenohenoにはついていけない…
0487nobodyさん
05/02/25 08:46:48ID:MlDT1rYU誰の注目も浴びない->やる意味がないという悲しい現実。
次の皇帝を選ぶのも皇帝の重要な仕事だとか。
0490nobodyさん
05/02/25 14:59:05ID:???話し合うのって意味ないんじゃないの？
与党と野党が話し合ったところで大した意味ないよね。
選挙で勝利した方がすべてを取るわけで、「支持しない」という事実が重要なのであって、
支持しない理由というのは「支持しないという意見に支持を集める」ためぐらいにしか役に立たない。
0491nobodyさん
05/02/25 15:00:32ID:???まあ、普通はそう思うだろうね。
実力さえあれば俺は自分勝手を許すタイプだが、実力もないし他人の意見も聞かないんじゃ、支持しようがない。
0492nobodyさん
05/02/25 15:07:15ID:???まあある意味henohenoの責任ではなくて、henohenoに任せた人の責任なんだろうが。
0493nobodyさん
05/02/25 16:17:10ID:???1.4.4→1.4.5のバージョンアップはかなりいい仕事だと思ってたんだけど。
デフォのスキンでlintのエラーが殆どないこととかも気に入った。
ウェブログツールと違って、ページを追加していってもそれが保持されるし。
0494nobodyさん
05/02/25 16:37:36ID:???２月リリースに固執して、1.4.5_rc1のあと１週間しか待たずにリリースした結果が、ポカミス修正中心の1.4.5_1リリースだし。
1.4.5はBugTrackの集まるのをもう少し待ってからリリースしてれば、こんなことにはならなかった可能性もあるかと。
あとcssのphp化も、cssのカスタマイズをしてる人間にとっては嫌がらせとしか思えなかった。
結局、また弄るの面倒なんでpukiwiki.skin.phpの<link rel="stylesheet"〜の部分を今まで通りのに戻したし。
0495nobodyさん
05/02/25 16:53:45ID:???0496486だけど
05/02/25 18:35:02ID:???いや、開発日記の更新がまめなのとか、リリースにαとrcかませてるのとか
見ると周りにかなり気を使ってる印象をうけたので、それと逆の見方をしてる人は
どういう所でそういう印象をもったのかな、と興味があるのだ。
できればどんなやりとりを見てそう思ったのかURLを示せれば最高なのだが。
0497nobodyさん
05/02/25 18:55:03ID:???っていう要望に答えるためのものだろう。あとは表示用と印刷用でcssを
まとめるためか。ブラウザごとの場合分けやピクセル計算もできるので歓迎。
今後ピュアなcssに戻る可能性も否定できないけど･･･戻らないで欲しいな
英語化の流れは、webからcvsリポジトリみるときにいろいろ文字化けするのを
嫌ったのか？英語化のし残しが残念だがこれもメインの流れとしてはいいと思う
でもやっぱり読むのつらいしちょっと英語がヘンなところあるし、
あと、PukiWikiの新規ユーザーが入ってこなくなってしまうので
日本語版は絶対必要。cvsに入れて欲しい(henohenoがここまでやらなくてもいいけど)
0498nobodyさん
05/02/25 19:25:15ID:???まるで本人のごとくhenohenoと価値観が同じだね。
確かにあなたが示したことはhenohenoが大事だと思って力を入れたことそのもの。
問題は、それがプロジェクトの運営でもっとも大事なことではないってことだんだけどね。
0499nobodyさん
05/02/25 19:29:43ID:???無理して新バージョンをリリースしなけりゃもっといい。
まあこの調子だと心配しなくてもそのうち一般のユーザーからは見捨てられるだろうけどね。
結局henohenoは「節操のない頻繁なリリース」というプロジェクト運営上の初歩的なミスを犯してるんだよね。
しかも本人は自分はプロジェクト管理が上手いと思っているから始末に終えない。
0500nobodyさん
05/02/25 19:35:16ID:???> いや、開発日記の更新がまめなのとか、
そんなことはどうでもいいが
>リリースにαとrcかませてるのとか
全然だめだね。あんな上で誰かが同じことを書いてるが、あんな短期間のα版やrc版のリリースは意味がない。
単に表面的に体裁を整えているだけに見える。思うんだけどhenohenoって実際にプロジェクトを運営した
経験がないんじゃないかと。未経験な人が聞きかじりの知識で真似事をしているように見える。
初めてプロジェクトリーダーを任された人が、まさに行う行動パターンにあまりにもそっくりだ。
誰でも最初は初心者なんだから、経験が乏しいことを今責めはしないが、初心者なら謙虚に
周囲の声に耳を傾けるべきだと思うけどね。
0501nobodyさん
05/02/25 19:54:23ID:???> 個人的に1.4.5でよかったのはcssのphp化。たぶんtDiaryのスキンを使いたい
> っていう要望に答えるためのものだろう。
何にでもメリットとデメリットがあるわけで、そういう見極めが大事なんだけどね。
例えばcssをphp化するデメリットについて、どれだけ念入りな議論がされたというのだろう。
>あとは表示用と印刷用でcssをまとめるためか。
だからそれはcssを切り替えられる機能があればいいこと。それをデメリットも考えずに
節操なく自由度は大きいほうがいいだろうと考えるセンスが、henohenoの経験を疑わせる。
>ブラウザごとの場合分けやピクセル計算もできるので歓迎。
これも同上。そもそもそこまでやっているシステムがどこにあるんだか。
Pukiwikiは「各ブラウザ毎に最適な表示を行うためのツール」ではないのだから、
あくまでWiki本来の部分に注力し、それ以外の部分については保守的なくらいがちょうどいい。
0502nobodyさん
05/02/25 19:54:33ID:???これもいろいろ混同している。英語環境でPukiwikiが機能すること、Pukiwiki本体の
表示が英語にできること、ドキュメントの英語化。これらは別のことだし、そもそも
本当にpukiwikiが優れたソフトなら、英語圏の人々は日本語を取り除くような変換ツールを使ってでも
動かしてくれるはず。我々が日本語非対応の海外のツールを無理に使うようにね。
いずれにしても、これについても英語化することで生じるデメリットについて
どれだけ議論が行われたというんだか。
> 日本語版は絶対必要。cvsに入れて欲しい(henohenoがここまでやらなくてもいいけど)
だから逆なんだってば。英語版の方が無用の長物なの。結局英語版を作れば日本語版と
英語版の２つが欲しくなるわけで、両方をサポートするなどばかばかしい。さらにいえば
両方をcvsに入れるなど正気の沙汰とは思えない。キャッシュをcvsに入れるのと同じように
おろかな行為。
バージョン管理においては管理しなければならないものを最小にするのが基本。
だから自動的に生成される中間ファイル（objとか）はcvsに入れないし、実行ファイルも
普通入れない。管理するものが増えれば、ソースと中間ファイルが同じバージョンになっているか、
チェクインンのし忘れがないか、などねずみ算的に管理の手間が増えていくからだ。
そうしたことを考えずに、なんでもかんでもcvsに放り込むという神経を疑うね。
0503nobodyさん
05/02/25 21:22:00ID:???0504nobodyさん
05/02/25 21:29:17ID:???http://pukiwiki.org/dev/index.php?%A5%ED%A1%BC%A5%C9%A5%DE%A5%C3%A5%D7
開発日記とか開発談義とかもあるけど量が多いのであとまわし･･･
0505nobodyさん
05/02/26 00:10:14ID:???0507henoheno ◆g2j80BX5do
05/02/26 13:58:42ID:???>>252
> リリース間隔については以前 [[ロードマップ#n869dd20]]
> (変な書き方ですが、伝わりますよね? (^^; ) で話して
> いまして、半年は短いと考えています。
既に該当のページをチェックしておわかりかと思いますが、
「半年は短い」は「半年は長い」の誤りです。
>>257
英語版・一部英語版(メニューだけ等)・一部英語のUTF-8版
の需要はかなり以前からあります。
なお、英語化を薦めているタイミングで、韓国のユーザーから
パッチが届きました :) (BugTrack2/13)
こちらから韓国語版のマージを働きかけることができなくも
なかったのですが、あちらから働きかけがあったのは有り難い
ことだと思っています。
0508henoheno ◆g2j80BX5do
05/02/26 13:59:20ID:???stableブランチを作ってはどうか、というご提案をありがとう
ございます。その辺は以前から既に検討されていまして、
「今はすべきでない」と考えています。
「改修が足りていない」と言う表現も同じ意味ですが、みんな
片付いていると思っているか、中身を気にされていないけれど、
実態がそうでない所が沢山積み重なっていて、鋭意修正中なのに
ここでブランチを切っても仕方がないということです。
具体的にはフォローが行き届いていない既存のBugTrackを
ご覧下さい。BugTrack2/17 など。
[[ロードマップ#n869dd20]] でmerlinさんが言われていま
すが、現状「linux-kernel の pre に当たるのは、daily-CVS
が受け持」っています。ブランチが一本なので当たり前ですね (^^;
0509henoheno ◆g2j80BX5do
05/02/26 14:00:07ID:???「半年は短い」というのは誤記です。申し訳ありません。
初期状態のキャッシュは、ユーザーに生成させるのではなく
パッケージ(*.tar.gzや*.zip)に最初から同梱しておくのが
良いと考えています。
＃この手間は、PukiWikiのホスティングサービスを構築したり、
＃PukiWikiをいくつも立てたり・立て直したりする時に
＃特に大きく影響します。
また、これがあるか無いかは、インストール直後の使用感
にも影響します。
すなわち各ユーザーに負担を強いるくらいであれば、
パッケージ製作時にパッケージ製作者が生成するのが
良いと思います。
そこで運用の問題になるのですが、パッケージ製作時に
初期状態のキャッシュを自動生成させるルーチンは現状
ないために、今回 cache/recent.dat と同じ対応を
行いました。
ちょっと難ですが (^^; これで「release.sh でパッケージ
生成を自動化できる」状態が今も維持されています。
詳しくは BugTrack2/8 をご覧下さい。
0510nobodyさん
05/02/26 14:02:00ID:p95mJyNKでよろしかったですか
0511henoheno ◆g2j80BX5do
05/02/26 14:16:18ID:???だと思います。
名称の発端は PHP + YukiWiki ですが、ピューキウィキとは
言わない気がします。
海外の方(at 本家WikiWikiWeb)には
> A little unfortunate that Puki is similar to 'puke',
> a word meaning 'vomit'.
という印象を与えることがあるようですので、
言わない方が良い気がします (^^;
逆に日本語ローカルなネタですが、GeboGeboという
Wikiがあるようです・・・
http://www.gebogebo.org/
> The name GeboGebo derives from the Germanic rune gebo,
> which means as much as "Giving and taking".
ネーミングは難しい問題ですね・・・
0512henoheno ◆g2j80BX5do
05/02/26 14:21:13ID:???発見。ぷきうぃき が正解です。
FAQ/2 や
http://pukiwiki.sourceforge.jp/PHPconference2003/
をご覧下さい。
0513nobodyさん
05/02/26 14:44:11ID:???> 俺も日本語版はcvsに入れて欲しいな。英語版は今後どうなるか知らないけど別にあっていいと思うよ
だからcvsに日本語版を入れればいいこと。英語版はcvsに不要だし、そもそもcvs以外にも不要。
英語版ができれば英語圏の人も使ってくれるともくろんだのかもしれないが、そういうものではない。
その証拠に中国語版とかは有志が勝手に進めている。必要とする人が必要とすることを行う。これこそ
オープンソースなわけ。
必要な物を追い出し不要なものを残したからhenohenoは批判されているわけ。
0514nobodyさん
05/02/26 14:46:13ID:???> メタ議論についていくにはロードマップのページあたりから見ていけばいいんですかね
henohenoってメタ議論好きだよな〜。俺も嫌いじゃないがｗ、henohenoはTPOをわきまえるべきだと思うよ。
やるなら本来の議論のじゃまにならない方法でやるべき。
0518nobodyさん
05/02/26 15:28:30ID:???> 既に該当のページをチェックしておわかりかと思いますが、
> 「半年は短い」は「半年は長い」の誤りです。
おや、当該のページの方が誤りだと思ったよ。思わずお節介にも書き換えようと思ったぐらいだ。
それはそうとして、問題なのはあなたがそう（「半年は長い」）考えていることではなくて、
あなたのその考えが支持されていないのが問題なわけ。しかも経験豊かな人にあなたを
支持しない人が多い気がするんだけどね。支持している側はあまり考えて物を書いていない印象を受ける。
そしてあなたはそういった意見に対して何ら説得力のある説明をしないし、理解も求めていない。
単に「自分はこれが正しいと思う！」と繰り返しているだけ。結局自分勝手なんだよ。
自分が作った最新版を多くの人に使ってみてもらいたいと思うのは誰もが同じこと。
ユーザーからの反応は励みになるし、意見はさらなる改良のヒントになるからね。
しかしその一方で頻繁に多くのバージョンをリリースすればエンドユーザーは
混乱するし、それに対するサポートの負担も増える。また改造やプラグインの作成を行っている人々や
それらを利用している人たちの負担もね。
この二律背反を回避するために多くのオープンソース開発は開発版と安定版を分けている。
誰だって一つのバージョンに集中した方が楽だし、おもしろいに決まっているわけで、
にも関わらず開発版/安定版という手法が広く使われている意味をあなたは軽視している。
0519nobodyさん
05/02/26 15:28:46ID:???数人のプロジェクトも数100人のプロジェクトも、ね。つまりしっかりとした開発体制をとるか、
いろいろ言い訳して自分が楽しいことだけをやるか、というのはリソースの過不足の問題ではなく、
どれだけ深くプロジェクト運営を理解しているかという問題。
さらにいえば、あなたの言動からあなたは開発版/安定版という形態でのプロジェクトを運営したことがないように感じる。
あなたは欠点ばかり机上の空論的に並べいるが、そうした点は運用方法の工夫でいくらでも避けることができるものだ。
重要なのは形態ではなく実質的なものなのだからね。経験がないなら周囲から吸収すればいいものを、
あなたは「うまくいくとは思えない」と門前払いしてしまっているから、あなた自身の知識や経験もいつまでたっても
成長しない。リーダーは優柔不断では困るが、それは最終的な決定を行う時点のこと。あなたはそうした
さじ加減がわからないから、はるか以前の段階であなたやPukiwikiにとって有益となるような意見の芽を摘んでいる。
> の需要はかなり以前からあります。
需要があるか否かではなく、あなたが率いているプロジェクトで行う意義があるかという話をしている。
意義があるか否かは需要があるか否かだけでは決まらない。そんなこともわからないのかわからないふりをして
目をそらしているのか…いずれにしろまともなプロジェクト運営者のとるべき態度ではないね。
あなたは他人の意見は一応聞く（ふりw?）が、他人に対して理解を求める努力は一切しない。
あなたのこの文章を読んでもわかる通りね。あなた程度の実力（はっきりいえば素人に毛が生えた程度の経験）で、
そんな独断専行で周囲の人がついてくると思っているところが、未熟だといっている。
0520nobodyさん
05/02/26 15:41:15ID:???> なかったのですが、あちらから働きかけがあったのは有り難い
> ことだと思っています。
これは各国語を本体のプロジェクトがサポートしなくてもうまくいっている実例だろうね。
つまりあなたのやったことは無駄でしかない。ちょっと残酷な言い方をすれば、ね。
Pukiwikiの各国語対応をあなたは勘違いしている。各国語対応とはコメントや表示文字を変えることではないし、
それらを本体が包含することでもない（もちろん包含する方法もあるだろうが、モジラプロジェクトのような
大規模なものならともかく、Pukiwikiプロジェクトのような少人数プロジェクトには向かない）。
各言語を母国語とする人々が修正や改良をしやすいようにコードや開発体制を整えていくこと。
コードについていえば、ソースに日本語が入っていることは致命的なものではない。その対処方法は
彼らが考えてくれる。必要なのは彼ら独自の修正やPukiwiki本体の今後の修正においても彼らの
負担が少なくなるようなコードに変えていくこと。言語間で共通化できる物はまとめ、できないものは
できないものでまとめる、といったね（まあ、さすがにこんなことは書く必要ないだろうが）。
0521nobodyさん
05/02/26 15:42:48ID:???開発を行い、彼らにとってのエンドユーザーにどのバージョンを提供するか悩みを増やす。
本体が開発版/安定版と分ければ、彼らもそれに歩調を合わせて安定版により重厚な改良を加えると同時に、
目新しもの好きの人間は開発版を追いかけていくだろう。あなたのやり方は彼らから選択肢を奪っていることにもなる。
あなたは「自分が開発しやすい」ことばかりを考え、「他人が開発しやすい」かどうかという観点が
欠如しているように見える。それゆえ「勝手だ」といわれるわけ。俺のようにストレートにいう人間は
少ないかもしれないが、心の中で思っている人間はもっと多いと思うよ。
もちろん、心の中ではあなたを応援している人間も多いだろう。しかし応援してくれる人間が多いのだから、
批判の声を無視していいと考えているなら、それは困ったことだ。最終的に意見が割れれば多数決という方法も
否定しないが、そこに至るかなり手前であなたは「俺はこれが正しいと思うから、こうする。決定だ」と
いっている。そんなつもりはないというかもしれないが、他人からはそう見えるし、いま重要なのは
あなたの「つもり」ではなくて「他人からあなたの言動がどう見えるか」なのだ。
プロジェクトの運営とは、あなたが考えているよりもこうした部分の比率が大きい。あなたはそうした部分が
あまり得意ではないように見える。しかしだからといって悲観したり意固地になる必要はない。
扉さえ開けておけば、いずれあなたが不得意な面をサポートしてくれる人材が現れるものだ。もちろん
扉を開けておくと、うさんくさい人間（俺のように？ｗ）に対しても無防備になるから、この点は注意しなければ
ならない。なれないことをやる場合警戒は必要。警戒を怠らずなおかつ扉を開くさじ加減を学ぶ段階にあなたはいると思うよ。
今のあなたは締め切った扉を前にして、どうやったらその扉をぶち破られないですむかばかり考えているように「見える」。
0522nobodyさん
05/02/26 15:53:01ID:???> ございます。その辺は以前から既に検討されていまして、
> 「今はすべきでない」と考えています。
「既に検討されている」部分を読んだ上での話。
> 実態がそうでない所が沢山積み重なっていて、鋭意修正中なのに
> ここでブランチを切っても仕方がないということです。
この考え方が根本的に間違っている。修正を行い、よい状態にするのが
開発であり、そのための開発体制であり、そのためのブランチなんだけどね。
あなたは開発が終了しメンテナンスモードに入った段階が「ブランチを切る」段階だと考えているようだ。
そういうブランチの切り方ももちろんあるが、それ以外の目的にもブランチは有効。
あなたはブランチを切る目的が一種類しかないと思いこんでいるように見える。
ブランチを分けるべきだと主張している人々は少なからずいるのだから、もしかしたら
自分が知らない利点ややり方があり、彼らがそれを知っているかもしれない、という可能性を考えるべき。
誰でも知らない/未経験のことはあるものだ（もちろん俺もね）。
知らないことそのものではなく、知らないことに出会った時の姿勢が、
その人の資質（これはソフト開発に限らないが）を決める。
0523nobodyさん
05/02/26 16:15:35ID:???> パッケージ(*.tar.gzや*.zip)に最初から同梱しておくのが
> 良いと考えています。
その方法は、あまり積極的に賛成しないが、猛反対もしない。しかしcvsにキャッシュを入れるのはばかげている。
> ＃この手間は、PukiWikiのホスティングサービスを構築したり、
> ＃PukiWikiをいくつも立てたり・立て直したりする時に
> ＃特に大きく影響します。
しない。正確には、そういったレベルのことを問題にするならPukiwikiにはもっと多くの
（キャッシュの問題が取るに足らない問題に見えるぐらい）たくさんの問題がある。
そうした段階でキャッシュについてわずかな改善をしたところで意義は小さい。
その一方でそのためにcvsの管理など開発側の負担はかなり大きい。
何が大切かのバランス感覚があまりよいとはいえない。
> パッケージ製作時にパッケージ製作者が生成するのが
> 良いと思います。
まあそれは一つの解法ではあるが、
0524nobodyさん
05/02/26 16:17:04ID:???自動化にこだわるならrelease.shから?plugin=linksを実行できるようにしたらいいんじゃないの？
もうアホかと。単に初期コンテンツを変更した時にキャッシュを忘れずに生成して、同時にcvsに
コミットするように神経を使う手間が増えただけにしかみえない。あなたは「なぜ自分が考えていることが
合理的なはずなのに、そう考えない人もいるか」をもっと考えた方がいいと思うよ。
自分と違う考えになるのは、相手が未熟だからではなく、相手の方がいろいろな経験をし、どんな
方法にはどんな利点と欠点があるかよく承知しているからかもしれないだろうに。そういったことが
できる人間が長い目で見れば、結果的に多くの経験も積めるわけ。
ちょと話はずれるけど、あなたはこれまでに「この人は優れたプロジェクトリーダーだ」と感じる
人間が身近にいたのだろうか？なんとなく「なんて頭が悪いんだ」と感じるリーダーにしか出会えなかった
のではないかと感じるんだよね。その不幸には同情するけれど、そのためにあなたは将来も
優れたプロジェクトリーダーに出会える機会を自分から放棄してしまっているようで、不憫でならない。
あなたが耳を傾ける姿勢さえ示せば、より多くの人があなたにアドバイスをしてくれると思うよ。
耳を塞いでいる状態の人には、その耳をこじ開けてでもアドバイスする人はあまり多くないからね。
0525nobodyさん
05/02/27 00:45:20ID:???0526nobodyさん
05/02/27 02:53:18ID:???少し落ち着け。お前さんは経験豊富で書きたいことがたくさん
あるのかもしれんが、そんなにいっぺんに書いても伝わらんぞ。
0527nobodyさん
05/02/27 14:49:37ID:???なかなか興味のあることかも知んないけど２ちゃんじゃ読む気にならん。
pukiwikiつかってまとめページ作ってくれｗ
0528nobodyさん
05/02/27 23:25:52ID:???もっと、実際的で有益な、
>>446
さんみたいに、〜したいけどできないっていうのを解決していくような
そいうスレにしませんか？
あるいは、そいういうの専用の別のスレ作るとか。
0529nobodyさん
05/02/28 00:08:42ID:u3KqR1d4メリットが少ないような気がするのですが…
読みを登録しても
・「一覧」ページを生成するときは一文字目しか読んでない。
・検索しても読みまでは検索してくれない。
きちんと辞書っぽい並びで一覧ページが生成されたり、
検索が読みまでカバーするように出来るのなら
全部読みを登録しなおしたいのですが…
0530nobodyさん
05/02/28 00:22:44ID:???最新版（1.4.5）使うだけでできますか？
（現在1.4.2使ってます）
0531nobodyさん
05/02/28 00:54:54ID:???なんか鼻につくというか慇懃無礼というか。
とりあえず、全部わかっててもスルーしてるけど。
なんど例のAAを貼り付けたい気分になったことか。
0532nobodyさん
05/02/28 00:57:28ID:???http://pukiwiki.org/dev/index.php?cmd=read&page=BugTrack%2F741&word=%A5%E9%A5%A4%A5%D6%A5%D6%A5%C3%A5%AF%A5%DE%A1%BC%A5%AF
0533nobodyさん
05/02/28 01:55:30ID:???0535nobodyさん
05/02/28 02:24:44ID:???pukiwiki 1.4.2 の検索結果 約 140,000
pukiwiki 1.4.3 の検索結果 約 169,000
pukiwiki 1.4.4 の検索結果 約 96,700
pukiwiki 1.4.5 の検索結果 約 16,500
0536nobodyさん
05/02/28 02:47:34ID:???0537nobodyさん
05/02/28 08:12:18ID:???> あるのかもしれんが、そんなにいっぺんに書いても伝わらんぞ。
いっぺんに書くと頭がオーバーフローしちゃう人は、自分の能力に合わせて
少しずつ読めばいいこと。それすら自分で自分をコントロールできないなら、
そういう人間はどのみちたいしたことを考えられないから、考えなくていいんじゃない？ｗ
0538nobodyさん
05/02/28 08:13:29ID:???読みたい人が読めばいいこと。人間、読みたくないことはいくらでも理由を考えつくものだよ。
そんな「理由」に意味はない。
0540nobodyさん
05/02/28 08:19:40ID:???態度が気に入るとか気に入らないとか、AAを貼り付けたいとか貼り付けたくないとか、
あんたがそいつに抱いている感情とほぼ同じものを他人はあんたに抱くだろうね。
あのさ、「ネットの匿名性を利用して感情の赴くままに行動するな」なんて言い古されたことを
書く気はない。それを承知の上でやるなら、それも一つのやり方だと思うからね。
しかし少なくとも自分が何をやっているかを自覚すべきだろうね。
0541nobodyさん
05/02/28 08:30:10ID:???「henohenoもがんばってるんだから多少の誤りは悪くいうな！」とかの「有罪だが情状を酌量せよ」って意見じゃなくて、
正面から「henohenoのやり方は正しい！」「無罪である」って方向の、ね。
もちろん「まともな」意見としてね。この場合の「まとも」とはその結論が正しいという
理由を筋道だって説明しようと努力が見える「意見」ね。努力しているなら、
それが達成できてなくても情状酌量しようｗ
0544nobodyさん
05/02/28 16:20:46ID:???以降、マンウォッチはこちらでどうぞ。
pukiwikiな人たち
http://ex9.2ch.net/test/read.cgi/net/1109575206/
0546nobodyさん
05/02/28 17:19:28ID:???lib周りを弄ってると特に…
0547nobodyさん
05/02/28 18:04:20ID:???>>530
1.4.5で動くかたしかめたかったらなーー！！
1．4．5で運営してるサイト訪ねて
ガッチンゴッチンごるもれああああ
ブラウザの右下確認さらせやーーー
0548nobodyさん
05/02/28 18:17:14ID:???okkezだっけ？ あの人は言動がhenohenoシンパっぽく見えるかな。
0549nobodyさん
05/02/28 18:47:24ID:???たしかに。
でも1.4.5から1.4.5_1へは差分が公開されてたからまだ良かったけど、
ユーザが確実に変更してるpukiwiki.ini.phpについては、
設定をいちいち見比べて書いていくのは面倒なので、
ファイルの中の何を弄ったのか具体的に書いてあると、
移行が楽になるんだけどなぁ。
0550nobodyさん
05/02/28 18:48:49ID:???0551nobodyさん
05/02/28 18:59:42ID:???ディレクトリ変えるんならファームまでいって欲しいよ。
リードオンリーだっけ？
あんなめんどくさいことしたくない。
とにかく無駄に敷居高くなったよなぁ。
0552nobodyさん
05/02/28 19:19:18ID:???1.4.2のままでも自作プラグインのrss10ppあたりを使えばできる気がする。
>550
1.4.3→1.4.4移行作業は今思えば楽な方だったよ……。
デメリットのある仕様変更もほとんどなかったし。
そういえば素朴な疑問として、何故orgやdevは1.4.5にアップデートしないんだろね。
開発者自身が安定版だと内心では思ってないんだろうか。
■ このスレッドは過去ログ倉庫に格納されています