RubyKaigi 2017の記録

先日、広島で開催されたRubyKaigi 2017に行ってきました。

相変わらず各トークのテクニカル度合いが異常にハイレベルで刺激的なカンファレンスでした。

最近、静的解析やRubyと型の関係がホットトピックであることもあり、ripperやparser gem等のRubyパーサやRubyVM::Iseq周りを触っているスピーカーが多く、コアに突っ込んでいく人のアクティビティにはとても刺激を受けました。 個人的にはIseqのバイナリ表現とソースコードの変換を活用してマクロの様なことを実現していたCompiling Rubyという発表が印象的でした。 後、毎年ラストのキーノートはやってることが凄過ぎて、圧倒されるばかりですね。

私自身は、メインのスピーカーとして登壇することはできませんでしたが、LTスピーカーとして話をする機会がもらえたので、そこで登壇してきました。

f:id:joker1007:20170927024108j:plain From RubyKaigi 2017 | Flickr

壇上から写真が撮れるのは嬉しい。 f:id:joker1007:20170919174020j:plain

内容は、Refinementsの貴重なユースケースと、Refinementsにbinding_ninjaという拙作のgemを組み合わせた黒魔術の例を示す、という話でした。

binding_ninjaは、C Extensionとして実装することで、メソッドの呼び出し元のコンテキストのbindingを暗黙的に引数に組み込んで渡す、というgemです。 何のことやら良く分からんと思うので、リンク先のREADMEを読むとどういうものか伝わるかと思います。 binding_of_callerという有名なgemがあるのですが、それの機能限定、高速化版みたいなものです。

後から聞いた感じだと、喋りの勢いと技術的なマニアックさが良い按配だったらしく、割と好評だったみたいです。いやー、ウケて良かったー……。

また、2日目の夜は多くのDrink upが開催されてましたが、私は永和システムマネジメント様がスポンサードしていたDrink upでスタッフとして日本酒の選定をさせてもらいました。

日本酒を大量に準備してのDrink upは二度目で、前回もとても好評だったことや、永和というネーミングバリューもあり、一般参加者の募集は即日完売だったらしく、いやースタッフで良かったーと思いましたね。

RubyKaigi 2日目で「Food, Wine and Machine Learning: Teaching a Bot to Taste」というタイトルで登壇していたMai Nguyenさんが参加してくれて、ワインを愛する彼女に日本酒を振る舞うことができたことを嬉しく思っています。

Drink upも好評に終わって最高の夜でした。

f:id:joker1007:20170919185609j:plain f:id:joker1007:20170919185615j:plain

今回、お店側のスタッフの人がかなりサポートしてくれて、同じグループの日本酒バルのお店からメンバーを派遣してくれた様で、お酒を振る舞う上でめちゃくちゃ助かりました。ちゃんと味を見た上で分かり易くグルーピングして並べてくれたし、好みの味に対するお酒のリコメンドもしっかり応えてくれました。

名刺を貰ったので、もしまた広島に行く機会があれば、是非足を運びたいお店ですね。

f:id:joker1007:20170927180620j:plain

その後、Ruby Karaokeまで参加し、大体最後まで居たんですが、ここでめちゃくちゃ消耗して3日目のセッションの半分以上を聞きそびれるという失態を犯すことに……。 まあその後、海外から来てRuby Karaokeに参加してくれた人に軽くお礼の言葉を貰ったんで、まあいいかーという気になりました。救われた感じw

結局、3日目の夜も大体朝方までデカ外人(@dekagaijin)パークで飲んでいて、ヘロヘロのまま宿に戻ったら、チェックアウトが10時だったので9時ぐらいに起きる羽目になり、ロクに広島観光をする余力もなく、お好み焼きだけ食べて東京に戻る、という感じでした。 本当は、もうちょっと宮島ぐらいまで行ったりしたかったんですが、家まで帰り着いた時の自分のコンディションを考えると、帰って正解だったな、と思う。

来年は仙台ということで、東京からだと広島より行き易いし、ジョジョの聖地である杜王町についにRubyKaigiが!って感じなので、何とかCFPに応募できるぐらいは頑張りたいと思います。

穴子飯美味かった。 f:id:joker1007:20170918213147j:plain

穴子刺とハモとメゴチ。ハモは西日本に限る。 f:id:joker1007:20170918202018j:plain

辛いのはそんなに得意ではないが山椒は好きなので、広島の汁なし担々麺は良かった。 f:id:joker1007:20170918120329j:plain

私的リモートワークの良い点、悪い点

Twitterでちらっと見かけたので、自分も良い点と悪い点をまとめてみようと思う。

良い点

  • 電車に乗らなくて良い
  • ミーティング開始の5分前まで寝てられる
  • 人の話し声がしない
  • 話しかけられずに済む
  • 疲れたらいつでもベッドにダイブできる
  • ちゃんとアウトプットしてれば、仕事している様に見せなくてもいい
  • 寝間着で仕事ができる
  • ハイスペックなPCが使える
  • WiFiが不安定みたいなトラブルが少ない
  • 良い椅子が使える
  • ヘッドホン無しで音楽が聞ける
  • いきなり歌い出しても、誰も変な目で見ないし、迷惑がかからない

基本的に引き篭りなので、自宅の環境が快適になる様に腐心した結果、大抵のオフィスより自宅の方が執務環境として優秀であり、自宅より仕事に関する物の水準が高い会社というのをほぼ見たことがない。

そして、日常生活において、歌うというのが精神の健康上とても大事なので、音楽を聞きながら突然歌い出したりしたいのだが、出社してそれをやると頭が致命的な人に思われてしまうし人に迷惑がかかるので、これが最も重要と言えるかもしれない。 カーレンジャーのOPとか聞いてたら「レッツゴー!」とか言いたいし、キングゲイナーのOP聞きながら「キング、キング、キングゲイナー」って歌わずに済ます方が難しい。(そんな曲を仕事中に聞くな、という話であるが……) 実際、すげー辛いテストコードの修正作業とか無意識で歌えるテンション高めの曲とか歌いながら無理やりドライブすると、結構進捗するので勢いってのは大事だと思う。

悪い点

  • チームメンバーとのコミュニケーション量は減る
  • たまに飲みにいく話になった時に、場所が渋谷とか新宿だと行くのが面倒くさい
  • ギリギリまで寝てようと調整し過ぎて寝坊する、疲れたので仮眠を取ろうとして寝過ぎる
  • 生活リズムが無限にズレていく
  • 仕事を止めるタイミングが無いので無限に仕事をしてしまう
  • 飯を食わなくなり、アルフォートで生活する様になる
  • 運動不足が加速する
  • 職場までの距離に対する我慢が足りなくなってくる
  • 歌いながら仕事をすることに慣れてしまい、たまに外に出た時に突然歌い出す危険が増す

一番問題なのは仕事し過ぎではないかと思う。中断するタイミングも特に無いので飯を食うのが面倒臭くなり、冷蔵庫にストックしてあるアルフォートに頼ることになる。幸いにして家の近くにタリーズがあるので、考えごとやら軽く本読む時にタリーズまで行ってついでにサンドイッチ食ったりする様にしている。

生活リズムのズレを是正する仕組みも無いので、自分の睡眠傾向だと生活リズムがえらいことになる。最近は朝の7時から8時に寝て12時から14時に起きることが多い。半年前ぐらいまでは5時には寝れてたんだが……。そして、ミーティングに合わせて無理やり起きたりするので、かなり辛いことになる。

総じて肉体にじわじわダメージが蓄積されていく。自分がどうしても不健康な生活に向かっていくからなのだが、意思の力とかではどうしようもない感じ。

しかし、基本的に肉体にダメージが溜まるのは根本的に自分の体質やら生活スタイルの問題であり、大なり小なり出社してても同じことなので、仕事をするという点においては、やはり自宅が快適なのであまり自宅から離れたくはない。

Ryzenで久々にPCを1台組んだ

Thinkpadが唐突にぶっ壊れたため、自宅のPC環境を早急に何とかしないと色々不便でしかたなくなってしまった。 最近、Ryzenが盛り上がってるし、ここ5年ぐらいデスクトップPCを新調していなかったので、もうこのタイミングで1台作ってしまうことにした。

ちなみに、予算に限界があったため、タイミング的にThreadripperで組むことも可能だったがそれは諦めた。

構成

パーツ 名称
CPU Ryzen 1800X
マザー MSI X370 GAMING PRO CARBON
メモリ Crucial Ballistix 16GB x2
NVMe CFD CSSD-M2O512PG1VN 512GB
VGA GIGABYTE GeForce® GTX 1070 G1 Gaming 8G
電源 Seasonic X Series 860W SS-860XP2S
クーラー Corsair H110i (簡易水冷)
ケース Thermaltake Core v4l

f:id:joker1007:20170822041403j:plain

所感

ツクモで安売りしてた電源とマザーとRyzenのセットを買って、後は適当に集めた。 大体、これで25万ぐらいか。 再利用できるものが何も無かったんで、全部買い集めたら結構かかってしまった。 割とかかってしまったので、GPUは日和ってGTX 1070にした。まあどうせそんなに激しく使わないだろうし。 ケースを持ち帰る時に、あんまりでか過ぎると重くて辛いので、程々のサイズのミドルタワーにしたら(それでも持ち帰るのは辛かった)、ビデオカードが3.5インチベイに干渉する問題があった。幸い取り外しが効くもので、3.5インチベイにそんなHDDを突っ込む予定も無かったので、ベイを取り外して事なきを得たが、ちゃんと長さを測っとくべきだった。最近のビデオカードがあんなでかいとは……。

OSはもちろんGentooを入れた。

ちなみに、Gentooなので日々バリバリコンパイルしているが、噂のSEGVは起きてない。やっぱあれ初期ロットの問題かBIOSがこなれてなかっただけなんじゃないだろうか。 AGESA 1.0.0.6 ファームウェアならメモリコントローラーがかなり安定する、という話があったのでちゃんとBIOSを上げておけば大丈夫な気がする。

ただ、問題が無かった訳ではなくて、唐突にPCがフリーズする問題に数日悩まされた。 ログにも何も出てなかったのだが、ある日syslogにrcu_schedでCPUがstallしているというログが出てたことと、フリーズする状況が長時間のアイドル後に操作しようとした時に頻発してたことから、色々ググってみるとC6-Stateを切ると安定したという報告が見つかった。 いわゆる、CPUのアイドル時の省電力機能だ。 状況やエラーログから、これはC6-Stateからの復帰に失敗している可能性がかなり高いとみて、BIOSで無効にしてみたところ、めちゃめちゃ安定した。 その後は一度も固まってないし落ちてない。超快適。 ハードウェアの初期不良とかでなくて良かった。CPUが悪い可能性はあるが、別にC6-State切った所で困ることはないし。

久しぶりにデスクトップPCを新しくしたら、今までのノートPC生活から劇的に性能が向上して超快適である。 やはりデスクトップPCぐらいの処理能力は欲しい。 特にカーネルやブラウザのコンパイルがこんなに早く終わるとは、Gentoo使いにとってはとても嬉しい。SEGVさえ起きなければ。(自分の環境では起きてないから今のところ問題ない)

というわけで、快適なPCが手に入ったが、今までずっとノートPCだったのでWebcamとかスピーカーも無い(イヤホンはある)ことに気付いて、色々と買い足している。 思ってたよりかなりお金がかかってしまったが、動作感やスペック的にはかなり満足のいく感じになったので、とりあえず良かった。

パーフェクトRuby第二版 こぼれ話

書籍紹介は既にいくつか書かれているんで、私は自分の担当した箇所の話を書こうかと思います。

本日(5/17)改訂2版 パーフェクトRubyが発売されます - すがブロ
改訂2版 パーフェクトRubyが出版されました - esm アジャイル事業部 開発者ブログ
改訂2版 パーフェクトRuby:書籍案内|技術評論社


私は、どっちかというと大きく書き直す所をメインで担当していました。主にテストコードの章です。後Refinementsについても少し書いてます。
テストコードの章では、書籍紹介にある様にtest-unitを採用しています。
fluentdプラグイン関連のテストコードはtest-unitで書かれていることが多いのですが、最近その辺りを結構触っているので、私が書きますよと手を挙げさせていただきました。
Refinementsについては、恐らく数少ないproduction環境でもRefinementsを活用しているものとして、貴重なユースケースを提供しておこうという意図があったので書かせてもらいましたw
私はRefinementsとても好きなんですが、実装側の苦労とか機能の限定が厳しいので、あんまり良い評判を聞かないですね……。
もちろん、そんな上手いこと使えるケースはそう多くないので、無理して使うのは止めようね、とは書いてありますw

test-unitを採用した理由ですが、この本はRubyという言語自体をテーマにした本なので、バンドルされているテスティングフレームワークを採用して書くのが入門者にとっても分かり易いだろうと思ったからです。
また、通常のRubyコードにかなり近く、特化したDSLについての事前知識を説明しなくてよかったので、内容をコンパクトに収めることができました。
ちなみに、私個人としてはRSpecは結構好きなのですが、RSpec3系になって嫌う人の気持ちも分かりますw
Power Assertも好き嫌いあると思いますが、これも言語自体にバンドルされていて、自分も関連gemを作ったりpull reqを出したりしたこともあって、ちゃんと触れています。


実際、一番しんどかったのはテストコードを書くためのサンプル実装を用意することと、モックを使ったテストを行う理屈をサンプル実装の中に用意することでした。
シンプルで読むのに苦労は無い、がテストを書くことが役に立ちそうで、リファクタリングの余地がありそうな程度に冗長なコードで、モックやスタブを紹介するためにそういうテストを書く理由が存在するコードを用意しなければならないわけです。
色々頭を捻った結果がこの本に書かれているわけですが、上手くいってるかどうかは読んでくれた人がどう受け取るか次第って所でしょうか……。
突っ込みを入れたい人は、是非、書店やgihyoさんの電子書籍サイト等でお求めください!

開発環境がLinuxに戻ってそれなりにこなれてきたので現在の環境について書く

Macを捨ててThinkpadGentooを入れて開発環境としてから2ヶ月が過ぎた。
世の中にはMacから離れようとしてThinkpadを買ったら、矢印キーボード押しにくいとかタッチパッドがクソなので、Macに戻っていった人も居るみたいですが、私としては至極快適に過ごしております。
そもそもThinkpadタッチパッドは基本無効化するものなのでどうでもいい。まあそのスペース邪魔なんだよ、とは思いますがw
Wi-Fiの無効化キーを誤爆するという危険があるらしいが、Gentooだと頑張って設定しないとそういう特殊なキーはそもそも動かないので、そんな危険もなく安全ですね。
Gentoo入れてタッチパッドを無効化すれば、Windows10というOSも使わなくていいし、全て解決するんではないでしょうか。


前置きはこのぐらいにして、色々と使うものが安定してきたので今の環境について書いていきます。

デスクトップ環境

Gentooportageというパッケージ管理システムがよく壊れるというか、依存関係が複雑なパッケージ入れてるとバージョンアップのタイミングでコンフリクトしたりする。
なので、依存関係の複雑になりがちなGUI周りのコンポーネントはできるだけ入れたくない。
というわけで、GTKベースにしつつGNOMEKDEとかいう重厚なデスクトップ環境を丸ごと入れるということはせずに、Awesomeというタイル型ウインドウマネージャーを直接起動している。
PCが起動すると、コンソールのログイン画面が出て、ログイン後にコマンドでGUIを起動するようにしている。xinitrcに"exec awesome"と書いてstartxを実行する。
おかげでめっちゃ軽い。起動直後のメモリ消費は200MB程で済む。

ランチャー

AlbertというAlfredもどきがあったのでランチャーとして使っている。
元々Alfredの高度な機能はほとんど使ってなかったので、アプリの起動さえ出来れば特に困らなかった。
Gentooにはパッケージもあったので簡単に入って便利。

ターミナル

mltermを使っている。
24bitのtrue colorが表示できて、sixelが使えるから使っているのだが、正直そこまで軽量とは感じないので、もうちょっと軽いターミナルを探している。
mltermの良い所は依存コンポーネントが少ないところ。gnome-terminalとかkonsoleとかは依存が多過ぎてもっての外だ。
urxvtが24bit表示できれば良かったのだが……。

クリップボード管理

parcelliteを使っている。
システムトレイに常駐できるし、基本的な機能があって、これも依存が少なかったので採用した。

開発環境

最近はneovimとdockerがあれば大体何とかなる。ホストOS側に色々と入れるとportageが壊れやすくなるので、できるだけdocker内に封じ込める様にしている。
コンテナ内で操作することも色々あるのでストレスなく操作できる様に、自分のzshrcとかpecoとかを突っ込んで"docker exec"を実行できる簡単なラッパースクリプトを書いている。

Twitterクライアント

TweetDeckがメイン。普通にChromiumで表示している。たまにmikutterを使うこともある。

チャット

仕事ではSlackを使っていて、Gentooにはパッケージがあったのでそれをそのまま入れて使っている。

音楽再生

wine上でfoobar2000を動かして使っている。というか未だにこれより便利な音楽プレーヤーが無いのってどうなんだ。10年前から何も変わってないぞw
自分の持ってたUSBのDAC兼ヘッドホンアンプは普通に使えたので、wine経由してWASAPIで再生している。96kもちゃんと出た。
問題は、iTunesレーティングが同期しないことで、iPhoneを使っている身としてはちょっと辛い点が増えた。

動画再生

mpvが軽くて良い。
しかし、自分のT460sは一応GeForceを積んでいるのだが、今のところLinuxでこういうノート用の追加3DコントローラーでVDPAUを上手く使う方法が無い。
色々調べたのだがかなり厳しそうだ。
DRI2で動かせば、可能性ありそうな気がするんだが、良く分からなかった。
なので、GPUは上手く活用できていない。

ファイラー

とりあえずspacefmとvimfilerを併用して使っている。
これも依存が少ないから採用した。nautilusとかGNOMEが入ってしまうので駄目だ。
その外のファイラーも大体デスクトップ環境とセットで入ってしまって辛かった。

Wi-Fi接続とbluetooth接続

それぞれコマンドでやっている。
Wi-Fiはiwコマンドかiwconfigコマンドで電源を操作して、wpa_supplicantを起動しておけば勝手に繋がった。
接続設定とかパスフレーズはwpa_passphraseコマンドの実行結果を/etc/wpa_supplicant/wpa_supplicant-.confに書いておく
bluetoothは、bluetoothctlというコマンドを使ってconnectしている。しかしBluetooth4.0規格のマウスが上手く繋がらないとか時々ハマる。
ヘッドセットとかイヤホンの類はまだ試してない。

パスワード管理

1passwordのWeb版をお試し中。wine使ってWindows版を入れるかどうかも検討しているが、まだ決めてない。

電子書籍とか画像ビューワー

KindleはwineでWindows版入れたら普通に使えた。
画像系はmcomixというビューワーでzipとかrarの中身も見れるのでこれを使っている。
PDFとかePubはあんまり良いビューワーが見つかってない。ePubFBReaderというのを使ってるが正直微妙。

マルチディスプレイ

最近は、EDIDの情報がちゃんと取れれば普通にディスプレイを認識するので、"xrandr"コマンドでディスプレイ表示を切り替えれば、大体上手く動作する。
ただ、接続チェックはちゃんとした方が良い。

まとめ

全体的な感覚としては、Macより2倍は動作が軽い。
特にタイル型ウインドウマネージャー派としては、Mac上で無理矢理やってるのとは全く反応速度が違う。久々の感覚だが、やはりこうであって欲しい。
Dockerを開発に使う上でも、変なハマりどころとかパフォーマンス上の問題が発生しないのでめっちゃ快適だった。
そもそもコンテナは起動が速いとか言ってるけど、Macだと結局VM噛んでるから別に早くないし、むしろストレージに問題ありまくりでめっちゃ辛かった。
開発機として使うなら、やはりLinuxの方が良い。iOS開発者はどうしようもないけど……。
最近のLinuxは蓋を閉めたらちゃんとスリープできるので、バッテリー問題も困ることはそんなに無い。
まあ、稀に復帰できないことはあるんだけど、そもそもMacでも時々復帰しないし。
CPUがあんまり高クロックで動作しない様に上限かければ6時間は電池が持つ。


というわけで、今のMacが気に入らないなら、そろそろMacから離れる好機かもしれない。
宗教上の理由でLenovoのPCを使いたくない、という人も居るかもしれないし、別にThinkpadを進めるわけではないけど……。


2/3 15:00 追記
はてブコメントで、資料作成とOfficeどうしてるんだろう?というものがチラホラあったので追記しました。

資料作成について

資料は、よっぽどビジュアルに凝ったものを作る場合を除いてmarkdownで書いてreveal.jsで表示する形にしている。
Mac使ってた時も最近の時期はそうだった。
ビジュアルが必要なかっちりした発表の時は、仕方ないのでMacを引っ張り出してきてkeynote使うかもしれない。

Officeについて

一応、必要になったらlibreofficeを入れようと思っているが、ここ3年でプレゼンテーション資料以外の用途でOfficeっぽいものが必要になったことはない。
基本的にはGoogle DocsGoogle Spreadsheetで対処している。
そもそもMacにもOffice自体は入ってなかった。あのKeyNoteの付属品みたいなものは、あんま役に立たないし……。
謎マクロが大量に入ったExcelがやってきたら詰むけど、元々の状況に変化は無いw

MacBook Proを捨ててThinkpad T460sを買ってgentooを入れた

英字キーボード配列にできて開発ユースに耐えうるノートPCがとても選択し辛い昨今、なんとなく安牌ポジションだったMBPについにさよならしました。
元々、Macを好んで使っていたというより、解像度が高くて英字配列にできて電池の持ちが良いというノートPCがMBPだっただけで使ってたのですが。

一番大きな要因がコンテナの利用頻度が増えて開発環境も含めてDockerを使う様になったので、Macだとどうにも面倒だという点です。
docker-machineのデフォルトとかdocker for Macのデフォルトが遅過ぎて話にならないし、dinghy使ってもdocker-sync使っても微妙でかつ面倒くさい。
普通にLinux上で直接動かせるなら、無駄な苦労だと思って、まず開発用PCをLinuxにしようと決めました。
そしたら新しいMBPが30万越えるのに、一世代前のCPUとメモリでドヤ顔してくるわ、キーボードがペラッペラの気に食わない形になったので、買う気が失せたのを機にMBPを買うのを止めた次第です。
(Touchbarはどうでもいい)
まあ、昨今Thinkpadレノボ化してからあんまりいい話聞かないので悩みはしましたが。

T460sスペック

  • CPU: skylakeのi7-6600U (これは残念)
  • メモリ: DDR4 24GB
  • ディスプレイ解像度: 2560x1440
  • ストレージ: NVMe 1TB

基本部分はざっくりこんな感じ

MBP 2016との比較としては、

  • CPUは同等
  • メモリは多いし早い
  • ストレージの上限はMacの方が多い
  • ディスプレイの解像度はMacが買ってるが、非光沢なのは良い (というか3年以上前からあの解像度のMacがヤバイ)
  • キーボードはMacより良い (トラックポインタ付いてるし)
  • TouchpadはMBPの方が精度良いと思う
  • 重さは13インチとほぼ同じ
  • ベゼルが180度まで開く
  • 普通のUSB3.0端子がある
  • 10万近く安い
  • ドック追加しても数万円安い
  • ESCキーとかFnキーがある!(どうせHHKB使うけど)

自分は、3年前のMBPからの移行だったのでかなりスペックが上がったし、やっと4kディスプレイが60hzで出せるようになってちゃんと使えるようになったのが嬉しい。
MBPと比べてでかいのは、普通のUSB端子があるのでケーブル買い替えなくていいし、無駄なアダプタケーブル持ち歩かずに今まで通りで良くて楽。
ディスプレイに関しては、3年以上前にRetina出してた当時のMBPは今思えば異常だった気がする。あの時はテンション上がったのになあ……。今は細いバーでDJ出来るぜーとか言っててもうなんか……。えー、それ?って感じである。

使用感におけるMacとの比較

OSはgentoo linuxを入れて使っている。archと悩んだがそれなりにgentoo党なので慣れてる方にした。
久々にインストールバトルしたから、ハマりまくって辛かったが……。

gentooにして余計なものを結構削ぎ落とした構成にしたので、GUIを起動しても起動した辞典でメモリ消費量は350MB程で、24GBメモリ積んでるので、これなら相当富豪的に使っても無くなったりしないだろう。
dockerがめっちゃサクサク使えるし速い!やっぱMacOSはこの辺り辛い。
全体的にクソ早くなった。自分のMacが大分色々と肥大化してて無駄なものが動いてたってのもあるが、このサクサク感は嬉しい。
キーリピートとかキーレイアウトは普通に変えられるが、KarabinerがSierraでも元の機能レベルで動く様になったならあっちの方が多機能で良い。あそこまで簡単にレイアウト変えるのはLinuxだとちょっと辛い。
homebrewは何だかんだで良くできてて楽。バイナリパッケージとコンパイルを適度に組み合わせられるのが良かった。
この辺りはgentooを使ってるので色々と時間がかかる。まあ、そこが大事な人はarchを使えば良いと思う。
後は、どうせvimでコード書いて端末で動かすので開発環境的には大して変わらない。

今は、ファイラーどうしようか悩んでる所なのでFinderとの差は良く分からん。Finderサムネイルがサクっと確認できてリサイズも簡単だからそこは強力だと思う。

全体としては、開発環境としてはやっぱLinuxの方がどう考えてもサクサク感が高い。ちょっぱやである。

一つ大きな問題があって、今まで1passwordに超依存した生活になっていて、これをどう移行するか目処が立ってないところである。
もう良く使うものはFirefoxにマスターパスワード付きで保管して、他の特殊なものはiPhoneの1passwordから参照する、という手段で大体の利用側は何とかなる。
問題は登録だがこっちは良いソリューションが無い……。

gentoo苦労話

そんな苦労するぐらいなら使うなって突っ込みもあるかと思いますが、苦労するだけの見返りはあるのでgentooを使ってます。とはいえ色々ハマったのでまとめておきます。
ちなみにgentooを使ってて嬉しいのはパッケージ管理でライセンス上きついものも普通に管理できるし、コンパイルオプションレベルで必要なもの取捨選択できて、色んなものをマニュアルで設定する訓練が積めるのでLinuxの事が良く分かる、とかそんな所ですね。
ここからは、gentooの設定の流れをつらつらと書いてるだけなので、興味無い人は続きは読まなくて大丈夫ですw


まず、インストールする時、GentooのLiveDVDが普通に動作するので、変にハマらなければそんなに苦労は無い見込みだった。(結果ハマったけど)
lspciとかdmesg見ながらカーネルに組込むドライバをぽちぽちとやる。コンパイルまでは問題無かった。
しかしUEFIのノートPCにLinuxをまともに入れるのはこれが初だったので、UEFIについての知識が無くgrubのインストールで調べものをする。
で、元々Windowsに使われてたブート領域に相乗りすることにし、efibootmgrを使ってgrubの起動処理を書き込もうとしたのだが、なんかefibootmgrがバグってたのか俺のchrootのやり方が悪かったのか分からんのだが、chroot環境の中でgrubefiバイナリのパスを指定すると、HDDのタイプとかUUIDが全部0で埋まってしまうという訳の分からん状態になった。
エラーメッセージも何も出なくて成功した様に終了したので、最初それに気付かなくてgrubが動かねええええ!って唸ってた。

1時間ちょっとぐらい悩んで0埋めされてておかしいことに気付いて、色々ググった結果同じ症状が出てた人を発見。なんかバージョン上げると解決する、みたいな話があったのでchrootの外に出て、efibootmgrをunmaskして新しいバージョンを取ってきたら、無事にEFIの設定を書き込めた。
これでgrubが起動できるようになった。

その後、カーネルが動かなかったのだが、これはframe buffer consoleのサポートを有効にしてないという凡ミスで、大分時間を浪費した。久々過ぎて忘れてた。
一回、カーネルを入れた後で、Arch LinuxwikiによるとACPIとかサスペンド回りでバグがあるらしいんで、カーネルをunmaskして4.8.9まで上げる。

後、dockerとかKVMで必要になりそうなカーネルコンフィグを組み込んでいく。
wifiはドライバはあるけどファームウェアは組み込んでおくか、どっかに用意しとく必要があるっぽかったので、wireless-wikiからfirmwareを落としてきて、Gentoowikiを見ながらカーネルに組み込んだ。
無事認識できて良かった。

これで初期インストールは完了。


とりあえずインターネットに繋がらないと何もできないが、dhcpcdを入れて有線で繋げばすぐに繋がったので、しばらくそれで作業した。繋げばDHCPからIP取れるのありがたい。
wifiはArch LinuxWikiを見ながらsystemdからwpa_supplicantが起動できるように設定をして、パスフレーズを設定ファイルに書いたら勝手に繋がった。最近のLinuxはすげー楽で焦った。


ウインドウマネージャは前Awesomeを使っていて挙動も好みだったので、Awesomeを使うことにする。
最初gnomeをベースにしようかと思っていたが、余計なもの入れて時間かかるのもなーって感じだったので単体で突っ込んで、xinitrcから直接起動することにした。
なんかこれで問題無く動くし、起動時にstartxするぐらい大した手間でもないので、もうディスプレイマネージャーもデスクトップ環境全体も必要無いやと判断して、このまま運用しようと思っている。
おかげで、起動した時点での消費メモリは350MBぐらいで、異常に軽量になった。
この時点で、開発に使うだけなら使えなくはないぐらいにはなったけど、まあ流石にまだちょっと辛い。


次は音を出せるようにする。これはArch Linuxwikiを見つつpulseaudioを入れたらすぐに認識した。最近はデバイスドライバさえちゃんと入ってれば、ほとんど勝手に認識するから素晴らしい。まあここで認識してくれてなかったら大分辛いところだったが……。
音量の調節は最初コマンドでやってたが、流石に辛いのでvolumeiconとpavucontrolをインストールした。volumeiconのおかげでキーボードのVolUpとVolDownキーが効く様になったが、ちょっとイマイチなので今後直す。


サスペンドがまともに動かんのはノートPCだと結構辛いので、ACPIのwikiを見つつacpidを入れたら、初期設定で普通に動作した。蓋を開け閉めした時も勝手に動くので驚いた。一応ちゃんとカーネルコンフィグは事前に準備しておいたのだが、最近は普通に動くんだなーと思った。


ちなみにカメラもドライバを組み込んでおいたら勝手に認識して動作した。ビデオチャットサービスに繋いだら普通に使えて良かった。


こんな感じで大体仕事で使えるようになったのだが、自宅のPCレイアウト変えたり仕事の合間に調べものしながら作業してたりで、結局5日ぐらいかかってしまった。
まあ、おかげで現在は結構快適です。ibus-skkでスティッキーシフトができないことを除けば……。

やっぱ、MacOSより開発用としてはLinuxの方が良いし、個人的にもこっちの方が好きだ。
このタイミングで捨てて正解だったような気がする。
今更移行するに移行できない1passwordとiTunesというものがあって、この辺りをどうするかは未だに目処が立ってないんで、当分の間自宅からMacが無くなることはないけど。

今更だがISUCON本戦の感想と反省

もう2週間ぐらい経ってしまったが、tagomoris & tnmtとチームを組んでISUCON本戦に出場してきた感想を書こうと思う。
中々ブログ書いてる暇が無くて、えらく遅くなってしまった。
ちなみに結果は6位。3位以下は割と団子状態で、後一手ぐらい刺さってれば3位は行けただろうなあと、残念な思いがある。
まあ、どっちにしろ1位はちょっと難しかった。


細かい流れはモリスさんのブログに既に書かれているので、そちらに譲る。


今回のお題はdockerがバリバリ活用されていたのと、SSE + Reactによるサーバーサイドレンダリングの組み合わせという非常にモダンな構成だった。
お題の発表後は、流石にうわー……マジかーって感じになった。
そもそも、現時点のRubyのWebフレームワークというものはSSEの様なストリーム配信と余り相性が良くない。
なので、あんまり使わないし、最適化のノウハウも溜まってない。辛い。


dockerに関しては、仕事でバリバリ使ってたので余り問題にならなかった。自分がdocker周りの環境整備を引き受けて、諸々の調整をしてたしログの確認もそんなに問題無く実現できたと思う。仕事で使ってて良かった。
なので、多くのチームがdockerを剥がしにかかってたけど、うちは最後までdockerを使ってた。これは良い点もあったが、もしかしたら悪い点もあったかもしれない。
良い点は、動作確認がめっちゃ楽だったこと。これは予選で動作確認が辛かった反省を活かせたと思う。実装の修正がとても楽だった。そして、プロセスの数の調整とかredisの追加とかも割と簡単にできたこと。これはdockerに慣れてないと手間取る可能性はあったが、上手く対応できて良かった。
悪い点は、もしかしたら有意なレベルでオーバーヘッドがあったかもしれないこと。自分の感覚ではそこまでスコアに影響するレベルじゃなかったとは思っているのだが……。


今回は、redisの投入周りやdocker周りの処理を大体引き受けて、まあまあ役には立てたと思う。
大きな反省点としては、やはりSSEとサーバーサイドレンダリングの知見が足りなかったので、ちょっとした変更で改善できそうな点を見過ごしてしまってたところがある。
後はやる事に手一杯過ぎてベンチマーカーのログをちゃんと確認するのに意識が回らなかった。この辺りISUCON経験の無さが出た気がする。


最も失策だったのは、nodeで書かれたサーバーサイドReactに手を入れなかったこと。かなりCPU食ってたのは分かってたんだが、ここ弄って勝てるならnode選択が有利過ぎるんじゃないのか、と思ってしまって結局手を入れることができなかった。
割と普通のWebアプリケーションとしてチューニングできるところはある程度処理できたはずなので、ここのキャッシュが上手く出来てればベースのスコア水準は割と高い方だったんじゃないだろうか。無念である。
ISUCON本戦は複数台構成になることもあって、やれる事の範囲が滅茶苦茶多くなるので、時間内に上手く最善手を見つけてその手を打ち切れた所が勝つって感じだと思うが、うちのチームはそれがやれなかった。


チームとしては、やはり皆経験豊富だしめっちゃやりやすい感じだった。会社バラバラでチーム組んでる中ではかなり良いチームだったと思う。
しかし、モリスさんが最近ミドルウェアばっか書いてる様に、俺もあんまり普通のWebアプリケーション書いてないというかデータフローの設計とか分析基盤依りの仕事ばっかしてるので、ちょっと勘が失われている所があったかもしれないw
何にせよ、優勝は逃したものの初出場で本戦で勝負になるスコアが残せたのは、優れたチームメイトのおかげであることは間違いない。
負けたのは残念だったけど、とても楽しい1日だった。
モリスさん、tnmtさんと、ISUCON運営メンバーの皆様、ありがとうございました。