ruby

Revised by Piotr Solnica and Andy Holland

Lately, I have been playing around and contributing to the great ecosystem of dry-rb, first of all, I have to say the community is absolutely fantastic, super supportive and eager to welcome many new contributors.

I took me some time, to figure out how to correctly setup every project I worked on, not that I work in tons of projects, but now that I have a better understanding of how to setup, it makes more sense to me, at least.

In the last couple of weeks I have been working, with a little project of my own. I always love Command Line Tools, I don’t know what they have but using them make feel more like a Hackers or someone that actually know what he is doing.

So I decided to build one, with the help of a gem called Thor, which by the way is a great gem, that help you build your CLI really easy.

This is the second part of my previous post Improving our rake tasks.

In this one we will discuss a way for testing our rake task, the example will be very straight forward. We will invoke the rake task and expect that some class receive the correct arguments.

Lately I have been writting some rake tasks, for downloading backups, for accesing API’s, or for automating teadious and repetitive work. Rake task are great, but dangerous at the same time.

We tend to add so much code to our rake task, that they become a source of errors. Following the principles of OOP we can clean our rake tasks, improving our code and making them much easier to test.

Last night I was reading some blogs about ruby patterns, for me is sometimes difficult to understand the use of this kind of patterns, mostly because in my work we just throw thousand of lines of code, and deal with a lot of legacy code from other person who contribute to our projects. I currently work for comparason website in Spain Kelisto Lately there is one projects that is architecture is strongly inheritance, so there are many classes that inherited from a parent class.