Hoy me ha escrito un alumno preguntándome por una licencia para un programa. Una licencia de cualquier aplicación contiene una serie de reglas para el uso y modificación de la misma. Licencias libres, dan libertades. Privativas, no las dan. También me ha dicho que yo era el único profesor que les ha hablado de licencias en el grado. ¿Cómo puede salir una persona de una carrera sin saber de licencias? Si alguien le encarga un programa, ¿cómo sabe lo que el cliente puede o no hacer? Si decide usar librerías libres en una aplicación que va a liberar, o para el caso a vender, ¿cómo sabe qué licencia tiene que poner? Es sólo un ejemplo de estas carencias que percibimos los que venimos del campo del software libre. Y seguramente también clientes, personas de recursos humanos que entrevisten y en general, el mundo. Pero no es la única, sólo la primera.

La segunda es aprender un lenguaje de programación. Sí, uno. Cualquiera me vale, pero os voy a dar una pista de lo que no es un lenguaje de programación: Matlab. Es un entorno privativo donde es fácil hacer cosas porque todo está ya hecho. ¿Procesamiento de imágenes? Toolbox de procesamiento de imágenes. ¿Redes neuronales? Toolbox de redes neuronales. Todo fácil y bonito y pagado por el contribuyente. O pirateado, que tampoco hay que hacerle ascos. Pero ¿y si hay que hacer algo que no esté en una toolbox? Huuuy, qué follón… va a ser que no.

Si esos lenguajes ya son de scripting, tienes dos por el mismo precio. Pero es que incluso en las facultades (de Informática u otras ingenierías) en las que enseñan lenguajes de programación, se limitan a usar extensivamente C, C++ o Java. Excelentes lenguajes. También con una curva de aprendizaje elevada y poco ágiles a la hora de desarrollar rápidamente algo; necesitados de un montón de líneas de código. Hasta no hace mucho, sin sistemas estándar de empaquetamiento e instalación de bibliotecas. Y, en general, lentos a la hora de escribir un programa y rápidos de ejecutar, lo que no los hace especialmente aptos para enseñar, donde es mucho mejor que el alumno aprenda a escribir programas rápidamente y luego adquiera las habilidades necesarias para optimizarlo y/o elegir el lenguaje más adecuado a cada caso.

Afortunadamente estos lenguajes son libres, aunque en algunos casos sólo se verán entornos de programación privativos, en el caso de C++, o, peor, sólo se verán lenguajes de programación privativos en entornos privativos Visual algo. Los lenguajes de scripting son fundamentales para prototipado, para sistemas y para mil tareas que un informático tiene que hacer. Si no conoces Python, Perl, Ruby, JavaScript, te faltan habilidades que vas a necesitar con una probabilidad cercana al 1 en tu puesto de trabajo.

Y si no conoces otro lenguaje, el inglés, también. Es prácticamente imposible que no lo hayas necesitado durante la carrera y el desarrollo de alguna aplicación o el aprendizaje de un nuevo lenguaje, por la simple razón de que StackOverflow no está en español. Busca un mensaje de error de una librería y la respuesta estará en inglés, y sí, en StackOverflow. Así que el stack de un full stack programmer debe incluir al menos ese lenguaje, el inglés. Aunque sea para saber qué significan las palabras full stack.

¿Cómo se instala este programa? Es frase escuchada en másters de informática en todos sitios. El problema es que cuando han visto sistemas operativos no han visto qué es el kernel, cómo se levantan servicios o cómo ver el rendimiento del mismo, sino semáforos y cómo almacenan los discos duros la información en bloques. Seguramente muy útiles, pero no si eso excluye que te expliquen como instalar un paquete desde la línea de órdenes. Y esto implica conocer una serie de cosas: el sistema operativo Linux, trabajar con la línea de órdenes y conceptos básicos como servicios, demonios o niveles de ejecución. Mucha gente tendrá la suerte de trabajar en una gran empresa donde el departamento de sistemas le proporcionará un ordenador con todo instalado. La mayoría tendrá que trabajar en entornos no tan favorables y le darán una máquina vacía en la que tendrá que instalar todo para ponerse a trabajar en un par de horas con el resto del equipo. Y eso es saber Linux, es conocer la ínea de órdenes y cómo montar un servidor web con una base de datos NoSQL.

El 99% de los trabajos en equipo en la carrera se hacen usando email o, los más modernos, Dropbox o similar. Es desde luego un avance a cuando se hacía con disquetes, pero un atraso a hacerlo usando un sistema de control de fuentes como git. Con git sabes quién ha hecho qué, puedes volver atrás, probar cosas simultáneamente, crear y resolver tareas en entornos como GitHub… En público o en privado, no conocer Git y GitHub te hace ser más improductivo, y por tanto menos empleable. Ojo, que como todo lo de arriba no es culpa tuya (en parte), sino que a nadie se le ocurrió que las aplicaciones se desarrollaban en equipo normalmente y aprender un sistema como este era fundamental.

Una herramienta como git sólo te lleva al principio del camino, trabajar sobre los mismos fuentes sin demasiados follones. Pero, ¿quién hace qué? ¿Cómo se informa a los demás de lo que está haciendo? ¿Si surge alguna duda o no sabes cómo hacer algo, a quién le preguntas? ¿Cómo se decide qué características nueva implementar? ¿Y cómo se informa de un error que ha pasado los tests o la petición de una nueva característica?

En el mundo del software libre ya hay herramientas para todo ello: gestores de incidencias como RedMine o los más básicos integrados en GitHub o Gitlab, listas de correo, canales de IRC siempre abiertos para ayudar a los principiantes.

Y StackOverflow. StackOverflow es el oráculo de Delfos y el consultorio de Elena Francis pero para un programador. Pregunta y se te responderá. ¿Que quieres adaptar una librería OpenGL para hacer programas de escritorio en XSLT? Pregunta. ¿Que quieres conectar tu Casiotone a tu Arduino? Pregunta. ¿Que del error que te ha dado ha salido un puño de la pantalla y te ha dado en tus partes? Pregunta. StackOverflow es el aleph, todo está allí y todo se sabe. Os voy a decir un secreto: los profesores de la uni no sabemos todo. De hecho, es probable que si te ha salido un error al instalar no sé qué herramienta no tengamos ni puñetera idea de qué se trata. Pregunta en StackOverflow. Primero busca, claro. Si no lo encuentras, pregunta.

Esta es una batalla perdida. Ningún informático que se respete a sí mismo documentará nada. Pero si lo hace, por favor, que no lo haga en Word. Especialmente no en Word. Todos los lenguajes de programación (entre los que no se incluye Matlab) incluyen su propio sistema de documentación, pero también hay otros sistemas Textile, Markdown o Latex que permite escribir documentación estructurada aparte de los ficheros de la aplicación. De ahí, generar cualquier cosa es fácil: PDF, HTML o un ePub. Además, se aprende en cinco minutos, lo que equivale a 0.000005 créditos ECTS. O 25, según se mida.

¿Cómo se publica una aplicación? Se mete en un zip y se copia al servidor por FTP, ¿no?

No. En entornos de integración/despliegue o publicación continua se hace automáticamente: test, generación de ficheros para despliegue, ejecución de lo necesario para el despliegue (¿hará falta una base de datos? ¿un servidor de mensajería? ¿una red privada virtual?) y efectivamente despliegue de la aplicación desde un entorno de gestión de fuentes como el de arriba. Todo ello, por supuesto, usando herramientas libres. ¿Es el desarrollo basado en test una materia arcana? Pues es posible, porque se ve relativamente poco en graduados en universidades españolas. En una empresa, o al menos una buena empresa, nada se despliega si no ha pasado todos los tests.

Cuando creas algo en software libre, lo creas en abierto, donde todo el mundo puede verlo. Sabes que si hay algún hueco de seguridad, alguien te lo va a encontrar. Hay una alta probabilidad de que sea buena gente y te avise, pero también puede ser que no; en todo caso eres consciente de que la seguridad no es algo que se le añade a un programa al final cuando está todo terminado: es un requisito fundamental. Tienes que pensar en todos los posibles huecos y evitarlos, usar prácticas seguras, usar versiones de las librerías sin huecos de seguridad conocidos.

Eso no sería así sin el software libre: por un lado por la mentalidad y la cultura que uno ocupa cuando se pone a programar (recuerda, en un equipo) y por otro porque la mayoría de las herramientas que van a usar son libres y, por tanto, confías en ellas porque han pasado los mismos controles y los ha visto tanta gente (posiblemente más) que tu herramienta.

Y van todas juntas porque, al fin y al cabo, están relacionados con lenguajes e idiomas y formas de relacionarse con el usuario. Además, son dos dades y dos ciones, así que queda todo paralelo y simétrico. La accesibilidad y la usabilidad están íntimamente relacionadas: para cierto tipo de usuarios (por ejemplo, yo que ya no veo como solía hacerlo), el identificar las funcionalidades de una web y poder interacturar con ella es cuestión de poder cambiar el tamaño de letra y de usar contrastes adecuados. La accesibilidad universal va más allá e implica que cualquier persona con cualquier diversidad funcionar pueda acceder. Las ciones, igual: que el programa pueda trabajar en cualquier idioma. Las agrupo juntas porque son el tipo de cosas de “Bueno, si eso, cuando llegue la necesidad, ya lo metemos”. Pero nunca se funciona así: un programa accesible, usable, que se pueda traducir fácilmente a cualquier idioma, necesita principios de diseño (casos de uso, por ejemplo, trabajar con las librerías básicas de traducción) que no se pueden simplemente añadir luego. Traducir una aplicación al inglés puede ser un infierno de buscar cadenas por los fuentes (y ser incapaz de hacer cosas que requieran ir más allá, como trabajar con diferentes sentidos en la escritura) o tan fácil como suministrar un fichero a un traductor; la accesibilidad exactamente igual. Puede ser imposible o tan fácil como trabajar con las herramientas de accesibilidad habituales del sistema operativo y hacerles el trabajo fácil. En la primera iteración de este artículo no estaban porque es cierto que, salvo la usabilidad, no es algo que se suela tener en cuenta en la empresa habitualmente. Pero debería tenerse, si queremos que una aplicación llegue a todo el mundo y, sobre todo, si queremos generar esas nuevas versiones fácil y eficientemente.

Aquí se incluye, como es natural, la codificación de ficheros y cadenas y en general todo. Cuando a alguien le empiezan a salir símbolos raros se echan las manos a la cabeza, cuando es simplemente Unicode, que sirve para algo más que para poner caracteres cachondos en el Twitter. Unicode, UTF-8, todas esas cosas, todavía no se explican en Informática lo que causa múltiples problemas a la hora de trabajar con ficheros, bases de datos y programas que tengan diferentes concentos de la codificación.

¿Cómo? ¿Estadística? ¿Eso no es matemáticas? No, es informática y es imprescindible cuando analizas las prestaciones de un sistema o un programa. Pídele a un informático recién licenciado que te diga qué carga es capaz de soportar una aplicación web. “Uf, un mogollón porque uso un servidor súper guay”. Si le indicas que puede ser que no, te es capaz de montar un proxy con equilibrado de carga. Pero ¿es capaz de leer un log y modelar esa carga? ¿Es capaz de montarte un test de esfuerzo sobre el servidor con diferentes escenarios a partir de ese modelo de carga? ¿Es, simplemente, capaz de probar dos diferentes implementaciones de un algoritmo y decirte, estadísticamente, cuál es la más eficiente usando algo tan simple como un test de Wilcoxon o, más aún, decidir si se usa uno de Wilcoxon o u T de Student? O, volviendo al tema anterior, ¿saben montar un test de usabilidad con un grupo de usuarios y analizar los resultados?

Lo más normal es que no. De hecho, puede que este no sea un problema del plan de estudios, porque la mayoría incluyen Estadística, sino de no cruzar el puente entre las técnicas estadísticas y su uso en el diseño e implementación de sistemas informáticos. O de dejar la estadística como una asignatura de primero y no como algo fundamental que interesa al resto de las asignaturas de programación y de sistemas.