読者です 読者をやめる 読者になる 読者になる

ravelll の日記

よしなに

macOS Sierra の tmux + vim でコピーができなくなった

tech

OS を Sierra にアップグレードしたところ、tmux 上で起動した Vim だとヤンクしてもレジスタに何も登録されなくなってしまい、コピーもペーストもできなくなった。

あれこれやったところ解決できたんだけど、問題が明確にならないまま解決されたのでどれが効いたのかよく分からず。とりあえず動いたことは動いたので、メモ。

ちなみに Vimbrew install vim --with-lua --with-luajit --with-mzscheme --HEAD で入れていて、ターミナルは iTerm2 を使っている。

--

まず tmux と reattach-to-user-namespace を --HEAD オプション付きで install し直す。

$ brew uninstall --force tmux reattach-to-user-namespace
$ brew install tmux --HEAD
$ brew install reattach-to-user-namespace --HEAD

.tmux.conf に reattach-to-user-namespace の設定を追加。

set-option -g default-shell $SHELL
set-option -g default-command "reattach-to-user-namespace -l ${SHELL}"

設定後、OS を再起動。

--

これで直った。

各ソフトウェアのログを追ってすらいないので、症状が同じでも解決されない人もいそう。

鴨川ビール会議

RubyKaigi の翌日、川でビールを飲む体験をしてきた。

「東京の人はなんで川に入らないんですか」「渋谷って川ないんですか」「セルリアンとヒカリエとガーデンプレイスを繋ぐ川があると良さそう」などの発言がありました。

atnd.org

RubyKaigi 2016

event tech

f:id:ravelll:20160908150608j:plain

RubyKaigi 2016 に参加してきた。今年は開催地が京都だったので旅行を兼ねられて良かったし、会もとても楽しかった。

今回ペパボはお菓子スポンサーをしていて、自分はその設営を担当していた。設営後はだいたいトークを聞きに行っていたのでブースにはあまりいなかったんだけど、@hsbt さんや @udzura さんがいてくださってスーパー助かりました 🙇

聞いたトークは以下の通り。

  • 1日目
    • Ruby3 Typing (@yukihiro_matz)
    • dRuby in the last century (@m_seki)
    • Welcome to haconiwa - the (m)Ruby on Container (@udzura)
    • A proposal of new concurrency model for Ruby 3 (@ko1)
    • A Tale of Two String Representations (@nirvdrum)
    • Unifying Fixnum and Bignum into Integer (@tanaka_akr)
    • Scalable job queue system built with Docker (@k0kubun)
  • 2日目
    • How DSL works on Ruby (@hsbt)
    • Learn Programming Essence from Ruby patches (@takkanm)
    • Web Server Concurrency Architecture (@wyhaines)
    • Building maintainable command-line tools with mruby (@drbrain)
    • Modern Black Mages Fighting in the Real World (@tagomoris)
    • SciRuby Machine Learning Current Status and Future (@mrkn)
  • 3日目
    • Hijacking syscalls with (m)ruby (@franckverrot)
    • Dive into CRuby (@nalsh)

3日目ぜんぜん聞けてないのは2日目終了後 @hisaichi5518 と飲みに行くぞとなり途中どんどん Rubyist たちと合流してのみ続けた結果朝になり人間が終わったからです。聞きたかった話はいくつかあったけど、エンジニアの知り合いがガッと増えたのはトークを聞きそこねることをカバーするに余りある価値なので良かったと思う。

トークの内容はあとからスライドや動画を追えばいいけど、隣に座っていた外人と英語で話し込んで文化の違いと英語力の無さを味わったり、それまで知らなかった人と飲み会で仲良くなったり、目の前の膨大な人間たちが全員 Ruby 書いてるというコミュニティの大きさに圧倒されたりといったことは現場でしか味わえないし、それによってしか刺激されない気持ちもあると思う。なので少なくとも「自分には理解できないトークが多いし…」「後でスライドは見るし、別に行かなくていい」のようなトーク内容だけを理由に参加しないのはもったいないな〜という気持ち。行くと楽しいですよ。

社内 ISUCON に参加した

tech event

今週火曜に開催された社内向け ISUCON に参加してきた。これが、まあなんともなかなかに堪える体験だった。

〜開催日

個人では本家 ISUCON のまとめページにある解説や参加した方々のエントリを眺めて押さえるべきポイントを知ることから始めた。

チームメンバーでは1週間前くらいからちょいちょい集まって、誰がどこのレイヤを担当するか、RubyPHP のどっちの実装を使うか、ハマりそうなポイントはどこか、等々話したりした。

アプリケーションのレイヤを担当することになったのと、「実装は Ruby で」となったので、使われるであろう Unicorn の設定ファイルを準備したり、stackprof の使い方を見たり、よくあるアプリケーションの変更ポイント(セッション活用のパターンや N+1 問題が仕込まれるパターンなど)を抑えたりした。

「まあこれくらいやればそれなりには貢献できるだろ」とその時は思っていたけど、今にしてみれば何を根拠に、という気持ちだ。

当日

お昼ごろ、お題のアプリケーションやインスタンスが配布され、試合開始となった。アプリケーションは Slack を模した、10個くらいの action を持つチャットアプリだった。

それから5時間奮闘したのだけど、結果から言うと、全員チューニングがほとんどできないまま5時間が過ぎ、Fail した。

何が起きたかというと、開始してデプロイ環境を作り変更を加え始めたあたりで謎の 500 エラーが頻発するようになり、終ぞその原因を突き止められないまま終了時間になった、といった具合。

何が問題だったのか

利用するであろうツールの素振りをしていなかった・足りていなかったことも問題だったけど、それよりもチームとしての取り組み方に大きな問題があったように思う。そのことについて、以下にもう少し掘り下げて書こうと思う。念のため言うと書いたことは自分や取った行動の話で、メンバー全員が取っていたわけではありません。

・共有なしに変更を行った

変更者以外が変更を知らなかったために、それに起因する問題の原因特定が遅れたことが何度かあった。

どのレイヤの変更にしても、共有 -> 変更のフローを守っていれば、問題の原因の切り分けが格段に楽になっていたことと思う。

・変更の正しさよりもチームの快適さを優先した

メンバー間の空気が悪くなることを恐れて、チームとしてすべき意思決定を断念したタイミングがあった。これは特に良くなかったと思う。

実際の場面を挙げると、初期実装に使われていた puma はメンバー全員が不慣れであり、使用経験者が複数人いる Unicorn にすべき、という提案をしたが、他方の意見に納得することなしに puma 続投を決定してしまった。後日、500 エラーが出ていた原因の一旦は puma にあったことが明かされた。悩んだ岐路と最も困らされた原因のポイントが一致したことは偶然ではあったけど、慣れたツールを使うことで原因の特定がしやすくなったのではとは思う。

そもそもこのイベントに参加している以上、チームとして再優先すべきは最終スコアを伸ばすことであり、そのためには一時的な反感を買っても(当然言葉は吟味した上で)意思を伝え続けるべきだったと思う。

・変更の吟味をしなかった

改善のポイントは膨大にある一方で、それに使える時間は短い。その中で、効果の大小や最終的な状態を十分に考慮せずに変更を行ってしまった。

改善できそうなポイントを探し、期待できる効果の大きさや予想される所要時間からやれるものを割り振って進めるのが良かったのだと思う。

本家 ISUCON で上位になった方々の参加エントリを見ても、各自が手当たり次第改善しまくったのではなく、チームで選択した改善を丁寧に重ねていったチームが多いように見える。


といった初 ISUCON 記でした。精神的に大変負荷のかかったイベントでした...w 開催翌日までダウナー人間でしたが、今となってはとてもよい経験だったように感じます。

次回開催があったとき、もしくは本家 ISUCON に出場するときにはかなりのやっていきを見せつけられるよう、今からアレをコレしていこうと思います。

読書記録をつけ始めた

book

1日12ページの読書も1年続ければ4400ページ、4400ページは Linux プログラミングインタフェース2回読んでも足りないページ数、それはつまり知、糧、ということで日の平均読書量が12ページを超え続けるよう読書記録をつけ始めた。

記録方法はシンプルで、1日ごとに (1日の読了ページ数 - 12) を加算した値をツイートするというもの。最近よく忘れるので数日ごとになってる。

この記録方法にはいくつか問題があって、まず過去の記録が振り返りづらい。これはハッシュタグで改善できそうなので早速今日からやっていくことにする。

累積記録が分からないのも問題で、おかげでページ数が直接の目的になりづらくなっている感もあるけど、達成感がイマイチ。あれこれ並列に読まず1冊ずつ読了してブクログに読了記録から達成感を得ていくと良いのだろうか。でもオブジェクト指向入門800ページ以上あるし....

あと電子書籍だとページ数が分からないのも困る。最近技術書の半数は電子書籍で買ってるから結構な頻度で困る。現場を見てからソリューションを考えるべきだった。今は Amazon にあるページ数と Kindle の読了パーセンテージから適当につけてる。

ちなみに今はプログラマのための SQL 第4版を読んでる。今更ながら Web アプリケーションエンジニアとして SQL に疎いのは致命的な気がしてきたのでチェック付けつつじっくり進めてる。プログラミング Elixir も届いてるので早くそっちも読みたい。

プログラマのためのSQL 第4版

プログラマのためのSQL 第4版

プログラミングElixir

プログラミングElixir

今ある積読を片付けるだけでも4000ページ超えるし、ばんばん片付けてばんばん楽しいことをやっていきたい。あとここしばらく日記の締めを雑にしがちだと思う。

最近の IIDX

game

最近は週に1日くらいの頻度でやりに行ってる。今日は EXPERT の SECRET に追加された曲をあれこれ解禁した。これで今作のイベント曲は大方出たと思う。SHIKI さん xi さんなど、BMS 界隈で有名だった人たちがまた更に IIDX に進出していてびっくりした。

SP/DP 一通りやったけど激烈に難しい曲は特に無かった。ただ自身が衰えすぎていて Grand Chariot の DPA は AAA 出せず。このゲームは速くて多いとクる。

衰えの状態を少し具体化すると、縦方向も横方向も認識の精度が酷く落ち、手の感覚の解像度が著しく下がって常に少しかじかんでいるような状態になってしまった。思えばこの数ヶ月、IIDX だけでなくピアノも触れる頻度が激減していて、それはそうなるだろうという感じ。

IIDX も幾らか悲しいけどピアノが弾けない悲しさは中々なので、早速今日から感覚を戻すべくやっていく次第。

新卒エンジニアたちに計算量の話をした

tech

今年も弊社は新卒エンジニア向けに座学をする季節になりました。

自分は毎回興味はあるけど知識がない分野を教えることにして無理やり学習機会を作るスタイルでやっていて、今回は計算理論について教えることにした。

speakerdeck.com

1時間で教えるには無理のある分野だったので興味を持ってもらうことをゴールとし、実習なしでもそれなりに理解できてキャッチーな話題を集めた。

学習意欲の強い新卒氏たちのことなので興味さえ湧けば各々やってくれると思っての構成だったけど、それなりに興味を持って聞いてくれたようだったし、得たものもあったようで良かった。

自分自身さわりの部分しか学んでないし熱も出ているところなので、もう少し学習を続けようと思う。