Feeds:
Entradas
Comentarios

Archive for the ‘General’ Category

IronHack


Hace unos tres meses, en la fiesta final de la SpainJS conocí a Mauricio. Una persona muy entusiasta y con ganas de llevar a la realidad su último proyecto. Estuvimos hablando un rato y nos despedimos. Hace un par de semanas, ya desde Berlín, me sorprendió ver que este proyecto había pasado de sueño a realidad. Sí, me sorprendí, porque no es usual que los proyectos se transformen en realidades, y eso habla bien de Mauricio, y de su tesón trabajando.

Así que en este post voy a hablar de IronHack, ¿por qué? Ellos no me pagan un duro por este post, pero pienso que es una iniciativa muy interesante, en especial para la comunidad de jóvenes desarrolladores. De hecho yo mismo estuve a punto de involucrarme en un par de iniciativas similares que desgraciadamente no consiguieron despegar.

(Enrique, déjate de rollos y ve al grano, que luego la gente mira el scroll y huyen espantados)

¿Qué es IronHack? Es sencillo, es una escuela para nuevos programadores donde se enseña como hacer software en el mundo real. Imagínate, hace poco que has terminado la universidad o estas terminando. Ha sido duro, pero lo peor es que la mayoría de los conocimientos que te han enseñado son obsoletos. Tal vez sepa algo de JAVA y SQL, quizás teoría de compiladores e incluso C. Con suerte entenderás el modelo waterfall de desarrollo de software y si os han hablado de Scrum ya tendréis más suerte que yo. En mis tiempos me enseñaron el modelo COCOMO, y ¿quién se acuerda de eso? No se vosotros, pero a mi cuando me enseñaron OO me decían que era como un modelo entidad relación pero con herencia.

Sí, tal vez encontraras trabajo en una consultora “cárnica” con todo eso, pero no en una startup o en una empresa importante que se dedique a hacer software de verdad. Hay cosas realmente importante que desgraciadamente no se están enseñando en la universidad: como Ruby o JS, como TDD y BDD, los principios de “clean code” y SOLID, HTML y CSS, Git y GitHub y como poner una aplicación en producción en la nube. Si piensas que todo esto son “moderneces”, os recuerdo que a mi me preguntaron sobre todo esto de forma exhaustiva cuando me entrevistaron para eBay.

No sólo es el temario, sino el método didáctico y los profesores. No es lo mismo que te enseñen todo esto un teórico que no ha sacado a producción software en su vida, a que te lo enseñe un aguerrido veterano del mundo real.  Echad un vistazo al listado de personas involucradas en el proyecto. Y por supuesto, aprender haciendo. Se trata de aplicar los conceptos a un pequeño proyecto y ponerlo en producción.

Finalmente está la guinda, tal vez alguna de las empresas patrocinadores contrate a los mejores de la promoción. Las empresas no son tontas y saben que los medios tradicionales de reclutamiento sólo consiguen gastar dinero y reclutar no-talento.

Si alguno está buscando diferenciarse del resto de sus compañeros de promoción, o simplemente aprender cosas nuevas. Echadle un vistazo a IronHack, tal vez os interese.

Read Full Post »


Hola a todos, en este post no voy a explicar nada técnico, sino que voy a hacer publicidad de una iniciativa privada y capitalista: mis cursos de formación.  A partir de ahora, si veis un post de “Ganarse el pan” que sepáis que es un anuncio comercial.

Hasta ahora he estado haciendo formación, consultoría y mentoring para empresas. La verdad es que no me ha ido mal, pero siempre me quedó el gusanillo de abrir la formación a individuos particulares. Así que decidí organizar una serie de cursos  sobre JS. Tras unos iniciales intentos fallidos, ya por fin tenemos el primero: “JS Profesional”. El titulo, lo confieso, es un poco serio, y barajé algún título más escandaloso, pero al final lo he dejado en una cosa más neutral. Se trata de un curso orientado al típico desarrollador  que nunca ha trabajado en serio con JS, sino que sólo ha tenido un contacto superficial del lenguaje, como validación de formularios, efectitos con jQuery y un poquito de AJAX. La mayoría de los desarrolladores de “server side” están en esta tesitura. El objetivo del curso es dar un empujón a estos profesionales, para que JS deje de ser un lenguaje misterioso que falla incomprensiblemente. Son 10h de curso, pero van a ser muy intensas, y te van a dar la base para empezar a practicar JS a otro nivel. Eso sí, después hay que practicar en la vida diaria lo que se ha aprendido en el curso. Para más información sobre el curso visita aquí: https://eiar.stagehq.com/events/1683

Pero mis planes no pasan sólo por este curso, quiero crear una serie de cursos sobre temas avanzados: Node.js, REST con JS, integración continua con JS, etc.

Todos los cursos van a seguir el mismo formato: dos clases de 5h cada una. En principio vamos a hacerlo los viernes por la tarde y los sábados por la mañana. La idea es que sea un horario compatible con la gente que trabaja. Sin embargo, he recibido peticiones de poner cursos en otro horario, así que aquí os dejo una encuesta sobre el tema:

Si estas desempleado, no creo que te importe mucho el horario, pero en cada curso reservamos una plaza gratuita para desempleados. Con esto queremos unirnos a la iniciativa #DecisionesQueAyudan. Simplemente tienes que mandarnos tu CV, y justificante de estar desempleado, a nuestra cuenta de correo: info.eiar@gmail.com

Y finalmente os quiero comentar que no voy a estar dando estos cursos yo sólo: me he asociado con el amigo Israel Alcázar El mismo lo explica en su blog En principio Israel va a hacer un curso sobre Git (sistema de control de versiones que todo el mundo debería estar usando ya, excepto si está usando Mercurial o el magnífico PlasticSCM). Más información sobre este curso aquí. Lo interesante es que como estamos juntos en esto proponemos un descuento de 10 euros por curso si te apuntas a ambos cursos. Si te apuntas a un curso mío, recibirás por correo un cupón de 20 euros de descuento para el curso de Israel, y viceversa.

Para finalizar otra encuesta, esta vez sobre el tema precio:

Y por último agradecer a toda la gente que ha hecho retuits y ha recomendado el curso, con gente como vosotros todo es más sencillo.

Bueno, espero que esta iniciativa tenga éxito y podamos seguir dando muchos cursos!

Read Full Post »


Este post no es para tratar de convenceros de que os unais a las legiones de Javascript, sino para explicar mis razones para tomar ese camino de perdición. Antes que en javascript programé en tres o cuatro lenguajes, principalmente C y Java. Por supuesto en la universidad aprendí LISP, PROLOG, ADA, varios dialectos de ensamblador y alguna cosa más, pero como nos lo he vuelto a tocar desde entonces no los considero parte de mi “toolkit”.

Yo empecé en esto de Javascript como la mayoría de vosotros, haciendo unos scripts güarrotes para validaciones y efectillos, en los tiempos del año 2000. Era un mal necesario con el que tenía que convivir al desarrollar mis preciosas aplicaciones thin-client en Java. Sin embargo sobre 2005, empecé a querer usar servicios REST sin sesión por temas de rendimiento, lo que me hizo repensar la arquitectura de mis sistemas.  Fue entonces cuando descubrí AJAX, y me quede fascinado por las posibilidades. Desde entonces fue un camino sin retorno; cada vez que aprendía más, descubría nuevas tecnologías, y reflexionaba más sobre como diseñar mejor mis aplicaciones, más enganchado me quedaba con Javascript, y desde entonces hasta ahora.

Así que, ¿por qué Javascript?

Es ubíquo

Que yo sepa, es el lenguaje que en la actualidad está más extendido del mundo. Virtualmente en cada ordenador de cada casa se puede ejecutar una versión u otra de Javascript. ¿Qué ordenador no tiene un browser? ¿Al menos un IE6? Sí, algunas personas por motivos de accesibilidad o seguridad no lo tienen disponible, pero son una exigua minoría.

¿Y en servidor? Pues ya sabeis que tenéis el node.js, tenéis Rhino, etc. En concreto en node.js se está invirtiendo cantidades ingentes de dinero. Ya está soportado en algunas plataformas cloud, como Heroku/Cedar y Windows Azure.

¿Y en desktop? Pues desde hace tiempo existe la plataforma Mozilla, ¿en que creéis que se programa la mayor parte de Firefox y Thunderbird? En una mezcla de Javascript (y C para el bajo nivel). Además Windows 8 plantea usar a JavaScript como uno de los lenguajes de preferencia para hacer aplicaciones de escritorio (otorgándole el mismo rango que a C#).

El mismo lenguaje para cliente y servidor

A día de hoy Javascript es el único lenguaje en el que puedes desarrollar por completo una aplicación web de punta a punta, desde la UI hasta el acceso a BBDD. ¿Qué tiene esto de interesante?

  • No necesitas dominar más de un lenguaje para hacer la aplicación web. Esto te permite no estar cambiando de contexto entre un lenguaje y otro, o simplemente no necesitar dos equipos de desarrollo especializado (uno de front-end y otro de server-side). Además de aumentar tu productividad, puede facilitar tener un equipo de proyecto más cohesionado.
  • No necesitas recodificar la misma lógica tanto en Javascript como en el lenguaje que estés usando en tu server-side. ¿Modelos de negocio? ¿Validaciones? Todo eso es único y debería ser reutilizable tanto en tu front-end como en tu server-side. Si lo haces todo en Javascript, terminas teniendo un montón de código común en ambos lados, que antes tendrías que haber duplicado y mantenido en dos lenguajes diferentes. Eso sí, hay que diseñar tu arquitectura de la forma adecuada para que esto se pueda cumplir.
  • Estándares de codificación y criterios de calidad unificados para todas las capas de tu sistema.
¿No veis todo esto como una “killer feature” de Javascript? Yo personalmente el día que descubrí node.js, vi el cielo abierto, y me dije “esto es la caña”.

Tipado dinámico

Confieso que este punto es muy subjetivo. Ya sabeis que soy un fanático del TDD. Y si haces TDD como es debido, al final el compilador deja de ser tan valioso. Los errores de sintaxis o de tipos son muy sencillos de detectar y arreglar usando TDD, no necesitas un compilador para ello. En los lenguajes de tipado estático, el compilador detecta este tipo de errores, pero a cambio tienes que esperar a que éste se termine de ejecutar. Además normalmente tendrás que escribir más código, para añadir toda la información de tipado que el compilador necesita. Esto hace que el ciclo de TDD sea algo más lento que en un lenguaje de tipado dinámico. Ya que TDD me va a detectar esos errores de todas formas, no me resulta rentable el “trade-off” propuesto por el compilador.

Dicho esto, si no hacéis TDD, mucho cuidado con Javascript, puede ser un buen dolor de muelas de depurar, e incluso pequeños fallos de sintaxis te pueden llevar por el camino de la amargura. Para mi lo ideal del TDD es no tener que depurar, o si lo tengo que hacer, que sea sobre 4 o 5 líneas de código bien identificadas, y que están siendo ejercitadas por un test predecible. Desde este punto de vista Javascript no plantea ningún problema.

Paradigma mixto

Es un lenguaje que te permite hacer OO hasta de dos formas diferentes, con “extends” y sin “extends”. Pero es que además también puedes hacer programación funcional con él. Esto te permite elegir el paradigma de programación que mejor se adapte al problema a resolver.

¿Tratamiento de colecciones? ¿Cálculos puros (validaciones, reglas de negocio)? ¿Programación asíncrona? Mejor el paradigma funcional

¿Modelado de negocio? ¿DDD? Mejor OO

Y por supuesto en una aplicación de verdad vas a tener que usar ambos paradigmas, y mezclarlos armoniosamente. Incluso a veces los puedes mezclar de tal forma que llegan a ser difícil de distinguir uno de otro.

Flexible

Es un lenguaje ideal para hacer DSLs internos, gracias a su gran flexibilidad. Puedes añadir y eliminar funciones al vuelo tanto en una instancia como un constructor. Esto no sólo te permite crear DSLs sino añadir nuevas capacidades al lenguaje, y realizar metaprogramación (aunque en Ruby y Groovy se puede llegar incluso más lejos).

Reconozco que esto puede ser una fuente de problemas, y es mejor evitar este tipo de funcionalidades. Por ello las últimas versiones de Javascript te permiten cerrar total o parcialmente un objeto, para evitar que se puede modificar en tiempo de ejecución. Sin embargo en algunos casos está justificado hacer este tipo de cosas. Aparte de los DSLs y quizás algunos ejemplos de metaprogración, el caso más importante es el de retrocompatibilidad. ¿Qué ocurre si estoy ejecutándome en una máquina virtual de Javascript que no soporta la API de colecciones de la última versión de Javascript? ¿Y si estoy en un navegador que no soporta alguna API de HTML5? ¡No hay problema! Con Javascript puedo detectar tal eventualidad y añadir la API que me falta de forma dinámica. Este tipo de capacidad ha permitido a Javascript sobrevivir en el infierno de incompatibilidades de los distintos browser por más de 10 años.

¿Y los WTF?

Sí, Javascript tiene algunos WTF. Sólo es cuestión de comprenderlos y saber que están ahí. Por ejemplo, los ámbitos de visibilidad no se señalan con ‘{‘ y ‘}’. En Javascript las llaves son prácticamente cosméticas y sólo sirven para agrupar el cuerpo de bucles y condicionales. Otra tema es el hoisting de variables, o el hecho de que en Javascript no existan los números enteros sino que sean todos en coma flotante. Personalmente el WTF que más me molesta es que Javascript tiende a ser “listillo”. Esto significa que intenta no fallar nunca con excepción. De ahí el horroroso e infernal sistema de coerción de tipos o el abuso de null y NaN en mucha de las librerías del lenguaje. En esto sí es verdad que se sufre.

Sin embargo los WTF de Javascript no son tantos ni tan difíciles de aprender como la gente piensa. La mala fama de Javascript viene por causas totalmente ajenas al lenguaje, los WTF de los navegadores. Tradicionalmente la implementación de los navegadores de los estándares de manipulación de HTML y de los servicios estandarizados por W3C ha sido defectuosa. Eso ha causado multitud de quebraderos de cabeza a los desarrolladores. Realmente, en la mayor parte de los casos, cuando un desarrollador piensa en las heridas recibidas en acto de servicio por parte de Javascript, normalmente debería achacarle la culpa al navegador. Desgraciadamente hasta hace poco navegador y lenguaje han estado mezclados en las mentes de los desarrolladores.

El pero

No todo es bonito en el lenguaje. Hay varios problemas con Javascript. El primero, y más importante, son los WTF arriba mencionados. El segundo es la sintaxis tan fea que tiene. La verdad de que con esto de querer simular ser C o Java la pifiaron bien. Espero que en siguientes versiones del lenguaje arreglen todo esto. Si no de momento podemos usar “strict mode”; para desactivar la mayor parte de los WTF, o usar CoffeeScript. El caso de CoffeeScript es curioso, si sabes Javascript entonces CoffeeScript te parece un simple dialecto de Javascript. Si no conoces Javascript, te parecerá un lenguaje totalmente diferente. El caso es que CoffeeScript soluciona la mayor parte de los WTF de Javascript, y tiene una sintaxis mucho más elegante. Lo tengo en el punto de mira a ver como se desarrolla.

Estos son los problemas que reconozco con el lenguaje. Después hay problemas humanos. Ese programador de Java que intenta programar en Javascript como si fuera un hermano retardado de Java (me incluyo en los culpables). Claro, intentas que una manzana se parezca a un plátano, y después vas echando pestes de lo feas que son las manzanas. No critiquemos el lenguaje sólo porque tengamos un conocimiento superficial de este, y al intentar programar como lo hacemos en nuestro lenguaje server-side, las cosas no nos salgan bien. ¡Es como si yo ahora digo que Clojure es una mierda porque no me termino de acostumbrar a su sintaxis y no puedo hacer una asignación de variable de forma sencilla! (no sería mal post :-D )

También hay que reconocer que no es un lenguaje sencillo de aprender. Primero tienes que aprender los WTF, para desarrollar instintivamente buenas prácticas que los eviten. Después tienes que ser capaz de dominar dos paradigmas de programación distintos, OO y funcional. Sólo así conseguirás sacarle toda la potencia a Javascript.

Conclusión

Desde mi punto de vista a día de hoy Javascript es el lenguaje más adecuado para desarrollar aplicaciones web. El problema es que no tiene competencia, ¿qué otro lenguaje tiene unas características similares a las anteriormente mencionadas? Yo no conozco ninguno. Ciertamente Ruby es bastante elegante, y me gusta bastante, ¡ pero sólo se ejecuta en servidor ! Java no está envejeciendo nada bien, y aunque C# es más avanzado está mucho menos extendido y tampoco se ejecute en servidor. Lo mismo puede decirse de Clojure, Scala o Groovy. Sí, podemos hacer como GWT o ClojureScript y compilar estos lenguajes en Javascript, pero, ¿con qué fin? La experiencia GWT ha resultado fallida.

En cualquier caso, a día de hoy, programes en el lenguaje que programes, si quieres hacer aplicaciones web modernas, te toparás con Javascript. Así que es mejor aprenderlo y dominarlo.

Tal vez en el futuro salga un nuevo lenguaje, con más ventajas que Javascript para hacer aplicaciones web. En ese momento tiraré Javascript a la basura y me pondré con el nuevo lenguaje, pero me temo que aun quedan 10 años para eso.

¡Espero que os hayan sentado bien las torrijas de Semana Santa!

Read Full Post »

Mi experiencia codemotion


Este es un pequeño post que tiene doble objetivo, por un lado quiero contar un poco como fue mi día de codemotion y las charlas a las que fui, por otro lado quiero aclarar algunos aspectos de la charla que di. Empecemos por lo primero.

Las charlas a las que yo asistí

La primera charla que vi fue sobre crear aplicaciones nativas en Widows 8 con Javascript, de Boris Armenta (@borisarm). La verdad es que la charla estuvo interesante, y Boris habló justo sobre lo que decía el título de su charla. Empezó con una pequeña introducción sobre la nueva plataforma de desarrollo de Windows 8, y después hizo una demo. La verdad es que tenía mucha curiosidad por ver como lo habían montado los señores de Microsoft para poder desarrollar aplicaciones nativas con JavaScript. Por lo que Boris contó no se lo han montado mal. Por un lado han orientado las APIs de desarrollo al paradigma de aplicaciones táctiles y no de ratón. En el caso de que el dispositivo no sea táctil, Windows 8 adaptará nuestra aplicación al ratón y teclado de forma transparente al programador. Por otro lado han cogido la máquina virtual de JavaScript de IE9, llamada “Chakra”, y la han extraído del browser para que podamos ejecutar aplicaciones javascript de escritorio en modo nativo, totalmente separado del browser. Ahora con JavaScript puedes acceder a la API del sistema operativo de forma directa y no estás restringido por el sandbox del browser. ¿Y como pintas las UI? ¡Pués con HTML5 y CSS! Windows 8 te proporciona una sintaxis de microdata para marcar el HTML y hacer bindings de este con tu librería de widgets en javascript. Eso sí, Boris se cuidó mucho de decir que esos bindings sólo funcionan para aplicaciones nativas, que nos olvidáramos de usarlos en IE. Sabia decisión para evitar problemas con los estándares. Parece que Microsoft está aprendiendo. Una apreciación personal (Boris nunca dijo nada parecido), me da la impresión que el tema silverlight y XAML ha quedado en segundo plano, como si Microsoft se estuviera preparando para marcarlo como obsoleto. Inquietante y esperanzador a la vez.

Curiosamente, por la tarde me metí en otra charla de .NET, se trataba de las extensiones reactivas de .NET, presentado por Fernando Escolar (@fernandoescolar) y Quique Martínez (@quiqu3). La verdad es que se lo montaron bien, con una dinámica de presentador “gerente” vs. “técnico” divertida. El tema fue las nueva extensión de .NET para programación reactiva, que no es más que un DSL para manejar relaciones observador/observer y bindings de forma  sencilla y elegante, mediante una fluent API. Me resultó también curioso que la misma extensión estuviera portada a Javascript. ¿Será Javascript el próximo lenguaje de referencia para .NET? No lo se, pero apunta maneras. En cualquier caso técnicamente no me pareció nada nuevo, ya que se parece mucho a las cosas que se pueden hacer con ember.js o con knockout.js.

Antes del café de la mañana me fui a ver a Arun Gupta hablar sobre el futuro de JEE 7. Me salió la vena nostálgica de “javero empresarial” que tengo, y se me antojó ver si la JEE evolucionaba por buen camino. Me alegré ver que están pensando orientar JEE al mundo del cloud. No sólo eso sino que percibí un esfuerzo serio por facilitar la vida tanto al desarrollador como al personal de sistemas. Creo que están intentando reaccionar para eliminar esa fama que tiene JEE como plataforma excesivamente compleja. También me gustó la idea de integrar OSGi dentro de JEE mediante el proyecto Jigsaw.

Después de la comida me divertí mucho con la charla de Berto Yáñez (@bertez) sobre Popcorn.js, un framework de la comunidad Mozilla para mejorar y ampliar la interacción de Javascript con las etiquetas <video> y <audio> de HTML5. Ambiente distendido, risas y código en directo. Sin duda de lo mejor del día.

Finalmente, como no, saqué el machete y conseguí abrirme paso para conseguir un asiento en la charla de David Bonilla (@david_bonilla). Hizo publicidad de Atlassian de forma muy elegante y para nada encubierta, e hizo alguna que otra crítica constructiva a varias empresas y a algunas actitudes que tenemos los desarrolladores. Por supuesto el tema era interesante de por si, y algo que a mi personalmente me interesa bastante: como atraer a los desarrolladores a tu plataforma/producto para crear un ecosistemas de desarrollo. Conseguir esto es el santo grial, ya que te proporciona una base de desarrolladores enorme que va a extender y enriquecer tu producto de forma totalmente gratuita. En contrapartida los desarrolladores tienen la oportunidad de ganar dinero y/o hacerse una reputación o simplemente divertirse. Quizás el único fallo de la charla de David fue su excesiva duración, ¡ que ya era última hora y estábamos todo deseando ir a unas cañas :-) !

Me gustó

Un acierto desde mi punto de vista el reunir a comunidades de distintas plataformas de desarrollo, PHP, Ruby, Python, JavaScript, Java y .NET, y también alguna charla de DevOps y de Agile. La variedad es lo que ha distinguido a esta conferencia de otras. ¡Espero que se rompan las barreras endogámicas que separan a cada comunidad de desarrollo!

Por supuesto me gustó bastante el ambiente, el ver estudiantes siempre es bueno desde mi punto de vista. Es importante que las nuevas generaciones vayan viendo lo que se cuece en el mundo real, ya que desgraciadamente la carrera universitaria suele estar muy alejada de la realidad y anticuada en la mayor parte de los casos (con honrosas excepciones). También es interesante que vean que existen conferencias sobre informática en España, y que no tienen porque irse al extranjero para asistir a una conferencia interesante.

También me pareció un buen detalle el cocktail que los organizadores ofrecieron a los ponentes.

Y como no, lo mejor, que como en todas las conferencias, fue la oportunidad de hacer networking con gente nueva por un lado, y reencontrarse con viejos compañeros de viaje.

Cosas a mejorar

Tal vez el próximo año sería mejor que todos los ponentes comieran junto a los asistentes. Con el cocktail es más que suficiente.

Otro detalle fue que hubo demasiada gente. Esto hizo que todas las salas estuvieran muy llenas y que en algunos casos se estuviera bastante incómodo.

UPDATE: Se me olvidaba, hubiera sido muy interesante tener “stands” para las distintas comunidades de desarrolladores que han participado en el evento. Los asistentes podrían haber trabado mejor contacto con otras comunidades de esta manera. Como co-organizador de MadridJS, creo que para el año que viene sería muy interesante tener esto.

Sobre mi charla

Tengo que comentar un par de cosas sobre mi charla. Tal vez algunos asistentes se pensaron que iba a hablar más de CSS orientado a objetos. En realidad esta charla es la hermana de otra que di en la XPWeek el año pasado. Para mi las dos charlas constituyen dos caras de la misma moneda, en una me centro más en CSS y en otra exploro más el diseño javascript. Lamento la posible confusión que pueda haber causado el título y la descripción de mi charla (que es responsabilidad mía no de la organización).

En mi charla sobre CSS orientado a objetos que di el año pasado me centré sobre todo en la parte de CSS, y solo hablé de pasada sobre la arquitectura javascript, y está más orientada a diseñadores. Para los realmente interesados, y la gente que se quedó con ganas de saber más de OO CSS, pueden encontrarla aquí.

Sin embargo en la charla que di en codemotion me quise centrar en los valores “ágiles” y en la arquitectura de software para aplicaciones javascript, como medio para facilitar la colaboración eficaz entre desarrolladores y diseñadores. Obviamente está más orientada a desarrolladores. Esta última está colgada aquí. La he hecho con impress.js así que necesitaréis un navegador “moderno” que soporte HTML5 para verla. Por cierto, mi idea era ver bastante código, pero no me fijé en que las charlas eran de 45min y la cosa quedó bastante corta en ese aspecto. Afortunadamente todo el código está disponible para que lo miréis en Github aquí.

En cualquier caso creo que ambas charlas pueden ser interesantes para ambos roles, y quizás ayuden a entender un poco más lo que implica el trabajo de uno y otro.

Read Full Post »


Hola de nuevo, como vimos en el anterior post la herencia de implementación puede ser un verdadero problema. Sí, es verdad, existen técnicas para diseñar nuestras clases para que puedan ser reutilizadas mediante herencia. Notad la cosa tan fea que acabo de decir. Si quiero que mi clase sea reutilizada, tengo que diseñarla de antemano, es decir, no importa para nada la interfaz de la clase, ni los tests que tenga sobre esta, ni la especificación del contrato. Si quiero reutilizar utilizando “extends” tengo que saber como está implementada la clase internamente, incluyendo todas las cosas “private” que tenga por dentro. A algunos les parecerá de lo más normal, a mi me da que pensar, ¿y entonces, para que leches sirve la encapsulación?

En cualquier caso voy a profundizar un poco en como hacer las cosas “bien” con la herencia de implementación, para ver las limitaciones de la técnica, y para ver si me quito el San Benito de programador petardo.

Tras reflexionar sobre el problema de mantenibilidad que tienen con la clase “Lista”, el equipo decide contratar a un consultor externo, y tras convencer a la mesa de compras de que paguen la estratosférica tarifa de 45 euros/hora, consiguen contratar a uno de los más reputados expertos locales. Haciendo honor a sus honorarios, el experto diagnostica y resuelve el problema en un santiamén (lástima que cobre jornada o fracción). “Pero señor@s”, dice el experto, “¿es que nunca habéis leído el GoF?”, continua, “aquí os pongo un patrón Template Method que os vais a chupar los dedos”. Ni corto ni perezoso modifica el código, y ListaSencilla le queda así.

public class ListaSencilla implements Lista {
  private List datos = new ArrayList();
  public ListaSencilla() {
    super();
  }
  @Override
  final public void insertar(String elemento) {
    datos.add(elemento);
    procesamientoAdicionalTrasInsertarElemento(elemento);
  }
  @Override
  final public void insertarVarios(Collection elementos) {
    for (String elemento : elementos)
      insertar(elemento);
  }
  /**
   * Este método es invocado cada vez que un nuevo elemento
   * es insertado en la Lista
   * @param elemento El elemento que acaba de ser insertado
   */
  protected void procesamientoAdicionalTrasInsertarElemento(String elemento)
  {
    // Intencionadamente en blanco, es un "hook" para sobreescribir
  }
  @Override
  public String describirContenido() {
    StringBuilder descripcion = new StringBuilder("Contenidos: ");
    for (String elemento : datos) {
      descripcion.append("'");
      descripcion.append(elemento);
      descripcion.append("' ");
    }
    return descripcion.toString();
  }
}

Nótese el uso de la palabra clave “final”. Esta palabra clave se puede poner a nivel de método, o mejor, a nivel de clase, indicando que no se puede sobrescribir el método o hacer extends de la clase. La palabra clave “final” es un gran invento de JAVA, pero claro,  hay que leer entre líneas: un lenguaje que tiene herencia de implementación, pero que además tiene una palabra clave que prohíbe la herencia, muy sospechoso. En realidad los diseñadores de JAVA sabían muy bien que la reutilización de código mediante herencia de implementación es peligrosa. Conscientes de ellos, añadieron “final”, para dar la capacidad al desarrollador de marcar una clase o método con “¡Peligro, no heredar o sobrescribir!”, en el caso de que no hubieran diseñado de antemano la clase para herencia. Desgraciadamente no he visto que mucha gente use “final”.

Siguiendo con la historia, al usar “final” y “Template Method” en conjunción con el método protegido “procesamientoAdicionalTrasInsertarElemento”, se desactiva cualquier problema. Por un lado no podemos sobrescribir los métodos peligrosos, ya que son “final”. Por otro lado el implementador de la clase diseña su código de tal forma que si quiero reutilizar la clase, no lo pueda hacer de cualquier forma, sino sólo sobrescribiendo el método protegido a tal fin. Con este cambio, la clase “ListaAuditable” queda como sigue:

public class ListaAuditable extends ListaSencilla {
  private Auditor auditor;
  public ListaAuditable(Auditor auditor) {
    super();
    this.auditor = auditor;
  }
  @Override
  protected void procesamientoAdicionalTrasInsertarElemento(String elemento)
  {
    auditor.elementoInsertado(elemento);
  }
}

Da la impresión de ser un código bastante elegante. Desde luego ha merecido la pena pagar la exorbitante tarifa del consultor externo. Sólo hay un problema pequeñito, el test de “ListaSencilla” se ha complicado. Claro, ahora no sólo hay que testear el contrato “Lista” en “ListaSencilla”, que es el que define como se usa la clase por parte de los consumidores de esta. Ahora hay otro contrato, representado por el método protegido, entre “ListaSencilla” y todas las clases que la extiendan. Este contrato es “en negro”, ya que no es público, sino “protegido”. Necesitamos un test que pruebe que el método protegido es llamado en los momentos adecuados y con los parámetros adecuados. Pero este contrato no está en una interfaz de un colaborador, sino en un método “protected”, ¿cómo hacemos el test? Afortunadamente con un poco de programación “clever” se puede terminar haciendo testing de esto. Lo dejo como ejercicio al lector.

Otro pequeñito problema es que alguien siga pensando que no tiene por que entender la implementación de la superclase, que le vale sólo entendiendo el contrato público (pobrecito), y al heredar haga cosas como esta:

public class ListaAuditablePetarda extends ListaSencilla {
  private Auditor auditor;
  public ListaAuditablePetarda(Auditor auditor) {
    super();
    this.auditor = auditor;
  }
  @Override
  protected void procesamientoAdicionalTrasInsertarElemento(String elemento)
  {
    super.insertar(elemento); // Ouch !!!
    auditor.elementoInsertado(elemento);
  }
}

¡ Ay, que cosa más fea ! ¿Es que nadie se lee el Javadoc? Obviamente nadie debería usar super para llamar a un método peligroso (final), sólo sobrescribir métodos protegidos o métodos públicos no peligrosos (no final). Bueno, a parte de estos problemitas subsanables con un poco de “hacking”, y despedir al inútil que cometió la anterior tropelía, parece que la técnica funciona.

Pasa el tiempo y aparece otro problema con este enfoque. ¿Qué ocurre si queremos hacer la extensión de una clase de una forma no prevista de antemano? No puedes. Tienes que volver a modificar la clase padre para añadir extensibilidad en el nuevo “eje” que te haga falta. Por supuesto en cualquier desarrollo serio, ha habido una extensa e intensiva fase de análisis funcional y diseño técnico, y esas cosas no pueden pasar, ya que se han cubierto todos los posibles cambios. Desgraciadamente nuestros amigos no son tan profesionales y usan una cosa llamada “agile” que les impide hacer un buen análisis y diseño “up-front” como dios manda, y no tienen muy claro las necesidades de diseño futuro de su sistema.

Nuestros sufridos desarrolladores se encuentran con un nuevo requisito, ahora resulta que algunas especializaciones de “ListaSencilla” pueden rechazar un elemento, y negarse a insertarlo si cumple alguna característica concreta. Desgraciadamente en las clases hijas de “ListaSencilla” no pueden añadir esta funcionalidad, deben abrir su implementación, y siguiendo “Template Method” añadir un punto de extensión más.

public class ListaSencilla implements Lista {
  private List datos = new ArrayList();
  public ListaSencilla() {
    super();
  }
  @Override
  final public void insertar(String elemento) {
    if (!esInsertable(elemento))
      throw new ElementoRechazadoError(elemento);
    datos.add(elemento);
    procesamientoAdicionalTrasInsertarElemento(elemento);
  }
  @Override
  final public void insertarVarios(Collection elementos) {
    for (String elemento : elementos) {
      if (!esInsertable(elemento))
        throw new ElementoRechazadoError(elemento);
    }
    for (String elemento : elementos)
      insertar(elemento);
  }
  /**
   * Este método es invocado para pedir permiso sobre si un elemento
   * puede ser insertado o no
   *
   * @param elemento
   *        El elemento que queremos insertar
   * @return si se puede insertar o no
   */
  protected boolean esInsertable(String elemento) {
    return true;
  }
  /**
   * Este método es invocado cada vez que un nuevo elemento
   * es insertado en la Lista
   *
   * @param elemento
   *        El elemento que acaba de ser insertado
   */
  protected void procesamientoAdicionalTrasInsertarElemento(String elemento)
  {
    // Intencionadamente en blanco
  }
  @Override
  public String describirContenido() {
    StringBuilder descripcion = new StringBuilder("Contenidos: ");
    for (String elemento : datos) {
      descripcion.append("'");
      descripcion.append(elemento);
      descripcion.append("' ");
    }
    return descripcion.toString();
  }
}

Bueno, no duele tanto, al fin y al cabo el código parece razonablemente limpio y “ListaAuditable” ni se ha enterado. Ahora implementamos el requisito, realmente ocurre que pueden existir tres tipos de listas auditables, aquellas que no admiten elementos que contengan espacios y aquellas que sólo admiten elementos de longitud par. Bueno, a implementar. La cosa queda como sigue:

public class ListaAuditableConElementosSinEspacios extends ListaAuditable {
  public ListaAuditableConElementosSinEspacios(Auditor auditor) {
    super(auditor);
  }
  @Override
  protected boolean esInsertable(String elemento) {
    return !elemento.contains(" ");
  }
}

Y también:

public class ListaAuditableConElementosLongitudPar extends ListaAuditable {
  public ListaAuditableConElementosLongitudPar(Auditor auditor) {
    super(auditor);
  }
  @Override
  protected boolean esInsertable(String elemento) {
    return elemento.length() % 2 == 0;
  }
}

Ok, no esta nada mal, casi podemos cantar victoria, ¡además hemos reutilizado “ListaAuditable”!

Pasa el tiempo, y con él llegan cambios, e inevitablemente nos llega otro requisito. Resulta que las listas que no son auditables también pueden existir en la forma de listas que no admiten elementos con espacios, y las que sólo admiten elementos de longitud par ¡Qué dura es la vida del desarrollador! De nuevo al código, queda lo que sigue:

public class ListaConElementosSinEspacios extends ListaSencilla {
  public ListaConElementosSinEspacios() {
    super();
  }
  @Override
  protected boolean esInsertable(String elemento) {
    return !elemento.contains(" ");
  }
}

Y también:

public class ListaConElementosLongitudPar extends ListaSencilla {
  public ListaConElementosLongitudPar() {
    super();
  }
  @Override
  protected boolean esInsertable(String elemento) {
    return elemento.length() % 2 == 0;
  }
}

¡Han aparecido otras dos clases! ¡Ya tenemos 6 implementaciones de “Lista”! Bueno, al menos son cortitas y sencillas, y estamos reutilizando un montón. El problema es que estamos a empezar a detectar un tufillo a violación del DRY. De hecho es la misma implementación de antes pero heredando de “ListaSencilla” en vez de “ListaAuditable” ¿Quién dijo que el copy&paste era malo? Quizás si en vez de usar “extends” usáramos otra cosa… nada, todo el mundo sabe que la herencia es “esencial” a la OO, su “killer feature”, mejor seguimos con el “Template Method”, y no liamos más la cosa.

Seis meses más tarde tenemos 60 clases “Lista”. Resultó que salieron cinco formas más de filtrar los elementos de las listas, y encima además de listas “auditables” y “sencillas”, tenemos listas “lazy”, listas “persistentes”, etc. En fin, que necesitamos una clase por cada combinación posible. La verdad es que esto ya no parece tan limpio.

Una última reflexión. Para el que sea propenso a pensar en cosas inútiles, aquí lanzo una pregunta, ¿cómo es mejor implementar ListaAuditableConElementosLongitudPar? ¿Heredando de ListaConElementosLongitudPar o heredando de ListaAuditable? ¿Da igual? Y en caso de que sea igual, ¿no parece un accidente histórico el decidir implementarla de una forma y no de otra, y no una decisión de diseño guiada por criterios de ingeniería del software? Inquietante, al menos para mi.

Reconozco que este es un ejemplo un poco “cogido por pinzas”, pero no me negaréis que ilustra un problema real, que tal vez muchos estáis reconociendo de haberlo sufrido. Esta explosión combinatoria de clases es algo que se conoce también desde antiguo, y está ligado al hecho de que tenemos herencia de implementación simple. Si alguno está pensando en solucionarlo con herencia de implementación múltiple, nada vosotros mismos. Si no habéis tenido bastante con la herencia simple, ahora si que os podéis meter en un buen lío. Está claro que el verdadero problema reside en usar “extends” como mecanismo de  reutilización de código.

Resumiendo:

  • Puedo reutilizar código con “extends”, pero tengo que diseñar de antemano para ello.
  • Al diseñar de antemano, sólo puedo reutilizar aquello que está pensado para serlo, y no cualquier característica pública de la interfaz de la clase. Si necesito reutilizar mediante “extends” alguna característica de la clase que no esté diseñada para ello, pues o me aguanto, o no uso “extends” o simplemente abro la clase padre y la modifico (muy SOLID no es, no).
  • El que reutilice con “extends” una clase debe conocer si ésta está diseñada para ello, y por lo tanto conocer la implementación interna de la clase padre.
  • La forma más común (no la única), es usar un patrón “Template Method” de GoF, pero esto dificulta el testing, ¿cómo pruebo los métodos protected?
  • Algún programador petardo, que no se haya leído nuestro excelente Javadoc de los métodos “protected”, puede acabar invocando al “super” y terminar con errores en las nuevas clases, errores que a veces son sutiles de detectar.
  • Esta forma de reutilizar código está sujeta además a la explosión combinatoria de clases.

Algunos argumentaron en el post anterior que “extends” no sirve como mecanismo de reutilización de código, sino como mecanismo de especialización. O sea, para especializar clases pero sin reutilizar código. Pues vaya tela, ¡yo pensaba que lo que mantenían relaciones de especialización eran las interfaces!. Y que alguien me diga, ¡ para que sirve la herencia de implementación si no es para reutilizar código ! ¡Para que quiero especializar una clase sin reutilizar su código! ¡ Quiero un ejemplo concreto !

¿Existe alguna forma mejor de reutilizar código? La respuesta es sí, pero viene con un precio a pagar. A algunos, como a mi, este precio le parece pequeño, pero a otros les parece enorme. Lo veremos en el siguiente post.

Read Full Post »


Hola a todos, este post me lo venía pidiendo el cuerpo desde hace tiempo. Es común oírme decir que la herencia de implementación (“extends” para los javeros) es una mierda, y cada vez que lo digo veo caras de estupefacción e incluso recibo alguna que otra crítica. La verdad es que no lo entiendo bien ya que esto se sabe desde hace bastante tiempo, es más hasta tiene un nombre: “problema de la clase base frágil”, aunque yo prefiero decir que “extends es una mierda”. Incluso, algunos dicen que James Goslin, el padre de JAVA, reconoció que incluir “extends” en el lenguaje fue un gran error. Yo considero que “extends” no tiene nada que ver con la OO (al menos no con el concepto original), sino que se incluyó porque para algo tenían que servir las clases, y se pensó que se podrían usar para reutilizar código mediante la herencia de implementación.

Vamos al lío, os voy a contar una historia. Suponed la siguiente interfaz:

public interface Lista {
	void insertar(String elemento);
	void insertarVarios(Collection elementos);
	String describirContenido();
}

Se trata de una interfaz sencilla que representa una lista, con dos métodos para añadir contenido. Veamos ahora una implementación de tal interfaz:

public class ListaSencilla implements Lista {
	private List datos = new ArrayList();

	public ListaSencilla() {
		super();
	}

	@Override
	public void insertar(String elemento) {
		datos.add(elemento);
	}

	@Override
	public void insertarVarios(Collection elementos) {
		for (String elemento : elementos)
			this.insertar(elemento);
	}

	@Override
	public String describirContenido() {
		StringBuilder descripcion = new StringBuilder("Contenidos: ");
		for (String elemento : datos) {
			descripcion.append("'");
			descripcion.append(elemento);
			descripcion.append("' ");
		}
		return descripcion.toString();
	}
}

¿Sencillo verdad? Es una implementación muy directa y no tiene mayor misterio. Ahora supongamos que a otro miembro del equipo, que no escribió la clase “ListaSencilla”, le encargan desarrollar una implementación de “Lista” que cada vez que se añada un elemento a ésta, informe a un objeto auditor de tal suceso. Como nuestro desarrollador está enfocado en el objetivo de esta nueva clase, que es informar al auditor, y no le interesa volver a reimplementar y duplicar la lógica de inserción de datos, decide reutilizar código. ¿Qué mejor manera de utilizar el venerable “extends”? Al fin y al cabo, la herencia de implementación es la verdadera ventaja de la OO y su mecanismo más potente para reutilizar código. Mirando la especificación de “Lista” y conociendo que ya hay una implementación “ListaSencilla” disponible, le sale esto:

public class ListaAuditable extends ListaSencilla {
	private Auditor auditor;

	public ListaAuditable(Auditor auditor) {
		super();
		this.auditor = auditor;
	}

	@Override
	public void insertar(String elemento) {
		super.insertar(elemento);
		this.auditor.elementoInsertado(elemento);
	}

	@Override
	public void insertarVarios(Collection elementos) {
		super.insertarVarios(elementos);
		for (String elemento : elementos)
			this.auditor.elementoInsertado(elemento);
	}
}

El desarrollador ni se molesta en probarlo, obviamente va a funcionar, él ha respetado el contrato de la interfaz y está usando a los amiguetes “extends” y “super”. Más tarde le llega un bug, ¡resulta que el auditor es notificado por cada elemento por duplicado! Desconcertado nuestro programador recurre a esa poderosa arma de la ingeniería del software, el depurador, y consigue aclarar el misterio. La implementación del método “insertarVarios” en la superclase llama internamente a “insertar”, que como está sobreescrito en la clase hija también notifica al auditor, pero claro, “insertarVarios” de la clase hija también notifica al auditor por su cuenta, y de ahí la doble notificación al auditor. Mas claro agua, y si no lo habéis entendido, ¡depurad!

El desarrollador aprende la valiosa lección de que no sólo debe saber el contrato del código que quiere reutilizar, sino que debe analizar con detalle como está diseñada internamente la clase a reutilizar. Ya sabía él que todo esto del diseño por contrato y las interfaces no eran más que paparruchas para vender libros y cursos. Tras pensar detenidamente cambia el código y le queda:

public class ListaAuditable extends ListaSencilla {
	private Auditor auditor;

	public ListaAuditable(Auditor auditor) {
		super();
		this.auditor = auditor;
	}

	@Override
	public void insertar(String elemento) {
		super.insertar(elemento);
		this.auditor.elementoInsertado(elemento);
	}
}

Genial, bug resuelto de la mejor manera posible: borrando código. Más contento que unas castañuelas, el desarrollador se va a casa con la satisfacción del buen trabajo cumplido.

Pasa el tiempo, y un desarrollador senior, revisando la clase “ListaSencilla”, e ignorante de que esta clase tiene más descendientes que Gengis Khan, decide optimizar el método “insertarVarios”. Decide ahorrarse el bucle, y que leches, reutilizar código de la clase “ArrayList” que para eso viene en la JDK, estos desarrolladores junior sufren del síndrome NIH… La nueva versión:

public class ListaSencilla implements Lista {
	private List datos = new ArrayList();

	public ListaSencilla() {
		super();
	}

	@Override
	public void insertar(String elemento) {
		datos.add(elemento);
	}

	@Override
	public void insertarVarios(Collection elementos) {
		datos.addAll(elementos);
	}

	@Override
	public String describirContenido() {
		StringBuilder descripcion = new StringBuilder("Contenidos: ");
		for (String elemento : datos) {
			descripcion.append("'");
			descripcion.append(elemento);
			descripcion.append("' ");
		}
		return descripcion.toString();
	}
}

¡ Qué sencillez ! ¡ Qué elegancia ! No por nada es un “lead developer” que se conoce la JDK al dedillo. Otro que se va para casa inconsciente de la que acaba de armar. ¿Por qué debería preocuparse? Al fin y al cabo el contrato de la interfaz “Lista” se cumple, y para demostrarlo tiene un test automatizado de hermoso color verde. Mientras tanto, la “ListaAuditable” y posiblemente muchas más subclases de “ListaSencilla” comienzan a fallar sin previo aviso.

Al día siguiente, el “lead developer” decide arreglar el problema, mira a ver el código de “ListaAuditable” y lo solventa en menos que canta un gallo. El código queda así:

public class ListaAuditable extends ListaSencilla {
    private Auditor auditor;

    public ListaAuditable(Auditor auditor) {
        super();
        this.auditor = auditor;
    }

    @Override
    public void insertar(String elemento) {
        super.insertar(elemento);
        this.auditor.elementoInsertado(elemento);
    }

    @Override
    public void insertarVarios(Collection elementos) {
        super.insertarVarios(elementos);
        for (String elemento : elementos)
            this.auditor.elementoInsertado(elemento);
    }
}

¿Os resulta familiar ;-) ?

“Tonto desarrollador junior”, piensa el lead developer, “se nota que en vez de fijarse en la interfaz y los tests, se ha mirado la implementación de la superclase, y por ahorrarse un método la que liado…”. En fin, muy triste :-(

Algunos de vosotros pensará que he hecho trampas, que no he usado “bien” la herencia de implementación y que soy un petardo de programador. En el siguiente post explicaré como hacerlo correctamente. Pero ésto no es lo importante, lo que quiero mostrar es que tenemos un mecanismo de reutilización de código, la herencia de implementación, que es más peligrosa que una caja de bombas. Yo prefiero no usar un mecanismo con el que tengo que andarme con pies de plomo, aunque me haya leído y entendido el contrato del código que quiera reutilizar. La herencia de implementación no es segura porque rompe la encapsulación, y necesito saber cómo está implementada la clase padre para poder heredar de ella de forma segura. Todo esto se produce porque mezcla el estado e implementación privada de la superclase con la de la clase hija en una única instancia, en vez de mantenerlas separadas. ¿No sería mejor tener un mecanismo de reutilización de código que siempre fuera seguro? Sí, claro que existe, y lo veremos más adelante.

Read Full Post »


Hola a todos, tras digerir un poco la experiencia CAS2011, saco dos conclusiones:

  • Esta CAS2011 me ha gustado más que la del año pasado. Desde mi punto de vista la organización ha mejorado y ha habido más caras nuevas.
  • Nos estamos mirando el ombligo.
Algunos sabréis que hace poco estuve en la ScrumGathering 2011, organizada por la ScrumAlliance en Londres. Cuando la gente se me presentaba, el diálogo resultante llevaba más o menos las siguientes líneas:
Agilista Internacional: ¿Ah, Español?
Agilista de pueblo (o sea, yo): Sí
AI: ¿Y allí hay agilistas también?
AP: Sí, claro, tenemos dos eventos importantes al año, la CAS y el AOS
AI: ¿Y va mucha gente?
AP: Sí, entre 150 y 250 personas a cada una
AI: ¡ Wow, es mucha gente ! Pero, …. ¡ no había oído hablar de estas conferencias en mi vida !”
AP: Claro, por que es todo en español
AI: WTF !
Iteremos sobre toda la gente con la que hablé y os hacéis una idea de lo quemado que me volví al pueblo. Pero eso no fue lo peor, lo peor fue que la mesa redonda de la CAS2011, ¡ fue en español ! El pobre J.B. Rainsberger tuvo que hablar en castellano, ¡ inaudito ! Seguro que @jbrains no vuelve a ninguna conferencia española…
Creo que ha llegado el momento de dar un paso adelante, sacudirnos los complejos y desencasquetarnos la boina de la cabeza. ¿Por qué no empezamos a montar la siguiente CAS pensando en que sea un evento internacional? Creo que eso tendrá al menos los siguientes beneficios:
  • Variedad en los asistentes y en las propuestas.
  • Proyección internacional de la comunidad española.
  • Atraerá a más patrocinadores. Una CAS de 300 o 400 personas con ámbito internacional seguro que es más atractiva que una de 200 con proyección nacional.
  • Networking. No es networking si siempre hablamos con la gente que conocemos (gracias por recordarme esto @david_bonilla). Si vienen personas de todo el mundo las oportunidades de networking aumentan.
  • Cuando yo vaya a conferencias internacionales no tendré que escuchar más WTF y sufrir más miradas condescendientes :-)
Por lo tanto yo propongo que orientemos el siguiente evento a un ámbito más amplio. La web y los folletos en inglés. Las sesiones impartidas en inglés. Los voluntarios ayudando en inglés. Nuestros pesos pesados promocionando a nivel internacional (@ecomba, @david_bonilla, @xquesada, @acyment …). Y cualquier acción que se os ocurra.
¿Y el precio? Pues no podemos seguir pensando en pagar 4 perras. Si queremos una conferencia como dios manda hay que pagar más dinero, ¿200 o 300 euros la early bird? Yo se de gente que se puede gastar 200 euros en un fin de semana de fiesta y después dicen que 200 euros es mucho dinero por un fin de semana de agilismo.
Os dejo con una reflexión, ¿qué es la CAS? ¿Un evento de agilismo organizado por españoles para españoles? ¿O un evento de agilismo organizado en España para el mundo entero? Vosotros decidís.

Read Full Post »


Hola a todos, la mayoría de vosotros sabréis que recientemente he tomado la decisión de abandonar atSistemas, la empresa que me ha visto crecer como profesional durante estos últimos 11 años. Han sido muchos años, llenos de buenos recuerdos, trabajo duro y éxitos profesionales, pero nada dura eternamente.

Desde hace dos años empecé a sentir que existe otra forma de trabajar posible, basado en los conceptos de desarrollo Agile y Lean. Desgraciadamente para mi, la reciente crisis ha hecho que tal forma de trabajo sea imposible de implantar en atSistemas de forma simple y sin poner en peligro a la empresa (que ofrece actualmente bastante más de 350 puestos de empleo). Me marcho manteniendo relaciones cordiales con mi antigua empresa y espero seguir colaborando con ellos en cualquier proyecto agile que les surja.

Reconociendo este hecho, decidí abandonar atSistemas e intentar demostrar que se puede ganar dinero trabajando de forma ágil, y anteponiendo la calidad a la tarifa. De esta forma podré llevar a cabo mis ideas con mi propio dinero y bajo mi propia cuenta y riesgo. El intentar encontrar y explotar mercado para esta filosofía de trabajo es un objetivo personal que pienso perseguir con mucha energía. Si os digo la verdad, ahora me encuentro muy ilusionado y lleno de fuerza. Sólo el tiempo dirá si he apostado por caballo ganador, pero yo tengo fe en mi. Es la misma confianza que hizo que me marchara de Sevilla a Madrid a trabajar en una empresa que en aquel entonces no conocía de nada, a una ciudad desconocida, sin experiencia laboral, con el dinero justo para vivir un mes y habiéndome leído por primera vez lo que era una JSP en el AVE. Yo diría que aquella fue una decisión acertada, y no veo por que ésta no puede serlo.

Ahora quiero despedirme de toda la gente con la que he trabajado en atSistemas; toda la gente que me despidió el viernes y me hizo saltar una lagrimita cuando no miraban; despedirme de los chic@s de Cádiz, mis “conejillos de indias”, con los que experimenté con el agilismo y mis malditos “frameworks de la muerte” (aun me queda algo de aquella botella de serie limitada); despedirme de los compañeros de Barcelona (Aleix, tenemos que vernos); despedirme de “mis” arquitectos, espero que sigáis defendiendo el fuerte, y también de las chicas de administración y de RRHH. También me despido de los comerciales (sí, también de vosotros) a los que les di la brasa con mis ideas. Aunque espero que no sea una despedida absoluta, sino que nos vayamos viendo de vez en cuando (y Lourdes, espero mandarte alguna factura de vez de en cuando :-)).

Tengo que dar también las gracias a gente que no es parte de atSistemas por ayudarme y apoyarme, me refiero como no, a la comunidad ágil en España, que además me ayudaron a comprender que no era el único que estaba haciendo “locuras” por ahí. El encontrar esta comunidad ha sido algo muy importante para mi, y me ha animado a salir de la “cueva”. Me sorprendí de sus “retuits” y mensajes de ánimo cuando anuncié mi nueva etapa personal y profesional. Me resultó revelador que me dierais enhorabuenas más que ánimos :-O.

Y por supuesto un beso a mi mujer, @mcberros, que me ha dado soporte incondicional en esta arriesgada (y emocionante) decisión.

Y aquí os dejo un par de fotos. En la primera están muchos, pero faltan muchos más, que están distribuidos por todas partes de España:

La gente de la oficina de las Rozas

Y aquí la otra foto, donde se atestigua por qué no me sentía parte de atSistemas…

Las chicas de las Rozas

…porque obviamente soy el más feo de la oficina :-)

Saludos a todos y espero que podamos hacer una quedada.

P.S. Y por supuesto gracias por el iPad2, ¡ que era lo que me faltaba para convertirme en un apple fan boy !

P.S.S. No puede faltar la foto de la botella edición limitada:

Edición limitada @eamodeorubio

Read Full Post »


This blog is in Spanish but some readers have suggested me to translate the posts to english. In this way they will be in two languages, spanish (main) and english.

What do you think?


Read Full Post »

¡Hola Mundo!


¡Hola a todos! En este primer post simplemente presentaré este blog.

Lo primero de todo es comentaros cual es la temática del mismo. Aquí intentaré ir escribiendo un articulo o dos al mes contando mi visión de las últimas tendencias en ingeniería del software, frameworks e informática profesional en general.  Explicaré, con más o menos fortuna, cosas como servicios REST, metodologías ágiles, TDD, aplicaciones RIA y AJAX y buenas prácticas en general.

¿Por qué este blog? Simplemente me di cuenta de que mis compañeros y yo tenemos de vez en cuando conversaciones y discusiones donde vamos aprendiendo como aplicar todas estas nuevas ideas para mejorar los proyectos en los que estamos inmersos. Así que reflejar lo aprendido mediante un blog se me antoja una buena idea. Se trata de dar un enfoque práctico, desde la realidad del día a día sobre todos estos temas a veces tan confusos, abstractos o teóricos. Normalmente no pondré código, este no es un blog de “ejemplos de código”, sino que más bien trataré de explicar conceptos de forma sencilla y como aplicarlos a la realidad.

Espero que vosotros participéis en la discusión y dejéis muchos comentarios. Respetaré todos los comentarios, aunque sean negativos, siempre y cuando sean educados, sigan las normas básicas de la etiqueta y vengan a cuento. Creo que este blog puede ser de utilidad y generar un debate constructivo.

Intentaré no hacer posts largos, sino cortos y sencillos. Si alguna cosa es compleja la abordaré en varios posts.

¿Por qué en español? Pues muy sencillo, ¡ya hay muchos blogs en inglés! Además no esta de más dar una visión “hispana” de todo esto, por aquí también sabemos hacer las cosas bien. Sin embargo, aunque escribiré en español, no pienso traducir palabras técnicas. No escribiré cosas como ‘cadenas’ o ‘arreglos’ sino ‘strings’ y ‘arrays’ y en vez de ‘servicios web’ hablaré de ‘web services’.

Nos vemos pronto

Read Full Post »

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 42 seguidores