vscode-ruby-light開発日記 - Prismパーサー導入編
vscode-ruby-lightの開発中に考えたことを書いていきます。今回は、内部で利用しているRuby用パーサーのtree-sitter-rubyからPrismへの移行について書きます。 @ruby/prismパッケージの概観 Prismは、JavaScriptからもその実装を利用できるよう、@ruby/prismという名前でnpmパッケージを公開しています。 何が含まれているパッケージなのかというと、まずWASMバイナリという形でコンパイルされたPrismの実装と、それを便利に使うためのJavaScriptの実装、それからTypeScript向けの型定義ファイルが含まれています。これらはESModuleという形式に従ってモジュール化されています。またruby/prismのリポジトリ内に、JavaScript向けの簡単なドキュメントも含まれています。 もちろん、本拡張でもこのnpmパッ
vscode-ruby-light開発日記 - 初期版ふりかえり編
vscode-ruby-lightの開発中に考えたことを書いていきます。今回は、2022年末に初期版を開発してから1年ほど経った2023年末時点でのふりかえりを行います。 vscode-ruby-lightとは 1年ほど前に、Ruby用VSCode拡張: vscode-ruby-lightという記事を書きました。要約すると、Rubyがインストールされていなくても使える、Rubyを書くのがちょっと便利になるVSCode拡張をつくってみているという話です。具体的には、シンタックスハイライトやトークンの選択など、VSCode標準の機能よりちょっと良い編集体験を提供しようという目的の拡張です。 あまり真面目に開発している訳ではなく、VSCode拡張やLSPについての勉強も兼ね、ちょっとした趣味プロジェクトとして開発したりしなかったりしているというのが実情です。開発自体は1年ほど停滞していたのですが
npm ciのキャッシュ方式の検討
結論から言うと、node_modulesをキャッシュしてnpm ciの実行を省略するのが、多くの場合には有効そうです。 はじめに CIで npm ci を使うとき、実行時間短縮のためにキャッシュの利用を検討することになると思います。このとき、どのようにキャッシュするのが良いのでしょうか？ よく知られているキャッシュ方式として、以下の二通りの方式があります。 ~/.npmをキャッシュする方式 node_modulesをキャッシュする方式 それぞれの違いについて、詳しく見てみましょう。 ~/.npmをキャッシュする方式 npm ci を実行すると、POSIX系のOSではデフォルトで ~/.npm にキャッシュデータが書き込まれます。package-lock.json をキーにこのディレクトリをキャッシュしておくことで、次回以降の npm ci 実行時にこのキャッシュデータを利用しよう、というの
Railsアプリの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 Action
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とい
Ruby用VSCode拡張: vscode-ruby-light
Ruby向けに、vscode-ruby-lightというVSCode拡張をつくっています。この拡張は、利用者に特にRubyのインストール要求することなく、シンタックスハイライトやカーソル操作など、VSCode標準の機能よりちょっと良い編集体験を提供しようという目的の拡張です。 最初は「メソッドやブロックをもう少し上手く選択できるようにしたい」というモチベーションで調べ始めたのですが、気付けば色々な機能を持つVSCode拡張が出来上がっていました。この記事では、幾つかの機能を紹介しながら、関連する話を書いていこうと思います。 Selection Range VSCodeにはExpand Selectionというコマンドがあり、選択範囲を拡大したり狭くしたりできます。このコマンドには、例えばWindowsであればデフォルトでShift + Alt + →にショートカットキーが割り当てられていま
良かったもの2022
良かったものを年末にまとめる回、2022年版。 ストレスレストーキョー PC作業用のデスクチェアとして使い始めたら大成功。元々はリビング用だった。 前に書いた記事: ストレスレストーキョーで作業 前に書いた記事: ストレスレストーキョーのリクライニングチェア Amazon｜EKORNES [正規品]ストレスレス®トーキョー スター ブラック/マットブラック チェアのみ mサイズ｜リクライニングチェア オンライン通販 エルゴトロンLX デュアル 長身ポール ディスプレイを支える技術。横長ディスプレイ上下2枚×リクライニングチェアの組み合わせが絶妙に噛み合っている。たまに縦長の絵を大きく表示したいときがあり、上側のディスプレイを引っ張って回すだけですぐ縦長にできるのも便利。 前に書いた記事: エルゴトロン LX デュアル Amazon.co.jp: エルゴトロン LX デスク デュアル モニタ
rubocop-migration
rubocop-migrationというGemをつくった。 ActiveRecordのmigrationでハマりがちな罠を回避したり、記法に一貫性を持たせるための、RuboCop向けのCopをまとめたライブラリである。例えば、テーブルへの読み書きをブロックしてしまうようなMigrationの書き方を検知し、それがもし別の方法で回避可能なものであれば違反とする、といったCopが含まれている。 背景としては、先週にstrong_migrationsの話を見かけ、RuboCopから使える形で提供されていると便利そうだと思い用意した。実際、ほとんどのCopはこのライブラリの内容を参考に実装している。 異なる点として、strong_migrationsだと検知させるためにアプリケーションのコードに変更が必要で、またデータベースへの接続も要求される。一方で、rubocop-migrationはこの辺を
カスタムCopでリファクタリング
RuboCopのカスタムCopを書いてリファクタリングを行う話として、丁度良い事例があったので紹介します。 改善したいコード 仕事先のRailsアプリを眺めてみると、昔から慣習的に次のようなコードが書かれていることが分かりました。 module A extend ::ActiveSupport::Concern included do def foo end def bar end end end 本来は、特別な理由が無い限り次のように書かれるべきコードです。 module A def foo end def bar end end これは後から分かったことですが、このようなコードはファイル数で言うと数百件、メソッド定義数で言うと千件弱あるようでした。 用意したカスタムCop そこで、RuboCopのカスタムCopを書いて、このコードを自動修正することにしました。詳しい書き方についてはここ
『メモの魔法』を読んだ
毎日狂ったようにメモを書いている人が、メモについて語ってくれる本。人生訓や自己啓発的な語り口の内容が意外と多かった。 この辺の考え方は拾い上げておきたいと感じた。 情報の記録それ自体は機械にとって変わられるべき仕事だと考えるが、これとは別の観点として、メモを取れる程度に高い集中力で情報の入力に臨むことは有益だ 構造的にメモを取るように意識することで、情報を構造的に捉える必要性が発生するので、結果的に自身をそのような試みに導き、構造化能力や言語化能力を鍛えられる 自己分析ができている者は重宝されやすい。メモを取ることで自己分析を大いに進められ、自身の価値を高められると共に、自己実現にも繋がりやすい 強い願いを持つ者ほど大きな事を成しやすいが、人は生きていく中で願いを忘れてしまうので、書き留めておくことでそれを防ぎ、また何度も見返すことでそれを強められる 協力者が多いほど事を成しやすい。言語化
リリースノート管理術
みなさま、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に似た形式で変更内
ActiveSupport::Deprecation.behavior
RailsのDeprecation Warningの出力手段を好きにカスタマイズする方法について。 config.active_support.deprecation Railsはその機能について破壊的な変更を入れるとき、まず「次のマイナーバージョンでこの機能を廃止するよ」という警告を出すように計らってくれている。この警告は常に ActiveSupport::Deprecation の機能を使って出力される。 Railsアプリの設定で、次のような項目を見たことがないだろうか。 config.active_support.deprecation = :notify 例えばこの設定をした場合、Railsは起動時にこの設定値を見て、ActiveSupport::Deprecation.behavior = :notify みたいなことをしてくれる。ActiveSupport::Deprecati
rubocop –format github
RuboCopをGitHub Actionsで使うならGitHubActionsFormatterが便利。 Workflow commands形式で出力してくれるので、GitHub Actionsが勝手にそれを拾ってPull Requestだと自動的に変更行に注釈を付けてくれるし、Checksの項目にもエラーと警告の一覧が出力される。 但し、この出力形式は主に機械が便利にキャプチャするためのものなので、人間がログを直接見るときには不都合なことが多い。例えばGitHub Actionsのログでは、Workflow commandsが使われたとき、色を付けたりしてくれるもののファイルパスや行番号を隠してしまう。問題のあったファイルパスを知りたいのに、これは問題だ。 rubocop –format progress –format github と複数指定し、人間用と機械用の両方を同時に出力させ
eval_gemfile
ちょっとしたコード変更を紹介するシリーズ。 - instance_eval( - File.read('Gemfile') - ) + eval_gemfile('Gemfile') Gemfileから別のGemfileを評価したいときに使えるメソッドとして、eval_gemfile (Bundler::Dsl#eval_gemfile) があったことを、他人のコードを読んでいて思い出した。結果的に、上記のように書き換えた。やっていることは大体同じだけど、異常系の考慮や相対パスの取り扱いなど細かなことをやってくれるし、DSLに入りてはDSLに従うべきだろうという考えの元で。 こういうきもい処理は、複数のGemfileを運用するとき場合などに出てくる。例えば、アプリケーションでRails 6と7との過渡期で並行運用するときや、ライブラリで複数のバージョンのGemをテストするときなど。
SolargraphをDocker環境でこっそり使う
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 も同じパスに設定しておく
寝具2022
使っている寝具を振り返ってみる。 「マニフレックスの枕をお使いとのことでしたが、何というモデルですか。あとマットレスとベッドフレームも良かったら教えてください」という質問を、r7kamuraのマシュマロ宛にいただいたのがきっかけ。 枕 自分の枕遍歴は次の通り。 パイプ枕 テンピュールの枕 無印良品の何らかの枕 マニフレックスのグランデ マニフレックスのグランデは、ふかふかで使いやすい万能モデル。高反発枕界の中では比較的柔らかめで、形状が固定されていない。ふつうの枕からの乗り換え時に大きな違和感が発生しづらい。ちょっと良い枕が気になっている人におすすめ。 最初にマニフレックスの枕に興味を持ったのは、Sanographix氏のブログ記事で言及されていたのがきっかけ。その後ロフトで見る機会があり、欲しいなと思ってほしいものリストに入れていたら、京都に引っ越したときに友人から送っていただいた。それ
『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のコントロー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
rubocop-rails_deprecationをsevencopへ統合
Sevencop/BelongsToOptional
GitHub Pagesとテンプレートリポジトリ