Month: May 2012

Nueva carrera de informática

Ayer el Consejo Superior de la Universidad Nacional de Quilmes, el pleno, por unanimidad aprobó la propuesta de creación de la carrera y el plan de estudios propuesto para la Licenciatura en Desarrollo de Software.
Personalmente participé de algunas de las discusiones de plan de estudios de esta carrera y puedo decir que el plan está muy bien (al menos para mi gusto). Un detalle a destacar es el nombre de la carrera, el cual refleja claramente el foco: Desarrollo de Software. Esto marca un diferencia respecto de la mayoria de las carreras de informática que suelen hacer referencia a Análisis de Sistemas, Sistemas de información, Informática, Computación, etc,. etc.
Esta licenciatura comprende 10 semestres, con un total de 41 materias semestrales (de distintas cargas horarias), los primeros 4 semestres serán de materias comunes a la TPI (16 en total). En los siguientes 6 semestres, hay 4 materias obligatorias y 3 optativas que sirven tanto para la licenciatura como para TPI, 2 materias que se cursan con la Diplomatura en CyT, y 16 materias nuevas, exclusivas de la Licenciatura.
¡Mis felicitaciones a Fidel a todo el equipo de TPI por este gran hito!

Build Servers Initiative

A couple of weeks ago I started helping some teams to set up their continuous integration servers. There are several tools and strategies you can use to accomplish this task. In our case, we decided to use MSBuild as the automation tool and TeamCity as the continuous integration server. Team City provides several features to automate the build process, but we preferred to minimize the dependencies with Team City for 2 main reasons:
  • We want to be able to run the automated build process in the devs machines.
  • We want to be able to use another build server.
For us, the standard build process includes:
  • Running source analysis (StyleCop)
  • Running code analysis (FxCop)
  • Compiling (CS compiler)
  • Running tests (MSTest)
  • Running coverage (VS build-it coverage feature)
MSBuild only provides built-in support to compile, so for the rest of these tasks we had to do some research. A couple of weeks ago Gabi Iglesias posted about some of the spikes we did.
After research and spiking, this is the approach we finally took:
  • To run StyleCop and FxCop we are using MSBuild Extension Pack, an open source project published at CodePlex
  • To run MSTest and coverage we are using home made MSBuild tasks developed by our Engineering Excellence team (these tasks were developed back in 2008, so for our new initiative we had to update them)
In upcoming posts we will provide more details on this topic.

Desafio de diseño: objetos inteligentes

Estaba preparando un ejemplo para algo3 cuando me surgió esta cuestión.

Como ya he mencionado en algo3 solemos programar juegos. En general los juegos tienen ciertos personajes que van actuando autonomamente con el paso del tiempo, a estos objetos es a lo que llamo objetos inteligentes. Por poner un ejemplo, tomemos el clásico juego de naves Gálaga, donde las naves enemigas actuan autonomamente con cierta lógica interna.

Cuando llevamos esto a código siguiendo el paradigma orientado a objetos, estas naves solo debieran tener un método público del tipo actuar, el cual seria invocado desde el GameLoop. Dentro de dicho método, cada nave decidiria si moverse en una determinada dirección, o si disparar, o si hacer ambas cosas al mismo tiempo, etc. Con el fin de que dicho método no quede demasiado largo, generalmente extraeremos varios métodos privados: uno con la lógica de movimiento, otro con la lógica de disparo, etc, etc.

Ahora la cuestión es: ¿como escribir pruebas unitarias para esta clase cuando tiene un solo método con tanta lógica? Es claro que es posible escribir pruebas unitarias para estos casos, pero si intentan hacerlo verán que no les quedará código muy feliz, pues el código de arrange de cada prueba podria resultar bastante largo y engorroso de escribir debido a todos los caminos posibles dentro del método bajo prueba. Una opción para evitar esta situación podria ser hacer públicos los métodos privados y asi escribir pruebas por separado para la lógica de movimiento, para la lógica de disparo, etc, etc, pero esto implicaría poner públicos ciertos métodos que naturalmente seria privados, con el solo fin de hacer pruebas. Definitivamente esta opción me hace ruido.

¿Entonces? Tengo una propuesta, pero será parte de otro post, mientras tanto, los invito a lo que piensen.

Continuará….

Adopción de C# en aumento

Desde hace ya un par de años el Algo3, les permitimos elegir el lenguaje de programación a utilizar en el TP grupal. En un comienzo la elección estaba restringida a Object Pascal (Delphi) o Java y en la actualidad es Java o C#. Históricamente la mayoría de los alumnos se han inclinado por Java en una proporción de 4 a 1 (y estoy siendo generoso con C#).

Pero resulta que este cuatrimestre, particularmente en el curso JT (que es en el que estoy yo) ha habido una adopción masiva de C#, de 9 grupos, al menos 6 han elegido C#. La única explicación que se me ocurre para esta situación particular del curso JT es la influcia de los docentes.

En este curso somos 4 docentes: Pablo, Gabi, Diego y yo. Este cuatrimestre, desde que comenzamos a estudiar lenguajes de tipado estático, la mayoría de las clases las dieron Gabi y Diego, ambos afines a C#, por lo cual casi todos los ejemplos en nuestra clase fueron mostrados en C#. Esto, sumado al buen manejo de Gabi y Diego del Visual Studio, resulta una influencia considerable para los alumnos.

Pero la verdad recien la sabremos al final del cuatrimestre cuando hagamos la clase de cierre.

Mi enfoque hacia la arquitectura de software

Cuando me tocó estudiar este tema formalmente como alumno, recuerdo que lo hice desde la perspectiva del proceso unificado. Luego por iniciativa propia estudié el tema desde otras perspectivas/fuentes. Pero creo que lo que realmente me hizo entender el tema fue poner manos a la obra. Con esto en mente, hace unos dias me senté a preparar mis clases sobre este tema para mi materia de UNQ. Revisé algunas fuentes tradicionales, notas personales  y algunas fuentes más recientes y pensé algunos ejercicios para hacer con lo alumnos de cara a intentar bajar a concreto algunas cosas que pueden llegar a resultar abstractas.

Como mencioné en un post anterior, decidí encarar el tema presentando un problema, el cual nos fue guiando por los atributos de calidad hacia la arquitectura como disciplina. Luego en una segunda clase, vimos algunas definiciones formales y estilos de arquitectura con algunos ejemplos concretos razonando sobre código las implicancias de cada estilo. La tercer clase la decicamos a ver algunas técnicas concretas para atacar la definición de arquitectura de una aplicación. Finalmente en una cuarta clase, los alumnos realizaron presentaciones de ciertos estilos de arquitectura utilizando el mismo enfoque que habiamos utilizando previamente para presentar otros estilos.

Como material de estudio complementario a lo visto en clase elegí:

En algunas clases posteriores volveremos sobre algunas temas de arquitectura (por ejemplo para analizarla en el contexto de distintas metodologias de desarrollo), pero ya como cuestión colateral y no como tema central de una clase.

Nueva edición del curso de Ingeniería de Software de Berkeley

Hoy comienza una nueva edición del curso  online de Berkely sobre el que estuve escribiendo tiempo atras: Software Engineering for Software as a Service. En esta ocasiónvoy a ser parte del staff del curso: puntualmente voy a estar colaborando en los foros y en el armado de los exámenes. Para esta nueva edición hay varias mejoras: nuevos videos, más ejercicios y bug fixes entre otros.
Los interesados pueden inscribirse gratuitamente en https://class.coursera.org/saas.

 

¿Qué hacer con la basura electrónica?

El fin de semana estuve haciendo un poco de limpieza y me encontré con un par de cosas para tirar: pilas no recargables, (restos de) teléfonos celulares, cargadores de teléfonos celulares, auriculares, etc, etc. y me surgió la pregunta en cuestión: ¿que hago con esta basura electrónica?

Instintivamente entré a la página de Greepeace con la esperanza de encontrar algo información. Escontré bastante información al respecto, pero ninguna dirección concreta de adonde llegar mis residuos. Entonces les escribí un mail con mi inquietud. Abajo transcribo la respuesta que me envió Greepeace:

Actualmente no existe en nuestro paìs un sistema de gestiòn que permita desechar en algun lugar los aparatos electrònicos obsoletos y luego ser reciclados.

Con la aprobación de la media sanciòn de la Ley de Basura Electrónica en la Cámara de Senadores hemos dado un gran paso para alcanzar la soluciòn al problema de las pilas, baterías, lamparitas de bajo consumo, computadoras y el resto de los productos electrónicos. Esta ley obligará a las empresas fabricantes e importadoras de todo tipo de productos eléctricos y electrónicos a hacerse cargo de sus residuos y a establecer lugares donde poder descartar adecuadamente este tipo de basura para que tenga un proceso adecuado de reciclado. 

Baterías recargables en desuso
Por el momento sólo existen en Capital Federal puntos de recolección para que puedas llevar baterìas recargables en desuso. Estos lugares fueron implementados como consecuencia de la Resolución de la Agencia de Protección Ambiental respecto del Programa de Pilas y Baterìas recargables. Para saber donde estàn estos lugares podes ingresar en el siguiente link: http://www.buenosaires.gov.ar/areas/med_ambiente/apra/des_sust/res_esp/empresa_recoleccion.php?menu_id=32341

CPU, Accesorios, Monitores en desuso
Si vivis en Capital Federal y tenès algun monitor, mouse o CPU que ya no uses màs y quieras donar podès llevarlo a Fundación Equidad quienes reacondicionan computadoras y las donan a escuelas que no tengan equipos informàticos. Mas info: http://www.equidad.org/

En Rosario (Pcia de Sta Fe) existe la organización Noto Tau. Si tenés algùn monitor, mouse o CPU que ya no uses màs y quieras donar para reutilizar contactate: http://www.tau.org.ar 

Gestión de Residuos Electrónicos
Silkers SA es la empresa líder en la Argentina en la Gestión Sustentable de los Residuos de Aparatos Eléctricos y Electrónicos. La empresa brinda servicios de recolección, separación, valorización y reciclado del e-scrap, recuperando importantes recursos naturales y minimizando el impacto ambiental. Mas info: http://www.silkers.com.ar/ 

Programa ECOMOTO
La empresa Motorola cuenta con 39 puntos de recolección donde reciben baterìas recargables en desuso y equipos celulares -de todas las marcas- en desuso.
Mas información podés entrar a la página de la empresa y consultarles por su programa ECOMOTO.

No hay mayor información respecto a otros lugares en el resto del país que cuenten con habilitaciones correspondientes para retutilizar o tratar este tipo de residuos. Es por ello imperiosa la necesidad de contar con un sistema de gestión en todo el país, con puntos de recolección accesibles al consumidor y lugares adecuados para su posterior reciclado.


Algunas noticias de Agiles 2012

La sede es Córdoba y los chairs del evento son Emilio Gutter y Pablo Rodriguez Facal. Pero nada de esto es noticia, pues son cuestiones que fueron publicadas hace ya un par de meses.

Lo que si puede considerarse novedad es que se confirmó que Tincho Salias será Keynote speaker de este evento lo cual es una noticia doblemente buena: una vez más tendremos un keynote speaker latino y conociéndolo a Martín su keynote seguramente será sobre prácticas concretas no muy lejanas al código.

Otra novedad es que ya está abierto el call for papers con fecha límite el 16 de Junio

Introducción a la arquitectura de software

El lunes pasado empezamos a meternos en temas técnicos, más precisamente en cuestiones de diseño de alto nivel, cuestiones comunmente llamadas de arquitectura. A diferencia de la mayoría de la bibliografía decidí saltar las definiciones y presentar el tema a partir de una problemática concreta siguiendo algunas ideas de Mike Cohn y Less Bass.

En clases anteriores habíamos trabajado sobre modelado de negocio, identificación de user stories y especificaciones en forma de features (bdd), para esto trabajamos con un material que yo mismo preparé hace un par de años para un workshop que dicté en un Agile Open.

Cuando realizamos este workshop en clase habíamos debatido sobre algunas user stories que no seguian el criterio INVEST, cosas del estilo “Como responsable de soporte del sistema quiero que el acceso a la base de datos se haga utilizando el componente XYZXYZ” o “Como responsable máximo de la aplicación quiero que la misma esté disponible 99.999% del tiempo“. En su momento clasificamos estas stories como system stories (acorde a la propuesta de Mike Cohn). La particularidad de las system stories es que resultan transversales a todo el sistema. Una forma en que me gusta caraterizar estos distintos tipos de stories es diciendo:

  • Las user stories describen lo que el sistema debe HACER, o mejor dicho lo que deben permitir hacer al usuario.
  • Las system stories describen lo que el sistema debe SER, o sea, describen propiedades del sistema.

Estas propiedades del sistema son inherentemente transversales a las user stories. En una época eran llamadas requerimientos no funcionales y luego fueron renombradas como atributos de calidad que es el nombre técnico con el que se las referencia en la actualidad. En alguna bibliografía recuerdo haberlas visto caraterizadas como *ilities, en referencia al sufijo que suelen tener: scalability, availability, security, portability, interoperability, testeability, etc, etc.

A partir del análisis de estos atributos de calidad en el caso particular de la aplicación en cuestión, es que uno determina ciertas tácticas para cumplir con ellos. En un paso posterior buscaremos un estilo de diseño que nos ayichude implementar las tácticas elegidas.

Veamos un ejemplo concreto. Trabajando en conjunto con nuestro product owner identificamos una system story que hace referencia a cierta disponiblidad de la aplicación. Para intentar asegurar la disponiblidad deberiamos en primer lugar utilizar alguna táctica para ser capaz de detectar fallas en la aplicación que puedan llegar a interrumpir el servicio (fault detection). Al mismo tiempo deberiamos contar con alguna táctica que determine como accionar en caso de detectar que el servicio ha sido interrumpido, o está por ser interrumpido (fault recovery). Complementariamente podriamos utilizar alguna táctica para intentar evitar las fallas (fault prevention).
Algunas tácticas posibles para encarar estas tres cuestiones son:

  • Fault detection: ping/echo y heartbeat
  • Fault recovery: voting, reduncancy y shadow operation
  • Fault prevention: removal from service, transaction y process monitor.

(no traduje estas estrategias para facilitar la búsqueda en caso que alguien pretenda ahondar en el tema)

Finalmente una vez elegidas las tácticas concretas, se elige un estilo de arquitectura de que nos permita implementarlas.

Todo este proceso aqui descripto forma parte de lo que denominamos “Definición de arquitectura”.

Continuará…

Sobre los primeros egresados de TPI

Como mencioné anteriormente, tuve el honor de ser invitado a formar parte del jurado de evaluación del trabajo de inserción profesional de Nahuel Garbezza, egresado de la primera promoción de la Tecnicatura en Programación Informática de UNQ. Los otros miembros del jurado fueron Nicolás Passerini  y Hernán Wilkinson.

Además de ser un gran honor, fue una experiencia interesante. El trabajo en cuestión consistió en desarrollar una herramienta de BDD para Pharo Smalltalk (algo así como un análogo a Cucumber). Una vez aceptada la propuesta de ser jurado recibí el trabajo y lo fuí leyendo a medida hacia algunas pruebas con la herramienta y revisaba el código. El trabajo estaba muy bien escrito, lo cual no me extraña, ya que la directora del trabajo fue Gabi Arévalo. Desde el punto de vista técnico la herramienta estaba muy bien, con un amplio set de pruebas automatizadas y una cobertura del modelo por encima del 70%.

La defensa del trabajo tuvo lugar el viernes pasado a continuación de la defensa de Federico Sawady, el otro egresado de esta primera camada de TPI.

El trabajo de Federico (dirigido por Fidel) consistió en la implementación de un sistema de tipos para el lenguaje Gobstones que es utilizado en las primeras materias de programación en TPI.

Las defensas consistieron en presentaciones de 45 minutos seguidas por preguntas/comentarios de los jurados y del público en general. Entre el público se encontraban profesores, alumnos, familiares, autoridades de la universidad y gente de la Fundación Sadosky.

Mis felicitaciones a los egresados y al equipo de dirección de TPI por el gran trabajo que estan haciendo.