Continuo con el análisis de la encuesta 2016 de Stack Overflow en donde, la verdad, estoy sacando conclusiones que no me esperaba del todo. Que el rey es JavaScript o que de lo que más abunda son desarrolladores Web, son realidades que puedo percibir en cualquiera de los proyectos en los que trabajo o colaboro.
Sin embargo, hay otras que no tenía tan claras o, incluso que pensé que eran totalmente diferentes; y las cuales quiero compartir en este tercer artículo de la serie.
Los amados, los temidos y los deseados
Mi primera sorpresa es que el lenguaje más amado en este año ha sido Rust– del cual no había oído hablar nunca – y que está orientado a la fiabilidad (seguridad de funcionamiento), la velocidad y la concurrencia; y por lo visto no es la primera vez. Si quieres saber más aquí tienes la web oficial.
Swift lo sigue de cerca, seguido de un sorprendente lenguaje funcional: F#. El cual me parece especialmente atractivo, pero no pensé que pudiera superar a Scala, aunque sea por poco.
Fijate de que dos de los cuatro lenguajes más queridos son funcionales, y ninguno tiende hacia el dinamismo de JavaScript.
No es ninguna sorpresa que a estas alturas los desarrollos en Visual Basic, WordPress y Matlab sean en los que nadie quiere caer. Y ya me sorprende que superen al afamado fabricante de dolor llamado SharePoint.
En los más deseados tenemos en cabeza de preferencias a Android, seguido de dos JavaScript: Node.js – que indica la potencia de JS en el backend y en el escritorio– y AngularJS que ha conseguido que MVC y SAP se conviertan en un estándar de facto en la Web.
Tendencias ganadoras y perdedoras
De esta gráfica la primera conclusión que saco es que los desarrolladores somos unos caprichosos que seguimos las modas, y nos encanta ir probando cosas nuevas, tener intensos debates de porqué la mía es la más larga la mejor y después abandonarlo en pos de la siguiente última moda.
Si no, no podría entender que React, lenguaje que no utiliza casi nadie como señalan los anteriores resultados de la encuesta, le saque casi 150 puntos de diferencia a Spark y más de 200 a Swift.
En los que ya no están tan de moda encuentro antiguas “balas de plata” como Haskell o Cofee Script, ahora están entrando en el oscuro y profundo pozo de las tecnologías obsoletas.
Pero, por encima de todos – y no por ser una tecnología viejuna – tenemos a Windows Phone y su imparable camino al abismo. Que en un año haya reducido su presencia en Stack Overflow más de un 65% es todo un síntoma de que, compañeros, hay que salir de este agujero corriendo, que el muerto empieza a oler.
Money, money, money
Y ahora entro en el mundo de Yuppi, ese en donde los USAmericanos hablan de sueldos que en los países castellano parlantes no son más que un brillo en el horizonte del país de la prosperidad.
Como se puede ver, según estos datos en el mundo los profesionales que más ganan son los que utilizan F#, Dart o Cassandra (en España ni en las ofertas de trabajo describen correctamente lo que son), y en los Estados Unidos un perfil que conozca Scala puede levantarse 125.000$ tan pancho.
De hecho, de esta estadística solo saco en claro lo que dice el propio Stack Overflow… que la pasta está en la Nube, y que son estos desarrolladores los que han visto más incrementado sus sueldos. Y si, además, tienes conocimientos del Stack completo, vas a estar a la cabeza del sueldo que puedes pedir.
Eso sí, en el mundo real en el que vivimos, no te van a pagar 105,000$ por muy buenísimo que seas.
Otra cosa que debes tener muy en cuenta si aún no te has especializado; en las tres principales categorías (quitando móviles que aquí ganan los de siempre) los lenguajes funcionales están siempre en el pódium. Por lo que si lo juntas con conocimientos de bases no sql como Hadoop o similares, puedes llegar a pedir un pastizal (que no te lo darán, ya verás).
¿Con qué trabajamos?
No, no es broma. Es en serio. La misma cantidad de personas programan en Notepad++ que en Visual Studio, y un poquito por detrás se queda Sublime Text.
Para mí que haya tanta gente trabajando con Visual Studio me sorprende, aunque no sé por qué al ser un excelente entorno de programación. Pero lo que me deja patidifuso es que tantos utilicen Notepad++ - está claro que tengo que echarle una larga ojeada- y que en cuarto lugar esté Vim.
Pensé que mis pesadillas universitarias con comandos como q! habían desaparecido hacía más de 25 años, pero veo que aún hay mucha gente que le debe gustar. Aunque me resisto a creer que se puede desarrollar más cómodamente que con un Eclipse o IntelliJ.
Por último, miro con cierta envidia el que finalmente OSX se halla encumbrado como el Sistema Operativo preferido para una mayoría de los desarrolladores. Si bien es cierto que, si sumo las tres versiones principales de Windows /7, 8 y 10), le sacarían más del triple.
Sigo sin tener claro por qué exactamente del éxito de máquinas tan caras a las que lo primero que se hace es ponerle un emulador de Windows, pero cada uno hace con su dinero lo que le apetece.
El resto de la encuesta ya entra en temas de trabajo, los cuales están alejados de nuestro entorno y son un brochazo grosero realizado desde la lejanía del otro lado del océano.
Ahora lo interesante sería que le dedicaras una media horita en revisar todos los resultados de la encuesta, que leyeras las explicaciones del propio equipo de Stack Overflow y que compartieras con el resto de la comunidad tus propias conclusiones.
Oracle y Google andan enredados en una incruenta batalla legal desde el 2012, por el uso por parte de esta última de 37 APIS de Java que se utilizan dentro del sistema operativo Android.
Es más, el problema no viene tanto del uso, si no del modo en que las utiliza. Ya que Google defiende que ha realizado un "uso razonable", como permite la licencia de forma gratuita. Mientras que Oracle defiende que debería estar recibiendo millones de dolares a causa del copyright.
La verdad es que el tema muestra, una vez más, la debilidad de las leyes actuales para proteger a los usuarios, que somos los que pagamos el pato siempre finalmente. Y muestra la peor cara de Oracle, que le ha faltado tiempo para intentar sacar rédito monetario de un lenguaje que se ha encontrado maduro, con su compra de Sun.
Por otro lado, es todo un aviso a navegantes y una extraña visión de negocio a medio plazo, que seguro le va a costar a Oracle más de un disgusto; viendo lo que ha sufrido la reputación de otras compañías que también se pasaron de exigentes con sus patentes.
Lo más preocupante es la posible reacción de Google si finalmente paga la multa multimillonaria que le puede caer en el juicio del próximo 5 de Mayo, ya que ha demostrado que no le tiembla el pulso de cortar los servicios a pesar del daño hecho a sus usuarios (véase la lucha de Google contra Microsoft).
Type Script 2 es la segunda versión del conjunto de extensibilidad de JavaScript que permite realizar una programación tipada, orientada a objetos y que compila en EAMC 3 o superior.
Al principio se enfrento a resistencias en la comunidad, pero poco a poco ha ido ganando usuarios hasta recibir el espaldarazo final con el anuncio por parte del equipo de desarrollo de Angular JS, que su futura versión 2 se va a programar en Type Script.
Un buena web como punto de información
Microsoft acaba de anunciar la publicación de una nueva Web de TypeScript 2, con un bonito diseño basado en la ciudad de Seattle, pero sobre todo con el objetivo de ser la fuente de información primaria de la tecnología.
Para ello lo primero que he encontrado en la página principal es el cómo descargarlo, instalarlo y configurarlo en los editores de la familia de Visual Studio (2013, 2015 y Code), y también en los que utilizan en el resto de la comunidad, como son: Sublime, Vim, Eclipse, Atom, etc.
Me ha gustado el formato en el que presenta la documentación - huyendo del terrible formato Help de Windows - de forma similar a si fuera un blog tecnológico, pero con artículos de buena calidad y detalle.
También la sección de ejemplos me parece muy interesante, sobre todo para novatos (like me) que requieren una ayuda para empezar. Si acaso señalar negativamente que son muy pocos los que hay publicados, pero en la siguiente pestaña lo resuelve.
La sección de conexiones nos lleva a sitios de interés como puede ser el repositorio GitHub del código (si, es Open Source) por si nos diera por hacer un Pull Request; a Stack Overflow, al twiter del equipo y al Blog de TypeScript para estar a la última o hacer cualquier pregunta; a un repositorio GitHub en donde puedo acceder a una colección de ficheros de definición; y un último enlace al listado de empresas que utilizan TypeScript (me sobra).
Para cerrar, una última pestaña me da acceso a algo que me gusta siempre. Un editor/ compilador/ ejecutor online de TypeScript, en donde en la caja de texto de la izquierda puedo ir escribiendo mi código, compilarlo y ver el resultado en JavaScript a la derecha, y ejecutarlo para ver un bonito "Hello World". En algunos momentos algo tan sencillo es muy útil para refrescar esa sintaxis que se resiste.
Lo primero que te voy a aconsejar es que te leas entero el especial que los compañeros de Xataka han realizado sobre el evento. Ya que este artículo tiene un enfoque mucho más técnico y funcional.
Segundo, es que son dos partes. Esta primera en la que reviso las actualizaciones más importantes de las herramientas de trabajo que se han anunciado en el Build 2016, y un segundo más orientado a Skynet…
El soporte de la versión 6.X de Apache Cordova, incluyendo una mejor integración con npm y una mejora en los mensajes de error en la Build.
Para las Universal Windows App, ahora permite escoger la versión del SDK, para así definir cuál es el Sistema operativo mínimo que requiere la aplicación. Y ha mejorado el engorro de andar introduciendo las credenciales una y otra vez al utilizar el Asistente del Store packaging.
Para el lenguaje de hombres (y mujeres) de pelo en pecho, C++, se han implementado las capacidades descritas en las librerías de C++11, C++14 y C++17, obligando a modificar el compilar para que las soporte y aprovechando para corregir unas 300 incidencias conocidas. Otra cosa interesante es que se ha integrado en el IDE el uso nativo de SQLite, base de datos por antonomasia para persistir datos localmente en movilidad.
Hablando de movilidad y C++, esta actualización permite importar proyectos Xcode en Visual Studio, y utilizar Gradle para construir artefactos para Android.
En C# aparece una nueva función que permite seleccionar un trozo de código y enviarlo a una ventana llamada “Exceute interactive” que permite lanzar y probar el código seleccionado. Y otras pequeñas modificaciones del funcionamiento del IDE como que es más “inteligente” ante mis errores tipográficos.
Ya entrando de lleno en el IDE propiamente dicho, me ha gustado la actualización automática de las extensiones (se acabó el tostón de actualizarlas a mano, si lo prefiero). Y se ha mejorado la barra de estado inferior con un comportamiento más útil al trabajar con el control de versiones.
El team explorer también mejora añadiendo nuevos comandos Git, el soporte de conectarse a repositorios Git configurados para guardar ficheros grandes (LFS), una mejora de la vista del histórico, y una página específica para Ramas (Branches). La única novedad para TFVC (el repositorio tipo TFS de toda la vida) es que se pueden añadir políticas de branch.
Pero es que, además, hay una lista más larga que un día sin pan de cambios y mejoras en rendimiento, velocidad de respuesta del IDE y corrección de errores. Además de actualizaciones de versión de la muchas de las herramientas principales.
NuGet ha sido actualizado a la versión 3.4 que tiene, para mí, la principal ventaja de funcionar en entornos Linux y Apple, y mejorar la velocidad en las operaciones. También TypeScript – mira el artículo sobre su nuevo portal -, las herramientas de Análisis de desarrollo, las SQL Server Data Tools, las herramientas de Python para Visual Studio y el SDK de Azure.
Visual Studio “15” para el nuevo Windows 10
Si, lees bien, no es una errata. Tenemos nueva versión de Visual Studio en Preview. Pero ojo, es una versión muy tierna – que solo nos pondremos los más frikis – que tiene el núcleo de .NET y poquitas cosas más.
Si acaso lo más interesante, por ahora, es que la instalación cambia y me permite configurar un poco más cómodamente las cosas que quiero y no quiero instalar.
Así, he pasado de una instalación estándar de varios Gigas, a una de poco más de 600 Mb. Ya que, como si utilizara Npm o NuGet, solamente se baja e instala las dependencias necesarias, y ninguna más.
Descargando dependencias e instalando solo lo justo
Y aquí está! Instalando junto con un Visual Studio 2015 Enterprise Update 2
Eso sí, al abrirlo, la primera sensación es que es el mismo Visual Studio 2015, pero con menos cositas. Ya que, como he comentado anteriormente, he instalado justo lo que quería. Sin añadidos extras ninguno.
Una cosa muy buena, es que si te conectas con tu cuenta Microsoft, te trae toda la configuración por defecto que tienes en la nube. Y eso en verdad es muy cómodo.
En esta segunda parte voy a revisar la inesperada deriva hacia la inteligencia artificial que ha mostrado Microsoft en esta Build 2016, con múltiples anuncios de servicios relacionados con la interacción virtual.
Vida artificial en las redes sociales
Microsoft ha presentado un nuevo concepto, que se une a los conocidos “cloud-first, mobile-first”, que se describe como “Conversation as Platform”, algo similar al concepto Cloud de PaaS pero orientado a ofrecer servicios de conversación autónomos.
Y hay que reconocer que las demostraciones de Bots funcionando sobre redes sociales y sobre Skype, nos dejaron a todos con la boca abierta. (aunque con una sensación de DejaVu con cierto clip de Office).
Centrándonos en Skype, han habilitado una nueva sección en la sección de Developer en el portal de la herramienta, que me ha permitido inscribirme para que me den acceso a la versión preview de este framework de desarrollo, que aún no está publicado.
También desde este portal puedo acceder a la documentación actual de la plataforma de desarrollo para Skype, y a una demostración de la API de Skype for Business (bastante simple, por cierto). En resumen, las demos en la Build estuvieron muy bien, pero para hincarle el diente hay que bucear bastante y esperar.
Otra url, esta me parece más interesante, es la de Microsoft Bot Framework, la cual está orientada a construir mis propios Bots sociales. Es decir, pequeñas inteligencias artificiales que pueden realizar todo tipo de acciones y comunicaciones de acuerdo a la lógica que le implemente.
Para ello, me he bajado la plantilla para Visual Studio 2015 de un proyecto Bot Application, en donde podré utilizar el novísimo Bot Builder SDK para desarrollar diálogos programados en C# o en Node.js.
Después debería poder conectarlo a las redes sociales para que interactúe con ellas por medio del Bot Connector. Y, por último -aún no está habilitado – podré publicar y compartir mis “bichitos” en el Bot Directory. En el cual ahora mismo solo hay una limitada representación de Bots de Micro, que muestran por donde podrían ir los tiros (BuildBot es desesperantemente tonto), y del que quisiera resaltar el CaptionBot.
Sin duda, lo mejor de esta página es la documentación detallada de la codificación de los Bots, con profusión de ejemplos para quien le apetezca meterse a hacer aplicaciones de Bots sociales.
API y servicios cognitivos
Si los Bots sociales me parece una interesante (y arriesgada) apuesta de futuro por parte de Microsoft, y una demostración del músculo en verdadera innovación que muestra Microsoft ante la languidez continuista de la mayoría de las compañías de software, los servicios cognitivos sí que les encuentro una utilidad directa y una excelente fuente de ingresos.
Así, por ejemplo, en el Build 2016 se hizo una demostración de unas gafas que tomaban una foto de lo que tenían delante y se lo describían verbalmente a la persona invidente que las portaba. Algo que consiguió arrancar una ovación a un público asistente más bien frío.
Pero es que el sistema de reconocimiento escénico lo he estado probando en la página del CaptionBot, en la cual subo una foto cualquiera y me hace una descripción, sorprendentemente fiable. No está a la altura de la demo, pero como ves en las imágenes es capaz de describir imágenes complejas.
Pero aún mejor son las API que Microsoft ha puesto a la disposición (gratuita por ahora) de los desarrolladores y que han mejorado mucho tanto en su capacidad de capturar información, como de describirla de una forma racional.
Por ejemplo, me parece impresionante que, de una foto mal tomada desde la ventanilla durante un vuelo, detecte que estoy en el cielo (volando), en un avión, en un ala, que hay nubes y que es de día.
Pero el conjunto de API’s no se queda solamente en las de Visión, sino que también tienes conjuntos de ellas agrupadas por temáticas.
Speech. Reconocimiento de habla.
Lenguaje. Entendimiento del lenguaje, corrección, análisis lingüístico, análisis de texto, etc.
Conocimiento. Operaciones sobre el conocimiento académico.
Búsquedas. Sobre el motor de Bing, buscar todo tipo de material.
Vuelvo a la realidad, a una realidad holográfica, con el anuncio y demostración (más bien pobre) del desarrollo de aplicaciones para las nuevas “gafotas” de Microsoft. Que, con un concepto muy diferente a las VR actuales, quieren abrir un nuevo camino en la interacción con los usuarios – esto lo he oído antes unas cuantas veces.
Y para ello se ha publicado el esperado SDK holográfico y el, más que esperado, emulador de las gafas Hololens para Windows. Hay que tener cuidado porque el emulador está basado en Hyper-V, y ya nos hemos llevado alguna sorpresa desagradable al intentar correrlo en equipos viejos.
Además, los afortunados que se puedan gastar 4000 dolares en un Kit de desarrollo, han oído con alegría el anuncio de que por fin se están realizado los envíos, y que estarán llegando a sus compradores en unos pocos días.
La otra novedad es la llegada temprana (se esperaba para finales de año) de una nueva versión de Windows 10– totalmente gratuita para usuarios actuales – y de la cual me puedo instalar a mi propia cuenta y riesgo, el SDK.
En mi caso, no lo voy a probar porque aún no me he puesto la última versión de Windows 10 Insider, y los SDK tan tempranos siempre los carga el diablo. Pero no tardará mucho en caer.
Y para ir cerrando este largo artículo, una última recomendación: darse de vez en cuando una vuelta por la página de herramientas para Azure porque te puedes llevar una sorpresa, como yo, al encontrar el Azure SDK para Visual Studio “15”, el Storage Explorer en Preview, las Azure Tools para Visual Studio Code, o las herramientas de Docker.
Si sientes curiosidad por Agile y eXtreme Programming, es muy probable que hayas escuchado en artículos y charlas que el testing es bueno, que es tu red de protección, que te hace más alto y más guapo, etc etc etc ... con lo que es probable que hayas oído nombrar el término "Mock" o "Mockear dependencias".
En este artículo, vamos a intentar aclarar un poco más la terminología que hay detrás de este y otros conceptos de testing, partiendo de la sabiduría de uno de los grandes: Martin Fowler.
Dobles de test
Fowler, en su artículo "Mocks Aren't Stubs", nos hace ver la necesidad de desambiguar este término del que tanto se abusa en la literatura y sobretodo en frameworks, acabando por convertirse en algo ambiguo y poco claro. Y es que acabamos llamándole a todo "Mock", cuando tenemos una gran variedad de lo que vamos a pasar a llamar a partir de ahora, dobles de test.
Para entenderlo mejor, vamos a partir de una definición que hace el propio Fowler y que deja claro inicialmente cual es el objetivo de los dobles de test:
"Test doubles is a generic term for any kind of pretend object used in place of a real object for testing purposes"
Así pues, un doble de test es simplemente un objeto que utilizamos en sustitución de otro cuando queremos realizar un test y no queremos romper o ir más allá del "sujeto bajo test" (a partir de ahora SUT).
Imaginemos que queremos testear una parte del código que interactúa con el API de pagos de un tercero. Ejercitar este API todo el tiempo puede ser lento, si se produce algún error puedo llegar a pensar que es culpa de mi código y, además, es probable que ni tenga disponible una plataforma de pruebas contra la que poder ejecutar mis tests sin tener que rascarme el bolsillo haciendo un pago cada vez.
Es por esto que resulta conveniente siempre probar en aislamiento el SUT. Este planteamiento, que parece sencillo de explicar, puede resultar bastante complicado en el escenario expuesto anteriormente si hacemos uso de APIs de terceros, por lo que necesito algún mecanismo que me permita contar con dobles, impostores o reemplazos de estas unidades que no quiero ejercitar durante las pruebas. Lo que necesito son pues dobles de test :)
Cuando estoy programando, uno de los principales objetivos que debería tener siempre es que el código que escriba sea lo más mantenible posible. Una manera de conseguirlo es que el código sea expresivo, claro y sencillo de leer y seguir (también conocido como Clean Code). Con esto, quiero remarcar que la intención a la hora de programar es extremadamente importante cuando desarrollamos código compartido en un equipo. En este sentido, en lugar de llamar Mocks a todos los dobles de test, lo que haremos es analizar las diferencias sutiles que existen en cada uno de los tipos y ver cómo podemos aprovecharnos de ellas para mejorar la expresividad del código.
Tipos de dobles de test
Según la clasificación de Fowler, podemos atener a varios tipos de dobles de test:
Dummy: Son dobles de test que se pasan allí donde son necesarios para completar la signatura de los métodos empleados, pero no intervienen directamente en la funcionalidad que estamos testeando. Son simplemente relleno.
Fake: Son implementaciones de componentes de nuestra aplicación que funcionan y son operativas, pero que sólo implementan lo mínimo necesario para poder pasar las pruebas. No son adecuados para ser desplegados en producción, por lo que nunca serán utilizados fuera del ámbito de un test. En este caso, un ejemplo claro sería una base de datos en memoria.
Stubs: Conjunto de respuestas enlatadas que se ofrecerán como resultado de una serie de llamadas a nuestro doble de test. Serían por ejemplo el resultado de una consulta a base de datos que puede realizar un repositorio. Es importante comentar que en este tipo de dobles únicamente atendemos al estado que tienen estos objetos y nunca a su comportamiento o relación con otras entidades.
Mocks: Dobles de prueba que son capaces de analizar como se relacionan los distintos componentes, permitiendo verificar si un método concreto ha sido invocado o no, qué parámetros ha recibido o cuantas veces lo hemos ejercitado. Aunque también pueden devolver una respuesta con un estado determinado, su foco se centra más en el análisis del comportamiento. Nos ayudan a testear pues el paso de mensajes entre objetos.
Al igual que pasa con los tests unitarios en los que todos los stacks de programación ya cuentan con su propia xUnit (jUnit para Java, nUnit para .NET, unittest para python, etc), también podemos encontrar multitud de frameworks o librerías para crear dobles de test.
A continuación vamos a ver un par de ejemplos de como usar Stubs y Mocks en JavaScript con Jasmine, ya que ofrece un montón de funcionalidades interesantes para el trabajo con dobles.
Ejemplo de uso de Stubs
En el siguiente ejemplo podemos ver como, a partir de la definición de un repositorio para la consulta de usuarios en la BD, podemos crear un stub que nos permita interactuar con este objeto sin conectar con la BD real.
Recordemos que queremos que nuestros tests sean rápidos e independientes, así que cualquier clase que se ejecute en la frontera o boundary de nuestro sistema, puede ser susceptible de ser reemplazada por un doble de test a la hora de diseñar nuestra pruebas.
Para crear nuestro Stub, jasmine nos ofrece le método spyOn(...).and.callFake con el que vamos a poder definir que cuando se llame a un método concreto de un objeto, este devuelva una respuesta enlatada como resultado.
describe("Locked users", () => {
let userRepository;
beforeEach(() => {
userRepository = {
findLockedUsers() {
return [];
}
};
spyOn(userRepository, "findLockedUsers").and.callFake(() => {
return [ 'borillo', 'ricardo' ];
});
});
it("stubs can be created over functions", () => {
expect(userRepository.findLockedUsers).toBeDefined();
});
it("stubs register function calls", () => {
let lockedUsers = userRepository.findLockedUsers();
expect(userRepository.findLockedUsers).toHaveBeenCalled();
});
it("stubs should return custom values", () => {
let lockedUsers = userRepository.findLockedUsers();
expect(lockedUsers).toEqual([ 'borillo', 'ricardo' ]);
});
});
Como podemos ver, jasmine no hace ninguna distinción entre Mocks o Stubs, y los llama a todos Spy. Como nuestro objetivo es dejar clara nuestra intención lo máximo posible, podríamos crearnos nuestro propio método de definición del Stub (stubOn) y añadir este plus de semántica al código.
Esta modificación no varía en nada los tests que ya había implementado, pero sí la forma en que se inicializan los valores antes de cada ejecución, por lo que el código quedará de la siguiente forma:
De forma similar a los Stubs, vamos a poder crear Mocks en jasmine, pero esta vez, tendremos la posibilidad de realizar comprobaciones más orientadas a comportamiento, como son si se ha llamado o no un método, con qué valores ha sido llamado o cuantas veces.
En este caso, para crear un Mock de nuestro repositorio, vamos a utilizar jasmine.createSpyObj, la cual permite definir un esqueleto inicializado con una serie de métodos a los que invocar cuando estemos utilizando el Mock (saveToStorage y remove).
Con el fin de detectar las llamadas que se realizan a este Mock, lo inyectaremos como dependencia al userService que hemos definidiso, asertando posteriormente si se han realizado o no las llamadas y qué valores se han pasado.
describe("User registration", () => {
let userRepository, userService;
beforeEach(() => {
userRepository = jasmine.createSpyObj(
'userRepository', ['saveToStorage', 'remove']
);
userService = {
register(userRepository, userName) {
userRepository.saveToStorage('db');
userRepository.saveToStorage('disk');
}
};
userService.register(userRepository, 'borillo');
});
it("mock functions should be available", () => {
expect(userRepository.saveToStorage).toBeDefined();
});
it("mock functions should be called", () => {
expect(userRepository.saveToStorage).toHaveBeenCalled();
expect(userRepository.remove).not.toHaveBeenCalled();
});
it("mock functions should receive params", () => {
expect(userRepository.saveToStorage).toHaveBeenCalledWith('db');
expect(userRepository.saveToStorage).toHaveBeenCalledWith('disk');
});
it("mock functions should be called several times", () => {
expect(userRepository.saveToStorage.calls.count()).toEqual(2);
});
});
Conclusión
Nuestros tests deben ser rápidos, independientes, expresivos y transmitir la intención de forma clara y concisa.
A la hora de crear tests que no dependan de otros colaboradores o incluso de infraestructura externa como la BD, los dobles de test pueden ser nuestros mejores aliados.
Su uso tanto para la gestión del estado con los Stubs, como del comportamiento con los Mocks, son una herramienta más que no podemos olvidar en nuestro toolkit de Agile Developers.
Una de las grandes virtudes de la Máquina Virtual de Java (JVM) es que nos da la habilidad de utilizar cualquier lenguaje que sea capaz de compilar bytecode. Existen infinidad de lenguajes que se ejecutan sobre la JVM, entre los que destacan algunos como Scala, Clojure o Groovy.
Pero desde hace unos meses, tenemos un nuevo sheriff en la ciudad.
Kotlin, el lenguaje de programación de Jetbrains
Si te mueves en algunos sectores como el desarrollo de Apps en Android, seguramente últimamente hayas oído hablar de Kotlin.
Kotlin es un lenguaje creado por Jetbrains, la empresa detrás de Intellij, el famoso IDE para Java. Es un lenguaje muy sencillo de aprender y de utilizar. Uno de sus principales objetivos es el de ofrecer una serie de características simples pero con una gran potencialidad.
Es un lenguaje orientado a objetos con algunas características funcionales.
¿Por qué surge Kotlin?
Te estarás preguntando cuál es la necesidad de crear otro lenguaje de programación. La gente de Jetbrains se hizo esa misma pregunta hace unos años, y llegaron a la conclusión de que necesitaban para sus proyectos un lenguaje que fuese mucho más expresivo que el anticuado Java para ser más productivos.
Así que ni cortos ni perezosos, cogieron el famoso libro de Joshua Bloch, Effective Java, y solucionaron con Kotlin la mayor parte de los problemas en Java que su propio diseñador había detectado.
Estas son algunas de sus características:
Es ligero: a diferencia de otros lenguajes que se construyen sobre la JVM, el equipo de Kotlin se preocupa de que su librería sea lo más pequeña posible. De esta forma es fácil de usar en entornos como Android, donde el límite de métodos siempre es un dolor de cabeza.
Es interoperable: como Jetbrains quería usarlo internamente para todos sus productos, uno de los objetivos principales era que pudieran utilizarlo con su base de código existente. De esta forma, aunque desarrollemos en Kotlin, podemos seguir utilizando todas las librerías existentes en Java. Y podemos, incluso, mezclar los dos lenguajes en un mismo proyecto.
Es un lenguaje fuertemente tipado: Aunque rara vez tendrás que indicar mientras escribes cuál es el tipo. El compilador será capaz de inferir los tipos de las variables por ti, obteniendo lo mejor de los dos mundos: un código seguro y conciso. Además, todos los tipos son objetos.
Es seguro frente a nulos: uno de los mayores problemas en Java son los valores nulos. No hay forma de especificar cuándo aceptamos que una variable pueda ser null, por lo que tendemos a tener cientos de NullPointerException inesperados. Kotlin usa nulidad explícita, lo que nos obligará a comprobar si un valor es nulo antes de usarlo.
La versión 1.0 del lenguaje fue lanzada el 15 de febrero de 2016, tras más de 5 años de desarrollo.
Sintaxis de Kotlin
Aunque aquí podría hablar largo y extenso sobre todas las diferencias que podemos encontrar entre Java y Kotlin, voy a tratar de sintetizar algunas de las más relevantes.
Properties
Al igual que muchos otros lenguajes modernos, Kotlin utiliza properties en lugar de campos para definir los miembros de una clase. Una property es lo que en Java sería un campo + getter + setter. De esta forma en nuestra clase podríamos tener algo así:
var name: String = "MyName"
Esto nos permite asignar y recoger su valor como si fuera un campo público en Java, pero con la posibilidad de sobrescribir el getter o el setter en cualquier momento:
var name: String
get() = "Name: $field"
Algunas otras cosas interesantes a ver aquí:
No es necesario usar punto y coma para finalizar las líneas
Podemos añadir código directamente a los Strings añadiendo el símbolo $ delante, de tal forma que nos evitamos cosas como el String.format() de Java.
Podemos marcar nuestras properties y variables con var, lo que significa que la variable es mutable (tiene getter y setter) o con val, que hará la variable inmutable (sólo tiene getter).
Constructor
Aunque se nos da la posibilidad de usar varios constructores, la idea en Kotlin es que utilicemos sólo uno. De esta forma, se nos da la opción de definirlo directamente tras el nombre de la clase, de esta forma:
class Contact(name: String, imageUrl: String)
Si los parámetros del constructor van a ser las propiedades de la clase, simplemente tenemos que marcarlos con val o var
class Contact(val name: String, val imageUrl: String)
¿Qué ocurre si necesitamos dos sobrecargas de contacto? Imaginemos que los contactos pueden no tener imagen. Esto se puede hacer fácilmente porque le podemos asignar valores por defecto a los parámetros de una función:
class Contact(val name: String, val imageUrl: String = DEFAULT_URL)
Desde este momento, ya podemos crear contactos de dos formas distintas:
val contact = Contact("Peter")
val contact2 = Contact("John", "http://...")
Un par de cosas a notar aquí:
Como ves, no hace falta la palabra new para crear un objeto.
No es necesario especificar el tipo de la variable que estamos creando, el compilador es capaz de inferirlo.
Data Class: las clases POJO de una línea
En Java, si queremos crear una clase de almacenamiento de estado, necesitamos definir un constructor, los campos, los getters y los setters, el toString(), el equals() o el hashCode() entre otros. Con Kotlin podemos hacer todo esto en una línea:
data class Contact(val name: String, val imageUrl: String = DEFAULT_URL)
Esta clase implementa todas esas funciones basada en las properties que define, y además añade otras características como un método copy o la posibilidad de descomposición en variables:
val (name, image) = contact
Seguridad frente a nulos
Ya hemos hablado de que Kotlin es segura frente a nulos. ¿Pero cómo funciona? Si queremos que una variable pueda ser nula, tendremos que marcar el tipo con una interrogación. A partir de ese momento, tendremos que comprobar si la variable no es null antes de poder usarla:
val contact: Contact? = null
contact.print()
El código anterior no compilará. Si queremos que funcione, necesitamos comprobar que no es null:
val contact: Contact? = null
if (contact != null) {
contact.print()
}
Otra propiedad interesante de Kotlin es el auto-casting. Kotlin hace casting automático siempre que es posible. Por ejemplo, dentro del if, el contacto se comporta como si fuera de tipo Contact y no Contact?. Esto es muy útil cuando comprobamos por ejemplo si un objeto es de un tipo. No necesitaremos hacer casting para empezar a usarlo como tal.
Volviendo al tema de la nulidad, tenemos una forma más condensada de hacer lo anterior:
val contact: Contact? = null
contact?.print()
En ese caso, la función print() sólo se ejecutará si el contacto no es nulo.
Finalmente, podemos saltarnos todas esas comprobaciones y decirle al compilador que estamos seguros de que esa variable no es null. No conviene abusar de este operador, ya que volveremos a encontrarnos con los mismos problemas que en Java si lo hacemos:
val contact: Contact? = null
contact!!.print()
Ese código fallará en ejecución, pero compilará sin problemas.
Extension functions
Las funciones de extensión son otra cosa muy curiosa de Kotlin, y que hará que tu código sea mucho más limpio. Vienen a sustituir a las típicas clases de utils con métodos estáticos que nos creamos en Java. En Kotlin se pueden añadir funciones nuevas a clases a las que no tenemos acceso de forma muy sencilla:
fun String.hassel(): String {
return "${this}hoff"
}
Como ves, tan sólo hay que indicar que la función pertenece a String, y podremos usar this en el cuerpo de la misma. Esta función añadirá "hoff" a cualquier String. Podemos usarla como si fuera una función más de la clase:
val x = "hello".hassel()
Por supuesto, esto no modifica el código real de la clase, añadirá un import a la clase donde se use. También se puede escribir en una sola línea:
fun String.hassel() = "${this}hoff"
Algunas cosas a tener en cuenta:
Las funciones se identifican con fun
Si usamos la asignación para definir la función, no hace falta especificar el tipo de retorno.
Lambdas
Las lambdas son ya muy conocidas en el mundo de la programación, ya que muchos lenguajes las incluyen. En Java, no ha sido hasta Java 8 que no se han añadido lenguaje, pero en Kotlin nos ofrecen algunas características extra.
Una lambda es básicamente una función anónima en la que definimos únicamente los parámetros de entrada y el de salida de la misma. Por ejemplo, una función que recibe un String y un entero y devuelve un String con ambos concatenados se podría definir así:
val f: (String, Int) -> String = { s, i -> "$s $i" }
Por supuesto, si estamos asignando un valor, podemos evitar especificar el tipo indicando los tipos de las variables:
val f = { s: String, i: Int -> "$s $i" }
Las lambdas se pueden pasar como parámetros de funciones. Esto hace que no necesitemos crear interfaces con un sólo método para crear callbacks o listeners, como ocurría en Java 7. Podemos hacer:
asyncTask {
if (it) {
print("Operación asíncrona realizada con éxito")
}
}
Un par de consideraciones extra aquí:
Si el último parámetro de una función es a su vez una función, lo podemos sacar de los paréntesis. Y si los paréntesis se quedan vacíos, eliminarlos. Esto nos permite escribir estas estructuras de bloque que nos ayudan crear nuestros propios DSLs.
Si la función sólo tiene un parámetro de entrada, se puede usar la palabra reservada it.
La mezcla de funciones de extensión con lambdas lleva la expresividad de Kotlin a otro nivel. Imaginemos que tenemos un objeto Database que necesitamos abrir y cerrar cada vez que escribimos en él. Con Kotlin nos podríamos crear esta función de extensión:
interface Database {
fun open()
fun close()
fun add()
}
inline fun Database.use(f: Database.() -> Unit) {
open()
f()
close()
}
Con esto ahora podemos crear bloques donde previamente se abrirá la base de datos, y se cerrará una vez que se termine. Además, como la función que se pasa por parámetro es a su vez una función de extensión, podemos usar los métodos de Database como si estuviéramos dentro de la clase:
db.use {
add("item1")
add("item2")
}
Muchas más características
Por no hacer este artículo mucho más extenso, te cuento algunas otras características que podrás encontrar en Kotlin:
Las interfaces pueden tener código: de esta forma, puedes extraer código común a interfaces sin sentirte obligado a usar herencia. Eso sí, las interfaces no pueden tener estado, por lo que cualquier property que declares necesitará ser sobrescrita por quien la implemente para darle un valor.
Las colecciones pueden usar operaciones funcionales: aunque las colecciones de Kotlin son wrappers de las de Java para maximizar la compatibilidad con otras librerías, están supervitaminadas. Podrás hacer decenas de operaciones sobre ellas usando toda la potencialidad de las lambdas, como filter, sort, map, reverse y un largo etcétera.
Se pueden sobrescribir los operadores, de tal forma que tus clases pueden hacer uso de ellos de la forma que necesiten. No se pueden añadir más operadores que los definidos por defecto.
La delegación de propiedades es otra característica muy interesante, que permite delegar el valor de una propiedad a otra clase. Gracias a esto, podemos tener propiedades lazy, u obligar a que los setter tengan ciertas condiciones, o ejecutar una acción cuando el valor se modifique...
Conclusión
Si estás acostumbrado a trabajar con Java, sobre todo si te encuentras en entornos tan restrictivos en cuanto a versión de Java como es Android, encontrarás en Kotlin un gran aliado.
Empezar con Kotlin es muy fácil, simplemente descarga IntelliJ y crea un nuevo proyecto Kotlin. A partir de ahí podrás empezar a probar todo lo que he ido tratando en este artículo.
¿Qué te parece Kotlin? ¿Crees que es un lenguaje con posibilidad de hacer frente a los ya existentes en la JVM?
Seguramente estás un poco harto de tu empleo actual. Tienes un salario absurdo, tu jefe no valora lo que haces, a tu empresa sólo le importa vender y la parte de desarrollo es una carga y, en definitiva, cuando llega el domingo por la noche te acecha la gran depresión.
Es muy normal en los países latinoamericanos. En muchas empresas aún existe la cultura de que lo importante son los números, y dejan la calidad del software a un segundo plano. Su única métrica es que cuanto más rápido acabes tu trabajo, mucho mejor.
Por tanto, te quedan dos opciones: o te acabas uniendo al clan de los vendedores, o te quedarás comiendo marrones y con un sueldo ridículo el resto de tu vida. En realidad hay una tercera: escapar.
Para ello, seguramente vas a necesitar prepararte muy bien, porque lo que hayas aprendido en una cárnica de este tipo no te va a servir de mucho para conseguir un empleo digno. Necesitas un plan de acción sólido para tus próximas entrevistas.
1. Ten muy claro lo que buscas
Necesitas conocerte a ti mismo primero, para luego conocer lo que esperas de tu nueva empresa
Este es el primer paso, ¿a qué tipo de empresa quieres moverte? Para eso tienes que responder a unas cuantas preguntas. Necesitas conocerte a ti mismo primero, para luego conocer lo que esperas de tu nueva empresa.
¿Qué tipo de vida quieres tener?
Mucha gente no se ha preguntado nunca algo tan esencial. ¿Por qué quieres quieres evolucionar profesionalmente?¿Cómo quieres que sea tu vida?
A lo mejor tu pasión es ser el mejor programador del mundo, aunque ello implique trabajar 14 horas al día y no ver a tu familia.
O por el contrario, quieres tener más tiempo para ti, o un horario más flexible, y te interesa buscar un trabajo en remoto desde casa.
O puede que lo único que te mueva es el dinero, y mejor cuanto mayor sea el salario.
Todo es igual de digno, pero es importante tenerlo claro. Piensa principalmente qué es lo que quieres que la empresa te aporte en este momento para tu plan a largo plazo. Si quieres salir de una cárnica, lo que te interesará será entrar en una empresa donde aprendas mucho, independientemente de horarios y salarios: un equipo de gente muy buena, donde se apliquen buenas metodologías de trabajo y se luche por código de calidad.
Durante la entrevista, presta atención a las señales de alerta roja
Durante la entrevista, trata de detectar esas señales que demuestran si una empresa se toma en serio el desarrollo de software
Las entrevistas no están solo para que la empresa te conozca a ti. Es también tu momento para que tú conozcas a la empresa.
No me quiero entretener mucho en este punto, porque hace poco que publiqué una guía gratuita con todas las señales a tener en cuenta, pero básicamente pregunta:
Cómo gestionan sus proyectos
El tipo de herramientas que usan
Cuáles son las metodologías que utilizan para asegurar la calidad del software
Cuál es la cultura de la empresa
Si durante la entrevista eres capaz de entender cómo es el día a día de la empresa, te será mucho más fácil estar seguro de si es el lugar ideal para ti en este momento.
2. Necesitas mejorar tus conocimientos
Cuanto antes asumas que no vas a dejar de estudiar en lo que te queda de vida, mucho mejor.
¿Qué conocimientos necesitas adquirir? Esta es una pregunta difícil. Va a depender mucho del tipo de empresa al que te enfoques, y de lo que ellos necesiten. Pero sí que está claro que la mayoría de las empresas en las que te interesa estar van a buscar en ti un perfil similar.
La hiperespecialización es la clave
Si quieres que te contraten en una buena empresa con un buen salario, vas a necesitar ser muy bueno en algo. El problema de saber un poco de todo y mucho de nada es que te va a ser muy difícil destacar sobre la competencia. Y saber mucho de todo en nuestro sector es inviable, evoluciona demasiado rápido como para poder estar al día de tanto cambio.
Por ello mi recomendación es que busques algo que te apasione y te enfoques en ser el mejor en ello.
Hoy en día, incluso especializarse en una tecnología puede ser demasiado genérico. Intentar ser el mejor en Android (por poner un ejemplo) puede ser complicado, pero puedes especializarte en crear interfaces de usuario increíbles, o ser el que más sabe de arquitecturas en Android, o el que mejor domina ciertas partes del SDK.
Incluso aunque no busquen esa especialización tan concreta en ti, destacarás mucho más si eres el mejor en algo.
Eso no significa que no debas saber un poco de todo
No nos engañemos, la hiperespecialización es necesaria pero no suficiente. Aunque sepas mucho de algo en particular, vas a necesitar conocer conceptos básicos de desarrollo que aplican a cualquier ámbito. Te tienen que sonar estos temas:
Calidad de código: clean, SOLID, patrones de diseño, arquitecturas, testing, refactoring...
Como digo, no tienes que dominarlo todo, pero sí que cuando te hablen de ello sepas defenderte.
El problema de saber un poco de todo y mucho de nada es que te va a ser muy difícil destacar sobre la competencia.
Además, esta base de conocimientos más genérica es la que te permitirá pivotar con facilidad en el futuro. En un mundo tan cambiante, vas a necesitar reinventarte cada pocos años (da igual que seas programador o charcutero), así que esos conocimientos generalistas te van a ayudar no sólo a ser buen profesional hoy, sino a poder seguir dedicándote a esto dentro de muchos años.
Y todo ayuda, incluso temas que se alejan más de la programación, como pueden ser el marketing online, visibilidad, temas de diseño... Cuanto antes asumas que no vas a dejar de estudiar en lo que te queda de vida, mucho mejor.
3. Haz que te descubran
Todo producto necesita una buena campaña de marketing para venderse bien. En este caso tú eres el producto.
Lo de echar curriculums en las ofertas de trabajo que te interesen está muy bien, pero no debería ser tu principal estrategia. Cuando eres tú el que envía el curriculum estás admitiendo una necesidad y eres tú la parte débil del proceso de selección.
¿Y si pudiéramos invertir el proceso? ¿Y si en vez de ser tú el que busca, consigues que te busquen a ti? En nuestra profesión, esto es muy sencillo. Sólo tienes que rellenar tu perfil de LinkedIn y esperar a que hordas de recruiters se abalancen sobre ti. Pero eso no significa que los empleos que te ofrezcan sean mucho mejores que lo que tienes ahora.
Si realmente quieres acceder a empresas de calidad, necesitas posicionarte en el sector como un referente. Hay profesionales muy buenos que se quedarán toda la vida en malas empresas con sueldos de risa, mientras que otros algo menos buenos lograrán mejores resultados. Puede ser injusto, pero el mundo capitalista funciona así.
Todo producto necesita una buena campaña de marketing para venderse bien. En este caso tú eres el producto, y tienes que conseguir que tus posibles compradores te conozcan y sepan de tus cualidades antes siquiera de contactar contigo. Con esto no te estoy diciendo que mientas: tienes que ser muy bueno y además tener pruebas que lo demuestren.
El blog debe ser el centro de mandos de tu presencia online
¿Cuáles son las mejores herramientas?
El blog: debe ser el centro de mandos de tu presencia online. Si alguien quiere conocerte, podrá encontrar tu blog, ver sobre qué hablas, qué es lo que conoces y cómo mueves a la gente que te sigue. Un blog es muy importante por muchas razones, pero en este caso la persona que te entreviste seguramente buscará tu nombre en Google, y si encuentra un blog con contenido de calidad, sumarás muchos puntos.
Github: algunos lo llaman el curriculum del siglo XXI. No hay mejor forma de saber cómo programa alguien que entrar en su Github a leer su código. Si tienes un blog, lo más sencillo es crear repositorios con ejemplos para tus artículos.
Presencia offline: te surgirán muchas oportunidades si asistes a eventos, te dejas ver, participas y, por supuesto, si das charlas. Aunque nuestro mundo sea muy online, sin duda el networking sigue siendo una de las herramientas más efectivas para darte a conocer.
Lo mejor de todo esto es que, además de mejorar como profesional, conocerás a mucha gente como tú. Los eventos son una de las actividades más gratificantes y divertidas que puedes hacer, y conseguirán que empieces a ver tu profesión como una pasión, que al final es a lo que tienes que aspirar.
4. La temida prueba de código
Si es una empresa seria, seguramente te acabarán haciendo una prueba de código. Este es uno de los momentos más complicados en cualquier entrevista, y no existe una regla fácil para estar preparado.
Primero porque muchas empresas lo enfocan mal: se limitan a hacer preguntas muy teóricas que previamente han tenido que preparar buscando ellos mismos por Internet, pero esperan que sus entrevistados las resuelvan con su ingenio. Al final lo que se debería valorar es que esa persona encaja en el equipo y conoce lo que se usa en el día a día. Pero si algo lo puede resolver Stackoverflow, no tiene mucho sentido preguntarlo.
Y segundo, porque aquí cada empresa te preguntará lo que le parezca, y no tienes forma de estar preparado para todo. Mi recomendación es que vuelvas al punto 2, adquieras un poco de conocimientos sobre todo aquello (los temas de código limpio, SOLID, arquitecturas... son bastante recurrentes) y no te obsesiones con la prueba de código.
Si conoces a alguien que haya pasado el proceso, será mucho más fácil. También hay libros que te pueden ayudar a prepararte, pero a mí todo esto me parece tan artificial que no tengo claro que tenga mucho sentido. Sé tu mismo, demuestra tus conocimientos, y si no les cuadras lo mejor es seguir buscando.
Al final todo se reduce a esto: si quieres estar en una gran empresa necesitas ser un gran desarrollador.
Ser el mejor candidato tan solo consiste en ser mejor profesional
Al final todo se reduce a esto: si quieres estar en una gran empresa necesitas ser un gran desarrollador. Así que, si no lo estás haciendo ya, empieza a buscar 1-2 horas extra al día para dedicarlas a mejorar en todo lo que hemos hablado aquí.
No es un proceso rápido, pero será duradero, y de paso, muy probablemente reconectarás con tu profesión. Te darás cuenta de que el desarrollo de software es apasionante, y de que existen empresas donde merece la pena trabajar y que se toman en serio la programación y la calidad del código. Y si no, igual es momento de que cambies totalmente de profesión.
¿Se te ocurre alguna otra recomendación para prepararte para una entrevista? Cuéntanos en los comentarios.
webpack es una herramienta de agregación de recursos para aplicaciones web que permite generar una distribución única a partir de un conjunto establecido de assets.
Entre los recursos que es capaz de gestionar webpack, podemos encontrar formatos soportados por defecto como HTML, JavaScript, CSS, así como otros formatos que necesitan ser transformados como SASS, CoffeeScript o Jade.
Cuando trabajamos en un proyecto web, en un modo de funcionamiento más tradicional, es habitual partir de un fichero HTML con ficheros JavaScript y CSS relacionados mediante los tags script, link o style.
El problema suele ser que, a medida que las dependencias crecen y el desarrollo se complica, aumenta el número de assets a ser incluidos en el HTML y con ello el número de peticiones que el navegador debe realizar al servidor para cargar la página, haciendo que el rendimiento se vea perjudicado ostensiblemente.
Con webpack definiremos un único pipeline de procesamiento de recursos, obteniendo un único fichero empaquetado y minificado con todos los recursos necesarios para nuestro desarrollo.
En este aritículo examinaremos a fondo webpack, centrándonos en los principales casos de uso con los que nos podemos encontrar.
Instalación
webpack utiliza NodeJS, por lo que tenemos que poder ejecutar previamente (cualquier versión actual de NodeJS servirá):
$ node -v
v5.10.1
Por otra parte, vamos a instalar webpack mediante NPM, por lo que también lo deberemos tenerlo operativo:
$ npm -v
3.8.3
Con NodeJS activo y funcionando, ya podemos instalar webpack para su uso en línea de comandos:
$ npm install webpack -g
NOTA: Para usar una dependencia en la sección de scripts del package.json, no es necesario instalar esta dependencia como global con -g. En este caso, con un npm install convencional es suficiente al enlazarse siempre las dependencias en el node_modules/.bin.
Otro punto importante es que instalar un paquete como webpack de forma global hace que no tengamos un excesivo control sobre la versión que estamos utilizando. Si omitimos el flag -g, webpack se instalará en nuestro directorio de trabajo y tendremos que ejecutarlo de la siguiente manera:
$ node_modules/.bin/webpack
Creación de un proyecto simple
Antes de nada, inicializamos el proyecto:
$ mkdir webpack-simple
$ cd webpack-simple
$ npm init -y
NOTA: Como recomendación, es interesante añadir al package.json el atributo "private": true para que este módulo nunca pueda ser subido a un repositorio NPM público.
A continuación, debemos instalar la dependencia de webpack en el proyecto con:
$ npm install webpack --save-dev
NOTA: Si eres un fan de la linea de comandos, recuerda que NPM tiene un modo abreviado para lanzar instrucciones. Por ejemplo, el comando anterior podría simplicarse de la siguiente forma: npm i webpack -D
Para nuestro primer ejemplo "simple", vamos a crear un fichero app.js con un contenido sencillo:
console.log('Webpack rocks!!');
Y un index.html desde el que se incluya el resultado de ejecutar webpack sobre estos assets:
Si ahora ejecutamos webpack en línea de comandos, podremos generar el fichero bundle.js y ya podremos cargar index.html en nuestro navegador y comprobar la consola para ver el mensaje que hemos generado:
$ webpack app.js bundle.js
Por último, podemos registrar como script en NPM el comando que acabamos de ejecutar en línea de comandos, con el fin de simplificar el acceso al mismo, quedando el package.json como sigue:
NodeJS implementa un sistema de definición e importación de módulos conocido como CommonJS. De forma muy resumida, CommonJS permite que podamos exportar funciones y objetos complejos desde un fichero JavaScript o módulo, para luego importarlos y poder así reutilizarlos donde sea necesario mediante el uso de exports y require.
Así pues, podemos tener un fichero messenger.js con el siguiente contenido y exportar la función hola mediante module.exports:
module.exports = function hola(valor) {
console.log('Hola ' + valor);
}
De esta forma, podemos usar posteriormente este módulo y la función exportada desde nuestra aplicación principal app.js mediante require:
var saluda = require('./messenger.js');
saluda();
Como comentaba al principio del apartado, este mecanismo está soportado por NodeJS, pero no tenemos una forma nativa de utilizar CommonJS en los navegadores (al menos hasta que todos implementen ES6 modules).
Para conseguir esta modularización y encapsulación de nuestro código, podemos optar por utilizar el Module Pattern o delegar en herramientas como webpack o browserify para que nos provean de esta funcionalidad en el navegador.
Para ponerlo en práctica, crearemos un nuevo proyecto llamado webpack-modules siguiendo el proceso de configuración del ejemplo anterior (crear directorios, npm init e instalar dependencia de webpack).
A continuación, aplicaremos los cambios descritos (cambiamos el app.js y creamos el messenger.js) y ejecutaremos npm start para lanzar webpack y generar así el resultado final:
Si ahora abrimos el fichero index.html con el navegador, veremos el mismo resultado de antes por consola, pero esta vez la lógica ejecutada ha sido importada desde el módulo correspondiente.
Si tienes curiosidad por ver como webpack ha obrado el milagro de los módulos, edita el fichero generado bundle.js y verás todo el montaje que hace falta :)
Gestión de la configuración
Como hemos visto, es posible llamar al comando webpack con los parámetros necesarios para realizar el procesamiento. En cualquier caso, a medida que ajustemos su funcionamiento con más opciones, será mucho más sencillo definir todas las configuraciones en un fichero único que webpack sea capaz de cargar cuando lo lancemos.
Este fichero de configuración se suele llamar webpack.config.js y una definición básica del mismo puede ser:
Con este fichero creado en nuestro directorio de proyecto, podremos ejecutar webpack sin pasarle ninguna opción y él mismo cargará automaticamente el fichero de configuración con las opciones definidas.
Loaders: Hojas de estilo CSS
Una de las premisas que sigue webpack es que cualquier recurso utilizado en la aplicación debe definirse y ser tratado como un módulo, independientemente de si es un fichero JavaScript, CSS o cualquier otro recurso. Ya se que suena un poco raro, pero es más fácil de lo que parece :)
Esto quiere decir que, si queremos que nuestros estilos CSS sean minificados e incluidos en la distrubición generada, tendremos que hacer un require de estos ficheros desde el punto de entrada principal (app.js en nuestro caso) o incluirlos como "entry point" (lo mismo pasará si queremos incluir alguna imagen, por ejemplo).
De esta manera, webpack los procesará y permitirá su aplicación y carga desde JavaScript directamente, evitando el tener referenciados los ficheros CSS mediante link o style dentro de la página HTML principal y minimizando así el número de peticiones que se hacen al servidor para completar la carga de la página.
Vamos a ver como funciona realmente!!
Partiendo de nuestro ejemplo de uso de módulos webpack-modules, vamos a crear un proyecto nuevo llamado webpack-css (ya sabes, hay que inicializar el proyecto como en todos los casos anteriores).
Para este proyecto, vamos a intentar incluir en el pipeline de procesamiento de webpack el tratamiento de los estilos CSS que hemos definido en el fichero style.css:
body {
background-color: #ddd;
color: red;
}
Para ello y si todo en webpack es un módulo, tendremos que modificar el app.js y hacer un require de nuestro fichero CSS. Sí, has oido bien, un require de CSS:
require('./style.css');
var saluda = require('./messenger.js');
saluda();
Es bastante curioso, pero de esta forma va a intentar procesar este módulo mediante uno de los loaders que tenga cargados. Como inicialmente sólo contamos con un loader para ficheros JavaScript que viene por defecto, si después de esta modificación intentamos ejecutar el comando webpack, se producirá un error indicándonos esta situación:
Hash: b07e232caa73ce9c11c0
Version: webpack 1.12.1
Time: 46ms
Asset Size Chunks Chunk Names
bundle.js 1.75 kB 0 [emitted] main
[0] ./app.js 75 bytes {0} [built] [1 error]
[1] ./style.css 0 bytes [built] [failed]
[2] ./messenger.js 72 bytes {0} [built]
ERROR in ./style.css
Module parse failed: /base/webpack/webpack-css/style.css Line 1: Unexpected token {
You may need an appropriate loader to handle this file type.
| body {
| background-color: #ddd;
| color: red;
@ ./app.js 1:0-22
Para solucionar el problema, necesitamos hacer dos cosas. La primera es instalar el loader correcto utilizando NPM:
npm install css-loader style-loader --save-dev
Y la segunda es configurar webpack para cargar este módulo de procesamiento CSS cuando procese nuestro pipeline.
Como hemos visto en el apartado anterior, esto lo podremos hacer modificando el fichero webpack.config.js, el cual quedará de la siguiente forma:
NOTA: Cuando veamos en un loader más de un término separados por una admiración, entenderemos que se van a aplicar varios loaders encadenados comenenzando siempre de derecha a izquierda.
Si ejecutamos de nuevo el comando webpack, el resultado será correcto:
Si queremos ver en detalle todos los módulos intermedios que ha tenido que cargar webpack para completar la tarea de incluir nuestro CSS, tendremos que incluir el paràmetro --display-modules:
No estaría de más revisar el contenido del bundle.js. Ahora podremos ver que hay mucho más código y que hay una sección dedicada a cargar nuestros estilos CSS y aplicarlos.
Hojas de estilo externas
En general, mezclar dos tipos de outputs como son el procesamiento de JavaScript y el CSS, no es del todo deseable, ya que es importante favorecer el cacheo de los recursos en el navagador y si enviamos todos los recursos juntos, este fichero completo va a cambiar muchas más veces y se deberá descargar completo cada vez.
En el ejemplo anterior, si lo que queremos es que los estilos se generen un fichero .css separado, sólo tendremos que usar un plugin para webpack llamado extract-text-webpack-plugin. Este plugin permite detectar todas las definiciones de estilos, procesarlas y extraerlas del bundle.js general, permitiendo ser guardadas en el fichero que especifiquemos:
En ciertas aplicaciones, puede resultar interesante a la hora de realizar la construcción el poder disponer de un fichero de salida para cada módulo o parte de la aplicación y no generar un único fichero mega grande con todo el código. Es el caso de un proyecto en el que tenemos una parte del desarrollo para web y otro para mbile.
webpack nos ofrece soporte para esta problemática con la definición de múltiples entry. De este forma nos permite separar el procesamiento de cada módulo implicado y generar ficheros distintos de salida. En nuestro caso, el webpack.config.js quedaría de la siguiente forma:
NOTA: En cada caso, el comodín [name] se sustituirá por el valor de cada una de las entry definidas.
Generación de versiones para producción
Si después de la ejecución del comando webpack has ido viendo el contenido del fichero bundle.js, habrás visto que este fichero no está minificado.
Para su despliegue en producción, es recomendable optimizar el tamaño del fichero final generado, por lo que webpack proporciona el parámetro -p con el que podemos optimizar su salida.
$ webpack -p
Hash: f0b9ee353a1bb7213bae
Version: webpack 1.12.1
Time: 503ms
Asset Size Chunks Chunk Names
bundle.js 3.66 kB 0 [emitted] main
[0] ./app.js 75 bytes {0} [built]
[1] ./messenger.js 72 bytes {0} [built]
+ 4 hidden modules
WARNING in bundle.js from UglifyJs
Side effects in initialization of unused variable sourceMap [./~/style-loader/addStyles.js:185,0]
Side effects in initialization of unused variable media [./~/style-loader/addStyles.js:203,0]
Condition always false [./~/style-loader/addStyles.js:23,0]
Dropping unreachable code [./~/style-loader/addStyles.js:24,0]
Condition always false [./~/style-loader!./~/css-loader!./style.css:10,0]
Dropping unreachable code [./~/style-loader!./~/css-loader!./style.css:12,0]
Side effects in initialization of unused variable update [./~/style-loader!./~/css-loader!./style.css:7,0]
Como podemos ver, webpack utiliza internamente UglifyJS para minificar y optimizar nuestro fichero JavaScript de salida. En este sentido, puede ser normal ver algunos warnings como salida del comando.
Recarga automática de cambios
watch
Ejecutar constantemente el comando webpack todo el tiempo puede resultar realmente pesado. Con el fin de trabajar de forma desatendida, webpack incorpora el parámetro -w (equivalente a --watch), el cual permite monitorizar los ficheros definidos y lanzar la construcción de nuevo si alguno de ellos cambia.
Para ello sólo tenemos que modificar nuestro package.json para que webpack se inicie con este parámetro:
En cualquier caso, esto sólo actualiza los carmbios en disco, por lo que tendremos que ir al navegador y recargar la página manualmente después de cada cambio.
Para mejorar este flujo de trabajo, webpack incorpora el webpack-dev-server, el cual permite que se notifique al navegador ante cambios con el fin de que este pueda recargar la página.
Si queremos utilizarlo, actualizaremos nuestro package.json de forma que en lugar de lanzar el comando webpack, sea el webpack-dev-server el que sea invocado:
NOTA: No olvidemos que webpack-dev-server es una nueva dependencia para nuestro proyecto y que, como tal, necesita ser instalada previamente mediante npm i webpack-dev-server -D (al igual que hacíamos con la de webpack).
Si aplicamos estos cambios al package.json del proyecto webpack-simple, podremos ejecutar npm start y ver la siguiente salida:
$ npm start> webpack-simple@1.0.0 start /../webpack-simple> webpack-dev-server --progress --colors
Hash: 396f0bfb9d565b6f60f0
Version: webpack 1.13.0
Time: 9ms
webpack: bundle is now VALID.
http://localhost:8080/webpack-dev-server/
webpack result is served from /
content is served from /../webpack-simple
Como podemos ver, webpack-dev-server nos informa de la URL que tenemos que cargar en nuestro navegador para que se produzca la magia y el navegador se recargue cada vez que realizamos algún cambio.
Es momento de probarlo!!!
Actualizaremos toda la config, lanzaremos el proyecto webpack-simple con npm start y accederemos al URL que se nos propone (http://localhost:8080/webpack-dev-server/ en este caso).
Si ahora vamos con nuestro editor y modificamos el fichero app.js, veremos como el navegador realiza la recarga y el resultado de la ejecución ya recoge nuestras modificaciones (podemos cambiar el mensaje que lanza el console.log a la consola del navegador).
Hot Module Replacement (HMR)
Por último, aunque la notificación de recarga al navegador resulta muy conveniente, sería incluso mejor si a la hora de realizar la recarga de una página, se conservara el estado de las variables en ese punto. Imaginemos que tenemos una aplicación rica que tiene pestañas, listas y múltiples botones. Si cada vez que refrescamos tenemos que reproducir toda la navegación realizada para verificar cada pequeño cambio, entonces esta forma de trabajo no nos resultará muy productiva.
Mediante la implementación de Hot Module Replacement o HMR, webpack recargará los cambios manteniendo el estado actual de nuestras variables.
Para poder utilizarlo, sólo tenemos que modificar ligeramente la configuración de nuestro package.json:
Sólo nos queda arrancar el webpack-dev-server con npm start y probar que funciona:
$ npm start> webpack-hot-loader@1.0.0 start /../webpack-hot-loader> webpack-dev-server --hot --inline --progress --colors
70% 1/1 build moduleshttp://localhost:8080/
webpack result is served from /
content is served from /../webpack-hot-loader
Hash: 5de8396088de010c8afa
Version: webpack 1.13.0
Time: 343ms
Asset Size Chunks Chunk Names
bundle.js 254 kB 0 [emitted] main
chunk {0} bundle.js (main) 216 kB [rendered]
[0] multi main 52 bytes {0} [built]
[1] (webpack)-dev-server/client?http://localhost:8080 2.67 kB {0} [built]
[2] ./~/url/url.js 22.3 kB {0} [built]
[3] ./~/url/~/punycode/punycode.js 14.6 kB {0} [built]
[4] (webpack)/buildin/module.js 251 bytes {0} [built]
[5] ./~/querystring/index.js 127 bytes {0} [built]
...
[73] ./~/ansi-regex/index.js 135 bytes {0} [built]
[74] (webpack)/hot/dev-server.js 1.85 kB {0} [built]
[75] (webpack)/hot/log-apply-result.js 813 bytes {0} [built]
[76] ./app.js 232 bytes {0} [built]
webpack: bundle is now VALID.
A continuación, accederemos a la página del webpack-dev-server (http://localhost:8080/webpack-dev-server/), donde cargará la aplicación. Si ahora abrimos las Chrome Tools y modificamos el console.log que se hace en el fichero app.js, veremos algunos mensajes que nos informan de la recarga y los cambios se aplicarán inmediatamente sin perder el estado actual. Esta es la salida de las Chrome Tools:
Webpack rocks: 0
bundle.js:8098 Webpack rocks: 1
bundle.js:8098 Webpack rocks: 2
2bundle.js:619 [WDS] App updated. Recompiling...
bundle.js:684 [WDS] App hot update...
bundle.js:8048 [HMR] Checking for updates on the server...
bundle.js:8011 [HMR] Cannot apply update. Need to do a full reload!
bundle.js:8053 [HMR] Waiting for update signal from WDS...
bundle.js:616 [WDS] Hot Module Replacement enabled.
bundle.js:8098 Webpack rocks!! 3
bundle.js:8098 Webpack rocks!! 4
Webpack 2: Llega el tree-shaking
El proyecto Rollup de Rich Harris ha popularizado una funcionalidad muy interesante en el mundo del empaquetado JavaScript: El tree-shaking. Hablamos de tree-shaking cuando existe algún proceso que, tras evaluar nuestro código fuente, es capaz de decidir qué funciones se utilizan o no en los módulos que importamos. Si alguna función no se utiliza, no se importará a la hora de generar el bundle final.
Como podemos imaginar, esta funcionalidad reduce en gran medida el temaño final del bundle.
La buena noticia es que tendremos esta funcionalidad disponible en Webpack 2, ya que ha sido incluida en su roadmap!! :)
Conclusiones
Tener nuestros assets bajo control es muy importante en proyectos de tamaño medio y grande. Con webpack podemos gestionarlos de una manera unificada y sencilla, dando solución a los casos de uso más habituales como es el procesado de ficheros JavavScript, CSS, SASS, incluso asistiendonos a la hora de desarrollar mediante el uso de Hot Module Replacement.
Si aun no has utilizado nunca webpack, dale una oportunidad y mejora tu flujo de desarrollo.
[Chimp.js] (simplemente Chimp en adelante) es un framework para automatizar pruebas web construido sobre Node.js y que funciona en cualquier plataforma (OSX, Linux y Windows). Permite escribir tests en Javascript obteniendo feedback en tiempo real, ya que el navegador puede ejecutar los tests mientras los escribimos.
Probar la interfaz de usuario con pruebas automatizadas
Se trata de una herramienta para crear pruebas sobre nuestra interfaz de usuario, por lo que vamos a poder utilizar estas pruebas como smoketests, pruebas de regresión, o incluso pruebas de aceptación. Permiten probar que la interfaz de usuario funciona correctamente después de realizar cambios en el código, más rápidamente que las pruebas manuales, por lo que podemos ejecutarlas con más frecuencia.
Este tipo de pruebas se situarían en la cúspide de la famosa pirámide de testing (concepto creado por Mike Cohn y popularizado por Martin Fowler).
Piramide de testing de Mike Cohn
Lo que plantea este concepto es que la base de nuestras pruebas de software debe estar compuesta por tests unitarios. Son pruebas de ejecución muy rápida que se encargan de verificar que cada uno de nuestros módulos por separado funciona.
En el siguiente escalón de la pirámide se situarían las pruebas de integración, con las que comprobamos el correcto funcionamiento de nuestro sistema. Estas pruebas requieren un entorno de integración, en lugar de usar dobles de test como hacen las pruebas unitarias, y tardan más tiempo en ejecutarse.
Por último estarían las pruebas que se ejecutan sobre la interfaz de usuario de nuestra aplicación. Estas pruebas han sido tradicionalmente frágiles (un cambio en la interfaz hace que haya que rehacer los tests). Esta fragilidad aumenta si usamos herramientas de tipo "grabar y reproducir", bastante usadas en el mundo del testing. Son pruebas que requieren más tiempo de ejecución y también, en muchos casos, son difíciles de manejar en entornos de integración continua.
Chimp facilita la tarea de realizar tests sobre la interfaz de usuario, encargándose de la configuración necesaria para poder ejecutar estas pruebas. Se encarga, por ejemplo, de instalar Selenium, ChromeDriver, IEDriver, PhantomJS o Cucumber.js haciendo de esa forma más sencillo mantener el foco en lo realmente importante: el desarrollo, tanto de nuestra aplicación como de los tests que asegurarán la calidad de nuestro software. Además, combina perfectamente con distintas herramientas de integración continua.
Usar Chimp es especialmente interesante si usamos como metodología BDD (Behaviour Driven Development), puesto quec está perfectamente integrado con Cucumber. Esto nos va a permitir avanzar sin distracciones en nuestro desarrollo. Además de con Cucumber, también podemos usar Chimp en combinación con otros frameworks de pruebas en javascript como Mocha o Jasmine.
Chimp es utilizado por Simian, una herramienta de colaboración para la especificación de requisitos de software también desarrollada por los chicos de Xolv.io.
Instalación
Los únicos requisitos previos son, tener instalado node y npm, y el JDK v1.8 o más actual. Para verificar que efectivamente cumplimos estos requisitos, abrimos uns ventana de línea de comandos (terminal en linux y mac) y verificamos las versiones instaladas de node.js y java. Para ello ejecutamos los siguientes comandos: 'node -v' para saber la versión de node.js, y 'java -version' para la versión de java.
Primero confirmamos nuestra versión de Node y Java
Si cumplimos con los requisitos, simplemente debemos ejecutar el comando 'npm install -g chimp' o 'npm install chimp', en función de que queramos instalarlo globalmente, o bien sólo para un determinado proyecto. Ya está. Es lo único que tenemos que hacer. NPM se encargará de instalar todos los módulos necesarios.
Ejemplo práctico
Para hacernos una idea más clara de como funciona Chimp, vamos a ver un sencillo ejemplo de uso. Vamos a crear un test en el que abriremos una ventana del navegador Chrome, iremos a la web de google (Given I have visited Google), realizaremos la búsqueda "Genbeta Dev" (When I search for "Genbeta Dev") y verificaremos que aparece un enlace a Genbeta Dev (Then I see "Genbeta Dev").
Necesitamos una ventana de línea de comandos y el editor de código que más nos guste. Para este ejemplo yo he usado Atom.
Vamos a seguir el tutorial que hay en el sitio web de Chimp, pero para los más impacientes os voy a mostrar todo el código fuente y la estructura que vamos a tener como resultado final:
Resultado final del ejemplo. Carpetas y código.
Lo primero que vamos a hacer es crearnos una carpeta dónde pondremos el todo el código de nuestro ejemplo (2 archivos). En nuestro caso hemos llamado a la carpeta 'tutorial_chimp'. Posteriormente, desde la línea de comandos, dentro de esta carpeta, ejecutamos el siguiente comando:
'chimp --watch'
Chimp descargará las herramientas que necesite y en la consola nos mostrará un mensaje como este:
'[chimp] Running... [chimp][cucumber] Directory ./features does not exist. Not running'.
Ahora vamos a crear una carpeta 'features' y veremos que arranca una sesión del navegador Chrome. Dentro la carpeta features creamos el archivo el archivo 'search.feature'. Editamos este archivo y ponemos lo siguiente:
Feature: Search the Web
As a human
I want to search the web
So I can find information
Scenario: Search for Genbeta Dev
Given I have visited Google
When I search for "Genbeta Dev"
Then I see "Genbeta Dev"
En la consola nos aparecerá el siguiente mensaje:
[chimp] Watching features with tagged with @dev,@watch,@focus
[chimp] Running...
0 scenarios
0 steps
Ahora añadimos la etiqueta @watch a nuestro archivo search.feature justo antes de definir el escenario, y guardamos el archivo, quedando algo así:
Feature: Search the Web
As a human
I want to search the web
So I can find information
@watch
Scenario: Search for Genbeta Dev
Given I have visited Google
When I search for "Genbeta Dev"
Then I see "Genbeta Dev"
En la consola ahora veremos más información, y cucumber nos indica que no se han implementado las definiciones de los pasos para ese escenario, y nos informa de cómo hacerlo.
Creamos la carpeta support, dentro de features, añadimos el archivo 'step_defs.js' y añadimos el siguiente código:
module.exports = function() {
this.Given(/^I have visited Google$/, function () {
browser.url('http://google.com');
});
this.When(/^I search for "([^"]*)"$/, function (searchTerm) {
browser.setValue('input[name="q"]', searchTerm);
browser.keys(['Enter']);
});
this.Then(/^I see "([^"]*)"$/, function (link) {
browser.waitForExist('a=' + link, 5000);
});
}
Ahora si, Chrome irá a la página de Google.es, buscará 'Genbeta Dev', y Chimp confirmará que un enlace a 'Genbeta Dev' aparece en la página de resultados.
Conclusión
Esto es sólo un pequeño ejemplo de lo que se puede hacer con Chimp. Se trata de una herramienta con mucha proyección de futuro. Con los conocimientos adecuados de Cucumber y la sintaxis Gherkin puede aportar mucho a equipos que quieran empezar a aplicar BDD.
Aspectos positivos:
Entre las cosas que más me gustan de Chimp destacaría que es muy rápido empezar a usar la herramienta. En unos minutos podemos tener algunos tests listos para montarlos en nuestro entorno de integración continua, sin importar que usemos TravisCI, CircleCI, CodeShip o, por supuesto, Jenkins.
Otro aspecto positivo es que hacen muy sencillo empezar a hacer Desarrollos Dirigidos por Comportamiento (BDD), muy demandados por la industria actualmente, y de gran valor si nuestros equipos de desarrollo y negocio trabajan codo con codo.
Otro aspecto destacable
Aspectos negativos:
Lo peor es que de momento tiene poca comunidad, debido a su juventud. Esto hace que la información que hay en la web, más allá de la oficial, sea de momento escasa.
Por otro lado, Chimp hace muchas cosas por nosotros a nivel de configuraación, y eso ahorra tiempo. Pero si se rompe, puede llevar algún tiempo conseguir que funcione de nuevo.
La integración continua es un proceso en el desarrollo de software que consiste en crear versiones automáticas de nuestro producto lo más a menudo posible para asegurar la integridad de nuestro código.
Este proceso funciona además muy bien con sistemas en los que existen tests que validan nuestro código, pues la integración continua comprobará entonces no sólo que se puede construir, sino además que funciona correctamente.
Existen en el mercado varios sistemas de integración continua muy conocidos como pueden ser Travis o Jenkins. Pero hoy es vengo a hablar de BuddyBuild: un sistema enfocado a móviles y extremadamente sencillo de configurar y utilizar.
BuddyBuild es un servicio en la nube de integración continua para aplicaciones móviles. Es un proyecto bastante joven, pero que está creciendo a una velocidad increíble. Actualmente es completamente gratuito, si bien en un futuro cobrarán a las empresas por usarlo.
En este artículo os voy a hablar de cómo se integra BuddyBuild con Android, pero el proceso sería muy similar para una aplicación en iOS.
Creando el proyecto
Para este ejemplo, voy a crear un proyecto muy sencillo, con una rama master y algunas otras ramas para que veamos cada uno de los casos en los que BuddyBuild nos aporta valor.
Para acceder a BuddyBuild, sólo necesitas tener una cuenta en Github o Bitbucket. En particular, la cuenta tiene que ser una que tenga acceso al repositorio que quieres integrar. En este ejemplo usaré Github.
Después, elige tu proyecto y haz click sobre Build. BuddyBuild se encargará de todo el proceso de configuración del entorno de construcción:
Cuando BuddyBuild termine de configurar el entorno, verás que tienes un listado de ramas disponibles, y que ha construido la rama master automáticamente por nosotros. Ya podrás ver si tu rama compila:
A partir de este punto, te voy a enseñar cada una de las funcionalidades que nos aporta BuddyBuild, divididas en cuatro apartados: Build, Deployments, Feedback y Crash Reports.
Build
Es la parte más interesante de BuddyBuild y donde podemos configurar más parámetros. Aquí nos encontraremos con todas las ramas del repositorio, y podremos lanzar manualmente la construcción de cada una de ellas.
Además, la configuración nos permitirá que, cada vez que hagamos un push en una rama, BuddyBuild nos compile automáticamente el código. Esto, como verás después, va a ser muy interesante para trabajar con Pull Requests, pues sabremos de un vistazo si el nuevo código rompe algo.
Entre las opciones a configurar en esta sección, tenemos las siguientes:
Notifications: Nos permite configurar a quién notificar, cuándo, cómo y sobre qué ramas. Si usas Slack, también se puede integrar fácilmente con éste.
Auto-Build: Aquí indicarás qué ramas quieres que se construyan automáticamente cuando haya un nuevo commit.
Application Variants: si usas diferentes variantes de tu aplicación (mediante build types o flavors), aquí puedes elegir cuáles se construirán por defecto, y puedes especificar casos especiales por rama. Podrías por ejemplo configurar que por defecto sólo se compile la versión de release, pero que en master se construyan todas.
Environment Variables: Puedes añadir las variables de entorno que necesites para que tu proyecto se construya. Puedes incluir aquí las claves de las APIs en lugar de incluirlas directamente en el código.
Unit Tests: En qué ramas quieres que se ejecuten los tests unitarios. Si los tests fallan, la construcción mostrará un error. Es ideal para darse cuenta rápidamente en qué punto hemos roto los tests.
UI Tests: Podemos también elegir en qué ramas queremos que se lancen los tests de instrumentación. Es increíble que funcione sin absolutamente nada de configuración, si bien es cierto que tiene ciertas limitaciones. Por defecto no podemos cambiar ni la versión del emulador que se lanza para ejecutarlos, ni tampoco fallará la construcción si fallan estos tests. Se pueden pedir estos cambios por correo para que lo modifiquen ellos.
APK Signing Keystores: Aquí podemos añadir las claves de firmado, para que sea capaz de compilar el proyecto en release.
Build Status Badges: Puedes añadir un badge al README.md para saber siempre en qué estado está tu rama. En el repositorio de ejemplo puedes verlo.
Ahora voy a crear una rama con un test que no compile, y a hacer un Pull Request. Verás qué es lo que pasa:
Para empezar, en BuddyBuild podemos ver el problema. Pero si creamos un Pull Request, veremos esto en Github:
Sin necesidad de probar el código, ya sabemos que algo está fallando, y podemos hacer click en Details para ir al detalle en BuddyBuild. Además, puedes configurar alertas para que te lleguen correos cuando una rama falla.
Como ves, de forma muy sencilla tienes configurado tu proyecto para que se construya automáticamente con cada ejecución, y además integrado con Github para darte información rápida durante la revisión de Pull Requests.
Deployments
Ahora que ya estamos construyendo nuestro proyecto, podemos hacer que se envíe automáticamente a ciertos grupos bajo distintas condiciones. Por ejemplo, podríamos configurar una nightly que se lance automáticamente cada noche con lo último que haya en master, y una beta privada desde una rama beta cada vez que se añada algo nuevo. Tendrás que elegir también la variante que se despliega:
Además, en esa misma sección puedes publicar directamente en la Play Store mediante una configuración muy similar. Puedes elegir desde qué ramas y en qué condiciones publicarás en alpha, beta o production.
Feedback
Aquí entramos ya en la parte de gestión de errores y feedback, que será gestionada mediante el SDK de BuddyBuild, el cual se integra automáticamente cuando BuddyBuild compila nuestro código.
Gracias a ello tenemos algunas funcionalidades que de forma automática se agregan a nuestra App, y que podemos elegir si activamos o desactivamos bajo ciertos criterios:
Shake for feedback: Agitando el móvil el usuario puede enviar información a BuddyBuild con un pantallazo (lo vemos en un momento).
Crash reports: Recibiremos los errores que se produzcan en nuestra aplicación (más en detalle en el siguiente punto).
Actualizaciones: Si hay una nueva versión disponible, la App informará al usuario para que permitirle actualizar de forma sencilla.
Sólo tenemos que elegir en qué ramas queremos que se integre el SDK, y BuddyBuild lo hará por nosotros:
Además, también podemos configurarlo para que nos cree issues en Github automáticamente, con el contenido de esta sección y de la sección de bugs que veremos después. Echa un vistazo al resto de opciones de configuración.
Una vez integrado el SDK e instalada la App, cuando agites el teléfono te aparecerá una ventana e la que puedes seleccionar la sección sobre la que aplica el feedback y un texto. Éste es el resultado de lo que llega a BuddyBuild:
¿Qué es lo siguiente que podríamos hacer con esto? Desde el detalle, puedes crear una issue directamente en Github con la imagen y el detalle:
Como ves, puedes integrar todo el ciclo de tu aplicación en un único sistema de forma muy sencilla. ¡Y aún nos queda la gestión de errores!
Crash Reports
Los informes de errores son una de las partes donde más foco tienen que poner aún si quieren superar a otras alternativas. Lo que más me gusta es que el propio log del error te indica la línea exacta donde ha ocurrido, y puedes ver parte del código que rodea la línea problemática.
Además, puedes ir saltando por el stacktrace al resto puntos del código, por lo que se hace muy sencillo ver qué está ocurriendo. En este caso simplemente forcé una excepción al hacer clic en un botón:
Todavía le faltan funciones que considero esenciales, como gráficas sobre los dispositivos en los que se produce el error, versiones de Android, poder adjuntar logs... Por lo que he podido hablar con ellos, están trabajando activamente en mejorar toda esta parte.
Conclusión
Como habrás observado, BuddyBuild destaca por ser una herramienta extremadamente sencilla de configurar, y por dotarnos de unos funcionalidades que cubren una gran mayoría de los casos reales en sistemas de integración para aplicaciones móviles.
Te recomiendo que le eches un vistazo y lo pruebes con un proyecto propio para que puedas comprobarlo por ti mismo. Además, si te interesa el tema puedes seguir leyendo el resto de artículos sobre integración continua.
¿Qué te parece BuddyBuild? ¿Echas en falta algo? ¿Crees que es una opción real para empresas y grandes proyectos? Cuéntanos en los comentarios.
Women Techmakers es una iniciativa liderada por Google que se ha convertido en una realidad a nivel mundial.
Con motivo del día internacional de la mujer, se han realizado durante el mes de marzo diferentes eventos con el objetivo de dar a las mujeres que se dedican al ámbito tecnológico, el protagonismo que se merecen.
La principal característica de este tipo de eventos ha sido el papel predominante de la mujer en el mismo, compartiendo sus experiencias en los distintos ámbitos tecnológicos en los que desempeñan su actividad y contribuyendo así a la visibilidad de la mujer en el sector.
En este marco y con la coordinación de GDG Spain, se han lanzado durante 2016 hasta 14 eventos de Women Techmakers, los cuales han permitido que por toda la geografía española se recuerde a todos los que integramos el mundo de las nuevas tecnologías que el papel de la mujer sigue creciendo y cada vez lo hace con más fuerza en todas las comunidades técnicas.
Eventos realizados
Como punto de partida, tomaremos el portal publicado por GDG Spain como paraguas para todos los eventos organizados bajo la marca de Women Techmakers. En él podemos ver todos y cada unos de los eventos realizados, así como tener acceso a los recursos generados durante los mismos en forma de fotos, videos, slides y mucha mucha ilusión.
Sin duda, esta respuesta tan mayoritaria por parte de los GDG españoles no es más que un reflejo de lo sana y activa que es la comunidad de desarrollo española y de cómo busca mejorar intentando que la participación de las mujeres en este tipo de eventos sea cada vez más alta y su implicación mayor.
Ponentes implicados
Lo más interesante es que la oferta de charlas desplegadas en los distintos eventos ha sido muy rica e interesante. Así, hemos podido disfrutar de sesiones sobre programación en Ruby o Python, Machine Learning, técnicas posturales o realidad virtual entre otros interesantísimos temas. Sólo hay que ver el programa ofrecido por Madrid, Castellón o Vigo, entre otros!!
Desde nuestra experiencia más concreta con el GDG Castellón, uno de los puntos que requirió más esfuerzo fue completar la parrilla de sesiones … aunque finalmente se consiguió con creces y con mucha calidad :) Es importante pues destacar aquí el papel y la energía de gente de la comunidad que continúa implicándose en este tipo de eventos, de empresas del ecosistema local que se han volcado con el evento aportando ponentes o patrocinando sesiones y también la acción de otros grupos de apoyo como el ya conocido Tech & Ladies, que tanto aporta a la hora de conseguir eventos de éxito.
Finalmente, no tenemos que olvidar que ninguno de estos eventos sería posible sin la intervención de las speakers, por lo que me voy a permitir recogerlas aquí para agradecerles su desinteresada aportación (disculpadme si hay alguna que se nos ha escapado): Gina Tost, Victoria Yasinetskaya, Toñi Herrero, Vero Logu, Pino Caballero Gil, Davinia García, Elisa de Gregorio, Sara García Cuesta, Carina González, Verónica Martín Jiménez, María Montserrat Melo Marrero, Berta Arbelo Pérez, Laura A. Gómez González, María Panizo Casado, Rocío Rodríguez Morín, Marisol Lerma, Mª Encarnación Beato Gutiérrez, Ana Mª Fermoso García, Montserrat Mateos Sánchez, Isabel Cabezas, Davinia García, Adela Fort, Carmen Checa, Mª Àngels Moncusí, Maddalena Molteni, Gloria Bueno, Helena den Haan Alonso, Begoña Moros, Almudena Alcaide Raya, María José Ortín, Mercedes Valdés, Victoria Palomo, Vanessa Cantero, Carmel Hassan, Fátima Acién, Yamila Moreno, Laura Andina, Fina Pérez, Adriana Luengo, Ana Belén Medina, Esther Sanz, Gloria Bueno, Isabel Cabezas, Carmen Checa, Laila El Qadi, Paola García, Teresa de la Torre, Isabel Cabezas, Carmen Checa, Laila El Qadi, Paola García, Teresa de la Torre, Rita Madariaga, Esther Lozano, Michaëlle López, Paula, Nuria Rico, Ana María Prieto, Mónica López, Magalí Gabriela Piterman, María Alcalde, Natalie Widmann, Meritxell Calvo, Marta Garrido, Maite Gimenez, Laura Díaz, Ana Plazas Martínez, Yolanda Corral, Lidia Contreras, Carolina San Miguel, Loli Iborra, Sara Serrano, Cristina Font, Susanna Alós y Jessica Travieso.
Experiencias en primera persona
Como no podía ser de otra forma, desde el GDG Madrid y el GDG Castellón nos gustaría compartir con vosotros la experiencia de sus organizadoras principales, cuáles han sido los retos principales que han tenido que afrontar y su opinión respecto al impacto y conveniencia de seguir trabajando en este tipo de eventos. No hay mejor testimonio que el de nuestras chicas de los GDG!!!
GDG Madrid: Laura Morillo
Desde que conocí la iniciativa de WTM me entusiasmó la idea de organizar uno. Siempre he intentado estar muy involucrada en iniciativas que tratan de acercar mujeres y tecnología y organizar un evento donde conseguir que solo mujeres nos hablarán de sus conocimientos y experiencias, parecía muy interesante.
Encontrar a las ponentes no fue tarea fácil, aún creo que es una asignatura pendiente para muchas de nosotras el darnos cuenta de lo que sabemos y lo que podemos compartir (¿síndrome del impostor?). Sin embargo, también es cierto que saber que se trataba de un evento de tecnología con ese enfoque especial en las mujeres creo que ayudó a que algunas ponentes se animaran a dar el salto al escenario por primera vez.
Estoy muy contenta con el resultado que tuvimos: 15 ponentes, 13 charlas y 135 asistentes, de los cuales un 70% fueron mujeres.
Además, el contenido fue muy variado. Pudimos presenciar desde una ‘guerra’ entre una desarrolladora y una diseñadora que nos mostraron cómo se las arreglan para integrar el trabajo de ambas en su día a día, hasta una pequeña youtuber de 9 años que cautivó a todos los presentes demostrando que las más pequeñas también pueden disfrutar de la tecnología.
¡Esperamos que este evento sirva de ejemplo y motive a más chicas en el futuro!
GDG Castellón: Emma López
Women Techmakers Castellón se celebró el pasado sábado 23 de abril. Disfrutamos de un día de charlas donde 14 ponentes hablaron de temas tan interesantes como machine learning, open data, ux, ciberseguridad, voluntariado o realidad virtual.
El público, unos 70 asistentes a lo largo de la jornada, estuvo animado en la ronda de preguntas y los espacios para el networking fueron provechosos. Es dificil recomendar una única charla, es mejor que te pases por el canal de decharlas y las veas por ti mismo ^_^
La idea de montar un WTM surgió de la incomodidad. Incomodidad al ver que se celebraba en otras ciudades de España pero nadie estaba montando nada en el área de Valencia-Castellón. WTM es una interesante iniciativa para incentivar a las mujeres a ser ponentes y unirse a comunidades enriqueciéndolas y haciéndolas más diversas. ¡Así que manos a la obra!
Tenía claro lo que quería: montar un evento de un día de charlas, con ponentes locales. Una jornada donde hablar de software y hardware con voz de mujer, con esa voz tan poco oída normalmente en charlas de este tipo. Lo primero fue buscar cómplices. Encontrar las primeras ponentes y encontrar el lugar. Con eso asegurado, decidí tirarme a la piscina y publicarlo en GDG Spain. A partir de ahí, la pequeña gran montaña rusa de montar un evento: publicar la web, buscar ponentes, hablar con patrocinadores, buscar catering, hacer difusión…
Me gustaría agradecer al equipo de decharlas y GDG Castellón el apoyo dado por facilitar el espacio, grabación, difusión y enlace con GDG Spain. Así mismo, agradecer a los patrocinadores que apoyaron el evento. Pero, sobre todo, me gustaría agradecer el esfuerzo de todas la ponentes que dieron una charla en este primer WTM Castellón. Sé que todas tenían una agenda apretadísima y aun así se animaron a colaborar. ¡Muchas gracias a todas!
El organizar WTM Castellón es un paso hacia la normalización de la comunidad técnica en Levante y sin duda todos disfrutamos ese día.
Sin duda, los eventos de desarrolladores organizadas por las comunidades son las que mejor funcionan. Por varios motivos, pero sobre todo por la pasión y las ganas de compartir conocimientos que derrochan tanto los speakers como los organizadores.
Englobado en la categoría de de los DevFest apoyados por Google, cuenta este año con auténticos Speakers RockStars del panorama de desarrollo en España e, incluso, de fuera. Entre los días 4 y 5 de Junio se celebrará en Cáceres con más de 15 horas de charlas y 14 ponentes procedentes de Karumi, Jobandtalent, Tuenti, Google, IBM, Mozilla o Twitter.
No queríamos dejar pasar la oportunidad para pulsar el momento que estamos viviendo a nivel desarrollo: conocer cuáles son las tecnologías de las que tenemos que fijarnos y sobre todo, de qué van a hablar en ExFest.
Hemos preparado un recopilatorio de algunas de las preguntas que hemos lanzado a los ponentes de esta edición del ExFest. A continuación os dejo con ellas:
Jorge J Barroso. "Programando en diferido"
Jorge Barroso, Android expert en Karumi y Google Developer Expert
¿De qué nos vas a hablar en el ExFest?
En el exfest vamos a hablar de las distintas opciones que tenemos para hacer operaciones pesadas en Android, las compararemos, las mediremos, veremos cuando son útiles. ¿Quien ganará? ¿RxJava?¿AsynTask?¿Ágera?
¿Qué te ha convencido para acudir a este ExFest?
En dos años se ha convertido en una cita ineludible dentro de las citas de Android español, además este año con un cartel de lujo y en mi tierra. Que mas puedo pedir.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
Testing y arquitectura, las herramientas vienen y van, pero escribir buen código, que funcione como debe y que sea legible, no pasará nunca de moda.
¿De qué nos vas a hablar en el ExFest?
Cómo explotar las nuevas tendencias y API's de inteligencia artificial en tus APPs (Web o mobile).
¿Qué te ha convencido para acudir a este ExFest?
El equipo humano que esta detrás de la organización, y por supuesto todo el mundo que participa del evento.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
Todo el campo de la inteligencia artificial esta haciendo que comencemos a percibir la interacción de los usuarios con la tecnología de otra forma. Ejemplos como los ChatBots y las nuevas AI APIs, están facilitando la exploración y aplicación de estas técnicas en nuevos campos.
En el futuro los agentes/IAs nos permitirán, por ejemplo, desde monitorizar y mejorar los consumos de las baterías de nuestros mobiles, a facilitarnos la interacción entre nosotros. Es algo que ya esta aquí, y que solo necesitamos explotar.
Abdón Rodríguez Davila. "How Polymer works inside?"
¿De qué nos vas a hablar en el ExFest?
Mi idea es explicar qué ofrece Polymer en cada una de sus tres capas de funcionalidad. Pero como el Google I/O está muy cerca, puede que añada alguna cosa en función de lo que nos cuenten.
¿Qué te ha convencido para acudir a este ExFest?
Su excelente organización, que creo que hará un evento increíble.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
Web Components y Progressive Web App, sin duda. :)
Pedro Vicente Gómez Sánchez. "World-Class Testing Development Pipeline for Android"
¿De qué nos vas a hablar en el ExFest?
Escribir tests no es una tarea sencilla. Cuando un desarrollador se adentra en el mundo del testing automático le surgen millones de dudas que no tienen una fácil respuesta. Durante esta charla hablaremos sobre qué testar en una aplicación y como hacerlo utilizando diferentes técnicas y aproximaciones.
¿Qué te ha convencido para acudir a este ExFest?
El esfuerzo y la pasión que ponen los organizadores de este evento que consigue que se organize en Extremadura uno de los mejores eventos relacionados con Android de España con un conste por entrada irrisorio.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
Testing, big data, programación reactiva y programación funcional.
Joaquin Engelmo Moriche. "Programación defensiva y sistemas resilientes en el mundo real"
¿De qué nos vas a hablar en el ExFest?
Habitualmente hablo de testing pero esta vez la charla irá sobre como el testing "no todo lo puede" y una vez puesto un sistema en producción comienza una nueva aventura. La integración con terceros, la demanda de los usuarios, una campaña de marketing y motivos varios pueden afectar al rendimiento e incluso la estabilidad de tu sitio. Hay técnicas y tecnologías para hacer de todo esto menos doloroso y lo más inevitable posible. Contaré casos que hemos tenido en Tuenti y que cosas hemos aplicado para dormir mejor por las noches y disfrutar de los fines de semana :)
¿Qué te ha convencido para acudir a este ExFest?
Lo primero, es mi tierra, me crié en Zafra, he estudiado en la Universidad de Extremadura y he vivido 12 años en Cáceres. Creo que compartir lo que he aprendido con mucha gente que irá de por allí es un deber y un honor. En segundo lugar porque el evento ya tenía proyección el año pasado y este año se han superado. Tanto la logística como los ponentes son de primera y si no fuera ponente iría como asistente al 200%. Y en tercer lugar pero no menos importante, pasar ese fin de semanas con viejos amigos, gente que respeto y que les tengo mucho cariño es una carga de batería para el día a día en nuestra profesión.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
Es una pregunta complicada porque cada uno tiene su círculo y se nos escapan muchas cosas. Del mundo server side y la JVM, mi cueva habitual, destacaría como están madurando lenguajes como Scala o Kotlin e incluso como Java ha dado un buen salto con Java 8. A nivel de arquitectura destacaría los microservicios y todo el ecosistema que se están montando alrededor, pero cuidado, hay que saber los pros y los contras (algo que contaré en mi charla). Y, los viejos clásicos nunca pasan de moda, conocer SOLID, aplicar testing o conceptos de DDD, entre otros, harán que mejores como programador.
¿De qué nos vas a hablar en el ExFest?
La charla trata de como dominar la herramienta clave usada por el android dev. a día de hoy: Android Studio. Se mostrarán 'in situ', tips y consejos quizás pasados desapercibidos para ser más productivo en el día a día con la herramienta.
¿Qué te ha convencido para acudir a este ExFest?
La comunidad, que demuestra que cualquier lugar sin ser una capital o una gran ciudad puede ser el escenario para albergar uno de los mayores eventos an nivel nacional.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
Desde mi punto de vista, quizás no importe tanto el con qué desarrollamos un producto si no que resultado obtenemos, hoy en día conocer cómo ofrecer la mejor experiencia de uso a los usuarios prima sobre las tecnologías utilizadas.
Con todo, comprender como los usuarios se desenvuelven con los productos es obligatorio para un desarrollador, apostar por dominar la usabilidad y el diseño sazonado con conocimientos técnicos son los ingredientes clave para el éxito.
Andrés L. Martinez Ortiz. "Google Firebase: desarrollo de aplicaciones móviles"
¿De qué nos vas a hablar en el ExFest?
Google Firebase es una nueva plataforma de soporte de desarrollo de aplicaciones móviles y web que integra soporte al backend, autenticación, real time database, asi como hosting estático y otras características que permiten el escalado de las según crecen el número de usuarios.
¿Qué te ha convencido para acudir a este ExFest?
ExFest se esta convirtiendo en el referente de las conferencias en el sur de España. Cuenta con excelente ponentes internacionales y congrega a publico desde todos los rincones del pais. Cubre todo tipo de tecnologías desde la web hasta el cloud y todo esto en una ciudad estupenda para conferencias.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
Interfaces de mensajería (bots), micro servicios y progressive web apps (applicaciones web con funcionalidad offline)
¿De qué nos vas a hablar en el ExFest?
Os hablaré de polymer starter kit, basado en el standard de web components y polymer, la nueva forma de hacer web que cambiará por completo el concepto que la gente tiene, en ocasiones con razón, de ella. Va a ser una charla de las que te dejan con ganas de empezar a hacer cosas.
¿Qué te ha convencido para acudir a este ExFest?
El track que han preparado en Web me parece muy completo e interesante, con un muy buen planteamiento. Además, tuve una buena experiencia en el Women Tech Maker Cáceres, muy bien organizado, y me quedé con ganas de más.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
El desarrollo web está avanzando de manera frenética y desde luego levanta mucha expectación respecto a lo que puede alcanzar. Componentes Web y Progressive Web Applications forman una unión muy potente como para dejarlos de lado, así que no dudaría en aprenderlos para no quedarme fuera de lo que está por venir.
Jorge Castillo. "Developing Android apps with Java 8"
¿De qué nos vas a hablar en el ExFest?
Google publicó la preview del SDK de Android N hace muy poquito, la cuál daba soporte a algunas funcionalidades de Java 8. Actualmente hay muchas dudas acerca de esto. En mi charla hablaremos del nuevo compilador disponible a partir de N, Jack. Intentaremos también arrojar algo de luz sobre las nuevas funcionalidades disponibles. Haremos uso de las mismas para proponer una nueva idea sobre cómo estructurar la arquitectura de nuestras aplicaciones. Además, aclararemos qué funcionalidades podemos emplear en versiones más antiguas aprovechando la retrocompatibilidad.
¿Qué te ha convencido para acudir a este ExFest?
En concreto me he sentido más atraído por el resto de ponentes, y el networking en general. Creo que va a ser un gran evento, y tendré la oportunidad de coincidir con un montón de gente interesante.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
Creo que es inevitable pensar en los lenguajes de programación más modernos, que parecen muy centrados en aumentar el nivel de los lenguajes anteriores, mejorando su expresividad y su potencia. La mayoría están centrados en dotar el desarrollo de aplicaciones móviles de ciertas notas propias de la programación funcional. Creo que es bastante positivo para todos empezar a familiarizarnos con este tipo de lenguajes y la forma de programar que proponen, y replantearnos un montón de cosas que hemos venido dando por sentadas desde hace mucho tiempo.
¿De qué nos vas a hablar en el ExFest?
Voy a hacer un recorrido por los aspectos más relevantes de la arquitectura de Twitter for Android y, en concreto, las técnicas que hemos empleado para modernizar una aplicación con cinco años de antigüedad y cientos de miles de líneas de código. En la actualidad, TfA emplea Dagger2, RxJava, una arquitectura de componentes para las actividades y miles de tests de unidad.
¿Qué te ha convencido para acudir a este ExFest?
Recomendación de profesionales de confianza y nombres reconocidos entre los speakers.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
En mi opinión, las tendencias más prometedoras en Android son de sobra conocidas, pero tienen un largo recorrido por delante:
Inyección de dependencias estática con Dagger2 y formalización de los scopes y grafos de objetos de la aplicación.
RxJava y programación reactiva, especialmente aplicada a la abstracción de pipelines de datos y la actualización dinámica de la UI.
Técnicas de programación funcional, tanto en Java 8 como en Kotlin.
Procesamiento de anotaciones y generación automática de código.
Optimización del código generado: ReDex, DexGuard.
Salvador de la Puente González. "From Web App to Progressive Web App"
¿De qué nos vas a hablar en el ExFest?
De las llamadas aplicaciones web progresivas, las tecnologías que las integran y su aplicación.
¿Qué te ha convencido para acudir a este ExFest?
Me invitó la gente de Google y desde Mozilla pensamos que es una oportunidad idónea para hablar ante un público realmente interesado en la evolución de la Web y sus tecnologías. Además, no conozco Cáceres.
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
Por citar algunos: Service Workers como proxies programables, más allá de los usos clásicos; WebVR, la realidad virtual en la Web nos acerca un poquito más al futuro de Gibson en Neuromante; Physical Web podría convertirse en la siguiente gran revolución de Internet; Web Assembly expandirá las posibilidades de la web hayá donde se le atribuían problemas de rendimiento y finalmente, yo mantendría un ojo sobre Servo, el navegador de nueva generación de Mozilla que podría suponer un punto y aparte en cuanto a arquitectura, fiabilidad y rendimiento de este tipo de software.
¿De qué nos vas a hablar en el ExFest?
Uno de los principales quebraderos de cabeza que tienes los desarrolladores es decidir qué tipo de arquitectura van a escoger para su proyecto. La charla pretende mostrar diferentes tipos de arquitecturas disponibles a dia de hoy y mostrará una comparación entre las diferentes opciones. Todo basado en un proyecto open source de Google del que soy participe. Android Architecture Blueprints
¿Qué te ha convencido para acudir a este ExFest?
La alta calidad de los ponentes y la genial organización por parte de Borja
Mójate, ¿Cuáles crees que son las tendencias a nivel de desarrollo más prometedoras a día de hoy? ¿En qué nos deberíamos fijar y si podemos aprender sin dudarlo?
Cualquiera de las dos plataformas móviles iOS o Android son una apuesta segura. No parece que vayan a desaparecer en un futuro próximo. Fuera del tema móvil creo que React / React Native tienen un futuro brillante sin olvidarnos de Polymer / Go.
El paradigma de gestión de infraestructura en el cloud y las razones que pueden haber detrás del mismo, son temas que habitualmente se pueden afrontar de una forma más sencilla y operativa en el núcleo de una startup o incluso de una empresa tradicional, mientras que en el ámbito de las administraciones públicas esto puede suponer "todo un reto".
Este reto es el que ha afrontado la Universitat Jaume I de Castellón en su paso de un entorno de gestión on-premises a uno totalmente gestionado en el cloud de Amazon y que hoy os relatamos como la primera experiencia de migración al cloud de una administración pública en españa.
No todo va a ser como Netflix o LinkedIn gestionan su infraestructura :)
Motivaciones
Antes de nada, vamos a reflexionar un momento acerca de los factores que pueden motivar que nos planteemos un objetivo como este.
En mi opinión y al margen de muchas que seguro tendréis en mente, para mi son fundamentales tres: Flexibilidad del modelo de consumo, foco en el core de negocio y ahorro de costes.
El llamado modelo de consumo no es más que el mismo modelo al que estamos acostumbrados con la luz o el agua y que se basa en convertir la computación en una commodity más. De esta forma, si necesito más recursos los utilizaré y pagaré por ello, y si en el siguiente mes no tengo carga, pues reduciré el número de servidores provisionados (crecimiento elástico).
Por otra parte y fundamental en mi opinión, tenemos el objetivo de mantener el foco en el core de negocio. Si nuestra actividad es la de dar soporte a la gestión, la investigación y la docencia en una universidad, entonces el correo electrónico o la computación son "males necesarios" de los que necesitamos estar dotados, pero no representan necesariamente el objetivo principal de mi actividad. No son el core de mi negocio (aunque dependa de ellos para poder dar un servicio de calidad).
Esto es algo que se ha ido entendiendo con el tiempo, dando lugar a múltiples casos de éxito de migración del correo electrónico o de las herramientas de colaboración a plataformas de cloud público como es el caso de Google Apps. En este sentido, la Universitat Jaume I fue la primera universidad en completar el proceso de migración del correo electrónico del profesorado y de los estudiantes a GMail en el año 2010.
Pero en este planteamiento conviene tener en cuenta que para poder realmente liberarse de una parte importante de la gestión de la infraestructura, la solución a adoptar no tiene que ser un reflejo "1:1" de la arquitectura de que disponemos on-premises, sino que debe diseñarse y ser reformulada para aprovechar cada vez más los servicios PaaS del proveedor y su capacidad de crecimiento elástico y no quedarse en un modelo de IaaS en el que disponemos de máquinas virtuales que acabamos gestionando igualmente nosotros.
Por último, están los factores económicos. El ahorro de costes y la facilidad de contratación es algo que tiene mucho peso en las organizaciones actuales. En este sentido debemos tener cuidado con las afirmaciones del tipo "El cloud es caro y esto lo tendríamos igual en un proveedor normal de máquinas virtuales" (o con cuatro PCs del MediaMarkt, que también se puede llegar a escucharse ...).
En este sentido y para responder a esta afirmación, hay que tener en cuenta todos los factores que intervienen en el cómputo del coste de nuestra infraestructura on-premises. La cuestión es que tenemos que seguir manteniendo el CPD, luz, licencias de VMWare, licencias de software de backup, cintas y almacenamiento o incluso las horas de dedicación del personal técnico que opera toda la infraestructura.
Si queremos tener más pistas de cuanto nos va a costar el paso, AWS nos provee de dos herramientas para hacer cálculos de coste. Por una parte, tenemos la famosa calculadora o simple monthly calculator, que es cualquier cosa menos simple, y por otra parte la AWS Total Cost of Ownership (TCO) Calculator que nos ayuda a calcular el coste comparado de lo que costaría con respecto a una instalación on-premises.
Si estáis considerando realmente un cambio de este estilo en vuestra organización, mi única recomendación es que hagáis un análisis serio de costes.
Condicionantes
Nos centraremos principalmente en los condicionantes de tipo legal y en los relacionados con el equipo de profesionales necesario para poder completar el proceso (las personas siempre acaban siendo uno de los factores determinantes para el éxito de cualquier proyecto).
Al ser una entidad pública, uno de los primeros requisitos que nos encontramos es la obligación en el cumplimiento de la ley de protección de datos (LOPD), el esquema nacional de seguridad (ENS) y el esquema nacional de interoperabilidad (ENI). Para asegurarnos que cualquier solución de cloud cumple con estos requisitos debemos fijarnos en lo que se expone en el RD 1720/2007 y en el Anexo A del CCN-STIC-823 de Seguridad en Entornos Cloud, validando posteriormente que cada proveedor de cloud cumple con el checklist que allí se consigna (incluyendo la obligación de que los datos siempre residirán dentro del espacio de la unión europea).
Por otra parte, si intentamos ir siempre hacia servicios en PaaS, el equipo que tenga que operar estos servicios deberá de alguna manera adaptar su forma habitual de trabajar a las nuevas necesidades. Aunque ya no es necesario instalar nuevo hardware en el CPD, instalar el sistema operativo y configurar la red o el filtrado de puertos, hay todo un nuevo conjunto de tareas de automatización y provisión de servicios que aparecen en escena.
Estamos hablando en general del perfil que cada vez más se identifica como DevOps y que se encarga de programar la infraestructura y todos sus servicios relacionados, alineando los requisitos y las visiones tanto del área de desarrollo como de la de sistemas. El perfil de DevOps es un perfil que no existe en muchos equipos y que en estos casos se convierte en clave (a no ser que contemos ya con un equipo de desarrolladores Full Stack, que no suele ser lo habitual).
En cualquier caso, la única garantía de éxito para proyectos de esta envergadura es que todos y cada uno de los responsables de las distintas áreas implicadas (comunicaciones, sistemas y aplicaciones) trabajen de forma conjunta y coordinada.
Implantando la arquitectura diseñada
Aunque el entorno de gestión de partida pueda involucrar muchos servicios y máquinas, con el fin de que sirva como ejemplo nos vamos a centrar en los siguientes tipos de elementos a la hora de evaluar el impacto de un proceso de migración de estas características:
Infraestructura de red.
Base de datos corporativa.
Servidores y frontales.
Almacenamiento
Y mucho mucho más ...
Infraestructura de red
Amazon implementa el concepto de Virtual Private Cloud (VPC) como base para construir nuestra estructura de red y así ir ubicando nuestros servicios en distintos segmentos expuestos a través de balanceadores hardware como es el caso de los Elastic Load Balancers (ELB).
Hay que tener en cuenta que para el acceso de administración o incluso de los servicios que se queden on-premises tras la migración, es interesante hacer uso de un tunel VPN contra AWS.
Ojo con este tipo de conexión, ya que necesitamos normalmente un hardware dedicado y una configuración muy concreta que Amazon nos proveerá. Nuestra experiencia en este respecto es que todo funciona mejor si el hardware que dediquemos al tunel está entre la lista de los soportados por Amazon y podemos cargar en él de forma directa las reglas que AWS nos genera.
Fuera de estos detalles, la configuración de red es bastante sencilla y raramente hay que hacer muchos ajustes a posteriori, por lo que esta parte no debería dar muchos dolores de cabeza.
Como característica adicional para aumentar la disponibilidad, podemos hacer uso de las distintas zonas de disponibilidad que no son más que extensiones desplegadas en datacenters distintos y separados lo suficiente para evitar caídas en caso de pérdida de servicio.
Base de datos
Entramos en el verdadero meollo de la cuestión, ya que habitualmente todos los aplicativos de gestión están conectados con la gran base de datos central. En estos escenarios tan data-centric, la base de datos es el núcleo de todas las operaciones y es el primer activo a considerar dentro del proceso de migración (si este no es tu escenario y no dependes de una gran base de datos relacional, antes de nada me gustaría decirte lo mucho que te envidio y, además, que Amazon ofrece un catálogo muy completo de NoSQL entre el que podemos encontrar un Redis en el servicio de ElasticCache o también un key-value/document database en DynamoDB).
Una de las primeras preguntas que debemos hacernos es si estamos dispuestos a asumir un periodo de parada o down time a la hora de realizar la migración de datos. Si nos lo podemos permitir y parar unas horas, el proceso de transferencia pasará por parar la base de datos central, realizar un export de todos los esquemas definidos, transferir este dump al servicio de Amazon de gestión de base de datos relacionales en PaaS que es RDS y posteriormente realizar allí el proceso de importación.
Por contra, si no queremos ningún tipo de tiempo de parada, una opción a evaluar es la del Data Migration Service de AWS que permite sincronizar datos entre instancias de base de datos, soportando PostgreSQL, MySQL y Oracle entre otras. Este escenario que parece el ideal, se vuelve un tanto complejo en el caso de que el esquema cambie a diario (muchas operaciones de DDL en producción) o si son cientos los esquemas de datos que se tendrían que sincronizar en DMS (distintas tareas de sincronización por cada esquema afectado).
Si nos decantamos por el primer escenario que incluye la parada de servicios, el primer problema con el que nos enfrentamos es la copia de una gran cantidad de datos desde nuestras instalaciones al cloud (en nuestro caso alrededor de 650GB de dump de base de datos).
En este sentido, si queremos transferir información de forma directa, podemos elegir entre dos posibles escenarios:
Copiado de información directo a un bucket de S3. El comando de copia a S3 implementa nueva funcionalidad de transferencia en paralelo de información que, unida a la división del dump de exportación en ficheros de un tamaño menor durante el proceso de export de la base de datos hace que el tiempo total de transferencia se reduzca dramáticamente.
Transferencia de paquetes UDP con Tsunami. En este escenario necesitamos montar la parte servidora de Tsunami en una máquina EC2, aunque con las condiciones adecuadas de estabilidad de la conexión de red, podemos alcanzar velocidades de transferencia muy altas.
NOTA: Sólo una advertencia importante en estos casos de transferencia de grandes volúmenes de información: Es necesario elegir de forma adecuada la instancia de destino en EC2 ya que muchas no poseen las características de networking óptimas para un performance adecuado o el volumen EBS no está optimizado (ambas características se deben elegir a la hora de iniciar una nueva instancia en AWS). En la mayoría de los casos, es mucho más recomendable iniciar el proceso con una instancia de altas prestaciones para completar el proceso de migración lo más rápido posible y luego ajustar el tamaño a las necesidades reales del servicio, que hacerlo con una instancia pequeña con el fin de limitar el gasto desde el minuto cero.
Hay que tener en cuenta que, en el caso de Oracle, una vez que el dump de la base de datos llegue por completo a S3, se deberá copiar a una máquina EC2 y luego ser transferido a RDS para iniciar el proceso de import.
Servidores y frontales
Si nuestras aplicaciones son principalmente software legado corriendo en máquinas virtuales, poco tenemos que comentar. La idea es que estas puedan pasar de la forma más sencilla posible y no tengamos que realizar muchos cambios sobre estos entornos. De esta forma, el proceso siempre será el de convertir la máquinas virtuales VMWare en origen siguiendo la documentación de AWS e importarlas como AMIs en el entorno de Amazon. Ojo con las versiones de sistema operativo, ya que nos podemos llegar a encontrar con limitaciones por parte de Amazon ante instalaciones muy viejas.
En cualquier caso, la estrategia de migración consitirá en importar en AWS una SNAPSHOT de la máquina virtual que tenemos on-premises y luego preparar los scripts de sincronización de datos necesarios para que el sistema de ficheros de la instancia remota esté totalmente actualizado en el momento de hacer el cambio.
Para el caso de servicios nuevos, la idea sería crear nuevas máquinas en EC2 basadas en imágenes que tenemos disponibles en AWS, también llamadas AMIs (como la de AWS Linux basada en CentOS).
La alta disponibilidad la conseguimos en este caso haciendo uso de un balanceador hardware o ELB y la definición de un grupo de escalado que mantenga arrancadas como mínimo el número de instancias de esta AMI que nosotros queramos fijar. Si decimos que sean dos, en caso de que una instancia caiga, EC2 arrancará una nueva máquina basada en la imagen elegida.
Como aspecto avanzado, podemos definir eventos como por ejemplo para el caso en que la CPU supere el 80% durante tres periodos de comprobación seguidos. Ante esta situación podemos indicar que el número de instancias puede crecer por ejemplo hasta 4, destruyéndose posteriormente las que sobren hasta llegar al mínimo cuando la carga baje.
Por contra, si queremos conseguir un despliegue lo más PaaS posible, tener nuestras aplicaciones desplegadas en EC2 no nos dejará del todo satisfechos. Como alternativa tenemos varias opciones para dejar de ocuparnos de la capa del sistema operativo y de su operación si utilizamos servicios como:
Elastic Beanstalk. Permite desplegar aplicaciones NodeJS, PHP, Python, Ruby, Java, Go o contenedores Docker sin tener que preocuparnos por el sistema host ni el servidor de aplicaciones en el que van a correr, ya que este lo proporciona AWS de forma transparente.
Elastic Container Service (ECS). Nos ofrece un cluster de Docker donde desplegar nuestras aplicaciones si ya las tenemos "dockerizadas".
Hay que tener en cuenta que el uso de estos servicios no supone un coste extra en nuestra factura, ya que Amazon sólo nos cobrará por la parte de almacenamiento y hardware provisionado para poder dar soporte este servicio.
Almacenamiento
Por último, queda hablar del sistema de almacenamiento, el cual debemos planificar en función de la naturaleza de los datos a migrar.
Por una parte tenemos la información de la base de datos, la cual se cargará en RDS y se gestionará enteramente en un volumen que definiremos allí, de forma que será el propio RDS el que nos proveerá de SNAPSHOTS diarias y de un sistema muy sencillo de recuperación de las mismas en caso de querer restaurar una copia en otra instancia, recuperar datos o crear réplicas de lectura (no disponible para Oracle).
Por otra parte, tenemos el almacenamiento de bloques que utilizamos para los sistemas de ficheros de nuestras máquinas EC2, los cuales pueden ser locales a cada una de nuestras instancias o compartidos entre las mismas.
Si son locales, haremos uso normalmente de un volumen EBS (ojo a lo que comentábamos de que el tipo de instancia debe proveer EBS optimizado para que el rendimiento sea adecuado), mientras que cuando son compartidos, o bien montamos un servicio de NFS entre nuestras máquinas o bien probamos el nuevo servicio Elastic File System que se encuentra aún en preview en la región de Irlanda.
Por último, todo el resto de objetos a almacenar puede ir depositado en un bucket de S3 y, activando las políticas necesarias, pasar a ser archivado en Glacier para su conservación (servicio de archivado mucho más barato y más durable, pero con un coste y tiempo de acceso mayor si necesito recuperarlo muy tempranamente).
Lo interesante de S3 es que los recursos allí almacenados se pueden servir directamente por HTTP sin necesidad de disponer de un servidor web, así que puede ser un mecanismo sencillo de distribución (el cual soporta también otros protocolos como BitTorrent).
Y mucho mucho más ...
Disculpadme si me he dejado fuera tantísimas cosas importantes como son la seguridad, el acceso mediante usuarios IAM, el API, la consola web, la autenticación de dos factores en las cuentas, la creación de roles de acceso y la posibilidad de asignarlos a máquinas a la hora de realizar operaciones de API, el registro de acciones de CloudTrail, la gestión de certificados y claves con Certificate Manager y CloudHSM, el envío de notificaciones mediante SNS, el servicio de DNS Route53 o las nuevas capacidades para ejecutar contenedores ... y mucho mucho más :)
Conclusiones
En la actualidad existen muchos factores que pueden justificar el paso de una infraestructura on-premises a una cloud, pero uno de los más importantes es el foco en nuestro core de negocio.
Las soluciones de cloud suponen un coste de inversión más alto que las de los proveedores tradicionales, pero a cambio nos ofrecen todo un conjunto de funciones de valor añadido que nos liberan de ciertas tareas de muy bajo nivel, lo que supone un ahorro de tiempo y esfuerzo.
Conocer bien tu infraestuctura te ayudará a realizar una buena planificación de un proceso de migración, pero ten en cuenta que deberás realizar cambios y ajustes previos para poder concluir el proceso con éxito.
Cuando concluyas el proceso y tengas todo tu entorno en el cloud, es muy probable que su arquitectura no sea la más adecuada para aprovechar las capacidades que ofrece el proveedor y minimizar los costes en su uso. Es por ello que el proceso de evolución debe seguir una vez completado el primer paso, haciendo que nuestra arquitectura sea cada vez más flexible y eficiente.
La adopción de herramientas y tecnologías que se están estandarizando en la industria en lugar que las específicas del proveedor puede ayudar a evitar el temido "vendor lock-in", de forma que siempre podamos ser capaces de cambiar de AWS a Google Cloud o volver a nuestro entorno on-premises si fuese necesario. En este sentido, podemos intentar apostar por herramientas de provisión como Ansible en lugar del API de AWS o Cloud Formation o, por ejemplo, por Docker y Kubernetes en lugar de Beanstalk y ECS.
En definitiva, la apuesta por el cloud está más que consolidada ... ¿Vas a apostar por ella?
Mientras el lenguaje más utilizado del mundo cumplió ya sus 20 años, hay muchas voces en el mundo del desarrollo que reniegan de Java.
Es cierto que Java es un lenguaje antiguo, que para muchas tareas es extremadamente verboso y que tiene problemas de base que uno de sus creadores, Joshua Bloch, desgranó en su libro.
Entonces, ¿por qué tantas compañías vuelven atrás y abandonan lenguajes mucho más modernos para utilizar Java? Te voy a presentar unos cuantos ejemplos y veremos si tienen algo en común.
El sorprendente caso de Twitter
Moverse a un lenguaje como Java tiene una implicación aún mayor: comenzar a utilizar la Máquina Virtual de Java
Esto significaba que sus servidores ahora podían servir 10 veces más peticiones que anteriormente.
¿Cómo era esto posible? La primera razón fue el cambio de base de datos, de MySQL a Lucene, lo que permitía búsquedas en tiempo real. Pero la segunda, y más importante, el salto a Java dejando atrás Ruby.
El utilizar la JVM como entorno de ejecución abre la puerta a una gran cantidad de lenguajes, como Scala, Clojure o Kotlin
Moverse a un lenguaje como Java tiene una implicación aún mayor: comenzar a utilizar la Máquina Virtual de Java (JVM). El runtime de Ruby tiene algunos problemas de rendimiento comparado con la JVM, lo que generaba que un servicio con tanta demanda como es Twitter tuviera problemas cuando había picos en su uso.
Pero las ventajas no acaban aquí: el utilizar la JVM como entorno de ejecución abre la puerta a una gran cantidad de lenguajes que pueden ser utilizados conjuntamente y aplicados donde resulten más eficientes. Por ejemplo Twitter utiliza Scala y Clojure para algunos de sus servicios.
Pero por lo que podemos leer en este artículo del blog de Twitter, el verdadero problema estaba en la escalabilidad de Ruby on Rails para manejar peticiones en tiempo real. Al ser un lenguaje interpretado, el consumo de CPU y memoria se disparaba conforme iba creciendo el número de usuarios.
Uber, la famosa startup, también da un paso atrás
Usar múltiples lenguajes tiene un coste en términos de velocidad: hay que solucionar el mismo problema varias veces
La arquitectura de Uber es un poco diferente, basada en microservicios. Esta filosofía les ha permitido crecer muy rápido y escribir cada uno de estos microservicios en lenguajes muy diferentes. Uber utiliza Node.js, Python, Go, Java y Scala, lo que además les permite contratar ingenieros de forma más rápida al no verse limitados por el el lenguaje.
Pero el usar tantos lenguajes diferentes se convierte en una limitación cuando se tiene que solucionar el mismo problema tantas veces como lenguajes existen. La reutilización se convierte en algo muy complejo.
Por lo que comenta Matt Ranney a InfoQ, nunca se habrían imaginado el coste que suponía el escribir los microservicios en lenguajes tan diferentes.
En Uber decidieron quedarse exclusivamente con dos lenguajes para los nuevos desarrollos: Java y Go. La razón parece ser porque sus sistemas más críticos y que requieren un mayor rendimiento, como son los que calculan rutas y tiempos estimados, están escritos en java.
Netflix
En palabras de Andrew Glover, en el Engineering Manager de Netflix:
"La gran mayoría de los servicios de nuestra arquitectura están desarrollados usando Java y la JVM. Netflix usa una arquitectura sin estado, por lo que según atraemos a más clientes podemos incluir más instancias de forma relativamente sencilla. Tenemos miles de procesos Java ejecutándose todo el tiempo, por lo que según crecemos no nos encontramos con excesivos retos de infraestructura."
"También utilizamos muchas herramientas de software libre que están basadas en Java, lo que nos hace mucho más sencillo monitorizar, actualizar y escalar nuestros servicios."
Tenemos miles de procesos Java ejecutándose todo el tiempo, por lo que según crecemos no nos encontramos con excesivos retos de infraestructura
Square
La famosa compañía de lectores de tarjetas par móviles, más conocida entre los desarrolladores (sobre todo Android) por crear algunas de las librerías que todos utilizamos también utiliza Java en sus sistemas críticos. Muy interesante la charla de Bob Lee: On the cusp of a Java renaissance, donde nos cuenta algunas de las razones.
Es mucho más sencillo contratar talento especializado en Java que en Ruby
En ella también lo compara con Ruby, y una de las mayores ventajas es la concurrencia. Mientras que Ruby puede manejar unos 10-20 procesos concurrentes por segundo, Java (con algunas tecnologías como Netty) puede superar los 100.000 procesos concurrentes, lo que supone un ahorro considerable en hardware.
Además, debido a la expansion de ambos lenguajes, es mucho más sencillo contratar talento especializado en Java que en Ruby. Este es un aspecto muy importante a tener en cuenta, pues nos encontramos en una situación en el mercado del desarrollo de software donde los perfiles especializados son muy caros y difíciles de encontrar.
Java es una opción muy real
Y como estas, hay muchas otras compañías que utilizan Java en su día a día como lenguaje principal para los sistemas de más alta demanda de sus servicios. ¿Significa esto que el resto de lenguajes no deben utilizarse? No, igual que hemos encontrado estos ejemplos para Java, se podría hacer lo mismo con muchos otros lenguajes.
En algunos entornos puede ser la solución más eficiente. En términos de concurrencia es más efectivo que otras tecnologías. También entran en juego otras características como la seguridad.
Hay una gran cantidad de software libre listo para ser integrado en nuestros proyectos, los que nos puede ahorrar muchísimo tiempo de programación.
El utilizar la JVM nos abre la puerta para un número mucho mayor de lenguajes que se ejecutan sobre la JVM, como Scala, Clojure o Kotlin, que pueden ofrecernos ventajas sobre Java, y que en general se integrarán muy bien con código ya escrito en este lenguaje.
Un último punto, y para mí uno de los más importantes: la facilidad de encontrar expertos en Java. Realmente la contratación de talento es un problema que afecta a muchas compañías, y es mucho más sencillo encontrar perfiles Java que en cualquier otro lenguaje menos conocido.
¿Entonces deberías aprender Java?
Destacar como desarrollador Java te va a ser mucho más difícil que hacerlo en algún lenguaje más minoritario
Pero si hablamos desde un punto de vista más pragmático, precisamente la escasez es la que genera sueldos más altos. Destacar como desarrollador Java te va a ser mucho más difícil que hacerlo en algún lenguaje más minoritario. La especialización es básica para que las empresas te consideren un referente.
Dicho esto, hay muchas especializaciones dentro del mundo de Java, y está claro que es un lenguaje que seguirá con nosotros mucho más tiempo. Así que tampoco será nunca una mala inversión de tiempo.
Conclusión
Java y la JVM están aquí para quedarse por mucho más tiempo. No parece que vayamos a ver sus sustitución a corto plazo, ya que muchas compañías de éxito siguen confiando en este lenguaje para sus sistemas más críticos.
Además, el auge de los lenguajes basados en la JVM hacer que podamos tener lo mejor de ambos mundos. Confiar en Java hoy en día no nos limita a usar otros lenguajes más modernos más adelante.
¿Tú qué opinas? ¿Crees que Java tiene los días contados? ¿Piensas que puede abrir puertas a la hora de buscar empleo?
Vale, tu madre no sabe explicar a tus tías a que te dedicas ("trabaja con ordenadores, internet y esas cosas"), tus amigos piensan que eres el servicio técnico de Apple y cuando se acerca una fecha de entrega, echas más horas que un reloj en el trabajo. Todo esto es cierto pero, por lo demás, ser desarrollador no está nada mal, de hecho incluso puede llegar a estar bastante bien. Como muestra, un botón en forma de 17 momentos por los que merece la pena ser desarrollador (sin demasiado orden ni concierto).
1. Cuando estrenas nuevo equipo y compruebas que ya no se te cuelga al iniciar Eclipse
Aunque claro, te quedas sin la excusa para el primer café del día. ¡Si es que no se puede tener todo!
2. Poder ponerte títulos guays en las tarjetas de visita
Como, por ejemplo, estos:
Scrum Master
Project Manager
Team Leader
PHP Ninja
Java Legend
Angular Gurú
Amado Líder
jQuery Samurai
Mother of Dragons
Python Evangelist
El Napoléon del PL/SQL
Git God
3. Cuando encuentras ese bug que tanto se te resistía y lo arreglas en un par de minutos
Somos los mejores. Y punto.
4. Cuando le dan a Star o "forkean" la librería que subiste a GitHub
Os quiero, tíos, de verdad.
5. Cuando tu respuesta en Stack Overflow es la más votada
Porque eres de los que contesta en Stack Overflow, ¿verdad?
6. Cuando tu pet project empieza a dar beneficios
El primer paso hacia el sueño (profesional) que todos tenemos: una web o app que pegue el pelotazo y nos retire.
7. Cuando aceptan tu charla para el Codemotion
Luego te puedes poner en la bio de Twitter algo como "Yo fui ponente de Codemotion 2015" y fardar.
8. Cuando "comitean" tu parche al master de ese proyecto open source que tanto te gusta
Miradme todos como lo peto. ¡Soy el rey del mundo!
9. Cuando te contactan por Linkedin de esa empresa a la que ya le tenías echado el ojo desde hace tiempo
Si tu quisieras y yo me dejara...
10. Cuando descubres que el Red Bull es gratis en la oficina
Pero con moderación, que la virtud está en el término medio, que ya lo decía Aristóteles.
11. Poder poner Konami Codes lo más frikis posibles
Por si te has quedado a cuadros: aquí la explicación de lo que es un código Konami y aquí unos cuantos ejemplos muy top.
12. Cuando le salvas la papeleta al becario y te mira como si fueras Steve Job
Luego los novatos descubren que todo lo que sabes lo aprendiste en Stack Overflow y te pierden el respeto. Ley de vida.
13. Cuando una reunión con otro área es corta y productiva
¿Es para caerse de espaldas cuando sucede esto o no?
14. Cuando heredas un proyecto y todo está bien documentado
Alerta spoiler: esto no ocurre (casi) nunca. El legacy code es nuestra gran Nemesis.
15. Cuando las fans te piden autógrafos por los pasillos de las conferencias
Alerta spoiler (II): esto sí que no pasa nunca... por lo menos en España, que en Estados Unidos como los developers are the new rockstars pues lo mismo si que pasa.
16. Cuando la columna To-Do del tablón se queda vacía
El Scrum Master no daba un duro por mi y mis estimaciones pero entonces "boom!".
17.Cuando haces deploy en producción y todo va bien a la primera
O lo que es lo mismo: me encanta que los planes salgan bien.
Pd1: Esta selección de momentazos es totalmente personal. Los comentarios quedan abiertos para que podáis aportar los vuestros.
Pd2: si nada se tuerce, la semana que viene volvemos con el lado oscuro, el reverso tenebroso, de este post. A esta misma bat-hora, en este mismo bat-canal. Stay tuned.
BDD es uno de los términos de moda en el desarrollo de software en los últimos años. A pesar de ser un término muy utilizado, no todo el mundo sabe exactamente qué es eso de BDD, más allá del significado de esas siglas, Desarrollo Dirigido por Comportamiento (Behaviour Driver Development), ni cómo puede BDD ayudarnos en nuestro trabajo diario como desarrolladores.
BDD es una evolución de TDD (Test Driven Development o Desarrollo Dirigido por Pruebas). De hecho, el concepto de BDD fue inicialmente introducido por Dan Northcomo respuesta a los problemas que surgían al enseñar TDD.
TDD está basado en 2 prácticas: Escribir las pruebas primero, y Refactorizar después:
TDD: En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito
En BDD también vamos a escribir las pruebas antes de escribir el código fuente, pero en lugar de pruebas unitarias, lo que haremos será escribir pruebas que verifiquen que el comportamiento del código es correcto desde el punto de vista de negocio. Tras escribir las pruebas escribimos el código fuente de la funcionalidad que haga que estas pruebas pasen correctamente. Después refactorizamos el código fuente.
Partiremos de historias de usuario, siguiendo el modelo “Como [rol ] quiero [ característica ] para que [los beneficios]”. A partir de aquí, en lugar de describir en 'lenguaje natural' lo que tiene que hacer esa nueva funcionalidad, vamos a usar un lenguaje que nos va a permitir describir todas nuestras funcionalidades de una misma forma, un lenguaje específico para BDD, como Gherkin, del que hablaremos un poco más adelante.
Este lenguaje con el que vamos a describir las funcionalidades es lo que en DDD (Domain Driven Design o Diseño Guiado por el Dominio) llaman lenguaje ubicuo, es decir, un lenguaje semiformal que es compartido por todos los miembros de un equipo de desarrollo de software, tanto desarrolladores de software como personal no técnico. Este es uno de los aspectos claves: BDD facilita la comunicación entre todos los implicados en el desarrollo, sean técnicos o no.
BDD es un proceso de desarrollo de software que trata de combinar los aspectos puramente técnivos y los de negocio, de manera que tengamos un marco de trabajo, y un marco de pruebas, en el que los requisitos de negocio formen parte del proceso de desarrollo.
A la hora de definir cada funcionalidad, una opción es que esa definición venga por parte de negocio, quién posteriormente se la pasa a desarrollo (o testing), quienes escriben las pruebas. Es una opción, pero no es la única, y probablemente tampoco sea la mejor.
Otra opción es que sean los propios desarrolladores quienes escriban esta definición de las funcionalidades, a partir de la descripción a alto nivel de la funcionalidad que le ha dado la gente de negocio. Esto hace que los desarrolladores tengan que ver esa funcionalidad desde el punto de vista de negocio, y eso es positivo.
Una tercera posibilidad es que estas funcionalidades se escriban conjuntamente por negocio y desarrollo, por ejemplo durante la reunión del Sprint Planning. De esta forma pasaríamos de una lista de requisitos priorizada que el product owner presenta al equipo de desarrollo, a una lista de pruebas de comportamiento que pasan como tareas al Sprint Backlog.
Se trata de unir la especificación funcional con la documentación de pruebas, para ayudar a eliminar la distancia entre las personas de negocio y los desarrolladores.
Gherkin
Gherkin, es un lenguaje comprensible por humanos y por ordenadores, con el que vamos a describir las funcionalidades, definiendo el comportamiento del software, sin entrar en su implementación. Se trata de un lenguaje fácil de leer, fácil de entender y fácil de escribir. Es un lenguaje de los que Martin Fowler llama 'Business Readable DSL', es decir, 'Lenguaje Específico de Dominio legible por Negocio'.
Utilizar Gherkin nos va a permitir crear una documentación viva a la vez que automatizamos los tests, haciéndolo además con un lenguaje que puede entender negocio. Otro aspecto interesante es que se puede usar Gherkin en otros idiomas, no sólo en inglés. Actualmente Gherkin soporta más de 60 idiomas.
Lo bueno de Gherkin es que para empezar a hacer BDD sólo nos hace falta conocer 5 palabras, con las que construiremos sentencias con las que vamos a describir las funcionalidades:
Feature: Indica el nombre de la funcionalidad que vamos a probar. Debe ser un título claro y explícito. Incluímos aquí una descripción en forma de historia de usuario: “Como [rol ] quiero [ característica ] para que [los beneficios]”. Sobre esta descripción empezaremos a construir nuestros escenarios de prueba.
Scenario: Describe cada escenario que vamos a probar.
Given: Provee contexto para el escenario en que se va a ejecutar el test, tales como punto donde se ejecuta el test, o prerequisitos en los datos. Incluye los pasos necesarios para poner al sistema en el estado que se desea probar.
When: Especifica el conjunto de acciones que lanzan el test. La interacción del usuario que acciona la funcionalidad que deseamos testear.
Then: Especifica el resultado esperado en el test. Observamos los cambios en el sistema y vemos si son los deseados.
Lo normal es probar distintos escenarios para comprobar una determinada funcionalidad. De esta forma vamos a pasar de nuestras historias de usuario a pruebas de comportamiento automatizables. Para automatizar estas pruebas necesitamos apoyarnos en herramientas, como Cucumber, que entiende perfectamente el lenguaje Gherkin.
Cucumber
Cucumber es una de las herramientas que podemos utilizar para automatizar nuestras pruebas en BDD. Cucumber nos va permitir ejecutar descripciones funcionales en texto plano como pruebas de software automatizadas.
Cucumber fue creada en 2008 por Aslak Hellesoy y está escrito en Ruby, aunque tiene implementaciones para casi cualquier lenguaje de programación: JRuby (usando Cucumber-JVM), Java, Groovy, JavaScript, JavaScript (usando Cucumber-JVM y Rhino), Clojure, Gosu, Lua, .NET (usando SpecFlow), PHP (usando Behat), Jython, C++ o Tcl.
Otros frameworks BDD
Cucumer es probablemente la herramienta más conocida y más utilizada para automatizar pruebas en BDD, pero existen otros frameworks con los que poder hacer BDD para los lenguajes de programación más habituales:
Una de las formas más sencilla de instalar Cucumber para nuestras primeras pruebas es hacerlo con node. Para ello simplemente debemos ejecutar desde una ventana de línea de comandos:
npm install -g cucumber
Tras esto, si todo ha ido bien, tendremos cucumber instalado en nuestra máquina.
Los casos de tests se escriben en archivos con la extensión .feature, y dentro de cada uno de estos archivos hay uno o más escenarios de prueba. Primero vamos a crear una carpeta cucumber, dentro de esta una carpeta features, y dentro nuestro primer archivo .features.
Vamos a partir de una historia de usuario, con el esquema clásico: “Como [As a human] quiero [ search GenbetDev en Google] para que [find GenvetaDev website]”, para crear el caso de prueba que vamos a automatizar con Cucumber:
Feature: Buscar GenbetaDev en google
As a human
I want to search GenbetDev en Google
So I can find GenvetaDev website
Scenario: Search for Genbeta Dev
Given I have visited Google
When I search for "GenbetaDev"
Then I see "Genbeta Dev"
Copiamos ese texto en nuestro archivo y lo llamamos 'my_feature.feature'. Ahora vamos a ejecutar nuestro test. Para ello, suponiendo que estemos en windows, desde una ventana de comandos ejecutamos:
cucumber-js features/my_feature.feature
En linux sería:
cucumber.js features/my_feature.feature
El resultado será el siguiente:
Esto lo que nos indica es que debemos ahora implementar el código de pruebas que permita verificar ese test. Una posibilidad sería la siguiente:
module.exports = function() {
this.Given(/^I have visited Google$/, function () {
browser.url('http://google.com');
});
this.When(/^I search for "([^"]*)"$/, function (searchTerm) {
browser.setValue('input[name="q"]', searchTerm);
browser.keys(['Enter']);
});
this.Then(/^I see "([^"]*)"$/, function (link) {
browser.waitForExist('a=' + link, 5000);
});
}
Llegados a este punto, al contrario de lo que ocurría con Chimp.js, que se encargaba de instalar todo lo necesario para poder probar, con Cucumber tenemos muchas alternativas y somos nosotros los que debemos decantarnos por unas herramientas u otras como complemento, dependiendo también del lenguaje de programación que elijamos. Por ejemplo, para pruebas web, podemos apoyarnos en capybara, cucumber-mink, o en navegadores como zombie.js o phantom.js, junto con selenium webdriver.
No es la primera, ni la última vez que escribo sobre la enorme complejidad inherente al desarrollo de software. De la necesidad -siempre creciente- de conocimiento que soportan todos los actores en la industria actual. Y lo fácil que es perder el ritmo para mantenerse en la cresta de la ola tecnológica.
Las metodologías, procesos y procedimientos intentan ordenar el caos hacia donde tienden las construcciones de aplicaciones informáticas. Mientras que las herramientas, a su vez, ganan en profundidad y ámbito de actuación en una búsqueda permanente de liberar al factor humano de las tareas repetitivas o tendentes al error, para que se pueda centrar en utilizar su talento y capacidad intelectual en la codificación y los retos algorítmicos que se presentan.
Los orígenes
Como con muchas de las cosas relacionadas con la informática, no existe un origen claro, y definido del termino DevOps. Algunos opinan que es una evolución natural y esperada del concepto de ALM (Gestión del Ciclo de Vida de las Aplicaciones), de lo cual Andrew Clay Shafer y Patrick Debois hablaron en la conferencia Agile del 2008 de Toronto; y donde utilizaron por primera vez el término de "Infraestructura Agile".
Mike Loukides, publicó un completo análisis en donde sostiene que DevOps era la forma natural de trabajar en los tiempos iniciales de la informática (el programador también cambiaba las cintas), y que se separaron las funciones de Programación y Operaciones en los años 60. Mike, continua con un análisis detallado del artículo de Adrian Cockcroft, en donde se refiere a NoOps, término en donde se unen los conceptos de DevOps y PaaS (Plataforma como servicio). Siendo esto un estado final extremo, en donde los departamentos de IT estarían vacíos de sentido en la industria de desarrollo de software.
Incluso, el origen de DevOps pudiera provenir del libro The Phoenix Project, que describe el compendio de todas las cosas que pueden ir mal en un proyecto de desarrollo de software, y cómo paliar los impedimentos por medio de la automatización. Lo que es indudable es que esta obra se ha convertido en una referencia del movimiento DevOps.
Descripción del ciclo de DevOps
¿Pero cuál es el ciclo al que se llama DevOps? De forma simplificada, se podría resumir en la siguiente imagen:
Como se puedo observar al primer vistazo, DevOps tiene sus raíces en metodologías Iterativas, y más específicamente en la evolución de las herramientas para desarrollo Agile.
Reúne en un solo bucle dos mundos de la industria que hasta ahora estaban meridianamente separados, y que ha sido fuente de rivalidades y discusiones durante las últimas décadas: Desarrollo y Operaciones.
Sin embargo, el objetivo de DevOps es que ambos grupos de trabajo se coordinen, se comuniquen y establezcan lazos de cooperación que dejen atrás esas diferencias artificiales, frente a las necesidades de integración que los sistemas informáticos requieren.
Planificación.
Esto, que en metodologías en Cascada es el principal escollo para un desarrollo iterativo, en Agile se convierte en una conversación continuada con el cliente. En donde se define el trabajo a realizar, se prioriza de acuerdo a su complejidad y valor, o se cambia el alcance de forma dinámica, quitando o añadiendo requisitos dentro del tiempo acordado.
Es esta planificación, la inicial para sentar las bases del proyecto y las que se suceden de forma continuada durante todos los sprint, sobre la que trabaja el equipo. Decidiendo cual es la forma óptima de construir y tomando las decisiones tecnológicas que correspondan.
Con la actualización diaria de la herramienta de visualización del flujo de trabajo, y las liturgias de descritas por la metodología, se realiza un seguimiento del estado del proyecto y de los impedimentos que estuvieran afectando al desarrollo.
Desde el punto de vista de las herramientas de DevOps, partiendo de una visión Agile, estas soportan todos los trabajos de documentación, modelado de la planificación y las priorizaciones. También, la gestión del flujo de trabajo por medio de tableros electrónicos, la obtención de métricas y la visibilidad del estado de avance de forma sencilla e inmediata.
Kanban Virtual. Tareas en diferentes estados a partir de las Historias de Usuario.
Desarrollo y pruebas
En este capítulo lo que más impacto tiene, desde el punto de vista de DevOps, es la automatización del almacenamiento del código. Para ello existen plataformas de control de versiones que permiten realizar conceptos básicos como versionado, histórico y trabajo colaborativo por medio de estructuras de desarrollo en ramas.
Estos repositorios de código han dado un paso adelante al asociar el código al flujo de tareas, permitiendo una trazabilidad absoluta, e integrando las herramientas de pruebas, rendimiento y calidad, en el flujo de trabajo diario del desarrollador.
Pero nada de ello tendría sentido si no hubiera una (re) evolución cultural (nacida en los años 90) en la industria de la codificación de software, que ha traído nuevos baremos de calidad y buenas prácticas; donde ya no solamente importa que las aplicaciones funcionen bien, si no también el cómo lo hacen. Y que aún dista de estar implantada en la generalidad de nuestro sector.
Publicación continúa
Resultado de una Build de Integración Continua
Si tengo código versionado, y tengo baterías de pruebas que aseguran tanto la calidad como el funcionamiento de toda la aplicación, automatizando dichos procesos he llegado al concepto de Integración Continua.
Cada vez que yo actualice mi código en el repositorio, se va a lanzar la ejecución de todas las pruebas necesarias que revisen su integración con el resto del software, y que no “rompe” nada.
Fácil es de ver que el siguiente paso dentro del flujo de automatizaciones es que, ese código compilado y comprobado, pueda ser desplegado de forma automática -previa las validaciones necesarias- en los diferentes servidores de la plataforma (QA, Pre, Pro, etc.)
Y, fíjate, aquí ya estamos saliendo del ámbito exclusivo del desarrollador, y hemos entrado en el área de Sistemas.
Ya no hablamos de código, sino de infraestructura. Y de las necesidades que tiene un IT para asegurar que las actualizaciones o mejoras no producen incidencias en Producción. Es decir, disponer de las herramientas necesarias para poder visualizar tempranamente los problemas y actuar sobre ellos.
Análisis de operación
El gran cambio que representa DevOps en comparación con lo que hasta ayer se llamaba ALM, viene de la automatización del análisis de las operaciones: monitorizar de forma constante la salud de la aplicación y de la infraestructura.
Pruebas de carga contra un servidor Web
No solamente se trata que IT, por medio de contadores y alertas, siga realizando sus labores de auditorías del estado de los servidores y comunicaciones; si no que ahora se aboga por el uso de herramientas específicas que obtengan las métricas que supervisan el estado de salud del funcionamiento del software y que permitan el acceso al histórico de resultados en donde poder visualizar - de forma sencilla - la evolución del producto.
Así, se pueden tomar decisiones estratégicas relacionadas con la escalabilidad, con la infraestructura como software, y con los trabajos correctivos y evolutivos que todo programa soporta durante su vida útil. Cerrando el círculo de DevOps al utilizar las conclusiones de los Análisis de operación como parte de la planificación de los trabajos que se deben realizar sobre el software.
¿Es DevOps una moda?
Sí, pero no.
Sí, en la realidad de que quien más está solicitando servicios de DevOps son los departamentos de IT de las empresas. Quienes, en muchos casos, se están haciendo eco del runrún de la industria que tiene palabras como Agile o iteración como paradigma del cambio necesario en la búsqueda de evitar los fracasos de los proyectos; pero sin tener un conocimiento firme sobre – tan siquiera- la gestión del ciclo de vida de las aplicaciones o metodologías de desarrollo Agile.
No, ya que DevOps trata sobre plasmar sentido común a las complejas operaciones de codificación y sistemas que comprenden el desarrollo de productos informáticos. Y que, cuanto más tiempo pase y más empresas lo implanten, más se mostrará de forma indiscutible el aumento de productividad que conlleva.
Como señalaba anteriormente, DevOps incluye los propios mecanismos para validar la mejora que implica aplicar esta cultura empresarial en los departamentos de desarrollo y sistemas. Siendo esto, junto con la flexibilidad de cambiar la orientación del desarrollo hacia el camino más óptimo en cada ocasión, la semilla de su propio éxito y del sobrevivir al estado actual de moda.
Supón que sigues todas las guías de estilo, eres "clean", cuidadoso, fiel seguidor de TDD, conoces tu plataforma, ... pero, aun así, por una extraña razón, con el tiempo tu sistema se tambalea, o debes perder mucho tiempo en refactorizar, o el número de tests hace que tus despliegues demoren horas, o cada vez te resulta más confuso ver la mejor forma de introducir mejoras, ... ¿qué ha fallado?
No estoy hablando de cuando se hacen las cosas mal (en que es más o menos obvio que tarde o temprano se pierda el control), estoy hablando de cuando las cosas se hacen bien o, al menos, se han seguido los cánones marcados por la industria. No es infrecuente perder el control de un proyecto y ocurre en una gran variedad de ámbitos, equipos grandes o pequeños, en grandes y pequeñas empresas, con recursos y sin recursos.
¿Qué es la fragilidad del software?
La fragilidad del software representa una propiedad global de un sistema (de software), pero no de lo bien o mal que funciona, sino de la capacidad del mismo para adaptarse a algún cambio. Así, un sistema puede ser muy robusto, tolerante a fallos, rápido, ... y, aun así, ser tremendamente frágil. Si cuando de un sistema que funciona bien (razonablemente, bien o muy bien) se dice "mejor no tocarlo", es porque ese sistema es frágil.
La fragilidad del software da idea de la capacidad de un sistema de software para adaptarse a algún cambio
Si definir la fragilidad del software resulta bastante sencillo (tolerancia al cambio), determinar y/o identificar sus causas resulta tremendamente complicado ya que existen innumerables razones por las que un sistema se vuelve frágil, pero además, dichas razones están con frecuencia interrelacionadas (enrevesadas mas bien) de modo que, por ejemplo, alguien podría pensar que un sistema es más frágil cuanto más tiempo transcurre sin mantenimiento (por ejemplo, porque la plataforma de desarrollo evoluciona y debe guardarse, recuperarse o reinstalarse una versión acorde a dicho sistema), pero no es menos cierto el recíproco, que un sistema es más frágil cuanto más modificaciones sufre (por ejemplo, si no mantenemos la probabilidad de detectar y corregir por encima de la de introducir errores, los errores, sólo pueden aumentar con el tiempo).
Por el ejemplo primero queda claro que no es suficiente con "no tocar nada" para que no aumente la fragilidad de nuestro software (¡aumentará aunque no modifiquemos nada!) y por el segundo que la fragilidad aumentará o disminuirá de acuerdo a un complicadísimo juego de malabares entre una aparente infinidad de factores interrelacionados (enrevesados).
no es suficiente con "no tocar nada" para que no aumente la fragilidad de nuestro software
¿En qué me afecta la fragilidad del software?
En primer lugar decir que, el que no te sientas afectado (no percibas síntomas de fragilidad en tus softwares) ya es un síntoma de que (quizás) estés ignorando la fragilidad del software, en el sentido de que puedas estar derrochando recursos (muy probablemente), no obstante, es sin duda el mejor punto del que partir (siempre que ese derroche sea asumible).
Sin embargo en general (con excepciones por supuesto) y en todo tipo de países y empresas (ojo, en mi subjetiva experiencia), los sistemas frágiles están a la orden del día, y existe una clara intención (que sea consciente o inconsciente lo desconozco) de mantener un equilibrio entre los costes y la fragilidad del sistema de tal forma que el patrón habitual suele ser rentabilizar el sistema al máximo y por tanto, asumiendo muchos inconvenientes que no son populares (a.k.a son vergonzantes) en el mundillo. Decidir si es un acierto o una equivocación a mí me parece que es mucho más difícil de lo que parece, porque aunque seguro que todos tenemos en mente proyectos que han sido un desastre, lo cierto es que esas empresas funcionan y ganan mucho dinero con esos sistemas tan frágiles. Si les afecta, no lo parece mucho.
esas empresas funcionan y ganan mucho dinero con esos sistemas tan frágiles
Por otro lado, también hemos comentado que aunque un sistema no se modifique (no sólo el codebase, me refiero a todo el sistema, incluyendo hardware, personal, etc...), la fragilidad aumenta, aunque en dicho caso, no se sufre (manifiesta) dicha fragilidad. Un ejemplo podrían ser los videojuegos, la gran mayoría de los juegos poseen una fragilidad "latente" bastante elevada (no tan grande como cabría esperar porque suelen ser "cajas negras", compárese dicha fragilidad con aquellos que requieren un servidor para funcionar...) pero el mecanismo de la emulación, permite congelar ese estado y la fragilidad de todos los juegos emulados pasa a ser la que tenga el emulador.
Por tanto, que la fragilidad exista en mayor o menor medida no parece ser tan relevante como que tenga un efecto real sobre nuestros objetivos. ¿No estaría bien poder determinar o regular en qué medida me va a afectar la fragilidad de mi sistema?.
¿Qué hace frágil un sistema?
Que yo sepa, nadie lo sabe, es decir, está claro que proviene de infinidad de factores interrelacionados y trivialmente podríamos enumerar una gran cantidad de ellos, también podemos enumerar cuestiones que nos parecen obvias (muchas de las cuales son ampliamente discutidas, tan obvias no serán...), pero no hay un modelo matemático (sí algunas métricas) que describa la evolución de la fragilidad de un sistema y por tanto que nos permita hacer predicciones, como se hace con el tiempo meteorológico, y actuar anticipadamente y/o de forma inteligente (preventiva).
De todos modos, podemos enumerar algunos muy muy generales que engloban otros muchos particulares:
fallos de software: básicamente "corner cases" cruzados entre múltiples piezas de software que a posteriori son difíciles de identificar o, aunque son identificados, son difíciles de aplicar una solución global (por las interacciones producidas).
fallos en la arquitectura: básicamente incoherencias en el/los modelo/s utilizados a lo largo del tiempo, normalmente introducidos por desconocimiento (ej. pensar que el cliente conoce las interrelaciones de su negocio) o bien de forma consciente por imposibilidad de definir un modelo mejor, ésto tiene (al menos) dos causas no excluyentes, la falta de recursos y/o la impredictibilidad (que no es exactamente desconocimiento).
fallos en el proceso: aquí estarían todas las técnicas englobadas por el término "buenas prácticas": clean code, documentación, patrones, testing, ...
fallos de hardware: el software requiere un hardware para funcionar (un emulador al final corre en un hardware) y no siempre es fácil emular todo el contexto que requiere el software (por ejemplo, ya hemos comparado la fragilidad de los juegos "caja negra" y aquellos que requieren un servidor para funcionar).
fallos de personal: no sólo de aquellas implicadas directamente en el sistema, aun cuando la "caja negra" que describe nuestro software no sufra ningún tipo de modificación, la fragilidad puede provenir del uso que terceras personas hacen de él (en el boom de las .com [en España ya en este milenio] se percibió claramente, pues las páginas web "viejas" asumían un internauta "friki" pero cada vez más internautas "normales" accedían a la red requiriendo un replanteamiento de las mismas, todo ello derivó en libros como "No me hagas pensar" de Steve Krug).
Fragilidad del software y la entropía
Si estás al tanto de la segunda ley de la termodinámica, te habrás fijado que la evolución de un sistema software y la evolución de su fragilidad tiene mucho que ver con la entropía de un sistema. Lehman indica que cuando se modifica un software, su complejidad siempre crece, pero yo (osado de mi) no estoy de acuerdo pues nuestro sistema software no está cerrado y de la misma forma que nuestra entropía decrece con nuestro ciclo vital (comer y ...; véase El camino a la realidad de Roger Penrose) podemos reducir la entropía de nuestro software a costa de aumentar (por ejemplo) la nuestra propia.
Una demostración (por fuerza informal) es que partiendo de un código vacío, podemos recorrer el ínfinito grafo de ediciones que podemos hacer sobre el mismo (por ejemplo, "v", "vo", "voi", "void" "voidm", "voidma", "voidm", "void", "void ", "void m", "void ma", "void mai", "void main", ...) y por tanto es obvio que podemos movernos a voluntad por todo el grafo, donde cada uno de los nodos corresponde a un estado de nuestro codebase (unos compilarán y otros no, unos tendrán más fragilidad y otros menos, etc...). Digamos básicamente que podemos reducir (¡o aumentar!) la complejidad (fragilidad y entropía) de nuestro software tirándola por el retrete...
Este resultado era obvio, cuanto más recursos dediquemos, más probable será (¡que no seguro!) que la fragilidad de nuestro sistema se reduzca (moviéndonos por el grafo de estados de nuestro código), la cuestión es ¿cuales son los recursos mínimos necesarios y cómo usarlos para que la fragilidad de mis sistemas estén dentro de cierto margen?.
¿Cuáles son los recursos mínimos necesarios y cómo usarlos para que la fragilidad de mis sistemas estén dentro de cierto margen?
¿Cómo minimizar la fragilidad de mi sistema?
Yo no lo se. La respuesta fácil es enumerar términos como clean, TDD, KISS, patrones, microservicios, ... pero son sólo técnicas, manifiestos, guías, ... basados en la experiencia y que pueden o no encajar con nuestro contexto particular. Obviamente usar buenas prácticas parece adecuado, pero no hay que olvidar que una buena práctica mal usada se convierte rápidamente en una pésima práctica y, además, ya hemos visto que dichas prácticas son sólo una parte, no hace mucho Google se preguntaba porqué algunos equipos de trabajo funcionan y otros no (otro factor que tiene visos de afectar a la fragilidad del producto).
Una buena práctica mal usada se convierte rápidamente en una pésima práctica
Parece entonces que hay "algo" por encima de esas prácticas que debería poder hacerse de las cuales yo veo dos sobre otras (que habrá, que yo desconozco y que puede sean más relevantes): la experiencia y sentido común de quien aplica las soluciones, pues es dicha experiencia la que sabe seleccionar las técnicas (ej. herramientas, normativa, arquitectura, ...) más adecuadas para el caso (y ésto es algo que no puede transmitirse fácilmente de unas personas a otras; los términos enumerados anteriormente apuntan a ello) y algo que sí creo firmemente que ayudaría sustancialmente a contener la fragilidad de nuestros sistemas son los estándares (porque definen autopistas sobre las que no hay margen de elección y pueden aprenderse muy fácilmente) que a nadie parece importarles demasiado o quizás nadie consigue definir buenos estándares para nuestros problemas pero, si lo piensas, son los estándares fijados hace décadas las partes de nuestros sistema que siempre funcionan y de las que ni siquiera nos fijamos (por asumidas) cuando ponemos los dedos en nuestros teclados.
Algunos recordamos con dolor aquellos días en los que teníamos que usar Eclipse para desarrollar aplicaciones en Android. El cambio a Android Studio y la introducción de Gradle supusieron un innumerable número de mejoras y de flexibilidad que aún a día de hoy sigue dando sus frutos.
El nuevo Android Studio 2.2 presentado durante el Google I/O ha querido ir más allá, ofreciendo una gran cantidad de herramientas que facilitarán mucho el día a día de los programadores Android.
Hemos podido ver mejoras a nivel de diseño, desarrollo, compilación y testing, de las que paso a hablarte una a una.
Diseño
En este aspecto hemos visto el que quizá sea el cambio más grande que se ha hecho en la forma de diseñar pantallas desde que se implantó Android Studio. ¿Conseguirán por fin que nos olvidemos del XML y utilicemos el diseñador visual?
Nuevo editor de layouts y el Constraint Layout
El nuevo `ConstraintLayout`, diseñado para ser utilizado con el editor, nos permitirá crear interfaces de usuario complejas sin necesidad de anidar múltiples ViewGroup
El editor de layouts ha sido totalmente renovado y adaptado para ser más sencillo de usar. Las dos características principales son:
El modo blueprint: Con él podemos ver la "radiografía" de nuestro layout: cómo cada una de las vistas se relaciona con el resto, especialmente útil para el nuevo ConstraintLayout.
Un panel de propiedades simplificado: Se ha hecho un gran esfuerzo de organización para dejar a la vista sólo las propiedades más utilizadas de cada una de las vistas, de tal forma que no nos volvamos locos buscando entre propiedades que casi nunca se usan. Siempre podremos pasar a una vista más detallada para ver el resto.
Muy relacionado con este nuevo editor, nos llega el que han llamado ConstraintLayout, un layout específicamente diseñado para ser utilizado con el editor y que, nos aseguran, nos permitirá crear interfaces de usuario complejas sin necesidad de anidar múltiples ViewGroup. Esto supone una mejora en cuanto a rendimiento.
El ConstraintLayout basa su funcionamiento en "constraints" que anclan unas vistas a otras, a posiciones de la pantalla, etc. Aquí es donde el modo blueprint nos ayuda a saber qué está ocurriendo. Además, el editor puede calcular de forma inteligente algunos de estos constraints.
Por lo que he podido probar, requiere un poco de práctica hasta que se entiende cómo funciona, pero parece muy potente.
Inspector de layouts
Aunque ya teníamos un inspector que nos permitía saber cómo estaba estructurada una vista, este nuevo inspector es mucho más potente, pudiendo revisar toda la jerarquía de vistas, y qué atributos tiene cada una. Se puede acceder a él desde el monitor de Android.
La pena es que sólo se puede usar con Apps en debug. Sería muy interesante poder inspeccionar cualquier pantalla de cualquier aplicación, y aprender cómo ha sido diseñada.
Desarrollo
El nuevo Android Studio 2.2 se alinea con la última versión de IntelliJ (2016.1), incluyendo todas sus novedades. Pero, además, incluye mejoras en otros frentes
Un plugin para Firebase
Si no te perdiste el Google I/O, sabrás que Google ha transformado Firebase en la herramienta con la que todo desarrollador de Apps soñaría y, además, gratis hasta cierto número de peticiones.
Las novedades darían para un artículo completo, pero en Firebase se han integrado herramientas como analíticas, mensajería en la nube, AdMob, informe de errores, notificaciones push, almacenamiento en la nube...
El asistente que se incluye ayuda a trabajar con Firebase de forma mucho más sencilla, indicándonos los pasos necesarios para integrar cualquiera de los servicios.
Buscador de ejemplos de código
Si sobre cualquier clase hacemos click con el botón derecho (o ALT+F8), obtendremos un listado de ejemplos donde se usa esa clase en los distintos repositorios de Google.
De esta forma puedes ver en contexto cómo se utilizan clases que no conocías. Realmente útil.
Y más mejoras
Lint incluye algunas novedades, y ahora detecta nuevos casos donde puede haber problemas. Uno de los que más me ha llamado la atención es que ayuda a detectar la visibilidad adecuada, como por ejemplo un método que es público y podría ser privado.
Además, se han añadido mejoras cuando se trabaja con C++ y el NDK, permitiendo depuración paso a paso mucho más precisa por ejemplo, y saltando sin problema entre código Java y C++.
Construcción
El compilador experimental Jack ahora soporta anotaciones y compilación incremental
En este aspecto siguen las mejoras relacionadas Instant Run, que sigue evolucionando hacia el objetivo de conseguir que la gran mayoría de las ejecuciones sean en caliente, y por tanto no necesiten reiniciar la aplicación.
Pero además también ha habido avances en el compilador experimental Jack, que ahora soporta anotaciones y compilación incremental.
Una novedad muy interesante es el nuevo visor del Merged Manifest. Cuando se compila una aplicación, todos los Manifest de las librerías que incluyas en tu proyecto se unen en uno solo, que es el que conforma el Manifest final. A veces ocurre que tu aplicación pide un permiso que tú no has añadido, y no sabes qué librería lo está incluyendo. Con el nuevo visor no volverás a tener ese problema.
Testing
En el futuro, Android Studio podrá guardar tu interacción como tests de Espresso
En testing, la novedad principal es que podremos grabar nuestra interacción con la aplicación en forma de tests de Espresso, de tal forma que luego se puedan reproducir automáticamente como tests de instrumentación. En la última versión hasta la fecha (2.2 Preview 2) aún no se ha añadido esta función, pero estará disponible en algún momento.
Una novedad de la que sí que podemos disfrutar ya es la del analizador de APK. ¿No sabes qué hace que tu APK ocupe tanto espacio? ¿Quieres saber qué librería está haciendo que llegues al límite de 64.000 métodos? Puedes comprobar todo esto y mucho más.
Ve a "Build" y allí encontrarás la opción "Analyze APK". Aquí puedes inspeccionar todo el contenido del APK, como los recursos, los layouts, las clases que utiliza, etc.
Conclusión
Como ves, son muchas las novedades que nos ha traído esta nueva versión del Android Studio. Desde mejoras a nivel de diseño como el nuevo editor de layouts, hasta otras útiles para detectar problemas como el inspector de layouts, el de APKs o el visor del Manifest.
Muchas mejoras que nos ayudan a los desarrolladores Android a crear aplicaciones de mayor calidad en menos tiempo.
¿Has probado el nuevo Android Studio? ¿Qué te parecen todas estas mejoras?
