分割HHKB配列が実現できる自作キーボードキットChoco60を買った

はじめに

　素晴らしいキットを制作，販売しておられるrecompile keysさん，自作キーボード関連の製品を手広くてがけておられる遊舎工房さんに感謝します．

というわけで完成しました．Choco60です． pic.twitter.com/PUYkQRueme

— 院生 (@pudding_info) November 4, 2019

Choco60とは？

　recompile keysさんが今年開発された自作キーボードキットで，特徴としては以下の点が上げられます．

• CherryMX互換キースイッチ対応の62キーの分割キーボード
• HHKBをそのまま分割したような配列
• アンダーグロー非対応
• アクリルプレートサンドイッチマウント

詳細は以下の記事をご覧ください．

recompile.net

最上段の配列を削った40%キーボードのCocoa40という姉妹モデルもあります．

recompile.net

どこで買える？

　遊舎工房で委託販売されています．また，イベントへの出展時に少数頒布されている場合もあるようなので，公式のTwitterアカウント（@recomplie_keys）をフォローするのが良いと思います．

yushakobo.jp

売り切れになっていることが多い人気のキーボードキットですので，欲しい人はTwitterアカウントをフォローしてツイートの通知をオンにしておくと良いと思います．

なぜChoco60？

　以前まではMint60を使用していました．

poyo.hatenablog.jp

これはこれで大変良いキーボードキットで，一番最初にこれを経験できたのは大変幸運だったと感じています．しかし，上の記事中でも言及しているように，バックスラッシュやチルダ，バックスペースの位置がデフォルトだと合わず，HHKBライクにキーマップを変更して使って居ました．物理的に右上のキー数が足りないため，

• HHKBのESCの位置にチルダ
• ESCはAの横のコントロール単押しで対応
• 通常のUS配列のバックスラッシュとバックスペースを入れ替え

という様な使い方をしていたため，しばらくHHKBを触った後に戻ってくると，混乱してESCの代わりにチルダとか，チルダの代わりにバックスラッシュとかを乱発したりするようになってしまいました*1．

　研究室ではMint60，バイト先と家ではHHKBを使って居るため，できればHHKBに合わせたいところです．

• 耐久性と信頼性の観点から，仕事で使う道具はHHKB ProfessionalのUS配列が良い（Type-Sだとなお良い）
• でも分割キーボードは身体が楽なのでプライベートではなんとかしたい
• HHKBを単に二つ並べても，Fnがもう片方には伝播しないので難しい
• じゃあ分割キーボードでHHKB配列だ！

となるのは当然の流れだと思います．地味にHHKB配列は通常のUSともそこまで大きく乖離しないので，MacBookを使っても，ESCやチルダなど一部のキーを除けばちゃんと打てるのも個人的にはポイントが高いです．

キースイッチやキーキャップなど

　recompile keysさんが技術書典で頒布された冊子Learning Custom Mechanical Keyboardを参考に，個人的にはリニアよりもタクタイルの方が好みだったため，以下の様な選択になりました．全て遊舎工房で購入することが出来ます．

• キースイッチ：ZealPC Zilent V2 62g
  • ハウジング等の潤滑：Tribosys 3203
  • スプリングの潤滑：Krytox GPL 105

キーキャップは当初JTK HyperFuseを検討していたのですが，お金が無くて手が出ず，次点で検討していた以下のキーキャップと同等の物が遊舎工房の店舗にあったのでこれを購入しました．

talpkeyboard.stores.jp

キースイッチの潤滑

　具体的な方法は下記の記事が大変参考になります．

keys.recompile.net

　キースイッチオープナーは下記の物を注文しました．

make.dmm.com

素材はMJFのPA12GBです．エクスプレスサービスを利用したので通常注文はわかりませんが，注文してから4日目に手元に届きました．

初めてDMM makeのお世話になったんだけど，綺麗なもんだなぁ．
キースイッチオープナーです． pic.twitter.com/OsqWPMh0ml

— 院生 (@pudding_info) November 2, 2019

後はAmazonでマイクロアプリケーターを買いました．ルブステーションは使用しませんでした．感想としては「これを1日でやりきるスケジュールにした自分をひっぱたきたい」です．

ホームポジションの目印を作る

　このキーキャップはFキーとJキーの位置に触って分かる目印が付いていません，個人的にはかなりこれに頼っているところがあるため，自作することにしました．

　作り方は道具さえあれば難しくなく，UVレジンとUV照射器を使い，FキーとJキーに少しだけレジンを垂らして固めるだけです．少なくとも頑張って剥がそうとしてもびくともしない，くらいには頑丈になります．耐久性はこれから評価します．

UVレジンを借りてホームポジション用の目印を作った．ちゃんと固まると爪でガリガリやっても取れないし良さそう． pic.twitter.com/1yLTIIUY7t

— 院生 (@pudding_info) October 31, 2019

遊舎工房の店舗では他に

• 瞬間接着剤とラインストーンを使う
• 虫ピンを熱して刺す

などを紹介していただけました．ありがとうございます．

作り方

基本的には以下のサイトの通りです．キットにも特に説明書等は付属しないので，これを見てさっぱりわからんという人には難しいと思います*2

keys.recompile.net

1. ダイオードを基板に刺す

基板とダイオード

　キットの中身からまずは基板とダイオードを取り出します．適当にニッパで切りながら，基板に刺していきます．僕は指で適当に曲げながら差し込んでいきましたが，汚いので出来ればリードベンダー*3とかを使った方が良いです．

　また，基板から浮いてしまうとスイッチと干渉するため，足を折り曲げるだけでなく，マスキングテープを使って固定した方がやりやすいです*4．足を先に切る派，半田付け後に切る派がいるらしいですが，どちらの場合でもニッパは小さい方がやりやすいです*5．

全てのダイオードを半田付けした様子

2. TRRSジャックとリセットスイッチのはんだづけ

　本家の説明が少しわかりにくいのですが，Choco60というロゴのある方が表面で，recompile keysというロゴのある方が裏面になります*6．ダイオードは表面から付けて，裏面からはんだ付けしたことになります．

TRRSジャックは裏面から付けて表面からはんだ付けする

リセットスイッチも同様に裏面に付けて表面からはんだ付け

3. スタビライザーを装着

　これは絶対lubeした方が良いことが経験的に分かっているので，少し過剰なくらいlubeしました．高い潤滑剤を使うともったいないので，Super lubeで十分です．それ以外には特に工夫はしていません．

左右のシフトとスペースキーにスタビライザーを付ける

4. 表側アクリルプレートを装着

　先に表になるアクリルプレートを装着するのですが，順番的に先に3mmのスペーサーと8mmのネジをアクリルプレートに固定すると楽です．

小さい方が3mmのスペーサー

短い方のネジでは明らかに長さが足りないのですぐ気付くと思います．長い方のネジを使って固定します．

表側アクリルプレートにネジとスペーサーを固定

これを基板の表面側（ダイオードのある側）から，各ネジの位置を合わせてはめ込み，裏側から長い方のスペーサーで固定します．無理に硬く締めると割れる可能性があるので，対角線上から順に少しずつ締めましょう．

アクリルプレートをはめた様子

5. キースイッチをはめ込んではんだ付け

　少し押し込んで固定することになるのですが，このときアクリルプレートを一緒に押し込まないように注意しましょう．割れます．

全ての位置にキースイッチをはめる

　後は裏面からはんだ付けするのですが，このときキースイッチが浮き上がっていないか確認しましょう．キーキャップを付けたとき，仕上がりが凸凹になってしまいます．

6. ProMicroをはんだ付け

　最近のChoco60にはコンスルーが付属しているのでこれに準拠します．

基板にコンスルーを刺す

　ProMicroを裏向けにしてかぶせます．スペーサーの高さから分かるとおり，かなりギリギリです．少し浮かせてしまうと，簡単に干渉します．気をつけてはんだ付けしましょう．

ProMicroを裏向きにしてはんだ付け

7. ボトムプレートを装着

　裏面からボトムプレートを装着し，ゴム足を貼り付けます．僕はコンスルーのピンとボトムプレートが少し干渉してしまい，若干たわんでいます．締める際は対角線上から順に，少しずつ締めていき，大丈夫か確認しましょう．

裏面アクリルプレートとゴム足を装着

8. キーキャップをはめる

　裏返して全てのスイッチにキーキャップを装着します．今回のキーキャップセットには合うスペースキーがなかったため，Shiftで代用しています．「-」と「=」が入れ替わっているのはこれを書いている最中に気付いて直しました…

完成！

ファームウェアを書き込む

　Mint60はデフォルトでファームウェアが焼かれたProMicroが同梱されていたのですが，こちらは自分で書き込んでからで無いと動作確認もできません，幸いビルド環境を持たない人のために，デフォルトのhexファイルが頒布されているので，こだわりのない人はこれを使いましょう．

https://qmk.fm/compiled/choco60_default.hex

Dockerでビルド

　前回の記事から少し更新があり，QMKが公式のDockerコンテナを出しました．少し使い勝手が違うので，紹介します．

# 自分でキーマップを書く人向け
$ git clone --recurse-submodules https://github.com/qmk/qmk_firmware
# 適当にキーマップを書く
$ KEYMAP_NAME=キーマップ名
$ cp -r qmk_firmware/keyboards/choco60/keymaps/default qmk_firmware/keyboards/choco60/keymaps/${KEYMAP_NAME}
$ vim qmk_firmware/keyboards/choco60/keymaps/${KEYMAP_NAME}/keymap.c
# Dockerコンテナにクローンしたリポジトリをマウントしてビルドする
# qmk_firmwareディレクトリまでの絶対パスを自分の環境に置き換える
$ docker run --rm \
    -v $PWD/qmk_firmware:/qmk_firmware \
    qmkfm/qmk_firmware \
    make choco60:${KEYMAP_NAME}
# .hexファイルができる
# ls -l | grep hex
-rw-r--r--    1 pudding  staff  45333 Nov  4 13:50 choco60_pudding.hex

avrdudeで書き込み

　最初に，macOS Catalinaの人はこちらを読んでください．

poyo.hatenablog.jp

それ以外の人は，普通にavrdudeで書き込みが出来ます．裏面のリセットスイッチを押し，以下のコマンドを実行します．

$ sudo avrdude -p atmega32u4 -c avr109 -U flash:w:choco60_${KEYMAP_NAME}.hex

使ってみた感想

普段の作業風景

　やはり慣れている配列というのは素晴らしく，新しいキーボードなのにすぐに手に馴染みます．キースイッチをタクタイルにしたのも個人的にはかなり正解だったと感じていますし，リニア軸に馴染めなかった人は検討してみると良いのではないでしょうか．作る上でもそんなに難しい箇所はなく，作りやすいキットだったと感じています．lubeしたり，macOS Catalinaでファームウェア書き込みするために調べまくっていた時間の方が，はんだ付けしている時間よりはるかに長かったです．
　本当は家用にもう一台欲しいのですが，これ一台を作るために（いくら諸々の初期投資費用がかかっているとは言え）既にHHKB Professionalを2台くらい買える金額になり始めているので，ちょっと難しそうです．

まとめ

• 写真はちゃんとミラーレス一眼で撮れば良かった…
• Choco60はHHKBをそのまま左右に分割したような自作キーボード
• 作る上で難しいところは特になく，初心者でもおすすめできる
• macOS Catalinaはまだちょっとやめておいた方がいい

この記事はChoco60 + Zilent V2 62gで書きました．もう少し軽いタッチでも良かったので，リーフもlubeして良かったかも．

---

*1:Vimmerとしては致命的

*2:そんな人おるんか…？

*3:決まったピッチで綺麗に折り曲げられる道具． https://www.amazon.co.jp/dp/B00J3E11VQ/ref=cm_sw_r_tw_dp_U_x_bf6VDbEJQT8E

*4:僕は手元に無かったので，ダイオードをまとめているテープ（写真の白と赤のテープ）を剥がして使いました．明らかにこれはバカなので，マスキングテープくらい用意しましょう．

*5:僕はデカいニッパで基板に傷を付けました

*6:これはもしかしたら初期ロットと少し違うかも知れません

macOS Catalinaでavrdudeを使ってProMicroに書き込もうとするとprogrammer is not respondingというエラーが出る

はじめに

　これは2019/11/4現在の情報です．macOS10.15よりも新しいバージョンでは当てはまらない可能性があります．何か更新があれば，コメントを頂けると幸いです．

何が起きた？

　QMK Firmwareを知らない自作キーボード界隈は居ないと思いますが，ファームウェアを

1. Docker環境でビルド→avrdudeを直接叩いて書き込み
2. make キーボード名:キーマップ名:avrdudeでビルド & 書き込み

のどちらの方法でも，ProMicroに大して書き込みが出来なくなってしまいました．具体的には下記の様なエラーが出ます（Docker環境でビルドしたhexファイルを書き込もうとしていました）．

$ sudo avrdude -p atmega32u4 -c avr109 -P /dev/tty.usbmodem142101  -U flash:w:.build/choco60_pudding.hex

Connecting to programmer: .avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding

avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: ser_drain(): read error: Device not configured
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
Found programmer: Id = ""; type =
    Software Version = .; Hardware Version = .
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: buffered memory access not supported. Maybe it isn't
a butterfly/AVR109 but a AVR910 device?
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: leave prog mode
avrdude: ser_send(): write error: Device not configured
avrdude: ser_recv(): read error: Device not configured
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: exit bootloader
avrdude: ser_close(): can't reset attributes for device: Device not configured

avrdude done.  Thank you.

最初はリセットスイッチの押し忘れ・タイミング外れなど色々と検討しましたが，最終的に下記のIssueにたどり着き，Catalinaの問題であることが分かりました．

github.com

純粋にOS側での問題があるらしく，QMK Firmwareやavrdude側でどうにかすることが難しい事が伝わってきます．が，コメントでVirtualBox経由だと上手くいったといった内容が見受けられるので，じゃあVagrantでビルド環境ごと隔離すれば良いじゃんと思い，試してみました．

環境

以下の様な環境で試しています．

• macOS Catalina 10.15
• Homebrew 2.1.15
• avrdude version 6.3
• Vagrant 2.2.5
  • vagrant-vbguest 0.20.0
• VirtualBox 6.0.14r133895
  • VirtualBox Extension Pack 6.0.14

手順

1. QMK Firmwareをクローン

　forkして使っている人や，既にローカルに持っている人はそれぞれ自分の環境に置き換えてください．最終的にローカルにリポジトリがあり，そのパスが分かれば良いです．ここでは適当にユーザのホームディレクトリ以下にcloneしたとして以降の手順を行います．

$ pwd
/Users/ユーザ名
$ git clone --recursive https://github.com/qmk/qmk_firmware

2. VagrantとVirtualBoxのインストール

　Homebrew Caskでインストールします．Extension Packとバージョンを合わせる必要があります．もしVirtualBoxだけ先にインストールしており，Extension Packのインストールに失敗する場合，先にbrew cask upgrade virtualboxする必要があるかも知れません．

$ brew cask install \
    vagrant \
    virtualbox \
    virtualbox-extension-pack

Guest Additionsの自動更新プラグインをインストールします．

$ vagrant plugin install vagrant-vbguest

Guest Additionsを更新する

$ vagrant vbguest

僕はこの辺りで一度再起動を挟みました．

3. ProMicroデバイスの情報を確認

　USBケーブルでProMicro（を実装した自作キーボード）とMacを接続します．VirtualBoxではUSBデバイスを仮想環境から扱うために，パススルーを許可するデバイスをホワイトリスト方式で許可する必要があります．そのためにプロダクトIDやベンダーIDを控える必要があります．VboxManageコマンドを使って確認します．

$ VBoxManage list usbhost
Host USB Devices:

UUID:               b8bdff28-b707-43f1-8340-51e9943f74f7
VendorId:           0x2341 (2341)
ProductId:          0x8037 (8037)
Revision:           1.0 (0100)
Port:               1
USB version/speed:  0/Full
Manufacturer:       Arduino LLC
Product:            Arduino Micro
Address:            p=0x8037;v=0x2341;s=0x000008828f96a793;l=0x14210000
Current State:      Busy

# 以下略

VendorIdとProductIdをメモります．次に，リセットスイッチを押して書き込み可能状態にします．このとき，ProductIdが変化するので，これもまたメモります．

$ VBoxManage list usbhost
Host USB Devices:

UUID:               b8bdff28-b707-43f1-8340-51e9943f74f7
VendorId:           0x2341 (2341)
ProductId:          0x0037 (0037)
Revision:           0.1 (0001)
Port:               1
USB version/speed:  0/Full
Manufacturer:       Arduino LLC
Product:            Arduino Micro
Address:            p=0x0037;v=0x2341;s=0x000008828f96a793;l=0x14210000
Current State:      Busy

# 以下略

これを次の手順でVagrantfileに記述します．

4. Vagrantfileを用意

適当なディレクトリ（ここでは$HOME/qmk_vagrantとする）に，以下の内容をVagrantfileとして配置します．

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|

  config.vm.box = "hashicorp/bionic64"
    
  config.vm.provider "virtualbox" do |v|
    # USBデバイスのパススルーを許可
    v.name = "VM to flash firmware into ProMicro"
    v.customize ["modifyvm", :id, "--usb", "on"]
    v.customize ["modifyvm", :id, "--usbehci", "on"]
    # 以下にパススルーを許可するデバイスの情報（vendoridとproductid）を書く
    # nameは単に識別のためなので特に気にしないで良い
    v.customize ["usbfilter", "add", "0",
                 "--target", :id,
                 "--name", "Arduino Micro (writable)",
                 "--vendorid", "2341",
                 "--productid", "0037",
                 "--remote", "no"]
    v.customize ["usbfilter", "add", "1",
                 "--target", :id,
                 "--name", "Arduino Micro",
                 "--vendorid", "2341",
                 "--productid", "8037",
                 "--remote", "no"]
  end

  # ここを環境に合わせて書き換える
  config.vm.synced_folder "/Users/ユーザ名/qmk_firmware", "/qmk_firmware"
  config.vbguest.auto_update = true

  # avrdudeとQMK Firmwareのビルドツール一式を揃える
  config.vm.provision "shell", privileged: false, inline: <<-SHELL 
    sudo apt-get update
    sudo apt-get install -y python3-pip avrdude
    /qmk_firmware/util/qmk_install.sh
   SHELL
end

5. ProMicroをMacから抜く

　USBケーブルで繋いでいたProMicroを抜きます．その方が安定しました．

　おそらくmacOS側でビジーだと，VirtualBoxのゲストOS内にうまくマウントできないのだと思います．

6. vagrant upで仮想環境を起動

　前の手順で用意したVagrantfileのあるディレクトリで以下のコマンドを実行します．

$ vagrant up

これで無事仮想環境が起動するのを待ちます．色々なインストールを含むので，多少時間がかかります．起動したらsshして仮想環境へ接続します．

$ vagrant ssh
# USBデバイスを確認
(guest) $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

7. 再びUSBで接続し，書き込む

　再びUSBケーブルでMacとProMicroを接続します．以降の手順ではリセットスイッチを押す度にゲストOSが一瞬止まったように感じます．操作は反映されるので，焦って適当にコマンドを打たないようにしましょう．

　リセットスイッチを押して書き込み可能状態にしてlsusbしてみます．

(guest) $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 2341:0037 Arduino SA
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

/dev/ttyACM0が見えれば成功です．割とすぐ消えてしまうので，見えなくても焦らず再びリセットスイッチを押しましょう．

(guest) $ ls -l /dev/ttyACM0
ls: cannot access '/dev/ttyACM0': No such file or directory
# 1，2回見つからなくても何度か押せば見つかる
(guest) $ ls -l /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 0 Nov  3 15:30 /dev/ttyACM0

ここまで見えていればほぼ勝利です．ここから先は自分でavrdudeで書き込むのも，makeに任せるのもなんとかなります．

# /qmk_firmwareに移動
(guest) $ cd /qmk_firmware
# ファームウェアをビルドして書き込み
(guest) $ sudo make choco60:default:avrdude
QMK Firmware 0.7.54
Making choco60 with keymap default and target avrdude

avr-gcc (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text    data     bss     dec     hex filename
      0   16012       0   16012    3e8c .build/choco60_default.hex

Copying choco60_default.hex to qmk_firmware folder                                                  [OK]
Checking file size of choco60_default.hex                                                           [OK]
 * The firmware size is fine - 16012/28672 (55%, 12660 bytes free)
Detecting USB port, reset your controller now...................
# ここでリセットスイッチを押してしばらく待つ
Device /dev/ttyACM0 has appeared; assuming it is the controller.
Waiting for /dev/ttyACM0 to become writable.

Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
    Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x44

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file ".build/choco60_default.hex"
avrdude: input file .build/choco60_default.hex auto detected as Intel Hex
avrdude: writing flash (16012 bytes):

Writing | ################################################## | 100% 1.97s

avrdude: 16012 bytes of flash written
avrdude: verifying flash memory against .build/choco60_default.hex:
avrdude: load data flash data from input file .build/choco60_default.hex:
avrdude: input file .build/choco60_default.hex auto detected as Intel Hex
avrdude: input file .build/choco60_default.hex contains 16012 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.13s

avrdude: verifying ...
avrdude: 16012 bytes of flash verified

avrdude: safemode: Fuses OK (E:FB, H:D8, L:FF)

avrdude done.  Thank you.

手動でavrdudeコマンドを使って書き込む場合，以下の様にします．

$ sudo avrdude -p atmega32u4 -c avr109 -P /dev/ttyACM0 -U flash:w:hexファイルへのパス

直接 /dev/ttyACM0を指定するのですが，見つからない場合以下の様にエラーが出ます．

$ sudo avrdude -p atmega32u4 -c avr109 -P /dev/ttyACM0 -U flash:w:.build/choco60_pudding.hex
avrdude: ser_open(): can't open device "/dev/ttyACM0": No such file or directory

avrdude done.  Thank you.

リセットスイッチを押してからこのデバイスファイルが出現するまでラグがあるので，落ち着いて数回実行してください．

うまくいかないとき

　最初全くうまくいかなかったのですが，あるとき急に上手くいくようになったので正直これはかなり再現性の低い手順なのではないかと思っています．ただいくつかポイントはあるかなと思っています．

1. macOS側でProMicroに触らない（ビジー状態にしない）
2. vagrant upする前に一旦USB接続を切断し，ゲストOS起動後に接続し直す
3. リセットスイッチを押してからは失敗しても2，3回やり直す
4. とりあえず再起動する

正直macOS Catalinaにアップデートしない or Windows，Linux等の他のOSを使用する方が絶対良いと思います（真顔）．

まとめ

• macOS Catalina 10.15では，avrdudeを使ったQMK Firmwareの書き込みが出来ない
• これはmacOSのせいなので，他のOSを使用することで解決する
• ワークアラウンドとしてVagrantとVirtualBoxを使用し，ホストのUSBデバイスをゲストOSから参照することで書き込むことが出来る

この記事の手順は丸1日の試行錯誤を圧縮・整理した内容になっています．足りていない手順や余計な手順を含む可能性があることに留意してください．

　早く修正されることを祈っています．それでは良きキーボードライフを．

GoCon 2019 Autumnに参加してきた

はじめに

　今回はGo Conference 2019 Autumnへ参加するにあたり，Wantedly株式会社様よりスカラシップによる支援を頂きました．大変感謝しております．また，運営の方々，大変楽しくためになるカンファレンスでした．次回以降も是非とも参加したいと思っております．本当にありがとうございました．
　なお，本記事では自分が面白いと思って聞いたセッションについて掲載しています．全体の総括ではありませんのでご了承ください．

初めて参加してみて

　Go Conの存在については以前から知っており面白そうだと感じては居ましたが，開催地が遠かったのもあり，今回が初参加となりました．
　これまでのことは存じ上げませんが，今回の会場はどこも登壇者と聴衆の距離が近く，一体となって盛り上げていくような感覚がありました．僕がスカラシップ用のバッジを身につけていたのもあるとは思うのですが，話したことない方からも「学生の方ですか？」とかお声かけ頂いたりして，大変ありがたかったです．

スカラシップ参加者用の緑色の園児ニアの証，tofu_on_fire

　セッションはどれも聞き応えがありましたが，ただの全体のまとめをしがない学生が書いても意味は無さそうです．そこで，今回は僕自身が聞いてこれから活かしていけそうだなと思った話や，純粋に興味があり面白かった話などに絞っていくつかピックアップしたいと思います．一応万全は期していますが，内容等に間違いがあればこっそり指摘して頂けると修正します．

面白かったセッション

全て自分で聞きに行ったセッションです．資料のURLはTwitter等で知ったものについては載せています．

1. Go GC algorithm 101

gocon.jp

　まずは最初のセッションである，Wantedlyの20卒内定者taxioくんの発表です．説明が非常に分かりやすく，知見として有益でした．一時期Pythonのプログラムのメモリリークに悩んでいたこともあって，自分でGCについて多少調べたりしていたのですが，入門として非常に優秀なスライドだと思います*1．

　特に，GCというものは文章で書かれてもイマイチ理解出来ない部分があり，視覚的に図で示されるとなんとなく理解しやすいように感じます．まだまだ奥深い話が無限にある世界だと思うので，彼がもっと詳しくブログを書いてくれることを期待しています．

発表後に上がった質問

　さて，本Sessionの内容はもうスライドとしてまとまっており，これ以上僕が言うことは何もないので，会場で出た質問とそれに対する発表者による回答をざっと上げていきます．

• Q: 世代別GCが美味しいケースはどこ？Goでは通常スタックに確保されるはずで，ヒープに短命なオブジェクトが漏れてくるケースは珍しいのでは？
  A: Rick氏の発表*2をもう少し見る必要がある
• Q: 短命なオブジェクトでヒープに来る物はどんなもの？
  A: エスケープ解析などによって決まり，詳しくないのでなんとも言えない．
• Q: Bitmap markingでCoWとの相性が上げられているが，GoでフォークしてCoWが活かされるケースはあるか
  A: 調べたがはっきりした言及がない．他の言語などで有効なことは分かっており，一応括弧付きで記載した．
• Q: Concurrent Mark & Sweepを選んだ理由は？
  A: 最初はCopy GC（フラグメンテーションを抑える）などが検討されていたが，Go 1.4でのCからGoでのセルフホストへの移行との兼ね合いもあり，実装コストと効果の面から選ばれた．
• Q: JVMなどではGCアルゴリズムを変更できるが，Goでもそういうオプションを付ける展望はあるか？
  A: Issueなどで見たことはない

この中で個人的に気になったのは一つ目と二つ目で，これらはお互いに関係しているのですが，突き詰めると

• Goにおいてヒープにアロケーションされるのはどのようなときか

という問いに収束します．ヒープにも短命なオブジェクトのアロケーションが頻繁に起きるなら，世代別GCも効果がありそうに思えますし，そうでないならむしろなぜそのような検討がされているのか気になるところです．

Goでヒープにアロケーションされるのはどのようなとき？

Google先生に聞いてみたところ，このブログがヒットしました．

hnakamur.github.io

この記事自体は

segment.com

これを参考にしているようです．本文からいくつか引用すると，

ポインタはスタック割り当ての阻害要因なので可能なら避ける。
ポインタを使うとほとんどの場合ヒープ割り当てになってしまう。

とか

スライスはサイズが動的でコンパイル時には未決定なのでバックストア(スライス内のポインタが参照する先)の配列がヒープ割り当てになる。

とか

戻り値で文字列やスライスを返す関数には注意。
例えば func (t Time) Format(layout string) string の戻り値のstringの値(正確にはバックストアの配列)はヒープ割り当てになる。

とか書いてあり，Goの文脈に置いても，それなりにヒープへのアロケーションはありそうという感想を持ちました．

結局Goで世代別GCは効くのか？

「go generational gc」とかで検索していると下記のGoogle Formに行き当たりました．

• Why golang garbage-collector not implement Generational and Compact gc?

ここでは世代別GCの可能性について，

• 世代別GCの良いところはSTWの時間を短く出来るところ
• ただしGoは並列でGCをするので，STWの時間は世代のサイズに依存しない
• GoではGC時間を最小化する代わりに全体の実行を一次停止するのではなく，異なるコアで並列に実行することの方が良いと想定している
• とはいえGCが並列で行う必要のある仕事を減らすことで大きな価値をもたらす可能性もある
• 今この仮説について検証を進めている

ということが述べられているようです（これが2017年）．

これを踏まえて

blog.golang.org

を読んでみると（これが2018年），

• 大きなヒープサイズに対してはそう悪くない
• ただ私たちのベンチマーク上ではあまり良い結果を示さなかった
• 世代についての仮説がGoに当てはまらないわけではなく，若いオブジェクトはスタック上で生きて死んでいくというだけ
• そのため，他の言語よりも世代別GCの効果が弱い

と述べられているようです．

　結局，Goのコントリビューターたちは色々試した上で，今の実装に行き着いているようです．ただし特定のケースでは別の方法のほうが良いというようなことはあり得そうなので，質問でも上がっていたように「GCアルゴリズムを可変にする」というような仕組みがあっても面白いのかなと思いました．

2. Go で"超高速"な経路探索エンジンをつくる

　次にDeNAの井本さんのセッションで，経路探索のアルゴリズムとGoにおける実装上の高速化の話です．井本さんの説明が非常に丁寧でわかりやすく，アルゴリズムの話・実装の話のどちらもしっかりと納得しながら話を聞くことができたように感じました．特に実装の話においては，Goにおけるsliceとmapの実装方法を説明した後に，改善の方法と結果を示すという方針で話が組み立てられており，わかりやすかったです．

　LT・セッション等で見かけがちな「でもそれそちらのドメインではの話でしょ？」みたいな高速化ではなく，本当に基礎的な，ちょっとしたGoのコードからでも実践できるようなプラクティスが述べられていることが特に素晴らしかったです．sliceやmapを一切使わずに書くことなんて普通無いと思いますし，それらを使う上で簡単に実践できるプラクティスが背景知識と共にまとまっているのは，知見として非常に素晴らしいと思います．

　また，これは会場の様子を映像と音声でお伝えできないのが悔やまれるのですが，登壇者である井本さんが非常に落ち着いた声でゆっくりと説明されており，聞き取りやすかったというのも大きかったです．人は緊張すると早口になったり，重要なところで噛んでしまったりするものです*3．落ち着いて話されているセッションというのは聞いている側も安心できるので，こういうところも見習っていきたいと思いました．

発表後に上がった質問

　結局mapが遅いので，見方を変えてmapを諦め二次元配列でのアクセスにするという話でmapの高速化の話は終わっていました．それについて，メモリ局所性に基づいた高速なハッシュマップの実装があるはず（？）というような質問が上がっていたのですが，僕自身の知識の無さであまり理解出来なかったため，省略します*4．

アルゴリズムの重要さ

　今回はGoConということで，みんなGoの実装についての注目度の方が高いと言うことは間違いないと思います．実際僕もあまりアルゴリズムへの造詣が深いわけではないので，ぱっと使えて分かりやすいsliceやmapの使い方に目が行ってしまいがちです．
　しかし，最も重要なのは「どういうアルゴリズムを選択するか」という部分のはずです．この発表でも前半でアルゴリズムの選択について触れられていますが，実務では単に最速のアルゴリズムを探すわけではなく，実用性を考えて，要件に合うものを使うことになるはずです*5．今回のDeNAさんでの要件だと「渋滞の反映」みたいな，事前計算時間に対する要求があったはずです．何らかの制約がある中でアルゴリズムを選択するのは，どういったところでどういった経験・知識を積むと良いのか知りたいです．競技プログラミングも近い物だとは思いますが，やはり少し実務とは違う部分もあると思っているので．

3. Write Container Runtime in Go

最後に@tomocyくんの発表です．資料が上げられていないので， https://gocon.jp/sessions/write_container_runtime_in_go/ の説明欄から引用します．

昨今では、DockerやKubernetesは多くのプロダクションで採用されています。そしてコンテナランタイムはこれらの技術を支える、正に中心的な技術です。このトークではrunCなどの各コンテナランタイムのGoのコードを紹介しながら、コンテナランタイムについて話します。またOCIが定めるOCI runtimeについてを、自作のコンテナランタイムをそれに準拠させながら話します。このトークの後で実際に自身の手でコンテナランタイムの自作、OCI runtimeへの準拠ができるように、GitHubにログ付きのレポジトリーを公開する予定です。

このセッションではContainer Runtimeを""Goで""実装するという部分に重きが置かれており，実際に彼が実装したコードを示しつつ，OCI Runtime Specに沿って実装を進めていくという形で発表が行われました．
　実は彼もWantedlyのスカラシッププログラムで来ていたのですが，自己紹介でおもむろに「実は今日登壇します」と言い出して，全員の度肝を抜いたという裏事情があります．僕は開催前からこのセッションを見る予定をしていたので，まさか同じスカラシップの学生が登壇者だとは思わず，驚きと焦燥でかなり動揺してしまいました……

2019/11/1 0:00 追記
tomocyくんが資料を上げてくれました！

彼のアフターレポートはこちら

medium.com

Container Runtime

コンテナランタイムの実装として最も一般に普及しているのは，おそらくDockerが使用しているruncです．これについては以下の資料が分かりやすかったです．

OCIランタイムの筆頭「runc」を俯瞰する from Kohei Tokunaga

上記資料の4ページ目にあるように，Dockerのような高レベルランタイムは，runcという低レベルなコンテナランタイムのインターフェースであると言うことが出来ると思います．そのため，Dockerの仕様に沿ったコンテナランタイムを実装すればruncと差し替えて使うことも出来るわけです*6．

OCI Runtime Spec

github.com

　コンテナランタイム実装について，標準的な仕様を定義しているのがLinux Foundation傘下にあるOpen Container Initiative（OCI）です．runcの開発元でもあります．

　ランタイムの実装者はこれを見ながら実装するのですが，実はこの仕様では5つの操作方法と，それに対して何を返し，何をするべきかが記述されているだけで，内部の実装をどう書くかには一切言及がされていません．その5つの操作方法が以下です．

操作名	コマンドと引数	何をするべきか
State	state <container-id>	コンテナの現在の状態を返す
Create	create <container-id> <path-to-bundle>	コンテナを作る（実行はしない）
Start	start <container-id>	コンテナに与えられているコマンドを実行する
Kill	kill <container-id> <signal>	コンテナにシグナルを送って止める
Delete	delete <cintainer-id>	Createされたコンテナを削除する

上記の5つのコマンドを実行できるCLIを用意すれば，OCI Runtime Specに則ったランタイムを作れる，というわけです．

どう実装するか

　runcと同様，tomocyくんはLinuxの機能（Namespace，cgroup，chroot/pivot_root…etc）をふんだんに利用したランタイムの実装をしたそうで，実際に起動したプロセスが，どのようにホストから隔離されてコンテナとして動作していくのかを順に追って説明してくれたので，仮想化の機能についてそう詳しくない僕でも話について行くことが出来ました．
　また，Goでの実装方法についても

• urfave/cliで簡単にコマンドを実装する
• Dependency Injectionを使ってテスタビリティを上げ，CLIを薄く保つ
• _linuxなどのプレフィクスをファイル名に付けることでBuild ConstraintによってOSごとにビルドされるファイルを変える

などの基本的な，しかし実際によく使われている手法を紹介していました．本当に短いコードで色々示してくれるので，あれっもしかして簡単なのでは？とちょっと思わせてくるあたりが凄かったです．

「車輪の再発明が好き」

　この発表で特に印象に残っているのは彼が言っていたこのセリフです．普通だと「それはもうあるし再実装するのは無駄だよ」とか周囲から言われて止められがちなのですが，彼はあえてそういった車輪の再発明をGoでやるということに情熱を傾けているそうです．昼食時にもGoのhttp.Clientを自前で実装し直してみている話とかを聞かせてくれました．

　普段僕は「あるものは使う」というスタンスなので，必要があればサードパーティーの実装を躊躇なく使いますし，言語の持つ便利な機能やモジュールがあれば，同等の機能を自分で実装することはほとんどありません．しかし，逆を言えば

• そういった機能がどのように実現されているのか
• 実現するにあたってどういうところに苦労するのか

といった部分をほとんど知らないままでいることになります．例えば今回のコンテナランタイムの話にしても「Namespaceとかchrootとか使ってるらしい」みたいなことは知っていても，どういう順番でそれらが使われていくのか，どのように使うのかといった情報はほとんど知りませんでした．こういったことが他の様々なものに対しても同様に起きていると考えると，自分の無知に絶望してしまいそうです*7．

　たまにはそういった，よく使うけどどう動いているのか知らないみたいなものについて，コードリーディングしたり実際に手を動かしてみるなどしてみると，より自分の世界が広がるかなと感じました*8．

発表後に上がった質問

• Q: Dockerを動かすために必要な物にはどういうものがある？
  A: DockerはOCIあんまり守ってないので，イメージのディレクトリレイアウトも違うし，Dockerのためにいいかんじに動かすコマンドが必要
• Q: 強いランタイムはどういう実装をしている？
  A: 例えばgVisorはセキュリティ特化で，一部ハイパーバイザのようなことをしているらしい．速度はトレードオフかもしれないが，リソース分離をしっかりやっている．評価軸に沿ったランタイム選定をすれば良い．
• Q: Linux特有の機能を使いまくっていて良い．Mac使ってるみたいだけど，Linuxのやつをどう開発した？
  A: 開発にはエディタの機能を，動作検証はコンテナの中でやった

特に最後のLinuxの機能を使いまくっているのにMac使いってどういうことなんだと思っていたのですが，どうもVSCodeでは環境変数GOOSによって補完される内容が変わるらしく，これを使って実装していたとのこと．確かにGOOS設定できるようにしてくれというIssueがあり，実際に対応されているようです．

github.com

コンテナの検証をコンテナの中でやるというのも，会場の笑いを誘っていました(笑)

tomocyくんの名言（迷言）要約集

• コンテナランタイムって作ってもあんまり感動がない
• もっと感動が欲しい人はDockerコマンドから叩けるようにしよう
• Dockerから使えるようにすればさすがにお母さんも感動してくれるはず

彼はおそらくとんでもない化け物だと思います（褒めてる）．

Goコミュニティにどう貢献していくべきか

　残念ながら僕はスーパープログラマではないようなので，Go言語そのものや，Goでの開発に対してとてつもないインパクトのある何かを残せるとは思っていません*9．では，そういう自分が何をやっていけるかというと，やはり

• Goをこういうシチュエーションで使っている
• こういうところが便利でこういうところがつらい
• こんな便利なものを作ってみたよ，実はGoで書いてるよ

みたいな，Goを使うことについての対外的な情報公開かなと思っています．結局ユーザがたくさん居ても情報が出てこないとその活発さは可視化されないし，コミュニティが活発で無いと新規ユーザも増えないと思っています．Goの恩恵をたくさん受けているので，恩返しというと恩着せがましいですが，コミュニティにとってより良い影響を与えられるように頑張っていきます．

まとめ

　Go Conferenceは実務でバリバリGo書いている人でなくても，得られる知見がたくさんあります．開催地が遠くてお金が……という場合にも，何社もスカラシップスポンサーとして学生を支援してくれています．ちょっとでも気になっているなら，次回の参加を検討されてみてはいかがでしょうか．

　次か次の次くらいのGo Conferenceでの登壇目指して精進していきます．同じく登壇を目指す方々，対戦よろしくお願いします．

---

合わせて読みたい

www.wantedly.com

---

*1:PythonのGCは主に参照カウント方式を，補助的に世代別GCを使用しているのでGoのものとはかなり異なります

*2:blog.golang.org

*3:これは僕の話です

*4:行列演算の例で有名な同じ行の要素に連続してアクセスした方が早いという話に近い物だと思うのですが，短い質問時間の中では僕の理解が追いつきませんでした．

*5:実務でそんなにアルゴリズムをゴリゴリやったことがないので想像で書いています．場合によるとは思います．

*6:これを利用したのが（Docker 18.09までで）コンテナからGPUを使用できるようにしたnvidia-dockerです

*7:例えばGoのmapやsliceの詳しい実装についても井本さんのセッションでこの日初めて知りました

*8:そういう意味で，Wantedlyのスポンサーセッションで紹介されていたGopher's Code Reading Partyはとても良さそうです

*9:これは諦めていると言うことと同義ではありません