Blog News about what we are doing

Fernando Dobladez

RubyConf Argentina 2012 - Day#1

Written by José Rozanec

This year Code54 sponsored RubyConf Argentina again! It was a great conference and we wanted to share some notes from it with you.

The first talk was titled “Where are my interfaces?”. A great talk by Jano Gonzalez from Chile. He introduced Ruby for beginners and Java/.NET programmers. He quickly showed some syntaxis and conventions, lambdas, declarative programming, mixins and more. He was concise and clear. For those who are tied to the JVM, he recommended to try JRuby. He concluded that programming languages are tools, and tools should be used where they fit for, and should be used well in that scope.

Second talk was “Ship it: staying lean at Living social” presented by Andy Atkinson. He shared his experience at Living social about how they apply Lean Startup principles to validate ideas, learn quickly and at a low cost from consumers (test ideas cheaply!), and preserve focus despite growth.

To do so, he described how they use AB-Testing, iterations and always start small. Features should be rolled out slowly, testing them by customer groups (ex.: by city).

Their engineering process has four clearly delimited phases: build it, pretty (design and UX), ship it, make it fast. How fast should you move? Andy answered us quoting Mark Zuckerberg: “if you are not breaking things, you are not moving fast enought”. This means you need to optimize for quick recovery from mistakes and share experience afterwards.


  • validate riskiest assumptions first
  • optimize for iteration speed and quick recovery
  • test small ideas with big potential
  • use A/B testing for optimization and product development
  • make customer validation your first goal

“Power of small tools” was presented by Michel Martens. He said we often see a dilemma between completness and simplicity. He stated that some tools aim to do everything, and so grow in complexity, and become harder to combine. He also pointed that software may have implicit dependencies (ex.: an authentication wrapper should always be up to date, handling latest changes on authentication for multiple providers) which may make it hard to mantain. Simple tools should be focused on a single problem. That makes them easier to understand, combine and mantain. If interested on this topic, you must check Simple made easy, by Rich Hickey.

Bruno Aguirre, from presented us “The web of tomorrow”. A great demo explaining us WebRTC mediastreams, peer connections and media channels:

  • Media Channels
    • allow camera and/or mic access and take care of image/sound synchronization.
    • what do we need to make it work? This feature is available out of the box on Chrome: navigator.getUserMedia() does the magic. You can also try this great js library, to use this feature from other browsers
  • Peer Connections
    • what do we gain? P2P, descentralization: connection between hosts persists even if the App server fails
    • what do we need to use them? It reuses protocols! We need a signaling server (XMPP, SIP) and a STUN server (used to calculate the best path between two points)
  • Data Channels
    • what do they provide? A channel to exchange data with low latency, high throughput, unreliable send on top of an established P2P
    • practical uses? VNC, multiplayer web games without a central server

Florian Gilcher had an amazing talk: “Self-improvement for pros”. Some tips he shared with us were:

  • we are all familiar with those situations when you get amazed at someones knowledge: what would you ask? First thing you’ll get to mind is “how did you learn ALL this?!”. But we can ask smarter questions to get better responses (ex.: what’s your favourite trick?)
  • consistent, regular and hard work is the way to get good at things.
  • since setup always drags us down, we should learn be our own devops; we should automate things as far as possible. But we can do a lot of progress on time efficiency and will still need time.
  • work time and learning time are different and should not be mixed.
  • check what literature you are reading: focus on doing things very consciously. If you see you’re loosing time, switch to another thing.
  • read a lot. There is no need to do an exercise for every thing you read. Knowing more vocabs allows you to think about them and will have more topics to talk with others.
  • when learning new techs, set ambitious goals. Expose to unpredicted as way to learn.
  • pass your knowledge along: help others with your skills. You have not understood what you can’t explain.
  • from while to while go offline: work with what you have. Do more work to find the solution instead of googling it.
  • be on the lookout: constant learning keeps you from becoming a dinosaur.

Wynn Netherland introduced 30 minutes of “API-logetics”, presenting patterns and anti-patterns: Amongst the patterns, we can list:

  • support curling: curl an endpoint and get info; support basic auth.
  • maximize payload: return full objects! Clients should decompose the data, to get the pieces that are meaningful to them.
  • rock the cache: use ETag cache policies!
  • dog food it: consume it, do something useful with it! Do something meaningful with your own API!
  • use HTTP codes properly: if you leverage HTTP, your tooling can leverage HTTP.
  • announce changes breaking compatibility
  • make documentation obvious. A good docs example is parse
  • create awesome guides!
  • provide a REST console
  • provide fast, transparent support
  • provide free samples
  • make it mashup friendly
  • support streaming: clients should be able to use a persistent HTTP connection to get updates as come.

As anti-patterns, he listed

  • security mazes: a pain of steps to auth. An example can be OAuth 1.0.
  • insane urls: urls should be user friendly. Don’t use url encoded params!
  • confuse header with body: don’t put all info at the header.
  • establish harsh rate limits
  • endless terms of service changes
  • inconsistency

Santiago Pastorino, a Rails core committer, presented us new features to be released with Rails 4.0

  • RoR definitely drops support for Ruby 1.8.7 and requires Ruby 1.9.3. Advantages you gain with this are:
    • uses Yarv, a quicker VM and bytecode interpreter
    • brings lazy sweep GC
    • native threads!
    • provides better strategies for global interpreter lock (GIL) and gobal VM lock (GVL)
  • allows mass asignements
  • supports declarative ETags
  • provides russian doll views caching! This means that even when content changes, you’re not going to throw out the entire cache. Only the bits you need to and then you reuse the rest of the caches that are still good.
  • introduces turbolinks: once a page is loaded, all links work with AJAX. This means js and css are no longer reloaded and recompiled (Chrome does recompile!). Be aware that onReady() will activate just for the first time we load the page.
  • support for asynchronous queues
  • new friendlier error descriptions should provide better feedback to beginners.

“Dealing with Developers / Dealing with designers” was presented by Nicolás Sztabzyb and Lucas Florio. They shared experience about common problems that arise between programmers and designers: how do we think of each other and how should we collaborate to get things work.

“Off the Tracks - Challenging the Rails Mindset” was a great talk presented by Nick Sutterer. He presented some great concepts and recommended to use some gems. Among the concepts, he explained the Representer pattern, which solves problems around document parsing, processing and rendering. The proposed solution is to create a representer, an object that knows how to layout and serialize a document when mixed into a domain class, but also capable of parsing incoming representation documents. Representers can be used in the client. Returned representations will also include hypermedia links endpoints to identify the given resource and for further requests. For further details, there is a great post on this. If interested on using this concepts on your RoR application, check the roar gem

He also encouraged us to use:

  • cells, a gem that allows to reuse view components as cells on RoR. Cells are cacheable and testable. The gem provides views inheritance.
  • objectify, a framework that codifies good object oriented design practices for building maintainable rails applications.

After the talks, we were all invited to get a beer and share experiences with other devs.