Incepción Ágil: Visión de alto nivel

En el segundo paso de nuestra Incepción de Proyectos vamos a tratar de condensar la visión de cómo resolver el problema que nos convocó a muy alto nivel, pero entrando en algunos primeros detalles que podamos discutir abiertamente, y nos sirvan para seguir la conversación.

El "Elevator Pitch" es un término que viene del mundo del marketing de los años 60~70, y la idea es tener un argumento tan bien preparado y condensado, que pueda usarse para "vender" una idea a alguien al encontrarlo en el ascensor, aprovechando el escaso tiempo de un piso al otro.

Aunque es probable que en el caso de nuestro proyecto no necesitemos "vender" la idea más allá del grupo de la Incepción (o si, aún más tarde, cuando queremos enrolar a alguien más en el proyecto), utilizamos su estructura porque destaca una serie de elementos que nos resultan útiles discutir.

Nuevamente, es tarea del facilitador dividir a la audiencia en grupos de tres o cuatro personas, con papel y lápiz, para crear diferentes versiones del "Elevator Pitch" dentro de un time box de 5~10 minutos, que después presentaremos y discutiremos entre todos.

Una ayuda es mostrar un modelo posible, sobre todo para resaltar los componentes que buscamos incluir:

Para [ cliente | público ]
que tiene [ necesidad | oportunidad ]
[ nombre producto ] es un [ tipo de producto ]
que [ beneficio | razón de compra] 
A diferencia de [ principal competidor | alternativa ]
nuestro producto [ diferencial competitivo ]

Como se ve, todavía tiene muchos elementos de marketing, pero los elementos están ahí. Si se trata de un proyecto de desarrollo, podemos pensar quién es nuestra audiencia principal, su necesidad, que categoría de solución vamos a darle, cuál será el principal beneficio, cómo se diferencia de lo que se utiliza actualmente o alternativas que ya existan en el mercado, y así.

Suelo resaltar que no queremos listas de características.Es importante que podamos leer el resultado en 20 a 30 segundos. Los detalles vendrán después. Queremos por ahora sólo lo más importante.

Esta actividad finaliza con la discusión abierta y una reelaboración de la que obtenemos una sola frase consolidada, o unas pocas alternativas principales.

Dejo nuevamente un ejemplo pequeño del taller en al Tech Meetup de Montevideo.

Incepción Ágil: foco

La primer actividad que realizo en un taller de Incepción es una ronda en la cada uno se presenta y comenta para qué cree que está en el taller.

Como en general, el facilitador debería mantener el timebox, es decir, aclarar que cada uno tiene un tiempo acotado (en este caso podría ser uno o dos minutos por persona), y tratar de ser claro en lo que esperamos de cada participante, por ejemplo:

• Nuestro nombre y perfil (rol, área ó especialidad)
• Quién nos convocó
• Lo que creemos que podemos aportar en esta reunión

Al terminar la ronda, podemos hacer que cada uno escriba brevemente en un post-it cuál cree que es el objetivo principal de la Incepción: ¿qué problema queremos resolver?

Nuevamente ponemos un timebox de 2 a 3 minutos, y después pegamos todo en una hoja, agrupamos los que son iguales o similares, y discutimos brevemente las ideas que son muy disimiles.

El objetivo central es que lleguemos a tener claro entre todos el problema que queremos resolver, sin que nadie venga y "se lo comunique" al resto. Queremos que surjan las inconsistencias o diferencias de nivel de abstracción que haya entre los asistentes.

Otro tema importante: si entre la ronda y la definición final del foco descubrimos que alguno de los participantes probablemente no tenga mucho que aportar, ni le podamos aportar el resto, lo liberamos, agradeciéndole haber venido, y manteniendo un contacto por si descubriésemos que hay algún tema puntual para consultarle. Esto es algo que debe manejar el facilitador para que suceda sin conflictos. No queremos que nadie sienta que su participación "no tiene valor" per se, pero tampoco queremos que haya asistentes que no estén realmente involucrados con el foco de esta Incepción.

Incepción Ágil: ¿a los backlogs los trae la cigüeña?

Tanto en el caso de Scrum como XP u otros frameworks ágiles, nos basamos en una lista priorizada de items a implementar. El nombre más común para esta lista es el que se usa en Scrum, que es Product Backlog, o Backlog a secas.

Sacando de lado que los items del Backlog sean historias de usuario, casos de uso, o un híbrido de cualquier tipo, usualmente no está claramente detallado de dónde sale al menos la versión inicial que luego irá evolucionando a través de las iteraciones.

Por otro lado, siempre aparece la duda de cómo podemos hacer dentro del paradigma ágil para mantener la flexibilidad y postergar todo lo posible las decisiones duras respecto al producto, aprovechando a nuestro favor el aprendizaje continuo, pero sin perder de vista la visión general o el objetivo al que queremos llegar.

Una de las prácticas más populares en los últimos años en la comunidad ágil para generar esta visión común y comenzar a definir el backlog, es la Incepción Ágil, documentada inicialmente por Jonathan Rasmusson, alias Agile Warrior, en su libro The Agile Samurai y en su blog.

En este post inicio una serie en la que voy a intentar recorrer cada una de las 10 actividades que yo realizo al facilitar esta actividad, describiendo la manera en que yo (particularmente, y posiblemente a diferencia de otra gente) los oriento, y qué es lo que trato de generar.

¿Cuándo y cómo se realiza una Incepción Ágil?

Para empezar, el formato que recomiendo para esto es el de un taller colaborativo, y el foco es que estén presentes (y en un mismo lugar físico) todas las personas fuertemente involucradas en el problema a discutir (ya que tal vez no esté claro si se convertirá en un proyecto, varios, o nada). 

Lo ideal es lograr un buen nivel de compromiso desde los patrocinadores principales del proyecto potencial, o las personas que tienen responsabilidad sobre el problema que queremos resolver. Esto es importante para poder convocar también a la gente que conoce el problema (tal vez desde un punto más operativo), otros relacionados fuertemente (sectores o áreas relacionadas) o los que estarán potencialmente involucrados en la implementación o soporte (por ejemplo, gente de tecnología, desarrollo, diseño).

Por otro lado, suele ser clave el rol del facilitador del taller, que debe entender bien el formato general y las actividades individuales, poder moderar discusiones que se desborden, mantener el ritmo de la reunión, asistir las necesidades de los equipos, y otras tareas generales. En organizaciones donde ya hay gente que actúa como Scrum Master o Coach ágil, ellos suelen ser los más indicados. Pero también se puede contar con algún entusiasta que idealmente haya participado en una Incepción previa.

La duración también depende del nivel de importancia del proyecto/problema que vamos a tratar. Puede variar entre medio día y dos días completos.

En la práctica he facilitado Incepciones desde medio día con menos de 10 personas, hasta un día y medio con casi 20. No hay una regla muy específica a aplicar, y creo que cada organización y contexto debe encontrar su punto. Yo prefiero reservar más tiempo del esperado, y terminar antes, a quedarse "corto" y que los participantes se dispersen sin haber terminado.

El estilo de la reunión

Algo que para mi es fundamental es el estilo que le damos a este evento. Yo prefiero contar con un espacio abierto para poder moverse, algunas mesas para trabajar en grupos de 4 o 5 personas, y sobre todo muchas paredes para poder ir pegando resultados de las actividades. La mayor parte del tiempo lo que se va generando son  láminas con diferentes visiones del problema/proyecto, usando colores, tijeras, materiales varios, y en general un tipo entrañables livianos, poco formales, y que requieren trabajo manual.

Parte del secreto es que al trabajar con las manos y haciendo dibujos o armando cosas con las manos, generamos un ambiente en el que las jerarquías tienden a borrarse, generando mayor participación y una discusión más abierta, que al contrario de la formalidad excesiva, tiende a sacar a la luz mucho más fácil, pero sin tanto riesgo, montones de temas críticos.

Quedan debajo un par de fotos de un taller en el que practicamos esta técnica en el reciente Tech Meetup en Montevideo, para que tengan una idea del tipo de cosas que tenemos al terminar (teniendo en cuenta que en esta caso trabajamos sobre un proyecto ficticio, y en un tiempo acotado de 90 minutos).

Para los que quieran seguir la serie de artículos, todos los artículos están bajo el tag inception, o pueden utilizar esta guía:

1. ¿Para qué estamos acá?
2. Elevator Pitch
3. Vision Box
4. Qué si, qué no
5. La comunidad
6. La solución
7. Los miedos
8. Tamaño
9. Trade-Off
10. ¿Cuánto cuesta?

 

Ficciones y Realidades, aumentadas o virtuales (+ video)

En 1992, Neil Stephenson publicaba su novela “Snow Crash”. En la historia, parte del movimiento literario de esa época conocido como Cyberpunk, Stephenson imaginaba un entorno virtual al que los usuarios se conectaban y en el que adoptaban un personaje, o “avatar” con características particulares, como un alter ego virtual. Aunque hay algún antecedente del uso de la palabra “avatar” para un concepto similar, esta novela fue la que lo popularizó y trajo hasta nuestros días. No fue su única influencia: el creador del célebre Doom reconoce este libro como influencia directa, y algunas plataformas como Second Life o similares están sumamente basadas en esa obra.

La principal diferencia entre la manera de “entrar” en el multiverso de Snowcrash, al igual que en otras ficciones de esa época, es que la interfaz no era, como en las aplicaciones que usamos, a través de un teclado y un monitor convencional, sino que se imaginaban cascos, guantes y hasta trajes de realidad virtual, que brindaban una experiencia totalmente inmersiva y en primera persona.

 

Pasaron diez años y pico para que en 2003 Cory Doctorow publicara su primera novela, “Down and Out in the Magic Kingdom”, en que imaginaba nuestra sociedad adaptada al uso de dispositivos auxiliares incorporados a nuestro cuerpo, de modo que estuviésemos conectados permanentemente con nuestros amigos o grupos especiales de personas cuando querramos, y que nuestra visión se complementase con datos relevantes sobre las personas, lugares o situaciones que estamos presenciando, nuevamente, en una experiencia totalmente integrada. Cory es un gran defensor de las licencias abiertas y esta novela, como todo lo que hace, puede descargarse gratis de su sitio, sin alguien está interesado (yo la recomiendo especialmente).

Saltando otro poco más de diez años, la realidad aumentada ya es algo a lo que nos estamos acostumbrando, en pequeñas dosis, y tal vez con grandes espacios de mejora, pero ya todos conocemos o usamos aplicaciones que nos permiten que nuestro celular “reconozca” ciertos objetos o imagenes y nos de información adicional, o reconozca el tema que estamos escuchando en la radio y nos muestre la letra. Y obviamente tenemos al menos cerca muchísima información disponible sobre rutas, personas, el clima y demás en nuestros dispositivos. Y es el principio, porque ya están llegando desde relojes más inteligentes a dispositivos “usables” como Google Glass, que nos acercarán a esa experiencia de disponer los datos adicionales sin mirar a otro lado, sino como parte de nuestra visión general.

Y así como la realidad aumentada creció lentamente, la realidad virtual está regresando, después de unos 20 años en suspenso. De la mano de procesadores y sensores más rápidos, dispositivos como “Oculus Rift” están finalmente resolviendo los problemas que detuvieron el avance de esas experiencias virtuales inmersivas. Este producto, que está todavía en etapa de prototipo para desarrolladores de juegos, ya tiene muchisimo soporte de los principales productores de la industria, y está por salir al mercado, cuando haya cantidad de software generado, y cuando se haya pulido aún más para el mercado de consumo. Básicamente es una pantalla muy liviana, como la de una tablet, pero de alta resolución, montada en una especie de antifaz, y que produce dos mitades de la imagen, una para cada ojo, y tiene sensores de posición que hacen que al girar, subir o bajar la cabeza, la imagen virtual acompañe nuestros movimientos con una latencia tan baja que no podemos percibirla. Lo que falta por ahora es que no nos vemos a nosotros mismos, pero ya hay varios experimentos en conjunto con dispositivos como Razer Hydra (ver video debajo), una especie de evolución del controlador de la Wii, que podemos tener en las manos y puede generar parte de nuestra imagen en el mundo real. Y claro, hay otros controladores en marcha del estilo de los guantes virtuales que se imaginaban hace 20 años.

Como mencioné vez pasada hablando de nuevas interfaces, el desafío para nosotros es probar los SDK de estas nuevas herramientas e imaginar nuevos productos o servicios que podemos desarrollar integrándolas.

En resumen, las realidades aumentadas (complemento de nuestro mundo real) y las virtuales (que reemplazan nuestros sentidos con otro mundo) estan para quedarse. Es buen momento para volver a pensar en qué es la realidad, como el Maestro hizo a lo largo de 50 posts en su blog.

Aquí queda el video que muestra Razer Hydra en acción (menos de 3 minutos):

[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.

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.

 

[Autobombo] Libro gratuito de "Introducción a los lenguajes de la web"

Atención: en este post hablo sobre un trabajo mío, porque se trata de un trabajo gratuito y espero que útil para algunos de los lectores. Para ser bien explícito en los casos en que mencione cosas que me involucran directamente, decidí usar un tag (en el título mismo del post) [Autobombo]. Para quienes no comprendan el término, es un argentinismo que usamos para usando alguien se hace propaganda a si mismo. Pueden quedarse tranquilo porque no soy tan productivo, así que no creo que ocurra muy a menudo. :)

Con mi compañero de ruta Juan Gabardini terminamos recientemente la versión final (al menos por ahora) de este librito que es, como dice el título, una mera introducción a HTTP, HTML y CSS.

El objetivo del libro es acercar a los conceptos más básicos a gente que se está acercando al desarrollo, o que tiene experiencia en otras áreas, como aplicaciones de escritorio o tecnologías anteriores.

El libro cubre temas como Internet (dominios, direcciones IP y puertos), HTTP (peticiones y respuestas; cookies) HTML5 (elementos, texto, enlaces y formularios), CSS, aplicaciones web mínimas (en PHP, Python y Flask, Ruby y Sinatra), y algo sobre URL semánticas.

Como explicamos en el arranque, no nos metemos en JavaScript, que es un tema mucho más grande, ni entramos en detalles muy profundos, pero tratamos de dejar punteros a otros recursos abiertos donde poder profundizar.

Todavía no lo agregamos a la página de Kleer donde pueden encontrar otros libros gratuitos, pero se viene en breve.

Espero que les resulte útil.