Mi forma de vida

Los que me conocen me habrán oído hablar alguna vez sobre pesadilla en la cocina, versión america o española. La primera vez que lo vi me quede fascinado, prácticamente todo se podia trasladar a nuestra profesión. Imaginaba a esos comerciales intentando vender en sala esos productos informáticos que desconocen y atribuyéndonos propiedades mágicas que hacen posible convertir mero en lubina. También podía ver a esa cocina corriendo como pollo sin cabeza sin nadie que gestione la demanda u organice el trabajo. Y sí, también desarrolladores en cocina poco profesionales.

Viendo este programa te das cuenta de que cualquiera se cree capacitado para montar una cocina y no te digo ya nada para cocinar. Pero lo cierto es que hay mucho incompetente, irresponsable y  en definitiva personas que no aman lo que hacen y no respetan su profesión.

Uno de los últimos programas que pude ver era en Miami. La cocinera, una joven americana, estaba apunto de perder el cariño por lo que hacía. Lo sé porque yo también he estado ahí, renegando de esta profesión y apunto de abandonarla, pero como a mi, un Chicote llego al rescate. Quiero que su última frase se os quede grabada como se me quedo a mi (no es literal): Me he dado cuenta de que cocinar no es sólo un trabajo sino que es una forma de vida.

Programar es mi forma de vida. Es la tuya?

 

 

Etiquetado con:
Publicado en: articulos

Pomodoro y responsabilidad

El otro día un compañero me argumentaba porque utilizaba un pomodoro web de estos que puedes compartir con otra gente dándoles una url. Por lo visto su mujer lo mira antes de llamarlo para no interrumpir su pomodoro. Yo le comenté que a mi no me llaman de casa cuando estoy trabajando y si lo hacen es porque es importante y puede interrumpir un pomodoro.

Pero no quiero discutir las interrupciones sino más bien las pausas. Analicemos esto:

Cada 25 minutos de trabajo 5 minutos de pausa.

Cada 4 pomodoros 15 minutos de pausa.

Esto hace que cada 4 pomodoros, 1 hora y 40 minutos de trabajo hayamos pausado durante 30 minutos. En una jornada laboral normal de 8 horas trabajarías 6 horas y cuarto y dedicarías a las pausas 1 hora y 45 minutos.

Ahora bien, ¿qué entendemos por pausa? Si entendemos por pausa hablar con tu mujer, pues… que de las 8 horas que te paga tu jefe te pases casi dos colgado al teléfono no parece muy responsable por tu parte. Sin embargo, si aprovechamos esas pausas para dejar al cerebro que se relaje y ocuparnos de tareas menos exigentes pero relacionadas con nuestro trabajo estaríamos hablando de otra cosa ¿no crees?

¿Qué haces tu en las pausas del pomodoro?

Publicado en: articulos

El Programador Profesional

Muchas veces he pedido a mis compañeros que tengan una actitud profesional y no menos veces me han preguntado que es eso. Por eso al volver a encontrarme con este articulo de Uncle Bob no me he resistido a traducirlo.

El rasgo mas importante de un programador profesional es la responsabilidad. Los programadores profesionales se responsabilizan de su carrera, sus estimaciones, sus planificaciones y su trabajo. Un programador profesional no hace recaer su responsabilidad en otros.

Si eres profesional, eres responsable de tu carrera. Es tu responsabilidad leer y aprender. Es tu responsabilidad estar al día de la industria y las tecnologías. Demasiados programadores creen que que es responsabilidad de sus jefes impartirles formación. Están equivocados. ¿crees que los médicos piensan así? ¿Y los abogados? No, ellos siguen aprendiendo es su tiempo libre y de su propio bolsillo. Invierten mucho tiempo leyendo periódicos y veredictos. Se mantienen al día. Y nosotros deberíamos hacer los mismo. La relación entre tu y tu jefe esta muy clara en tu contrato. Abreviando: el te paga y tu haces un buen trabajo.

Los profesionales se responsabilizan del código que escriben. No liberan código a no ser que sepan que funciona. Piensa en esto un minuto. ¿Como puedes considerarte un profesional si estas mandando código que no estas seguro que funciona? Los programadores profesionales no esperan que calidad encuentre fallos porque ellos no envían código hasta que ellos lo han probado. Desde luego, calidad encontrara errores porque nadie es perfecto. Pero como profesionales nuestra actitud debe ser no dejar nada para que calidad lo encuentre.

Los profesionales juegan en equipo. Se responsabilizan de lo que entrega todo el equipo, no solo de su propio trabajo. Se ayudan unos a los otros, enseñan unos a los otros, aprenden uno de los otros incluso se protegen unos a los otros cuando es necesario. Cuando un compañero se derrumba, los otros se meten, saben que algún día serán ellos los que necesiten protección.

Los profesionales no aguantan grandes listas de bugs. Una gran lista de bugs es una chapuza. Sistemas con miles de incidencias en la base de datos del gestor de incidencias son tragedias negligentes. De hecho, en muchos proyectos, la sola necesidad de un gestor de incidencias es un síntoma de irresponsabilidad. Solo los sistemas gigantescos deberían tener listas de incidencias tan largas que justifiquen el uso de un gestor.

Los profesionales no hacen mierda. Están orgullosos de su trabajo. Mantienen su código limpio, bien estructurado, y fácil de leer. Siguen estándares y buenas practicas. Jamas corren.
Imagina que te están operando a corazón abierto y puedes ver al médico. El médico tienen un deadline. Tiene que terminar antes de que el bypass dañe demasiadas células de tu sangre. ¿Como quieres que actué? ¿Quieres que actué como el típico desarrollador de software, corriendo y parcheando todo? ¿Quieres que diga “después arreglare esto” ? O prefieres que actué con disciplina , tomándose su tiempo y confiado en que su forma de actuar es la mejor. ¿Quieres mierda o quieres profesionalidad?

Los profesionales son responsables. Se responsabilizan de su carrera. Se responsabilizan de que su código funciona bien. Se responsabilizan de la calidad de su trabajo. No abandonan sus principios cuando se avecina la fecha de entrega. De hecho cuando la presión aumenta, los profesionales se aferran aún más fuerte a las disciplinas que saben que funcionan.

—Robert C. Martin (Uncle Bob)

Articulo Original: http://programmer.97things.oreilly.com/wiki/index.php/The_Professional_Programmer

Me gustaría añadir algo más, si tus condiciones contractuales ya no te gustan cambialas o busca otro trabajo.  Los profesionales no dejan de serlo nunca, eso no seria profesional.

Publicado en: articulos

2013 La opinión de mis compañeros

valoración gráfico valoración gráfico 2 valoración gráfico 3 valoración gráfico 4

Publicado en: articulos

2013

Este año ha sido un año de mucho trabajo y sacrificio. He intentado, desde el puesto de director técnico, liderar un cambio metodológico, técnico y cultural en mi empresa. Un día os contaré las motivaciones para aceptar este puesto y como fue todo el proceso, pero simplificando mucho, diré que había intentado hacer los mismo desde la posición de “arquitecto-jefe de proyecto-desarrollador” y parecía que desde esta posición sería más posible.

Primer reto “Organizar equipo X”:

El primer mes, mes y medio lo dedique a enterarme como esta montado el tinglado. Entre tanto todos los días a primera hora asignaba todo el trabajo a cada persona. Una vez que tuve más o menos claro la organización actual reuní al equipo y les propuse kanban.
Este equipo es uno de los que más trabajo me ha dado y más me ha obligado a romperme la cabeza. Después de muchos cambios, de muchas discusiones, retros… parece que por fin tenemos un proceso con el que todo el mundo esta igual de conforme que de disconforme. Parece que funciona, pero hemos tenido algún lastre y hay algo que aún tenemos que cambiar para conseguir una cadencia constante, además de que el equipo trabaje como un EQUIPO.

Segundo reto “Organizar el resto de equipos”

Después de muchas vueltas, idas y venidas tenemos identificados tres equipos más. Unos hacen scrum otros hacen kanban, algunos funcionan bien otros peor, algunos están distribuidos otros no. Hacer cambios en estos equipos y conseguir mejoras es un reto que habrá que abordar en 2014.

Tercer reto “Mejorar la calidad y reducir la deuda técnica”

Esta es la gran asignatura pendiente. Aunque conseguimos formación y hemos incluido revisiones de código y TDD necesitamos algo más. Necesitamos compromiso, compromiso con la profesión.

Cuarto reto “Brecha tecnológica y proyectos que se han enmarronado”

Era necesario abordar ciertos proyectos técnicos que no se podían posponer más y que nos estaban lastrando o contra los que nos íbamos a estrellar. Además hubo que hacerse cargo de tres proyectos que se torcieron y que tenían muy mala pinta. Aquí dimos la talla o al hemos eso me parece a mi y aunque algo todavía colea creo que se concluirán más o menos satisfactoriamente.

Quinto reto “Mejorar el entorno y las herramientas”

Cambiar los equipos fue relativamente fácil, el aire acondicionado y la luz más complicado, en el caso del aire aún está pendiente.

Sexto reto “Crear una política salarial”

No fue fácil pero lo conseguimos.

Séptimo reto “Elevar salarios a nivel de mercado”

Qué queréis que os diga, lo que me dicen a mi, la cosa esta muy mala.

Seguro que se me olvida alguno de los retos con los que hemos topado este año pero creo que casi todo esta aquí, nos falta ser más lean y menos nosotros mismos.

Como os decía, un año de mucho trabajo y sacrificio. Un año en el que he puesto todo lo que sé y todo lo que soy en este proyecto. Un año profesional que termina con sabor agridulce, pero eso, eso ya es otra historia.

Publicado en: articulos

DispatchOperationRuntime y Excepciones. Mi respuesta.

Lo primero que anda mal es el mensaje que lanza la excepción.

Pero realmente el método al que se llamo fue:

Esto, a parte de hacerte perder unas horas intentando determinar el problema, es un mal menor y un error que le puede pasar a cualquiera.

Para mi el problema mas grande esta en la llamada a DiagnosticUtility.FailFast. Este método recibe un mensaje (el de arriba), el tipo de excepción que se captura y el mensaje de la excepción, pero perdemos el resto de información. Por tanto lo que se muestra a la salida es esto:

Bastante inútil, ¿no creéis? Sin embargo la excepción original incluía la verdadera pila de llamadas y podíamos determinar exactamente donde se generaba la excepción, que por cierto era un error de desbordamiento al hacer el flush de nhibernate.

Como no podemos tocar el código de WCF (DispatchOperationRuntime) tendremos que ser más imaginativos. Al final opte por envolver la excepción original en otra que devolviera como mensaje toda la información que me parecía relevante. Supongo que podría haber intentado una solución más elegante con algo de AOP pero también más compleja.

Update:

Es posible aunque no lo he probado que mediante las capacidades de extensión de WCF podamos usar nuestro propio Dispatcher. ¿Alguien lo confirma?

Referencias:

¿Qué anda mal en este código? DispatchOperationRuntime y Excepciones
http://msdn.microsoft.com/es-es/library/system.servicemodel.dispatcher.icallcontextinitializer.aspx
http://fabiomaulo.blogspot.com.es/2009/10/nhibernate-wcf-session-per-call-in.html
http://reflector.webtropy.com/...

 

Etiquetado con:
Publicado en: programación

¿Qué anda mal en este código? DispatchOperationRuntime y Excepciones

Etiquetado con: , ,
Publicado en: programación

Dynamic dispatch en c#

    private void Application_DispatcherUnhandledException(
           object sender
          , DispatcherUnhandledExceptionEventArgs e)
    {
        Process((dynamic)e.Exception);
    }

    public void Process(Exception exception)
    {
        Log.Warn("Exception");
    }

    public void Process(ArgumentException exception)
    {
        Log.Debug("ArgumentException");
    }

Referencias:
http://en.wikipedia.org/wiki/Dynamic_dispatch
http://mstecharchitect.blogspot.com/2008/11/how-to-handle-unhandled-exception-in.html
http://msdn.microsoft.com/en-us/library/dd264736.aspx

Publicado en: Uncategorized

Fotos segundo sábado áxil

Publicado en: Uncategorized

TDD/BDD – Segundo sábado áxil

Este fin de semana tuvo lugar el segundo sábado áxil de la comunidad áxil-mente de Galicia. En dicho evento pude proponer una charla sobre BDD, después de escuchar las opiniones de todos y ordenar un poco mis ideas voy a intentar expresar mi opinión al respecto.

Yo soy de los que piensan que BDD es TDD bien hecho. Tengo que reconocer que esta opinión provoco ciertas sonrisillas y tal vez merezca la pena una aclaración.

Al principio, al menos en “mi” principio, TDD era una de las practicas de XP y consistía en escribir un test antes de empezar a escribir código. Solo eso. ¿Y BDD? BDD es todo lo que TDD quiso ser y no le dejaron. Escribir los test antes que el código tiene una serie de beneficios intrínsecos. Tenemos mucho más que una extensa red de seguridad para hacer refactoring o cambiar algo en nuestro código. Lo cierto es que también nos ayuda a obtener un mejor diseño, a desacoplar más nuestras clases, a centrarnos más en lo que estamos haciendo, a diseñar nuestras APIs desde el punto de vista de quién las consume y un largo etc. Por tanto TDD merecía un nombre más ambicioso, entonces llego BDD.

La primera persona que hablo sobre BDD fue Dan North. En su artículo habla sobre todo el proceso que siguieron él y algunos amigos hasta dar con lo que llamaron BDD. Os animo a leer el artículo con atención. Para mí la palabra clave es “behaviour”.  Si quitamos la palabra test de nuestro proceso de desarrollo favorito y ponemos comportamiento no tendremos una batería de test que ejercita nuestras clases y métodos, tendremos el comportamiento de nuestros objetos expresado en forma de test. Esa es la clave.

Un poco de código:

Ejemplo en TDD:

   1:  [TestClass]
   2:  public class CalculatorTests
   3:  {
   4:     [TestMethod]
   5:     public void AddTest()
   6:     {
   7:        var calc=new Calculator();
   8:        var result = calc.Add(3, 2);
   9:        Assert.AreEqual(5,result);
  10:      }
  11:  }

Ejemplo en BDD:

   1:  [TestClass]
   2:  public class CalculatorSpecs
   3:  {
   4:      [TestMethod]
   5:      public void given_two_natural_number_when_add_then_result_is_ok()
   6:      {
   7:         var calc = new Calculator();
   8:         var result = calc.Add(3, 2);
   9:         Assert.AreEqual(5, result);
  10:      }
  11:  }

¿Pero qué aporta BDD? Bueno, primero desterrar de una vez por todas la T(est) de su nombre, algo que muchos pedían a voz en grito. Y segundo, otra serie de beneficios, por ejemplo: la mejor documentación de tu código estará en tus test, serán menos frágiles o al menos mentirán menos ya que prueban el “qué “ y no el “cómo”, incluso, si tienes suerte, puede que tus clientes escriban los criterios de aceptación de sus historias usando Gherkin y cerrarás el círculo como hace Dan North en su artículo.

Algunos dicen que BDD son test de aceptación. Yo pienso que un test tanto si es de aceptación, de integración, unitario o lo que sea debe y puede expresar un comportamiento. Otros hablan de niveles y dicen que BDD solo se puede aplicar a niveles más externos de la aplicación dejando TDD para las capas más internas y cercanas al desarrollador. Mi opinión es que estas confusiones las han provocado los framework y sus notaciones a la hora de expresar los comportamientos. Así tenemos Given/When/Then o Context/Specification. Pero no podemos dejar que estos frameworks nos digan dónde podemos usar BDD. Si para ti no es natural expresar los test de tus capas más internas con GWT entonces no lo uses, usa cualquier otra forma que te sea útil (can_add_two_numbers por ejemplo).

BDD es la forma de hacer TDD del siglo 21, ¿te lo vas a perder?

 

Para saber más:

 

Etiquetado con: ,
Publicado en: articulos, eventos, tdd