10 libros que todo programador debería leer

21/07/2017
Artículo original

Para mucha gente, en contra de lo que se cree, las vacaciones son el momento más temido del año, pues supone una gran presión ya que deben cumplir con aquellos propósitos que se habían hecho a sí mismos o a los demás; ¿te suena de algo? Por ejemplo, en vacaciones…

  • No tocaré el ordenador, desconectaré de mi trabajo
  • Quedaré con mis amigos, iré al cine, leeré varios libros...
  • Haré excursiones con mi familia, incluso iré a la playa.

Pero lo anterior cada año se convierte en:

  • Estás todos los días delante del ordenador. Tu respuesta es: "Pero... ¡si no estoy trabajando!. Me entretengo, solo estoy frikeando... Bueeeeno, de paso he respondido un par de correos, pero nada más" ??
  • "Yo casi que me quedo en casa, es que... siempre se me quema la espalda, id vosotros"
  • No tengo tiempo
  • ...

Aunque no tenemos el remedio mágico, sí podemos ayudarte a conseguir un equilibrio durante tus vacaciones.

Para ello te proponemos que te hagas con una buena colección de libros “clásicos” (quizá un par más actuales) que te permitirá ir a la playa con tu familia o losamigos mientras te conviertes en un gran programador. Eso sí, todos ellos en están publicados solo en inglés (excepto el de Steve Krug).

Pero no te equivoques: no vas a tocar un ordenador, pues los libros que te sugerimos no te van a enseñar ningún lenguaje ni tecnología en concreto (para eso están nuestros cursos ??). Con estos libros desarrollarás habilidades que harán que destaques por encima de los demás miembros de tu equipo, a igualdad de conocimientos técnicos.

Aquí te dejamos la lista con 10 clásicos inmortales, con conocimientos que te valdrán para toda tu carrera professional:

1- The Pragmatic Programmer

Andrew Hunt y David Thomas

Un clásico muy reconocido que te enseñará a aprender a pensar y a actuar de manera más pragmática a la hora de programar.

The Pragmatic Programmer

2- CODE: The Hidden Language

Charles Petzold

Del mítico Charles Petzold, padre de la notación húngara. CODE: The Hidden Language te ayudará a entender cómo funcionan las computadoras por dentro, y enriquecerá el modo que tienes de ver tu trabajo cada día, comprendiendo muchas cosas.

CODE: The Hidden Language

3- The Mythical Man-Month

Frederick P. Brooks

El libro que acuñó la frase "añadir más personas a un proyecto que va con retraso, hará que vaya más retrasado aún". Echa abajo un montón de mitos sobre el trabajo de desarrollador.

The Mythical Man-Month

4- Cracking the Coding Interview

Gayle Laakmann McDowell

Aunque no estés buscando trabajo le podrás sacar mucho partido pues contiene casi 200 preguntas típicas de programación que se hacen en entrevistas de trabajo, mostrando cómo resolverlas.

Cracking the Coding Interview

5- Programming Pearls

Joe Bentley

Una joyita llena de ensayos que tratan de enseñarte lecciones prácticas, independientes del lenguaje, que aparecen con los años de práctica. También enseña bastante código dentro, pero es casi lo de menos.

Programming Pearls

6- Soft Skills: The software developer's life manual

John Sonmez

Según su autor, la parte divertida de ser programador es escribir código. El resto no lo es tanto pero hay que saber dominarlo también pues igual de importante a largo plazo. Por eso este libro incluye consejos y técnicas para muchas cosas: desde cómo encontrar una buena empresa donde trabajar hasta cómo ser feliz (con un par). En cualquier caso, tiene muchas ideas útiles dentro.

Soft Skills: The software developer's life manual

7- Working Effectively with Legacy Code

Michael Feathers

Aunque el trabajo ideal de todos siempre es escribir nuestro propio código desde cero, la realidad es que mucho del trabajo que hacemos es mantener código antiguo. Hay sistemas críticos que es casi imposible reemplazar, y aplicaciones con miles de usuarios que debemos mantener. Este libro se centra en cómo abordar este tipo de trabajo.

Working Effectively with Legacy Code

8- Zen and the Art of Motorcycle Maintenance

Robert M. Pirsig

Sí, un libro de motos en la lista. Pero un verdadero clásico que vale para todo tipo de profesiones, no solo la nuestra. Escrito hace más de 40 años, en 1974, es un libro casi de filosofía, pero que nos enseña cómo se confrontan y deben ponerse de acuerdo dos formas muy diferentes de ver cualquier tecnología: la mente analítica (que se nos suele asociar a los programadores) y la romántica (se suele asociar con la mayoría de los usuarios) que es todo lo contrario y que no profundiza en nada. Filosofía apta no solo para el trabajo.

Zen and the Art of Motorcycle Maintenance

9- Clean Code: A Handbook of Agile Software Craftsmanship

Robert Martin

Hacer un programa que cumpla unas especificaciones suele ser bastante fácil. Lo complicado es hacerlo conciso, elegante, entendible y fácil de mantener de cara al futuro. En eso se diferencia un buen programador de uno malo. Este libro va sobre cómo conseguir eso y está lleno de ejemplos y casos de estudio para que te conviertas en un buen artesano del software.

Clean Code: A Handbook of Agile Software Craftsmanship

10- Don't Make Me Think (En español: No me hagas pensar)

Steve Krug

Si tu software necesita muchos manuales para poder ser utilizado... mal vamos. La tesis central de este libro es que los usuarios deberían poder utilizar el software sin tener siquiera que pensarlo. Este libro va sobre usabilidad y hacerle la vida más fácil a tus usuarios. Nada mas y nada menos. Aunque está orientado a la Web, la mayor parte de lo que explica vale para cualqueir tipo de aplicación.

Don't Make Me Think

¿Qué te parecen? ¿Ya te apetece leer alguno?

Si crees que hay uno (¡o varios!) clásicos de estos que nos hemos olvidado (sin ser de un lenguaje o plataforma de programación concretos y con sabiduría que dure en el tiempo), no te cortes y dínoslo en los comentarios.

¡Feliz verano!

Los 3 artículos que deberías leer si quieres aprender Angular

18/07/2017
Artículo original

Desde que AngularJS evolucionó a Angular (mal llamado Angular 2) nos encontramos ya por fin ante una tecnología madura, un framework estable en el que vale la pena invertir tiempo y recursos para aprenderlo bien y sacarle provecho.

Si todavía te estás iniciando y te encuentras un poco perdido, (o si en su día aprendiste AngularJS y no sabes si te vale la pena cambiarte), aquí te recopilamos algunos de los artículos sobre Angular más populares de nuestro blog y que te servirán para orientarte.

Las 10 principales diferencias entre AngularJS y Angular

https://www.campusmvp.es/recursos/post/las-10-principales-diferencias-entre-angularjs-y-angular.aspx

A pesar de tener un nombre similar, no te engañes, AngularJS y Angular no tienen nada que ver. El mal llamado "Angular 2 o Angular 4", que se llama solamente Angular, no es una nueva versión de AngularJS (también denominado Angular 1.x). Es un nuevo framework, escrito desde cero y con conceptos y formas de trabajar completamente distintos. Y es que Angular puede llegar a ser 5 veces más rápido que AngularJS gracias al rendimiento que ofrecen su sistema de inyección de dependencias jerárquico y la detección de cambios basados en árboles unidireccionales.

Las 5 principales ventajas de usar Angular para crear aplicaciones web

https://www.campusmvp.es/recursos/post/las-5-principales-ventajas-de-usar-angular-para-crear-aplicaciones-web.aspx

Angular, como en casi todo hoy en día, tiene muchos fans acérrimos y muchos detractores. Básicamente, o lo amas o lo odias. No suele haber término medio. En este post te presentamos sus 5 principales ventajas para que te formes tu propia opinión.

¿Es Angular 2, Angular 4 o simplemente Angular?

https://www.campusmvp.es/recursos/post/es-angular-2-angular-4-o-simplemente-angular.aspx

En Diciembre de 2016 se celebró el NG-BE, la primera conferencia de Angular en Bélgica. Igor Minar (jefe de desarrollo de Angular) asistió como presentador e hizo algunos anuncios interesantes relacionados con el itinerario de lanzamientos de Angular. En este artículo encontrarás información interesante para entender las versiones presentes y futuras de Angular.

Ahora, ¡a aprender Angular!

Esperamos que disfrutes leyendo estos artículos al menos tanto como nosotros hemos disfrutado escribiéndolos para ti. Y si ahora quieres ponerte en serio a aprender Angular, ya sabes, aprovecha nuestro curso. Te servirá tanto si ya conoces AngularJS y quieres actualizarte, como si partes de cero y quieres aprender a dominar el nuevo framework (el curso incluye el aprendizaje de TypeScript). ¡Nos vemos dentro del aula online!

Nueva Guía: System Administration & Security - Salary & Skills Report

17/07/2017
Artículo original

Nueva Guía: System Administration & Security - Salary & Skills Report

This kit will tell you what you need to know to earn more in system administration and security.

Diverse and rapidly changing, network administration and security is the backbone of the 21st century workplace. What are the essential skills of the modern sysadmin? Does it pay to specialize, or go polyglot? Which tech is the overwhelming top pick in the world of configuration management?

This kit also includes these valuable resources:

  • Sysadmin & Security Salary & Skills Report
  • Navigating the Threat Landscape: A Practical Guide
  • Top Tips for Securing Big Data Environments
  • Encryption as an Enterprise Strategy
Descárgala ahora

Visita la página Manuales gratuitos o consulta el catálogo completo.

Minimizar y ofuscar JavaScript desde el menú contextual del Explorador de Windows

17/07/2017
Artículo original

Antes de seguir leyendo, si no tienes claro qué es la minimización y ofuscación de código JavaScript, dale una lectura a este artículo que escribí en la web de campusMVP.

Si estás haciendo un desarrollo web Front-End medianamente grande, estarás usando con toda seguridad algún tipo de Task Runner para automatizar las principales tareas. Entre ellas, por supuesto, la generación de archivos para producción, lo cual incluye generar los archivos JavaScript minimizados y ( probablemente) ofuscados. De hecho, hoy en día es probable que estés usando Webpack con su plétora de loaders y plugins que te permiten hacer casi cualquier cosa.

Pero si estás programando algo más pequeño y rápido, muchas veces no te preocupas de usar Webpack, Gulp, o ni siquiera npm. Y que diablos: muchas veces tan solo te interesa poder pillar un archivo JavaScript cualquiera y poder minimizarlo. Sin más ceremonias.

Los editores más comunes tienen la opción de minimizar archivos de código, generalmente mediante algún tipo de plugin o extensión. Por ejemplo, Visual Studio Code (mi favorito) tiene Minify, Visual Studio usa Web Compiler, Atom tiene una plétora de plugins para hacer esto, y hasta Web Storm usa Uglify-JS por debajo.

Y es que el minimizador y ofuscador de JavaScript por antonomasia es sin duda Uglify-JS. Esta paquete npm toma un archivo .js y lo convierte en su versión minimizada, opcionalmente lo ofusca (modificador --mangle) y también puede generar archivos de mapa de código fuente (--source-map). Este es el que yo utilizo.

Usarlo desde la línea de comandos es muy sencillo, como veremos a continuación.

Usando Uglify-JS desde la línea de comandos

Para todo este tipo de herramientas es necesario instalar Node.js en nuestro equipo de desarrollo, que es lo que usan por debajo para ejecutarse. Y además usaremos npm para instalarlos.

Hoy en día es prácticamente indispensable disponer de Node.js instalado para hacer casi cualquier desarrollo web Front-End. Así que casi se puede dar por hecho que este entorno está instalado en la máquina de cualquier desarrollador actual.

Para instalar el paquete solo debemos abrir una línea de comandos y escribir:

npm install -g uglify-js

esto instalará la herramienta de manera global en nuestro equipo, para poder utilizarla desde cualquier sitio.

Ahora, para minimizar un archivo .js podemos escribir:

uglifyjs archivo.js --compress --source-map filename=archivo.min.js.map -o archivo.min.js

Esta línea de comandos lanza la ejecución del proceso e indica que se debe minimizar el archivo (--compress) generando uno nuevo con el nombre "archivo.min.js" (parámetro -o), y además generar el archivo de mapa de código fuente "archivo.min.js.map" (opción --source-map) para facilitar su depuración en producción si fuera necesario.

Si además queremos ofuscar el archivo resultante, cambiándole de nombre a las funciones privadas, variables locales, etc... de modo que se dificulte el seguimiento del código, podemos añadirle la opción --mangle, que sirve precisamente para eso:

uglifyjs archivo.js --compress --mangle --source-map filename=archivo.min.js.map -o archivo.min.js

Nota: es importante tener en cuenta que Uglify-JS solo es capaz de minimizar código ECMAScript 5, es decir, JavaScript "clásico". Si nuestro código incluye construcciones específicas de ECMAScript 2015 o posterior (ES6+), como funciones Lambda, clases, plantillas, iteradores, etc... su ejecución fallará. El motivo es que la herramienta parte de la base de que antes de pasar a producción el código ES6+, éste se va a transpilar a ES5 usando alguna herramienta como Babel. Así que tenlo en cuenta si se produce algún error.

Facilitando aún más su uso: menús contextuales en el explorador de Windows

Lo anterior, la verdad es que es muy sencillo, y no cuesta demasiado hacerlo de vez en cuando. Sin embargo no deja de ser tedioso tener que abrir una línea de comandos, acordarse de esa sintaxis y escribir la instrucción cada vez que queramos hacerlo.

Por eso, lo que yo uso es un menú contextual que me aparece directamente en el explorador de archivos de Windows cada vez que pulso con el botón secundario en un archivo con extensión .js:

Opciones en mi menú contextual

De hecho, para que no me moleste, lo tengo definido de modo que solamente me aparezcan estas opciones cuando pulso además la tecla de mayúsculas. De este modo no me estorban entre todas las opciones cuando solo quiero abrir el archivo en un editor y solo aparecen exactamente cuando los necesito: MAYÚSCULAS + Botón Derecho.

Para conseguirlo hay que tocar el registro del sistema. Para ello tenemos que abrir el programa editor de éste, regedit.exe, como administrador:

Abrir regedit como administrador

y situarnos en la rama HKEY_CLASSES_ROOT\JSFile\Shell\. Dentro de ésta debemos definir dos sub-nodos con el nombre que le queramos dar a los nuevos comandos, por ejemplo "Minimizar" y "Minimizar y Ofuscar". Dentro de éstos habrá a su vez un nuevo sub-nodo denominado "Command", que es el que contendrá el comando a ejecutar al pulsar en esa opción (uglifyjs en este caso):

Definición de un comando en el registro

El comando completo es:

cmd /c uglifyjs "%1" --compress --source-map filename="%1.min.js.map" -o "%1.min.js"

Para poder ejecutar uglifyjs, que solo funciona desde la línea de comandos, debemos llamarlo usando el ejecutable del sistema cmd.exe, que es el que lanza la línea de comandos con el comando que le pasemos a continuación. Este ejecutable tiene algunos modificadores, de los cuales nos interesan dos:

  • /k: este ejecuta el comando indicado y luego continúa la ejecución, es decir, nos deja la línea de comandos abierta. Esto solo nos interesará normalmente si necesitamos ver por pantalla el resultado de la ejecución, aunque siempre tenemos la opción de enviarla a un archivo si queremos usando el operador >.
  • /c: ejecuta el comando y termina la ejecución, por lo que ni siquiera veremos la línea de comandos al final. Este será el que utilicemos en este caso.

Además le pasamos el argumento %1, que en este contexto representa la ruta completa del archivo sobre el que hemos hecho clic con el botón secundario. Dado que no hay manera de obtener solo el nombre del archivo sin la extensión, en esta versión del comando lo que le indicamos es que genere un archivo con el mismo nombre y la extensión ".min.js" ("%1.min.js"), lo cual nos da un ".js" de más de lo habitual en el nombre. Así que si por ejemplo el archivo se llama miApp.js, obtendremos miApp.js.min.js. Y lo mismo ocurre con los mapas: miApp.js.min.js.map.

Tampoco es algo muy grave. Lo podemos dejar así o simplemente lo podemos editar (clic encima y F2 para renombrar) y quitarle el ".js" de más que tiene. Es un pequeño precio a pagar por la comodidad de usarlo de esta manera.

Para que solo aparezca cuando pulsamos la tecla de mayúsculas al mismo tiempo debemos editar el nodo "padre" y y añadirle una clave de texto vacía llamada Extended (así, como la "E" mayúscula):

Extended

Ahora repetimos lo mismo con el otro comando (simplemente añadiendo --mangle a la línea de comandos), y ¡listo para utilizar!:

Proceso de minimización y ofuscación

Para que no tengas que pasar el trabajo de meter a mano eso en el registro te lo doy ya hecho en un archivo .reg. Solo tienes que descargarlo, descomprimirlo y hacer doble-clic sobre el archivo .reg que contiene. Se meterán esas dos claves en el registro y podrás utilizarlo de la misma manera que has visto.

Solo unos recordatorios:

  • Debes tener instalado Node.js y el paquete uglify-js como hemos visto al principio.
  • Debes pulsar el botón derecho del ratón cuando saques el menú contextual o no aparecerán los comandos.
  • Puede que tarden un rato en aparecer o que tengas que cerrar todas las instancias del explorador de archivos antes de que parezcan.

¡Espero que te parezca útil!

FRIKADAS: Juegos para aprender a programar en ensamblador

13/07/2017
Artículo original

El lenguaje ensamblador es el más bajo nivel al que podemos llegar a la hora de programar.

Una computadora consta en esencia de un procesador, que es el cerebro de la máquina y que se comunica con la memoria y todos los demás dispositivos. Cada tipo (o "familia") de procesadores posee su propio conjunto de instrucciones (llamadas "instrucciones de lenguaje máquina") de bajo nivel para llevar a cabo o gestionar diversas operaciones, como leer o colocar un dato en memoria, realizar una operación aritmética o lógica, y cuestiones muy simples de ese estilo. Nada que ver con las operaciones que podemos hacer con los lenguajes y plataformas de "alto nivel" que usamos en nuestro día a día. Esas instrucciones no son más que conjuntos de ceros y unos que se le pasan directamente al procesador...

Una persona no puede programar usando solamente 0's y 1's. Sería una locura. Así que para tratar de simplificarlo y que fuese más sencillo se inventó el lenguaje ensamblador. Este lenguaje consta de una serie de palabras que representan cada una de esas operaciones sencillas que el procesador puede realizar. Gracias a él, en lugar de utilizar ristras inmanejables de ceros y unos, se pueden usar algunas palabras. Luego hay un programa "ensamblador" que traduce esas instrucciones en el código máquina que el procesador entiende.

No es una gran mejora pero supone la diferencia entre poder programar una máquina a bajo nivel o no poder hacerlo.

Uno podría pensar que el lenguaje ensamblador, siendo tan árido y complejo, no sería muy popular. Sin embargo si ves el conocido índice TIOBE de popularidad, en junio de 2017 ensamblador es el décimo lenguaje más popular de la lista, ¡por delante de Swift, Ruby, Go o Visual Basic!.

Ranking TIOBE Junio 2017

¿Cómo es posible?

Bueno, algunos hablan de la velocidad que puedes conseguir con ensamblador, pero quitando aplicaciones muy concretas esa posible ganancia no es apreciable. Pero sí es cierto que puede suponer una ventaja en muchas aplicaciones de bajo nivel en cuanto a tamaño del programa, eliminación de posibles fuentes impredecibles de inestabilidad o retardo, uso de instrucciones directas que no están disponibles en los compiladores de alto nivel... Por supuesto es indispensable para crear drivers, virus, criptografía avanzada dependiente del tiempo...

Más allá de que tengamos una aplicación práctica en la que utilizarlo, aprender al menos los rudimentos del lenguaje ensamblador puede ayudarnos a comprender muchas cosas sobre el funcionamiento de un computador:

  • Cómo ejecuta las instrucciones el procesador.
  • Cómo se representa y maneja la información en la memoria de los dispositivos.
  • Cómo se accede a los diversos dispositivos.
  • Cómo se establece la interacción entre el procesador y el Sistema operativo.

Es decir, bajo nivel, pero ayudándonos a tener los conceptos muy claros de modo que luego trabajar con lenguajes de más alto nivel nos resulte más simple y entendamos muchas cosas.

Aprender ensamblador no tiene que ser aburrido

Lo malo de aprender ese lenguaje es cómo abordarlo, pues es muy árido. Hay pocos libros (nuestro tutor Francisco Charte escribió algunos hace años, ya descatalogados), y muchos menos cursos. Y en cualquier caso, si no quieres meterte a fondo, solo aprender los rudimentos, es un poco "matar moscas a cañonazos".

Sin embargo existen otras opciones...

Quizá te sorprenderá saberlo, pero hace tiempo que existen algunos juegos que están especialmente diseñados para aprender ensamblador al mismo tiempo que nos divertimos.

A mí me sorprendió también cuando lo vi en la revista Spectrum del IEE de mayo. Me hicieron mucha gracia, me he acordado ahora y me apetece reflejarlos aquí, así que ¡vamos a ello!

Human Resource Machine

Human Resource Machine

El juego te pone en la piel de un trabajador de oficina que está entre dos cintas transportadoras. Por una de ellas llegan letras y números, y tú debes colocarlas en la cinta de salida pero cumpliendo unas determinadas reglas. Para ello te proporcionan dos elementos: el suelo (que actúa como un espacio temporal de memoria) y algunas operaciones que puedes realizar (las instrucciones). De entrada solamente tienes dos, pero a medida que superas niveles (y aprendes) aparecen más opciones.

Es muy original y con su planteamiento podrías jugar a él y no saber que estás aprendiendo ensamblador al mismo tiempo :-)

Disponible para Windows, Linux, Mac, en Steam y para la nueva Nintendo Switch por $9.99.

TIS-100 de Zachtronics

TIS-100

Este, más que un juego, es ya un simulador. Lo que simula es la interfaz de un microprocesador de los años 80.

La trama del juego es que has heredado un ordenador de los '80 que era de un tío tuyo. El chisme no funciona bien porque está corrompido. El objeto del juego es resolver ciertos puzles en ensamblador para recuperar algunas porciones de la memoria y descubrir el propósito original del aparato. Como interfaz tienes una pantalla de texto con varios nodos de procesamiento que se pasan mensajes unos a otros.

Este requiere más de tu parte para empezar y avanzar, pero la dificultad es más gradual y quizá engancha más una vez que arrancas con él. Eso sí, trae hasta manual de instrucciones, clavado a los que había hace 30 años (¡qué tiempos!).

Está disponible para Steam (Windows, Linux, Mac) por unos 6€ y para iPad por menos de 4 dólares.

Shenzhen I/O de Zachtronics

Shenzhen

De la misma casa que el anterior, este es más reciente (lanzado en noviembre del año pasado).

En esta ocasión eres un ingeniero electrónico occidental que decide irse al lugar en dónde se fabrica todo hoy en día: Shenzen, en China. Allí compras muchos componentes diferentes como memoria, micro-controladores y puertas lógicas y debes usarlos para ir construyendo diversos aparatos según los pedidos recibidos. Al igual que el anterior, unos componentes se comunican con los otros en función de las instrucciones que les vayas poniendo a cada uno. Cada componente tiene su propia hoja de especificaciones que debes leer para aprender a utilizarlo.

Palabras mayores, pero divertido :-)

Se puede conseguir para las mismas plataformas que el anterior a excepción de iPad.

En resumen

Si te gustan los juegos de "romperte la cabeza" y de paso quieres aprender los entresijos de cómo funciona un procesador, aquí tienes tres opciones estupendas que te darán horas de diversión en esta época veraniega.

Yo, el primero (Human Machine Resources), lo recomendaría incluso para personas jóvenes (¿12-14?) que tengan cierta predisposición para este tipo de pensamiento estructurado. Les ayudará a comprender mejor algunos conceptos, a desarrollar más su pensamiento lógico y ordenado, y quién sabe si quizá les abrirá una vocación profesional :-)

La manera correcta de actualizar npm en Windows

11/07/2017
Artículo original

npm, el gestor de paquetes de Node.js, se ha convertido con el tiempo en una herramienta absolutamente indispensable para cualquier desarrollador Web, especialmente para desarrolladores Front-End y, obviamente, para los que usen Node.js para el backend. A través de este gestor de paquetes y automatizador de scripts es posible instalar todo tipo de utilidades y herramientas, y es la base del tooling moderno utilizado para desarrollar (desde minimizar archivos hasta crear complejos procesos de automatización y bundling).

Conviene tener siempre la versión más reciente de la herramienta, por lo que de vez en cuando debemos actualizarlo. Si descargamos el instalador de la última versión de Node.js ya vendrá incluido, pero ¿y si, como ocurre muchas veces, solo queremos actualizar el propio npm pero no la versión de node?

Dado que npm es a su vez un paquete npm, en teoría deberíamos poder actualizarlo como cualquier otro paquete, usando el comando:

npm update -g npm

Pero esto no siempre funciona como esperábamos en Windows. El motivo es que, bajo Windows, Node.js se instala en la carpeta C:\Program Files\Nodejs e incluye también la versión "de serie" de su versión para npm, como se puede observar en esta figura:

que en realidad apunta a un código que está dentro de la carpeta node_modules de la instalación de Node.js.

Pero cuando actualizas un paquete npm con la instrucción vista más arriba, lo que hace es actualizar el paquete en la carpeta propia del usuario, en C:\Users\<usuario>\AppData\Roaming\npm, de modo que aunque la instalación de Node.js sea global, cada usuario puede manejar sus propios paquetes sin interferir con los demás.

El conflicto viene de que, cuando se instalar Node.js en el sistema, una de las opciones a añadir al PATH de Windows ambas carpetas: la de instalación de Node.js y la de los paquetes de npm:

Pero la ruta de los paquetes se instala en el PATH de usuario, y la de Node.js se instala en el PATH del sistema:

Rutas de Node en PATH

Y esto provoca un conflicto, pues el PATH del sistema siempre tiene preferencia frente al del usuario (al contrario que las demás variables de entorno, pero PATH es especial en esto). Por ello, cuando actualizas npm (guardándose la nueva versión en la ruta de los paquetes npm, del usuario), el efecto práctico es que el sistema no encuentra la nueva versión, puesto que encuentra antes el npm original que está en la carpeta de instalación de Node.js, y que venía con éste.

¿Cómo podemos solucionarlo?

Bueno, existen diversas maneras.

La primera y más sencilla sería eliminar la versión original de npm que viene con Node.js, pero no sin antes haber actualizado npm de la manera indicada al principio. Serían los dos archivos recuadrados más arriba. El problema de hacer esto es que si alguien más utiliza Node en la misma máquina y no lo ha actualizado lo dejaremos automáticamente sin el gestor de paquetes. Yo pienso que mejor no tocar los archivos originales si podemos encontrar otra solución.

La otra solución pasa por actualizar npm directamente en la carpeta original, lo cual par hacerlo bien implica una serie de pasos un tanto tediosos y que están descritos en la documentación de npm.

Para evitar tener que pasar el mal trago, como no, existe un paquete npm que nos soluciona el problema. Se trata de npm-windows-upgrade. Lo escribió el programador Alemán Félix Rieseberg cuando trabajaba en Microsoft (ahora está en Slack).

Para poder utilizarlo necesitaremos abrir una ventana de PowerShell como administrador:

Una vez en PowerShell debemos asegurarnos de que podemos ejecutar scripts de PowerShell, que por defecto vienen "capados", escribiendo esto:

Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force

Ahora ya podemos proceder. Lo único que necesitamos es instalar el paquete npm mencionado:

npm install -g npm-windows-upgrade

¡Listo! Ahora ya podemos usar esta herramienta para actualizar npm a la versión que queramos:

En la figura anterior se ve cómo compruebo la versión actual de npm (sale la 5.0.3) y cuando lanzo el actualizador me indica las versiones disponibles, a través de la cuales me puedo mover. La más reciente es la 5.2.0, que es la que escojo y pulso ENTER para instalarla. Al cabo de un rato (más largo que lo que muestra el GIF, que he acelerado en la parte de la instalación), npm queda actualizado directamente en la carpeta de Node.js.

Esta herramienta, que parece un tanto rebuscada, de hecho es tan efectiva que ahora ya es el método que recomienda el propio Node.js en la documentación para actualizar npm en Windows. Así que no hay problema por hacerlo así.

¡Espero que te haya ayudado!

¿Cómo redimensionar un reCAPTCHA con CSS?

10/07/2017
Artículo original

En este post vamos a ver cómo modificar fácilmente el tamaño de un recaptcha o de cualquier otro widget externo que tengamos en nuestra web, en el caso de que alguno de estos se ponga rebelde. Aunque no sea algo difícil, la solución no es tan obvia como te puedas creer. Si no dominas a fondo HTML y CSS seguro que te viene bien este truco (y de paso, vete planteándote hacer un curso como este).

El reCAPTCHA que sobresale

Supongamos que has implementado reCAPTCHA (el sistema de captchas de Google) para un formulario de contacto en un sitio web, el formulario está en una columna demasiado estrecha (por ejemplo, en un div) y te ocurre esto:

En realidad no hace falta que sea una columna fija muy estrecha. Te podría pasar también que, al intentar hacer responsive la web, esa columna se haga demasiado estrecha en dispositivos pequeños. Una posible solución podría ser usar la versión compacta sí, pero, ¿y si queremos resolverlo solo con CSS?

Yo me encontré en esta situación recientemente y tengo que reconocer que de entrada me frustré un por ir a lo loco y sin pensar, porque cambiándole el tamaño al iframe no conseguía nada. Pero mi sentido css-arácnido me decía que sí era posible y que en algún lado habría una solución. Lo sorprendente es que no fue Stack Overflow quien me puso sobre la pista, sino The Geek Goddess.

Primero, como paso fundamental, es hacernos la pregunta que se haría cualquier detective peliculero que se precie: Soy "Fulanito", de homicidios, esta es mi jurisdicción ¿qué tenemos?

El consejo del abuelo

Cuando te encuentres un bug en CSS o algo que no te funciona bien, no sucumbas al pánico. Intenta ver primero "qué tenemos aquí" y dividir el problema principal en partes pequeñas que se puedan ir abordando poco a poco.

Esto te puede servir tanto para hacer una web como para preparar una tarta en el horno. De nada.

A ver, que al contrario de lo que te pueda parecer, en lo que respecta a la parte front-end, el reCAPTCHA de Google no es que sea nada del otro mundo. Es como muchos otros widgets de páginas externas que puedes encontrar por ahí: un código JavaScript que escribe un iframe para cargar un recurso externo.

Pero claro, no podemos pasar con CSS a través del iframe para modificar su contenido, y sobrescribir las dimensiones de iframe por CSS tampoco parece dar resultado ya el JavaScript le escribe reglas CSS en línea, aparte de que el contenido de un iframe no se redimensiona en función del tamaño de este...

Eso no lo podemos tocar, así que, de entrada, lo mejor es plantearse qué podemos hacer en la parte que sí podemos tocar.

Redimensionando el reCAPTCHA con CSS

Si no podemos modificar nada en el elemento, ¿qué nos queda? ¿Hay algo que podríamos hacer? Pues sí. No podremos modificar el elemento per se, pero sí podemos modificar el conjunto de su representación visual (nuestra jurisdicción). Un pequeño matiz sin importancia ;-) .

¿Hay alguna propiedad de CSS que nos permita transformar la representación visual de un elemento? Sí, la hay, y se llama transform.

¿Cómo usamos transform para modificar el tamaño del reCAPTCHA?

Al implementar reCAPTCHA tenemos que definir la id del elemento en el que se va a inyectar el captcha por JavaScript. En mi caso el div se llamaba html gwd- reCAPTCHA_2 , así que me bastó con esto:

    
    #gwd- reCAPTCHA_2   {
                        transform: scale(0.84);
                        transform-origin: 0 0;
                       }
    

Si además de redimensionar el widget principal, queremos redimensionar la retícula de imágenes que hay que seleccionar a veces como paso adicional, añadiremos la id #rc-imageselect:

    
    #gwd- reCAPTCHA_2, #rc-imageselect   {
                        transform: scale(0.84);
                        transform-origin: 0 0;
                       }
    

Y el resultado:

El reCAPTCHA de Google ya con el tamaño deseado

Voilà. Limpio y fácil, ¿a que sí? :-)

La función scale() de transform nos permite, como su propio nombre indica, modificar la escala del elemento al que se hace referencia. Hay muchas otras transformaciones posibles, rotar (en uno o varios ejes), distorsionar, etc....

La propiedad transform-origin nos permite modificar por coordenadas el punto a partir del cual se realizará la transformación, que por defecto está en el centro. En este caso es 0 0, y no, no se refiere a la cerveza, sino a la esquina superior izquierda de nuestro elemento. A partir de ahí reducimos el tamaño del captcha desde el 100% hasta el 84% (0.84 en números decimales y notación anglosajona).

Si consultamos la compatibilidad en navegadores de transform veremos que es muy buena, así que probablemente no te encuentres con grandes problemas. De todas formas, en función del público habitual de tu sitio web, quizá te interese guardar la compatibilidad hacia atrás usando prefijos propietarios de cada navegador.

    
    #gwd- reCAPTCHA_2, #rc-imageselect {
                        -webkit-transform: scale(0.84);
                        -moz-transform:    scale(0.84);
                        -ms-transform:     scale(0.84);
                        -o-transform:      scale(0.84);
                        transform:         scale(0.84);

                        -webkit-transform-origin: 0 0;
                        -moz-transform-origin: 0 0;
                        -ms-transform-origin: 0 0;
                        -o-transform-origin: 0 0;
                        transform-origin: 0 0;
    }
    

Para navegadores inferiores a IE9, normalmente IE8, quizá te vaya mejor usar zoom. Y para versiones muy, pero que muy antiguas de IE (a partir de IE 5.5) puedes probar con la propiedad Matrix Filter.

¿Lo puedo usar para hacer responsive mi web con reCAPTCHA?

Sí sin problema. Simplemente escribe las reglas que te convengan en la media-query adecuada en cada caso.

Y lo mejor, este truco lo puedes usar con otros widgets

Este sencillo truco lo puedes aplicar a otros widgets de páginas externas que suelen causar estos mismos problemas porque también son iframes: por ejemplo la caja de "Me gusta" de Facebook o widgets de otras redes sociales como Twitter.

Mi experiencia en el 3er Hackathon de la Universidad de Granada

08/07/2017
Artículo original

Estos últimos cuatro días, (Viernes, Sábado, Domingo y Lunes) he participado en el 3º Hackathon de la UGR organizado por la oficina de software libre. Ha sido una experiencia más que buena, he conocido a mucha gente realmente agradable y volcada con el software libre. Aunque no conocía a nadie personalmente, el primer día ya eramos como una gran comunidad en la que se respiraba un ambiente que transmitía muy buen rollo.

El viernes se presentaron los proyectos, de los cuales lo participantes debían elegir uno con el que colaborar a lo largo del Hackathon. Paso a nombrarlos a continuación:

  1. GeoRemindMe, de Rubén Dugo y Raúl Ortega
  2. DAF-Collage, Javier Rodríguez y Simeón Ruiz.
  3. Workespeis FKP, de Pedro Serrano Prieto, Carlos García Pardillos y Andrei Corcodel Biboiu.
  4. Free Publi Displays, de Rubén Cáceres
  5. Truco, de Antonio Castillo.
  6. Pupils de Serafín Vélez y Fran Lucena.

De entre todos estos proyectos, decidí colaborar con el primero, GeoRemindMe. Lo que me llevó a conocer a Raul Jiménez, un gran informático, y por supuesto gran persona. Tras pasar estos cuatro días junto a él espero seguir manteniendo el contacto y la amistad. Por supuesto, al integrarme en este proyecto he conocido a grandes programadores como Rubén, con el que finalmente también he hecho amistad, y Javier

Desde aquí recomendar a todo el mundo que tenga la oportunidad de acudir a hackathones o eventos de este tipo que impulsan el software libre, que lo hagan. Es una experiencia fantástica en la que te relacionas con gente que tiene una forma de pensar muy parecida a la tuya, en la que se impulsa enormemente el trabajo en equipo.

En la parte técnica de este hackathon, me he dedicado a implementar algunas interfaces gŕaficas para la aplicación Android del proyecto, junto con unos cuantos adaptadores para dichas UIs.

Participar en este evento me ha servido también para ir atenuando el temor escénico que tengo a hablar en público, ya que el último día presenté los avances que se habían logrado en el proyecto, y tengo la foto que así lo demuestra (Aunque he de decir que Raul me apoyó en la presentación):

Quiero hacer una especial mención al grupo de traductoras que han trabajado duro estos días para poner al día en varios idiomas el blog de GeoRemindMe: @Rutmg1, @Nazapn, Natalia, @FernandoMeleroG, Fátima, Clara, Ana y @_AnaJi

Para que conozcáis a las personas que han colaborado en el proyecto, copio un extracto del blog de GeoRemindMe:

Ruth Moya: @Rutmg1

Salut! Soy licenciada en traducción e interpretación por la Universidad de Granada. Actualmente estudio un máster de traducción. Conocí GeoRemindMe! gracias a mi participación en el tercer Hackathon de informática. Junto con Nazareth Pérez, he realizado la traducción de la aplicación web de GeoRemindMe! al francés, enfrentándome así a la localización de software. Esta participación me ha permitido abrir mis horizontes laborales hasta límites insospechados y conocer gente con iniciativa y ganas de comerse el mundo, sobre todo si está relleno de pollo!

Podéis encontrarme en LinkedIn y en Twitter (@rutmg1)


Nazareth Pérez: @Nazapn

¡Hola a tod@s!Soy licenciada en Traducción e Interpretación por la Universidad de Granada y en la actualidad curso un máster de Traducción junto con mi compañera Ruth. Para mí fue todo un reto participar en este proyecto porque nunca antes me había tenido que enfrentar a la traducción de software y mucho menos en francés, mi segunda lengua. Haber participado en GeoRemindMe me  ha permitido conocer a gente encantadora con la que espero seguir en contacto en un futuro y de la que seguir aprendiendo.

A mi también podéis encontrarme en LinkedIn y Twitter (@nazapn)


Natalia Fernández

Hola! Soy una estudiante de 4º de Traducción e Interpretación de la Universidad de Granada. Me apunté a Hackathon porque me interesan las nuevas tecnologías y el papel que los traductores tienen en ellas. Gracias al Hackathon hemos aprendido sobre software libre, lenguaje HTML y de algunos de los magníficos proyectos que se propusieron. Me ha encantado poder ayudar como traductora en GeoRemindMe, hemos pasado un fin de semana diferente y muy divertido, así que lo recomiendo a todo aquel con ganas de aprender y de pasárselo bien.

Artículos que he traducido:

  • “Logros del 2º Hackathon y sus culpables”
  • “GeoRemindMe y otros proyectos, ¡comparemos!”
  • 3rd Hackathon: Translation+Android

Podéis encontrarme en: Linkedin


Fernando Melero: @FernandoMeleroG

Estudiante de último curso de Traducción e Interpretación de la Universidad de Granada. En este equipo he colaborado traduciendo al inglés algunos artículos del blog de GeoRemindMe. Decidí participar en este Hackathon debido a la gran importancia que cobran cada vez más las tecnologías en la traducción. Hemos aprendido algunos aspectos del software libre, así como también hemos practicado traduciendo artículos del blog y, algo muy importante, hemos hecho amigos y lo hemos pasado genial todos juntos.

Los artículos que he traducido para este proyecto han sido:

  • Conference on Internationalization of CADE, Granada
  • The University of Granada Supports GeoRemindMe!.
  • 3rd Hackathon: Translation+Android

Podéis encontrarme en Linkedin y en Twitter (@fernandomelerog).


Fátima Fernández-Palacios

¡Hola! Soy estudiante de último curso de Traducción e Interpretación en Granada intentando descubrir lo que quiero hacer en el futuro. Me apunté al Hackathon porque quería entrar en un mundo totalmente desconocido para mí, aunque en el que estaba muy interesada, ya que la localización me parece una de las ramas de la traducción más interesante. Debo decir que me ha encantado la experiencia, y que después de esto no me extrañaría seguir ligada a la localización en un futuro. Si en la actualidad el futuro para los traductores está bastante negro, por lo menos voy a hacer algo que realmente me gusta, y qué mejor que dedicarte a un sector en el que he descubrido que hay tan buen rollo (al menos lo relacionado con los pollos). Los artículos que he traducido son:

  • GeoRemindMe’s (private) beta is already here
  • Improved version 1.1
  • GeoRemindMe! becomes finalist in the EOI’s Entrepeneur Contest.
Yo también estoy en LinkedIn

Clara Fernández

Hola, soy Clara y estoy en el último año de Traducción e Interpretación de Granada. Hackathon ha sido una experiencia muy positiva. Hemos aprendido mucho y nos lo hemos pasado muy bien. He trabajado con GeoRemindMe y he conocido a la gente tan simpática que trabaja en este proyecto.

Artículos que he traducido:

  • GeoRemindMe is moving to the CADE in Granada
  • GeoRemindMe! becomes finalist in the EOI’s Entrepeneur Contest.

Ana Oñate

¡Hola! Soy estudiante de 4º curso de Traducción e Interpretación de la Universidad de Granada. En un principio, cuando me apunté no sabía muy bien de qué iba a ir el Hackathon pero como ocurre en muchas ocasiones te dejas llevar por lo que han hecho tus amigos y al final ha resultado una experiencia realmente interesante. Lo que está claro es que en la actualidad la traducción de este sector es muy importante y con tan sólo un fin de semana puedes sumergirte un poco en este mundo. Además, es una oportunidad perfecta para hacer nuevos amigos y cambiar un poco de ambiente, que nunca viene mal. Para este proyecto he traducido el artículo GeoRemindMe Adjusts the Sails.

Mi perfil de LinkedIn.


Ana Jiménez: @_AnaJi

Estudio Traducción e Interpretación en la UGR. Me enteré de que se iba a organizar en Hackathon por Twitter, y decidí apuntarme porque siempre me ha encantado cualquier tema relacionado con la informática, los videojuegos e Internet. Pensé que sería interesante y me permitiría tener un primer contacto con el ámbito de la traducción que más me llama la atención: la localización. El resultado no ha sido sólo eso, sino que además he conocido a gente nueva con la que pasar un buen rato y la experiencia ha sido muy agradable. Además, ya de primeras el proyecto de GeoRemindMe me gustó mucho, y me ha animado a seguir en este mundillo del software libre.

Para este proyecto he traducido los artículos:

  • Visit to Silicon Valley: 8 lessons we learnt
  • Sneak peak: web application
  • GeoRemindMe spread in the media
  • GeoRemindMe appears in the media
  • First team meeting.

Podéis encontrarme en Twitter y Linkedin.


Alejandro Alcalde: @ElBaulP

Hola, soy Técnico Superior en Desarrollo de Aplicaciones Informáticas y actualmente estudio el 1º curso del Grado en Ingeniería Informática. Encontré el evento del 3º Hackathon ojeando la web de software libre de la UGR y ha sido una experiencia más que buena. A parte de conocer a mucha gente y pasar un fin de semana divertido, he visto como se gestiona y se trabaja en un proyecto real y grande. Concretamente en este Hackathon me he dedicado a colaborar en el desarrollo de una parte de la aplicación para dispositivos Android. Sin duda seguiré asistiendo a eventos de este tipo y le espero seguir la pista al fantástico equipo de GeoRemindMe, al que le deseo lo mejor.

Podéis encontrarme en Linkedin, Twitter y mi blog personal.


A modo de resumen os dejo esta galería de fotos:

Os dejo otras crónicas de gente que participó en este evento:

Continuous Delivery en profundidad: pipelines de Jenkins

06/07/2017
Artículo original

Jenkins

En esta primera entrega, explicaremos cómo usar los pipelines de Jenkins con Stratio Big Data para obtener un rastreo de ciclo de vida completo, desde el equipo de desarrollo al entorno de productivo final.

Durante el “Lunch & Learn” sobre Continuos Delivery de Stratio vimos algunos de los problemas y ahora trataremos de explicarlos para que podáis comprender sin problema la naturaleza de los principales bugs y la solución que hemos implementado (algo que explicaremos en la segunda parte).

Los pipelines son código

Cada uno de nuestros pipeline está en un grupo privado de github bajo Stratio’s organization repo, donde contamos con varios elementos:

  • l.groovy
  • libvars.groovy
  • libpipeline.groovy
  • dev-project.groovy

l.groovy es el directorio principal para los métodos compartidos y se utiliza para analizar los archivos, comprobar el código, hacer compilaciones, ejecutar pruebas y crear imágenes de docker. Más de 70 métodos, la mayoría privados. El pipeline de Jenkins nos permite cargarlo de forma automática desde un repositorio jenkins interno, pero para hacerlo más fácil, nos saltamos esa opción y dejamos el archivo en github.

libvars.groovy es el directorio para las variable compartidas. Groovy permite variables sin tipo, pero algunas son con tipo para tener un mejor mantenimiento. Algunas de esas variables son constantes, comos las urls (internal nexus, gitolite o registro de docker), canales en slack y versiones predeterminadas.

libpipeline.groovy es el método principal. Decidirá qué tipo de operaciones se van a llevar a cabo en la tarea actual. Volveremos a hablar sobre este archivo más adelante.

dev-project.groovy es el verdadero pipeline. Verdadero porque carga los tres archivos anteriores, establece los valores de las variables e invoca el método principal previo. A modo de ejemplo, podemos echarle un vistazo a uno de los proyectos en código abierto de Stratio (Stratio Crossdata) que viene con comentarios sobre su objetivo:



import groovy.transform.Field

@Field String lib

node('master') { //Common element load
    def cdpwd = pwd().split('/').reverse()[0].replaceAll('@.*', '')
    lib = load "../${cdpwd}@script/l.groovy"
    l.vars = load "../${cdpwd}@script/libvars.groovy"
    l.pipeline = load "../${cdpwd}@script/libpipeline.groovy"
}

// Some metadata for checking out, identifying and messaging abouts warnings/errors
l.v.MODULE = 'crossdata' 
l.v.MAIL = 'crossdata@stratio.com'
l.v.REPO = 'Stratio/crossdata'
l.v.ID = 'xd'
l.v.SLACKTEAM = 'stratiocrossdata'
l.v.FAILFAST = true 

// Stratio is polyglot, and so are its developments. 
// We need to know what build tool we have to use
l.v.BUILDTOOL = 'maven' 

// Should we deploy to sonatype oss repository (so maven artifacts become public)
l.v.FOSS = true 

// Each PR gets statuses, as soon as each run action passes or fails
l.v.PRStatuses = ['Compile', 'Unit Tests', 'Integration Tests', 'Code Quality'] 

l.v.MERGETIMEOUT = 70  // Timeous for each kind of operation we could perform
l.v.PRTIMEOUT = 30
l.v.RELEASETIMEOUT = 30
l.v.SQUASHTIMEOUT = 15

l.v.MERGEACTIONS = { // If our git hook sent a payload related to a PR being merged 
                  l.doBuild()

                  parallel(UT: {
                     l.doUnitTest()
                  }, IT: {
                     l.doIntegrationTest()
                  }, failFast: l.v.FAILFAST)

                  l.doPackage() //Might be a tgz, deb, jar, war
                  // java-scaladocs are published to our s3 bucket 
                  // (such as http://stratiodocs.s3-website-us-east-1.amazonaws.com/cassandra-lucene-index/3.0.6.1/)
                  l.doDoc() 

                  parallel(CQ: {
                     // Static code analysis with Sonarqube 
                     // and coveralls.io (for some FOSS projects)
                     l.doCodeQuality() 
                  }, DEPLOY: {
                     l.doDeploy()
                  }, failFast: l.v.FAILFAST)

                  // And push it to our internal docker registry
                  //, for a later usage in tests and demos
                  l.doDockerImage() 
                  // A Marathon cluster deploys the previously build image
                  l.doMarathonInstall('mc1') 
                  l.doAcceptanceTests(['basic', 'auth', cassandra', 'elasticsearch', 'mongodb', mesos', 'yarn'])
                 }

l.v.PRACTIONS = { // If our git hook sent a payload about a PR being opened or synced
               l.doBuild()

               parallel(UT: {
                  l.doUnitTest()
               }, IT: {
                  l.doIntegrationTest()
               }, failFast: l.v.FAILFAST)

               l.doCodeQuality()
               // We deploy a subset of our wannabe packages to an staging repo            
               l.doStagePackage()
               // Work as packer, building a temporal docker image, so a container can be used for testing 
               l.doPackerImage() 
               l.doAcceptanceTests(['basic', 'auth', cassandra', 'elasticsearch', 'mongodb', mesos', 'yarn'])
              }

l.v.BRANCHACTIONS = { // We could receive a hook signalling a branch to be forged
                   l.doBranch()
                  }

l.v.RELEASEACTIONS = { // So we could release a final version
                    l.doRelease()
                    l.doDoc()
                    l.prepareForNextCycle()
                    // This time the image is the real deal
                    // It will end @ Docker Hub (https://hub.docker.com/r/stratio/)
                    l.doDockerImage() 

                    // Deploying again, to a production Marathon cluster
                    l.doMarathonInstall('mc2')
                    // Let the world know a new version is released, and spread its changelog
                    l.doReleaseMail() 
                   }

l.v.SQUASHACTIONS = {
                   // Currently just checks a PR statuse, rebases it, 
                   // invokes l.v.PRACTIONS, and merges the PR
                   l.doSquash() 
                  }

l.pipeline.roll()

Volviendo al libpipeline.groovy, podemos ver cómo se utilizan algunas de las variables previamente configuradas:

Algunas de las opciones que no se mencionan son las más brillantes: Antes de realizar los tests de integración y aceptación, se seleccionan, ejecutan y configuran varias imágenes de docker. Cuando finalizan los tests se destruyen los contenedores, pudiendo disfrutar de un entorno limpio para hacer pruebas.

Como ya te podrás imaginar, se pueden consultar tanto los repositorios públicos como los privados en diferentes proveedores de gits (github, gitlab, bitbucket). Podemos trabajar con maven y hacer proyectos.

Y como la mayoría de los elementos pueden ser definidos por cada equipo de desarrollo, algunos elementos pueden leerse desde cada repositorio git:

Javier Delgado es evangelista no oficial del uso de Jenkins para tareas continuas (inspection, testing, delivery), apasionado de la automatización y orador en diferentes conferencias sobre estas materias. Ingeniero informático y fiel seguidor del aprendizaje continuo, actualmente trabaja como ingeniero DevOps en Stratio, compañía de big data española-americana pionera en ofrecer a grandes empresas una transformación digital completa en torno a sus datos a través de un único producto.

Articulo original publicado en el blog de Stratio.

También te recomendamos

Simplifica en apps: una para dominarlas a todas

Automatizando el testing de web móviles: Appium + Nightwatch.js

SDKMAN!: Un gestor de SDKs para dominarlos a todos

-
La noticia Continuous Delivery en profundidad: pipelines de Jenkins fue publicada originalmente en Genbeta Dev por Javier Delgado Garrido .

Continuous Delivery en profundidad: pipelines

06/07/2017
Artículo original

Jenkins

En esta primera entrega, explicaremos cómo usar los pipelines de Jenkins con Stratio Big Data para obtener un rastreo de ciclo de vida completo, desde el equipo de desarrollo al entorno de productivo final.

Durante el “Lunch & Learn” sobre Continuos Delivery de Stratio vimos algunos de los problemas y ahora trataremos de explicarlos para que podáis comprender sin problema la naturaleza de los principales bugs y la solución que hemos implementado (algo que explicaremos en la segunda parte).

Los pipelines son código

Cada uno de nuestros pipeline está en un grupo privado de github bajo Stratio’s organization repo, donde contamos con varios elementos:

  • l.groovy
  • libvars.groovy
  • libpipeline.groovy
  • dev-project.groovy

l.groovy es el directorio principal para los métodos compartidos y se utiliza para analizar los archivos, comprobar el código, hacer compilaciones, ejecutar pruebas y crear imágenes de docker. Más de 70 métodos, la mayoría privados. El pipeline de Jenkins nos permite cargarlo de forma automática desde un repositorio jenkins interno, pero para hacerlo más fácil, nos saltamos esa opción y dejamos el archivo en github.

libvars.groovy es el directorio para las variable compartidas. Groovy permite variables sin tipo, pero algunas son con tipo para tener un mejor mantenimiento. Algunas de esas variables son constantes, comos las urls (internal nexus, gitolite o registro de docker), canales en slack y versiones predeterminadas.

libpipeline.groovy es el método principal. Decidirá qué tipo de operaciones se van a llevar a cabo en la tarea actual. Volveremos a hablar sobre este archivo más adelante.

dev-project.groovy es el verdadero pipeline. Verdadero porque carga los tres archivos anteriores, establece los valores de las variables e invoca el método principal previo. A modo de ejemplo, podemos echarle un vistazo a uno de los proyectos en código abierto de Stratio (Stratio Crossdata) que viene con comentarios sobre su objetivo:



import groovy.transform.Field

@Field String lib

node('master') { //Common element load
    def cdpwd = pwd().split('/').reverse()[0].replaceAll('@.*', '')
    lib = load "../${cdpwd}@script/l.groovy"
    l.vars = load "../${cdpwd}@script/libvars.groovy"
    l.pipeline = load "../${cdpwd}@script/libpipeline.groovy"
}

// Some metadata for checking out, identifying and messaging abouts warnings/errors
l.v.MODULE = 'crossdata' 
l.v.MAIL = 'crossdata@stratio.com'
l.v.REPO = 'Stratio/crossdata'
l.v.ID = 'xd'
l.v.SLACKTEAM = 'stratiocrossdata'
l.v.FAILFAST = true 

// Stratio is polyglot, and so are its developments. 
// We need to know what build tool we have to use
l.v.BUILDTOOL = 'maven' 

// Should we deploy to sonatype oss repository (so maven artifacts become public)
l.v.FOSS = true 

// Each PR gets statuses, as soon as each run action passes or fails
l.v.PRStatuses = ['Compile', 'Unit Tests', 'Integration Tests', 'Code Quality'] 

l.v.MERGETIMEOUT = 70  // Timeous for each kind of operation we could perform
l.v.PRTIMEOUT = 30
l.v.RELEASETIMEOUT = 30
l.v.SQUASHTIMEOUT = 15

l.v.MERGEACTIONS = { // If our git hook sent a payload related to a PR being merged 
                  l.doBuild()

                  parallel(UT: {
                     l.doUnitTest()
                  }, IT: {
                     l.doIntegrationTest()
                  }, failFast: l.v.FAILFAST)

                  l.doPackage() //Might be a tgz, deb, jar, war
                  // java-scaladocs are published to our s3 bucket 
                  // (such as http://stratiodocs.s3-website-us-east-1.amazonaws.com/cassandra-lucene-index/3.0.6.1/)
                  l.doDoc() 

                  parallel(CQ: {
                     // Static code analysis with Sonarqube 
                     // and coveralls.io (for some FOSS projects)
                     l.doCodeQuality() 
                  }, DEPLOY: {
                     l.doDeploy()
                  }, failFast: l.v.FAILFAST)

                  // And push it to our internal docker registry
                  //, for a later usage in tests and demos
                  l.doDockerImage() 
                  // A Marathon cluster deploys the previously build image
                  l.doMarathonInstall('mc1') 
                  l.doAcceptanceTests(['basic', 'auth', cassandra', 'elasticsearch', 'mongodb', mesos', 'yarn'])
                 }

l.v.PRACTIONS = { // If our git hook sent a payload about a PR being opened or synced
               l.doBuild()

               parallel(UT: {
                  l.doUnitTest()
               }, IT: {
                  l.doIntegrationTest()
               }, failFast: l.v.FAILFAST)

               l.doCodeQuality()
               // We deploy a subset of our wannabe packages to an staging repo            
               l.doStagePackage()
               // Work as packer, building a temporal docker image, so a container can be used for testing 
               l.doPackerImage() 
               l.doAcceptanceTests(['basic', 'auth', cassandra', 'elasticsearch', 'mongodb', mesos', 'yarn'])
              }

l.v.BRANCHACTIONS = { // We could receive a hook signalling a branch to be forged
                   l.doBranch()
                  }

l.v.RELEASEACTIONS = { // So we could release a final version
                    l.doRelease()
                    l.doDoc()
                    l.prepareForNextCycle()
                    // This time the image is the real deal
                    // It will end @ Docker Hub (https://hub.docker.com/r/stratio/)
                    l.doDockerImage() 

                    // Deploying again, to a production Marathon cluster
                    l.doMarathonInstall('mc2')
                    // Let the world know a new version is released, and spread its changelog
                    l.doReleaseMail() 
                   }

l.v.SQUASHACTIONS = {
                   // Currently just checks a PR statuse, rebases it, 
                   // invokes l.v.PRACTIONS, and merges the PR
                   l.doSquash() 
                  }

l.pipeline.roll()

Volviendo al libpipeline.groovy, podemos ver cómo se utilizan algunas de las variables previamente configuradas:

Algunas de las opciones que no se mencionan son las más brillantes: Antes de realizar los tests de integración y aceptación, se seleccionan, ejecutan y configuran varias imágenes de docker. Cuando finalizan los tests se destruyen los contenedores, pudiendo disfrutar de un entorno limpio para hacer pruebas.

Como ya te podrás imaginar, se pueden consultar tanto los repositorios públicos como los privados en diferentes proveedores de gits (github, gitlab, bitbucket). Podemos trabajar con maven y hacer proyectos.

Y como la mayoría de los elementos pueden ser definidos por cada equipo de desarrollo, algunos elementos pueden leerse desde cada repositorio git:

Javier Delgado es evangelista no oficial del uso de Jenkins para tareas continuas (inspection, testing, delivery), apasionado de la automatización y orador en diferentes conferencias sobre estas materias. Ingeniero informático y fiel seguidor del aprendizaje continuo, actualmente trabaja como ingeniero DevOps en Stratio, compañía de big data española-americana pionera en ofrecer a grandes empresas una transformación digital completa en torno a sus datos a través de un único producto.

Articulo original publicado en el blog de Stratio.

También te recomendamos

SDKMAN!: Un gestor de SDKs para dominarlos a todos

Simplifica en apps: una para dominarlas a todas

Diez tecnologías que los javeros amamos (o al menos hablamos bien de ellas)

-
La noticia Continuous Delivery en profundidad: pipelines fue publicada originalmente en Genbeta Dev por Javier Delgado Garrido .

Página Siguiente