Category Archives: Ruby on Rails

My Year in: Software Development

The year of 2018 has been a wild ride for me. It started at EmCasa.com, the startup I described a year ago. We were in the process of putting out a successful MVP, engaging clients, becoming accelerated by Harvard University and closing out an excellent seed round with important investors. All this in just a few months.

Very quickly my job morphed from do-it-all (think product and CTO duties, plus co-founder responsibilities) to team-building. This was a highlight as I was lucky to bring in great people like Gabriela Seabra, Nathan Queija and Rodrigo Nonose, each respectively owning mobile, web frontend and backend. On the design side, Plau.co did great work.

For the first time I felt fully ready to create a digital company in style. The Elixir-React stack worked beautifully, we rolled out features fast and the development team became a cohesive unit very quickly.

Towards the middle of the year, as the company reached 14 people, it had become clear to me that there wasn’t a good cultural fit among the founders. It was one of those very painful decisions but ultimately not difficult to make when visions don’t intersect well enough: we parted ways amicably at the end of July and I went looking for a new job.

That month was tense for me. I knew I had a deadline to basically stop getting paid, my wife was 6 months pregnant with twins and I had nothing lined up as far as work.

I am part of Toptal’s network of freelancers and that was one of the main ways I tried to find the next thing. I found something that really interested me: they had posted an opening to join their Core Team. I applied, passed, and joined the team as a freelancer in August. 

The first few weeks were hard in a sense: I and two other developers coming from Toptal’s talent network had a kind of secondary status, without access to many tools. Luckily our teammates were extremely helpful and welcoming. In a few weeks we became official team members and got access to what the other engineers see.

My team works on Toptal’s public pages, from home to skill pages, basically everything a logged out user can access in the website. 

It’s been a tremendous experience for me so far, as it’s the largest organization I’ve been a part of in technology. Toptal is in fact the largest fully distributed company in the world today. As such, I work with people from all over the world, and that’s the part I like best. To do it from home is the cherry on the cake as my children are very young and being close to the family is priceless at this moment.

At my team I’ve experienced the most well-developed set of processes I’ve ever come across. The firm has reached a level of maturity that allows for very well written task tickets, a proper retrospective at the end of each sprint, interesting strategic discussions among executives, and work that has large-scale, immediate impact. On the other hand, I am very far from top strategic decisions and information, and this feels weird to me having run my own company for so many years.

To a very large extent, this was the year when, for me, technical concerns became secondary to human concerns. Sure, if you’re starting a product alongside just one other person, what tech stack exactly to choose is of paramount importance. In a team of 200 that’s much less important, as each person can focus on a narrower part of the work, and the human interactions can catalyze or hinder progress.

Thus, I gave myself the chance of observing all the teams in the organization: dialogs, processes and rituals. Whatever was visible to me, I tried to learn from. It wasn’t long before I got the opportunity to onboard newcomers, help interview candidates, conduct daily standups and interface with other companies. That’s not to say I didn’t study programming this year: I continued my deep-dive into the Elixir codebase, studied GraphQL, some more Elm, algorithms, some Python and a little bit of Natural Language Processing.

It’s much easier to paste some code or links to a framework and illustrate what goes on as a programmer. Human interactions seem to me much harder to communicate. A book that does a great job of explaining management applied to software is The Manager’s Path, by Camille Fournier. I read it this year and it very neatly sums up many things we learn the hard way, plus many others I simply did not know.

So this year was one in which I started out as CTO and ended-up as an individual contributor. But each experience has taught me a lot about management and leadership, which will be my way forward in technology.

 

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.