Ruby on Railsの驚異的な台頭は、斬新な技術とタイミングによるところが少なからずあります。しかし、技術的な優位性は時間の経過とともに失われていきますし、タイミングの良さだけでは長期にわたってムーブメントを維持できません。そのため、Railsがどのようにして現役であり続けることができたのかだけでなく、どのようにしてそのインパクトとコミュニティを成長させてきたのかについて、より広範な説明が求められています。私が提唱するのは、永続的な実現要因は、今も昔も物議を醸しているドクトリン（信条）にあるということです。 このドクトリンは過去10年の間に進化してきましたが、その最も強力な柱のほとんどは開発当初からのものでもあります。私はこれらの考え方の根本的なオリジナリティを主張していません。Railsの主な成果は、プログラミングとプログラマーの本質についての異端的な考えを手広く集めたものを中心に
class DeviseCreateUsers < ActiveRecord::Migration[6.1] def change create_table :users do |t| t.string :first_name, null: false, default: "" t.string :last_name, null: false, default: "" t.text :profile, t.string :telephone, t.integer :age, t.integer :role_id, t.integer :company_id, t.datetime :deleted_at, ## Database authenticatable t.string :email, null: false t.string :encrypted_password, null:
STORES でエンジニアをしている片桐です。 STORES では店舗運営に関するさまざまなプロダクトを提供しています。これらのプロダクトは元々別の会社で運営されてきた完全に異なるプロダクト群で、アカウント体系から全く異なるシステムになっていました。近年はこれらのシステムを本格的に統合する取り組みを進めてきており、その中で統合のためにいくつかのシステムが新たに作成されてきました。 ある程度統合が進み、うまくいったところ・いかなかったところが見えてきた中で、これまでに作ったシステムの技術選定・システムの役割に対する課題感が見えてきました。 現在弊社ではこの課題を解決していくプロジェクトを進めています。その中の1つで、Goで作られたシステムをRuby on Railsで作られたシステムに移植する作業を行なっているので、今回はそれについて紹介させていただきます。 移植元のシステムの課題 今回別シ
はじめに 現在携わっているプロジェクトで、ActiveStorageでS3にアップロードしたファイルをCDNを利用して配信するタスクを担当することになりましたが、同じようなタスクを処理した経験がなかったため、私用のAWSアカウントでS3とCloudFrontを用意して試しに実装してみました。 この記事では、Active Storage（プロキシモード） + S3 + CloudFront でファイル配信を実現した方法や、学びになったと感じたことをまとめました。 「自分なりにこう理解している」という内容を記載していますが、記載されている内容に誤りが含まれている可能性がありますので、「この部分おかしいんじゃ？」「ここはもっとこうした方がいいのに」等のご指摘やご質問がございましたら、是非コメント頂けますと幸いです🙏 CDNとは？なぜ必要なのか？ CDNとは、Content Delivery N
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: How to: Rails params.expect - Martin Emde 原文公開日: 2024/10/22 原著者: Martin Emde -- RubyGems.orgとbundlerのメンテナーです。 日本語タイトルは内容に即したものにしました。 参考: 4.6 Strong Parameters -- Action Controller の概要 - Railsガイド 参考: Rails 8.0 API expect -- ActionController::Parameters -- APIドキュメントでも、従来のpermitとrequireよりexpectが望ましいと書かれています。 参考: 8.0 Changelogのexpect -- ここにも詳しく書かれています。 以下の記事もどうぞ。 Rails 8:
Rails 7.2 で rails new した際に搭載される rubocop-rails-omakase について、それがどのようなもので、どのように使うことを期待されているかを書き記しておきます。 github.com rubocop-rails-omakase は DHH が著者となる Ruby コーディングスタイルルールです。 一次情報はあくまで作者である DHH 発信のものとしてもらいたいですが、私自身も rubocop-rails-omakase や Rails 7.2 の RuboCop 関連機能にコントリビューションしていることもあり、比較的オリジンに近いことを述べることができると思います。また RuboCop のコミッターをしているため、たぶん RuboCop の世界にちょっと詳しい方でしょう。 とはいえ、いろいろな考え方がある領域であることも承知しているため、ひとつの考
こんにちは osyoyu です。RuboCop は好きですか？ B/43の開発の現場でもRuboCopは活用しており、ご多分に漏れず .rubocop.yml がすくすくと育てられていました。コードの一貫性はよく保たれていた…… のですが、 # rubocop:disable がそれなりの頻度で出現したことからも、適用されているルールが最良のものかは少しばかり疑問があった、という具合です。 そこで、今回は “unconfigurable” をウリにしているRuboCopルールセットであるStandard (standardrb/standard) を採用し、全コードをこのルールに適合するよう修正しました。Standardは少々 “強い” 名前ですが、コミュニティの中でコレ一強・一択というものでもなく、あくまでひとつのオプションという立ち位置です。 しかしそれなりに大きなコードベースではこの
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
このYouTubeライブはフロントエンドの最適化を専門にするmizchiさんがCloudflare Meet-up Tokyoで行った同タイトルのプレゼンを、RustやRDBの実装に詳しいkoba789さんを話し相手に語っていくというものだ。背景としては2人ともチーム開発の現場でのRailsが活発に利用されていた時期にウェブ開発を経験し、現在はNode.jsのサーバーサイドも実践している。 ライブは3時間半という長時間におよび、スライド外の周辺情報や持論や余談など多岐に渡るので、すでにこのプレゼンに触れた人でもさらに深掘りできるようなコンテンツになっている。 全体を大まかに1時間ごとの3パートに区切って視聴するとわかりやすい。前半はRailsからNext.jsに辿り着くまでのウェブ開発の変遷。ORMの話は主に後半戦で。最後の1時間はアフタートークになっている。 内容としてはRailsアプリ
この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 60 週目の記事です！2年間連続達成まで 残り 46 週 となりました！ 「モジュラーモノリス」はここ数年で広く普及してきました。実際にモジュラーモノリスを取り入れた開発事例を多く見かけるようになりました。当記事では改めてモジュラーモノリスの起源を遡り、また、さらにその先に進むためにどのような準備をしておくべきかを軽くまとめてみます。 モジュラーモノリスとは モジュラーモノリスの起源は 2018 年頃 「モジュラーモノリス」という言葉の正確な起源は把握していませんが、Simon Brown が GOTO Conference 2018 で行った講演がその起源の一つかもしれません。この講演は、モジュラーモノリスの概念をわかりやすく説明しており、その後、多くの企業がこれに注目するきっかけとなりま
【アドカレ2023】Sidekiqのredis-namespace gemからの脱却 これは 株式会社TimeTree Advent Calendar 2023 の12日目の記事です。 11日目は @gonsee の カレンダー開発の怖い話: 週番号 の記事 でした。 こんにちは。今年の4月からTimeTreeに入社し、プロダクトDivというチームに所属しています。 社内では Dashというニックネームで働いています。 この記事では、 redis-namespacegemからの脱却までに行なった手法などを紹介していこうと思います。 ※この記事に使用しているバージョンはそれぞれ下記の通りです。 Ruby on Rails：7.0.8 ElasticCache for Redis：7.0.7 Sidekiq Pro：5.5.8 redisgem：4.8.1 redis-namespacegem
遠藤氏の自己紹介遠藤大介氏：今日は「AWSのLambdaとPlanetScaleを組み合わせると、超絶スケールするWebアプリを作れちゃうぜ」という話をしていこうと思っています。 最初に自己紹介です。遠藤と申します。SonicGardenという会社で、プログラマーと執行役員をやっています。インフラと機械学習などが好きで、趣味もプログラムで仕事もプログラムな感じの人間なんですが、最近は機械学習周りが盛り上がっているので、そっちもいろいろやっています。 あと、ロードバイクに趣味で乗っているのですが、最近ちょっと乗れていません。それからゲーマーで、最近は『FF16』にどっぷり浸かっています。 （スライドを示して）ささっと2個ほど宣伝したいのですが、SonicGardenで無料のオンラインプログラミング合宿をやろうと思っていて、今、夏のキャンプの申し込み受付をしています（登壇時点）。 学生や第2新
Ruby shop turns to Go, Java, and Kubernetes for platform makeover Analysis GitHub invited a handful of journalists to its San Francisco headquarters to explain how the social code hosting biz is evolving from a website into a platform. The event was hosted by Sam Lambert, whose title – head of platform – removes any doubt about how things will turn out. Founded in 2008, GitHub became a platform fo
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Gemfile of dreams: the libraries we use to build Rails apps—Martian Chronicles, Evil Martians’ team blog 原文更新日: 2024/05/28 原著者: Vladimir Dementyev（首席バックエンドエンジニア）、Travis Turner（技術記事編集者） サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 日本語ブログ: 合同会社イービルマーシャンズ - Qiita 日本語タイトルは内容に即したものにしました。また、gemごとにGitHubリポジトリへのリンクカードも追加してあ
今年もRubyKaigiが始まりましたね！noteはrubyスポンサーとして協賛しています。三重の会場にきている方は、ぜひnoteのブースにも足を運びください。 さて、noteはRuby on Railsを用いたwebサービスとして2014年にリリースされました。現在でも継続してRailsのコードベースを利用しています。 しかし、多くの機能がリリースされ、開発者も増えたため、モノリスの巨大化が進んでおり、開発効率に影響が出始めていました。 今回はそれらの問題を解消するために、noteが継続的に取り組んでいる・取り組んできたバックエンドの改善プロセスについて説明していきます。 モジュールでサービスを構成するモノリスは大きくなるとメンテナンスが難しくなります。Railsは、MVCの各層に全てのドメインがフラットに並び、レイヤごと・レイヤ間の結合度が高くなる設計思想で、巨大モノリス化への対処が難
はじめに 「Railsは関心の分離が不十分である」という批判をよく目にします。状況が深刻になったら、Railsに足りない別のピースを導入しなければならないというのです。しかし私たちはそうは思いません。 「素のRails（vanilla Rails1）ではここまでしかできない」みたいな批判を耳にすることがよくあります。Railsはアーキテクチャレベルで関心の分離が不十分なのだから、アプリはいずれメンテナンス不能になり、足りないピースを導入するという別のアプローチが必要になるというのです。 代表的なDDD（ドメイン駆動開発）書籍では、概念上の4つの層である「プレゼンテーション層」「アプリケーション層」「ドメイン層」「インフラストラクチャ層」について議論しています。 アプリケーション層は、ドメイン層と協調動作してビジネスタスクを実装します。しかし、Railsが提供しているのは「コントローラ」と「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
