概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Mythical IO-Bound Rails App | byroot’s blog 原文公開日: 2025/01/23 原著者: byroot -- Railsコアコミッター、Rubyコミッターであり、ShopifyのRuby/Railsインフラチームのシニアスタッフエンジニアです 日本語タイトルは内容に即したものにしました。 IO-boundは英ママとしました。 私がやりたいのは、Pitchfork1に関する記事を書いて、これがどんな理由でできたのか、なぜ現在のような形になったのか、そして今後どうなるのかについて説明することです。しかしその前に、いくつか解説しておく必要があります。 Railsとパフォーマンスの話題になると「データベースがボトルネックになる」という話がよく持ち上がりますが、RailsはいずれにしてもI
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Railsmas on Mars: 12 Days of Mandatory Developer Joy and Challenge—Martian Chronicles, Evil Martians’ team blog 原文公開日: 2024/12/31 原著者: Svyatoslav Kryukov（バックエンドエンジニア）、Artur Petrov（バックエンドエンジニア）、Travis Turner （技術編集者） サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 日本語ブログ: 合同会社イービルマーシャンズ - Qiita 日本語タイトルや見出しは内容に即したものにしました。
CQRS+ES の力を使って効果を感じる / Feel the effects of using the power of CQRS+ES
これは Livesense Advent Calendar 2024 DAY 21 の記事です。 転職会議の池田です。MySQL を 8.0.19 以上のバージョンにアップグレードした際に時間差で発生した Rails アプリケーションの不具合とその対応について書きます。 TL;DR なにがおきたか MySQL 8.0.19 と ActiveRecord の Boolean キャスト 実際に問題となるタイミング どのように対応したか 再発防止のために おわりに TL;DR MySQL 8.0.19 から 整数型の表示幅が表示されなくなることで、 ActiveRecord が tinyint(1) のカラムに対して行っている Boolean キャストが行われなくなる 整数型の表示幅は MySQL をアップグレードしただけでは表示されたままで、ALTER TABLE を実行したタイミングで表示さ
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Drive-by Active Storage advice | justin․searls․co 原文公開日: 2024/09/16 原著者: Justin Searls -- Test Doubleの共同創業者です 日本語タイトルは内容に即したものにしました。 参考: Active Storage の概要 - Railsガイド 今はカンファレンスの発表の準備中で、これまで私が積み重ねてきたアドバイスについて詳しく説明している余裕がありません。そういうわけで、いくつかのアドバイスを本記事にまとめておいて、スライドからリンクすることにします。 今日のお題はRuby on RailsのActive Storageです。Active Storageは、アプリケーションやデータベース・サーバーを詰まらせずに、写真や動画などのユーザー生
HotwireとNext.jsをちゃんと見て比較しよう#本サイトでは、React/Next.jsに詳しいフロントエンドエンジニアを対象に、実際に動くコードと実際に動くデモを体感しながら HotwireとReact/Next.jsを比較します。 各技術でのUIの作り方を伝えるだけでなく、さまざまな状況での動きを確認していただくために、仕組みや限界も紹介します。そのため、かなり細部の議論もしています。 HotwireでもNext.jsと同等か、それ以上のUI/UXが実現できます。「Hotwireは簡単だけど、React/Next.jsの方が優れたUI/UXが作れる」というのは、かなり特殊なものでない限りは誤解ですHotwireはバックエンド非依存です。Rails, Laravel, Django, Go, Nodeでも関係なく動きます。実際、本サイトのHotwireコードはNext.js AP
Rails7.2から、GitHub Actionsを使ったCIワークフローが標準で用意されるようになりました。 これにより、Railsアプリケーションの開発において、テストやセキュリティチェック、スタイルチェックが自動化され、開発体験が向上します。 このワークフローを見ていく中で、いくつかの学びがあったので、備忘録としてまとめてみました。 「CIで何しているかよくわからない」という方でも、この記事を通して「CIでこういうことをしているんだ」という理解を深めてもらえたら嬉しいです。 各ジョブを見ていく 1. scan_ruby（セキュリティチェックの自動化） name: CI on: pull_request: push: branches: [ main ] jobs: scan_ruby: runs-on: ubuntu-latest steps: - name: Checkout co
こんにちは。 メディアサービス開発部 Webアプリケーション開発課のフサギコ(髙﨑)です。 Ruby on Railsによるバックエンドの実装運用とAWSによるサービスインフラの設計構築を中心とした、いわゆるバックエンド方面のテックリードとしてニコニコ漫画を開発しています。 本記事では、私たちが開発・運用しているRails製のjson APIバックエンドにおいて、mallocの実装としてjemallocを使うように変更したことについてお話します。 背景 私たちが2020年4月から開発しているニコニコ漫画のRails製json APIバックエンド(以降「新バックエンド」と呼びます)は、2010年8月のサービス開始以来サービスを支え続けているPHP製アプリケーションのビジネスロジックに関する式年遷宮的移行先であり、当初よりAWS ECS Fargate上で実行しています。*1 今年8月にリリー
高度診断部アプリケーションセキュリティ課の山崎です。 弊社エンジニアの名古屋と山崎がRuby on RailsのActive Storageの脆弱性CVE-2024-26144を報告しました。 本脆弱性はRailsの5.2.0から7.1.0のバージョンに影響するもので、お使いのRailsのバージョンが最新でない場合にはアップデートを推奨します。 本記事では本脆弱性の注意点と、関連してCookieのキャッシュに関する調査内容を紹介します。 TL;DR ・ Set-Cookieヘッダがキャッシュされると別人ログイン問題が発生する ・ RailsのActive StorageでSet-Cookieヘッダがキャッシュ可能な設定であった(CVE-2024-26144) ・ Nginx(+ Passenger), Apache(+ mod_cache)等のキャッシュ機構と合わせて利用すると実際に事故が
こんにちは。SREのkyontanです。Rubyが大好きなのでRubyの話をします。ちなみにリクルートはRubyKaigi 2024へGold Sponsorとして協賛しています! *1。ぜひ沖縄でお会いしましょう。 これはあるアプリケーションのメモリ消費量を示すグラフなのですが、まさかgemを入れ替えるだけでこんなに嬉しい変化が見られるとは思っていませんでした。今日はそんなgemの話をします。 話は遡って2023年4月のある日、インターネットを眺めていたところ、ShopifyがpitchforkというOSSを公開したという情報が目に留まりました。 調べてみると、どうやら著名なRackサーバー実装の1つであるunicornの派生版であり、メモリ使用量の削減に特化しているらしいのです。 github.com これはスタディサプリ小中高のあのリソースドカ食いマイクロサービス第一位である api
RailsのためのHTTP/2プロキシ「Thruster」がオープンソースで公開された。ほとんど設定不要で、導入によりRailsアプリをより高速かつセキュアにする。 Ruby on Rails（以下、Rails）の開発元である37signalsは、より高速でセキュアなRailsアプリケーションを実現するHTTP/2プロキシ「Thruster」をオープンソースとして公開しました。 We've released Thruster as open source! It's a tiny, no-config HTTP/2 enabling, asset caching, X-Sendfile sending proxy for Rails' default web server Puma. One of the secret sauce elements of ONCE, now availab
（表内のデータ確認日：2024/03/21） スター数だけで言えば prawn が強いですし、歴史もあります。 しかし、コミットが現在もされているものの、最新バージョンのリリースが2020年12月から3年以上空いてしまったのは気がかりです。 wicked_pdf や pdfkit は1年に1度以上は新バージョンのリリースがおこなわれているので、 この２つのどちらかが良さそうに思いました。 最終的には、README が充実していて使うまでのハードルが低そうな wicked_pdf を選びました。 1-1. WkHtmlToPDF 問題 wicked_pdf や pdfkit には重大な問題があります。 これらの gem は WkHtmlToPDF という HTML を PDF に変換する CLI ツールによって支えられているのですが、 これのメンテナンスが 2022/6/29 のコミットを最
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Rails 8 introduces a built-in rate limiting API - BigBinary Blog 原文公開日: 2024/02/13 原著者: Yedhin Kizhakkethara 参考: 週刊Railsウォッチ20240123: レート制限APIを追加 Web開発の動的な世界では、リクエストのフローを管理することがアプリケーションの応答性と信頼性を維持するうえで重要です。レート制限（rate limiting）はAPIの交通整理巡査として機能する強力な技術であり、リソースへの正当なアクセスを確保して潜在的な混乱を防ぎます。レート制限を一言で言うと、「ユーザー」「デバイス」「アプリケーション」が一定の時間枠内で許されるリクエスト数（レート）を制御することです。 本記事では、レート制限の概念を詳
まとめ: アプリのサーバー設定はRuby Webアプリのスループットやコストあたりのパフォーマンスに大きな影響を与えます。設定の中でも最も重要なものについて解説します（2846 word、13分） RubyのWebアプリサーバーは、ある意味で自動車のガソリンに似ています。よいものを使ってもそれ以上速くなりませんが、粗悪なものを使えば止まってしまいます。実際にはアプリサーバーでアプリを著しく高速化することはできません。どのサーバーもだいたい同じようなものであり、取っ替え引っ替えしたところでスループットやレスポンスタイムが向上するわけではありません。しかしダメな設定を使ったりサーバーで設定ミスしたりすれば、たちまち自分の足を撃ち抜く結果になります。クライアントのアプリでよく見かける問題のひとつがこれです。 本記事では、3つの主要なRuby アプリサーバーであるPuma、Unicorn、Pass
このエントリは SmartHR Advent Calendar 2023の21日目の記事です。 Railsのバージョンを上げる作業は、単に新しいバージョンのgemをインストールするだけでは終わりません。Railsの新しいバージョンに沿った設定項目を確認し、適宜適用していく必要があります。もちろん必ずしもすべての設定を最新にしなければならないわけではありませんが、Railsの新しい設定というのは基本的にそうすることにメリットがあるから作られているわけで、特別な理由がなければ最新の状態にしておきたいものです。 みなさんのRailsアプリケーションのconfig/application.rb には次のような設定があるはずです。 config.load_defaults 6.1 このコードサンプルは引数が6.1なので、Rails6.1デフォルトの設定を適用していることを示しています。これを7.0に
週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Rails 🔗 rage: Rails互換の高速APIフレームワーク（Ruby Weeklyより） つっつきボイス:「Railsっぽく書ける軽量かつ高速
SmartHRでは開発にRuby on Railsを広く採用しています。 今日は負債解消のために、開発しているサービスでRailsのモデル名をすべて変更した話を紹介します。 既存のモデル構造のつらみ 私達が開発しているサービスでは、モデルの親子構造が分かりやすいということで、モデルをネストした構造にしていました。 例えば、 User に紐づくプロフィール画像 User::ProfileImage は、 app/models/user/profile_image.rb に配置する具合です。 パッと見の構造が分かりやすいのですが、時が経つにつれて次のようなつらさが顕在化してきました。 Railsの規約(推奨ルールのようなもの)に則っていないので、関連定義が冗長になる テーブル名が長くなる。 外部キーや関連名が長くなる。 関連名と外部キー名が一致せず、カラムを呼び出したいときにDB定義を見ないと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
