Category Archives: Software

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.

Deploying to Dreampress – note to self

If you setup a Dreampress installation with a *.dreamhosters.com temp site.
And when you deploy the final domain the links get stuck to the old .dreamhosters.com, including the admin area which becomes unreachable.

Make sure wp-config database credentials are directly reachable (or they evaluate correctly for a command line script).

SSH into the host and clear Varnish and Memcached caches:
curl -X PURGE “http://yourwebsite.com/.*” ; wp cache flush

Also, you may want to temporarily rename wp-content/object-cache.php, flush, and revert to the correct name.

Monitoring Phoenix

For the past month or so, I’ve looked at Elixir and Phoenix with interest. Phoenix is a young framework, still in beta, so tools are only starting to appear.

Michael Schäfermeyer has posted on Medium about monitoring in Phoenix, a welcome addition.

Here’s wishing for a quick port of Slim or Jade into Elixir.

WordPress and CodeClimate: 1 second thought experiment

After spending the last year-and-a-half working on a new Rails product, and recently succumbing to Code Climate, I took a small WordPress project. Don’t get me wrong: I love WordPress.

But one has to wonder what score this file would get on Code Climate.

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.

React.js and software workarounds

The amount of conceptual compromises React.js either addresses or introduces is very high. That, however, is typical, especially in a browser environment.

This introductory talk explains the basic design decisions that led to React.js.

Although the video is a bit old, it’s also surprising to hear, at the very end of the video, that the presenter has no idea whether React will be used for Facebook mobile on browsers. Reminds us of Microsoft.