Our #devs channel is a cross-project, shared space where the entire dev team of SINAPTIA can ask questions, share opinions, and discuss interesting articles or tech they come across. The idea is to post a curated extract of what happens there every week.
Your ActiveJobs are your service layer
The team had an interesting discussion about the role of Service Objects and Jobs in Rails applications. Fernando kicked off the discussion with this comment:
Do we really need these single-line Job objects whose only purpose is to instantiate and call a service object? Ultimately,
SomethingJob.new(params).performandSomethingService.new(params).callare functionally equivalent. Also, if we put the service logic inside a Job object, we get “async for free”.
Patricio suggests a pragmatic approach:
- Use service objects when business logic is complex and needs future refactoring
- Use jobs for external service calls or time-consuming operations
He also mentions that with ActiveJob, running jobs in sync mode is trivial, so they are equivalent.
Lucas suggested that separating services from jobs allows changing job mechanisms without affecting the service layer. But he also notes that with ActiveJob that is trivial, which weakens the argument.
System tests are dead
Fernando shared this article about system tests with Playwright commenting that he intended to give it a go in one of our projects: Running Rails System Tests with Playwright instead of Selenium.
Which sparked this discussion and ultimately ended up talking about DHH’s post “System Tests Have Failed”, the team shared their experiences:
Patricio agrees that integration and system tests are fragile and painful to maintain. He shared his experience with a project he worked on a few years back with a massive end-to-end test suite that took 50 minutes to run. It always had flaky tests, so it usually took a few runs to get a green light.
Fernando agreed and they both immediately thought of:
Not every team can wait 2 hours to merge a simple Pull Request… Can you guess what the outcome was?
Yup, automated tests were replaced by a QA person. The development process became faster, fewer bugs were shipped to production because there were things a person could discover that an automated test couldn’t, and the dev team could focus on building valuable stuff instead of fixing flaky tests. A huge deadline was met timely and a client was happy.
A few days after, Jorge Manrubia tweeted:
When it comes to system tests in Rails, I fully agree with David’s vision: their benefit/cost is tiny just because their cost is huge.
We couldn’t agree more.
Link Dump
AI and Development
- Manicode.ai - A tool for editing codebases from the terminal. It’s said to have a better generation for multi-file changes than Cursor’s composer.
- How I use AI to write code Ben Heirdon shares some tips on how to use AI-driven code editors.
The following two have an interesting take on the architectural place of AI in a codebase:
Ruby Performance
- Ruby 3.4 String Key Optimization - String key lookups in hashes now as fast as Symbols
- Jean Boussier is working on optimizing Ruby stdlib’s JSON parser and he’s making good progress
Development Tools
Fernando shared this VSCode Key Binding tip for inserting the relative path of the current file in the vscode terminal:
{
"key": "ctrl+shift+t",
"command": "workbench.action.terminal.sendSequence",
"args": { "text": "${relativeFile}" },
"when": "terminalFocus"
}
That’s it for this issue. See you around next week!