Meetup de arquitectura: academia meets community

El pasado jueves participé de una reunión del Meet up de Arquitectura de Software de Buenos Aires. La temática de la reunión fue: ¿Cómo tiene que ser una IDE para arquitectos?

El orador principal fue Victor Braverman, un reconocido investigador de la UBA.  La sesión comenzó con una exposición de Victor en la que presentó un trabajo desarrollado en conjunto con la gente de Epidata, una consultora Argentina especializada en Arquitectura de Software.  En forma resumida:

  • Victor y su equipo desarrollaron una herramienta para generar una representación visual de la arquitectura de una aplicación a partir del análisis automatizado del código fuente de la misma y de ciertas propiedades de runtime.
  • Luego utilizaron dicha herramienta en dos proyectos de Epidata y realizaron un serie de sesiones de trabajo con arquitectos de dichas aplicaciones para analizar lo generado por la herramienta
  • A lo largo de esas sesiones de trabajaro detectaron ciertas cuestiones en las que la herramienta agregaba valor

 

Luego de la exposición inicial se abrió la charla con la idea de que la audiencia diera su opinión sobre el tipo de funcionalidades / información que podría resultar útil que la aplicación ofreciera.

Lo presentado por Victor me pareció interesante al igual que lo surgido de la audiencia pero lo que más destaco es la iniciativa de este grupo de académicos de acercarse a la comunidad de práctica. No es raro ver a los académicos trabajando en conjunto con la industria, pero general esas interacciones con la industria son empresas, rara vez con las comunidades de práctica. Mis felicitaciones para Victor, su equipo y también para la gente de Epidata por esta iniciativa conjunta.

Cierre AyDOO 2016 en UNTreF

El cuatrimestre terminó y en mi opinión su desarrollo estuvo bastante en línea con lo planeado inicialmente.

Comenzando por los números duros:

  • Hubo 16 inscriptos, 2 de ellos nunca vieron a clase, 1 vino solo una clase y los restantes 13 completaron la cursada.
  • La nota promedio de cierre de cursada fue 7,9/10.
  • La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue de 7,5/10.

Personalmente quedé muy conforme con el desarrollo de la materia, obviamente siempre hay cuestiones que mejorar, pero en términos generales creo que la dinámica fue apropiada. Creo que el uso del campus virtual ayudó mucho a la dinámica y personalmente estoy muy conforme con la herramienta utilizada (Eliademy).

Entre los puntos positivos destacados por los alumnos estuvieron:

  • El uso de un lenguaje nuevo para ellos (Ruby), ya que hasta el momento la mayoría había trabajado casi exclusivamente con Java. Cabe aclarar que no trabajamos solo con Ruby, sino que comenzamos trabajando con Java y luego pasamos a Ruby. En este sentido varios alumnos sugirieron comenzar con Ruby mucho antes.
  • Los videos. Para varias cuestiones (principalmente de carácter técnico) compartí videos grabados por mi, que los alumnos encontraron muy útiles.
  • Los casos reales. En casi todos los temas que fuimos viendo, fui compartiendo casos reales que me he encontrado en mi carrera profesional como ingeniero.

Entre los puntos negativos a mejorar destacaron:

  • La estimación de la carga de trabajo. Inicialmente yo había estimado (y explicitado) unas 4 horas semanales de trabajo extra clase, pero según reportaron los alumnos, en promedio debieron dedicar unas 10 horas semanales.
    => Definitivamente este es un punto a mejorar y lo que pienso hacer al respecto no es modificar las tareas semanales sino simplemente comunicar que se requerirán unas 10 horas de trabajo semanal extra clase.
  • La falta explícita de recreo. Dado que la dinámica de las clases incluye actividades de trabajo, no suelo dar recreos explícitos, sino que para mi el momento de recreo es  cuando hacen las actividades. Típicamente doy X minutos para hacer las actividades y en ese tiempo son libres de tomar una porción para hacer su recreo. Fui explícito respecto a esto pero evidente a los alumnos no les gusta y quieren que de un recreo explícito.
    => Sinceramente no estoy convencido de cambiar esto, pero es algo que evaluaremos en la próxima edición. Una opción que estoy barajando es dar un recreo de 10 minutos pero que sean los propios alumnos quienes lo pidan explícitamente en cada clase y si nadie lo pide, entonces posiblemente no se haga.

Finalmente hubo algunas opiniones contradictorias de los alumnos respecto del nivel de exigencia. Si bien hubo coincidencia en que el nivel de exigencia fue alto, algunos lo consideraron muy positivo mientras que otros lo consideraron negativo.

aydoo2016

Actividad extra-curricular @UNTreF: Desarrollo con Vagrant

Este Jueves 28 de Julio voy realizar una actividad extra-curricular en @UNTreF. Se trata de una sesión acerca de Vagrant, una poderosa herramienta para manejo de ambientes virtualizados.

Creo que Vagrant puede resultar una herramienta muy útil para los alumnos que deban cursar materias de programación avanzada. La cuestión es: en las materias de programación básica, típicamente basta con instalar un IDE (tipo Eclipse) y listo, no se requieren herramientas adicionales. Pero en las materias más avanzadas típicamente hay que utilizar algunas herramientas más, como kits de desarrollo (SDKs), bases de datos, web servers, etc, etc. Es ahí donde el uso de Vagrant puede simplificar mucho la preparación del ambiente.

La idea de esta sesión es hacerla online vía Google Hangouts y con participación activa de la audiencia, o sea: la sesión mezclará explicaciones con consignas que los alumnos realizarán en sus propias máquinas. Para esto los alumnos participantes deberán tener instalado en sus máquinas Git, Virtual Box y Vagrant.

Si este primer experimento funciona relativamente bien puede que sea el punto de partida para un conjunto de actividades de capacitación online. Veremos

Preparando Ingeniería de Software 2016 @ UNTreF

En segundo cuatrimestre de 2016 dictaré la materia Ingeniería de Software junto a mi colega el ingeniero Pablo Tortorella (@pablitux). De cara a facilitar a los potenciales alumnos la organización de su cuatrimestre queremos compartir algunas cuestiones referentes a la dinámica de la materia para esta edición 2016.

  • La materia se dictará los jueves de 18 a 22 (si, jueves) en la sede Lynch.
  • Más allá de la asistencia formal requerida por reglamento, recomendamos fuertemente la asistencia a clase.
  • La dinámica de evaluación será continua: tareas semanales + trabajo práctico final (últimas 5 semanas del curso).
  • Utilizaremos una herramienta virtual de soporte para centralizar la publicación, entrega y evaluación de tareas. Las tareas serán principalmente lecturas + cuestionarios + ejercicios de programación.
  • Trabajaremos con GNU+Linux (obligatorio) y Ruby.
  • Estimamos que la carga de trabajo extra clase será aproximadamente de 6 horas semanales (aunque puede que sea un poco mayor durante el desarrollo del trabajo final).

Cosecha de libros

Cosecha de libros

En Mayo pasado cuando asistí a la XPConf aproveché que había una stand de venta de libros y me di el gusto de comprar un par de libros que tenía en la mira desde hace tiempo.

En línea con la idea de que en un equipo todos sus miembros deben tener un perfil tipo T (saber en profundidad de un tema y al mismo tiempo tener una idea general del resto) hay un tema particular en el que me siento especialmente flojo: Usabilidad. Por esto decidí comprar dos libros:

  • The Design of everyday things, de Donal Normal, un libro clásico, no particularmente de software sino de diseño y usabilidad en general. Me lo había recomendado @dfontde hacía ya tiempo.
  • Don’t make me think, de Steve Krug, este si es un libro específico sobre usabilidad de software. Lo había visto hacía años en la biblioteca de una empresa amiga y desde entonces lo tenía en mi wish list.

Otro tema en que me siento flojo es en testing exploratorio y por ello también me compré un libro al respecto:

Finalmente había un conjunto que libros que ya había leído (al menos parcialmente) y que como me gustaron mucho quería tenerlos en formato físico:

“Agilistas” ¿fuera de foco?

Yo: me parece que deberíamos liberar las funcionalidades a medida que las vamos completando

El Scrum Master: o sea que querés usar Kanban en lugar de Scrum

Es la tercera vez en lo que va del año que tengo este diálogo, cada vez con un Scrum Master distinto (en distintos proyectos). No soy experto en Scrum pero ¿acaso Scrum dice que hay que esperar al final del Sprint para liberar una funcionalidad? Y si así fuera ¿que problema hay? Si vemos que en nuestro contexto puede resultar más beneficioso liberar a medida que completamos cada funcionalidad ¿porque no hacerlo? ¿Simplemente porque no es lo que dice Scrum?

Mi sensación es que hay:

  • Gente más preocupada por hacer Scrum que por entregar valor
  • Gente más preocupada por decir que es ágil que por serlo
  • Gente más preocupada por los ritos que por la mejora continua

 

El camino freelance, parte 6: libros recomendados

El camino freelance, parte 6: libros recomendados

Decidirse a comenzar el camino freelance no es fácil. A mi me llevó un buen rato, un par de años de hecho. La primera vez que lo consideré seriamente fue a fines de 2008 pero no di el paso hasta el 2012.

Allá por 2008 empecé a investigar hablando con algunos freelancers que conocía y leyendo algunos blogs, hasta que finalmente me compré un libro: The Principles of Successful Freelancing de Miles Burke. El libro valió la inversión, me ayudó a ver varias cuestiones que no estaban en mi radar en aquel momento.

Hoy, habiendo ya recorrido un par de años en el camino independiente vuelvo a recomendar el libro de Burke pero también he descubierto algunos otros que recomiendo con el mismo énfasis.

Soft Skills de John Sonmez y The Software Craftsman de Sandro Mancuso son dos libros excelentes y que recomiendo para todo programador profesional más allá de que trabaje de forma independiente o en relación de dependencia. Ser profesional es un valor que en el caso de trabajadores independientes es aún más valioso. El libro de Mancuso está enfocado en el desarrollo profesional. El libro de Sonmez también habla de desarrollo profesional pero es más profundo y llega a cubrir cuestiones concretas como técnicas de productividad, estrategias de trabajo remoto, marketing personal, la transición freelancer y cuestiones económico/financieras.

Los tres libros que mencioné  hasta el momento son libros para informáticos, el cuarto libro que quiero recomendar es mucho más genérico y posiblemente también más famoso: Los 7 hábitos de la gente altamente efectiva de Stephen Covey. Este libro nada dice sobre programadores ni trabajadores independientes, sino que básicamente habla de organización personal, algo fundamental para todo trabajador independiente.