De vuelta Linux +10 años después

Mi última PC de escritorio la compré allá por 2005 y dejé de utilizarla allá por 2008. Desde entonces he utilizado notebooks. A comienzos de 2013 compré una MacBook Air y desde entonces he vivido con MacOS.

Pero este año decidí volver a comprarme una máquina de escritorio, me compré una mini PC (en otro post hablaré sobre el hardware). La cuestión era qué sistema operativo utilizar, las opciones eran: Windows 11 o algún Linux. Descartar el Windows fue mucho más fácil que elegir la distribución de Linux. Luego hablarlo con un par de colegas y leer algunos foros, los finalistas fueron Arch y Ubuntu. Me incliné por Ubuntu, principalmente porque pensé que tendría menos troubleshooting con los drivers (la última vez que instalé Linux tuve que recompilar el kernel para hacer andar un modem 3G).

Ya teniendo decidido instalar Ubuntu lo siguiente a ver era si ir por un «Ubuntu puro» o alguno de sus «primos» como Mint o Elementary. Finalmente me quedé con Ubuntu y con el sistema de ventanas default.

La instalación fue muy fluída, descargué una imagen, la quemé en un USB booteable y desde ahí instalé. Hice una configuración dual-boot con el Windows que venía de fábrica con la PC porque uno nunca sabe si en algún momento sale un proyecto de desarrollo Windows.

Para mi sorpresa, todo, absolutamente todo me anduvo de una: wifi, bluetooth, micrófono, webcam, impresora y los dos monitores. Impresionante. El dato curioso es que lo único que me requirió más trabajo de lo esperado fue la configuración de la VPN que yo pensaba que andaría de una y sin embargo tuve que hacer troubleshooting y unas operaciones adicionales via terminal.

Luego de esta fluida experiencia, estoy convencido que de ahora en más vamos a pedir uso obligatorio de Linux en las materias a mi cargo. Perdón, corrijo, no vamos a obligar a usar Linux, sino que solo daremos soporte a quienes trabajen con sistemas de la familia unix/linux.

Notas de un cuatrimestre atípico @fiuba

Atípico básicamente por dos cuestiones: un cambio en plan de estudios de la carrera y una situación de movilización y defensa de la educación pública. Vamos por parte.

La situación sin precedentes de emergencia presupuestaria y ataque constante a la educación pública nos llevo a realizar varias acciones de visualización y apoyo, que entre otras cuestiones, nos llevó a realizar clases públicas.

Por otro lado, y al igual que en UNTreF, este cuatrimestre «estrenamos» curso en FIUBA a partir de la implementación del nuevo plan de Ingeniería Informática.

En este sentido, el curso que dicto actualmente está «homologado» como Métodos y Modelos en la Ingeniería de Software 2 (9521 para la carrera de Licenciatura en Sistemas) y como Ingeniería de Software 2 (TA049 para la carrera de Ingeniería Informática).

En lo formal el cambio de plan de Ingeniería Informática tiene un impacto menor en términos de contenidos, pero en la práctica vivimos dos impactos:

  1. Si bien la materia sigue ubicada en cuarto año, hay un cambio en la correlativas que hace que los alumnos puedan llegar habiendo recorrido un camino distinto de materias.
  2. Al mismo tiempo, como la materia no es correlativa de ninguna otra, es posible que esta materia sea la última de la carrera. De hecho este cuatrimestre tuvimos 3 alumnos para quienes esta fue su última materia.

Adicionalmente, debido a el proceso de transición entre planes, tuvimos gente gente en situaciones particulares respecto de las materias cursadas previamente.

A pesar de estos cambios creemos que el curso salió muy bien. Inicialmente parecía que sería más complicado pero luego la cuestión mejoró. Comenzamos el cuatrimestre con un record de inscriptos, según nos informó el departamento: 51 alumnos. Sin embargo, varios nunca aparecieron y en la segunda clase ya teníamos 33. Como de costumbre, durante el cuatrimestre se fueron bajando algunos más y finalmente terminamos la materia con 22 alumnos. Algunos otros números de nuestra encuesta:

  • La encuesta fue contestada por 18 alumnos
  • La evaluación general de la materia: 8,9 / 10
  • La nota promedio de aprobación fue 7,3/10 lo cual representa un mínimo histórico pero al mismo tiempo la conformidad con la nota fue 4,4 / 5.
  • Dinámica de clases fue 4,7/5 lo cual iguala el máximo histórico. Curiosamente algunos alumnos destacaron que lo mejor de la materia fueron las clases presenciales.
  • Respecto del porcentaje de presencialidad/virtualidad, 15/18 indicaron que les pareció indicado mientras que 2 hubieran preferido más virtualidad y 1 más presencialidad.
  • La dedicación semanal extra-clase, según reportaron en la encuesta, fue de 9 horas, sin embargo en el tracking de tareas ese número da 7,9.
  • El NPS nos dió 44

Por otro lado, en la actividad de cierre destacaron dos items accionables hacía adelante:

  • Proveer más material sobre Arquitectura Hexagonal, un tema central de la materia y que este cuatrimestre costó mucho.
  • Revisar la configuración de las reglas de code quality ya que algunas resultaron incómodas, sin sentido y/o demasiado exigentes.

Cierro con algunos comentarios de feedback libre de la encuesta:

«Excelente la materia, por momentos la odie, pero ya al haber terminado, puedo observar que la dureza y el nivel de exigencia valieron la pena y me enriquecieron en todo sentido.»

«Fue la materia en la que más aprendí en lo que va de la carrera»

«Me pareciero muy util el contenido dado y la forma de dictarlos. Me da lástima recién a esta altura de la carrera toparme con esta materia que siento que me hubiera servido mucho en otro momento. Me gustó mucho que se recomienden autores para leer sobre ciertos conceptos, que utilicemos TDD (por más que personalmente no me gusta, ahora le encuentro un gran valor) y sobre todo que hayamos tenido clases presenciales.
Me voy de la materia sintiéndome motivada a mejorar, queriendo investigar y profundizar sobre los temas que aprendí. Muchas gracias por a todo el equipo docente de la materia, me pareció muy bueno todo!»

Nuevos cursos de Ingeniería de Software

A partir del cambio de plan de estudios de la carrera de Ingeniería en Computación de UNTreF, este cuatrimestre tuvimos que cambiar nuestro curso de Ingeniería de Software. Previamente la materia Ingeniería de Software se encontraba al final de la carrera (último año) y ahora, en el nuevo plan, se encuentra en tercer año.

Este cambio impactó en varias cuestiones:

  1. Los conocimientos previos con los que llegan los alumnos. Previamente los alumnos llevaban con unas 35 materias aprobadas, mientras que ahora llegan con alrededor de 20.
  2. El nivel de maduración/experiencia de los alumnos. En general los alumnos de último año ya se encuentran trabajando en el rubro y eso les da una determinada experiencia de programación, resolución de problemas, etc. Los alumnos de tercer año, en cambio, muchos aún no trabajan en el rubro y su experiencia en programación es mucho más acotada.
  3. La cantidad de alumnos, hay muchos más alumnos en tercer año que en quinto. Pasamos de tener unos 8-10 alumnos a tener alrededor de 25.

Al mismo tiempo, si bien el nombre de la materia se mantiene y los contenidos no son tan distintos, el nivel de profundidad cambió radicalmente. Vimos de forma mucho más superficial ciertas cuestiones de gestión, e incluso sacamos algunos temas de arquitectura, mientras que nos detuvimos mucho más en temas de programación y diseño a nivel objetos. Cuando comenzamos a planificar la materia pensamos en varios cambios, pero finalmente decidimos no hacer demasiado cambios «up-front» porque desconocíamos el perfil de los «nuevos alumnos», así que decidimos seguir un enfoque más «adaptativo» e ir viendo sobre la marcha.

Comenzamos el curso con 33 alumnos y lo terminamos con 24, una caída muy importante comparado con nuestros números históricos (en los últimos dos años todos los alumnos que comenzaron la materia, la completaron). Sin embargo creemos que no estuve tan mal, sobre todo porque en un primer momento pensamos que llegaríamos al final con menos de 10 alumnos.

Una consecuencia del cambio de plan de estudio es que muchos de los contenidos que sacamos de la materia, los estaremos dando en una nueva materia optativa, «Ingeniería de Software Avanzada» que comenzaremos a dictar el año próximo. En lo personal nunca dicté una materia optativa, pero es algo que me viene dando vueltas en la cabeza hace un buen rato. Me gusta la idea de que la gente no venga «obligada». Al mismo tiempo, creo que al ser una materia optativa, se presta un poco más a la experimentación.

Hoy, habiendo terminado la materia, estamos muy conformes con el resultado y lo cual es confirmado por el feedback de los alumnos. La evaluación general de la materia, resultado de una encuesta anónima, nos arrojó en promedio 9/10, con una dispersión mínima (fueron todos 8, 9 y 10).

Cierro con algunos comentarios de la encuesta:

«Gran materia, aprendí un montón. Vine de entrada con esa expectativa, ya que compañeros que ya la había cursado me dijeron que era de las mejores de la carrera.»

«Aprendí como es la dinámica de trabajar desarrollando, algo que no se aprende en ninguna materia. Me parece muy valiosa la enseñanza desde cero y terminar aplicando todo junto en un proyecto. Estoy muy agradecido»

«Buena dinámica de clases, menos aburridas que una clase normal.»

(esto último comentario que encantó «menos aburridas que una clase normal» 😉 )

Sobre story points, horas y demás yerbas de estimación

Ayer en una clase de Ingeniería de Software en @untref un alumno me consulto sobre «la tendencia a dejar de utilizar story points».

En lo personal desconocía esa tendencia, pero si me constan un par de cuestiones al respecto de los story points.

  1. Los story points son uno de los artefactos peor entendidos y más mal utilizados de la ingeniería de software. Ejemplos clásico: gente que estima en story point para luego «traducirlos» a horas.
  2. Los story points son herramientas surgidas en un contexto con ciertas condiciones, valores y principios. Como suele ocurrir, utilizar una herramienta fuera del contexto y las condiciones en las que fue pensada, podría no dar los resultados esperados.
  3. En lo personal me animo a decir que me han resultado una herramienta útil pero que hoy en día, intento no utilizarlos. Los story points nos ayudan a lidiar con ítems de distinta complejidad/tamaño. Si logramos particionar los ítems de forma tal que todos tengan «el mismo tamaño», entonces podremos directamente hablar de cantidad de ítems y prescindir de los story points.
  4. Lo que definitivamente no me ha funcionado es estimar/planificar utilizando horas. No digo que no funcione en general, sino que a mi, con el conjunto de prácticas que utilizo(pair-programming, mobbing, gestión de alcance variable, etc), no me funciona. Más aún, en un punto resulta incompatible.

En fin, cada médico con su librito.

Infra para TPs

Desde que comencé a dictar la materia Ingeniería de Software (allá por 2012), siempre apunté por un enfoque muy práctico y lo más parecido posible a la práctica profesional. Entre otras cosas esto implica construir software y ponerlo a correr, en nuestro caso en un ambiente cloud. Para esto he utilizado distintas herramientas/servicios/plataformas a lo largo del tiempo. Comencé con Heroku, luego Okteto , fly.io, Azure y Render. También hay algunas otras que evalué y que por uno y otro motivo descarté sin llegar a utilizarlas en el curso.

Siempre he procurado utilizar servicios que resulten gratuitos para los estudiantes, llegando incluso a pagar yo mismo por el servicio.

Hoy en día estoy usando tres plataformas Render , Neon y un Kubernetes sobre Digital Ocean. En caso de Render y Neon, ambas ofrecen un free tier. Mientras que en el caso de Digital Ocean es posible acceder a 200 dólares de crédito si se cuenta con el GitHub Student Developer Pack. Esta oferta de GitHub incluye un interesante set de recursos gratuitos para estudiantes entre los que se incluyen cursos, licencias y accesos a servicios como Heroku, Digital Ocean y Azure entre otros.

Iniciativa: «El estado de TDD»

Mis colegas residentes en España, Matheus Marabesi y Emmanuel Valverde Ramos, ambos practicantes y estudiosos de TDD, están llevando adelante una encuesta sobre el uso de dicha técnica. En realidad esta encuesta es parte de una iniciativa más amplia que empezaron tiempo atrás: https://thestateoftdd.org/.

Creo que la encuesta es un recursos valioso para todos aquellos que practicamos TDD o que intentamos investigarlo, por ello invito a todos aquellos que practican TDD o que tal vez no lo practican pero les gustaría hacerlo, a que completen la encuesta disponible aquí.

Nuevo proyecto: DevCamp

La semana pasada comencé un nuevo proyecto con uno de mis clientes favoritos. De forma muy resumida me dijeron: «Necesitamos que entrenes a estos jóvenes profesionales que recientemente se unieron a la organización y que a la pasada resuelvan esta problemática de negocio»

No es la primera vez que hago un proyecto de este tipo, en el pasado desarrollé iniciativas similares para Auth0, Onapsis y Southworks. Este tipo de proyectos es sin duda mi preferido, está en muy alineado con lo que hago en la universidad y sinceramente creo que me sale bien (esto lo digo basado en el feedback de participantes e involucrados).

Esta iniciativa tiene como objetivo que los participantes puedan sumarse a un equipo y trabajar con cierta autonomía, aportando valor de manera armónica sin generar ruido en el equipo. Esto requiere tener ciertos conocimientos técnicos y ciertas habilidades «blandas». En este contexto trabajamos sobre prácticas tales como: versionado, coding conventions, Test-Driven Development, Specification By Example, estimación, reporte, versionado e integración continua, diagnóstico y troubleshooting entre otras.

El proyecto recién comienza y durará entre 6 y 8 semanas al cabo de las cuales esperamos que los participantes se sumen a equipos de de desarrollo de la organización. Continuará…

Proyecto trunco: Devs No Ops

La semana pasada cerré un proyecto que había comenzado a mediados de julio. Quien me contrató fue el gerente del área de desarrollo y la idea era ayudar a mejorar el proceso de delivery implementando prácticas de lo que comúnmente se denomina «DevOps» (automatización de pruebas, builds, deploys, etc, etc).

Propuse hace un primer piloto (formalizado en la contratación de un paquete de horas) trabajando con uno de los equipos de desarrollo para entender la dinámica de software delivery de la organización. El panorama parecía prometedor pues detecté muchas oportunidades de mejora tanto en el área de desarrollo como en operaciones y por ello decidimos hacer un acuerdo de trabajo hasta fin de año.

Ya desde el comienzo el trabajo con el área de operaciones no parecía fácil, bastante resistencia y excusas diversas amparadas en regulaciones del sector. Sin embargo, confiaba en poder «subirlos al barco», pues ya he lidiado con escenarios de este tipo en varias ocasiones.

Lamentablemente, no logramos que operaciones «se suba al barco». Más aún, en un punto es como que decidieron patear en contra, negando permisos, dilatando decisiones e ignorando pedidos. Nunca me había pasado algo así. Con lo cual logramos implementar algunas mejoras con los equipos de desarrollo (versionado, análisis estático de código, automatización del build, etc, etc) pero fue muy poco lo que pudimos avanzar más allá de las prácticas que los developers realizan en sus máquinas de desarrollo. Obviamente que tampoco pudimos avanzar en las cuestiones de colaboración dev<->ops que se plantean dentro del paradigma DevOps. Es por esto que un proyecto que inicialmente estaba pensado para durar hasta diciembre, decidimos cortarlo en octubre, el contexto organizacional no estaba listo aún para encarar una transformación de este tipo.

Como siempre, intento ver el vaso medio lleno y por eso incluso en este caso que bien podría interpretarse como un proyecto fallido creo que hay lecciones aprendidas, las dos más importante que me llevo en este caso son:

  • Reafirmo que si el área de «Ops» no compra, es muy poco probable llegar a buen puerto. A partir de esto, yo debería asegurarme que la gente de Ops esté involucrada desde el momento cero (incluso antes de confirmar la contratación).
  • Si la organización no se percibe como una empresa de tecnología, tal vez sea mejor no meterme, mi forma de trabajo no calza bien en esos casos. Como me dijo una vez mi colega Sergio Villagra, hay proyectos que mejor no hacerlos 🙂

Clase abierta bancando la #EducaciónPública

A partir del veto de la Ley de Financiamiento Universitario se están desarrollando diversas actividades en las universidades nacionales.

Es por eso que hoy, luego de más de 20 años de docencia universitaria, di por primera vez una clase pública. Luego de hablarlo con mi equipo docente decidimos que era el momento y la forma más apropiada de hacer visible nuestra posición y nuestro apoyo al reclamo universitario.

Configuramos el aula pública con una pizarra móvil y los escalones de explanada a modo de asiento. Con el ruido ambiente de la Avenida Paseo Coló, nuestra clase de Ingeniería de Software 2 comenzó a las 8:00 AM. Éramos los únicos en la explanada de la facultad pero hacia las 9:00 AM se fueron sumando otros cursos.

En la clase me acompañaron Kevin, Joaquin y Alejo, miembros de mi equipo docente. El tema que abordamos fue medio conceptual y bastante polémico: hablamos de modelos de branching, integración continua, trunk-based development y monorepos.

Creo que a pesar de la constante amenaza de lluvia, la clase salió muy bien en parte porque no llovió.

Como la situación no mejore, me temo que volveremos a repetir la experiencia.

Sobre la investigación en Informática

En estos tiempos en que la educación y sistema científico Argentino están sometidos a desfinanciamiento y cuestionamientos varios, quiero compartir un poco de información general y algunas cuestiones de mi caso.

Al hacer investigación, en primer lugar uno debe encontrar un tema de investigación y debe empezar a estudiar para encontrar algún punto concreto donde potencialmente hacer un aporte. Ya estudiar un tema implica recursos, de mínima hay que leer publicaciones científicas, las cuales en su gran mayoría no son de acceso gratuito. En general los centros de investigación y universidades suelen tener suscripciones pagas para poder dar acceso a sus investigadores. En Argentina, hay ciertas suscripciones cuyo acceso lo gestionaba el ministerio de ciencia y técnica y lo disponibilizaba para diversas instituciones públicas. En este momento, varias de esas suscripciones han caído (no las renovaron). En fin, de alguna forma el investigador estudia, encuentra una idea dónde hacer un aporte y comienza entonces «el camino hacia el aporte». Esto que describo aquí de forma lineal puede no ser tan así, dependiendo del caso puede ser una cuestión más «iterativa», con idas y vueltas.

Ya teniendo un tema (o al menos una pista de por dónde ir) hay que poner manos a lo obra, lo cual puede implicar actividades muy distintas dependiendo del área de investigación. En mi caso, yo trabajo en Ingeniería de Software Empírica, lo cual no suele requerir ningún equipamiento particular, ni compuestos químicos, ni tampoco un laboratorio. Nos basta con una computadora. En este sentido podríamos pensar que para mi caso esta parte del trabajo es relativamente «barata» en términos comparativos con otras disciplinas. Básicamente trabajamos con gente y con datos. Puede que necesitemos de algunas herramientas no gratuitas (software licenciado, algún servicio online, etc), pero en general de costo bastante accesible (algunos cientos de dólares). Es importante destacar que dentro de la informática hay otras temáticas muy distintas (por ejemplo todo lo relacionado a Inteligencia Artificial) y que pueden tener necesidades de recursos/infraestructura también muy distintas.

No voy a entrar en detalles pero básicamente aplicamos el método científico y en algún punto llegamos algún hallazgo que consideramos que agrega valor y «expande la frontera del conocimiento». Es momento de publicar, pues según las reglas del sistema la real medida de avance es la publicación. Escribimos un artículo y lo enviamos a una conferencia o a una revista. La publicación tiene dos objetivos: validación y difusión. Para publicar, ya sea en una conferencia o en una revista, hay que pasar por un proceso de revisión por pares. Los revisores evaluarán nuestro artículo considerando diversas dimensiones que obviamente incluyen el valor de nuestro aporte, pero también la rigurosidad del proceso de investigación y la presentación (o sea, qué tan bien escrito está el artículo). En el «caso feliz», nuestro artículo será aceptado para publicación lo cual nos pondrá muy contentos pero traerá seguramente aparejado un desembolso de dinero. En el caso de las conferencias tendremos que afrontar los gastos de la participación en la conferencia que básicamente son la inscripción y la logística de participación (traslado, alojamiento, viáticos, etc). Simplemente a modo de ejemplo: en agosto participé del CLEI 2024, una conferencia internacional que se realizó en Bahía Blanca. Tuve que viajar a Bahía Blanca y alojarme allí 2 noches. Asimismo la inscripción me costo 260 dólares. Redondeando tuve un gasto total de 400 dólares, de los cuales 340 salieron de mi bolsillo. La universidad solo me pudo aportar unos 60 dólares. Claro que hay conferencias más económicas pero también las hay más caras. Personalmente he participado en conferencias de 100 dólares y en conferencias de más de 1.000. Asimismo he participado en conferencias en Argentina, Brazil, Bolivia, Escocia, España y Finlandia y en todos los casos la mayor parte de los costos los afronte de mi bolsillo. A diferencia de lo que suele ocurrir con las conferencias de industria, donde los speakers tienen la entrada bonificada y en ocasiones también algunos viáticos, en las conferencias académicas hay que pagar, sobre todo los autores deben pagar pues el proceso de publicación no es gratuito. Publicar en una revista, puede en algunos casos, resultar menos oneroso, pues no hay costos de logística ni inscripción, pero en general hay que pagar a la revista. Si bien hay revistas en las que puede publicase gratuitamente, hay muchas otras en las que el costo publicación requiere un desembolso. Un costo implícito en todo este proceso es el tiempo que deben dedicar los investigadores, un tiempo que hoy en día en Argentina es remunerado muy pobremente.