【ORACLE】テーブル容量の確認２
前回のやつは、
テーブル名を与えたらそのテーブルの全項目に対するNVL(LENGHB(COLUMN_NAME),0)を作ってくれるが、
その後先頭に「SELECT」と最後尾に「FROM [テーブル名]」を自分でつけて自分でSQLを流すという作業が必要だった。
そこまで含めて完全自動化できそうだったのでやってみた。
ストレイテナーと確率８（連続の確率）
なんかシャッフルで聴いていると
重複度が２以上の曲A（シングルとアルバムで２つ持ってるとか）があったとき、
あるタイミングでAが再生されるとその次かその次の次あたりでまたAが流れることが多いように感じる。
例えばストレイテナーと確率１ではSILLY PARADE（重複度２）の連続再生確率を計算したが、
その確率は約0.00367%という結果になっており、100000回（10万回）に３回くらいしか起きない。
この値からすれば「連続再生」はかなりレアだと思うのだがどうも聴いているとよくこういう現象にあたる気がしてきた。
「直近で聴いたことあるから耳に残ってる」ということで印象に強く残るのかもしれないが、
そもそも連続再生に対する遭遇率が低いんだし、現象が発生しなければ印象に残るもくそもないと思うのだ。
SILLY PARADEは重複度２なので、１曲どこかで再生されると残りは１曲となり、
それがしかも連続するとなるとかなり低確率であることは計算するまでもなく感じ取れるが、
ストレイテナーと確率５で確認した結果では手持ちのストレイテナーには重複度３の曲（CLONE等）もあり、
こっちの連続再生はSILLY PARADEに比べれば少し高い感じもする。
また、冒頭述べたように、「連続」でなくても、
CLONE⇒（なんか別の曲）⇒CLONEというように間に１～２曲挟むパターンにもよく遭遇する印象がある。
こういったパターンも加味して、今回は「連続の確率」というのに着目してみたい。
軍師官兵衛に出ている小寺の家来の人って？
もすうぐ終わる大河ドラマ「軍師官兵衛」であるが、
嫁さんがハマっちゃって録画したりDVD借りたりしてまで見逃すまいとしており
俺もそれに付き合って最初から全部見ている。
最初は意味もなく「大河ドラマｗｗｗｗ」って感じだったんだけど見始めると面白いねこれ。
というか、大河ドラマを真面目に見たのって多分これが生まれて初めてだと思う。
他の大河ドラマもそんな感じなんだろうか。
巷では大ヒットとなったらしい「竜馬伝」すらマジで全く１秒も見ていないが、見続けてると面白いんだろうなあ。
※というか「大ヒットとなったらしい」ってのも噂で聞いた程度でデジタルな評価を知ってるわけではないのだが
IPPONグランプリのバカリズム
最近嫁さんが家でIPPONグランプリのDVDを見ている。 俺も一緒になってたまに見る。 見ていてなんとなく目につくのが、バカリズムがIPPON取
【UNIX】Tera Termマクロ（ttl）のメモ
昔TeraTermマクロ（.ttl）を使う機会があったので少し勉強した。
備忘のためそのメモを載せる。
Tera Termでサーバに接続してから行う一連の動作を「.ttl」というファイルに専用の文法で記述することでマクロ化することができる。
Tera Termの作者のページにリファレンスが載っている。
ストレイテナーと確率７（ちょっと別の方向の話）
ストレイテナーと確率２では、
「60分以内に聴けるストレイテナーの曲は約14～15曲」という検証結果が出ている。
この「60分」とは、俺の１回の出勤ないし帰宅にかかる時間である。
ただ、１回の出勤で1からスタートして60分聴いた後、
その帰りにまた1からスタートして60分聴く、
というのは実はあまりやってない。
ある日の出勤時に1からスタートして聴き始めたら、
その帰りは出勤時の最後に聴いていた曲の続きから、
その翌日の出勤時は前日の帰宅時に聴いていた曲の続きから…、
という感じでいつも聴いている。
だから一回シャッフルで聴き始めたら最後の曲を聴き終わるまで基本的にリセットしていない。
※厳密に言うと”そういう聴き方をしていることが多かった”である。
今までの検証の流れを受けて現在は、
毎回リセットして60分以内に聴く曲を記録しているからである。
シャッフルでスタートして最後までリセットせずに聴き続ければ、
中の順番はランダムでも、（リピートしない前提で）手持ちの全楽曲の演奏時間の総和分、聴き続ければ、全曲聴いたことになるが、
60分聴くたびに毎回リセットして次また1からシャッフル再生…
とやっていけば当然前回までに聴いた曲が今回のシャッフル再生に入る可能性があり、
こういう聴き方をしていたら全曲聴き終わるまでどれくらいかかるんだろう？
というのがふと気になってシミュレーションしてみたくなった。
ちなみに手持ちのストレイテナー全曲の演奏時間総和は257曲で約17時間である（Behind The Sceneが入ったから18時間くらいになってるのかも）。
よって、１回のシャッフルで聴き続ければ中の順番がどうであろうと17時間で終わるが、
シャッフルで60分聴いてリセットしてまた最初からシャッフル→という繰り返しだとこれがどこまで広がるのかは気になる。
これは「60分で聴いてる曲のリスト」の記録を、どれくらい続ければ終わるのかという予想に繋がる話だが、
今までの確率議論とは少し外れるが、今回はそのシミュレーションをしてみたい。
Windows Liveフォトギャラリーのシャッフル設定の謎（バグじゃないかこれ説）
家のパソコンのスクリーンセーバーをWindows Live フォトギャラリーにして、 写真が入ってるフォルダの一番上のルートフォルダを指定して「コンテンツをシャッフルする」にチェックをいれている。 （↑の画像参照） この設定にしておくと、スクリーンセーバー中、使われる写真が毎回ランダムになって、いろんな写真を見ることができるのだが、なぜか必ず最初の一枚は絶対同じ写真になる。
ストレイテナーと確率６（３の続き）
ストレイテナーと確率３（「CLONEをよく耳にする」のは事実なのか？）の続き。
前回は「CLONE」という曲だけに着目したが、これを別の曲にしたときの考察を実施してみる。
手持ちのストレイテナー全２５７曲の中で、インスト除くと３つある「CLONE」は、
1つ目：平均64曲目、2つ目：平均128曲目、3つ目：平均192曲目
にそれぞれ選択されるということが前回の検証でわかっている。
CLONEは重複度３だったが、重複度が異なる別の曲だとどういう結果になるのか？
を試してみたくなった。
前回の結果を見て疑問に思ったのは、
1つ目：平均64曲目
2つ目：平均128曲目
3つ目：平均192曲目
というように、その差がきれいに64になっていることだった。
CLONEの重複度は３だから、
他の重複度の曲でやるとどうなるのか？実験してみたい。
ちなみにCLONE前提で考えていたので「どの曲か」の判定文字列はソースコードにべた書きしている。
ちょっと直してコンパイルかけるだけだからそれほど苦でもないが
こういう検証をするにあたっては外部から引数等でもらうつくりにした方が良かったなと感じた。（だが直さない）
※ただ、「ストレイテナーと確率３」で使用した検証用プログラムにおける
１試行結果を書き出す処理「（３）シミュレーション メイン処理」は
曲が可変（つまり重複度が可変）になることを想定してListを使用していたので
曲名部分の固定値を変えるだけで対応可能にはなっている
ストレイテナーと確率５（２と４の続き、まとめられる曲をまとめて再検証）
前回↓の続き。
ストレイテナーと確率２
ストレイテナーと確率４
前回の検証では、集計のKEY判定を収録されている曲名の文字列だけで行っていた。
よって、実際には（ほぼ）同じ曲なのに別々の曲として集計されていたり、
一方でオリジナルとアコースティックアレンジで別の曲なのに曲名が同じというだけで同じ曲として集計されていたり、
といった点が若干の心残りとしてあった。
（当時は「面倒くさい」で片づけた）
実例を挙げると（上記記事内でもちょこっと書いてあるが）、
Dear Deadman収録の「Melodic Storm-DEAR EDIT-」はシングルの「Melodic Storm」とほぼ同じだが曲名が異なり、、
TITLE収録の「REBIRTH」はSOFT収録の「REBIRTH」とまったく違うが曲名が一緒。
このため、Melodic Stormの集計範囲からはDEAR EDITは除外されているし、
REBIRTHはオリジナルとアコースティックで全く違うが同じ曲として集計されている。
実際に聴いているときは、曲名ではなくその曲の中身で「どの曲か」を判別しているはずである。
よって、上記の「違い」を加味して、前回行った検証を再実施してみようと思う。
これは、「CLONEをよく聴く気がしてならない」というモヤモヤとしたものが晴れない自分を納得させるためのものである。
⇒この判別を正せば、ひょっとしたらCLONEが選ばれやすさ１位になるんじゃあねーか！？という淡い希望を抱いている
【ORACLE】分散トランザクションについて
前に書いた記事の詳細を補足する（見返したら自分で良くわからなかったので）。
舞台となるのはDB LINKでつながっている２つのDBである。（↓のようなイメージ）
●LOCAL DBには「TABLE_A」というテーブルと、「SYNONYM_B」というシノニムがある。
SYNONYM_BはDB LINKを経由してREMOTE DBの「TABLE_B」に繋がっており、
LOCAL DB側に実体はない。
●REMOTE DBには「TABLE_B」というテーブルがある。
このDBはそれ単体で閉じており、DB LINKを経由してLOCAL DBを参照することはない。
●このとき、LOCAL DBに接続してSYNONYM_Bに対してSELECTをかけた直後、
そのトランザクションは「分散トランザクション」になる。