左右分割型のキーボードを椅子に固定してみた。 今回使ったキーボードは、Keyball39。左右に分かれているタイプで、左右合わせて合計39個のキーが搭載されており、右手側にトラックボールが付いているキーボード。 このキーボードの底面に鉄板を貼り、椅子から生やしたアームに磁気式の雲台で固定し、磁気式のUSBケーブルで配線してみよう、というのが今回の試みです。なお、以前には別のアプローチとして、机に固定する方法を紹介しました。 分割キーボードを机に固定 Corne V4 Chocolateのときはケース内底面に鉄板を貼りましたが、今回は底面のアクリル板に直接鉄板を貼ってみることに。剥がしやすくするために、マスキングテープの上から貼り付けました。 Amazon | ［エムティ］スチールプレート （マグネット吸着用） シルバー 正方形 ■ 24x24mm / 裏面超強力1mm厚シール付 10枚入（

左右分割型のキーボードを机に固定してみた。 今回使ったキーボードは、Corne V4 Chocolate。左右に分かれているタイプで、左右合わせて合計46個の背の低いキーが搭載されており、はんだ付け不要な簡単組み立てキットが販売されている、初心者にもおすすめのキーボード。 このキーボードのケース内底面に鉄板を貼り、机から生やしたアームに磁石型マウントで固定しよう、というのが今回の試みです。 このキーボードのケース内底面には格子状にでっぱりが付いているので、大きな鉄板一枚を貼るのは難しい。そこで、小さな鉄板を複数枚貼り合わせていく。世の中には両面テープ付きの小さな鉄板がまとめて売られているので、それを使います。今回はこの正方形のやつと円形のやつをそれぞれ10枚ずつ貼ってみたところ、十分な磁力を得られました。 Amazon | ［エムティ］スチールプレート （マグネット吸着用） シルバー 小

新しいPCを組んだ。 自作PCを組むのはこれで二台目。一台目については以下の記事で紹介している。 自作PC2021 前回の組み立て時に基本的な部分を学べたので、今回は一度やってみたかった本格水冷に挑戦してみることにした。 組み立て後 組み立て前 この記事では、利用した各部品を紹介していく。前半では水冷にあまり関係無い部分、後半では水冷に関係する部分に触れる。自作PC2027を書くことになる頃合いで読み返したい。 ケース Lian LiのO11 EVO RGBを利用した。 Amazon | LIANLI E-ATX対応ミドルタワーPCケース O11D EVO RGB Black リバーシブルデザイン E-ATX（幅280mm以下） / ATX/Micro ATX/Mini-ITX規格対応 RGBストリップ標準搭載 420mmラジエーター搭載可能 日本正規代理店品 | リアンリー(Li LIA

コードレスドライヤーはいいぞ。 ドライヤー本体の様子 自分が使っているのは、Zuviという会社の製品。 Zuvi Halo 光ヘアケアコードレスドライヤー Zuviは香港のスタートアップ企業で、製品開発は深センで行っているとのこと。日本法人はZuvi Japan株式会社。 充電時間は30分ぐらいで、最大風量でも約15分は使える。風量は前まで使ってたDysonのドライヤーより強いぐらいなので、かなり強力。温度はぬるめ。高温多湿な脱衣所で乾かすより、リビングで落ち着いて乾かす方が好きなので、最近は専らリビングに持ち込んで使っている。自分以外 (特に小さい子とか) を乾かすのにも便利かも。テレビでも見てもらっておけばいいし。 充電スタンドに置いた様子 重量は630g。例えば最近のPanasonicの良いやつ EH-NA0J-W だと本体重量が550g、Dysonの良いやつ Supersonic

結論から言うと、node_modulesをキャッシュしてnpm ciの実行を省略するのが、多くの場合には有効そうです。 はじめに CIで npm ci を使うとき、実行時間短縮のためにキャッシュの利用を検討することになると思います。このとき、どのようにキャッシュするのが良いのでしょうか？ よく知られているキャッシュ方式として、以下の二通りの方式があります。 ~/.npmをキャッシュする方式 node_modulesをキャッシュする方式 それぞれの違いについて、詳しく見てみましょう。 ~/.npmをキャッシュする方式 npm ci を実行すると、POSIX系のOSではデフォルトで ~/.npm にキャッシュデータが書き込まれます。package-lock.json をキーにこのディレクトリをキャッシュしておくことで、次回以降の npm ci 実行時にこのキャッシュデータを利用しよう、というの

参加しているプロジェクトで、RailsアプリのCIの高速化を行った。 まだ進行中の部分も幾つかあるが、結果から言うと、元々8分前後だったテストが3分半程度に短縮された。行った作業を幾つかの観点に分け、どのように高速化を行ったか、どの程度高速化されたか等を記述する。 プロセス数とマシン性能の調整 元々は2コア1プロセス4マシンで8分程度掛かっていたが、8コア8プロセス1マシンに変更することで5分程度に短縮された。 このプロジェクトではCIにGitHub Actionsを利用している。GitHub Actionsではデフォルトで2コアのマシンが利用されるが、Large runnerを利用して8コアに変更した。費用は変わらない。 また同時に、8プロセスで並列実行するためにparallel_testsを導入した。このプロジェクトではMySQLとElasticsearchを利用しており、またファイル

GitHub Actionsでテストファイルを複数ノードに適切に分割するためのカスタムアクション、r7kamura/split-tests-by-timingsを作った。 CircleCIに同様の仕組みがあり、今回はこれのGitHub Actions版が欲しかった。 既存ツールとして、Go製のleonid-shevtsov/split_testsというCLIツールがあり、これを利用するchaosaffe/split-testsというカスタムアクションがある。 このカスタムアクションでも不足は無かったが、幾つかの理由で今回自作するに至った。 しばらく使いそうなので、保守性を上げるためにも、不要な機能を取り除いて必要最低限の機能にしたかった GitHub Actionsは仕様変更が多いため、自分で保守できるようにしたかった 今回、内部実装としてRust製のmtsmfm/split-testとい

GitHub Codespacesをちょっと試した。 初期導入時にハマりどころも多いけど、真面目に設定しておけば、普通にCodespacesの環境だけで開発することは十分できそうだなと感じた。リポジトリ単位で環境を用意するのが基本で、多くのリポジトリに対して毎日のようにレビューをしたりPull Requestを出したり、みたいな開発フローには綺麗にはまらないと思うけど、普通に仕事で単一のリポジトリに対してだけ作業する用途であれば上手くはまると思う。Zoomで会議しながら重い処理を実行していても影響が無いのは良かった。Zoomで会議しながら重い処理を回すべきではないという意見もある。 Codespacesの利用の流れ Codepsacesを利用するときの流れについて。まず、予め .devcontainer/devcontainer.json を配置したリポジトリを用意しておく。Codespa

最近は下記のようにライブラリ等のリリースを自動化している。 バージョンを入力するとPull Requestを生成 Mergeするとリリース ラベルの管理 前回のリリース以降にMergeされたPull Requestからリリースノートが自動生成されてほしい。このとき、Keep a Changelogの形式を参考に、変更点が以下の7種類に分類されてほしい。 add change deprecate fix remove security other そこで、Pull Requestに予めラベルを付けておくことで、どの節に分類するかを決定させる。またこのようなラベリングの習慣を設けることで、各Pull Requestの粒度の是正もねらう。ラベルを利用したリリースノート自動生成機能自体はGitHubが備えているので、.github/release.ymlでそのラベルを使う旨を指定すれば良い。 この

良かったものを年末にまとめる回、2022年版。 ストレスレストーキョー PC作業用のデスクチェアとして使い始めたら大成功。元々はリビング用だった。 前に書いた記事: ストレスレストーキョーで作業 前に書いた記事: ストレスレストーキョーのリクライニングチェア Amazon｜EKORNES [正規品]ストレスレス®トーキョー スター ブラック/マットブラック チェアのみ mサイズ｜リクライニングチェア オンライン通販 エルゴトロンLX デュアル 長身ポール ディスプレイを支える技術。横長ディスプレイ上下2枚×リクライニングチェアの組み合わせが絶妙に噛み合っている。たまに縦長の絵を大きく表示したいときがあり、上側のディスプレイを引っ張って回すだけですぐ縦長にできるのも便利。 前に書いた記事: エルゴトロン LX デュアル Amazon.co.jp: エルゴトロン LX デスク デュアル モニタ

みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内