台風が来たので自宅勤務してみた

台風がきていて、会社には行けそうだったけど無理せず自宅勤務でいいよって連絡がきてたので自宅勤務してみた。午後に山手線が止まっていたので、結果的に正解だった。家でフルタイムの仕事をしてみた率直な感想としては、仕事はできるけど慣れていないからか集中するのが難しいな、という所だった。

インターネットに繋っていれば仕事ができて、自宅はインターネットに繋っているので自宅で当然仕事ができる。ただ、会社で使っているモニタとキーボードがなかったので使い勝手はいつもと違うし、空調や照明なんかもいつもとは違うので違和感がある。特に、照明は暖色系のものを使っているので仕事向きではないような気がした。

家の中でもくつろぐスペースと何か作業するスペースをちゃんと分けたいなあ。

Rubyでstdoutl/errを標準出力/エラーとファイルの両方に出力する

stdout/stderrをファイルにも出力したくていろいろ調べて、いい感じの解決方法を見つけたのでメモしておく。

ruby-listにmatzが投稿していた(Re: puts,printの出力をファイルにも出力するには)。

これを実行すると、こうなる。

[ruby]
defout = Object.new
defout.instance_eval{@ofile=open("/tmp/test.log", "w")}
class <<defout
def write(str)
STDOUT.write(str)
@ofile.write(str)
end
end
$stdout = defout

puts ‘aaa’
[/ruby]

[text]
$ ruby ./test.rb
aaa
$ cat ./test.log
aaa
[/text]

なるほど、標準出力と標準エラーにputsされている。便利。

これができると、次はstdoutとstderrの両方をファイルにも出力したくなる。その場合はこうしちゃえばいい。

[ruby]
defout = Object.new
defout.instance_eval{@ofile=open("/tmp/test.log", "a")}
class <<defout
def write(str)
STDOUT.write(str)
@ofile.write(str)
@ofile.flush
end
end
$stdout = defout

deferr = Object.new
deferr.instance_eval{@ofile=open("/tmp/test.log", "a")}
class <<deferr
def write(str)
STDERR.write(str)
@ofile.write(str)
@ofile.flush
end
end
$stderr = deferr

puts ‘aaa’
warn ‘bbb’
puts ‘ccc’
[/ruby]

[text]
$ ruby ./test.rb
aaa
bbb
ccc
$ cat ./test.log
aaa
bbb
ccc
[/text]

flushしないとtest.logにstdoutが先に全て出力され、その後にstderrが出力されてしまうようだ。また、この方法だとsystemのような子プロセスの出力はteeされないので注意しないといけない。

APS-CからMFTに乗り換えた

写真を撮るようになってからずっと使っていたPENTAXとGRからLumix(Panasonic)に乗り換えた。フォーマットとしてはAPS-Cからマイクロフォーサーズ(MFT)。自分の中でかなり大きな変換点なのでいろいろ書いておく。

PENTAX

確か大学2年の頃に写真を撮るようになって、その時初めて買ったカメラがPENTAXのK100D Superだった。それからずっとメインカメラとして使っていた。しばらく撮らなくなったこともあったけど、2012年頃にK-5IIに買い替えて、その後FA31を購入している(2014年)。

GR

持ち歩き用にコンデジが欲しいな、と思って購入したが、スマホと役割りが被っているのと画角が自分の好みでなかった。スマホよりボケるけど暗所ではスマホの方が便利。

Lumix

購入したのはGX7 mk2とLumix 12-35mm f2.8。FA31ばかり使っていて少し飽きていたのと、そもそも歩きまわるのが好きなので一眼レフが重いという問題があり、乗り換えることにした。K-5IIとFA31で1.1kgなのに対し、GX7mk2と12-35mmだと731g。体積的にも小さくなって、これならずっと持ち歩けそう。大事なのは写真を撮ることで、自分の行動に合うものを選ぶべきだ。K-5IIはフィールドカメラで質実剛健だったが、そんな性能を必要とする場所に行くことはまずないのだ…

所感

やはり軽くてコンパクトなのはよい。コンパクトすぎてダイヤル操作が若干辛い事があるが、使い始めてまだ数週間なので様子見だろう。画質は、やはりAPS-Cに比べると若干負けている事があると思う。先日夕日を撮ったが、ISO200〜400で結構ノイズが乗っているように見えた。MFTだからなのか、手ぶれ補正等の影響なのかは分からないのでこれももうしばらく使ってみる必要がある。背面液晶がタッチパネルなのだが、これは非常に便利なので全ての背面液晶はタッチパネルになるべき。

 

P1010608
GX7 mk2で撮影した夕焼け。ISO200。

カーテンの自動開閉を実現するためにmornin’を買った

先日、mornin’というカーテン自動開閉ガジェットの存在を知った。

http://blog.horimisli.me/entry/mornin

調べてみると3,985円とお手軽だったのでさっそく購入して使ってみることにした。朝、amazonで2個購入して、翌日に到着。2個買った理由だけど、1個だけだとカーテンが両開きの場合片方しか操作できないためです。

開閉方法はタイマーによる自動操作とスマホをリモコンとして使う手動開閉の2種類。リモコンは複数のmornin’を同時に操作可能。スマホとmornin’を紐づける必要があるが、すごく簡単に紐づけることができた。

 

IMG_4493

 

操作したらこんな感じで開閉する。結構音は大きいが、この音で目が覚めることは自分の場合はないかな?

Hi-SPEED MODEを有効にすると若干早く動かすことができる。

目的は自動開閉なので、タイマーを設定する。とりあえずこういう時間にしてみた。

 

IMG_4494

 

IMG_4495

今朝自動で開いていたが、全く気づかなかった。結構いい感じ。

ただ、1点気になっていることがあって、それはカーテンを開いた時に端まで開かない所があること。カーテンランナーの間に設置するため避けられないのだが、なんとなくしまらないなあ。

IMG_20160807_115949

 

とはいえ、満足。アプリの操作も迷うことがないし設置も簡単で、すごくよくできたプロダクトだと思う。おすすめです。

 

Vagrant + CentOS7+ kdump でVMのメモリサイズが小さいとkdumpの起動に失敗する

別にVagrantに限った話ではないけど。
Vagrantでprovisionする時にkdumpを起動しているのだが、VMのメモリサイズが1GBになっているようなVMだとそれが失敗していた。
原因と対策について整理しておく。

発生した問題

例えば、以下のようなVagrantfileでVMを起動するとする。

 

手元に作る環境なので、productionとは異なりメモリサイズを小さくしておく、ということは十分に有り得る。
この時、vagrant upすると以下のようになりprovisioningに失敗する。

 

原因

このログからではよくわからないので、VMにログインして状況を確認する。

 

起動に失敗したkdump.serviceのstatusを確認すると、「No memory reserved for crash kernel」と表示されている。
これは、メモリをkdump用に割り当てたいが、VMのメモリサイズが不足していて割り当てられないというエラーのようである。

このページの手順2.1によると、割り当てるメモリの量は/etc/default/grubを見れば分かる。実際に見てみるとcrashkernel=autoとなっている。autoの場合は予約するメモリサイズが自動的に設定される。どういう値になるかはこのページに書かれており、また、自動設定に必要な最小メモリサイズの情報がこのページに書かれている。後者を見ると、x86_64の場合は2GB必要であるということが分かる。つまり、上記Vagrantfileでは1GBしかメモリを用意していなかったためkdump用にメモリを確保しておらず、kdumpの起動に失敗したのである。

解決方法

解決方法として、以下が挙げられる。

  1. VMのメモリサイズを2GB以上にする
  2. crashkernelの値を変更し、固定値にする

てっとり早いのはメモリサイズ変更だが、kdumpのためだけに2倍のメモリを使うというのはなんだかしゃくである。なので、crashkernelの値を変更して、固定値にする方法を採用する。

手動で変更する場合はここの手順通りに作業を進め、crashkernelの値を128Mにして再起動すればよい。しかし、Vagrantの場合再起動した後にkdumpを起動する必要があるため、ややこしい。

そこで、aidanns/vagrant-reloadを使う。これはprovisioningの途中でVMを再起動して、その後のprovisioningをやってくれるというvagrantのプラグイン。Vagrantfileを以下のように修正してやる。

 

vagrant upするとちゃんとVMが再起動し、sshで再度接続して次のprovisioningに進んでいることがわかる。

provisioningする度にVMを再起動するので時間が伸びるのがデメリット。