Component-based Rails applications : large domains under control /

Use Components to Improve Maintainability, Reduce Complexity, and Accelerate Testing in Large Rails Applications "This book gives Ruby pros a comprehensive guide for increasing the sophistication of their designs, without having to forsake the principles of elegance that keep them in our corner...

Descripción completa

Detalles Bibliográficos
Clasificación:Libro Electrónico
Autor principal: Hagemann, Stephan (Autor)
Formato: Electrónico eBook
Idioma:Indeterminado
Publicado: Boston : Addison-Wesley Professional, [2018]
Colección:Addison-Wesley professional Ruby series.
Temas:
Ruby on rails (Electronic resource)
Application software > Development.
Web applications.
Component software.
Logiciels d'application > Développement.
Applications Web.
Composants logiciels.
Application software > Development
Component software
Web applications
Acceso en línea:Texto completo (Requiere registro previo con correo institucional)
Tabla de Contenidos:
  • Machine generated contents note: 1.1.Component-Based Rails
  • 1.1.1. What Component-Based Rails Is
  • 1.2. Benefits of Component-Based Applications
  • 1.2.1. Improved Communication of Intent
  • 1.2.2. Improved Collaboration Among Developers
  • 1.2.3. Improved Creation of Features
  • 1.2.4. Improved Maintenance of the Application
  • 1.2.5. Improved Comprehension of Application Parts
  • 1.2.6. History Repeating?
  • 1.3.Component-Based Ruby
  • 1.4. The Application Continuum
  • 1.5. Related Works
  • 2.1. The Entire App Inside a Component
  • 2.2. ActiveRecord and Handling Migrations within Components
  • 2.2.1. Installing Engine Migrations with Rake
  • 2.2.2. Loading Engine Migrations in Place
  • 2.2.3. Known Issues
  • 2.3. Handling Dependencies within Components
  • 2.3.1. Using path Blocks for Specifying CBRA Dependencies
  • 2.3.2. Adding a Regular Gem: slim-Different Templating
  • 2.3.3. Locking Down Gem Versions
  • Note continued: 2.3.4. Adding the Development Version of a Gem: Trueskill-A Rating Calculation Library
  • 2.3.5. Adding Predictions to the App
  • 3.1. Testing a Component
  • 3.1.1. ActiveRecord Model Specs
  • 3.1.2. Non-ActiveRecord Model Specs
  • 3.1.3. Controller Specs
  • 3.1.4. Helper Specs
  • 3.1.5. Feature Specs
  • 3.2. Testing the Main Application
  • 3.2.1. What to Test in the Main App
  • 3.2.2. How to Put Everything Together
  • 3.2.3. How to Set Up a Continuous Integration (CI) Server
  • 3.3. Asset Loading for Components
  • 3.3.1. Production-Ready Assets
  • 3.4. Switching Databases
  • 3.5. Deploying to Platforms-as-a-Service
  • 3.5.1. Deploying to Heroku
  • 3.5.2. Deploying to Pivotal Web Services
  • 3.6. Updating Application Dependencies
  • 3.6.1. Updating the Bundle in All Components
  • 3.6.2. Updating Every Component & apos;s Gem Version
  • 3.6.3. Updating Rails
  • 3.6.4. Long-Running Dependency Updates
  • 3.6.5. Listing a Dependency Only Once
  • Note continued: 3.7. Proposal for a Different Application Root-Showcasing the Difference of Components & apos; Structure
  • 3.7.1. Why Would I Want to Change That?
  • 3.7.2. How CBRA Can Change How I Present and Perceive My App
  • 3.7.3. Making CI and PaaS Work with the New Structure
  • 3.7.4. What Is Next?
  • 4.1. Determining What to Extract: Bottom-Up
  • 4.2. Refactoring: Extract Domain Gem-Predictor
  • 4.2.1. Fixing Inside-Out: Making AppComponent Work Again
  • 4.2.2. Last Step: Ensure That the App Works
  • 4.2.3. Summary of Bottom-Up Component Extractions
  • 4.3. Determining What to Extract: Top-Down
  • 4.3.1. Unclear Dependency Direction
  • 4.3.2. Not Everything Needs Predictor
  • 4.3.3. Implications of the First Set of Extractions
  • 4.3.4. Problem with the Current Solution
  • 4.3.5. Reducing Needed Dependencies
  • 4.4. Refactoring: Pulling Up a UI Component-TeamsAdmin, GamesAdmin, PredictionUI, WelcomeUI
  • 4.4.1. Generate
  • 4.4.2. Move
  • 4.4.3. Fix, Part 1: Reusing Test Helpers
  • Note continued: 4.4.4. Fix, Part 2: Routing Issues
  • 4.4.5. Fix, Part 3: The Container Application
  • 4.4.6. An Explicitly Contracted Global Navigation
  • 4.5. Refactoring: Pushing Down a Model Component-Teams, Games
  • 4.5.1. Getting Away with Less
  • 4.5.2. Fixing Teams Tests
  • 4.5.3. Fixing Everything Else
  • 4.6. Refactoring: Improve Naming of Component-AppComponent to WebUI
  • 4.6.1. Whatever Happened to AppComponent?
  • 4.6.2. Refactoring Component Names
  • 4.6.3. Refactoring a Component Name Throughout the Application
  • 4.6.4. An Even More Mechanical Approach
  • 4.7. More Component Refactoring Patterns
  • 4.7.1. Splitting One Component in Two: Disentangling Unrelated Concepts
  • 4.7.2. API Component
  • 4.7.3. Third-Party Service Adapter
  • 4.7.4.Common Functionality Component
  • 5.1. Small Steps
  • 5.2. One Big Step
  • 5.2.1. Prerequisites
  • 5.2.2. Script This!
  • 5.2.3.A Scripted Refactoring
  • 5.2.4. Cleaning Up Persistence
  • 5.2.5. Using Persistence
  • 5.2.6. Summary
  • Note continued: 6.1. Hexagonal Architecture
  • 6.1.1. Hexagonal Architecture and CBRA
  • 6.1.2. Implementing Hexagonal Rails with CBRA
  • 6.1.3. Teasing Out an Adapter in the Frontend
  • 6.1.4.A Repository for Data Storage
  • 6.1.5. Swappable Data Storage
  • 6.1.6. Summary
  • 6.2. Data-Context-Integration (DCI)
  • 6.2.1. DCI and CBRA
  • 6.2.2. Implementing DCI with CBRA
  • 6.2.3. Summary
  • 7.1. Kotlin, Java, and Gradle
  • 7.2.NET/C
  • 7.3. Conclusion
  • A.1. Plain versus
  • full versus
  • mountable Engines
  • A.1.1. Gem
  • A.1.2. Plain Plugin
  • A.1.3. Full Engine
  • A.1.4. Mountable Engine
  • A.2. How Do Engine Routes and Engine Mounting Work?
  • A.2.1. Engines as Subdomains
  • A.2.2. Engines Are (Unfortunately) Singletons
  • A.3. Additional Testing with Older Versions of Rails
  • A.3.1. View Specs
  • A.3.2. Routing Specs.

Ejemplares similares