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著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です
銀座Rails#21で「Fat Modelの倒し方」を発表しました
Fat Model1まずはFatステージ1。Railsというものを全然知らない超初心者が陥るステージです。ビューに何でもかんでもロジックを書いちゃう。その結果がFat Viewです。 次にFatステージ2。ある程度Railsに慣れてきた開発者が陥るステージです。Modelへのロジック分離がうまくできず、Controllerにロジックが集中する。その結果はFat Controllerです。 最後がFatステージ3。Railsを習熟したエンジニアであればModelにロジックを寄せていくのが定石です。その結果出来上がるのはFat Modelです。 このように どんなにRailsに習熟してようと最終的にぶつかる壁がFat Model です。 Fat Model対処のための３つのアプローチFat Modelを倒すためのアプローチとして、僕は下記の3つに分けて整理すれば良いのではと考えました。 Rai
Rails: リクエストのライフサイクルとRackを理解する（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Lifecycle of a Rails Request 原文公開日: 2019/05/02 著者: Godfrey Chan サイト: Skylight 日本語タイトルは内容に即したものにしました。画像は元記事の引用です。 2019/10/03: 初版公開 2022/08/02: 更新 参考 以下のサイトで、Railsのリクエストの全ライフサイクルをビジュアル表示で追うことができます。本記事と合わせて参照することで理解が進むと思います。 サイト: Rails Trace rails-trace.chriszetter.comより 本記事は、私達がRailsConf 2019で行ったスピーチのまとめです。スライドはこちらでご覧いただけます。 エディタでコントローラのファイルを開き、アクションメソッドにRubyコードを少々書
Railsで処理を別クラスに切り出す方法について - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はエンジニアが増えた影響か、Railsの質問に答えていることが多いです。 以前、Railsの太ったモデルをダイエットさせる方法についてというタイトルでPOROを使っていこうという話を書きました。その際にコード例などもなるべく多く載せるようにしたのですが、このエントリだけを読んだ状態では、いざ「POROを使ってみよう！」としたときにまだ悩む余地がありそうです。 POROはその名の通り普通のRubyオブジェクトなので、いろんな書き方ができてしまいます。それなりに経験がある人でないと、どのように書いたらいいんだろう…と悩んで時間を使ってしまいそうですね。さらに、複数人で開発しているチームだと書き方のバラツキも気になるところです。きっと、POROを書くときのお作法が決まっている方が開発しやすいはず。 そこで、
立ち上げ期スタートアップのテスト方針（Ruby on Rails編） - マチマチ技術ブログ
こんにちは！マチマチというご近所SNSを開発している id:fujimuradaisuke です。 スタートアップで働くみなさん、テスト書いてますか？テストの書き方・方針ってチームによってかなり異なるんじゃないかなーと思っています。実際いままで僕が参加したチームもそれぞれに個性がありました。そこでマチマチのテスト方針やその背景をシェアしたら面白いのでは…？と思ったので（僕は他の人のテスト方針を読みたいです）、社内向けにまとめておいた文章を共有してみようと思います。 背景 ご近所SNSマチマチは「ひらかれた、つながりのある地域社会をつくる」というミッションのもと2016年に開発がスタートしました。現在外部のお手伝い頂いている方を含めて5人のエンジニアで開発しています。構成としてはプレーンでモノリシックなRuby on Railsのアプリケーションです。現在は気がつけばモデルが200個とそこそ
Vim入門でつまづいたが再入門しました - そういうこともある
1. 経緯 今更ながらですが、Vimに入門してみました vimを使うときは、Gitでコミットメッセージ書く時だったり、サービス運用時、緊急対応でサーバに入って直接ファイル触るとかあったので、Vimは使えるようになりたいな〜と常々思っていました ただなかなか使いこなせず、結局移動は矢印キー使ってしまったりとなかなか活かしきれていなかった感じです さすがにそろそろ本格的に使えるようにしないといけないなと思ったので、色々と調べてみて再度入門してみたので、それをまとめてみました 2. 何をしたのか？ Vim関連の情報収集 初心者向けにわかりやすくまとめてある記事が多く、最初からこれを読んでおけばよかったと後悔 Gitのコミットログ書くときはvimでなど、色々な場面でvimをなるべく使うようにしました 最初はなれなくてかなりストレスでしたが、少しづつ手に馴染んでくるまでなんとか耐えて乗り切りました
【Everyday Rails Blog 翻訳】RSpec 3.7.2へのアップグレードとシステムスペック - give IT a try
はじめに 先日もお伝えしたとおり、電子書籍「Everyday Rails - RSpecによるRailsテスト入門」はRails 5.1とRSpec 3.6に対応しました。 ただし、RSpecについては現在すでにバージョン3.7がリリースされています。 RSpec 3.6と3.7は機能的な差異はほとんどないのですが、一点だけ、「システムスペック」という新しいタイプのテストが増えています。 このシステムスペックについて、原著者のAaronさんがご自身のブログで紹介されているので、その内容を翻訳してみました。 Everyday Railsの読者の方は（もちろんそれ以外の方も）ぜひ参考にしてみてください。 RSpec 3.7.2へのアップグレードとシステムスペック 原文: Upgrading to RSpec 3.7.2 and system specs | Everyday Rails 数ヶ月
Rails tips: Value Objectパターンでリファクタリング（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Refactor you Ruby on Rails application using value object pattern 原文公開日: 2018/01/31 著者: Paweł Dąbrowsk Value Objectは、Null Objectパターンと同様Rubyの純粋なオブジェクトです。こうしたオブジェクトは値を表現しますが、ユーザーオブジェクトのようなシステム内で一意のオブジェクトを表現するためのものではありません。Valueオブジェクトは常に値だけを返しますが、Policy Objectのように論理値（true/false）だけを返すのではなく、他の値を返すこともできます（ほとんどの場合文字列です）。このパターンにおけるルールは、「シンプルに保つこと」と、「オブジェクトが生きている間は属性値をしないこと」です。
Ruby on Rails Is Dead — 2018 Edition
It’s 2018, and it’s high time for us at JetRuby to once again scrutinise everything we believe in, and answer the million (ish)-dollar question: “Is Ruby/Rails finally deader than a coffin nail in 2018?” The rumors of Ruby’s nascent (inevitable, immutable, irreversible) demise have been whispered about for years inside developer locker rooms, and yet the language and Rails, the framework, are stil
Railsアプリケーションにおけるフロントエンド環境のモダン化
freeeの価値基準の一つである、ユーザーにとって「本質的（マジ）で価値ある」ものを届けるということ。本連載ではそれに向かって、日々挑戦を続ける開発現場の事例をお伝えします。本記事では、freeeでのフロントエンド環境の改善への取り組みである、Ruby on Railsアプリケーションにおけるフロントエンド環境のモダン化について紹介します。Rails5.0以前の標準的なフロントエンドのビルド基盤であるSprocketsアセットパイプラインがもたらした問題について解説するとともに、その仕組みに依存して成長してきたプロダクトがいかにしてSprocketsへの依存を断ち切ったかについて説明します。 対象読者 Ruby on Rails 5.0以前のアプリケーションのフロントエンド開発で、npmによるモジュール管理やwebpackなどによるビルドを行いたいのにそれがなかなか実現できずに困っている方
新しいRailsフロントエンド開発（1）Asset PipelineからWebpackへ（翻訳）｜TechRacho by BPS株式会社
新しいRailsフロントエンド開発（1）Asset PipelineからWebpackへ（翻訳） 新しいRailsフロントエンド開発（2）コンポーネントベースでアプリを書く（翻訳） 新しいRailsフロントエンド開発（3）Webpackの詳細、ActionCableの実装とHerokuへのデプロイ（翻訳） 概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Evil Front Part 1: Modern Front-end in Rails 原文公開日: 2017/12/05 著者: Andy Barnov、Alexey Plutalov サイト: Evil Martians 前書き 本記事は、フロントエンドのフレームワークに依存しないRailsプレゼンテーションロジックを現代的かつモジュール単位かつコンポーネントベースで扱う方法を独断に基いて解説するガイドです。3部構成のチュ
nippo の Gemfile (2017-12-02版) - r7kamura - Medium
Rails で使っている gem の知見が欲しいという話をいただいたので、いま開発している nippo という Web アプリの、2017年12月2日時点で master に commit されている Gemfile の中身を解説する。 定義順序について説明してから、個々の gem について簡単に説明する。 定義順序まず group 指定の無いもの、次に group 指定付きのものという順で定義している。細かいけど group それぞれも辞書順。複数の group を同時に指定する場合は、それらを繋げたものを順序指定時のキーとしてソートする。こういうルールなので、gem メソッドの引数の :group オプションは利用しない。 意図的に順序を気にして定義しないといけないケースが存在するので、各 group ごとにまず順序を気にしないといけないやつを記述して、後に辞書順のやつを記述するように
先人達から学ぶRailsのテーブル設計 - Qiita
はじめに Ruby on Rails Advent Calendar 2017 - Qiita の4日目の記事です。 背景 Railsのテーブル設計について、社内で議論することは多いのですが、サービスの要となる部分であるが故、社外にER図を公開するケースは少なく、自分達のサービス開発時以外にテーブル設計を学ぶ機会が少ないです。 目的 OSSで公開されているRailsアプリケーションのソースコードから、テーブル設計に関するデータをまとめることで、テーブル設計時の議論に活かすことを目的とします。 具体的には、「1テーブルが持つ情報量として、どれくらいのカラム数が妥当なんだろう…？」や「テーブル名やカラム名を命名する時にどちらの単語の方が一般的に使われているんだろう…？」といった疑問点の解消を目指します。 方法 OSSで公開されているRailsアプリケーションの見つけ方 AwesomeRails
Ruby on Railsを使った開発で参照してもよいドキュメント - Qiita
記事中のURLや内容、特にRailsやRubyのバージョンについて古くなっていることに気づいた方はぜひ編集リクエストください。 この記事はOkinawa.rbのAdventCalendar 5日目の記事です。 YassLabの業務時間中にQiita:Teamに書き溜めたものを編集して公開します。 4日目は @siman さんの「今年作った gem の紹介 (2017)」でした。 明日は @fullkawa さんのFinOpsのはなしです。 背景 人数が増えたり参加プロジェクトが増えるにつれ以下のような変化がおきました。 同じソフトウェアのさまざまなバージョンを扱うようになった コードレビューをする人・される人が増えた 同じソフトウェアでもバージョンによってAPIや使い方が異なる場合があります。 また、人によっては参考にする情報源がバラバラになってしまい、ソフトウェアの開発者が提供しているド
運用に耐えるRailsによるWebアプリケーションの作り方 - Qiita
2019/09/09加筆: 注意事項 多くの人に見ていただいていますが，この記事は2017年12月当時（Railsの最新バージョンが4.2ぐらい）に書かれたものであり，現在は内容がかなり古くなっています 2019年9月現在，筆者はRailsどころかwebアプリケーション開発からも離れているため，今の所アップデートする予定はありません（というかできません）． そのため，本記事を参考にする場合は使用しているRailsのバージョンに合わせて適宜脳内補完しながら読んでいただければ幸いです． 本記事に書かれているようなベストプラクティスを検討する上で最善の方法は，Railsの公式リファレンスとRailsのコードそのものを読んで最善策を模索することです．Rails5以上を使っている場合は，こんな古い記事を読まずに，自分で最善の方法について検討することをおすすめします． 筆者は，2014年半ばから201
RailsでAPI作成とAPIのテストのまとめ - Rails Webook
Photo by Gonzalo Baeza | Flickr - Photo Sharing! RailsでJSONを返すAPIを作成し、また、APIのテスト方法も説明します。 JSONを返すAPIは、RailsのActiveSupportより拡張されたto_jsonメソッドとDMMが開発したjbuilderというGemを使います。 APIのテストにはおなじみのRSpec3を使います。 動作確認 Rails 4.1.7 jbuilder 2.2.6 rspec-rails 3.1.0 factory_girl 4.5.0 目次 1. 前提条件 2. APIの作成 2.1. 1つのコントローラーでHTMLやJSONを返すAPI 2.2. JSONのみを返すAPI 2.3. APIのバージョニング 3. APIのテスト 3.1. テストファイルの準備 3.2. 一覧(index)APIのテス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsでの開発どんな事考えながら作業しているのか - komagataのブログ
GitHub - willnet/rspec-style-guide: 可読性の高いテストコードを書くためのお作法集
GitHub - everyleaf/el-training: 株式会社万葉の新入社員教育用カリキュラム
