Helix 5行ステンレスプレートを作った #Helix祭り

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。一部の人はご存知のとおり、最近は家でキーボードを作るのにはまってます。

ymotongpoo.hatenablog.com

ymotongpoo.hatenablog.com

しばらくこれらの40%キーボードを使っていて快適に過ごしていて、実際に普段もこれらをメインとして使っているのですが、紆余曲折あって積みキーボードとなっていた各種キーボードキットがサルベージされました。

1. Helix 5行のステンレスプレートのフルキットとKailh Low Profile白軸とキーキャップが必要個数分
2. Helix PCB 1セット（予備）
3. foobarのPCBと上下プレート 2セット
4. MinidoxのPCB 1セット
5. Let's Splitの作りかけ（はんだ付けミスで動かなくなったまま）

これらを動作させようと思い、まずはフルキット揃っているHelixを組み立てることにしました。このHelixのフルキット、なんと2年半前のHelixの共同購入（GB）の際のもので、自作キーボード界隈で「#Helix祭り」として盛り上がっていたものですが、そこからずっと眠らせていたと思うと申し訳なくて仕方がない....!!!

品名	個数	備考
PCB+ステンレスプレートセット	1セット	GBで購入
SMDダイオード	70個	GBで購入
OLED	2個	GBで購入
スプリングピンヘッダ	2個	GBで購入
ProMicro	2個	GBで購入
Kailh Low Profileスイッチ	70個	白軸をGBで購入
Kailh Low Profile用キーキャップ	1セット	GBで購入
TRRSケーブル	1本	なんでもよい
microUSB-USB-Aケーブル	1本	なんでもよい

というわけで早速組み立てていきます。

ビルドログ

photos.app.goo.gl

Helixには素晴らしいビルドガイドがあるのでそれを見れば手順はわかるのですが、自分が心配したのはこの2年半の間に遊舎工房実店舗が開店し、Helixの販売も定常的にされるようになったので、改善が多数行われビルドガイドが古くなってしまっているのではないか、という点です。

github.com

ありがたいことにHelixのビルドガイドはGitHubで公開されているので履歴が分かります。見てみると多少の改善があるものの2年半前からほぼ変わっていない！とりあえずこれを読み進めれば良さそうということで一安心です。

構成の選択

まず最初のセクションである構成の選択です。Helixは行数とバックライトのLEDの種類で手順や基板の形が変わるので、そこを再確認。

• 行数: 5 （すでに5行用のステンレスプレートを買ってしまっている）
• LED: アンダーグロー

LEDに関してはステンレスプレートなのでバックライトはちょっともったいないかなと思ったのと、アンダーグローであれば基板下面にあとから追加可能なこともあってこの選択にしました。アンダーグロー用のLEDテープはAliExpressで購入してまだ手元に到着していないのですが、その到着を待たずに使えるという利点もあります。GBの際に買ったSMDのLEDは予備用のPCBをアクリルプレートで作る際に使おうと思います。

ダイオード

ステンレスプレートなので内側は見えないからリードダイオードでも良かったんですが、どうも自分がGBしたときにSMTにしたかったらしくチップダイオードがたくさんあったのでSMTすることにしました。が、やはりSMTが本当に苦手なので、最初は大変苦労しました。

慣れてきたらスッスッとつけられるようになりましたが、部品がある一定上の小ささになると厳しいです。ハンダゴテのコテ先は2Cを使っているのですが、どうもランドを温めるのがやりづらい、というのが感想です。一通り実装できたのでよかったのですが、@mteiさんがS9のコテ先がつけやすいと動画をアップされてるのを見かけたので、ちょっと気になっています。

S9 のコテ先、使いやすい、、、 pic.twitter.com/kNuXp38Gfn

— m.tei / ishii (@mtei) 2020年8月4日

白光 こて先/S9型 T18-S9

SMTの際は片側のランドにフラックスを塗った後に、コテ先にハンダを盛っておいて、ペタペタと判子を押すようにランドを触っていったらうまく盛りハンダができました。

基板上での導通確認

導通確認をしないで失敗したことが何度かありSelf-Made Keyboards in Japan (SMKIJ)のdiscordで皆さんに助言をいただきながらテスターで確認をすることの大事さを痛感しているので、都度チェックです。ダイオードのはんだ付けがきちんとできているか確認します。

ProMicroが載る部分のオレンジの丸の部分にテスターの黒いプローブ、キースイッチのオレンジの丸の部分に赤いプローブを当てて導通ができてるかを確認し、上の段ではProMicroで1つ上のピン、その上の段ではProMicroでもう一つ上のピン、という具合に一段ずつ調べていき、すべての段で導通の確認を取りました。

TRRSジャックとOLEDソケットとタクトスイッチ

TRRSジャックとOLEDソケットとタクトスイッチは基板にマスキングテープで固定して普通にはんだ付け。

OLEDピンヘッダも、OLEDにマスキングテープで固定してからはんだ付け。

ProMicroのコンスルーへのはんだ付けとファームウェア焼き

これはコンスルーを基板に甘挿しした上でProMicroをコンスルーに載せてはんだ付けをすると楽でした。

ありがたいことにHelixではデフォルトキーマップでのビルド済みファームウェアをビルドガイドと同じレポジトリ内に公開してくれているので、QMK Toolboxを使ってサクッと書き込み。

ProMicroを搭載した上で入力テスト

ダイオードをはんだ付けした状態での導通確認ができているので、ProMicroのコンスルーへのはんだ付けとTRRSジャックの はんだ付け、コンスルーと基板の接触がすべてきちんと行われていれば、キースイッチの足の部分をショートさせるだけでキー入力ができるはずなのでその確認をします。

まず片手だけの状態でパソコンにつないで入力確認を行い、確認が取れたので、次は両手をTRRSケーブルでつないだ上で確認します。この状態ですべてのキーでの入力が確認とれたので、あとはキースイッチだけきちんとはんだ付けすれば完成です。

ステンレスプレートの絶縁

ステンレスプレートのキットには絶縁シートがついていたはずなのですが、どこを見ても見つからないので、無くしてしまったか手違いで入っていなかったか、もう2年半前なのでわかりません。いずれにせよ上のプレートが基板に触ってショートしなければいいので、絶縁をします。

念の為同じ絶縁シートがあればそれを購入しようと思いSMKIJで聞いてみたのですが特定には至らず、カプトンテープで絶縁するのが良さそうという話で、自分も代案がなければそうするのがいいだろうと思っていたので素直に地道にテープを貼っていきました。

とりあえず全部金属部分が隠れるようにテープを貼った後にデザインカッターで穴の部分を切り取っていくという作業はSMTと同じくらい面倒でした。地味に時間を食った作業です。

キースイッチのプレートへのはめ込み

いま絶縁したばかりのプレートにキースイッチをはめ込んでいきます。これがまた大変ではめ込むにはキースイッチ横の爪の部分を押し込みつつ上から抑えて嵌めるという力の要る作業にも関わらず、キースイッチの足の部分から押すと簡単に外れてしまうので気を遣いました。

キースイッチの基板へのはんだ付け

プレートの下側からキースイッチを押してしまうとプレートから外れてしまうので、プレートを上下逆さまにして置いた上で、基板を上からはめていく形にしたらうまく嵌められました。

ただそれでもOLEDやProMircoの部分が出っ張っていて、上から力いっぱいに押し込むわけにはいかないので、ある程度の数がはまったら指でキースイッチと基板を挟むようにしてはまりが浅いところをきちんと固定していきます。

それが終わったらあとはキースイッチのピンをはんだ付けするだけです。多くのキースイッチに対応するために結構キースイッチのピン用の穴が細かいので他のランドまでハンダが流れてしまわないよう、必要以上にハンダを付けず手早く行いました。

キースイッチはんだ付け後の導通確認

理論上はこれではんだ付けが必要な工程はおしまいです。*1この状態でキー入力が認識されるか再度確認します。

普通にキーボードとしてつないで、1つずつキー入力を行って確認完了。

最終組立

ビルドガイドにあるようにまずOLED用カバーをつけた後に上下プレートを固定し、キースイッチをつけて完成。キースイッチは傾斜が緩やかな方が手前側です。

完成です！この薄さでできたことは本当に満足です。

ホームポジション用突起

無刻印のキーキャップですべてのキーが同じ形のものだとホームポジションを目視なしで確認するのが難しいので、ホームポジション用の突起を付けます。これも2年半前に買っていた点字シールから突起一つ分を切り取って貼り付けました。

さすが点字用だけあって突起の大きさが完璧と感じられるくらい違和感の無いサイズです。

おまかせ点字シール(触知図編Ver.4)透明タイプ

おわりに

作ってみて、やはりHelixは突起部をなくそうと思えばSMTができ、実装が難しいと思えばリードダイオードが使え、4行でも5行でも使える、LEDはチップでもテープでも使える、OLEDが使える、とGB当時に手に入れられたキットの中では制作のしやすさと拡張性の高さで群を抜いていたと思います。その拡張性に惹かれ当時GBに参加したことを組み立てながら思い出しました。いろいろあって伸ばし伸ばしになっていたけれど、ようやく完成できてよかったです。*2

40%キーボードをしばらく使ってからHelixを使ってみるとかなりキー数が多く感じます。PCBがもう一組あるので、アクリルプレートを発注して、次は4行でかつバックライトで実装しようと思います。

本記事はHelixを使って書かれました。

*1:LEDテープは後日届いてから付ける予定

*2:LEDテープが届いたらアンダーグロー化しますが、とりあえず完成ということで

Google Compute Engineのインスタンスに自動でGoogle Cloud Operationsのエージェントがインストールされるようにする

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。今回は担当分野の新しい機能について紹介します。本記事はGoogle Cloud LoggingやGoogle Cloud Monitoringというものがなにかをすでに理解されている方向けに書いています。

TL;DR

Agent Policyを使うことで、Google Cloud LoggingとGoogle Cloud MonitoringのエージェントをGCEインスタンス作成時に自動でインストール＆起動させられるようになる。

Google Cloud Logging + Google Cloud Monitoring on Google Compute Engine

Google Cloud LoggingやGoogle Cloud MonitoringはGCPが提供するログとメトリクスに関するマネージドサービスです。Google Cloud Platform上の各種マネージド・サービスやインスタンスのシステムログ、監査ログ、システムメトリクスなどはバックエンドで自動で取り込まれ、これら2つのサービスで確認できます。またGoogle App EngineやGoogle Kubernetes Engineを始めとするランタイムではアプリケーションログやアプリケーションメトリクスなども自動で送られるように設定されています。

しかしGoogle Compute Engineのインスタンスではその性質ゆえに、アプリケーションログやアプリケーションメトリクスの取得のためにはGoogle Cloud LoggingやGoogle Cloud Monitoringの各種エージェントをインスタンス作成後に追加でインストール＆起動する必要がありました。

今回の新機能はその手間をAgent Policyという機能を使って無くそう、というものです。

Agent Policyの管理

cloud.google.com

本記事の内容は上の公式ドキュメントにあるものをそのままなぞっているだけなのですが、現時点でドキュメントが少しわかりにくい部分もあるので補足しながら追っていきます。

本機能は本記事執筆時点でAlpha版なので gcloud components ではalphaをインストールしておいてください。

$ gcloud components install alpha

権限周りの設定

まず下準備として権限周り（IAMなど）の設定をするのですが、いくつもの権限を設定しなければいけないので、それを一気に行ってくれる便利シェルスクリプトが用意されていますのでこれをダウンロードして適宜オプションを指定して実行します。

• https://cloud.google.com/stackdriver/docs/set-permissions.sh

ドキュメントにも書いてありますが、このシェルスクリプトを使って行うことは

1. Cloud Logging、Cloud Monitoring、OS Configの各APIの有効化
2. GCEのデフォルトサービスアカウントへの必要なロールの追加
3. OS Configメタデータの有効化
4. 指定したosconfigのIAMロールを指定したユーザーまたはサービスアカウントに付与

次の例は agent-install-test というプロジェクトで admin@example.com というユーザーに roles/osconfig.guestPolicyAdmin の権限を付与する場合の例

$ bash set-permissions.sh --project=agents-install-test --iam-user=admin@example.com --iam-permission-role=guestPolicyAdmin

Agent Policyの作成

上の準備ができたら　Agent Policyを作成します。次の例は ops-agent-debian というAgent Policyを作成する例です。 ルールとしてDebian 10のイメージでGCEインスタンスを作成する場合に、Cloud LoggingとCloud Monitoringのエージェントをインストールするよう指定します。

$ gcloud alpha compute instances ops-agents policies create ops-agents-debian \
  --agent-rules="type=logging,version=current-major,package-state=installed,enable-autoupgrade=true;type=metrics,version=current-major,package-state=installed,enable-autoupgrade=true" \
  --os-types=short-name=debian,version=10

これで Debian 10 のイメージでインスタンスを新規作成すると自動でCloud LoggingとCloud Monitoringのエージェントがインストールされ起動されるようになります。ほかにもGCEインスタンスに特定のタグが付いた場合の条件を設定するには --group-labels を指定すれば良いです。

cloud.google.com

テスト1: Debian 10のインスタンスを作成する

早速GCEインスタンスを作ってみます。まず条件に一致するDebian 10のインスタンスです。

$ gcloud compute instances create test0 \
  --image-project debian-cloud \
  --image-family=debian-10 \
  --zone=us-central1-a \
  --preemptible \
  --boot-disk-auto-delete
Created [https://www.googleapis.com/compute/v1/projects/agents-install-test/zones/us-central1-a/instances/test0].
NAME   ZONE           MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
test0  us-central1-a  n1-standard-1  true         XX.XX.XX.XX   XX.XX.XX.XX  RUNNING

$ gcloud compute ssh test0 --zone=us-central1-a
Writing 3 keys to /home/ymotongpoo/.ssh/google_compute_known_hosts
Enter passphrase for key '/home/ymotongpoo/.ssh/google_compute_engine':
Linux test0 4.19.0-10-cloud-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
ymotongpoo@test0:~$ sudo service google-fluentd status
● google-fluentd.service - LSB: data collector for Treasure Data
   Loaded: loaded (/etc/init.d/google-fluentd; generated)
   Active: active (running) since Tue 2020-08-11 08:50:36 UTC; 1min 17s ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 110 (limit: 4373)
   Memory: 66.9M
   CGroup: /system.slice/google-fluentd.service
           └─2128 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd --log /var/log/google-fluentd/goo

Aug 11 08:50:36 test0 systemd[1]: Starting LSB: data collector for Treasure Data...
Aug 11 08:50:36 test0 google-fluentd[2106]: Starting google-fluentd 1.7.1: google-fluentd.
Aug 11 08:50:36 test0 systemd[1]: Started LSB: data collector for Treasure Data.
ymotongpoo@test0:~$ sudo service stackdriver-agent status
● stackdriver-agent.service - LSB: start and stop Stackdriver Agent
   Loaded: loaded (/etc/init.d/stackdriver-agent; generated)
   Active: active (running) since Tue 2020-08-11 08:50:42 UTC; 1min 32s ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 13 (limit: 4373)
   Memory: 6.2M
   CGroup: /system.slice/stackdriver-agent.service
           └─2470 /opt/stackdriver/collectd/sbin/stackdriver-collectd -C /etc/stackdriver/collectd.conf -P /var/ru

Aug 11 08:50:42 test0 collectd[2469]: plugin_load: plugin "write_gcm" successfully loaded.
Aug 11 08:50:42 test0 collectd[2469]: plugin_load: plugin "match_regex" successfully loaded.
Aug 11 08:50:42 test0 collectd[2469]: plugin_load: plugin "match_throttle_metadata_keys" successfully loaded.
Aug 11 08:50:42 test0 collectd[2469]: plugin_load: plugin "stackdriver_agent" successfully loaded.
Aug 11 08:50:42 test0 collectd[2469]: plugin_load: plugin "exec" successfully loaded.
Aug 11 08:50:42 test0 collectd[2469]: plugin_load: plugin "aggregation" successfully loaded.
Aug 11 08:50:42 test0 stackdriver-agent[2449]: .
Aug 11 08:50:42 test0 systemd[1]: Started LSB: start and stop Stackdriver Agent.
Aug 11 08:50:42 test0 collectd[2470]: Initialization complete, entering read-loop.
Aug 11 08:50:42 test0 collectd[2470]: tcpconns plugin: Reading from netlink succeeded. Will use the netlink method

Cloud LoggingとCloud Monitoringのエージェントがインストールされて動いてますね！

テスト2: CentOS 8のインスタンスを作成する

今度は条件に合致しない、CentOS 8のインスタンスを作成してみます。

$ gcloud compute instances create test1 \
  --image-project=centos-cloud \
  --image-family=centos-8 \
  --zone=us-central1-a \
  --preemptible \
  --boot-disk-auto-delete
Created [https://www.googleapis.com/compute/v1/projects/agents-install-test/zones/us-central1-a/instances/test0].
NAME   ZONE           MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
test1  us-central1-a  n1-standard-1  true         XX.XX.XX.XX   XX.XX.XX.XX  RUNNING

$ gcloud compute ssh test1 --zone=us-central1-a                                                                  Writing 3 keys to /home/ymotongpoo/.ssh/google_compute_known_hosts
Enter passphrase for key '/home/ymotongpoo/.ssh/google_compute_engine':
[ymotongpoo@test0 ~]$ sudo service google-fluentd status
Redirecting to /bin/systemctl status google-fluentd.service
Unit google-fluentd.service could not be found.

[ymotongpoo@test0 ~]$ sudo service stackdriver-agent status
Redirecting to /bin/systemctl status stackdriver-agent.service
Unit stackdriver-agent.service could not be found.

こちらは各エージェントがインストールされていないことが分かります。

おわりに

本機能はまだAlphaですので、まだまだ変更の可能性が十分あります。たとえば、現状作成した ops-agents のポリシー一覧やその詳細は gcloud コマンドでしか確認できず、UIはありません。

cloud.google.com

また本機能がサポートされているのは Cloud Logging Agent と Cloud Monitoring Agent がサポートされているLinuxディストリビューションのイメージが使用された場合のみです。もし本機能を利用されていてなにか不具合や要望がありましたら ops-agent-policy-feedback@google.com まで直接連絡するか、もしくは @ymotongpoo まで連絡してください。

「フラッシュ・ボーイズ 10億分の1秒の男たち」読了

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。コロナ禍によって在宅勤務が増えるだけでなく外出の機会が減った結果、家での趣味が増えています。4月以降に増えた活動だけでも

• 読書
• 自作キーボードの調整・作成
• 園芸・家庭菜園
• 仕事部屋の整理・充実

などがあります。特に読書のペースは昨年と比べるとだいぶ上がり、図書館から常に本を借りている状態になりました。最近は金融・経済・西洋美術の本を読むことが多いのですが、先日読み終えた「フラッシュ・ボーイズ 10億分の1秒の男たち（原著題: Flash Boys: A Wall Street Revolt）」が金融系でありつつITが深く関連する話で面白かったので読書記録として残しておきます。技術書以外の記録を残すのは久々です。

フラッシュ・ボーイズ 10億分の1秒の男たち (文春文庫)

以降、本書のネタバレを含みます。

高頻度取引業者がどうやって儲けるのか

高頻度取引（High Frequency Trade; HFT）が隆盛したのは自分が思っていたよりずっとあとで、2000年代後半、とくにサブプライムローン問題の後でした。金融系のニュースを見ると度々HFTの話題が出ていたためなんとなくその存在は知っていたし、雰囲気で「HFTはマーケットメイク戦略と裁定取引で儲けている」ということは知っていたのですが、本書でその細かな実態を初めて知り、これはとんでもないことだと改めて認識しました。

HFT業者が行うマーケットメイク戦略は価格差がある反対売買を繰り返すことでトレンドを作り適切なタイミングで利ざやを稼ぐ方法、裁定取引は価格の動きが異なる市場間で反対売買を行い価格差で利ざやを稼ぐ方法ですが、どちらにおいてもいち早く情報を獲得することで大きな利益を生み出すことができるため、回線速度を高める（低レイテンシ）ことが最重要となります。サブミリ秒での取引ですべてが決まっていたため、もはやこれは彼らに取っては必須の条件でした。HFT業者は取引所までのレイテンシを下げるために専用回線の契約やコロケーションなどを行います。基本的に経路が最短になればレイテンシは一番低くなるため、第1章や映画で作っていた専用回線はそれを目的としてシカゴとニューヨーク（実際はニュージャージー）をとにかく真っ直ぐつないでHFT業者に高い利用料で貸し、大儲けしたという話でした。

さらにナスダックを始めとする公開取引所や、ダークプールと呼ばれる投資銀行などが運営する私設取引所（PTS）の一種でのコロケーションも、場所を貸す代わりに高い利用料を取り、取引所ではその利用料による収入も無視できなくなっていたようです。また取引所はHFT業者が多く来てくれるように、取引に応じて報奨金を払うなどの施策も行っているということも初めて知りました。こうして取引所がHFT業者との結びつきが切り離せない状態になっていて、各投資銀行が実際に運用を行うにあたっても常にHFT業者にフロントランニングされ、本来であればHFT業者がいなければ安く買えた、あるいは高く売れた株式が期待通りの額で取引できず、結果しわ寄せは各投資家（我々一般投資家含む）に来るという、実情を知ると看過できない状況でした。

IEXが成し遂げようとしたこと

こうした事実に気付いたのがカナダロイヤル銀行（RBC）のブラッド・カツヤマで、投資銀行が株式の取引を行う際に必要な数の株式を取得するために複数の取引所に発注をかけると各取引所に発注が届く時刻に時間差が生まれ、そこをHFT業者に突かれてしまうことに気が付き、時間差がなくなるように調整するソー（Thor）と呼ばれる取引プログラムを開発しました。これによりRBCだけでなく他の投資銀行にもソーの利用を呼びかけ、その過程で多くの投資家を味方につけていきます。

ソーの利用だけでは、その利用者だけしかHFT業者による搾取を免れることはできませんが、HFT業者が利益を取得する構造（高頻度取引を支えるReguration NMSと呼ばれる法律や、ダークプールに許される取引状況の非公開など）を健全化したいと考えたブラッドは、そのためには健全な取引所が必要で、かつそれが無視できない規模にならなければいけないと考え、IEXという取引所を立ち上げるに至ります。そこではHFT業者に有利になるような取引条件やルールを可能な限り排除して、コロケーションも認めず、アクセスするにはフロントランニングが不可能な距離にある中継所を経由しなければならないなど、徹底した公平性を目指しました。

立ち上げ直後にはHFT業者がいる状況を維持したい投資銀行などから嫌がらせを受けたりもしますが、本書の最後ではHFTによる利益を享受できないと判断したゴールドマン・サックスがIEXに協力し、結果IEXを取引所として維持していくのに必要な取引数を達成するに至って、今後の市場の健全化を願いつつ物語は終わります。

ゴールドマン・サックスとHFT

ゴールドマン・サックスはIEXを助けた一方で、そこに勤めていた優秀なロシア人エンジニアのセルゲイ・アレイニコフが同社を退職する際に、ソースコードの窃盗を行ったという理由で刑事訴訟し、結果セルゲイに懲役8年の判決がなされるに至り、実際セルゲイは刑務所で過ごすことになります。本書によれば、セルゲイはゴールドマン・サックス社内でHFT関連の対応をするために、社内の巨大なコードベースを整理しつつ、OSS製品にパッチを当てた上で社内で利用していて、そのパッチ込みのコードを退職の際に外部のコードホスティングサービスに置いたということで窃盗として訴訟された、ということになっています。

外部に置いたコードの大半がupstreamにあったものである上に、パッチを当てたものを還元するすることが許されなかったために行った行為であるにも関わらず、それをゼロから構築した機密事項であるかのごとく訴訟を起こし、最終的に覆されたとはいえ、懲役8年の実刑判決に至らしめたのは、ゴールドマン・サックスのHFTで利益を出しきれない焦りもあったのでしょう。

結果、HFT関連の牽引をしていた責任者が転職したあとの後任が自社の利益と倫理の両立が可能である市場の健全化に向かってIEXに肩入れしたのは、サブプライムローン問題でCDOを顧客に売りつつ、その暴落に賭けてCDSを買い、結果巨額の利益をあげたたった数年後というのはなんとも皮肉だと感じました。*1

HFTと日本市場

日本でも東京証券取引所を始めとするJPXが2010年にシステムを刷新し、高頻度取引などを行うインフラを整え、実際にコロケーションサービスを提供したりしています。

www.jpx.co.jp

研究者の報告によれば、2017年現在においては日本におけるHFTの状況は東証が主で、米国と違いダークプールでの取引量はほとんどないとのことですが、iDeCoやNISA、401kの推進などが進められているので今後どうなっていくのかは個人的に大変気になります。本書で書かれているような状況とは違い、日本ではHFT業者は金融庁への届け出をしなければならず、また今年8月（今月！）にダークプールに対してより多くの情報を公開するような規制が入るということで、せっかくこうした話題も理解できるようになったので、動きを追っていきたいと思います。

余談ですが、金融庁やJPX関連の情報を検索すると、検索上位がPDFファイルへのリンクだらけになり、PDFを除いてしまうと1次情報が壊滅的になくなってしまうので、モチベーションが無いのは分かりますが、金融関係者のみなさまにおかれましては、ウェブサイトに直接情報を掲載してくださいますよう、お願いいたします。

映画版との違い

本書「フラッシュ・ボーイズ」は一昨年「ハミングバード・プロジェクト 0.001秒の男たち（原作題: The Hummingbird Project）」というタイトルで映画化され、昨年日本でも公開されました。

夢のプロジェクト発案は偶然? それとも運命!?／映画『ハミングバード・プロジェクト 0 001秒の男たち』本編映像

映画は観ていないのですが、トレーラー映像や観た方が紹介しているあらすじを読む限り、本書の第1章に書かれていた内容を広げたもののようで、本書の本筋とは違う内容になっているようです。映画版は超高頻度取引（HFT)業者のために高速（低レイテンシ）回線の敷設を行う話にとどまっているようですが、本書ではその話は話の入り口でしかなく、本筋は上に述べたようにHFT業者のために投資家が不利益を被っているいう事実とダークプール含め取引所がHFT業者の活動を許すことで利益を上げているために是正していないこと、それを正すために立ち上がったブラッドの奮闘という、勧善懲悪物になっています。

マイケル・ルイスの著作

マイケル・ルイスは金融系ノンフィクション作家・ジャーナリストとして有名で、本書以外にも「マネーボール（原著題: Moneyball: The Art of Winning an Unfair Game）」「世紀の空売り（The Big Short: Inside the Doomsday Machine）」といった著書がそれぞれ映画化され、映画も含めて大きな話題となりました。

マネー・ボール〔完全版〕

世紀の空売り―世界経済の破綻に賭けた男たち (文春文庫)

自分はマイケル・ルイスの著作を本で読むのは初めてで、「マネー・ボール」も「世紀の空売り」も映画でしか観ていませんでしたが、これを機にこれらの原作や他の著作を含めて読んでみようと思います。

追記 (2020/08/03 12:45): セルゲイ・アレイニコフとErlang

記事を公開したら力武さんが次のように教えてくれたので調べてみました。

Sergey AleynikovはErlangの人としても有名。

— Kenji Rikitake (@jj1bdx) 2020年8月3日

Wikipediaを見るとたしかにErlang製OSSに数多く貢献していた旨記載があります。

He authored a telecommunications patent and contributed to a number of open-source Erlang and C++ projects. He also published several Perl modules on CPAN.

Wikipediaにもリンクがありますが、ZeroMQのErlangバインディングを書いたのは彼で、実際ZeroMQのorganizationを見ると、彼が書いたバインディングのフォークが公式となっています。（@saleynが彼のGitHubアカウント）

github.com

他にもErlangコミュニティのメーリングリストで彼の無罪確定のニュースがスレッドになるくらい有名であったことが伺いしれます。　

erlang.org

関連書籍

本書の中でいくつか面白そうな書籍が参照されていたので、そちらも読んでみたいと思いました。

ウォール街のアルゴリズム戦争

Broken Markets: How High Frequency Trading and Predatory Practices on Wall Street Are Destroying Investor Confidence and Your Portfolio (English Edition)

参照

• 裁定取引 - Wikipedia
• 高頻度取引 - Wikipedia
• コロケーション｜証券用語解説集｜野村證券
• IEX - Wikipedia
• 投資業界を根底から変える、ブラッド・カツヤマの挑戦 | Forbes JAPAN（フォーブス ジャパン）
• THOR (trading platform) - Wikipedia
• Regulation NMS - Wikipedia
• 「コードは財産にあたらず」：ゴールドマンサックス問題で米連邦裁が見解 | WIRED.jp
• アメリカは100年に一度の金融危機か ―リーマン・ブラザーズの破綻は金融恐慌の引き金となるか―（国際文化学科 教授：河内 信幸） 国際関係学部 中部大学
• コネクティビティサービス | 日本取引所グループ
• 東証アローヘッド｜証券用語解説集｜野村證券
• 日本における高頻度取引(High Frequency Trading)の現状について (日本証券業協会)
• PDF 現物市場の機能強化に向けたアクションプログラム（参考資料）

*1:サブプライムローン問題の際にはそれだけでなく、CDSを売っていたAIGの株の空売りもして二重で儲けていたのがなんともえげつない

Goのソースコード内のトリビア

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。Google Cloud Operationsもさることながら、Go Conferenceの運営など、長らくGoコミュニティに関わってきましたが、まだまだ知らないことがあったということを昨日今日で知ったので共有します。

time.minWall

time.minWall という値があります。

• src/time/time.go - go - Git at Google

const (
    hasMonotonic = 1 << 63
    maxWall      = wallToInternal + (1<<33 - 1) // year 2157
    minWall      = wallToInternal               // year 1885
    nsecMask     = 1<<30 - 1
    nsecShift    = 30
)

これは time パッケージ内で時刻の起源を設定するための定数値なのですが、これが1885年に設定されているわけです。1900年とかならまだしも、なぜ1885年なのかという疑問が湧いてきます。実際これは自分が気付いたわけではなく、友人の @la_luna_azul がふとしたときに疑問に思っていたのを見て調べてみたら、自分もよくわからなかったわけです。

1885年といえば、思いつくのはBack To The Future 3で過去に戻ったときの年です。偶然の一致とはいえ、この年をわざわざ指定するということは少なからずその影響があったのでは？という期待が湧いてきます。実際、この定数値を決めるにあたっての理由になりそうな記録を探してみると以下の2つが見つかりました。

github.com

ここでRuss Coxは次のように回答しています。

OK, this is checked in for Go 1.9. I moved the internal epoch to 1885 (max year 2157) to avoid any possible problem with NTP-epoch-derived times. I also adjusted the design doc to reflect this change and some minor encoding changes.

Thanks for the constructive conversation everyone.

しかし、ここでは1885年に設定したという事実は書いていても、その根拠は書かれていません。Go 1.9でepochのデフォルトを1885年にしたと書いてあるので、そのproposalがあるはずです。探してみると次のproposalが見つかります。

go.googlesource.com

ここでは次のようにコメントされています。

Unix-based systems often use 1970, and Windows-based systems often use 1980. We are unaware of any systems using earlier default wall times, but since the NTP protocol epoch uses 1900, it seemed more future-proof to choose a year before 1900.

なるほどepochがいろいろあるけれど、とりあえず1900年より前にしておけば良さそうだからそうしたと。しかし、そこでわざわざ1885年に設定する理由はありません。もう自分の中では「もうBack To The Futureの年というイースターエッグなんでしょ！」と思ってはいたんですが、やはり確証は欲しいものです。こういうものは聞いてしまうのは無粋かもしれないし、知ったところでなんになるわけではないけど、もう知りたくてたまらない！！

そこでRuss Coxにメールしてみました。するとすぐに返事が返ってきました。

Yes, people talked me into moving it back before 1900, and 1885 was the obvious choice due to its historical significance to Hill Valley, California. :-)

やっぱりBack To The Futureだったのか！！なんかスッキリした！！

http.aLongTimeAgo

こんな質問に答えてくれるRuss Coxは優しいなあと思っていたら、話はこれで終わりではありませんでした。先の返信に続けて、次のような返事があったのです。

See also http.aLongTimeAgo, which is now sadly set to time.Unix(1, 0) but used to be time.Unix(233431200, 0).

• src/net/http/http.go - go - Git at Google

// aLongTimeAgo is a non-zero time, far in the past, used for
// immediate cancellation of network operations.
var aLongTimeAgo = time.Unix(1, 0)

たしかにこれはいま time.Unix(1, 0) になっています。昔はどうだったんでしょうか。Go 1.8でこの定数が導入されたので見てみると

• src/net/http/http.go - go - Git at Google

// aLongTimeAgo is a non-zero time, far in the past, used for
// immediate cancelation of network operations.
var aLongTimeAgo = time.Unix(233431200, 0)

このepoch秒が表す日付はいつなのでしょうか。見てみましょう。

1977年5月25日です。"A long time ago"とこの年が紐づくものといえば....

Star Warsしかありませんね！！！これの第1作目、Episode IVの公開日を見てみましょう。

ja.wikipedia.org

ドンピシャでした。実際にこれはどのように使われているかというと、コメントにあるようにネットワークの操作を即座にキャンセルするためにわざとありえない過去の時間を指定することで接続をキャンセルさせるというときに使われます。Go本体のコードだと次のように出てきます。

cr.conn.rwc.SetReadDeadline(aLongTimeAgo)

デッドラインを過去に設定することで強制的にキャンセルさせるわけです。

おわりに

こういうようなちょっとした遊び心は自分でプログラムを書いているときにも入れたくなるわけですが、そういう仲間内のおふざけみたいなものを垣間見れるとより親近感が湧いてくる気がします。これからもこういう発見ができることを楽しみにしています。

おまけ

この記事を書くにあたって、一応Russ Coxに「公開してもいいですか？」と聞いたら

Feel free. No secrets here.

という返事をくれました。隠してはないけど表には書かない、遊び心を感じる回答でした。

おまけ2

mattnさんが、http.aLongTimeAgo に関してついた line comment を見つけてくれました。

「この変な数字は何？。誕生日？」「スターウォーズの上映が開始された日だよ。」 / “net, net/http: adjust time-in-past constant even earlier · golang/go@698…” https://t.co/kexk9XGqX1

— mattn (@mattn_jp) 2017年4月9日

github.com

Claw44を使い始めた #claw44

はじめに

こんにちはStackdriverあらためGoogle Cloud Operations担当者です。先日Caravelle BLEを作って使い始めて絶好調だったのですが、諸事情で2台のマシンを使わねばならず、そうなるとBLE接続のキーボードだと不便だということになり、有線の40％キーボードを作ろうと思い立ち、Claw44を注文しました。

yushakobo.jp

用意したもの

• Claw44 製作キット
  • 自分はBOOTHで買ったんですが、遊舎工房のほうが安定供給されている感じがあります
• OLED
  • 遊舎工房より購入
• Kailh Speed Burnt Orange 50個
  • 遊舎工房より購入
• OEMプロファイルキーキャップ
  • ひとまずCaravelle BLEのを外して使用
• TRSケーブル
  • Awinnerオーディオステレオケーブル 3.5mm 両方L型 90度 オスオス 極スリム iPhone Xperia Arrows Galaxy Aquos Urbano Huawei対応 スマホ タブレット MP3 AUX用 (0.5M)
• micro USBケーブル
  • Pro Microのmicro USB端子はもげやすいので、以前買ったマグネット式のケーブルを用意
  • こういうの → Ewise マグネット 3in1 充電ケーブル 1mx2本 360度回転 防塵 Android iPhone MicroUSB TypeC 対応 3A 急速充電 データ転送 QC3.0 (2本セットシルバー)

ビルドログ

Caravelle BLEに続いて、今回も大したビルドログはなく、素晴らしいビルドガイドを参考にしたらあっさりできました。

yfuku.com

以下、作業中の諸々の感想です。

• キースイッチソケットの取り付けのとき、押し付けながら盛りハンダを溶かすと「ポコッ」とソケットが穴にはまりながら固定されるのが気持ちいい
• OLEDはソケットに挿すと片持ちでの固定になるので、ソケットに挿しても普通にグラグラ動くから不安になる
• スペーサーに脱落防止用の輪っかをはめるのが地味に大変だった
• キーキャップの付け替えで外そうとすると、キースイッチごと取れてしまって面倒なことが多い
• ファームウェアの書き込みでちょっと手間取った
  • 最初メインで使っているWindows機でやろうとしたけどWSL使わないワークアラウンド探して結局やめた
  • サブのLinuxマシンでDocker動かしたら一発で簡単にできた
  • おとなしく qmk_firmware のレポジトリのスクリプト を使うのが良い
  • 自分の場合 $ ./util/docker_build.sh claw44:ymotongpoo:avrdude

できた

Tentatively finished. I should get better set of keycaps. #claw44 pic.twitter.com/TfrVX7nzc2

— Yoshi Yamaguchi ⌨ Keyboard builder (@ymotongpoo) 2020年7月11日

作者のオススメが3Dキーキャップだったので、OEMプロファイルのキーキャップでのフィット感はどうかなと思ったけど、普通にいい感じに収まってくれました。またPCBがプレート内にかなりコンパクトに収まってくれているので、非常にスッキリとしているのもいいですね。キーキャップはいまAliExpressに発注しているDSAプロファイルのものが来たら、そちらに付け替えようかなと思っています。

今後

Caravelle BLEのデフォルトキーマップが良かったので、そのときに自分用に少しカスタマイズしたものをベースに、Caravelle BLEから減った4キー分をうまく割り当てた結果、だいぶキーマップがこなれた感じになって、しばらく40%キーボードはこれをベースにしていこうかな、という感じです。

使い始めてみると小指のスタッガードが思ったよりも下がっていて、慣れるのに少し時間がかかりそうです。こういったキーボードは個人の手の形に大きくフィット感が左右されるので、しばらく使ってみてフィット感がいまいちだった場合には、もしかすると来月あたりにまた別のキーボードを作り始めているかもしれません。

またファームウェアではデフォルトでOLEDに押したキーを表示しますが、セキュリティ観点で決して良くはない、というか完全に問題があるので、現在のレイヤーを大きく表示するような動作にしたいと考えています。ただ、OLEDをいじるためにファームウェアを適当にいじると文鎮化する可能性があるので、うまいことテストする方法を知りたいです。

おわりに

Caravelle BLEと違いダイオードとICのコンスルーのはんだ付けがあったので、もうちょっと時間がかかるかと思いましたが、就寝前の数時間で2日間であっさり完成してくれました。作者の @yfuku_ さん、良い基盤を作ってくれてありがとうございました。