Archivo del Autor: Pedro Ballesteros

Así de justo será el acceso a la universidad en el año del coronavirus

Hace ya bastantes días ví en un informativo de TVE una noticia que quitaba bastante peso al problema que va a acarrear a todos los estudiantes la suspensión de las clases a causa del coronavirus. Lo comparaban con alguna situación similar del pasado, que no recuerdo bien cual, también hubo una suspensión de clases, al parecer no hubo gran impacto, los alumnos salieron adelante sin problemas, eso dicen.

Leo que el Ministerio de Educación ha realizado declaraciones como las siguientes:

…se han tomado medidas para que todos los alumnos puedan terminar el curso sin verse perjudicados por la suspensión de las clases presenciales…

…el objetivo es asegurar que alumnos y alumnas puedan acabar el curso sin verse perjudicados a causa de las medidas adoptadas para contener la expansión del coronavirus Covid-19. Seguiremos poniendo en marcha cuantas iniciativas sean necesarias…

Pues bién, las medidas no están funcionado. Los alumnos sí se están viendo perjudicados, y mucho. ¿que medias se han tomado? ¿retrasar un més la EvAU?

Dejaré al margen los numerosos de problemas relacionados con el supuesto seguimiento de las clases o el problema de completar los temarios. Dejaré al margen que lo de realizar clases online se ha dejado al criterio exclusivo de cada profesor. Algunos profesores no han hecho nada desde que suspendieron las clases, han pasando olímpicamente de ponerse en contacto con los alumnos. Otros sí han mantenido algún tipo de ayuda, organizando mediante multi videoconferencias alguna especie de clase o tutorial. A estos que por su propia iniciativa se han esforzado en seguir educando se les da mil gracias (por video no es lo mismo, pero algo es algo).

Me voy a centrar en un caso concreto, los alumnos de 2º de bachillerato que intentarán acceder a la universidad. Esos alumnos que han estado estos dos últimos años matándose por conseguir una nota media que les permita elegir la carrera que quieren. La nota media de esos dos años de bachillerato contará un 60% mientras que la nota del EvAU un 40%.

Voy a poner dos casos concretos de cómo se están realizando los exámenes de evaluación de 2º de Bachillerato en dos institutos públicos cualquiera:

  • INSTITUTO 1: Se les entrega a los alumnos el examen por escrito y se les da un plazo de entre 2 a 4 días para rellenarlo y enviarlo al profesor.
  • INSTITUTO 2: El examen es online, todos los alumnos están obligados a tener encendida la camara, mediante videoconferencia por zoom, están obligados a enfocar el examen que tienen que tener sobre la mesa, en todo momento se tienen que ver sus manos, no se pueden ir hasta que no termine el examen.

No son casos inventados, mi hija va al INSTITUTO 2, un amigo suyo va al INSTITUTO 1. Este amigo le esta pidiendo ayuda a mi hija para rellenar el examen de lengua, les han dado 4 días para terminarlo, al parecer el examen de matemáticas ya se lo ha rellenado su hermano mayor.

Qué justo va a ser este año el acceso a la universidad, sobre todo para los alumnos se han matado por conseguir ese 60% de la nota, que a otros les están regalando. Es cierto, no va a haber ningún impacto de la crisis sobre los estudiantes, sobre todo para aquellos matriculados en esos centros educativos que han decidido que lo mejor es regalar la nota.

Creo que cualquiera puede imaginarse el nivel de cabreo que tiene mi hija por todas las injusticias y dificultades que se están viviendo desde que se suspendieron las clases, no solo por el ejemplo concreto de la EvAU, por todo, a todos los niveles, les esta costando horrores sacar este curso adelante. El nivel de stress y desilusión está por las nubes. …a la mierda, se me fastidió la nota media…

Nuestros gobernantes en cambio están tranquilos, como siempre, el problema está solucionado, retrasamos prueba de la EvAU un mes, ya está todo solucionado.

No tengo ni puta idea de que podría hacerse, por eso yo no soy ni educador, ni Ministro de Educación, pero creo los que están ahí si han sido elegido para eso, para pensar alguna buena solución.

La cosa es que para solucionar un problema lo primero es admitir que hay un problema en lugar de negarlo.

Desarrolladores recogen firmas para pasar Madrid a Fase 0.0.5

En vista de que se prevé que la solicitud de pasar Madrid a fase 1 del confinamiento el próximo día 11 de Mayo va a ser denegada, una plataforma de desarrolladores está recogiendo firmas para solicitar el uso de semver (proceso de asignación de versiones ampliamente utilizado en el campo del desarrollo de software).

 
…que al menos se pueda hacer el upgrade a 0.0.5
no tiene que ser un todo o nada…
 

Se propone mantener versiones 0.y.z comúnmente utilizadas en los desarrollos iniciales donde el producto aún está en fase experimental y cualquier cosa puede ser cambiada en cualquier momento, siendo aplicadas a versiones que NO SE DEBERÍAN considerar estables.

Todo esto encaja perfectamente en la situación actual en la que no vamos directamente a la versión (o fase) 1.0.0, pero la población demanda algún permisillo adicional al ya existente del deporte y los paseos.

Entre las propuestas de esta beta 0.0.5, esta plataforma de desarrolladores plantea un permiso para poder estar en la calle en alguna franja horaria concreta sin necesidad de moverse…

 
ni paseos… ni ostias… los informaticos tambien tenemos derecho a oler la calle haciendo lo que más nos gusta…
 

Quizás se podría usar el horario nocturno que ahora presenta un desperdicio de recursos enorme, algo totalmente absurdo para este grupo de informáticos.

En todo caso, para evitar la picaresca, se propone requerir el uso de un portátil durante el disfrute de este permiso, para justificar dicha inactividad física y sedentarismo voluntario.

Aun así ya empiezan a surgir peleas internas respecto a una cláusula que regularía el tipo de portátiles a usar, más concretamente los sistemas operativos que se permitirían.

 
…no quiero bajar a la calle a disfrutar de mi hora de no moverme con mi MacBook Air Retina y a 2 metros un tipo con un Windows 10 en un Acer de mierda…
 

Debate bastante controvertido, similar al del uso de tabuladores vs espacios, que genera batallas sangrientas (hablando virtualmente).

Angular Customizable Templates

The code on GitHubAngular Customizable Template

I’m currently working on a project where we have inherited a lot of AngularJS code. The application was developed as a prototype, so some things were coded in a very quick and provisional way and with a lack of very good practices.

We are now working on the transformation of the prototype to a real product. I’ve ended up making a deep refactoring of all the browser-side code that in some parts it seems more a reboot than a refactoring.

One of the things that terribly frightened me more was to bump into code containing those huge chains of nested $parent.

<span ng-if="$parent.$parent.$parent.object.property">
  {{$parent.$parent.$parent.$parent.object.property}}
</span>

It is generally a very bad idea to access to the parent scope using the $parent property, but it is even worse to reach that level of nesting. The code is unmaintainable. A minimum change in the template will change the depth of the accessed scope and will invalidate all the bindings. There are some core directives that create new scopes, for example the ng-if directive.

It seems that kind of code was driven by the need to customize the HTML templates of certain custom directives.

<my-directive customHeader="/templates/customHeader.html">
  <div>Some content wrapped by the directive using transclusion</div>
</my-directive>

The <my-directive> directive is based in a HTML template and it is declared with an isolated scope. When the customHeader attribute is defined, the directive includes that template HTML file using the <ng-include> directive.

The problem is that all the code included in the customHeader.html file will be accessing the isolated scope of the <my-directive>. An isolated scope doesn’t use prototypal inheritance, so the customHeader.html template needs to use the $parent property to access to the scope where it is supposed to be defined.

While working on that kind of code I thought another way to make it possible to create directives based on HTML that allow the customization of some parts of their templates while retaining access to the right scope.

I made the Angular Customizable Template module. It is based on ‘element’ transclusion. It currently has the drawback that the mechanism only works for directives that wrap its content using simple transclusion. So it is still a work in progress but I think it can give you some ideas.
Sigue leyendo

¿Me creo eso del Refactoring?

La primera vez que escuché algo de metodologías Agile como Extreme Programming o Scrum, una de las primeras cosas que pensé fue:

¡Vaya una mierda que nos están vendiendo!

Esta primera evaluación de las metodologías Agile fue debida precisamente a todas esas historias de trabajar al día. Programar lo justo para cumplir. Evitar la codificación de funcionalidad futura. No perder el tiempo en la creación de arquitecturas para pretendidos frameworks reutilizables. Todo se acabará mejorando en un hipotético refactoring posterior.

 

“Keep it simple, stupid” (KISS)
“You ain’t gonna needed it” (YAGNI)
“If it’s worth building, it’s worth testing. If it’s not worth testing, why are you wasting your time working on it?”

 

Habían sido muchos años de lucha contra el Spaghetti Code, intentando evitar las anti-metodológicas prácticas del Death March o el Cowboy Coding, que es a lo que me sonaba todo lo Agile.

Harto de enfrentarme a código con chapuzas, pegotes y parches, ¿¡Me vienen ahora con unas metodologías que hace apología de todas esas prácticas!?.

Lo estaba entendiendo bastante mal, porque me habían contado a medias la verdadera práctica del refactoring.

La lección aprendida es que para que el agilismo funcione, sin lugar a dudas es vital combinar “GESTIÓN + INGENIERÍA”.

Scrum proporciona una gestión y planificación agile de proyectos. La implantación de prácticas agile en un grupo muchas veces se queda sólo en Scrum, ya que la parte de gestión y planificación es es siempre más fácil de cambiar que las prácticas de ingeniería.

Extreme Programming proporciona la Ingeniería del Software Agile. Son metodologías más complicadas de introducir, ya que requiere de expertos programadores, son prácticas que emergen de la programación y no de la gestión, que es donde suele estar el mayor poder de influencia.

 

Cuando conocí el bucle micro-incremental e iterativo de TDD, o del BDP (Behaviour Driven Programming) de BDD, es cuando realmente entendí el paradigma YAGNI y sus derivados.

 

El refactoring es vital en TDD.
Si no haces un refactoring continuo no estás haciendo TDD.
Si no haces refactoring no estás diseñando.

Usando este tipo de metodologías es como se hacen viables principios como YAGNI. Así es como se puede diseñar directamente desde el código. El código nos va mostrando el diseño y la arquitectura de nuestra aplicación.

 

El refactoring es lo que hace posible que ese framework reutilizable, esa arquitectura o ese gran diseño surja de forma orgánica, justo en el momento que se necesita. Además con la libertad de modificación y trasformación que proporcionada la amplia cobertura de los Small Scaled Tests que han dirigido dicho refactoring.

Deberíamos llamar a la metodología Test Driven Refactoring (TDR).

Me horroriza oír hablar de “la deuda tecnológica”. Este concepto no debería existir. Da la sensación de que se le ha puesto un bonito nombre a lo comúnmente conocido como chapuza tecnológica.

No deberíamos calcular la chapuza tecnológica acumulada a lo largo de los sprints para decidir si necesitamos un período de refactoring. Se trata de un refactoring que nunca jamás nos van a permitir hacer, ya que nunca vamos a tener tiempos muertos.

Los períodos de refactoring no existen porque el refactoring es continuo.

Sí, me creo eso del refactoring, pero cuando se utiliza de forma continua, incremental e integrado en un bucle de trabajo basado en Test Driven Refactoring (o Behaviour Driven Refactoring).

Quiero un Scrum Master Especializado

Muchas veces da la sensación de que el rol del Scrum Master se está convirtiendo en una figura algo devaluada y fácilmente sustituible dentro de los equipos de Scrum.

Parece que el trabajo que realiza un Scrum Master es tan trivial que cualquiera puede desempeñarlo con sólo unas meras pinceladas de la metodología. He oído hablar incluso de equipos que se turnan el rol de Scrum Master de un sprint a otro (personalmente me parece anti-scrum).

No soy Scrum Master y nunca he desempeñado dicho rol.

Sólo soy un miembro más del equipo de desarrolladores, y aun así quiero revindicar la figura del Scrum Master. Trasmitir la importancia de que para vivir un buen Scrum es vital la existencia de un buen Scrum Master, con las habilidades adecuadas, y a ser posible formado y experimentado.

Es cierto que los equipos de Scrum son auto-organizados.

Aun así la figura del Scrum Master es fundamental. El trabajo que debe realizar al margen de los sprints requiere gran dedicación y esfuerzo.

A veces se simplifican las funciones reales de un Scrum Master, reduciéndolas a una mera organización y moderación de reuniones.

¿Es el Scrum Master un simple Moderador de Reuniones?

Sigue leyendo

Test Driven Development: Eliminando Malentendidos

Últimamente cuando alguien me pregunta por TDD acabo planteándome la misma pregunta:

¿Están interesados en la metodología de desarrollo llamada Test Driven Development o en realidad tan solo están pensando en codificar unos tests antes del desarrollo?

Parece una pregunta redundante ¿acaso no es lo mismo aplicar TDD que codificar tests antes del desarrollo de la funcionalidad?

Esta es precisamente la raíz de muchos malentendidos y la respuesta es un rotundo NO.

La Raíz de los Malentendidos

Cuando se habla de TDD en realidad muchas veces se está pensando en técnicas para  la automatización de tests de alto nivel (integración, sistema o interfaz de usuario). El interés que despierta TDD es el interés hacia las técnicas para la programación de tests automáticos, reduciendo TDD a un nombre de moda que aconseja programar los tests antes de escribir una sola línea de código funcional – lo que deja de lado aspectos fundamentales de Test Driven Development, que en realidad es una metodología con reglas propias.

Quizás el problema se deba a que la primera letra ‘T’ dirige el foco hacia el testing en lugar dirigirlo hacia la última letra ‘D’ del development (designing/coding).

Se confunde una metodología del equipo de desarrollo con una metodología del equipo de control de calidad (quality assurance).

Malentendido comprensible al formar parte del nombre de la metodología – esperemos que el cambio de vocabulario propuesto por Behaviour Driven Development con la eliminación de la palabra "test" evite este malentendido.

Test Driven Development es precisamente una metodología diseñada como herramienta de trabajo para los programadores.

No se trata de una metodología para el equipo de QA. Existen otras prácticas más directamente relacionadas con la QA como ATDD – además de prácticas específicas de Agile Testing.

Sigue leyendo