tmux起動しようとしたらdyld: Library not loaded: /usr/local/opt/libevent/lib/libevent-2.1.6.dylib

@ macOS Mojave

ref: https://apple.stackexchange.com/questions/127186/installing-tmux-but-getting-dyld-library-not-loaded-referenced-from-usr

Homebrewでインストールしているtmuxが起動できなくなる

% tmux
dyld: Library not loaded: /usr/local/opt/libevent/lib/libevent-2.1.6.dylib
  Referenced from: /usr/local/bin/tmux
  Reason: image not found

stackexchangeの内容を参考にlibeventをlinkし直してみたりしてもエラーは解消されず。

ためしに、libevent-2.1.6.dylibなるファイルがいるかどうか確認してみるといない。かわりにlibevent-2.1.7.dylibがいた。

ってことで、更新されたlibeventをtmuxが参照できていないんだと思うので、tmuxを再インストール

% brew reinstall tmux

解消されました。

開発環境を改善しようと思って無理やり左右分離式キーボードな環境をつくっている件

最近、キーボード関連のエントリー多いですね。

hikakujoho.com

HHKB2台使いとかマジですごいです。。。

で、なんで自分のブログにこんなこと書いているかと言ったら、自分も同じようなことをしているから。

同じようなことをしている人がいて、勝手にうれしくなったのです。

↓今の自分のキーボード環境↓無理やり左右分離式キーボードな環境をつくっています。

Apple Wireless Keyboard（US配列）の2台使い。Magic Keyboardじゃないのは、買い替えてないから（笑）

Apple Wireless Keyboard (US) MC184LL/B

なんでこんなことしているのか

Apple Wireless Keyboardって、コンパクトでいいキーボードなんですが、コンパクトすぎて、肩が前側にどんどん入り込んでくるんですよね。

そうすると、肩甲骨まわりの筋肉がずっと緊張した状態になったりして、筋肉やら柔軟性やら的によくない。

自分は肩が凝っている感覚はないのですが、肩や肩甲骨の動きが良くない感じが強くて課題に感じていました。

ErgoDox EZとかが話題になったりして、左右分離式のキーボードを試したかったのですが、なかなか踏み出せず。。。

そんなときに、Apple Wireless Keyboardを2つ持ってることに気づいて、並べてみたわけです。

キーボードを2つ使うための設定

macOSでは、複数のキーボードを使うときには、ちょっとした設定をする必要があります。

それは、左側のキーボードでShift、右側のキーボードで別のキー、みたいにキーボードをまたいで修飾キーを使うときのこと。

OSのデフォルトの状態では、別々のキー入力とされてしまうため、修飾キーが無視されます。

Karabiner-Elementsを使いましょう！幸せになれます。

注意点は、macの電源をつけた直後のログイン画面ではKarabiner-Elementsは起動していない状態なので、パスワード入力時に修飾キーを使う場合は、キーボード1つで入力しましょう。

キーボードの角度とか

普通にキーボードを2つ並べても、キータイピングはしやすくないです。

手首の角度が変な感じになって、むしろ腱鞘炎になるかも（？）

なので、キーボードの置き方を工夫します。

自分の今の状態は写真のとおりですが、

• ちょっとだけ外側に開く。
• キーボードの手前側を少しだけ高くする。キーの面がおおよそ水平になるくらい。

キーボードの手前側を高くする部分は、100均で買った滑り止めシートをまるめて高さ調整しています。

で、キーボードの手前側が高い状態で、手をおきやすくするために、リストレストを用意します。

僕が使っているのは、ヨドバシで安く売ってたリストレスト。1つ300円ちょっとを2つ。

ロアス ジェルリストレスト グリーン WR-703GN

ということで改めてこんな感じ。

ツールド東北2018エントリーその後

先日ツールド東北2018のエントリーで起きたあれこれについて自分が考えたことを勝手に書いていたわけですが、、、

sugilog.hatenablog.com

その後JTBスポーツさんも動きがありましたね。

jtbsports.jp

先日あれこれが起きたエントリーは先着順のエントリー。

ツールド東北2018では抽選エントリーもあって、先着順の申込みのあとに抽選エントリーがある、という順番でした。

先着順エントリーでトラブルがあったので、抽選エントリーを遅らせる、という対応をしていたわけですが、

tourdetohoku.yahoo.co.jp

その間にトラブルの検証と新しいサーバー環境を用意した、ということのようです。

今後トラブルが発生しないで、いい感じにスポーツイベントを支えてくださることを期待します！

ツールド東北2018先着順エントリー＠JTBスポーツステーションの問題点をウェブアプリケーションプログラマー視点で考えてみる

5月26日（土）20時からツールド東北2018一般参加者のための先着順エントリーが開始され、まさかの状態になりました。

その時のTwitterの状況は #ツールド東北 を検索しただけのまとめを作っておいたのでそちらで見ていただけます。

togetter.com

まさかの状態とは？

ざっくりいうと、アクセス集中によるサーバー負荷高等のため、ユーザーがエントリーをうまく進めることができない状態（＝不具合がある状態）が続きました。

5月26日22時現在、参加エントリーページにアクセスしづらい状況が続いておりご迷惑をおかけし大変申し訳ありません。サイトに接続しづらい状態、一部のお客様のエントリーが完了できない状態が続いております。大変恐れ入りますが、しばらく時間をおいてアクセスいただきますようお願い申し上げます。

— ツール・ド・東北 (@tourdetohoku) May 26, 2018

ツールド東北事務局（≒Yahoo Japan）のお詫びによると、不具合が5時間ほど続きました。

tourdetohoku.yahoo.co.jp

ちなみにシステム的に当事者に当たるJTBスポーツステーションがお詫びを出したのは2日たった5月28日（月）。

jtbsports.jp

このエントリーでは謝罪が遅いとかうんぬんとかそういう話には触れません。

ウェブアプリケーションプログラマー的に今回の問題を考えてみる

自分はウェブアプリケーションのプログラマーです。

ウェブアプリケーションプログラマーとして、今回のツールド東北2018＠JTBスポーツステーションの問題を考えてみます。

サーバーをあらかじめ増やしておくべき、みたいな話は出しません。そもそも今回のトラフィックが結局どのくらいあったのかもわかりません。

問題点を以下の3点で整理してみます。

• 申し込みステップが多すぎる。
• 一部のサーバー負荷がシステム全体をダウンさせてしまう。
• JavaScriptによるフォームコントロールの存在によってUIが期待しないエラー状態になってしまう。

申し込みステップが多すぎる

今回のツールド東北2018＠JTBスポーツステーションの申込みは、ステップをまとめると以下のようになっていました。（覚えている範囲です。）

• JTBスポーツステーションログイン
• イベントページ
• 申し込みコースの選択をするページ
• 申し込み内容の入力をするページ
• 申し込み内容の確認をするページ
• 申込みの確認、というページ
• 支払い方法の選択をするページ
• 申込み内容の確定ページ

支払い方法でクレジットカード決済を選択すると、更にステップが増えます。

• マイページから未決済イベントを選択。
• 支払いの注意事項の確認をするページ。
• 支払い方法の入力をするページ。
• 決済完了ページ。

覚えているだけで12ページあります。12ページのページ遷移全てでアクセスエラーになる可能性があります。

エントリーは大事な内容を入力していますし、決済方法も大事な入力をしています。簡単にページ数を減らすことがいいとは言いづらいですが、ちょっと過剰です。

申込み内容の入力は、連絡先の入力と緊急連絡先の入力をしています。事前でも事後でも入力できる内容＝イベントとは本来直接関係しない入力内容です。

申込みの確認、というページは、「申込み内容の入力ができました」「次は支払い方法を選択します」ということを言っているだけで、何も情報がありません。申込みの途中なので、仮受付状態になっている、みたいな話でもありません。

じゃあ、どうするの？

より前工程の申込みステップをシンプルに省略することができれば、それだけアクセスを削れます。

丁寧な確認ステップを進ませたいのであれば、それだけインフラコストへ投資する必要がある、という言い方もできるかもしれません。

一部のサーバー負荷がシステム全体をダウンさせてしまう

JTBスポーツステーションは、システム全体が単一サーバー群で構成されていたような雰囲気があります。

ツールド東北2018のエントリーが始まると同時に、JTBスポーツステーション自体へのアクセスや、JTBスポーツステーションへのログイン処理もアクセスエラーになり始めました。またクレジットカード決済についても同様に、アクセスエラーが何度も発生しました。

おそらくアクセス集中していたのは、ツールド東北2018イベントページ〜申し込み内容の入力あたりまでです。（すくなくとも、クレジットカード決済にアクセス集中していたことは考えづらいです。）

つまり、一部の機能へのアクセス集中によって、システム全体がダウンしてしまっていた、という状態が考えられます。

で、どうするの？

クリティカルな機能をサーバー負荷から切り分けられるような構成をすることを検討できます。

• イベント申し込み機能
• クレジットカード決済機能
• その他の機能

イベント申し込みは、先着順のような申込みの場合、一気にアクセスが集中する傾向があります。イベント申し込みにアクセス集中したとしても、クレジットカード決済には影響させない、というような切り分けを考えておくとよさそうです。アクセス集中する場合には、イベントの規模に合わせて、サーバーを増強しておくことができます。

クレジットカード決済を切り分けるといいのは、お金のやりとりが発生する部分だから、です。決済方法を入力したあとにアクセスエラーが発生すると、決済ができたかどうかが不安になります。多重決済をしてしまった場合、ユーザークレーム〜補填をする必要もでてきます。

アクセスするサーバー群を整理できたら、ボトルネックがデータベースに移るはず。

JavaScriptによるフォームコントロールの存在によってUIが期待しないエラー状態になってしまう

JTBスポーツステーションの申込みフォームのいくつかは、JavaScriptによってコントロールされていました。

そのJavaScriptは、別ファイルで追加リソースとして読み込まれる内容に記述されていました。

とはいえ、ここまではよくある話。

問題は、アクセス集中によってサーバーへのアクセスがし辛い状態の中で、同じサーバーからJavaScriptを読み込もうとしていたのです。つまり、UIにはみえないところで、JavaScriptの読み込みがエラーしていました。

JavaScriptの読み込みがエラーしたことで、申込みフォームを動かすためのJavaScriptコードが存在しないため、申込みフォームが反応しない、ということが発生していました。

ちなみにですが、JTBスポーツステーションは、JavaScript以外にも画像やCSSもアプリケーションサーバーから配信しているように見えます。

んで、どうする？

3つくらい方法があります。

• ミッションクリティカルなフォームのコントロールにJavaScriptを使わない。
• ミッションクリティカルなフォームコントロールするJavaScriptはHTMLの中に書いてしまう。
• JavaScriptのような静的ファイルはCDNを使って配信し、アプリケーションサーバーへアクセスさせない。

1つ目の方法は最も簡単な方法ですが、申込みフォームの入力内容チェックなどができなくなります。

2つ目の方法はありがちですが、JavaScriptライブラリに依存し始めた途端に実現が難しくなるかもしれません。単純にHTMLのファイルサイズが大きくなるだけなので、読み込みが遅くなることも予想されます。

3つ目の方法はコストがかかる方法になりますが、JavaScriptに依存したUIをつくることが当たり前のようになっている今なら、最も現実的な方法だろうと考えます。

このコンピューター書がすごい！2018年版 の勝手なまとめ

新春座談会 このコンピュータ書がすごい！ 2018年版—2017年に出たコンピュータ書ならこれを読め!

今回でなんと10周年。おめでとうございます！

（2017年は、iPhoneと初音ミクが10周年だったらしい。）

このイベントで紹介される本は、2017年の1年間で、ジュンク堂書店池袋本店で売れたコンピューター書のうち、試験対策本などを除いた本のランキング。

sugilogの感想やら、興味持った本やらをまとめていきます。

---

2017年版のトピックと感想

リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

2012、2013、2014と総合1位だった本。2017年も総合4位という継続して人気の本。

会社でも読んでいるメンバーいるし、そのメンバーの説明をきいても、内容を見ても、とても納得の度合いが高い。

動けばいい、ということ以上に、人が作って読んでメンテナンスするのがプログラムなんだ、ということで、不滅なんだなと。

Excel本

2017総合ランキング2位が、Excel最強の教科書 完全版

Excel 最強の教科書[完全版]――すぐに使えて、一生役立つ「成果を生み出す」超エクセル仕事術

2017総合ランキング7位が、たった1日で即戦力になるExcelの教科書

たった1日で即戦力になるExcelの教科書

Excel、というかVBA for Excelは会社でもサポートしているから、少しでも理解を深めないと、、、。

Python／機械学習本

大量にあるので、別にまとめます。

とにもかくにも、機械学習、人工知能が、ホットトピックなんだな、と。2時間のイベントの中の30分位？時間を使って紹介されてる。

ブロックチェーン

ほんのちょっとだけど、ビットコインについての情報収集を始めた。

投資をするような余裕はないけど、知らなくてよいのかが疑問になってきたので。

エンジニア的には、ブロックチェーン。

本のタイトルで言うと、ブロックチェーン・プログラミング、とか。

ブロックチェーン・プログラミング 仮想通貨入門 (KS情報科学専門書)

キーワードの一つに、スマートコントラクト、というものがあるみたい。全然知らないので勉強しないと。

DevOps／SRE

The Dev Ops, SRE, Infrastracture As Code, ...

どうやって運用チームを作って、動かして、、、、みたいなところ。

会社でも少なからず関わるので、いよいよ知らないでは済ませない。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

---

Python／機械学習本

Python本とても人気。特に機械学習と絡めたりしている。

ちょっと読んでみたいのが、100問でわかるPython、学生のためのPython （教科書的なもの）

100問でわかるPython

非エンジニアでもとっつきやすい入門書も、エンジニア向け入門書も、いろいろ出てる。

総合ランキングにも、Python本や機械学習本がたくさん入っている。

• ゼロから作るDeep Learning
• 退屈なことはPythonにやらせよう
• などなど。

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

ゼロから作るDeep Learning、は2016年にでた本で、2017年になって総合ランキング1位。 イベント会場でちら見しておもしろそうだったので、買いました。

著者さんからのメッセージによると、続編が執筆中らしい。続編も「ゼロから」コンセプトを継続。

講談社の機械学習プロフェッショナルシリーズに新しいシリーズ。

• 青い本は理論より（前から出てる）。
• 赤い本は応用より（前から出てる）。
• 新しく入門向けに、緑本。これも読んでみたい、けど数式が多いらしい。

機械学習がホットットピックになっている関連で、関連の数学本もたくさん出ている。

機械学習のツール、ライブラリ関連もたくさん。R、Julia、TensorFlow、Chainer、など。

。。。大量に紹介されてる。。。

---

その他、興味を持った本。

Androidを支える技術

Androidを支える技術〈I〉──60fpsを達成するモダンなGUIシステム (WEB+DB PRESS plus)

Androidを支える技術〈II〉──真のマルチタスクに挑んだモバイルOSの心臓部 (WEB+DB PRESS plus)

2巻構成。

1巻はGUIを時間制約がある中でどうやって作るのか、2巻はアクティビティをメモリの制約の中でどうやって作るのか。

Android開発者くらいしか読んでない気がするけど、とてもいい本。

今の最前線にいる「スマホ」で、コードリーディングができる「Android」をテーマにしている。

でも、ウェブだけとか、昔ケータイやってました、とか言う人も是非読んでほしい本。

スマホ、という枠組みに対して何を頑張り何を捨てたのか、ということ。結構とんがっている内容らしい。

ビッグデータを支える技術

ビッグデータを支える技術―刻々とデータが脈打つ自動化の世界 (WEB+DB PRESS plus)

Googleを支える技術の著者さんが書いている新しい本。著者さんはTreasure Dataに所属している。

http://gihyo.jp/book/2017/978-4-7741-9225-3

プログラマの数学 第2版

プログラマの数学第2版

結城先生の本。改訂版。

第1版を読んで勉強しているので、すぐに買うのは微妙なんだけど、、、機械学習周りのことを加筆してるみたいなのでそこは読んでみたい。

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

パフォーマンス関連。2017年にいろんなレイヤーでのパフォーマンスが出ているらしいけど、今のところ自分に必要なのはサーバーサイド。

他にフロントエンドもある。

• Webフロントエンドハイパフォーマンスチューニング
• 超速！Webページ速度改善ガイド

超速! Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus)

Webページ速度改善ガイドは2017年に紹介記事も読んで、会社に一冊ほしいなぁと思っていた本。

CSSの設計し直しをするタイミングでは買って勉強したい。

Real World HTTP

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

HTTP 1.0, 1.1, 2.0 でどんな変化があったのか、どういうことになっているのか、という内容。

どちらかというと、仕様書よりも現実でどうする、みたいな話に落としているところで興味がある。

アルゴリズム図鑑

アルゴリズム図鑑 絵で見てわかる26のアルゴリズム

代表的なアルゴリズムについて、とにかくコードでなく図で、こんな動き、ということをまとめた本。

自分は仕事のためにプログラミングを覚えて、ウェブの世界の（難しくない）プログラムばかりをつくってきたわけで、アルゴリズムによるデータの動きをイメージするのが不得意。

Goならわかるシステムプログラミング

Goならわかるシステムプログラミング

ウェブ記事で勉強させていただきました。自分には内容的にこれでも大変でしたが、、、

とはいえ、学びは多いです。プログラムをただ書いているだけだと、意識してないことが多い。

それだけプログラミング言語がいい感じに抽象化してくれているのだ、ということへの感謝も湧いてきます。

C言語ポインタ完全制覇

新・標準プログラマーズライブラリ C言語 ポインタ完全制覇

ポインタコワイ。。。なんて言ってられない。

この本は新版なんですね。

悲劇的なデザイン

悲劇的なデザイン

放射線をあてる機械のプログラムは、間違えると人が死んでしまう。

影響の範囲やら度合いはさておき、プログラムはユーザーに影響をあたえるわけです。

教訓をまなんだり、どうやって防ぐかをまなんだり、大切な内容。

正直、とっつきにくいタイトルですが、どこかのタイミングで読んでおきたい。

ISUCON7決勝に参加してきました＠チームinarisan

ということで、参加して、負けてきました。

isucon.net

正直、全然スコアのびず。

初期スコアが5000点位に対して、最終スコアが13600点くらい。人権は失っていませんが、仕事ができた感がありませんorz

優勝チームが65000点くらい、2位チームが28000点位、優勝チームが飛び抜けていますが、20000点超えたチームもそこそこいたみたいなので、全然だめでした。

お題は、クッキークリッカーをソーシャルライクに（みんなでクリックできるように）したもの。

ポイントは、アプリケーションによるサーバー4台に対する振り分け（いわゆるゲームのチャンネルシステムみたいなもの）と、ウェブソケットを使った通信の中でのアプリケーション改善。

できなかったことは大量にあるので、やったことくらいは記録に残しておきます。自分はアプリケーションメインなので、アプリケーションのことだけ。

やったこと

①ルームごとにサーバーの振り分けを矯正して、負荷をならしつつ、サーバーごとにデータストアを持てるように変更。

ルームの振り分けは1サーバーに集中させて、そこのデータストアで振り分けを管理するから、グローバルなデータストアは不要。（本当はここからインメモリ化しないといけない）

②ステータスの更新処理を0.5秒ごとから0.8秒ごと（くらい）に遅くする。ステータスは1秒以内にルーム内のユーザーに同期されれば良いので、おそくしちゃう。

（けど、ステータスの取得ロジックを最適化しきれなかった。）

③0.5秒なり0.8秒ごとに取得する必要があるステータスをキャッシュ化させる。

してみたけど、キャッシュの仕方が悪かったり、失効タイミングが微妙だったりで、ベンチマーカーのチェックに引っかかってしまう。

ということで

モニタリング、プロファイリング、などなど、問題点を見つける部分をもっと勉強する必要があります。

というか、全然わかってない、ということがわかった。

ブレブレだけど記念撮影しました。LINEやKlabの皆さまや運営に携わられてた皆さま、ありがとうございました。

ISUCON7参加しました＠チームinarisan

ISUCON7の予選に参加しました。

今回参加したチームはチームinarisanです。ギリギリですが本戦出場！！終了1時間前までは諦めが強かったですが、何とか挽回しました。

isucon.net

運営の皆さま、お疲れ様でした。スコアが伸びずに苦労しましたが、その分、学びも多くて問題を解くことを楽しめました。

来月もよろしくお願いします！

チームメンバー

@lukesilviaさん（会社の2年先輩）と@mashanさん（会社の1年先輩）と自分 @sugilog。

2015年にもISUCONに同じチームメンバーで参加していて、そのときは予選突破→決勝で撃沈、という感じ。ちなみにそのときのチーム名はチームhammerでした。

今回は、役割をちゃんと意識したり、分担したわけではないですが、ざっと↓の感じに。

@lukesilviaさんが経験豊富なプログラマーなので、全体チェックとDBまわり。

@mashanさんは普段はインフラ管理されているので、OSとかDBとかの設定、nginxでのキャッシュとか、足元の部分を全部。

自分 @sugilogはコードばっかりいじってました。今回用意されたサーバーにログインしたのも10回もないはず。最後はmemcacheと格闘してました。

実装言語

rubyの参考実装から修正をすることにしました。理由はふだん使っているのがrubyだから。

僕個人は最近はGoとNode.jsを扱うほうがおおいのですが、それでも実装スピードはrubyのほうが速くて、チームメンバー3人共あつかえるほうがいいので、やっぱりruby。

今回のお題だとそんなに言語に依存してパフォーマンスがブレる、みたいなことも無いんだろうと勝手に思ってますが。。。どうなんでしょ？？

コードは恥ずかしいので晒しません。最後にmemcacheと格闘した実装が汚すぎる。

良かったこと

dstatが神：@mashanさんがずっと監視してくれてた。おかげで帯域の詰まりもちゃんと把握できてた。

動作テストをする：@lukesilviaさんがアプリケーションの動作をしっかりチェックしてくれていたので、どこがおかしくなったかに早く気づけた。

最後まで諦めない：勝負に出すぎると最後のスコアを落とすんだけど、ちゃんと積み上げでやったことは裏切らないと思う。

勝負に出るコードはすぐに戻せるようにする：ベンチマークは知らせながら、リバートしたコードを手元に用意しておく。すぐにサーバー側のコードを元に戻せれば傷が浅くて済む。

やったこと

時間軸はだいぶ適当です。記録をちゃんと残してるわけでもないので、だいぶおかしいかも。。。

最初の2時間

• レギュレーションを読む。
• コードリーディング。
• OSとかDBでざっくり変えておいたほうがいい設定を変更。
• systemctlの切り替え。
• とりあえずのベンチマーク。
• とりあえずsleepを消す。。。消してよかった？

コード的にはN+1があるから、まずはそこからだね、と言う感じ。

アイコンが確実にボトルネックになりそうなことはわかってたけど、まだ優先順位を決められていない状態。

このときは、ウェブ2台＋DB1台の構成を維持。

次の2時間？

• N+1の解消。
• アプリから返したアイコンをnginxでキャッシュ。

全然スコアが伸びなくて落ち込む。

次の2時間

帯域が詰まってしまう、ということでその辺を改善。

• アイコンに対してNginxからキャッシュヘッダーを付けてみる（etag on;とか色々）。
• ウェブを3台にしてみる。
• アイコン画像の読み込みをlocalhostのDBから読み込むために、DBをレプリケーション構成にする。

ここで5万点くらい？だった気がする。上位チームがうん十万点で争ってたから、がちで凹む。

@lukesilviaさんは予定があるので戦線離脱！！（個人的にはこの時点でプチパニック）

次の1時間

• アプリケーションからetagヘッダーを付けて返してみる。アイコンの画像名の生成がhexdigestで計算されてたので、とりあえずそれを流用。
• 部分的にmemcachedからデータを取得できるようにコードを変え始める。
• ちょっとずつ再起動テストを始める。

あまり伸びず。。。

最後の1時間

• pumaのスレッドとworkerの数を調整。結局どちらも1か2か、それくらい。
• memcacheから可能な限りデータを引けるようにする。
• 再起動テストをしまくる。

他チームのスコアが見えなくなったくらいのタイミングでスコアが急伸。15万点付近まで伸びる。

あれこれやって、途中微妙に鳴ったのでコードを戻して、みたいなことをして、最後の最後で215280（2017-10-22 20:58:58 +0900 JST）。

正直、運が良かった、というところが大きい気がします。