DevLOVE関西行ってきた。

具体的にはこれ。

https://devlove-kansai.doorkeeper.jp/events/36446

以下、自分の勝手な解釈が多々含まれるけど感じたこと、きいたことをまとめる。

 

「エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方」
というエモーショナルなタイトルで、現場よりの話。

仕事のできないメンバーをできるように変えていくにはという話。

仕事ができるとは何か。できないとは何か。
まずそこからして人によって受け止めかたは様々だろうけどまぁそれはそれ。

とにかく人から期待した結果を引き出すためその人に変わってもらおうとするとき、どう変えたらいいのか、本当に変えていいのかという不安が出てきがちである。

そして人によってはそれは簡単なことだと感じられ、人によっては困難な道のりに感じられる。
その差は人によってそれぞれ抱えるメンタルやとるべき責任、思い込みなどの背景が違うからだという話。

んで、それじゃぁ行動を変えるには、習慣化するにはどうすればいいだろう。
こういうとき、たいてい気合いとか気の持ちようだとかの解決策が提示されがちだが、そういう解決策は実行・継続不可能なことが多い。

よって、小さく行動を変えさせ、分かりやすいフィードバックを与えてやり、その射幸性によって習慣付けさせ、その人を期待通りの行動を取ってくれるように計らうのが行動学的に理にかなっているという話。

そしてフィードバックは早ければ早い方がよい。動物的なレベルでいうと60秒以内が望ましい。理性的な大人は2週間ぐらいはギリ待てる。

ちょっと雑だし、ソシャゲーみたいな表現になったけど、根本はそんな感じかなと思った。

もしかしたら「小さく行動を変えさせ」のところは行動を変えさせる必要もなくて、好ましい指標を外部から計測し、公表してあげるだけでもよいかもしれない。

こういうのは行動科学マネジメントというジャンルらしい。

そのまま他人に適用するよりも、まずは自分に適用してみるのがよさそうだと感じた。
「人はこういう風に振る舞うんだよ」と、生半可な知識で知った風なことを言って逆鱗に触れてはいけない。

「こういう心理作用かあるとのことなので、最近心がけています」みたいな所から始めて効果を確かめつついい感触であれば周囲にも広めていくぐらいが今の自分にはよさそう。

 

こうして、勉強会のフィードバックを早めに出すことも、今回の勉強会で学んだことだ。

と、いいオチがついたのでそれではまた。

fitdesk使用感日記

fitdeskを買ってからというもの、PCに向かうとき=fitdeskぐらいの勢いで乗っている。PCがfitdeskの上においてあるのだから当たり前なんだけど。

実際にfitdeskを買うまでは「これはとてもいいものだからオフィスへの導入を考えてもいいものなのでは」ぐらいに思っていたのだが、実際に乗っていると思った以上に汗をかいてしまうので、だいたいパンツ一丁の状態で乗っていることが多い。職場でパンツ一丁で働いているメンバーが居ると辛いものがあるだろうから導入は厳しそうだ。

まぁ、職場への導入は別に真面目に考えてるわけでもないのでそれはそれとして。

よくあるサイクルマシンのように絶対にダイエットするんだ!みたいに強い意志でガツガツ乗る必要がないので気に入っている。PCで作業したければサイクルマシンに乗る事になるので、自然と運動するようになる。とはいえずっと乗っているとさすがに疲れるのでちょっと疲れた時は普通の机で仕事をする。みたいに使っている。

体重は81kg周辺をさまよっているが、2kgぐらいは普段から増減あるので特に効果は出ていないと言える。

78kgぐらいがコンスタントに出るようになってきたら効果が出てきたと言えるんじゃないかなぁと淡い期待を抱いている。

プログラマー vs 運動不足

きっかけ

プログラマーは、だいたい運動不足になりやすい仕事だ。

PCに向かって色々調べ物している時やプログラミングしている時が一番楽しい時なので、動かなければいけないという差し迫った状況にないと際限なくPCの前で座っている人も少なくない。

オフィスで仕事をしているプログラマーであれば出社が必須なので少なくとも通勤という名の運動ができるが、今風に在宅勤務するようなプログラマーというのは本当に運動をする機会がない。

私自身、この春から週に一度ずつ在宅勤務をしていたのだが最初の数回は朝時間になったらPCの前に座り、昼休憩以外はずっとPCの前から全く動かないという不健康極まりないありさまだったのだ。

しかし、いろいろな状況が重なって私は2015年9月から週に3回程度の在宅勤務になる予定だ。こうなると運動不足が今以上に深刻な問題になってくると思っている。

そして私は現在35歳。大学入学時に178センチ65キロ程度だったのが、大学卒業時には70キロを超え、中年になった今や83キロもあるのである。18キロ程度、生命活動に不要なことが明らかな肉があるということだ。会社の同僚にも「体脂肪率30%!体の30%が油!」と言われてしまうのだ。

これ以上、運動不足な人生を送って贅肉を増やしていくのはリスクしかない。在宅勤務が増えて加速度的に体重を増やしてしまうと、生産性は脂肪による死亡で0になる。つまり人生を変える時が来たのだ。

冴えた解決策

だいたいにおいて、一人の人間が合理性を追求して出した結論というのは異様に見えることがある。

fitdeskという商品はまさにそれであろう。

FitDesk X-2.0 ジャパンモデル(フィットデスクX-2.0 ジャパンモデル )エアロバイク、パソコン

私にとっては合理性の限りを追求するとこの製品のような結論に達するのはごく自然であることに感じられるのだが、世間様の評判を調べると「何たるネタ商品!」みたいな感じの扱いをされてしまっている。

と言うわけで、我が家にはfitdeskがある。これから、fitdeskに乗りながら本blogを書いていくという算段なのだ。実は昨日書いた記事もこれに乗って書かれている。 mitomasan.hatenablog.com

食事制限をするつもりはあまりないので、業務中にこの机にまたがっているだけでどれだけの効果があるか、気になるところである。

cronのクラスタリングサポート(CentOS7)

ある日、突如 cron に疑問を感じ man cron を実行してみた。 たまたま CentOS7 だったのだが、「CLUSTERING SUPPORT」なるセクションがありびっくりした。 cronでクラスタリングとな!

びっくりしたのはいいが、実際に何をやってくれるのかはさっぱりわからなかったので和訳してみることにした。

以下、和訳。間違いがあればすいません。

*1

クラスタリングサポート

In this version of Cron it is possible to use a network-mounted shared /var/spool/cron across a cluster of hosts and specify that only one of the hosts should run the crontab jobs in this directory at any one time. This is done by starting Cron with the -c option, and have the /var/spool/cron/.cron.hostname file contain just one line, which repre- sents the hostname of whichever host in the cluster should run the jobs. If this file does not exist, or the hostname in it does not match that returned by gethostname(2), then all crontab files in this directory are ignored. This has no effect on cron jobs specified in the /etc/crontab file or on files in the /etc/cron.d directory. These files are always run and considered host-specific.

本バージョンの cron はネットワークマウントされた共有の /var/spool/cron を クラスタのホストをまたがって、どの時点においても一つだけのホストが実行すべき ジョブを実行することができる。これは -c オプションを与えて cron を起動すれば 実現できる。そして、/var/spool/cron/.cron.hostname に一行だけあれば そこに属するクラスタのいずれかのホストがジョブを実行すべきジョブを実行する。 もし、このファイルがないか hostname が gethostname(2) にマッチしない場合、 このディレクトリにあるすべての crontab ファイルが無視される。これは、/etc/crontab や /etc/cron.d 以下を対象とした cron の動作に影響を与えない。それらのファイルは 常に特定のホスト上で実行される。

Rather than editing /var/spool/cron/.cron.hostname directly, use the -n option of crontab(1) to specify the host.

/var/spool/cron/.cron.hostname を直接編集するよりは、crontab(1) の -n オプションを用いてホストに特化した設定を編集するほうがよい。

You should ensure that all hosts in a cluster, and the file server from which they mount the shared crontab directory, have closely synchro- nised clocks, e.g., using ntpd(8), otherwise the results will be very unpredictable.

あなたはクラスタのすべてのホストに対して以下のことを保証すべきである - crontab directory がファイルサーバーをマウントしていること - しっかりと時刻が同期されていること そうでなければ、結果がどうなるかは予測不能である。

Using cluster sharing automatically disables inotify support, because inotify cannot be relied on with network-mounted shared file systems.

クラスタシェアリングは自動で inotify(7) サポートを無効化する。 なぜならば inotify(7) はネットワーク共有されたファイルシステムを中継しないからである。

CAVEATS

All crontab files have to be regular files or symlinks to regular files, they must not be executable or writable for anyone else but the owner. This requirement can be overridden by using the -p option on the crond command line. If inotify support is in use, changes in the symlinked crontabs are not automatically noticed by the cron daemon. The cron daemon must receive a SIGHUP signal to reload the crontabs. This is a limitation of the inotify API.

全ての crontab ファイルは普通のファイルか、そのシンボリックリンクである。 それらは実行可能であったりオーナー以外の誰にでも編集可能であってはいけない。 この要求は crond のコマンドラインを -p オプションで上書きすることができる。 もし inotify サポートを使っている場合、シンボリックリンクされた crontab はデーモンにその変更を自動で通知しない。 これは ionotify API の制限である。

The syslog output will be used instead of mail, when sendmail is not installed.

sendmail が install されていない場合、syslogの出力は代わりに mail コマンドが利用される。

和訳してみてわかったこと

どうやら、/var/spool/cron を複数台にネットワークマウントすることにより、マウントされたサーバーをクラスタとみなしてその中の一台だけがジョブを実行するということができるようだ。

ただし、注釈にあるようにしっかりと時刻が同期されていなければ何が起きるかわからないという大変怖い事が書いてある。 ソースを読み込んで起きうる現象を把握しておかなければ到底プロダクションに投入できるものではない気がする。

私は最近 cron について非常に不安を感じているので、cron の動作をきちんと確認したいと思っている。この記事はその前フリでもある。

*1:@kitora_naoki に和訳の変なところの指摘をもらって修正しました!