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.

Nuevo sitio: Scrum Masters Community (+ video)

 

El amigo Tobias Mayer, pionero en dictar los talleres de Certified Scrum Master en Argentina, y un combatiente de la metodologías ágiles y Scrum en particular (incluso dando lucha desde adentro de la Scrum Alliance en su momento) lanzó recientemente un muy buen recurso para la comunidad de Scrum: un sitio web llamado scrummasters.community.

En el sitio se pueden encontrar libros, sitios y otros recursos recomendados por la comunidad de Scrum Masters en general, incluyendo algunos comentarios.

Es una especie de catálogo comunitario de recomendaciones, sencillo y útil.

Aprovecho el post para recomendar especialmente el último libro de Tobias, The People’s Scrum, que recopila los mejores artículos de Tobias en los últimos años, y no trata de explicar Scrum, sino que reflexiona sobre el espíritu, sobre el paradigma y las condiciones que estas prácticas crean, y a sus veces requieren.

Les dejo un video corto (~7 minutos; en inglés) de Tobias charlando en un evento sobre Scrum más allá de software.

Aprendiendo a programar Android en 12 clases gratuitas (+ video)

Por si alguno no se enteró, el equipo de JetBrains adaptó su excelente IDE para Java IntelliJ lanzando junto a Google una versión gratuita llamada Android Studio, que se encuentra en Preview, pero ya disponible para descarga.

Como esta gente no se queda quieta, además de lanzar la IDE, que es una alternativa más moderna y mejorada (al menos en mi opinión) a Eclipse, se asociaron también con el sitio de entrenamiento en línea Tuts+ para publicar una serie gratuita de entrenamiento sobre desarrollo en Android, presentada por el italianísimo Dino Esposito (el contenido está en inglese), una personalidad del mundo .NET pero también reconocido por su ductilidad para moverse entre plataformas, y sus cualidades como autor y entrenador.

La serie, llamada Android for the Busy Developer, compuesta por doce episodios, está basada en IntelliJ y no en Android Studio (no se bien por qué, pero para todo lo básico es lo mismo).

La serie completa cubre:

1. Introducción (~12m) 
2. Diseñador de Interfaces (~18m)
3. Interactividad mínima (~11m)
4. Ciclo de vida (~20m)
5. Más actividades (15m)
6. Vistas de Lista (~16m)
7. HTTP (~14m)
8. Almacenamiento (~15m)
9. Menúes (~16m)
10. Diálogos (~11m)
11. Preferencias (~15m)
12. Publicación (~6m)

Como pueden ver, son más de dos horas y media de entrenamiento, totalmente gratis, y más allá de que Dino muestre cómo se usa IntelliJ, los conceptos aplican al desarrollo Android utilizando la herramienta que uno prefiera (incluso si uno prefiere programar en C#, utilizando Xamarin Studio), porque hay mucho sobre la arquitectura y APIs básicas de la plataforma.

Les dejo el primer episodio (~12 minutos), en el que Dino explica cómo hacer el clásico Hello, World, para que vean más o menos el tono de la serie.