タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
はじめに 2020年の11月末。 なんとなく自作キーボードでも始めて見るかと思い付きました。 それまで自分にとって自作キーボードはハードウェア技術的にも既知で、 さらに長年使い続けたHHKBから乗り換える気も起こらず見向きもしなかったわけですが 「実際にやってもいないのにわかった気になるのは頭でっかちでよくないな」 と考えてやってみることにしたのです。 ということでやってみて見事にハマりまして 始めて1か月で数台のキーボードを組み立て この5か月で10台を超え20台に迫る勢いでキーボードを組み立て・設計・制作するに至りました。 この記事では自分が作ってきたキーボードたちを振り返ってみたいと思います。 なにぶん数が多いので1つのキーボードにつきなるべく量を絞って以下の観点から書き下していきます。 なぜそのキーボードを選択したのか(作ろうと思ったのか) 作った際の特徴、思い出話とかあれば 作っ
HHKB Studio レビュー — KaoriYa
2023/10/25発売のHHKB Studioを購入し、構成・構造を細部まで検証したのでレビューします。 注意: 詳細レビューは執筆中で、随時追記しています。ひとまず総評まで読んでいってください。 レビューする私の立場 私はHHKB Studioの購入者です。 特にどこからか提供や依頼を受けてのレビューではありません。 またHHKBの従来品の愛用者でした。 初期のHHKB Professionalから始まり、 Pro 2、Type-S、HYBRID Type-Sまで色違いや予備品も含めて 合計7台を所有しています。 加えて2020年末より自作キーボードに傾倒しました。 短期間で大量のキットを組み立てたり、 自ら回路を設計したり、 ファームウェアを書き起こしたり、 あのKeyballシリーズのファームウェアを担当したり と 自作キーボードとポインティングデバイスに関する一定以上の知見を持っ
golangで書いたプログラムをDockerで動かしOOMが発生した際になるべく情報を残して殺される方法を紹介します。 2020/08/16追記: この記事の内容はgolangに関してはやや現実的ではなくなってしまいました。 詳しくは続編を参照してください。 TL;DR golang製のプログラムは仮想メモリ(VSZ)の確保に失敗するとgoroutineのダンプを吐いて死ぬ DockerのOOMはRSSベースで検出時にSIGKILLを投げてくる Docker利用時にVSZで制限をかけるスクリプトを書いた golang製のプログラムはlinux-amd64において最低でも101MBのVSZを要求する VSZの制限がそれより小さいと当然起動できない 実際のRSSは3MB程度で起動する Background コンテナ内で動いているプロダクション上のgolang製のプログラムが時々OOMに殺されて
golangでテストのためだけにinterfaceを書くのが死ぬほど嫌だったので編み出した技を紹介します。 TL;DR テスト(=mock)のためだけにinterfaceは切りたくない 型エイリアスとビルドタグを組み合わせるとinterfaceがなくてもモックが作れる この手法に必要なモックを自動生成するプログラムを作った interfaceは本当に必要なシーンで使うべき Background 現在モックを使った単体テストは一般的です。 Javaでの例を挙げると、モックしたいコンポーネントについて予めinterfaceを定義しておき、モックではそのインターフェースを実装するのが定石です。 しかしgolangのinterfaceはJavaなどのそれとは若干性質が異なるため、テスト=モックのためだけにinterfaceを書くのはオーバーワーク気味です。 そうテストのためだけにinterface
正規表現はVimに限らずコンピューター上でのテキスト操作において非常に強力です。 しかし学習の難しさも非情で多くのIT技術者、Vimmerが正規表現に苦しんでいるのを幾度となく目の当たりにしています。 ただ正規表現は本当にそんなに難しいのでしょうか。 いいえそんなことはありません。 正規表現は本来とても簡単な原理で学習も容易なのです。 にも関わらず難しいと思われてしまうのは、原理を理解しないまま外見上の機能をそのまま覚えようとするからです。 本記事では正規表現の原理にフォーカスし解説することで、Vimを含む様々な正規表現実装の利用難度を適切にしようという記事です。 本記事は Vim Advent Calendar 2019 の1日目の記事です。 「正規表現」はもともと形式言語という言語学の一分野の研究から生まれました。 言語学というのは言葉を科学的に研究する学問です。 形式言語はその中でも
前の記事:golangとDockerとOOM を書いた後で Go側の事情に変化があったため、 あの記事に書かれた方法は現実的な選択肢ではなくなってしまいました。 この記事では私が使っているGo 1.14以降でのOOM対策と、 どうしてそうせざるを得なかったのか解説をお届けします。 TL;DR Goの64ビット版はVSZの最小要求量が大幅に拡大した (500MB超) 前の記事で紹介した方法が現実的ではなくなった VSZの制限をRSSに転用する=最低でも500MBのRSSを設定することになる 代わりに自プロセスのRSSを監視して閾値を超えたらアポトーシスするようにした RSS取得用のkoron-go/phymemパッケージを作成した Background あの記事を書いた翌月末にGo 1.14がリリースされました。 その変更点の中に以下の記述があります。 The page allocator
Docker Desktop for Windows と VirtualBox を共存できないか試していて、 もっとも納得できていない現象を紹介します。 本記事はトライしたけどできなかった系のお話から始まります。 さらに妥協した方法を模索しているうちに不可解な現象に遭遇しました。 たまたまその不可解な現象の回避方法を発見しましたが、 どうしてそれがうまく機能するのかはわかっていません。 教えてもらったことをきっかけに正しい理解を得ました。 詳しくはこちらの 追加記事 をご確認ください。 TL;DR Docker Desktop for Windows の仮想スイッチ vEthernet (DockerNAT) が生きてると、VirtualBox のポートフォワーディングで 1688 から 2279 の範囲が利用できなくなる ネットワークアダプタ vEthernet (DockerNAT)
go get の動作メモ — KaoriYa
TL;DR module 有効下の go get は -u 相当 (バージョン未指定なら) go.mod の module には /v{2以上の値} という suffix でメジャーバージョンを書く必要がある 省略すると v0 もしくは v1 とみなされる 取得時には go get example.org/foo/bar/v2 のようにする パッケージを取ってくるときはこれで良いが、コマンドの時はリリース済みのメジャーバージョンを機械的に知る方法がないのでキツいね 髄記 言わずと知れた go get 、Goのパッケージをインストールしたり、コマンドをインストールしてくれたり、バージョン管理してくれる偉いやつ。 調べてみると module が有効かどうかで振る舞いが変わるらしい。 src/cmd/go 下をみると module かどうかでコマンドそのものが入れ替わってる。 internal/
自作キーボードを始めてちょうど1年。 前回の報告より約7か月。 その遍歴を振り返ってみたいと思います。 はじめに 2020年12月3日の夜中に人生初の自作キーボードに組み立て始めました。 そのまま徹夜をしてちょうど1年前の今日12月4日に自分だけのErgoDashを手にしました。 (前回の記事参照) 怒涛の如くキーボードを組み立てたことを紹介した前回の報告記事から約7か月間、 私が何をやっていたのかダイジェストで振り返ってみます。 そして記事の終盤にはコミックマーケット99における頒布物の宣伝があります。 4月下旬～5月上旬 まず何と言ってもその後HHKBを置き換えて常用することになる YUIOP60HH4 が完成しました。 現場でYUIOP60HH4がHHKBを置き換える瞬間 YUIOP60HH4 は、 自作キーボード活動を続けてる際に出会った Everglide Dark Jadeキー
time.Timer は使ってますか? とても基本的な要素なのですが意外と正しい使い方は難しいのです。 つい先日ハマった事例とともにその正しい使い方を紹介します。 この記事は Go Advent Calendar 2019 の21日目の記事です。 皆さんは time.Timer は使ってますか? Timer は指定時間経過後に C <-chan Time に現在時刻が 1回だけ投入されるという極めてシンプルな型です。 メソッドも Stop() と Reset() の2つだけと少なくシンプルです。 そう…シンプルなのですが正しく使うには2つほど大事な注意事項があります。 この記事ではそれらを解説します。 TL;DR time.Timer#Stop() 後に time.Timer.C を読み捨てなければいけない場合がある
本記事は前回の DockerNATが一部のポートを潰しちゃう話 を読んでることを前提に書かれています。 まだの方は先にそちらを読んでからこちらをどうぞ。 TL;DR Windows には「ポート除外範囲」(excludedportrange)という指定した範囲のポートの利用を禁ずる機能がある 実は「ポート除外範囲」には2種類ある エフェメラルポートの動的割当から除外する 特定プログラムが予約し、そのプログラム以外からの利用を禁ずる 2種類とも同じコマンドで確認できるのでややこしい Hyper-Vをインストールする前に「ポート除外範囲」を追加するのが良い コマンド例: > netsh int ipv4 add excludedportrange protocol=tcp startport=2222 numberofports=1 経緯 前回の記事 を公開したところ、 ある方から以下のような
最近は Vim でコードを書くことがなくなり、RubyMine や Visual Studio Code を使うことが多いが、ちょっとしたファイルの内容を確認する時に Vim を使うことがある。 昔から Mac で Vim を使うために MacVim-KaoriYa のお世話になっていたのだが、 2018 年頃からメンテナンスが止まっており、Big Sur にアップデートしたあたりから GVim でカーソルを移動したり、スクロールすると描画が壊れるようになった。 さすがにこのまま使い続けることは難しいので MacVim に切り替えることにした。 GitHub - macvim-dev/macvim: Vim - the text editor - for macOS 元々 MacVim-KaoriYa は、この MacVim をベースに香り屋さんのパッチを当てて日本語化したもの。 本家の
SRVレコードDialer — KaoriYa
Go2 Advent Calendar 2019 8日目の参加記事です。 TL;DR SRVレコードで Dial() できる koron-go/dialsrv を作った dialsrv.Dialer は net.Dialer をラップする形で互換インタフェースを備えている HTTP も gRPC も SRV レコード越しで接続できるようになる nomad のようなオーケストレーションツールで動かすアプリで使う想定 SRV レコード Dialer 皆さんはDNSをひいてますか? いえこのページを見れているということはDNSをひけていることはわかってます。 ですがそれを普段から意識している人は少ないはずです。 まずはちょっとこのDNSを意識してみましょう。 DNSというのは名前をIPアドレスに変換するためのデータベースです。 ブラウザがこのDNSに www.kaoriya.net という名前を
Keyball61の一般販売に寄せて — KaoriYa
2022/03/02の昼12時よりトラックボール付き自作キーボードKeyball61が一般販売されます。 販売を記念してファームウェアを担当した身としてKeyball61の魅力をかなり角度を付けて語りたいと思います。 2022/03/02の昼12時よりトラックボール付き自作キーボードKeyball61が一般販売されます。 販売を記念してファームウェアを担当した身としてKeyball61の魅力をかなり角度を付けて語りたいと思います。 明日3/2㈬の昼12時から #Keyball61 の初期ロットを10セットだけ販売開始します！初回はLEDおまけ付きです 量産版供給はその一週間後くらいの予定です。よろしくお願いします🙏https://t.co/FL8TvBTooE — 白銀ラボ ﾖｰｷｰｽ🎱 (@Yowkees) March 1, 2022 Keyball46との関り Keyball61を
MacVim-KaoriYa から MacVim + vim-kaoriya に移行してみました。 splhack/macvim-kaoriya: MacVim-KaoriYa MacVim by macvim-dev koron/vim-kaoriya: Vim+kaoriya build system 方針 MacVim と vim-kaoriya の中身を変更しない。 MacVim-KaoriYa 固有の vimrc 設定を極力反映する。 UTF-8 と CP932 でエンコーディングされたファイルを変換不要にする。 macOS 以外でも極力影響のない vimrc にする。 手順 MacVim と vim-kaoriya のインストール brew install macvim test -d ~/.vim || mkdir ~/.vim git clone https://githu
背景 MacをBig SurにアップグレードしたところMacVim-KaoriYaが動作しなくなったのでその対応方法を共有致します。 結論だけいうと、以下の対応が必要でした。 環境設定の詳細で、「Core Textレンダラの使用する」のチェックを外す。 フォントをRictyにする。 症状と対応方法 1. 画面がまっくろになる MacVim-KaoriYaをウインドウを開くと、画面が真っ黒になりアプリが利用できません。。。 ■ 対応方法 環境設定の詳細で「Core Textレンダラの使用する」のチェックを外す。 2. カーソルなどの表示位置がおかしい フォントと利用しているプラグインの組み合わせで、カーソルなどの表示がおかしくなるようでした。 ■ 対応方法 フォントをMenloからRictyに変更することで解消しました。 ※ 解消後の画面 最後に Big SurへのアップデートでMacVim
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自作キーボードを始めて5か月の歩み — KaoriYa
golangとDockerとOOM — KaoriYa
テストのためだけに`interface`を書きたくないでござる — KaoriYa
Vimmerに捧げる正規表現の基礎中の基礎 — KaoriYa
その後のgolangと(Dockerと)OOM — KaoriYa
DockerNATが一部のポートを潰しちゃう話 — KaoriYa
2021年後半の自作キーボードの歩み — KaoriYa
time.Timer#Reset() の正しい使い方 — KaoriYa
一部のポートが潰されちゃう件と正しい回避方法 — KaoriYa
Mac の Vim を MacVim-KaoriYa から MacVim に切り替えた - 暇人じゃない
MacVim-KaoriYa から MacVim + vim-kaoriya に移行する - Qiita
Big SurにおけるMacVim-KaoriYaの動作設定 - Qiita
blog.livedoor.jp/kaana727
iphone-mania.jp
gigazine.net
www.youtube.com
www.hokkaido-gas.co.jp
gigazine.net