Railsを高速かつセキュアにするHTTP/2プロキシ「Thruster」、37signalsがオープンソースとして公開
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
個人的Rails開発環境構築2024
新規でRailsプロジェクトを始める時の個人的な環境構築についてまとめる。前提とする条件等は下記。 規模: ~中規模 開発者数: 個人 利用シーン: PoC作成・スタートアップ立ち上げ・並の業務アプリ開発等 基本戦略 利用シーン的に「思い立ったらすぐアプリの開発ができる」という感じの運用がしたい。極力セットアップで悩みたくないから必要なミドルウェアなどは全部Dockerでインストールできるようにして立ち上げれば終わり、の環境を作る。その環境の中で色々とコマンドを叩いたり、rails newやrails gなどでRailsアプリを作成していく。 この辺のRailsの初期セットアップの手間を出来るだけ省きたいのでtemplateとなるリポジトリを作成し、そこからcloneしてくるだけでOKにする。 フロントエンドはReactなどを使わずをRails標準のerbとHotwireを軸に開発する。開
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を利用しており、またファイル
大阪Ruby会議03でHotwireを使ったモーダルUIを15分で作ってみました＆基調講演裏話 #osrb03 - give IT a try
はじめに 2023年9月9日に開催された大阪Ruby会議03で、基調講演（キーノート）を担当させてもらいました。 regional.rubykaigi.org 当日使った資料はこちらです。 発表のタイトルは"Enjoy Ruby programming, Enjoy Ruby community!"でした。 今回の基調講演ではちょっと攻めた取り組みとして、「Hotwireを使ったモーダルUIを15分で作る」というテーマでライブコーディングもしてみました。 www.youtube.com ライブコーディングには思わぬトラブル付きものですが、今回は何とかノートラブルで実装できました！ 時間も15分以内（たぶん12〜13分ぐらい？）に収まりました〜😄 基調講演をするにあたって意識したこと 今回、基調講演を担当するにあたって「IT系カンファレンスの基調講演はどういうものであるべきか」を自分なりに
Remove TypeScript - laiso
経緯 world.hey.com DHHが「オタクくん見てる〜？ 今からうちのレポジトリからTypeScriptを剥しま〜す」と宣言したことにより、Web開発者界隈でTypeScriptの是非自体の話になり騒ぎになった*1*2。 github.com その後、野次馬がたくさん集ってきてrevertプルリクエストを立てる人やTypeScript公式リポジトリから全ソースコードを消すプルリクエストを出す*3ようなキッズムーブをする人も出てきた world.hey.com 実際の変更 8617行のTypeScriptがJavaScript化された。(Sloc 便利) ❯ scc src/ ─────────────────────────────────────────────────────────────────────────────── Language Files Lines Blan
モダンウェブフロントエンド勉強会を開催しました - クックパッド開発者ブログ
こんにちは、クックパッドで最近はモバイルアプリを離れもっぱらウェブアプリを作っている @morishin です。 先日、社内で「モダンウェブフロントエンド勉強会」と題して React, Next.js, Core Web Vitals, SSR, CSR, SSG, ISR, SSR Streaming, React Server Component といったキーワードに触れつつ、昨今のウェブ開発事情について話をしました。せっかくなのでその内容の共有と、勉強会を開催した動機などを紹介したいと思います。 この話は fukabori.fm でも取り上げていただいてお話ししたので、よければそちらもご視聴ください。 fukabori.fm 背景・動機 クックパッドのウェブアプリケーションは10年以上もの間 Ruby on Rails で開発されてきましたが、2020年から一部のページは Next.
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
Railsを主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ
Rails の問題は Rails のベストプラクティスがフロントエンドのベストプラクティスの邪魔になるどころか全く逆方向で相反してる点です。DHHの思想がフロントエンドと根本的に逆行してる。そういう人が作るフレームワークなのでwebpackerの抽象化を根本的に間違ったりする。 — prev.js (@mizchi) December 1, 2020 昨日もリプライで少し書いたけど、DHH自体が直近のHeyの開発でも明確にJavaScriptというものを触れないようにすることを是としているような主張をしているので、DHH wayが色濃く反映される以上この状態はもう避けられない気がしている — potato4d / Takuma HANATANI (@potato4d) December 1, 2020 Railsがフロントエンドの最先端をゆく人々1から良く思われないのは事実として。 Vie
Railsで作るBFFの功罪
This document discusses using Rails as a backend for front (BFF) layer in a microservices architecture. It describes how Rails was used to build the BFF layer for an e-commerce site called HPB, acting as an API gateway between the client and various backend services. Key points discussed include using Puma to improve throughput, caching APIs to reduce response time, and implementing an API gateway
Rails 7.0正式リリース、Node.js不要のフロントエンド開発環境がデフォルトに
Ruby言語によるWebアプリケーションフレームワークの最新版となる「Rails 7」が正式リリースされました。 Rails 7.0 FINAL: The fulfillment of a vision to present a truly full-stack approach to web development that tackles both the front- and back-end challenges with equal vigor. https://t.co/WxJ0nKYfE7 — Ruby on Rails (@rails) December 15, 2021 Rails 7の最大の変更点は、フロントエンド開発環境が刷新されてNode.jsを用いない構成がデフォルトとなったことでしょう。 Rails 6では、優れたフロントエンド開発環境を実現するためにトランスパ
GraphQL と Prisma から考える次のN年を見据えた技術選定 / Architecture decision for the next N years at StudySapuri
JSConf JP 2021 で登壇した資料です #jsconfjp #jsconfjp_b Links: [Active Recordから考える次の10年を見据えた技術選定](https://speakerdeck.com/yasaichi/architecture-decision-for-the-next-10-years-at-pixta) [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architecture-pract
Rails 7.0でアセットパイプラインはどう変わるか | Wantedly Engineer Blog
Rails 7.0ではフロントエンドサポートが刷新されます。新たなライブラリが多数導入され、選択肢が増えるため、「Rails公式のものを選べばOK」という戦略が通用しなくなります。 本稿では、Railsでフロントエンドを書くための選択肢について、その歴史と実装を踏まえて比較検討します。 結論から言うと(まだアルファ版なので今後も状況が変わる可能性はありますが、) 新規アプリケーションではSprocketsの役割は無くなりそうです。新しいライブラリとして Propshaft, importmap-rails, jsbundling-rails, cssbundling-rails が登場し、主要な選択肢として以下が提供されます。 (各ライブラリの詳細については後述します) Propshaft + importmap-railsデフォルトの選択肢。Node.jsが不要。トランスパイルを含め、複
RailsでCloud Runは1月いくらかかるか - komagataのブログ
フィヨルドブートキャンプというプログラミングスクールのEラーニングアプリをCloud Run + Railsで動かしています。 1ヶ月使ってみた結果、8,000円ぐらいでした。 Cloud Runが300円でCloud SQLが7,000円って感じです。Cloud Buildとかちょこまかしたのはありますが誤差の範囲。 Cloud Runは1コンテナだったら1日10円ぐらいなんですよね。信じられないほど安い。 これでDockerイメージ放り込んでおけば自動スケールの環境が手に入るならほとんどの仕事のアプリはこれでいい気がします。パフォーマンスもいいし、これからのアプリは全部これで行こうと思います。
著名なオープンソースRailsアプリのapp/以下を見る
Railsにおける app/ とは app/はRailsのアプリケーション用ディレクトリで、普通のRailsアプリケーションでは、この下にmodels,controllers,viewsを含めた様々なディレクトリが作られます。 基本的には新しいディレクトリを追加する必要はないのですが、アプリケーションが複雑になると、Railsを拡張するべくここにアプリケーション固有のディレクトリを作って、その下に関連するファイルを置くことがあります。 中には、servicesやserializersのように、多くのRailsアプリケーションで見られるものもあれば、完全にアプリケーション独自のものが作られることもあります。また、アプリケーションによっては独自のディレクトリは一切作らないものもあれば、大量に作るものもあります。それぞれアプリケーションの開発方針によるものです。 本記事では、比較的有名なOSSの
Rails 設計 最強
自分が目指したいRailsアプリの形とは何か、ということについて考えていた。 常日頃から考えていたRailsアプリでの不満をこの議論に合流させた結果、「Rubyを書くときに当たり前にやるようなことを、Railsアプリを書くときでも当たり前のようにやる」というところが肝で、自分が目指したいRailsアプリの形はその先にあるのではないか、と一旦結論付けてみることにした。 「普通にRubyでコードを書くときはやらないけど、Railsだったらこう書く」という何かが存在していることが、さまざまな失敗の原因をつくっていると思う。 RubyとRailsが地続きに繋がっていないというか、どこかで断絶があり、そこから筋の悪い設計が生まれている ―あるいは持ち込めるはずの良い設計を持ち込めていない― のではないか、という話。 実際にはどの辺りが気になっているのか？という例を挙げると、氷山の一角を指摘するだけな
最近のRails関係の仕事内容
RubyやRailsのアップグレードを主なマイルストーンとしつつ全体的に開発体験を良くしていくというタイプの仕事を請けることが多いのですが、仕事を依頼する側の視点に立ってみると「実際のところ業務に参加するとどういうことが行われるのか？」というのがやはり気になると思います。 実際、最近の打ち合わせでもその手の不安について相談されることがあったので、ここ1ヶ月でそれ系の仕事で出したPull Requestを元に、実際に何をやっていたかの例を挙げてみたいと思います。 開発環境構築手順や説明方法の改善 荒れたRuboCopの改善 .rubocop.ymlからTargetRailsVersionを取り除く DEPRECATION WARNING対応いろいろ 既存のメソッドと名前が被っているスコープを別名に変更 RSpecのpositional-argumentsを置換 activerecord-im
Railsは技術的負債である
Railsを使うと、初速は早くなる。それは間違いないと思う。一方で、RailsはVierwからDBまで密結合したフレームワークなので、「段階的なアップグレード」とかがむずかしい。ヴァージョンをあげるときには一気にエイヤであげる必要が出てきがちである。さらに、プロダクトが巨大になってくると結局様々な工夫を凝らしてViewからDBまでの間を疎結合にしていくことになる。そうなってくると、「これRailsである意味あるんだっけ」となって、段階的なアップグレードのしにくさや気をぬくと密結合な設計になるという欠点が目立ってくる。 これは、まさに技術的負債そのものである。ここでわたしが「技術的負債」を「単なる悪いもの」として扱っているわけではないことに注意してほしい。Railsを使うというのは、そういう将来の負債を借り入れて、その借金を使って早くプロダクトを世の中に届けるという判断をしている、ということ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails 7.1をn倍速くした話
Hotwire を 本番環境で使ってみた感想
The Majestic MPA
