Facebook Twitter LinkedIn Google+ Contacto English Version excentia

Artículos de opinión

martes, 7 de junio de 2016

Barcelona AtlasCamp 2016 - Irrepetible (o no)


La semana del 23 de mayo tuvo lugar en Barcelona la edición 2016 del AtlasCamp, evento que reúne a todo aquel relacionado con las herramientas de Atlassian y su ecosistema de add-ons.

Como no podía ser de otra manera, estuvimos allí, por partida doble, como Atlassian Experts por ser proveedor de servicios y como Marketplace Vendor como proveedor de algunos add-ons.

La edición fue excelente, tanto la ubicación como la organización fueron perfectas. Un entorno idílico para compartir experiencias e informarse de las novedades de los productos de Atlassian. Algo irrepetible en España.

El primer día fue "solo" para Atlassian Experts, donde se nos revelaron muchas cosas a nivel interno y que poco después se hicieron públicas durante el resto de días y a lo largo del tiempo. Entre ellas las tan esperadas certificaciones así como algunas novedades de productos (Portfolio 2.0 para JIRA).

No hay sitio mejor que este para reunir a todos los fanáticos de Atlassian

Y ya a partir del martes pusieron toda la carne en el asador, os dejo un resumen de lo que creo que fue lo más importante:

BitBucket Pipelines

Ya disponible en versión Beta. Fue una grata sorpresa para todos, aunque aún queda ver cómo avanzará y se posicionará este producto. Parece que de un plumazo quieran "quitarse" de encima a los sistemas de integración continua, directamente ofreciendo los pipelines para Continuous Delivery dentro de BitBucket.

Todo en un mismo sitio (código + automatización). Veremos que tal funciona.

Apps para JIRA y Confluence en Cloud

Pues si, directamente desarrolladas por Atlassian (y por ahora solo disponibles para instancias de JIRA y Confluence en Cloud). Todo el poder de JIRA y Confluence en tu bolsillo.

Una actriz, Jessica Alba, fue la que inspiró a Atlassian para decidirse por crear las aplicaciones móviles. Desde luego, no es para menos, con una embajadora así cualquiera se sentiría inspirado.


Edición colaborativa en Confluence (oh yeah!)

Si, si, si, como lo oyes. Por fin puedes editar páginas en Confluence con muchos usuarios a la vez, y se ve como cada uno va añadiendo/cambiando lo que se edita. Genial.

Para mi fue una de las cosas más importantes. Esperemos que con esto sea aún más ágil documentar y colaborar en Confluence.

Si quieres conocer todos los secretos no te pierdas este video.



APIs y más APIs para productos Atlassian

No podía faltar una buena ración de APIs para sacar provecho a todos los productos y para poder integrar y desarrollar nuevos add-ons. Concretamente se presentaron:

  • La API REST para JIRA Service Desk, es el momento de extender la funcionalidad de Service Desk.
  • HipChat Connect, para crear addons de Hipchat en Cloud.
  • Nuevas APIs para Confluence, para crear macros y extensiones de páginas y temas visuales.
  • Nuevas extensiones en JIRA Connect, destacando Issue Fields para añadir nuevos campos en JIRA Cloud (por fin, nos acercamos a algo parecido a los Custom Fields en modo Cloud).
  • Marketplace API, para "consumir" todos los detalles y crear tus propios informes personalizados para tener el control de todo lo que ocurre con tus productos. 
  • El anuncio de la colaboración con Open Api Initiative 
  • Y muchas, muchas más cosas internas...

Developers Breakouts (experiencias en desarrollo de add-ons)

Sin duda de lo más interesante es poder compartir las experiencias de desarrollo con el resto de "Vendors" y de Atlassian Experts. Que mejor momento que después de comer para tener sesiones rápidas con desarrolladores y que cuenten de primera mano lo que les ha llevado al éxito o lo que más dolores de cabeza les ha producido.

Desde problemas encontrados para migrar addons de server a cloud hasta técnicas para potenciar las ventas de un determinado addon o ejemplos de stacks de tecnologías para empezar a trabajar en cloud.

Muy muy concentradas pero muy muy útiles.

Irrepetible... (o no)

Ya sé que es difícil de transmitir por aquí pero he de decir que fueron tres días apasionantes y que es espectacular poder estar rodeado de los mejores expertos de Atlassian así como compartir experiencias entre desarrolladores. Es algo increíble.

Poder hablar con los creadores de los addons de Kepler (quién no los ha utilizado), con Bob Swift (si, el mismisimo), con toda la gente de AppFire, con Adaptavist (potenciando ScriptRunner y preparándolo para Cloud tras adquirirlo), de Gliffy, ...

De repente es como si fueras un fanático del baloncesto, y todas las estrellas estuviesen ahí contigo, jugando el mismo partido de baloncesto.

Irrepetible... 
... o no. 
Porque el fin de fiesta fue el anuncio de que el próximo Atlassian Summit y AtlasCamp se van a celebrar JUNTOS, de nuevo en España, en Barcelona, la primera semana de Mayo de 2017.

Y allí estaremos de nuevo para vivir esta maravillosa experiencia :-)

AtlasCamp Developers Connect 2017














... y si te lo perdiste, disfruta de las charlas disponibles on-line ...

Si quieres disfrutar de las principales charlas, aquí tienes el enlace:




martes, 1 de marzo de 2016

excentia labs, retrospectiva


Han pasado ya cuatro meses desde la reunión de seguimiento cuatrimestral de la compañía donde anunciamos un cambio organizativo.

Aquel cambio tuvo muchas consecuencias a nivel de gestión: responsabilidades, crecimiento, más “peopleware” y agilidad, con equipos auto-organizados y multi-funcionales por proyectos, … Pero sin duda una de las grandes novedades fue el nacimiento de “excentia labs” (que además, casi, casi, coincidió con el nacimiento de mi segundo hijo :-) ).

excentia labs nace con orientación a productos, para impulsar su desarrollo y su comercialización. Queremos darle el peso y la visibilidad que se merece a todos esos pequeños productos que actualmente utilizan nuestros clientes cuando les proveemos servicios, pero que también estamos comercializando en diferentes marketplace (Atlassian, SonarQube) o impulsamos como desarrollos open-source. El objetivo es potenciarlos como línea de negocio directa y que la inversión siga manteniendo un retorno sostenible.

Pues bien, ahora que ha pasado algo de tiempo, queríamos compartir con vosotros algunos números:
  • 36 es la cantidad de versiones de productos que han sido liberadas en este periodo. Concretamente 24 versiones de extensiones para JIRA, y 13 versiones destinadas al mantenimiento de plugins de SonarQube.
  • La velocidad de desarrollo es de dos versiones por semana (y eso que incluye navidades ;-)). 
  • En este tiempo hemos puesto en el mercado tres nuevos plugins
  • En estos cuatro meses contabilizamos más de 3.500 descargas. Nuestro plugin de visualización de métricas en 3D (city model) para SonarQube está en la cima de nuestros plugins más descargados. 
LogMeIn, Swarovski, Engineering, Infineon, INDRA, Accenture, Alfresco, Comparex, Airgas, WilliamHill, y muchísimos más. Muchas gracias a todos por confiar en nosotros y en nuestros productos para seguir mejorando vuestro software y vuestros procesos. Seguiremos trabajando para manteneros a nuestro lado durante mucho tiempo :-)

En total, hemos acumulado ya más de 300 instancias activas de JIRA que usan nuestros plugins.
No podemos saber cuantos plugins de SonarQube están en instancias activas, pero nuestras “cuentas" nos dicen que deberíamos rondar las 500 instancias activas de SonarQube, teniendo en cuenta plugins comerciales, gratuitos y open-source.

Para terminar, una bola extra, comentar que la comunidad de SonarQube Hispano que estamos impulsando, cuenta ya con un año de vida, y registra más de 50.000 visitas, con más de 250 usuarios únicos registrados, y con más de 100 preguntas realizadas y con un 97% de las preguntas respondidas. Alex encabeza la lista de expertos de la comunidad, con más de 50 respuestas y más de 1.000 puntos. A ver si alguien es capaz de superarle ;-)

Pero todo esto es solo el principio, todavía nos quedan muchas cosas por mejorar y nuevas funcionalidades que implementar… ¡Seguiremos informando!

jueves, 11 de febrero de 2016

La velocidad de una caravana en el desierto



Artículo traducido de G. Ann Campbell, encargada de los productos de lenguaje en Sonar Source. Ver artículo original
____________________________________________
Procesadores rapidos
"¿Cuál es la velocidad de una caravana en el desierto?" El líder del equipo técnico de desarrollo de plugins para lenguajes de SonarQube planteó esa pregunta hace poco para ilustrar una cuestión sobre las herramientas de desarrollo. La respuesta a la pregunta sobre la caravana es que se mueve a la velocidad del camello más lento. Estaba utilizando la metáfora para ilustrar que un desarrollador sólo puede trabajar a la velocidad de su herramienta más lenta. 

Esta es una razón por la que los desarrolladores quieren - y los gerentes inteligentes compran – equipos de trabajo con procesadores rápidos. Nos gustan no sólo porque nuestras cabezas frikis funcionan con herramientas (¿o chips?), sino porque nos acercan más a la capacidad de trabajar a la velocidad del pensamiento. Pero ¿qué pasa con las otras herramientas? ¿Qué pasa con las herramientas de calidad? 

Por la misma razón que los desarrolladores quieren procesadores rápidos, entornos de desarrollo (IDE) rápidos y compiladores rápidos, también quieren herramientas de calidad rápidas. Olvida el punto y coma al final de una línea de código Java y la mayoría de IDE se iluminarán inmediatamente en rojo. Esa retroalimentación rápida y de calidad te permite codificar de forma rápida y eficiente, sin agonizar sobre detalles triviales. 

Del mismo modo, la retroalimentación rápida en la calidad del código te permite marcar las características como "hecho y limpio", y seguir adelante. Es por eso que SonarSource ofrece tres opciones diferentes para hacer un análisis previo a la confirmación en el control de versiones (pre-commit checks). Esa es la razón por la que abogamos (¡y practicamos!) la inspección continua. Revisar la calidad del código una vez al mes o una vez a la semana o justo antes de una liberación de versión ya es demasiaaaado tarde. 

Porque los desarrolladores quieren trabajar a la velocidad del pensamiento, no a la velocidad de la burocracia corporativa. Y los gerentes inteligentes, también.

miércoles, 4 de noviembre de 2015

¿Conoces la integración de SonarQube con MSBuild y Team Build?


Adaptación del artículo de Stuart Kent (Microsoft). Ver el artículo original
--------------------------------------------------------------------------------------------

La deuda técnica es el conjunto de problemas en un esfuerzo de desarrollo que hacen ineficiente el avance del progreso en el valor del cliente. Ésta mina la productividad al hacer el código difícil de entender, frágil, difícil de validar y crea trabajo no planificado que bloquea el progreso. La deuda técnica es muy maliciosa. Comienza siendo pequeña y crece con el tiempo a través de cambios apresurados, falta de contexto y falta de disciplina. Las organizaciones a menudo encuentran que más del 50% de su capacidad está minada por la deuda técnica.

SonarQube es una plataforma de open source que es la solución “de facto” para la comprensión y la gestión de la deuda técnica. 

Los clientes nos lo han dicho, a nosotros y a SonarSource, la compañía que está detrás de SonarQube: el análisis de aplicaciones .Net con SonarQube y la integración con tecnologías de builds de Microsoft necesitan mejorar considerablemente.

En los últimos meses hemos estado colaborando con nuestros amigos de SonarSource y estamos encantados de poner a tu disposición un conjunto de componentes de integración que permiten configurar una Build Team Foundation Server (TFS) para conectarse a un servidor SonarQube y enviar los siguientes datos, los cuales se recopilan durante una build bajo la visión de perfiles y umbrales de calidad definidos en el servidor de SonarQube: 
  • Resultados de análisis de código de .Net y JavaScript
  • Análisis de código clonado
  • Datos de cobertura de código de las pruebas
  • Métricas para .Net y JavaScript
Nos hemos dirigido inicialmente a TFS 2013 y superiores, para que los clientes puedan probar estos cambios inmediatamente con código y con las definiciones de builds que ya tienen. Hemos intentado usar los cambios anteriormente mencionados con las builds en Visual Studio Online (VSO), usando un agentes en local, pero hemos descubierto un error en torno al cálculo de los datos de cobertura de código sobre el que ya se está trabajando para resolverlo. Cuando esté solucionado, lo comentaremos en este blog. También estamos trabajando en la integración con la próxima generación de builds en VSO y TFS.

Además, SonarSource ha desarrollado un conjunto de reglas .Net, que se han escrito utilizando el nuevo framework de análisis de código basado en Roslyn, y se ha publicado en dos formas: en un paquete Nuget y en VSIX. Con este conjunto de reglas, el análisis que se realiza como parte de la build también se puede hacer en directamente dentro de Visual Studio 2015, explotando la nueva experiencia de análisis de código del IDE.

El código fuente de lo anterior está disponible en https://github.com/SonarSource, concretamente aquí:
Estamos muy agradecidos también a nuestro equipo de ALM Rangers por su constante apoyo y que han escrito, en paralelo, una guía de instalación de SonarQube que explica cómo configurarlo de modo que esté listo para su puesta en producción y que se utilice junto con Team Foundation Server 2013 para analizar aplicaciones .Net. Esto incluye la referencia a los nuevos componentes de integración mencionados anteriormente.

Esto es sólo el comienzo de nuestra colaboración. Tenemos un montón de ideas interesantes sobre nuestro backlog, así que no nos pierdas de vista.

Como siempre, estaremos muy agradecidos de vuestros comentarios sobre la experiencia e ideas sobre cómo se podría mejorar para ayudaros a vosotros y a vuestros equipos y ofrecer de manera más eficiente un software de mayor calidad y más fácil de mantener.

miércoles, 28 de octubre de 2015

La entropía del software


Alejo Lopez Entropia del software


Por Alejo López, consultor de calidad del software en excentia 

--------------------------------------------------------------------------------------

“Medida del desorden de un sistema”. Esta es la definición que la RAE nos ofrece de entropía. Y en 1992 en el libro Object-Oriented Software Engineering: A Use Case Driven Approach , aparece el término de entropía del software: “La segunda ley de la termodinámica parece plausible para los sistemas de software; Cuando un sistema es modificado, su desorden o entropía, siempre aumenta. Esto es conocido como entropía del software”. (wikipedia)

El software, aun no siendo un ser vivo, con el tiempo envejece, deteriorándose y muriendo cuando se vuelve obsoleto, siendo sustituido por otro software más “joven” y mejor adaptado al entorno.

En principio hay diversos factores, que influyen en esta entropía o envejecimiento, ciertos autores hablan de la podredumbre del software, y posiblemente sea una definición más visual de lo que en realidad sucede durante la vida útil de un producto.

Un software que depende del entorno en el que se ejecuta, puede dejar de funcionar o bajar su rendimiento por cambios en el mismo. Pensemos en una base de datos que es migrada de máquina y la conexión está “harcoded” dentro del código, esta aplicación dejara de funcionar hasta que no se vuelva a generar una nueva versión. O pensemos en una aplicación que para imprimir depende de un determinado tipo de impresora. Este tipo de dependencia con el entorno puede ser un mal necesario en determinadas circunstancias, pero la normalidad y lo más sensato es que no sea así. Disponer de ficheros de configuración que nos permitan cambiar los parámetros de conexión de base de datos, a un servidor de correo o la configuración de una nueva impresora por ejemplo, nos evitará muchos problemas.

Entropia del software

Esto nos lleva a otro factor que interviene en esta degradación. Imaginemos que se realizó una configuración inicial del sistema y durante algunos años no se ha cambiado. Puede darse el caso que sea necesario realizar modificaciones y el usuario o bien no quiere realizar esta configuración, porque fue “dolorosa” en su momento y no sabe dónde acceder para realizarla, o bien le falta información para configurar correctamente el sistema, puesto que por ejemplo no conoce credenciales correctas, no conoce las rutas a otros sistemas, etc.

El código sin usar puede darnos algún que otro dolor de cabeza. Éste es un código, ejecutado rara vez, que puede contener errores difíciles de localizar y es muy fácil que pasen desapercibidos por el usuario. Uno de los grandes riesgos de este tipo de código es que, con la modificación de los requisitos del sistema, se introduzcan defectos que a la larga permanecerán agazapados hasta que se vuelva a ejecutar la funcionalidad; y por supuesto esto ocurrirá en un momento crítico. Pensemos en una carga de datos: una modificación de los requisitos acordó que el campo email, tenía que ser obligatorio a nivel de base de datos, se modificó el formulario asociado, pero nadie se acordó del proceso de carga de datos, en el que nadie nos garantiza que existan datos para el campo email.

Por ultimo están las actualizaciones. En un sistema compuesto por múltiples módulos e integraciones, la modificación de una parte puede afectar al resto del sistema. Esto es conocido como el infierno de las dll o infierno de los jar, según la tecnología que se use. Seguramente estos infiernos dan para más de un artículo y de un problema.

Para resumir, podríamos clasificar todos estos problemas en dos tipos de degradación:
  • Degradación inactiva: básicamente significa dejar morir el software sin ningún tipo de mantenimiento evolutivo, por lo que en algún momento dejará de ser útil al no haber actualizaciones.
  • Degradación activa: un software que es continuamente modificado para satisfacer nuevos requerimientos se volverá cada vez más complejo y que incluso puede perder el objetivo principal para el que fue desarrollado.
Para retrasar la inevitable obsolescencia del software, es imprescindible un buen análisis de las necesidades y un buen diseño del mismo. Y tanto o más necesario es la aplicación de buenas prácticas durante el desarrollo, como el desarrollo de pruebas unitarias, de integración y funcionales que al menos cubran la funcionalidad crítica. Una buena documentación técnica y de usuario también colabora en que nuestras aplicaciones tengan una vida larga y plena.
 

Copyright® 2015 - excentia - Aviso legal | Privacidad | Contacto