Diario de Programación

Hace un mes aproximadamente terminé de leer "JavaScript, The Definitive Guide". Un libro sobre JavaScript y alrededores que me ha encantado. Aparte de JavaScript, trata bastante bien temas como JavaScript en un navegador web, una introducción a node.js y rhino en el lado del servidor, AJAX, jQuery, almacenamiento local en el navegador, Canvas de HTML5, …

Son un montón de páginas, 1100 nada menos, pero aproximadamente la segunda mitad son una guía de referencia de las funciones de JavaScript, por lo que de lectura es aproximadamente la mitad.

Comienza con los principios de programación en JavaScript desde cero, el típica capítulo de introducción al lenguaje que no aporta demasiado a casi nadie, demasiado rápido para el que no sabe nada de programación, pero demasiado trivial para el que sabe programar en otros lenguajes. Aun así, dentro de esta parte, he encontrado una pequeña joya para alguien como yo acostumbrado a otros lenguajes y es todo el tema de cómo se hacen conversiones de tipos automáticas, sobre todo en los condicionales, es decir, cuándo una variable independientemente de su tipo (string, numérico, un objeto,…) se considera que es true o false.

Sin embargo, luego empieza a meterse en profundidad en montones de temas variados de JavaScript y aquí es donde algún programador experto en otro lenguaje pero sin demasiado conocimiento de JavaScript, empieza a disfrutar del libro. Por supuesto, hay temas demasiado farragosos como para que sea agradable leerlos, pero hay otros que me han parecido geniales, tanto por lo que supone aprender cosas que no sabes, como por la forma de exponerlas.

Entre los primeros, los farragosos, está la parte de orientación a objetos en JavaScript, clases, herencias, polimorfismo a base de tipado tipo pato, También la parte de eventos en los navegadores web es pesadita, más que nada porque cada navegador es de su padre y de su madre y no hay acuerdo en los eventos que se producen, cómo se llaman y cuándo se producen. El libro no puede hacer mucho más que dar una lista con una breve descricpción de cada uno de ellos.

Sin embargo, entre las partes geniales, me ha encantado la forma de explicar las expresiones regulares, tanto, que he hecho mi propio tutorial de expresiones regulares en JavaScript siguiendo esa forma de explicación, por supuesto, donde esté el libro que se quite cualquier tontería que haya podido hacer yo. También me ha encantado la forma de explicar jQuery, todos sus apartados, desde los selectores para buscar y modificar elementos de nuestro HTML, como la parte de AJAX, efectos especiales como fadeIn() y fadeOut(), …

En fin, totalmente recomendado para aquel que ya ha empezado a programar cosas en JavaScript pero necesita profundizar y comprender más el tema.

Esta mañana, como todas las mañanas de día laborable, estaba desayunando en mi cafetería habitual antes de ir a trabajar. La camarera estaba hablando con uno de los clientes y comentaban el precio de un móvil que libre costaba unos 300€, pero si hacías contrato costaba unos 80€. Por supuesto, sería un móvil de estos güay que ahora, imagino que con Android o similar.

Mi móvil es un "patatófono", el de la foto, con java JME, con teclas y todo, de tarjeta prepago porque soy muy rácano y encima lo uso como hucha, ya que cada 6 meses le meto dinero para que no se caduque la tarjeta y como pasa el 99% del tiempo apagado, tampoco lo gasto.

Sin embargo, la conversación de la camarera me ha hecho pensar que todos estamos "pillados" por los móviles de última generación. Ella con su cliente de la forma habitual, pendiente de los "wasaps" mientras pone cafés, y yo, raro de mí, de la forma "dura". Justo mientras ella hablaba con el cliente, yo estaba desayunando y leyendo "Programming Android: Java Programming for the new generation of Mobile Devices".

Aprovecho para comentar que el libro no me está gustando demasiado. Voy aproximadamente por la página 150 de sus 550 y todavía está explicándome que eclipse tiene autocompletar. Hasta ahora va explicando las cosas metiéndose en detalles sueltos muy profundos, pero explicándolos por encima y sin dar un "esquema general". Por ejemplo, primero explica java en un capítulo, pero evidentemente muy por encima. Luego cuenta el SDK de Android con todas sus herramientas en otro capítulo, describe un montón de herramientas que vienen con el SDK, pero metiéndose en detalles sin explicarlos claramente. Luego se mete con detalles que considera importantes de la programación Android, como liarse a explicar programación concurrente, tema un poco "farragoso" para empezar por él, y nuevamente se mete en detalles sin explicarlos claramente.

Sigo leyendo, enganchado como estoy al "hard way" de los móviles.

Cuando se habla de metodologías ágiles y quizás porque en el fondo somos programadores y no gestores, siempre se habla de cosas como la reunión diaria, las entregas frecuentes, los tableros Scrum, los test automáticos, etc, etc. Sin embargo, hay otro punto realmente importante y del que no se suele hablar, la intervención directa del cliente a lo largo de todo el proceso.

Afortunadamente, he tenido oportunidad de practicar con este último punto y ahí va la experiencia. Pongámonos primero en contexto

El proyecto es un proyecto pequeño para lo que estamos acostumbrados, un solo desarrollador, yo mismo, durante algo más de seis meses y con la suerte de poder dedicarme al 100% al proyecto (cosas de la crisis, no hay demasiado trabajo). Hay también un jefe de proyecto, pero su única gestión es básicamente el tema económico y alguna reunión o charla esporádica con los "jefes" del cliente. El proyecto es un proyecto Web, en el que sólo hay software implicado, el servidor está desde el principio en las instalaciones del cliente, con su dominio público en internet y al que tengo acceso de administración con una VPN (red privada virtual)

En este contexto, tengo contacto diario y directo, por teléfono y email, con los usuarios finales del proyecto, los que van a estar usando esa web día a día, así que pensé que es una situación ideal para metodologías ágiles. Al ser yo el único desarrollador y estar el cliente en otra ciudad a más de 400 km de distancia, todo eso de las "demos" y reuniones al estilo Scrum no me parecía adecuado, así que  opté por una opción más al estilo Kanban. Me di de alta en https://kanbanflow.com , hice un tablero con cuatro columnas : to-do, in-progress, verification y done, copié los requisitos iniciales en la columna to-do y le mostré el tablero a los clientes, así como una explicación del funcionamiento general de Kanban y metodologías ágiles, en lo que a ellos les afecta. Les pareció una idea estupenda y es lo que estamos usando.

Ellos ordenaron y matienen ordenada la columna de "to-do", además de añadir más tareas cuando les viene en gana, en el orden en que quieren que se desarrolle. Yo siempre saco la primera tarea de arriba del todo y la muevo a la columna "in-progress", teniendo como máximo 3 tareas simultáneas en desarrollo. Cuando termino de probarla en mi entorno de pruebas y la subo al servidor, la muevo a "en verficacion" y ellos, tras probarla, la mueven a "done" o la devuelven a la primera columna con más cosas que quieren o bugs que han encontrado. En fin, nada que no sepamos ya del funcionamiento de un tablero Kanban.

¿Y cuales son las consecuencias de todo esto?. Pues bien, como nada es blanco ni negro, hay cosas buenas y otras no tan buenas. Empecemos con las primeras.

Lo mejor de todo es que el cliente está encantado. No es solo que me lo digan cuando les pregunto, es también el "feedback" que me da nuestro jefe de proyecto cuando habla con ellos o lo que yo mismo oigo a los clientes hablar entre ellos cuando nos hemos reunido cara a cara.

Lo primero que les gusta, por supuesto, es que el producto, aparte de no tener grandes fallos, cumple exactamente lo que necesitan, como no puede ser de otra forma, puesto que los mismos usuarios finales lo ven evolucionar día a día y deciden sobre lo que se debe hacer y cómo. Y lo segundo que les encanta es la excelente gestión de sus peticiones (mérito de un mecanismo como Kanban), ellos tienen total control sobre lo que piden y cuándo se aborda, así como total visibilidad de lo que se está haciendo y lo que tarda en hacerse. Ninguna de sus tareas lleva un tiempo estimado de más de 3 ó 4 días, pero la mayoría son de 1 ó 2 días, por lo que ven progresos de forma continua. Si alguna tarea lleva mucho más, hablo con ellos y tratamos de partirla, creando una tarea más pequeña con lo que realmente es importante para ellos y otras con lo menos importante y que puedan poner más abajo en la lista.

Y ahora viene la parte no tan buena. Aunque se deja claro al principio que pueden añadir, modificar y ordenar tareas a su gusto, también se deja claro que el proyecto tiene una fecha de terminación y que toda modificación que hagan o tarea que añadan, no debería afectar a esa fecha, sino simplemente hacer más probable, si no seguro, que las tareas al final de la columna to-do se queden sin hacer. Esto, por supuesto es algo que no les gusta oir. Pero eso no es lo peor, porque la ventaja de controlar el desarrollo día a día les convence frente a la posibilidad de que alguna tarea poco importante para ellos se quede sin hacer y de alguna forma, lo aceptan. Lo peor es que en el día a día se "emocionan" con las tareas que se van realizando y tienden a no acabarse nunca. Cuando terminas una tarea y ellos la prueban, se les ocurren mejoras que inmediamente hacen que la tarea vuelva a la columna "to-do", con añadidos para hacer y, normalmente, al principio para que se aborde inmediatamente. Hay que estar continuamente pidiéndoles verificación, como sutil indirecta de que nos estamos eternizando en los detalles, de si están seguros que ese nuevo añadido es más prioritario que las siguientes tareas en la lista.

Hay otro detalle, no sé si bueno o malo, y es el "pequeño estrés" que causa este método al desarrollador (yo). Al ver ellos el progreso día a día y ser tareas de tan poco tiempo estimado (1, 2, 3 días), "canta" mucho si un día me distraigo con cualquier cosa. Si tengo alguna reunión ajena al proyecto, si acabo de volver de vacaciones y tengo el típico día perezoso que te pasas "güeveando" en internet o con el email … Se ve agravado por el hecho de que para tener mejor visibilidad de cómo va el proyecto, llevamos un pequeño excel compartido que se actualiza todos los Viernes, en él aparecen las tareas, el tiempo que yo estimo para cada una de ellas en días y sumando esos días, la fecha prevista de terminación de cada una de ellas … y por tanto la fecha prevista de terminación del proyecto si se hacen todas las tareas. Si una tarea se complica más de lo previsto, ya me causa un pequeño "estrés" actualizar el excel y ver cómo la fecha de finalización se va alargando a la vista de todos. Pero me causa mucho más "estrés" si encima ese retraso va causado por la típica pereza que todos tenemos algún día que otro.

Puedo asegurar que nunca he trabajado tanto y tan seguido como en este proyecto, en parte por el "estrés" que me causa perder el tiempo, en parte por tener en todo momento perfectamente claro qué es lo que tengo que hacer y cómo. Ojo, no he echado ni una sola hora de más, es simplemente que apenas pierdo el tiempo a lo largo del horario laboral tratando de que el flujo de tareas de "to-do" a "done" sea lo más fluído posible.

Ahora nos estamos acercando a la fecha prevista de finalización, por supuesto, con requisitos iniciales que el cliente no ha considerado importantes al final de la lista to-do y totalmente fuera de plazo, pero con otros requisitos que han añadido sobre la marcha y que han considerado más importantes hechos a su gusto, con el cliente bastante contento en general. Veremos qué tal va el cierre final ….

Ando liado con menús y chorradas varias en el proyecto. El "rollo" es que a veces los menús son muy largo (fíjate en esta tabla de códigos ISO de paises). En base de datos va el código numérico o el de dos/tres letras, mientras que al usuario se le deben presntar los textos legibles con el nombre completo del país. A veces es símplemente mostrar un país resultado de una consulta, otras veces es mostrar un menú (unos select/option de HTML).

Pues bien, a partir de una de esas tablas hay que conseguir bien una tabla en base de datos con dos columnas: código – texto legible, bien el menú select/option de HTML, bien un fichero properties de java con muchas líneas codigo=país, etc. Y muchas veces la única entrada que tenemos es copiar de una página web como esa.

Habitualmente, un "truco" que hago es seleccionar con el ratón la tabla de la página web en cuestión, esto me copia en el portapapeles el código de la tabla HTML y afortunadamente, si se pega eso en un Excel lo hace de forma correcta (fíjate en la imagen)

Ahora el proceso es más fácil, se puede exportar esto a un CSV, que no es más que un fichero de texto en el que cada fila corresponde a una línea y los valores de las columnas van separados por comas, encerrados en comillas o como queramos. Eliminamos antes las columnas que no nos interesen y obtenemos un fichero de texto como este (abierto ya con el editor vi)

Bien, pues con un fichero como este, lo habitual sería cogerle algún lenguaje de script, como phyton, perl, awk o cualquiera de nuestro gusto y hacer un pequeño programita que lea eso línea a línea y genere lo que  nosotros queramos, estilo

<option value="AF">Afganistán</option>

si queremos, por ejemplo, un select/option de HTML. Pero no es necesario uno de estos lenguajes, el mismo editor vi (gvim en mi caso) tiene un potente buscar y reemplazar con expresiones regulares similares a las de cualquiera de esos lenguajes. Si en el editor anterior ejecutamos el comando (lo explicamos al final)

:%s/^\(\S\+\); *\(.*\)$/<option value="\1">\2<\/option>/

nos da el resultado esperado

El comando no es más que un comando de vi que permite sustituir unas cadenas por otras.

El : es para entrar en el modo que nos permite escribir comando de este tipo.

El %s indica la s un "sustituir" y el % que se haga en cada línea. El comando s lleva este formato s/cadena a buscar/cadena nueva/.

La cadena a buscar es una expresión regular, en la que ^ indica inicio de línea y $ fin de línea, como en cualquier lenguaje.

\S+ indica caracteres no espacios una o más veces, como en las expresiones regulares de cualquier otro lenguaje. La diferencia aquí es que el + hay que escaparlo, por eso \S\+. Esto ira casando con los códigos de dos letras. El .* indica cualquier cadena de caracteres, que iran casando con las descripciones de los paises.

Como nos interesa guardarnos ambas cosas (el código y la descripción), las encerramos entre paréntesis, pero a diferencia de otros lenguajes, aquí también hay que escaparlos, así que quedan cosas tan feas como \(\S\+\) y \(.*\). Entre ambas está el ; y el espacio que por lo que vemos es opcional, es decir <espacio>*

En la parte de la nueva cadena, tenemos disponibles en \1 y \2 lo que habíamos colocado entre paréntesis, es decir código de país y descripción. Así que la cadena nueva no es más que el <option> completo, poniendo \1 donde va el código de país y \2 donde va la descripción.

Nada que no se pueda hacer desde un script en otro lenguaje, como hemos dicho, pero .. ¿qué pasa en mi caso que posiblemente hiciera el script usando el vi? ¿para qué hacer el script, salvo que piense reutilizarlo más veces?

En un lenguaje fuertemente tipado y orientado a objetos, se comprueban las clases de los objetos antes de asignarlos a variables, de forma que sólo se pueden asignar a una variable objetos que son de la misma clase que la variable o hijas de la misma. Por ejemplo, si la clase Hija herada de la clase Padre, se puede hacer esto

Padre p = new Hija();

Una vez hecho, sólo pueden llamarse a métodos o atributos que estén declarados en la clase Padre. Si Padre tiene metodo1() e hija tiene metodo2(), sólo podemos hacer p.metodo1(), mientras que p.metodo2() dará error. Todo esto da sentido a cosas como las interfaces, definiendo a priori que métodos necesitan tener las clases hijas para que luego estas lo implementen.

Hay otros lenguajes, como javascript, que usan lo que se llama "Duck typing" o como lo traduzco yo "tipado tipo pato". La idea básica de este tipado es que si algo anda como un pato, grazna como un pato y nada como un pato, pues entonces es un pato. Los lenguajes que usan este tipado no miran los tipos ni las herencias de los objetos, simplemente permiten asignar cualquier cosa a cualquier variable. De esta forma, podemos hacer

p = new Hija();

y luego llamar tranquilamente a p.metodo1() o p.metodo2(), pero también podemos hacer

p = new Padre();

y llamar a p.metodo1(), dando error p.metodo2(). Es decir, no importa el tipo, el error saltará a la hora de hacer la llamada si "el pato no es capaz de granzar".

 Hace unos días descubrí una herramienta online que me ha encantado, KanbanFlow.

Te registras gratuitamente y tienes la posibilidad de crear tableros Kanban. Lo que me ha gustado es la sencillez de uso, pero con bastantes posibilidades de configuración. Puedes crear varios tableros, indicar qué columnas tiene cada tablero, crear etiquetas de colores y simplemente arrastrarlas de una columna a otra, en fin, todo lo que se espera de un tablero. Puedes añadir subtareas, que no serían más que una lista de "checks" dentro de una etiqueta. Lleva además un cronómetro de pomodoro con el que podemos guardar tiempos de trabajo en las tareas.

La versión gratuita en principio permite crear cualquier número de tableros y compartirlos con cualquier número de usuarios. La versión de pago principalmente permite asignar roles a los usuarios, exportar a ficheros pdf, csv, etc, llevar histórico de las tareas y tiempos, …

Otro detalle es que la gente que está trabajando en esto parece estar pendiente del asunto. Puse una pequeña petición en su página de ayuda y soporte y aunque me la negaron, tardaron en contestar una o dos horas.

Acabo de leer OpenLayers 2.10 Beginner’s Guide 

OpenLayers es una librería javascript que nos permite hacer aplicaciones con mapas en nuestra página web. Los mapas pueden ser los de Google Maps, Bing, OpenStreetMap o servidor por cualquier servidor que cumpla los estándares OGC, como Geoserver. OpenLayers "traga" además otro montón de formatos para dibujar mapas directamente de ficheros.

El libro es muy básico, empieza desde el principio, tan desde el principio que incluso nos explica lo básico de javascript y qué son las clases, la herencia, los métodos y atributos. Por supuesto, no se entretiene demasiado en ello, una simple explicación para no pillarse los dedos según va avanzando en OpenLayers.

Si, como yo, has empezado con OpenLayers a base de ensayo y error, copy-paste de código en google y ya tienes algo de experiencia, este libro es muy básico, pero siempre acalara algún concepto que puedes no haber "pillado" en tus pruebas, ensayos, errores, copies y pastes.

Es ideal sin embargo para leer antes de empezar con OpenLayers, el libro va despacio, no es muy complejo lo que explica y va asentando bases antes de seguir. Cada apartado resulta un poco repetitivo porque primero te explica cómo funciona, luego te lo vuelve a explicar mientras te dice cómo codificarlo y finalmente te lo vuelve a explicar añadiendo un título "¿Qué acaba de pasar?" después de que hayas ejecutado el ejemplo que acabas de codificar. Lo dicho, ideal para quien no tiene idea del tema y le gusta asentar bien las cosas.

En la metodologías ágiles, Scrum por ejemplo, es típico que se hable de entregas al cliente frecuentes, con algo que les sea útil y donde puedan ir viendo los progresos. Últimamente, estoy pensando si eso es o no posible en todos los proyectos. ¿Por qué? Porque en el proyecto que estoy ahora es claramente posible y así lo estoy haciendo, pero eso me ha hecho darme cuenta que en los proyectos anteriores no solo no es tan fácil, sino que posiblemente es poco menos que imposible.

Los proyectos en los que ando actualmente, ya casi desde hace dos años, son proyectos web. Y cada proyecto lleva dos o como mucho tres desarrolladores y se hacen en unos meses, menos de un año, cada uno de ellos. En estas condiciones es fácil hacer entregas frecuentes. Tu proyecto solo lleva software y está público en internet. Así que haces un pequeño desarrollo de un par de semanas, aunque sólo sea el login, o la página principal con un poco de funcionalidad, la subes al servidor, se lo dices al cliente y ellos prueban y dan su opinión. Y repites el proceso cada 15 días o así añadiendo cada vez un poco más de funcionalidad, siguiendo las indicaciones de tu cliente.

¿Y cómo eran los proyectos de antes?. Pues bien, el proyecto más gordo en el que estaba metido era un proyecto en el que había varios departamentos implicados, de software, de hardware, de montaje (hierros, tornillos y cables), etc, etc. En unos camiones suministrados por el ciiente (unos 10 camiones), se montan varios equipos hardware, unos comprados como GPSs, estaciones solaris, PCs con Windows, receptores de radio, .. otros diseñados y fabricados específicamente para el proyecto, bien a otras empresas, bien a otro departamento, como radiogoniómetros o exploradores de frecuencia, … y se hace mucho, pero que mucho software, para controlar todo eso y presentar datos decentes a los usuarios en cada camión. Desgraciadamente, en semejante entorno, el software es lo que menos se nota. Por mucho software en varios lenguajes (Ada, Java y C++ sobre Windows y Solaris) que lleve el sistema, siempre llama más la atención 10 camiones, repletitos de equipos en su interior y con varias antenas gigantes en su exterior.

¿Cómo hacer entregas frecuentes y funcionales al cliente en este entorno?. Teniendo en cuenta que el hardware tarda lo que tarda en llegar, que los camiones no se nos entregan hasta que hay suficiente hardware como para empezar el montaje físico y que la mayor parte importante del software no se puede integrar hasta que están los equipos físicos…. la única opción es hacer simuladores de todo y hacer "demos" más o menos frecuentemente, que el cliente vea la interfaz de usuario, la pinta que tiene, qué datos va a presentar y cómo, como se va a manejar, …. pero todo con datos simulados. Y cuando llega el tiempo de integrar realmente con los equipos hardware verdaderos y ver cómo los ejecutables que corren en los diferentes camiones se comunican entre ellos, os aseguro que es un verdadero infierno, cualquier bug puede ser debido a cualquier cosa, desde un cable mal conectado, pasando por un equipo que no funciona correctamente hasta, por supuesto, un bug en el software.

¿Y cómo haces test automáticos de todo esto? Sí, se pueden hacer test automáticos de las "chorradas", como que si un usuario introduce mal su password no se le deja entrar en el sistema, típico ejemplo de cualquier manual ágil, pero no se puede probar de forma automática y fácilmente que si dos radiogoniómetros en camiones distintos detectan un emisor de radio y se triangula su posición, aparece dibujado en el mapa de  un tercer camión (de hecho, tiene que aparecer dibujado en el mapa de todos los demás camiones). Un test automático de todo esto, eliminado el hardware y sustituyéndolo por simuladores, implica arrancar al menos tres ejecutables (uno por camión), más los simuladores si son ejecutables sueltos ya que simulan un equipo hardware, y verficar que en un mapa (o en la base de datos que hay detrás del mapa) aparece el emisor de radio detectado en la posición correcta.

Estoy mucho más de acuerdo con la filosofía ágil que con la tradicional, pero no existe la llave inglesa universal que vale para todo tipo de tuercas y  tornillos simultáneamente. Si es posible aplicarla, adelante, y si no es posible, hay que hacer lo que se pueda intentando conseguir lo mejor de ella.

Bueno, realmente exagero un poco cuando digo "he leído…", me he dejado sin leer los últimos capítulos.

La parte central del libro me ha encantado, pero la primera parte y la última me han resultado muy pesadas e inútiles, hasta el punto de dejar de leerlo en esa última parte.

Los primeros capítulos nos cuenta principalmente las ventajas de TDD, no se extiende mucho en qué es o cómo se hace TDD, sino que se extiende mucho (muchísimos) en sus ventajas. Estas ventajas son más o menos conocidas por todos (código con menos fallos, confianza en que no estropeamos nada a la hora de hacer refactoring por lo que nos cuesta menos hacerlo, etc, etc). Por ello, varios capítulos dedicados a las ventajas me parece excesivo e incluso repetitivo, ya que una y otra vez comenta las mismas ventajas.

Afortunadamente el grueso de capítulos centrales me ha parecido una maravilla. No por TDD en sí mismo, sino porque se dedica para cada tipo de proyecto diffícilmente testeable (base de datos, jsp, swing, etc) a mostrarnos los distintos frameworks con los que podemos trabajar (jdbc, hibernate, spring, jsf, tapestry, wicket, …) como las librerías útiles para hacer test automáticos en esos frameworks (mockito, clases de spring que son mock objects de interfaces java complejas, jspunit, fit, etc, etc). Lo mejor de todo esto es que no da por supuesto que conocemos cada framework o librería, sino que nos da un resumen de cada uno de ellos, qué es, para qué sirve y cómo se usa. Así que esta parte, más que para hacer test automáticos, sirve realmente para conocer de qué van todas esas siglas que oímos de continuo y a veces no sabemos qué son (jsf, spring mvc, tapestry, jsf, wicket …) y es una primera guía para saber por dónde empezar a usarlas.

Dentro de este grupo de capítulos nos habla de los test de aceptación, que son test automáticos de más alto nivel donde idealmente se considera el sistema como caja negra y se testea desde fuera automáticamente. Idealmente estos test deben estar escritos por el cliente más que por los desarrolladores, puesto que el cliente es el que sabe lo que quiere y si el test es o no suficiente. Así que, aparte de discutir en qué casos se puede/debe testear desde fuera el sistema como caja negra, o cuando se puede/debe testear justo por debajo de la interfaz de usuario, nos introduce en herramientas como fit o fitnesse.

En la última parte, la que he dejado de leer, nos muestra los problemas que podemos tener con nuestros compañeros de trabajo si intentamos convencerlos de que usen TDD, y cómo identificar esos problemas y cómo abordarlos. Pero para mí, programador principalmente, lo de las relaciones humanas no es un libro que me entretenga. Y para mí, cabeza cuadriculada, semejante texto me parece demasiado "etéreo" y evidente. Oír por enésima vez las ya consabidas frases estilo "para que tus compañeros hagan TDD, dales ejemplo haciéndolo tú" o "si te dicen que sí sin entusiasmo igual te están diciendo que no", no me parece que ayuden demasiado a pelearte con los problemas día a día. Este tipo de problemas son problemas que puedes resolver si tu forma de ser es la adecuada para ello, y los resolverás o no independientemente de que hayas leído este libro. Hay quien de forma innata es un lider y que yo sepa, no existe quien de forma innata es un anti-lider y se convierte en lider con un cursillo.

Hablando de cursillos, me ha llamado la atención (creo que tiene toda la razón), este post sobre el peligro de las certificaciones, tan de moda hoy en día http://www.javiergarzas.com/2012/09/problemas-testing.html

Y volviendo al libro otra vez, una frase traducida más o menos libremente que me ha llamado la atención "Los buenos programadores sufren un tipo especial del síndrome de déficit de atención, consistente en poner todo su empeño en usar una herramienta nueva, para abandonarla pocos meses después  y poner nuevamente todo su empeño en otra herramienta más nueva". Real como la vida misma.

Google sigue siendo una pequeña maravilla comparado con lo que había antes, tanto buscador como gmail y otras aplicaciones. También sigue siendo una maravilla comparado con otros buscadores o aplicaciones. Sin embargo, creo que va perdiendo respecto a cómo empezó.

Ahora me encuentro con frecuencia que el buscador de google es "demasiado listo" y pretende intuir qué estás buscando en vez de mostrarte resultados de lo que realmente estás buscando. Modifica las palabras "raras" que pones para buscarte las comunes (por ejemplo, si ente las palabras de búsqueda incluyes la herramienta buildr, es muy probable que te cambie y muestre resultados con la palabra "build"). También es muy frecuente que te ponga resultados de búsqueda en los que no aparece en absoluto algunas de las palabras que buscas. Quizás para búsquedas normales de gente normal sigue siendo un buscador muy válido, pero cuando un programador empieza a buscar conjuntos extraños de palabras por algún error que le ha salido a cómo hacer algo concreto y su búsqueda consiste en un conjunto extraño y heterogéneo de palabras, como "buildr nullpointer create project" (por decir algo), salen cosas que a lo mejor no tienen nada que ver con buildr, o no aparece project por ningún lado, o te cambia la palabra buildr por build (es sólo un ejemplo, no he probado a buscarlo y ver qué sale).

En cuanto a gmail, estoy hasta las narices de que me pida periódicamente mi número de teléfono móvil. No, no quiero dárselo, no me da la gana, pero él insiste, e insiste, e insiste,…

Y google+ tá como una maniega , me manda mensajitos, por ejemplo el de hoy,  indicándome que cuatro personas me han añadido a sus círculos. Bueno, me parece bien, si no fuera porque esas cuatro personas hace varios meses que me han añadido a sus círculos. Y hace quince días me había vuelto a avisar de lo mismo con las cuatro mismas personas. Debe ser alguna venganza por no querer darle mi número de teléfono móvil a gmail.

Y un "gadget" que tengo en igoogle para búsqueda de una palabra en blogs…. también "tá como una maniega", me muestra hoy lo que salió hace un mes, o no me muestra cosas. En fin, que no me parece en absoluto fiable.

Y youtube es últimamente un poco incordio. Visito la página para buscar videos o lo que sea … y cuando estoy a punto de darle al ratón para hacer click en alguno o ponerlo en marcha… el anuncio de la parte superior le da por aparecer de golpe (tarda en cargarse más que el resto de la página), desplazando todo el contenido de la página hacia abajo de golpe y haciendo que mi click caiga aleatoriamente en cualquier otro lado.

En fin, me disculpareis, pero me estoy desahogando, acabo de recibir de google+ que cuatro personas me han añadido a sus círculos, cosa que han hecho hace más de un mes algunos de ellos.