←前 2005年07月上旬 ↑index 2005年07月下旬 次→
■
このページの上の方に期間限定で掲示していた「ルービックキューブコンテスト 2005 in 京都」が終了したそうだ。
速報によると4x4x4部門で世界記録が出たとか。
大会の写真とかJRCAのページで公開されると思うので楽しみにしよう。
関西放送の「スーパーニュース」(7/11 18:15〜19:00)でちょっと紹介されるそうなので、
関西方面在住の方はどうぞ。
■
裏日記を書くってのはめんどいもんでして。
mixiだとお上品なマイミクの人達も見る以上、あまりお下劣なことは書きにくい。
上司がマイミクにいるのに職場のぐちとか書くのはキモチワルイ。
個人的すぎることもね(ゲームの成績とかw)。
いあ、SNSだからってお上品な社交的日記ばっかり書いてるかって言うとそうでもないか。
もちろん見知らぬ人に参考になる(かもしれない)ような種類の情報も書いてたりする。
そういうのはなるべくこっちにもコピーしようと思うんだけど、なかなかめんどくさい。
技術的な情報(Perlの××がバグってるとか、Apacheのなんとかとか)は
googleで引っかからない場所に書いても無味ないんで、こっちに書くようにしてる。
これはmixiで書いても、読む人にはつまんなさそうだからやめとく。
つまんなさそうってのは、マイミクであってここを知らない人の特性で判断。
いや、彼らがここを読んでないという保証はまったくないわけだけども(汗)。
■ そうやって2つも日記を持ってると、 一方が表、一方が裏っていう使い分けにどうしてもなってしまう。 「ヲレには裏も表もないぜ! ヲレのすべてを見たまい!」って人もいるようなんだけど、 なかなかその境地までは達しませんねえ。 そんで、回りを見てるとそういう人程、SNSっつー閉じた世界に貴重な情報を書いてる気がするのだな。 「SNSだから読者の身元は安心」っていうのは、おいらは幻想だと思ってるんだけど、 実際に存在するのかもしれないねえ。 「いつでもマイミク限定に設定変更できるよ」っていうことなのかもしれないけど。
■
ああ違うかな、おいらのは「マイミクの人達に読む価値のある日記を提供しなきゃ」っていうアレかな。
なんて言ったっけ、mixi症候群だっけ。
そうだよな、mixiに日記を書く動機なんてのは、google-reachableな日記も持ってる身からすると、
マイミクの人達に自分を見てもらいたいか、足あとを稼いで自己満足にひたるかしかないわけだ。
日記の公開範囲をマイミクにして、マイミク以外の人に見られたら困ることだけ書きゃあいいか。
それはそれで何だかつまんないよな。
マイミク以外に見せられない話なんて、それこそ恥ずかしい部分だけセレクトしたことになっちゃう。
「社交場」ってのはやっぱり、自分の全てをさらけだす場じゃなくて、
相手に合わせて自分の(・∀・)イイ!!ところだけ選んでお見せする場なんだよね。
そうやって選べば、そっちが「表」になって、残りが「裏」になる。
■ mixi日記に書いた内容の中にはgoogleでインデックスしてもらった方が、 少しは世のためになるかもしれないなあと思う内容もあったりするんですが、 こっちやあっち(どっち?)にコピーしてないのは、ひとえにめんどくさいからです。 別に情報の囲い込みに協力する気はないんです。 こっちの日記がぐちっぽい内容ばっかになるのも、上に書いたような「残った裏」のせいです。 すいません。ごめんなさい。
■ とか書いてて、「裏」の方が「表」より読者が多いっつーことに気づいたりとか。わはは。
■
スピードキュービングの練習。
23.53, 24.19, 23.84, (19.36), 32.37, 23.21, (37.68), 26.01, 23.50, 28.45, 27.27, 23.05; avg = 25.54
26.09, (18.68), 31.62, 26.04, 23.26, 24.16, 21.22, 26.24, 25.09, 24.06, (60.41), 24.74; avg = 25.25
24.58, 24.80, (19.30), 26.24, (50.49), 25.36, 29.31, 22.40, 29.90, 23.66, 22.53, 26.90; avg = 25.57
27.28, (21.83), 27.79, 23.91, 25.43, 25.79, 23.86, 26.90, 24.90, 28.91, (30.08), 24.59; avg = 25.94
21.44, 25.82, (21.30), (30.71), 26.06, 27.61, 23.09, 24.37, 22.97, 23.23, 23.27, 22.29; avg = 24.02
22.33, 20.02, 23.04, (16.67), 24.65, 24.22, 23.82, 23.51, 23.84, (27.47), 24.81, 19.56; avg = 22.98
新アルゴで苦しむ。30秒超が5回、うち2回は大失敗。それでも新アルゴでもsub25というのが増えてきた。
そして眠いのをがまんしながらの最後の回ではnon-luckyケースの自己ベストを達成。
■ 京都大会の結果案内がJRCA(日本ルービックキューブ協会)のトップページに出ているというので見に行った。 そしたらなんと日本選手権大会ですと? 9月3日……は日本にいない。残念無念。
■ おばきいさんとこから、 物欲サディスファクト経由で、ルービックキューブアース。 うわっ、欲しい! これは欲しい!
■ GC斑鳩。ついに5面田鳬最終形態(石の直前)まで、13.6M。チェイン更新は1面106、2面111、5面68。 1面の歌鶫成功率が7割くらいまで上がったのと、 虎斑木菟後の早回し虎鶫が7セット14チェイン分出るというのを目撃。
■ おてうさんとこに新流行語の予感! (7/9の日記)。
■
昨日のポップンCS9。ついにタイムリリースで全隠し要素が解禁。
マラソンモードが出たのを確認してギャンブラーZをonに。
ボス戦でノスタルジックHをしろポップで戦う。うひーつらい。
1時間ほど練習モードで特訓した後、再戦して勝利。
初クリア: アレグリアH(23), ＵＳダンスポップH(24), アレグリアEX(25), スペシャルエンディングH(27)
■
今日のキューブ練習。
22.60, 23.06, 23.84, 29.60, 27.90, 28.62, 25.69, 25.24, (22.20), 24.03, 23.08, (29.99); avg = 25.37
24.03, 23.28, 21.92, 22.45, 26.18, 25.29, 24.67, 23.98, (28.03), (17.92), 21.66, 24.22; avg = 23.77
23.07, 18.99, 22.86, (18.01), 24.72, 23.11, 23.69, 25.00, (28.07), 22.31, 24.34, 26.11; avg = 23.42
第180回選手権: 25.77, 20.02, 21.46, 22.87, 26.03, 20.05, 22.50, (47.61), 28.38, 24.85, (19.13), 37.48; avg = 24.94
(19.97), 23.48, 29.36, (33.18), 28.33, 25.10, 22.96, 26.20, 25.18, 22.97, 21.22, 23.90; avg = 24.87
22.23, 25.87, 25.53, 29.88, 24.48, (41.12), 22.21, 29.69, (20.69), 33.96, 24.60, 23.55; avg = 26.20
23.23, 27.05, (40.04), 23.33, (19.11), 22.46, 26.27, 28.67, 23.59, 27.01, 31.77, 30.25; avg = 26.36
26.31, 24.61, 23.75, 25.63, 21.94, 30.40, 29.37, (30.53), (19.96), 21.67, 25.10, 23.83; avg = 25.26
(23.27), 25.49, (49.96), 25.49, 27.68, 24.78, 23.63, 24.95, 23.66, 23.36, 27.51, 26.71; avg = 25.33
(19.80), 23.48, 22.79, 23.72, 23.69, (35.56), 24.72, 25.43, 23.08, 28.09, 21.23, 23.08; avg = 23.93
後半の6回は晩ご飯でビール飲んじゃったのでダメダメ。素面のときと比べて平均1秒以上遅い(汗)。
新アルゴは全然安定しない。5回に1回は大失敗して、F2Lからやり直しになってしまう。
大失敗を除外してもまだ2.7秒遅い。
■ そういえば会社に入ったばかりのころ、「アルゴリズム」を「アルゴ」と略して呼ぶのに大変な違和感を感じたものだけど、 スピードキューブやるようになってから自分でも普通に使うようになっちゃった。 困ったね。
■
Firefoxがeuc-jpなページからformのtextareaを送るとき、
latin-1のアクセント文字のエンコードがおかしい。
例えば「ß」を「0x8f 0xa9 0xce」の3バイトにしてる。
これって正しいエンコーディングなのだろうか? SS3+2バイトって……外字? JISX0212?
どの資料を調べたら正しいかどうか判断できるのだろう?
検証コード: 以下のフォームのソースをEUC-JPでセーブしてブラウザで開き、「送る」を押す。アドレスバーを見る
(このまま押しても多分大丈夫。日記鯖はEUC-JPで出してるから)。
■
スピードキュービングの練習。
23.38, (21.06), (31.60), 21.97, 21.34, 22.74, 25.61, 23.38, 27.58, 23.25, 23.37, 23.16; avg = 23.58
24.62, 22.37, 25.33, (21.98), 23.72, 27.46, 22.96, 23.30, (30.20), 23.38, 28.75, 24.99; avg = 24.69
23.52, 22.90, 25.33, (28.05), 24.99, 25.51, 25.59, 27.45, 24.62, 21.96, 24.48, (21.53); avg = 24.64
22.66, 25.52, 23.05, 26.35, 24.11, 28.17, (21.02), 21.54, 21.67, 23.60, (29.14), 21.10; avg = 23.78
20.95, 23.96, 23.78, 27.00, 23.36, (19.07), 23.42, 23.90, 24.91, 22.30, (27.47), 25.94; avg = 23.95
新アルゴのオーバーヘッドは1秒まで減った。平均タイムを見ると良くなってるようだけど、
sub21が2回しかないってのは、どこかうまくいってない感じ。
23秒台がやたら多いのはどうなんだ、いい兆候と考えていいのか?
■ 昨日のこれ、JISX0212の0x294eにßは入っているらしい。SS3で呼び出せば0xa9 0xceになるのね。 EUC-JISX0213になると0x8f 0xa9 0xd5でßになるとのこと。 なぜ数字がずれているのかナゾは深まる。
■
そんでまあ、なんでこんな話になったかというと、mixiの日記でドイツ語のアクセント文字を書いたら、Firefoxでは読めるのにIEでは化けるという話になったのだった。
どうやらこんなメカニズムになっていると予想してみた。
おいらはフォームに「ß」と入力
→ Firefoxは%26szlig%3Bとmixiに送信
→ 確認画面でhiddenパラメータに「ß」が入ってくる(※1)
→ 作成を押すとhiddenパラメータの内容をEUC-JPでエンコードし直して送信(※2)
→ 日記にはEUC-JPでエンコードされたSS3 + JISX0212のßが保存される
→ FirefoxではEUC-JPのG3にJISX0212が入っていて、SS3で呼び出せるのでOK(表示前にいったんUnicodeにしてるんだよね、きっと?)
→ IE6ではCodepage 51932で表示するが、G3にJISX0212が入っていないので文字化け
さて悪いのは誰?
案1: ※1で&を&とエンコードして来ないmixiが悪い
案2: ※2でhiddenパラメータをそのまま送りゃあいいのに、わざわざEUC-JP SS3でエンコードし直すFirefoxが悪い
案3: EUC-JPをちゃんと表示できないMSIEがもちろん悪い
案4: ユーザーごとのタイムゾーンもサポートしてないようなmixiに、日本語以外が書けるなどと期待するおいらがそもそも悪い
■
スピードキュービングの練習。
(21.31), 23.93, 28.78, 26.97, 26.79, 23.59, 22.04, 25.88, 25.96, (29.00), 23.43, 23.04; avg = 25.04
22.33, 23.42, 20.87, 21.38, (17.82), 25.32, 23.35, 21.35, 19.98, 22.46, 22.09, (27.90); avg = 22.26
25.84, 23.05, 23.73, 25.80, 23.38, 25.99, 25.67, (18.88), 21.32, 22.00, 22.02, (26.16); avg = 23.88
24.47, (20.49), 20.71, 23.80, 23.34, 24.08, 22.92, 24.77, (24.84), 22.15, 23.05, 21.13; avg = 23.04
23.77, 23.39, 22.28, (26.47), 23.48, (20.88), 25.80, 22.17, 21.92, 24.45, 26.02, 24.42; avg = 23.77
(19.90), 25.45, 21.08, 21.61, 25.55, 24.07, 21.62, 21.34, 25.78, (26.48), 24.15, 23.72; avg = 23.44
今日は調子がいい。新アルゴで一度も失敗しなかった。他アルゴとのタイム差は1.2秒。
もうほとんど完成したかな。
2セット目の22.26は自己最高記録だけど、PLLヌキが2回もあったんで、追い風参考記録ってところか。
一応、speedcubing.comのルールだと、ラッキーケースがあってもローリングアベレージでもOKってことになっている。
ローリングアベレージだと1セット目の11回目からで22.03秒。
■
ユーザーに日付を入力させるウィジェットがあるのだが、その戻り値がjava.util.Date。
文字列でほしいから、Date→Stringという変換を行う。ここに罠がある。
これら2つの間の変換にはTimeZoneが必要。
ウィジェット内のString→Date変換に使われたTimeZoneがわからないことには、
getValue()のDate値からユーザーの意図した日付は得られない。
安易にSimpleDateFormatかなんかで変換できたつもりになってると、
ウィジェット内ではJST、サーバー内ではGMTだったりして日付がずれることになってしまう。
java.util.Dateってのはタイムゾーンとは独立した1ミリ秒の解像度を持つ時刻。
一方「日付」ってのはタイムゾーンに依存した24時間の長さを持つ期間。
そもそも「2005年7月20日」という日付を「2005/07/20 00:00:00.000 (どこかのタイムゾーン)」という時刻型で表現しようなどというのが間違いじゃないんか?
getValue()の戻り値を「入力された日付の午前0時GMTに対応したDate」とか、
「入力されたタイムゾーンでyyyy/MM/ddにフォーマットした結果の文字列」とか定義してくれてたらよかったのに。
■
いや、違う。本当はわかってる。
ユーザーに日付を入力させるGUIを持つアプリという時点で、
ユーザーのTimeZoneは常に意識されていないとおかしい。
ウィジェットには常に明示的にsetTimeZone()がされていて、
入力された文字列から何か別の表現への変換には常にそれが使われる。
サーバーのデフォルトタイムゾーンがどんなものであってもうまく動く、
そういうシステムでなくちゃいけない。めんどくさいよう。
サーバーもクライアントもユーザーもみんな同じタイムゾーンにいるからOKだよね、とか思っていたら、
ウィジェットだけGMTに住んでましたということが、あったわけですねー。
■ ここらへん、誰しも一度(や二度)はハマった経験があると思うんだけど、 ベストプラクティスはどうなってるんだろ。 例えば未来の日付はdate_t(エポックからの秒数)で永続化してはいけない、とかコツがあると思うんだけど。 エポックからの秒数って、うるう秒の発生と関係なく「今年はうるう秒がありますよー」って情報をインストールした時点で変わるものだし。