FutureJS - the future happens on May 2014


As you already know, we are the people behind the amazing Barcelona Ruby Conference, with two very successful editions so far (2012 and 2013), and yet one more coming this September.

What started as an exploratory concept -- building a conference -- soon began to be a very serious commitment for us. We never had had so much fun before hanging out with all the people at BaRuCo and building an intellectually challenging, safe, fun space for both attendees and speakers.

But waiting a whole year between BaRuCo editions wasn't fair to the great people we had met nor to us. So we decided to run a second conference every year, this time focused on the front-end and its future.

And so FutureJS was born. A new conference focused on the future of JavaScript on the browser, fresh ideas and what's to come next. And it's happening on the 1st-3rd May this year in Barcelona. As we did with BaRuCo, we took special care in crafting an amazing speakers roster, and introduced a few new ideas as well -- hands-on workshops where you get first hand experience on bleeding-edge topics such as WebGL, HTML5 games, single-page apps, ClojureScript, browser performance... you name it.

We are so excited about this event that we think you will be too. After already selling out the first batch, we just opened our second batch today, as well as student tickets. Go get yours while they're hot! :)

Also, Barcelona in May is GORGEOUS. Gorgeous enough that I'll fly all the way from Berlin. So there's that.

See you all there :)


Reviewing Pull Requests from Vim with vim-codereview

For quite some time I've been frustrated with much code reviews interferred with my normal workflow. Whereas I usually do everything from the terminal and Vim, in order to review my peers' code I had to open the URL in a browser, use a web interface and even use the mouse at times.

Once I was looking for a way to improve this, and I found a nice Vim plug-in called patchreview. It was good to review patch files, but that was definitely not convenient for GitHub Pull Requests.

So I went on and spent a few Fridays building a plug-in for this: vim-codereview, and oh what a delight! It uses the patchreview plug-in to do all the diff heavy lifting, and it interfaces nicely with GitHub.

What you can do with it is essentially reviewing the code in a nice vimdiff-like interface, commenting on a whole Pull Request and commenting on specific parts of the diff.

I set up a brief demo screencast for you to see how to use it :)

Happy reviewing!


RailsGirls: A Summer of Codes

If you haven't heard about the RailsGirls Summer of Code, you're missing out big time! At Codegram we are very committed to the RailsGirls movement, and not only we sponsored the first RailsGirls workshop in Barcelona very recently (in the context of the Barcelona Ruby Conference), but we sponsored the Summer of Code as well.

The RailsGirls Summer of Code is an amazing 3-month project where women from all over the world work full-time on Open Source projects. And we're so proud to support it!

What I'm most excited about is that Dirkjan Bussink (from Rubinius fame) and I are mentoring one of the projects. The amazing and hard-working Nicole Felhösi and Laura Wadden are creating their own programming language (Lani) on the Rubinius VM and writing a tutorial about it. They even have a blog and a twitter account where they share their day-to-day experiences.

To help them with the project we meet once a week in the SoundCloud offices, where they work from. I'm also very happy to have met the SoundCloud folks, who have been very committed to the Summer of Code since the beginning, not only with their sponsorship but with lots of resources and enthusiasm as well.

In conclusion, we're really happy to be part of this. The summer might be over, but the RailsGirls Summer of Code will continue to make the tech world shine a bit longer!


Distributed Codegram: New Horizons

New horizons

Codegram has changed a lot in the past 10 months.

The team has grown from six to nine people, so we moved to a bigger office in Terrassa. We also established a partnership with El Cocu, an awesome music and video production team, who now work at our office. They are the folks behind Barcelona Ruby Conference's awesome trailer!

Speaking of which, we have also been really busy preparing a truly awesome Barcelona Ruby Conference for this September. Check it out if you haven't yet.

One of the coolest changes though is that we are now present not only in Barcelona, but in Berlin as well. Last year I moved to this great German city! Berlin is home to many new tech startups, and it's attracting more and more talent from all around the world. Personally, I also think it is the best city to live in Europe, but that's just my opinion :)

Expanding to Berlin allowed us to be able to work with some of the coolest names in the startup scene. I had a great time working for half a year on Wunderlist 2 by the lovely folks at 6Wunderkinder, many of which are almost like a second family to me. We helped build the new API currently serving 6 different platforms. Early this year we moved on to a new project at Wimdu, where I'm having a lot of fun as well. In a city like Berlin, who knows what's next?

If you're in Berlin and you haven't met me yet, come say hi! You'll find me at the local Ruby user group, struggling between parentheses at random Clojure meetups, or just hanging out among friends and beers at the Landwehrkanal.

And if you couldn't make it to the inauguration of our new office in Terrassa last month, check out our flickr album about it! :)


New gem released: Futuroscope!

At Codegram, we've been recently working on leveraging Service Oriented Architectures to our products. This comes with real benefits like being able to work on different technologies, databases, teams and architectures in each piece of the product at hand. The right toolset for the right service - so far it's worked great and now we have an ecosystem of smaller services that move faster than a big'ol monolithic application.

But it comes with a cost: Communication. Using HTTP for glueing services together is pretty extended and people use to spend a lot of time and resources trying to speed up HTTP responses using different caching strategies, multi-get request and so. But we tend to forget a really powerful tool: Parallelization. But even if we don't, threads are hard, and nobody likes mangling with mutexes and thread-safety. It just feels outside of our domain for the most of the problems.

Futuroscope jumps on stage!

Futuroscope was created by the following premise: In most of the cases, we don't care about an actual variable's value right now. What if we could run some processes on the background until we need their values?

That's called the future pattern but we actually tried to give it an extra spin thanks to Ruby's duck typing - we don't care wether the parallel object is a promise or not. It walks, swims and quacks like the object we're waiting for. So we don't have to change our API's. It just works right now, for free, in your existing libraries.

Uhmm... Sure. Can we have an example?

Ok, so that's how could deal with an scenario where you need to make 3 searches to Twitter and sum all the result counts:

In my computer, that takes 3.059169 seconds. Here's how you could do it with futuroscope:

This takes 1.105958 seconds on the same setup.

We could reimplement this in a more convenient way using futuroscope's map syntax:

Is that black magic?

This is actually what's happening behind the scenes:

  • When you warm up your Ruby script and load futuroscope, it's automatically creating a pool of threads eager to process stuff.
  • When you create a future, will send that block to be processed by the thread pool and will immediately return a proxy object that delegates everything to that block's return value, without blocking the main thread.
  • When you try to call any method on that proxy, it will either wait for the results to complete or return them immediately if already finished processing them.

You can check out futuroscope on GitHub.


  • Futuroscope creates a thread pool of 8 workers by default, which will auto-scale up to 16 when it's given a lot of work. That's configurable. That's meant to help memory management and for performance.
  • You could reach dead locks when you're calling futures inside of futures (because of the thread pool). You shouldn't be doing that.
  • Futuroscope takes its name from an awesome amusement park located near Poitiers, France, and which I believe heavily shaped my childhood - not implying for good. You should check it out.
  • Futuroscope will works great on MRI, Rubinius and JRuby in 1.9 or 2.0 syntax.
  • On MRI, you'll only notice performance improvements if you're doing IO in between, because is not able to run ruby code in parallel (blame the Global Interpreter Lock).

Thoughts? Feedback?

We're eager of getting feedback from you. Please check out futuroscope on GitHub and let us now if you find any issues or can think of ways to improve it!