Nuevos cursos interesantes en Coursera.org

Ayer me llegó un mail de Coursera.org anunciando nuevas 12 nuevas universidades que sumaron cursos a la oferta de la plataforma. Con un rápido vistazo identifiqué algunos cursos que me resultaron interesantes:

Lamentablemente, no tengo suficiente tiempo en este momento, pero en verdad que me gustaria tomarlos todos.

Si tienen tiempo, no lo duden, creo que no se van a arrepentir.

Cómo enseñar/aprender a estimar

Tengo la impresión de que este es un tema muy pobremente tratado en los contextos académicos. Digo esto basado en mi experiencia personal y en lo que he hablado con varios colegas.

En mi caso vi la temática estimación en una clase en una materia, donde el docente realizó una explicación de diversos métodos. Nada más, sólo una explicación teórica. Nada de práctica para pudieramos entener mejor los métodos. Lamentablemente creo que esto no fué una situación aislada, pues he hablado con varios colegas de diversas casas de estudios y la situación no es muy distinta.

Personalmente creo que la estimación, al igual que varias de las actividades de la ingenieria de software, es una actividad que se aprende a partir de la práctica.

Cuando tuve que preparar el tema estimaciones para la materia que dicto en UNQ, determiné utilizar el siguiente enfoque:

  1. Explicar algunas generalidades sobre estimación (quien, cuando, para que, etc)
  2. Comentar brevemente los métodos más difundidos
  3. Explicar en detalle dos métodos
  4. Hacer un ejercicio grupal de estimación en clase
  5. Darles un apunte para lean y refuercen lo explicado en clase
  6. Pedirle a los alumnos que estimen cada tarea de la materia antes de realizarla
  7. Hacer un segundo ejercicio grupal de estimación en clase

El punto (6) lo hemos hecho a lo largo de todo casi toda materia, estimando y planificando cada tarea (esto es: cada alumno lleva un excel donde registra cuando va realizar la tarea de la materia y cuando tiempo estima decicarle). Luego de realizada la tarea, deben registrar también el tiempo real insumido. Con esto apunto a que los alumnos no solo hagan el ejecicio de estimar, sino que también se acostumbren a planificar.

Obviamente este enfoque me lleva más de una clase, pero creo que bien vale la pena.

Mi dream team

Estaba preparando mi clase de Ingeniería de software de mañana, cuando me vino a la mente la idea que quiero compartir con este post.

Resulta que esta clase va a tener dos partes: revisión de las  evaluaciones y visita de un invitado. Estaba pensando en como presentar al invitado cuando decidí que con una simple oración debería ser suficiente:

«Si tuviera que armar un dream team para llevar adelante un proyecto de desarrollo de software, este individuo seria la primer persona que incluiria»

Tal vez alguien lea esto y piense que la persona merecedora de esta frase debe ser un excelente programador, muy habilidoso, muy productivo, etc, etc. Un groso en una palabra. Y en parte sí, lo considero un groso, pero… ¿es un excelente programador? Mmm, si pero no es el mejor que conozco ¿es muy productivo? mmm…si nada nada del otro mundo.

Entonces…¿por qué he de incluirlo en mi dream team? Porque es un profesional capaz de adaptarse al contexto, tiene una sólida formación, es criterioso pero sobre todas las cosas: es una persona en la que tengo absoluta confianza y con la que sé que puedo trabajar armónicamente.

¿Y tú? ¿que cuestiones tendrías en cuenta para armar tu dream team?

Ensalada de lenguajes y el «flexible» Javascript

Durante las últimas 2 semanas estuve trabajando con 4 lenguajes distintos. El día de ayer es un buen ejemplo de un dia extremo. Arranqué el día en Southworks con C# y JavaScript.  Luego por tarde, en Fiuba  me tocó Java. Y finalmente cerré el día el UNQ con Ruby.

En este contexto, me ocurrió el lunes pasado, una situación curiosa que me hizo tomar conciencia de algunas curiosidades de Javascript. Resulta que paśe todo el dia alternado entre JavaScript y Ruby. Implementé 1 user story completa y la dejé otra a la mitad. Dado mi limitado conocimiento de JavaScript, pasé mucho más tiempo codeando Javascript que lo que paśe en Ruby. Al día siguiente continué completando la story que me había quedado pendiente y para la cual tenia que reutilizar algunas funciones JavaScript que había escrito el día anterior. Estaba en plena depuración con el navegador cuando me dí cuenta que en una de mis funciones utilizaba una variables locales que no habia declarado (en JavaScript la variables deben declararse con var). Yo simplemente las usaba sin haberla declarado, tal cual se hace en Ruby. Lo curioso del caso es que el navegador, ejecutaba mi código como si nada, sin arrojar siquiera un warning, ¡ja!¡que peligro!

Una vez, este tipo de situaciones refleja la importancia del uso de herramientas como JSLint.

Fiuba los cria y el Azure los junta

El miercoles pasado estuve dictando un entrenamiento sobre Windows Azure en las oficinas de Microsoft Argentina. No voy referirme en este post ni al entrenamiento y ni a azure sino a un par de reencuentros que viví  (aqui y aqui hay algo de información más específica del evento).

Resulta que entre la audiencia del curso me reenccontré con tres viejos conocidos de FIUBA.

Guille Rugilo, docente de Arquitectura de Software. Si mal no recuerdo a Guille lo conocí cursando Física 1, aproximadamente en el año 1999. Luego compartimos un par de materias más. En el año 2003/2004 trabajamos juntos en Millenium 3, luego volvimos a hacerlo en Huddle Group (lugar en el que Guille sigue trabajando actualmente).

El segundo reencuentro fue con Nico Padula. Nico fue alumno de Algo3 y luego se sumo al equipo docente. Por aquella época yo trabajaba en Huddle y cuando decidí irme, lo postulé a Nico para que me reemplazara. Desde entonces Nico trabaja en Huddle.

El tercero y último personaje es Pablito Roca. Otro ex alumno (y también ex docente de Algo3). Actualmente Pablito es docente de Taller de programación 1, una de las materias mejor dictadas en Fiuba.

Como si fuera poco, el anfitrion del evento fue Ariel Schapiro, otro personaje Fiuba con quien cursé parte de mi carrera y en parte resposable de que yo me haya sumado en Southworks.

Event: Going Deep with Windows Azure

This past Tuesday and Wednesday Microsoft Argentina hosted the Going Deep with Windows Azure training event. We took care of second day sessions:

  1. Azure Service Bus
  2. Hadoop on Azure
  3. Node.js and Java on Windows Azure
  4. Azure Websites
  5. Azure Virtual Machines

I was in charge of the third session. I started talking about the different technologies supported by Azure and then I focused on just 2 of them: Node.js and Java. In both cases I did a brief explanation and then I run a demo.

For Node.js I deployed to azure the Pictionary sample developed by my colleague David Frassoni (alias Harry). I did it from a machine running Ubuntu and using the new Git Publishing feature offered by Azure.

In the case of Java, I create a Java Web application using Tomcat 7, Eclipse for JEE Developers and the Eclipse Plug-in for Windows Azure. I run the application i the local emulator and then showed how to deploy it to Azure.

Here is the slide deck I used in the session.

Agile Open sobre Software Libre

El evento se realizó en las instalaciones de la Facultad de Informática de la Univesidad de Belgrano. El facilitador fue DiegoF y hubo más de 30 asistentes. Tomé varias notas durante el evento, pero lamentablemente perdí mi anotador ese mismo dia, ups!. Por suerte Fer Claverino grabó este video resumiendo algunas de las ideas habladas. También Ingrid escribió al respecto en su blog.

Personalmente me alegró reencontrarme con Mariano Simone  (ex-alumno y colaborador de Algo3), simplemente un fenómeno con quien espero poder trabajar en algún momento. En una sesión que compartimos Marino mencionó algunas aplicaciones open source de FDV Solutions (la empresa donde trabajar actualmente).

Una de las sesiones en las que participé fue sobre motivación y manejo de expectativas en los proyectos open source. En ella compartí algunas de las situaciones que viví liderando la traducción de Pharo By Example.Me llevé varias ideas, pero ninguna completamente convincente.

Otra sesión interesante en la participé fue sobre puntos en común/diferencias entre métodos agiles y proyectos desarrollados con dinámica open source. Uno de los participantes de la sesión fue Federico (no recuerdo su nombre) quien participa en la distribución de Linux/Debian.

Sobre el final del evento hablamos de organizar un open space sobre la temática educación. La idea seria realizarlo hacia fines de Julio para que los asistentes puedan aplicar las ideas surgidas el próximo cuatrimestre. Los mantendré informado.

Team City organizational setup alternatives

The way we decided to manage the continuous integration process is to have one build server per project, that is an exclusive virtual machine with a Team City install running on it. These strategy gives each team full control over the server without having to worry about other projects.

Other alternative, that I think is more frequently used, is to have only one build server for the whole organization and several build agents. When using this strategy the build server concentrate the all build configurations, checkouts the code and delegate to an agent the execution of the build steps. If you have two projects with incompatible software requirements (i.e. one project running on Windows and other on Linux), then you could setup one Windows agent and Linux agent.

Last week I setup an environment following this second alternative. I took 2 machines, in the first one I installed a full TeamCity environment: server and agent, and in the second one I installed just an agent. It was very straight forward. One additional benefit of this setup is that it allows run builds in parallel.

Técnicas para administrar el backlog de proyecto

La semana pasada como parte de mis tareas cotidianas en Southworks, estuve trabajando en la capacitación de un nuevo compañero. Como parte de la capacitación le expliqué algunas técnicas que solemos utilizar para manejar el backlog de nuestros proyectos y luego de hacerlo decidí ponerlo por escrito para que esté accesible para la comunidad en general. Este es el link al post que escribí (está en inglés)

Ojala les resulte útil.

«Los ingenieros son la Victorinox de la sociedad»

Hace unos dias un colega me compartió este artículo del cual extracté el título de este post. La frase pertenece a Adolfo Guitelman, vicepresidente del Centro Argentino de Ingenieros.

Algunos datos estadísticos que aporta el artículo son:

  • En la argentina se estima que hay un ingeniero cada 6600 habitantes mientras que en paises como Israel y China hay 1 cada 1500.
  • Actualmente se reciben unos 6000 ingenieros por año, de los cuales el 32% egresa de la UTN
  • El tiempo promedio para que un ingeniero se reciba es de ocho o nueve años
  • En FIUBA, durante 2011, egresaron unos 450 ingenieros
  • En ITBA durante 2011, egresaron 240 ingenieros industriales

 

¿Incluiran esas cifras a ingenieros agronomos? No creo

¿E ingenieros en sistemas/informática/computación? Estimo que si