お仕事してないかも(汗)
 日記

• おしごとのしくみ 実録:食卓遊戯密着大本営発表廿四時
  

　読んでふと思ったけど。そういえば最近、自分のプレイで「お仕事」を選ぶ場面が少ないような……。しかも他人にも「やったら勝てなくなると思うならお仕事するな」といってる気がする。
　最近のゲームは極端にお仕事が少ないから、そういう脳になってるんだろうか。というかひょっとして、わかってない奴空気嫁と思われてるかも。
　……まあいっか（ぉ

　いや、この記事の主張とぜんぜん関係ないこと書いてるのもなんなのでちょっと続ける。

それって嘘ですよね。

　たしかに嘘だと思います。

言い換えると、ここには「合理的でなくなるための合理的な理由がある」。

　微妙すぎるところにつっこんだこというと。
　マルチゲームは、究極までつきつめても選択が決まらない（神々のマルチゲーム）。
　だから、理屈でいって「合理的でなくなる必要さえない」。あるいは「もともと合理的になることはできない」。

　そして、これこそがマルチゲームだというのはそのとおり賛成。

Googleマップのマーカーを動的生成
 日記

　Googleマップのマーカーは、自作のものを使うことができる。このとき、フルカラー半透明pngを使える。というか、マーカーの影画像も指定するのだけど、こちらは半透明にしとかないとかっこ悪すぎだ。
　で、このマーカーに好きな文字を入れて動的生成したい。というか数字ぐらい入れさせろ。

• http://slightlyblue.com/blog/2006/08/googlemaps.html
  

　↑ここに紹介されているやつとか。
　画像URLを

numbered_marker.php?image=001.png&text=99

　とかやると、PHPのGDモジュールを使って文字をpng画像に合成してくれると。

　しかしだ。これが、IE6だと透明部分が透明にならないんである。なんか灰色になる。
　原因を調べたら話がややこしいのでまとめとこう。

１．まず大事な話だが、
　いつのまにかIE7は半透明pngに対応してる
　んである。上の問題で背景が透明にならないのはIE6以下だけだったのはそのせいだ。しかし。

２．Googleマップのマーカーが透過してるのはブラウザの機能ではない
　だって、本家Googleマップで、マーカーの周りが灰色になってるなんてことはないのだ。

　つまりこれは、実はブラウザがどうとかいう問題じゃないハズで。
　要するにGoogleマップが、マーカー画像をpngと認識してないんじゃないか？
　Content-Typeは出力してるがなあ。

　というわけで、上の画像URLをこうしてみた。

numbered_marker.php?image=001.png&text=99&.png

　透明になったし(笑)。

　どうやら、画像URLの最後が「.png」だったらアルファレベル使って透過合成、みたいなことをやってるらしい。
　つまりどちらかといえば、拡張子が.pngじゃないのに透過できてるほうが偶然だったと？(笑)

　ややこしいことして無理やりpngを透過させる方法もあるようだし、そういうのも調べちゃったけど。実はこんなしょーもない対策があったという話。なんだかなあ。

［2008.03.11 01:34］Namany :
そういうハックもいいけど、そういう仕様なら本来はこう書くべきじゃない？
numbered_marker.php?text=99&image=001.png

［2008.03.11 01:44］てらしま :
　あたしかに(笑)
　まあじっさいには、画像ファイル名を直接渡すなんて怖くてできないから、このままの仕様で使うことはないと思うのでハックが必要な場面も多そうですが。

JOIN禁止でよくね？
 日記

　なんかこの業界には神話が多くてね。「DBへの問い合わせは少なくするのが正義」というのもそのひとつ。いやたしかに少ないほうがいいから神話とはいいきれないんだけど、それはちゃんとSQLを書けることが前提にあっての話だ。

　どんどんサブクエリのつかいかたに長けていく人がいる。そういう人は、たぶんわたしじゃ書けないと思うようなSQLを平気で書く。
　っていうかそもそも、なんであんなSQLを書こうと思うんだろう……というのがけっこう疑問だったわけなのだけど。その理由に、さっき思い至った。
　けっこう、背筋が寒くなる想像なのだけど。

　……ああいうSQLを書く人にとって、テーブルはフルスキャンするのが基本なんじゃないか。
　多重にフルスキャンするのが基本だから、サブクエリでいったん減らしてからJOINしたほうが高速だったんじゃないか。

　考えたらぞっとした。
　設計がよくないときは、これが正解というケースは確かにあると思う。だとしたら彼らは間違っていない。そこが恐ろしい。
　確かにそのほうが速いなら、そっちの道に進んじゃった人はどんどんそっちにいってしまうと思う。そういえば、テーブル定義書にインデックスについての記述がまったくないなんてざらだよな……。

　というわけで、そういう人の習い性を覆すことは難しいと思う。それならいっそのこと、多少過激でもJOIN禁止！　といっちゃったほうがいいような。
　わりと最近本気で思いはじめてるんだけど。いつか一度やってやろう。

　……量子DBができて、インデックスのことなんか考えなくてよくなる時代がくればいいんだ。そうか。

［2008.03.08 21:19］英-Ran :

JOIN禁止！　といっちゃったほうがいいような。

3000行のプログラムより1000行のSQLの方が高速だし読みやすいと思ってしまう私のような変態にそれは辛すぎます(;o;)　むしろ、SQLわからない人は業務系プログラム作るの禁止にしたい(w

……ああいうSQLを書く人にとって、

ああいうSQLってどんな奴を想定してますでしょうか。私がこいつSQLわかってないなぁ、と思うのはカーソルを多用するやつですかね。なんでRDB使うのにループを回して検索するかなぁ……

［2008.03.11 00:35］てらしま :

3000行のプログラムより1000行のSQLの方が高速だし読みやすいと思ってしまう

　まあ高速ならいいと思いますけどね。問題は、その高速なSQLを書ける人ばかりじゃないことですなあ。

むしろ、SQLわからない人は業務系プログラム作るの禁止

　だからこれは正しいと思った(笑)。というかいま思ったけど、本当は分業が正しいのかも。
　（わかってるのでしょうけど）たしかに1000行のSQLは3000行のプログラムになっちゃうかもしれないけど、1000行のSQL５本分ならたぶん4000行くらいのプログラムで表現できるわけで。それを極端にやったらJOIN禁止！
　まあ、機能ごとに別の人が作るから、機能をまたいでSQLや処理を共通化とかはできないことが多いのが現実ですが。

ああいうSQLってどんな奴を想定してますでしょうか。私がこいつSQLわかってないなぁ、と思うのはカーソルを多用するやつですかね。

　わたし自身は、明示カーソルについてはテストデータ作るときくらいしか使ったことないけど。本質的にはそういうことですよねえ。
　おそらくわたしとは考えているレベルが違うので恐縮だけど。JOINするときに必ずカッコを書いてインラインビューを使うのが正義、と信じている一派が確かにいます。インデックスは無効になってるんだけど……
　あー、あとSQL２回投げるのがヤダからUNIONとか。SQLサーバのメモリは無限だと思ってる、というか現実には、SQLサーバはブラックボックスなんだろうけど。
　そういう意味では、カーソル多用というのは中身をわかろうとしてるからぜんぜんマシという気も(笑)

　まあJOIN禁止は、いつか一度ネタとしてやって、後悔してやめる予定です(笑)。

宇宙をプログラムする宇宙
 読書

　こういう科学本には２種類ある。おもしろい本と、笑うべき本だ。
　もちろん、内容が間違っているとか、トンデモとか宗教とか、そういうのはのぞく。
　笑うべき本といっても、特別内容に間違いがあるわけではなくて。じっさい、偉い科学者の人がそれまでの知見から書いた、内容もわかりやすく示唆に富んだ本だったりもするんだけど、それでも「ここは笑うべき」という本はあるんである。
　たとえば……といって例はあえてあげないけど。
　だいだい、歳をとって引退したか前線から退いたかした科学者が、宇宙のこととか脳のこととか、哲学とかを語っちゃってる本が怪しい。あー、これは科学に限らないか。
「笑うべき」ポイントは何種類かある。
　一つは、なにか壮大だけど予言性のない理論、たとえば人間原理とかが結論として登場したとき。
　二つめは、科学の話がいつのまにか人間の生きかたとか倫理とかの話になっていたとき。
　三つめは、よく考えればわかる論理の飛躍で、人間の意識とか宇宙のありようとか、そういう未解決の問題を自分の専門分野の話にすりかえてしまったとき。
　そういう本のタイトルにはよく「宇宙」とか「人間」とかが入っている。何冊か読んでいると、本屋で見かけたときに雰囲気を嗅ぎとれるようになる。

　この本。いかにもそっち系の匂いがしていたわけである。
　そりゃあおもしろい本ならおもしろいんだから読みたいけど、笑うべき本だって笑えるんだから、それはそれで楽しめる。むしろそういうのを読みたい気分のときだってあるわけで、これはそういうときに買った本だった。
　ところがこれが、予想に反して、ちゃんとおもしろかったのだ。

　どちらかというと、宇宙の話でもプログラムの話でもなく、量子コンピュータについての本として読んでもかまわない。
　量子論理演算とはなんなのかとか、具体的にどうやるのかとか、そのあたりの概説がわかりやすく書いてある。
　その上で、エントロピーというのは情報のことなんだとか、なぜエントロピーが増大するのかとか「計算量は使えるエネルギーの量に比例する」とか、横断的な議論がおもしろい。
　このあたりは、サイエンスフィクションの立場に似ているという気がする。けっきょく、専門的なことだけ書かれた教科書は誰が読んでもつまらないし、こうして視野の広い話に還元してくれないと、少なくともわたしたち読者にとっては、科学なんてなんの意味もないわけでね。
　いってみれば、ＳＦじゃなければ科学じゃない！

　……逆にいえば、おもしろければ多少トンデモでもかまわなかったりもするけど。
　この本にしても、量子計算の話が万物理論の話にまで広がってしまう必要が果たしてあるのか？　という気はした。
　あと一歩で「笑うべき」領域にいくところなのかもしれないし、本当はわたしの理解が足りないだけで、笑うべきポイントを見逃したのかもしれないんだけど。
　でも「あらゆるものは量子ビットに還元できる」という主張は現代人には理解しやすいし、それはつまり計算機に理解しやすいということだ。納得するしかない説得力があると感じた。

　たとえば一匹一匹のマグロの単純な習性から、容易に群れのシミュレーションを作れる。群れ全体を記述する方程式を考えるより、シミュレーションを作るほうがずっと簡単だ。
　それに、群れが形成されるメカニズムを方程式で表現されても意味がわからないと思うけど、シミュレーションなら一目瞭然。
　シミュレーション科学の有効性はそろそろみんな知っている。
　物理法則について、そういう理解のしかたをしてもいいんじゃないか、というのがこの本のいいたいことと思う。たしかにそうかもだ。

あるＱ言語技術者の話
 日記

　ほんの少し未来の話だ。システム開発を巡る問題の数々はそのころになっても解決しておらず、それどころか、量子コンピュータの普及とそれにともなうさまざまな新技術の登場により、さらに混沌を深めている。
　そんな時代、あるＱ言語（量子論理演算を基礎としたプログラム言語）プログラマが、炎上案件のまっただ中にいる。
　毎日のようにやってくる仕様変更、日替わりのＤＢ定義、インフルエンザに倒れるリーダー、突如撤退する協力会社。数日に一度しか家に帰れない日々に、彼の心身はとっくに限界を超えている。
　リリースも間近となったある日、元請けの会社から一通のメールが届く。
「ソースコードのレビューをしたところ、メンテナンス性に懸念が出てきた。ついては、ログ出力ポリシーをこちらで定めたのでこれにしたがってほしい」
　なにをいまさら、と憤る彼だったが、上流の会社に逆らっている暇はすでにない。彼はその日も徹夜で、いわれるままにソースの修正をおこなった。
　さて、そのシステムのリリース後、多聞に漏れず重大な不具合が発覚する。検索結果画面を表示するたびに、一覧に表示されるデータが変わるのだという……。

　……→の本とか読んでてそんな話を考えたのだけど。
　なんかあまりにありそうだし、共感を得られる相手がずいぶん限られているのでプロットだけ書いとくことにしてみたり。
　要は、ログを出力した時点で量子計算の波動関数が収束しちゃってたよねというオチなのだけど、これまた説明がめんどくさくなったからしないし（ぉ

　この本はかなりいい本なのでおすすめです。

　あ。Ｑ言語ってもうあるだね……。