10 Pines Blog

Some performance case studies

lighting-talk performance

At 10Pines we do lightning talks every week to share interesting things with all our team.

Here is a presentation from the last Lighting Talk I gave.

30 Aug 2013

Parallel tests on Travis

jruby parallel ci

Since the last post, a lot of things happened: some things were fixed, some tests got faster and I learned that some aspects of JRuby are just slow (for now).

First of all, the author of parallel_tests was very kind to not only accept my pull requests, but to provide feedback and even fix my broken code instead of rejecting it. There was a way in RSpec to correctly calculate time spent on each file, instead of doing it per example (which resulted in the problems mentioned in the previous post). This resulted in increased CPU throughput (at least in MRI) as all processors could be loaded at the same time, instead of having them working together only a fraction of the time (because some of them finished earlier and remained idle).

18 May 2013

Parallel tests for JRuby

jruby rspec parallel

Recently, we’ve been porting one of our projects from Ruby 1.9.3 (MRI) to JRuby 1.7.3. There was a fair amount of work involved, mainly about Ruby gems and (in)compatibility with C extensions (which JRuby dropped support), but that will be left for another post. Here, I’d like to discuss the recent addition of JRuby support to the parallel_tests gem.

Our tests take about 20 minutes to run (it’s suite of ~3800 examples, which are currently undergoing refactoring to improve performance), but a lot of the machine’s processing power is unused. So I thought we could start by actually running all the code we can, before starting to profile and tune it. Also, if the delays were caused by waiting events, it wouldn’t help making the code run faster. This sounds good, but it didn’t turn out to be that easy.

7 May 2013

10 Pines, una empresa diferente

Hace unos años atrás cuando nos juntamos para formar 10Pines teníamos muchas dudas sobre lo que pasaría, sobre cómo nos iría, sobre la factibilidad de hacerlo, dudas lógicas de cualquier emprendimiento y cambio. Pero había una visión basada fuertemente en nuestras experiencias laborales pasadas que todos compartíamos y tenía que ver con qué tipo de empresa queríamos lograr desde el punto de vista humano y técnico. Esta vez, a diferencia de lo que aquellos que me conocen pueden estar esperando, no me voy a concentrar en los temas técnicos sino humanos.

11 Jun 2012

akka, un framework con actores en la jvm

jvm framework java concurrency

Introducción

Akka es un framework para programación concurrente, distribuida y tolerante a fallos en la JVM, principalmente basado en Scala pero que también soporta Java. Akka implementa el modelo de Actores (http://en.wikipedia.org/wiki/Actor_model) que se basa en entidades llamadas Actores que se ejecutan concurrentemente y se envían mensajes de forma asincrónica entre sí. Este mismo modelo es el que implementa el lenguaje de programación Erlang. Akka también implementa Software Transactional Memory, un mecanismo de memoria transaccional que es una alternativa al locking para acceder a estructuras de datos en memoria compartidas, y que es similar al que está implementado en el lenguaje Clojure.

En este articulo, veremos como utilizar Akka en Java, utilizando Actores y STM para resolver un problema de concurrencia simple pero que involucra multiples variables que se actualizan a la vez, con un cierto nivel de contención. Vamos a ver varias implementaciones, explorando las posibilidades de Akka, con el código fuente disponible para bajar. Utilizaremos la versión Akka 1.2.

29 Feb 2012

automatically change configuration based on current environment

java config-management spring

What if the application were aware of its different running environments so it could change its configuration automatically based on the current one?

23 Feb 2012

language’s type system and their impact in breaking dependencies

object-design code-reuse

One of the things that makes TDD difficult to apply on existing code (or just “legacy code”) is the dependencies that the object subject to test may have. The more “dependencies” the object has, the more difficult it will be to test it, almost for sure.

What makes things even harder is that usually most dependencies are incorrect, there is an unnecessary coupling between objects result of bad designs (yes, there are good designs and bad designs as there are good paintings and bad paintings, good music and bad music… being the definition of good and bad relative to a set of principles or rules. At least there is a design principle in software development that we all agree on that looks to maximize cohesion and minimize coupling. So the more unnecessary dependencies, the bigger the coupling, the worst the design is).

16 Feb 2012

The Art of Naming

naming object-design

Today we all know now that variables should not be called x or y, not even i nor n when we use the famous “for”… but do you know why? have you had trouble naming a variable? and what about a method (message) or a class?

The truth is that naming in software development is really important, so important that I usually say that programming is “the art of naming”.

2 Feb 2012

About names when designing with objects

naming object-design

One of the recurrent problems I see when teaching OO design is the “names” used by the programmers to name classes, methods, etc.

The problems are different depending if attendees are from the industry or the university. At the industry I see that names are wrongly selected, bias technology names, while at the university it is common to see the lack of ideas to name things (which makes sense because they have less experience). I will concentrate on the problem I see at the industry.

12 Jan 2012

protocolo fix: aspectos básicos y utilización en java mediante la librería quickfix/j

java finantial library

Introducción

El protocolo **FIX ** (Financial Information Exchange Protocol) es un protocolo de mensajes para el comercio de instrumentos financieros. FIX se utiliza ampliamente para la comunicación automática entre los participantes del intercambio de instrumentos, y especifica como son los mensajes para crear ordenes de compra y venta y consultar cotizaciones de instrumento, entre otros. Este protocolo es el que hay que utilizar para comunicarnos con practicamente todos los mercados financieros de manera electrónica.

En este articulo, veremos los aspectos básicos del protocolo FIX, como utilizarlo mediante la librería de java QuickFIX/J mediante un ejemplo como cliente y servidor, y algunos aspectos poco obvios que hay que tener en cuenta al utilizarlo.

21 Nov 2011