10月の夜雨の寒さときたら。会社を抜け出した1万人くらいが聖地等々力に集まりました。私も後半途中から参加。すでに田中裕介がゴールを決めて、小林悠のゴールの直前くらいに中に入りました。新丸子から歩いてきて、歓声の感じでゴールしたなってのは分かったんですけどね、7番ゲートまでぐるっと回っているのがもどかしい。 試合のほうはあまり危なげなく…というほどではないけど、まあ実力の差がそのまま出たかなと。試合が終わって記録を見てやっと気づきましたが、相手は一人退場になってたんですね。2点差だし憲剛はこのまま温存かと思いきや、顔見せで出てきました。そこはパウリーニョか稲本あたりかなと思ってたんですけどね。 しかし今節の上位陣は川崎以外は総崩れ。浦和の背中が少し近づきました。残り5試合で6ポイント差。川崎は先日のアウェイガンバ戦で負けたことが悔やまれます。でも直接対決がなく他力ですけど、勝ち続ければ可能性は… 今後の対戦は以下の通り。

会社のMBPもYosemiteにしました。昼休みに昼飯を食いにいっている間に終わっているつもりだったが、自宅のMBPと同じところで詰まっていた。適当にログを見ていると、JMicronのkextのロードが云々…で止まってた。まあ同じようにログを見ているうちに通過し、無事にYosemiteになった。JMicron？ なんだろう。何かそんなものをインストールしたかな？？ 覚えてないな。 通知の株価のところ、会社でやると日本市場のコードしか出てこなかったりする。プロキシで何か制限したりしているのかもしれない。それ以外は大したトラブルもなく進んだ。

どこを見ても、力に満ちている？ こういうキャッチコピー考えてるの誰なんでしょうね。 現時点で実用的なUnixのデスクトップ環境としては唯一と言ってもいいくらいの地位を築いたMacOSだが、OSのアップデートはどうか。FedoraのpreupgradeやFedUpとくらべてどうなのか… アップデート中、残り1分の表示が出てから30分以上動きがなくて焦りました。適当に操作してたらいきなり画面上部にカーソルと近づけるとメニューが表示されることに気づいて、そこから「ログ表示」みたいにしたら何か動いているようで、ログの流れを眺めていたら再起動がかかって、そこからは無事に進みました。 今日の午前中、会社のMBP(自宅と会社で同じ機種を使ってます)でやるのを控えて良かったです。MBPの1台しか手元にないので、長時間仕事にならないところでした。しかも会社のは最近立て続けにSMCリセットをかけなきゃいけなくなったという不調なMBPなので。来週の帰り際か昼休み前にでもやろう。 まあハラハラドキドキさせてくれますよね。期待を裏切らない。 見た目のフラットデザイン(?)は違和感がありすぎる。システムフォントも変わった(よね？)。前のも悪くなかったけど、Yosemiteのフォントも嫌いじゃないですね。iTunesが赤くなったのも謎だ。何かの警告かと思っていろいろいじったりしてみたが問題はなさそうで、ぐぐったらこれ、「Appleが気の迷いで単に赤くしてみた」ってだけなのね…そう来たかよ。 通知のところに株価を表示できるようになったが、日本市場のticker codeは無味乾燥な数字なので、いまいち。米国だと会社名を推測できるのだが…まあ一応日本市場にも対応しているところは偉いな。たまたま私が務めている会社は東証とNASDAQに上げているので、並べて比べることができたりする。

ユニークな番号を採番したいケースがありますよね。SQLでやれば複数のサーバ間でユニークにできる。UUIDは重ならないとかいう話もあるが、実際システムでユニークであることを保証しようと思えば乱数等に依存するわけにはいかない。 というわけで、ここではSQLを使って採番することを考える。

CREATE TABLE tbl (num integer NOT NULL UNIQUE PRIMARY KEY)

で、どんなSQLを発行すれば次に取りたい値を求められるのか？

SELECT (num+1) FROM tbl
 WHERE (num+1) NOT IN (SELECT num FROM tbl)

これは十分直感的な書き方。num+1の値であって既存のnumの中にはない、というもの。どっかでググって見つけてきたクエリだ。ただこれはMySQLの場合dependent subqueryになる。

mysql> EXPLAIN SELECT (num+1) FROM tbl WHERE (num+1) NOT IN (SELECT num FROM tbl);
+----+--------------------+-------+-----------------+---------------+---------+---------+------+------+--------------------------+
| id | select_type        | table | type            | possible_keys | key     | key_len | ref  | rows | Extra                    |
+----+--------------------+-------+-----------------+---------------+---------+---------+------+------+--------------------------+
|  1 | PRIMARY            | tbl   | index           | NULL          | PRIMARY | 4       | NULL |    1 | Using where; Using index |
|  2 | DEPENDENT SUBQUERY | tbl   | unique_subquery | PRIMARY,num   | PRIMARY | 4       | func |    1 | Using index; Using where |
+----+--------------------+-------+-----------------+---------------+---------+---------+------+------+--------------------------+
2 rows in set (0.00 sec)

この「dependent subquery」というやつはMySQLにおいては忌み嫌われている有名な「遅くなる」クエリで、よく「外側から評価される」と称される。外側が評価されて、結果それぞれに対して内側のサブクエリが毎回実行されるという意味で直感的な動きとは異なってしまい、効率良さそうに書いたつもりが実は良くない、という問題をはらんでいるらしい。遅くなってしまうクエリにしても、内外を逆転して書ける種類のものであれば、良くなるんだろう。 ↑で上げたクエリの場合は外側と内側が同じ分量なのでまあ、そんなに悪化するとは思えない。実際いろいろ試してみたが、そんなに遅くはならない。 JOINを使ってみる場合はこんなクエリになる。

後悔というほどでもないけど、子供と雑談していて暦の説明をしたんですが、もっといい説明ができたかもしれないなと。 まず、暦というのは種をまく時期を決めたりするから非常に重要なものであったと。このへんは説明できた。 太陰暦というのは月の満ち欠けを数える暦で、だいたい1年に12回新月→満月(→新月)を繰り返すことから12ヶ月になった。だから太陰暦時代は毎月15日あたりが満月だった。なんで太陰暦になったかというと、月は形が変わるので太陽よりも観測しやすい。形を見ながら数えてればだいたい29〜30日くらいで1周するし、12回くらいで季節が元に戻るというのが昔の人にも分かったわけだ。このへんは説明できなかった。 しかし12回の月の満ち欠けでは1年とは誤差が大きすぎ、たまに1ヶ月追加したりしないと季節がズレていってしまい、不便が大きい。そこで太陽の角度とかを観測する技術が出て太陽暦になった。これだと太陰暦に比べてズレが少なく、だいたい4年に1回くらい2/29を追加することで1日以内のズレにできたわけだ。このへんは多少まともに説明できた。まあ時代によって観測精度が上がってきてうるう年の追加方法が変わったとかいうのは説明できなかったな。 単に「昔は太陰暦があったけど今は太陽暦なんでズレが少ないんだよね」という説明は上手くなくて、技術の推移で説明してけばもっと分かりやすかったな、と思ったんですね。実際に子供でも月の形の変化を知ってるわけだが、太陽の変化を知ることはできないでしょう？ 大人でも多くの人は太陽の変化で暦を作るなんてできないだろう。月の形を見ながら日数を数えるくらいなら、子供でも日記をつければできるような気になれるんじゃないかと思う。 でも、なぜ昔は太陰暦だったかなんて、誰も教えてくれなかったな。Wikipediaにも書いてない。だから「太陽よりも月のほうが観測しやすかったから」が正解なのかは正直、自分にも分かってないのだが、そう考えるしかないよな、と思っている。まあ潮の満ち引きを知りたい云々…というのはあるんだろうけど、それって後付けだよね。 まあたぶん子供はしばらくしたら忘れてるんだろうけど。

久々に行ってきました昨日の等々力。その前には宮内の鎮守の森の春日神社の祭りがあって、神輿だの山車だの。山車は引いてお菓子をもらったりしてましたが、そんなこんなは置いといて。ハゲつるピッカーンな奴が子供3人連れて、ゴール裏でちょこまか動く子供をフォローしながら見てました。ナビスコ準決勝で、アウェイで1-3で負けて帰ってきたという状況。2-0で勝つか、3点差で勝てば上がり。 試合の出だしは快調で、後半途中までは行ける感じがしてました。サブに中村憲剛がいたから、1点取ればいいという状況になったら憲剛が全てを決してくれるだろうというね。でもあと2点。あと2点になってからが長かった。余計な失点が重くのしかかり、敗戦。憲剛の決まるところも相手DFの突き出された尻にブロックされて枠外へ。無失点で済むとは思えなかったから4点は最初から必要と見込まれてたよね。2失点したから5点が必要になった。 全体的には、もし森島が決めてれば、みんながハッピーだったろうと。もし決めてればね。仮定法過去完了？ だっけ？？ 2本ほど好機がありましたよね。 まあ小林悠(代表に呼ばれて不在)がいたら、5〜6本ばかり外すか、あるいは2本決めるかしてたろう。私としては久々の等々力で久々の勝利ということで気分は悪くないはず…だけど、目的を達成できなかった残念さが強かった。

一つ前の、droneでビルドできない問題は、.drone.ymlのscriptにcp -r ./ $GOPATH/src/github.com/wtnb75/xxxx/ みたいに書いておけばよいことを発明した！ 手間かけさせやがって。

Go(golang)はかなりいろいろなことがよく考えられた良い言語だが、大きな欠陥がある。その欠陥はやはりimport。gitやmercurial等のリモートリポジトリを指定できてそれはそれで大層便利ではあるのだが、タグやブランチ、バージョン等を指定できない(常にmasterのHEADが使われる)ことがしばしば問題となる。 このimport問題の中でもとりわけ大きなものが、local importの問題だ。 リポジトリ上で開発していて、同じリポジトリのサブディレクトリを対象にimportしたいとする。

import "./subdir"

通常はこれで良いのだが、$GOPATH/src以下もgo getでcloneしてくるリポジトリになっていて、ここのソースに対して作業をしていると、相対パスによるimportがエラーになる。

can't load package: /path/to/go/src/github.com/wtnb75/xxxxx/yyyy.go:16:2: local import "./subdir" in non-local package

つまり、$GOPATHにのっとって開発する(実際golangではそれが推奨されている)場合は、こう書かなければならない。

最近は子供たち側の初期配置をまともにして対戦しています。まあまだこの配置だと大人が勝つことが多い。長男に持ち駒を持たせたり金も落としはじめると大人が負けるかな。次男はまだそれよりは弱い。 ここまで来ましたね。たまに大人(私)がびっくりするような良い手を打ってきたりしますね。まあ私は全然強くないんですけどね。

コメント画面の「スパムをすべて削除」する操作が全く戻ってこない。しびれを切らしてリロードするとちょっとは消えてるけど大部分が残ったまま。 このサイトにはほとんどコメントは来ないのだが、普通の設定(akismetで自動判定されたspamが1ヶ月で自動消去)でも常時数千件のspamが溜まっている。それでたまに全件削除しようとボタンを押してみるが…スピードが遅すぎる。何をやっているのか？ MySQLのDELETEが遅いのかも、と思って試しに以下のSQLを実行してみたら、瞬時に終わった。綺麗さっぱり。まあすぐに10件を越えてくるのだが。

DELETE FROM wp_comments WHERE comment_approved='spam'

WordPressは出しているSQL文がものすごく下品なものになっているに違いないな。どうせPHPで1件1件チマチマ消しているんだろう。自動削除というのもたぶんメチャクチャなSQLを発行していて無駄に重くなっていた可能性もあるな。