After a month under the rain in Paris, I became convinced that the place was in fact Siberia, or at the very least annoyingly cold. Luckily, I have the luxury to work remotely from Mexico, and got back just as Crowd Int's conference Magmarails was starting. In Manzanillo. On the beach.

While the place has many charms, the speakers and attendees were all awesome, and I really enjoyed clever conversations, with only minor hangovers.

I could write a lot more about all the talks I went to, but I'd rather pick a few that I enjoyed to summarize this three days conference.

The future of work

Wednesday, Scott Chacon from Github gave a keynote about how Github is organized, and the challenges they face by having grown so fast lately. While I had read about the topic earlier, his speech was thought-provoking: although AF83 is the nicest place to work at, I'm still wondering how to apply some of their mantra to my company, to upgrade our culture of work.

In the end, if I were to remember only one piece of advice, it would be question everything, as it is easy to get used to your inefficiencies to the point they have become invisible.

startup.rb - emprendiendo como rubista mexicano

Later, César Salazar gave a talk about his work at Mexican.VC, and how much potential for innovation there is in this country. Not knowing about venture capital in Mexico, I listened for a while and felt quite stupid for not realizing sooner that if the Silicon Valley's ideas could reach as far as Paris, why would they not exist in Mexico?

The shortage of coders in the Bay area pushed a number of companies to look around, so these really are great times to be a Ruby shop in Mexico. The only things missing to get the party started are ambition, and innovation, this is what Mexican.VC (among others) is trying to fix! To me, his talk sounded like a call to arms, to a nascent community of passionate programmers.

API: Assumptions Probably Incorrect

I cannot not mention Wesley Beary's talk on API design. Without entering in the technical details, his talk revealed a very good understanding of key principles when designing any form of API: simplicity, consistency, and reliability. Furthermore, you can enjoy (and test-proof!) the application of these principles on Heroku's CLI, or one of his most used rubygems fog.

Rails 4 and the future of the web

Everybody was quite excited to listen Aaron Patterson's keynote about Rails 4.

Were mentioned the upcoming job queueing features, more streaming goodness and how nice it'd be to just have direct access to the damn TCP socket in a controller. He covered quite a few other topics from type casting, complex types, to the need of a Rails.js, that could all be released within Rails 4 (well maybe not Rails.js which is more of an idea like “OMG why haven't we done it yet!?”). I must add that he's a very nice and patient person (and speaker), so thanks for coming by, and take good care of your cat overlord.

Go go fast as a developer

Dr Nic's talk was really a developer guide on how to release more code, filled with tips on how one could do it faster. Starting with how he used to build and package gems, and how at some point it was even easier to write rails plugins than ruby gems, his point is that the more tools we have to avoid typing boring commands and code, the better (bundle gem for example). Avoiding boilerplate is bliss: AUTOMATE ALL THE THINGS!

The next thing that will slow an open-source developer down is of course maintenance of his own code. Replying to e-mails and tickets, fixing bugs, etc. So, the more you can hand-off your stuff, the faster you can concentrate on other things.

Go simple

Blake Mizerany has, like so many of us, discovered Go recently, and fell in love… like so many of us. The expressiveness of the language, its flexibility, and features often make it look like a dynamic language. Why not then try a few Go concepts in Ruby? His experiments were about keywords like defer, or panic, and how they can be made using some Ruby tricks.

One thing I really enjoy with Go, is the way a method notifies its callers of errors by returning two values. This forces the developer to handle errors when they occur, and is arguably a lot nicer than exceptions: catching an exception can be done at any point of the call-stack and when reading code, one would waste brain power figuring out why and what is this exception handler doing.

Not to mention the evil habit of some ruby developers of using the horrible rescue nil when dealing with libraries that threaten to raise exceptions.

Ruby Kids

While Steve Klabnik has kept _why's Hackety-hack alive for a long time, and the project is a very good idea, Ron Evans (and others) felt that, for instance, the lack of tests were making it difficult to contribute to the project, and update it… So they created a new similar project: Kids' ruby.

As a kid, I remember having BASIC to play sounds, display shapes, and tinker with whatever would seem like a lot of fun. The Kids' Ruby project is about making that happen with today's computers: while they have gained like a bazillions of cores, they also have gotten a little bit more complicated, and locked. Let's show today's kids how to hack these beasts simply.

Software is just the tip of the iceberg, and many KidsCodeCamps have been organized to propose workshops using Kid's Ruby. They were all fully booked days before they start.

Where I conclude…

MagmaRails was my first Rails conference in Mexico, and I was delighted by the quality of the talks. Furthermore the guys of Crowd Int. were all incredibly nice, although a little bit curious about that guy from France but-who-lives-in-Oaxaca (I'm all for simplicity really). I can only hope I'll be back to Manzanillo next year with a few more folks from AF83. ;)