Categoría: academia

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.

Primeros egresados de la tecnicatura en programación (UNQ)

El viernes próximo la Tecnicatura en Programación Informática de UNQ (carrera de la que soy docente) tendrá sus primeros dos egresados: Federico Sadaway y Nahuel Garbezza. Será a partir de las 18 horas cuando ambos alumnos defiendan sus correspondientes trabajos finales de carrera (formalmente llamados trabajo de inserción profesional).

El trabajo de Federico se titula «Formalización e implementación de un sistema de tipos para el lenguaje de programación Gobstones» personalmente no estoy muy familiarizado con Gobstones, solo se que se utiliza en las primeras materias de programación de la carrera.

Por su parte el trabajo de Nahuel se titula «Desarrollo dirigido por comportamientos en Pharo Smalltalk» y con este sí que estoy bastante familiarizado ya que soy uno de los jurados evaluadores.

Por el momento no voy a entrar en más detalles, solo les digo que si desarrollan en Pharo, el trabajo de Nahuel puede resultarles de gran interés. Luego de la defensa dedicaré unas lineas más extensas la experiencia de ser jurado y también al trabajo de Nahuel.

Algunos números sobre el curso de Ingeniería de Software de Berkeley

Ayer recibí el mail con el certificado de haber completado el curso y junto con ello, algunos datos interesantes.

  • Unos 20 mil estudiantes vieron al menos una de las clases.
  • Unos 10 mil estudiantes intentaron resulver al menos un questionario o uno de los ejericios.
  • Unos 3 mil quinientos estudiantes completaron el curso.

El curso se repetirá hacia mediados de mayo y una segunda parte  cubriendo Rails avanzado, trabajo en equipos, código légacy, performance y seguridad será ofrecida hacia finales de octubre.

Sobre los trabajos finales de carrera en FIUBA

Para recibirse de ingeniero en informática en la UBA es necesario realizar un trabajo final, el cual puede ser una tesis o un trabajo profesional.

La tesis es un trabajo de investigación de caracter individual, que se realiza bajo la dirección de un profesor y que es evaluado por tres jurados entendidos en el tema de la tesis. Esta tesis es una tesis de grado y como tal no require extender la frontera de conocimiento, o sea no es necesario un aporte de transcedental a la materia en cuestión. En algunos casos este tipo de tesis suele denominarse tesina. Un esquema típico de una tesis de este nivel en un área de ingeniería podría consistir en:

  1. Caraterizar un problema
  2. Analizar las soluciones actuales (estado del arte)
  3. Proponer una solución distinta (por ejemplo utilizando una tecnologia de reciente aparición)
  4. Analizar pros y contras del nuevo enfoque propuesto.

Una particularidad de las tesis en Fiuba es que requieren que se implemente algo, o sea: hay que codear.

El trabajo profesional es la realización de un «trabajo de la vida real».  El mismo se puede realizar de a dos alumnos y requiere la supervisión de un profesor el cual también se encarga de la evaluación del trabajo. En ocasiones los alumnos aprovechan el auspicio de sus empleadores para realizar su trabajo profesional en el contexto de su actividad laboral y de esa forma «matar dos pájaros de un tiro».

En ambos casos es necesario presentar un anteproyecto y a partir de la fecha de aprobación del mismo, los alumnos cuentan con un periodo de un año para presentación del trabajo/tesis. Generalmente este anteproyecto suele presentarse cuando el trabajo ya cuenta con cierto grado de avance. Tradicionalmente (y en la actualidad la cuestión sigue igual) la mayoría de los alumnos opta por la realización de trabajo profesional en lugar de tesis, tal vez sea porque a simple vista genera menos incertidumbre que la realización de una tesis. O sea, la tesis es un trabajo de investigación y la carrera no nos prepara para realizar trabajo de investigación. En general al llegar al final de la carrera todo alumno tiene experiencia investigando como utilizar una herramienta o como resolver un problema técnico, pero ello es bastante distinto al trabajo requerido para realizar una tesis.

En está página se listan las tesis realizadas por los ingenieros en informática de la UBA hasta el día de hoy.

En mi caso, yo elegí hacer una tesis, pues tuve la suerte de por esas casualidades de la vida cruzarme con un tema que me inquietó y que me motivó a realizar un trabajo de investigación que luego se convirtió en mi tema de tesis (en su momento escribí al respecto).

Continuará…

Maestria Tecnología Informática Aplicada en Educación: primer año completo

Hace un par de semanas me dieron la última nota de primer año. Todo bien, terminé primer año aprobando las correspondientes 3 materias. Me parece que es un buen momento para compartir algunas impresiones.

La organización general de la maestría desde el punto administrativo está bien. Por otro lado la organización de las materias me pareció dispar.

Las materias Educación a Distancia y Tecnología me parecieron bien organizadas, brindando un acompañamiento constante y cercano a los alumnos. Por otro lado la materia Psicologia Cognitiva fue bastante más «informal», la cátedra publicaba el contenido a estudiar y habilitaba los foros para consulta, dejando que el alumno se auto organice para el seguimiento de la materia.

Desde el punto de vista del contenido, Educación a Distancia fue sin duda la mejor materia a mi parecer, no solo por el contenido en si mismo, sino también por la forma en que el equipo docente realizaba la mediación. No puedo de dejar de destacar en esta materia el desempeño de la profesora Alejandra Zangara cuyas clases presenciales fueron impecables y su feedback fue muy preciso y orientador.

El viernes próximo comienzo a cursar el segundo año, el sábado les cuento.

Sobre el curso de Ingeniería de Software de Berkeley

Hace un tiempo comenté que estaba tomando un curso online de la Universidad de Berkeley ofrecido en la plataforma online de la Universidad de Standford. Ayer rendí el último examen y lo completé.

El curso me gustó, aprendí algunas cosas y reforcé otras, pero debo decir que esperaba algo distinto. El título del curso era «Software Engineering for SaaS» , pero de SaaS se vió muy poco. Respecto a esto algunos alumnos opinaban que el hecho de usar Ruby/Rails ya cumplia con el contenido de SaaS. Yo personalmente no comparto, creo que Ruby/Rails es un solo un framework, muy productivo sin duda, pero que implementa patrones que han estado en uso por varios años como MVC y Active Record y que pueden o no usarse para hacer aplicaciones SaaS. Al mismo tiempo, temas como escalabilidad, que resultan muy relevantes en aplicaciones SaaS, apenas fueron mencionados.

Más allá de los contenidos, me gustó mucho la dinámica y tengo ganas de hacer algo similar ofreciendo parte del contenido de la materia que estoy dictando en UNQ.

Resultados del relevamiento sobre POO

Hacé un tiempo publiqué una encuesta para relevar los lenguajes utilizados para la enseñanza de la POO. Esta encuesta la distribuí entre conocidos y también en algunas listas de correo en las que participo. En total obtuve 143 respuestas provenientes de 6 paises distintos de habla hispana (Argentina, Uruguay, Peru, España, Republica Dominicana y Guatemala).

Básicamente la encuenta preguntaba sobre el lenguaje utilizado en la primer materia de objetos, aquella en la que el alumno se cruza por primera vez con los conceptos de polimorfismo y herencia. También se preguntaba sobre la materia/institución y la época, pues entiendo que a lo largo del tiempo ha habido una variación.

El análsis de los resultados me ha llevado un tiempo, pues no se trata de contar resultados individuales, sino que es necesario agruparlas por institución y época.

Los resultados han arrojado que en los casos anteriores a 1990 los leguajes utilizados han sido Object Pascal (Delphi) y Smalltalk.

Durante los años 90 los lenguajes predominantes son C++ y Smalltalk

Ya  a partir del año 2000, comienza a descatarse Java en desmedro de C++ y Smalltalk.

Más allá de estos números, se confirma mi hiṕotesis, la gran mayoria de las intituciones utilizan UN solo lenguaje para la enseñananza del Paradigma OO en la primer materia dedicada al tema.

Con estos resultados puedo seguir trabajando en mi paper sin cambiar el enfoque ya que mi teoría se confirma. Cuando tenga el primer draft lo publicaré en este mismo medio.

Gracias a todos los participaron de la encuesta.

Primer cuatrimestre 2012: ¡largamos!

Asi es, largamos y casualmente en esta ocasión el cuatrimestre comenzó al mismo tiempo en FIUBA y en UNQ. Curiosamente la mi mátricula de alumnos se invirtió respecto del cuatrimestre pasado: mientras que en Ing. de Software (UNQ) tengo menos alumnos (pasé de 15 a 7) en Algo3 (FIUBA) tenemos alrededor de 50 alumnos (casi el doble que el cuatrimestre anterior).

El comienzo fue bastante movido, de hecho las clases comenzaron la semana pasada y recien ahora me pude hacer un tiempo para escribir un par de líneas. Algo interesante es que en ambas materias noto una mejora respecto del cuatrimestre anterior:

  • En Algo3, a pesar de tener más alumnos, las cantidad de consultas sobre el TP0 se redujeron notablemente. Lo cual a mi entender tiene que ver con 2 cuestiones: el enunciado del TP fue menos ambiguo y al mismo tiempo las explicaciones en clase previas a la entrega del TP0 fueron lo muy claras.
  • En Ing. de software, me asignaron un aula ¡excelente!: pizarra blanca enorme, mesas altas con ruenas y banquetas. Por otro lado tengo un alumno del  cuatrimestre pasado que me va a estar dando una mano como colaborador, lo cual espero nos permita tener un mejor seguimiento de los alumnos.

Si bien las materias tratan sobre distintos tópicos, en ambos casos estamos poniendo un importante énfasis en las pruebas: TDD, BDD, etc.

Otro punto común es que en ambos casos vamos a estar utilizando como herramienta de apoyo la plataforma Moodle.