In this blog post I am not going to talk about N.W.A’s song called “Express Yourself”. Nor Madonna’s. Nope. I’ll talk about Ruby and how wonderfully expressive it is. But, we all know that, don’t we? We have heard that tens or hundreds of times. But, I am not really sure we all know what that means. Back to the future About two years ago, when I was pair-programming with a more exprienced colleague of mine, I wrote the following code:
Have you ever heard of hoisting? Well, regardless if you have or you have not, Ruby has an interesting hositing mechanism built-in. Let’s take a dive and see how it creates variables and do some experiments with it. Hoisting What is hoisting? Well, according to Google “hoist” means to raise something. Apparently, with with ropes and pulleys. At least, back in the day. Well, when it comes to variable hoisting, it’s basically a mechanism by which the language, in our context - Ruby, declares and defines variables.
We all know that there are different design patterns. They are all quite trivial to learn, but, the trick lies in applying them. When should we use this or that pattern and will that help in making our code better and cleaner. Well, tests are code as well and, you guessed it, there are some testing patterns that are around for a while. Today, we will take a look at one of them.
Those of us that do Test Driven Development have heard about doubles, mocks, stubs, fakes and spies multiple times. Unfortunately there is a ton of confusion about all these words and their meaning. Let’s see what each an every one of these really mean, where we should use them and how the popular testing frameworks for Ruby implement these. Test Doubles So, first things first. One of the biggest misconceptions is that doubles are types of objects that are used in testing.
When testing our code, we usually go for the happy path ™. We are awesome developers, we test our code, we are careful and there’s no way our code might crash. Or not really? I often try to think of software as a live being. It thinks, it does stuff and sometimes it gets some things wrong. Just like us. We sometimes trip up while walking, we drop our keys or forget them on our desk at the office.
Float precision in Ruby is a well known quirk. But when testing floats, not many of us bother to remember this and make their tests respectful to this quirk. In this post we will see how the popular Ruby testing frameworks help us test Floats properly. Background story Last week I published a post about migrating a test suite from RSpec to Minitest. What was very interesting is that I got a mention on Twitter from Ryan Davis with an offer for a code review of the migration.
I have always wanted to have some fun with Minitest but until this weekend I never got the chance to do it. For those of you that don’t know, Minitest is a suite of testing facilities, that support TDD, BDD, mocking and benchmarking. Having wanted to play with Minitest, this weekend I decided that I will migrate the test suite of a gem of mine, from RSpec to Minitest. Read on to see how it all went.
In my last two posts about Rack, I wrote about the basics of Rack and how to write middleware. If you have no idea what this is about, I recommend reading the last two posts (in the order above). For the rest of you, carry on - today we will see how to write awesome Rails middleware and how to use it in any Rails application. Rails and Rack play together really nice, so keep on reading!
There has always been a lot of noise about Test-Driven Development (TDD), best practices and it’s pros and cons. I don’t know if you remember, but last year DHH, Kent Beck and Martin Fowler had a series of public hangouts where they shared their opinions on TDD and testing in general and engaged in a very interesting discussion. These hangouts were recorded and in my opnion - they are a must watch.
Last time I wrote about the basics of Rack and writing a tiny Rack application. If you are unsure what Rack is and what is it’s purpose, I recommend you read the other post, famirialize yourself with Rack and get back to this post. If you think you know enough about Rack, please, carry on reading. Enter: Middleware So, middleware. Lets take it from the basics. What is middleware? Remember that Rack “wraps” HTTP requests and responses?
About three years ago, when I started working with Ruby and Rails, I noticed that the term “Rack” always came up in my Google searches. Overwhelmed with all of the stuff I needed to learn combined with the awesomeness of Rails, which shields the new Rails devs from it’s internals, I never really understood Rack or writing Rack apps. Although I used to see people mentioning “middleware” or “Rack middleware” I never really wrote (or tried to write) any middleware.
I am pretty sure everyone of us has been in a situation where you needed to generate a report and/or extract some data from a database and present it in a spreadsheet. In many cases, our clients prefer Excel to handle spreadsheets/reports, because, duh, it’s Excel. So, how do you approach this problem? Do you copy and paste data? Or use a RDBMS GUI to generate the report into a spreadsheet?
In every software, there are some things that have to be unique. For example, a Rails app has only one logger. Also, applications must have configurations, like environment, various API keys and etc. Take the configuration example - we need only one configuration for a runtime of an application. If all of the configuration data is stored into a class, then the whole app will need to use an object of that class.
Startup - in my opinion it’s the most ear-catching word nowadays. It represents growth, energy and, of course, billions of dollars. But yeah, a billion of dollars over a weekend is next to impossible. So, why would you attend a startup weekend? What’s the benefit? Or, if you know the answers to these questions, you probably would like to know how to win? Yeah, everybody would like that… This year, it was my first time to attend a startup weekend and it happened in the city where I live - Skopje, Macedonia.
Really cool gems, like Carrierwave for example, have this neat feature of configuring the gem in runtime. It allows you to easily configure how the gem will behave in your app. For example, you can add various authentication keys, how errors should be handled and what not. If you want to add this cool functionality in your gems, read on to find out more. Personally, I love to implement (and use) this way of configuring libraries in runtime.
Recently Confreaks uploaded a ton of RailsConf 2015 talks on Youtube. Although I haven’t watched all of the talks, these are some of the ones that in my opinion are very worth watching. Keep in mind that this list will grow as I watch more talks over time. So, without further ado… So You Want to Start Refactoring? by @j3foley In this talk, Jillian Foley talks about refactoring. She shares some techniques about how to approach code that you haven’t written and how to easily refactor it.
Recently I did an experiment with RSpec’s formatters. Turns out, the output that RSpec returns when you run your specs can be very customized for your own needs. Read on to learn how you can write custom RSpec formatters. Writing custom formatters RSpec allows customization of the output by creating your own Formatter class. Yep, it’s that easy. You just need to write one class and than require it into RSpec’s configuration to use it.
Recently I wrote about the Template Method pattern and how it’s implemented in Ruby. In the comments, one of the readers commented that the Template Method pattern is in fact the Strategy pattern. After thinking hard about how I should answer the question, I thought about writing a post comparing the two patterns. So, here it is - my version of design patterns head to head. Let’s see what these two patterns have in common and what are their key differences.
For those late to the Ruby 2.2.0 party like me, aside from the changes (and updates) the core team made under the hood for this version, they introduced couple of new methods to the _Enumerable_ module and to the Method, Float, File and String classes. Lets take a look at these methods and explore how we can use them in our everyday jobs. Just a heads up, make sure you use Ruby 2.
Gemfiles require at least one gem source, in the form of the URL for a RubyGems server. Although it’s not recommended, it’s possible as of Bundler 1.7, to add multiple global source lines. Each of these sources has to be a valid Rubygems repository. When using multiple sources, bundler shows a warning message: Although, this warning can be disabled by running the bundle config disable_multisource true command, there’s a better approach to this.