Skip to main content

ログ取得ツール

Vagrant + AWSメモ

vagrantのawsプラグインを今更ながら使う。Macになって、VagrantもWindowsから使ってた頃よりも使いやすくなったので。普段はVirtualBoxなんですが、台数を稼ぎたい時なんかには必要だろうなぁと。自宅で遊ぶのに台数が必要か? と言われると困るが。

  • security group(ファイアウォール)を正しく設定しないとsshで入れない。Vagrantfileでもそれを指定する。
  • Amazon Linuxの場合はユーザ名がec2-user、RHELはroot、Ubuntuはubuntuと選択するOSによって異なる。これもVagrantfileに書く。
  • sshの秘密鍵(keypair)をVagrantfileと同じディレクトリに置くと、rsyncでVMの/vagrantに転送されてしまう。Vagrantfileは転送されない。
    • だがvagrant rsyncでどちら方向にもコピーされてないような気が…
  • Amazon Linuxのsudoersはrequirettyが有効なので/vagrantを作れなくてエラーになる。
    • requirettyの行をコメントアウトしてvagrant provisionでOK
  • 警告の消し方が分からない

警告というのは、これ。

MacBook Pro

転職を期に、Macとgitの人になってみました。転職前はLinux/Windowsとmercurialだったんですけどね。40を目前にして、自分を取り巻くコンピューティング環境がだいぶ変わりました。

新しい職場ではMacを使っている人が多かったので、まあ月に1度くらいWindowsが必要なシステムを使うケースもあるんですが、その場合はVDIを利用させてもらうことにして、MacBookProのRetinaディスプレイモデルを買わせてもらいました。これが殊の外具合が良いので、自宅でも同じの買っちゃいましたよ。安いし。画面が異常に美しいです。壊れてるんじゃないかと思うくらいに。計算性能も良い。

プログラミング方面では、brewとかvagrantとかchefとか、Rubyで書かれているものが多いこともあり、仕事上でも関係するので意識的にRubyを使おうとしていますが、まだPythonを使ってしまう癖が抜けてません。自分ではRubyは避けてJavaScript(node.js)に行く予定だったんですが、どうもそうも行かないような気配。いずれにしてもC/C++からは離れていきそうです。せっかくMacはclang/LLVMでObjective-Cなのにね。

トッキュウジャー…名作の鼓動

なんというか、そんなエピックなイマジネーションを感じませんか? まあ、無駄に伏線を張りすぎな感もあるが(複々線化されちゃってる、みたいなね)。

キョウリュウジャーはドゴルド/空蝉丸やトリンあたりのエピソードは盛り上がったが、他はそれほどでもなかったように思う。

川崎2-2神戸 (リーグ戦開幕)

ついにリーグ戦も開幕。等々力は雨で寒くて泣きそうでした。帰り道も暗くてね。この季節は、できればもっと昼間にやって欲しいですね。

試合の方は同じスタメンでやった貴州戦よりも良い試合になっていたように思いますが、結果はロスタイムに追いつかれての2-2。2005年の怒涛の開幕4試合(?)連続ロスタイムゴールを思い出しますね。

しかしこの季節に異常な強さを見せる印象のある神戸相手に負けなかった、2点取れたというところはポジティブ。内容も悪くない。

川崎1-0貴州 (シーズン到来!)

一足お先にシーズン到来。ゼロックスがあった広島とマリノスよりは一歩遅いが。

久々の等々力は寒かったが風が弱かったのでまだ普通に過ごせた。ただ、買った食料は冷えきっていた。

貴州はアップのときにサブの選手(に思える格好をした大柄な人々?)がボール拾いをやっていた。プロではあんまり見ない光景だなぁと思ったが、あれ本当に選手だったのかな?

芝は先日の雪の影響を受けたはずだし季節も季節なので青々とはしていなかったが、破綻はない状態だったと思う。

パウリーニョは実力を見せたが、今日の出来であれば山本真希でも同等以上にやれたろう。川崎もボールは持ててパスも回るが危険なプレーの頻度は低く、得点チャンスも少なかったよね。これからシーズンを進めながら調子を上げていって欲しいところ。シーズン開幕でレナトのFKに勝ち点をもらうのは、実は毎年かも?

貴州は前半に9番のでかい中心選手が負傷で下がった形だが、選手を入れ替えて内容を向上させたようにも見えた。川崎は最後まで選手交代なし。それなりに危うい場面もあったが気を抜かずにカバーした。

何度削除しても復活するGoogle+ Auto Backup (2)

やはり実行ファイル(C:\Users(username)\AppData\Local\Programs\Google\Google+ Auto Backup\Google+ Auto Backup.exe)のファイル名変更だけではあっさり復活した。

まあ、あいつらはそんな甘い奴らじゃないだろうと思ってたよ。

もしかして、Picasaが復活させてるんじゃないか?

C:\Program Files (x86)\Google\Picasa3\GPAutoBackup.msiの名前も変更して、様子を見る。

次復活したらどうしよう。見つけ次第殺すスクリプトをタスクスケジューラで仕込もうか…

何度削除しても復活するGoogle+ Auto Backup

まるで、ばいきんまんのように何度やられても決して諦めない。こいつのアンインストールは単なる「ばいばいき~ん」であって、真の意味でのアンインストールには程遠いのだ。Picasaを使っている限り、何度でも復活する。Picasaは使いたい、でもAuto Backupは気持ち悪い。そういうユーザーはどうしたらいいのだろうか?

ぐぐっても「こんなに便利」「オン/オフの切り替え」「バックアップされた写真を削除するには?」くらいの情報しか出てこない。Google+使ってないし一度もバックアップしたことないので、単に使わないからアンインストールしたいだけなのだ。起動するたびに変なダイアログが出るのがね。こんなの出てきたら子供が勝手にクリックしちゃうでしょ。

しょうがないので、実行バイナリをxxxx.exeからxxxx.exe.bakにリネームしてみた。

これでしばらく様子見。

これでも復活したらどうしよう…

vagrantとchefを使うときの注意点 (1)

ふつう/tmpはtmpfsにしたいと思ってこういうrecipeを書くじゃないですかーやだなーもう。

mount "/tmp" do
  pass 0
  fstype "tmpfs"
  device "none"
  action [:mount, :enable]
end

それをVagrantで操作しているVMに適用するような操作をすると、cookbookが見つからないとかいうエラーが出るじゃないですかー。

Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'cent64'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Fixed port collision for 22 => 2222. Now on port 2200.
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2200 (adapter 1)
[default] Running 'pre-boot' VM customizations...
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
DL is deprecated, please use Fiddle
[default] Machine booted and ready!
[default] The guest additions on this VM do not match the installed version of
VirtualBox! In most cases this is fine, but in rare cases it can
prevent things such as shared folders from working properly. If you see
shared folder errors, please make sure the guest additions within the
virtual machine match the version of VirtualBox you have installed on
your host and reload your VM.

Guest Additions Version: 4.2.16
VirtualBox Version: 4.3
[default] Mounting shared folders...
[default] -- /vagrant
[default] -- /tmp/vagrant-cache
[default] -- /tmp/vagrant-chef-1/chef-solo-1/cookbooks
[default] Running provisioner: chef_solo...
[default] Configuring cache buckets...
Generating chef JSON and uploading...
Running chef-solo...
[2014-01-24T14:08:47+00:00] INFO: Forking chef instance to converge...
[2014-01-24T14:08:47+00:00] INFO: *** Chef 11.6.0 ***
[2014-01-24T14:08:48+00:00] INFO: Setting the run_list to ["recipe[base::tmpfs]", "recipe[base::ntp]", "recipe[base::timezone]", "recipe[base::epel]"] from JSON
[2014-01-24T14:08:48+00:00] INFO: Run List is [recipe[base::tmpfs], recipe[base::ntp], recipe[base::timezone], recipe[base::epel]]
[2014-01-24T14:08:48+00:00] INFO: Run List expands to [base::tmpfs, base::ntp, base::timezone, base::epel]
[2014-01-24T14:08:48+00:00] INFO: Starting Chef Run for localhost
[2014-01-24T14:08:48+00:00] INFO: Running start handlers
[2014-01-24T14:08:48+00:00] INFO: Start handlers complete.
[2014-01-24T14:08:48+00:00] WARN: Cloning resource attributes for service[ntpdate] from prior resource (CHEF-3694)
[2014-01-24T14:08:48+00:00] WARN: Previous service[ntpdate]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/base/recipes/ntp.rb:21:in `block in from_file'
[2014-01-24T14:08:48+00:00] WARN: Current  service[ntpdate]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/base/recipes/ntp.rb:27:in `block in from_file'
[2014-01-24T14:08:48+00:00] WARN: Cloning resource attributes for service[ntpd] from prior resource (CHEF-3694)
[2014-01-24T14:08:48+00:00] WARN: Previous service[ntpd]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/base/recipes/ntp.rb:21:in `block in from_file'
[2014-01-24T14:08:48+00:00] WARN: Current  service[ntpd]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/base/recipes/ntp.rb:27:in `block in from_file'
[2014-01-24T14:08:48+00:00] WARN: Cloning resource attributes for execute[rpmkey] from prior resource (CHEF-3694)
[2014-01-24T14:08:49+00:00] INFO: mount[/tmp] mounted
[2014-01-24T14:08:49+00:00] INFO: mount[/tmp] enabled

================================================================================
Error executing action `install` on resource 'yum_package[ntp]'
================================================================================


Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of /usr/bin/python /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/provider/package/yum-dump.py --options --installed-provides ----
STDOUT: [option installonlypkgs] kernel kernel-bigmem installonlypkg(kernel-module) installonlypkg(vm) kernel-enterprise kernel-smp kernel-debug kernel-unsupported kernel-source kernel-devel kernel-PAE kernel-PAE-debug
STDERR: yum-dump Repository Error: Error making cache directory: /var/cache/yum/x86_64/6/base error was: [Errno 2] No such file or directory: '/var/cache/yum/x86_64'
---- End output of /usr/bin/python /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/provider/package/yum-dump.py --options --installed-provides ----
Ran /usr/bin/python /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/provider/package/yum-dump.py --options --installed-provides returned 1


Resource Declaration:
---------------------
[2014-01-24T14:08:50+00:00] INFO: Running queued delayed notifications before re-raising exception
[2014-01-24T14:08:50+00:00] ERROR: Running exception handlers
[2014-01-24T14:08:50+00:00] ERROR: Exception handlers complete
[2014-01-24T14:08:50+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Chef never successfully completed! Any errors should be visible in the
output above. Please fix your recipes so that they properly complete.

Vagrantはcookbookやキャッシュを/tmp以下にマウントするんですよね。だからcookbookの中で/tmpをマウントしてカラにしたらcookbookのファイルが読めなくなってダメなんですな。actionからmountを外せば問題は解消しますが、/tmpがtmpfsになるのはリブート後ということになります。

3人でババ抜きをしたときの勝利確率は?

最近、3人でババ抜きをするケースがあります。誰が勝つ確率が高いのか。Pythonでサイコロを振ってみました。1000ゲーム。もっと多いほうがいいのかもしれない。

20140123001009

初期状態でババを持っている人(ババ持ち)が1抜け(win1)する確率は28%ですが、なぜかババを持っている人から引く()人物が1抜けする確率24%よりも高いです。しかし、初期状態でババを持っている人にカードを渡す(初期状態でババから最も遠い人物=最後)が1抜けする確率は実に47%に達します。この人物は負ける確率も24%と最も低いです。しかし2抜けに着目すると、が最も高い43%となりました。

次、何ターンまでゲームが進むか。以下の通り。横軸がターン数で、ターンの左縦軸が頻度、CDFもプロットしてみました。

20140123001924

1ターンが10秒で進むとすると、だいたい20ターン(3分半)程度で終わるケースが多いということになります。50%のゲームは20ターンで終わります。1ターン3秒なら1分で終わります。

カスミガセキ・ジグラッドは実際何階あるのか?

今日のメリークリスマス・ネオサイタマの再放送を見て気になった、カスミガセキ・ジグラッドの階数。

  • 最上階はこの時点で700階
  • 不吉を忌み嫌う日本人の慣習より、4や9の数字が含まれる階や部屋は存在しない

計算してみる。

# python
>>> def isinvalid(n): return "4" in str(n) or "9" in str(n)

>>> isinvalid(4)
True
>>> isinvalid(1)
False
>>> 700-len(filter(lambda f: f, map(isinvalid, range(700))))
384

実際のところはだいたい380階くらいなんですね。388階の次が500階とか、使いにくいビルなのは間違いない。

現実の日本の最高だとあべのハルカスの300m(60階)ですが、階数で言えば横浜ランドマークタワーの296m(70階)が最高。その5~6倍の高さと推測できるため、最上階の標高はだいたい1600m程度か。マルノウチ・スゴイタカイ・ビルのモデルとなった丸ビルは179.2m(37階)、新丸ビルは197.6m(38階)なので、それらの10倍の高さ。ネオサイタマは地震とか大丈夫なんでしょうか?

来年完成(再建)予定のニューヨークのワールドトレードセンターの1番は541m(本体は415mで108階)、世界一のブルジュ・ハリファは828m(本体636m、160階)ですから、まあスケール的には参考になるかな。