Moccato

In July and August 2015, I spent about 140 hours working on Moccato.

They are a subscription service for Nespresso pods. Apparently Nestle’s patent or rights for exclusivity recently expired, and Fabrizio Serra, formerly from ChefsClub, took up on the opportunity to have high-grade Brazilian coffees delivered to people’s doors.

They had run into difficulties with the frontend, even though they had been able to launch the website in some fashion. When I took up the work, they had a solid backend engineer, Dimas Cyriaco, a mostly complete and excellent visual identity developed by my brother’s Plau (who evidently were the ones to recommend me for the work), and were ready to begin packaging and shipping coffee all over Brazil.

Moccato is built on Ruby on Rails. Earlier, they had attempted to do an API-only backend in Go, but it was not successful. They decided to go with Rails, and what was initially an independent API client was integrated into the new Rails app.

They managed to make it work somehow, but the code base was highly impractical to iterate upon. The home page was linked to static css and js files, as were about 4 or 5 other pages, all to their own assets which were not at all using Rails’ asset pipeline. Thus, changing a mere style would involve finding it in any of up to 5 redundant stylesheets, and then making sure that style wasn’t used anywhere else.

Once I had that diagnosis, it was clear we had to move everything into the Rails asset pipeline, remove all duplicity, and only then look into giving the frontend conceptual coherence. Classes were named completely different from one file to another, and the DOM structure had 3 or 4 different versions.

The reorganization was not particularly difficult to do, but it’s remarkable how laborious it always is after something is in place. It’s impossible to stress enough how much more economic it is to have a very good programmer from the get-go. Also, of course, how it’s never very easy to get one.

I converted all .erb templates to .slim. Yes, Slim is much better in my opinion. If one is a Ruby programmer, Slim is the most Ruby-like templating system there is. It’s concise in the same way Ruby is.

I also converted most Javascript to Coffeescript. Same idea here: it’s a Ruby project, so it’s great to use a similar mental model for everything.

The pleasure of working with Slim and Coffeescript is like night and day when compared to xml-based templates and curly-brace-semi-colon-purgatory JS 5. Also they’re far more productive and, performance-wise, pretty identical.

I was able to introduce a few things which I learned from working with guys at Code Miner, such as using Pivotal Tracker (better than Asana, which I had been using prior, and possibly not as good as Sprint.ly, which I want to use soon) and certain Github project management procedures ranging from using pull requests even if working alone on a repo (pretty extreme, I know) to subtle commenting etiquette and markdown styles.

Perhaps most importantly, I learned and used Airbrake for the first time. It’s an integration that notifies you of exceptions via email, Slack or other channels. It has a ton of possibilities, and it’s one of those things you just can’t live without after you experience it. Another one I was not able to delve much into, but seemed pretty powerful, was RD Station, as far as I know a Brazilian digital marketing engine that seems really well done and which I will definitely look into with more detail.

The end result was a desktop website that is free of extreme layout breakages, much more consistent visually, and much closer to being considered responsive. Also, I was able to build a mobile version, which really should be everyone’s first consideration from now on — instead of desktop —, as much as I personally prefer to use and develop software for larger screens.

I wish I had more time to fine-tune the designs and work on user admin pages, but that was not to be. It may, however, happen in the future, and I will write about it if so. Many thanks to my brother Rodrigo, to Dimas for being such a great work partner, to Fabrizio for the trust and to the whole team at Moccato. I wish you much success.

Ruby Method Autoload

Continuing to study Rails’ source, I quickly had to take a look at the Rack gem, which wraps HTTP requests and responses. It’s far smaller than Rails.

The first thing that caught my attention was the way it loads the modules.

autoload :Builder, "rack/builder"

Autoload is Ruby’s way to lazy load modules. It only loads the above module when Builder is called in the code. This page breaks it down in more detail.

Ruby on Rails: Array method From

Looking at RoR 5.0 beta’s source code, here’s a very simple method that has been around for a while and does what the framework is so great at: humanizing the programming interface.

/activesupport/lib/active_support/core_ext/array/access.rb@from

 # Returns the tail of the array from +position+.
 #
 # %w( a b c d ).from(0) # => ["a", "b", "c", "d"]
 # %w( a b c d ).from(2) # => ["c", "d"]
 # %w( a b c d ).from(10) # => []
 # %w().from(0) # => []
 # %w( a b c d ).from(-2) # => ["c", "d"]
 # %w( a b c ).from(-10) # => []
 def from(position)
   self[position, length] || []
 end

It’s an array method, so it will use the dot-chained array as self as is the case in Ruby.

It uses the already pretty convenient array[new_start, new_end] notation to chop off the beginning of the array.

If you are working on an array that has, say, 5 elements, but passed it a position value of 8, the above operation will mercifully not throw an exception – rather, it will just return nil.

In those cases the || [] ensures the method will still return an array type, in this case an empty one, which is a sweet spot between making sense and being convenient.