Helixビルドログ

2018年3月に自作キーボードを作った際のビルドログになります。

Helix Keyboardとは

左右分離、格子配列、ロープロファイルスイッチに対応した自作キーボードキットです。

https://yushakobo.jp/shop/helix-keyboard-kit/

私自身は自作キーボードを作るのは2作目で、1作目はViterbi Keyboardを組み立てて自宅で利用しています。

なぜ自作キーボードなの？

  • 自宅でも会社でもAppleの標準キーボードを使い続けていたが、最近肩こりが重くなってきた
    • 分離キーボードを試してみたかったが、普段JIS配列を利用しているのでUS配列に即座にスイッチできない
  •  格子型キーボードのほうが指が合理的に動くことを知っていた
    • 以前Ergodox EZを借りて使っていたことがあり、運指自体は理想的だった
      • では何故Ergodoxではダメだったかと言うと、右手側のキー数が理想からあと1列足りなかった

と動機はいくらでも上がりそうなのですが、何より「楽しい」ことが強いモチベーションとなってます。

Helixを選択した理由

  • 一度Viterbi Keyboardを作ってみたが、もともとMac遣いなのもあってロープロファイルのほうが指が合いそう
  • かっこいい
  • めっちゃ光る（これについては結局使わなかった反省）
  • キー数がやや多い（理想はViterbiと同様の7×5列）

構成

昨年末にあったGroup Buyに乗っかったので、フル構成にしています。

  • ステンレスプレート版（アクリルは剛性が心配だった）
  • バックライト版（フルカラーLEDを全てのキーの後ろにつける版）
  • キーキャップは雰囲気で決めたかったので、文字あり白、無地白、無地黒の3種類を購入

準備

大体手持ちの工具なんかで対応できたいのですが、2つほど追加で用意しました。

  • 温度調整機能付きはんだごて
    • Twitterを見る限り、LEDを壊さずにつけるのに必須のようだったので
    • これを買っとけば間違いない。
      [amazonjs asin=”B006MQD7M4″ locale=”JP” title=”白光 ダイヤル式温度制御はんだこて FX600″]
  • ハンダ
    • はんだ付け箇所が多そうだったので
    • 鉛の含有率が低いハンダを買ってしまい、低温での溶けにくくて困った

部品の確認とLED実装


こんな感じで一式届きました。

  • スチールプレート
    • Viterbiとほぼ同じくらい
    •  基盤
      • 同じパーツを表裏で使って左右に分けます。写真ボケてしまってますが。
  • キーキャップ
    • 文字入りはHelixで利用しないものも入っていました
  • スイッチ
    • 写真がありませんが、茶軸を選びました
  • ダイオード
    • チップとリードを選択できるが、マゾ属性が無いのであればリードをお勧めします。特に見た目に影響が無いのに苦労すること請け合い。
  • LED
    • とにかくこれが辛い。穴にキレイに嵌らない状態でハンダ付すると大体接触不良、時間を掛けて接続させると温度で死にます。
      • 他の方は治具を作ったり、耐熱テープで固定したり工夫していました。私は面倒で曲がったままのものが多数。
    • 温度でLEDが死んだかどうかも分かりづらいのも難易度を上げます。とにかくテスターを多用して接続チェックしつつ最小限の時間で取り付けましたが、70個中2個は完全に沈黙。（予備がいくつか入っているので助かりました）
      • キーを取り付ける前にファームウェアを焼いて、都度確認しました

キースイッチ実装とキーキャップ装着

  • LEDの動作確認が終わったら、スチールプレートにキーを差し込み、裏から基盤にはんだ付けします。
  • スチールプレートからキーがポロポロ取れるので、マスキングテープなどでキーを留めると良いと思います。
  • 裏のスチールプレートを留める際、かなり隙間が無いのでカプトンテープを貼って絶縁しました。

    [amazonjs asin=”B01J7FLFUM” locale=”JP” title=”waves ポリイミド 絶縁 耐熱 テープ 50mm”]
  • あとはキーをはめれば完成。

雑感

  • OLEDディスプレイは無くとも、あと1列右側にキーが欲しくなる。
    • JIS配列に慣れてしまうと右側にキーがあと1列分欲しい。
    • キー配列は試行錯誤した結果、ハイフン「ー」をレイヤーに押しやる苦渋の決断をしました。
  • キーボードバックライトはとてもとても美しいのですが、会社で使うには煩わしくなってしまい、結局切って使っています。
  • 自作キーボードはハードウェアとソフトウェアの両面から楽しめて、実用にもつながりとにかく素晴らしい。エンジニアなら全員やるべき。

次はPCB設計からやってみたい。

 

【読書メモ】マネジメントとは何か

通勤時間で読んでいた本も何とか年内に読了。各ケースが短く分かれていて読みやすく、明快な言葉、内容も実践的で素晴らしかった。マネジメントで悩んだらこの本に戻ることになりそう。

[amazonjs asin=”4797372605″ locale=”JP” title=”マネジメントとは何か”]

【読書メモ】ワーク・シフト　─孤独と貧困から自由になる働き方の未来図<2025>

休暇中の課題図書を読む。エンジニア向けに書かれたものではないが、シリアルスペシャリストを目指せ、というメッセージはエンジニアの考え方と相性が良い。（もちろん書いてある全てを鵜呑みにすべきではないけれど）

「ある技能が他の技能より高い価値を持つということはどういう場合なのか」という抽象的な切り口は、普段の私は思いつかないので思考を深くするいい機会だった。

[amazonjs asin=”B009DFJE9Q” locale=”JP” title=”ワーク・シフト　─孤独と貧困から自由になる働き方の未来図”]

AccountManager と Self-Issued OP は共存するのか（しない）

経緯

前職の後輩より、AndroidでのAccountManagerの実装について問い合わせを受けました。詳細を確認したところ、「スマホアプリで認証連携を検討した際に、OpenIDのSelf-Issued OPを使いたいとの要件があるため、秘密鍵の管理をAccountManagerでやりたい」という趣旨でしたので、ちょっと調べてみました。

はて、

そもそも、「秘密鍵管理する」ということはどういうことか？これは OpenID の Self-Issued OP の仕組みに起因しています。Self-Issued OPについて誤解を恐れず非常にざっくり説明すると、「OpenID の管理をスマホ内に入れて、そこから他のアプリやブラウザからのログインなり何なりを認可連携させる仕組み」です。イメージとしては、OpenIDを管理するアプリを入れ、そこにログインだけしておけば、他のアプリやブラウザからのログインはOpenID経由と同じ仕組でアプリ内ですべてまとめてやってくれる、という仕組になります。GoogleとかYahooとかに頼らなくても、IDプロバイダからは独立してスマホ内でアカウントを管理するということです。

一方、AccountManagerは、Android内にアプリのID/Password/Tokenを比較的安全に保存し、他のアプリに認証サービスを提供するためのものです。

どっちも同じようなもの？それになんか便利そう？

いやいや、結局のところ、このSelf-Issued OPのアプリを解析されたら認証・認可の機能を乗っ取られかねません。保存すべき秘密鍵はどう管理するのか、root取られたらどうするのか、、、。
では、AccountManagerで秘密鍵などを管理させたら？というのがこの問い合わせに至った、という経緯なわけで。

そもそも求めている状態は何か？

Self-Issued OPアプリと、それを利用するRPのアプリが同一パブリッシャーの場合は、Self-Issued OPなんて面倒なことをやらないで、共通アカウントをAccoutMangaerに格納するほうが現実的じゃないかと。そこがパブリッシャーの場合はAccountManagerは使えないですが、だからといって Self Issued-OP を独自アプリに採用するのはちょっと、、、という感じですね。OSレベルでの実装であれば使い勝手も良くなるとは思いますが。
というわけで、OpenIDを使いたいという気持ちはわかるものの、今のSelf Issued-OPの仕組に乗っかるのはセキュリティ的に気になります。アプリが同一署名である必要がある、という制限がありますが、AccountManagerが近い形で実装はできるので、こちらからアプローチするのが適切かと思われます。

知識は陳腐化する

OpenIDを触っていたのが3年以上前なので、まったく見当違いなことを言っている可能性もありますが、ツッコミありましたらコメントでお願いします。

【読了】幸せな死のために一刻も早くあなたにお伝えしたいこと

若い医師から見た生と死について。素晴らしい本だった。下手な感想を伝えるよりも、とにかく読んでいただきたい。

[amazonjs asin=”4344983777″ locale=”JP” title=”幸せな死のために一刻も早くあなたにお伝えしたいこと 若き外科医が見つめた「いのち」の現場三百六十五日 (幻冬舎新書)”]

クラウドソーシング所感

ここ1ヶ月ほど、全く仕事とは関係無いところでゲーム開発をしています。
ゲームそのものを、というより、比較的大規模なモノ作りプロセスを自分で廻したくて（あわよくば仕事にフィードバックしようかと）実践しているのですが、その中の幾つかのプロセスでクラウドソーシングを試しておりまして、幾つか気がついたことがあったので所感を。

・クラウドソーシングの拡大

ゲーム内のキャラクターを幾つか用意するためにクラウドソーシングを利用したのですが、実際試してみて初めて、クラウドソーシングは今後大きく成長する市場になりうると実感しました。

とにかく発注金額が圧倒的に低い。海外のサービスも試しましたが、海外は更に低い。

特に、アウトプットの着地が分かりやすいものについては依頼しやすいので、クオリティを下げずに発注することができます。また個人対応が多いので、柔軟性のある対応を求めることもある程度可能です。
実際に金額をやや抑えて発注しても、かなりレベルの高いものを出してくるデザイナーが何人も出てくるし、後からの修正も（誰もがそうというわけではないでしようが）柔軟に応じていただけました。

・一方でクラウドソーシングの問題

こちらは3Dモデル発注をした際に感じたことですが、特に技術練度を要するような作業については、品質にモロに影響がでてしまいます。

あるセミプロレベルの方に発注した際は完全に失敗して、微妙なアウトプットが出てきてしまいました。

クラウドソーシングでは相手側が個人で請け負っている場合が多く、法人同士の付き合いでは当然行われる逐次のアウトプット確認などがしにくく、また、個人のスキルの問題なので、これ以上クオリティを上げてくれ、という依頼が出来ないため、再度別の方に依頼するなどのオペレーションが必要となってしまいました。

・クラウドソーシング内の市場

上記に関連しますが、クラウドソーシング内でも需要供給のバランスがあるのが興味深いです。

例えばイラスト作成は供給側が完全に過多になっていてバランスが崩れています。

120点のイラストが書ける一部の神レベルの作家は適正な価格での受注が維持できると思われるのですが、80点位の作家は見合った報酬を受け取るのはかなり難しいと思われます。

・クラウドソーシングでの海外発注

海外に3Dモデリングを海外に出した際に想定金額を思い切って下げたのですが、それでも請け負うデザイナーが世界中にいるのに驚きました。

実際には日本の相場の数分の一で、ウクライナ・マレーシア・ブルガリアなどから受注可能とメッセージが来ます。

ただ、実際に発注すると、日本と海外の違いは言語だけではなく「仕事への取り組み度合い」であることを痛感します。

まず、仕事に対するコミットが非常に緩い。普通に連絡が取れなくなる受注者が出る。出来高払いなので金額的な損失は無いのですが、別のデザイナーへの発注が遅れるので時間的損失が大きいです。

そのように考えると、プロレベルの仕事を発注するには、海外に出さず日本人に依頼するがまだ妥当だと思われます。
ちなみにアメリカ人は円安もあって日本よりもずっと高い見積もりでした。アウトプットは良さそうだったんですが。

引き続きゲーム開発で思った所感など書いていきます。