2018-11-28

自作キーボードのLily58を作った

7日に届いて17日に完成した。平日の夜と週末にやって10時間はかからなかったと思う。このビルドログ書くほうが時間かかってるかも。

買ったもの

Lily58本体のセット
Kailhロープロファイルスイッチ × 60個
- 赤軸メインで茶軸を少し混ぜた
Kailhロープロ無刻印キーキャップ × 60個
- 白黒組み合わせで購入
Mantis(マンティス)【2in1３本セット 1m】マグネット式充電ケーブル
- Pro Microはもげるのでその対策にマグネット式が良いと見かけたので買ってみた
audio-technica 車載用オーディオケーブル0.4m
- とりあえず長さとカールしてるのが良かったので買ってみた

今回は持ち運びを前提にしていたので、薄くするためにKailhのロープロキーと組み合わせて作った。キーキャップはキーカスタマイズするので、刻印がないものにした。

金額に特に不満はないけど、だいだい全部で17,000円くらい。

組み立て

公式のビルドガイドはこちら。（久しぶりに見たらアップデートされてかなり丁寧に書いてありました）

Lily58/buildguide_jp.md at master · kata0510/Lily58

特に注意が必要だったところを書いておく。

ダイオードの取り付け

足の折り曲げはビルドガイドにあった通り、アクリル板を3枚重ねて曲げると楽だった。アクリル板はとりあえず洗濯バサミで挟んで固定していた。

折り曲げるとこんな感じになる。

底面側から足を通す。これは右手側になる。

マステで止めてひっくり返してはんだ付けする。マステで止めた段階で、先に足を短くしてしまっても良いかもしれない。足をカットしながらでないと、邪魔になるのではんだ付けしにくかった。

Pro Microの取り付け

Pro Microは付属のコンスルーを差し込んではんだ付けをする。はんだ付けした後にPCBにコンスルーを差し込む。片方しかはんだ付けしない、という点に注意する。

差し込んだ後にPro Microが簡単に抜けてしまったり、PCBを揺らすとカタカタしたりするといった感じで、とにかく緩そうだったら注意が必要。

自分はしっかり取り付けたつもりだったが接触不良になっていた（後述）。

※最近更新されたビルドガイドではどちらもはんだ付けするように記載されているので、そうしたら問題なくなるはず。

両方取り付けたらこんな感じになる。

アクリル板とPCBの重ね合わせ

ダイオードを取り付けた後の、はんだの仕上がり部分（山になったところ）が邪魔してしまい、アクリル板とPCBがピッタリ重ならない。そのためロープロファイルの軸だと、スイッチの足がPCBに届かない状態になってしまう。

なので、はんだの山をニッパで切り取って薄くする作業を行った。次の写真の真ん中のとこが削ったところ。

なかなか地味に時間がかかるし面倒な作業だったが、これでようやくピッタリ気味で重ねることができた。

※ここもビルドガイドでは表面実装のダイオードが推奨されている

キースイッチの取り付け

この状態でもキースイッチの足はちょっとしか出てこないので、はんだ付けが難しかった。コテ先をスルーホールに突っ込んで温め、ハンダを流し込む気持ちでやったら上手くいった感じがする。

念のためキースイッチをはんだ付けした後に、テスターで各キーがきちんと導通するか確認を行った。（組み立てが終わってからの動作確認で上手くいかなかったので、この段階で確認しといて良かった）

ファームウェアの書き込み

ソフトウェア的には特に困ることはなかった。

Pro Microのリセット

片方で、リセットのスイッチがうまく動作しなかったため、Pro MicroのRSTとGNDを直接ショートさせてリセットした。

Pro Micro & Fio V3 Hookup Guide - learn.sparkfun.com

この辺を参考にした。

動作確認

組み立ても終わりファームウェアの書き込みも終わったが、どうにもうまく動かない。左側はbしか反応しないし、右側はそもそも電源が通ってなさそうだった。

キースイッチの確認

たまにキースイッチが壊れていて反応しないケースがあるらしい。キースイッチをはんだ付けしたタイミングで各スイッチの導通チェックを行っていたので、スイッチの破損や不良がないことは確認済みだった。

ファームウェアの書き込みの確認

PC側での作業の結果（ターミナルでの出力）からファームウェアの書き込みは正しくできていそうだったので、コンスルーの足を直接ショートさせてみた。ピンの組み合わせに応じたキーが入力されたので、ファームウェアの書き込みには失敗していないと確認が取れた。

PCBとPro Microの接続

Discordで教えてもらったので、Pro MicroをPCBに差し込み直したり、コンスルーとPCB接触部分をいじってみたりすると入力できるキーが増えたので、ここに問題があったらしい。コンスルーがやはりどうしても抜けそうな感じがするので、しっかりと折り曲げたりとかしてきちんと接続ができるようにした。結果、問題なくキーが入力できるようになった。また右側についても問題なく動作するようになった。

参照したブログを失念してしまったが、行や列が全然反応しない場合にはこのあたりの接続不良が原因の場合があるらしい。まさに自分もそうだった。

※最新のビルドガイド通りにちゃんとはんだ付けしておけば問題ないはず

使ってみて

完成したのはこんな感じ。キーキャップの種類と数を間違ってしまって、黒が足りなかった。ホントはホームポジションのとこだけ白くするつもりだったけど。

MacBookとの接続の時に、アダプタの周りがごちゃっとしてしまう。MacBook本体からコネクタの部分までのケーブルが長めのアダプタに変えれば問題ないかな。

これはLily58の問題ではないけど、どうもキーキャップが滑る感じがして、ホームポジションのおさまりが悪く誤タイプが最初は多かった。なので、ホットグルーで認識のためのポチを作った。そのおかげか、慣れたからか、ここ数日はホームポジションを間違うこともなくなった。

おわりに

ハンダ付けからファームウェアの書き込みまでは特に問題なく進んだが、PCに接続してからの動作確認が大変だったので、今後作る機会があれば以下のようにしてみようかと思った。

ProMicroとコンスルーを接続する
この段階でファームウェアの書き込みを行い、各ピンをショートさせキー入力が行えることを確認する
- ここでうまく行ってなければProMicroの不良やファームウェアの書き込みに失敗していると判断できる
PCBにダイオードやキースイッチをはんだ付けしていき、各キースイッチでの導通チェックを行う
- ここで導通チェックすることで、キースイッチに問題がないことが確実になる
PCBとProMicroを接続する
- この後の動作確認においては、キースイッチとProMicroの動作確認は取れているので、上手くいかない場合にはPCBとProMicroの接触不良が怪しい

とにかく、全部組み合わせてしまってからの動作確認は大変なので、こまめにチェックしていくのが大事だな。

この文章は9割くらいiPhoneで書いていて、仕上げを作成したLily58で書いた。とても使い心地が良くて満足している。

2018-10-29

Twitterを制限してNuzzle/Reederを使うようにした

Twitterついついダラダラと見続けてしまうので、良くない。iOSの最近入った機能のスクリーンタイムを使って使用時間を制限することにした。1日30分。

とはいえ情報収集の側面もあるので、代替手段としてNuzzle/Reederを使うようにした。どちらも以前は使っていたものの、ここ数年はほとんど使うことがなかった。

Nuzzle

Twitterのアカウントを連携するとTL状に現れたURLをサマリーしてくれる。アプリでも確認できるし、デイリーのメールも送ってくれる。

人気や話題の記事は漏らさずに拾ってくれてるので「えっそれは知らなかった」みたいなこともない。

あとやたらとURLを含むツイートをたくさんするアカウントがあると、けっこうノイズ感がある。まぁこれはTwitterのTL見ててもそうなんで、仕方ないんだけど。

Nuzzleで拾った記事で良さそうだったらRSS購読するという流れにしている。

Reeder

RSSリーダーアプリでFeedlyのフロントとして使っている。 RSSだけだと新規にフィードが増えていかないし徐々に不活性になってしまうので、それを補うためにNuzzleを使う。

Nuzzleで書いたように、Twitterで見かけたブログ記事の内容が良かったらそのブログを購読するようにしていた。

さっき確認したら登録フィード数は170位あったが、もちろん毎日全部のサイトが更新されるわけではない。1日10件程度で、タイトルだけで判断して興味がなければ見なければ良い。

おわりに

Twitterを直接見るのに比べると色んな記事の流量は減ってると思う。知る機会は減ったかもしれないが、知らなくても良いことを知らずにすむようになったんではないかと思う。

ノイズが少ない方が自分としては嬉しいかもしれない。

2018-10-19

npxが便利だった

最近またNode.jsを触ってる。

npmで色々インストールするときに、そのプロジェクトでしか利用しないものは、やっぱりグローバルな領域にはインストールしたくない。

けど、そうするとnode_modules/.binにPATHを通すとか一回り工夫しないといけなくて、地味にめんどくさかった。

npxはその辺りを上手くやってくれるツールっぽい。

npx パッケージ 引数

みたいに実行する。

色々できそうだが、今のところはコマンド呼び出しにしか使ってない。

2018-10-05

gitのpush.defaultをcurrentにした

pushが楽だからという理由で設定を変更した。

currentとsimpleの違い

push.defaultのデフォルト値は過去に変更されたことがあって、2.0以降だとsimpleになっている。

simpleはupstreamが設定されていて、同名の場合にプッシュ先を省略できる。

currentは同名のブランチだけをプッシュする。upstreamが設定されていなくても良く、リモートリポジトリにブランチがなくても良い。

自分の使い方

gitのブランチの作成はローカルでやる派なので、何か新しいissueに取り掛かる時には、

$ git checkout -b do-something

として、ローカルでブランチを作成する。一通り作業が終わったら、

$ git push -u

とする。

simpleとは違ってブランチ名を指定しなくてもプッシュができるだけなんだけど、地味に便利。

vcs_infoの都合で-uを使ってupstreamを設定しているが、無くても問題ない。

2018-10-01

異動した

先日病気をしてからの体調面のこと、幸いに受け入れてもらえるチームがあったこと、などいろいろあって異動することにした。

以前の部署では、休んでた期間を除いて一年強と短い期間ではあるが、複数チームが関わる大きなプロダクトに携われたことは、とても良い経験になった。

今日からはスモールチームでやっていく。規模感は前とは全然違うが、その分自分が関われる範囲は広いだろう。それに自分の実力が成果に直結することになるので、今まで以上にちゃんとしてないと。

とはいえあまり意識高い感じでこじらせるとしんどいんで、良い感じでパフォーマンス出せるようにがんばろう。

2018-09-26

zshでGitのリモートリポジトリのホスト名を表示する

zshではvcs_infoを使用して作業中のリポジトリの情報を表示することができる。「zsh vcs_info」でググるといろいろと出てくるが、私は以下の記事をベースに設定を行って、少しずつアップデートしている。

zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する（記事は4年ほど前のものだが、zsh自体がそんなにアップデートしているわけでもないので、今でも十分通用する）

最近になってgithub.comとgitlab.comのどちらも使用するようにしたので、リモートリポジトリを間違えないようにホスト名を表示できるように修正した。

リモートリポジトリのホスト名を取得する

git ls-remote --get-urlでリモートリポジトリのURLを取得できる。このURLは.git/configに記載されているものが表示されるようになっている。たぶんgit remote add origin REMOTE_REPOSITORYで設定したものと同じになるはず。リモートが複数設定されている場合にどうなるか未確認だが自分のユースケースではそれはあまりないので、気にせず使っている。

git@github.com:kawaken/dotfilesという構成になっている場合が多いので、:と@で分割してホスト名に該当しそうな箇所を拾っている。

hostname=$(git ls-remote --get-url | cut -d: -f1 | cut -d@ -f2)

プロンプトに表示する

自分の場合はhook_com[branch]の中に混ぜ込むようにしている。 https://github.com/kawaken/dotfiles/blob/master/zsh/vcs_info#L54

-    echo "%f${arrow}%F{cyan}${remote}%f${(j:/:)gitstatus}"
+    echo "%f${arrow}%F{cyan}${remote}(${hostname})%f${(j:/:)gitstatus}"

最終的にはこんな感じで表示される。

f:id:kentaro_kawano:20180926234632p:plain

出力結果が長い

ホスト名が出るのは良いが、ちょっと長いので短くしたい。ここで以前書いたホスト名を短くする手法を使う。SSH_CONFIGを使用してgitのリポジトリURLを短縮する

# gh = git@github.com
git remote rm origin
git remote add origin gh:kawaken/dotfiles
git branch -u origin/master

f:id:kentaro_kawano:20180926234611p:plain

シンプルな表示になった。

2018-09-20

GitLabCIの結果をGitHubにコミットする

hugoで生成したHTMLをコミットしたかったのでやってみた。

SSHのキーペアを作成する

既存のものは使い回したくないんで、新規に作成する。

$ ssh-keygen -f id_rsa_gl2gh

作った鍵は以下のように使用する。

公開鍵 -> GitHubのDeploy keyとして設定する
秘密鍵 -> GitLab CIのVariableに設定する

GitHubでのDeploy keyの設定

コミットしたいリポジトリの設定から、作成した公開鍵をDeploy keyに追加する。追加したあと、SSHで接続の確認をする。

$ ssh -i id_rsa_gl2gh git@github.com
PTY allocation request failed on channel 0
Hi kawaken/kawaken.me! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

普段使っている鍵と違い、ユーザ名と特定のリポジトリ名が表示されている。

GitLabCIのVariableの設定

GitLabCIでは実行中の環境変数を外部から設定できるようになっている。プロジェクトのSettings -> CI/CDのVariableの設定に、Key/Valueの組み合わせを登録する。

Key名をSSH_PRIVATE_KEYにして、秘密鍵を登録する。

UI上は短い一行の値しか入力できないように見えるが、複数行の内容でも問題なく設定できる。

GitLab CIの設定

Using SSH keys with GitLab CI/CD | GitLab におおまかな手順は載っているが、ちょっと修正が必要になる。

自分は以下のような設定になった。

before_script:
# SSH用のディレクトリ作成
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh
# github.comのSSH host keysを保存する
  - apt-get update -y && apt-get install openssh-client -y
  - ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
# ssh-agentの設定
  - eval $(ssh-agent -s)
  - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null
# git のユーザ情報設定
  - git config --global user.email "user@example.com"
  - git config --global user.name "Kentaro Kawano"

to_github:
  stage: build
  script:
    - rm -fr public
    - git clone git@github.com:kawaken/kawaken.me.git public
    - hugo
    - cd public
    - export MESSAGE="update $(date +'%F %T')"
    - git add -A .
    - git status
    - git commit -m "${MESSAGE}"
    - git push origin master

  only:
    - master

更新対象のリポジトリをhugoの出力ディレクトリとし、変更をすべてコミット&プッシュするようにした。

git statusを途中で実行しているのは、何が対象となったかをGitLabのJobのログに残したいため。