Category Archives: Software

[ActiveRecord] Get a polymorphic owner class out of the owned object

The question is: how can we retrieve a owners class of a polymorphic association without loading the owner object into memory? Solution There are (at least) two ways to do this. First one is not recommended (as it might fail with multiple namespaces with same class names, etc: or a better one that will work […]

Read more at the source

Karafka (Ruby + Kafka framework) 0.5.0 release details

I’m proud to announce that we’ve released a new shiny version of Karafka: Framework used to simplify Apache Kafka based Ruby applications development. In this article I will cover all the important changes and new features that you will be able to use. Karafka? But what is it? Karafka provides a higher-level abstraction than raw […]

Read more at the source

Ruby: Hash default value – be cautious when you use it

Few weeks ago a friend asked me, why this Ruby example acts so strangely: You may ask, why a hash that clearly has some values in a ‘foo’ key is empty when we print it? Furthermore, why once we delete this key, the values are still present? Everything goes down to the ::new method and […]

Read more at the source

Apache Zookeeper + Apache Kafka start / restart script

During my work on Karafka framework I have to start/stop/restart Apache Kafka and Zookeeper quite often. Here’s a short script that will pull the most recent version of Kafka and Zookeeper, will run them and print their IPs. Note, that it will also stop Kafka and Zookeeper if they were running.

Read more at the source

Key points to consider when doing a software rewrite

The third post of Low Internal Software Quality series. As well as a big software refactor, a rewrite is not a simple thing either. After many years, we have gotten experience enough to point what you had better consider when planning and executing a rewrite process. Will the two platforms live together for some time … »

Read more at the source

Key points to consider when doing a big software refactoring

The second post of Low Internal Software Quality series. Doing a big software refactor1 is not a simple thing. There are lots of points that you should think about, from planning and prioritizing to team motivation and execution. Understanding these points in a structured and clear way is part of the job. The good news … »

Read more at the source

Dry-Configurable lazy evaluated default settings

Dry-configurable is a simple mixin to make Ruby classes configurable. It is quite nice, uses Struct and allows you to have default values. Unfortunately, it does not support (yet hopefully) default values that are evaluated upon each setting key request. When would that be useful? Let’s take a simple example: Kafka + Zookeeper. Zookeeper stores […]

Read more at the source

Errbit + HTTPS: Setting up Errbit reporter (Airbrake v5 gem) to work with self-signed HTTPS certificate

Note: If you’re using old Errbit version (0.2.0, 0.4.0) and an old Airbrake version (v4) please refer to this manual to make it work with self-signed certificates. Having an error catcher like Errbit behind SSL is generally a good idea. Especially when Errbit is hosted on a different server than you application (for example when […]

Read more at the source

Synology DMS 6 + Gitlab Docker + Gmail

When you’ll setup your Gitlab instance using Synology DMS 6.0 UI, despite the fact that you’ve provided all the Gmail credentials, you will notice that it does not send any emails. You probably end up with a message similar to this one when: EOFError: end of file reached It may sound a bit enigmatic, but […]

Read more at the source

Integrating Trailblazer and ActiveRecord transactions outside of a request lifecycle

When you use Ruby on Rails with ActiveRecord, you can get used to having separate transaction on each request. This is valid also when using Trailblazer (when inside of a request scope), however Trailblazer on its own does not provide such functionality. It means that when you’re using it from the console and/or when you […]

Read more at the source

Sending email: Controllers versus Models

November 16, 2009

While reviewing some code recently, I came across controller code that resembled the following.

if @customer.save
  CustomerMailer.deliver_welcome_message(@customer)
  flash[:message] = "Your account has been successfully created. We've sent you a welcome letter with..."
  redirect_to dashboard_path
else
  ...
end

Fairly typical Rails code. Nothing alarming here, but I wanted to evaluate the call to the mailer in this scenario. When it comes to sending emails from your application, you can choose to do it from the controller as in the example above or in your models. Our team prefers to do this from our model via a callback as we are considering this to be part of our business logic.

Each time a customer is created, we want to send them an email. This can be moved into the model and resembled something like the following..

after_create :send_welcome_message #, other callbacks..

def send_welcome_message
  CustomerMailer.deliver_welcome_message(self)
end

There are a few benefits to doing it this way.

We can test that this is being triggered within our model specs instead of our controller specs. (we prefer to spend more of our time working within models than controllers)
We remove the dependency that all requests must be processed through our controllers.
- Example: We may one day create rake tasks that data and want these emails to still be sent out. (We’ve had to do this a few times)

I definitely don’t think doing this via controllers is a bad idea, I just lean towards keeping controllers as dumbed down as possible. This allows us to have less controller code that is focused on passing data to/from models and letting our models do the heavy lifting.

UPDATE: DHH was kind enough to post a more detailed response on his blog.

[…]

Faster Rails Tests

April 16, 2014

Editor’s Note: Our post today is from Peter Bell. Peter Bell is Founder and CTO of Speak Geek, a contract member of the GitHub training team, and trains and consults regularly on everything from JavaScript and Ruby development to devOps and NoSQL data stores.

When you start a new project, automated tests are a wonderful thing. You can run your comprehensive test suite in a couple of minutes and have real confidence when refactoring, knowing that your code has really good test coverage.

However, as you add more tests over time, the test suite invariably slows. And as it slows, it actually becomes less valuable — not more. Sure, it’s great to have good test coverage, but if your tests take more than about 5 minutes to run, your developers either won’t run them often, or will waste lots of time waiting for them to complete. By the time tests hit fifteen minutes, most devs will probably just rely on a CI server to let them know if they’ve broken the build. If your test suite exceeds half an hour, you’re probably going to have to break out your tests into levels and run them sequentially based on risk – making it more complex to manage and maintain, and substantially increasing the time between creating and noticing bugs, hampering flow for your developers and increasing debugging costs.

The question then is how to speed up your test suite. There are a several ways to approach the problem. A good starting point is to give your test suite a spring clean. Reduce the number of tests by rewriting those specific to particular stories as “user journeys”. A complex, multi-page registration feature might be broken down into a bunch of smaller user stories while being developed, but once it’s done you should be able to remove lots of the story-specific acceptance tests, replacing them with a handful of high level smoke tests for the entire registration flow, adding in some faster unit tests where required to keep the comprehensiveness of the test suite.

In general it’s also worth looking at your acceptance tests and seeing how many of them could be tested at a lower level without having to spin up the entire app, including the user interface and the database.

Consider breaking out your model logic and treating your active record models as lightweight Data Access Objects. One of my original concerns when moving to Rails was the coupling of data access and model logic and it’s nice to see a trend towards separating logic from database access. A great side effect is a huge improvement in the speed of your “unit” tests as, instead of being integration tests which depend on the database, they really will just test the functionality in the methods you’re writing.

It’s also worth thinking more generally about exactly what is being spun up every time you run a particular test. Do you really need to connect to an internal API or could you just stub or mock it out? Do you really need to create a complex hairball of properly configured objects to test a method or could you make your methods more functional, passing more information in explicitly rather than depending so heavily on local state? Moving to a more functional style of coding can simplify and speed up your tests while also making it easier to reason about your code and to refactor it over time.

Finally, it’s also worth looking for quick wins that allow you to run the tests you have more quickly. Spin up a bigger instance on EC2 or buy a faster test box and make sure to parallelize your tests so they can leverage multiple cores on developers laptops and, if necessary, run across multiple machines for CI.

If you want to ensure your tests are run frequently, you’ve got to keep them easy and fast to run. Hopefully, by using some of the practices above, you’ll be able to keep your tests fast enough that there’s no reason for your dev team not to run them regularly.

[…]

The Ruby Rails Aggregator