サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
r7kamura.com
数年ぶりに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
Windowsで開発環境を整えた。 背景 開発環境を改善しようと思い、PCデスクの見直しなどをやっていたら、Windowsでも開発できるようにしようと思い至った。新しい環境を試してみたい気持ちが1割と、新しいゲーミングPCを組みたい気持ちが9割だ。 エディション Windows 10 Homeエディションを利用している。 Windows 10 ProにはHyper-Vという仮想化機能を直接利用できる利点があるが、WSL2で同じようなことをより便利に実現できるようになったおかげで、この点においてPro版の必要性は薄れてきている。今のところ自分のやりたいことはWindows 10 Homeですべて実現できている。 Windows Update WSL2を使うために、Windowsをバージョン2004・ビルド19041に更新した。 日々の自動更新ではバージョン1903で止まっていて、まだ自動では
良かったものを年末にまとめる回、2022年版。 ストレスレストーキョー PC作業用のデスクチェアとして使い始めたら大成功。元々はリビング用だった。 前に書いた記事: ストレスレストーキョーで作業 前に書いた記事: ストレスレストーキョーのリクライニングチェア Amazon|EKORNES [正規品]ストレスレス®トーキョー スター ブラック/マットブラック チェアのみ mサイズ|リクライニングチェア オンライン通販 エルゴトロンLX デュアル 長身ポール ディスプレイを支える技術。横長ディスプレイ上下2枚×リクライニングチェアの組み合わせが絶妙に噛み合っている。たまに縦長の絵を大きく表示したいときがあり、上側のディスプレイを引っ張って回すだけですぐ縦長にできるのも便利。 前に書いた記事: エルゴトロン LX デュアル Amazon.co.jp: エルゴトロン LX デスク デュアル モニタ
なぜ個人でウェブサイトを運用しているのかについて、整理しておきたい。 要約すると、以下の理由でやっている。 ウェブの技術を学べて費用対効果が高いから 表示されるコンテンツを制御したいから フィードバックの場と適切な距離を置きたいから かっこいいから コスパが高い 個人でウェブサイトを持って運用していくことは、学習意欲の高い多くの人にとって費用対効果の高い活動だと思う。 ほとんどの技術が無料で利用できる時代になってきているので、ここで言う費用というのは時間や労力のことで、効果というのは得られる知識のこと。その仕組みを用意するにあたって、ウェブサイトというものがどういう仕組みで動くかということが、一通り理解できる。この辺の分野を本職とするような人であれば、こういうことは最低限理解しておいてほしいし、何なら採用面接でもこういったことを質問する・される機会がある。 学習コストについて述べたけれど、
新しい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
みなさま、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に似た形式で変更内
開発環境をMacからWindowsに切り替えたことについて、実際どうですかと聞かれることが何度かあったので、そのときも話した現在の所感みたいなものを書き残しておく。 結論すると、移行後の環境をかなり気に入っている。 1996年のカリフォルニア州 2~3日は主にメタキー周りのキーバインドや見てくれの違いに戸惑い、幾らか離脱症状が出たものの、1週間もすれば流石に慣れてきて、最終的に、個人の用途ではMacを全く触らなくなった。開発環境がMacを前提としている仕事先があったり、貸与されたPCで作業する仕事先があったりするので、完全に触っていない訳ではない。 よくよく比較してみると、あると嬉しい便利機能がOSから提供されていることが多くて、これは意外なところだった。例えば、クリップボードの履歴を残しておいて呼び出せるようにする (Windows + Vキー) とか、ぶっ壊れたときに少し前の状態に戻す
開発環境構築用のメモを自分用に書き残しておく。 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辺りをライセンスキー無しでインストールしていると思うので
このサイト r7kamura.com の実装言語をRubyからRustに変えてみた。 アプリケーションの概観 このサイトには、大別すると次の6種類のルーティングパターンがある。 GET / トップページ GET /articles/:article_id 記事ページ GET /feed.xml RSSフィード GET /links リンク集 GET /sitemap.txt サイトマップ (Google Search Console等が利用する) GET /* その他の静的ファイル (CSSや画像など) Rubyの実装では、適当なRackアプリケーション + rack-captureという構成で、Webアプリケーションとして実装しつつGitHub Pagesのために静的ファイルも吐き出せるという仕組みになっていた。 Rustの実装もほぼ同じで、適当なHTTPサーバー + 適当なHTTPクラ
自分が目指したいRailsアプリの形とは何か、ということについて考えていた。 常日頃から考えていたRailsアプリでの不満をこの議論に合流させた結果、「Rubyを書くときに当たり前にやるようなことを、Railsアプリを書くときでも当たり前のようにやる」というところが肝で、自分が目指したいRailsアプリの形はその先にあるのではないか、と一旦結論付けてみることにした。 「普通にRubyでコードを書くときはやらないけど、Railsだったらこう書く」という何かが存在していることが、さまざまな失敗の原因をつくっていると思う。 RubyとRailsが地続きに繋がっていないというか、どこかで断絶があり、そこから筋の悪い設計が生まれている ―あるいは持ち込めるはずの良い設計を持ち込めていない― のではないか、という話。 実際にはどの辺りが気になっているのか?という例を挙げると、氷山の一角を指摘するだけな
大きなサメのぬいぐるみの購入方法について。 背景 最近サメの人気が高まっているのか、サメのぬいぐるみについてよく質問されるようになった。Gawr Guraさんの影響が大きいのかもしれない。つい先日質問してきた人は、サメ好きの友達にプレゼントするつもりらしい。いい友達だ。これまでこういう質問に対しては昔書いたサメを支える技術を紹介していたが、情報が古くなってきたので、この機会に新たに書き直すことにした。 サメの配信を見るサメ 購入方法 2020年10月25日現在では、この大きなサメのぬいぐるみはchumbuddy.comから購入できる。2015年にはamazon.comでも購入できたので、自分はここから購入したのだけど、今は取り扱っていないようだ。惜しいことだ。 chumbuddy.comでは、わた入りザメとわた無しザメが売られている。 体積が増えるので海外からの配送が大変そう 出所不明のわ
docker composeではserviceごとにprofilesという属性を指定できて、起動時にこれを指定することで関連する一連のserviceだけを起動させられる。 どういうシーンで使えるのか。例えばとあるRailsアプリでは、一部の開発者はMySQLやRedisなどのデータストアだけdocker composeで起動して開発し、他の開発者は加えてRubyもdocker composeで起動して開発している。osxfsが遅すぎて、ファイルへの読み書きが頻発する処理がmacOSのDockerでは使い物にならないからだが、この話は今回どうでもいい。さてこのとき、データストア用のserviceに適当な名前のprofileを割り当てておくことで、個々のserviceの名前を逐一指定しなくても起動でき、将来の変更にも強くなって嬉しい。 # profile導入前 docker compose u
GitHub Codespacesをちょっと試した。 初期導入時にハマりどころも多いけど、真面目に設定しておけば、普通にCodespacesの環境だけで開発することは十分できそうだなと感じた。リポジトリ単位で環境を用意するのが基本で、多くのリポジトリに対して毎日のようにレビューをしたりPull Requestを出したり、みたいな開発フローには綺麗にはまらないと思うけど、普通に仕事で単一のリポジトリに対してだけ作業する用途であれば上手くはまると思う。Zoomで会議しながら重い処理を実行していても影響が無いのは良かった。Zoomで会議しながら重い処理を回すべきではないという意見もある。 Codespacesの利用の流れ Codepsacesを利用するときの流れについて。まず、予め .devcontainer/devcontainer.json を配置したリポジトリを用意しておく。Codespa
開発機をMacからWindowsに移行して2年ほど経った時点での振り返り。 年表 2009年07月 MacBook Pro 1を購入、プログラミング開始 2014年07月 MacBook Pro 2を購入 2016年12月 Windows機1を入手、PCゲーム開始 2017年07月 MacBook Pro 3を購入 2018年06月 Windows機2を購入 2020年09月 MacからWindowsへ開発機を移行 2021年01月 Windows機3を購入 2022年10月 現在 過去記事 開発機を移行してすぐの頃の感想は、次の記事に書いた。 Windowsで開発 Windowsへの回帰 自作PC2021 デスクトップPCを譲渡 Macからの移行という観点だと、次の記事も幾らか関連があるかもしれない。 AirPodsをWindowsで使う Windows10でMagic Trackpad
RubyやRailsのアップグレードを主なマイルストーンとしつつ全体的に開発体験を良くしていくというタイプの仕事を請けることが多いのですが、仕事を依頼する側の視点に立ってみると「実際のところ業務に参加するとどういうことが行われるのか?」というのがやはり気になると思います。 実際、最近の打ち合わせでもその手の不安について相談されることがあったので、ここ1ヶ月でそれ系の仕事で出したPull Requestを元に、実際に何をやっていたかの例を挙げてみたいと思います。 開発環境構築手順や説明方法の改善 荒れたRuboCopの改善 .rubocop.ymlからTargetRailsVersionを取り除く DEPRECATION WARNING対応いろいろ 既存のメソッドと名前が被っているスコープを別名に変更 RSpecのpositional-argumentsを置換 activerecord-im
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のコントロー
参加しているプロジェクトで、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を利用しており、またファイル
初学者用のRustの教材として、RustでWebアプリケーションのサーバーサイド側をつくる一連のチュートリアル記事、『Zero To Production In Rust』を読んでみている。 https://www.lpalmieri.com/posts/2020-05-24-zero-to-production-0-foreword/ 一気に読んでいるかのような雰囲気でさらりと書いているが、仕事と遊びの合間に少しずつ、数日に1章程度の速度でゆっくり読み進めている。 問題駆動型の学習方法が嬉しい 知らない知識を複数同時に与えると学習効率が悪くなりがちなので、ある程度基礎部分を学んだら、少し難易度の高い領域であっても、自分の馴染みのある分野でどう使うかという話を例に学んでいく方が良いと考えている。今回の自分のケースの場合、Webアプリケーション開発という題目がそれにあたる。分からないところが
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
最近は下記のようにライブラリ等のリリースを自動化している。 バージョンを入力すると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でそのラベルを使う旨を指定すれば良い。 この
ソフトウェア開発などでバージョンを上げるときによく "bump version" のように "bump" という語彙が使われるんだけど、これって "Bring Up My Post" の頭字語だったんだ。 つまり、みんなコミットメッセージで「バージョンage」とか言っていたのか。急に在りし日のインターネットに引き戻された感覚だ。 ちなみに、このように完成形の語ありきでつくられた逆頭字語をバクロニム (backronym; bacronym) というらしい。再帰的な頭字語である GNU (GNU's Not Unix) や PHP (PHP: Hypertext Preprocessor) もバクロニムの範疇に入るみたいだ。 『バクロニム - Wikipedia』
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
左右分割型のキーボードを机に固定してみた。 今回使ったキーボードは、Corne V4 Chocolate。左右に分かれているタイプで、左右合わせて合計46個の背の低いキーが搭載されており、はんだ付け不要な簡単組み立てキットが販売されている、初心者にもおすすめのキーボード。 このキーボードのケース内底面に鉄板を貼り、机から生やしたアームに磁石型マウントで固定しよう、というのが今回の試みです。 このキーボードのケース内底面には格子状にでっぱりが付いているので、大きな鉄板一枚を貼るのは難しい。そこで、小さな鉄板を複数枚貼り合わせていく。世の中には両面テープ付きの小さな鉄板がまとめて売られているので、それを使います。今回はこの正方形のやつと円形のやつをそれぞれ10枚ずつ貼ってみたところ、十分な磁力を得られました。 Amazon | [エムティ]スチールプレート (マグネット吸着用) シルバー 小
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とい
結論から言うと、node_modulesをキャッシュしてnpm ciの実行を省略するのが、多くの場合には有効そうです。 はじめに CIで npm ci を使うとき、実行時間短縮のためにキャッシュの利用を検討することになると思います。このとき、どのようにキャッシュするのが良いのでしょうか? よく知られているキャッシュ方式として、以下の二通りの方式があります。 ~/.npmをキャッシュする方式 node_modulesをキャッシュする方式 それぞれの違いについて、詳しく見てみましょう。 ~/.npmをキャッシュする方式 npm ci を実行すると、POSIX系のOSではデフォルトで ~/.npm にキャッシュデータが書き込まれます。package-lock.json をキーにこのディレクトリをキャッシュしておくことで、次回以降の npm ci 実行時にこのキャッシュデータを利用しよう、というの
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を維持する作業がリリースのたびに面倒だった。これを自動化したかったので、
良かったものを年末にまとめる回、2020年版。 ホットクック 具材をぶち込んでボタンを押せば完成 https://www.amazon.co.jp/dp/B08HMF4W7S 今年はこれのおかげで毎日自炊が続いた。これからも続くだろう。カレーや鍋、低温調理、つくりおきなど用途はいろいろ。9月に2020年モデルのホットクックが出たので、今から買うならこちらが良い。内鍋がフッ素加工されているのと、蒸しカゴが付いている違いが大きい。『ホットクック KN-HW16E-R』という記事でも紹介した。 ホットサンドメーカー 生卵を入れるときは弱火で時間を掛けて焼くと良い https://www.amazon.co.jp/dp/B081CKFWYV 主に朝食としてホットサンドをつくるのに使っている。1人では食べ切れないという人向けに、最近では更に半分のサイズのものも発売された。実はちょっとした肉や魚介類を
作業机の配線の記録をまとめておきます。 現在の様子 2020 2020年は牧歌的な時代で、子供の頃から使っていた机の上に、必要な機器を乱雑に並べていました。当時はゲームの録画や配信をはじめた頃だったので、それ以前と比べると、キャプチャーボードやオーディオインターフェースが増えていっていました。 乱雑に積まれた機器達 2021 2021年には作業机を買い替えたり、はじめて自作PCを組んだりしました。この辺りでようやく、配線に真面目に向き合い始めました。この年には、天板下にクランプで取り付けられる、サンワサプライのケーブルトレーを導入しました。 電源ケーブルはカーペット下を通している あらゆる機器が詰め込まれたケーブルトレー 電源タップはマグネットシートで設置 PC裏にはゲーム機 2022 引越しを済ませ、生活が落ち着いてきた頃合いで、半年間、朝6時から12時まで毎日作業配信をやってみました。
YARDのアノテーションを元にそこそこ便利な説明や補完機能を提供してくれるSolargraphを、Gemfileに含めずこっそり使いてえ……しかもDocker環境で……という人向けの情報。 一番の問題として、gem install solargraph でsolargraph gemを入れたい訳だけど、揮発しないように工夫が必要になる。 一般的なRuby向けのDockerfileの構成だと、bundle install で入れるGemだけをdata volumeで永続化していることが多い。よく見るパターンは、vendor/bundle または /usr/local/bundle にdata volumeをmountするようdocker-compose.ymlで設定し、加えてこのパスを BUNDLE_PATH に設定するパターン。これに加えて例えば GEM_HOME も同じパスに設定しておく
次のページ
このページを最初にブックマークしてみませんか?
『r7kamura.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く