---

■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 最新50

read.cgi改良スレッド

654 ：デフォルトの名無しさん ：01/09/02 19:36 ID:McpMRzTs

zz_GetStringリファインしてみた。
あと'=' がない場合が想定されていなかったので、無い場合は無視するようにしたっす。
あ、commitのcomment入れ失敗。日本語文字が消えてる(^^;

655 ：デフォルトの名無しさん ：01/09/02 19:54 ID:McpMRzTs

>>624 で入れたやつ、rawmodeでもURLがタグ化されてるけどいいの?

656 ：デフォルトの名無しさん ：01/09/02 19:54 ID:nSC2NXko

>>631-634 Last-Modifiedの件だけど　オレのところのApacheで確認してみた
ところ　mod_gzip使ってもserver-parsedになってない静的コンテンツは
ちゃんとLast-Modified吐いてます　ということでserver-parsedを外しても
問題がないのなら外してもらった方がいいですね

あとExpiresヘッダがらみの部分が現在

#if 1
　　　　get_lastmod_str(expires_str, zz_fileLastmod + 5);
#else
　　　　　　　:
#endif

とかなってるけど　まぁ実際には EXPIRES が定義されてなければExpiresヘッダは
吐かれないけど　もしこのままExpiresヘッダを吐いたとすると　mtimeの
５秒後にexpireされてしまう......ということは事実上"Pragma: no-cache"と
ほとんど等価になってしまってブラウザでキャッシュされなくなってしまうような
気がするんだけど......

657 ：656 ：01/09/02 20:56 ID:nSC2NXko

server-parsedの場合これどうかね？

　　　　　　　　　　　　　　　　　　　　　Apache module mod_include

XBitHack directive

　　Syntax: XBitHack on|off|full
　　Default: XBitHack off
　　Context: server config, virtual host, directory, .htaccess
　　Override: Options
　　Status: Base
　　Module: mod_include

　　The XBitHack directives controls the parsing of ordinary html
　　documents. This directive only affects files associated with the MIME
　　type text/html. XBitHack can take on the following values:
　　　　　:
　　full
　　　　　As for on but also test the group-execute bit. If it is set,
　　　　　then set the Last-modified date of the returned file to be the
　　　　　last modified time of the file. If it is not set, then no
　　　　　last-modified date is sent. Setting this bit allows clients and
　　　　　proxies to cache the result of the request.

658 ：♯6411 ：01/09/02 21:29 ID:rH8fTNpc

>>657 そもそも、server-parsedにしてる
理由って、adとか差し込むため?

659 ：♯6411 ：01/09/02 21:29 ID:rH8fTNpc

>>656 Expires: の件に関しては、
途中で投げちゃったので、
深く追求しないで…鬱

660 ：655 ：01/09/02 21:33 ID:McpMRzTs

rawmodeでタグ化してるけどってのは、
http://www.psychedance.com/test/read.cgi?bbs=tech&key=998997848&raw=0.0
これ見るとrewrite_href*が処理されてるように見えるんだけど。

661 ：655 ：01/09/02 21:37 ID:McpMRzTs

>>660
って勘違い。鬱

662 ：デフォルトの名無しさん ：01/09/02 22:18 ID:df.8HYUw

どちらにせよ個々のPCの時間がそんなに精度良くサーバと
合ってるはずないんで Expires ヘッダ使うのは無理だと思われ

663 ：♯6411 ：01/09/02 22:23 ID:rH8fTNpc

>>662 Expiresに関しては、どちらかとゆーと
キャッシュサーバに対する妥当性を与える
手段としてあれこれ研究してたす。

ウチの会社で使ってるのはSquid-2

664 ：デフォルトの名無しさん ：01/09/02 22:27 ID:McpMRzTs

>>662
Expiresの時刻はDateヘッダの時刻との差を出して
有効期間を割り出すものじゃないかと思うけど。
RFC2616
>13.2.4 Expiration Calculations
> freshness_lifetime = expires_value - date_value

665 ：デフォルトの名無しさん ：01/09/02 22:28 ID:nSC2NXko

>>663 とするとCache-Controlでわ？

666 ：♯6411 ：01/09/02 22:36 ID:rH8fTNpc

>>665 IE5では、Expires:で保障されてる
オブジェクトに対しては、サーバに問い合わせすら
しない、という噂を聞いて、いろいろ試してた
んですわ。たとえば、過去ログとかは有効期限を
長めに設定しても生きていける可能性が
あるわけでしょ?

/* ためしに廃棄期限をちょっと30秒先に設定してみる */
という部分が、その実験の名残。

先日出た結論 >>336 >>391 以降 では
.cgi ? などという文字がURLに含まれていると、
キャッシュサーバだけでなく、UAもExpiresを信用しなく
なるのでは? ということだった。これに関しての
実験は、後ほどしてみる。

667 ：662 ：01/09/02 22:45 ID:df.8HYUw

>>664
すんません、逝ってきます

668 ：デフォルトの名無しさん ：01/09/02 22:48 ID:nSC2NXko

>>666 なるほど......ただ問題は有効期限切れでexpireされると　キャッシュから
捨てられてしまうため　今度は逆にコンテンツが変化していなくても取得しに行って
しまうことになるので　そのあたりのトレードオフを検討する必要がありますね

まぁおっしゃる通り過去ログなら有効期限を１年ぐらいにしておけばいいのかも
知れませんけど

669 ：♯6411 ：01/09/02 22:53 ID:rH8fTNpc

>>668 詳しく実験してないんだけど、
大筋では、expiredなオブジェクトに対しても、
I-M-S付きで取りに逝ってくれるようなので、
無駄ではない、かもしれん。

今は別の作業やってるので、Expires:の検証ができぬ。

670 ：デフォルトの名無しさん ：01/09/03 05:03 ID:TpCC4vQc

>>568 を読み流してた。。

read2ch.hから、
#defineKatjusha_Beta_kisei
がなくなってます。
http://cocoa.2ch.net/test/read.cgi?bbs=unix&key=998695422&st=81&to=81&n=true

その他、CM_BBSPINKやLOGLOGOUTはどうなんだろ？

671 ：♯6411 ：01/09/03 05:21 ID:L5jSUf32

>>670 いつのまにか消えてますな(ｗ
いま調べたら、リポジトリには
ハナっからかちゅーしゃ規制定義が
入ってないっぽ。

漏れも、なんであちこちに
Katjusha_Beta_kisei
入ってんだろー? とギモンにはなってた
んだが…まーいっか。

672 ：♯6411 ：01/09/03 06:15 ID:L5jSUf32

そろそろ寝るか…

要望: だれか、現行版(5.10?)とほぼ同じもの(?)に、
タグつけといてもらえませんか?
漏れはどの時点が取り込まれたか、いまいち
覚えてませんです。

673 ：デフォルトの名無しさん ：01/09/03 09:10 ID:.8abJrUE

Ver5.10の導入報告は前スレ608
CVSの導入が前スレ739(commitが764)
というわけで、Ver5.10は残ってない

5.10以前に導入され、苦情や問題の無いcondition
NEWBA
DEBUG
GSTR2
こいつらはOK

GZIPは、プロセス数問題があるので保留
PREVENTRELOADは、削除依頼板に若干気になる発言があるので保留
ZLIBは、導入時にzlibがなく、入っていない

674 ：デフォルトの名無しさん ：01/09/03 13:38 ID:nLIVOBVk

「掲示板に戻る」をindex2.html→index.htmlに。

潜在的なバグ
readSettingFile()
　　if (cptr[len] == '='
cptr + len < endp を確認してからにしないとまずい。

dat_out_raw()
　　pPrintf(pStdout, "%.*s", BigLine[i+1] - BigLine[i], BigLine[i]);
datに'\0'が含まれていた場合に、期待した動作をしない。
(最近はbbs.cgiで'\0'をはじいている気がするし、
mod_gzipが.datも圧縮するようになれば、あまり問題ではない)

675 ：♯6411 ：01/09/03 13:40 ID:xDKgLLeA

>>673 そうだったのか、tnx.
リポジトリの最初の方が、5.10にやや近い、
ということにしとけば、いいのかな?

676 ：デフォルトの名無しさん ：01/09/03 14:35 ID:eRhXWXRI

>>674
/index.html より / にしたほうが明らかにバイト数が少なくてすむ。

677 ：デフォルトの名無しさん ：01/09/03 18:04 ID:Z2g4dJyM

>>676
>今までは、http://teri.2ch.net/accuse/index2.htmlとかで
>ブックマークしてたと思いますが、
>これから、http://teri.2ch.net/accuse/になります。
>index2.htmlってのがいらなくなるわけですね。

http://teri.2ch.net/accuse/
だと、gzip化されてない様に見えるが？
mod_gzipが導入されるまでの移行中は、どこに戻すのがいいのやら。

678 ：仕様無しさん ◆NwLv.g/w ：01/09/03 19:32 ID:shKKa9Vo

＞677 とりあえず #defineで設定して後ですぐに変えられるようにしとくのが吉かと。

679 ：デフォルトの名無しさん ：01/09/03 20:28 ID:MKp/si06

ちょっと　Expiresヘッダを吐いた場合のIE5.01とネスケ4.72の
振る舞いを観察してみました

IE5.01 -> Expiresは無視されている模様（Expiresを吐かなかった場合との差が見られない）

ネスケ4.72 -> 当該ページを表示させてから「戻る」ボタン等で前のページに戻ってから
　　　　　　　　「次」ボタン等で当該ページに戻った際に次のような振る舞いになる
　　　　　　　　Expire日時前 -> そのままキャッシュの内容が表示される
　　　　　　　　Expire日時後 -> If-Modified-Since付きでコンテンツを取りに行く
　　　　　　　　　　　　　　　　　Statusが304ならキャッシュの内容を表示
　　　　　　　　このケース以外（URLを直打ちした場合，リンクからジャンプした場合，
　　　　　　　　リロードボタンを押した場合等）ではExpiresなしの場合と振る舞いの違いがない模様

ってな感じでした　なお >>664 で指摘されているRFCの規定にもかかわらず
ネスケはコンテンツをexpireさせる日時はPC側の内部時計のものを使ってしまっている模様

ところで　ネスケ4.72で次のような問題があるようです
　　　　gzip圧縮されたコンテンツでContent-Lengthヘッダが指定されていると
　　　　Last-Modifiedによる指定が無効になってしまう
これはネスケ側のバグではないかと思います　現在2chサーバで稼動中のread.cgiでは
Content-Lengthヘッダがありませんが　これが指定されるようになると
ネスケでは（少なくとも4.72では）If-Modified-Since付きのリクエストを
行わなくなって毎回コンテンツを取りに行くようになってしまうと思います

mod_gzipではdechunkを行うとContent-Lengthヘッダを生成させるので
（そうでなくともスタティックなコンテンツではそうですが）これは
頭の痛い問題ですねぇ......

680 ：♯6411 ：01/09/04 00:04 ID:.iUWuuDs

cvs追いかけてる人は知ってると思うけど、
いま、インデクスの実装を行っており、
設計はほぼ固まりました。

概要・特長は以下の通り。
・インデクスのサイズは 4096 bytes
・/board/dat/idx/XXXXXXXXXX.idx
・ディレクトリ idx がなかったら、インデクスは作成されない
・bbs.cgiの改造はたぶん不要
・完璧な排他制御(ｗ
・スピンロック不使用
・SMP safe(まじかよ)

仕様はほぼ決まっているが未実装な機能は以下の通り。
・あぼーん時のインデクス再構築

…っていっても、いまからmainに組み込むことを
考えると、もちっと道のりあるかな?

681 ：デフォルトの名無しさん ：01/09/04 00:27 ID:1lIywugU

read.cgi更新されたもよう。
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=999451574&nofirst=true&st=573&to=573

682 ：♯6411 ：01/09/04 00:28 ID:.iUWuuDs

>>681 ここのカレントじゃなく、
zlib使うようにしたバージョンかな?

683 ：デフォルトの名無しさん ：01/09/04 00:29 ID:Mgf2Z89w

ありゃ、生DATのgzip圧縮転送って結局まだ有効になってないの? ＞新read.cgi

684 ：デフォルトの名無しさん ：01/09/04 00:34 ID:1lIywugU

なんかindex.htmに戻るようにしただけな気がする。

685 ：デフォルトの名無しさん ：01/09/04 00:45 ID:ydrizmO6

そうかな？

686 ：♯6411 ：01/09/04 00:49 ID:MmUrMvH6

あまりアグレッシヴな改造やると
嫌われるかなあ? (鬱

687 ：デフォルトの名無しさん ：01/09/04 01:40 ID:LkAi.Uls

早く「>>」規制を解除してほしいなぁ。

いちいちst=&to=打ち込めば済むんだろうけど、
ほとんどの人は「レス全部」押すだろうし。
「前100レスを読む」ボタンつけるのととどっちがいいんだろ。

688 ：デフォルトの名無しさん ：01/09/04 01:53 ID:1lIywugU

「掲示板にもどる」を修正。
index2.cgiチェックは標準からはずした。
index2.htm[l]は使われなくなるようなので、index.htm[l]に変えた。
SERVER_SOFTWAREにmod_gzipがあったら、index.htm[l]も出さないようにした。

689 ：デフォルトの名無しさん ：01/09/04 08:03 ID:b.YsqqHc

-DUSE_PATHや-DGZIPって、外すとコンパイルすらできないね。

690 ：デフォルトの名無しさん ：01/09/04 11:09 ID:1lIywugU

>>689
GZIPとZLIBなしでのコンパイルは、>>688で直してある。

691 ：♯6411 ：01/09/04 14:01 ID:h7Jd1mr6

>>689 外してコンパイルの
テストはほとんどしてなかったろで(ｽﾏｿ

ただ、自分が掻いた部分に関しては、
path_depth == 0 のときは
従来の動作を行うように
心がけてたんだけど…ここ2日くらいの
変更についてってない(鬱

692 ：デフォルトの名無しさん ：01/09/04 14:06 ID:EcqU4D62

USE_PATH未定義でコンパイルできるようにして
rewrite_href2をrewrite_hrefに取り込んでみた。

693 ：♯6411 ：01/09/04 14:44 ID:.iUWuuDs

>>692 新バージョン見まスた。
お手数おかけしまスた。

694 ：デフォルトの名無しさん ：01/09/04 15:50 ID:s4.H7M7U

やっぱりそろそろ不要な#ifdefを整理したほうがいいような。

695 ：♯6411 ：01/09/04 16:09 ID:.iUWuuDs

>>694 ちなみにウチのプロジェクトだったら、
ひととおりチェックして機能的に採用されそうなものは
条件を取り払ってしまう、というポリシーっす。
今回は誰がプロジェクトマスターというわけでも
ないからねえ(ｗ

696 ：♯6411 ：01/09/04 16:35 ID:.iUWuuDs

index仕様をcommitした。
殺してあるので、実験したい場合は以下に。

・#define USE_INDEX
・mkdir board/dat/idx

これ主体に書き換えることができれば、
BigBuffer, BigLineを置き換えていくことになろう。

697 ：♯6411 ：01/09/04 16:39 ID:.iUWuuDs

>>696 linuxでは動いているが
freebsdでは動いてないっぽ…鬱

698 ：デフォルトの名無しさん ：01/09/04 16:51 ID:EcqU4D62

>>696
read.c
> /* XXX これはウソ、Expires: は、
> 現在時間を基準にすべきである */
ローカル時計じゃなくてDateヘッダ(サーバ時間)基準だってば。

699 ：デフォルトの名無しさん ：01/09/04 16:52 ID:EcqU4D62

>>698
ってread.cgiはそのサーバで実行してるから同じことか (鬱

700 ：♯6411 ：01/09/04 17:09 ID:.iUWuuDs

>>697 単にサイケどっと混むのパーミションの
問題だった(鬱

>>698 おいしいつっこみありがとう。
これで二人とも鬱だ氏のう

701 ：デフォルトの名無しさん ：01/09/05 13:47 ID:Il0l9chs

CFLAGSに"-march=i686"って入れても大丈夫かな？

あと実運用のではLDFLAGSに"-s"って入れた方がバイナリサイズが小さくなる
ので　その分CGI呼び出しでの負荷が軽くなる......かな？

702 ：♯6411 ：01/09/05 14:50 ID:2LugT.hk

>>701 ld -s でやってるわけじゃないけど
make strip ってのが用意されてる。

703 ： ：01/09/05 21:26 ID:ZOwDxD/w

read.cgi ver5.12 (01/9/5)

704 ：♯6411 ：01/09/05 21:31 ID:zceo8xV2

>>703 まだまだだねー

漏れは別の仕事が入ったので、休憩中。

705 ：デフォルトの名無しさん ：01/09/05 21:32 ID:F4TkSYjU

>>703
これってcvsのソース持ってってくれてるのかなあ?

706 ：デフォルトの名無しさん ：01/09/05 21:48 ID:F4TkSYjU

>>705
されてなさげか

707 ：デフォルトの名無しさん ：01/09/05 21:52 ID:d3E9QeVc

ここの成果を参考にしつつ、夜勤さんが管理しているソースを夜勤さん自身が
メンテしているのだろうね。トラブルも怖いし転送量削減に関係ない部分の
アグレッシブな変更はやはりちょっと手を出しづらいのであろう。

708 ：名無し ：01/09/06 00:31 ID:4dWQq6IU

sage でやってると夜勤さんは気付かないらしい。
みんなから、もう忘れ去られてるし。

709 ：辛口 ：01/09/06 00:56 ID:TLbpbvsU

俺だけかもしれないけど、新しいおもちゃを買ってもらった子供の気分だったね。

read.cgiに新機能なんか要るわけない。
何か別な機能が必要になれば、別途用意すればいい。
余計な機能は邪魔。

便利になるようにするのはいい。
ただ、それがピーク転送量や負荷に影響する可能性があれば
簡単に時間帯制限を設けたり、機能を外したりできるようにしておくべき。
(ほとんど影響しないならば、是非取り入れるべき)

とは言っても、決めるのはここにいる誰かではなく、
夜勤さんであり、ひろゆきである。
特にread.cgiには夜勤さんの決定が最重視されるだろう。
もちろん好き嫌いで決めるのではなく、いろいろ試し、
転送量や負荷を調べ、結果を見て判断するだろう。

ただ、現状のシステムを変化させる必要があるような機能は
夜勤さんはおそらく取り入れない(変更できない)。
現状に合わせて、その中で最善な機能を選択すると思われる。

read.cgiに求められるのは、ピーク時の転送量と負荷の削減。
忘れられかけているが、転送量問題が表面化するまでは、
サーバー負荷が最大の懸案だった。
特殊機能があっても使わなければ同じとは言っても、
ここ(2ch)は、他の人や組織から悪意を持って攻撃される事もある(あった)。
負荷が増える可能性も全て消しておかなければならない。
復帰作業が、スクリプト名を公開せず、
サーバーや時間帯によって厳しく決め事を設けているのを考えればわかるだろう。
便利な機能でも、負荷がかかるようならおそらく外される。

index.htm[l]から"投稿日"が消え、レスから曜日も省かれているのに、
read.cgiは投稿日を非表示にするオプションも(まだ)ない。
文字通り「１バイトを削る」という作業を行っているのに、
常時全レスにアンカーを設定する事に、夜勤さんは同意するだろうか。
natto等に導入されていたread.cgi Ver4.23には、
読みこみdatの最大値を時間帯によって変動させていた。
(もちろん、サーバーの負荷を考慮して。実際、bbspinkの最大値が変更された)
こんなオプションも(まだ)ない。
こういった基本的な点をもう一度重視して、
安定化を図るべきではなかろうか。

で、良さそうと思えるバージョンが安定したら、
そこで簡単なオプション説明でもつけて夜勤さんに推薦するといいのでは？
ここでずっと続けているから、夜勤さんも安定していないと考えて
取り入れないのかもしれない。

710 ：♯6411 ：01/09/06 01:00 ID:ae./7xbU

>>709 「新しいおもちゃ」の部分は禿胴。

711 ：　 ：01/09/06 04:01 ID:IAYQ/SXs

楽しげな新機能を思いつきました。
新規ログ１０件表示にして、表示順を逆にして新しいレスを上に表示する
書き込み後再び、この１０件表示にすれば、チャットモードの完成。

実況スレがさらに活発化！（あかんやん・・。）
このモードでは、無駄な部分は徹底的に削って超簡易表示モード
日付も時間も表示する必要は無い。
一行レスが乱れ飛ぶ事必死！（笑）

712 ：デフォルトの名無しさん ：01/09/06 08:22 ID:0iK.UQWw

>>709
同意

「こんなん作ってみました」じゃなくって、「ここをこう変更するだけで
○○の低下は××程度に抑えたまま転送量をここまで削減することができます」
という具体的な数字を挙げながら説明をして、変更のリスクに見合うだけの効果が
確実と説得できないと採用されないと思うよ。
＃リーマンなら当然分かると思うが。

だからここで30個アイディアが出てそれをこのスレのバージョンですべて採用しても
本番環境では29個ボツになるかもしれない。

それを分かった上でいろいろ試すのはいいんじゃないかと思うけど。
このスレももはや直接的な実装よりも、そういう斬新なアイデアが
出てこないかという部分で期待されてるんだろうし。

713 ：デフォルトの名無しさん ：01/09/06 08:36 ID:x54XUUQc

更新日：とか年の上2桁、曜日の削除って、圧縮かからないときにしか
ほとんど効果ないよな。
圧縮かけられないリクエストって全体のどれぐらいなのかな。

714 ：デフォルトの名無しさん ：01/09/06 12:57 ID:iopuCCXI

現在がサーバ負荷よりも転送量に重大な問題があるなら、
指定した板の指定したレスの生データを吐き出すCGIを
用意してくれないかな。

monazillaで利用されて少しは転送量軽減の足しになるのではあるまいか。

715 ：♯6411 ：01/09/06 13:02 ID:EWT7f5cU

正直、採用されない(採用されたがらない?)コードを
いじくりまわしてるのは、モチベーションが下がる一方で。

いろいろ問題提起もあったんで、もしこの
プロジェクトを続けるんなら、仕切り直しもしたい。

「誰でも気楽に改造を施すことができる」
「評価とかレビューのプロセスが欠落している」
などが、漏れ的には大きな問題になってると
考える。後者は、モチベーションが上がんないと
誰もレビュー買って出ない、というのもあるけど。

また、プロジェクトマスターに相当する人間が
いなかったので、実装の方向性が固まってなかった
とゆーのもある。漏れが突っ走りすぎたのも、
単に歯止めが利かなかっただけ(ｗ

漏れ的には、「バイト数低減と転送量低減のバランス」
「ローカルキャッシュおよびキャッシュサーバへの
キャッシング効率」「実装の軽量化」「潜在バグの追放」
を睨んであれこれ手を出してた。
あ、あと、「ｵﾅｰﾆ」「換骨奪胎」もだな(ｗ

ちうわけで、もうしばらくは、唯一コテハン晒して
生き残ってる漏れが、取りまとめ役に回っても
構わんのだが、どーよ?

実際の実装にまつわるギロンはまた後ほど。

716 ：♯6411 ：01/09/06 13:48 ID:TE3IkoNg

>>709 一点だけ。

> index.htm[l]から"投稿日"が消え、レスから曜日も省かれているのに、
> read.cgiは投稿日を非表示にするオプションも(まだ)ない。
> 文字通り「１バイトを削る」という作業を行っているのに、
> 常時全レスにアンカーを設定する事に、夜勤さんは同意するだろうか。

夜勤さんが同意するかどうかは置いといて。
投稿日を非表示にするか否かに関して、
ここでは「全部削れ」という意見は出なかったので
誰もその方面に手を着けなかった、と考えるべき。
むしろ、「曜日は復活させてほしい」という意見の
方が多かったと感じてる。(俺もそう思う)
ちなみに、現在の仕様だと、内部で投稿日を
解釈してるので、(曜日の表示を含め)日付フォーマットを
自在にいじるのは簡単。

あ、「投稿日」という文字列を削る話?
ぞぬで見てたから気づかなかった。

あと、アンカーの件は俺の改造を指してると思われ。
俺的な考えでは、局所的に見たらバイト数の増加に
繋がれど、大局的に見たらリクエスト数の軽減に
繋がるのでは? と考えて試験的に導入。
この手の仕様に関しては、いくら思考実験を繰り返しても
結局のところ実地テストなしには最終的な評価が
出せないと思うが、いかが?

path仕様でない箇所で<A name=x>を出してるのは
俺の手落ち。機会があったら禁止しとくっす。

個人的な意見では、1バイトでも削る作業より
他にすることはまだある。

最終的に判断するのは夜勤さんであり、ひろゆきさんで
あるという事実には同意。ただ、キャップが誰も
意見を言ってくれない(放置?)以上、その手前の
レベルでとりまとめを行う人間は必要。

717 ：♯6411 ：01/09/06 14:04 ID:.R/e0Ey.

>>712 今後検討する仕様に関しては、
効果予測の文と一緒に提案することにするっす。

ただ、リーマン稼業と違い、
「とりあえず実装してみた、評価頼む」は
大いにありなのだと考える。
以前ｳﾆｸｰｽ板見てた連中に、ここがなんて言われてたか
覚えてる? 「理論ばかりで実装が遅れてる」(←揚げ足歓迎)
なので、漏れはまず実装して、それをたたき台にしたい
と考えた。結果的には、安定版がつくれないので、
ちょっとマズい方針だったんだが。

というわけで、「新機能実装ブランチ」を「バグ取り安定」から
分けないと、作業がしにくいなあ、と昨夜思った。

ちなみに漏れも、いわゆるリーサラだけど、
クライアントに提案して尻込みされた例は数知れず。
説得して採用させたことも多いけどね。

718 ：デフォルトの名無しさん ：01/09/06 19:19 ID:nYC88wV.

自己満足でやりたいなら、勝手にやってれば？

719 ：名無し娘。 ◆vP.bOZFQ ：01/09/06 23:23

>>716
おそらく「投稿日」という語句そのものを削る話だと思います。

>>717
>「とりあえず実装してみた、評価頼む」は
>大いにありなのだと考える。
それは同感なのですが、評価対象がふくらみすぎて、しかも、どこで
defineなりをすればどこがどう変わるのか、途中からさっぱり不明に
なってしまったと感じています。#ifdef の字面と内容が噛み合わない
部分さえ出てきた始末で。
評価してもらうのに最良の方法は、私は結局、全設定を外部ファイルによって
動的変更可能にすることだと思います。
そのこと自体が負荷増を伴うのは確かですが、それなら評価が終わって正式
採用の決まった設定から順に、再び内部定義に切り替えればいいのですし。

もし今後も続けるのでしたら、現行read.cgi(ver5.12/ver5.0x)に対し、
新たな選択肢を提起する形で、もう一度実装をし直す必要があるように
感じます。

720 ：音楽侍 ◆NtVkSITE ：01/09/07 00:08

火急的な課題がなくなったんだったら、そして、今後も改良作業を続けるのだったら、read.cの変更を出来る人を決めるだけでだいぶ違うと思うです。
read.cｎ変更権にパーミッションかけるだけで、だいぶ作業が効率化すると思います。

今までは時間に追われてましたけど、これからは効率化だけ見ていくべきだと思います。
あと、「こういう機能はいかがですか？」と、夜勤さんなどに確認をとるというのがもっとも効率的だと思います。
これまでの経緯から、私は名無し娘。さんがリーダーになるのが良いのでは？と思います。

721 ：名無し娘。 ◆vP.bOZFQ ：01/09/07 00:16

>>720
私は、いわゆる「プログラムは読めるけど書けない」人種ですので、ご勘弁を。
#6411さんのようなしっかりとしたコーディングをなされる方が仕切らないと
何もできないlevelに達していると感じます。

722 ：デフォルトの名無しさん ：01/09/07 00:26

�
u
�

723 ：(ﾟДﾟ)ﾊｧ?スレ発起人＠批判要望板 ：01/09/07 00:29

はじめましてー
詳しく read.c のソースは読んでないのですが

/* SJIS1バイト目＝<br>タグ直前の空白が削除可かを適当に判定 */

IE等では>>722のようなことになるので，
datファイルの<br>前の空白だけでなく，
datファイルの各行末にある<>前の空白も
削除可能かどうか判定されると完璧ではないかと思います．

724 ：♯6411 ：01/09/07 00:32

>>720
> 今までは時間に追われてましたけど、これからは効率化だけ見ていくべきだと思います。
同意。内部的には、効率化・安全化を進める
べきなんでは〜と。
漏れのコードは安全化より重要な「自己満足化」が多いのだが(ｗ

> あと、「こういう機能はいかがですか？」と、夜勤さんなどに確認をとるというのがもっとも効率的だと思います。
漏れは夜勤さんﾊｧﾊｧではないので追いかけ切れんす。
どなたか、この点のフォローをしていただければ。

>>721
「読める」人間こそ、取りまとめに必要ではないかな?
漏れは「掻けるけど嫁ない」人間なので(ｗ

さしあたっては、ブランチを設けることを提案。

725 ：709 ：01/09/07 00:54

反論は煽り系のキャラで逝ってみる

>>716
＞あ、「投稿日」という文字列を削る話?
＞ぞぬで見てたから気づかなかった。
関連スレや意見を読んだりすれば、
どういう状態になっているか、板を開いてみる程度はするのが普通。
現状を認識しようとする意志が全くないわけね。
現状を把握せずに機能を提案できるなんて、すばらしい。

＞俺的な考えでは、局所的に見たらバイト数の増加に
＞繋がれど、大局的に見たらリクエスト数の軽減に
＞繋がるのでは? と考えて試験的に導入。
試験的に導入した割に、完全に書き換えてしまうわけね。
戻せるとはいえ。「俺的な考え」を基に。
で、コンパイルが通らなくなったりしても、
尻拭いは後回しにして、結局他の人がすることになるわけだ。

＞この手の仕様に関しては、いくら思考実験を繰り返しても
＞結局のところ実地テストなしには最終的な評価が
＞出せないと思うが、いかが?
その通り。だから？
簡単にテストができるようにしておけばいいものを、
まるで仕様が確定したかのように扱うのはどうかと思うが、いかが？

>>717
＞個人的な意見では、1バイトでも削る作業より
＞他にすることはまだある。
個人的な意見なんでしょ。他人に押し付けないでよね。
ま、ある程度は同意するけど。
そもそも「１バイトを削る」自体が夜勤さんの言葉からの引用だけど、
それも読んでないんだろうね。

＞「とりあえず実装してみた、評価頼む」は
＞大いにありなのだと考える。
その通りだね。
普通は評価前に仕様確定するようなやり方はしないけどね。

726 ：709 ：01/09/07 00:54

あ、俺はリーダーに最も適任なのは夜勤さんだけど、忙しいだろうし
それ以外では名無し娘。 ◆vP.bOZFQさんが適任だと思うね。
関連スレのチェックもしているし、重視すべき事項を一番わかっていると思う。
直接コーディングなんかできなくても、
機能追加の方向性やスケジュール等を把握して示してくれれば充分。
以前から、要望やらをまとめたりしてくれてたしね。

既に実装済みの機能や不具合の修正もいくつもあるのに、
(zlib等の他にも、ぱっと見で>>687とか>>559とか。>>606は未？)
fix版が出せないのは悲しいからね。

727 ：名無し娘。 ◆vP.bOZFQ ：01/09/07 01:11

>>724 >>726
ボランティアの作業で、仕切る人間が口だけじゃまずいと思いますです。
あくまでコーディングをする人にすべての権利があり、それを承知の上で
周りの人もそれぞれの意見をいう。。。という共通意識が何より大切かと。
ですから私が仕切るわけにはいきませんです。

夜勤さんがread.cgiにどれくらいの時間を割けるのかは、わかりません。
ですがやはり、いくらソースが長くなっても、オリジナルのソースと改良案は
（部分毎に）並行して提示しないと、採用には抵抗があると思います。

そろそろ、replace系の関数を最適化する方が先なのかもしれませんね。

728 ：♯6411 ：01/09/07 01:13

ﾏﾀｰﾘと逝くよ…

> 現状を認識しようとする意志が全くないわけね。
> 現状を把握せずに機能を提案できるなんて、すばらしい。

ｵﾅｰﾆだったんだよ、所詮。


> 試験的に導入した割に、完全に書き換えてしまうわけね。
> 戻せるとはいえ。「俺的な考え」を基に。
> で、コンパイルが通らなくなったりしても、
> 尻拭いは後回しにして、結局他の人がすることになるわけだ。

同意。自分じゃ条件外すことはめったにしないしのー。


> 簡単にテストができるようにしておけばいいものを、
> まるで仕様が確定したかのように扱うのはどうかと思うが、いかが？

放置されてて誰も構ってくれないので、
(うん、外せといわれたら即座に外せはするんだけど)
外す方法を吟味せずにcommitした漏れはダメダメだ。


> 個人的な意見なんでしょ。他人に押し付けないでよね。

ｵﾅｰﾆなんだ、言わせてくれよう。


> そもそも「１バイトを削る」自体が夜勤さんの言葉からの引用だけど、
> それも読んでないんだろうね。

読んだ記憶はあるんだが、俺解釈してた。
字面通りに受け取らないとダメねー


> 普通は評価前に仕様確定するようなやり方はしないけどね。

<a name=>の件は、正直、すまなかった。


…漏れはもともと煽りキャラ持ってないんだが、
ﾏﾀｰﾘキャラも持ってないので、疲れた…
(引用ばかりすると、十分煽りになりうるんだが)
…疲れたので、今晩はもう逝くよ…探さないでくれ…鬱だ氏のう

729 ：音楽侍 ◆NtVkSITE ：01/09/07 01:28

>>727
＞ボランティアの作業で、仕切る人間が口だけじゃまずいと思いますです。

ちょっと違うです。むしろ、全体を見られる人はコーディングしない方がいいです。
どうしても自分が動くと、いろいろ出ます。読めるけどかけない人の方が適任かと。

いろんなプロジェクト見てくださいです。
リーダーやマネジャーがコーディングを始めたプロジェクトは大抵納期間に合いませんです。
品質管理もままなりませんです。

>>728
相談と報告のキモチが良薬かと・・・

730 ：デフォルトの名無しさん ：01/09/07 01:34

とりあえず、既出の不具合で未修正のもの。
キャッシュであぼーんされたレスが見える？(詳細不明)>>441
PATH_INFO時に間違えるとレス１しか表示されない>>624
かちゅ〜しゃ規制>>670
設定ファイル読みこみ時のオーバーフロー>>674
行末の空白削除>>723
それ以前は>>397だけど、どれだけ残ってるかな・・

その他、今気がついたもの。
批判要望板で最近よく出てくる
「このスレッド大きすぎます」への暫定対処として、
datファイルの大きさがある程度(最大値-16K位)を超えたら、
「もうすぐ読めなくなります。新スレの準備を。」の警告があれば親切かも。

あと、できるだけ設定ファイルから読みこめるようにして、
リメイクは不要にした方がよさそうだね。

731 ：デフォルトの名無しさん ：01/09/07 02:19

>>723さんは
「スクリプト関連要望統合スレッド 」
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=994071363
の人ですね。

732 ：730 ：01/09/07 04:48

改めてソースを見たら、既に>>674は修正されてた。氏にます。
他にも修正済みがあるかも。

733 ：デフォルトの名無しさん ：01/09/07 08:33

これまで行った変更点をすべて列挙して、それぞれの目的と変更量とそのリスク、
転送量削減に対する効果、その他の効果などを一覧にまとめてテストケース作って
すべて再評価した上で改めて内容を吟味したらいかが？

テストサーバに置いてここの住人にテスト手伝ってもらうとかはできるっしょ。
仕様書はソースコード、って状況はやっぱりＰＧの自己満足モードで終わっちゃうよう。

734 ：デフォルトの名無しさん ：01/09/07 10:44

read.cgiに加えられている変更点は単純に２つに分類できる。
A)転送量・負荷低減のために行われるもの
B)機能を追加してより使いやすくするもの
そして、それぞれの変更点について、
1)導入する
2)導入しない
3)時間帯によって導入する
の３つの選択肢がある。
この３つのうち、1)か2)かを選択するようにしておくのは
#ifdefで切り分けるだけなので比較的簡単だが、
3)の形式は#defineで導入し、さらに時刻によって
処理を変化させなければいけないので、1)2)よりは面倒になる。
しかし、転送量や負荷の少ない時間帯に比較テストできるため、
「試しにやってみて結果を知りたい」場合に有効になる。
試した結果が、時間制限付にするか完全導入するかの判断材料になる。

というわけで、「この機能は時間制限つきで導入してみよう」という指針が
示されれば、必要な変更を施して仮導入してもよさそうな気がする。
さらに、外部ファイルで変更可能にしておけばさらに良かも。

735 ：デフォルトの名無しさん ：01/09/07 10:44

ブランチを設けるのは大賛成。
Linuxみたく、安定版と開発版とで仕切る人が別になるのも手だろう。
従事するメンバーを分けるほど人数が多いわけじゃないが。

当面、安定版は現行のVer5.12と同等の機能部を抽出し
不具合を修正したものをベースに、ある程度の機能追加をしたものになると思う。
「ある程度」がどの程度なのかは、まとめ役の人の裁量に従いたいが、
-DZLIBは以前から作ってある
-DCHECK_MOD_GZIPはあった方がいい
-DUSE_SETTING_FILEは柔軟性のために必要
等々、結構難しそう。
さらに、-DZLIB,-DUSE_MMAP等の「見栄えは変わらないが負荷低減を狙う機能」は、
早目に安定版にいれて、確定させてしまいたいところだ。

また、増えすぎた#ifdefの中で、Ver5.10以前の導入で問題出ていないものは
条件をはずしてしまっていいと思う。
個人的には-DLASTMOD,-DNEWBA,-DGSTR2は全然問題なし、
-DPREVENTRELOADも#ifdef無しで構わないと思うが、
意志決定はまとめ役の人の判断に任せるのが一番。
BadAccessの旧版にあるAccept-UAのリストなどは、
コメントとして残しておくのがいいかもしれない。
(気分的には、BadAccess中のReadOnlyなローカル配列はstaticにしたいなー)

あ、娘。さんは「オリジナルも残したほうが」と言ってるな。
だったら、採用をほぼ決定したものに対しては、
同じ１種類の#ifdefにしてしまったら、少しはわかりやすくなるかも。

736 ：デフォルトの名無しさん ：01/09/07 10:45

以下は名無し娘。さんのお手伝い・・・のつもり。

>#ifdef の字面と内容が噛み合わない部分

-DCUTRESLINKは、本当に#define名と内容が一致していない。
変更部のメインは最適化で、リンクの削除はオマケ程度な感じ。
方向としては、
・mmapがSHARED & READONLYで使えるようにBigBufferを読みこみだけに
・ファイル全体やレス全体を走査する回数を極力減らす
・そのために変換や空白削除、http://のリンク等を全て同時に行う
といったところ。
ただ、そのことにより内部で保持するデータ形式が変わってしまい、
他の部分への影響も出ている。
名目通りのCUTRESLINKに相当するのは大きなswitch文の一箇所だけで
全体のdefine名は、つけ直すならBUFFER_READONLYとか
NO_RES_NUL_TERMINATEとか、そんな感じに近いと思う。

>replace系の関数を最適化する方が

上とも関連するけど、現在、-DCUTRESLINKを指定すると
replace系は全く使われない。
現行のVer5.12等では、hlinkReplaceの中でdoReplaceが使われているが、
これもressplitter_splitの内部に吸収されている。
ソース中ではTYPE_TERIが定義されていない場合にsomeReplaceが呼ばれるが、
同等の変換は既にressplitter_split内部で為されているので、本来必要ない。

というわけで、-DCUTRESLINK(内容は違う)を採用する方針でいくなら、
replace系には目を向けなくてもいいと思う。
あえて不安材料を挙げれば、Ver5.1xでの稼動実績があるのが基本部だけで、
保持データ系式の変更やhttp://リンク、mmapとの併用、
これらでの実績が乏しい点があるが、今のところ
まともなdatを低負荷時に読んでいる範囲では、問題は出ていない。

逆に、-DCUTRESLINKを採用しない/条件等によっては機能をoffにしたい、
となる可能性があるなら、replace系の最適化には意味がある。
その辺の判断と指示はまとめ役の人にお任せしたい。

737 ：♯6411 ：01/09/07 12:17

>>734
細分してみた。

> A)転送量・負荷低減のために行われるもの

* 外部的に機能がほぼ変わらないもの

A0) 安全性の向上のみを目的としたもの(いわゆるバグフィクス)
A1) 転送量の低減を狙っているもの
A2) 転送量以外の負荷低減
A3) 単なる設計・構造・インタフェイス変更

> B)機能を追加してより使いやすくするもの

B0) 従来仕様と相反しない、独立した機能
B1) 従来仕様の不備を補完するもの
B2) 従来仕様の不備を再定義するもの
B3) 従来仕様と置き換わるもの

フォローきぼんぬ

738 ：♯6411 ：01/09/07 12:20

>>735
PREVENTRELOADは、まだなんとなく
潜在的な問題をはらんでるような気もしない
でもないんだか、杞憂だろうか?

739 ：♯6411 ：01/09/07 12:23

>>736
CUTRESLINKを再評価するのであれば、
名前付けなおしてさらに細分化するのがよろしかと。

あと、従来とまったく置き換わってしまうものに
関しては、モジュールを切り分けることを
前向きに検討した方がいい。

740 ：デフォルトの名無しさん ：01/09/07 12:33

>>730おつかれ。
ところで、提案していた

>批判要望板で最近よく出てくる
>「このスレッド大きすぎます」への暫定対処として、
>datファイルの大きさがある程度(最大値-16K位)を超えたら、
>「もうすぐ読めなくなります。新スレの準備を。」の警告があれば親切かも。

はたしかに良いな。

是非搭載してほしいところだが、夜勤さんは嫌がるだろうか？
（read.cgiの負荷増大につながるため）

741 ：デフォルトの名無しさん ：01/09/07 12:33

今CHUNKが強制になってる感じ?
#ifdefでCHUNKにならない従来型UIにする選択肢なくなってない?

742 ：723 ：01/09/07 13:22

>>731
そうです。

743 ：♯6411 ：01/09/07 15:34

ブランチ案

○リリースには明示的にリビジョンを設ける
ex) 5.12
今回は、どの辺から始まってるか微妙なので、
-r4.99あたりで始めるといいのでは。
夜勤さんから、本番に適用したバージョンを
もらい受けて、-r5.xx などとしてcommit
以降、Revision 4.99 が存在するとして説明。

○リリース候補(4.9.x.x)
プロジェクトマスター
(あるいはマスターから委任された人間)
のみがcommitできるブランチ。
cvs tag -b RC-4-99 のようにつくっておく。

○ワーキングブランチ(4.9.x.x.y.y)
今までheadでやってたものは、みなブランチの中で
作業を行う。
cvs co -r RC4-99 bbs で取り出したブランチに、
cvs tag -b HEAD-4-99 のようにつくっておく。

○プロジェクトマスターの役目
・適宜ワーキングを吟味し、RCに取り込み、commit
・夜勤さんの作業に追従
・新しいリリースが出たら、ブランチを作成。

○検討事項
ワーキングブランチは、
改造系統毎に分ける、あるいは
担当毎に分ける方がいいかもしれない。


ブランチの作成は、サーバ持ってる aki さん
あたりにやってもらえると早いんだけど、
さしあたっては名無し娘。さんがやってもらえれば。
(ローカルで念入りに実験した方がいいかも)
漏れがやってもいいです。

744 ：♯6411 ：01/09/07 15:37

>>743 最新リリースの入手に手間取るようだったら、
さしあたっては8/28 4:00(GMT)あたりのものを
「仮リリース」として据えるといいかも

745 ：音楽侍 ◆NtVkSITE ：01/09/07 15:54

検証班の作業も工程に入れて置いてください(^_^;)

746 ：名無し娘。 ◆vP.bOZFQ ：01/09/07 17:32

ver5.12(夜勤さん版)のひとつ前に実動してたのって、verいくつでしたっけ。。。

昨日ちょっとだけ、試しにteriに入ってるread.cgiをいじめてみたら、zz_xx の
size制限がかなり厳しくなってるようで。zz_xx[20]になってるのかな。
たとえば http://piza2.2ch.net/test/read.cgi?bbs="></a> みたいなこと
やられると気持ち悪いからかもしれません。
こんな感じで、いろいろちょこちょこと夜勤さんが手直ししてくださってるのかも。

なんにせよ、一度夜勤さんにお出まし願った方がよさそうですね。
どのソースを元に、どういうとこから手をつけてくのがいいか。
などなど。

747 ：デフォルトの名無しさん ：01/09/07 17:56

>>746
> なんにせよ、一度夜勤さんにお出まし願った方がよさそうですね。
さんせい

748 ：デフォルトの名無しさん ：01/09/07 20:49

>>746-747 そうですよね　とにかく運営サイドの誰かに度々ここに来てもらって
意思疎通ができないと　こちら側だけで突っ走ってもタダの骨折り損になりそうな
気がしますし

749 ：デフォルトの名無しさん ：01/09/07 22:39

>746
http://piza2.2ch.net/test/read.cgi?b=tech&k=998845501
の段階で zz_GetString が変わって、キーの先頭1文字しか見なくなりました。
たとえば
http://piza2.2ch.net/test/read.cgi?board=tech&kiji=998997848
のように書いても正しく読めます。

750 ：名無し娘。 ◆vP.bOZFQ ：01/09/07 23:20

>>747-748
機会があればお願いしてきます。
>>749
1文字判定もできますが、たとえば zz_ky は今でも20文字(19文字)を
格納しています(判定後、切り出された文字列。たとえば key=998997848 の
"998997848"部分)。
http://piza2.2ch.net/test/read.cgi?bbs=123456789abcdefgh
をリクエストしたときのエラーメッセージ中、下部「過去ログ倉庫」の
リンク先を見ると、何となく何をやっているかがわかります。

751 ：名無し娘。 ◆vP.bOZFQ ：01/09/07 23:21

>>750
...hまでじゃだめじゃん。
http://piza2.2ch.net/test/read.cgi?bbs=123456789abcdefghijklmnop
やると。。。ね。

752 ： ◆D69Zsbfg ＠夜勤 ★ ：01/09/08 20:33

どうも、お世話になっています。 > みなさん。
明日の未明(今晩)あたりに、登場しまーす。
で、最新版を組み込もうかなぁと目論んでいます。

よろしくお願いします。

753 ：音楽侍 ◆NtVkSITE ：01/09/08 20:57

おつかれさまです。

335KB

---

新着レスの表示

---

スレッドリストへ戻る 全部 前100 次100 最新50

0ch BBS 2004-10-30