OpenIDでテキストを共有できます
- 新規作成
- OpenIDで認証してエントリーを新規作成します
- 共有
- エントリーにはOpenIDで閲覧と編集に制限かけることができます
- 変更履歴
- 編集履歴もあるので、コラボレーションにも活用できます
新着エントリー
ギルティドラゴン 確率メモ
ギルドラ確率厨のメモです。
前提
デッキのフリーポケットを1色で統一した単色デッキについて考えます。
フリーポケットに入れた色=メイン色
その他の2色=サブ色
単純な考え
単色はデッキに16枚。サブ色は8枚+8枚の合計16枚。ドローする時の単純な期待値はメイン色50%、サブ色A25%、サブ色B25%となります。
初手は8枚ドローの期待値は、メイン色4枚、サブ色各2枚となります。
ドロー5でのチャージの期待値はメイン色2.5枚。ドロー4なら2枚となります。
この基本的な考えに加えて、その時の状況によって変化する部分があります。
デッキに何色が何枚あるかによって確率が上下したり、連続で引かなければならないときなどです。
初手の確率
| メイン色 | 確率 | 備考 |
| 0枚 | 約0.122% | サブ色のどちらかが4枚以上あるはずだからそれで乗り切ろう |
| 1枚 | 約1.740% | サブ色のどちらかが4枚以上あるはずだからそれで乗り切ろう |
| 2枚 | 約9.136% | サブ色各3枚なら相手の事故を祈るか、多色チャージで凌ごう |
| 3枚 | 約23.255% | メイン色を選んでチャージに賭けよう |
| 4枚 | 約31.492% | 平均的初手 |
| 5枚 | 約23.255% | 最高のアタックパワーを期待できる攻撃的な初手 |
| 6枚 | 約9.136% | 次のターンのリーダーを含めた選択肢の広い初手 |
| 7枚 | 約1.740% | チャージ枚数の期待値が下がる初手 |
| 8枚 | 約0.122% | 一色に染まった綺麗な手札を見て心を癒す初手 |
1ターン目の各種状況による確率
初手332(メイン色3枚)
- メイン色を選び、1枚もチャージできずに詰まる確率=最初にドローされる2枚がともにサブ色である確率は約19.928%
- メイン色援軍Lv3を選び、ドローした3枚ともサブ色の確率は約8.152%
- さらにその状態から、1枚もチャージできずに詰まる確率=最初にドローされる2枚がともにサブ色である確率は約13.333%
初手332(メイン色2枚)
- 仕方なくサブ色を選び、1枚もチャージできずに詰まる確率=最初にドローされる2枚がともに別色である確率は約55.435%
- メイン色援軍Lv3を選び、ドローした3枚ともサブ色の確率は約5.929%
第47回新潟記念(GIII)
| 馬名 | 性齢 | 重量 | 騎手 | 所属 | 前走 | |
|---|---|---|---|---|---|---|
| エオリアンハープ | 牝5 | 木幡 | (東)宗像義 | 天の川1 | ||
| オペラブラーボ | 牡7 | 中舘 | (東)久保田 | 七夕賞8 | ||
| サトノフローラ | 牝3 | ○○ | (東)堀宣行 | 関屋記3 | ||
| サンライズベガ | 牡7 | 北村宏 | (西)音無秀 | 小倉記15 | ||
| シャイニングアワー | 牡6 | ○○ | (西)羽月友 | マリ-ンS10 | ||
| シャイニーブラウン | 牡6 | 石橋脩 | (西)平田修 | 天の川2 | ||
| セイクリッドバレー | 牡5 | 丸山 | (東)高橋裕 | 関屋記5 | ||
| (地)タッチミーノット | 牡5 | 三浦 | (東)柴崎勇 | 七夕賞2 | ||
| (地)トウカイプライム | 牡6 | 柴田大 | (東)成島英 | 天の川7 | ||
| トウショウウェイヴ | 牡6 | 吉田豊 | (東)大久洋 | 函館記15 | ||
| ナリタクリスタル | 牡5 | 武豊 | (西)木原一 | 小倉記6 | ||
| プティプランセス | 牝5 | 武士沢 | (東)伊藤正 | 信濃川1 | ||
| ホワイトピルグリム | 牡6 | 田辺 | (西)鮫島一 | 小倉記9 | ||
| ミッキーペトラ | 牡5 | 柴田善 | (西)森秀行 | 函館記16 | ||
| ヤマニンキングリー | 牡6 | 田中勝 | (西)河内洋 | 小倉記4 | ||
| Bワルキューレ | 牝7 | 岩崎 | (西)佐山優 | 小倉記8 |
- 馬柱2chから。
- セイクリッドVSタッチミー
- えおりん&サトノ⇒ハンデ次第
- 新潟巧者サンベガ状態どうなのか
- キングリー新潟外回りどうか
- つか札幌記念出とけよ。
plackup-nagios-web
use Plack::App::CGIBin;
use Plack::Builder;
my $cgibin = Plack::App::CGIBin->new(
root => "/usr/local/nagios/sbin",
exec_cb => sub { my $file = shift; $file =~ m!\.cgi$! and -x $file },
)->to_app;
my $static = Plack::App::File->new(root => "/usr/local/nagios/share")->to_app;
builder {
enable 'ReverseProxy';
enable sub {
my $apps = shift;
sub {
my $env = shift;
$env->{REMOTE_USER} = 'xxxxx';
$env->{PATH_INFO} .= 'index.html'
if $env->{PATH_INFO} =~ m!^/nagios/([^\.]+/)*$!;
$apps->($env);
};
};
mount '/nagios/cgi-bin' => $cgibin,
mount '/nagios' => $static,
}
Q4Mのinstall
試したのはubuntu 10.04にて
$ apt-get install libmysqld-dev $ mysql_config --libs --include --plugindir -Wl,-Bsymbolic-functions -rdynamic -L/usr/lib/mysql -lmysqlclient -I/usr/include/mysql /usr/lib/mysql/plugin $ cd /tmp $ wget http://q4m.kazuhooku.com/dist/q4m-0.9.5.tar.gz $ sudo apt-get source mysql-server $ ls -1 mysql-dfsg-5.1-5.1.41 q4m-0.9.5.tar.gz $ tar zxf q4m-0.9.5.tar.gz $ cd q4m-0.9.5 $ CPPFLAGS="-I/usr/include/mysql" CFLAGS="-L/usr/lib/mysql" ./configure \ --with-mysql=/tmp/mysql-dfsg-5.1-5.1.41 \ --prefix=/usr $ make $ cp src/.libs/libqueue_engine.so /usr/lib/mysql/plugin $ cat support-files/install.sql| mysql
MySQLのソースはビルドしなくても入るっぽい
サーバが死んだ(運用屋さん)
「サーバが死んだ(運用屋さん)」「サーバが落ちた(プログラマさん)」 「サーバが飛んだ(ハード屋さん)」「サーバ壊れた(機器管理の事務員さん)」「サーバ動かない(ユーザさん)」と言う法則を目の当たりにしておりまする。様々
http://twitter.com/itimasan/status/91334502445613057
つまり、
- 「サーバが死んだ」=> サーバを擬人化
- 「サーバが落ちた」=> サーバを隷属化
- 「サーバが飛んだ」=> 電気的、物理的に飛んだ
- 「サーバが壊れた」=> 理由はあまり関係ない
- 「サーバ動かない」=> サーバを使う側から見た現象
ということなのか
statusカラムとインデックスについて
statusカラムとインデックスについて。
CREATE TABLE entries (
id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
body VARCHAR(255),
category TINYINT NOT NULL,
status TINYINT NOT NULL,
created_at DATETIME NOT NULL,
INDEX(status)
) ENGINE=InnoDBここに、98%の確率でstatus=1、残り2%はstatus=0となるようにデータを5000行入れて検索する
テストはMySQL 5.5でやってます。
mysql> explain SELECT * FROM entries WHERE status=1; +----+-------------+---------+------+---------------+------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+---------------+------+---------+------+------+-------------+ | 1 | SIMPLE | entries | ALL | status | NULL | NULL | NULL | 5187 | Using where | +----+-------------+---------+------+---------------+------+---------+------+------+-------------+ 1 row in set (0.00 sec)
これは、インデックスを使っても絞り込めないので、テーブルスキャンとなる。
LIMITをつけると、インデックスを使う
mysql> explain SELECT * FROM entries WHERE status=1 ORDER BY id DESC LIMIT 100; +----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+ | 1 | SIMPLE | entries | range | status | status | 1 | NULL | 4899 | Using where | +----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+ 1 row in set (0.00 sec)
rowsが4899件とインデックスでは絞り込めていないようにみえるが、statusインデックスを後ろから100件読むだけで済むので効率は良い。実際ROW OPERATIONは100行になる。
つぎに、statusカラムではなく、FORCE INDEX(PRIMARY) を使う。
mysql> explain SELECT * FROM entries FORCE INDEX(PRIMARY) WHERE status=1 ORDER BY id DESC LIMIT 100; +----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+ | 1 | SIMPLE | entries | index | NULL | PRIMARY | 4 | NULL | 100 | Using where | +----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+ 1 row in set (0.00 sec)
rowsは下がるが、ROW OPERATIONは100+2(status=0を飛ばす分)のようだ。はてしてこれは上と比べてどの程度非効率なのかどうかが、よくわからない
データの論理削除のためにstatusカラムを用いることはあるとよく思うんだけど、検索条件に合わせてインデックスにstatusを追加していくのがよいか、ソート条件だけインデックスしてstatusのフィルタリングはMySQLに任せるか、アプリケーションのロジックでやるのも含めてどの手段がいいんだろうな
statusのある/なし分インデックスを追加するのはないと思うので、後者の2つがいいのかなと個人的には思う
nginxで http://example.com//foo/bar にきたリクエストを /foo/bar にredirectする
nginxで http://example.com//foo/bar にきたリクエストを /foo/bar にredirectする
location / {
if ( $request_uri ~ ^// ) {
set $doubleslash "R";
}
if ( $request_method = GET ) {
set $doubleslash "${doubleslash}M";
}
if ( $doubleslash = RM ) {
rewrite ^/(.+)$ /$1 redirect;
}
}nginxのifは複数の条件をいれたり、nestしたりできないので大変
参考 http://rosslawley.co.uk/2010/01/nginx-how-to-multiple-if-statements.html
rake もどき
###=========================================== $tasks = {} def task( task_name , &task_block ) if String === task_name name = task_name $tasks[name] ||={} $tasks[name][:deps] = [] $tasks[name][:task_block] = task_block else name = task_name.keys[0] $tasks[name] ||={} $tasks[name][:deps] = task_name[name] $tasks[name][:task_block] = task_block end end def run_task( tasks ) if String === tasks run_task( $tasks[tasks][:deps] ) $tasks[tasks][:task_block] && $tasks[tasks][:task_block].call() else tasks.each do |name| run_task( $tasks[name][:deps] ) $tasks[name][:task_block] && $tasks[name][:task_block].call() end end end ###=========================================== task "default" => "dist" task "dist" => ["init", "compile"] do puts "-- make distribution --" end task "init" do puts "-- initialize -- " end task "compile" do puts "-- compile --" end ###=========================================== run_task("default") #or # run_task(ARGS)