OctopressとAndroid

毎日github(enterprise)で生活している私にとってOctopressはなかなか快適なんですが、ひとつだけ問題があった。

octopressのテーマのファイルはほとんど全て<html lang=”en”>になっている。これは普通は問題にならないが、例えば今のNexus5(KitKat)のChromeブラウザはlang=”en”だとフォントが汚いんですね。ひところの違和感以外に感じるものがない中華フォントよりはマシだけど、やはり日本語のフォントではないっぽい感じに描写される。「写」「反」の字とかが非常に気になるわけだ。例えば大手サイトだとhuffingtonpost.jpのモバイルサイト(.comドメイン)もやはりlang=”en”になっているのでフォントは汚い。

英語と主張するUTF-8文書でCJK領域のコードが来た時に、どの言語のフォントを使うかを選択する、そこで中国のフォントが選択される…これが中国と日本の人口の差なのかな。消費地としては日本の市場のほうが魅力があると思うんだけどね云々。

そこで。

  • git grep -l ‘lang=”en”‘ | xargs sed -i.bak -e ‘s,lang=”en”,lang=”ja”,g;’
  • rake generate
  • rake deploy

これでかなりマシになる。これができるのは自分の管理下のサイト限定ですが。

フォントではMac(Yosemite)のEmacs 24.4.1でも悩まされてますがそれはまたいずれ別の機会にでも語りましょう。

輝けるクソ、あるいは光るうんこの物語

light-shit

小さな縁日でよくあるスーパーボールすくい。あれで一番人気なのが、LEDで光るうんこ。なんでまたうんこの形をしちゃってるんでしょうね。いずれせよ、他の形状よりもうんこの人気が高いのは間違いのないことだ。一応密閉されているので水に浮かべても大丈夫。

わたなべ家の息子たちは先日、小学校のイベントのスーパーボールすくいでこの輝けるクソを入手。かなりハッピーな状態になってます。翌朝起きるなり「ひかるうんちは?」と聞いてきたりね。おいおい何時だと思ってるんだ。自分で探せよと。

苦節1X年

いろんなことがありました。学生時代に借りていた奨学金を、ついに完済しました。3X歳の誕生日。フロンターレは肝心なところでの負け癖が相変わらずであることを確認しましたが、私はひとり祝杯を上げています。缶ビールでね。

実際のところ、分別のつく大人になって考えると、貸与の奨学金というのは良い制度ではなかったと思います。対象者を増やせる利点はあるにしても、貸与で年間100万くらい借りられるんですけど、私の場合はマスター(修士)の2年間借りて200万の借金がある状態で卒業しました。就職先があったから良かったようなものの、就職できなかったらと考えるとぞっとしますよね。今から思うと24とかそこそこの若いやつに学業のために借金負わせて放り出すなんてオニですよ。そんなに辛く当たってくれなくても良かったんじゃないかなと思う。若い人への教育は社会のためにもなることでしょう? 200万って、もっと大人になったらはした金でも、若者には大きなお金ですよ。

理系の人間がマスター行きたかっただけで、悪いことしてるわけじゃないんだよ。知らない人も多いのかもしれませんが、理系だと半分くらいの学生がマスター行くんですよ。ドクター行くのは物好きだけだけど、マスターは普通の学生の半数が行くもの、なわけだ。

  • 私の時代だと大学まで出るのはほとんど全員だったから、大学卒業まで持つのは親に責任があると思った→親が学費を払った
  • マスターは私は行っときたいと思ったけど世間的にはフィフティフィフティで親が面倒を見る責任はないと思った→奨学金を貰って学費を出した

この代償が200万の借金(ただし無利子)。これはきつい。経済状況を考えると、親からすればなんでもない額だったろうと今では分かる。

確かに、私は就職できたから返済に困ることはなかったし、実家暮らしでバイトもしてたから卒業時点で200万くらい貯金がある状態だった(=奨学金を貰わなくても払えた)んだけど、一般論としては引っかかるものがある。ドクター行ってたらもっと悲惨だったろうし。

まあそれもこれも完済だ。

このお祝いに自分へのご褒美に何を買おうかな。うふふ。

まずは電話ですね。今使ってるのはちょっとスペックが低くて何かと弱々しいので、買い換えたい。

iPhone6か、iPhone5sか、Nexus5だか6だかか、あるいはもっと安いやつか。3大キャリアとの契約を一切持っていないクリーンな身体を保つために、SIMフリー版というのが必須条件。一応MVNOの会社に在籍してるわけだし。実際安いしね。

前職のFujitsuの電話もSIMフリーでfmworld.netで売ってたら遊びで買ってみるつもりではあるんですけどね。1年以上前のemobile版の製品が1つだけ出ていて、オレの推理によればこれはSIMフリーな気もするが…買う前に調べたほうがいいか…しかしリンクをたどっていっても買える気がしない。「カートに入れる」「購入する」ボタンはないのか? えーと、ショッピングサイトだよなここは??

というわけで問題はiPhoneにするかどうかなんですけど、PCも電話もAppleで揃えればそれなりに快適だろうとは思うんですけど、私はAndroid嫌いじゃないんですね。Windowsは最後まで好きになれなかったけどね。で、Lollipopが出たタイミングでKitKat以前のを買ってアップグレードがない可能性というのもアレだしなぁ。

サイズを考えると、最近の電話も大型化が進んでいて、私のジーンズのポケットに入るかどうか疑問が残る。そこ行くとiPhone5sが適度に小さいんですよね。小型のものは最近まともな機種は出ていないみたい。Nexus5はiPhone6よりでかいのか…そして期待したZenFone5はNexus5よりもさらに大きかった…そしてiPhone6 Plusというどでかいやつよりも大きいNexus6という…おまえらおかしいだろうと。ポケットに入れて持ち歩くんだよ?

だがここは大型化のビッグウェーブに乗っておくべきではないか? という気持ちもあるのだった(続く)

全日本空手道選手権大会2014

昨日は行ってきました東京体育館。長渕剛のエンドレスヘビーローテーション。新極真の風が吹く。まさしく名曲です。

少年部の演武もなかなか素晴らしい出来。

「俺達のケンブ」こと入来建武は準優勝。決勝では引き分け延長なら行けるか、と思ったところで旗が3本上がりました。あれでまだ19歳ですからね。見た目はとてもそうは見えませんが。

カラテはルールが分からないながらも選手によって特色もあって、見ているだけでも楽しめました。顔面殴打が反則なので一発KOみたいなものはほとんどなく、ボクシングと違って派手な防御技術は要求されません。互いに打ち合って時折見せる足の大技という感じ。つまりダメージが蓄積していく。最後に上回ったほうが勝つ。ニンジャのイクサのように最後に技ありで逆転した楠生選手の試合あたりはなかなか凄かった。この大会は体重制がなく、引き分けだった場合に体重差が一定以上あれば軽いほうが勝つ、というレギュレーション。

俺達の入来建武は時間の使い方は巧みなものがあり、ボクシングみたいにラウンドの終盤でしっかりラッシュをかけて審判の印象を高めるような戦術を採っていた。まあ「ラウンド」という概念はないしポイント制もないが、有効でしたね。蹴りも下段中段に集めて、身体のバランスを崩さずに打ち続けていくという、恵まれた体格を活かしつつ弱点が少ない戦い方。勝ち上がり方も危なげなく、このやり方で安定して勝っていけばいいんじゃないかな。

カラテはオリンピック種目を目指しているそうで、いろいろあるみたい。

川崎2-0鳥栖 (こんなに寒いんですね)

10月の夜雨の寒さときたら。会社を抜け出した1万人くらいが聖地等々力に集まりました。私も後半途中から参加。すでに田中裕介がゴールを決めて、小林悠のゴールの直前くらいに中に入りました。新丸子から歩いてきて、歓声の感じでゴールしたなってのは分かったんですけどね、7番ゲートまでぐるっと回っているのがもどかしい。

試合のほうはあまり危なげなく…というほどではないけど、まあ実力の差がそのまま出たかなと。試合が終わって記録を見てやっと気づきましたが、相手は一人退場になってたんですね。2点差だし憲剛はこのまま温存かと思いきや、顔見せで出てきました。そこはパウリーニョか稲本あたりかなと思ってたんですけどね。

しかし今節の上位陣は川崎以外は総崩れ。浦和の背中が少し近づきました。残り5試合で6ポイント差。川崎は先日のアウェイガンバ戦で負けたことが悔やまれます。でも直接対決がなく他力ですけど、勝ち続ければ可能性は…

今後の対戦は以下の通り。

勝ち点クラブ3031323334
57浦和A鹿島AマリノスHガンバA鳥栖H名古屋
52ガンバH東京H仙台A浦和H神戸A徳島
51川崎A甲府H清水A鹿島H広島A神戸
50鹿島H浦和A新潟H川崎AセレッソH鳥栖
50鳥栖H新潟H神戸A徳島H浦和A鹿島

どうでしょうね。鹿島はガンバ以外とは直接対決があります。鳥栖も浦和鹿島との当たりを残してますし、ガンバも浦和との当たりを残してます。浦和も川崎以外とは当たりますね。あとは神戸(鳥栖ガンバ川崎)や徳島(鳥栖ガンバ)、新潟(鳥栖鹿島)といったあたりとの対戦が鍵を握っているのかな。

あとはもちろん、32節のガンバと浦和の直接対決が天王山? 直接対決もけっこう多いし、楽しみですね。いずれにせよ浦和が猛烈に優位に立っているのは間違いない。なにせ2位に5ポイント差つけている。実際のところ手強いのはガンバと鹿島で、直接叩けばいいだけでしょ。大船に乗った気持ちでいるといいですよ。あとはガンバ。アウェイ浦和戦で勝つことを前提にすれば、ほかはホームだったり降格が決まった徳島だったりするので、5チーム中で当たりは最も良くて、チャンスは意外に大きい。

H/Aで言うと、川崎と浦和以外はホームで3試合戦えます。でも川崎と浦和は関東圏なので移動はそれほどないかな。鳥栖もアウェイは近い徳島と最終節の鹿島なのであまり移動の影響は心配しなくても良かろう。

Yosemiteと共に生きていく

会社のMBPもYosemiteにしました。昼休みに昼飯を食いにいっている間に終わっているつもりだったが、自宅のMBPと同じところで詰まっていた。適当にログを見ていると、JMicronのkextのロードが云々…で止まってた。まあ同じようにログを見ているうちに通過し、無事にYosemiteになった。JMicron? なんだろう。何かそんなものをインストールしたかな?? 覚えてないな。

通知の株価のところ、会社でやると日本市場のコードしか出てこなかったりする。プロキシで何か制限したりしているのかもしれない。それ以外は大したトラブルもなく進んだ。

Yosemiteが最高すぎて生きるのがつらい

どこを見ても、力に満ちている? こういうキャッチコピー考えてるの誰なんでしょうね。

現時点で実用的なUnixのデスクトップ環境としては唯一と言ってもいいくらいの地位を築いたMacOSだが、OSのアップデートはどうか。FedoraのpreupgradeやFedUpとくらべてどうなのか…

アップデート中、残り1分の表示が出てから30分以上動きがなくて焦りました。適当に操作してたらいきなり画面上部にカーソルと近づけるとメニューが表示されることに気づいて、そこから「ログ表示」みたいにしたら何か動いているようで、ログの流れを眺めていたら再起動がかかって、そこからは無事に進みました。

今日の午前中、会社のMBP(自宅と会社で同じ機種を使ってます)でやるのを控えて良かったです。MBPの1台しか手元にないので、長時間仕事にならないところでした。しかも会社のは最近立て続けにSMCリセットをかけなきゃいけなくなったという不調なMBPなので。来週の帰り際か昼休み前にでもやろう。

まあハラハラドキドキさせてくれますよね。期待を裏切らない。

見た目のフラットデザイン(?)は違和感がありすぎる。システムフォントも変わった(よね?)。前のも悪くなかったけど、Yosemiteのフォントも嫌いじゃないですね。iTunesが赤くなったのも謎だ。何かの警告かと思っていろいろいじったりしてみたが問題はなさそうで、ぐぐったらこれ、「Appleが気の迷いで単に赤くしてみた」ってだけなのね…そう来たかよ。

通知のところに株価を表示できるようになったが、日本市場のticker codeは無味乾燥な数字なので、いまいち。米国だと会社名を推測できるのだが…まあ一応日本市場にも対応しているところは偉いな。たまたま私が務めている会社は東証とNASDAQに上げているので、並べて比べることができたりする。

SQLで採番

ユニークな番号を採番したいケースがありますよね。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を使ってみる場合はこんなクエリになる。

SELECT (t2.num+1) FROM tbl t1
 RIGHT OUTER JOIN tbl t2
 ON t1.num=t2.num+1
 WHERE t1.num IS NULL

これはsimple queryが2発。見るからに問題は起きなさそう。

mysql> EXPLAIN SELECT (t2.num+1) FROM tbl t1
    ->  RIGHT OUTER JOIN tbl t2
    ->  ON t1.num=t2.num+1
    ->  WHERE t1.num IS NULL;
+----+-------------+-------+--------+---------------+---------+---------+------+------+--------------------------------------+
| id | select_type | table | type   | possible_keys | key     | key_len | ref  | rows | Extra                                |
+----+-------------+-------+--------+---------------+---------+---------+------+------+--------------------------------------+
|  1 | SIMPLE      | t2    | index  | NULL          | PRIMARY | 4       | NULL |    1 | Using index                          |
|  1 | SIMPLE      | t1    | eq_ref | PRIMARY,num   | PRIMARY | 4       | func |    1 | Using where; Not exists; Using index |
+----+-------------+-------+--------+---------------+---------+---------+------+------+--------------------------------------+
2 rows in set (0.00 sec)

たとえばSqliteはRIGHT OUTER JOINが使えないのでLEFT OUTER JOINを使うと、、、

SELECT (t1.num+1) FROM tbl t1
 LEFT OUTER JOIN tbl t2
 ON t1.num+1=t2.num
 WHERE t2.num IS NULL

これもsimpleが2発。

mysql> EXPLAIN SELECT (t1.num+1) FROM tbl t1
    ->  LEFT OUTER JOIN tbl t2
    ->  ON t1.num+1=t2.num
    ->  WHERE t2.num IS NULL;
+----+-------------+-------+--------+---------------+---------+---------+------+------+--------------------------------------+
| id | select_type | table | type   | possible_keys | key     | key_len | ref  | rows | Extra                                |
+----+-------------+-------+--------+---------------+---------+---------+------+------+--------------------------------------+
|  1 | SIMPLE      | t1    | index  | NULL          | PRIMARY | 4       | NULL |    1 | Using index                          |
|  1 | SIMPLE      | t2    | eq_ref | PRIMARY,num   | PRIMARY | 4       | func |    1 | Using where; Not exists; Using index |
+----+-------------+-------+--------+---------------+---------+---------+------+------+--------------------------------------+
2 rows in set (0.00 sec)

まあでも実際、やってみるとクエリの時間に大差ないんですよね。↑の場合はjoinよりもdependent subqueryのクエリのほうがむしろ(若干)速かったりするしね。

ああ、↑で書いたクエリはテーブルがカラの状態では何も返ってこない。最初に初期値(0とか)を入れて番兵みたいにしておくとか、カラの結果だったら適当に選ぶとかする必要がある。

暦の説明についての後悔

後悔というほどでもないけど、子供と雑談していて暦の説明をしたんですが、もっといい説明ができたかもしれないなと。

まず、暦というのは種をまく時期を決めたりするから非常に重要なものであったと。このへんは説明できた。

太陰暦というのは月の満ち欠けを数える暦で、だいたい1年に12回新月→満月(→新月)を繰り返すことから12ヶ月になった。だから太陰暦時代は毎月15日あたりが満月だった。なんで太陰暦になったかというと、月は形が変わるので太陽よりも観測しやすい。形を見ながら数えてればだいたい29〜30日くらいで1周するし、12回くらいで季節が元に戻るというのが昔の人にも分かったわけだ。このへんは説明できなかった。

しかし12回の月の満ち欠けでは1年とは誤差が大きすぎ、たまに1ヶ月追加したりしないと季節がズレていってしまい、不便が大きい。そこで太陽の角度とかを観測する技術が出て太陽暦になった。これだと太陰暦に比べてズレが少なく、だいたい4年に1回くらい2/29を追加することで1日以内のズレにできたわけだ。このへんは多少まともに説明できた。まあ時代によって観測精度が上がってきてうるう年の追加方法が変わったとかいうのは説明できなかったな。

単に「昔は太陰暦があったけど今は太陽暦なんでズレが少ないんだよね」という説明は上手くなくて、技術の推移で説明してけばもっと分かりやすかったな、と思ったんですね。実際に子供でも月の形の変化を知ってるわけだが、太陽の変化を知ることはできないでしょう? 大人でも多くの人は太陽の変化で暦を作るなんてできないだろう。月の形を見ながら日数を数えるくらいなら、子供でも日記をつければできるような気になれるんじゃないかと思う。

でも、なぜ昔は太陰暦だったかなんて、誰も教えてくれなかったな。Wikipediaにも書いてない。だから「太陽よりも月のほうが観測しやすかったから」が正解なのかは正直、自分にも分かってないのだが、そう考えるしかないよな、と思っている。まあ潮の満ち引きを知りたい云々…というのはあるんだろうけど、それって後付けだよね。

まあたぶん子供はしばらくしたら忘れてるんだろうけど。

川崎3-2ガンバ (森島)

久々に行ってきました昨日の等々力。その前には宮内の鎮守の森の春日神社の祭りがあって、神輿だの山車だの。山車は引いてお菓子をもらったりしてましたが、そんなこんなは置いといて。ハゲつるピッカーンな奴が子供3人連れて、ゴール裏でちょこまか動く子供をフォローしながら見てました。ナビスコ準決勝で、アウェイで1-3で負けて帰ってきたという状況。2-0で勝つか、3点差で勝てば上がり。

試合の出だしは快調で、後半途中までは行ける感じがしてました。サブに中村憲剛がいたから、1点取ればいいという状況になったら憲剛が全てを決してくれるだろうというね。でもあと2点。あと2点になってからが長かった。余計な失点が重くのしかかり、敗戦。憲剛の決まるところも相手DFの突き出された尻にブロックされて枠外へ。無失点で済むとは思えなかったから4点は最初から必要と見込まれてたよね。2失点したから5点が必要になった。

全体的には、もし森島が決めてれば、みんながハッピーだったろうと。もし決めてればね。仮定法過去完了? だっけ?? 2本ほど好機がありましたよね。

まあ小林悠(代表に呼ばれて不在)がいたら、5〜6本ばかり外すか、あるいは2本決めるかしてたろう。私としては久々の等々力で久々の勝利ということで気分は悪くないはず…だけど、目的を達成できなかった残念さが強かった。