A fines de 2022 Heroku cambió su modelo de suscripciones y descontinuó su oferta gratuita que muchos veníamos utilizando. Yo tenia alguna que otra aplicación de juguete pero principalmente venia utilizando Heroku en mis materias para que los alumnos puedan desplegar las aplicaciones que construyen durante la cursada. Si bien es cierto que con estos planes Heroku incluye una oferta para estudiantes la misma no se ajusta a nuestras restricciones pues exige una tarjeta de crédito para poder acceder a la oferta.
Este cambio de Heroku nos obligó a buscar alternativas considerando nuestras restricciones:
La plataforma/servicio debe ser gratuito y adicionalmente no debe pedir tarjeta de crédito (hay varias plataformas que a pesar de ofrecer opciones gratuitas piden igualmente una tarjeta de crédito para hacer una validación del usuario)
Debe soportar nuestro stack tecnológico, básicamente necesitamos poder correr una aplicación web construida en Ruby y con una base de datos PostgreSQL.
Estas restricciones nos obligaron a descartar algunas opciones interesantes como Vercel (no soporta nuestro stack).
Finalmente hemos decido utilizar Render que cumple con nuestras restricciones y que de acuerdo a la pruebas que hicimos parece que se ajusta bien a nuestras necesidades funcionales.
Mi colega Hérnan hizo un video orientativo para nuestros alumnos mostrando como desplegar en Render una aplicación web Ruby+PostgreSQL.
Durante el primer cuatrimestre de este 2023 estaré dictando esta materia en calidad de Profesor Invitado en la carrera de Ciencias de la Computación en la Facultad de Ciencias Exactas y Naturales de la UBA.
La materia será una variante reducida MeMo2 con algunos agregados. Será reducida porque las materias dictadas en esta modalidad tiene una duración de medio cuatrimestre (8 semanas).
El temario tentativo es:
Ingeniería de Software Continua: fundamentos.
Principios Lean & El movimiento DevOps.
Flujos de valor en el proceso de entrega de software.
Tipos y Estrategias de testing.
Software Configuration Management de segunda generación.
Desarrollo guiado por pruebas de aceptación.
Integración, Entrega y Despliegue continuos.
Delivery Pipelines & Estrategias de despliegue.
Gestión de Ambientes.
Modelos de infraestructura & Infraestructura como Código.
Roles y Modelo de Equipo.
Técnicas de trabajo colaborativo.
Gestión del proyectos vs. Gestión de Producto.
Operaciones y el enfoque SRE.
Digo tentativo porque aún me falta terminar de bajarlo a detalle de implementación y es posible que no llegue a cubrir la totalidad. de los puntos.
En términos de dinámica de cursada mi idea es utilizar la misma que en MeMo2 lo cual implica:
cursada híbrida (algunas clases presenciales y otras clases virtuales).
un enfoque muy «hands-on»
una carga de trabajo extra-clase de unas 6 horas semanales a lo largo de todo el curso.
stack tecnológico basado en Ruby, GitLab y Kubernetes
herramientas colaborativas para soporte de la cursada: GoogleGroups, CanvasLms, Discord y Google Meet
Dado el alto grado de interacción con los estudiantes, la materia está planteada con un cupo de 16 vacantes.
A comienzos de marzo tengo una reunión con personal de la facultad donde espero tener más «detalles de implementación».
Pensamiento final: mientras escribo estas línea se me ocurre que esta materia podría dictarla como materia optativa en otra institución o incluso como un curso privado, si llega a haber algún interesado no dude en contactarme.
Este año 2023 viene con algunas novedades que se suman a mis actividades recurrentes.
En el ámbito académico, seguiré con mis materias de grado en UBA Ingeniería (memo2) y UNTreF (Ing. de Software) y también volveré a dictar (por cuarta vez) el Seminario de Postgrado en Software Delivery. Una novedad es que durante el primer cuatrimestre de 2023 estaré dictando una nueva materia en UBA Exactas: Ingeniería de Software Continua (más detalle próximamente). Finalmente, si bien aún no está confirmado, es posible que durante la segunda mitad de año también esté participando del dictado de otro Seminario de Postgrado en UNTreF sobre Arquitectura de Software.
En el ámbito no-académico, ya tengo confirmada una nueva edición del Taller de Prácticas Técnicas para Scrum Masters y Agile Coaches que comenzará a mediados de marzo. También tengo la intención de estrenar dos nuevos talleres: uno sobre «Artesanía de Software» (sobre esto escribí algo el año pasado) y otro sobre «Especificación con ejemplos, BDD y TDD» (sobre esto tengo varias ideas pero nada escrito aún). Respecto de estos dos talleres, estoy considerando hacer un experimento de crowdfunding para cubrir los costos de preparación y dictado, en breve compartiré más información al respecto.
Como siempre, dudas, consultas y sugerencias las pueden poner en los comentarios o bien contactarme en privado por aquí.
Terminé de leer este libro hace un par de días. Me gustó y me alegró ver que varias de las cuestiones que menciona coinciden con lo que vengo aplicando en mis proyectos y enseñando en MeMo2.
Al margen de que ya sabía, descubrí algunos conceptos y capacidades de Gherkin de las que nos estaba al tanto como ser los «journey escenarios» y la diferencia entre las «data tables» y «example tables».
El texto está escrito de forma tal que intercala explicaciones conceptuales con fragmentos de diálogos de un equipo de desarrollo que aplica esos conceptos. En cierto modo esto hace que la explicación de cómo formular buenos ejemplos contenga muchos ejemplos.
Creo que es fundamental para todo equipo pretenda aplicar BDD que al menos una persona del equipo de desarrollo maneje fluidamente las cuestiones descriptas en este libro (¿el facilitador/Scrum Master? ¿un tester?).
Hace varias semanas tenia pendiente la publicación de este post. Creo que para muchos el 2022 fue «el año de la vuelta»: volvimos a las aulas, volvimos a la oficinas, volvimos a encontrarnos, volvimos… ¿mejores? Mmmm, no sé, pero sin duda volvimos distintos. De hecho algunos no volvimos completamente, algunas casas de estudio (y empresas) tomaron consciencia de que hay ciertas cuestiones de la educación (y del trabajo) que pueden verse beneficiadas de un esquema híbrido online/onsite. En mi caso particular, no volví a pisar las oficinas de un cliente en parte porque he estado trabajando con clientes del exterior. Y en el ámbito académico, adoptamos un esquema híbrido que consideramos lo más apropiado didácticamente para nuestra materia.
Al igual que el año pasado tuve una dedicación muy similar en academia e industria.
Estuve trabajando en una iniciativa para la enseñanza de Ingeniería de Software en las carreras de sistemas a partir de la cual escribimos un artículo que ya hemos enviado para evaluación a un congreso.
En el ámbito industrial, la primera mitad del año estuve trabajando como parte del staff de RadioCut, una aventura que inicié en 2021 con la intención de ser parte de un producto pero que lamentablemente no resultó como esperaba. Ya en la segunda mitad del año volví a mi trabajo de consultoría/freelance. Finalmente por otro lado dicté en reiteradas ediciones mi Taller de Introducción a Kubernetes y realicé la primera edición del Taller de Prácticas Técnicas para Scrum Masters.
Toda herramienta es creada con un fin y luego usada como a cada uno le parece. El ejemplo que siempre pongo es el de la mesa: podríamos pensar que la mesa fue pensada para sentarse a comer o a trabajar, pero sin embargo alguien podría usarla para acostarse a dormir. Esto puede traer dos riesgos:
que no resulte muy cómodo/conveniente o incluso que tenga limitaciones, «¡que incómodo dormir en la mesa! => es razonable ya que no fue pensada para eso»
que posiblemente haya una herramienta más apropiada => ¿qué tal si probas dormir en la cama?
(tengo la sensación de que esta situación de «dormir» en la mesa se repite frecuentemente en la industria del software con distintas herramientas)
En este sentido Gherkin fue pensado como una herramienta de colaboración/comunicación/especificación para ser utilizada de programar la solución y que nos trae el beneficio adicional de poder automatizar utilizando alguna herramienta Gherkin-compatible como Cucumber, Cucumber-jvm, Behat, etc, etc.
Sin embargo vemos en la industria un uso alternativo de Gherkin/Cucumber: la automatización de pruebas una vez que la solución ya está programada. Si bien este escenario esalgo perfectamente válido a mi no me resulta conveniente. O sea: si no vamos a tener el involucramiento del usuario y no vamos a trabajar colaborativamente en entender el negocio antes de empezar a programar y solo buscamos automatizar pruebas, me resulta entonces más práctico programar las pruebas con alguna herramienta de la familia xUnit o Rspec. Un escenario en el que automatizar con Gherkin/Cucumber «a posteriori de la programación» es cuando tenemos una persona describiendo la prueba (erscribiendo Gherkin) y otra persona escribiendo el código de automatización por detrás del Gherkin. En lo personal sigue sin convencerme.
Pero al margen de mis gustos y convicciones, hay una diferencia importante en el uso de Gherkin dependiendo de la intención con la que lo estamos usando. Más concretamente la forma en la que vamos a escribir los escenarios con Gherkin va a ser distinta. Veamos un ejemplo, tomemos una funcionalidad de login, si estamos usando Gherkin como herramienta de colaboración/comunicación/especificación y seguimos las recomendaciones de los creadores, podríamos tener lo siguiente:
Antecedentes:
Dado que existe un usuario "juan" con clave "claveFuerte123"
Escenario: Login exitoso
Cuando un usuario ingresa credenciales "juan" y "claveFuerte123"
Entonces el login exitoso
Escenario: Login fallido por clave incorrecta
Cuando un usuario ingresa credenciales "juan" y "claveIncorrecta"
Entonces el login es fallido
Algunos puntos para destacar:
El foco está en el comportamiento omitiendo todo detalle de implementación
No hay ninguna mención a elemento de presentación/pantallas/html
Los escenarios son muy cortos
Veamos ahora una versión alternativa que típicamente podría ser creada «post-programación» con el fin de automatizar una prueba de regresión.
Antecedentes:
Dado que existe un usuario "juan" con clave "claveFuerte123"
Escenario: Login exitoso
Dado que en el campo "usuario" pongo "juan"
Y que en el campo "clave" pongo "claveFuerte123"
Cuando hago click en el "Login"
Entonces veo el mensaje "Bienvenido"
Escenario: Login fallido por clave incorrecta
Dado que en el campo "usuario" pongo "juan"
Y que en el campo "clave" pongo "claveIncorrecta"
Cuando hago click en el "Login"
Entonces veo el mensaje "Credenciales incorrectas"
A diferencia del otro caso aquí vemos mención a los elementos de presentación/pantalla y un detalle «del cómo», esto se debe a que el escribir el Gherkin de esta segunda forma permite reutilizar código de automatización. O sea, el paso «Dado que en el campo <x> pongo <v>» es completamente genérico y lo puedo utilizar tanto en el escenario de login como en cualquier otro. Por otro lado el paso «Cuando un usuario se logueo con credenciales «juan» y «unaClaveIncorrecta» es muy específico del login.
Entonces:
En un contexto donde el objetivo central es la automatización, será mucho más probable encontrarnos con Gherkin del segundo estilo.
En un contexto donde el objetivo es entender/comunicar será más probable (y conveniente) el uso de Gherkin del primer estilo.
Estos dos estilos de Gherkin que menciono aquí son en cierto modo dos extremos. Asimismo, si bien la sintáxis de Gherkin no viene sufriendo grandes cambios, la forma de uso ha ido variando dado pie a distintos estilos. Lo importante para mi es que cada equipo establezca explícitamente un conjunto de convenciones sobre su uso que estén en sintonía con el uso que le vayan a dar.
Para aquellos que apuesten a utilizar Gherkin como herramienta de colaboración/especificación les recomiendo la serie de libros de Rose y Nagy «The BDD Books«.
Hablando de «modalidades de contratación» en el mundo IT podemos identificar en un extremo el «empleado en relación de dependencia» y posiblemente en el otro al «freelancer».
Cuando alguien es contratado en relación de dependencia es un «empleado pleno», goza de una serie derechos de acuerdo a la legislación vigente que incluye típicamente (en Argentina) cuestiones tales como aporte a la seguridad social, cobertura médica privada, indemnización en caso de despido injustificado, etc, etc. A esto, algunas empresas agregan beneficios extra como posibilidad de comprar acciones de la empresa, días extra de vacaciones, etc. En este contexto el empleado típicamente debe trabajar determinada cantidad de horas mensuales en un determinado rango horario (con mayor o menor flexibilidad) y a fin de mes cobra un sueldo fijo seguro.
Por su parte el freelancer no trabaja para un cliente en particular, más aún, no tiene cliente fijo (pues si lo tuviera seria posiblemente una relación de dependencia «encubierta», algo penado por la ley) y por ende no goza de todos los beneficios del empleado en relación de dependencia. No tiene sueldo asegurado y debe encargarse él mismo de sus cargas sociales, su cobertura médica, etc, etc. . Tiene que salir a buscar clientes, vender, ejecutar y cobrar. Puede no sonar muy atractivo, pero tiene algunos beneficios que para algunas personas son muy valiosos. Puede elegir en qué proyectos trabajar, con quién trabajar, cuando trabajar (esto es medio relativo porque dependiendo de que tipo de trabajo realice, puede que tenga que trabajar en un horario fijo o al menos en el rango típico de oficina). Puede incluso elegir cuánto cobrar, puede cobrar más (si se da mañana para venderlo) o incluso cobrar menos si por alguna razón «estratégica» (o de gusto) así lo desea. Quienes prestamos servicios de consultoría solemos trabajar en esta modalidad.
En cierto modo a mitad de camino entre las dos modalidades previamente mencionadas hay una modalidad muy comúnmente utilizada por empresas de USA. Es lo que habitualmente se denomina «contractor». Alguna vez escuché a alguien referirse a este tipo de contratación como «relación laboral precarizada» porque el «contractor» muchas veces tiene muchas de las obligaciones de los empleados en relación de dependencia pero sin los derechos/beneficios de estos. Ojo aquí, hay que tener presente que las legislaciones laborales son distintas en USA y en Argentina, entonces cuando digo «relación precarizada» lo digo a la luz de la legislación Argentina. Para el empleador resulta típicamente más «barato» el contractor que el empleado en relación de dependencia y al mismo tiempo le da más flexibilidad. Por su parte el trabajador «contractor» tiene alguna cuestiones como el empleado en relación de dependencia en el sentido que tiene que trabajar determinada cantidad de horas por mes, típicamente no elige sus proyectos ni con quien trabaja, pero tampoco tienen que andar buscando clientes ni gestionando cobros.
Se me ocurrieron dos ejemplos ambientados en Juego de Tronos. Un caso típico de freelancer es Bronn, de hecho el término freelancer hace referencia a esos caballeros «lanzas libres» que vendían sus servicios a uno u otro señor. Típicamente un mercenario. En el otro extremo están los miembros de la Guardia Real, los capas blancas, que son empleados en relación de dependencia del rey.
Hace un par de días terminé de leer este libro escrito por Carlos Blé. Me pareció muy bueno y me gustó mucho.
El libro es un muy buen compendio de buenas prácticas de programación y diseño. Reúne temas ya tratados en otras publicaciones y agrega temas que personalmente nunca había visto en un libro. En cada tema, más allá de la explicación y algún ejemplo, se suma la opinión de Carlos, siempre pragmática, constructiva y basada en la experiencia.
El libro está escrito en castellano, lo cual también suma puntos, ya que no tengo presente otros libros de esta temática escritos en castellano. Un punto a mi parecer negativo es que los ejemplos de código están en inglés, lo cual me resultó molesto por tener que cambiar de idioma entre el código y la prosa, pero es un tema menor.
Varios de los temas que cubre el libro son temas de MeMo2, o mejor dicho, son temas que nos gustaría que los alumnos de MeMo2 ya tengan asimilados. Lamentablemente no siempre los tienen asimilados y por ello nos vendría muy bien contar con este libro como recurso de estudio. La editorial del libro (Savvily) tiene un acuerdo para que los estudiantes puedan acceder gratuitamente a sus libros, pero dada la burocracia de UBA, veo muy difícil que se logre firmar el acuerdo. De todas formas, no pierdo la esperanza.
Una y otra vez leo en redes críticas a Jira. Y no son críticas que tengan que ver con que el producto sea inestable. Es como que la gente «sufriera» al usar Jira. Algo así como que cada vez que hacen alguna acción en Jira recibieran una descarga eléctrica al estilo picana.
De entrada Jira es una herramienta y como tal no es intrínsecamente buena ni mala, todo depende de cómo se la use. Jira ofrece un conjunto de funcionalidades para dar soporte a equipos que pretenden trabajar en un contexto «agile». Una confusión muy habitual está dada por gente que cree que trabaja de forma «agile» por el solo hecho de usar Jira. Esto es sin duda una de las fuentes de crítica que recibe Jira, pero no es un problema de Jira sino de ese subconjunto de usuarios.
Algunas otras críticas que ha recibido Jira tienen que ver con «la interpretación» (o tal vez deba decir implementación) que hace Jira de «agile». Ejemplo: permitir hacer estimaciones en horas cuando la estimación en horas no es lo que se estila en agile, entonces algunos «extremistas» se agarran de esto para decir «Jira es anti-agile». Que la herramienta permita estimar en horas no significa que obligue a trabajar así (no estoy seguro que esto de la estimación en horas siga siendo así, pero no es relevante, es solo para ejemplificar).
Otras críticas vienen de gente que no le gusta «trackear su trabajo en Jira». Aquí hay 2 cuestiones: 1) No se la agarren con la herramienta sino con quien les exigió que la usen de esa forma y 2) En general a quien no le gusta trackear el trabajo, no le gusta hacerlo con Jira ni con ninguna otra herramienta.
Mi punto es: Jira es simplemente una herramienta que ofrece una serie de funcionalidades «más o menos» alineadas con una forma de trabajo «Agile».
A mi parecer el problema surge a partir de dos situaciones iniciales:
gente que se pone a utilizar la herramienta sin hacer la correspondiente personalización. No diseñan su forma de trabajo, sino que simplemente ponen Jira y dejan que Jira defina su forma de trabajo. Dicho en criollo: ponen el carro por delante del caballo.
gente que hace una personalización «inconveniente» de Jira en el sentido que la personalización realizada resulta incómoda para quienes luego deben usar la herramienta diariamente. Esto resulta muy curioso porque una de las premisas de Agile son los equipos autoorganizados y un equipo autoorganizado debería poder personalizar la herramienta de gestión a su gusto (o incluso elegir la herramienta de gestión), sin embargo en más de una organización, la personalización de Jira (o la herramienta de gestión que sea) la decide gente que luego no usa la herramienta diariamente.
Cierro con algunas preguntas para aquellos que no les gusta Jira (en realidad creo que aplica a cualquier herramienta de gestión):
¿pensaste los tipos de los items de backlog de tu proceso y luego configuraste Jira? o ¿directamente te pusiste a utilizar lo que traia el template de Jira?
¿pensaste los estados y transiciones de estados de los items de backlog de tu proceso y luego configuraste Jira? o ¿directamente te pusiste a utilizar lo que traia el template de Jira?
¿pensaste los campos/datos de los items de backlog de tu proceso y luego configuraste Jira? o ¿directamente te pusiste a utilizar lo que traia el template de Jira?
Si realmente hiciste el ejercicio de «diseñar» tu proceso y luego lo plasmaste en la herramienta y aún así estas desconforme con Jira, entonces tal vez tu crítica este justificada. Pero si no hiciste el trabajo de «diseño» de tu proceso, entonces….
En FIUBA la gran mayoría de los docentes en el área de computación son de dedicación parcial lo cual básicamente significa que van a la facultad a dictar una materia y listo. Esta dedicación parcial implica formalmente de ~10 horas semanales y un sueldo en sintonía con eso, con lo cual muchos de estos docentes ejercen la docencia más por gusto (¿vocación?) que por necesidad, ya que casi todos «viven» de su trabajo en la industria. Más aún, algunos ni siquiera tienen nombramiento formal, lo cual implica que no perciben un sueldo. Al mismo tiempo, en general no hacen investigación ni ninguna otra actividad en la universidad salvo tal vez colaborar en alguna cuestión como participar de una comisión asesora o dirigir los trabajos finales de los alumnos. Es posible que esta situación también ocurra en alguna otra institución pero no puedo asegurarlo. En lo personal, esta situación de FIUBA yo solía verla como «inconveniente» ya que a nivel institución esos docentes de dedicación parcial no generan conocimiento (publicaciones formales) pues no se hacen investigación. Esto hace que sean muy pocas las publicaciones formales en el área de computación con filiación FIUBA.
Por otro lado tampoco me parece conveniente que todos los docentes de una carrera sean de dedicación completa/exclusiva, porque en un área de ingeniería es necesario una dosis de «mundo real» que viene dada por el ejercicio en la industria.
Pero hace un par de meses tuve una charla con un docente investigador del área de computación de otra institución que me comentaba que gran parte de sus docentes son de dedicación completa/exclusiva y que como tales hacen hacen investigación. Y más aún, varios de ellos solo quisieran dedicarse a hacer investigación pero que por reglamentación están obligados también a dar clases. ¡Ooopss! docentes que no quieren hacer docencia.
Este me hace pensar que en la situación de FIUBA no es tan mala, al menos en términos de docencia pues como mencioné, gran parte de los docentes ejercen la docencia por «vocación»* . Sin embargo, creo que es necesario lograr una balance a nivel institucional para poder tener docentes que hagan investigación (lo cual requiere cargos de mayor dedicación) y docentes «de industria» (practitioners, como se les suele llamar a la gente de industria en los en ámbitos académicos).
* sin duda que hay más motivaciones que la pura vocación, algunos harán docencia para sumar antecedentes, otros para continuar aprendiendo, pero mi punto es que en general esos docentes no lo hacen «por necesidad» ni obligación.
Blog de NicoPaez 