実際、悩んでいるげな記事を書いた数分後に発注してたんですけどね。持ち歩く電話がNexus5になりました。このタイミングでNexus5ですよ。6が出る直前。個人向けChromebookが出たりする話題の中。だいたいPlay Storeでもとっくに売り切れてるじゃないですか。ただですね、Lollipopが降ってくるという話ではあるし、6はでかすぎるらしいので、5でいいかなと。あと6はMotorolaになるので、別のベンダのを試したかったというのもある(Motorolaのは壊れるまで使ったが、LGのは使ったことがなかった)。 使った感じはかなり良い。でかいのでポケットがはちきれそうなのは置いといて。「おーけーぐーぐる」も日本人の発音で反応します。…が、これを人前で声に出すのは恥ずかしい＆一人のときに発音するのも自分が自分で恥ずかしいので、たぶん一生使わないでしょう。使わないクセに自己主張の激しいクソ機能だと思います。いつか「おーけーぐーぐる　お前を消す方法」と発音するかもしれませんね。 数日WiFiのみで使ってから、SIMカードも入れて無事に電話に。LTEの表示が輝かしい。今まで3Gの電話だったので、LTEが使えなかったのよね。標準のブラウザがChromeになってくれて、だいぶスッキリしました。まあそれもこれも今さらな感想ですが… 写真のGPSタグがどうなるのか気になって外で撮ったりしてましたが、あんまり精度が良くないみたいな感じです。GPSTestとかを使って見ていると比較的すぐに位置が決まるので、写真のアプリがぼかしているのかな？ それとも何かオレの操作が悪いのか？？ そのへんはよく分からない。カメラは全方位の写真を撮るやつ(Photo Sphere)がなかなかイカしてますね。ビューワも面白いし。 あと顔認証。これで子供には勝手に使わせないぞ、と。三男は顔認証で出てくる自分の顔にパンチして喜んでたりもしますが、勝手に使われることは防げそうです。今まで隠れて勝手にゲームしてたりしたんだよね。まあ急に静かになったり効果音が聞こえたりするのですぐに気づき、少し泳がせてから捕まえてた。 しかしですね、最初に設定した単純なパスコードのパターンは次男にあっさり破られてしまいました。恐るべし次男。ちょっと変えて、今はバレてません。でも放っておくと緊急通報しかねないので、そこは注意が必要か。 音楽も鳴らしたりしてみましたが、これも悪くないです。まあ音楽の場合はヘッドホンの出来のほうが要素としては大きいので。最初は端子を奥まで押し込めなくて(固かった)、スピーカーから出る音をヘッドホンごしにかすかに聴いて「あれ？」って感じでしたけどね！ でもまあ、結局やってるのはFBReaderでEPUBの本を読んでるか、数独かCalcudokuやってるかくらいの地味な使い方に落ち着きそう。今までと変わらんじゃないか。あとちょっとしたときに顔認証やるのがクセになってますね(笑)。時刻を確認したいだけのときでもカメラが起動するのは電池の無駄かも？

先日お伝えしたのるレージの邪悪さだが、最近はどうなのか？ ↓正解はこちら↓ 毎月11日にアクセスできないだけでなく、12日も過負荷でヤバかったぞ。過負荷が増大しているのでは？ 何とかしろよ東急。アナウンスを一斉じゃなくて数日に渡ってずらすとか、11日だけサーバを増強するとか(クラウド使えばできるでしょ？)、何とかならないんすかね！

毎日github(enterprise)で生活している私にとってOctopressはなかなか快適なんですが、ひとつだけ問題があった。 octopressのテーマのファイルはほとんど全てになっている。これは普通は問題にならないが、例えば今のNexus5(KitKat)のChromeブラウザはlang=“en"だとフォントが汚いんですね。ひところの違和感以外に感じるものがない中華フォントよりはマシだけど、やはり日本語のフォントではないっぽい感じに描写される。「写」「反」の字とかが非常に気になるわけだ。例えば大手サイトだとhuffingtonpost.jpのモバイルサイト(.comドメイン)もやはりlang=“en"になっているのでフォントは汚い。 英語と主張するUTF-8文書でCJK領域のコードが来た時に、どの言語のフォントを使うかを選択する、そこで中国のフォントが選択される…これが中国と日本の人口の差なのかな。消費地としては日本の市場のほうが魅力があると思うんだけどね云々。 そこで。

小さな縁日でよくあるスーパーボールすくい。あれで一番人気なのが、LEDで光るうんこ。なんでまたうんこの形をしちゃってるんでしょうね。いずれせよ、他の形状よりもうんこの人気が高いのは間違いのないことだ。一応密閉されているので水に浮かべても大丈夫。 わたなべ家の息子たちは先日、小学校のイベントのスーパーボールすくいでこの輝けるクソを入手。かなりハッピーな状態になってます。翌朝起きるなり「ひかるうんちは？」と聞いてきたりね。おいおい何時だと思ってるんだ。自分で探せよと。

いろんなことがありました。学生時代に借りていた奨学金を、ついに完済しました。3X歳の誕生日。フロンターレは肝心なところでの負け癖が相変わらずであることを確認しましたが、私はひとり祝杯を上げています。缶ビールでね。 実際のところ、分別のつく大人になって考えると、貸与の奨学金というのは良い制度ではなかったと思います。対象者を増やせる利点はあるにしても、貸与で年間100万くらい借りられるんですけど、私の場合はマスター(修士)の2年間借りて200万の借金がある状態で卒業しました。就職先があったから良かったようなものの、就職できなかったらと考えるとぞっとしますよね。今から思うと24とかそこそこの若いやつに学業のために借金負わせて放り出すなんてオニですよ。そんなに辛く当たってくれなくても良かったんじゃないかなと思う。若い人への教育は社会のためにもなることでしょう？ 200万って、もっと大人になったらはした金でも、若者には大きなお金ですよ。 理系の人間がマスター行きたかっただけで、悪いことしてるわけじゃないんだよ。知らない人も多いのかもしれませんが、理系だと半分くらいの学生がマスター行くんですよ。ドクター行くのは物好きだけだけど、マスターは普通の学生の半数が行くもの、なわけだ。

昨日は行ってきました東京体育館。長渕剛のエンドレスヘビーローテーション。新極真の風が吹く。まさしく名曲です。 少年部の演武もなかなか素晴らしい出来。 「俺達のケンブ」こと入来建武は準優勝。決勝では引き分け延長なら行けるか、と思ったところで旗が3本上がりました。あれでまだ19歳ですからね。見た目はとてもそうは見えませんが。 カラテはルールが分からないながらも選手によって特色もあって、見ているだけでも楽しめました。顔面殴打が反則なので一発KOみたいなものはほとんどなく、ボクシングと違って派手な防御技術は要求されません。互いに打ち合って時折見せる足の大技という感じ。つまりダメージが蓄積していく。最後に上回ったほうが勝つ。ニンジャのイクサのように最後に技ありで逆転した楠生選手の試合あたりはなかなか凄かった。この大会は体重制がなく、引き分けだった場合に体重差が一定以上あれば軽いほうが勝つ、というレギュレーション。 俺達の入来建武は時間の使い方は巧みなものがあり、ボクシングみたいにラウンドの終盤でしっかりラッシュをかけて審判の印象を高めるような戦術を採っていた。まあ「ラウンド」という概念はないしポイント制もないが、有効でしたね。蹴りも下段中段に集めて、身体のバランスを崩さずに打ち続けていくという、恵まれた体格を活かしつつ弱点が少ない戦い方。勝ち上がり方も危なげなく、このやり方で安定して勝っていけばいいんじゃないかな。 カラテはオリンピック種目を目指しているそうで、いろいろあるみたい。

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を使ってみる場合はこんなクエリになる。