About This Title

Pages: 475
Published: June 2022
ISBN: pending
In Print

Sustainable Web Development with Ruby on Rails

Practical Tips for Building Web Applications that Last

by David Bryant Copeland

Learn how to get the most out of Ruby on Rails 7.1 without making a mess. Create Rails apps that can be sustained for years without accruing carrying costs that make development slow and expensive. Recently updated for Ruby on Rails version 7.1, this book is over 450 pages of practical tips, with clear code examples. Each tip is presented with the tradeoffs and nuance you’d face on an actual project. Everything in the book has been applied to real-world systems that have been in production for years. If you want that for your apps, this book has what you are looking for.


This work was written and produced entirely by the author. We are proud to be distributing it.

eBook Formats:

  • PDF for desktop/tablets

  • epub for Apple Books, e-readers

Get all eBook formats here for $49.95 (USD)

Add to Cart we accept visa, mastercard, amex, discover, paypal


This book contains 27 chapters that cover how to sustainably grow and manage your Rails application. Almost every aspect of Rails is discussed in depth. It starts with creating a new Rails app and authoring useful development scripts for setting up and running the app that can grow with you and your team. The book then goes through many aspects of Rails, discussing how to sustainably write code and design your app. The book works outside-in starting from routes, HTML, Helpers, and CSS before continuing onto the database, Active Records and controllers.

The book also outlines a strategy for managing business logic, which is create a service layer outside your Active Records. This is all followed by a detailed end-to-end example, building a complicated feature that stresses the bounds of any Rails app. After that, the book goes through several technical topics related to managing a Rails app that aren’t about the code, such as authentication, observability, APIs, and technical leadership. This book can be your reference to growing and sustaining Rails apps for years to come!

What You Need

You’ll need a working development environment to run Ruby on Rails. The book uses Ruby 3.2 and Rails 7.1, however you should be able to follow along and use any supported version of Ruby or Rails. You will also need to run Postgres, version 9 or later. The book contains an appendix on how to set all of this up using Docker, which is what was used to generate the code in the book. In this case, you just need Docker running on your computer.

Resources

Releases:

  • P2.0 2024/01/09
  • P1.0 2022/06/17

Contents & Extracts

  • Sample
  • Introduction
    • Why This Book Exists
      • What is Sustainability?
      • Why Care About Sustainability?
      • How to Value Sustainability
      • Assumptions
      • Opportunity and Carrying Costs
      • Why should you trust me?
    • The Rails Application Architecture
      • Boundaries
      • Views
      • Models
      • Everything Else
      • The Pros and Cons of the Rails Application Architecture
    • Following Along in This Book
      • Typographic Conventions
      • Software Versions
      • Sample Code
    • Start Your App Off Right
      • Creating a Rails App
      • Using The Environment for Runtime Configuration
      • Configuring Local Development Environment with dotenv
      • Automating Application Setup with bin/setup
      • Running the Application Locally with bin/dev
      • Putting Tests and Other Quality Checks in bin/ci
      • Improving Production Logging with lograge
    • Business Logic (Does Not Go in Active Records)
      • Business Logic Makes Your App Special…and Complex
      • Bugs in Commonly-Used Classes Have Wide Effects
      • Business Logic in Active Records Puts Churn and Complexity in Critical Classes
      • Active Records Were Never Intended to Hold All the Business Logic
      • Example Design of a Feature
  • Deep Dive into Rails
    • Routes and URLs
      • Always Use Canonical Routes that Conform to Rails’ Defaults
      • Never Configure Routes That Aren’t Being Used
      • Vanity URLs Should Redirect to a Canonical Route
      • Don’t Create Custom Actions, Create More Resources
      • Use Nested Routes Strategically
      • Nested Routes Can Organize Content Pages
    • HTML Templates
      • Use Semantic HTML
      • Ideally, Expose One Instance Variable Per Action
      • Wrangling Partials for Simple View Re-Use
      • Use the View Component Library for Complex UI Logic
      • Just Use ERB
    • Helpers
      • Don’t Conflate Helpers with Your Domain
      • Helpers are Best at Exposing Global UI State and Generating Markup
      • Configure Rails based on Your Strategy for Helpers
      • Use Rails’ APIs to Generate Markup
      • Helpers Should Be Tested and Thus Testable
      • Tackle Complex View Logic with Better Resource Design or View Components
    • CSS
      • Adopt a Design System
      • Adopt a CSS Strategy
      • Create a Living Style Guide to Document Your Design System and CSS Strategy
    • Minimize JavaScript
      • How and Why JavaScript is a Serious Liability
      • Embrace Server-Rendered Rails Views
      • Tweak Turbo to Provide a Slightly Better Experience
    • Carefully Manage the JavaScript You Need
      • Embrace Plain JavaScript for Basic Interactions
      • Carefully Choose One Framework When You Need It
      • Ensure System Tests Fail When JavaScript is Broken
    • Testing the View
      • Understand the Value and Cost of Tests
      • Use :rack_test for non-JavaScript User Flows
      • Test Against Default Markup and Content Initially
      • Cultivate Explicit Diagnostic Tools to Debug Test Failures
      • Fake The Back-end To Get System Tests Passing
      • Use data-testid Attributes to Combat Brittle Tests
      • Test JavaScript Interactions with a Real Browser
    • Models, Part 1
      • Active Record is for Database Access
      • Active Model is for Resource Modeling
    • The Database
      • Logical and Physical Data Models
      • Create a Logical Model to Build Consensus
      • Planning the Physical Model to Enforce Correctness
      • Creating Correct Migrations
      • Writing Tests for Database Constraints
    • Business Logic Code is a Seam
      • Business Logic Code Must Reveal Behavior
      • Services are Stateless, Explicitly-Named Classes with Explicitly-Named Methods
      • Implementation Patterns You Might Want to Avoid
    • Models, Part 2
      • Validations Don’t Provide Data Integrity
      • Validations Are Awesome For User Experience
      • How to (Barely) Use Callbacks
      • Scopes are Often Business Logic and Belong Elsewhere
      • Model Testing Strategy
    • End-to-End Example
      • Example Requirements
      • Building the UI First
      • Writing a System Test
      • Sketch Business Logic and Define the Seam
      • Fully Implement and Test Business Logic
      • Finished Implementation
    • Controllers
      • Controller Code is Configuration
      • Don’t Over-use Callbacks
      • Controllers Should Convert Parameters to Richer Types
      • Don’t Over Test
    • Jobs
      • Use Jobs To Defer Execution or Increase Fault-Tolerance
      • Understand How Your Job Backend Works
      • Sidekiq is The Best Job Backend for Most Teams
      • Queue Jobs Directly, and Have Them Defer to Your Business Logic Code
      • Job Testing Strategies
      • Jobs Will Get Retried and Must Be Idempotent
    • Other Boundary Classes
      • Mailers
      • Rake Tasks
      • Mailboxes, Cables, and Active Storage
  • Beyond Rails
    • Authentication and Authorization
      • When in Doubt Use Devise or OmniAuth
      • Authorization and Role-based Access Controls
      • Test Access Controls In System Tests
    • API Endpoints
      • Be Clear About What—and Who—Your API is For
      • Write APIs the Same Way You Write Other Code
      • Use the Simplest Authentication System You Can
      • Use the Simplest Content Type You Can
      • Just Put The Version in the URL
      • Use .to_json to Create JSON
      • Test API Endpoints
    • Sustainable Process and Workflows
      • Use Continuous Integration To Deploy
      • Frequent Dependency Updates
      • Leverage Generators and Sample Repositories over Documentation
      • RubyGems and Railties Can Distribute Configuration
    • Operations
      • Why Observability Matters
      • Monitor Business Outcomes
      • Logging is Powerful
      • Manage Unhandled Exceptions
      • Measure Performance
      • Managing Secrets, Keys, and Passwords
  • Appendices
    • Setting Up Docker for Local Development
      • Installing Docker
      • What is Docker?
      • Overview of the Environment
      • Creating the Image
      • Starting Up the Environment
      • Executing Commands and Doing Development
      • Customizing the Dev Environment
    • Monoliths, Microservices, and Shared Databases
      • Monoliths Get a Bad Rap
      • Microservices Are Not a Panacea
      • Sharing a Database Is Viable
    • Technical Leadership is Critical
      • Leadership Is About Shared Values
      • Leaders Can be Held Accountable
      • Accountability Can be Implicit
    • Colophon

Author

David Bryant Copeland has been a professional programmer since 1995. He’s the author of Build Awesome Command-Line Applications in Ruby 2 and Rails, Angular, Postgres, and Bootstrap. He was previous CTO of healthcare startup Mood Health as well as Chief Software Architect at Stitch Fix, where he created many Rails apps and watched them evolve over six years and 100+ developers.

eBook Formats:

  • PDF for desktop/tablets

  • epub for Apple Books, e-readers

Get all eBook formats here for $49.95 (USD)

Add to Cart we accept visa, mastercard, amex, discover, paypal

Related Titles:

About This Title

Pages: 475
Published: June 2022
ISBN: pending
Edition: 1
In Print