Rails-APIでTODOアプリを作る。 - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Railsのcontrollerにおいて、メソッド外で初期化したインスタンス変数を参照すべきでない理由 - Qiita
背景 Ruby on Rails を利用した中規模以上のプロジェクトにおいて、 Fat な controller を解消するために、処理を分割することはしばしば行われます。例えば、サブメソッドへの一部処理の切り出し, before_action, concern への処理の委譲が行われます。しかし、処理を分割する際に、メソッド外で初期化したインスタンス変数を参照してしまうような例を時々見かけます。 このような実装は、一見DRYでシンプルに見えてしまうかもしれませんが、実際には開発効率の低下につながったり、バグの原因になる可能性が高くなります。 この記事では、メソッド外で初期化されたインスタンス変数を参照することの危険性と、それを避けた方が良い理由を考察してみたいと思います。 避けた方が良い例 class BooksController def index set_author set_bo
クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog
前置き この記事、本来は Flux には Model がないのではないかと思った覚書 - ナカザンドットネット と Flux の Store が ViewModel かって話からの MVW とかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く のアンサーとして書き始めた記事だが、前置きだけで別テーマとなったので、前後編に分割する。 僕は元々がゲームクライアント屋だったときの発想を引きずってるのと、既存の Web の開発の文脈に対して距離を置いていることを明言しておく。あとこういうテーマでとある原稿書いていたので、頭の整理も兼ねて。 ActiveRecord の功罪を振り返る このテーマを語るにあたって、まず Rails の MVC について述べなければならない。なぜなら、フロントエンドのアーキテクチャとは、サーバーサイドの MVC の模倣に始まり、破綻し、結果として
Validating REST queries with Rails (Example)
I've recently been working on a few RESTful API's using Rails. One of the problems that I keep seeing with end users is that they usually don't read the documentation very well and make simple mistakes when making specific requests and queries. This is easily solved with error handling and validation of the API. There are a few gems out there that will handle this sort of situation for you, but th
Railsで時刻 time型を扱う | 株式会社テクノブレーン
Railsでtime型を扱うのに少々苦戦したので グループウェアのタイムカード機能（時刻のみ記録）を実装する際、時刻の情報をデータベースに保存する際のデータ型をどうすれば良いのか悩みました。少しですが。 PostgreSQLでは日付時刻関連のデータ型はこちらのドキュメント にも記載されていますが、以下の通りです。 timestamp [without time zone] 日付・時刻（時間帯なし） timestamp with time zone 日付・時刻、時間帯付き date 日付（時刻なし） time [without time zone] 時刻（日付なし） time with time zone その日の時刻のみ、時間帯付き interval 時間間隔 time with time zone などは詳細を理解できない部分もありますが、個人的な経験上データベースに保存する時刻はUTC
Rails で RESTful Web API をシンプルに保つ設計 - アジャイルSEの憂鬱
Rails で RESTful な Web API を作る場合、色々な方法があると思います。 今回、私が API を作るときによくやっている設計をブログに書いてみます。 コード 説明するより、コードを見てもらった方が早いと思うので、コードを書く。 # config/routes.rb namespace :api, defaults: { format: :json } do namespace :v1 do resource :user, only: :show end end # app/controllers/api/v1/users_controller.rb module Api module V1 class UsersController < ApplicationController before_action :doorkeeper_authorize! def show
本当にあったRailsの怖い話
meguro.rb#9で発表した資料です 「心霊現象」という文字が映らない心霊現象が発生しております。
Railsのファットモデル問題に対処する前に読んでほしい記事 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 Skinny Controller, Fat Model Railsではスキニーコントローラー、ファットモデル（Skinny Controller, Fat Model）という方針のもと、 コントローラーのコード量を少なくして、モデルを分厚くするという書き方が推奨されていました。 10 Ruby on Rails Best Practices — SitePoint Rails Best Practices 1: Fat Model – Skinny Controller このような背景から、ファットモデルという設計が目指すべき設
RailsでAPI開発する前に知っておくべき４つのこと - Qiita
$ bin/rails g scaffold user name:string mail:string password:string invoke active_record create db/migrate/20151214145437_create_users.rb create app/models/user.rb invoke test_unit create test/models/user_test.rb create test/fixtures/users.yml invoke api_resource_route route resources :users, except: [:new, :edit] invoke scaffold_controller create app/controllers/users_controller.rb invoke test_un
Rails5 API + devise でユーザーの認証と作成機能を実装した API を作成する - 文系プログラマー
2017/04/26 curl部分に間違いがあったので修正、ついでにログインの必要な動作を追記 目標 Rails v5.0.0 から追加されたapiオプションを使い、ユーザーの作成と認証機能を実装したベーシックな Rails API を作る rails new まずはプロジェクトを作成します $ rails new devise-api --api --skip-bundle Gemfile に次の gem を追加し, bundle install gem 'devise' gem 'active_model_serializers' devise devise を立ち上げます $ rails generate devise:install create config/initializers/devise.rb create config/locales/devise.en.yml Us
Rails での JSON API 実装まとめ - onk.ninja
Rails での JSON API 実装まとめ 前後リンク RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST Ruby on JSON の図のような流れになるんですが、それぞれ見ていきます。 to_json (2011-2013 頃) 2011-2013 年頃、僕らは render :json を使っていました。 render json: @user render json: @user.to_json として User#as_json や User#to_json を利用します。 この頃はまだ SPA という言葉もなく、ネイティブアプリもそこまで流行っていなかったので これで十分だったのですが、どんどん API に世の中が寄っていき、限界を迎えます。 この頃のツラみ JSON を組み立てるのが大変
Railsで重要なパターンpart 2: Query Object（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Essential RubyOnRails patterns — part 2: Query Objects 公開日: 2017/09/18 著者: Błażej Kosmowski サイト: selleo.com 2017/10/25: 初版公開 2022/03/24: 更新 前回: Railsで重要なパターンpart1: Service Object Query Object（または単にQuery）パターンもまた、Ruby on Rails開発者が肥大化したActiveRecordモデルを分割し、コントローラをスリムで読みやすくするのに非常に有用なパターンです。本記事はRuby on Railsを念頭に置いていますが、このパターンは他のフレームワーク（特にMVCベースでActiveRecordパターンを適用できるもの）にも簡単
startupでもrails使うなら これだけはやっとけ的 tips集 - Speaker Deck
All slide content and descriptions are owned by their creators.
Awesome Ruby : 素晴しい Ruby のライブラリ・ツール・フレームワーク・ソフトウェアの数々
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 元記事: Awesome Ruby Ruby 以外の言語, ソフトウェアについては を参照してください. Awesome List in Qiita Awesome Java Awesome JavaScript Awesome Node.js Awesome Python Awesome Go Awesome Selenium Awesome Appium 抽象化 ActiveInteraction - アプリケーション固有のビジネスロジックを管理します. Cells - Rails のコンポーネントを表示します. Decent Ex
form objectを使ってみよう - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。 Ruby化のプロジェクトが始まって1年が過ぎました。新しいメンバーも入り、Railsのコード量は日に日に多くなっています。可読性を保ちつつアプリケーションを大きくしていくために、使える知見をチームメンバーに効率よく伝えていくのが大事だと感じる今日このごろです。 普段メドピア内ではコードレビューや社内勉強会などで知識のシェアを行っています。そんなとき、ブログ記事や書籍などのまとまった文章があると「これ読んでおいて」と言うだけで良くなるので楽です。先日form objectを使ったほうがいいですよーという内容でレビューコメントをつけようとしたところ、日本語で詳しくまとまった文章が見当たりませんでした＞＜なければ自分で書くしかありません。そこで今回はRailsにおいて可読性を保つための知見である、form o
FormオブジェクトのURLの渡し方について - Qiita
Rails Advent Calendarの2日目の記事である Rails4でFormオブジェクトを作る際に気をつける3つのポイント｜江の島エンジニアBlog を読んだんですが、ちょっと気になる所があったんで突っ込みを入れてみる。 モデル層であるFormオブジェクトにURLを返すためのメソッド定義するのは、あんまりよろしく無いんじゃないかと思う。 そもそもurl_helperをちゃんと動かすためにはホスト名やポート等のリクエスト情報が必要で、この例の様に相対パスを出力するだけなら使えなくもないけどモデル層から呼ばれることは、余り想定されていない。 デコレーター層に生やすか、そもそも組込みのヘルパーを使うべきではないかと思う。 ちなみにform_forヘルパーが中で使っているのはpolymorphic_pathというヘルパーで、地味だし自分も良く忘れるのだが、この例ではこれがそのまま使えるは
Rails のサービスクラスでのマイルールとちょっとしたコツ - Qiita
動機 Railsにおけるサービスクラスのオリジナルルール という記事をたまたま見つけ、「自分ならこう書くかな」と感じたことがいくつかあったので、記事にしてみました。 なお の参考記事の中でさらに参考にされている 肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳) という記事のコードを、この記事でも説明のために用いようと思います。そこで、以下は 2 つの記事をこのように呼称します。 参考記事 1: Railsにおけるサービスクラスのオリジナルルール 参考記事 2: 肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳) さらに翻訳元の記事: 7 Patterns to Refactor Fat ActiveRecord Models ルール 1. クラス名は「動詞 (+ 目的語)」にする 参考記事 1 のものとほぼ同じルールです。末尾に
【Rails】WEB APIを長く運用するための仕組み化 - ZOZO TECH BLOG
こんにちは、バックエンドエンジニアのじょーです。大規模なサービスのAPIを開発する際に、ルールを決めずに開発していると無秩序なコードが散見される運用がしづらいAPIになってしまいます。また、ルールを決めたとしても共有が上手くいかないなどの理由で守られなくなってしまうこともあると思います。 本記事では、APIを運用しやすくするために、ただルールを決定しただけではなく、ルールを守るためにそれぞれ仕組み化をしたことを紹介します。 APIのレスポンスを統一する デコレーターを使ってレスポンスの定義を綺麗に書く パラメーターを統一する Validatorによりパラメーターの明記を強制する コーディング規約を守る LinterとSideCIを導入して修正とレビューの自動化 Linterのルールを適度に調節する 1. APIのレスポンスを統一する ここで言うAPIのレスポンスを統一するというのは、返すA
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RailsでAPIつくる – 参考サイト一覧 – Logicky BLOG
Rails5とAPIモードについての解説
