El porque de mis videos en YouTube

Hace algún tiempo empecé a grabar y subir a YouTube una serie de vídeos sobre temas técnicos. Durante este tiempo algunas personas me han preguntado el motivo de hacer estos vídeos. Y es muy simple.

En las diferentes empresas o proyectos en los que me he ido incorporando o bien de los que he tenido responsabilidades sobre la organización técnica, una de las cosas que siempre me ha parecido que no estaba muy bien resuelta ha sido el tiempo necesario para empezar a ser productivo.

El tiempo que se tarda en ponerse todo el entorno de trabajo, tanto servidor, base de datos, entorno de desarrollo, así como el tiempo que dedicas los primeros días de trabajo a documentarte.

No tanto ya por el tiempo que dedica la persona nueva sino porque además de eso suele haber una persona sentada al lado explicándole las cosas.

Por eso me he dedicado a experimentar con Wikis, máquinas virtuales, etc. Y uno de los experimentos ha sido con los vídeos.

Y si en vez de tener a una persona explicando una cosa una y otra vez lo hago solo una vez y lo grabo… ¿Es viable? ¿Es práctico? ¿Que infraestructura necesito?

Ese es el objetivo de mis vídeos en YouTube.

Innovación

A los profesionales con inquietudes nos suele gustar innovar en nuestro trabajo, pero cuando trabajas para terceros no siempre es fácil. Debemos tener muy presente que toda mejora supone un cambio, pero no todo cambio supone una mejora. Lo importante de la innovación es aportar valor al cliente. 

Cuando te encuentras trabajando para una organización que ya tiene establecidas sus herramientas y metodologías es complicado poder innovar, porque si quieres hacerlo sobre algún área ya definida por la organización vas a tener que proponer algo que realmente les aporte una sustancial mejora, ya que sino acabamos cambiando y no mejorando. Y no es fácil salvo que te encuentres trabajando para una organización con planteamientos y herramientas obsoletas.

Para matar el gusanillo suele ser más útil el buscar algún reducto donde la organización no se haya desarrollado. De esta forma con no mucho trabajo puedes conseguir proporcionar mucho valor al cliente. Es una tarea no precisamente fácil, sobre todo cuanto más organizada y moderna sea la organización, ya que tendrá cubiertos las principales áreas. 

Cual es el porcentaje adecuado de cobertura de código

En mi opinión, lo mejor que puedes hacer es olvidarte del porcentaje de cobertura de código. Me explico.

Cuando lees el libro de Kent Beck, que es el autor que puso de moda las pruebas unitarias, y que viene a ser el manifiesto de programación extrema, te das cuenta que no habla en ningún momento de porcentajes de cobertura. El lo que dice es qué hay que escribir todas las pruebas que se te ocurran, de cosas que pueden fallar, obviamente. Y una vez que el código pasa todas esas pruebas y no eres capaz de encontrar ninguna prueba más tu código ya es correcto.

A la hora de probar nuestro código existe un grupo de herramientas que son las de cobertura de código que nos ayudan en nuestro trabajo. Estas herramientas, en el caso de Java, lo que hacen es poner la máquina virtual en un modo en el que la máquina va diciendo por que líneas de código va pasando cuando se ejecuta código. De tal forma que si nosotros ejecutamos nuestras pruebas unitarias con una herramienta de cobertura de código y vemos que hay una serie de líneas de código por las cuales no se ha pasado, eso nos proporciona una información muy valiosa. Puede ser por dos motivos o bien nuestro juego de ensayo no es tan completo como nosotros creíamos y se nos ha escapado alguna casuística o bien es lo que se llama código muerto, es decir en algún momento ese código tuvo alguna utilidad pero en este momento ya no la tiene y no se usa y se puede eliminar.

El problema viene cuando se confunde un medio con un fin es decir el fin de las pruebas unitarias es asegura que código es correcto la cobertura del código es un medio. Si nos obsesionamos con los porcentajes con un 70% o 60% u 80% de cobertura es cuando estamos equivocando el medio y el fin.

Obviamente si nuestra cobertura de código es baja es prácticamente imposible que nuestro juego de ensayos sea completo ya que hay muchas líneas por las cuales no pasamos. Pero también se puede dar el caso inverso, es decir que hayamos pasado por todas las líneas de código no quiere decir que las condiciones que hemos puesto en el JUnit sean las correctas o todas las necesarias. De hecho podríamos poner como única condición el siempre valido assertTrue(true) y nuestra cobertura de código sería alta.

Es por ello que, como decía al principio, no creo que haya que darle especial importancia al porcentaje de cobertura. Si es un buen indicador pero necesita de una persona que supervise porque él nivel es bajo o si un nivel alto realmente me está asegurando la calidad.

Curriculum vs. pasión

Últimamente está muy de moda dentro del agilismo y todas estas prácticas de emprendimiento el recalcar la importancia del la pasión en el trabajo y que el currículum hoy día tiene poca validez, ya que es una herramienta 1.0 del siglo pasado.

A veces hay conceptos que cuesta un poco asimilar y aunque puedes entender que efectivamente es importante la pasión en el trabajo, no es tan fácil entender porque un currículum no es algo tan válido hoy día. Pero últimamente se han dado una serie de circunstancias que me han hecho entender cual es esa diferencia.

Yo, por ejemplo, (y no tiene nada que ver con esas circunstancias que he comentado) en mi currículum puedo poner que he dado formación y es cierto, y no lo hacía mal del todo. Pero es algo que siempre he intentado evitar, porque no me gusta. Es lo que tiene el curriculum que o mientes quitando cosas o si realmente lo que estás diciendo es la realidad, es como su nombre indica, el discurrir de la vida y yo efectivamente… he sido profesor.

Pero por ejemplo sí vemos el blog, este blog que estás leyendo, podrás darte cuenta de que cosas son las que me interesan, porque nadie me obliga a escribir lo que escribo, simplemente escribo lo que me apasiona o lo que me molesta.

Para mi esa es la validez que tiene este blog, es una forma de expresar claramente qué cosas son las que me apasionan y que cosas no. No quiere decir que todo de lo que no escriba aquí lo aborrezca hay cosas que simplemente no tengo tiempo para abordarlas y otras que si que efectivamente pues ni si ni no, las he hecho porque tocaba hacerlas.

MongoWeather: Infraestructura en la nube con RedHat OpenShift

Hoy traigo un videotutorial sobre la infraestructura para la prueba de concepto de tratamiento de datos meteorológicos con MongoDB.

Normalmente las pruebas las suelo realizar sobre máquinas virtuales, para no saturar la máquina física. Pero el otro día hablando con los chicos de RedHat que están en el trabajo me propusieron otra opción. Esta opción consiste en utilizar la nube que tiene RedHat. Al final viene a ser la misma solución salvo que en vez de tener una máquina virtual en mi máquina la tengo en la nube, con lo cual, es accesible para el resto del mundo y ya no necesito sobrecargar mi máquina.

En muy poco tiempo, unos 15 minutos, disponemos de una máquina perfectamente configurada y disponible en Internet que incluye un servidor de aplicaciones, una base de datos mongoDB y una herramienta de administración de esa base de datos en este caso rockMongo.

Todo por supuesto completamente gratis es una máquina pequeñita de un giga y 500 megas de RAM pero para la prueba de concepto es suficiente.

Espero que os guste.

Ampliando horizontes en YouTube

Hoy toca hablar de novedades en este blog, ya que recientemente he iniciado una serie de videotutoriales en mi canal de YouTube .

Desde hace tiempo he sido partidario de utilizar toda la tecnología que tenemos a nuestra mano y de forma accesible para mejorar en nuestra profesión, y uno de los puntos que siempre me ha parecido que tiene mucho margen de mejora es la parte de enseñar a la gente que se va incorporando a la empresa o proyecto.

Cada vez que entra alguien, sobre todo en proyectos grandes con mucha gente hay que andar repitiendo las mismas explicaciones, porque al final todo el mundo tiene básicamente las mismas dudas. Y ahi el hecho de hacer pequeñas grabaciones en plan screencast pueden ser muy útiles.

Así que me he animado a grabar algunas cosas, sobre todo pequeños tutoriales o trucos y además lo he realizado en nuestro idioma, ya que he visto que no hay mucho material en nuestro idioma.

Son grabaciones caseras, en las que la única inversión ha sido un micrófono un poco más profesional que el de la webcam, para que se oiga mejor. Es un micrófono chulísimo y que recoge muy bien la voz.

Espero que os guste y no dudéis en suscribiros al canal de youtube o darle a la manita para arriba si os gustan los videos.

Puntos de interrupción condicionados

Esta entrada es sobre un pequeño truco que no mucha gente conoce y que resulta bastante útil. Se trata de como tener puntos de interrupción que hagan que nuestro JBoss Developer Studio / Eclipse se pare cuando se produce una condición.

Supongamos que, por ejemplo, se nos produce un error porque en un determinado punto de nuestro programa una variable vale nulo. Pero ese valor no se da siempre, sino que es en determinadas condiciones que no tenemos claras y no siempre que pasamos por ese punto se produce el valor nulo, o estamos en un bucle, por ejemplo.

La forma de ayudarnos que tiene el eclipse es con los puntos de interrupción con condiciones.

Tomemos como ejemplo el siguiente código:

Queremos que se pare la ejecución, solo cuando la variable i vale 15. Para ello ponemos un punto de interrupción en la línea 10 y con el botón derecho mostramos las opciones del punto de interrupción.

Se nos mostrará la siguiente ventana en la que podremos indicarle que queremos un punto de interrupción condicionado y podremos escribir la condición, en este caso que i sea igual a 15
Cuando depuremos el código veremos que se nos para cuando se cumple la condición de que la variable valga 15
Espero que os haya resultado útil este pequeño truco.
Os dejo aquí un pequeño video en el que se puede ver esto mismo en ejecución. 

.

Nuestro rol como clientes y proveedores y sus paradojas

En la vida de cada uno de nosotros en la mayor parte de las situaciones somos consumidores de productos o servicios. Compramos cosas, como ropa, electrónica, etc, o bien contratamos servicios, como por ejemplo la línea telefónica.

Y normalmente somos exigentes con las compañías que nos prestan estos servicios. Es lo normal, pagamos por un producto y servicio y queremos que nos lo presten correctamente. A nadie le gusta quedarse sin cobertura en el teléfono, o que no le funcione el terminal, o que el medico no le diagnostique bien, o un largo etcetera.

A veces lo que nos ocurre como trabajadores es que no nos damos cuenta que en ese momento nosotros somos los prestadores del servicio. Y lógicamente nuestros clientes van a tener un nivel de exigencia similar al que nosotros tendríamos si fuésemos los clientes. Y se nos suele olvidar.

¿Que pensaríamos si estamos reformando la cocina de nuestra casa y el albañil cuando llega la fecha de entrega nos dice que va a tardar más? Lógicamente lo más probable es que no nos parezca bien, no vamos a disponer de nuestra cocina, con el trastorno que nos supone, y encima nos va a costar más, porque obviamente el albañil no va trabajar gratis.

Pero me he encontrado con casos en este sector de la informática en los que gente del equipo se permite plantear que se le pida más tiempo al cliente. Y lo más curioso es que luego cuando las cosas van mal y el cliente te echa se extrañan.

Pero ¿alguien mantendría o volvería a contratar al albañil que obviamente está siendo incapaz de llevar la reforma de la cocina a cabo?.

MongoWeather: Carga de la información

El siguiente paso para poder procesar los datos de la estación meteorológica con mongoDB, después de tener instalada la infraestructura, es proceder a cargar los datos.

El programa de la estación meteorológica permite exportar los datos en formato CSV, es decir separado por comas. Y este formato es soportado por la utilidad de importación de mongoDB.

Con lo que tan solo con un comando debiera de ser suficiente:

mongoimport -d weather -c weather –type csv –file ./EasyWeather.csv –headerline

Con esto le decimos que importe los datos en la base de datos weather y la coleccion es también weather. Así mismo le decimos que el formato es csv, que la primera línea tiene el nombre de los campos y cual es el fichero que queremos importar.

Con esta información nos importará los datos, pero…

Vemos que hay ciertos datos que no los ha importado correctamente.
Podríamos modificarlos en origen con algún conjuro (sed -e ‘s/ /g’ o similar) de Linux, pero vamos a darle una solución con mongoDB.
Esta solución se basa en un cursor, que recorre todos los registros y los va modificando para convertir los String en fechas.
El script es este (está también disponible en la página de GitHub):
Con este cursor creamos un string con el formato adecuado y con el creamos el objeto Date para que mongoDB lo gestione como lo que es.
Seguimos teniendo otro problema, y es que cuando no existen datos la exportación del programa de la estación meteorológica pone un texto «—«. Pero como es una substitución simple, podemos hacerlo con una update más sencilla

MongoWeather: Instalación

El primer paso para poder almacenar y tratar los datos de la estación meteorológica con mongoDB es… tener instalado el mongoDB.

Yo he utilizado para tener el servidor un CentOS versión 7. En la página de mongoDB hay instrucciones para realizar la instalación.

Solo añadir que por defecto no escucha más que en el interface localhost, es decir 127.0.0.1 Para permitir que se pueda llamar desde otra máquina hay que cambiar una linea en el fichero de configuración /etc/mongod.conf

Con esto solo tendremos que reiniciar el servidor y comprobar que se arranca correctamente.

Como cliente estoy usando roboMongo pero eso si desde una máquina windows porque con el CentOS no me dejaba instalarlo por problemas de dependencias.

En este caso ya hay ciertos datos cargados, pero eso en la próxima entrada