分割キーボードを椅子に固定
左右分割型のキーボードを椅子に固定してみた。 今回使ったキーボードは、Keyball39。左右に分かれているタイプで、左右合わせて合計39個のキーが搭載されており、右手側にトラックボールが付いているキーボード。 このキーボードの底面に鉄板を貼り、椅子から生やしたアームに磁気式の雲台で固定し、磁気式のUSBケーブルで配線してみよう、というのが今回の試みです。なお、以前には別のアプローチとして、机に固定する方法を紹介しました。 分割キーボードを机に固定 Corne V4 Chocolateのときはケース内底面に鉄板を貼りましたが、今回は底面のアクリル板に直接鉄板を貼ってみることに。剥がしやすくするために、マスキングテープの上から貼り付けました。 Amazon | ［エムティ］スチールプレート （マグネット吸着用） シルバー 正方形 ■ 24x24mm / 裏面超強力1mm厚シール付 10枚入（
良かったもの2023
良かったものを年末にまとめる回、2023年版。 ラブリコと扇風機 脱衣所に大きな扇風機を設置できたおかげで、年中入浴後に快適に過ごせて、お風呂に入るのも楽しかった。入浴は健康に生活を送る上で重要な習慣だと感じているので、今年はそこの快適度を上げる努力をできたのが良かった。ラブリコは、賃貸物件でも問題無く設置できるし、最終的な処分も難しくはないし、自分で自分の環境を良くするDIYの楽しみがあるので、良いものだと思う。羽が大きい扇風機はいいぞ。 『脱衣所に壁掛け扇風機』という記事でも触れた。 Amazon.co.jp: 平安伸銅工業 LABRICO DIY収納パーツ 2×4アジャスター強力タイプ オフホワイト 最大使用荷重40kg EXO-1: ホーム＆キッチン あっちこっちふきん 12年ほど食器用に使っているふきん。めちゃくちゃ吸水力があるので、食器を拭くのに最高。高いだけの価値がある。欠点
GitHub Codespaces 雑感
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でそのラベルを使う旨を指定すれば良い。 この
リリースノート管理術
みなさま、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に似た形式で変更内
作業配信31日
毎時00分から50分まで作業して、50分から00分まで雑談休憩する、という作業配信を始めてから31日経った。 作業時間の中では、色々つくったり、学んだり、変えたり、新しいことを始めたりした。 開発: GitHub Issuesでブログを書くやつ 開発: Googleドキュメントでブログを書くやつ 開発: RuboCopの .rubocop_todo.yml を自動で解消するやつ 開発: Gemfileの差分を検知するやつ 開発: 見てるページをリッチテキストでコピーするChrome拡張 開発: 見てるページをMarkdownでコピーするChrome拡張 開発: Twitterにショートカットキーを追加する拡張 開発: TweetDeckにショートカットキーを追加する拡張 開発: Twitterのおすすめコンテンツを非表示にする拡張 開発: AmazonのURLを自動的に正規化する拡張 開発
『Sustainable Web Development with Ruby on Rails』を読んだ
David Bryant Copelandさんが書いた、Railsについてのこだわりの詰まった本。 takahasimさんも『Sustainable Web Development with Ruby on Rails』はRails使ってるなら絶対面白いと思うと言っていたように、面白い。これまでRailsを使ってきた中で、楽しいこともつらいことも沢山あったんだろう。そういうことが感じ取れるような話が展開されている。 幾つかの気になった話題を拾い上げて、自分の感想を述べていきたい。気になる話題は100個ぐらいあるが、がんばって10個ぐらいに留めたい。 Don’t Create Custom Actions, Create More Resources Railsが提供する7種類のアクション名以外使うな、必要なら新しくリソースをつくれ、という主張。つまりDHHはどのようにRailsのコントロー
Chrome拡張 つくりかた 令和最新版
数年ぶりにChrome拡張のつくりかたを調べた。 本当に何も分からなかったので、Twitterで「2022年にChrome拡張つくりたかったら何見て学べばいい？」とつぶやいてみたところ、何人かの人が教えてくれた。教えてもらった中から幾つかのリンク先を紹介するような形で記述していく。 Create a Vite-React Chrome Extension in 90 seconds - DEV Community 2022年時点だと比較的新しめのフロントエンド向けツールであるviteと、viteのChrome拡張向けプラグインである@crxjs/vite-pluginを使ってChrome拡張をつくってみよう、という記事。今回自分は主にこれを参考にしながら開発を進めた。Reactと言っているが、自分のChrome拡張ではUIは存在しなかったので、Reactに関する部分は読み飛ばして、vite
海辺のエンジニア
その時代だからこそ現実的に学べる技術、というものがあると思っている。 例えば自分はRuby on Railsという技術についてここ10年でそこそこ学べた。しかしこれは、それを学び始めたばかりの人でも大きく役に立てる仕事がたくさん存在していた時代に、たまたまそれに興味をもっている者がそこに居合わせたから学べたのであって、いま例えば2022年にRailsを学ぼうとしても、同じように順当にはいかないと思う。 もう少し掘り下げて言うと、機運の訪れていないとき、言い換えると社会的需要のないときにそれを学ぼうとしても誰かに貢献しづらく、経済的に成り立ちにくいし、モチベーション的にも成り立ちにくい。ただ純粋に何かを学ぼうとしても現実的にはなかなか成功させづらくて、「何か貢献できるものをつくりながら学べるき環境がそこにあるか」ということまで考えないといけない難しさがある。 何かこういう、いつでも漕ぎ出せる
GitHub Actionsでメインバージョンのブランチ維持
keep-main-version-branchというGitHub Actions Workflowを用意したので、これについて説明しておく。 GitHub Actionsを公開するときの文化として、v2やv3のように、メインバージョンの最新版にアクセスできるGitのrefを提供しておくという慣習がある。例えば、コードをcheckoutしてくるための公式GitHub Action actions/checkoutでは、uses: actions/checkout@v3 のように利用しろと説明されている。v3という名前付きのrefをつくる方法としては、v3ブランチをつくる、またはv3タグをつくる、という二種類の方法がある。 自分も次のように幾つかのGitHub Actionsを保守しているが、このメインバージョンのrefを維持する作業がリリースのたびに面倒だった。これを自動化したかったので、
RubyのDockerイメージでよく使う環境変数
Ruby向けのDockerイメージで使いがちな環境変数について整理する。 GEM_HOME RubyGemsに対して、どのディレクトリにGemをインストールするかを指定する環境変数。例えば gem install foo を実行すると、この環境変数で指定したディレクトリにfoo gemがインストールされる。 Dockerでありがちな作戦として、/gem のような適当なパスにデータボリュームをマウントしておいて、そこにGemを永続化させておくというのがある。このときGEM_HOMEを /gem に指定しておくと、gem install bundler を実行したときそこにBundlerがインストールされ、更に /gem/bin/bundle も用意される。 BUNDLE_PATH Bundlerに対して、どのディレクトリにGemをインストールするかを指定する環境変数。例えば bundle i
Slimcop
SlimテンプレートにRuboCopを適用するツール、Slimcopをつくった。 https://github.com/r7kamura/slimcop 使い方 基本的には、RuboCopと同じような機能をSlimテンプレート向けに提供するツールとなっている。SlimcopはGemとしてインストールでき、CLI向けに slimcop というコマンドを提供する。実行すると、Slimテンプレート中に埋め込まれたRubyのコードを検出し、それらに対してRuboCopで検査を実行する。また特徴的な機能として、auto-correctにも対応している。 $ slimcop --help Usage: slimcop [options] [file1, file2, ...] -a, --auto-correct Auto-correct offenses. -c, --config= Specify
request specのパターン
request specを書くときに従っているパターンを言語化する。 ファイルパス 1つのエンドポイントに対して1つのテストファイルを用意する。 GET /users GET /users/:id GET /users/:user_id/articles POST /users/:user_id/articles GET /users/:user_id/articles/:id/edit 例えば、上記のエンドポイントに対して以下のファイルを用意する。 spec/requests/users_index_spec.rb spec/requests/users_show_spec.rb spec/requests/user_articles_index_spec.rb spec/requests/user_articles_create_spec.rb spec/requests/user_a
docker composeのserviceをグループ化
docker composeではserviceごとにprofilesという属性を指定できて、起動時にこれを指定することで関連する一連のserviceだけを起動させられる。 どういうシーンで使えるのか。例えばとあるRailsアプリでは、一部の開発者はMySQLやRedisなどのデータストアだけdocker composeで起動して開発し、他の開発者は加えてRubyもdocker composeで起動して開発している。osxfsが遅すぎて、ファイルへの読み書きが頻発する処理がmacOSのDockerでは使い物にならないからだが、この話は今回どうでもいい。さてこのとき、データストア用のserviceに適当な名前のprofileを割り当てておくことで、個々のserviceの名前を逐一指定しなくても起動でき、将来の変更にも強くなって嬉しい。 # profile導入前 docker compose u
作業机の配線整理
作業机の配線を整理した。 前の物件から引き継いだレースカーテンの尺が足りていない 机までの配線 以下のような必要なケーブルを、ラグの下を経由して机の足元まで配線している。厚めのラグを作業机の下に敷いておくとこういう配線が楽になる。 電源タップ用の電源ケーブル 無線LANルーター用のLANケーブル プロジェクター用のHDMIケーブル 電源タップ ケーブルトレーに入れるより設置する方が色々取り回しやすい マグネットシートを使って電源タップを机に取り付ける。 自分の作業机は脚が金属製なのでそこに取り付けたが、机の天板にマグネットシートを貼ってそこに取り付けても良いと思う。ACアダプタを沢山付けても動かない程度には強力にくっついてくれる。エレコムのこの電源タップはACアダプタを付けやすく、シンプルで使いやすい。 Amazon.co.jp - エレコム 電源タップ 6個口 2m Amazon.co.
Windows開発環境構築メモ
開発環境構築用のメモを自分用に書き残しておく。 GUIアプリケーション この辺りを入れる。 Google Chrome Google日本語入力 1Password 4 Dropbox Docker Desktop for Windows 未だに購読版に移行せず買い切り版の1Password 4を利用している。 Windows + Vを利用するとクリップボード履歴を有効化できるので、済ませておく。 Google日本語入力の設定 HENKANキーでIMEを有効化 MUHENKANキーでIMEを無効化 というキー設定を普段利用しているのでそのように設定する。 直接入力 入力文字なし 変換前入力中 変換中 以上の4つのモードについて、それぞれキー設定のエントリを追加する。 Windowsライセンス認証 Windows 10 Pro 64bit辺りをライセンスキー無しでインストールしていると思うので
良かったもの2020
良かったものを年末にまとめる回、2020年版。 ホットクック 具材をぶち込んでボタンを押せば完成 https://www.amazon.co.jp/dp/B08HMF4W7S 今年はこれのおかげで毎日自炊が続いた。これからも続くだろう。カレーや鍋、低温調理、つくりおきなど用途はいろいろ。9月に2020年モデルのホットクックが出たので、今から買うならこちらが良い。内鍋がフッ素加工されているのと、蒸しカゴが付いている違いが大きい。『ホットクック KN-HW16E-R』という記事でも紹介した。 ホットサンドメーカー 生卵を入れるときは弱火で時間を掛けて焼くと良い https://www.amazon.co.jp/dp/B081CKFWYV 主に朝食としてホットサンドをつくるのに使っている。1人では食べ切れないという人向けに、最近では更に半分のサイズのものも発売された。実はちょっとした肉や魚介類を
rack-ok
rack-okというGemをつくった。 概要 何かというと、GET /healthに対して200 OKを返すだけのRackミドルウェア。冗談みたいなプログラムだけど、今更Rackの世界に入門してハローワールドしたかった訳ではなくて、ロードバランサーからのヘルスチェックに応答させるために、こういう実装が必要になる機会がそれなりにある。 背景 Railsアプリとかだと、こういうのは（適切なという意味ではなく雑なという意味で）適当なコントローラで実装されたりするのだけど、機能てんこ盛りのコントローラで200を返すだけの処理をやるのはどうにも無駄が多い。それに、ヘルスチェックはHTTPでリクエストが飛んでくるので、SSL対応用の機能を有効化しようとするとヘルスチェック用のエンドポイントだけ確認対象から除外する必要が出てきたりする。Rackミドルウェアだと、その辺の問題が解決できる。 ヘルスチェック
GistでGemを公開
Gistにファイルを置くだけで、Gemとして公開できる。 最小構成だと、gemspecとソースコードをGistに配置すれば良い。 Gem::Specification.new do |spec| spec.name = 'my_gem' spec.version = '0.0.1' spec.authors = ['Your Name'] spec.email = ['[email protected]'] spec.summary = 'Summary of this gem' spec.files = ['my_gem.rb'] spec.require_path = '.' end # ここに好きなコードを書く 使う側では、gitプロトコルでGistのGitリポジトリとしてのURLを指定すれば良い。 gem 'my_gem', git: 'https://gist.github.co
かなでものの机
20年ぶりに机を新調した。 かなでものの、幅180cm・奥行80cmのラバーウッドの天板と、X型の脚を組み合わせた。脚の形状が可愛いのが気に入っている。杉無垢材かラバーウッドかで迷ったが、落ち着いた見た目と硬い表面の使い勝手を優先し、ラバーウッドの天板を選択した。 天板の加工が優れていて、思っていたより表面や角のさわり心地が良い。購入前は少し大きすぎるかもしれないと思っていたが、使ってみるとそういうこともなかった。机が大きいと満足感がある。 これまで使っていた机 これまではGarageのFantoniという机を2枚繋げて使っていた。20年使ったが、丁寧に使えばもう20年ぐらいは使えたと思う。引っ越しが多く、分解・組み立て作業や頻繁な移動を繰り返したこともあり、流石に脚の接合部のガタつき方が怪しくなってきていた。 今回新しい机を一緒に組み立てるぞという名目でひさしぶりに友達を召喚できたので、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
