自分は Tasty という BuzzFeed のレシピ動画を参考にするようにしている。自分も前はクックパッドを見ていたが、クックパッドにお金を払っていないため人気順でレシピをソートすることができず、検索してヒットする複数のレシピを見て比較したりするのに疲れてしまった。
Tasty は動画で料理が作られていく課程を見ながら料理をできるので楽しいし失敗しにくいと思う。映像や音楽もプロが作っているだけあって娯楽性が高い。 Tasty の問題点はレパートリーが洋食に偏ること。オリーブオイルどばどばで MOCO'Sキッチン のような感じになってしまいがち。あと簡単には手に入らない調味料を使っていることが多いので、カルディコーヒーなどの輸入食材店に足繁く通うことになってしまう。
手早く簡単に、家にあるもので何かを作りたい、という要求は満たせないかもしれないけど（クックパッドは冷蔵庫にある材料でレシピを検索したりできるのが便利）、料理を作ること自体が娯楽である人には Tasty はとても参考になると思う。
Lifehack (笑) 臭がしてこれまでキー入力拡張みたいなアプリケーションを使うのは敬遠してたんだけど（そもそもああいうのは IME がないアスキー文化圏の人向けだと思ってた）、 Pull Request 出すときのテンプレートとかを一発で出せたら便利だなと思ってその手のやつを使うことにしてみた。
有名どころだと TextExpander がある。試してみようとしたら何と月額課金に移行してて買い切りではなくなっていた。しかも結構高い（年額 $40）。いろいろ物色してたら昔何かの bundle で購入していた Typinator というやつがあって、こいつならアップグレード料金で使えるし買い切り型だったので使ってみることにした。新規で買っても EUR 24.99 で TextExpander の年間使用料より 1000 円くらい安い（24.99 EUR = 3061.5624 JPY）。
仕事で Zoom というビデオ会話ツールをよく使う。 Zoom には電話番号みたいに個人に紐付く固定の URL が存在してて、誰かと話したいときにそれを Slack 上に貼りつけて会話を始めたりする。この URL をいちいち Zoom を開いてコピペするのめんどいので ,zoom と打つと出せるようにしている。一瞬で MTG 始められて便利。
,dt と打って2017-03-11 のように今日の日付を表示させることも可能（入力キーや日付・時刻のフォーマットはカスタマイズできる）。こういう機能は ATOK にも付いているけどスペースキーを押したりリターンキーを押して確定したりしなくてよいのが快適。 ふむふむ～、ナルホディウスですぞ のような変換に何度も文節を調節したりしないといけないやつも ,naruho と打てば出せるようになってチャットが円滑に行えるようになった。
冒頭に書いたように、 Pull Request 出すときに使ってる定型文みたいのがあって、過去の Pull Request からコピーしてきたりしていたのが一発で入力できるようになって異常に便利。 pullreq と入力するとシュバッと展開されるようにしている。こんな感じ。
ATOK に辞書登録するのとは違って改行を含んでいてもいいし、日本語入力モードに切り替えなくても良いのが便利。
Typinator には GItHub みたいになってしまうのを抑制する機能がついてて、大文字が二文字連続したあとに小文字が入力されると自動的に二文字目を小文字に変換するという機能（ GItHub を GitHub に直してくれる）がついている。 Typinator は vi mode でシェルを操作しているとかは判別できないので勝手に補正してくれて上記のようなキーストロークが bbi と修正されてしまう。
Vimmer なのでシェルの操作モードを vi mode にしているのですけど、単語移動するときについつい
Shift + b Shift + b i
とか入力してしまうと Typinator が反応して bbi に補正されてしまってうざい。
設定に DOuble CAps Exception というのがあって例外設定できるみたいだったので BBi を追加してみたけどどうもうまく効いてないみたい…（ bbi に補正されてしまう）
さらに詳しく設定を調べてみると、アプリケーションごとにルールの有効・無効を切り替えられるっぽいので、 iTerm を使っているときは連続する大文字の小文字補正を行わないことにしてみた。これで様子を見てみよう。
合同勉強会 in 福岡という勉強会があって、 Nulab の人やクラスメソッドの人たちが福岡に来て発表するということだったので行ってみたいと思ったけど参加者枠が埋まってたので LT 枠で申し込んで行ってみた。まえブログに書いた BitBar の話をした。
以前一緒に仕事していた Rudolph Miller 先輩がインタビューで「勉強会は勉強しに行くところじゃなくて自分が普段勉強してることが合ってるか確認しに行くところ」みたいなことを言ってたけど、今回は普段勉強してないことがありありとなった感じでやばいなと思った。皆さん AWS とか Azure とか Terraform とかに詳しすぎる。きしだなおきさんの機械学習についての発表とかさっぱりわからなかった。平川 剛一さんの Server-side Swift の話は面白かった。 Server-side Swift の開発、 Apple じゃなくて IBM が主導しているそう。ぼちぼち Web フレームワークなんかもできてきてるみたい。
LT は皆さんレベルが高く、ネタに走りつつも技術的に高度な内容で自分の LT が一番しょぼかった。発表もうちょいうまくなりたい。
Vim で Markdown を編集するとき、 vim-quickrun を使って Marked でプレビューするようにしてる。これが便利で体に染みついてるので、 Deckset で表示する用の Markdown スライドを Vim で編集しているときに一発で Deckset を開いてプレビューできたら便利だなと思ったので以下のようにしてみた。
slides が含まれていたら filetype を markdown.slide にするft=markdown.slide のときは vim-quickrun で Deckset にファイルをプレビューできるようにするこんな感じ。
au Bufread,BufNewFile /*/slides/*.markdown set filetype=markdown.slide
let g:quickrun_config['markdown.slide'] = {
\ 'outputter' : 'null',
\ 'command' : 'open',
\ 'cmdopt' : '-a',
\ 'args' : 'Deckset',
\ 'exec' : '%c %o %a %s',
\ }便利。
酒は健康上の問題より、タイムマネジメント上の問題を考えるべきだと思うようになった。というのも酒を飲むと何もできなくなってしまうからだ。
酒を飲むことの問題点、酔って暴れたりとか健康を害したりとかお金がなくなったりとかいろいろあると思う。自分は幸いにして飲めば必ず暴れる（たまに暴れる）とか酒で肝臓を悪くするというような状況ではない。しかし酒を飲むことでその日が終わってしまい、やるべきこと、やった方がいいことができなくなってしまう。たとえば夜 7 時に飲めば 7 時にその日が終わってしまう。寝るまでに 5 時間あったとしても、その 5 時間に勉強したり本を読んだり仕事したりすることはできない。なぜなら酔っ払ってしまっているから。
酒、健康や経済や家庭を滅ぼすほどに飲まなくても、たとえば厚労省が示している適量と言われる量しか飲まなくても、酒を飲みつづけることで自己研鑽や自己投資に時間を使うことができず自分の労働者としての価値を高められず低賃金にあえぎ続けることになる。
iPhone 7 にしたら結構カメラの画質良くなって割と満足してる。フィルターかけることの喜び知ってしまって VSCO で遊んでる。フィルターかけるとオリジナルとフィルター済みの2パターンの画像ファイルできてしまう。 SNS にアップロードするときはフィルターかけたやつを上げたいけど記録用に自分のフォトライブラリに残すやつはフィルターかかってないやつがよい。そういう運用してるとフィルターかかってるやつとかかってないやつの両方がごちゃごちゃにフォトライブラリに残ったりして管理をどうするかで悩んでる。
一眼レフは相変わらず D90 使ってる。結構ボロボロになってきてて買い換えたいのだけど先立つものがなく買い換えられていない。グリップのラバーゴムを交換したり、キットレンズの VR 18-200 の修理をしたりしながら何とか使ってる。やっぱり iPhone のカメラとは別格の写真が撮れる。特に Nikon 純正の単焦点を付けて撮ったときは良いのが撮れる。フルサイズ機への買い換えを考えたこともあるけど、最近はぶっ壊れるまでとことん D90 を使おうかなと思ってる。ただ D90 は動画がよくない。音声はモノラルで解像度低いしフレームレートも低くオートフォーカスもなし。動画の画質は iPhone 5 くらいの頃から iPhone に負けている。 Apple TV でテレビに映して再生すると一昔前の YouTube みたいな画質になる。
一眼レフには Mac 側のストレージを圧迫するという問題点がある。いま使ってる MacBook Pro は 2009 年モデルでかなり古い。初期搭載の HDD から 512GB の SSD に変えているけど RAW がストレージを使いまくってて残り 20 GB 程度しか空きがなく Xcode のアップデートも行えないような状態。そもそも RAW 撮りやめてしまっても良いのではと思い始めた。 RAW 現像する暇ないし Aperture の開発は停止されて RAW 現像できるソフトがそもそも手元にない。実はカメラの撮って出し JPEG でも十分満足できている。結構良い画質で撮れてそれを Keenai （旧 Eye-Fi ）でさっとスマートフォンに取り込んで SNS に上げたり iCloud 共有したりすることの方が自分のカメラの使い方としてプライオリティ高い。
プロでもハイアマチュアでもない普通の個人はどういうフォーマットで写真を撮って保存するのがベストなのだろうか。 RAW で撮っとけば後々後悔することはあるまいと思っていたけど、ストレージの値段が劇的に安くなってきてるわけでもない（ローカルストレージは安くなったが、クラウドストレージに同期しながら使おうとすると結局コスト高い）し、デバイス間の転送速度の問題もある。 2017 年のベストな写真管理方法知りたい。
puma にして喜んでたけど二時間後くらいに NewRelic で様子を見てみたらメモリ 90% 以上消費してて swap ファイルもめっちゃでかいのができてて暴発一歩手前になってた。
一旦 puma をシングルモードからクラスターモードに変えて puma_worker_killer を導入し、 worker を定期的に再起動するようにした。ただ restart 後のメモリ増加傾向は変わらない。
引き続き NewRelic で様子を見ていると Python2 が一番メモリを食っている。このブログは Syntax Highlighting に Python の Pygments を pygments.rb 越しに使っている。これまで unicorn の worker プロセス 2 個で動かしていたときには最大でも Python のプロセスは 2 個で事足りてたけど、 puma にして 16 スレッド（ puma のデフォルト）が起ち上がるので、 16 個の Python プロセスが起動していたっぽい。
これは意味ないなということで以前利用したことがあった Pygments の Ruby 移植版である rouge に変えてみることにした。こちらは Ruby なのでスレッドが別プロセスを起動してメモリ爆発ということにはならないと思われる。
puma_worker_killer と Pygments 置き換え後半日様子を見たが、これでメモリ消費量爆発ということはなくなった。
sidekiq でスレッドを増やしたときにも似たようなことを経験したけど、 Ruby から外部のプロセスを起動するようなプログラムを書いているときにマルチスレッドで処理をさせると、 Ruby のプロセスは増えなくても外部のプロセスがめっちゃ増えてそのせいでメモリあっぷあっぷになったり CPU の使用率が高まったりする。マルチスレッドプログラミングのご利用は計画的に。
puma をクラスターモードにしたことで別の問題も発生した。なんとセッション情報が異なるプロセス間で共有されていないっぽい。なのでログインしてすぐに再ログインを求められるようになった。これは不便。原因を調査するには時間がかかりそうだったのでシングルモードに戻してみることにする。
セッション情報が異なるプロセス間で共有されていない
これはちゃんと設定があって、 puma.rb に preload_app! を記述すればよかった。
If you're running in Clustered Mode you can optionally choose to preload your application before starting up the workers. This is necessary in order to take advantage of the Copy on Write feature introduced in MRI Ruby 2.0. To do this simply specify the --preload flag in invocation:
# CLI invocation $ puma -t 8:32 -w 3 --preloadIf you're using a configuration file, use the preload_app! method, and be sure to specify your config file's location with the -C flag:
$ puma -C config/puma.rb # config/puma.rb threads 8,32 workers 3 preload_app!
これでプロセス間でセッション情報が共有されるようになった。
