I was listening to recent podcast by Taylor Otwell, Laravel Snippet episode 11, where he touched on the debate in Laravel community on where you should put your code logic - in Controllers, Models, or Services. Here's what he said. First, I'll just quote Taylor, and then provide some comments and additional links below. So, "skinny" or "fat" models? What approach does creator of Laravel prefer? I
はじめに Next.jsにServer Actionが新しく導入されました。サーバ上の関数をブラウザから直接呼び出すようなコードの書き味を提供するもので、非常に魅力のあるコンセプトだと私は思っています。ただしサーバ上で実行されるコードとブラウザで実行されるコードの境界が曖昧で、"use server"のセキュリティ上の懸念もよく議論されています。 一方で、私の先日の記事Next.jsで簡単なCRUDアプリを作りながら気になったセキュリティ: Railsの視点からで、私はこの"use server"問題には言及しませんでした。まだ非常に新しい話題でかつNext.js側の対応も進行中だというのもありますが、実は個人的にあまり気にならないのが最大の理由です。 気にならなくなったきっかけは、Server ActionをRuby on Railsのコントローラと同じように考え始めたことです。こうする
この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2018 の投稿記事です。 12月はRubyのリリースが楽しみなk-shogoです。 今までに規模も寿命も様々なRailsアプリケーションの開発に携わってきました。本記事ではそんな自分が「Railsプロジェクトにかかわるならこんな方針を合意できるチームが良いな」と思っていることをまとめます。 どんなことに気をつけているのか Railsでアプリケーションを作成する時、もしscaffoldで事足りるようなものならば取り決めは必要にはなりません。 複雑なアプリケーションだったとしても、一人で開発しコードが全て頭に入っており、今後もずっとメンテナンスできる覚悟があり、過去の自分を常に信頼できるのであればこれもまた方針は不必要です。 コードの規模が大きくなりそう、サービスの寿命が長くなりそう、複数人で開
A Rock Solid, Modern Web Stack—Rails 5 API + ActiveAdmin + Create React App on Heroku How to blend a rock-solid CMS and API with the absolute best in front-end tooling, built as a single project and hosted seamlessly on Heroku. Rails is an incredible framework, but modern web development has moved to the front-end, meaning sometimes you don’t need all the bulk of the asset pipeline and the templat
Presented at RailsConf 2018 in Pittsburgh, PA. Upgrading Rails can go from easy-to-hard quickly. If you've struggled to upgrade to a new version of Rails, you're not alone. And yet, with useful deprecation warnings and extensive beta periods, Rails has never made it easier to upgrade. So what makes it hard? By looking at the past ten years of Rails upgrades at Clio (and other notable apps), let's
この記事は Ruby on Rails Advent Calendar 2015 15日目の記事です。 これまで携わってきたソーシャルゲームのサーバーサイド開発では、1タイトルに対して主に3つの機能を作成することが多かった。 API スマートフォンのネイティブアプリケーションから呼ばれるJSON(あるいはJSONフォーマット互換)API 管理用画面 ユーザー情報管理、その他各種制御処理を行う(BANとか補填とかマスタデータキャッシュ管理とか)。エンジニアとカスタマーサポートチームが使用する デバッグ用画面 開発用のWebUI、単純なAPIを呼ぶフォームではなく「カードのレベルをMAXにするボタン」みたいなものが機能ごとに沢山ある 開発を行う場合、大体はAPI用の機能がメインになる。ただ、デバック用画面に関しては完全に社内開発用なので適当で構わないけど、管理用画面に関してはそれなりの作りこみ
このエントリは Ruby on Rails Advent Calendar 2014 の 7 日目のエントリです。 前日は seri_k さんの「Turbolinksさんと上手く付き合う10の方法」でした。 お詫び WIP です。公開期限に間に合わない可能性があるため、まだ途中ですが先に公開してしまいました。 サンプルコード等を後ほど追記する予定です。 → 12/08 18:10 追記しました。 Rails のファットモデル問題 Rails で構築したアプリケーションが大規模になり機能が増えていくにつれてモデルが大きくなり、そのうち手がつけられなくなる問題は古くから指摘されています。これについてはもはや詳細を述べるまでもないと思うので割愛しますが、この問題は 2014 年になった今でも多くの開発チームを悩ませていると感じています*1。 このエントリでは、普段 Rails を業務で使いながら
はじめに 自分が rails をさわり始めたときはバージョン1からバージョン2に変わるあたりだったのですが、バージョン2が出た年を振り返るとなんと2007年でした。 月日の流れが速い事に驚く中、早く知ってたら良かったのになぁって事をつらつらとまとめてみました。 最近 rails さわり始めてみたよ！って方の参考になれば良いなと思います。 今回は便利な gem とかではなく、素のrailsで出来ることを挙げています。 ちなみにバージョンは以下の環境です。 About your application's environment Ruby version 2.1.3-p242 (x86_64-darwin14.0) RubyGems version 2.2.2 Rack version 1.5 Rails version 4.1.8
Railsアプリケーション開発を完全にDocker化する Tweet Degica のすべてのサービスは Rails で開発しており、そのうちの一部は Docker を使用した本番環境にデプロイしています。しかし開発者個人の開発環境にはいまだに Docker を導入できていません。最も大きな障害は spring を docker コンテナ内で上手く扱う方法が確立されていなかったことですが、この問題は docker-compose を工夫して利用することで解決可能であることがわかりました。 ということで、今回は rails アプリケーションの開発環境を完全に docker 化する方法を紹介します。 完全に、というところがポイントです。この方法を使えば docker 以外のツールを一切ホストマシンにインストールせずに rails アプリの開発を行うことができます。 (ちなみに、弊社の本番環境は
技術部の小野(@taiki45)です。この記事では簡単なアプリケーション(ブログシステム)の実装を通して、クックパッドで作成・使用しているライブラリのGarage の紹介と Garage を使った RESTful Web API の開発をご紹介したいと思います。 Garage は RESTful Web API を開発するための、 Rails gemified plugins です。Rails プログラマは Garage を使って Rails を拡張することで素早く Web API を開発することができます。Garage は新しくアプリケーションを開発する場合にも、既存の Rails アプリケーションに組み込んで Web API を実装する場合でも使用できます。Garage はリソースのシリアライズやアクセスコントロールなど Web API の実装に必要な機能をカバーしています。 Ruby
When you run rails generate rspec:install, the spec/rails_helper.rb file includes the following configuration: RSpec.configure do |config| config.use_transactional_fixtures = true end The name of this setting is a bit misleading. What it really means in Rails is "run every test method within a transaction." In the context of rspec-rails, it means "run every example within a transaction." The idea
昨日のRails Developers Meetupで綺麗なテストコードの書き方について発表してきました。 Rails Developers Meetup #1（東京会場） - connpass 資料はこちら 余談 もともと数年前くらいから、テストコードの書き方についてまとめたいなーと思っていたのですがなかなかキッカケがなくて手を付けられていませんでした。今回のミートアップ駆動で一通り形にするところまでいけて今とてもスッキリした気持ちです 😇 もっと多くの人にテストコードの書き方を意識してもらいたいので、また機会があればどこかで喋りたいですね。 昨日発表した内容はGitHubリポジトリにまとめたものの一部です。綺麗なテストコードの書き方について詳しく知りたい方は下記のリンクからどうぞ。 willnet/rspec-style-guide お願い 今回まとめた内容はあくまで僕が考えるテスト
Rails::Engine allows you to wrap a specific Rails application or subset of functionality and share it with other applications or within a larger packaged application. Every Rails::Application is just an engine, which allows for simple feature and application sharing. Any Rails::Engine is also a Rails::Railtie, so the same methods (like rake_tasks and generators) and configuration options that are
Rails::Railtie is the core of the Rails framework and provides several hooks to extend Rails and/or modify the initialization process. Every major component of Rails (Action Mailer, Action Controller, Active Record, etc.) implements a railtie. Each of them is responsible for their own initialization. This makes Rails itself absent of any component hooks, allowing other components to be used in pla
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
