私のキーボード遍歴
ここ数年でキーボードを数種類使用してきたのでそのまとめです。 私がエンジニアになってからのキーボードを順を追って書いていきます。
1. ELECOMのキーボード
当時支給されていたノートPCのキーボードがUKっぽい感じで使いづらく、手取り早く購入したもの。
今思うとコスパは最高でした。 bluetoothだけどチャタリングもない、接続不良もなし。 1000円台だし最高と思った私は会社と家用で２つ購入。それでも3000円くらい。 なんでもいい！という方はこれだなーって思いました。
他のメンブレンに比べるとそんなに打ち心地も悪くないです。
2. ドン・キホーテのUSキーボード
新調したMacBookProがUSキーになったことがきっかけで、US配列の素晴らしさに気づいた頃。 ドンキで2000円くらいのパンダグラフ式USキーボードが販売されていました。 印字はMac仕様で文句なし。
しかし使用してみると
bluetooth接続はPCがスリープしたらシステム環境設定で都度設定しなおし なんか打ちづらい 特に１つ目に関しては本当にストレスでした。。
3. MacBookProのキーボード
会社支給のPCがMacになった頃、本体のキーボードでも問題がないことに気づきます。 確か2015年モデルで配列は日本語でした。
ただ開発しているとノートPCはシューシュー鳴って熱くなる。 そして手汗を書く -> トラックパッドの滑りがなくなる という悪循環。
仕事終了間際は明らかに「あ、この人手汗すごい」みたいになってました。
4. HHKB Lite2 for Mac
キーボードで頭を悩ませている最中、隣の席の先輩がいいタイピング音を出していました。 それがPFUのHHKB Lite2。
Happy Hacking Keyboardってなんじそりゃーと調べたらもうすぐに引き込まれました。
ただ、HHKB上位モデルは高い！ 宮城県民の私はHHKBの操作感を試すことが容易ではありません。 3万円出して失敗するのが怖くなり、Liteを購入することに。
本当に良くできた製品で、メンブレンなのに打ち心地よし！ タイピングがスムーズになったことに感動し、キーボードって大事だなとこの時強く思いました。
またタミヤのグリスをキーキャップ裏に塗ると静音化・打ち心地向上になることを知り実行。 これがまた良くて、ある先輩は「これ、静電容量無接点ですよ」と言っていました。
5. HHKB Lite2 for Mac（改造版）
Liteを使い続けていた私ですが、どうしても上位モデルへの憧れが捨てきれませんでした。 毎日メルカリをチェック。車で行ける範囲のハードオフも全て行きました。
しかし購入に踏み切れない、別にLiteに不満があるわけじゃない。
あるとすれば着脱できないケーブルが格好悪い。
ということでケーブルを着脱式に改造することにしました。
改造に付き合っていただいた先輩には今でも感謝しています。
このケーブルがとても邪魔。上位モデルは着脱式になっている。
元のUSBを切り、別売のUSBメスと繋ぐ。備え付けのUSBハブはスペースの関係で断ち切りました。。
見事着脱式に。尊師スタイルもストレスなくできるように。
真ん中からぴろーんとのびていたケーブルがなくなるとスッキリしますね
6. HHKB Lite2 2台目を購入
改造をすることで上位モデルにグッと近づくことを知り、持ち運び用に2台目を購入。 こちらも同じように改造を施しました。
２回目で少し慣れたのか、こちらはだいぶ綺麗に仕上げることができました。
はいかっこいい
7. HHKB Lite2 for Macを無刻印化
数字以外を無刻印にした
無刻印に憧れを抱き、どうにかLite2を無刻印化できないかとキーキャップを探すことに。
しかしメンブレンの無刻印キーが見つからず、あってもLite2に合うかなんてわからない。
じゃあ刻印を消せばいいのかと、紙やすりで刻印を夜な夜な削りました。 その結果大満足な仕上がりに（時間と労力は相当かけました）。
今思えば上位モデルを購入した方が効率的だったかもしれませんが、手塩にかけたキーボードにはそれなりの愛着が湧きました。
8. 分離キーボードへの興味
静電容量無接点方式以外はほぼ上位モデルに近づいたLite2に満足していたある日、自分の肩が開ききらない感覚に気がつきます。 骨の勉強をしている奥さんにも、普段の立ち姿がかなり前傾になっていることを指摘されました。
そこで分離キーボードに興味が湧き始めます。 肩を開きながらキーが打てるなんて最高だなーとか思いながら物色。 しかしHHKB慣れをしているため、他の配列が怖くなっていました。 （7sProとかあるにはあるんですが、やはりそれなりにお値段します。）
そんな時、こちらのブログを見つけました。
ブログ内から画像を拝借
「これはちょっとw」が第一印象だったのが著者の方に申し訳なく思います。
「これはさすがに・・・あ、俺できるじゃん」 といった感じでHHKB Lite2を2台所持していたのできてしまいました。
まさかのまさかでこれがとても良い。 分離になることで違和感とかすごいだろうなと思っていたのですがそんなこともなく、肩も開くし打ちやすいしこれだわ。 が感想です。
9. Mistel Barocco MD770
HHKB2台使用は良かったです。 ただ机幅のとりすぎが気になり、結局分離キーボードを購入することにしました。
HHKBの配列に合わせた分離型は完成品のものとしては無さそうで、あるとすれば自分で組み立てが必要なものばかり。
- 自作キーボードもそれなりにお値段はる
- 組み立てこわい
この２点を理由に完成品の中で一番それっぽそうな Mistel Baroco MD770を選択。 HHKBっぽく触れるようにキーキャップの位置、キーマップを少し変更しました。
Karabiner-Elementsにもだいぶお世話になったので、カスタマイズ関連は別記事でいつか書きたい。
初のメカニカルキーボード・赤軸は打ち心地もいいし満足しています。 またtypeCに対応していることや、cherry軸なのでキーキャップのカスタマイズが容易になりました。 無刻印にしたくなったら紙やすりは使わず、さくっと購入したいと思います。
10 まとめ
- なんでもいいから安くていいものを！
- USキーがいい！
- HHKBがいい！
- 上位モデル怖くて買えないから廉価版を近づけたい！
- 分離にしたい！
- 本物の分離キーボードが欲しい！
というのがここ数年の流れでした。 また好みが変わる可能性は大いにあり得ますが、MD770でかなり満足しておりしばらく使い続けたいと思います。
ESLintとか雰囲気で使ってたから
お手伝いさせてもらっているサービスで構文チェックをもちろんのこと導入されているですが、私自身雰囲気で使っていたのでまとめてみる回でございます。
ESLint
そもそもlintっていろんなlintがあるイメージですがlintってなんですかね。
lintとは、コンピュータプログラムなどのソースコードを読み込んで内容を分析し、問題点を指摘してくれる静的解析ツール。また、そのようなツールで解析を行うこと。ツールを指す場合は “linter” （リンター）と呼ぶこともある。 https://e-words.jp/w/lint.html
ソースコードの中に潜むバグの原因や、構文間違いを自動でチェックしてくれるツールを総称してlinterと呼ぶみたい。 この知ってるようで説明できないことを知れた感じが良いですね〜。 名前はECMA Script linterのことでしょうきっと。
例として下記。
import { hoge, huga } from './hogehuga.ts' export const piyo = () => { return hoge }
hugaをimportしているのに使用していない場合、eslintにかけると
'huga' is defined but never used
といった感じで怒ってくれる。
この機能ってバグを防ぐのは勿論なんですが、レビュワーの負担を減らす意味でも大きな効果がありますよね。 時間的な負担もありますが精神的な負担が減る。 「あーこう書いてるけどわざわざ言わなくてもいいかなー、バグにはならんし」 とか 「これ指摘したら細かすぎかなー」 とか。そういうことを考えなくてよくなるわけです。 変な気を使いたくない！
Prettier
読み方は「プリティア」。 prettyの比較級なので「よりきれい」とかそういう意味かな。 こちらはコードフォーマッターで、決められたきれいな形に整形してくれるものです。 よく取り上げられてる例が１行の長さに応じて改行に対応していること。
return { hoge, huga, hige, piyo, tiger, lion, horse, panda }
↓
return { hoge, huga, hige, piyo, tiger, lion, horse, panda, }
これも地味に大事で、短い行なら
return { hoge, hige }
でいいという人もいれば、必ず改行したい人もいたりする。
return { hoge, hige, }
でもそんな人もimport文では改行しない
import { hoge, hige } from './hogehige.ts'
なにが正解か誰もわからない。 だからpretteir様を正解にしよう。
ちなみにprettier-eslintなるものがあり、こちらを使用することでESLintとPritteir両方使えるようになるそうです。 https://github.com/prettier/prettier-eslint 開発しているプロダクトにもこれが入ってました。知らずに使ってた。
VTC
最後はTypeScriptの型チェック。 これはVue.jsに限った話ですがvue-type-checkというpackageがあり、単一ファイルコンポーネントの型チェックをしてくれます。 例えば型Userにないageが定義された場合
type User = { id: number name: string } const user: User = { id: 1, age: 20 }
vtcを実行すると下記のようなエラーを返してくれる
162:32 Type '{ id: number; age: number; }' is not assignable to type 'User'.
Object literal may only specify known properties, and 'age' does not exist in type 'User'.
160 | }
161 |
> 162 | const user: User = { id: 1, age: 20 }
さらにこれのいいところはtemplate内の型もちゃんとチェックしてくれること template内でUserに定義されていないnameを参照しようとすると
<template> <div> {{ user.name }} </div> </template> <script lang="ts"> ・ ・ ・ type User = { id: number age: number } const user: User = { id: 1, age: 20 } return { user } </script>
下記のようにエラーを返してくれます。
Property 'name' does not exist on type 'User'.
> 68 | {{ user.name }}
| ^^^^
意外と気付きにくい型エラーもチェックしてくれそうです。
以上 です。 もっといろんなツールがあるとは思うのですが、フロントエンド開発はこれらを入れておけば間違いないんじゃないかと🦑 だいぶなんとなくで使っていたし、必要性も再認識できたので書いてよかったでございます。
Nginxの名前の由来
有名なwebサーバの一つにNginxというものがあります。 「エンジンエックス」と読みます。
読めなくないですか？ 初めて知ったときは「いや読めませんよ」と思いました。
で、Nginxの名前の由来を調べたらたまにyoutubeでみるやっすんさんの記事に遭遇しました。
youtubeのリンクもあったので観ることにしました。
はい、ということで詳しく解説がありました。 要約すると
nginがなぜエンジンと読まれるかについては感覚というか、深い意味はなかったのでしょうかね。 一応製作者本人がお話しているということなので。
いやいや本当かよ！と思って本人が語る記事を見ました。
「エンジン」という発音が好きだったので、そこから紆余曲折を経て思いついた「Nginx」という名前は見た目もかっこいいしエンジンという音も含まれているので、これにしました。 tps://www.publickey1.jp/blog/14/nginxigor_sysoevnginx.html
本当でした。ありがとうございました。
近頃Githubから急に怒られるらしい
何が起きている？
GitHub に「パスワード認証」をやめろとずっと警告を出され続けていたが怠惰にも無視していたら，ついに
— ワトソン (@wtsnjp) 2021年8月15日
remote: Support for password authentication was removed on August 13, 2021.
と言われて使えなくなった🙃
そもそもこれはなんだということで、 https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations にアクセスしてgithubのブログへ。
Beginning August 13, 2021, we will no longer accept account passwords when authenticating Git operations on GitHub.com.
なるほど、去年から「来年8月13日でパスワードでアクセス（コマンドラインやアプリでgithubにアクセスすることを）させなくするよー」とは言ってたと。 ただ２要素認証を事前にしていればこの影響は受けないみたいです。 というのも、２要素認証をしている場合はhttpsのパスワードにトークンをセットする必要があるためです。
The following customers remain unaffected by this change: If you have two-factor authentication enabled for your account, you are already required to use token- or SSH-based authentication.
で、そもそもなぜこれをしたのかというのが
Despite these improvements, for historical reasons customers without two-factor authentication enabled have been able to continue to authenticate Git and API operations using only their GitHub username and password.
前文は省いていますが、要は二要素認証などで優れたセキュリティ対策が行えるにもかかわらず、 その設定を行わないアカウントはパスワードでgitを操作できてしまっていたというのが問題だったよう。
ではどうするか
下記記事を参考にmacのキーチェーンアクセスを変更すると解決するみたいですね。 （パスワードではなく発行したトークンを使用するようにする） https://zenn.dev/suzuki_hoge/articles/2021-08-github-access-f732e5b9868137
結論
せっかくだし二要素認証を設定しましょう
