When to use x-objects?

An article, posted 6 months ago filed in ruby, rails, ruby on rails, service, architecture & when to use.

So I wrote a few short articles on when to use FormObjects and Jobs and ServiceObjects. The question is of course "it depends", but the leading principle I have is keep it simple. That being said, for inspiration, some suggestion for different layers to manage the application complexity from Vladimir Dementyev's talk on Railsconf:

Presentation

  • Controllers (standard Rails)
  • Channels (standard Rails)
  • Views (standard Rails)
  • Presenters
  • Form Objects
  • Filter Objects

Application

  • Authorization Policies
  • Jobs (standard Rails)
  • Event listeners
  • Interactors
  • Deliveries
  • Notifiers
  • Mailers (s…

Continue reading...

When to use Modules / Concerns?

An article, posted 8 months ago filed in ruby, rails, ruby on rails, service, architecture, when to use & modules.

Whenever your model gets too heavy?

The easiest way to clean up your classes might be to create smaller, more concise methods. The next easiest way of tiding up your models is moving stuff to modules (whether they are 'Concerns' or not). Modules can then be included in the final classes. It will lead to a crowded list of methods exposed on these classes, for which alternative solutions exist (Presenters, Decorators), but if you shield off private methods nicely and have a consistent way of naming things, I wouldn't be too concerned about that. Note that having many modules used in only a single class might be a code smell: perhaps you're trying to do too much with that single class.

Concerns or Modules?

When you're using Rails, you can make use of Concerns. They offer a few advantages over traditional modules, so use it whenever you're bothering recreating the same behaviour using plain old ruby Modules. I prefer consistency, so if you've adopted Concerns, use con…

Continue reading...

When to use Form-objects?

An article, posted 8 months ago filed in ruby, rails, ruby on rails, service, architecture, when to use, async, form & models.

When necessary.

It depends. By default I would advise against them; not creating Form objects to receive and validate data that could be validated by the Model directly. Even when you have a few nested attributes that belong to the main model modified, I would advise against Form objects. Keep It Simple.

But… sometimes you have more complex forms that don't fit the database-mirroring model as nicely.

Continue reading...

When to use Job (or Worker) objects?

An article, posted 8 months ago filed in ruby, rails, ruby on rails, service, architecture, when to use & async.

Always.

When you are able to do stuff async (not blocking the web-request), make it async. It will also reduce the need for a category of Service-objects. Worker or Job objects can often be called inline if desired.

Sidenote: I personally prefer the "Job" object name, a Job that needs to be performed. Worker is a name that was popularised by Sidekiq, but Sidekiq moved to Jobs as well.

Continue reading...

When to use Service-objects?

An article, posted 8 months ago filed in ruby, rails, ruby on rails, service, architecture & when to use.

Never.

There is of course never an absolute answer to stuff but if you are running it in a background job anyway have you considered directly writing it in a Worker or Job-object? Note that you can always run jobs async when needed.

My main objection against service objects is that all too often they are ill defined as a category. So while having fat controllers or fat models may be a bad thing, just creating a bunch of somewhat arbitrary 'Services' is not making the code more manageable.

When considering adding a 'services' directory to your app, try to think of what class of problems you want to tackle. And when in doubt, just keep messing around with the somewhat fatter models & controllers.

Continue reading...

The academic vs the builder

An article, posted more than 6 years ago filed in bazaar, cathedral, open source, architecture, web, w3c, standards, css, xhtml & pragmatic.

“dichotomies make it easier.”

Just over two decades ago The cathedral and the bazaar by Eric Steven Raymond was published. It talked about software development and kind of suggested that a more bazaar like ‘architecturing’ would improve the way complex systems could be build. Nowadays BDUF is a swear-word. In an ever-changing world, you can’t predict the future. So why design for one year. Experiment! Extend!

When I was visiting the Fronteers conference a few weeks ago I had a short interaction where I apologized for my maybe bit academic bias. I remembered I was still quite fond of some old xhtml standard that never really arrived.

Reading the online resilient web design-essay I was reminded of the continuous struggle between practitioners and the standards co…

Continue reading...

A developer’s status update: Test driven deadlock

An article, posted about 7 years ago filed in bdd, tdd, test, driven, development, deadlock, writer's block, block, status, failsafe & architecture.

No worries, I do value testing. But test driven? It depends.

The last few weeks I’ve been working off and on building a crawler. The thing triggers a series of scheduled tasks that could run in parallel, generating (possibly) tasks (that are consequently scheduled again in their own task-specific queue) on its own and so on. The end goal is structured copies of external resources (read: webpages). But I’ve been stuck close to the start for quite a while, setting up the base architecture using the test driven development approach. And I’m failing, it’s going too slow :(

Small victories

Like many developers, this is not my first parser/crawler. But this time I wanted to make a GoodParser™. Make it more extensible, and flexible and foremost robust, building in fault-tolerance from start. But I’m not getting near the end result and it is frustrating.

The TDD-school says make small victories, and oh yes, I had my sheer number of victories already. But the end is nowher…

Continue reading...

murb blog