November 3rd, 2024

Ruby on (Guard)Rails

Mike McQuaid highlights Ruby on Rails' rapid development benefits and runtime error challenges, advocating for tools like Rubocop and RSpec, and promoting incremental improvements and type systems to enhance software quality.

Read original articleLink Icon
Ruby on (Guard)Rails

Mike McQuaid discusses his extensive experience with Ruby applications, highlighting both the advantages and challenges of using Ruby on Rails. He emphasizes that while Ruby allows for rapid development, it also leads to frequent runtime errors that are often not caught until production. McQuaid prioritizes developer happiness, user satisfaction, and a balance between velocity and quality in software development. He advocates for the use of various tools and practices to mitigate issues, including linters like Rubocop, testing frameworks like RSpec, and monitoring tools such as Sentry. He also recommends adopting a type system, specifically Sorbet, to reduce runtime errors. McQuaid acknowledges the challenges of working with legacy code but asserts that incremental improvements can lead to significant benefits. He concludes by encouraging developers to set strict guidelines while allowing flexibility to adapt as needed.

- Ruby is effective for fast development but prone to runtime errors.

- Developer happiness and user satisfaction are key priorities in software development.

- Utilizing linters, testing frameworks, and monitoring tools can help catch issues early.

- Adopting a type system like Sorbet can significantly reduce production errors.

- Incremental improvements in coding practices can lead to better outcomes over time.

Link Icon 2 comments
By @falkensmaize - 3 months
As someone who writes a lot of RoR and typescript at work, I find I’m generally happier and more satisfied after completing a ticket in typescript.

It seems counterintuitive because Ruby is generally more expressive and readable than JavaScript. In theory, Ruby should be the “happy” language. I think it really just comes down to confidence that what I’ve written will work properly at runtime. There’s always a nagging paranoia with Ruby that I’ve missed adding a safe nav operator or forgotten an .is_a? somewhere, and those mistakes have led to embarrassing production issues in the past.

Typescript is far from perfect, but I experience a lot less bugs when writing code in it.