🟢 Ruby article is a stub (expand it)

[beechnut]

Additional content could include:

• Linking to our Rails template
• Typed Ruby (via RBS/Sorbet)
• Linking to other useful Ruby resources

[beechnut]

The page should eventually answer, "Why is this language / language-specific practice right for a government context?" May touch on things like maintenance, compliance, hiring, web frameworks / time to market.

[bpdesigns]

Iceboxing til questions above can be answered

[beechnut]

Some brainstorming:

Subject	Thing	Level	Reason
style	Standard Ruby	standard	If you just use standardrb, there's no need to spend time debating style standards. Install and move on to getting the work done.
build: rapid prototype	18F Rails template	standard	For rapid prototyping, use the 18F Rails template. If your project is a derisking prototype or CRUD/CRED app, Rails will get you going fast, and the 18F template sets up a lot of what you need for gov security compliance.
build: production build	Hanami + ROM	experiment*	For builds that more for architecting rigorously validated event-sourced systems, use the CQRS pattern. Hanami as web framework, ROM for persistence. Hanami provides better architected schemas and data validations, and ROM provides less invisible magic — data schemas can be defined in the code, and they let you work better with CQRS / event-sourced patterns that ActiveRecord would quickly struggle under.
programming style	Object-oriented AND functional	standard	Ruby lets you combine the best of object-oriented programming (OOP) and functional programming (FP). Follow functional programming within methods, using dependency injection (DI) to make them more easily testable. Use object-oriented patterns and principles (like SOLID) for organizing code.
code design	Sandi Metz's rules	recommendation	You could fill books with recommendations for code design, but Sandi Metz's rules are a good starting point, as they help identify code smells and push you to design better code.
testing: rapid prototype	Use unit tests at minimum, ideally unit and integration tests	standard	"Move fast and break things" doesn't work in government. How about "Move fast and don't break things"? Using unit tests and integration tests can help avoid regressions and maintain forward velocity.
testing: production build	Use BDD and TDD	standard	BDD provides a common language shared by product folks and devs, and helps turn business requirements into features. Start with setting up Cucumber / Gherkin, then write the integration and unit tests before writing implementation code.
scale	Design your application to scale for anticipated usage	standard	If your service will be serving the general public, design with scale in mind. If you're serving a few hundred or a few thousand agency employees, scalability becomes much less important to design for up front.

• This experiment shouldn't go in the guide right now, but I have a hunch that designing an app this way would be really effective.

Recommended reading (free):

• Sandi Metz's rules for developers (Thoughtbot) - Simple rules that inspire you to recognize bad patterns and replace them with better ones.
• Code review without your glasses (Robert Heaton) - A guide to finding meaning in the "shape" of Ruby code.

Recommended viewing (free):

• Functional Core, Imperative Shell (Gary Bernhardt) - A pattern that enables Rubyists to write functional, testable code while also safely interacting with non-deterministic external components like APIs and system calls.

[beechnut]

For a process, I'm imagining drafting a standard and having an open comment period with the engineering chapter, sort of like we did with the static site generator decision.