(合理的な)理由

先月、髪を切りにいった時の美容師さんとの会話にて。結婚する合理的な理由て無いなと話をしていた。

美容師さん自身は既婚でありお子さんもいるので、まぁ話半分でもあり、間違いなくそっち側へ話を向けるほうが無難ではある。（未婚者にやたら「いいもんだよ」とすすめてもしょうがないだろうし、その場合言葉の端々から滲み出る優越感は隠せないだろうしねぇ）

・・とは思いつつも、やはり自分の場合には合理的な理由はない。
 家を継がなきゃというのはないし、世間体を気にするというのもないし、、。

「既婚者でなければ資格が与えられない」なにかの場合のみかな。
例えばフリーメイソンに入るとか。（と思ったら、どうも独身者でもいいのね。。）

まー、そういうのを一切考えなくても、ただ単にマネーパワーが全然足りない気がする。それが全てではないけど、ないと間違いなく困るよね。

gce をほんのすこしだけおさわり

GCEをすこーし触ってみた。一般提供開始前に使える状態にはあったけどずーっと放置していた。

https://cloud.google.com/ へいく
上部の Go to my console をクリック、Google Developer Console へ。

自分の場合はまえ作るだけで終わったプロジェクトが残ってたのでまずはお掃除。プロジェクトを削除し、心機一転、新しいプロジェクトを作成した。

課金の設定が必要だったのでぽちぽちと入力。種類は individual。（この時点では英語表示で利用していた）

コンソールが多言語対応しているということなので、日本語で利用。 気に食わなかったら英語に戻すつもり。
英語、スペイン語、ポルトガル語、中文(台灣)、日本語が選べる。

コンソールは、作成したプロジェクトから Compute Engine をクリックすればよい。
「VM インスタンス」=> 「新しいインスタンス」からさくさくとインスタンスは起動できる。
AWSでいうRegionという区分けは無い（？）ようで、インスタンス起動時に「ゾーン」から us-centralか、europe-west か、asia-east かを選ぶ。それぞれ a,b がある模様。

マシンタイプは慣れてないのでなにがなんなのかさっぱりわからない。スペックが表示されるからよいものの、まちがってハイスペックなのを起動しそうではある。すぐ止めればよいか。
ブートソースはいまんとこ選択肢が少ない。 debian と backports-debian の違いはなんだろう。rhel は別に課金されるんだろうか。

起動後は gcutil というのを利用し SSH。なのでまず gcutil を入れねばならんのだった。SSH鍵は実行時によきに計らってくれるので親切。

katsuji@testgce:~$ uptime
 16:57:13 up 25 min,  1 user,  load average: 0.00, 0.01, 0.05
katsuji@testgce:~$ cat /proc/version
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2

ps とってみると xen なんちゃらみたいなのはいないみたいなのでKVMか、と思ったらFAQにあった。
https://developers.google.com/compute/docs/faq?hl=ja#whatisgooglecompute

↑みるまえに slabbed-or-not というのを使ってみていた。

katsuji@testgce:~/slabbed-or-not$ ./slabbed-or-not
Not running under any known container type
Hypervisor: KVM

後発ならではの利点をふんだんに生かすのだろうな、と何となく思う。

コンソールの日本語表示は、エフェメラル/静的 と書くならエフェメラル/スタティックでよいんじゃないの、と思う箇所があったり。グラフ表示で 1hour, 1day となっていたりするので要所は抑えて対応してる感じかな。
「新しいインスタンス」クリック後に
Create a new instance  Show advanced options 
とでてきたりもしている。

かるく触ってみたあとに思ったのが、コンソールは
Google "Developers Console"
なんだよね。Developer でない身にとってはなんとなく居心地わるい感じ。Developer でないのに使ってスミマセン＞＜的な。。

しばらくはどこぞのだれかの事例をあれこれみて楽しむことにしよう。

OpenSSL おそうじの件

fork したものに当分名称はつかない模様。
http://undeadly.org/cgi?action=article&sid=20140418063443&pid=3


OpenBSD まわりはやはり undeadly.org 見ておくのが良いですな。

OpenSSL の件

Heartbleed Bug
とゆうので賑わってたのだけど、そもそも自分は

ハートビート拡張がなんなのか知らない

という・・・ orz

各ディストリビューションでの対応は〜〜みたいなエントリはボコボコ立ってるので、ハートビート拡張とわなんぞや、OpenSSLでやらかした missing bounds check でここがこ〜なってるからやばいのよね、みたいなくわしい解説をしてるとこをちゃんとみておきたい。一方GnuTLSだとこうなってる、とかも。

こういうソフトウェアのCIってどうやってるんだろうね。

 
RFC6520
https://tools.ietf.org/html/rfc6520

1.0.1f と 1.0.1g の diff とってみたものの、、うーん、なんだこれ。

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
のとおり、素直にgit.openssl.orgでdiffみればいいか。


関連サイト追記:
Theo 様からのお言葉
http://undeadly.org/cgi?action=article&sid=20140408063423

ウェブスケールシーコー

Web Scale SQL
http://webscalesql.org/

米FacebookやGoogle、Twitterなどが独自のMySQL拡張「Web Scale SQL」を開発へ
http://sourceforge.jp/magazine/14/03/28/163000

素敵な協業。
FAQみると、MySQL Community release のブランチでありフォークではないと書いてある。

「MySQL」と一口に言っても、MySQL, Percona Server, MariaDB と、
この WebScaleSQLとあって、選ぶに悩む人々が増えるのかもしれない。
MariaDBは 10.0で独自路線になりつつあるからまた違うか。
そういえば Drizzle ってどうなってんだろう。

去年は
 グーグルがMySQLを切り捨ててMariaDBを採用
とゆーのがあったんだけど、しれっとMariaDBからWebScaleSQLへの移行とかしちゃってるんだろうか。だろうねきっと。

種類の違う難しさ

とある件で正しいと思える情報源に行き着くのがなかなかどうしてむつかしい。

余計に手間やつうしんパケットの無駄が発生してる感があり、
今後スケールできるのかなーと。今の自分が考える事柄ではないものの。

しばらくは（ワーストケースだと、ずっと）本来注力するところ意外に多くの時間を割かないといけないのかもしれない。
この、異質な難しさと気持ち悪さを解消、あるいは軽減しないとな。

「慣れだよ、慣れ」で済ますのもなんだしな。。

Project Euler 再開することにした

前の職場のわけしがやってるのに触発されたので、前ちょこっとやって放置したProject Eulerを再開することにした。

日々コードを書くおしごとではないので、時間を増やす意味もあり。

まずはわけしが解いてるとこまで追いつかねば・・・