Se ha terminado un ciclo

Ayer, se terminó un ciclo en mi vida. Se que lo tenía un poco callado, pero ahora que ya es oficial lo puedo desvelar. He dejado esto:



Que era mi empresa y paso a: ¡Tener mi propia empresa! Pues sí, menudo cambio. Me he aguantado para no decirlo pero desde hace unas semanas que se puede decir que soy empresario. La empresa está ya registrada en Irlanda, pero me perdonaréis que no desvele detalles todavía, hasta cerrar unos cuantos flecos que tengo abiertos.

La principal razón para crear una empresa es que cambio de modo de trabajo. Ahora paso a trabajar como IT Contractor, o vamos, lo que llamaríamos autónomo, o Freelance en España. Un aspecto peculiar de la industria irlandesa es que de unos pocos años hacia aquí, es bastante común el crear tu propia compañía para hacer este tipo de trabajos, especialmente si vas a pasar más de seis meses trabajando para la misma empresa, ya que bajo la ley irlandesa, un juez podría decidir que eres a todos los efectos empleado de dicha compañía, y esto potencialmente la expone a problemas jurídicos.

La razón secundaria, pero no por ello menos importante, es que tener mi propia empresa me permite abrir unas cuantas posibilidades en las que estoy trabajando. Una es jLibrary, con el que se podría abrir una línea de soporte, aunque esto es sólo especular; y otra es ... bueno, eso por ahora es secreto :-)

Pues eso, con un poquillo de suerte mi primer contrato se cerrará a la vuelta de unas mini vacaciones en España que empiezan hoy. Así que no tendréis noticias mías estos días, pero no os preocupéis que daré muchos más detalles en breve.

¡Nos vemos en unos días!

Y yo que creía que conocía todos los tratamientos

Pues como toda la vida, ¿no? Señor, señora, señorita, Mr., Ms., Miss., ...

Pues va a ser que no. Por aquí, al menos a la hora de buscar seguro de coche con Quinn Direct hay más formas de tratamiento:



Y es que aquí están en todo!

Ryanair da una lección de como no lanzar un sitio web

Hace unas semanas, Ryanair anunció que iba a actualizar su sitio web para introducir un nuevo sistema de reservas y adaptarlo a algunos requisitos de la regulación europea. Como consecuencia de dicha actualización, anunciaron que su sitio web no estaría disponible durante todo un fin de semana, desde las 10pm del 22 hasta las 11pm del 25, o sea antes de ayer.

La verdad es que en un momento en el que el downtime se cuenta en horas, resulta un poco rocambolesco que un sitio de la magnitud de Ryanair anuncie que todo su sistema de reservas via web y su sistema de reservas telefónicas no estará disponible durante 3 días. Este tipo de cosas son admisibles en negocios tradicionales de lunes a viernes y de 9 a 5, pero en Internet, donde cada minuto de downtime es dinero perdido, resulta un poco chocante.

Pues bien. Para compensar las molestias, a alguien de product management (perdón por la asunción, pero no creo que a los responsables técnicos se les haya ocurrido esto) se le ocurrió el poner 2 millones de asientos a 10 euros. La consecuencia es que el pasado Lunes había una horda de caza-gangas probando ya desde primeras horas de la madrugada a ver si el sitio web estaba disponible y se podían realizar las reservas.

¿Se os ocurre mejor cosa para estrenar un sitio web que darle la bienvenida con millones de visitas? El resultado es que hoy parece que todavía la web sigue sufriendo muchísimo para simplemente darte una tarifa para un vuelo. A mi me ha tardado unos 10 minutos en responder, y la mayoría de los usuarios ha reportado tiempos de respuesta similares, además de haber reportado otros errores como tarifas que se alteran con refrescos o emails de confirmación perdidos en el limbo.

Los medios de comunicación ya se han empezado a hacer eco de estos problemas. CNN comentaba sin más que el sitio web estaba sufriendo algunos glitches. Computerworld también señalaba que la compañía estaba teniendo problemas "debido a la fenomenal demanda". Ayer por la noche, Ryanair pidió paciencia a sus usuarios por la lentitud del sitio web, escudándose en que el sistema ha estado despachando unas 20.000 reservas a la hora (5/sec.).

Independent.ie ha filtrado que otro de los problemas ha sido que Ryanair ha realizado la migración simultánea del frontend y del backend, lo que habría contribuido a agravar todavía más la situación.

El resumen es que la mala planificación de la migración de Ryanair ha traido muchas malas noticias a la compañía. Primero la pérdida de ingresos durante todo un fin de semana de parón, después el estar varios días con continuas quejas de los usuarios y con un sistema realizando menos reservas de las que se esperan, y para poner la guinda que las consultoras financieras como Davy rebajen la valoración de tu compañía ya que las consecuencias de la migración puede que impidan a la compañía llegar a su objetivo anual de 100 millones de pasajeros.

Photo via Tom Raftery@flickr que por cierto es Irlandés y tiene un muy buen blog.

Arquitectos, desarrolladores y escoger la tecnología adecuada

Repasando los artículos que tenía pendientes de leer en InfoQ, me he encontrado con este: Ideal Architecture is not always about Ideal Technology or Techniques. En el, se referencia a un post de Phillip Calçado en el que reclama que los arquitectos no deben ser tan egoistas y han de tener en cuenta las habilidades del equipo de desarrollo a la hora de escoger la tecnología para una aplicación.

Pone un caso como ejemplo:

Imagine you join a team of long time VB6 programmers to develop a new website. No one has experience with Ruby on Rails although you know that is exactly the best tool for the job. The website must be delivered in a short time frame, no time for training. Would you go for the best technical choice?

El problema del artículo y de lo que ponen en InfoQ, en mi humilde opinión, es que la cuestión no es tan fácil. No es algo tan sencillo como se pinta en esta historia en la que el punto central son los desarrolladores. Hay muchos otros factores como el coste de desarrollo, el coste operacional, la disponibilidad de herramientas, todos los requisitos no funcionales del proyecto (léase escalabilidad, extensibilidad, fiabilidad, tolerancia a fallos, etc.), la disponibilidad de soporte comercial, la facilidad para obtener documentación y soluciones a problemas, o la esperanza de vida de la tecnología por citar algunos. No es algo tan sencillo como coger a tus desarrolladores y decirles: "Bueno chicos, necesitamos consenso. ¿Vosotros en qué queréis programar?"

Por poner un ejemplo muy sencillo, en el hilo de lo que propone, si tengo unos desarrolladores que dominan la tecnología X, de poco me va a valer esto, si dicha tecnología entra en End Of Life el año que viene. Si tengo escoger entre una tecnología X (e.g. VB6) que todos mis desarrolladores dominan, y una tecnología Y (e.g. Rails) que sé que aporta muchísimas más ventajas en cuanto a requisitos no funcionales, que promete un desarrollo mucho más rápido una vez superada la curva de aprendizaje, que tiene una comunidad vibrante, que hay montón de documentación que afronta problemas actuales, etc. Pues lo siento, yo escojo Y.

Por otra parte, la elección de una tecnología no debe ser algo que se base únicamente en los gustos del arquitecto de turno. Efectivamente, el equipo de desarrollo se debe tener muy en cuenta también en la elección. Las skills disponibles son muy importantes, y más importante aún es el saber aprovecharlas al máximo. Por eso una de las cosas importantes al contratar gente es conseguir crear un equipo multidisciplinar. A mi de nada me sirve tener a 10 expertos en VB6. Prefiero tener 2 expertos en VB6, 2 en bases de datos, 2 en Java, 2 en Python, y 2 en aplicaciones web. Pero como he comentado anteriormente, en mi opinión esto es uno de los factores de la ecuación.

Un equipo de desarrollo multidisciplinar es mucho más moldeable a los cambios. Y para bien o para mal (yo creo que para bien), nuestra profesión está condenada al cambio constante. Es nuestro sino. Las tecnologías aparecen y desaparecen cada vez más rápido y de nada sirve el decir, "no es que todos mis desarrolladores sólo dominan esta tecnología de hace diez años y entonces sólo podemos desarrollar en esto", porque eso es seguir un muy mal camino.

Pero por esto es importante el rodearse de un gran equipo. Si por el contrario de lo que disponemos es de un puñado de personas a las que no les interesa la tecnología si no más bien el marcharse a casa cada tarde a ver la televisión, o que simplemente quieren seguir trabajando en lo que han hecho siempre porque no les interesa aprender nada nuevo. Bien, fair enough, como se dice por aquí; pues en este caso habrá que ser realistas y probablemente un proyecto actual no se ajuste a las posibilidades de este equipo de desarrollo en concreto.

En lo que estoy de acuerdo completamente con él es en que no hay que escoger una tecnología simplemente porque sea nueva, o porque sea lo más cool del momento. Estas tecnologías, tienen su espacio dentro de una empresa también, pero yo siempre las dejaría para pruebas de concepto, que de ser exitosas podrían materializarse en proyectos reales.

Photo: rutty@flickr

Y más sobre software en España...

Sergio Montoro escribe en La Pastilla Roja:

Ahora pongámonos en la piel del capo di tutti capi en la típica empresa española que vende software. La empresa típicamente se fundó hace 10 ó 20 años, hallá por los 80 ó 90. Empezaron como distribuidores de máquinas registradoras y poco a poco empezaron a escribir también el ERP de la gran superficie a la que se las vendían. Con el paso del tiempo aprendieron a ganar contratos públicos, y, a día de hoy, la empresa cuenta entre 50 y 500 trabajadores distribuidos en varias decenas de "cuentas vaca" que proporcionan el 80% de la facturación. El capo va camino de los 50 años (o más) y lo que tiene en mente a esas alturas de su vida es cuánto dinero le darán el día que venda la empresa, cantidad que depende casi exclusivamente del tamaño del fondo de comercio. Los mandos intermedios son una bandada de barracudas sedientas de poder motivadas principalmente por la cilindrada del coche y los metros cuadrados de despacho que obtendrán el año próximo. En tal empresa ¿cómo va a prosperar ninguna iniciativa de software? Cuando a la jefatura le proponen invertir 500.000€ en fabricar un software es casi como si le propusieran si quiere tirar el dinero a un vertedero nuclear. La empresa vive de los CONTRATOS (con mayúsculas) vive del software que se sabe que se va a cobrar, el comercial va, presenta una oferta económica, se acepta, se ejecuta y el cliente paga, la empresa no vive de ideas pajareras ni se puede permitir despilfarrar en proyectos de dudoso retorno de inversión, y no van muy desencaminados...

En la línea del post en el que buscaba empresas de software. ¿Alguna mención en el debate electoral a crear una industria tecnológica competitiva? O tenemos que esperar otros cuatro años...

Microsoft aclara a algunos de sus empleados lo que pasará si compra Yahoo

Microsoft ha publicado un correo dirigido al personal de la Platform & Services Division en la que el presidente de esta división, Kevin Johnson, aclara que impacto tendría una posible compra de Yahoo!

El correo hace referencia a diferentes temas:

• ¿Cuáles son los beneficios de una combinación Microsoft-Yahoo!? Aunque no lo dice en ninguna de las tres razones que aporta (mejor R&D, estimular el mercado de la publicidad online, y ventajas para los accionistas) está bastante claro que el transfondo es competir con Google.
• ¿Habrá reducciones de plantilla? Sí, en ambos bandos.
• ¿Qué pasa con las culturas de ambas compañías? La idea será combinarlas y quedarse con lo mejor de cada una.
• ¿Qué pasará con las marcas y las tecnologías de cada compañía? La marca de Yahoo! se queda, ya que es una de las razones de la compra. Poco a poco se vería como se integra con las marcas de Microsoft.
• ¿Qué pasa con la infraestructura de Yahoo! basada en Linux? Se mantendría como está y se procedería a un plan de integración entre ambas plataformas. El correo deja la puerta abierta a la migración de estos servicios a Windows.
• ¿Se mantienen los centros de Silicon Valley y Redmond? Sí.
  

La verdad es que este tipo de notas te dan una idea de la magnitud de una hipotética unión como esta. La postura de Microsoft respecto a la infraestructura de Yahoo! es interesante, y como afirman en DataCenterKnowledge Microsoft se convertiría en uno de los mayores consumidores de software libre del mercado.

Ahora bien, queda la cuestión abierta de si este tipo de notas son simplemente para la galería y sosegar a empleados e inversores de ambas partes.

Aprovechar tus puntos flacos

A veces tienes una tara que te hace creer que no vas a poder hacer determinadas cosas tan bien como los demás...

A veces te ves inferior a gente que lleva haciendo cosas toda su vida y crees que no puedes competir con ellos...

A veces tienes una pequeña empresa y ves realmente imposible el poder competir con gigantes...

A veces hasta de los programas de televisión donde menos te lo esperas puedes aprender cosas:



PS. Es sólo un baile, hay videos de superación mucho más impactantes en YouTube, pero en este es realmente espectacular ver como una persona aprovecha su tara para realizar una actuación excepcional. Parece que en YouTube tiene más videos en otros lugares.

Yahoo! despliega en producción la mayor aplicación basada en Hadoop

Justamente hace un rato que Yahoo! ha anunciado el despliegue en producción de la aplicación más importante desarrollada con Hadoop hasta el momento.

Se trata de Yahoo! WebMap una aplicación que se ejecuta sobre un cluster Linux de más de 10.000 núcleos y que se utiliza desde ahora mismo en cualquier búsqueda que se haga en la web de Yahoo. Aquí está como lo describen en el blog:

The Webmap build starts with every Web page crawled by Yahoo! and produces a database of all known Web pages and sites on the internet and a vast array of data about every page and site. This derived data feeds the Machine Learned Ranking algorithms at the heart of Yahoo! Search.


Las estadísticas que proporcionan son de vértigo (traduzco):

• Número de links: un trillón, aproximádamente.
• Tamaño de la salida: 300 Tb, comprimidos.
• Número de núcleos utilizados para ejecutar ún único trabajo map-Reduce: sobre 10.000
• Espacio en disco utilizado en el cluster de producción: 5 Petabytes.

Mucha más información en la entrada en el blog de Yahoo!. Creo que nos ha quedado a todos definitivamente claro que Hadoop es apto para producción :-)

Sun se prepara para competir con Amazon

Leo en DataCenterKnowledge que Sun Microsystems va a presentar en la JavaOne de este año su proyecto Caroline, lo que parece ser una nueva línea de negocio orientada al cloud computing. El artículo de DCN enlaza a otro artículo en The Register con mucha más información.

Para propocionar la infraestructura que competirá con Amazon utilizarán la virtualización disponible por defecto en Solaris 10, junto con Solaris ZFS, lo que debería garantizar un rendimiento superior a los sistemas ofrecidos por Amazon, basados en Xen.

El hosting se haría en Sun pero también se insinua que los usuarios podrán alojar sus propios grids. El almacenamiento parece que podrá realizarse vía MySQL (especulo aquí que probablemente después de la compra este sería el sistema que soportarían comercialmente) , PostgreSQL o Apache Derby. La autenticación parece que sería vía liberty.

En este enlace hay una presentación de la JavaOne 2007 con más detalles sobre el proyecto Caroline.

Wow, esto realmente promete mucho. La verdad es que no deja de ser realmente paradójico que tenga que ser una compañía que empezó vendiendo libros la que esté guiando el camino de otras compañías que llevan sufriendo muchos años para tener beneficios económicos. ¿Habrá encontrado Sun por fin otro filón?

Escalabilidad y Ruby on Rails

En BuildingWebApps, un portal para desarrolladores de Ruby on Rails publican un artículo cuya lectura es realmente recomendable, incluso para cualquiera que no se dedique al mundillo de RoR.

El artículo analiza el porque las aplicaciones desarrolladas en Ruby on Rails pueden escalar tan bien como las desarrolladas en otros lenguajes más maduros. Lo hace desde un punto de vista muy racional, lejos del típico "panfleto" que busca simplemente provocar líos o llamar la atención.

Convention over configuration

Y para explicar por qué Rails puede escalar se centra en un problema que no es común sólo a Ruby on Rails, si no a cualquier framework web que se base en el paradigma de convención frente a configuración, ya sea Ruby on Rails, Groovy on Rails, Spring MVC, JBoss Seam, o cualquier otro.

Al favorecer la convención (es decir, el proporcionar valores por defecto) frente a la configuración (es decir, el tener que configurar todo antes de empezar) se está favoreciendo la creación rápida de aplicaciones. Ahora bien, mucha gente no se da cuenta de que estos valores por defecto no dejan de ser más que eso, una convención. Una convención que nos permite prototipar rápidamente nuestras aplicaciones.

Pero a la hora de la verdad, a la hora de escalar, no quedará más remedio que remangarse y empezar a analizar como son nuestras consultas a base de datos, como está siendo la reserva de memoria, que latencia están introduciendo las diferentes abstracciones, como de pesadas están resultando nuestras páginas, etc. Sin hacer todo esto, es difícil que Ruby on Rails, o cualquier otro framework, pueda escalar.

Utilizar más hardware para escalar

El artículo continua hablando sobre otro tema interesante que es que el overhead de Rails te puede obligar a utilizar más hardware, pero que esto no implica que el framework no pueda escalar horizontalmente. De hecho, escalará igual que cualquier otro framework y utilizando mecanismos muy similares (ej. memcached).

Aunque obviamente dependerá del tipo de proyecto, teniendo en cuenta el precio del hierro hoy en día, y la rapidez de desarrollo con RoR en muchos casos este coste adicional es más que asumible si el time to market va a ser mucho menor.

Aún así, me viene a la cabeza que este argumento le hace a uno preguntarse ¿por qué no utilizar entonces plataformas alternativas como grails o JRuby on Rails que corren en máquinas virtuales más maduras?

En fin, un artículo que me ha parecido realmente interesante, y que además presenta una serie de estadísticas e información sobre sitios web que están utilizando Ruby on Rails actualmente que también refuerza esa idea de que realmente RoR escala, pero que es cuestión de ir madurando la plataforma y que aparezcan más soluciones.

¿Qué te hace falta para ser el mejor programador del mundo?

Piensa en ti mismo, en como eres, en las cosas que haces, en como programas, en las herramientas que utilizas, y contesta a esta pregunta, ¿qué te hace falta para ser el mejor programador del mundo?

Es una buena pregunta, ¿verdad? Bueno, en realidad es la típica pregunta que se hace en las entrevistas. De este tipo de preguntas que no tiene una respuesta única pero que sirve para ver como el entrevistado reacciona y que camino coje para buscar la respuesta.

Y es que la definición de buen programador es tan ambigua. ¿Es mejor programador alguien que codifica muy rápido o quizás alguien que codifica mucho más lento pero lo que hace siempre funciona?, ¿Es mejor programador alguien que conoce muchísimas herramientas o quizás alguién muy especializado en un lenguaje o sistema concreto?, ¿Es mejor programador alguien que conoce muchísimos lenguajes o alguién que conoce uno sólo a la perfección? ¿Es un buen programador alguien que conoce muchísimos patrones, buenas prácticas y domina la ingeniería o alguién que no conoce nada de eso pero que tiene un instinto nato que hace que todo salga bien? ¿Es mejor programador alguien que trabaja en equipo o alguien que quiere hacer todo el sólo? ¿Es mejor programador alguien que es muy social o alguien que es muy arisco pero muy superior codificando?

Demasiadas preguntas abiertas para el especificar un buen programador. Me voy a permitir hacer un paralelismo para explicaros mi opinión. Personalmente, a mi, me gusta mucho jugar al fútbol. Hace muchos años, era un fenómenos físicamente, aunque está mal que yo lo diga :-) En fin, que aunque era un tirillas, aguantaba jugando al fútbol cinco horas seguidas si me ponías. Con los años, he ido perdiendo condición física. Es lo que tiene la mala vida. Pero lo cierto es que mi juego siempre fue mejorando a medida que ganas fuerza, potencia, pero sobre todo... experiencia. Lo malo es que llega un momento en el que te vas haciendo cada vez más mayor y echas en falta poder llegar a ese balón, poder adelantar a alguien en carrera con un autopase, o simplemente poder echar una carrera sin tener que parar cinco minutos a resoplar (que sería lo más aproximado a mi juego actual, y eso en caso de que realmente pudiese echar una carrera :D)

Con la programación me pasa un poco lo mismo. Hace diez años me atrevía con lo que fuese. Que si ensamblador, que si C, que si probar a crackear algo, que si hacer un motor 3D, que si una demo, que si esto, que si lo otro. Si había que estar días y días al ordenador escribiendo sin parar, no había problemas. Ahora mismo, bueno, cuando llevo más de una hora ya empiezo a flojear bastante. Sin embargo, creo que ahora soy mucho mejor programador que antes.

¿Sería el programador ideal alguién con la vitalidad de un chico de 18 años y la experiencia de un hombre de cincuenta? Es muy posible. Sin embargo es pedir un imposible.

De todos modos, con animo de contestar a la pregunta que planteaba anteriormente, sin un imposible, me vuelvo al mundillo del futbol. ¿Qué necesita un futbolista para ser el mejor futbolista del mundo? Pues probablemente jugar en el Madrid, o en el Barcelona, o en el Milán o, vamos, en cualquier equipo realmente famoso. Adicionalmente, necesitará un cierto grado de carisma para protagonizar muchos titulares, ser un goleador (pocos porteros y defensas han sido los mejores) y hacer muchas filigranas, aunque no terminen en gol.

Con la programación se podría hacer un simil que seguramente desembocaría en el mejor programador del mundo. No creo que haga falta que lo explique mucho, ¿verdad? Estar en Google/Microsoft/Oracle/Yahoo/..., anotarse los tantos de los programas famosos (aunque sean otros los que preparen las jugadas), aparecer en las revistas del sector, etc. En resumen, el mejor programador del mundo necesita estar en la mejor empresa del mundo.

Pero bueno, a los que nunca seremos el mejor programador del mundo, nos queda consolarnos con que todos los equipos, y todas las aficiones tienen su jugador preferido. Incluso, quien sabe, seguramente hay millones de jugadores de fútbol anónimos que son mucho mejores que Kaká, pero que simplemente no tienen la oportunidad ni el equipo para demostrarlo. Igual de cierto es que hay muchísimas super-estrellas que las mueves a un equipo mucho más modesto y son incapaces de jugar decentemente, o que hay estrellas de equipos modestos que las mueves a un gran equipo y se convierten en jugadores mediocres.

Y a vosotros, ¿qué os hace falta para ser el mejor jugador programador del mundo?

Frameworks que espolean y ceden el paso

Ojeando las noticias de InfoQ he visto una entrevista a los creadores de TestNG: Cedric Beust y Hani Suleiman.

TestNG es uno de esos frameworks que ha cumplido su cometido. Bueno, realmente no lo ha cumplido en el sentido estricto de la palabra ya que estoy seguro que sus desarrolladores lo crearon para hacerse con el mercado del unit testing. Pero sin embargo, ha cumplido su cometido en el sentido de que gracias a él ahora JUnit es mucho mejor.

Cuando se lanzó TestNG, JUnit había estado varios años sin ninguna actualización, y las carencias eran realmente importantes. No había soporte de anotaciones, no se podían ignorar tests, el soporte de excepciones era realmente precario, y bueno, vamos, que la cosa podía ser mucho mejor de lo que era realmente. TestNG tuvo un enorme impacto en su momento, y ofrecía la funcionalidad que muchos desarrolladores estaban esperando.

Incluso en el 2005 tuve la suerte de hacer una entrevista a Cedric Beust acerca de dicho framework (la entrevista estaba originalmente en javahispano, pero es una pena con el cambio de web parece que mucho del contenido antiguo ya no está disponible; por suerte todavía está disponible en agile-spain).

El caso es que desde el 2006 el desarrollo en JUnit se agilizó de nuevo y la cantidad de funcionalidades que han añadido ha mejorado el producto considerablemente. JUnit 4.0 añadió muchas funcionalidades interesantes pero con JUnit 4.4 realmente han dado el empujón que hacía falta en parte gracias a integrar muchas contribuciones como el mecanismo de aserciones o las Theories.

La verdad es que me resultó curiosísimo que los creadores de TestNG lanzasen un libro a finales del 2007 sobre un framework aparentemente abandonado con los foros ya llenos de spam. Supongo que sería algo que tenían abierto desde mucho antes y que han querido terminar por el honorcillo y supongo que por sacar algún dinero. De todos modos en la entrevista de InfoQ, cuando le preguntan directamente a Cedric sobre el futuro de TestNG, la verdad es que evade la respuesta.

¿Será porque considera haber fracasado? Si es así, pues personalmente creo que se equivoca. Para mi TestNG ha cumplido su cometido y ha tenido éxito. Es cierto que yo ahora mismo no se lo recomiendo a nadie, sin embargo está clarísimo que si no hubiese sido por TestNG, ahora a lo mejor seguiríamos haciendo chapuzillas con JUnit 3.x.

Y es que a veces es necesario tener frameworks que obliguen a los demás a ponerse las pilas.

Code reviews, ¿buena o mala idea?

Hace poco que en mi empresa un compañero se encargó de preparar un sistema de code reviews. Como era de esperar, ha sido algo bastante polémico dentro del seno de los desarrolladores. Esto me ha hecho pensar bastante sobre el tema.

Uno de los problemas más importantes de las empresas es controlar la calidad del código que se genera para satisfacer las necesidades funcionales. Esa es una de las razones por las que yo mismo recomendé el realizar revisiones de código. Innegablemente, las revisiones de código son necesarias. Uno puede argumentar que con realizar tests funcionales sería suficiente, pero lamentablemente que un código cumpla su cometido funcional no garantiza que cumpla su cometido no-funcional, es decir, no garantiza que sea escalable, mantenible, extensible, o incluso... legible.

Sin embargo, ¿hasta dónde se debe llegar con con las revisiones de código? Mi experiencia es que las revisiones de código demasiado estrictas pueden ser muy contraproducentes según como sea la estructura de desarrollo de una empresa. Es muy fácil que se vean como un "aquí vienen los arquitectos a hacer de policías y hacernos la vida mucho más difícil". Con las revisiones de código es muy, pero que muy fácil caer en el autoritarismo y afectar en la moral de los desarrolladores que verán limitada su capacidad de creación.

Algunos argumentarán que cortar la capacidad de creación de los programadores es algo bueno. Es la típica aproximación de factoría de software. Tener personas robotizadas programadas para hacer lo que se le ha dicho exactamente del modo que se le ha dicho. Bajo esta suposición, el establecer revisiones de código muy estrictas sería el mejor modo de garantizar la calidad. Seguramente lo sería, pero lamentablemente sería el peor modo de garantizar la continuidad del personal. Al cortar la creatividad, no sólo se le esta prohibiendo a los desarrolladores hacer lo que más les gusta, si no que además éstos perderán toda "enlace sentimental" con el código que han creado. No esperes que estos desarrolladores vuelvan atrás, o se queden un par de horas, o piensen en casa como mejorar un código que les han obligado a escribir.

El mejor sistema de code reviews será aquel que permita un equilibrio entre los deseos del arquitecto y las ambiciones del desarrollador. Hay una serie de puntos que pueden hacer llegar a este equilibrio:

• Utilizar herramientas de análisis estático de código: Herramientas como PMD o Findbugs ayudarán a encontrar errores de código básicos, sin tener que advertir a los programadores que han cometido errores. El estar continuamente advirtiendo peresonalmente a los desarrolladores de errores que han cometido es algo que puede ser incómodo, y en algunos casos causar problemas sociales ("ahí viene el listillo a decirme lo que ya sabía"). Para ello, nada mejor que introducir estas herramientas en la build y despreocuparse de los fallos triviales.
• Centrarse en los aspectos no funcionales: Las revisiones de código no deberían centrarse en si el código funciona, o no, ya que eso es algo que desvelarán los tests de integración.
• No olvidar el componente social de las revisiones: Este es un aspecto muy importante. Las revisiones no son un sistema para mostrar que el revisor sabe más, o tiene más autoridad que el revisado. Tampoco son un sistema para asegurarnos de que las cosas se han hecho como hemos ordenado. Es muy importante que las revisiones sean un mecanismo de aprendizaje mutuo. Si las cosas no se han hecho como se recomendaban, seguramente haya razones para ello, que en su caso pueden ser de peso; en caso contrario el revisor debe actuar como mentor y aconsejar, o incluso ayudar realizando pair programming si es necesario.
• Olvidar los aspectos superfluos: Muchas veces, las revisiones tienden a derivar hacia temas bastante superfluos como el "porque esta variable es protected en vez de privada", o "por qué este valor es estático", o "por qué utilizas un espaciado de 6 si nuestro estándar dice que hay que utilizar 4". La mayor parte de estas cosas son realmente superfluas. Algunas se detectan con análisis estático, otras se solucionan con un formateador de código, etc. El valor de las revisiones no reside en estas minucias, sino en detectar el impacto de los nuevos componentes en la arquitectura del sistema. ¿Es escalable? ¿Es fácilmente mantenible? ¿Lo podremos monitorizar? ¿Está haciendo auditoría? ¿Se ajusta a nuestro modelo de componentes? ¿Define interfaces como el resto de nuestros componentes? ¿Está haciendo buen uso de los frameworks? ¿Hay problemas de rendimiento, memory leaks, o faltas graves claramente visibles?
• Dar libertad al desarrollador: Al hilo del punto anterior, una vez revisados los aspectos no funcionales y el impacto en la arquitectura, sinceramente, queda poco por revisar. Darle libertad al desarrollador para que cree sus propios componentes es importante, incluso darle la libertad para mejorar sus creaciones (dentro de un órden) es muy valioso ya que crea vínculos morales entre el desarrollador y sus "criaturas". De hecho, es importante sentarse e interesarse por el cómo ha sido diseñado el componente, y realizar sugerencias en caso de que sea necesario. A fin de cuentas, ¡a los programadores nos encanta hablar de lo que programamos!

Resumiendo, code reviews si, pero con paciencia, calma, y desde un punto de vista didáctico. Todo el mundo puede aprender de las reviews, tanto revisores como revisados.

Rod Johnson se pasa por Dublin

Kainos, una consultora de por aquí, organiza un seminario gratuito el 11 de Marzo en el hotel Westin aquí en Dublin. El seminario es bastante temprano, de 07:30 a 10:00, pero será impartido por el mismo Rod Johnson, por lo que seguramente será interesante.

Podéis encontrar más información en su sitio web. El seminario, y el desayuno, son gratuitos.

Code reviews. La medida WTF.

Este es bueno...



Visto via OSNews Comics.

Las 7 adquisiciones más grandes en el mundo del Open Source

Muy interesante entrada en Pingdom (parece que estos chicos no dejan de sacar entradas interesantes) que analiza las siete compras más caras del mundo del Open Source (sin contar algunas de las que no se tienen números).

Sun compara MySQL por 1000 millones de dólares,2008.

RedHat compra Cygnus Solutions, una empresa de soporte para productos Open Source por 675 millones de euros, 1999.

Citrix compra XenSource por 500 millones de dólares, 2007

Yahoo compra Zimbra por 250 millones de dólares, 2007

Red Hat compra JBoss por 350 millones de dólares (barato creo), 2006

Novell compra SUSE por 210 millones de dólares, 2003

Nokia compra Trolltech por 153 millones de dólares, 2008

Exceptuando dos, todas las compras se han producido en los dos últimos años, lo que indica claramente que el valor del Open Source ha crecido enormemente. Esto que comento se viene a reflejar en un estudio del grupo 451 donde se ve que el número de compras ha pasado de 6 en el 2003 a 30 en el 2007.

Por último se preguntan, ¿quién será el siguiente? Esta pregunta es difícil porque cada vez quedan menos. Tenemos a Postgresql en las bases de datos, Spring en cuanto a desarrollo, G2One (groovy/grails) podría tener potencial de compra aunque por ahora poca cosa, Terracotta sería apetecible. Pero quizás si tuviese que apostar probablemente lo haría por producto más tipo Alfresco o Pentaho, o quizás a algo más bloggeril como Wordpress.

¿Vuestras apuestas?

por cierto, si alguien quiere pujar por jLibrary ya sabe ;)

Si Microsoft compra Yahoo... ¿qué pasa con los desarrolladores?

A estas alturas todo el mundo estará ya al corriente de la oferta de Microsoft por Yahoo. Hay tantos análisis por la red que simplemente marea. Casi todos se centran en el tema económico, el poder competir con Google, la importancia del negocio de la publicidad online, etc. Pero, ¿qué pasa con los desarrolladores?

La verdad es que desde el punto de vista de un trabajador en Yahoo, la cosa no pinta demasiado bien (salvo por las stock options que puedan tener, claro). Steven Ballmer es bastante explícito en su carta:

Operational efficiencies: Eliminating redundant infrastructure and duplicative operating costs will improve the financial performance of the combined entity.

Lo miremos como lo miremos, desde el punto de vista de los desarrolladores es terrible. Hay demasiados productos que chocan. Y estaría en el aire el saber que pasa con cada producto. Además, estamos en una operación que si ya de por sí es masiva desde el punto de vista monetario, no se queda atrás desde el punto de vista técnico. El choque de varios mundos que tradicionalmente han estado enfrentados: .NET vs PHP+Perl+Java. El choque de servicios que aunque a la vista del usuario de a pie son muy similares, lo cierto es que internamente son muy diferentes.

Y siendo francos, aunque en muchos análisis hablan de unir fuerzas entre servicios, yo no lo veo tan sencillo. Claro, a no ser que le llamemos "unir fuerzas" a migrar la tabla de usuarios de Microsoft Live a Flickr y después sus fotos, y cargarnos simplemente el motor imágenes de Live.

Otro de los temas interesantes sería la integración de sus servicios de computación. Ambas empresas tienen sus sistemas de computación distribuida. Yahoo con Hadoop basado en Java, y Microsoft con su Edge Computing Network basado en .NET y para el que está activamente reclutando por aquí en Dublin. En un principio parece que no hay problema por mantener las dos redes de computación funcionando en paralelo, y de hecho la ganancia de poder de computación que podrían tener los hipotéticos servicios que fuesen mezclados sería enorme. Ahora bien, ¿se puede permitir una compañía mantener dos redes de computación totalmente diferentes en paralelo?

Por último, ¿qué significaría esto para .NET? Porque inmediatamente después de la adquisición, la plantilla de Microsoft estaría plagada de perfiles Java (es lo que busca principalmente Yahoo en sus ofertas), perl, php, python, etc. Pero, poco hay de .NET en Yahoo. Al ser Yahoo los comprados, supongo que uno se podría esperar cualquier cosa, y los desarrolladores de Yahoo estarían siempre en la peor posición. Pero, en mi opinión la operación sería un fracaso total si, en lugar de integrar y adoptar la cultura de Yahoo en la compañía, intentan migrar todo a plataformas .NET. Ya no sólo por la complejidad sino porque la huida de desarrolladores sería enorme.

Así que en caso de que se produjese la hipotética fusión podríamos estar en vísperas de una nueva vuelta de tuerca en cuanto al mundo del desarrollo. Quizás hasta pudiesemos programar con Java en serio desde Visual Studio :)

¿Es EC2 la solución para los tests de carga?

Observando las noticias que se van sucediendo relacionadas con el mundo de los servidores, parece que una tendencia últimamente es el utilizar instancias grandes de Amazon EC2 para realizar los tests de stress.

Y es que la idea es realmente atractiva. ¿Para qué molestarse en comprar o alquilar servidores y generar miles de clientes simulados en los mismos si por un módico precio puedes aprovechar la estructura de Amazon para ello? Es más, si el proceso de test de stress se realiza, digamos una vez al mes, pues una razón más para llevarse ese servicio a EC2 ya que la facturación es por hora de uso.

Aunque esto parecería algo dirigido especialmente a startups, parece que en Oracle es lo que están haciendo para probar Coherence y también en Webtide para probar su servidor de aplicaciones Jetty.

Está claro que el concepto de cloud computing está cambiando poco a poco la forma de trabajar de las empresas. ¿Cuánto tardarán los grandes vendedores de hierro en ofrecer servicios similares? Porque Microsoft y Google tienen este sector en el punto de mira, y tarde o temprano la popularidad de estos servicios tiene que ir haciendo mella en la facturación de las compañías que nos venden servidores físicos. Seguramente tendremos que esperar un par de años para verlo.

(foto de midom@flickr)