---

javaで時間を加算する実装例。
ストレイテナーのシミュレーションするときにテスト的にやったのでメモとして残す。

特に「時」（Hour）の部分がない文字列からDateFormatを通して時間に変換した後、別の時間と合計する場合は、
オフセットを適切な箇所に加算ないし減算してあげる必要がある。
これは、「時」の部分がない文字列のDateFormat#parseでは1970/01/01 00:00:00をもとに変換されたDateインスタンスを得るからである。
よって、基準となる1970/01/01 09:00:00からすると過去の日時であるため「負数」となり、
これを単純加算していくと負数＋負数でどんどん小さくなり、結果的にわけのわからん時刻になる。

例えば47分2秒＋14分58秒だが、当然だが「1時間2分0秒」という値がほしいのに対し、
オフセット加算をしないと「16時間2分」になる。
これは、
47分 2秒＝1970/01/01 00:47:02＝-29578000ミリ秒
14分58秒＝1970/01/01 00:14:58＝-31502000ミリ秒
で、合計すると-61080000ミリ秒となり、
1970/01/01 09:00:00からすると「過去の日時」を指すことになるので、
結果的に「1969/12/31 16:02:00」になる。
これをHH:mm:ssでパースして「16:02:00」、つまり「16時間2分」になってるように見えてしまうのだ。

---

 

---

---

前回の続き（？）で再び「iPhoneシャッフルでストレイテナーを再生」するときの考察をしてみる。
今回は「60分という制限時間内でどのアルバム・曲が一番聴かれる可能性が高いのか？」という点に着目してみたい。
この「60分」という制限時間は前回書いた通り俺の会社への出勤（または帰宅）にかかるDoorToDoorの時間とほぼイコールである。
要するに「１回の出勤においてシャッフルで曲を聴いた場合一番よく聴いているのはどのアルバム・曲か？」というのを調べる。

これは普段何気なく聴いているだけだと実際のところあまり気に留めていないが、
巨視的な視点で見たときには数学における確率の諸法則に従っているはずである。
ここでは、シャッフル再生が完全ランダムな曲順を保証するという前提で、
乱数によりシミュレーションを行うプログラムを作成し、いわゆるモンテカルロ法で結果を評価する。

※ちなみに最新アルバム「Behind The scene」は検証の対象に入っていません

---

 

---

---

 

ストレイテナー約３年ぶりのフルアルバム「Behind The Scene」感想！

 

---

---

通勤や帰宅時、または一人での外出時では、
基本的にiPhoneのシャッフル機能を使ってストレイテナーをアーティスト選択して再生している。
シャッフル再生というのが、”完全にランダムに曲順を決めている”という前提だと、
極稀に「おお…この曲が連続して流れるのって結構レアなんじゃあねーかッ！」と思う組み合わせに遭遇することがある。
ただいつもは数値的にそのレア度を評価したわけではないので、その時は「なんとなくレアかも」くらいにしか感じていない。
ちなみに今日なんかはSILLY PARADE(インスト)⇒SILLY PARADE(シングル)が連続して流れた。
気になったので確率を計算してみたらかなり天文学的確率だった。

---

 

---

---

Oracleの「FOR UPDATE OF TABLE.COLUMN」は、指定した項目を基準としてレコードの排他をかける構文だと思ってたが、

SELECTの対象が複数存在する場合にどのテーブルをロックするかを指定するもとの情報らしくて、

SELECT対象が１テーブルだけだとあまり意味がないらしい。

また、仮に複数あったとしても、「そのテーブルを（ロックする）」という意味しか持たず、

項目を指定することによる、その項目に関連する排他の意味合いはないようだ。（じゃあ書かせんなよ…FOR UPDATE OF TABLEだけ（COLUMN書く必要ない）でいいやんけ）

要するに項目Aと項目Bがあったら「FOR UPDATE OF 項目A」でも「FOR UPDATE OF 項目B」でも効果は同じ、ということらしい。



なお、前提として、ここでいう「そのテーブルを」というのは、FOR UPDATEを付けているSELECT側の条件（WHERE句等）に左右される。

つまり「テーブル全体をロックする」という意味ではなくて指定された条件に該当するレコードのみがロックされる。



まあでも確かに冷静に考えると、

指定した項目によっては「（その項目を指定したからって）だから何？」っていう気になるのもわかる。

これは、自身のプロジェクトにおいて、「FOR UPDATE OF TABLE.COLUMN」の「COLUMN」に指定される項目が、

得てしてKEY項目であることが多いことに由来するのだろう。

つまり「そのKEYのレコード全体をロックする」という意味合いとして使っている（書いている）と、

結果的には勝手に”勘違いしていた”ことになるのだが、

そもそも、もともとFOR UPDATE OF TABLE.COLUMNの".COLUMN"には、

Oracle的には、項目自体に対する排他等の意味や目的はなくて、

「そのテーブルを」の判断基準にしか使ってないんだから、

指定されたからといって、例えばフラグ的意味合いの項目だったとすると”値が1のレコードだけロックするの？”とか、

様々疑問が出てくることは確かである。

それに、KEY以外の項目を指定したとしたら（あるいはKEYなしテーブルだったとしたら）、

排他ができない無意味な構文になるかというと、それはそれで本末転倒であるし、

そういうことも考えると「よく考えればわかるだろ」と言われるとそうでもある。



結合してデータを取得する際に同じ名前の項目が一度のSELECT内で複数存在する場合に、

「どのテーブルの」項目かを区別する指定を明記しないと実行できずに怒られる仕様がある。

このFOR UPDATEの項目指定もそれとよく似ていて、その理由というか、経緯も多分同じなんだろう。

「Aテーブル.項目B」と「Cテーブル.項目B」が存在するとき、

単に「FOR UPDATE OF 項目B」とだけ書いても「どっちのだよ？」という気になるから、テーブル名から書かせるようになっている…

そんなところなんだろう。

だから「テーブルどころか項目名まで書かせている」というよりは「項目を書かせるためにテーブルまで指定させている」というほうが正しい気がする。

でも項目を書くことの意味がない（指定する項目によって排他の効果は変わらない）なら出発点がまず間違っていると思うのだ。

（これは俺の予想に過ぎないから事実がどうかは知らない…）

---

●ヘンリー・チャールズ・デヴィヴィエ（BILLY BAT 15巻） ●ロバート・キャンベル（東大教授、朝の情報番組「スッキリ！」に出演） こいつら似すぎ

---

動的にコマンド文字列を作って実行したい場合、そのまま文字列を書いて「`」で評価すると、
コマンド文字列内になる「'」がえてして邪魔になるときがある。
これを回避するために個人的にはよくevalを使う。

例えば以下のようなケースではうまい具合にコマンドが実行されない↓

for i in `seq 0 31`;do  
	cmd_wk="date +%Y/%m/%d --'""$i days ago""'";  
	echo "`$cmd_wk`"; ←ここがうまくいかない  
done  

これは
”現在日付から１日ずつさかのぼって日付をYYYY/MM/DD形式で標準出力する”
ことを実現したいのだが、実行すると

date: 認識できないオプション`--'0'です  
詳しくは `date --help' を実行して下さい.  

といわれて実行に失敗する。

これを回避するためにevalを使って

for i in `seq 0 31`;do  
	cmd_wk="date +%Y/%m/%d --'""$i days ago""'";  
	eval $cmd_wk  
done  

とするとうまくいく。

2014/10/06  
2014/10/05  
…  
2014/09/06  
2014/09/05  

↑2014/10/6に実行したのでこんな感じの標準出力になる。
実際には３２行出力される。

evalは引数に「実行したいコマンド文字列」を渡す。
そういう意味ではxargsに近いかもしれない（テクニックやコマンド原理の相似点はよく知らない）
最も単純な使い方では「eval ls」のようなものが出来るが、これは要するに「ls」と同じである。
「eval ls -las」なら「ls -las」と同じ効果を得る。

このevalは引数に渡した文字列そのものをコマンドとして実行しようとするので、
例えば「eval `date +%Y/%m/%d' '%H:%M:%S`」のようなevalコマンドは通常失敗する。
⇒これは引数部分の`date +%Y/%m/%d' '%H:%M:%S`＝"2014/10/06 10:21:44"という文字列をコマンドとみなすので
　自分の環境変数に指定された「2014/10/06」というコマンドを実行しようとするが、
　そんなコマンドはない旨のエラーが表示されることを表している。

---

 

---

---

HTMLのIMGタグのSRC属性には、通常外部の（自分自身のHTMLファイルとは別の）画像ファイルを指定するのだが、
画像のデータを示す文字列を指定することで、
外部の画像ファイルを使用せずに自身のHTMLファイル内で「画像」データを再現できる。
※ただしその分、HTMLファイルの容量自体が膨らむ。
特定の静的HTMLコンテンツがそれだけで完結していて、
外部の画像を読み込むような隙がない（配置された場所からしてネットワーク環境的に不可能な）ケースで使用する。
↑のような書き方をするとなんとなくレアケースにしか感じないが、実際、あったのである。（実体験故、詳しいことが書けない）

記述方法は以下の通りだ。

<img src="data:image/png;base64,[BASE64エンコードされた文字列]" alt="base64test">  

 

---

 

---

---

全角文字を含む値（VALUE）を持つjavaのpropertiesファイルは、使用する環境を考慮してか得てしてnative2ascii化されていることが多い。

よって、メモ帳やらサクラエディタ等の、一般的なテキストエディタで開くとこんな感じに見えてしまう↓

  
test.key=\u30d5\u30a1\u30a4\u30eb\u306e\u51fa\u529b\u306b\u5931\u6557\u3057\u307e\u3057\u305f\u3002  
#ちなみに"ファイルの出力に失敗しました"と書いてある  

当然この状態だと何書いてあるかわからんので日本語にしたいのだが、

知っているかぎりエディタ上でこれを日本語で復元して読み込んでくれるのはEclipseしかなく、

いちいちこのpropertiesファイルのために重いEclipse立ち上げるのも億劫で

手軽なnative2asciiの復元方法や、エディタがあればいいなあと思っていた。

どうもコマンドプロンプト上でnative2asciiコマンドを使うのが最も手っ取り早そうなので、

ここでその使い方を記述する。

---

---

を、見た。

 

（これを見た俺以外の人は）いきなり何言ってんだと思うかもしれないが実際に見たのだ。

 

いろんなゲームや漫画に「スライム」という存在は出てくるけども

この夢で対象になるのはドラクエのそれである↓

 

---