第3回2ch全板　コード関係の議論スレ２

1 ：08/03 〜 最終レス ：11/10

前回１１レスで終わったあのスレが帰ってきたぞ！
本スレ
第3回2ch全板　コード関係の議論スレ
http://etc7.2ch.net/test/read.cgi/vote/1199366460/l50
前スレ
第3回2ch全板　コード関係の議論スレ
http://etc7.2ch.net/test/read.cgi/vote/1199366460/l50

2 ：

２だけ取って逃げる

3 ：

３だけ取って逃げる

4 ：

>>1
本スレ間違ってるorz
第3回2ちゃんねる全板人気トーナメント運営スレ★3
http://etc7.2ch.net/test/read.cgi/vote/1203601911/l50

5 ：

５だけとって逃げる

6 ：

じゃあ6は貰っておく

7 ：

七人の侍

8 ：

８っぱふみふみ

9 ：

９やしい・・・でも・・・

10 ：

１０とい命

11 ：

ひらがなトーナメントが終われば、
こっちのスレも使いそうですね。
　　∧＿∧=-　∧＿∧
　 （∀｀ 　） -=（ 　´∀）
　 と 　 　つ と　　　 つ
　　（　＿｀)=-（　　 （_）
　　 ﾞヽ_,）　　-=し'"´
スレの即死落ちとかってどうゆう判定なんでしたっけ。

12 ：

>>11
始めは、Ｎ(KB)の容量若しくはｎレスに達しなければ、落ち
後ろは980レスが付いたら、24h経過後の最初のdat落ち判定のときに落ちる
仕組みだったと思う。
俺の記憶してる基準はこんな感じ（違ってるかもしれない）
あと　ｎやＮの部分は一般人には発表されないものなので、どっかに聞きに行っても教えてくれないよ

13 ：

よし！前スレ越えたぞ！

14 ：

一応参考までに。
http://www.itmedia.co.jp/enterprise/articles/0802/27/news027.html

15 ：

>>2->>3
お前らにだけは本気でついて行きたいと思った。

16 ：

まだ即死圏内にあるのでじわじわカキコ
コードの待ち時間だけど変動だとやっぱり分かりづらいね
10分固定でいけるんならそっちの方がいいんじゃないかな

17 ：

スレ保守カキコ。個人的な要望を書き残しておきます。
発行時間：１０分固定
画像認証：有(試行３回、60秒、予約と取得で２回認証)
BBQ機能：有
発行時間に関してはあまり多重防止にならないと思います。
画像認証の試行は５回でも良いかもしれないけど、５回より多くする必要な無しかと。
６０秒はCAPTCHAを他動認証等での突破しづらさのため（もっと短くても良いと思う）これ以上長くはできない。
コード予約と取得の２回認証は同じくCAPTCHA突破しづらさへの抵抗。
BBQはproxy対策という事で導入。2ch側で投票所に入れてもBeで突破できるらしいので。

18 ：

>>17
画像認証　類似文字の排除とかはどうするんですか？
１（数字のイチ）とＩ（アイ）やｌ（エル）が見づらかったり、０（ゼロ）とＯ（オー）が似通ってたり

19 ：

>>18
個人的には３回もあれば十分かと思っています。
自分は何回も認証やっていますが３回以内で引っかかったことありませんし･･･
無論それでも引っかかる人も結構いるみたいなので対策としては試行回数を５回にしても良いと思っています。
よって類似文字の排除自体は考えていません。
どうしても排除して欲しいって人は文字の画像を作って渡して頂ければ適応します。
私の方で画像を作成して用意する事は時間的に難しいので考えていません。

20 ：

>>19
＞１（数字のイチ）とＩ（アイ）やｌ（エル）
これらを全部同じ文字として認識(1でもIでもlでもOK)みたいにするのはダメなの？
それだけで精神的には随分楽だと思うんだけど……。

21 ：

>>20
画像認証はコード発行システムとは全く別プログラムで動作していると考えて下さい。
コード発行所システムからは簡単なパラメータ(文字数とか認証有効時間とか)を渡して、
画像認証プログラムを呼び出して動かしているような物です。
出力された画像、入力された文字は全て画像認証プログラム側で処理されるので介入は容易ではありません。
(画像認証プログラムはサーバーインストールされている物です。)
認証用画像を用意する方が遙かに堅実な方法かと思われます。

22 ：

俺は画像認証は無し、待ち時間変動制はありがいい。
画像認証はどうせ突破されるだろうし、慣れて無い人は失敗する可能性もある。

23 ：

失敗する可能性は何回でも可能ってことにしたら

24 ：

私はＢＢＱが嫌いだったりします。。。
理由：ＢＢＱ鯖が落ちてると１分半〜２分くらい
反応帰ってこないから
＃レアケースって言ったらそれまでだけどね。。。

25 ：

画像認証有り、待ち時間10分固定に賛成。

26 ：

>>24
自分もあんまり好きじゃない
個人的には
10分固定はあり
画像認証はなし
あたりがいいかな

27 ：

>>24
なるほど、ＢＢＱを使った物作ったことが無かったので貴重な意見ありがとうございます。
幸いまだ取りかかれていない状況です。
ＢＢＱを追加しなくても良くなると私の役目はもう終わりですかね？

28 ：

画像認証有り(なくてもいいがそこまで面倒とは感じなかったので)、待ち時間10分固定希望
まあ、◆APFKcKFi7U氏が最後まで第三回の主催をやる覚悟が決まったなら
ある程度イニシアティヴとって決めちゃってもいいと思うよ

29 ：

なんで追加しなくていいってなるんだよ。
じゃあ俺はBBQ追加しろで。
なぜなら　多重が容易になるから
すべては防げないって反論する人へ
・じゃあすべてを防げるものを出してください。
　そんなものないです。できるだけ多重はできないように努力するしかないんです
BBQ追加で多重がより困難になる。不可能になる訳ではない

30 ：

まあ落ち着け
　BBQありのメリット、デメリット
　BBQなしのメリット、デメリット
それぞれを考えるとき定量的な判断基準なんて出せないでしょ？
なら最後は主催が決めるしかないんだよ
という感じで全体的には動いてると思うけどな
>すべては防げないって反論する人へ
>・じゃあすべてを防げるものを出してください。
>　そんなものないです。できるだけ多重はできないように努力するしかないんです
人に自分の意見を押し付けるのは良くないと思うよ
まあこれは俺の考えだからスルーしてくれていいけどｗ

31 ：

あ、すいません。27だと「追加しなくていい」って言っているように受け取れますね、ごめんなさい。
私は機能を追加するもしないも基本的に◆APFKcKFi7U氏の決定で動いています。
私は個人的には>17に書いた通りの要望です。
ただし、
>理由：ＢＢＱ鯖が落ちてると１分半〜２分くらい
>反応帰ってこないから
これは結構困ります。下手するとＢＢＱが落ちている間は誰にもコード発行できないとかって事になるかもしれません。
私がまだＢＢＱの技術について詳しく調べる時間を取れていないのもありますが、
可憐車さんが嫌がる程の物に主催からのＧＯサイン無しに無理に取り組む必要は無いとも思ってます。
実際◆APFKcKFi7U氏はまだＢＢＱについて特に触れていないようですし。

32 ：

BBQってとても優秀だけど可憐車氏が心配している通り
ちょっと困ったことになる場合もある
ちょこっとコードを書いて回避できるならいいけど
実環境でそれを試すのは難しいような

33 ：

学校から大量取得は　*.ac.* *.edu *.edu.* *.go.*をdenyすれば結構弾けそう

34 ：

BBQ導入には賛成
理由：
どうせ2ch側で引っかかるので、発行所側で許可しても意味無い。
また、変にコード発行cgiを呼ぶ前に引っ掛けておけば、無意味な負荷も減ると思う。
それに、投票できないIPにコード発行するのは、発行所、投票者のお互いに無意味。

35 ：

追記：
2ch：BBQでNG、発行所:BBQ許可とした場合、投票者に
繋ぎ換えを奨励することになります。
また、
「コードを発行したIP＝投票したIP」
という風にポリシーを統一しておかないと、
もし末尾規制を行った場合、
「発行所側でコード発行を抑止したIP≠投票したIP」
となって、抑止の意味が無くなります。

36 ：

◆APFKcKFi7U氏を待ってるだけなのも時間が勿体ないので、BBQ鯖が落ちない事を前提にコード組みこんでみました。
今のままだとたぶんBBQ鯖が落ちたらコード発行できません。っというか発行所の挙動がおかしくなるかもしれません。
BBQ鯖落ち対策は◆APFKcKFi7U氏のBBQに対する見解待ちということでお願いします。
どう対策を組めば良いのか思いつきませんが・・・
>>33
http://etc7.2ch.net/test/read.cgi/vote/1203601911/183-184
>>34-35
>どうせ2ch側で引っかかるので、発行所側で許可しても意味無い。
●で規制に引っかからず2chは書き込めると思います。
>変にコード発行cgiを呼ぶ前に引っ掛けておけば、無意味な負荷も減ると思う。それに、投票できないIPにコード発行するのは、発行所、投票者のお互いに無意味。
負荷はたぶん増えてます。また、2ch(投票所)にBBQが働いていると知れば、わざわざ投票できないIPで発行所にくるユーザはそう多くないと思います。
>2ch：BBQでNG、発行所:BBQ許可とした場合、投票者に繋ぎ換えを奨励することになります。
BBQで規制されているからには相応の理由があるはずなので自業自得だと思います(勿論巻き添えも少なからずありますが)。
>「発行所側でコード発行を抑止したIP≠投票したIP」となって、抑止の意味が無くなります。
言いたい事が良くわかりませんが、投票したIPは知る由が無いのでIPでの比較は無意味かと思います。

37 ：

試しにコード取ってみた感想。
コード発行までに画像認証120秒制限で二回必要なのは手間すぎと思った。
個人的にみかかなのもあるけど。
アルファベット確認しながら打つの面倒よ。
待ち時間だかなんだかの説明書きがわかりにくい。
よくわからないからあせる。
試合当日で切羽詰ってたら、余計にあせると思った。

38 ：

追記
コード予約後に再度画像認証画面になったので、
予約がリセットされてしまったのかとも思った。

39 ：

>負荷はたぶん増えてます。
この場合、cgi側にメリットは無いという事ですね、了解です。
逆に、串を使ったDosによるコード鯖落としも考えられるので、
そういう事なら外した方がいいのかも。

40 ：

>>37-38
意見ありがとうございます。
画像認証に関しては導入確定ではありませんが、仕様の都合上認証2回or0回のどっちかとなります。
待ち時間の説明書きはindex.htmlにベタ打ちなんでわかりやすく綺麗に書くことは簡単です。
現在はただのメモ書き程度で読みづらいのは承知の上ですので後々改善します。
>>39
その通りです。cgi側はデメリットとも言えます。
Dos攻撃に関してはサーバー側の設定の問題ですのでコード発行cgiは関係ないです。
その件に関しては◆AGA/Iky.aoさん次第ですね。

41 ：

あれ、日本語がおかしい^^;
>cgi側はデメリットしかないとも言えます
の間違いです。

42 ：

BBQに関する勉強をちょこっとしてる所です。　遅くなり申し訳ありません。
基本的に、串による不正行為が規制できるなら付けて欲しいが、
そのせいで発行所スクリプトが動かなくなってしまうのなら使えないですね。
あとは、BBQの鯖落ちが投票所や発行所の鯖落ちと同じに扱えるのかが気になります。
146さんにお聞きしたいんですが、
今現在のスクリプトではBBQ鯖が落ちた時に
「コードが発行するのか、発行されないのか、
発行されてもそれが試合終了時の発行コードリストに反映されるかも不明」な状態という事でしょうか？
あと、BBQ鯖が今までにどれだけ落ちたのか実績調査中です。
詳しい方がいらしたら「去年このぐらい落ちてたよ。」とか感覚的な見積りでいいので教えてください。

43 ：

>BBQ鯖が今までにどれだけ落ちたのか
BBQ（に関わらず2chの鯖全て）が落ちるかどうかなんて、神のみぞ知る
ってな状況じゃないかと…
ましてや、全板のような長丁場では先の事なんて判りようも無いｗ
もし、BBQが落ちたら発行所側はどうするか？
というポリシーを決めて運用を整備して、コード側のコーディングを
お願いするしかないかとｗ

44 ：

お疲れ様です。
今現在ではBBQ鯖が落ちたときは、
「コードが発行/予約が正常にされる保証ができない」といった感じです。
現在PCアクセスからの処理の順序は
CPATCHA -> ProxyCheck (BBQはここに組み込んでます) -> コード予約・発行
となっております。もし、予約・発行まで行けば発行コードリストには反映されると思います。
BBQ鯖が落ちたときはProxyCheckの段階で止まってしまうため、
予約・発行が一切できなくなる可能性があります。発行まで行って、コードリストに入らない事は無いと思います。

45 ：

Net::Pingを使ってBBQ鯖に事前にping打ってから〜ってのも考えてみたのですが、
発行・予約する度にping打って確認していてはお話にならないので良い案が出てきません。
また、仮にpingを組み込んでも、BBQ鯖が再起動した時、
鯖復旧とBBQシステム復旧の間にラグが有った場合結局コード発行システムが予期せぬ動きをする事になってしまいます。
>>43
「BBQが落ちている間はやむを得ないのでコードを発行する」
というポリシーで良いかと思いますが、その判定方法が難しいですね・・・
反応が2分間も帰ってこないようではお話にならないですし・・・

46 ：

>ping打ってから
ネットワークが生き返っても、BBQ鯖から応答が帰らないと
コード発行所側は困った事になるんじゃないかとｗ
詰まる所、「2ch 鯖監視係。」さんみたいに鯖の生死を
監視できる仕組みが必要じゃないかとｗ
ダメモトで雪だるまスレに持って行っていくとかｗ

47 ：

ttp://sv2ch.baila6.jp/sv2ch12.html
未承諾さんのを参考にして仕様を決めるのもアリかなｗ
基本的に、BBQ鯖の生→死、または死→生を判定できれば良いから、
1.pingを規定時間間隔で打つ（投票のアクセスとは関係無しに個別処理）
2.応答結果をステータスリストに持つ
3.コード発行時にリストを参照して、ステータスの変更があれば
　鯖の状態を見に行く（ここら辺は未承諾さんの仕様を参考に）
　　※当然、”死”と判定された期間の運用を事前に決めておく
ってな感じで如何でしょうかｗ

48 ：

>>45
逆の「BBQが落ちている間はやむを得ないのでコードを発行しない」というポリシーが実装可能なら、
前回のルールに
・12時間以上にわたり板やコード発行所が利用出来ず投票が中断した場合は投票不成立とし、後日再投票とします。
　中断時間が12時間以内の場合は投票成立とします。
というのがあり、これの投票所板やコード発行所にBBQ鯖を加えてしまう方法もありかなと思うんですが。
（12時間というのをそのままキープするかは別途運営スレで話し合うとして）
ただし、BBQ鯖がちょくちょく落ちるような不安定なシステムだと、
こうゆう運営ルールでやっていくのは辛いですね。

49 ：

>ネットワークが生き返っても、BBQ鯖から応答が帰らないとコード発行所側は困った事になるんじゃないかとｗ
45の3,4行目の事ですか？仰るとおり困ったことになります。
　 　　　　 |
　 　＼　　__　　／
　 　＿　（ｍ）　＿ﾋﾟｺｰﾝ
　 　　　　|ミ|
　 　 ／ 　｀´　 ＼
　　　　　('A`)
　　　　　ノヽノヽ
　　　　　　　くく
Net::DNS使ってタイムアウト値を短くすれば・・・！

50 ：

…あ、まずいかも
>CAPTCHA -> ProxyCheck (BBQはここに組み込んでます) -> コード予約・発行
このタイミングだと、ステータスリストのロック/リリースタイミング次第で
不都合が起きるかもｗ
コード予約されている場合のみ、次のBBQチェックが走らないようにしないと
マズいですよねｗ

51 ：

一度クールダウン…
そもそも論として、”BBQを組み込むか否か？”はどうなるんでしょう？
・BBQ導入時のメリット
　2chのポリシーに準じているので、「コードは取れるのに投票できないぞｺﾞﾙｧ」
　という難民を防げる
・BBQ導入時のデメリット
　コード発行所側の負荷が上がる
　BBQ鯖が死んだときの処理/生死監視の処理を組み込む必要がある
　（当然、コード発行処理が膨らみます）
という所が思い浮かぶわけですが

52 ：

>>48
FOX★の昔の書き込みを参考にしてみたところ
1. Net::DNSでtcp_timeout(1)、udp_timeout(1)、retry(1)
2. BBQ処理前に投げてtimeout判定が出た場合はBBQ処理を中止。
これで「BBQが落ちている間はやむを得ないのでコードを発行しない」
というポリシーが実装可能な気がしてきました。

53 ：

>>51
主催が
>基本的に、串による不正行為が規制できるなら付けて欲しい
と言っているので組み込む方向で検討しています。
>「コードは取れるのに投票できないぞｺﾞﾙｧ」という難民を防げる
2chに書き込まずに投票だけする人口は少数だと思うのでメリットと呼べる程ではないと思います。
BBQによるメリットデメリット：
[メリット]
- 純粋な多重抑止効果が見込める(投票所のBBQがオフの場合のみ)
- 余計なコード発行を防ぐ効果が見込める(BBQ規制されているIPでコード取得 -> 品切れで発行できなかったIPからの投票を防げる)
[デメリット]
- 巻き添えｶﾜｲｿｽ
- コード発行cgiの負荷が増える。
- BBQ鯖が死んだ場合、
　 1. cgiプロセスをkillされて発行所停止
　 2. 約2分間アクセス者を待たせて恐らく処理が続行（？）となる。
　 のいずれかの状況に陥る。っがこれはなんとかなる見込みは立ってきた。

54 ：

[[3rdtest17-jJHizgtw-HB]]
おはようございます。
忘れないうちに<<BBQ>>が死んでいる場合の対策を入れてみました。
無理矢理詰め込んだ感が否めませんので正常に動作しないかもです。あまり自信無いです。
とりあえずコードは取得できているのであとはBBQ鯖が落ちてみないとわかりません。
組み込んだBBQ機能について簡単な説明します。
(1) Proxy判定直前(CheckProxy内)で、$Setbbqが有効の場合にbbq判定処理開始
(2) 判定ホスト文字列を作成
(3) Net::DNS呼び出す。tcp_timeout,udp_timeout,retryは全て1(本番環境の場合presistent_tcp,presistent_udpも有効にするかも？$SetbbqPで制御)
(4) (2)のホストをNet::DNS::Resolverでquery。
(5) query結果errorstringが'query timed out'で無い場合BBQ処理続行 -> (6)
　 query結果errorstringが'query timed out'の場合＋さらに$SetbbqXが有効の場合は$ProxyStr="51"; return(51); -> (7)。$SetbbqXが有効で無い場合はProxy判定処理へ。
(6) 帰ってきたアドレスをチェックして127.0.0.2だったら$ProxyStr="50"; return(50);。127.0.0.2じゃなかったらProxy判定処理へ。
(7) $ErrorCode == 50でBBQに引っかかっている/$ErrorCode == 51でBBQ落ちているメッセージを出力。
現在のBBQ周りの設定は$Setbbq = 1; $SetbbqX =1; $SetbbqP = 0;となっています。

55 ：

とりあえずBBQが落ちている間のポリシー、
「BBQが落ちている間はやむを得ないのでコードを発行しない」/「BBQが落ちている間はやむを得ないのでコードを発行する」
はcodeconfig.cgi側で簡単に切り替えられるようにしてあります。
他実装すべき機能が無ければ名無しに戻りますが何かありますか？

56 ：

＞- 巻き添えｶﾜｲｿｽ
ちょっとこれが分からない。　一応2chの荒らしとかの規制とBBQは別物だぞ

57 ：

接続が変動IPである限り、過去に焼かれたIPにぶつかる可能性が少なからずあると思います。
これもまたレアケースですが、原則規制解除のないBBQではありえなくもないと思いデメリットに入れておきました。
私のBBQに対する認識違いであって、そんな事無いのであればそれに越したことはなく、デメリットはCGI負荷のみになりますね。

58 ：

コード処理のたびにBBQ鯖を見に行くの?
投票者が殺到したらバーボン食らう予感w

59 ：

はい、コード予約時・発行時毎回見に行きます。
BBQ側からのアクセス規制はあるかもしれませんね。
事前にFOX★に断っておいた方が良いかもしれませんね。
許可が出るかどうかはまた別ですが。

60 ：

>>57
すいません、私もあまりBBQについて詳しくないので、今見ている最中です。
＞接続が変動IPである限り、過去に焼かれたIPにぶつかる可能性が少なからずあると思います。
この場合、変動IPだけど自分でIPを変更できない人もいるかと思います。
参加者からの自己申告によってIPを登録して、
該当するIPの人はBBQを含んだPROXYチェックをしないという機能を実装する事は可能ですか？
BBQを使う場合はFOXさんにお伺いする必要があるという事は理解しました。

61 ：

>参加者からの自己申告によってIPを登録して、
>該当するIPの人はBBQを含んだPROXYチェックをしないという機能を実装する事は可能ですか？
可能ですが、焼かれているIPを登録されて悪用されかねないですね・・・
いちいち自己申告されたIPを誰かが許可するのもかなり手間がかかりそうですし・・・
FOX★に伺うのは本番鯖の鯖を借りたあとが宜しいかと思います。

62 ：

>>61
ありがとうございます。
みんな、待ち時間10分固定がいいんですかね。
私としては初期の参加ハードルを下げる事で多くの参加者を募り、
トーナメントの楽しさをみんなが覚えた頃に厳しくしていくのを考えています。
トーナメントの予選と本選で投票所の仕様を変えて
予選：　5分固定　画像認証なし　BBQあり
本選：　10分固定　画像認証なし　BBQあり
準々決勝以降：　10分固定　画像認証あり　BBQあり
なんていう案はどうでしょうか。　BBQはFOXさんからNG出たらなしにします。
ご意見お聞かせください。＞ALL

63 ：

>>62
オーケーです。
画像認証に関して試行回数と制限時間はどういう値を考えていますか？

64 ：

すいません、忘れてました。
画像認証の試行回数を上げる事がスクリプト対策を弱めないということなら、
試行回数15回・30秒でもいいかなと思ってます。
人の目で見て判断が難しいのは0, 1, I, L, Oの5種類。
画像に使われるのは26＋10の36文字。
5文字長の画像の中に困難文字が一つも出ない確立は(31/36)^5=0.473
逆に5文字長の画像の中に困難文字が一つでも出る確率は1-0.473=0.523
試行回数5回で毎回困難文字が出る確率は0.523^5 = 0.039　25人に1人は毎回困難文字に当たります。
試行回数10回で毎回困難文字が出る確率は0.523^10 = 0.002　500人に1人は毎回困難文字に当たります。
試行回数15回で毎回困難文字が出る確率は0.523^15 = 0.000059　1万6千人に1人は毎回困難文字に当たります。
試行回数20回で毎回困難文字が出る確率は0.523^20 = 0.000002　40万人に1人は毎回困難文字に当たります。
0, 1, I, L, Oの文字を使わないような画像を用意する人が誰もいないので、
このぐらい余裕持たせてあげてもいいかなと思いました。
画像認証の試行回数をあまりにも増やすことで特に問題とかありますでしょうか？

65 ：

＞25人に1人は毎回困難文字に当たります。
平均的な確率ですね。　書き方が変で申し訳ないです。

66 ：

画像認証は
あるのならずーっとある　ないならずーっとないほうが
わかりやすいと思う

67 ：

気になってみて試行を1000回まであげてみてリロードしてみた結果、
一向に出て来ない特定文字があると判りました。ごめんなさい、下調べ不足でした。
Authen::Captchaで公開されている情報なのでもう書いちゃいますが、有効な文字は
0と1をのぞいた数字と全ての小英字、これによって実質判別し辛い文字は無くなると思います。
これらをあらかじめ宣言しておけば全34文字判別が可能かと思います。

68 ：

途中で送信してしまいました。
勿論判別し辛い回とかあると思いますのである程度試行回数は必要かと思いますが、
3〜５回で十分かと思います。

69 ：

画像認証に関しては試行回数を上げたところで
ほぼストレス軽減にはならないというのが俺の感想
実際に試行回数のせいで引っ掛かり
投票できなくなるというのは稀
そういうことではなく、一回目で1とlが判別つかなくて
(何回かやらせてもらったけどiとj、6とG、1とrなんかもわかりにくいようになっている)
ちゃんと打ち込んでるつもりでもやり直しを強制させるところにストレスが貯まる
後は2回も画像認証させるのは、うpロダとか見ても少ないと思うし
2回認証が仕様で1回にはできないというのなら
やめた方が賢明だと思う
なぜこんなガチガチにするんだという印象

70 ：

予約導入と一緒、コード取得を自動的に出来ないようにするようだための方策

71 ：

俺も一回ならばしょうがないと思うけど
二度もさせるのはちょっと…と思う
一度だけに出来る場合→やる
二度しないと出来ない→やらない
がいい。

72 ：

コード取得方法を前回と同じにしたらどうなるかは、
他のトナメで実績が有り余るほど在るわけで…
自分としては画像認証の導入を希望します。
>62
コード取得の条件を変える事はあまり良い事だと思えません。
上記の通り、最初から導入に１票です。

73 ：

BBQはない方がいいですが必要で認められるならいいです。
画像認証はいらないです、もし導入されるならコード待ちとどちらかにすべきです。
トーナメントばかりやっていて普通の考え方ができない人が多い気がします。
不正を見て見ぬふりできないなら不正が行われても気づかない優しい嘘の方がいいです。
プロバイダ別のコードとか携帯とPCが判別できるから荒れるのです。
これ最強を決めるのではなくてお祭りなのでしょう？
そんなに不正や多重がお嫌いならフシアナ投票必須にでもして下さい。
落とし所を過去のニートトーナメントの経験値で語られても困ります。

74 ：

>>71
と同じ感覚かな
画像→無しがいい
画像一回→どうしても必要ならば、まあ仕方ない
画像二回→パス
あと他のトナメでの実績はあんまり意味ないというか
言われてピンと来る説得力はないように感じる
全板トナメ厨というのは全板トナメ厨であって
他のトナメに興味なかった人も多いだろうし
一般のトナメ厨ですらない全板だけの参加の人は尚更
コード待ち時間は固定がいいが
予選と本選で変えるくらいならば、構わない。
第一回も予選コード無し→本選コードありに変えたように
本選になるとちょっと雰囲気変わるから

75 ：

画像認証30秒はきついです。
当方カナ打ちなので、アルファベットは確認しながらじゃないと打てません。

76 ：

最近家にいる時は発行所cgiを眺めていでようやく発行所cgiの全体が判ってきました。
結論から言いますと仕様上1回表示にできなくもないです。
私が実装可能なパターンは２つあります。
一つは処理も楽だけど画像認証突破の糸口を作ってしまう＝画像認証の意味が無い
もう一つは突破は恐らく無理だが発行所cgiの負荷が増える。＝応答が遅くなったり停止させられたりする可能性が増える
いずれにせよ、アクセスがあるごとに呼び出される処理がまた１つ増えるのでどちらにの案も、
メリットに対するデメリットが大きすぎると感じるので却下です。
>>75
何秒なら間に合いますか？
秒数は調整可能です。

77 ：

全板が特別なトナメであるワケでは無いし、また2chの内外から
参加者が集まるトナメという本質は変わらない訳で。
また、参加者がトナメ慣れしていないという事は、逆に言えば
その時のルールがオンリーワンなワケで、（他と比較して）
不便と感じるとも思えません。
そして、画像認証無しで実施した場合、殆ど確実に
（そして前回よりも早期、かつ大規模な）
多重が問題に上るでしょう。
そのリスクが予期できる状況で不採用というのは、
オススメできないです。
最後は主催者さんの意見に従いますが、
一応意見として出させてもらいました。

78 ：

別に画像認証しようがしまいが多重は確実に問題になるよ
荒らしは多重ネタ使うのは分かり切っている事だし
そうじゃない一般の人でも、話題にしやすいのは前回前々回で分かっている事
ちなみにどっちに決まってもいいけど
画像認証は面倒くさいというのが正直な所
アカウント取ったりブログコメントしたりでは慣れてるけど
投票という行為がコード発行所に行って→色々して→待って→取って→
投票スレ探して、そこに規定通り投票してという色々面倒なものがあるのに
画像もかよって感じがする

79 ：

>>72
> 他のトナメで実績が有り余るほど在るわけで…
これは最萌のことかな？
最萌未参加(待ち時間2時間が耐えられずやめた)の俺としてはそんな実感ないけど・・・
まぁいずれにせよ閉鎖的になるのは勘弁だなぁ
画像認証までついてしまうと、恩返しの一票とかやってくれる人が減りそう

80 ：

俺も画像認証は面倒だな
決まったらしょうがないけど
それと再萌経験ある人と
全板だけの人の温度差があるような気がする
再萌はキャラへの愛が前提にあるけど
全板はもっとライト層をいかに動かすかが焦点というか

81 ：

俺は最萌経験者だが2ちゃん関係の萌系トナメで画像認証使われたことないよな？
実績というのが何を指すのか今一不明…
それはともかく、画像認証はなくてもいいと思うが
必用派と不要派の意見は平行線な気がする。
今まで2ちゃん内のトナメでは導入されたことの無いものを有用であるか否かと議論するんだから、その効用や有効性、予想される影響等についてはどちらの主張も
仮定論というか、憶測の域を出ない面がある。
ある程度議論したら主催がすぱっと決めてもいいんじゃないか?
俺個人の意見としては"不要"と捉えているよ。

82 ：

>>81
そうだったのか
なんとなくのイメージで最萌ではそういうのが当たり前の世界なのかと思ってた

83 ：

ちなみに自分も不要かな
主催判断に任すけど
多重問題ってどうしても完全な対応が出来なくて
多重推奨という訳じゃなくても、そこそこの所で止めた方がいって派と
やれるだけは対策した方がいいって派の温度差あって
どこで切るかの感覚は平行線だとは思う

84 ：

言わんでいいかもしれないけど82=83

85 ：

>>76
少なくとも1分は欲しいです。
画像認証そのものについては、私も不要かなと思いますが。
散々言われているように、あんまりギチギチにしたのでは、
全板は成り立たない気がしますね。
参加者任せの部分が少ないと、どうしても面白さも減ると思います。
それは、規模の縮小につながり、更に面白くなくなり、
と、ループするんじゃないでしょうか。

86 ：

皆さんの言われてることは判ります。
結局のところ、コード取得方法を複雑にするコトによって
>面白さが減る
というコトだと思います。
ただ、もし1000人のうち1人が不正を働いても結果に影響は与えないでしょう。
（逆に、そんなコトになれば多分バレバレ）
ですが、1000人のうち10人や20人が不正を行えば、結果が変わるかもしれない。
そんなコトを知ったら、ライト層はすぐに離れていくと思います。
画像認証は試合を楽しむための一つのルールと言う、
そういった側面も含めて考えていただければ、と。

87 ：

>>85
>少なくとも1分は欲しいです。
ありがとうございます。本戦のパラメータ設定の参考にさせていただきます。

88 ：

うーん　今のネット環境考えると
暴走が一度始まる止まらないんだよね
（止めようと思うと、その一言で炎上したりするしね）
その暴走の予防線を張るのには、別にいいんじゃないのかな？
暴走されてトナメが立ち行かなくなっても、人が集まらなくてつまんねってなっても
叩かれるのは主催でしょ
ここでうだうだ話してるやつがケツ持つわけじゃないし、いろいろメリット・デメリットを淡々と上げていけばいいんじゃないの？

89 ：

>>86
それは皆分かっていて前提の元
でも、画像認証は別に不要じゃないかと思うって言っているんだろ
多重対策だったら携帯からオンリーにした方が
多重の影響が減ると言われても、いや、それは…と思う人がいるように
画像認証にした方がいいんじゃないかに対して
いや、別に…面倒な割にそこまでの対策にならないし…と思う人がいるだけ
多重が完璧に防げるならばいいけど、どうせ防げないならば、
がちがちの対策をして、多重厨に頑張らせるよりも
より参加しやすくして、一般参加層を増やす方がいいと思う人がいるだけ

90 ：

で、皆が言ってるように、この件は感覚の違いが平行線だと思う
（初期話していた、何分ならば待てるかの感覚の違いと同様に）

91 ：

全ひらがなで実際にコード取得してみて思った
画像認証ってかなりウザイな
全板と最萌の感覚の違いがあるのかもしれない

92 ：

1000人のうち10人や20人が手動で多重するのは全板の醍醐味の内だと思うけど
画像認証入れないと1000人のうち1人の不正で結果をひっくり返せるから問題になっているのではないかと

93 ：

こんなはじまる前からここでうだうだ言ってる自分ですら
うざいと思うから、普通の人は画像認証はもっとうざいと思うだろう
>>92
その話は平行線
個人的には主催判断だな

94 ：

俺も不要と思ってるが
主催が決めた事には従う。

95 ：

画像認証を使う使わないの意見はよく分かりました。
みなさんありがとうございます。
画像認証をトーナメント前半はOFF、後半はONにする事に対しては、
賛成意見がなく反対意見が少しあります。
賛否どちらでもかまわないので、途中で変更する事によるメリットやデメリットについて
ご意見ください。

96 ：

本選やベスト16あたりの再抽選時などの区切りのいいところで変えるなら
公式サイトに注意書きさえあれば何も問題はないと思います

97 ：

自分は画像認証が面倒だと言った者ですが
変えるならば区切りいい所ならばいいと思います。
ベスト16くらいならば、それなりにもう皆投票行為に慣れているだろうね
わかりやすいのは本選から？

98 ：

画像認証に関しては最初から入れるか
最初から入れないかの2択しかないだろ
ただでさえ面倒なもんを途中から入れたらさらに混乱するぞ
どうしても導入したいのなら最初から入れとけ
俺は最初から無い方がいいけどな

99 ：

入れときゃいいんだよ、全板トナメも三年たったら
こんなに進化したんだと思ってくれるよ、
新規は知らないけど

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【alone】孤独な男性板の名無し投票所 (239)
モー娘（狼）の看板募集2 (259)
【投票所】そろそろゲハの看板を換えよう　決選投票 (750)
エレファントカシマシ名曲ランキング (480)
ハングル板ローカルルール変更投票スレッド (323)
【あなたの】国鉄・JR車両投票スレ【好みは？】 (297)
--log9.info------------------
茶香炉 (328)
【癒し板名物】45猿専用スレ【盛大にドピュッ＞＜】 (292)
大阪・キタ周辺のマッサ店【梅田、天満etc】3 (573)
安田隆 The ARK Company 2 (574)
【当たりは】イマジン＠五反田【元宝塚】 (770)
【名古屋】メイドリフレクソロジー総合　Part36 (501)
【秋葉原】ンイネ屋【AﾉKｸﾞﾙｰﾌﾟ】 (543)
【出張】さくらメイド【新宿】 (341)
【吉祥寺 国立 荻窪】セレブ part2 (619)
【秋葉原】 すた★ぷろ　8時間目 (1001)
【大阪】カーテンコール【梅田】 (432)
◆大阪◆日本橋◆リラクゼーション184◆ (454)
◆大阪◆日本橋の癒し◆PART4◆ (923)
【横浜】横浜TAO (211)
【大阪】癒しの夢【難波】 (435)
【新宿】メイドリフレ　プリティキャロット 4 (443)
--log55.com------------------
【スズキ】クロスビー【XBEE】Part29
《》Renault Twingo/ルノー トゥインゴ Part31《》
【TOYOTA】トヨタ Tjクルーザー Part11【TJ】
【NISSAN】 日産 FUGA (フーガ) Y51型 【第32楽章】
■死んだ?■どうした!?日産27■放置プレー?■
【本スレ】シトロエンCシリーズスレpart79
【HONDA】ビートを語れ! ver.119【BEAT】
【HONDA】10代目シビック/CIVIC 51【FC1,FK7】