この本ではHotwireの基本的な使い方について解説します。 Rails7からフロントエンドのデフォルトにHotwireが採用されたのですが、まだあんまり日本語の情報が無かったので本にまとめました。Turboをメインに扱っていますが、Stimulusも扱っています。 Hotwireの最初の1冊として読んでいただけますと幸いです🙇♂️
Caution この記事はDHHファンの妄想によるシナリオが多分に含まれます。 というかほとんどです。 成り立ちが間違ってることも当然あるように思うので話半分で読んでください。 これは一体 最近のRailsフロントエンドやDHHの活動には一連の流れがあるわけですが、一部トレンドに沿ってない部分がある故にそれが汲めないというところがあるのではと思います。 それらの流れを記憶が定かなうちにつないで記録しておこうという記事です。 前提知識 Railsの生みの親、Rubyist Basecamp(社) DHHがCTOやってる会社 Basecamp(サービス) Basecamp(社)が開発してるプロジェクト管理ツール Trixを開発してたある日 Basecamp(サービス)に組み込まれてるリッチテキストエディタのtrixをcustomElements使って開発してたある日、DHHはあることに気づく。
これは何 「Rails Wayに沿って〜」とはReview欄などでよく言われるが、定義が人によってぶれている気がするので俺のRails Wayを示した記事です。 もはや本来のモノとは別物かも知れませんが、俺はこういう観点でRailsをみて、コードを書いているよ、ということを知ってもらう意味でもこの記事を公開することにしました。 前提として、「数人以上のチームでプロダクトを実際に開発して運用する」場合の自分のスタンスを示したものです。(私も仕事では独自DSLは書きませんが自由研究用途なら自分も独自DSLを書いたりします。) それでは、いってみましょう。 Model層 データベースの操作およびビジネスロジックを記述する。 テーブルの属性は原則NOT NULLにするべき。どうしても要件上NULLを許容しなければならない場合のみNULLを許容する。 Controllerからparamsを無思考で渡
Railsのコールバックが辛いって本当?実際にハマって、学んだこと チーム開発での経験は、一人で開発していた時とは全く別ものでした。Railsのコールバックは、 書いた本人ではなく他のメンバーが辛くなる ことが多いということを実体験を通して学びました。コールバックで苦しんだ経験を実際のシーンを元に書いてみました。 はじめに こんにちは。KitchHikeインターンエンジニアのタクです。 社員エンジニアの方から「Active Recordのコールバックは使い方を気をつけよう。」という趣旨のことを、入った頃から何回も言われていました。しかし、開発経験の浅い自分にはなぜ気をつけないといけないのかあまりピンときていませんでした。 たしかにインターネット上にはアンチコールバックの記事が多いのですが、どの記事を読んでも実体験がないからか、心から納得することはできませんでした。 「なぜそんなにもコールバ
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
Rails Developers Meetup 2019(2019/03/22 - 23)
背景 Skinny Controller, Fat Model Railsではスキニーコントローラー、ファットモデル(Skinny Controller, Fat Model)という方針のもと、 コントローラーのコード量を少なくして、モデルを分厚くするという書き方が推奨されていました。 10 Ruby on Rails Best Practices — SitePoint Rails Best Practices 1: Fat Model – Skinny Controller このような背景から、ファットモデルという設計が目指すべき設計という認識となりました。 「ファットモデル問題」の登場 ところが、原因はわかりませんが、次第にファットモデルが問題があるものとしてみられるようになりました。 界隈では「ファットモデル問題」として取り上げて解決するという方法が紹介されるようになります。 20
0. 背景 職場その他でいくつかのRailsプロジェクトを見て来て、同じ組織であってもリポジトリが違えば雰囲気が全然違うなと思い、その中でもこれはダメだろうと思ったことがありましたので、自分の備忘録も兼ねて記述します。 ここ2年ぐらいで出会ったRailsプロジェクトを見て感じた例ですので、他にも挙げようと思えば挙げられると思いますが、出会った中での記述ということでご理解ください。 また、技術的、より個別的な事象についてはRails AntiPatternsを読むといいかもしれません。 1. rubocopを導入していない rubocopはRuby Style Guideをベースにしたrubyの静的解析ツールです。Rubyを使ったことのある人で知らない人はいないでしょう。また、Ruby Style Guideについても、Rubyを勉強する初期に一読しておかなければいけないと言われる代物です。
バージョンアップがツライ毎度毎度、バージョンアップで非互換な修正加えてコードの修正が必要になって、Gemも上がって依存が壊れて いつまでやってんだよw Railsのプロジェクトでどれだけの人が最新版に追従できてんだよ?テストを書いてれば余裕? 本当かよ?正直に言ってみろよ?実際はレガシーRailsの山だろw 概念・周辺ツールがツライヘルパーやらマイグレーションの仕組みやら最初は良いかなと思ったけど、どう考えてもやり過ぎだ 短くかけるとか喜んでるやつは一度考え直せ 複雑さがRails側に寄ってるだけでなんも解決してない それで良いんだって?自分がコントロールできない知らないコードに依存して結局バージョンアップで地獄みてるだろw 最低限中で何が起きてるか理解しとけよwまあ理解できるころにはRailsでなくても良かったんやwってなるけどなw RAILS_ENV=productionだとstati
はじめに 人間は誰しも間違いを犯します。 「恥ずかしい間違いはすぐに修正してなかったことにしたい」と考えるのは当然の心理です。 幸いなことに、プログラム中のささいなtypoであれば、ささっと修正してコミットすれば、あたかも何もなかったかのように過去の間違いをかき消すことができます。 が! Railsアプリケーションの場合、migrationファイルだけは安易に修正してはいけません。 この記事ではその理由と、正しい修正の手順を紹介します。 問題が起きるシナリオ:花子さんはdb:migrateできない あるブログシステムにはUserテーブルがあります。 太郎さんはここに生年月日を保存するカラムを追加しました。 class AddBarthdayToUsers < ActiveRecord::Migration def change add_column :users, :barthday, :
RailsのAsset PipelineとPrecompileをNode.jsのみで処理できるgulp-sprocketsを作った 仕事ではRailsアプリを書いていて、JSやCSSなどのフロントエンドはRailsのAsset Pipelineの仕組みに則ってビルドしてる。 普通にRailsアプリ作ってると普段Sprocketsについて特に意識しないと思う。 Sprocketsはそこが凄くて、あまり考えなくてもドキュメント通りにやってれば、必要なAssetを結合できて、リリース時は変更がなければブラウザキャッシュから、変更があれば 新しく読み込まれるみたいなことをやってくれる。 なんだけど、もうそろそろ新しい機能はES2015で書きたいよねという人が増えてきた。 とはいえSprocketsは独自のディレクティブ以外は使えなくて、SprocketsWayから外れると途端に脆い。 ES2015
こんにちは、freeeでフロントエンドエンジニアをしている @joe_re です。 freee Engineers Advent Calendar 2015の4日目を書きます。 僕からはfreeeで現在進行中の革命について、フロントエンドのビルドプロセスを中心に書こうと思います。 革命 ってなんのこと? というのはフロントエンドヤンキーこと @ymrl が 2日目で書いたので詳しくはそちらをご参照頂ければ幸いです。 背景 弊社ではRuby on Railsを主軸にしてWebサービスを作っています。 Railsは素晴らしいフレームワークですが、めまぐるしく変化する昨今のフロントエンドについては、このままRailsの用意しているRailに乗ったままでは時代に取り残されてしまう危機感があります。 僕たちは時代に取り残されている場合じゃない。 最先端でかつ適切な技術を用いて未来を切り開いていかなく
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
db/schema.rbは何に使われるのか rake db:migrateなどをすると現在のスキーマが反映され、スキーマの確認などに便利なschema.rb。 ふと、1つのRailsアプリを分割して、複数のRailsアプリから同じDBを参照するようにしたくなったのだが、その際にどちらのRailsアプリにもdb/schema.rbを含める必要があるのか気になった。 db/schema.rbを削除してもアプリは動くのだが、 schema.rbには「It's strongly recommended that you check this file into your version control system.」と書いてあるので、本当に削除していいのか自信がない。 そこで、Rails4.1.5のソースを読んで、schema.rbがどんな用途に使われているのかを調査した。 schema.rbが
2014.02.07 ちょっと待った! Railsのgitリポジトリから Gemfile.lockとdb/schema.rbを除外してはいけない こんにちは、hachi8833です。 Railsをgitで管理するのであれば、ログファイルや、パスワード入りdatabase.ymlなどの登録したくないファイルを.gitignoreに記載してリポジトリから除外するのが普通です。しかし実際の案件では、除外すべきでないファイルが除外されていることがたまにあります。言うまでもないような話ですが、心当たりのある方は念のためチェックしてみましょう。 gitリポジトリから除外すべきでないファイル 以下では、誤ってgitリポジトリから除外されがちなGemfile.lockとdb/schema.rbについて説明します。代表的なものであり、すべてを網羅しているわけではないのでご注意ください。 Gemfile.lo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く