2025年4月入社予定の白戸 (ニックネーム: ユリタニ) です！ 最近は，毎週30分入社前の研修*1を受けています． 内容としては，gemをリリースすることを通じて， red-data-tools/red-datastockを題材にRubyGemsの仕組みを学ぶという研修です． クリアコードの須藤さんに説明をしてもらいながら実際に手を動かして学んでいます． 今回はその研修の中で学んだこととして，gemからの使用しないテスト関連ファイルの削除について説明します． はじめに この研修では，実際に手を動かして上記gemの改善しながら，gemの仕組みやOSS制作に必要な知識を学んでいます． 題材にしている red-datastock のディレクトリ内容を確認すると，下記のような構造になっていました． red-datastock/ ├ .github/ ├ lib/ ├ test/ # 今回の変更
fat gemを簡単に作れるようにするgemであるrake-compilerをメンテナンスしている須藤です。2019年にもfat gemをやめる話をしていましたが、5-6年経ってもまだfat gemが使われているので、この5-6年でのアップデートを紹介します。 おさらい まず、簡単に関連情報を整理しておきます。 まず、「fat gem」についてです。fat gemとはビルド済みバイナリーが入ったgemのことです。pre-compiled gemとかnative gemとかbinary gemとかと呼ばれることもあります。 fat gemの嬉しいところは次の通りです。 インストール時にビルドツールが必要ない（そもそもビルドしないから） インストール時にビルドで失敗しない（そもそもビルドしないから） インストールが速い（ビルドしないから） fat gemのキビシイところは次の通りです。 開発者
この記事は note株式会社 Advent Calendar 2024 の17日目の記事です。 あるRubyクラスを変更したがそのプログラムのテストケースの実行結果の確認だけでは不十分なことがよくある。例えば、CreateUserService -> Userのようなクラスの依存関係があったとする。プログラマはUserクラスに対して変更を加えたので、Userクラスに対するテストケースを実行すれば確認としては十分であると考えた。しかし、実際にはUserクラス単体ではCreateUserServiceからの実際の利用のされ方は確認できないし、保証もできないので（特にRubyプログラムであることも踏まえて）、うっかりUserクラスの振る舞いが変わってしまったことで、連鎖的にCreateUserServiceの振る舞いに影響してしまうということがよくある。 この問題には、以下のような解決策が考えら
この記事はソニックガーデン プログラマ アドベントカレンダーの16日目の記事です。 はじめに Rails のシステムテストって便利ですよね。実際にユーザーが使うシチュエーションをブラウザからRails、データベースまで包括的にテストできる。素晴らしい仕組みだと思ってます。 そんなシステムテストですが、アプリが大きく成長してきてユーザー体験を重視したリッチなUIやUXが充実しだしたりしたときに、こんな状態に遭遇しだしたりします。 なぜか、CIで自動テストが通らない 再実行したらうまくいく ローカルでは、テストが通る（テストの失敗が再現しない） 実際に体験した人ならわかると思うんですが、CIと同じ状況をなかなか再現できなくって厄介ですよね。 原因のわからない不可解な事情にプログラマとしては、どうにかしたいなと思いつつ、泣く泣く再実行してテストが通るまでリトライボタンを押したり、ローカルではテス
こんにちは。2021年12月にCAMPFIREに入社した小川です。 CAMPFIREではRailsを使って開発しています。わたしの入社後、いくつかRailsのパフォーマンスチューニングをする機会があったのですが、今回はそのうち、開発環境でのRailsの起動時間を約7分の1に短縮することができた事例についてご紹介したいと思います。 Railsの起動が遅いCAMPFIREで開発をしはじめてひとつ気づいたのが、開発環境でのRailsの起動にやけに時間がかかることでした。計測してみると1分以上かかっています・・・。 $ time bundle exec rake environment # ... real 1m10.845s user 0m8.075s sys 0m2.086s これは遅い。アプリケーションの規模はたしかに大きいのですが、それを加味しても遅すぎる印象です。 チームメンバーに尋ねて
現在、Ruby 製 worker を作成することを業務で行っているのですが、継続的にメモリ使用量が増加する現象に遭遇してました。 （グラフの値が下がったタイミングが数回ありますが、それぞれでデプロイが行われてリセットされただけ） ObjectSpace.allocation_sourcefile や ObjectSpace.allocation_sourceline を利用してどのファイルのどの行でメモリ確保が多くなるのか調べれるようにしました。 以下のようなコードを worker に追加しました。 require 'objspace' class MemoryProfiler INTERVAL = 5 * 60 DISPLAY_COUNT = 20 def self.start Thread.start do loop do memory_usages = {} ObjectSpace.
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Don't Use Floats and Use the Ruby Money Gem to Represent Currencies - Andy Croll 原文公開日: 2021/11/15 著者: Andy Croll 日本語タイトルは内容に即したものにしました。 アプリケーションで金額を管理しなければならなくなることはざらにあります。何の話かというと、Rubyコミュニティにある素晴らしいオープンソースのソリューションを使えば、自分で開発するよりもずっと良い結果を得られるのです。 以下のようにするのではなく 金額を表現するときにFloatやBigDecimalを使う。 # マイグレーション add_column :products, :price, :decimal class Product < Application
Rails(というかActiveRecord)に型を付けるのは大変だが、Railsが絡まないrubygemにはそんなに苦労なく型が書けるので、これからgemを書く時には型を書きたいという人向けに今のところオススメの設定を紹介します。 というか自分が忘れるのでまとめておきます。 現状とはsteep-1.3.1, rbs-2.8.4を指します。 rbsは既に3系が出ていますが、一般利用者が型検査に利用する場合はsteepを使うはずで、steepはまだrbsの3系に対応していません。また、rbs-3.0で多少変わっているところもあるので、割と寿命が短い話かもしれません。 設定例 とりあえず結論から。Steepfileとrbs_collection.yamlを修正します。 Steepfile: D = Steep::Diagnostic target :lib do signature "sig"
概要 VS Code Debug Visualizer という VS Code のエクステンションをご存知でしょうか。デバッグ中のオブジェクトを以下のようにビジュアライズしてくれるものです。 VS Code Debug Visualizer ではこれまで Ruby のサポートはされていませんでしたが、最新バージョン（本稿執筆時点ではバージョン2.4）より debug.gem を用いてのビジュアライズが可能になりました。 本稿ではそれらの実際の使い方についてお話ししていきます。 対象読者 本記事では VScode を用いた debug.gem の簡単な利用方法について理解していて、既にそれらのセットアップが完了している方を想定しています。 VScode を用いた debug.gem の使い方やセットアップ方法については以下のリンクなどをご覧ください。 事前準備 事前準備として VS Code
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[rails] rails generate xxx:install(カスタム Generator の作り方) - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d2bf1a1ca73cfb655b18925e25b0531065a81342/height=288;version=1;width=512/https%3A%2F%2Fv17.ery.cc%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGNTA1NTclMkZwcm9maWxlLWltYWdlcyUyRjE0NzM2OTIxNDY_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9M2JkNTRhYzU3ZWEwNDY0MDM1MTE2NDhlMDA5NmFhMTY%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D8a63fb17f1f5cb4668eb5b847a7fa01a%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCcmFpbHMlNUQlMjByYWlscyUyMGdlbmVyYXRlJTIweHh4JTNBaW5zdGFsbCUyOCVFMyU4MiVBQiVFMyU4MiVCOSVFMyU4MiVCRiVFMyU4MyVBMCUyMEdlbmVyYXRvciUyMCVFMyU4MSVBRSVFNCVCRCU5QyVFMyU4MiU4QSVFNiU5NiVCOSUyOSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPTE0YjgwYmNlNGIxMTUxYTFjNTA1NzYzYzEyMzBlNzk1%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBsaXZlcmFsbWFzayZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPTU1MTNmNTY5YmRiZjViN2E3ODRmZjNhNDllMDRmY2U1%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D6ff24fefbb171e50393c5d63e70ed9ff)
