Alt.net Open Space Buenos Aires 2010

El balance del alt.net open space en Buenos Aires fue muy positivo. No sólo por los temas muy interesantes sino sobre todo por poder charlar e intercambiar ideas con gente apasionada por el desarrollo de software y conocer en persona a quienes sólo conocía vía mail o twitter.

Estas son algunas notas de las sesiones en las que participé (están basadas en lo que me acuerdo que se habló así que disculpen cualquier error u omisión).

“Convergencia Web / Desktop”:

Del lado de las desventajas de desktop la principal que se mencionó es la del deploy que se ve complicado por las políticas de seguridad IT y en Windows 7 y Vista por UAC. En el caso de Silverlight / WPF se mencionó como una limitante el lock in con Windows y la imposibilidad de implementar en dispositivos móviles u otros. Por el contrario, estos son justamente puntos fuertes de las aplicaciones Web.

Como ventajas para desktop fueron la facilidad de desarrollo y unit testing que en cambio es más complicado en aplicaciones web, en particular el testing para javascript / jquery a pesar de que se mencionaron alternativas como QUnit. Otras desventajas son las diferencias entre navegadores y dispositivos y por supuesto la imposibilidad de usar la aplicación sin conexión.

En general hubo consenso en que depende de los requerimientos y el escenario cual camino tomaré. Se mencionó que cierto tipo de aplicaciones tipo Word o Visual Studio están mejor cubiertas en un escenario desktop. También para casos como el uso de dispositivos especiales, por ejemplo un lector biométrico.

Se habló también de algunas tecnologías nuevas que tienden a diluir las fronteras entre lo web y lo desktop.

Yo en particular veo un tendencia a llevar aplicaciones que eran exclusivas de desktop a la web, desconozco si esto pasa en el sentido inverso. El ejemplo clásico son los google docs, pero también otros como coderun studio que lleva algo complejo como es una IDE, a la web. Por otro lado tecnologías como jquery y sus plugins permiten una interfaz cada vez más rica y nos resuelven en gran medida las diferencias entre navegadores y dispositivos. Y otras como Gears permiten utilizar aplicaciones web como gmail o google docs tanto online como offline.

“Cómo y por qué participar en un proyecto open source”:

José Romaniello empezó hablando de cuales eran las motivaciones y los beneficios de participar en un proyecto open source, algunas que se mencionaron son la satisfacción de ver que alguien usa un software que hemos creado y otra la posibilidad de interactuar con programadores con mucha experiencia / conocimiento.

Por otro lado se habló de la poca gente que colabora en proyectos OSS y a partir de esto surgió el tema de las barreras y dificultades a la hora de colaborar. Por ejemplo para encarar el código en proyectos open source de un tamaño considerable.
Claudio Meschini tiró como propuesta que se genere un tutorial que explique a “groso modo” la idea de cada módulo, algo así como la introducción que le haría un desarrollador que viene trabajando desde el principio del proyecto a uno que empieza. La idea por supuesto no es pedir más cosas a quien está haciendo el desarrollo OSS sino por el contrario bajar la barrera de entrada para poder colaborar.
José mencionó como estrategia la de dejar issues de menor complejidad que un nuevo colaborador pudiera encarar con mayor facilidad.

Por otro lado Carlos Peix habló de la posibilidad de financiar de alguna forma los proyectos open source y dió como ejemplo el caso de 37 signals y Ruby on Rails. Ideas que se hablaron en torno a esto fueron la licencia dual, implementaciones o features custom, consultoría, etc.

“Unit testing como cultura de desarrollo” junto con “No tengo tiempo”

José Romaniello arrancó el tema contando cuales eran las razones (o excusas) que había escuchado para no hacer unit testing, esto llevó a la discusión de las dificultades en la adopción de esta técnica (y otras como pair programming), incluso para personas que reconocen las ventajas de su uso. Se tocó la problemática de entornos en los que no todos los desarrolladores realizan unit testing.

Se habló de cómo motivar o facilitar la adopción y se mencionaron algunas cosas que podían ser contraproducentes como por ejemplo imponer el uso de unit tests, que pueden llevar a tests inútiles, hechos sólo para lograr el coverage.

Se mencionó la necesidad de un cierto grado de experiencia para llegar a buenos tests y de cómo estos nos llevaban a cambiar nuestra forma de programar para obtener un código testeable, logrando un mejor diseño, con menor acoplamiento y mayor conciencia de las dependencias.

Se habló de código sin tests, o como dice Michael Feathers, de código legacy y Martín Salías hizo referencia al libro del mencionado autor: Working Effectively with Legacy Code.

Otra buena práctica que surgió en la sesión fue la de integración continua y cómo esto además genera una sinergia positiva con los tests.

También se habló del tema de estas prácticas frente al cliente y si correspondía plantearlas o no.

Para mi la motivación instantánea para realizar unit tests fue el aburrimiento que me produce realizar tests a mano, si bien al principio puede llevar más tiempo pensar y armar buenos tests, mi experiencia fue que con la práctica tardaba menos en probar que haciéndolo a mano y lograba un código con menos bugs.

Lo mismo me pasa con cosas como los deploys, automatizarlos es sacarme de encima una tarea aburrida, y una vez que hiciste eso estás a un paso de la integración continua.

“Que estamos aprendiendo de Ruby on Rails” junto con “Deploys en caliente”:

Se plantearon varias ventajas del entorno ruby, como por ejemplo que hay un gem para cualquier cosa que necesitemos y que gracias a rack, algo escrito para rails lo puedo llevar por ejemplo a sinatra y funciona, herramientas como las migrations, cosas como la facilidad de los deploys en rails (o tambien en php) versus los deploys en asp.net. Todas estas cosas y otras hacen posible una mayor reusabilidad y dinamismo, facilitando y acortando los tiempos de desarrollo en ruby.
Como ejemplo concreto se habló de la experiencia de uno de los participantes en un proyecto, en el que luego de tratar por 1 mes con asp.net mvc se logró mejores resultados en 2 semanas con rails, y esto a pesar de que en el equipo había más programadores con experiencia en .net y en cambio uno solo con experiencia en rails.

Al tratar de responder el por qué de estas diferencias algunas de las cosas que surgieron son los problemas de la rigidez en los entornos corporativos, la no aceptación de librerías / frameworks que no sean de Microsoft; la no compatibilidad entre asp.net, asp.net mvc, webmatrix, etc.; la falta de librerías y mayor dificultad para la reusabilidad de componentes en .net.

Algunas de estas herramientas ya empiezan a estar en el entorno .net, por ejemplo para el caso de migrations está: Subsonic Migrate Me, RikMigrations y Migrator.Net. En un proyecto grande estamos usando este último hace más de medio año con muy buenos resultados.

En particular Knack, un port de Rack a .net, es un proyecto muy interesante que ayudaría a mitigar estas diferencias. Este es un post (en inglés) explicando su importancia: http://www.robustsoftware.co.uk/post/2131023052/why-rack-should-matter-to-dot-net-developers y este un video: http://www.viddler.com/explore/remitaylor/videos/52/

Otras sesiones que hubo en las que no participé pero me hubiera gustado son NoSql, F# y Azure/Cloud (de las que me acuerdo).

Entre alguna sesión y otra (o quizás entre una empanada y otra) le pregunté a Carlos Peix sobre la charla sobre Generación de la UI a partir del modelo, me dijo que se habló de Naked Objects y que Juan Vidal contó de un producto de Ivolutia que vienen usando hace un tiempo ya, con buenos resultados en el contexto de aplicaciones LoB (Line of Bussiness). Se pueden realizar customizaciones para las pantallas que así lo requieran y destacó que en general son pocos los ajustes necesarios.
También hablamos con Claudio Meschini sobre Quetzal su proyecto open source que genera no sólo la UI sino otros artefactos a partir del modelo usando templates.

La devolución de todos en el cierre fue muy positiva, se planteo realizar reuniones con mayor frecuencia y se concordó que 3 veces al año era un número / meta razonable y se remarcó que cualquiera podía proponerlos.

Muchas gracias a quienes se ocuparon de la organización: Carlos Peix, Guadalupe Casuso y Miguel Saez y a los sponsors.

Un placer haber compartido con gente que tiene pasión por el desarrollo de software, ganas de intercambiar ideas, aprender y difundir buenas prácticas.

Links

Post sobre la sesión de unit testing en el blog de Nelo Pauselli

Post y fotos del evento en Code and Beyond

Alt.net Argentina: http://altnet-argentina.pbworks.com

Grupo de discusión de alt.net Argentina: http://groups.google.com/group/altnet-argentina

Alt.net Hispano: http://www.altnethispano.org

Anuncios

4 comentarios en “Alt.net Open Space Buenos Aires 2010

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s