Spring Roo, ¿competencia para Grails?

Interesante lo de Spring Roo. No lo conocía pero he llegado a él a través de la lista de Grails.

El link de arriba, el oficial, la verdad es que no deja nada claro que es Roo (el nombre parece que está todavía abierto). Según la descripción de esa página, pues casi que podría ser cualquier cosa. Pero bueno, básicamente Spring Roo viene a ser la alternativa Spring a Ruby on Rails o Grails. Es decir, un framework creado bajo los principios de convención frente a configuración y que aprovecha al máximo Java y Spring.

Hace un par de días, uno de sus autores publicó esta entrada en su blog donde muestra como construir una aplicación web Java totalmente funcional en solo 11 comandos. Vamos, muy en la línea de cualquier tutorial de grails o rails pero siendo todo Java, sin nada dinámico. En la misma entrada hay un link a la primera versión descargable de Roo por si lo queréis probar.

Ni que decir tiene que el framework está totalmente centrado en torno a Spring, Maven, JPA, muchas anotaciones, el soporte de REST de Spring 3.0 y AspectJ, siendo este último lo que se utiliza para introducir el llamemos "dinamismo" en la aplicación. La verdad es que de buenas a primeras a mi esta propuesta se me antoja muy pero que muy interesante. Especialmente por las ventajas de ser estático en cuanto al soporte del entorno de desarrollo, que es lo que a mi más me atrae. ¡Pero dónde estabas hace un año por favor!

En esta otra entrada de blog comentan algunas impresiones sobre Roo extraidas del keynote de Rod Johnson en la SpringOne.

Bueno y ahora la pregunta, ¿y por qué Spring Roo si SpringSource acaba de comprar G2One y por consiguiente tiene Grails entre sus proyectos? Graeme Rocher contesta en la lista de Grails.

We're working on a formal FAQ to help answer some of these questions, but fundamentally SpringSource is about enhancing developer productivity and those who cannot move to Grails (due to corporate policy mandating Java for example) shouldn't suffer from an unproductive environment hence the existence of Roo. Ultimately whether you use Grails or Roo you're going to be using Spring so we don't necessarily see them competing.

Now Roo can only achieve so much within the limitations of a statically typed language and in fact does most of its tricks through AspectJ and code generation. We hope that it is a gateway drug so that users eventually move to Grails and experience the full productivity benefits of both the Groovy language and the Grails framework. Until then people sticking with only Java at least have Roo as an option.

La explicación tiene todo el sentido del mundo. El único problema es que no evita que se trate de dos frameworks muy parecidos. ¡Y ambos hechos en Java! Con la única diferencia de que Grails soporta y requiere groovy. No sé yo si mantener los dos tiene demasiado sentido, por lo que esto siembra algunas dudas. ¿Podrian converger en el futuro? Dejo abierta la pregunta por si alguien quiere opinar.

Podcasts para no perderse: debug_mode=ON y Agile Spain

Hoy he estado escuchando el podcast que han hecho en javaHispano a la gente de Agile Spain y creo que ningún programador, analista, arquitecto, jefe de proyecto, gerente, y en definitiva nadie que se dedique al mundo del software debería perderse.

Tanto José Manuel Beas, como Xavier Quesada como Xavi Albaladejo demuestran un fenomenal conocimiento del mundo de las experiencias ágiles y comparten sus experiencias y consejos en este podcast que resulta enormemente instructivo, inspirador y que además es muy ameno de escuchar.

Por otra parte, tirón de orejas para mi que sigo demostrando lo malo que soy en cuanto a marketing :), los chicos de debug_mode=ON han iniciado una serie de podcasts y fueron tan amables de interesarse por Jobsket para su primer podcast. Fenomenal iniciativa también, y no os perdáis este número ya que en el tanto Dani como Jordi cuentan algunos de los secretos de Jobsket :)

Cinco cosas malas de ser contractor

El anterior post "Cinco cosas buenas de ser contractor" tuvo bastante buena acogida. Así que es hora de bajar a todo el que estaba pensando en hacerse contractor a la tierra y hablar sobre las cosas malas de trabajar por tu cuenta, que haberlas hailas.

• Inestabilidad laboral: Si buscas estabilidad laboral, entonces ser contractor no es lo tuyo. Olvídate de ello inmediatamente. Los contratos normalmente son a corto plazo, tres o seis meses, como mucho un año. Una vez terminado el contrato puede que continues o puede que no, dependiendo claro de muchas otras circunstancias.
  
  Es raro que un contract esté en una empresa más de un par de años. Lo natural es que su andanza termine tras varios meses, ya que o bien el proyecto ha terminado, o su tarea ha terminado, o simplemente porque la empresa cree que es el momento de que decida si quiere ser permanente o ir a otra parte. Aunque ojo, hay excepciones. Yo he conocido casos de personas con hasta diez años de contractors en el mismo lugar.
  
  Hay muchas empresas que tras tener a contractors varios meses en plantilla, intentan reconvertirlos a permanentes ofreciéndoles mejores puestos. Normalmente esto sucede cuando la empresa tiene mucho interés, pero no quiere tener contractors muchos años, ya que en tal caso el resto de trabajadores podrían empezar a considerar el por qué ellos no son contractors.
  
  En resumen, que hoy estás aquí y mañana estás a treinta quilómetros en otra empresa. Esa es la vida del contractor y no todo el mundo está preparado para ello. Hay gente a la que hacer esto le gusta, lo ve como cambiar, aprender cosas nuevas, menos monótono, etc. Pero otras personas prefieren tener tranquilidad en un sitio y dedicarse más a progresar. Si eres de estos últimos, mejor no ser contractor.


• Los primeros en caer: Si hay despidos, los contractors serán los primeros en irse. Es natural por varias razones, ya que primero suelen ser recursos más caros; segundo, no cuentan para las cifras de despidos de la empresa; y tercero porque si el resto de empleados permanentes ven que los despiden a ellos y que los contractors se quedan, bajaría la moral considerablemente.
  
  Si eres contractor y ves que no hay señales de renovación o que en la empresa se empieza a rumorear que hay despidos, entonces lo mejor es que pongas a funcionar la maquinaria de encontrar trabajo. No vale eso de esperar a la última semana, porque normalmente a un contractor le lleva más tiempo encontrar un trabajo que a alguien que busque un puesto permanente.
  
  La demanda de contractors es mucho menor que la de empleados fijos, así que hay bastante competencia por los puestos que van saliendo. Esto hace que si pierdes tu trabajo quizás pasen varios meses hasta que encuentres uno nuevo. Es por eso importante el comenzar a buscar pronto, quizás con un mes de adelanto, si no se ve ningún progreso en tu contrato actual. Si tras pasadas unas semanas tu actual cliente te ofrece renovar, pues bueno en el peor de los casos tendrás dos trabajos donde elegir.


• Difícil evolucionar profesionalmente: Hay mucha gente que le gusta ascender. Ir evolucionando. Ahora soy junior, ahora soy senior, ahora soy gerente, ahora soy presidente. Si ese es tu perfil, lo cual es perfectamente lícito, entonces olvídate de ser contractor, porque los trabajadores independientes no ascienden. Para algo son independientes :)
  
  Un contractor puede estar en el mismo puesto durante meses o años y ver como otros compañeros, quizás menos aptos que él, van consiguiendo puestos con más nombre y avanzando en la empresa. Esto es lo normal, y una empresa cuando contrata a un contractor no considera que lo tenga que mover a un puesto mejor pasado un determinado tiempo.
  
  Aunque ojo, eso no quiere decir que el contractor no progrese laboralmente. Conforme pasan los años puedes incrementar tu salario, o simplemente aplicar a puestos diferentes para aprender otras cosas. Aunque si por ejemplo eres un programador y quieres trabajar como Jefe de Proyecto pues tendrás que convencer a tu cliente de que puedes hacer esa labor.



• Marrones!: Estaba pensando en llamar a esta desventaja "retos profesionales", o algo así, pero voy a ser más directo: marrones. Esto no es algo generalizado, yo he tenido que trabajar en auténticos marronazos y en proyectos que empezaban desde cero.
  
  Pero es importante que el contractor tenga claro que su trabajo no tiene necesariamente que ser divertido, y debe estar preparado para todo, tanto para pasárselo bien diseñando sistemas maravillosos, como para pasarse largas tardes aburridas haciendo mantenimientos.
  
  Esto depende mucho de la empresa. Hay empresas que buscan expertos y que intentarán aprovechar al máximo lo que estas personas puedan aportar, ya que teóricamente se trata de recursos caros. Pero por otra parte, otras muchas empresas buscan contractors para hacer tareas que su personal no quiere/puede realizar. Esto pueden ser tareas aburridas, corrección de errores, etc.
  
  Las tareas también pueden cambiar. Lo que al principio puede parecer un buen trabajo después se puede volver un infierno en cuestión de segundos. Recuerdo uno que he tenido en el que comencé haciendo un sistema muy interesante, pero que lamentablemente el proyecto se canceló por problemas internos de la compañía. El último mes lo pasé haciendo perl mientras buscaba otro empleo. Y eso no fue divertido :)
  
  Y por supuesto, una de las razones más comunes para contractar contractors es porque los proyectos están naufragando. Es decir, que desde un principio entras en el marrón, quizás con otros diez contractors para salvar ese proyecto que nunca se salvará (porque ya sabemos que eso de salvar proyectos a base de contratar más y más gente no funciona, ¿no?). La mejor forma de estrenarse de contractor, proyecto en peligro y con horas extras a mansalva :)
  


• Aislamiento de la empresa: Esto también depende de la empresa, pero lo más normal es que el contractor no se integre dentro de la mecánica normal de trabajo. Es decir, que si hay reuniones internas es posible que el contractor no esté invitado; que si hay que pensar en funcionalidades futuras, diseños, arquitecturas, etc. el contractor tampoco tenga palabra sobre ello, etc.
  
  Yo estado en empresas en las que los contractors tenían voz y voto, y en otras en las que no lo tenían. Sea como sea, como contractor tienes que aceptarlo. A fin de cuentas es normal que algunas empresas intenten proteger ciertas cosas, aunque al final cualquier empleado podría también crear algo por su cuenta y empezar a competir.
  
  Respecto a la vida en la empresa, nuevamente y dependiendo de donde se esté trabajando, puede que te integren más o menos. Si de pronto un día se van de cena a un casino pagado por el club de ocio, pues puede que no estés invitado a no ser que pagues un extra; si un fin de semana toca viajecito a hacer surf, más de lo mismo; ¿Cena de Navidad? Pues igual. A fin de cuentas, un contractor es una empresa en si mismo y puede pagarse estas cosas si lo desea.

Pues nada, espero que os haya sido útil. Tanto este como el anterior post resumen lo que he ido percibiendo durante estos meses. Pero ni que decir tiene que esto son sólo mis opiniones personales, y quizás alguno de vosotros tenga algo más que decir. Así que los comentarios son más que bienvenidos.

Después de leer esto, ¿Qué os parece?, ¿Vale realmente la pena meterse en este mundo?

Primer Iniciador Galicia en Coruña este viernes.

María Encinar me avisa de que se va a celebrar el primer Iniciador en Galicia, y más concretamente en Coruña. Como yo todavía no podré ir, os lo comento porque me consta que hay unos cuantos gallegos leyendo este blog, o al menos eso dice el Google Analytics claro :)

Tanto María Encinar como David Pombar han hecho un fenomenal trabajo acercando este tipo de eventos a Galicia, donde no se puede decir que abunden este tipo de cosas. Así que desde aquí os animo a todos los que leéis este humilde blog a acercaros al ITE Caixa Galicia este Viernes 24 de Abril.

El ponente invitado es José Ramón García de Blusens y las cañas las paga Jacobo Lázare de BidoBido.com. Tenéis más información en el blog de María.

Mucha suerte.

Licencias de JIRA y Confluence a 5 dólares

Quizás os interese que Atlassian ha comenzado una promoción para Charity por la que ofrece licencias de JIRA y Confluence a 5 dólares. Podéis acceder a la promoción desde este enlace.

La verdad es que es un regalo. Encima incluye soporte y mantenimiento y te mantienen el precio durante las renovaciones. Yo me imagino que además de la obra social están también apuntando a toda la gente que se va a herramientas como campfire que son gratis para equipos pequeños.

Así pueden enganchar a personas que normalmente no pagarían por JIRA o Confluence. Si no lo habéis probado nunca y tenéis un equipo pequeño, en serio, os lo recomiendo enormememente. Tanto JIRA como Confluence son herramientas excepcionales.

Los retos de la nube para aplicaciones tradicionales

Muy interesante este hilo en el grupo de Cloud Computing de Google Groups, donde se exponen opiniones sobre cuales son los principales retos a la hora de migrar una aplicación tradicional a un entorno de Cloud Computing como pueda ser Amazon EC2. En el hilo se exponen algunas notas importantes:

• Falta de software preparado para la "nube". ¿Dónde están nuestros cloud-enabled Tomcats, WebSpheres, WebLogics o Jbosses, por decir algo? O por poner un ejemplo más reciente, Google lanza el soporte Java en Google App Engine pero hay que pasarse unas semanas arreglando Groovys, Grails, JRubys y similares.
• Volviendo al tema Google App Engine. La forma de programar cambia. Donde teníamos una base de datos tradicional ahora tenemos BigTable. Encapsulado o no en JPA o cualquier otro interfaz, hay que cambiar el chip.
• Bienvenidos al mundo de la programación distribuida. Aunque se puede usar la nube para desplegar una aplicación en capas tradicional. Pues aquí la idea es la promocionada por BigTables, MapReduces y similares. Es decir, distribuir el procesamiento/almacenamiento/mensajería entre los diferentes componentes de la nube. ¿Estás preparado para ello?, o incluso mejor, ¿Están tus programadores preparados para ello?

Nati Shalom de GigaSpaces comenta este mismo hilo en su blog y también Grig Gheorghiu tiene comentarios interesantes sobre sus experiencias en un despliegue importante sobre EC2.

Esperar fallos parece uno de los consejos más sensatos que se pueden extraer de estas lecturas, y también el de intentar automatizar el proceso para no morir en el intento. Una buena lectura para el que esté planteándose una migración.

Notas sobre la arquitectura de Facebook

Hace ya unos cuantos días que publicaron en InfoQ una presentación muy interesante sobre la arquitetura de Facebook. Es de esas presentaciones que te enganchan porque está claro que Facebook es la aplicación de moda, así que te quedas mirando para el video con cara de bobo y pensando "ooooh, así que lo hacen así".

He aprovechado para tomar unas notas que comparto con vosotros por aquí:

General

• De vértigo: Mas de 120 millones de usuarios activos, más de 50 mil millones de páginas vistas por mes, más de 10 mil millones de fotos, más de 50 mil aplicaciones de terceros, más de 400 mil desarrolladores, más de mil millones de conexiones.


• Plataforma basada en LAMP. PHP, Memcache y MySQL. Para el resto de servicios que no encajan dentro de este stack crean componentes en diferentes lenguajes. Tienen por ejemplo servicios escritos en C++, Java, erlang, python, ...


• Utilizan PHP básicamente porque es con lo que se empezó y porque es un lenguaje pensado para la web. Pero han tenido muchos problemas con él. Es un lenguaje complicado, dificil de extender, del que incluso los desarrolladores más experimentados escapan. Especialmente molestas les han sido su weak typing que hace difícil el comprender el código y la dificultad de hacer análisis estático.


• Han tenido que mejorar tanto PHP, como memcache buscando escalabilidad. También han hecho mejoras en MySQL

MySQL

• ¿Por qué? Porque es realmente rápido. Lo usan principalmente como un almacenamiento de key-value.


• 500 nodos físicos en cada centro de datos. Distribuyen bases de datos a lo largo de estos nodos. Los datos se distribuyen a lo largo de las bases de datos logicas.


• Utilizan también datawarehousing y periódicamente vuelcan datos a estos sistemas.


• No se hace ninguna join en producción


• La mayor parte del acceso de datos en Facebook es a datos recientes, asi que archivan los datos viejos.


• No han hecho demasiados cambios en MySQL. Un sistema para obtener el id de cualquier elemento (Facebook id -> database id) y la base de datos donde éste se encuentra + un sistema para mejorar el archivado. Han trabajado en resolver las insonsistencia entre las cachés cuando éstas están en diferentes centro de datos (problema habitual de replicación master-slave), etc. Es decir, librerías para facilitar el uso de MySQL.


• Tienen una base de datos con el grafo de contactos. El grafo está distribuido, pero los datos similares (e.g. tú perfil y el de tus amigos) esta collocated.
  
• De empezar de nuevo, seguirían con MySQL. Es una base de datos rápida que les permitió escalar desde el principio.


• No utilizan transacciones distribuidas ya que la consistencia de los datos no es una gran preocupación. De hecho, la mayor parte de los casos de uso no requieren ningún tipo de consistencia.

Memcache

• 25Tb !!


• Latencia media < 200 microsegundos.


• Utilizan multi-gets para obtener múltiples datos cacheados (e.g. fotos) en paralelo.


• Han hecho ligeras mejoras. Memcache sobre UDP ya que originalmente trabajaba sobre TCP que guardaba buffers y consumía demasiada memoria.


• Han modificado también el kernel de Linux para que se comporte mejor con Memcache (e.g. las interrupciones de red originalmente son tratadas sólo por un único core). No creen que la comunidad acepte sus modificaciones. Hack!!! :)

Más notas

• Tienen frameworks de unit tests, y regression test. Pero esto entro un poco mas tarde asi que la cobertura no es tan buena como desearian.


• Algunos límites, como el del número de amigos que se puede tener, están ahí para mejorar la escalabilidad.


• LAMP no es perfecto. En Facebook se pueden crear servicios en muchos lenguajes diferentes. La norma es simple: escoge el mejor lenguaje para la tarea.


• Intentaron migrar el código base a Python un par de veces pero sin éxito.


• Crearon y liberaron Thrift para la creación de servicios en diferentes lenguajes. El rendimiento es mucho mejor que el de otras alternativas como SOAP, CORBA, etc.


• También han liberado el gestor de logs Scribe

Y eso es más o menos todo. Mi impresión después de ver la presentación y conocer más a fondo la arquitectura de Facebook es que Facebook ha sido creado por un grupo de personas con grandes conocimientos de sistemas, no tan preocupados por el software en si mismo. Parece claro que el peso de la escalabilidad recae sobre el hardware, la base de datos, el kernel de Linux, la red, sistemas de redundancia y demás, en lugar de en el lenguaje o la plataforma en si misma.

¿Es esto bueno? Pues no se puede decir que les haya ido mal, ¿no? Aunque las organizaciones en las que estamos el resto de mortales, no tengo yo tan claro que se puedan permitir escalar a base de parches en MySQL, PHP, etc., y servidores a mansalva.

Super-interesante la presentación.

Cinco cosas buenas de ser contractor

Mi época como contractor parece que va llegando a su fin. No he mantenido muy al día el blog debido a la gran cantidad de trabajo que he tenido los últimos meses pero iré actualizando sobre esto en los próximos días. El caso es que hace unos meses que he cumplido un año como contractor.

Han sido doce meses muy emocionantes en los que he trabajado para dos compañías diferentes, curiosamente ambas dentro del mundo de los pagos o transacciones bancarias. La primera compañía se dedica a los pagos online mientras que la segunda se dedica a la implantación de productos de gestión de transacciones compatibles con el estandar SEPA. En fin, que eso no viene mucho a cuento. El motivo de este post es intentar expresar lo que en mi experiencia han sido las mejores cosas de ser contractor, por si alguno de vosotros está pensando en un cambio. Ahí vamos:

• Dinero: Decir lo contrario sería ser hipócrita. Un contractor normalmente está en una compañía un corto espacio de tiempo, pueden ser tres meses, seis meses, un año, dos años, o incluso en algunos casos incluso más, pero esto ya no es lo normal. Esto descarta el evolucionar profesionalmente en la empresa. Y si lo que buscas no es una carrera laboral en la empresa entonces lo único que queda es el dinero.
  
  Un contractor gana bastante más dinero que una persona con el mismo trabajo pero con contrato permanente. Aquí estaríamos hablando de ganar el doble, el triple, o incluso más. Si le echáis un vistazo a cualquier informe de salarios para contractors en Irlanda o UK la diferencia salta a la vista.
  
  Especialmente si vas a vivir al extranjero únicamente por la experiencia y tienes pensado volver, el ser contractor es una opción muy a tener en cuenta.


• Experiencia: El ser contractor te permite hacer algo que está muy mal visto en otro caso, y que es el trabajar en múltiples empresas a lo largo de un corto espacio de tiempo. De hecho, no es sólo que te lo permita, sino que en muchos casos no te queda más opción porque los contratos pueden ser de duración muy corta.
  
  No a todo el mundo le gusta estar cambiando continuamente de empresa, pero por otra parte esto te permite descubrir nuevas formas de trabajar, nuevas tecnologías, nuevas arquitecturas, trabajar en nuevos sectores en los que nunca habías trabajado, ampliar enormemente tu currículum, y por supuesto el hacer nuevos contactos y amistades.


• Impuestos: Volviendo a lo importante, y dependiendo de como te establezcas como contractor (autónomo, trabajar para una umbrella company, o tener tu propia empresa) pues podrás ahorrar más o menos en impuestos, pero por lo general ahorrarás más dinero que si fueras permanente. Lo normal es que recibas dietas por día trabajado, que recibas compensación por el gas, la electricidad o incluso el alquiler de tu casa que se considera como tu oficina, que puedas pasar gastos de cosas que necesites comprarte como ordenadores, libros, etc. Todo eso se aplica sobre tu sueldo antes de impuestos por lo que te saldrá mucho más barato de lo normal.
  
  Ojo aquí con las empresas paragüas que te ofrecen contratarte desde su sede en algún paraiso fiscal y que así obtendrás el 90% de tu sueldo bruto. Esto es totalmente cierto, pero son operativas que buscan agujeros en la ley, y te puede salir bien o te puede salir mal. A mi, por ejemplo, me ofrecieron establecerme en la Isla de Man y les dije que ni loco. Un ex-compañero mio sin embargo estaba con su empresa en la Isla de Man y tan contento, cuando lo volví a ver hace unos meses me contó que la "Hacienda" irlandesa le había ido detrás y que lo había pasado bastante mal, y que desde esas cambió la forma de contratar. Recordar que os digan lo que os digan, puede que su operativa sea legal, pero a efectos prácticos vosotros estáis evadiendo impuestos. Os puede salir bien, o mal.
  


• Horarios y horas extra: Un poco triste que sea así pero el horario y condiciones de trabajo de un contractor están claramante especificadas en su contrato. X euros al día o a la hora durante Y horas, y punto. Eso es lo que se trabaja y nada más. En caso de tener horas extras, pues tu contrato especificará (si no lo hace deberías mirarlo) el precio de la hora extra.
  
  Así que bueno, en el caso de un contractor no debería existir eso de trabajar doce horas y cobrar ocho, o pasarse los fines de semana porque corre prisa y no cobrar nada. En muchos casos ni te llaman para hacer fines de semana o ni consideran que te vayas a quedar. Y cuando no se cumple esto, pues en muchos casos al contractor le viene bien porque claro, es más dinero.



• Oportunidades: Esto viene un poco al hilo de la segunda razón expuesta anteriormente. Como consecuencia de la cantidad de contactos que haces, y de que la empresa te ve como otra empresa en lugar de como un empleado más, es posible que tengas nuevas ofertas laborales. Muchas veces es más sencillo por ejemplo el ir a trabajar desde casa ya que las empresas lo ven simplemente como una operación de offshoring.
  
  También, si eres bueno y tienes la suerte de estar en el sitio adecuado, pues puede que tengas la oportunidad de ampliar tu negocio. Quizás te pregunten si conoces más gente buena y puedas montar una pequeña empresa. Algo parecido he visto por ejemplo en una de las empresas donde he trabajado, donde dos de los contractors montaron una empresa y ahora tienen más de diez personas en Polonia desarrollando.
  
  Vamos, que es mucho más sencillo que aparezcan oportunidades cuando eres un proveedor de servicios más, que cuando eres un empleado más en la empresa. Con un contractor pueden tratar de igual a igual. Con un empleado hay que ser mucho más cuidadoso, ya que lo que hagan se comparará con el resto de empleados.

Y resumiendo estás serían mis cinco razones más importantes por las que en mi opinión vale la pena hacerse contractor. Pero no todo lo que reluce es oro, y en breve publicaré un post con cinco cosas malas de ser contractor. Y a partir de ahí, ya depende de cada uno. Hay gente a la que le gusta; hay gente a la que no; hay gente que simplemente piensa en eso como un período estacionario.

Sea lo que sea, si te animas a hacerte contractor, piensa que no tienes nada que perder y que como poco será una experiencia, ya que la forma de trabajar es totalmente diferente y se aprende muchísimo, para bien o para mal.

Imagen via Shmoomeema@Flickr.

UI: Convertir las cosas complejas en juegos de niños

El otro día leyendo alguna noticia en TechCrunch me encontré con eToro, y todo esto a cuento de que es una aplicación que ha conseguido levantar 6.3 millones de dólares, lo que no está nada mal en esta situación económica. eToro es una plataforma de trading para el mercado de divisas, pero su aproximación es radicalmente diferente a las de las aplicaciones tradicionales.

Habíendo trabajado más de un año en el desarrollo de una aplicación de trading para estos mercados, y habiendo estado relacionado con otras plataformas similares, lo que más me llamó la atención sin duda fue el interfaz de usuario. eToro hace sencillo el trading. Ridículamente sencillo, me atrevería a decir. Vamos que hasta un niño de cinco años podría entender lo que está haciendo.

Y es que la aplicación de escritorio de eToro (también tienen una web) parece un juego. Fijaros en el interfaz simplificado para la compra y venta de divisas, lo que ellos llaman Globe Trader.



O en sus charts simplificadas:



Está claro que tienen diseñadores y gente que ha de tener alguna experiencia en interfaces para juegos, porque es como si estuvieramos con cualquier simulador de negocios. Al mismo tiempo, el modo experto de la aplicación está ya mucho más orientado al profesional:



En serio, me ha parecido una estrategia super inteligente. El mercado de divisas es uno de los más peligrosos y es por ello que mucha gente no se atreve a invertir en el mismo. Si os pasáis por los blogs de traders españoles, veréis que casi todos se centran única y exclusivamente en los mercados de valores, y muy pocos se aventuran a comerciar con divisas. Esto es básicamente porque es un mercado que varia muy rápidamente, y aunque es muy sencillo ganar dinero, es muy fácil también el perderlo.

eToro ha creado un interfaz super-sencillo para atraer a más gente al mundo del Forex. Me pregunto si veremos más aplicaciones en el futuro que sigan esta estrategia de trasladar interfaces de usuario tradicionalmente serios al mundo de los juegos para intentar simplificar la experiencia de usuario.