Por fin hemos pasado a producción, la aplicación ha terminado de ser desplegada en la plataforma accesible a los usuarios y podemos dar por terminada la iteración actual llena de crisis, nervios y sobreesfuerzos; que han culminado en un fin de semana de trabajo continuado.

Disfrutamos de un breve y merecido descanso antes de volver temprano a la oficina para arrancar la siguiente iteración, planificando las tareas a realizar y coordinando los equipos de desarrollo, UX y calidad.

Pero, la primera llamada a media mañana, ha despertado la pesadilla que se ha ido gestando según el número de accesos ascendía siguiendo al sol.

Y ahora – cuando los problemas se están escalando hacia Dirección como la espuma de un mal cava – un sistema sobrecargado ha terminado por presentar un rendimiento inutilizablemente lento.

Las pruebas como garantes del rendimiento

Cuando estoy describiendo el concepto de Ingeniería del rendimiento, una vez más, no estoy hablando de conceptos nuevos o recientes. Ya en 2004 Microsoft, el equipo de Patterns & Practices, publicó un detallado documento sobre este tipo de Ingeniería, que sería actualizado en el 2012 con una versión Agile.

Básicamente lo que se documenta es la necesidad de realizar una programación orientada al rendimiento, en donde se integre este tipo de pruebas en el ciclo de vida de las aplicaciones, asegurando que - en cada una de las etapas - el sistema funcione dentro del rango de prestaciones esperadas para que su funcionamiento sea el correcto.

Siendo el objetivo final de estos patrones y prácticas (procesos) la transformación desde una aproximación reactiva a otra proactiva, en relación al rendimiento de la plataforma de hardware y software sobre la que funcionan las aplicaciones.

Los test unitarios, de integración, de sistemas o, incluso, los funcionales del Interfaz gráfico, están orientados a asegurar el funcionamiento correcto del código y de la aplicación con respecto a los requisitos funcionales.

Sin embargo, la Ingeniería del rendimiento se refiere a la necesidad de tener planes de prueba, lo más automatizados posibles, centrados en los requisitos no funcionales de la plataforma en donde se despliega y funciona el software.

Eso significa que estás pruebas están orientadas y dirigidas por el área de negocio. Quien realiza las priorizaciones de acuerdo a valores críticos del “business” como es el valor de los beneficios, la optimización de los costes o el impacto de los fallos del servicio.

Incluso puedo dar la vuelta a la tortilla, y utilizar los resultados de las baterías de pruebas como marco e indicador de la infraestructura necesaria para conseguir cumplir las expectativas. Definiendo el rendimiento de la aplicación primero y, luego, desarrollar el software orientado a cumplir el Plan de pruebas, para obtener unas prestaciones de ejecución determinadas.

Los cuatro test contra el apocalipsis

Como obliga cualquier proceso de construcción de software, lo primero que se necesita para definir el Plan de pruebas de rendimiento son: unos buenos requisitos. Con Criterios de Aceptación claros y bien detallados, que no dependan de interpretación y que – idealmente – puedan ser descritos de forma algorítmica con valores numéricos.

Por ejemplo: “Siendo un tipo de usuario determinado, el sistema debe devolver la respuesta de una búsqueda de clientes en menos de 5 segundos cuando están realizando búsquedas 250 usuarios de forma concurrente (no simultanea) en menos de 1 minuto. No superando los 10 segundos de respuesta cuando haya cargas puntuales de hasta 500 usuarios concurrentes.”

A estos requisitos, habría que añadirle aquellos que sean más técnicos, dependientes del hardware o de otras plataformas que deban ser integradas, y que se irán descubriendo durante todo el ciclo de vida de la aplicación.

En definitiva, deberé de construir una Pila de pruebas orientada a los cuatro tipos de test– y sus variantes – que se utilizaran para asegurar las prestaciones.

Test de carga

Los Test de Carga se llevan a cabo para asegurar que la aplicación cumple los objetivos de rendimiento esperados.

Con esta prueba se obtienen métricas sobre los tiempos de respuesta, las tasas de rendimiento y el consumo de recursos. Pudiendo señalar los puntos en donde empieza a fallar la aplicación, si aún no se ha llegado a los límites de sobrecarga.

Un subconjunto de este tipo de test son las pruebas de resistencia, en donde se sostiene durante un largo periodo de tiempo al uso normal esperado, y se comprueba el comportamiento del sistema.

Así se puede obtener indicadores como el “Tiempo entre fallos”, el “Tiempo medio de fallo” o similares, que permiten realizar acciones preventivas en el futuro.

Test de estrés

El objetivo de estas pruebas es revelar errores y bloqueos en la aplicación cuando es llevada a situaciones de carga alta. Es decir, un gran número de transacciones, de transferencias, de peticiones, de cálculos, etc.

El sistema se estresa llevándolo a los valores máximos esperados en las operaciones en producción, y se mantiene una monitorización constante del hardware y el software para tomar métricas sobre el comportamiento del sistema tanto durante la prueba de carga como en la recuperación del mismo al relajar la prueba de estrés.

Especialmente duras aquellas, en donde se lleva el sistema a superar varias veces su capacidad teórica y esperada - incluso llegando al colapso de la plataforma - durante breves espacios de tiempo. Pudiendo observar y medir cómo se comporta el sistema en esas condiciones, cuales son los subsistemas que primero fallan, de qué forma y cómo se recupera al volver a valores nominales.

Test de capacidad

Como indica su nombre, estas pruebas están centradas en apoyar la planificación de capacidades del sistema.

Partiendo de la base actual, se incrementa la carga del sistema para hallar el punto en donde inicia la degradación del rendimiento. Viendo las métricas se puede realizar una planificación de crecimiento del sistema para poder absorber más carga de trabajo (por ejemplo, incrementar el número o potencia de los procesadores, aumentar el ancho de banda, incrementar la memoria RAM, etc).

También son imprescindibles para poder definir un plan de escalado horizontal o vertical y, con entornos virtual izados, poder hacer pruebas piloto para validar las diferentes hipótesis de crecimiento.

Test de rendimiento

Son aquellas pruebas que validan los Criterios de Aceptación de rendimiento que describen la capacidad de respuesta, velocidad, escalabilidad y estabilidad de la aplicación.

Estas pruebas identifican las discrepancias entre las expectativas de rendimiento y las realmente obtenidas, permitiendo a negocio el tomar decisiones estratégicas sobre las plataformas y que se pueda planificar las acciones necesarias para optimizar las prestaciones de la solución.

Cuándo y cómo integrarlos

Muchos equipos de desarrollo tienen la impresión de que las pruebas de rendimiento se realizan cuando el código está estabilizado y durante los procesos de QA que desembocan en el despliegue. Incluso, en que su sitio natural es más cerca de producción que en construcción.

Pero eso es un error; las pruebas de rendimiento deben estar integradas desde el primer momento en el proceso de construcción de la construcción del software. Incluso antes.

Cuando se está realizando la toma de requisitos o incepción, antes de empezar a tirar una sola línea, durante la redacción de la Pila de Producto, se deben definir las historias, objetivos, y requisitos de rendimiento. Incluso se pueden diseñar los pilotos necesarios para validar las propias pruebas y las medidas que se quieren obtener.

Una vez arrancadas las iteraciones, en conjunto con el resto del equipo, se compromete las historias y requisitos que se van a desarrollar, se construyen las pruebas y los escenarios necesarios, y se realizan los test que puedan aportar valor a la propia construcción.

Durante el proceso de Despliegue se lanzan las pruebas de Aceptación, ten en cuenta que no todos los test están orientados a las validaciones de negocio como hemos visto con anterioridad, y se documentan los resultados . Por último, como momento crítico de toda iteración Agile, se incluye una retrospectiva de rendimiento dentro del proceso general de Mejora Continua.

Como puedes ver, es crítica la integración completa del equipo de test con el resto de los miembros del equipo. Ya que, solamente así, se podrá realizar un desarrollo que tenga el rendimiento como una de sus prioridades, evitando un precioso código de alta calidad que esté por debajo de la eficiencia exigida.

No hay balas de plata

Como bien sabe cualquiera que haya trabajado en desarrollo de software, no existen soluciones únicas que valgan para todas las ocasiones. Y los test de rendimiento también tienen sus ventajas e inconvenientes.

Ventajas

• Incremento de los ingresos al funcionar correctamente el sistema, procesando las transacciones dentro del plazo comprometido.
• Evitar que un problema de rendimiento implique el tener que desechar parte del sistema para ser reconstruido.
• Evitar que un problema de rendimiento implique retrasos en la puesta en producción de una pieza de negocio comprometida.
• Evitar innecesarios costes de adquisición de hardware adicional, a causa de problemas de escalabilidad o rendimiento.
• Evitar el incremento de costes de mantener un software en producción a causa de problemas de rendimiento creciente.
• Reducir el coste de operaciones para la gestión de problemas en el sistema originados por un rendimiento por debajo de las expectativas.
• Identificar cuellos de botella, en el hardware y software, que puedan tener impacto en el rendimiento o escalabilidad a un futuro.

Pero puntualizando a este frio listado, siempre me sorprende la cantidad de errores que suceden cuando sometemos a un código “sólido” - desde el punto de vista de codificación- a pruebas de estrés. Se lanzan los test y van surgiendo errores por muchas causas, pero que empiezan casi siempre por la saturación del pipeline de las comunicaciones vía hhttp request al servidor.

Entre los fallos que te vas a encontrar, puede haber problemas con las sesiones de sql o fugas de memoria (memory leeks) a causa de no utilizar un close o un dispose a tiempo. Porque hoy en día nos apoyamos demasiado en la “magia” del sempiterno recolector de basura.

Otro será un condicional ineficaz, un cuello de botella en un servicio que produce timeout en los casos de carga máxima; un sistema que no se recupera al ser llevado a límite, que no libera la memoria o el procesador y que tiene un límite temporal demasiado estrecho antes de llevar a la infraestructura a sus límites o a un funcionamiento degradado.

Por ello, para mí, la gran ventaja de aplicar pruebas de rendimiento lo antes posible es que se prueban servicios, módulos y plataformas completas. No solamente el hardware, sino también el software, la arquitectura, la escalabilidad y la visión global del desempeño de la aplicación.

Y me aseguro de que todo el esfuerzo y trabajo realizado sea utilizable por los usuarios.

Inconvenientes
El probar el sistema completo, llevándolo a sus límites, implica que requieren un trabajo extra en su planificación, construcción, ejecución y análisis de los resultados.

Además, por la taxonomía de la ejecución, se requiere una gran cantidad de tiempo y la presencia de los desarrolladores. Este tipo de test es muy complicado, o imposible, de integrar en un proceso de integración continua, más allá de los de validación.

De hecho, este tipo de pruebas son parte de la “pieza” de monitorización de las prácticas DevOps, orientadas a la salud de las aplicaciones. Y que se merecen, por si solas, un artículo.

Siendo el mayor inconveniente, la dificultad de transmitir al equipo de negocio y de gestión del proyecto el valor que aporta estas prácticas de aseguramiento de la calidad, y que aprueben el incremento del coste asociado durante la construcción y despliegue a cambio de todas las ventajas referenciadas anteriormente.

Más información

The Forrester Wave™: Application Performance Management, Q3 2016

Fundamentals of Engineering for Performance

Agile Performance Engineering

Performance Testing Guidance for Web Applications

Application performance engineering by HP

También te recomendamos

13 claves para mejorar el rendimiento de tu código Javascript

Yahoo libera el código de desarrollo de YSlow para que los desarrolladores interesados contribuyan

50-30-20, la regla que todo ahorrador debería conocer

-
La noticia Ingeniería del rendimiento ¿Cómo anticiparse a que los problemas de escalanibilidad ocurran en producion? fue publicada originalmente en Genbeta Dev por Juan Quijano .

Parece una broma de mal gusto, pero conozco a más de un desarrollador que ejerce su labor en auténticos “zulos”, opacos, soportando una conectividad pésima o demasiado restringida.

Sin duda esto es un hándicap, un dolor de cabeza y un incordio, del cual cada uno de ellos se queja amargamente.

Pero… ¿y si no tuviéramos ningún tipo de conexión a Internet, viéndonos abocados a descubrir en nuestras propias carnes lo dependiente que somos de la comunicación constante con el ciberespacio, y lo que significa un apagón completo que nos encierre en un sitio similar a como se trabajaba a principios de la novena década del siglo XX?

Empecemos por lo más básico

No es difícil poder acercarse a una gran superficie y adquirir una caja física con un Windows 10. Pones poco más de un centenar de euros encima del mostrador y te llevas el sistema operativo bajo del brazo.

En el caso de un Apple la cosa se complica ya que no hay tantos sitios donde poder hacerte con un Mac OSX.

En ambos casos, la forma más sencilla es pedirle a alguien con conexión que te haga un disco de arranque partiendo de una ISO que pueda descargar, y adquirir un serial que te permita hacerlo funcionar.

Y aún así continúan los problemas.

Windows requiere una activación del sistema operativo para evitar que te salgan mensajes de advertencia y te dejen de funcionar partes.

Para solventarlo puedes acceder a un engorroso y laborioso sistema vía teléfono, el cual te pone con una máquina, la cual te va indicando los diferentes pasos que necesitas completar hasta que -introduciendo el serial adquirido- te genera un código de activación que has de introducir de nuevo en el sistema para activar la copia de Windows.

Apple,como tiene el control del hardware, está pensado para ser instalado desde una ISO, al igual que Linux. Son distribuciones optimizadas para ser descargadas sus imágenes, quemadas en un DVD o configuradas en un USB de arranque.

Sin embargo, todas tienen, al menos, cuatro serios inconvenientes si no estás conectado a Internet:

• Muchas de las capacidades y software incluidos en el Sistema Operativo requieren de comunicación con los servidores del fabricante/distribuidor.
• El ID de usuario, su identificación, ha ido ganando complejidad y criticidad con el tiempo, ya que arrastra consigo la configuración del usuario, las especificaciones del perfil o el acceso a múltiples servicios, entre otras funciones.
• Las actualizaciones que todos tienen que aplicar a una instalación limpia son muy engorrosas de localizar para ser descargadas y poder ser instaladas offline. Y en algunos casos (como un Windows 8 pelado para actualizarlo hasta 8.1 completo) es prácticamente imposible.
• Los frameworks (como .NET) mayoritariamente se obtienen por medio del acceso a un repositorio remoto situado en la Red.

Herramientas

Ciertamente el escenario que he descrito durante el capítulo anterior es cada vez más improbable. La mayoría de los equipos de desarrollo que se mueven a un cliente son portátiles preinstalados por los departamentos de IT que incluyen el sistema operativo actualizado y listo para hacer funcionar todas las herramientas necesarias.

Y aquí volvemos a encontrarnos con los inconvenientes de no estar conectado.

Pongamos que me quiero poner a trabajar en un proyecto web moderno – en mi ejemplo utilizo el “full stack” de Microsoft + tecnología JS relacionada + Cloud.

Pues al no tener acceso a internet tengo el problema de que ni tan siquiera puedo buscar las páginas de venta y descarga de la suite de Visual Studio 2015, que es mi piedra angular para programar.

Es más, tampoco podría hacerlo en el caso de que use un “full stack” de, por ejemplo, Angular 1.x + Node.js y toda la miríada de software añadido que se debe descargar, instalar y configurar para que todo funcione al igual que una orquesta bien afinada y compenetrada. La única opción sería, una vez más, bajármelo todo a una unidad USB (que cada vez será más grande) para poder instalarlo desde el dispositivo físico.

Pero no, tampoco. Aquí nos encontramos con que todas las herramientas de desarrollo están compuestas por una miríada de módulos, parches, actualizaciones y dependencias.

Un infierno en ciernes que obliga a saber exactamente qué versión de una librería funciona con otra y que ha llevado a desarrollar mecanismos de configuración que buscan en los repositorios adecuados, descargan e instalan las versiones adecuadas.

Y ni así.

Por ejemplo, Visual Studio tiene como requerimiento, al igual que tener memoria RAM suficiente o un mínimo de procesador, una conexión a Internet; y no deberíamos esperar que funcionen manejadores de paquetes como NPM, o Nuget sin tener acceso a la red.

También hay que sumar el incremento constante de la presencia de la Nube, como sucede si vamos a trabajar sobre aplicaciones Adobe del tipo Photoshop, ya que ahora necesitan conexión permanente tanto para su instalación como para su funcionamiento.

Y la tendencia actual es encontrar aplicaciones que viven y se utilizan solamente en Cloud, cada vez con más abundancia.

For the Internet only

La gran revolución en nuestra industria de esta última década, es la llegada masiva de las metodologías ágiles a los equipos de trabajo y empresas; y de las herramientas asociadas.

Los stack de Atlassian (Jira y sus cientos de módulos) o el de Visual Studio Team Services, son complejos conjuntos de aplicaciones que soportan todo el ciclo de vida de la construcción de aplicaciones informáticas y que, ahora, amplían su ámbito de actuación abrazando el lado de la infraestructura y la monitorización que definen a los sistemas DevOps.

Para un programador el repositorio de código es el Santo Grial que debe tener una disposición completa en cualquier momento y lugar. Por ello existen y tienen tanto éxito plataformas como GitHub, VSTS, CodeFlex o BitBucket.

Y bajando un peldaño, también son críticos los “simples” almacenes de información tales como OneDrive, ClouDrive, Drive+ o DropBox.

No solamente las compañías necesitan tener un sitio de colaboración para que los equipos puedan acceder al código o a la documentación de forma segura y deslocalizada, sino que -personalmente- tengo almacenado en mis repositorios privados gigas de libros, información y ejemplos que ganan en importancia cuanto más desesperado estoy con un problema.

Porque, para el ser humano medio, es imposible almacenar en la memoria toda la información que es necesaria y oportuna durante el desarrollo de una aplicación. Sitios como StackOverflow son, simplemente, imprescindibles, al igual que las búsquedas en Google y sus millones de resultados.

Y todo, todo ello se queda inaccesible si Internet está bloqueado o tu conexión es demasiada restringida.

Hablando, que es gerundio

La madurez de internet, el crecimiento del ancho de banda y la irrupción de la informática móvil (plenamente ubicua), ha cambiado la forma de entender las aplicaciones ofimáticas con la llegada de sistemas exclusivamente basados en Internet, como son Office 365 o Google Apps.

Hace unos pocos lustros, la comunicación se establecía principalmente por voz o por email. En la actualidad, poco descubro si digo que la mayoría utilizamos un navegador web para acceder a nuestras redes de comunicación, cada vez más complejas, más ricas y más apabullantes tanto en cantidad, calidad y amplitud.

Después de un Pomodoro, hay pocas distracciones tan útiles como echar un vistazo al Twitter, responder los emails que empiezan a correr prisa, o hablar con alguien por Skype.

Y no solamente por la necesidad como humano de relajar la concentración, cambiar de contexto y descansar del esfuerzo que constituye picar código, sino porque produce un aumento de mi productividad más que importante: necesario.

Cuando estoy en un proyecto de desarrollo, necesito poner por escrito los problemas que me voy encontrando, y cómo solucionarlos. Para compartirlo y que sirva de ayuda a otros compañeros que estén “googleando” en pos de una respuesta, pero también para recordármelo más adelante cuando me vuelva a suceder o aborde retos similares.

Conclusión

Se puede desarrollar aplicaciones informáticas sin conexión a Internet, pero es MUY incómodo y requiere una planificación previa exhaustiva. Es decir, a menos que haya de por medio un verdadero problema de seguridad, o de riesgos vitales, es muy negativo dejar a un equipo sin conectividad.

La programación es, como repito siempre, una actividad extremadamente compleja que obliga al trabajo en equipo y utiliza de forma constante la búsqueda y extracción de información desde Internet.

No tener acceso a ello es como poner a un cirujano a operar con un guante sin dedos (una manopla). Una medida de alto riesgo que no solo es inútil, si no equivocada.

También te recomendamos

Los 17 momentos por los que merece la pena ser desarrollador

Trucos de limpieza que te salvarán la vida en una casa con niños

Los 17 momentos por los que odias ser desarrollador

-
La noticia¿Se puede desarrollar sin conexión a Internet? fue publicada originalmente en Genbeta Dev por Juan Quijano .

En el momento que leemos: "Empresa líder en su sector busca desarrollador/a para proyecto internacional con salario competitivo”, 9 de cada 10 desarrolladores han perdido el interés en ese puesto de trabajo. Es curioso como en una simple frase, se puede entender mucho sin decir nada. Está demostrado con este tipo de ofertas de empleo, la desconfianza es generalizada.

Cuando hablamos de dinero, la mayoría de nosotros reconocemos que hemos sido educados con la enseñanza de que es un tema tabú. Hablar abiertamente del dinero, no está bien, de hecho se percibe como una falta de respeto.

En el ámbito laboral, no hay tema que genere más discusión que el salario. Como norma general, el trabajador considera que cobra poco y el empresario que paga mucho. Lo miremos por donde lo miremos, el dinero nos importa a todos (a unos más que a otros) porque sabemos lo que cuesta ganarlo.

En mi día a día, hablar de dinero es habitual. Los desarrolladores me comentan el salario que quieren ganar, las empresas sí están dispuestas a pagarlo. Es un tema que tengo completamente naturalizado y por eso me gustaría compartirlo.

Comenzamos con los misterios que se esconden detrás del tan usado (y gastado): “salario competitivo”, “salario a convenir” y/o “salario según valía”. Siendo más claros, ¿cuáles son los principales motivos por los que no conocéis el salario en las ofertas de empleo?

1. La empresa quiere tener libertad de decisión y poder negociarlo en cada caso

Sin duda, es la principal razón que argumentan las empresas y aunque es comprensible, no suele funcionar a la hora de contratar el talento que necesitan.

Si no se es lo suficientemente claro desde el principio, es bastante probable que la mayoría de los profesionales no les interese la oferta.

La ambigüedad genera interpretaciones (malas en muchos casos) que no tienen porqué corresponder con la realidad: “El salario es bajo”, “Se me da mal y no me gusta negociar el salario”, “Cuando veo que no son transparentes con el salario, no me interesa”, “Según valía, es lo de siempre y me encontraré lo de siempre”, y un largo etc.

2. Para que no se enteren el resto de desarrolladores de la empresa y evitar conflictos internos

Es el número 2 en el ranking de por qué no se es transparente con el salario y el mayor de los conflictos a nivel interno.

Aunque os parezca increíble, la empresa puede estar dispuesta a pagar más de lo que esperáis, el problema es que no quieren que se enteren los demás.

Si todavía hay alguna empresa que piensa que los trabajadores no hablan entre ellos sobre lo que cobran, ya pueden ir cambiando esa mentalidad, porque siempre hay un buen y mal momento para hablar del salario.

Sabemos que hay empresas que con la finalidad de ser lo más transparentes posible, exponen públicamente los salarios de sus trabajadores, tal vez es una solución demasiado extrema, pero también lo es ocultar el salario para que no se entere el resto. Además, el ser humanos es curioso por naturaleza y se encargará de encontrar las respuestas que necesita.

Como todo en esta vida, en el término medio está la virtud y lo mejor es establecer el salario justo.

3. La empresa no quiere que el salario sea lo más importante para el desarrollador

En el puesto número 3 del ranking de la falta de transparencia y uno de los peores planteamientos vitales.

Ya hemos insistido que partimos de la base de que todos trabajamos por dinero y quien diga lo contrario, miente. Seamos honestos (todos) y establezcamos bien las bases, dejando claro que el dinero nos importa a todos y por tanto, llegar a un punto de coincidencia será más sencillo.

En los mejores procesos de selección, el dinero suele ser el tema que menos preocupa por ambas partes. Se habla al principio y si se está alineado, pasa a un segundo plano. Las conversaciones se centran en conocerse mejor y si ambas partes van en la misma dirección, se formalizará el salario.

Cuando todo va bien, los procesos de selección son puro flow…

4. La empresa va a ofrecer un salario bajo y cree que no conseguirá atraer el talento que necesita

Tiene bastante relación con el anterior. Sabiendo que el dinero es importante, ahora veremos hasta qué punto.

Una de las mayores preocupaciones de algunas empresas, es que no pueden permitirse pagar salarios acorde al mercado y por tanto, no quieren hacer público el salario porque temen que nadie quiera incorporarse. Es cierto que ofrecer un salario bajo, genera mucho conflicto, no siempre justificado, pero es lo que hay y a quien no le interese la oferta, que no se postule a ella.

Si se llega a un mínimo salarial, el desarrollador establecerá sus prioridades y valorará la oferta en conjunto, siendo el salario un factor más a considerar. Ahora, es cuando el dinero no es lo más importante, pero debe serlo todo lo demás.

Cuando una empresa no puede pagar un salario elevado, pero ofrece reto técnico, flexibilidad laboral y otro tipo de condiciones profesionales motivantes hay que dar más valor a todo eso, pero ser cristalino con la remuneración salarial.

5. La empresa no quiere que se entere la competencia del salario que ofrece y pueda hacer una oferta mejor

El miedo a que otras empresas, pueden hacer una oferta mejor y por tanto perder buenos profesionales, es una preocupación y uno de los mayores desafíos de este mundo competitivo. Esto hay que** asumirlo como un riesgo e intentar fidelizar a los profesionales**. Si se marchan por dinero, es bastante probable que sea porque se sienten mal pagados o el resto de condiciones profesionales que le ofrecen “en la competencia”, son mejores.

Por tanto, si una empresa tiene miedo a que la competencia se entere del salario que ofrece a sus profesionales, es suficiente indicador para darnos cuenta que algo no funciona y hay que solucionarlo.

Conclusión

Si nunca habéis pensado que se esconde detrás de “salario según valía” (y derivados), ahora, cuando veáis una oferta de empleo, recordad que no siempre la empresa quiere pagar lo mínimo (o tal vez si) … pero no deis por supuesto que es la única opción. Todo tiene una explicación, justa o no, pero la hay, y de vosotros depende si queréis conocerla o no.

Por cierto, si queréis saber vuestro salario con respecto al mercado actual, podéis preguntar a headhunters o buscar las publicaciones de los salarios en las presentaciones anuales de las empresas de selección.

También te recomendamos

Resultado de la encuesta de javaHispano: ¿Cuánto es el salario de un profesional Java?

¿Qué han enseñado las hormigas a la arquitectura?

Los Reyes del Mambo: los programadores mejor pagados

-
La noticia Lo que se esconde detrás de "salario competitivo, a convenir y según valía" fue publicada originalmente en Genbeta Dev por Emma Salamanca .

Hace unas semanas os presentamos algunas de las grandes disyuntivas del mundo del desarrollo y os pedíamos ayuda para resolverlas. Tuvimos la encuesta abierta durante dos semanas y 2.228 de vosotros nos ayudasteis contestando alguna de las preguntas. He aquí los resultados (menos dolorosos que el Brexit, lo de Trump y demás), ¡el pueblo ha hablado!

Tabular con espacios o con tabulador

Donde esté ese elegante tabulador (77%) que se quiten los cortos espacios (23%), ¿verdad?.

Escribir código en editor de código o en IDE

La potencia de un buen IDE (73%) se impone con facilidad a los editores de código (27%). No es país para developers hardcore. Sí, Vim, Emacs, incluso Sublime tienen ese aura romántica pero a la hora de la verdad la potencia y las infinitas opciones de un IDE nos hacen ahorrar mucho tiempo y eso, en el mundo laboral real, es lo más importante.

Trabajar en una startup o en una consultora

No os va el rollo de traje, fichar y demás, eso está claro: paliza de la startup (69%) a la gran consultora (31%). No es inesperado, desde luego. Idealista y naif, quizás, inesperado, no.

Bola Extra: Por qué prefiero trabajar en una factoría de software en vez de en una startup

Trabajo presencial o en remoto

La perspectiva de trabajar desde casa, sin tener que salir a este mundo loco, a los atascos, al cafe aguado de máquina, no resulta tan tentadora como podría parecer y el trabajo en remoto pierde por bastante (58% - 42%) contra el trabajo presencial. ¡No hay quien os entienda! (A quién quiero engañar, yo voté por trabajo presencial también).

Bola extra: 10 cosas sobre trabajar en remoto que quizás no habías pensado y que debería tener en cuenta

Comentar el código o no comentarlo

No, mucho de código auto explicativo no somos, nos va más lo de comentar, anotar y acotar, cuales Alan Moore de la vida. 69 a 31, paliza. Porque el código debería ser bello como un poema de Whitman pero si comentas y explicas ese bucle infernal que tuviste que sacarte de la manga a última hora pues mucho mejor para tu yo del futuro. Las cosas como son.

Bola Extra: Diez consejos para mejorar tus comentarios de código fuente

Webservices SOAP o APIs REST

La paliza más clara (84% - 16%) es la que API REST le mete a SOAP. Pobre SOAP, no le quiere nadie (sus motivos hay, ¡eh!). Las APis RESTful se imponen con gran autoridad... ya sólo nos queda hacerlas bien de verdad, que hay demasiadas APIs que se dicen REST pero que realmente no lo son.

Bola extra: Unas cuantas buenas prácticas cuando hablamos de APIs REST

Java o PHP (u otro)

La pregunta más igualada, quizás por la forma en la que estaba planteada, pero se ve que Java sigue fuerte como una roca y puede con todo o por lo menos con PHP. ¿Quién podría acabar con su reinado? ¿Python? ¿Node? ¿Lenguajes declarativos? ¿Lenguajes Microsoft? ¿Taylor Swift?

Formación reglada o autodidacta

Otra sorpresa (por lo menos para quien esto escribe): frente a los que prefieren la formación reglada (44%), los que prefieren ser autodidactas, los que viven la universidad de la calle, son mayoría (56%) y sin demasiada discusión. Los años de universidad o de FP casi que se ven como un lastre que no tiene por qué ser obligatorio. No deja de resultar curioso porque tanto en España como en América Latina los títulos siempre han sido algo muy respetado y que ha vestido mucho. Como decía el reciente ganador del Nobel de Literatura Bob Dylan: times are changin.

Bola extra: ¿Es imprescindible pasar por la universidad para trabajar como programador?

Y a vosotros, ¿qué os parecen estos resultados?¿Sorprendentes? ¿Lógicos? ¿Absurdos? Los comentarios quedan abiertos.

Imagen de portada | Fotograma de 'Napoleon Dynamite'

También te recomendamos

El sueño de trabajar en Silicon Valley, empezar de prácticas en una startup

Windows 10 en tu equipo convertible: todo lo que puede hacer por ti

Las 200 mejores universidades del mundo en Informática en 2014... ¡y hay españolas!

-
La noticia Resolvamos las grandes disyuntivas del mundo del desarrollo. Los resultados de lo que nuestros lectores dicen fue publicada originalmente en Genbeta Dev por Fernando Siles .

Hace tiempo que Kotlin se está convirtiendo en una alternativa real para muchos desarrolladores, principalmente en el mundo del desarrollo Android, donde aún seguimos anclados a versiones muy antiguas de Java.

Ya hablamos en su momento sobre cuáles eran las bondades de este lenguaje.

La gente de Gradle se ha dado cuenta de ello, y desde hace unos meses están trabajando con Jetbrains para crear Kotlin Script e integrarlo en Gradle 3.

Kotlin Script no es más que una forma de poder escribir scripts utilizando Kotlin, y es el mecanismo que utiliza Gradle para permitirnos definir sus build.gradle utilizando este lenguaje.

¿Cuáles son las ventajas de escribir los scripts de Gradle en Kotlin?

Dejando a un lado que uno pueda ser más o menos fan de uno u otro lenguaje, estas son las 3 principales ventajas que le encuentro al uso de Kotlin.

1. Es un lenguaje estático

Es decir, sabemos en tiempo de compilación qué tipos van a tener las variables, qué valores de retorno vamos a recibir de las funciones, etc. Y esto ayuda muchísimo al IDE a facilitarnos la tarea según estamos escribiendo.

Primero, porque nos permite un autocompletado muy potente. Y segundo, porque es capaz de preprocesar el código y detectar errores antes de ejecutar el script.

2. Integración total con el IDE

Lo que nos aporta múltiples ventajas, desde lo que comentaba en el punto anterior, hasta el uso de herramientas de refactorización, pasando por que podremos navegar al código fuente desde cualquier código escribamos.

3. Toda la aplicación en un mismo lenguaje

Aunque quizá sea una de las razones menos importantes, en la práctica puede ser muy útil. Podríamos tener todo nuestro proyecto Android escrito en Kotlin, tanto la aplicación como los scripts de construcción.

En proyectos muy sencillos que no requieran scripts muy complejos, casi no se va a notar la diferencia, porque el IDE lo genera por nosotros.

Pero en proyectos más grandes, Groovy se puede convertir en una barrera de entrada. Si el equipo ya está desarrollando la App en Kotlin, le será inmediato empezar a trabajar con Kotlin Script.

Ejemplo: App en Android usando Kotlin Script

Ya os comentaba que esto es una función experimental, así que está un poco lejos aún de ser algo sencillo de usar.

Por eso te voy a explicar los pasos que necesitas para crear un proyecto Android usando Kotlin Script para los build.gradle. Aquí la complejidad es doble porque tendremos dos build.gradle. El raíz y el del módulo.

Pero te cuento los pasos que necesitas.

1. Instala el plugin de Kotlin y activa las EAP de Kotlin 1.1

Kotlin Script sólo está disponible de momento en las EAP de la versión 1.1 de Kotlin, así que necesitas configurar el plugin para que descargue esa versión una vez que te lo instales:

Esta opción la tienes en Tools -> Kotlin -> Configure Kotlin updates

2. Crea un proyecto Android con Kotlin

Necesitas crear un proyecto nuevo en Android Studio y configurarlo para que use Kotlin. Puedes seguir los pasos exactos en esta guía.

3. Utiliza una distribución de Gradle que soporte Kotlin Script

La última hasta la fecha es una preview de 3.3 de Gradle. En gradle/wrapper/gradle-wrapper.properties modifica esta línea:

distributionUrl=https\://repo.gradle.org/gradle/dist-snapshots/gradle-script-kotlin-3.3-20161123161139+0000-all.zip

4. Configura el settings.gradle para que use los scripts correctos

Ahora, en lugar de utilizar de utilizar los archivos build.gradle, tendrá que usar los build.gradle.kts, así que necesitas modificar el settings.gradle a lo siguiente:

def configureGradleScriptKotlinOn(ProjectDescriptor project) {
    project.buildFileName = 'build.gradle.kts'
    project.children.each { configureGradleScriptKotlinOn(it) }
}

include 'app'

configureGradleScriptKotlinOn rootProject

5. Crea el build.gradle.kts raíz y configúralo

Verás que la apariencia es muy similar a la de un script escrito en Groovy:

buildscript {
    repositories {
        jcenter()
        gradleScriptKotlin()
    }

    dependencies {
        classpath("com.android.tools.build:gradle:2.2.0")
        classpath(kotlinModule("gradle-plugin"))
    }
}

allprojects {
    repositories {
        jcenter()
        gradleScriptKotlin()
    }
}

Una ventaja interesante es que no necesitamos especificar la versión de Kotlin. Es capaz de inferirla de la versión del plugin instalado.

6. Crea el build.gradle.kts para el módulo app

Este es un poco más complicado, y es donde creo que aún les falta por simplificarnos un poco la tarea.

Primero, porque hay que crearse unas cuantas funciones de extensión para que siga siendo tan legible como sería en Kotlin. Esas funciones deberían estar incluidas en algún momento dentro del propio plugin.

Y segundo, porque nos obliga a prácticamente reescribir el mismo buildscript que el del fichero raíz, cosa que no es necesaria con Groovy.

Eliminando un poco la parte boilerplate (puedes ver el archivo completo aquí), nos quedaría algo así:

apply {
    plugin()
    plugin()
}

android {
    buildToolsVersion("25.0.0")
    compileSdkVersion(25)

    defaultConfigExtension {
        setMinSdkVersion(15)
        setTargetSdkVersion(25)

        applicationId = "com.example.kotlingradle"
        versionCode = 1
        versionName = "1.0"
    }

    buildTypesExtension {
        release {
            isMinifyEnabled = false
            proguardFiles("proguard-rules.pro")
        }
    }
}

7. Ejecuta el proyecto

No sé si es posible, pero hasta la fecha no he sido capaz de ejecutar el proyecto usando Android Studio. Necesitarás ejecutarlo mediante terminal:

./gradlew installDebug

Ahora empieza la magia

Usando Kotlin Script ahora verás, por ejemplo, que el autocompletado funciona perfectamente:

O que, cuando escribimos algo de forma incorrecta, el IDE nos informa:

Estos pequeños detalles nos ahorrarán mucho tiempo cuando estemos implementando los scripts de Gradle.

Puedes ver el proyecto completo y descargarlo en el repositorio de ejemplo.

¿Qué te ha parecido Kotlin Script?¿Crees que marcará un antes y un después en la creación de scripts de Gradle, o que se seguirá usando Groovy como hasta ahora? Cuéntanos en los comentarios.

• En Genbeta Dev | Kotlin: La Máquina Virtual de Java tiene un nuevo aliado
• Más información sobre Gradle y Kotlin

También te recomendamos

Kotlin: La Máquina Virtual de Java tiene un nuevo aliado

Kotlin desde el punto de vista de un desarrollador Groovy

La Barcelona de 1850 que pensaba en los ciudadanos del futuro

-
La noticia Kotlin llega a Gradle: Escribe tus scripts de Gradle usando Kotlin script fue publicada originalmente en Genbeta Dev por Antonio Leiva .

Los desarrolladores somos los nuevos hechiceros de la sociedad. Condenados a estudiar de manera constante y diaria, a causa de nuestra inagotable ansia de conocimiento. Y orgullosos de construir sistemas que se implantan y utilizan en todo tipo de escenarios; a lo ancho, largo, alto y profundo de nuestro mundo (y más allá).

Es decir, los desarrolladores hacemos que muchas cosas funcionen gracias a nuestra capacidad intelectual; recibiendo a cambio, una invaluable dosis de satisfacción cuando nuestras criaturas – paridas con dolor y sufrimiento – llegan a producción y se utilizan.

Por eso llama poderosamente la atención la cantidad de tiempo que se puede perder – y se pierde – en estériles discusiones entre profesionales, que llevan a los extremos la defensa de sus ideas.

Ego y prepotencia

Prácticamente todos podemos reconocer que alguna vez el ego y la prepotencia nos ha cegado y hemos caído en una defensa numantina basada en que nuestro conocimiento es superior y no hay resquicio para que nadie pueda saber de algo que no conozcamos aún mejor.

Alguno de los síntomas que indican que estamos metidos en esta dinámica es el tomarnos a mal cualquier opinión contraria, por leve que sea, a la que tenemos plena certeza; el uso común de las palabras siempre y nunca “yo nunca he hecho eso” como argumento suficiente para dar por zanjado un debate; contestar siempre con una coletilla de valoración personal del contrario “solo los ignorantes pueden pensar así”; que nos escueza en la boca del estómago el que alguien “te pille” en un renuncio, error u omisión; u olvidar rápidamente el motivo del debate para convertirlo en una batalla personal.

La noticia buena es que esto se cura con autocrítica e intentando corregirnos cuando nos reconocemos alguna de las señales de que el ego nos está llevando a la prepotencia.

Menosprecio por desconocimiento

Algunas veces aseguramos cosas con rotundidad, basándonos en la confianza de lo que sabemos. Es más, algunas veces es obligatorio hacerlo así para trasmitir “expertise”.

Pero siempre hay mucho más de lo que conocemos, y es fácil caer en el menosprecio de otras opiniones a causa de nuestro propio desconocimiento.

De forma desesperante, cuanto menos sabemos y más nos creemos que sí, más despreciamos las opiniones de los demás y entramos en comportamientos que harían hacer perder la paciencia al Santo Job.

Un ejemplo sería el encontrarse a clientes o compañeros que no tienen idea de programar y que “se atreven” a opinar sobre temas técnicos. Lo que produce, en la mayoría de los casos, un rechazo especialmente virulento, en donde no hay resquicio para intentar descubrir cuál es el mensaje que intentan hacernos llegar.

O, siendo un referente de alguna comunidad técnica, algún “mindundi” se mete en el fregado de ir en contra de nuestra opinión, encontrándose el inconsciente con descalificaciones personales no solamente por el “Guru”, sino además por el jaleo continuado de los palmeros de turno.

En ambos ejemplos, nos olvidamos que todos somos ignorantes en casi todas las cosas relacionadas con nuestra profesión, y que la inmensa mayoría repetimos lo que otros han diseñado, descubierto o construido.

Es decir, aquí no hay gurús y, como mucho, tuertos en tierra de ciegos.

Este tipo de actitudes son muy complejas de corregir porque no somos conscientes de todo lo que nos falta por conocer, porque no tenemos paciencia para darnos cuenta de lo que podemos aprender y, porque al creernos realmente que sabemos más que nadie, nos enganchamos a esa sensación dulce de superioridad y reconocimiento. Siendo, como toda buena droga, muy duro darte cuenta de que “eres mortal”.

Talibanismo y Fanboismo

Ambos términos tratan sobre la defensa radical, emocional e irracional de una idea o conocimiento (tecnológico en este caso). Siendo el fanboismo lo mismo pero relacionado a una marca comercial.

La característica principal que señala que hemos caído en esta estéril posición, es el uso profuso y continuado de tres tácticas de discusión:

• “No hay mejor defensa que un buen ataque”. Nada más empezado el combate, ya que así lo vemos cuando estamos en estas posturas irracionales, se entra a atacar de forma inmisericorde la calidad profesional, técnica, personal y todo lo que sea necesario, de nuestro enemigo. Casi todo vale y, en caso extremo, entramos en una dinámica “Hater”.

• “Y tú más”. Da igual que estemos discutiendo sobre un agujero de seguridad del tamaño de una catedral, o prácticas monopolísticas deplorables: el enemigo es mucho peor y es culpable. Lo que hace, milagrosamente, que la crítica a nuestro objeto de defensa se diluya y desaparezca.

• “Al enemigo ni agua”. No se quiere ni vencer, ni convencer. Se quiere destruir al enemigo. Por lo cual el dicho de “se ve más la paja en el ojo ajeno que la viga en el propio”, se lleva a proporcionas monstruosas. Y las acusaciones de traidor, vendido y – a su vez- de talibán y fanboy, se suceden de forma reiterativa y cada vez más ofensivas.

Por alguna razón, casi siempre la discusión está a punto de finalizar cuando se llega a los términos tan manidos de “derechos” y/o “fascismo”.

Este tipo de actitud, en la informática, comúnmente las corrige el tiempo y la dura realidad de que no hay “pepitas de oro” que siempre estén indemnes e impolutas. Y más, porque casi siempre las marcas o tecnologías, siguen su camino sin importarle lo más mínimo las opiniones de los defensores de la pureza extrema.

La ley de la jungla en las redes sociales

Si añadimos gasolina a un fuego, lo más seguro es que acabemos más que chamuscados y con un incendio de proporciones preocupantes.

Algo parecido sucede cuando ejercemos o sufrimos cualquiera de las actitudes anteriores en una red social. Sea Facebook, listas de correos, foros, chat o el rey de los “flame”: twitter.

Lo que empieza como una diferencia de opiniones, escala rápidamente a un maremágnum de insultos cada vez más gruesos, a donde se van uniendo de forma entusiasmada hordas de contrincantes, palmeros, trolls y haters.

En menos de lo que canta un gallo, decenas o cientos de mensajes, llenos de muy mala baba, cruzan el ciberespacio, olvidado el fondo del asunto y – sobre todo – las formas.

Y es que la comunicación en la red está basada en el espejismo del lenguaje políticamente correcto. Lo que es difícil de cojones (un ejemplo de lo que no es), y resultando extremadamente fácil herir cualquier susceptibilidad de los receptores del mensaje.

Resulta complicado escribir una opinión en una red social sin que alguien se sienta ofendido, molesto o enfadado por alguna parte o la totalidad de lo afirmado. Porque, ante la duda y aún con la ayuda de los smiles, siempre entenderemos lo negativo, nunca lo positivo.

Al igual, es un deporte con altas recompensas para nuestro ego, el encontrar de forma inevitable aquellas opiniones a las que hacerle aclaraciones, puntualizaciones e ironías. Con más o menos elegancia, a muchos nos encanta enmendar la plana o demostrar que somos los que más sabemos.

Incluso, si no es ese el espíritu de la respuesta y realmente queremos aportar nuestro punto de vista o experiencia que pueda enriquecer un debate que nos gusta, hay una gran posibilidad de que sea entendido como una actitud prepotente, directamente proporcional a la egolatría de los lectores del hilo.

Por supuesto estoy dejando fuera de toda duda el que no pertenecemos a ninguno de los dos grupos realmente dañinos en las redes sociales:

• Los Haters, u odiadores. Que lean lo que lean, lo retuercen para atacar con todo su odio a su contrincante/enemigo.
• Los troll. Personas profundamente desequilibradas que disfrutan y se nutren de poner de los nervios a todas las personas participantes en una conversación. Consumiendo y nutriéndose con avidez de los insultos recibidos, y regodeándose en el desprecio que producen.

Conclusiones

Si eres lector habitual de GenbetaDev, te habrás percatado que no estoy escribiendo en primera persona, como es habitual, sino en la segunda persona del plural. Porque, he de reconocer que, como participante asiduo en redes sociales, en algún momento he vivido y he actuado de todas y cada una de las actitudes descritas.

Y mi amarga conclusión es: no vale la pena.

Hay que tener la mente clara y fría antes de entrar en un debate que se pueda convertir en una discusión. No es normal que se traspase lo límites del ciber espacio, pero cuando ocurre se pierden amistades y relaciones en el mundo real. Y eso es un precio muy alto a pagar por una discusión que, casi siempre es efímera y banal.

O sea, en mi caso, que es el único en donde me atrevo a dar consejos, una autocrítica constante y tratar de contar hasta diez antes de lanzar una contundente y descarnada respuesta o crítica, es el único camino que veo para dejar de estar metidos en “Saraos” que me drenan tiempo de una forma absurda.

¿Tú qué piensas?

También te recomendamos

Resolvamos las grandes disyuntivas del mundo del desarrollo

Desarrollo del pie: cómo ayudar al bebé a empezar a caminar

10 cosas sobre trabajar en remoto que quizá no habías pensado y deberías tener en cuenta

-
La noticia Comunicaciones agresivas en la Red, una pérdida de tiempo fue publicada originalmente en Genbeta Dev por Juan Quijano .

Poder realizar queries como si de una base de datos MongoDB se tratase pero hasta 100 veces más rápidas y con las ventajas de una base relacional. Esto es lo que propone el reciente lanzamiento de ToroDB Stampede. Simplificando el stack de ToroDB nos encontramos con una base de datos NewSQL, es decir, una base de datos que intenta proporcionar las funcionalidades y características de las bases de datos NoSQL, principalmente escalabilidad, sin renunciar al ACID de toda la vida de una base de datos relacional.

Viendo el ecosistema actual de base de datos, siempre nos ha llamado la atención la centena o miles de ellas que existen y sus diferentes protocolos. Lanzar una nueva base de datos es siempre complejo. Aquí está la primera aclaración sobre ToroDB, en lugar de implementar un nuevo protocolo y un sistema de queries propio, incompatible con el resto de sistema, la gente de ToroDB ha decidido implementar el mismo protocolo de MongoDB.

Dicho esto, cualquier desarrollador que esté usando MongoDB en sus sistema puede empezar a usar ToroDB sin mayor problema. Quizás sea buen momento de probarlo mediante ToroDB.

Y en las capas inferiores donde persistir los datos, una vez más, en vez de implementar un sistema propio se ha utilizado PostgreSQL. Tal como nos explican desde ToroDB, tener una arquitectura desacoplada permite que en el futuro se puedan implementar otros protocolos, distintos de MongoDB o de persistir en Oracle, DB2, etc..

¿Cómo funciona ToroDB?

ToroDB funciona como un nodo secundario oculto del clúster de MongoDB que replica todos los datos y sus actualización a una base de datos Postgres en tiempo real. Creando de este modo una estructura relacional para poder consultarlos a partir de una colección de documentos MongoDB.

Los cuatro pilares sobre los que se basa ToroDB son:

• Transacciones ACID en un entorno de trabajo MongoDB, es decir NoSQL, con todo lo que ello conlleva.
• Ecosistema SQL accesible que no teníamos si sólo usamos NoSQL. Al persistir en una base de datos relacional, se pueden utilizar herramientas de BI, Backup o administración que hoy por hoy no están en NoSQL.
• Velocidad de consulta. Gracias a la persistencia sobre Postgres podemos resolver queries complejas que hasta ahora MongoDB requería más tiempo.
• Facilidad de migración de NoSQL a SQL. Hasta ahora no era sencillo migrar de un sistema a otro. Con ToroDB se puede utilizar los conocimiento y los recursos de ambos sistemas.

ToroDB Stampede y ToroDB Core son productos open source y su código está disponible para descarga en nuestro repositorio de GitHub. Cuenta con una licencia AGPLv3, una de las licencias de software libre llamadas "virales" porque obligan a que todo el software integrado cuente también con una licencia AGPL.

Entrevista a Álvaro Hernandez Tortosa, CEO de ToroDB:

Tenemos la oportunidad de charlar con Álvaro Hernandez Tortosa para que nos cuenta más en detalle algunos aspectos de ToroDB. A continuación las preguntas de la entrevista que le realizamos antes de lanzamiento. Cualquier duda adicional seguro que podemos gestionarlo en los comentarios de este mismo post.

GENBETA DEV: El estado del arte de las bases de datos es inmenso ¿Por qué empezasteis por MongoDB, en lugar de otras noSQL como Casandra, por ejemplo? ¿Y por qué Postgres? ¿Qué os llamó más la atención en cuanto a ellas ¿Cuota de mercado? ¿Rendimiento? ¿Ecosistema?

ÁLVARO: Con respecto a la compatibilidad con MongoDB. Las bbdd NoSQL cada una han decidido crear su propio API, su propio interfaz al usuario. Esto ha creado una gran fragmentación en el mercado, confusión al usuario y dificultad de migración. De hecho, es probablemente un factor determinante que hará desaparecer a muchas bbdd NoSQL "pequeñas" porque crea una barrera de entrada. En ToroDB hemos optado por no inventar un interfaz nuevo, y sufrir esos mismos problemas, sino reutilizar uno ya existente. En este sentido, hemos buscado el líder del mercado, el más popular, el más utilizado, para favorecer la adopción. Y este es MongoDB.

En cuanto a Postgres (o PostgreSQL). Necesitábamos como base una bbdd relacional, sólida, fiable, extensible y software libre. Nadie dudaría en contestar "PostgreSQL" a esos requisitos. Además de ello, 8Kdata tiene un muy gran expertise en PostgreSQL, de más de década y media, y somos miembros relevantes de la comunidad mundial y fundadores de PostgreSQL España, el 5º PUG (Postgres User Group) mayor del mundo. Por lo tanto es una mezcla de las características de Postgres (en particular su extensibilidad) y nuestra experiencia con esta base de datos.

GENBETA DEV: Partimos del escenario más sencillo: somos desarrolladores que ya usamos MongoDB en nuestras aplicaciones ¿Qué deberíamos hacer para empezar a usar ToroDB? ¿Qué pasos y acciones tenemos que tener en cuenta?

ÁLVARO: En primer lugar el lanzamiento de ToroDB Stampede 1.0 beta, que va orientado tanto a realizar queries analíticas/BI/Data Warehousing de Mongo como a migrar de MongoDB a relacional. Su funcionamiento es muy sencillo: Stampede se comporta como un nodo más del replica set de MongoDB. Tan pronto se instale, configure (opcionalmente) y lance, comenzará a replicar desde 0 todos los datos que haya en el replica set, y continuará haciéndolo en tiempo real según se vayan insertando más datos en MongoDB.

Los datos, en Stampede, serán analizados, transformados de json a un diseño relacional, con tablas, columnas, relaciones, etc, como si lo hubiera diseñado un dba (decimos que ToroDB crea el DDL automágicamente). Y una vez ahí, se podrá conectar directamente y hacer queries sobre los datos en SQL puro, con un rendimiento para queries agregadas que puede ser 100 veces mayor que en MongoDB.

GENBETA DEV: Gestionar un proyecto Open Source no es trivial ¿Cómo suele ser el proceso de aceptación de PR al proyecto de ToroDB? ¿Cómo dáis visibilidad a esas colaboraciones? ¿Cómo estáis llevandolo o cómo tenéis pensado plantearlo para que encaje con vuestro Roadmap?

ÁLVARO: Estamos encantados de recibir contribuidores. El primer paso es, idealmente, comunicarse con nosotros a través de la lista de correo de desarrolladores para discutir qué se quiere hacer y qué dirección seguir. A partir de ahí, crear un parche, enviar un PR y el equipo de ToroDB lo evaluará. Todos los PR aceptados mantienen completamente la autoría del contribuidor y ToroDB garantiza que dicha contribución será software libre para siempre. Los contribuidores serán además listados en los release notes.

En cuanto al encaje con el Roadmap, las contribuciones son, sin duda, también feedback, y pueden alterar nuestro roadmap, al igual que las issues en Github. El encaje lo haremos en un análisis caso por caso, porque depende de muchos factores, como el porcentaje de contribución del contribuidor, cómo de nuclear sea la característica y nuestros propios recursos. Pero en general, si la contribución es beneficiosa para una mayoría de los usuarios , tenemos una política muy abierta y colaborativa hacia las mismas.

• Más información | ToroDB Stampede
• 8KData Blog | Announcing ToroDB Stampede 1.0 beta

También te recomendamos

Una introducción a MongoDB

Desarrollo del pie: cómo ayudar al bebé a empezar a caminar

UnQL, un lenguaje de consulta unificado para todas las bases de datos NoSQL

-
La noticia ToroDB Stampede, toda la potencia de una base de datos NoSQL en un entorno relacional mucho más eficiente fue publicada originalmente en Genbeta Dev por Txema Rodríguez .

Actualmente el número de herramientas a disposición de los equipos de desarrollo para probar software es muy amplio. Para cualquier tipo de prueba que queramos realizar (funcionales, rendimiento, regresión, etc.) el número de opciones disponibles, tanto gratuitas como comerciales, es muy grande. De entre todas estas he elegido 12 herramientas imprescindibles para probar software (y sus alternativas).

En unos casos son programas desarrollados para probar software. En otros, son programas que aunque no nacieron con ese propósito, han demostrado ser perfectos para realizar determinadas pruebas.

Hemos decidido incluir al menos una alternativa a cada uno, para que podáis comparar y elegir cual es la opción que mejor se adapta a vuestro caso.

SoapUI - Postman

SoapUI pertenece a las herramientas que nacieron para probar software. Está desarrollada en Java, y se utiliza para pruebas funcionales de APIs y servicios web. SoapUI tiene una versión gratuita de código abierto, y una versión de pago con algunas funcionalidades que hacen que sea mucho más productiva. Se trata de una opción absolutamente madura, cuya primera versión es de septiembre de 2005. Prácticamente imprescindible para los expertos en pruebas sobre APIs.

SoapUI tiene muchas funcionalidades interesantes: Permite crear conjuntos de pruebas tan complicados como queramos, analizar la cobertura de tests sobre nuestro servicio SOAP o REST, cambiar el entorno de pruebas de forma rápidamente, crear mocks a partir de un WSDL o incluso facilitar ciertas pruebas de seguridad.

La alternativa a SoapUI es Postman, mucho más popular entre los desarrolladores que SoapUI. Postman nos permite construir y gestionar de una forma cómoda nuestras peticiones a sevicios API REST.

Apache JMeter - HP LoadRunner - Octoperf

Apache JMeter y HP LoadRunner son 2 de los mejores programas para realizar pruebas de rendimiento y stress. JMeter es de código abierto y se puede descargar gratuitamente. Se utiliza para generar un gran volumen de carga que nos permita analizar y medir el rendimiento de aplicaciones web.

Load Runner es la alternativa para pruebas de rendimiento de HP. Existe la opción de utilizar LoadRunner en versión SaaS, de forma gratuita con su Community Edition, y ver de esta forma si es la herramienta adecuada para nosotros, sin ningún coste.

Una tercera opción para pruebas de rendimiento, también como SaaS es Octoperf. Basándose en JMeter, han creado una herramienta que no necesita de ninguna instalación y que nos permite crear escenarios, monitorizar nuestros entornos, ejecutar pruebas y analizar los resultados desde un mismo punto.

Sonarqube - Kiuwan

Sonarqube es una de las utilidades más populares para realizar análisis estático de código. Es open source, por lo que en principio es gratuito. Eso si, tendremos que instalarlo en una máquina, y mantenerlo actualizado. Además, determinados plugins son de pago, como por ejemplo el plugin para analizar código Swift, que cuesta 5.000 euros al año por instancia de Sonarqube.

Kiuwan es otro analizador estático de código, pero en este caso se trata de un servicio que podemos usar para analizar nuestro código sin preocuparnos por instalaciones ni actualizaciones. Podemos subir nuestro código a la nube para analizarlo, o descargar una aplicación que analizará nuestro código localmente y subirá los resultados a Kiuwan. Tanto Sonarqube (sonarlint) como Kiuwan tienen integración con distintos IDEs, que nos permiten detectar incidencias en nuestro código mientras lo escribimos, sin tener que esperar a análisis posteriores. También en ambos casos existen plugins para herramientas de integración continua como Jenkins.

Sonarlint para IntelliJ

Wget - Curl

Se trata de 2 programas que permiten descargar contenido de servidores web. No son utilidades de testing propiamente, pero dadas sus múltiples posibilidades, se usan habitualmente en combinación con otras para realizar ciertas tareas durante las pruebas, como por ejemplo simular las acciones de usuarios.

La principal característica diferenciadora de wget es su recursividad, que permite usarlo como una araña web que extrae enlaces de las páginas web y los descarga, repitiendo el proceso recursivamente hasta que todas las páginas han sido descargadas, o hasta que se haya alcanzado en nivel de repetición máxima especificado por el usuario. Curl por su parte tiene como ventajas el estar disponible para prácticamente cualquier plataforma, el tener una libreria con un API, soportar muchos más protocolos (SCP, SFTP, TFTP, TELNET, LDAP(S), FILE, POP3, IMAP, SMTP, RTMP y RTSP) y además permitir subir o enviar archivos.

Charles - Fiddler

Charles y Fiddler son 2 aplicaciones que se utilizan como proxy para hacer debug web o para capturar el tráfico de sesión de dispositivos móviles. Permiten capturar y grabar tráfico http/https, obteniendo información muy importante para nuestras pruebas. Fiddler cuenta con una versión totalmente funcional de forma gratuita, mientras que Charles dispone de una versión de prueba de 30 días, pero después necesitaremos comprar una licencia.

Sus utilidades son múltiples y, además de para capturar el tráfico de nuestra aplicación móvil, también podemos capturar tráfico http/https que después podemos utilizar para crear nuestras pruebas de rendimiento con Octoperf.

Greenshot - Jing - Shutter

A la hora de comunicar errores o comportamientos que no son correctos, una imagen claramente vale más que mil palabras. Sobre todo porque los desarrollos nunca van sobrados de tiempo, y si podemos evitarnos teclear una sola palabra de más, mejor. Es por eso que, un buen programa que nos permita tomar pantallazos de un área de la pantalla específica, o de una ventana, y destacar ciertos elementos o escribir notas, es muy importante.

Greenshot es una muy buena opción, pero sólo está disponible para Windows. Cuenta con un editor que nos permite, entre otras cosas, ofuscar determinadas áreas, para ocultar determinados elementos, recortar, añadir efectos, rotar imágenes, añadir textos, destacar áreas, o incluso añadir un efecto lupa sobre las zonas sobre las que queremos llamar la atención.

Imagen capturada con Greenshot y con diferentes efectos

Jing tiene 2 cosas que la hacen muy interesante: Disponible para Windows y Mac, y permite grabar vídeos de hasta 5 minutos (en formato flash (.swf)). Por último, para quienes trabajen con Linux, mi recomendación es Shutter.

Beyond compare - Kdiff3

A la hora de comparar archivos hay muchas opciones. Podemos simplemente necesitar comparar 2 archivos de texto con notepad++, o podemos comparar 2 archivos para ver si son exactamente iguales o no. Beyond Compare nos permite comparar archivos o carpetas, incluso archivos Microsoft Word o PDF, y realizar comparaciones de archivos byte a byte para asegurarnos de si son o no exactamente iguales. Además está disponible para Windows, Mac y Linux. Eso si, a partir de un cierto número de usos tendrás que pasar por caja (30$ la versión standard).

Una alternativa interesante y gratuita es Kdiff3. Está disponible para Windows, Mac y Linux y entre sus funcionalidades están el poder comparar 2 o 3 archivos de texto o directorios, y la posibilidad de combinar archivos de forma automática, o a través de su editor integrado.

Crashlytics - Testfairy

Estas 2 herramientas nos permiten distribuir versiones beta de nuestras aplicaciones para iOS y Android y extraer información de las pruebas que hagan nuestros testers.

Crashlytics nos permite distribuir nuestra aplicación, y además obtener información muy detallada de lo que los usuarios hacen. Testfairy, también facilita distribuir nuestra aplicación entre nuestros testers, acceder a logs, obtener feedback de los usuarios, grabación en vídeo de lo que hacen los usuarios e informes de error cuando la aplicación se rompe.

Si queremos una tercera opción, Appsee incluye muchas de las funcionalidades de las 2 anteriores. Además permite grabar en video sesiones de usuarios, para poder ver como utilizan la aplicación exactamente. Otra funcionalidad interesante es la de los mapas de calor de las zonas de toque, indicativos de las áreas dónde más atención ponen nuestros usuarios:

Mapas de calor de toques

Jenkins - Travis CI

Jenkins y Travis CI son 2 de las opciones más interesantes en cuanto a servidores de integración continua, aunque hay más opciones como TeamCity, CircleCI y Bamboo.

En cuanto a las diferencias, entre Jenkins y Travis CI, una de las más importantes es que Travis es un servicio en la nube (salvo la versión Enterprise, que se puede alojar en nuestra infraestructura), mientras que en el caso de Jenkins nosotros tenemos que alojar esa máquina, mantenerla y actualizarla. Otra diferencia es que Jenkins es gratuito, y Travis es de pago, salvo para proyectos Open Source. El funcionamiento también es diferente, puesto que en Jenkins configuramos jobs para realizar tareas, mientras que con Travis los comandos los especificamos en un archivo que está junto con nuestro código (archivos .travis.yml).

Nightwatch.js - Webdriver.io

En cuanto a frameworks para automatización de pruebas, he elegido 2 opciones que funcionan sobre Node.js, Nightwatch.js y Webdriver.io. Los 2 nos van a permitir escribir pruebas que utilizarán Selenium Webdrver para realizar comprobaciones en sitios y aplicaciones web, pudiendo utilizar para ello distintos navegadores web. El código, como veis en el siguiente ejemplo, es bastante asequible:

Ejemplo de Nightwatch.js

Tanto Nightwatch.js como Webdriver.io incluyen un runner que nos permite lanzar las pruebas desde nuestro sistema de integración continua. También pueden integrarse con otros aplicativos,como appium, para pruebas en dispositivos móviles.

La principal diferencia, a favor de Webdriver.io es que cuenta con una utilidad qu nos permitirá configurar nuestro proyecto simplemente respondiendo a algunas preguntas.

Easy Test Setup

HP Quality Center - Jira - Redmine

A la hora de gestionar las pruebas, HP Quality Center se puede considerar la opción estándar (si el presupuesto lo permite). Incluye gestión de requisitos, gestión de pruebas, gestión de defectos, paneles con métricas y mucho más. Forma parte de HP Application Lifecycle Management, relativamente habitual en grandes corporaciones.

Otra opción que podemos utilizar para gestionar nuestras pruebas es Jira. Simplemente con Jira, creando diferentes tipos de tareas y subtareas, o bien con plugins como Zephyr, tendremos gestión de requisitos, gestión de pruebas, gestión de defectos y paneles con informes, utilizando una herramienta que es bastante habitual en los equipos de desarrollo.

Redmine está más enfocada en equipos de QA. Es un software para la gestión de proyectos que incluye un sistema de seguimiento de errores. Redmine destaca por ser software libre y de código abierto, disponible bajo la Licencia Pública General de GNU.

mRemoteNG - MobaXTerm - RoyalTS

Por último voy a hablar de mRemoteNG, para mi, software de uso intensivo a diario. mRemoteNG es una aplicación que permite conexiones a equipos remotos. Soporta lo siguientes tipos de conexión: RDP (Remote Desktop), VNC (Virtual Network Computing), ICA (Independent Computing Architecture), SSH (Secure Shell), Telnet (TELecommunication NETwork), HTTP/S (Hypertext Transfer Protocol) y Rlogin (Rlogin). Podemos tener conexiones a diferentes tipos de máquinas, a las que nos conectaremos simplemente haciendo doble click. Además, podremos tener abiertas las conexiones que queramos en diferentes pestañas. Eso si, sólo disponible para windows. MobaXTerm es una alternativa a mRemoteNG muy interesante. Permite conexiones SSH, Telnet, Rlogin, RDP, VNC, XDMCP, FTP, SFTP o sesiones por puerto serie. Esta opción también, sólo disponible para windows. Una de las cosas más interesantes es la opción de multi ejecución, que permite ejecutar los mismos comandos en diferentes servidores, con sólo escribir una vez.

Por último, una opción para Windows y Mac, y para dispositivos iOS y Android es [RoyalTS](https://www.royalapplications.com/ts/osx/features).

Cada uno de estos programas da para varios artículos, y lo que hemos hecho no es más que una breve presentación. Si quieres saber más de alguna en concreto, o crees que alguna de ellas tiene alguna otra alternativa interesante, déjanos un comentario, y le dedicaremos un artículo.

También te recomendamos

FlowUp, cómo monitorizar el rendimiento de tus aplicaciones Android e iOS

¿No paras ni un segundo? Estos trucos te ahorrarán tiempo y dinero para estar perfecta en Navidad (y todo el año)

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

-
La noticia 12 herramientas imprescindibles para asegurar la calidad del software (y sus alternativas) fue publicada originalmente en Genbeta Dev por Raúl Hernández .

Recientemente se celebró Codemotion Spain 2016, el evento anual de desarrollo más multitudinario del territorio nacional, por segundo año consecutivo en el campus Montepríncipe de la Universidad San Pablo CEU de Boadilla del Monte, Madrid. Como no podía ser de otra manera, algunos editores y colaboradores de Genbeta Dev estuvimos por allí. Servidor entre ellos (obviamente, si no de qué iba a estar escribiendo este post) y estos son algunos apuntes, pensamientos y dudas que me suscitó dicho evento.

No reinó el caos, ergo éxito

Un evento de dos días con miles de asistentes y más de un centenar de charlas y talleres y que no terminé como el rosario de la aurora, sumido en un caos digno de 'El Señor de las Moscas', ya es en si mismo un éxito. Así que lo primero es darle, una vez más, enhorabuena al equipo de Codemotion por su encomiable labor.

Los "uniformes" están de moda

Empezó Tuenti (siguiendo el ejemplo de Facebook y demás totems del Valle, para variar) y ahora le siguen todos. De Beeva a Idealista pasando por Paqlink, Liferay, Lastminute.com o Jobandtalent (y muchas comunidades no relacionadas con empresas también). Sin tu camiseta corporativa no eres nadie y lo sabes.

¡Viva la diversidad!

No todo es web y apps, apps y web, en Codemotion. El monopolio va cediendo y este año hemos visto charlas de cloud, robótica, inteligencia artificial, big data, bots... Algunas charlas muy técnicas y otras más divulgativas e incluso inspiradoras (o por lo menos eso pretendían, que luego cada uno verá si consiguió inspiración o no). Así sí. Por cierto, aquí la agenda completa con sus slides y vídeos correspondientes.

¿Dónde está PHP?

Uno de los grandes damnificados de esta diversidad ha sido PHP: tan sólo un par de charlas entre todos los tracks (y había 8, más cuatro talleres). ¡Pero es que ni siquiera ha sido el foco principal de las bromas en las demás charlas! Ese honor ha sido este año para los frameworks de Javascript y su imparable y alocado florecimiento. Un nuevo orden.

Faltan mujeres, eso es así

Más mujeres entre los ponentes y entre los asistentes que otros años (y que otros eventos), sí, pero pocas todavía. Hubo incluso cierto polémica que se dio en llamar GenderGate. Harían bien desde la organización en "darle una pensada" a la situación. Y ya están en ello, que en esta edición ha habido una mesa redonda de título '¿Cómo acabar con la brecha de género en Tecnología?' en la que profesionales del sector como Laura Lacarra o Eva Mosquera.

#MargaretHamilton"symbolizes that generation of unsung women who helped send humankind into space." —@POTUShttps://t.co/QDA7exXkIHpic.twitter.com/E4PL2CykPU

— MIT (@MIT) 23 de noviembre de 2016

Un poco de brainstorming: ¿Track sólo con ponentes femeninas? ¿Regalar entradas a chicas developers en universidades e institutos? ¿Intentar traer a alguna desarrolladora top internacional (no hace falta que sea Margaret Hamilton, eh)? Opciones hay muchas, estas y otras, pero algo hay que hacer porque el tamaño y la visibilidad de Codemotion así lo exige.

¿Es buena idea puntuar las sesiones?

Una novedad de esta edición ha sido la posibilidad de puntuar y comentar las charlas. Una oportunidad muy buena tanto para que el ponente reciba buen feedback que le haga progresar como para que el troll de turno se desahogue. Sí, hay que registrarse y sí, había ciertas normas, pero ¿de verdad es una buena idea? Yo no estoy muy seguro, la verdad. Y menos si las puntuaciones son "por estrellas".

Es un congreso, no un concurso, ni un ranking. Seguro que hay otras maneras de dar feedback a los ponentes más discretas y menos susceptibles de trolleo (por ejemplo buzones de sugerencias, formularios de contacto...).

¿Momento para rotar?

Al ser una marca con ramificación internacional, no se como de "libres" están los organizadores de Codemotion Spain para innovar e introducir cambios pero, una vez asentado el evento en Madrid (consiguiendo incluso unas instalaciones bastante apañadas, lejanas pero apañadas), es posible que sea un buen momento para visitar otras ciudades donde la comunidad developer también es amplia (Barcelona, Bilbao, Sevilla, Valencia...), ya sea con ediciones propiamente dichas o con spin-offs más pequeños que se compaginen con el evento principal.

Y hasta aquí mis cuitas y reflexiones. Los comentarios están abiertos por si estuviste allí y quieres dejarnos tus impresiones. También nos interesa que si lo seguiste vía streaming, nos cuentes que tal (que no tenemos feedback ahora mismo). Bueno, que carallo, si ni fuiste ni lo seguiste por streaming también nos interesa conocer tu opinión.

Imágenes | Codemotion en Flickr En Genbeta Dev | Todo lo que hemos escrito sobre Codemotion Más info | Codemotion 2016

También te recomendamos

Large-scale Scrum, multas por no cumplir la normativa sobre cookies y hackers éticos: Pull Request #12

Otro compilador PHP para el bote: Recki-CT

Cómo mejorar tu foto sin tener que disparar el flash: los fotógrafos expertos te ayudan

-
La noticia Codemotion Spain 2016: apuntes, reflexiones y cuestiones varias fue publicada originalmente en Genbeta Dev por Fernando Siles .

Las APIs más populares que utilizamos a día de hoy son RESTful APIs o un pseudo estándar ad hoc HTTP inventado bajo demanda en ciertos proyectos. La necesidad de avanzar más rápido en productos cada vez más complejos, más allá de un simple CRUD, ha empujado un cambio en la forma en que interactuamos con las APIs. Aquí es dónde surge GraphQL, un fuerte candidato a sustituir a REST, sobre todo en el ecosistema de APIs para apps en mobile.

¿Qué hay de malo en REST? Nada en su concepción inicial y en el contexto dónde surgió, pero desde que fuera definido la forma de interactuar con las APIs ha cambiado. Vamos a repasar las razones por las que deberíamos repensar las tradicionales APIs basadas en RESTful en favor de GraphQL.

RESTful APIS versus GraphQL APIs

Obviamente las APIs REST han sido uno de los puntos determinantes para el auge del desarrollo de apps y de servicios distribuidos, tal como lo conocemos actualmente. Son “el pegamento” que no puede faltar en cualquier app.

REST es un claro caso de éxito, pero su concepción CRUD basada en resources, verbos y códigos de respuesta HTTP denotan cada vez más sus limitaciones y su inflexibilidad.

Principales debilidades de RESTful

En RESTfulutilizamos una URI para leer o escribir un único recurso, ya sea, por ejemplo, un producto, una persona, un post o un comentario. Si necesitamos trabajar con múltiples recursos como un listado de posts con un listado de comentarios, necesitamos manejar múltiples endpoint y encadenar distintas llamadas, a veces de forma secuencial. Es en las apps donde recae la responsabilidad de unir y mergear cada recurso.

¿Cuántas veceas os habéis encontrado con la tediosa tarea de “pintar” una pantalla con la información procedente de 4 o 5 endpoint diferente? Por ejemplo, solicitar los ids de los comentarios de un post concreto para luego pintarlos en la misma pantalla junto a él. Aquí por ejemplo, necesitamos una request al detalle del post, a las estadísticas del post, al listado de comentarios, etc… después juntar toda esa información.

Cuando hacemos una request, no recibimos simplemente la información que necesitamos, sino todo el conjunto de datos relativos al resource alojado en esa URI. Algo bastante complicado de gestionar y costoso en recursos cuando el 90% de los datos procedentes de cada resource/endpoint son innecesarios. Por ejemplo, si solo queremos obtener el nombre de una persona al hacer la consulta recibiremos datos como, por ejemplo, su fecha nacimiento o su profesión. Datos innecesarios que desde el lado cliente no podemos controlar y entorpecen la obtención de información necesaria.

El versionado de una API REST no es trivial. En muchas ocasiones necesitamos añadir nuevos campos o modificar el tipo de alguno de ellos pero para poder dar soporte de retrocompatibilidad los incluimos en el payload que los clientes viejos, lo cual hace crecer el payload de respuesta innecesariamente. O bajo otra estrategia, desde el lado del servidor gestionamos “vistas distintas” según la versión del cliente que consume el recurso. A veces eso nos lleva a innumerables if, codigo spagetti que poluciona el código original de respuesta.

Todos conocemos los verbos HTTP involucrados en las peticiones RESTful pero eso no asegura su correcta utilización. Ni mucho menos de sus códigos error basados en HTTP. Hay una decena de ellos representados a lo largo de las diversas categorías de 2XX, 3XX, 4XX o 5XX. Incluso algunos de ellos han ido surgiendo bajos las necesidades, pero no se utilizan de forma homogénea (a veces de forma laxa y poco estricta).

Por supuesto, las respuestas de error con el payload que reciben los clientes no se quedan atrás en la incoherencia de muchas APIs REST que consumimos. No hay una especificación que lo fije. Lo cual requiere que cada API necesite ser acompañada de una documentación para el desarrollador, corriendo el riesgo de ser incompleta, desactualizada o violada sin previo aviso desde la parte del servidor.

Para aliviar las idas y venidas obteniendo datos de un endpoint a otro muchos desarrolladores se lanzan al acuerdo explícito entre backend y mobile de crear sus propias APIs adhoc. Una pseudo mezcla del RESTful más estricto en algunos endpoint a un libertinaje de payload que componen vistas saltándose uno de los principales reglas de RESTful.

Lo que parece una buena solución puede convertirse en un auténtico quebradero de cabeza de mantener polucionado todo de código duplicado, abstracciones y la recurrente deficiente retrocompatibilidad. Los clientes que utilizan estos custom endpoint no pueden romper el contrato implícito fijado con lo que al final es imposible eliminar campos y los nuevos deben ser añadidos, aunque los consumidores ni los utilicen.

Con endpoint creados bajo el libre albedrío de una API custom, adhoc no tiene un sistema formalizado de tipos perdiendo la potencia de herramientas como Swagger para documentar o gRPC para crear idiomatic client apis.

¿Por qué utilizar GraphQL en nuestras APIs?

GraphQL es una de las alternativas que han surgido para solucionar la mayor parte de estos problemas arriba descritos con API REST.

El primer borrador del RFC (aún en desarrollo) que especifica GraphQL fue creado por Facebook. Tal como ellos mismo explican llevan usándolo y perfeccionandolo desde 2012 en sus apps móviles. Y no son los únicos, también Github, Pinterest o Shopify se han unido al carro. Todos los interesados en implementar GraphQL pueden colaborar en su definición, es Open Source.

GraphQL es un protocolo agnóstico y no depende en nada de HTTP. No usa métodos o respuestas HTTP. Por supuesto, sigue siendo el canal más popular para comunicarse entre consumidores de GraphQL.

Unas de las principales características de GraphQL es que el lenguaje y sintaxis usado en la request es el mismo que el de la respuesta. Analizando el JSON podemos comprender claramente el diccionario de key-value. Simplificando su uso podríamos decir que es un lenguaje pregunta/respuesta expresada en relaciones entre los objetos expuestos. Además GraphQL dispone de un sistema de tipado fuerte por el que cualquier mal uso puede ser rápidamente detectado en tiempo de desarrollo (incluso desde el IDE) en contraposición a un mapeo clásico de JSON.

Otro de sus principales rasgos es que la API puede ser single endpoint. Es decir, un único endpoint puede manejar sin problemas las peticiones de los clientes. Todas ellas puede preguntar sobre múltiples recursos y campos, tan sólo indicando qué necesitan. La respuesta será acorde a esta demanda de información, ni más ni menos.

Estas son algunas de las razones que hacen GraphQL eficiente, efectivo y fácil de usar. Pero su principal razón de ser es cambiar la concepción hasta ahora utilizada alrededor de los clientes móviles bajo un modelo Declarative Data Communication.

Los cliente móviles necesitan tener más poder de decisión sobre los datos que necesitan consumir. Esto les provee de mayor independencia sobre los servicios de datos. Las queries son enviadas desde el cliente lo que simplifica la retrocompatibilidad explícita.

Debemos evitar en la medida de los posible los clásicos viajes de datos entre cliente y servidor para componen ciertos datos requeridos para componer un vista única. El diseño GraphQL permite manejar jerarquías de objetos para componer las vistas que necesitemos de ellos, según los requisitos solicitados por el cliente.

Ejemplo de API GraphQL frente a una API tradicional REST. Creando una app sobre Starwars

Para comprender las diferencias entre API REST y GraphQL hay un excelente ejemplo utilizando la API de Starwars de personajes para construir una pequeña aplicación que consuma información de ambas APIs.

Aquí tenéis cada una de ellas para trastear por vuestra cuenta:

• API REST: SWAPI

• API GraphQL: SWAPI GraphQL Wrapper

Vamos a imaginar la vista de una app que pretender representar la ficha de los personajes de Starwars que muestran básicamente estos campos: * Nombre del personaje * Fecha de nacimiento * Lugar de nacimiento * Películas en las que aparece

Utilizando la API REST necesitaremos componer la vista con las siguientes request y sus correspondientes response:

• Obtenemos la información del personaje, por ejemplo, Luke Skywalker

people/1

{
    "name": "Luke Skywalker",
    "height": "172",
    "mass": "77",
    "hair_color": "blond",
    "skin_color": "fair",
    "eye_color": "blue",
    "birth_year": "19BBY",
    "gender": "male",
    "homeworld": "http://swapi.co/api/planets/1/",
    "films": [
        "http://swapi.co/api/films/6/",
        "http://swapi.co/api/films/3/",
        "http://swapi.co/api/films/2/",
        "http://swapi.co/api/films/1/",
        "http://swapi.co/api/films/7/"
    ],
    "species": [
        "http://swapi.co/api/species/1/"
    ],
    "vehicles": [
        "http://swapi.co/api/vehicles/14/",
        "http://swapi.co/api/vehicles/30/"
    ],
    "starships": [
        "http://swapi.co/api/starships/12/",
        "http://swapi.co/api/starships/22/"
    ],
    "created": "2014-12-09T13:50:51.644000Z",
    "edited": "2014-12-20T21:17:56.891000Z",
    "url": "http://swapi.co/api/people/1/"
}

• Información de su lugar de nacimiento

planets/1/

{
    "name": "Tatooine", 
    "rotation_period": "23", 
    "orbital_period": "304", 
    "diameter": "10465", 
    "climate": "arid", 
    "gravity": "1 standard", 
    "terrain": "desert", 
    "surface_water": "1", 
    "population": "200000", 
    "residents": [
        "http://swapi.co/api/people/1/", 
        "http://swapi.co/api/people/2/", 
        "http://swapi.co/api/people/4/", 
        "http://swapi.co/api/people/6/" 
    ], 
    "films": [
        "http://swapi.co/api/films/5/", 
        "http://swapi.co/api/films/4/"
    ], 
    "created": "2014-12-09T13:50:49.641000Z", 
    "edited": "2014-12-21T20:48:04.175778Z", 
    "url": "http://swapi.co/api/planets/1/"
}

• Películas en las que ha participado (n peticiones por cada película)

films/6/

films/3/

films/2/

films/7/

films/1/

films/6/

Después de combinar estas 6 respuestas JSON procedentes del servidor podremos satisface los datos requeridos por la vista. Anotamos dos grande problemas: el número de request/response diferentes que debemos que manejar y la cantidad de datos innecesarios que recibimos sin necesitarlos en el payload de la respuesta.

Por otro lado, utilizando el ejemplo de API GraphQL vamos obtener esos mismos datos.

Como comentábamos en el artículo, somos capaces de seleccionar los datos que queremos obtener. Básicamente podemos a partir del esbozo de datos de los requisitos de nuestra pantalla podemos construir la siguiente query de GraphQL:

/graphql?query={...}

{ 
  person(personID: 1) { 
    name 
    birthYear 
    homeworld { 
      name 
    } 
    filmConnection { 
      films { 
        title 
      } 
    } 
  } 
}

Lo que recibimos de respuesta se asemeja completamente a nuestra petición rellenando los valores de cada campo, tal que así:

{
  "data": {
    "person": {
      "name": "Luke Skywalker",
      "birthYear": "19BBY",
      "homeworld": {
        "name": "Tatooine"
      },
      "filmConnection": {
        "films": [
          {
            "title": "A New Hope"
          },
          {
            "title": "The Empire Strikes Back"
          },
          {
            "title": "Return of the Jedi"
          },
          {
            "title": "Revenge of the Sith"
          }
        ]
      }
    }
  }
}

Una de las herramientas más potentes que dispone GraphQL es GraphiQL, un sandbox para hacer consultas a la API aprovechando su carácter fuertemente tipado que nos ayuda a construir las queries y descubrir semánticamente los campos y relaciones disponibles.

Este artículo sólo ha sido una introducción a GraphQL. Nuestra intención ha sido hacer una comparación entre las tradicionales APIs REST y GraphQL.

Por supuesto, tenemos que adentrarnos en la implementación de GraphQL en backend y el ecosistema de librería, tools que dispone y sobre todo su relación con Relay y React en próximos artículos. Si queréis conocer más sobre el proyecto la web oficial de GraphQL mantenida por Facebook contiene gran cantidad de recursos.

También te recomendamos

Interoperabilidad en el siglo XXI

Pop, el motor de animaciones de Paper, liberado por Facebook

Los 13 mitos que no te creerías que fueran falsos pero Adam Savage demostró que sí lo son

-
La noticia¿Por qué deberíamos abandonar REST y empezar a usar GraphQL en nuestras APIs? fue publicada originalmente en Genbeta Dev por Txema Rodríguez .

La última semana de Noviembre estuve en Fort Lauderdale, Florida, en la conferencia G3 Summit en la que dí dos charlas. Se trata de la primera edición de una conferencia centrada en Groovy, Grails y Gradle, y organizada por el mismo equipo que se encargaba de la SpringOne 2GX. Debo admitir que Miami es un muy buen lugar para organizar una conferencia a finales de Noviembre. Pasar de los 8ºC y la lluvia de Madrid a los más de 25ºC y el sol de Miami es algo de agradecer.

La agenda incluía más de 50 charlas y a los principales líderes de los distintos proyectos del ecosistema Groovy. En G3 Summit estuvieron presentes tanto Graeme Rocher, líder del proyecto Grails como Jeff Brown, co-fundador del mismo framework; Guillaume Laforge líder de Groovy o Ken Kousen de Groovy Podcast y autor del libro Making Java Groovy.

Talleres y charlas

Durante la conferencia asistí a un workshop, tres keynotes y ocho charlas y en general todas fueron buenas. De ellas, mis favoritas son:

Build Web Applications with Ratpack

Empecé la conferencia con el workshop de Dan Woods sobre Build Web Applications with Ratpack. Dan, además de ser miembro del equipo de Ratpack ha escrito el primer libro sobre el framework: Learning Ratpack.
El workshop me encantó: muy bien estructurado con pequeños fragmentos de código que había que completar y tests ya preparados que servían para probar que todo era correcto. Además de muy buenas explicaciones por parte de Dan y también buena gestión del tiempo entre los distintos ejercicios. La verdad es que en ocho horas de workshop dio tiempo a ver muchos aspectos distintos de Ratpack y probar en profundidad distintas opciones y formas de resolver los problemas.
Si alguien está interesado en el workshop está disponible en el github de Dan.

High Performance Groovy

Una de las mejores charlas que he visto en mucho tiempo sobre problemas de rendimiento, pitfalls y gotchas a evitar cuando se trabaja con Groovy y, en algunos casos, también con Java. David Clark hizo un gran trabajo explicando con muchos ejemplos y con gran detalle distintos aspectos que debemos tener en cuenta cuando desarrollamos aplicaciones Groovy. Me quedo con:

• Utiliza Java 8 si puedes. El rendimiento de Groovy en Java 8 ha mejorado mucho.
• Cuidado con el boxing/unboxing, puede afectar mucho al rendimiento. En este caso se trata de un problema de Java y no sólo de Groovy.
• Abuso de dispatch dinámico. Si tu código realmente no es dinámico es mejor anotarlo con @CompileStatic, la diferencia de rendimiento puede ser muy grande, especialmente si el código es CPU-bound.
• Si tu código tiene IO (acceso a disco, base de datos, red,...) da igual que sea dinámico o no, apenas se va a notar la diferencia de rendimiento porque todo el tiempo lo vas a gastar esperando por la latencias del disco o la red.

Finalmente terminó la charla mostrando algunas herramientas que podemos utilizar para diagnosticar problemas de rendimiento. Comentó que la mejor con diferencia es YourKit aunque VisualVM también ofrece buenos resultados.

Todo el código mostrado en la charla está disponible en este repositorio de Github en el que también se incluyen las slides

Functional Programming for Groovy Programmers

Si alguna vez estás en una conferencia y tienes la oportunidad de ver a Venkat Subramaniam no lo dudes, no te defraudará. Venkat es un gran speaker que sabe cómo mantener la atención de los asistentes durante toda la charla y tiene una gran facilidad para explicar y transmitir sus conocimientos.
En esta ocasión hizo una introducción a la programación funcional, las ventajas, distintas aproximaciones que tenemos en Groovy,... La charla fue realmente buena y fiel al estilo que Venkat nos tiene acostumbrados: sin utilizar slides, sólo una lista de temas de los que hablar y código, muchos ejemplos de código con los que dejó muy claros todos los conceptos.
Es una pena que no se grabara porque merecería la pena verla de nuevo con más calma.

Groovy Puzzlers S03 – The Unstoppable Puzzlers Hit Again!

La charla más divertida de la conferencia. En esta ocasión Baruch Sadogursky con ayuda de Guillaume Laforge presentaron la tercera edición de los Groovy Puzzlers. Para el que no lo conozca la idea surgió hace tiempo con una charla en la JavaOne por Joshua Bloch y Neal Gafter en la que mostraban fragmentos de código Java y daban diversas opciones a la audiencia sobre cual era la respuesta o comportamiento correcto.
En este caso se trataba del mismo planteamiento pero con Groovy en lugar de Java. Para cada fragmento de código había cuatro posibles opciones y una vez que los asistentes votaban se mostraba la solución correcta. Entre los que habían acertado la respuesta debían tratar de explicar el por qué para ganar una camiseta. Debo admitir que esta era la tercera vez que veía la charla pero fue igual de divertida y entretenida que las veces anteriores ya que nunca logro recordar las respuestas de una vez para otra.

Dockerize your Grails!

Esta fue mi primera charla. En ella hablé de los distintos problemas que tenemos al desarrollar aplicaciones Java, en particular centrándome en Grails, y expuse tres problemas:

• El entorno de desarrollo no es el mismo para todo el equipo de desarrollo.
• Los entornos de desarrollo y producción son muy diferentes.
• Los problemas cuando tenemos un nuevo miembro en el equipo y el tiempo que tarda esta persona en empezar a ser productiva.

Después de esta introducción presenté Docker como la solución a estos problemas. Di un repaso a los conceptos básicos, expliqué las diferencias entre una máquina virtual y Docker y enseñé pequeños ejemplos de cómo se puede utilizar Docker.
Finalmente llegó el momento de las demos. Había preparado una aplicación muy sencilla pero que tenía diversas partes móviles en la arquitectura. La aplicación tenía una aplicación Grails que se encarga de producir un mensaje de texto, otra aplicación Grails que recibía dicho mensaje de texto por medio de RabbitMQ y finalmente daba la vuelta al mensaje y lo almacenaba en una base de datos Postgresql. Con esta sencilla aplicación pude mostrar cómo podíamos utilizar Docker para resolver los tres problemas comentados anteriormente.

Todo el código se encuentra en este repositorio y las slides son:

Taking advantage of Groovy Annotations

Para mi segunda charla me centré en todas las tranformaciones que nos ofrece Groovy. Como desarrolladores debemos aprovecharnos de todas las características y ventajas de nuestro lenguaje de programación y Groovy proporciona una gran cantidad de anotaciones que nos hacen la vida más fácil al desarrollar. Después de explicar las distintas categorías y numerosas transformaciones hice una demo creando desde cero una sencilla transformación AST para añadir un campo VERSION a una clase. La idea era demostrar cómo es posible crear nuestras propias anotaciones para poder solucionar ciertos problemas que de otra forma serían más complicados de resolver.

El código de esta transformación así como los tests están disponibles en este repositorio y las slides aquí:

La comunidad Groovy

La comunidad Groovy no es demasiado grande por lo que después de haber asistido a unas cuantas conferencias de Groovy y haber dado charlas en ellas conozco a mucha gente. Esta conferencia me ha servido para reencontrarme con viejos amigos que hacía tiempo que no veía y conocer gente nueva. Además también ha servido para que todo el equipo de Grails de OCI nos reuniéramos por primera vez :)

Me gustaría agradecer a los organizadores de la conferencia por su trabajo porque ésta ha sido estupenda. Se notaba que el equipo de NFJS se había encargado de todos los detalles: comidas, salas, breaks, wifi,... Todo funcionó sin ningún problema.

En cuanto a las charlas, además de las que he destacado todas me parecieron buenas y con un muy buen nivel por parte de los speakers. El único aspecto negativo (por comentar algo) son las 9 horas y 30 minutos de avión desde Madrid a Miami, aunque eso es algo que no tiene fácil solución... ;-)

Conclusión

Me llevo tres ideas y cosas a mirar con más detalle para el futuro porque seguro que en el ecosistema Groovy van a seguir dando de que hablar:

• Grails: Obviamente conozco Grails en detalle pero no deja de sorprenderme todo lo que ha avanzado el framework durante el último año: grandes mejoras de rendimiento, distintos perfiles para integrarse con Angular 2 o React, GORM 6 con soporte para Hibernate 5, MongoDB, Neo4j y Cassandra, y un largo etcétera de mejoras. Merece la pena seguir todas las novedades para no quedarse atrás.
• Ratpack: Después de haber estado un día completo en el workshop me parece una pasada lo que el equipo de desarrollo de Ratpack está haciendo. Ahora que todo parece que tiene que ser microservices, reactive y asíncrono creo que Ratpack va a tener mucho que decir y aportar durante el próximo año a la hora de desarrollar ciertos proyectos en la JVM.
• Groovy: Por supuesto el tema central de la conferencia era Groovy ya que en la mayoría de los casos es el nexo común que tienen el resto de herramientas y frameworks. Groovy sigue evolucionando y ya se está trabajando en Groovy 3.0 con su nueva gramática, el nuevo Meta Object Protocol (MOP), soporte para Java 9 y gran cantidad de mejoras.

Hay gente que dice que Groovy está muerto pero conferencias como está no hacen más que demostrar que se equivocan.

También te recomendamos

Pau Garcia-Milà: “Para integrar el ZOE en mi rutina no he hecho ningún cambio”

Nueve anotaciones de Groovy que te harán la vida más fácil al desarrollar

Mejora tu código Java usando Groovy

-
La noticia Groovy está bastante vivo, conferencias como la G3 Summit lo demuestran (resumen y opinión) fue publicada originalmente en Genbeta Dev por Iván López .

Hace unas semanas os presentamos algunas de las grandes disyuntivas del mundo del desarrollo y os pedíamos ayuda para resolverlas. Tuvimos la encuesta abierta durante dos semanas y 2.228 de vosotros nos ayudasteis contestando alguna de las preguntas. He aquí los resultados (menos dolorosos que el Brexit, lo de Trump y demás), ¡el pueblo ha hablado!

Tabular con espacios o con tabulador

Donde esté ese elegante tabulador (77%) que se quiten los cortos espacios (23%), ¿verdad?.

Escribir código en editor de código o en IDE

La potencia de un buen IDE (73%) se impone con facilidad a los editores de código (27%). No es país para developers hardcore. Sí, Vim, Emacs, incluso Sublime tienen ese aura romántica pero a la hora de la verdad la potencia y las infinitas opciones de un IDE nos hacen ahorrar mucho tiempo y eso, en el mundo laboral real, es lo más importante.

Trabajar en una startup o en una consultora

No os va el rollo de traje, fichar y demás, eso está claro: paliza de la startup (69%) a la gran consultora (31%). No es inesperado, desde luego. Idealista y naif, quizás, inesperado, no.

Bola Extra: Por qué prefiero trabajar en una factoría de software en vez de en una startup

Trabajo presencial o en remoto

La perspectiva de trabajar desde casa, sin tener que salir a este mundo loco, a los atascos, al cafe aguado de máquina, no resulta tan tentadora como podría parecer y el trabajo en remoto pierde por bastante (58% - 42%) contra el trabajo presencial. ¡No hay quien os entienda! (A quién quiero engañar, yo voté por trabajo presencial también).

Bola extra: 10 cosas sobre trabajar en remoto que quizás no habías pensado y que debería tener en cuenta

Comentar el código o no comentarlo

No, mucho de código auto explicativo no somos, nos va más lo de comentar, anotar y acotar, cuales Alan Moore de la vida. 69 a 31, paliza. Porque el código debería ser bello como un poema de Whitman pero si comentas y explicas ese bucle infernal que tuviste que sacarte de la manga a última hora pues mucho mejor para tu yo del futuro. Las cosas como son.

Bola Extra: Diez consejos para mejorar tus comentarios de código fuente

Webservices SOAP o APIs REST

La paliza más clara (84% - 16%) es la que API REST le mete a SOAP. Pobre SOAP, no le quiere nadie (sus motivos hay, ¡eh!). Las APis RESTful se imponen con gran autoridad... ya sólo nos queda hacerlas bien de verdad, que hay demasiadas APIs que se dicen REST pero que realmente no lo son.

Bola extra: Unas cuantas buenas prácticas cuando hablamos de APIs REST

Java o PHP (u otro)

La pregunta más igualada, quizás por la forma en la que estaba planteada, pero se ve que Java sigue fuerte como una roca y puede con todo o por lo menos con PHP. ¿Quién podría acabar con su reinado? ¿Python? ¿Node? ¿Lenguajes declarativos? ¿Lenguajes Microsoft? ¿Taylor Swift?

Formación reglada o autodidacta

Otra sorpresa (por lo menos para quien esto escribe): frente a los que prefieren la formación reglada (44%), los que prefieren ser autodidactas, los que viven la universidad de la calle, son mayoría (56%) y sin demasiada discusión. Los años de universidad o de FP casi que se ven como un lastre que no tiene por qué ser obligatorio. No deja de resultar curioso porque tanto en España como en América Latina los títulos siempre han sido algo muy respetado y que ha vestido mucho. Como decía el reciente ganador del Nobel de Literatura Bob Dylan: times are changin.

Bola extra: ¿Es imprescindible pasar por la universidad para trabajar como programador?

Y a vosotros, ¿qué os parecen estos resultados?¿Sorprendentes? ¿Lógicos? ¿Absurdos? Los comentarios quedan abiertos.

Imagen de portada | Fotograma de 'Napoleon Dynamite'

También te recomendamos

Las 200 mejores universidades del mundo en Informática en 2014... ¡y hay españolas!

Cómo conseguir que a tu bebé le gusten las verduras (y más cosas)

El sueño de trabajar en Silicon Valley, empezar de prácticas en una startup

-
La noticia Resolvamos las grandes disyuntivas del mundo del desarrollo. Los resultados de lo que nuestros lectores dicen fue publicada originalmente en Genbeta Dev por Fernando Siles .

Hace tiempo que Kotlin se está convirtiendo en una alternativa real para muchos desarrolladores, principalmente en el mundo del desarrollo Android, donde aún seguimos anclados a versiones muy antiguas de Java.

Ya hablamos en su momento sobre cuáles eran las bondades de este lenguaje.

La gente de Gradle se ha dado cuenta de ello, y desde hace unos meses están trabajando con Jetbrains para crear Kotlin Script e integrarlo en Gradle 3.

Kotlin Script no es más que una forma de poder escribir scripts utilizando Kotlin, y es el mecanismo que utiliza Gradle para permitirnos definir sus build.gradle utilizando este lenguaje.

¿Cuáles son las ventajas de escribir los scripts de Gradle en Kotlin?

Dejando a un lado que uno pueda ser más o menos fan de uno u otro lenguaje, estas son las 3 principales ventajas que le encuentro al uso de Kotlin.

1. Es un lenguaje estático

Es decir, sabemos en tiempo de compilación qué tipos van a tener las variables, qué valores de retorno vamos a recibir de las funciones, etc. Y esto ayuda muchísimo al IDE a facilitarnos la tarea según estamos escribiendo.

Primero, porque nos permite un autocompletado muy potente. Y segundo, porque es capaz de preprocesar el código y detectar errores antes de ejecutar el script.

2. Integración total con el IDE

Lo que nos aporta múltiples ventajas, desde lo que comentaba en el punto anterior, hasta el uso de herramientas de refactorización, pasando por que podremos navegar al código fuente desde cualquier código escribamos.

3. Toda la aplicación en un mismo lenguaje

Aunque quizá sea una de las razones menos importantes, en la práctica puede ser muy útil. Podríamos tener todo nuestro proyecto Android escrito en Kotlin, tanto la aplicación como los scripts de construcción.

En proyectos muy sencillos que no requieran scripts muy complejos, casi no se va a notar la diferencia, porque el IDE lo genera por nosotros.

Pero en proyectos más grandes, Groovy se puede convertir en una barrera de entrada. Si el equipo ya está desarrollando la App en Kotlin, le será inmediato empezar a trabajar con Kotlin Script.

Ejemplo: App en Android usando Kotlin Script

Ya os comentaba que esto es una función experimental, así que está un poco lejos aún de ser algo sencillo de usar.

Por eso te voy a explicar los pasos que necesitas para crear un proyecto Android usando Kotlin Script para los build.gradle. Aquí la complejidad es doble porque tendremos dos build.gradle. El raíz y el del módulo.

Pero te cuento los pasos que necesitas.

1. Instala el plugin de Kotlin y activa las EAP de Kotlin 1.1

Kotlin Script sólo está disponible de momento en las EAP de la versión 1.1 de Kotlin, así que necesitas configurar el plugin para que descargue esa versión una vez que te lo instales:

Esta opción la tienes en Tools -> Kotlin -> Configure Kotlin updates

2. Crea un proyecto Android con Kotlin

Necesitas crear un proyecto nuevo en Android Studio y configurarlo para que use Kotlin. Puedes seguir los pasos exactos en esta guía.

3. Utiliza una distribución de Gradle que soporte Kotlin Script

La última hasta la fecha es una preview de 3.3 de Gradle. En gradle/wrapper/gradle-wrapper.properties modifica esta línea:

distributionUrl=https\://repo.gradle.org/gradle/dist-snapshots/gradle-script-kotlin-3.3-20161123161139+0000-all.zip

4. Configura el settings.gradle para que use los scripts correctos

Ahora, en lugar de utilizar de utilizar los archivos build.gradle, tendrá que usar los build.gradle.kts, así que necesitas modificar el settings.gradle a lo siguiente:

def configureGradleScriptKotlinOn(ProjectDescriptor project) {
    project.buildFileName = 'build.gradle.kts'
    project.children.each { configureGradleScriptKotlinOn(it) }
}

include 'app'

configureGradleScriptKotlinOn rootProject

5. Crea el build.gradle.kts raíz y configúralo

Verás que la apariencia es muy similar a la de un script escrito en Groovy:

buildscript {
    repositories {
        jcenter()
        gradleScriptKotlin()
    }

    dependencies {
        classpath("com.android.tools.build:gradle:2.2.0")
        classpath(kotlinModule("gradle-plugin"))
    }
}

allprojects {
    repositories {
        jcenter()
        gradleScriptKotlin()
    }
}

Una ventaja interesante es que no necesitamos especificar la versión de Kotlin. Es capaz de inferirla de la versión del plugin instalado.

6. Crea el build.gradle.kts para el módulo app

Este es un poco más complicado, y es donde creo que aún les falta por simplificarnos un poco la tarea.

Primero, porque hay que crearse unas cuantas funciones de extensión para que siga siendo tan legible como sería en Kotlin. Esas funciones deberían estar incluidas en algún momento dentro del propio plugin.

Y segundo, porque nos obliga a prácticamente reescribir el mismo buildscript que el del fichero raíz, cosa que no es necesaria con Groovy.

Eliminando un poco la parte boilerplate (puedes ver el archivo completo aquí), nos quedaría algo así:

apply {
    plugin()
    plugin()
}

android {
    buildToolsVersion("25.0.0")
    compileSdkVersion(25)

    defaultConfigExtension {
        setMinSdkVersion(15)
        setTargetSdkVersion(25)

        applicationId = "com.example.kotlingradle"
        versionCode = 1
        versionName = "1.0"
    }

    buildTypesExtension {
        release {
            isMinifyEnabled = false
            proguardFiles("proguard-rules.pro")
        }
    }
}

7. Ejecuta el proyecto

No sé si es posible, pero hasta la fecha no he sido capaz de ejecutar el proyecto usando Android Studio. Necesitarás ejecutarlo mediante terminal:

./gradlew installDebug

Ahora empieza la magia

Usando Kotlin Script ahora verás, por ejemplo, que el autocompletado funciona perfectamente:

O que, cuando escribimos algo de forma incorrecta, el IDE nos informa:

Estos pequeños detalles nos ahorrarán mucho tiempo cuando estemos implementando los scripts de Gradle.

Puedes ver el proyecto completo y descargarlo en el repositorio de ejemplo.

¿Qué te ha parecido Kotlin Script?¿Crees que marcará un antes y un después en la creación de scripts de Gradle, o que se seguirá usando Groovy como hasta ahora? Cuéntanos en los comentarios.

• En Genbeta Dev | Kotlin: La Máquina Virtual de Java tiene un nuevo aliado
• Más información sobre Gradle y Kotlin

También te recomendamos

Kotlin desde el punto de vista de un desarrollador Groovy

Cómo conseguir que a tu bebé le gusten las verduras (y más cosas)

Kotlin: La Máquina Virtual de Java tiene un nuevo aliado

-
La noticia Kotlin llega a Gradle: Escribe tus scripts de Gradle usando Kotlin script fue publicada originalmente en Genbeta Dev por Antonio Leiva .

Los desarrolladores somos los nuevos hechiceros de la sociedad. Condenados a estudiar de manera constante y diaria, a causa de nuestra inagotable ansia de conocimiento. Y orgullosos de construir sistemas que se implantan y utilizan en todo tipo de escenarios; a lo ancho, largo, alto y profundo de nuestro mundo (y más allá).

Es decir, los desarrolladores hacemos que muchas cosas funcionen gracias a nuestra capacidad intelectual; recibiendo a cambio, una invaluable dosis de satisfacción cuando nuestras criaturas – paridas con dolor y sufrimiento – llegan a producción y se utilizan.

Por eso llama poderosamente la atención la cantidad de tiempo que se puede perder – y se pierde – en estériles discusiones entre profesionales, que llevan a los extremos la defensa de sus ideas.

Ego y prepotencia

Prácticamente todos podemos reconocer que alguna vez el ego y la prepotencia nos ha cegado y hemos caído en una defensa numantina basada en que nuestro conocimiento es superior y no hay resquicio para que nadie pueda saber de algo que no conozcamos aún mejor.

Alguno de los síntomas que indican que estamos metidos en esta dinámica es el tomarnos a mal cualquier opinión contraria, por leve que sea, a la que tenemos plena certeza; el uso común de las palabras siempre y nunca “yo nunca he hecho eso” como argumento suficiente para dar por zanjado un debate; contestar siempre con una coletilla de valoración personal del contrario “solo los ignorantes pueden pensar así”; que nos escueza en la boca del estómago el que alguien “te pille” en un renuncio, error u omisión; u olvidar rápidamente el motivo del debate para convertirlo en una batalla personal.

La noticia buena es que esto se cura con autocrítica e intentando corregirnos cuando nos reconocemos alguna de las señales de que el ego nos está llevando a la prepotencia.

Menosprecio por desconocimiento

Algunas veces aseguramos cosas con rotundidad, basándonos en la confianza de lo que sabemos. Es más, algunas veces es obligatorio hacerlo así para trasmitir “expertise”.

Pero siempre hay mucho más de lo que conocemos, y es fácil caer en el menosprecio de otras opiniones a causa de nuestro propio desconocimiento.

De forma desesperante, cuanto menos sabemos y más nos creemos que sí, más despreciamos las opiniones de los demás y entramos en comportamientos que harían hacer perder la paciencia al Santo Job.

Un ejemplo sería el encontrarse a clientes o compañeros que no tienen idea de programar y que “se atreven” a opinar sobre temas técnicos. Lo que produce, en la mayoría de los casos, un rechazo especialmente virulento, en donde no hay resquicio para intentar descubrir cuál es el mensaje que intentan hacernos llegar.

O, siendo un referente de alguna comunidad técnica, algún “mindundi” se mete en el fregado de ir en contra de nuestra opinión, encontrándose el inconsciente con descalificaciones personales no solamente por el “Guru”, sino además por el jaleo continuado de los palmeros de turno.

En ambos ejemplos, nos olvidamos que todos somos ignorantes en casi todas las cosas relacionadas con nuestra profesión, y que la inmensa mayoría repetimos lo que otros han diseñado, descubierto o construido.

Es decir, aquí no hay gurús y, como mucho, tuertos en tierra de ciegos.

Este tipo de actitudes son muy complejas de corregir porque no somos conscientes de todo lo que nos falta por conocer, porque no tenemos paciencia para darnos cuenta de lo que podemos aprender y, porque al creernos realmente que sabemos más que nadie, nos enganchamos a esa sensación dulce de superioridad y reconocimiento. Siendo, como toda buena droga, muy duro darte cuenta de que “eres mortal”.

Talibanismo y Fanboismo

Ambos términos tratan sobre la defensa radical, emocional e irracional de una idea o conocimiento (tecnológico en este caso). Siendo el fanboismo lo mismo pero relacionado a una marca comercial.

La característica principal que señala que hemos caído en esta estéril posición, es el uso profuso y continuado de tres tácticas de discusión:

• “No hay mejor defensa que un buen ataque”. Nada más empezado el combate, ya que así lo vemos cuando estamos en estas posturas irracionales, se entra a atacar de forma inmisericorde la calidad profesional, técnica, personal y todo lo que sea necesario, de nuestro enemigo. Casi todo vale y, en caso extremo, entramos en una dinámica “Hater”.

• “Y tú más”. Da igual que estemos discutiendo sobre un agujero de seguridad del tamaño de una catedral, o prácticas monopolísticas deplorables: el enemigo es mucho peor y es culpable. Lo que hace, milagrosamente, que la crítica a nuestro objeto de defensa se diluya y desaparezca.

• “Al enemigo ni agua”. No se quiere ni vencer, ni convencer. Se quiere destruir al enemigo. Por lo cual el dicho de “se ve más la paja en el ojo ajeno que la viga en el propio”, se lleva a proporcionas monstruosas. Y las acusaciones de traidor, vendido y – a su vez- de talibán y fanboy, se suceden de forma reiterativa y cada vez más ofensivas.

Por alguna razón, casi siempre la discusión está a punto de finalizar cuando se llega a los términos tan manidos de “derechos” y/o “fascismo”.

Este tipo de actitud, en la informática, comúnmente las corrige el tiempo y la dura realidad de que no hay “pepitas de oro” que siempre estén indemnes e impolutas. Y más, porque casi siempre las marcas o tecnologías, siguen su camino sin importarle lo más mínimo las opiniones de los defensores de la pureza extrema.

La ley de la jungla en las redes sociales

Si añadimos gasolina a un fuego, lo más seguro es que acabemos más que chamuscados y con un incendio de proporciones preocupantes.

Algo parecido sucede cuando ejercemos o sufrimos cualquiera de las actitudes anteriores en una red social. Sea Facebook, listas de correos, foros, chat o el rey de los “flame”: twitter.

Lo que empieza como una diferencia de opiniones, escala rápidamente a un maremágnum de insultos cada vez más gruesos, a donde se van uniendo de forma entusiasmada hordas de contrincantes, palmeros, trolls y haters.

En menos de lo que canta un gallo, decenas o cientos de mensajes, llenos de muy mala baba, cruzan el ciberespacio, olvidado el fondo del asunto y – sobre todo – las formas.

Y es que la comunicación en la red está basada en el espejismo del lenguaje políticamente correcto. Lo que es difícil de cojones (un ejemplo de lo que no es), y resultando extremadamente fácil herir cualquier susceptibilidad de los receptores del mensaje.

Resulta complicado escribir una opinión en una red social sin que alguien se sienta ofendido, molesto o enfadado por alguna parte o la totalidad de lo afirmado. Porque, ante la duda y aún con la ayuda de los smiles, siempre entenderemos lo negativo, nunca lo positivo.

Al igual, es un deporte con altas recompensas para nuestro ego, el encontrar de forma inevitable aquellas opiniones a las que hacerle aclaraciones, puntualizaciones e ironías. Con más o menos elegancia, a muchos nos encanta enmendar la plana o demostrar que somos los que más sabemos.

Incluso, si no es ese el espíritu de la respuesta y realmente queremos aportar nuestro punto de vista o experiencia que pueda enriquecer un debate que nos gusta, hay una gran posibilidad de que sea entendido como una actitud prepotente, directamente proporcional a la egolatría de los lectores del hilo.

Por supuesto estoy dejando fuera de toda duda el que no pertenecemos a ninguno de los dos grupos realmente dañinos en las redes sociales:

• Los Haters, u odiadores. Que lean lo que lean, lo retuercen para atacar con todo su odio a su contrincante/enemigo.
• Los troll. Personas profundamente desequilibradas que disfrutan y se nutren de poner de los nervios a todas las personas participantes en una conversación. Consumiendo y nutriéndose con avidez de los insultos recibidos, y regodeándose en el desprecio que producen.

Conclusiones

Si eres lector habitual de GenbetaDev, te habrás percatado que no estoy escribiendo en primera persona, como es habitual, sino en la segunda persona del plural. Porque, he de reconocer que, como participante asiduo en redes sociales, en algún momento he vivido y he actuado de todas y cada una de las actitudes descritas.

Y mi amarga conclusión es: no vale la pena.

Hay que tener la mente clara y fría antes de entrar en un debate que se pueda convertir en una discusión. No es normal que se traspase lo límites del ciber espacio, pero cuando ocurre se pierden amistades y relaciones en el mundo real. Y eso es un precio muy alto a pagar por una discusión que, casi siempre es efímera y banal.

O sea, en mi caso, que es el único en donde me atrevo a dar consejos, una autocrítica constante y tratar de contar hasta diez antes de lanzar una contundente y descarnada respuesta o crítica, es el único camino que veo para dejar de estar metidos en “Saraos” que me drenan tiempo de una forma absurda.

¿Tú qué piensas?

También te recomendamos

Resolvamos las grandes disyuntivas del mundo del desarrollo

Cómo conseguir que a tu bebé le gusten las verduras (y más cosas)

10 cosas sobre trabajar en remoto que quizá no habías pensado y deberías tener en cuenta

-
La noticia Comunicaciones agresivas en la Red, una pérdida de tiempo fue publicada originalmente en Genbeta Dev por Juan Quijano .

Poder realizar queries como si de una base de datos MongoDB se tratase pero hasta 100 veces más rápidas y con las ventajas de una base relacional. Esto es lo que propone el reciente lanzamiento de ToroDB Stampede. Simplificando el stack de ToroDB nos encontramos con una base de datos NewSQL, es decir, una base de datos que intenta proporcionar las funcionalidades y características de las bases de datos NoSQL, principalmente escalabilidad, sin renunciar al ACID de toda la vida de una base de datos relacional.

Viendo el ecosistema actual de base de datos, siempre nos ha llamado la atención la centena o miles de ellas que existen y sus diferentes protocolos. Lanzar una nueva base de datos es siempre complejo. Aquí está la primera aclaración sobre ToroDB, en lugar de implementar un nuevo protocolo y un sistema de queries propio, incompatible con el resto de sistema, la gente de ToroDB ha decidido implementar el mismo protocolo de MongoDB.

Dicho esto, cualquier desarrollador que esté usando MongoDB en sus sistema puede empezar a usar ToroDB sin mayor problema. Quizás sea buen momento de probarlo mediante ToroDB.

Y en las capas inferiores donde persistir los datos, una vez más, en vez de implementar un sistema propio se ha utilizado PostgreSQL. Tal como nos explican desde ToroDB, tener una arquitectura desacoplada permite que en el futuro se puedan implementar otros protocolos, distintos de MongoDB o de persistir en Oracle, DB2, etc..

¿Cómo funciona ToroDB?

ToroDB funciona como un nodo secundario oculto del clúster de MongoDB que replica todos los datos y sus actualización a una base de datos Postgres en tiempo real. Creando de este modo una estructura relacional para poder consultarlos a partir de una colección de documentos MongoDB.

Los cuatro pilares sobre los que se basa ToroDB son:

• Transacciones ACID en un entorno de trabajo MongoDB, es decir NoSQL, con todo lo que ello conlleva.
• Ecosistema SQL accesible que no teníamos si sólo usamos NoSQL. Al persistir en una base de datos relacional, se pueden utilizar herramientas de BI, Backup o administración que hoy por hoy no están en NoSQL.
• Velocidad de consulta. Gracias a la persistencia sobre Postgres podemos resolver queries complejas que hasta ahora MongoDB requería más tiempo.
• Facilidad de migración de NoSQL a SQL. Hasta ahora no era sencillo migrar de un sistema a otro. Con ToroDB se puede utilizar los conocimiento y los recursos de ambos sistemas.

ToroDB Stampede y ToroDB Core son productos open source y su código está disponible para descarga en nuestro repositorio de GitHub. Cuenta con una licencia AGPLv3, una de las licencias de software libre llamadas "virales" porque obligan a que todo el software integrado cuente también con una licencia AGPL.

Entrevista a Álvaro Hernandez Tortosa, CEO de ToroDB:

Tenemos la oportunidad de charlar con Álvaro Hernandez Tortosa para que nos cuenta más en detalle algunos aspectos de ToroDB. A continuación las preguntas de la entrevista que le realizamos antes de lanzamiento. Cualquier duda adicional seguro que podemos gestionarlo en los comentarios de este mismo post.

GENBETA DEV: El estado del arte de las bases de datos es inmenso ¿Por qué empezasteis por MongoDB, en lugar de otras noSQL como Casandra, por ejemplo? ¿Y por qué Postgres? ¿Qué os llamó más la atención en cuanto a ellas ¿Cuota de mercado? ¿Rendimiento? ¿Ecosistema?

ÁLVARO: Con respecto a la compatibilidad con MongoDB. Las bbdd NoSQL cada una han decidido crear su propio API, su propio interfaz al usuario. Esto ha creado una gran fragmentación en el mercado, confusión al usuario y dificultad de migración. De hecho, es probablemente un factor determinante que hará desaparecer a muchas bbdd NoSQL "pequeñas" porque crea una barrera de entrada. En ToroDB hemos optado por no inventar un interfaz nuevo, y sufrir esos mismos problemas, sino reutilizar uno ya existente. En este sentido, hemos buscado el líder del mercado, el más popular, el más utilizado, para favorecer la adopción. Y este es MongoDB.

En cuanto a Postgres (o PostgreSQL). Necesitábamos como base una bbdd relacional, sólida, fiable, extensible y software libre. Nadie dudaría en contestar "PostgreSQL" a esos requisitos. Además de ello, 8Kdata tiene un muy gran expertise en PostgreSQL, de más de década y media, y somos miembros relevantes de la comunidad mundial y fundadores de PostgreSQL España, el 5º PUG (Postgres User Group) mayor del mundo. Por lo tanto es una mezcla de las características de Postgres (en particular su extensibilidad) y nuestra experiencia con esta base de datos.

GENBETA DEV: Partimos del escenario más sencillo: somos desarrolladores que ya usamos MongoDB en nuestras aplicaciones ¿Qué deberíamos hacer para empezar a usar ToroDB? ¿Qué pasos y acciones tenemos que tener en cuenta?

ÁLVARO: En primer lugar el lanzamiento de ToroDB Stampede 1.0 beta, que va orientado tanto a realizar queries analíticas/BI/Data Warehousing de Mongo como a migrar de MongoDB a relacional. Su funcionamiento es muy sencillo: Stampede se comporta como un nodo más del replica set de MongoDB. Tan pronto se instale, configure (opcionalmente) y lance, comenzará a replicar desde 0 todos los datos que haya en el replica set, y continuará haciéndolo en tiempo real según se vayan insertando más datos en MongoDB.

Los datos, en Stampede, serán analizados, transformados de json a un diseño relacional, con tablas, columnas, relaciones, etc, como si lo hubiera diseñado un dba (decimos que ToroDB crea el DDL automágicamente). Y una vez ahí, se podrá conectar directamente y hacer queries sobre los datos en SQL puro, con un rendimiento para queries agregadas que puede ser 100 veces mayor que en MongoDB.

GENBETA DEV: Gestionar un proyecto Open Source no es trivial ¿Cómo suele ser el proceso de aceptación de PR al proyecto de ToroDB? ¿Cómo dáis visibilidad a esas colaboraciones? ¿Cómo estáis llevandolo o cómo tenéis pensado plantearlo para que encaje con vuestro Roadmap?

ÁLVARO: Estamos encantados de recibir contribuidores. El primer paso es, idealmente, comunicarse con nosotros a través de la lista de correo de desarrolladores para discutir qué se quiere hacer y qué dirección seguir. A partir de ahí, crear un parche, enviar un PR y el equipo de ToroDB lo evaluará. Todos los PR aceptados mantienen completamente la autoría del contribuidor y ToroDB garantiza que dicha contribución será software libre para siempre. Los contribuidores serán además listados en los release notes.

En cuanto al encaje con el Roadmap, las contribuciones son, sin duda, también feedback, y pueden alterar nuestro roadmap, al igual que las issues en Github. El encaje lo haremos en un análisis caso por caso, porque depende de muchos factores, como el porcentaje de contribución del contribuidor, cómo de nuclear sea la característica y nuestros propios recursos. Pero en general, si la contribución es beneficiosa para una mayoría de los usuarios , tenemos una política muy abierta y colaborativa hacia las mismas.

• Más información | ToroDB Stampede
• 8KData Blog | Announcing ToroDB Stampede 1.0 beta

También te recomendamos

Cómo conseguir que a tu bebé le gusten las verduras (y más cosas)

UnQL, un lenguaje de consulta unificado para todas las bases de datos NoSQL

Una introducción a MongoDB

-
La noticia ToroDB Stampede, toda la potencia de una base de datos NoSQL en un entorno relacional mucho más eficiente fue publicada originalmente en Genbeta Dev por Txema Rodríguez .

Actualmente el número de herramientas a disposición de los equipos de desarrollo para probar software es muy amplio. Para cualquier tipo de prueba que queramos realizar (funcionales, rendimiento, regresión, etc.) el número de opciones disponibles, tanto gratuitas como comerciales, es muy grande. De entre todas estas he elegido 12 herramientas imprescindibles para probar software (y sus alternativas).

En unos casos son programas desarrollados para probar software. En otros, son programas que aunque no nacieron con ese propósito, han demostrado ser perfectos para realizar determinadas pruebas.

Hemos decidido incluir al menos una alternativa a cada uno, para que podáis comparar y elegir cual es la opción que mejor se adapta a vuestro caso.

SoapUI - Postman

SoapUI pertenece a las herramientas que nacieron para probar software. Está desarrollada en Java, y se utiliza para pruebas funcionales de APIs y servicios web. SoapUI tiene una versión gratuita de código abierto, y una versión de pago con algunas funcionalidades que hacen que sea mucho más productiva. Se trata de una opción absolutamente madura, cuya primera versión es de septiembre de 2005. Prácticamente imprescindible para los expertos en pruebas sobre APIs.

SoapUI tiene muchas funcionalidades interesantes: Permite crear conjuntos de pruebas tan complicados como queramos, analizar la cobertura de tests sobre nuestro servicio SOAP o REST, cambiar el entorno de pruebas de forma rápidamente, crear mocks a partir de un WSDL o incluso facilitar ciertas pruebas de seguridad.

La alternativa a SoapUI es Postman, mucho más popular entre los desarrolladores que SoapUI. Postman nos permite construir y gestionar de una forma cómoda nuestras peticiones a sevicios API REST.

Apache JMeter - HP LoadRunner - Octoperf

Apache JMeter y HP LoadRunner son 2 de los mejores programas para realizar pruebas de rendimiento y stress. JMeter es de código abierto y se puede descargar gratuitamente. Se utiliza para generar un gran volumen de carga que nos permita analizar y medir el rendimiento de aplicaciones web.

Load Runner es la alternativa para pruebas de rendimiento de HP. Existe la opción de utilizar LoadRunner en versión SaaS, de forma gratuita con su Community Edition, y ver de esta forma si es la herramienta adecuada para nosotros, sin ningún coste.

Una tercera opción para pruebas de rendimiento, también como SaaS es Octoperf. Basándose en JMeter, han creado una herramienta que no necesita de ninguna instalación y que nos permite crear escenarios, monitorizar nuestros entornos, ejecutar pruebas y analizar los resultados desde un mismo punto.

Sonarqube - Kiuwan

Sonarqube es una de las utilidades más populares para realizar análisis estático de código. Es open source, por lo que en principio es gratuito. Eso si, tendremos que instalarlo en una máquina, y mantenerlo actualizado. Además, determinados plugins son de pago, como por ejemplo el plugin para analizar código Swift, que cuesta 5.000 euros al año por instancia de Sonarqube.

Kiuwan es otro analizador estático de código, pero en este caso se trata de un servicio que podemos usar para analizar nuestro código sin preocuparnos por instalaciones ni actualizaciones. Podemos subir nuestro código a la nube para analizarlo, o descargar una aplicación que analizará nuestro código localmente y subirá los resultados a Kiuwan. Tanto Sonarqube (sonarlint) como Kiuwan tienen integración con distintos IDEs, que nos permiten detectar incidencias en nuestro código mientras lo escribimos, sin tener que esperar a análisis posteriores. También en ambos casos existen plugins para herramientas de integración continua como Jenkins.

Sonarlint para IntelliJ

Wget - Curl

Se trata de 2 programas que permiten descargar contenido de servidores web. No son utilidades de testing propiamente, pero dadas sus múltiples posibilidades, se usan habitualmente en combinación con otras para realizar ciertas tareas durante las pruebas, como por ejemplo simular las acciones de usuarios.

La principal característica diferenciadora de wget es su recursividad, que permite usarlo como una araña web que extrae enlaces de las páginas web y los descarga, repitiendo el proceso recursivamente hasta que todas las páginas han sido descargadas, o hasta que se haya alcanzado en nivel de repetición máxima especificado por el usuario. Curl por su parte tiene como ventajas el estar disponible para prácticamente cualquier plataforma, el tener una libreria con un API, soportar muchos más protocolos (SCP, SFTP, TFTP, TELNET, LDAP(S), FILE, POP3, IMAP, SMTP, RTMP y RTSP) y además permitir subir o enviar archivos.

Charles - Fiddler

Charles y Fiddler son 2 aplicaciones que se utilizan como proxy para hacer debug web o para capturar el tráfico de sesión de dispositivos móviles. Permiten capturar y grabar tráfico http/https, obteniendo información muy importante para nuestras pruebas. Fiddler cuenta con una versión totalmente funcional de forma gratuita, mientras que Charles dispone de una versión de prueba de 30 días, pero después necesitaremos comprar una licencia.

Sus utilidades son múltiples y, además de para capturar el tráfico de nuestra aplicación móvil, también podemos capturar tráfico http/https que después podemos utilizar para crear nuestras pruebas de rendimiento con Octoperf.

Greenshot - Jing - Shutter

A la hora de comunicar errores o comportamientos que no son correctos, una imagen claramente vale más que mil palabras. Sobre todo porque los desarrollos nunca van sobrados de tiempo, y si podemos evitarnos teclear una sola palabra de más, mejor. Es por eso que, un buen programa que nos permita tomar pantallazos de un área de la pantalla específica, o de una ventana, y destacar ciertos elementos o escribir notas, es muy importante.

Greenshot es una muy buena opción, pero sólo está disponible para Windows. Cuenta con un editor que nos permite, entre otras cosas, ofuscar determinadas áreas, para ocultar determinados elementos, recortar, añadir efectos, rotar imágenes, añadir textos, destacar áreas, o incluso añadir un efecto lupa sobre las zonas sobre las que queremos llamar la atención.

Imagen capturada con Greenshot y con diferentes efectos

Jing tiene 2 cosas que la hacen muy interesante: Disponible para Windows y Mac, y permite grabar vídeos de hasta 5 minutos (en formato flash (.swf)). Por último, para quienes trabajen con Linux, mi recomendación es Shutter.

Beyond compare - Kdiff3

A la hora de comparar archivos hay muchas opciones. Podemos simplemente necesitar comparar 2 archivos de texto con notepad++, o podemos comparar 2 archivos para ver si son exactamente iguales o no. Beyond Compare nos permite comparar archivos o carpetas, incluso archivos Microsoft Word o PDF, y realizar comparaciones de archivos byte a byte para asegurarnos de si son o no exactamente iguales. Además está disponible para Windows, Mac y Linux. Eso si, a partir de un cierto número de usos tendrás que pasar por caja (30$ la versión standard).

Una alternativa interesante y gratuita es Kdiff3. Está disponible para Windows, Mac y Linux y entre sus funcionalidades están el poder comparar 2 o 3 archivos de texto o directorios, y la posibilidad de combinar archivos de forma automática, o a través de su editor integrado.

Crashlytics - Testfairy

Estas 2 herramientas nos permiten distribuir versiones beta de nuestras aplicaciones para iOS y Android y extraer información de las pruebas que hagan nuestros testers.

Crashlytics nos permite distribuir nuestra aplicación, y además obtener información muy detallada de lo que los usuarios hacen. Testfairy, también facilita distribuir nuestra aplicación entre nuestros testers, acceder a logs, obtener feedback de los usuarios, grabación en vídeo de lo que hacen los usuarios e informes de error cuando la aplicación se rompe.

Si queremos una tercera opción, Appsee incluye muchas de las funcionalidades de las 2 anteriores. Además permite grabar en video sesiones de usuarios, para poder ver como utilizan la aplicación exactamente. Otra funcionalidad interesante es la de los mapas de calor de las zonas de toque, indicativos de las áreas dónde más atención ponen nuestros usuarios:

Mapas de calor de toques

Jenkins - Travis CI

Jenkins y Travis CI son 2 de las opciones más interesantes en cuanto a servidores de integración continua, aunque hay más opciones como TeamCity, CircleCI y Bamboo.

En cuanto a las diferencias, entre Jenkins y Travis CI, una de las más importantes es que Travis es un servicio en la nube (salvo la versión Enterprise, que se puede alojar en nuestra infraestructura), mientras que en el caso de Jenkins nosotros tenemos que alojar esa máquina, mantenerla y actualizarla. Otra diferencia es que Jenkins es gratuito, y Travis es de pago, salvo para proyectos Open Source. El funcionamiento también es diferente, puesto que en Jenkins configuramos jobs para realizar tareas, mientras que con Travis los comandos los especificamos en un archivo que está junto con nuestro código (archivos .travis.yml).

Nightwatch.js - Webdriver.io

En cuanto a frameworks para automatización de pruebas, he elegido 2 opciones que funcionan sobre Node.js, Nightwatch.js y Webdriver.io. Los 2 nos van a permitir escribir pruebas que utilizarán Selenium Webdrver para realizar comprobaciones en sitios y aplicaciones web, pudiendo utilizar para ello distintos navegadores web. El código, como veis en el siguiente ejemplo, es bastante asequible:

Ejemplo de Nightwatch.js

Tanto Nightwatch.js como Webdriver.io incluyen un runner que nos permite lanzar las pruebas desde nuestro sistema de integración continua. También pueden integrarse con otros aplicativos,como appium, para pruebas en dispositivos móviles.

La principal diferencia, a favor de Webdriver.io es que cuenta con una utilidad qu nos permitirá configurar nuestro proyecto simplemente respondiendo a algunas preguntas.

Easy Test Setup

HP Quality Center - Jira - Redmine

A la hora de gestionar las pruebas, HP Quality Center se puede considerar la opción estándar (si el presupuesto lo permite). Incluye gestión de requisitos, gestión de pruebas, gestión de defectos, paneles con métricas y mucho más. Forma parte de HP Application Lifecycle Management, relativamente habitual en grandes corporaciones.

Otra opción que podemos utilizar para gestionar nuestras pruebas es Jira. Simplemente con Jira, creando diferentes tipos de tareas y subtareas, o bien con plugins como Zephyr, tendremos gestión de requisitos, gestión de pruebas, gestión de defectos y paneles con informes, utilizando una herramienta que es bastante habitual en los equipos de desarrollo.

Redmine está más enfocada en equipos de QA. Es un software para la gestión de proyectos que incluye un sistema de seguimiento de errores. Redmine destaca por ser software libre y de código abierto, disponible bajo la Licencia Pública General de GNU.

mRemoteNG - MobaXTerm - RoyalTS

Por último voy a hablar de mRemoteNG, para mi, software de uso intensivo a diario. mRemoteNG es una aplicación que permite conexiones a equipos remotos. Soporta lo siguientes tipos de conexión: RDP (Remote Desktop), VNC (Virtual Network Computing), ICA (Independent Computing Architecture), SSH (Secure Shell), Telnet (TELecommunication NETwork), HTTP/S (Hypertext Transfer Protocol) y Rlogin (Rlogin). Podemos tener conexiones a diferentes tipos de máquinas, a las que nos conectaremos simplemente haciendo doble click. Además, podremos tener abiertas las conexiones que queramos en diferentes pestañas. Eso si, sólo disponible para windows. MobaXTerm es una alternativa a mRemoteNG muy interesante. Permite conexiones SSH, Telnet, Rlogin, RDP, VNC, XDMCP, FTP, SFTP o sesiones por puerto serie. Esta opción también, sólo disponible para windows. Una de las cosas más interesantes es la opción de multi ejecución, que permite ejecutar los mismos comandos en diferentes servidores, con sólo escribir una vez.

Por último, una opción para Windows y Mac, y para dispositivos iOS y Android es [RoyalTS](https://www.royalapplications.com/ts/osx/features).

Cada uno de estos programas da para varios artículos, y lo que hemos hecho no es más que una breve presentación. Si quieres saber más de alguna en concreto, o crees que alguna de ellas tiene alguna otra alternativa interesante, déjanos un comentario, y le dedicaremos un artículo.

También te recomendamos

Cómo conseguir que a tu bebé le gusten las verduras (y más cosas)

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

FlowUp, cómo monitorizar el rendimiento de tus aplicaciones Android e iOS

-
La noticia 12 herramientas imprescindibles para asegurar la calidad del software (y sus alternativas) fue publicada originalmente en Genbeta Dev por Raúl Hernández .

Recientemente se celebró Codemotion Spain 2016, el evento anual de desarrollo más multitudinario del territorio nacional, por segundo año consecutivo en el campus Montepríncipe de la Universidad San Pablo CEU de Boadilla del Monte, Madrid. Como no podía ser de otra manera, algunos editores y colaboradores de Genbeta Dev estuvimos por allí. Servidor entre ellos (obviamente, si no de qué iba a estar escribiendo este post) y estos son algunos apuntes, pensamientos y dudas que me suscitó dicho evento.

No reinó el caos, ergo éxito

Un evento de dos días con miles de asistentes y más de un centenar de charlas y talleres y que no terminé como el rosario de la aurora, sumido en un caos digno de 'El Señor de las Moscas', ya es en si mismo un éxito. Así que lo primero es darle, una vez más, enhorabuena al equipo de Codemotion por su encomiable labor.

Los "uniformes" están de moda

Empezó Tuenti (siguiendo el ejemplo de Facebook y demás totems del Valle, para variar) y ahora le siguen todos. De Beeva a Idealista pasando por Paqlink, Liferay, Lastminute.com o Jobandtalent (y muchas comunidades no relacionadas con empresas también). Sin tu camiseta corporativa no eres nadie y lo sabes.

¡Viva la diversidad!

No todo es web y apps, apps y web, en Codemotion. El monopolio va cediendo y este año hemos visto charlas de cloud, robótica, inteligencia artificial, big data, bots... Algunas charlas muy técnicas y otras más divulgativas e incluso inspiradoras (o por lo menos eso pretendían, que luego cada uno verá si consiguió inspiración o no). Así sí. Por cierto, aquí la agenda completa con sus slides y vídeos correspondientes.

¿Dónde está PHP?

Uno de los grandes damnificados de esta diversidad ha sido PHP: tan sólo un par de charlas entre todos los tracks (y había 8, más cuatro talleres). ¡Pero es que ni siquiera ha sido el foco principal de las bromas en las demás charlas! Ese honor ha sido este año para los frameworks de Javascript y su imparable y alocado florecimiento. Un nuevo orden.

Faltan mujeres, eso es así

Más mujeres entre los ponentes y entre los asistentes que otros años (y que otros eventos), sí, pero pocas todavía. Hubo incluso cierto polémica que se dio en llamar GenderGate. Harían bien desde la organización en "darle una pensada" a la situación. Y ya están en ello, que en esta edición ha habido una mesa redonda de título '¿Cómo acabar con la brecha de género en Tecnología?' en la que profesionales del sector como Laura Lacarra o Eva Mosquera.

#MargaretHamilton"symbolizes that generation of unsung women who helped send humankind into space." —@POTUShttps://t.co/QDA7exXkIHpic.twitter.com/E4PL2CykPU

— MIT (@MIT) 23 de noviembre de 2016

Un poco de brainstorming: ¿Track sólo con ponentes femeninas? ¿Regalar entradas a chicas developers en universidades e institutos? ¿Intentar traer a alguna desarrolladora top internacional (no hace falta que sea Margaret Hamilton, eh)? Opciones hay muchas, estas y otras, pero algo hay que hacer porque el tamaño y la visibilidad de Codemotion así lo exige.

¿Es buena idea puntuar las sesiones?

Una novedad de esta edición ha sido la posibilidad de puntuar y comentar las charlas. Una oportunidad muy buena tanto para que el ponente reciba buen feedback que le haga progresar como para que el troll de turno se desahogue. Sí, hay que registrarse y sí, había ciertas normas, pero ¿de verdad es una buena idea? Yo no estoy muy seguro, la verdad. Y menos si las puntuaciones son "por estrellas".

Es un congreso, no un concurso, ni un ranking. Seguro que hay otras maneras de dar feedback a los ponentes más discretas y menos susceptibles de trolleo (por ejemplo buzones de sugerencias, formularios de contacto...).

¿Momento para rotar?

Al ser una marca con ramificación internacional, no se como de "libres" están los organizadores de Codemotion Spain para innovar e introducir cambios pero, una vez asentado el evento en Madrid (consiguiendo incluso unas instalaciones bastante apañadas, lejanas pero apañadas), es posible que sea un buen momento para visitar otras ciudades donde la comunidad developer también es amplia (Barcelona, Bilbao, Sevilla, Valencia...), ya sea con ediciones propiamente dichas o con spin-offs más pequeños que se compaginen con el evento principal.

Y hasta aquí mis cuitas y reflexiones. Los comentarios están abiertos por si estuviste allí y quieres dejarnos tus impresiones. También nos interesa que si lo seguiste vía streaming, nos cuentes que tal (que no tenemos feedback ahora mismo). Bueno, que carallo, si ni fuiste ni lo seguiste por streaming también nos interesa conocer tu opinión.

Imágenes | Codemotion en Flickr En Genbeta Dev | Todo lo que hemos escrito sobre Codemotion Más info | Codemotion 2016

También te recomendamos

Cómo conseguir que a tu bebé le gusten las verduras (y más cosas)

Large-scale Scrum, multas por no cumplir la normativa sobre cookies y hackers éticos: Pull Request #12

Otro compilador PHP para el bote: Recki-CT

-
La noticia Codemotion Spain 2016: apuntes, reflexiones y cuestiones varias fue publicada originalmente en Genbeta Dev por Fernando Siles .

Las APIs más populares que utilizamos a día de hoy son RESTful APIs o un pseudo estándar ad hoc HTTP inventado bajo demanda en ciertos proyectos. La necesidad de avanzar más rápido en productos cada vez más complejos, más allá de un simple CRUD, ha empujado un cambio en la forma en que interactuamos con las APIs. Aquí es dónde surge GraphQL, un fuerte candidato a sustituir a REST, sobre todo en el ecosistema de APIs para apps en mobile.

¿Qué hay de malo en REST? Nada en su concepción inicial y en el contexto dónde surgió, pero desde que fuera definido la forma de interactuar con las APIs ha cambiado. Vamos a repasar las razones por las que deberíamos repensar las tradicionales APIs basadas en RESTful en favor de GraphQL.

RESTful APIS versus GraphQL APIs

Obviamente las APIs REST han sido uno de los puntos determinantes para el auge del desarrollo de apps y de servicios distribuidos, tal como lo conocemos actualmente. Son “el pegamento” que no puede faltar en cualquier app.

REST es un claro caso de éxito, pero su concepción CRUD basada en resources, verbos y códigos de respuesta HTTP denotan cada vez más sus limitaciones y su inflexibilidad.

Principales debilidades de RESTful

En RESTfulutilizamos una URI para leer o escribir un único recurso, ya sea, por ejemplo, un producto, una persona, un post o un comentario. Si necesitamos trabajar con múltiples recursos como un listado de posts con un listado de comentarios, necesitamos manejar múltiples endpoint y encadenar distintas llamadas, a veces de forma secuencial. Es en las apps donde recae la responsabilidad de unir y mergear cada recurso.

¿Cuántas veceas os habéis encontrado con la tediosa tarea de “pintar” una pantalla con la información procedente de 4 o 5 endpoint diferente? Por ejemplo, solicitar los ids de los comentarios de un post concreto para luego pintarlos en la misma pantalla junto a él. Aquí por ejemplo, necesitamos una request al detalle del post, a las estadísticas del post, al listado de comentarios, etc… después juntar toda esa información.

Cuando hacemos una request, no recibimos simplemente la información que necesitamos, sino todo el conjunto de datos relativos al resource alojado en esa URI. Algo bastante complicado de gestionar y costoso en recursos cuando el 90% de los datos procedentes de cada resource/endpoint son innecesarios. Por ejemplo, si solo queremos obtener el nombre de una persona al hacer la consulta recibiremos datos como, por ejemplo, su fecha nacimiento o su profesión. Datos innecesarios que desde el lado cliente no podemos controlar y entorpecen la obtención de información necesaria.

El versionado de una API REST no es trivial. En muchas ocasiones necesitamos añadir nuevos campos o modificar el tipo de alguno de ellos pero para poder dar soporte de retrocompatibilidad los incluimos en el payload que los clientes viejos, lo cual hace crecer el payload de respuesta innecesariamente. O bajo otra estrategia, desde el lado del servidor gestionamos “vistas distintas” según la versión del cliente que consume el recurso. A veces eso nos lleva a innumerables if, codigo spagetti que poluciona el código original de respuesta.

Todos conocemos los verbos HTTP involucrados en las peticiones RESTful pero eso no asegura su correcta utilización. Ni mucho menos de sus códigos error basados en HTTP. Hay una decena de ellos representados a lo largo de las diversas categorías de 2XX, 3XX, 4XX o 5XX. Incluso algunos de ellos han ido surgiendo bajos las necesidades, pero no se utilizan de forma homogénea (a veces de forma laxa y poco estricta).

Por supuesto, las respuestas de error con el payload que reciben los clientes no se quedan atrás en la incoherencia de muchas APIs REST que consumimos. No hay una especificación que lo fije. Lo cual requiere que cada API necesite ser acompañada de una documentación para el desarrollador, corriendo el riesgo de ser incompleta, desactualizada o violada sin previo aviso desde la parte del servidor.

Para aliviar las idas y venidas obteniendo datos de un endpoint a otro muchos desarrolladores se lanzan al acuerdo explícito entre backend y mobile de crear sus propias APIs adhoc. Una pseudo mezcla del RESTful más estricto en algunos endpoint a un libertinaje de payload que componen vistas saltándose uno de los principales reglas de RESTful.

Lo que parece una buena solución puede convertirse en un auténtico quebradero de cabeza de mantener polucionado todo de código duplicado, abstracciones y la recurrente deficiente retrocompatibilidad. Los clientes que utilizan estos custom endpoint no pueden romper el contrato implícito fijado con lo que al final es imposible eliminar campos y los nuevos deben ser añadidos, aunque los consumidores ni los utilicen.

Con endpoint creados bajo el libre albedrío de una API custom, adhoc no tiene un sistema formalizado de tipos perdiendo la potencia de herramientas como Swagger para documentar o gRPC para crear idiomatic client apis.

¿Por qué utilizar GraphQL en nuestras APIs?

GraphQL es una de las alternativas que han surgido para solucionar la mayor parte de estos problemas arriba descritos con API REST.

El primer borrador del RFC (aún en desarrollo) que especifica GraphQL fue creado por Facebook. Tal como ellos mismo explican llevan usándolo y perfeccionandolo desde 2012 en sus apps móviles. Y no son los únicos, también Github, Pinterest o Shopify se han unido al carro. Todos los interesados en implementar GraphQL pueden colaborar en su definición, es Open Source.

GraphQL es un protocolo agnóstico y no depende en nada de HTTP. No usa métodos o respuestas HTTP. Por supuesto, sigue siendo el canal más popular para comunicarse entre consumidores de GraphQL.

Unas de las principales características de GraphQL es que el lenguaje y sintaxis usado en la request es el mismo que el de la respuesta. Analizando el JSON podemos comprender claramente el diccionario de key-value. Simplificando su uso podríamos decir que es un lenguaje pregunta/respuesta expresada en relaciones entre los objetos expuestos. Además GraphQL dispone de un sistema de tipado fuerte por el que cualquier mal uso puede ser rápidamente detectado en tiempo de desarrollo (incluso desde el IDE) en contraposición a un mapeo clásico de JSON.

Otro de sus principales rasgos es que la API puede ser single endpoint. Es decir, un único endpoint puede manejar sin problemas las peticiones de los clientes. Todas ellas puede preguntar sobre múltiples recursos y campos, tan sólo indicando qué necesitan. La respuesta será acorde a esta demanda de información, ni más ni menos.

Estas son algunas de las razones que hacen GraphQL eficiente, efectivo y fácil de usar. Pero su principal razón de ser es cambiar la concepción hasta ahora utilizada alrededor de los clientes móviles bajo un modelo Declarative Data Communication.

Los cliente móviles necesitan tener más poder de decisión sobre los datos que necesitan consumir. Esto les provee de mayor independencia sobre los servicios de datos. Las queries son enviadas desde el cliente lo que simplifica la retrocompatibilidad explícita.

Debemos evitar en la medida de los posible los clásicos viajes de datos entre cliente y servidor para componen ciertos datos requeridos para componer un vista única. El diseño GraphQL permite manejar jerarquías de objetos para componer las vistas que necesitemos de ellos, según los requisitos solicitados por el cliente.

Ejemplo de API GraphQL frente a una API tradicional REST. Creando una app sobre Starwars

Para comprender las diferencias entre API REST y GraphQL hay un excelente ejemplo utilizando la API de Starwars de personajes para construir una pequeña aplicación que consuma información de ambas APIs.

Aquí tenéis cada una de ellas para trastear por vuestra cuenta:

• API REST: SWAPI

• API GraphQL: SWAPI GraphQL Wrapper

Vamos a imaginar la vista de una app que pretender representar la ficha de los personajes de Starwars que muestran básicamente estos campos: * Nombre del personaje * Fecha de nacimiento * Lugar de nacimiento * Películas en las que aparece

Utilizando la API REST necesitaremos componer la vista con las siguientes request y sus correspondientes response:

• Obtenemos la información del personaje, por ejemplo, Luke Skywalker

people/1

{
    "name": "Luke Skywalker",
    "height": "172",
    "mass": "77",
    "hair_color": "blond",
    "skin_color": "fair",
    "eye_color": "blue",
    "birth_year": "19BBY",
    "gender": "male",
    "homeworld": "http://swapi.co/api/planets/1/",
    "films": [
        "http://swapi.co/api/films/6/",
        "http://swapi.co/api/films/3/",
        "http://swapi.co/api/films/2/",
        "http://swapi.co/api/films/1/",
        "http://swapi.co/api/films/7/"
    ],
    "species": [
        "http://swapi.co/api/species/1/"
    ],
    "vehicles": [
        "http://swapi.co/api/vehicles/14/",
        "http://swapi.co/api/vehicles/30/"
    ],
    "starships": [
        "http://swapi.co/api/starships/12/",
        "http://swapi.co/api/starships/22/"
    ],
    "created": "2014-12-09T13:50:51.644000Z",
    "edited": "2014-12-20T21:17:56.891000Z",
    "url": "http://swapi.co/api/people/1/"
}

• Información de su lugar de nacimiento

planets/1/

{
    "name": "Tatooine", 
    "rotation_period": "23", 
    "orbital_period": "304", 
    "diameter": "10465", 
    "climate": "arid", 
    "gravity": "1 standard", 
    "terrain": "desert", 
    "surface_water": "1", 
    "population": "200000", 
    "residents": [
        "http://swapi.co/api/people/1/", 
        "http://swapi.co/api/people/2/", 
        "http://swapi.co/api/people/4/", 
        "http://swapi.co/api/people/6/" 
    ], 
    "films": [
        "http://swapi.co/api/films/5/", 
        "http://swapi.co/api/films/4/"
    ], 
    "created": "2014-12-09T13:50:49.641000Z", 
    "edited": "2014-12-21T20:48:04.175778Z", 
    "url": "http://swapi.co/api/planets/1/"
}

• Películas en las que ha participado (n peticiones por cada película)

films/6/

films/3/

films/2/

films/7/

films/1/

films/6/

Después de combinar estas 6 respuestas JSON procedentes del servidor podremos satisface los datos requeridos por la vista. Anotamos dos grande problemas: el número de request/response diferentes que debemos que manejar y la cantidad de datos innecesarios que recibimos sin necesitarlos en el payload de la respuesta.

Por otro lado, utilizando el ejemplo de API GraphQL vamos obtener esos mismos datos.

Como comentábamos en el artículo, somos capaces de seleccionar los datos que queremos obtener. Básicamente podemos a partir del esbozo de datos de los requisitos de nuestra pantalla podemos construir la siguiente query de GraphQL:

/graphql?query={...}

{ 
  person(personID: 1) { 
    name 
    birthYear 
    homeworld { 
      name 
    } 
    filmConnection { 
      films { 
        title 
      } 
    } 
  } 
}

Lo que recibimos de respuesta se asemeja completamente a nuestra petición rellenando los valores de cada campo, tal que así:

{
  "data": {
    "person": {
      "name": "Luke Skywalker",
      "birthYear": "19BBY",
      "homeworld": {
        "name": "Tatooine"
      },
      "filmConnection": {
        "films": [
          {
            "title": "A New Hope"
          },
          {
            "title": "The Empire Strikes Back"
          },
          {
            "title": "Return of the Jedi"
          },
          {
            "title": "Revenge of the Sith"
          }
        ]
      }
    }
  }
}

Una de las herramientas más potentes que dispone GraphQL es GraphiQL, un sandbox para hacer consultas a la API aprovechando su carácter fuertemente tipado que nos ayuda a construir las queries y descubrir semánticamente los campos y relaciones disponibles.

Este artículo sólo ha sido una introducción a GraphQL. Nuestra intención ha sido hacer una comparación entre las tradicionales APIs REST y GraphQL.

Por supuesto, tenemos que adentrarnos en la implementación de GraphQL en backend y el ecosistema de librería, tools que dispone y sobre todo su relación con Relay y React en próximos artículos. Si queréis conocer más sobre el proyecto la web oficial de GraphQL mantenida por Facebook contiene gran cantidad de recursos.

También te recomendamos

Interoperabilidad en el siglo XXI

Cómo conseguir que a tu bebé le gusten las verduras (y más cosas)

Pop, el motor de animaciones de Paper, liberado por Facebook

-
La noticia¿Por qué deberíamos abandonar REST y empezar a usar GraphQL en nuestras APIs? fue publicada originalmente en Genbeta Dev por Txema Rodríguez .

La última semana de Noviembre estuve en Fort Lauderdale, Florida, en la conferencia G3 Summit en la que dí dos charlas. Se trata de la primera edición de una conferencia centrada en Groovy, Grails y Gradle, y organizada por el mismo equipo que se encargaba de la SpringOne 2GX. Debo admitir que Miami es un muy buen lugar para organizar una conferencia a finales de Noviembre. Pasar de los 8ºC y la lluvia de Madrid a los más de 25ºC y el sol de Miami es algo de agradecer.

La agenda incluía más de 50 charlas y a los principales líderes de los distintos proyectos del ecosistema Groovy. En G3 Summit estuvieron presentes tanto Graeme Rocher, líder del proyecto Grails como Jeff Brown, co-fundador del mismo framework; Guillaume Laforge líder de Groovy o Ken Kousen de Groovy Podcast y autor del libro Making Java Groovy.

Talleres y charlas

Durante la conferencia asistí a un workshop, tres keynotes y ocho charlas y en general todas fueron buenas. De ellas, mis favoritas son:

Build Web Applications with Ratpack

Empecé la conferencia con el workshop de Dan Woods sobre Build Web Applications with Ratpack. Dan, además de ser miembro del equipo de Ratpack ha escrito el primer libro sobre el framework: Learning Ratpack.
El workshop me encantó: muy bien estructurado con pequeños fragmentos de código que había que completar y tests ya preparados que servían para probar que todo era correcto. Además de muy buenas explicaciones por parte de Dan y también buena gestión del tiempo entre los distintos ejercicios. La verdad es que en ocho horas de workshop dio tiempo a ver muchos aspectos distintos de Ratpack y probar en profundidad distintas opciones y formas de resolver los problemas.
Si alguien está interesado en el workshop está disponible en el github de Dan.

High Performance Groovy

Una de las mejores charlas que he visto en mucho tiempo sobre problemas de rendimiento, pitfalls y gotchas a evitar cuando se trabaja con Groovy y, en algunos casos, también con Java. David Clark hizo un gran trabajo explicando con muchos ejemplos y con gran detalle distintos aspectos que debemos tener en cuenta cuando desarrollamos aplicaciones Groovy. Me quedo con:

• Utiliza Java 8 si puedes. El rendimiento de Groovy en Java 8 ha mejorado mucho.
• Cuidado con el boxing/unboxing, puede afectar mucho al rendimiento. En este caso se trata de un problema de Java y no sólo de Groovy.
• Abuso de dispatch dinámico. Si tu código realmente no es dinámico es mejor anotarlo con @CompileStatic, la diferencia de rendimiento puede ser muy grande, especialmente si el código es CPU-bound.
• Si tu código tiene IO (acceso a disco, base de datos, red,...) da igual que sea dinámico o no, apenas se va a notar la diferencia de rendimiento porque todo el tiempo lo vas a gastar esperando por la latencias del disco o la red.

Finalmente terminó la charla mostrando algunas herramientas que podemos utilizar para diagnosticar problemas de rendimiento. Comentó que la mejor con diferencia es YourKit aunque VisualVM también ofrece buenos resultados.

Todo el código mostrado en la charla está disponible en este repositorio de Github en el que también se incluyen las slides

Functional Programming for Groovy Programmers

Si alguna vez estás en una conferencia y tienes la oportunidad de ver a Venkat Subramaniam no lo dudes, no te defraudará. Venkat es un gran speaker que sabe cómo mantener la atención de los asistentes durante toda la charla y tiene una gran facilidad para explicar y transmitir sus conocimientos.
En esta ocasión hizo una introducción a la programación funcional, las ventajas, distintas aproximaciones que tenemos en Groovy,... La charla fue realmente buena y fiel al estilo que Venkat nos tiene acostumbrados: sin utilizar slides, sólo una lista de temas de los que hablar y código, muchos ejemplos de código con los que dejó muy claros todos los conceptos.
Es una pena que no se grabara porque merecería la pena verla de nuevo con más calma.

Groovy Puzzlers S03 – The Unstoppable Puzzlers Hit Again!

La charla más divertida de la conferencia. En esta ocasión Baruch Sadogursky con ayuda de Guillaume Laforge presentaron la tercera edición de los Groovy Puzzlers. Para el que no lo conozca la idea surgió hace tiempo con una charla en la JavaOne por Joshua Bloch y Neal Gafter en la que mostraban fragmentos de código Java y daban diversas opciones a la audiencia sobre cual era la respuesta o comportamiento correcto.
En este caso se trataba del mismo planteamiento pero con Groovy en lugar de Java. Para cada fragmento de código había cuatro posibles opciones y una vez que los asistentes votaban se mostraba la solución correcta. Entre los que habían acertado la respuesta debían tratar de explicar el por qué para ganar una camiseta. Debo admitir que esta era la tercera vez que veía la charla pero fue igual de divertida y entretenida que las veces anteriores ya que nunca logro recordar las respuestas de una vez para otra.

Dockerize your Grails!

Esta fue mi primera charla. En ella hablé de los distintos problemas que tenemos al desarrollar aplicaciones Java, en particular centrándome en Grails, y expuse tres problemas:

• El entorno de desarrollo no es el mismo para todo el equipo de desarrollo.
• Los entornos de desarrollo y producción son muy diferentes.
• Los problemas cuando tenemos un nuevo miembro en el equipo y el tiempo que tarda esta persona en empezar a ser productiva.

Después de esta introducción presenté Docker como la solución a estos problemas. Di un repaso a los conceptos básicos, expliqué las diferencias entre una máquina virtual y Docker y enseñé pequeños ejemplos de cómo se puede utilizar Docker.
Finalmente llegó el momento de las demos. Había preparado una aplicación muy sencilla pero que tenía diversas partes móviles en la arquitectura. La aplicación tenía una aplicación Grails que se encarga de producir un mensaje de texto, otra aplicación Grails que recibía dicho mensaje de texto por medio de RabbitMQ y finalmente daba la vuelta al mensaje y lo almacenaba en una base de datos Postgresql. Con esta sencilla aplicación pude mostrar cómo podíamos utilizar Docker para resolver los tres problemas comentados anteriormente.

Todo el código se encuentra en este repositorio y las slides son:

Taking advantage of Groovy Annotations

Para mi segunda charla me centré en todas las tranformaciones que nos ofrece Groovy. Como desarrolladores debemos aprovecharnos de todas las características y ventajas de nuestro lenguaje de programación y Groovy proporciona una gran cantidad de anotaciones que nos hacen la vida más fácil al desarrollar. Después de explicar las distintas categorías y numerosas transformaciones hice una demo creando desde cero una sencilla transformación AST para añadir un campo VERSION a una clase. La idea era demostrar cómo es posible crear nuestras propias anotaciones para poder solucionar ciertos problemas que de otra forma serían más complicados de resolver.

El código de esta transformación así como los tests están disponibles en este repositorio y las slides aquí:

La comunidad Groovy

La comunidad Groovy no es demasiado grande por lo que después de haber asistido a unas cuantas conferencias de Groovy y haber dado charlas en ellas conozco a mucha gente. Esta conferencia me ha servido para reencontrarme con viejos amigos que hacía tiempo que no veía y conocer gente nueva. Además también ha servido para que todo el equipo de Grails de OCI nos reuniéramos por primera vez :)

Me gustaría agradecer a los organizadores de la conferencia por su trabajo porque ésta ha sido estupenda. Se notaba que el equipo de NFJS se había encargado de todos los detalles: comidas, salas, breaks, wifi,... Todo funcionó sin ningún problema.

En cuanto a las charlas, además de las que he destacado todas me parecieron buenas y con un muy buen nivel por parte de los speakers. El único aspecto negativo (por comentar algo) son las 9 horas y 30 minutos de avión desde Madrid a Miami, aunque eso es algo que no tiene fácil solución... ;-)

Conclusión

Me llevo tres ideas y cosas a mirar con más detalle para el futuro porque seguro que en el ecosistema Groovy van a seguir dando de que hablar:

• Grails: Obviamente conozco Grails en detalle pero no deja de sorprenderme todo lo que ha avanzado el framework durante el último año: grandes mejoras de rendimiento, distintos perfiles para integrarse con Angular 2 o React, GORM 6 con soporte para Hibernate 5, MongoDB, Neo4j y Cassandra, y un largo etcétera de mejoras. Merece la pena seguir todas las novedades para no quedarse atrás.
• Ratpack: Después de haber estado un día completo en el workshop me parece una pasada lo que el equipo de desarrollo de Ratpack está haciendo. Ahora que todo parece que tiene que ser microservices, reactive y asíncrono creo que Ratpack va a tener mucho que decir y aportar durante el próximo año a la hora de desarrollar ciertos proyectos en la JVM.
• Groovy: Por supuesto el tema central de la conferencia era Groovy ya que en la mayoría de los casos es el nexo común que tienen el resto de herramientas y frameworks. Groovy sigue evolucionando y ya se está trabajando en Groovy 3.0 con su nueva gramática, el nuevo Meta Object Protocol (MOP), soporte para Java 9 y gran cantidad de mejoras.

Hay gente que dice que Groovy está muerto pero conferencias como está no hacen más que demostrar que se equivocan.

También te recomendamos

Nueve anotaciones de Groovy que te harán la vida más fácil al desarrollar

Mejora tu código Java usando Groovy

Cómo conseguir que a tu bebé le gusten las verduras (y más cosas)

-
La noticia Groovy está bastante vivo, conferencias como la G3 Summit lo demuestran (resumen y opinión) fue publicada originalmente en Genbeta Dev por Iván López .

Partiendo de cuatro aseveraciones, que se clarifican con doce principios, la industria del desarrollo de software lleva casi dos décadas en medio de una revolución de los procesos productivos, a la búsqueda de implantar las filosofías y metodologías Agiles.

Algo que, como bien conoce todo aquel que tenga experiencias personales de este tipo, es especialmente difícil conseguir que funcione correctamente. Incluso si nos decantamos por un framework tan abierto y generalista/ambiguo como pude ser SCRUM.

Además, hay que abarcar una complejidad creciente en la aplicación de este manifiesto, al desarrollarse a su alrededor una miríada de procesos, buenas prácticas y metodologías que se muestran como un impedimento de primer orden para llegar a buen puerto con la adopción Agile.

Fundamentos

Cuatro simples frases que comprenden un universo de sentido común y experiencia aplicado a la construcción de software. Cuatro profundas declaraciones que recuerdan, de forma constante, donde está el valor.

Cuatro declaraciones sencillas, y desde las cuales se ha creado un gigantesco mapa de principios, valoraciones, interpretaciones, prácticas, mejoras, evoluciones y puntualizaciones.

Cuatro comparaciones de valor, que debieran ser la medida sobre las que debiéramos dilucidar las dudas que surjan sobre la adopción de Agile en nuestros procesos de construcción.

A partir de estos fundamentos, el manifiesto Agile describe 12 principios que son normas de aplicación de los procesos agiles en nuestros equipos de desarrollo. Incluyendo en ellos, toda la experiencia atesorada por profesionales y metodologías ya reconocidos en el momento de la redacción del propio documento.

Y ya está, cuatro fundamentos junto con doce principios y una metodología – más bien framework – como Scrum, y es todo lo que necesitamos para adoptar el Agilísimo en nuestro equipo.

Pero no es así…

PBI, o el principio del infierno

Olvidémonos del principal problema que nos encontramos cuando queremos aplicar una metodología Agile como Scrum, que no es otro que la práctica inexistencia del Product Owner o Dueño del Producto. Por lo cual el fundamento de “Colaboración (cercana) con el cliente” se queda en agua de borrajas en demasiados casos, emergiendo figuras parcialmente supletorias como los proxy.

Y ahora centrémonos más en técnicas específicas como son los PBI (Product Backlog Items), artefactos que vamos a utilizar para construir nuestra Pila de Producto en donde se segmentará el valor que espera el cliente, de forma priorizada.

La aproximación es relativamente sencilla: vamos a construirlo por medio de Historias de Usuario. Pequeñas cartulinas o post-tip, en donde utilizaremos la fórmula de las 3 C’s: Card, Conversation y Confirmation

Es decir, la primera C la cubro en el formato clásico de: Cómo tal, Quiero hacer…, Porqué/Para que me aporte este valor... La segunda ce sería el cuerpo de la documentación en donde almacenaría todos los recordatorios de la conversación en cualquier formato que me sea útil. Y la tercera significa que debo dejar claros los criterios de aceptación que van a permitir dar por válida la realización de la Historia de Usuario.

También debo de estar seguro que mis Historias de Usuario cumplen con el acrónimo de INVEST: Independiente, Negociable, Valiosa, Estimable, Pequeña (Small) y Testeable; para asegurarme que son correctas y útiles en su función de describir cada requisito.

Y, además, debo de poder priorizarla por el valor que aporta (Product Owner) y por estimación (Develop Team) para poder comprometer un número dado de PBI’s en cada sprint.

Esto significa que el equipo de Scrum debe de conocer técnicas de estimación Agiles, como puede ser Wall, Triangulación o similares, que permiten hacer estimaciones iniciales de un gran número de PBI.

Aplicando a su vez, técnicas de estimación específicas para el sprint planning, como es el Planning Poker. Que son mucho más lentas, a cambio de obtener estimaciones bastante más afinadas, siguiendo lo esperado en un gráfico de cono de incertidumbre.

Pero volvamos con nuestras Historias de Usuario y veremos cómo las podemos mejorar. Aplicando técnicas de Desing Thinking lograremos una construcción más completa de nuestros PBI, incluyendo prácticas como los storyboards, story telling, mapas de empatía, pitch elevator y una miríada más.

¿Y si la historia de usuario es muy grande? ¡No hay problema! Utilizaremos agrupaciones por medio de Historias de Usuario Épicas o también Features. Que, ojo, a su vez tiene su técnica para ser subdivididas de forma eficaz. Eso sí, apliquemos el concepto Lean de evitar el Waste y solo poner foco en lo que aporte Valor, y breguemos con tareas no funcionales o con bugs que deben de aparecer en algún lado, pero no en el Product Backlog… ¿o sí?

Como es inevitable, en este punto nacen diferentes escuelas para abordar este tipo de disyuntivas de procesos que, en realidad, al cliente se la traen al pairo. Pero son críticas para el equipo de desarrollo.

Así vemos que algo tan simple como una lista ordenada de tareas, en la realidad se ha convertido en un artefacto complicado de construir y mantener de forma eficiente en los proyectos Agiles; tanto por el trabajo a tiempo completo que requiere durante todo el proyecto, como por el abanico de conocimientos que parece de obligado estudio.

Y sin tener en cuenta todas la técnicas psicológicas, sociológicas y tecnológicas que existen para el proceso de captura y diseño del producto. Entre las que nos encontramos con el reconocido brainstorming, el foco en la pregunta, los 5 Porqué, las 5 E’s, Descubrimiento por Hipótesis, MVP, y un largo etc.

De la mejora continua al coaching

Vamos un paso más allá, y hemos arrancado nuestro Scrum. Tenemos un Product Backlog y un Product Owner, listos para empezar a trabajar, y arrancamos nuestro sprint con todas las liturgias asociadas a framework.

Pero uno de los objetivos clave de Agile es establecer un marco de mejora continua en donde, al final de cada iteración, el equipo sea capaz de detenerse, reflexionar, sacar conclusiones y comprometerse a realizar acciones. Es decir, la retrospectiva.

Pues bien, hay suficientes técnicas de esta liturgia, que podríamos escribir existen multiples libros dedicados totalmente a cómo aplicar de forma eficiente esta reunión en el transcurso del proyecto. Así te encuentras con técnicas como la de “Estrella de Mar”, “Barco de Vela”, “6x3x5”, “Mad, Sad, Glad”, “Positivo, Negativo, Delta, Flor”, “Esqueleto de Pescado”, Timeline”, etc.

Incluso podemos ir varios pasos más allá, muy “Lean”, en donde entramos en medidores de la felicidad del equipo, del departamento o de la empresa. Con propuestas tan sencillas como puede ser un calendario Niko-Niko y sus caritas emocionales.

Y con la filosofía y el psicoanálisis hemos topado. De forma gradual pero consistente se ha implantado el uso de conceptos filosóficos y de mejora continua proveniente de procesos industriales y empresariales para aplicarlos en ámbitos mucho más allá de la mera construcción del software, origen de todo este tinglado, abarcando la cultura de la empresa en su globalidad y la vida diaria en lo más personal e íntimo.

Hemos visto surgir profesionales en técnicas de coaching (el entrenador, en roman palantino), llenándonos la cabeza y los sentimientos de buenos propósitos y deseos de mejora.

Verdaderos guías que nos acompañan en el camino para llegar a un éxito inaplazable, y que han convertido conceptos de crecimiento como “Kaizen” o metodologías cual “Lean”, en el centro neurálgico imprescindible de alcanzar, para poder aplicar de forma correcta y emergente los principios Agiles.

Por supuesto, los libros y conocimientos necesarios se van acumulando, los cursos se suman los unos a los otros, y las certificaciones cierran el circulo al validar el conocimiento y experiencias adquiridas.

Del tablero al universo “Kanban”

Una de las herramientas más conocidas del mundo Agile es el tablero Kanban, en su vertiente Scrum. Una forma visual de describir el flujo de trabajo, el estado de las tareas, de los bloqueos que existan o puedan existir, y de los puntos de mejora en el ciclo.

En definitiva una forma muy eficaz de auto organización y colectivización de la información.

Debería ser suficiente con un tablero físico, dibujar cuatro columnas, subdividir y priorizar las tarjetas con la descripción simple del trabajo a realizar para cada PBI comprometido durante la iteración actual, un visión u objetivo del sprint, y tener muy claro el concepto de Done que permite asegurar el finalizado un trabajo.

Pero ya que estamos, podemos añadir las capacidades push & pull del movimiento de las tarjetas, la subdivisión, el WIP o la división horizontal, para obtener un tablero “Kanban” más rico y con más capacidad de mostrar el flujo.

Y aún más, aplicar las técnicas “Just In Time” que desarrolló Toyota hace décadas (primera descriptora de la metodología Kanban), en nuestro proceso de desarrollo; y terminar siguiendo los siete principios de la versión occidental llamada “Lean”:

• Eliminar los desperdicios
• Ampliar el aprendizaje
• Decidir lo más tarde posible
• Reaccionar tan rápido como sea posible
• Potenciar el equipo
• Crear la integridad
• Véase todo el conjunto

Los cuales -a su vez- se complementan con múltiples prácticas, que también han ido evolucionando en el tiempo de la misma forma que ha ganado complejidad en su entendimiento, aplicación y uso.

Escalando Scrum y usando otras metodologías

Es cierto que Agile, y en especial Scrum, están orientado a equipos pequeños de alto rendimiento, experiencia y calidad técnica. Pero desde hace años se está aplicando a proyectos grandes, en donde decenas de personas deben participar en los trabajos.

Así surgen metodologías que han evolucionado el framework para que pueda funcionar, más o menos deformado, en estas circunstancias.

Scrum of Scrum, Scaled Agile Framework (SAFe), Large Enterprisse Scaled Scrum (LeSS) o Disciplined Agile Delivery (DAD), abordan las complejidades inherentes de escalar procesos que fueron diseñados, inicialmente, para equipos y proyectos perqueños.

Además, debemos de tener en cuenta que también existen metodologías Agiles más allá de Scrum, que son más concretas y que plasman los principios Agiles de una forma mucho más detalla.

Tenemos Extreme Programming (XP) pone mucho el foco en el desarrollo y en los desarrolladores. Haciendo natural utilizar técnicas como la programación en parejas o el desarrollo guiado por pruebas (TDD) para que emerja la arquitectura de manera orgánica y se limite la complejidad.

También tenemos DSDM, que es una metodología “pesada” Agile. Es decir, describe todos y cada uno de los procesos que se han de implantar, de forma detallada y con el objetivo de conseguir una empresa Agile.

Nacida en los años 90 por un consorcio de actores en el desarrollo de Sistemas de Información, añade conceptos orientados a la gestión del riesgo, la estimación y la presencia de la parte de negocio empresarial, para complementar y enriquecer una construcción Agile de proyectos.

O Crystal Clear, conjunto de metodológico que va cambiando de color según el tamaño del equipo, y de color según la criticidad de los errores. En ella se pone al equipo humano como centro de todo y se va incrementando la complejidad en los procesos según va creciendo el volumen de personas participantes.

Sin olvidar FDD (Featuren-Drive Development), también pensada y diseñada para equipos grandes o sin madurez suficiente de auto organización, en donde se describen cinco procesos que (hay que reconocerlo) son de lo más realista y pragmático de entre las metodologías Agiles.

Es cierto que para los que estamos acostumbrados a Scrum o “Scrum But” nos rechina una figura similar a un “Jefe de Proyecto” o a un Arquitecto, pero es otra aproximación salvaguardando los fundamentos y principios de Agile.

Propuestas de solución:

A todo este conocimiento, que debiera tener aprendido e interiorizado los equipos de trabajo, debemos añadirle la complejidad creciente del desarrollo de software.

Una carrera en donde continuadamente el profesional debe encontrar -casi a ciegas- cuál es el punto justo de equilibrio entre lo conocido y lo novedoso. Qué ventajas ofrecen los nuevos framework que aún está de moda, en comparación con el código aburrido, consistente y confiable con el que podemos abordar nuestras construcciones.

Y que, a su vez, implica que debiéramos estar permanentemente reciclándonos y aprendiendo en un torbellino constante que deja tiempo para muy poquitas cosas, cuidadosamente priorizadas.

Lo cual todo, junto con lo mucho que se ha quedado fuera del artículo, está significando que el grado de implantación positiva de Agile en las empresas esté siendo inferior a las previsiones que se tenían hace unos pocos años.

Arrancar con muchos bríos, pero con una enorme cantidad de normas, preceptos, filosofías, técnicas, prácticas y actividades, es un buen camino hacia el desastre o – aún peor – la inutilidad.

Tal vez, una buena propuesta sea aplicar a rajatabla el viejo concepto de los años 60: KISS (Keep It Simple Stupid).

Aplicando las liturgias de Scrum en su forma más básica y de forma iterativa de acuerdo a la madurez del equipo; revisando sobre los cuatro fundamentos del manifiesto, si realmente es necesario ganar un gramo de complejidad en pos de una mejora; y, en caso de nuevas adopciones en los procesos, estar plenamente justificadas y comprendidos los porqué.

Buscando un Coach, empecemos por acostumbrar al equipo a trabajar con un tablero físico Scrum (tareas y sprint), luego introduciremos las retrospectivas para que emerja la mejora continua; la Pila de Producto será imprescindible rápidamente para que el equipo pueda iniciarse en la auto organización; y todo ello debiera desembocar en las liturgias del Sprint Review y el Sprint Planning.

Si no ves claro algo o es dificultoso, como puede ser estimar por puntos, empieza por horas ideales (que es imperfecto y produce disfunciones); recuerda que lo importante no es la técnica, si no entender por qué estimar, cuando (si es necesario) y de qué manera.

No entres en otros conceptos hasta que tengas pleno dominio de los fundamentos y principios Agiles. Ya habrá tiempo para mejorar, y las retrospectivas te van a ir llevando a ello.

Reflexiona sobre que lo que menos valor aporta son los procesos y herramientas; que ser un especialista en Thinking Design es una gran ventaja en un nivel de madurez y adopción Agile medio, pero que lo verdaderamente importante es describir el trabajo con el detalle mínimo suficiente como para que el equipo de desarrollo se pueda auto organizar.

Funciona, a pocos, pero funciona

La pregunta que me hacen muchas veces es: ¿Pero es posible? ¿Funciona? Y la respuesta es un rotundo “depende”.

Si aplicas una metodología muy experimentada y madura como Scrum, tienes más posibilidades ciertas de conseguirlo. Lo difícil es continuar poniéndolo en práctica una vez que el coach o el tutor se haya alejado del proyecto. Demasiadas veces nos devora el día a día, los plazos y los costes, perdiendo el foco en lo importante que es seguir aplicando los fundamentos Agile al desarrollo de software.

Pero sí que hay empresas, muy pocas en comparación con la generalidad, que aplican metodologías Agiles y les funciona; construyendo equipos altamente motivados, y por ende productivos.

La pena es que aún hay más que, o no quieren salirse de sus procesos (o no-procesos), o las que lo intentaron, pero las dificultades en su implantación y continuidad de uso, las llevaron a fracasar y a no querer volver a “meterse en jaleos”.

Sin duda la complejidad de un crecimiento expansivo de los conocimientos necesarios para aplicar “bien” Agile, se ha convertido en el mayor hándicap para su implantación. Por ello tal vez el camino sea el abordarlo desde la simplicidad y la reflexión continua sobre los cuatro fundamentos.

Ir poco a poco.

En GenbetaDev | Retos de la agilidad en empresas grandes, Modelos de aprendizaje para el programador ágil ¿Cómo ser efectivo en nuestro aprendizaje constante?, DevOps. ¿Moda, mito o evolución?

Imagen de portada | Deloitte

También te recomendamos

Ser ágil es algo más que iterar

La necesidad de las pruebas en las metodologías ágiles

Cómo conseguir que a tu bebé le gusten las verduras (y más cosas)

-
La noticia¿La sobreingeniería de procesos puede llevar al fracaso las metodologías Agile? fue publicada originalmente en Genbeta Dev por Juan Quijano .