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.

Notes

• 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!

Hi everyone!

We have recently been using ElasticSearch in different projects and we're really happy with the results. I prepared a short talk for the Barcelona on Rails user group to let people now how our experience was with using ElasticSearch with Ruby and Rails.

Also, check out the companion gist with some code examples.

BTW, the awesome design wasn't (obviously) my work, kudos to Roger for the work!

Enjoy!

Check out this week's internal talk slides at Codegram:

• BDD best practices and antipatterns: Oriol Gual goes through some best practices that every BDD adopter should consider, and what anti-patterns should be avoided.
• Brew your own coffee...script: Txus shows us how to build a simple transcompiler (like CoffeeScript) in Ruby.

Check out this week's internal talk slides at Codegram:

• Encoding messages in a noiseless channel: Marc Riera explained to us how to construct an optimal, unique message encoding using the Huffman algorithm.
• HTTP authentication methods: Josep Jaume walked us among several http authentication methods, explaining some of their vulnerabilities.

As you might know, yesterday morning we had Monday talks at the office! Oriol talked about Object Oriented Nirvana, inspired by an old post about how to improve Object Oriented skills by using certain constraints while you're coding.

Then I got immediately interested on how to automate this, and knowing how easy is dealing with the Rubinius' Abstract Syntax Tree, I decided to give it a try and develop a tool that statically analyzes Ruby code to gain insights from it.

But what does it mean "statical analysis"? It means that this tool won't run any of your code at all, it just inspects it like you would as a developer, by looking at it. Since code is nothing more than nodes inside nodes, you can easily identify certain patterns that you consider wrong or desirable (for example, having else clauses in ifs, nesting blocks, or just using the word "foo" in actual programs). By traversing the AST, you can analyze parts of the code that don't fit your particular style or code quality requirements (actually with a little more work you could programmatically change those parts, i.e. automatic refactoring). I find this really cool!

The tool I've been working for the last couple of days is something along these lines (excluding, for now, the automatic refactoring part).

Introducing Pelusa - a Ruby Lint to improve your OO skills

Pelusa (which is Spanish for the word lint) is a static analysis tool and framework to inspect your code style and notify you about possible red flags or missing best practices. Above all pelusa doesn't run your code -- it just analyzes it syntactically to gain superficial insights about it, and raise red flags when needed.

Although Pelusa needs Rubinius to run, due to how easy it is to work with a Ruby AST with it, it doesn't mean that you have to run your application or Ruby code on Rubinius. Since it's a static analysis tool, pelusa doesn't care what your code runs on, it just looks at it and tells you stuff.

If you're curious, it looks like this (running on it's own code base, oh inception):

Find the default lint checks too Taliban for your tastes?

These are just guides, so you're free to fork the project and add/remove lints as you like. The fact that I've started with those doesn't mean that any of us thinks these are the true and only practices of Object Orientation, it's just a set of constraints that are fun to follow to achieve a mindset shift in the long run, or just to explore new styles.

One of the next features will be easy composability of lints, so you can remove those you don't like and add custom ones that fit your team's style or quality standards :)

Pelusa as a static analysis framework

With Pelusa, writing your own lints becomes very easy. Check out some of the default lints under the lib/pelusa/lint/ directory in the Github repo. Rolling your own style has never been easier!

Conclusion

My point by doing this was mainly exploring static analysis with Ruby, since I've never done it before, but also proving a point: good development tools are not only for statically typed languages! With a little imagination we can leverage our skills to make life better, or at least more interesting, for Ruby developers as well.

What do you think? Would you use this kind of tooling in your everyday job?