Spring I/O 2012

La semana pasada se celebró en Madrid la conferencia Spring I/O 2012. Con más de 300 asistentes y 34 charlas repartidas en 3 tracks a lo largo de dos días, es uno de los eventos técnicos de referencia a nivel nacional.

Pero la Spring I/O fue mucho más que charlas técnicas. Por ejemplo, la Comunidad de Groovy y Spring pudo disfrutar del fiestón patrocinado por Atlassian.

BonillaTV estuvo allí y aquí tenéis, en exclusiva, el reportaje del evento.

Durante todo el evento estuve haciendo de azafato en el stand de Atlassian en el evento así que, a pocas charlas pude acudir. Para los que busquéis más información sobre las mismas, os dejo algunas de las crónicas de la conferencia que ya han sido publicadas. Si conocéis más textos, por favor, enviármelos.

Comments { 5 }

Atlassian en la Spring I/O

Durante los próximos jueves 16 y viernes 17 de febrero, se celebrará la Spring I/O, una de las conferencias técnicas más importantes del año en España y, probablemente, la más relevante relacionada con el lenguaje Groovy y el framework Spring.

Como embajador de Atlassian, tengo el honor de anunciar nuestra colaboración con el evento como orgullosos patrocinadores del fiestón del mismo.

Todos los asistentes, ponentes y patrocinadores están invitados. Por supuesto, la primera ronda la paga Atlassian, pero como no sólo de alcohol vive el programador, podéis esperar mucho más: juegos, concursos, regalos y… un sorprendente y awesómico anuncio en exclusiva que puede cambiarle la vida a más de uno.

Fiesta SpringIO

No olvidéis vuestras acreditaciones del evento para que os podamos repartir los vales-por-un-copazo.

El sitio donde se celebrará esta bacanal técnica es un localón, muy conocido en la capital. Ni más ni menos que el Moma56, al lado del Paseo de la Castellana, y con una parada de metro en frente -Gregorio Marañón- a la que llegan las líneas 7 (naranja) y 10 (azul oscuro, casi negro) del Metro.

Para los que vengáis en coche, tenéis un montón de parkings públicos alrededor del local.

Si tenéis alguna pregunta, no dudéis en poneros en contacto conmigo -estaré durante todo el día en el hall de la Spring IO- o dejar un comentario en este mismo blog ¡Os esperamos a todos!

Atlassian Party / Spring I/O

Jueves, 16 de febrero de 2012. A partir de las 21h

MOMA56

C/José Abascal 56

28004 Madrid

BOLA EXTRA

 

Comments { 3 }

Segunda reunión del AUG Madrid

El próximo miércoles 8 de febrero, a partir de las 19h, en la sala CIBALL de Madrid, se celebrará la segunda reunión del Grupo de Usuarios de Atlassian en Madrid, o AUG Madrid.

Un EVENTAZO que constará de tres partes -completamente independientes entre si- con una duración aproximada de 20 minutos cada una, para que puedas incorporarte cuando quieras:

  1. En la primera parte, un servidor avanzará en primicia las novedades más interesantes que encontraremos en los próximos meses y avanzaré la estrategia de Atlassian en España con alguna que otra sorpresa que dejará a más de uno con la boca abierta.
  2. La reunión subirá de intensidad con una mini-sesión en vivo, donde el chamán de la Integración ContinuaHéctor Rodes nos mostrará una implementación en directo con Hudson/Jenkins y el muy amazing Bamboo -la alternativa de Atlassian- que permitirá ver los pros y contras de cada una de estas herramientas ¡Sin anestesia y sin paños calientes!
  3. Para acabar, el plato fuerte, Guillermo Montoya -CEO de Deiser- nos mostrará lo fácil que es crear plugins y extensiones para ConfluenceJIRA. Además, para celebrar su llegada al market de Atlassian, sorteará una suite completa de productos para 10 usuarios entre los asistentes.

Si crees que un AUG es una reunión de comerciales para venderte productos, es que no te has enterado de nada

Pero, el AUG siempre va más allá del programa oficial. El grupo nació con la intención de que crear un punto de encuentro para gente con distintos perfiles y conocimientos tecnológicos. Un lugar donde poder conocer y charlar con camaradas del metal, en un ambiente distendido y divertido.

Para que os hagáis una idea de lo que os vais a encontrar, os dejo un video de la anterior reunión :)

Como colofón,  networking y cervezas -la primera ronda, a cargo de los awesomicos partners de Atlassian, al fin y al cabo, esto es un AUG- y las sorpresas y diversión habituales. Si crees que un AUG es una reunión de comerciales para venderte productos, es que no te has enterado de nada. Ven a comprobarlo.

Segunda Reunión del AUG Madrid

Entrada Libre. 19:00h-20:00h + tercer tiempo (networking/cervezas)

Sala CIBALL

Calle Corredera Baja de San Pablo, 41

28004 Madrid

Bola Extra

Comments { 7 }

Crónicas Australianas. Día 14

Durante mi estancia en las oficinas de Atlassian en Sídney, no sólo he estado recibiendo formación sobre los productos y la compañía, sino que he pasado tanto tiempo o más en reuniones donde se discutía la futura estrategia corporativa.

Y no porque sea un ejecutivo de nivel mundial o porque me consideren una luminaria de los negocios, sino porque poseo algo que se valora a precio de oro dentro de la compañía: información directa sobre lo que quieren partners y clientes.

Product Management: si quieres vender, conoce a tu cliente

En Atlassian hay una verdadera OBSESIÓN con ajustar el roadmap de cada producto a las necesidades reales de los clientes. Después de constatar que la interfaz de JIRA resultaba complicada y confusa para muchos usuarios, por ejemplo, se creó el proyecto Kick-Ass, un desarrollo interno con el objetivo de hacer que la aplicación sea más sencilla y usable, al que han dedicado ni más ni menos que 30 desarrolladores.

Tradicionalmente, los Product Managers -los encargados de confeccionar ese roadmap- provenían del marketing puro y duro pero, desde que Audra Eng se hizo cargo de la gestión de producto, ha estado promoviendo sistemáticamente a técnicos como Product Managers. Según ella, los técnicos tienen una visión del mercado más amplia y más a largo plazo.

El arte de la documentación técnica

En Atlassian hay 7 escritores técnicos contratados a tiempo completo y quieren contratar a 10 más. La responsabilidad de los escritores técnicos no es sólo crear manuales de usuario, sino tutoriales completos sobre como administrar las herramientas y, lo que es más importante, como desarrollar plugins que extiendan los productos.

Evidentemente, toda la documentación se crea en Confluence -una de las herramientas de la casa- pero, Sarah Maddox me estuvo contando algunas peculiaridades de su forma de trabajar que merece la pena destacar:

  • Están OBSESIONADOS por conseguir que la documentación no sólo sea exhaustiva y de calidad, sino atractiva. Para conseguirlo, utilizan todos los trucos que pueden. Desde el uso de Zen Foundation -un plugin de Confluence- para darle un diseño propio y distintivo a developer.atlassian.com, hasta el uso de Gamification, como en el increíble tutorial Here be Dragons, que enseña a instalar y configurar todas las herramientas de la compañía mientras juegas.
  • La Documentación no está cerrada sino que permiten que la Comunidad colabore. Para empezar ¡Permitiendo comentarios en la propia documentación! Siguiendo con un programa que permite editar directamente el contenido a contribuidores de reconocido prestigio; y llegando hasta incluir enlaces a blogs externos con documentación relevante y de calidad sobre los productos.
  • Toda la información se publica automáticamente en formato PDF, HTML y XML, para que no sólo sea fácil de leer, sino también de procesar, si hiciera falta.
  • Toda la documentación se publica con licencia Creative Commons -reservando sólo el derecho de atribución- así que, en teoría, se podría coger toda la documentación, empaquetarla, ponerle una portada y venderla como libro en Amazon. Sería ratuno y vergonzante pero, por poder, se podría.

La verdad, esta política de documentación, con el objetivo final de conseguir que más gente conozca y use los productos, me parece brillante y sorprendente en una empresa de software propietario. Sobre todo, acostumbrado a la estrategia de otras compañías que han convertido la documentación de sus productos en otro negocio en si, aunque eso suponga un freno a sus propios productos.

El Testing, con cabeza

En Atlassian hay muy poca gente en el departamento de Calidad y están buscando continuamente gente nueva. Eso es así porque buscan perfiles muy concretos y poco comunes: desarrolladores que estén verdaderamente interesados y apasionados por la calidad en el software.

No hay ni un solo miembro del equipo de QA que no sea técnico. Entre otras cosas, porque entre sus obligaciones está la de mejorar y complementar los test unitarios ya programados por el equipo de desarrollo.

Durante la entrevista con el equipo, hubo un par de cosas que me llamaron mucho la atención:

  • El Testing Exploratorio, que en muchos sitios se hace de forma aleatoria, en Atlassian se hace siguiendo también una metodología: se hacen una serie de preguntas, una serie de presunciones de cómo trabajaría un determinado usuario. Se les asigna una cantidad de tiempo y se prueban.
  • Además de los tipos de pruebas habituales (functional testing, domain testing, stress testing…), en Atlassian se practica también el claim testing: si la compañía anuncia que la versión X del producto Y es un 20% más rápida, se prueba que efectivamente sea así.

OBSESIONADOS por conseguir que la documentación no sólo sea exhaustiva y de calidad, sino atractiva

Una vez más, me dejo muchas cosas en el tintero a pesar de escribir un artículo mucho más largo que lo habitual. Si queréis conocer de primera mano como se trabaja en Atlassian –o lo que es lo mismo, una compañía de producto con presencia internacional- creo que tendré que escribir una tercera parte de las crónicas australianas.

¿De verdad no creéis que muchas de las prácticas que he descrito pueden aplicarse directamente en nuestras empresas en España?

Comments { 5 }

La variable de entorno PATH en Mac, desmitificada

¿Qué es PATH?

Cuando en Mac abres un terminal, puedes ejecutar una serie de comandos como ‘pwd‘ -para mostrar la ruta absoluta del directorio en el que te encuentras- o ‘ls‘ -que muestra los ficheros y directorios incluidos en el mismo- independientemente del directorio donde estes y donde se encuentren dichos comandos. Eso es posible gracias a PATH.

PATH es una variable de entorno que permite definir las rutas en las que el sistema operativo buscará esos comandos o ficheros.

El contenido de PATH

Para saber el valor actual de la variable PATH, debemos escribir en el terminal

echo $PATH

El valor de PATH siempre son un conjunto de rutas a directorios o ficheros separados por dos puntos. Por ejemplo, la variable PATH con valor ‘/usr/bin:/bin:/usr/sbin‘  está incluyendo los directorios /usr/bin, /bin y /usr/sbin.

Incluyendo el directorio actual en PATH

Es posible que deseemos modificar el valor de PATH, por ejemplo, para incluir el directorio actual. Si no lo hacemos, no podremos ejecutar ningún comando ni abrir ningún fichero del directorio en el que estemos si este no está incluido en PATH.

Por ejemplo, si estamos en el directorio /Users/david/development/Tomcat/bin y, dentro del mismo, existe un fichero ‘startup.sh‘, al intentar ejecutar el comando

startup.sh

obtendremos un error de ‘Fichero no encontrado’ porque el sistema operativo no sabrá donde buscar el fichero ‘startup.sh‘. Por eso debemos indicarle que está en el directorio actual de trabajo, representado por un punto (.)

./startup.sh

Para evitar tener que usar el punto cada vez que queremos trabajar con un fichero de nuestro directorio actual de trabajo, debemos modificar el valor de PATH para que incluya al mismo.

Como modificar el valor de PATH

El valor de PATH, al igual que el de todas las variables de entorno, se modifica con la sintaxis

NOMBRE_DE_VARIABLE=valor

De tal manera que, para modificar la variable PATH para que incluya el directorio actual deberíamos escribir lo siguiente en el terminal

PATH=$PATH:.

Con esto, le hemos dado a PATH el valor actual ($PATH) y, además, la ruta del directorio actual (.), separándola de la anterior con dos puntos (:).

El problema es que, esta configuración se perderá en cuanto cerremos el terminal. Si quieres saber como modificar el valor de PATH de forma persistente, tendrás que aprender como el sistema operativo OS X compone el valor de PATH.

Como se obtiene el valor de PATH en OS X

En OS X, al iniciar una Terminal se ejecuta el archivo /etc/profile. Así, si escribiéramos al final del mismo la famosa linea

PATH=$PATH:.

conseguiríamos añadir el directorio actual al contenido de PATH, pero lo haríamos de una forma poco elegante -porque ese no es el lugar más adecuado para hacerlo- y seguiríamos sin entender como se compone el valor de PATH en OS X.

El mismo fichero /etc/profile lanza un programa de utilidad llamado path_helper. Este programa es el que determina como se compondrá el valor de PATH:

  1. Primero, añade las rutas que encuentra en el fichero /etc/paths. En dicho fichero podrías añadir más rutas, una en cada linea, sin tener que separarlas por (:). Esto modificaría PATH para todos los usuarios del sistema.
  2. Después, carga todas las rutas, una por linea, que encuentre en los ficheros del directorio /etc/paths.d. Este directorio permite configurar PATH modularmente. Así por ejemplo, Atlassian recomienda crearse aquí un fichero llamado ‘atlassian‘ para añadir las rutas de su SDK. Los ficheros se cargan por orden alfabético (se añadirán primero las rutas de ’50-X11′ que de ‘atlassian’). Esta opción, también modifica PATH para todos los usuarios del sistema.
  3. Por último, puedes crear un fichero .profile en tu directorio HOME -en el que se inicia la terminal- y definir en el mismo el valor de PATH con la sintaxis que ya hemos definido. Esta opción, sólo modifica PATH para el usuario cuyo directorio HOME contenga el fichero .profile

Saber como funciona path_helper no solo nos ayudará a configurar el valor de la variable PATH, sino que además nos permitirá conocer porque unos directorios aparecen antes que otros y resolver los conflictos de rutas que podamos tener.

La gestión del directorio actual por comandos que ya están en el PATH

Gracias a la contribución de Dani Lopez, Victor Martinez y David Martinez, completo la información del artículo:

Cuando se usan comandos del tipo open, vi, sh, etc… no es necesario incluir los ficheros del directorio actual en el PATH puesto que estos comandos ya gestionan por si solos esa salvedad.

Es decir, si se ejecuta un open facturas.pdf, el propio comando open intenta abrir el fichero y, si no lo encuentra, vuelve a intentarlo clavándole a fuego un ./ por delante para comprobar si está en el directorio actual.

Bola Extra

Comments { 28 }