Cubox Logo

Join Us Tomorrow for September’s Ruby Meetup

Join us tomorrow, second Tuesday of September for this month’s Ruby Meetup. We are having some interesting talks:

  • foca (Nicolás Sanguinetti) is giving an introductory talk about Git.
  • Federico Brubacher will talk about Lambda calculus.
  • Michael Cetrulo will give a talk about file-descriptors and redirections in bash.

Also for this meetup, we are having Davok Craft Beer, one of the greatest beers in our country.

Sign up at

We Are Joining New Context!

I’m thrilled to announce that we’re joining New Context. When I started Cubox, I wanted to create an environment where developers could shine. A place where I wanted to work, where people were smart and creative and worked hard. A place where we valued free software and community, contributing back to both.

Cubox is that place. It’s an incredible group of people and i’m proud of the team. We built a world class team in Uruguay. The acquisition is a validation of everything we’ve done over the last few years.

Cuboxers have helped with meetups, spoken at conferences around the world, helped make Ruby Conf Uruguay happen, released a ton of open source code. We’re not just about being the best in isolation, but engaging with the larger community so everybody can get better. Joining New Context lets us play on a larger stage.

In building Cubox, I came realize that there’s more than just building a fantastic engineering team, developing products the right way. We need to look at what we’re building. Creating the best product isn’t always enough. Sometimes we’d build an amazing application only to find nobody wanted to use or pay for it. We realized that we needed a methodology for designing the product in conjunction with the market where it’ll be used. We joined the lean startup movement, we worked with our clients to look at customer development and collect usage metrics.

New Context lets us do this work of providing agile development services to lean startups better. We’ve got a world wide network of amazing people to draw on. We’ve got access to Eric Ries, who literally wrote the book on lean startups. I’m not disappearing, but will be joining New Context as it’s CTO. We’re sticking around, I’m sticking around, and we’ll be building amazing things moving forward.

Press release on New Context

Cuboxer Pablo Astigarraga Speaking at Eurucamp 2012

Pablo Astigarraga, best known as PoTe, will be a speaker at Eurucamp 2012.

This year’s eurucamp heads out of town to the biggest of Berlin’s abundant lakes, the Müggelsee. Talks will take place at the Hotel Müggelsee and activities will take place around (and possibly in) the lake.

The conference will be held from August 17th to 19th. If you’re there, go say hi to Pote. His talk will be on Sunday at 12:00:

Monolithic vs Modular Software: No Holy Grails

One of the biggest problems in web development today is scalability. It’s a big problem, and not always easy to solve. The sheer number of requests that large applications need to process is huge, and increasing every day.

One of the most elegant and widely adopted techniques to deal with this is favoring modular architectures over monolithic ones. Having a modular network of tiny apps makes it easier to have a robust, maintainable codebase. Adopting the Unix philosophy of doing one thing right is a topic that has been coming up at conferences and on blog posts all over the world lately, and with good reason.

But is a modular architecture always the best solution? Is then a monolithic approach “wrong” from the get go? Sometimes building a modular system is worth it, sometimes it just isn’t. In this talk I put forward my thoughts and experiences dealing with refactoring your application into several small ones, how to build a monolithic app that can be easily split, how to approach the refactor gradually and incrementally, so as not to lose the ability to deliver new features, and how to decide when it’s simply not worth it.

On Git Commits and Programming Style

I recently had to send an email to our customer (and their developers) regarding mostly git usage and general Ruby coding style on our project.

The list borrows standard concept from many places and experienced git users and ruby developers will most likely know most of its points, but I was told it would make a good blog post, so here is an adaptation of the email.


On Git commit history:

  • Commit history is important, it’s even more important when we have a serious problem (IE: need to roll back changes for example). So make sure your commit messages are explanatory of what changes you introduce.
  • Don’t be afraid to use git commit --amend locally, I for example tend to forget about it and commit a lot of ‘debugger’ lines. So what I do is delete the lines, git add . && git commit --amend will fix the commit, so it will never get to github. (Important Note: never ever do –amend after you have already pushed to github. Or stuff will get scary – if you do this you’ll need to force push to github later, and it’s possible that you delete commits by other people)
  • Following the same reasoning: the first line of a commit message shouldn’t be longer than 50 characters. So as to keep it brief and easily parseable when you are reading through the commit history. If you need to talk more in detail about what you are doing (it happens a lot, and it’s not bad at all) do git commit without -m, so it goes into vim, and then write a short first line, leave an empty line and then describe the commit more in detail.
  • Don’t mix stuff, if you have a lot of changes do atomic commits only of the relevant files or else it gets really difficult to rollback only one feature, for example. Always think: “If I had to do a release NOW and this didn’t work: can I roll it back easily?”. If the answer is yes then you should be good to go :).

If you are working with Heroku

  • Don’t ever clone from the heroku repo, clone from the github repo and maintain that as origin, remember that we don’t use Heroku as version control, so make sure all your latest stuff is on github. There should never be a commit on heroku that was not in github first.

Ruby/General programming:

  • CSS in the views is a no-no.
  • Always use two-space indentation (soft tabs), make sure your editor does not insert tabs instead of spaces, as that might look different on different editors.
  • Same with JavaScript, a little is ok, big stuff goes into its own file (and in coffeescript, if possible).
  • Trailing spaces: I will murder you in your sleep.
  • Don’t leave empty lines at the end of a file. It gives me micro-seizures.
  • Never comment code and leave it there, we have git to remember our stuff, just delete it!
  • Always indent properly.

There is a styleguide for ruby (made by the guys at github) linked below that is more or less consistent with the style we have at Cubox (and with the standards on the Ruby community in general). Please read it, it’s only about 5~10 minutes and definitely worth it. :)

Further Reading

Original post by Pablo Astigarraga - check out This is where I tell you stuff

How to Get Good Developers

So for some unknown and weird reason I was contacted last week by someone from recruiting on a company that shall remain nameless, their intent wasn’t to hire me (or maybe it was, but they didn’t say it) but for me to give them advise on how to get in touch with highly skilled Ruby developers in Europe. They mentioned that I apparently lived there at some point and also misspelled my first name, which was really annoying.

I was bored today and felt like writing a response with some good advise, not really for their sake, but to try and help a bit to create a good ecosystem for programmers to work on, what follows is my reply, which I wrote a moment ago. I will just paste it here in the hope that it might be useful for other Recruiters. And maybe save myself a few emails in the future. :)

The email

I’m sorry I took a long time to answer your email, it was weird receiving it. Allow me to point which parts of it didn’t make much sense before giving you some advice on how to get in touch with good Ruby developers. :)

I haven’t really ever been to Europe, ever, and I only very recently spent about two months in the USA, also, you misspelled my first name, which let me tell you is a pretty horrible selling point. You need to take care of that stuff, specially since most good Ruby developers are pretty spoiled from a really favorable (for us) market right now, and used to be treated as highly valuable people are. Be careful about the small details, most of us have at least mild OCD and tend to notice this stuff. It’s annoying.

On to the advice you need: If you want good developers there are some main things you need to do:

Make yourself present at conferences.

We really pay a lot of attention to them, and highly trained developers attend those conferences either as speakers or attendees, try sponsoring a few for a start, or pay for a drinkup for the conference attendees after the event is done, EuRuKo (the last European conference held in Amsterdam recently) was on every Ruby developer twitter feed, your logo being everywhere and you being nice to people will tell us the two main things we want to know from a company before joining it: you are willing to give back to the open source community and you are fun and relaxed to work with. That’s really important stuff.

Pinpoint developers from open source projects an reach out to them.

Do your research, find out about good open source code in github, who maintains it, who originally wrote it, who contributed, don’t do stupid stuff like trying to get the original creator of Ruby on Rails as a “Ruby developer”, people in the open source world tend to be above average programmers, mainly due to their code being public and peer reviewed by a lot of other developers, we all learn a lot from that experience and grow to be the strong technical people that you need.

People with passion for what they do that will the extra mile on their own free will, because we feel proud of our code and want our products to succeed, being a programmer is much like being a gardener, or an architect, or some other form of art, only (for me at least) better. Because we spawn things with our minds and hard work and to see our brainchilds succeed is one of the greatest sources of joy we find. You want people with that sort of passion.

Spoil your developers (maybe not that much, but at least a little)

For better or worse most good developers today are really spoiled by the companies hiring them, and we’ve grown used to that, because of that it is highly unlikely that me or any developer that is happy leaves his or her job, and it’s very likely that a developer who feels mistreated, be it lack of respect for his work, considering him/herself underpaid or whatever other such thing will leave fairly quickly for greener pastures. The market has need of us and we are used to it. It’s just a fact that companies need to deal with these days.

Allow remote work

This is unfortunately just a no-brainer for you, most developers have their lives and the possibility of working remotely. Having a distributed team introduces some difficulty in team management but also gives you a much larger pool of suitable candidates, specially highly skilled developers, they can work for good companies from home, if they can’t do so for your company they are likely to not be interested.

I think those are the main facts, of course they don’t particularly apply to European developers, but Asian, South American, you name it. Wish you the best of luck with your company. :)

Original post by Pablo Astigarraga - check out This is where I tell you stuff

Evan and Diego on National TV

Punto Tecno is a TV show about technology news in Uruguay, focusing on the latest products and trends in communication and computers. Both Evan and Diego were recently invited to the show. You can watch both interviews below:

Cubox founder Evan Henshaw was invited to talk about the beginings of Twitter and how the company came to be:

Diego Algorta, Cubox CEO, was invited to talk about the existence of a new internet bubble like the dot com bubble in the 2000’s:

Thanks to Canal 20 and reporter Gerardo Sotelo for the invitation.

June Ruby Meetup

Tomorrow is the second Tuesday of the month, so it’s time for this year’s third Ruby Meetup.

Pablo Astigarraga (PoTe) is telling us about planet.rb, a gem he developed which works as a RSS aggregator to make “planet” sites.

The meetup is open for more talks, so we might have some other technical discussions. Anyone can propose a talk!

As usual, we’ll be hosting it in our CoworkingMVD space, at Bulevar España 2259. There’ll be pizza and drinks. And remember, if your company wants to host the meetup at their offices, or provide the drinks and food, you are more than welcome.

Sign up at

Cuboxer Bruno Aguirre Confirmed as a Speaker at Euruko 2012

We are very proud to announce cuboxer Bruno Aguirre (a.k.a. “cuervo”) will one of the speakers at Euruko 2012:

EuRuKo is an annual conference about the Ruby language with an informal atmosphere and lots of opportunities to listen, to talk, to hack and to have fun.

The conference will be held on June 1st and 2nd in Amsterdam and tickets are already sold out.

Bruno "cuervo" AguirreBruno will be giving the following talk:

The Future is Dead: Long live the Past

We keep looking for good ideas to improve our code, to make our systems even more powerful. But there are a lot of good ol’ ideas that are resurfacing and most of them were already thought about years ago.

I propose a journey through technology archeology to re-discover all that tools that are buried deep into the internetz.

Remember the scriptures of ‘The unix way’, the HTTP reference engraved in stone and learn from the elders about concurrency and single responsibility.

  • Old new HTTP
  • The Unix way in a modern world
  • RDBs mystic powers
  • … more stuff for free

Why should i care?

We have a lot of COOL new technologies like a Nodejs Fibonacci server and stuff

New technologies are great, but they are only a part of all the old ones that are buried in people’s mind. I want to show the amazing ideas that were crafted years ago and are waiting to return.

Old things are old and … like… old stuff sucks

A lot of old stuff sucks but a lot of it can teach us the way of crafting optimized code and solid solutions without being monolithic. And remember satellites and spaceships code were made without EC2.

If you go to Euruko, find Bruno and ask him for a hug.