Charla orientativa para estudiantes de secundaria

El pasado viernes estuve participando de un encuentro de orientación vocacional en la sede del CBC de Ciudad universitaria. Casualmente yo había participado de un encuentro similar en el mismo lugar en el año 1997, cuando estaba terminando la secundaria. A diferencia de aquella vez, en esta ocasión fui orador y no oyente.

El encuentro estuvo organizado por el área de orientación vocacional del CBC y pretendia reunir a representantes de las distintas carreras de informática dictadas en la UBA. En este sentido habia una persona de la Facultad de Ciencias Económicas, donde se dicta la carrera de Licenciatura en Sistemas de información de las Organizaciones y una alumna avanzada de la Facultad de Ciencias Exactas y Naturales, donde se dicta la carrera de Licenciatura en Ciencias de la Computación. Y finalmente estaba yo, en representación de la Facultad de Ingeniería, donde se dictan las carreras de Ingeniería en Informática y Licenciatura en Análisis de Sistemas.

El encuentro duró unas dos horas y comenzó con una breve charla de un representante de la CESSI, quien habló sobre las oportunidades laborales en Argentina en la industria del software.

Aquí estan las diapositivas que utilicé durante en encuentro.

ASSE 2014, ya casi estamos

El programa del simposio ya está listo. Por un lado tendremos las actividades tradicionales del simposio: presentación de trabajos y conferencistas y por otro lado tendremos algunas actividades nuevas.

En lo que respecta a presentación de trabajos, tendremos 19 presentaciones de trabajos originales y 8 comunicaciones orales de trabajos que han sido presentados en otros simposios internacionales.

En lo que respecta a las conferencias tendremos 2 de sponsors (Red Hat y Pragma) y 3 más de invitados especiales. En este sentido contaremos con Esteban Feuerstein (Fund. Sadosky) quien hablará sobre Big Data, Alvaro Ruiz de Mendarozqueta y Juan Gabardini quienes hablarán sobre Métodos ágiles. La descripción de estas conferencias está publicada en la página del simposio.

Adicionalmente a la clásicas actividades mencionadas, tendremos dos novedades.

La primer novedad es un taller de Arquitectura emergente dictado por Diego Fontdevila (requiere inscripción aparte pues tiene cupos limitados). Pueden encontrar más detalles de este taller aquí.

La segunda novedad es un espacio de debate sobre Enseñanza de la ingeniería de software. Este espacio tendrá lugar el Jueves 4 de Septiembre a partir de las 16.30 hs. La dinámica de este espacio estará dividida en dos actividades y Luciana y yo seremos los facilitadores. En primer lugar tendremos sesiones en formato Lightning talks, la idea es que cada participante que lo desee pueda presentar en 5 minutos su enfoque para la enseñanza de ingeniería de software y las dificultades que suele afrontar (puede que el tiempo de presentación varie un poquito dependendiendo de la cantidad de interesados en presentar). Luego de estas presentaciones, pasaremos a un debate con formato Fishbowl.

El detalle completo del programa está disponible en la página del evento.

Clasificación de herramientas para automatizar pruebas de funcionales

Las pruebas funcionales son las que típicamente hace un tester, que más le importa al usuario y sería ideal definir en conjunto con él, pues estas pruebas interactúan con el SUT desde la perspectiva del usuario. Son pruebas que Marrick clasifica como Business Facing.

Para este tipo de pruebas es muy relevante la forma en que las herramientas permiten expresar la prueba, ya que dado que son “pruebas de usuario”, dependiendo de la forma en este planteado el proyecto podríamos querer que estas pruebas sean escritas por el usuario.
En este sentido es que las herramientas para automatizar este tipo de pruebas han adoptado distintos enfoques:

  • Record and Play: permiten “grabar” la interacción del usuario con el SUT para luego reproducirlo. Con este tipo de herramienta, básicamente se ejecuta manualmente 1 una vez cada caso de prueba mientras la herramienta va grabando la interacción de manera que la misma y una completada la grabación las pruebas pueden repetirse tantas veces como se guste de forma automática. Un ejemplo de este tipo de herramientas es SeleniumIDE.
  • Keywork-Driven: este tipo de herramientas permiten definir las pruebas utilizando un conjunto de palabras claves par estructurar la prueba. Luego es necesario escribir cierto código (glue code) para vincular la prueba (expresada con palabras claves específicas) y el SUT. En esta categoría de herramientas entra toda la familia de Cucumber.
  • Data-Driven: este tipo de herramientas permiten especificar la prueba a partir de condiciones expresadas en tablas. Cada tabla es interpretada por por cierto código (glue code) que permite la interacción con el SUT. Las herramientas de la familia Fitnesse entran en este grupo.

Si bien muchas veces las herramientas pueden utilizarse de diversas formas, en general suelen ser concebidas para ser utilizadas de una forma particular (una silla es concebida para sentarse, sin embargo en ocasiones es posible utilizarla para elevar nuestra altura como si fuera una escalera). En este sentido cada herramienta puede verse más orientada con alguno de los grupos mencionados, pero ello no quita que la podamos usar de forma distinta.

Reportes en Jenkins

Si bien últimamente vengo trabajando muy felizmente con Travis, una de las funcionalidades que extraño mucho son los reportes. Cuando trabajo con Jenkins suelo hacer que mis jobs de CI muestren diversos reportes.

Hay dos estrategias para mostrar reportes en Jenkins:

  1. Utilizar las capacidades de reporting de Jenkins, ya sea nativas o con plugins, o bien
  2. Hacer que cada herramienta que forma parte del build genere sus propios reportes y luego simplemente hacer que Jenkins provea acceso a dichos reportes.

Un ejemplo del primer caso es el plugin de Cucumber-jvm que genera un reporte como el de la figura 1.

cucumber_jenkins
Figura 1

Un ejemplo similar pero usando la segunda estrategia sería ejecutar cucumber especificando que genere output HTML y luego usar el plugin Sidebar link de Jenkins para linkear el reporte generado por cucumber. En figura 2 se ve un caso de esta estrategia donde Jenkins provee links un reporte de features generado por cucumber y otro de coverage generado por SimpleCov. La figura 3 muestra cómo configurar los links a los reportes una vez instalado el plugin.

reportes_jenkins
Figura 2

 

sidebar_links
Figura 3

 

Notas del Primer Foro ProgramAR

El encuentro comenzó con una breve bienvenida de Ernesto Golom (Conectar Igualdad) y Fernando Schapachnick (Fundación Sadosky) quienes luego dieron lugar al keynote a cargo de Diego Golombek. Como de costumbre la presentación de Golombek fue muy entretenida, llena de curiosidades y con una cierre alentador.

Luego pasamos a la acción, nos reunimos en grupos de trabajo que habían sido armados de antemano por los organizadores. Cada grupo tenía asignado un moderador y una notebook para que algún miembro de cada grupo oficiara de escriba. La organización había preparado un conjunto de preguntas disparadoras para el debate de los grupos.

En mi grupo el debate se centró en la enseñanza de las ciencias de la computación como parte obligatoria de la curricula primaria y secundaria. Si bien yo comparto esa visión no creo que sea implementable a corto plazo por una simple razón: no hay suficientes docentes preparados para llevarla a cabo. Al mismo tiempo creo que si el objetivo es fomentar la vocación de los jóvenes por las ciencias de la computación, entonces debiéramos considerar una estrategia de corto/mediano plazo que contemple actividades por fuera de la educación formal, iniciativas como Nahual o Code Club están justamente en esa línea.

El cierre del encuentro estuvo otra vez en manos de Ernesto y Fernando quienes leyeron algunos extractos de lo trabajado por los grupos.

La iniciativa continúa con otros 6 foros que sea realizarán a lo largo del país en lo que resta del año. Al mismo tiempo hay un espacio habilitado en la web para continuar debatiendo y trabajando en forma virtual.

Algo que me sorprendió para bien es la cantidad de organismos partícipes de esta iniciativa: Presidencia de la Nación, Conectar Igualdad, Fundación Sadosky, Anses, Educar, Ministerio de Educación y Ministerio de Ciencia y Tecnología. Ojalá esta iniciativa se convierta en política de estado y tenga continuidad más allá de la bandera política del próximo gobierno.

Open Space UY 2014, sesiones primera parte

La primera sesión a la que asistí fue propuesta por @danilomerlino y trató sobre testing. En realidad inicialmente fue planteada como gestión de bugs, pero una vez expuesta la problemática, nos la pasamos hablando del testing. Estimo que en la sesión fuimos unas 15 personas. En forma resumida la problemática que disparó la sesión fue: a pesar de que los programadores hacen sus pruebas unitarias, cuando el software llega a los testers estos encuentran una gran cantidad defectos. Entre las sugerencias habladas para superar esta situación se mencionaron diversas prácticas como ser:

  1. Pair programming / Revisión de pares
  2. Test cruzados entre los programadores
  3. Trabajo más cercano entre programadores y testers
  4. Behaviour-Driven Development

Algunos de los asistentes comentaron haber experimentado bajas en la cantidad de defectos reportados a partir del uso de 1,2 y 3, cosa que también ha sido confirmada por diversos autores (Steve McConell entre ellos).

Yo fui quien hizo la propuesta 3 y junto con la propuesta mostré algunos features de proyectos en los que he participado en el último tiempo. Hay que destacar que si bien esta práctica permite generar pruebas de aceptación automatizadas, esto es simplemente un efecto colateral, el gran beneficio que  genera usar BDD es la charla que se da entre el equipo y el usuario  y los ejemplos de uso resultantes de la misma.

Comparto a continuación algunos links mencionados durante la sesión que pueden resultar de interés:

 

Continuará…

 

Coursera: Curso de Android, Semanas #6, #7 y #8

Estas últimas últimas tres semanas trataron muchos temas interesantes (services, content providers, etc) y los ejercicios me costaron un poco más, no porque fueran más complejos, sino porque las explicaciones fueron bastante pobres.

Los videos de la clase explicaban muchos temas de forma bastante superficial (el que mucho abarca poco aprieta) y al mismo tiempo los ejercicios se concentraban de forma más profunda en algunos temas sin tocar otros. La dificultad radicaba en que con el material de clase no resultaba suficiente para resolver los ejercicios.

A pesar de haber completado las 8 semanas, el curso aún no está terminado, pues hay que hacer un proyecto final en el cual espero trabajar esta semana.

Android Time! (curso gratuito)

Al igual que vengo haciendo los últimos veranos, este verano me he anotado para tomar un curso en Coursera. En esta ocasión se trata de un curso de Android llamado: “Programming Mobile Applications for Android Handheld Systems” ofrecido por la universidad de Maryland. El curso comienza el 21 de enero, tiene una duración de 8 semanas y requiere de una dedicación estimada de entre 3 y 6 horas semanales. Pueden ver más detalles en la página del curso.

Desde la semana pasada están disponibles los videos de las primeras clases que presentan la plataforma Android y las herramientas de desarrollo. Ya los estuve viendo y me parece que el curso será muy interesante.

How to backup Jenkins

There are a couple of plugins out there to backup Jenkins. Some of them focus on jobs configuration while others focus on Jenkins global configuration. All of them have in common that store a file (or set of files) in a certain location in the same box where Jenkins is running. In  my opinion this is not enough because in case of a hardware failure you could lose Jenkins and also the backups.

Maybe there is a plugin that solves this situation but I didn’t find it, so I decided to do the following:

  1. Create a code repository
  2. Create a PowerShell script to copy all jobs configuration files to the repository folder and commit them
  3. Create a Windows Scheduled Task to trigger the script once a day

To write the script mentioned in (2) you need to know some internal details about Jenkins. For each job you create, Jenkins creates a folder with the job name under the location $JENKINS_HOME/jobs. Inside the job folder you will find a lot of files but the only important for us is the config.xml which contains the job configuration.

If this explanation is not clear enough or if you simply don’t want to waste time writing the script, you can take a look at the script I wrote.

One more detail: I am wrapping my PS script with a cmd script in order to redirect the output to a file that I used as a log file.