taiyoh's memorandum

@ttaiyoh が、技術ネタで気づいたことを書き溜めておきます。

Ergo42が遂に組みあがりました

承前↓

taiyoh.hatenablog.com

問題点の絞り込みと対処法について

twitterに細かく情報をのっけて行く形だとちょっとあれだな、と思ったので、一旦ブログに現状をまとめてみたところ、作者のBiaccoさんに読んでいただくことができました。

実際のワイヤリングはどのようにやったか

f:id:sun-basix:20180727171857j:plain

当初はこのようなワイヤリングで導通させていましたが、いざケースのネジを締めて少し使ってみると、部分的にスイッチの半田が圧迫されるのか、キーが効かなくなってしまいました。 あれこれ考えて、もっと簡素化できる方法を思いついたので、バージョン2のワイヤリングをやってみました。

f:id:sun-basix:20180727172202j:plain

これなら圧迫もなく、無事に全部のキー入力が確認できました!因みにこの黄色いワイヤは、元々はブレッドボード用の硬いジャンパーワイヤですね。持っててよかった。

akizukidenshi.com

そして。。。

慣れないながらもちゃんと打つことができて、感動ですね。。。

キーマップについて

デフォルトのキーマップは、初めて分割キーボードに手を出した自分にとっては結構使いやすかったです。
でもやっぱり、自作キーボードに手を出した以上はもっと自分の好みを反映したいな、と思ったので、以下のキーマップを作成しました。

gist957d0e08b81c69d0c1cdda621f7debc4

当初は7列をフルに使うことを想定していて、妄想ではこういうキーマップを当初想定していました

f:id:sun-basix:20180727211141p:plain

が、いざこれを書き出して打ってみると、1列目と7列目のキーを押すのはだいぶしんどいと気づき、あえなく撃沈。
しばらく色々試していて見えてきたのは、特に僕の場合、意識せずに伸ばせる指の範囲は6列分までだということでした。
これを踏まえ、以下のようなルールを作ってみました

  • Tab, Ctrl, Shiftは内側に、そして左側に1つずつあればいい
  • ESC, LGUIは使用頻度が低いか、Tab, Ctrlとの組み合わせで使うことが圧倒的に多いので外側でいい
  • Dvorak配列も試してみたいので、Dvorakで明確に配置されているキーは必ず上3行の中に収める
  • META / SYMBで記号が打てならそちらに任せる
    • 無理にデフォルトキーマップの全キーを埋める必要はないだろう
  • 矢印キーはvimキーバインドに倣って「←↓↑→」の並びに
  • 手首に近いところにはよく使うキーは配置しない

これらを実際の配列に落とし込んだのが上記のキーマップです。
backspaceを右手親指で扱うというのはだいぶイレギュラーかも。でもまあ、しばらく使っていたら段々慣れつつあります。

qwertydvorakを共存させるにあたり、2点ほど気を付けたことがあります。

  • META / SYMBよりレイヤ番号を低くする
  • config.h#define PREVENT_STUCK_MODIFIERS をつける

hrhg.hatenablog.com

の記事より、定数を定義しておくことでmodifierキーのロックを防ぐことができます。また、dvorakのレイヤ番号をqwertyを配置しているdefault layerの次に低くしておくことで、default layerのキーを引き継げるだけでなく、上のレイヤのキーを利用することができます。なお、上記キーマップではqwertydvorakへの変換ですが、dvorakqwertyに戻す際は、METAからソフトウェアリセットをかければいいようにしています。

ファームウェアへの書き込みについて

自作キーボードを組み立ててる方々はMac使いが多く、Windowsでの情報が少ないように感じたので、自分のやったことと所感を載せておきます。
始めに書いておくと、僕はWSL(Windows Subsystem for Linux)とqmk toolboxを併用しています。
なぜMingwでの環境構築がおススメされているかというと、makeコマンド一発で(make ergo42/rev1:<keymap>:avrdude と入力すれば)ファームウェアへの書き込みまで行うことができるからです。
ただ、僕は諸々の開発環境をWSL上で既に作ってしまっているので、今更Mingwで環境を作り直すのが面倒くさく、こういう方式を採ることにしました。
その場合、 make ergo42/rev1:<keymap> とmakeの引数を調整すれば、WSL内でビルドまではやってくれます。あとはqmk toolboxでのhexファイルの読み込み先をビルド先に指定すればよいです。

最後に

特に僕みたいに初めてまともな電子工作をする人にとって、既製品を買うのに比べてだいぶお金も労力もかかってしまうのは間違いないです。
が、作りきった時の達成感は尋常じゃないですし、自分にとって必要なものだけがまとまっているキーボードというのは格別ですね。
因みにこのエントリは当然ながら、Ergo42+上記の自前キーマップで書いております。書いてるうちに少しずつキー入力の速度が上がってるのがなんか面白い。
いやそれにしても、キースイッチの押し心地はいいし、キーキャップの色は自分で好きなように変えられるし、配列に不満があれば変えればいいし、分割キーボードは肩回りの負担が確かに少ないし、これはちょっとハマりそうですね。。。!

Ergo42を組み立てています(そしてどうやら失敗しています)

[追記 2018-07-27] 組みあがりました

taiyoh.hatenablog.com

[/追記]

最近突如として自作キーボードに興味が出てきて、電子工作のスキルなんて全然ないのに道具を揃えてErgo42を組み立ててみることにしました。 (作者のBiacco42さん、ありがとうございます!)

github.com

組み立て手順については、qiitaにある組み立てログを参考に作業を進めていました。

qiita.com

ただ、Pro Microの右側の取り付けで盛大にミスをしてしまい、左側と同じ付け方をしてしまいました。 (チップやLEDが見える方を上側にしてしまった) なので慌ててスプリングピンヘッダを切って無理矢理取り外し、Pro MicroもAmazonでほぼ同じものを購入し、正しい向きにした状態で改めて装着しました。

KOOKYE Pro Micro ATmega32U4 5V/16MHz Module Board マイクロコントローラーボード Arduino Leonardo Replace ATmega328 Arduino Pro Miniと互換 3個セット

そんなこんなでキースイッチを全部半田付けしていざ試してみたところ、右側のキーボードの左から2番目の縦一列(デフォルトのキーマップで言う「U」「J」「M」「'」)のキーが全て効かない状態になっております。。。 以下、自分なりにトラブルシュートを行ってみました。

  • 4つのスイッチを全部差し替えてみましたが、特に挙動に変化はありませんでした
  • テスターで導通チェックをしてみましたが、絶縁状態にはなってないようでした
  • ダイオードの向きも問題ないようです
  • 右側のファームウェア書き込みのついでにいくつかキーを打ってみて、やはり当該のキーだけ打てませんでした
    • 左側との連係ミスとは考えづらい

となると、あと考えられるのは

  • Pro Microを外した時に必要以上に強い力がかかった
    • 目視する限り、基盤には影響はなさそうでした
    • ニッパーでスプリングピンヘッダを外す時に一部エッチングが削れてしまったというのはあります
  • 半田と半田ごての扱いが未熟でPro Microを痛めた

ですかね。。。 自分のスキルを差し置いて希望だけ書いておくと、Pro Microを使ったキーボードで縦一列が使えなくなる、というのがよくある失敗パターンとしてあって、何かをやり直したら解決する、だといいなぁ。 そうじゃないとしたら、もう1セット買って右側を作り直すしかなさそうですね。。。

f:id:sun-basix:20180724115454j:plain 左側は全キー問題なさそうなので、キーキャップまで全部着けました。パステル系のキーキャップを買ったので予想通りかわいい。

f:id:sun-basix:20180724115553j:plain この左から二番目の縦一列が全滅です。因みにキースイッチはkailh pro purpleです。打ち心地いいですねこれ。

f:id:sun-basix:20180724115703j:plain 右側のPro Microを上から見たところです。

f:id:sun-basix:20180724115751j:plain 右側のキーボードを基盤裏から見た図です。

Docker for Windows 18.03で/var/run/docker.sockがマウントできなくなってた

すでにGitHubの方にはissueが上がっていた

github.com

事前に COMPOSE_CONVERT_WINDOWS_PATHS=1環境変数を仕込んでおく必要があるらしい。

PowerShellの場合: $Env:COMPOSE_CONVERT_WINDOWS_PATHS=1
Cygwin等の場合: export COMPOSE_CONVERT_WINDOWS_PATHS=1

後方互換性壊すような変更入れるんならちゃんとアナウンスしてドキュメントにも書けよ」「環境変数追加するくらいでいちいちドキュメント書く必要ないだろ」というやり取りがあるあたり、趣深い。

sqsdの最近のアップデートについて

以前「作った」と書いたsqsdについて↓ taiyoh.hatenablog.com

最近これのバージョンアップを頻繁に行っている。

Release v0.0.4 · taiyoh/sqsd · GitHub

v0.0.3~v0.0.4の差分
社内のgoの達人方にレビューしてもらい、channel capacityを導入したところコードの見通しがものすごく良くなったので、v0.0.4として一旦リリース。
workerに送るqueueをchannelによってブロックできるようにすることで、余計なmutex等を入れずに安全にqueueをworkerに送れるようになった。

https://raw.githubusercontent.com/taiyoh/sqsd/d05b49d306957b94b1f524a84a184958cf4038d9/doc/msg_handler_sequence.png

このシーケンス図を同僚に見せたところ、「これは producer-consumerパターン で書くといいですね」というコメントをもらう。

Producer-Consumerパターン

Release v0.0.5 · taiyoh/sqsd · GitHub

v0.0.4~v0.0.5の差分

producer-consumerパターンは自分の中で咀嚼が必要だったので、一旦保留。
そろそろログ周りを整理したかったので、このQiitaの記事を読んで hashicorp/logutilsを入れることにした

qiita.com

この時点では構造化ログまでは必要ないと思っていて、ログレベルが調整できればいいと考えていた。

Release v0.5.0 · taiyoh/sqsd · GitHub

v0.0.5~v0.5.0の差分

producer-consumerパターンがやっと自分の中で咀嚼できたのでリファクタリングを開始。やってみたところ、今までJobという名前のstructがqueue自体の保持だけでなくconsumerの責務も負っていることが分かったので、それを分離したところ、それだけでほぼproducer-consumerパターンといえる組み方ができてしまった。あとはそのデザインパターンを適用していることを示すためにJobWorkerという言葉は避け、producerconsumerという言葉を使うことにした。
デザインパターンの適用をはっきり見せることができたので、βクオリティということを示したいのでバージョンを思い切って上げることにした。

Release v0.6.1 · taiyoh/sqsd · GitHub

v0.5.0~v0.6.1の差分

SQSのqueue urlの構築をパラメータから行うようにしてしまったため、例えばローカルで開発する時など、awsに飛ばないようにしなくてはいけない。
そのため、強制的にURLを指定できるようにもした。
また、実際にプロダクトに投入される時のことを想像したとき、万が一workerの起動が遅かった時、queueの取得が先に行われてしまうとvisibility timeoutが発生してしまうのではないか、ということに気づいた。その解決策として、producerの起動前にhealthcheck用のエンドポイントにリクエストを行い、その時のレスポンスコードが200を返したときにworkerの準備ができたとみなすことにした。それが済むまで、SQSへのqueueの取得は行わない。healthcheckに対してはexponential backoffアルゴリズムに従ってリトライを行い、これが規定の秒数に達しても200が返せないときはsqsdごと落とすようにした。この挙動はconfに healthcheck というセクションが定義されている時のみ行われる。optionalとしているが、なるべく定義した方がいいのでは、と考えている。

Release v0.7.0 · taiyoh/sqsd · GitHub

v0.6.1~v0.7.0の差分

docs.aws.amazon.com

queueの取得の性能について以前からぼんやり気になっていたので調べていたところ、上記URLに答えが書いてあった。(当然金はかかるが)ガンガンリクエストして取りに来てくれ、ということのようなので、遠慮なく一度に複数リクエストを投げられるようにした。v0.0.4の時にchannel capacityの対応を入れていたおかげで、投入部分は何も気にすることなく対応できたのがとてもよかった。

取り急ぎどうしても必要そうな更新は終わったつもりだが、これからまだまだ必要な機能実装はあるかもしれない。直近ではログの構造化を考えている。
また、イケてない箇所は優しくissueをいただけますと :pray:

「エンジニアリング組織論への招待」を読んだ

とにかく解り易かった。「不確実性に向き合う」という一本の大きな筋を見失うことなく、個人のメンタリングから組織の在り方までこんなにブレなくキレイに説明できていることが素直にスゴイと思った。 読む前は「エンジニア主導で何かしてくための本なのかな」と勝手に想像していたが、読み進めるうちに「事業部の(技術者に限らず)他のメンバーはどういうポイントでどういう不確実性に向き合っているんだろうか」と考えるようになった。

1章の「get wild and tough」でいきなり引き込まれ、2章で自分がメンタリングされている気分になっていた。読んでるだけで気分がよくなってきたので、自分が今まず欲しているのはこれなのかもしれない。これらを序盤に持ってくるあたり、「まずは自分のスタンスを変え、個々人間の情報の非対称性をなくしていくことが重要だ」と言われているように感じていた。3~4章ではチームビルディングやアジャイル・そしてそこから派生したプロジェクトのイテレーション手法について触れているが、どれもやはり「個人の情報の非対称性が少ない」というのが前提に立った話のように僕は捉えた。裏を返すと、情報の非対称性に対処するという基本的な部分の努力が払われないままリーンやアジャイルスクラムといった手法を取り入れても、ただ恰好だけ真似しただけで早晩破綻するだろう、とも受け取れる。事実、自分たちのチームのスクラムの体制は半分くらい崩壊しかかっている。導入した当時は「今必要だからスクラムを導入するしかない」と思っていたつもりだったが、今振り返ると、その前にやることがあっただろうと思える。

結構注意しなくては、と思ったのは、4章後半~5章にかけて「適切に権限移譲せよ」と書いてあったのだが、これを微妙な形で適用して結局「プリンシパル・エージェント関係」に陥らないかというのが心配になった。それを抑制するために、まずは個々人間で情報の非対称性を減らし、メンバーが増えてきたらチーム間の合意のためのプロトコルを作って、という形を適用していくのがいいのではと思うが、恥ずかしながら自分にはそうした世界を実感したことはない。

とりあえずこの本は目から鱗が落ちまくってるので、読み終わる前からすでに事業部の何人かにパワープッシュしている。「不確実性を減らす」というエンジニアリングの本質ができる環境を作りたい。

「GraphQL over WebSocket Protocol」という仕組みが提案されてるらしい

というのをたまたま調べものをしてる時に見つけた。 github.com

(以下このプロトコルGoWP と書きます)
GoWPだとどのクエリでもWebSocket通信上でできるように、ということが想定されているが、何より主眼に置かれてるのはsubscriptionへの対応ではないだろうか。
コネクション確立からクエリの登録までのプロトコルが明文化されているので、そうした足回りは対応ライブラリがあれば任せられそうというのがいいな、と。
例えば、golangでのGoWP対応ライブラリは以下のようなのがある。

github.com

これを見つけてから、

  • subscription でストリーミングしたいデータはHTTP通信で外から登録チャンネル毎に受け渡せる
    • 部外者に見せたくないデータが誤って流れるのを防ぐために、ユーザを指定できるようにしてもいいかも
    • アプリケーション上でのIDはJWTで受け渡してAuthenticateのタイミングでライブラリ上でコネクションIDとマッピング

なんてことができるプロキシサーバがあるといいかも。。。と妄想が一気に膨らんだところだった。
ただ、恐らくまだGraphiQLが対応してないので、今までと同じような開発体制が組めないというのはデメリットとしてありそう。
あと、ユーザ指定して任意のメッセージをサーバから送りたい、というための仕組みとしては kuiperbeltが既にあるので、そもそもserver pushの土管が用意できればいいだけなのにそこまでGraphQL使わないといけないのかとか、色々考えることはある。

GraphQLのMutationのビジネスロジックのエラーはどうハンドリングすればいいのか

最近調査していた内容のメモ。

GraphQLのJSONレスポンスは dataerrors の2つのキーに内容が大別される。
基本的に、期待するレスポンスが返せないときは errors にエラー内容が入るというのがGraphQLでやろうとしていることだが、特にMutationにおけるビジネスロジックのエラーはどう記述すればいいだろうか。
恐らくFacebook的には「ダメです!」とエラーダイアログを表示させて終了なのかもしれないが、世の中のサービスが全部それに倣っているということはなく、エラーとなった要素をクライアント側で特定して赤くしたりエラー文言を添えたりしたい、なんてケースはよくある。自分の担当しているサービスもそんな感じだ。

ひとまずRelayのドキュメントを開いてみる→ Mutations · Relay

ざっくりと「レスポンスには(追加・削除含め)変更のあったTypeのオブジェクトを返せ」という風に僕は読んでいる。エラーについては特に記述はなく、 GraphQLのレスポンスとしての errors に全て委ねているようだ。

RelayだけがGraphQLのプロトコルではないので(強力ではあるが)、他にないかと自分が軽く調べてみた限り、大きく2つの方法があるらしい。

1. errors のデータ構造を拡張する

medium.com

にその一例がある。確かに、という気持ちはあるが、今自分の使っているPerl版GraphQLライブラリはパラメータがかなり厳密に定められているので、そこに手を入れるとなるとモンキーパッチが必須になる。本家にpr送っても通るイメージが湧かない。パス。

tech.eshaiju.in

だと、ライブラリのエラーオブジェクト自体を差し替えるというアイディアもある。が、これもPerl版GraphQLライブラリだと errors に入れられるのは GraphQL::Error オブジェクトが要素となる配列しか認められてないので、上記と同様のコメントになる。

2. data 側のレスポンスの型としてビジネスロジックでのエラーを返せるようにする

github.com

結論が出ないままcloseされていて悲しみしか感じない。が、このissueを参照する形で

github.com

Rust版GraphQLライブラリでのやりとりを見つけた。 data.<mutation>.errors なら自分で専用の型を作ればいいだけなので、僕が見てきた方法の中ではこれが一番穏当で現実的なプランに見える。
もうちょっと調べてみたら、Ruby版GraphQLライブラリのドキュメントでも同様の内容があった→GraphQL - Mutations
が、これだと独自のレスポンス形式になるので、この取り決めがサービス内全体で適用できればいいが、Relayからはかなり逸脱しているようにも見える。その点の注意は必要そうだ。

まとめ

現時点だと、自分の担当サービスもビジネスロジックのエラーは data.<mutation>.errors を入れる方向で進めようとしている。Relayを踏襲するかどうかは実は検討中。