[Autobombo] Webinar de Arquitectura Ágil + Yoseki Coding Dojo semana que viene en RubyConf

Como avisé antes, el tag [autobombo] hace explícito que un post de este blog está referido a actividades en las que estoy directamente involucrado.

En este caso, quiero compartir el video (de ~50 minutos) del Webinar sobre Arquitectura Ágil que di anoche. 

 

Para los interesados en el tema, dejo links a la presentación original (muy similar a la del video) y al paper de hace unos años con el amigazo Diego Fontdevila en el Architecture Journal.

Para ver algunos de los comentarios durante el webinar, o posteriores, pueden mirar lo que quedó en Twitter bajo el hashtag #KleerArqAgil.

 

 

Por otro lado, si están interesados en la RubyConf Argentina, no se olviden que el próximo martes 26 de noviembre es el Ruby Fun Day, el evento anterior a la conferencia compuesto por talleres prácticos sobre diversos temas. Atención que este día es en la UP, no en Ciudad Cultural Konex como la conferencia.

En ese día de 15:30 a 17:30 voy a estar facilitando nuestro tradicional Yoseki Coding Dojo, edición Ruby. Si andan por ahí, pasen a saludar y avisen que leen este blog. :)

 

Novedades de Microsoft en direcciones interesantes (+ video)

Ayer hubo un evento de lanzamiento de Visual Studio 2013, donde Microsoft conato una serie de novedades. Algunas eran sabidas, dos en particular me llamaron la atención, porque me parece que son movimientos en la dirección correcta.

Finalmente se mostró el primer preview de la versión online de Visual Studio, que al parecer sólo se puede ver en videos por ahora, pero suena interesante. A pesar de estar bastante pegada a TFS online, una plataforma que no me resulta especialmente atractiva, mantiene y expande una actitud más abierta, con fuerte integración con Git, como se puede ver en el video que dejo debajo. Por otro lado, como verán, Node mantiene una presencia muy fuerte, con gran cantidad de ejemplos. La idea de que este entorno sea gratuito para grupos reducidos es importante.

Leí un par de notas periodísticas que mencionan esta iniciativa como una competencia directa de Microsoft a GitHub, que realmente me hicieron reír. Es cierto que algunos desarrolladores muy establecidos en el ecosistema Microsoft pueden preferir moverse en algún momento, pero no veo ninguna posibilidad de que algo de esto se plantee como una alternativa masiva. Al contrario, veo que son plataformas que pueden complementarse, y aunque no tengo chance de probarlo todavía, intuyo por las demos que tranquilamente se podría trabajar con esta IDE online desde un repositorio de GitHub. No veo ninguna dificultad técnica, y confío que el espíritu de apertura que intentan mantener desde este grupo de Microsoft no genere una barrera artificial.

Queda un video breve (~ 5 min) donde se muestra un proyecto Node, y cómo se utiliza el entorno, altamente integrado con TypeScript, que es otra estrategia interesante, sobre todo por lo poco intrusiva:

 

El otro gran anuncio es una asociación más directa con la gente de Xamarin, la empresa formada por los iniciadores del proyecto Mono, y todavía uno de los mayores grupos contribuyendo con él, que se dedica a permitir el desarrollo de aplicaciones nativas (no híbridas) en C# para iOS, Android, Windows Phone, OS X y otras plataformas (por extensión).

Lo interesante de esta asociación es que más allá de temas comerciales, tiene puntos técnicos muy importantes, logrando abrir más las puertas del ecosistema Microsoft / .NET hacia el exterior. Por ejemplo, las Portable Class Libraries (PCL) de .NET son ahora realmente abiertas y soportan el movimiento de librerías entre cualquier plataforma, facilitando muchísimo el intercambio también a nivel NuGet (el mecanismo de manejo de dependencias abierto del mundo .NET).

En total, esta noticia parece más de índole comercial, pero para mi el acercamiento al equipo de Xamarin y el reconocimiento del valor de llegar a estas plataformas fuera de su control son un blanqueo y una buena actitud que espero seguir viendo desde Microsoft hacia afuera.

Gigantes investigando: un vistazo al futuro

Creo que por acá todos saben que las empresas más grandes en la industria del software no paran de investigar, a ver quién gana en el próximo salto tecnológico, o quien se asegura un par de patentes que les de ventaja en el mercado los próximos años.

Más allá de que estemos de acuerdo o no con la política alrededor de la propiedad intelectual, es interesante echar una mirada a lo que están haciendo algunos de los principales centros de investigación de los gigantes de la industria. Gracias a la gente de Y Combinator, les dejo una serie de links a las páginas principales  sobre el tema:

• Microsoft Research y sus publicaciones
  Sus áreas de investigación cubren Comunicaciones y colaboración, Lingüistica computacional, Ciencias de la computación, Sistemas y Redes, Economía y Computación, Educación, Juegos, Gráficos y Multimedia, Hardware y Dispositivos, Salud y Bienestar, Interacción entre Computadoras y Humanos, Recuperación y Administración de Información, Aprendizaje Mecánico, Seguridad y Provacidad, Ciencias Sociales, Desarrollo de Software, Teoría y otras áreas temáticas.
   
• Research at Google y sus publicaciones
  Cubren Algoritmos y Teoría, Inteligencia Artificial y Aprendizaje Mecánico, Administración de Datos, Minería de Datos, Sistemas Distribuidos y Computación Paralela, Economía y Comercio Electrónico, Innovación en Educación, Ciencia General, Hardware y Arquitectura, Interacción entre Humanos y Computadoras y Visualización, Recuperación de Información y la Web, Percepción Mecánica, Traducción Mecánica, Sistemas Móviles, Procesamiento de Lenguaje Natural, Redes, Seguridad, Criptografía y Privacidad, Ingeniería de Software, Sistemas de Software y Procesamiento del Habla.
  
  
• IBM Research y sus publicaciones
  Uno de los pioneros en investigación de todo tipo, con más de 60 años en el tema y varios premios nobel a cuestas, cubren de todo, desde exploración y control espacial, genética y genómica, láseres industriales y quirúrgicos, salud, minería y por supuesto casi todas las áreas de software y hardware.
   
• Yahoo! Labs y sus publicaciones
  El menor de la serie, tal vez por ser la empresa que tiene hoy más problemas de crecimiento y subsistencia, de todas maneras se mantiene activa en áreas como Publicidad Computacional, Interacción entre Humanos y Computadoras, Medios, Aprendizaje Mecánico, Movilidad, Personalización, Investigación de Sistemas, y Búsqueda y Minería Web.

Les dejo un par de videos sobre los dos primeros, para darse una idea del estilo.

Research at Google (~3 min):

  

y un Tour por Microsoft Research (~10 min):

Imperdible: cócteles para programadores

Todos los años se festeja el Día del Programador, el día número 256 del año. Esta vez pasó el 13 de septiembre, y para festejarlo, un colega ruso publicó una serie de cócteles para programadores, publicada en GitHub, traducida a varios lenguajes, incluido el español, y con varias fotos muy buenas, algunas de las que reproduzco a continuación para abrirles el apetito (o la sed, en este caso).

Gracias a los amigos de Surculus Fructum por el dato.

Debajo, los cócteles para Ruby, Python y Assembler, respectivamente. En el post hay varios más, incluyendo las recetas. ¡Salud!

  

Agile Solo: Manejando el backlog personal

Continuando con la serie Agile Solo, hoy quería comentar algunas ideas para manejar el backlog de tareas y mejorar el nivel de compromiso de uno mismo hacia sus clientes o usuarios.

Una buena práctica para no dejarse tentar por la procrastinación es utilizar alguna herramienta para hacer público nuestro backlog. Como siempre, desde la agilidad le damos prioridad a la interacción entre las personas, por lo que prefiero concentrarme en cómo me comunico, y usar las herramientas más sencillas posibles (en particular me gusta Trello por que es liviano y su funcionalidad es mínima).

Lo importante para mi del backlog es tener donde volcar las clásicas tres columnas: pendiente, en marcha y terminado. Y lo bueno de tener una manera de hacerlo público es que podemos mostrar a las personas involucradas qué planificamos (por ejemplo, para la semana) y cómo vamos. Es posible que tengamos que unificar temas de varios clientes, y puede haber algunos relativamente confidenciales, para lo que prefiero usar nombres de código para los proyectos. De esta manera, cada cliente sabe el nombre de código, y puedo usarlo como “etiqueta” en mi backlog, sin divulgar identidades, preservando su confidencialidad. De la misma manera, no necesito poner detalles demasiado específicos de la tarea pendiente; alcanza con que ponga algo que mi cliente comprenda. Veamos un ejemplo:

Algunos tips sobre los nombre de código que me resultan útiles:

• No hacen falta para cosas no-confidenciales (en mi ejemplo, C&B para este blog, MUG, nombres de amigos)
• Conviene usar nombres que no signifiquen nada y que no tengan ninguna connotación. 
• Es bueno tener a mano una serie de muchos nombres disponibles. Yo elijo, por ejemplo, nombres astronómicos (estrellas, planetas o satélites) porque hay miles y usualmente no acarrean ningún significado especial. En otros casos utilicé nombres de ríos, pájaros, flores o plantas, frutas, etc. Google utiliza nombres de dulces para Android, Ubuntu animales más un adjetivo, etc.
• Lo importante es que el cliente reconozca SU proyecto (en el ejemplo, Fobos y Deimos son proyectos de clientes diferentes).

Obviamente exponer nuestro backlog plantea desafíos, pero yo creo que son sanos. Por ejemplo, el cliente de mi proyecto Fobos podría reclamarme prioridad sobre Deimos, aunque no sepa quien es. Eso nos obliga a ser transparentes, pero también a poder explicar racionalmente nuestra priorización, y el problema se termina si al final de cada iteración todos están conformes. También, aunque no hayan gran nivel de detalle en cada item del backlog, lo que hacemos para un proyecto puede inspirar ideas a otros clientes, y no está mal que esto pase.

Hay otras alternativas, por supuesto, como tener backlogs separados por cliente, donde cada uno vea su parte. En mi experiencia esto nos complica más de lo que nos ayuda, porque oculta la complejidad de nuestras actividades, y hace sentir a cada cliente que trabajamos solamente para él (lo que no está mal si es real).

Como siempre, hay cosas que dependen del nivel de madurez, pero en general yo prefiero que quien actúa de Product Owner en mi cliente tenga acceso a mi backlog y pueda poner todo lo que quiera. ¿Me arriesgo a que cambien prioridades? Si, pero prefiero siempre brindar más libertad y pedir responsabilidad que tratar de controlar. :)

Espero que algunas de estas ideas sirvan aunque sea para cuestionarlas y generar prácticas alternativas.