Cerrando la semana (II)

No me gustan las asignaturas en la que tu calificación no es una medida objetiva de tu rendimiento, sino una relativa respecto al rendimiento de tus compañeros. No es una manera justa de juzgar tu progreso. Quizá es que nunca me ha gustado medirme con una vara que no sea la mía propia. Estaré pecando de naive, y seguramente pensaréis que lo que debo hacer es empezar a acostumbrarme a ello. A que el mundo es realmente así, y que, si quiero sobrevivir, tendrá que ser mirando de vez en cuando a los que están a cada lado, para ver cómo de levantada tienen la frente y la nariz, y si estoy no sólo a la altura, sino por encima.

Digo esto desde la frustración que me causa haber recompilado el kernel Linux Blurry Fish Butt más veces de las que pueda recordar, añadiendo y quitando módulos, y leyendo documentación, que me lleva a más documentación, que termina, en, oh, sorpresa, más documentación. Jugando al equilibrio entre los kernel panics y mantener la conectividad de red, intentando dejar el núcleo en su mínima expresión sin que sea una gran pila ardiente de cuelgues.

Si vuelvo a leer un “If in doubt, select YES”, me da algo.

Este sistema de puntuaciones, en mi opinión -y experiencia-, favorece dos comportamientos que no me parecen sanos:

Primero, ofrece la tentación de optar por el camino de la fuerza bruta. Al final, quien obtiene el diez no suele ser quien más documentación ha leído, ni quien ha hecho los cambios que más sentido tienen, sino el que ha tenido más tiempo libre para quemarse las pestañas delante de la terminal, a base de prueba y error, tentando a su suerte a cada reinicio. Tiempo no es precisamente lo que me sobra últimamente, y tener que echar horas en balde para sacar unos kilobytes a un fichero sin saber si va a merecer realmente la pena me parece demencial.

El segundo vicio que fomenta es el secretismo. Soy el tipo de personas que, si me preguntas qué me salió en el ejercicio seis de la página cinco, no te diré la respuesta directamente, pero te guiaré en el camino de la solución. A $root pongo por testigo de la cantidad de veces que eso ha pasado. A la cantidad de WhatsApps que he contestado a medianoche para que nadie a quien conozca se quede sin presentar una práctica por no haberle querido ayudar. No saco ningún beneficio de no echar un cable a otro, porque quiero pensar que, si fuese yo quien tuviese el problema, alguien me tendería la mano que necesito -y que he necesitado más de dos y tres veces-. Con las puntuaciones competitivas esa colaboración se destruye. Nadie aprende tanto como podría. Nadie se beneficia. Terminas cansado, frustrado, y de mal humor. Entiendo que el mercado laboral fomente ese comportamiento (que no me agrada), pero debería quedar fuera del aula.

Por suerte, no toda la semana ha sido cansancio y frustración. Largas horas han languidecido frente al monitor, pero también ha habido tiempo para las buenas noticias y para descansar de este loco invento llamado ordenador. Estoy volviendo a ver The Office, y tengo que confesar que no ha envejecido tan bien como esperaba. La primera vez que la vi fue durante las noches de un caluroso verano en el que tenía que usar cascos para poder escuchar los diálogos por encima del rugir del ventilador de mi viejo portátil. Fue un verano de mañanas de piscina, tardes de fútbol y cañas, y noches de Skype, sirope de chocolate y series. Así que, aunque The Office no me parezca ahora tan divertida como la recordaba, sigue guardando valor sentimental.

Sin más dilación, estos son los enlaces de la semana que me han parecido lo suficientemente interesantes como para compartirlos. Realmente no he tenido mucho tiempo para surcar Internet por placer, así que la lista viene un poco floja en cuanto a cantidad.

  • [Texto] These 13 bad speaking habits are killing your credibility: Unos tips rápidos sobre cómo mejorar tus presentaciones. Los peores momentos que he pasado en la Universidad no han sido los exámenes de cuatro horas de física o matemáticas, o las tardes perdidas detrás de Eclipse sin poder avanzar en una práctica. Han sido exponiendo delante de una clase llena -y un profesor exigente- unas diapositivas poco ensayadas ante público real. Los grupos de amigos tienden a la auto-indulgencia a la hora de juzgarse mutuamente. Si bien no creo que haber conocido estos consejos me hubiese ayudado demasiado, sí habría paliado un poco el completo desastre que estas presentaciones resultaron ser.
  • [Texto] Día internacional de los datos abiertos, un balance mundial: hace poco hablaba aquí mismo sobre la mala calidad de los datos abiertos de la Junta de Castilla y León. Resulta que, si nos atenemos a según qué definición, estos datos han de ser fácilmente procesables por máquinas. Por lo que resulta que la Junta de Castilla y León carece por completo de datos abiertos. Una ocasión más en la que no podemos estar orgullosos de algo.
  • [Vídeo] What makes the Galaxy S7 waterproof?: un breve recorrido por el marco y la placa del Nuevo Galaxy S7, mostrando cómo el servicio técnico puede detectar que ha habido humedad, y cómo diversos componentes como el botón de encendido o el altavoz se protegen de la entrada de agua.
  • [Texto] Managing Style Guides at Shyp – How we use GitHub for design collaboration: un grupo de diseñadores ha adaptado Git a su workflow habitual para hacer cambios en sus guías de diseño. En vez de sobrescribir directamente un fichero importante en Dropbox, como venían haciendo hasta entonces (¡!), con GitHub este cambio tiene que pasar por una pull request antes de integrarse en la rama principal. Además, así se aseguran de que todo el mundo está utilizando la misma versión del fichero.
  • [Texto] A successful Git branching model: el post anterior me recordó al que enlazo aquí, que leí por primera vez hará ahora casi un año. Una lectura vetusta que, sin embargo, no ha perdido ni un ápice de validez desde que fue escrita. Si pretendes usar Git (o cualquier otro software de control de versiones) para tus proyectos, no te pierdas en infinitos commits en la rama principal. Al final terminarás con desastres parecidos a los que padecerías si hubieses usado Dropbox desde el principio para manejar cambios en tu código. Léete el artículo e intenta seguirlo al pie de la letra en tus pet projects.
  • [Texto] Accuracy takes poder: one man’s 3GHz quest to build a perfect SNES emulator: un artículo que habla sobre lo difícil que es detectar fallos en emulación de hardware mediante software, y por qué son tan importantes. Mientras que gran parte de los juegos para videoconsolas antiguas pueden funcionar sin problemas en un emulador que necesite poco poder de procesador, otros juegos hacían cosas tales como escribir en la memoria de vídeo, modificando el frame que se estaba dibujando para conseguir efectos tales como sombras, que hacen que el emulador tenga que forzar sincronizaciones entre sus hilos cada pocas instrucciones. Así, la emulación se ralentiza hasta límites que solo se pueden suplir a base de fuerza bruta.

Todos los enlaces de esta entrada están disponibles a fecha 13 de marzo de 2016, 0:54 a.m. hora española.

Deja un comentario