trancos123
Madmaxista
- Desde
- 6 Jul 2009
- Mensajes
- 5.877
- Reputación
- 11.708
Lo que se aprende, o debería, en la carrera de informática | Ricardo Galli, de software libre
En mi apunte anterior “Lo que demanda el mercado…” critiqué la obstinación de algunas autoridades universitarias, especialmente las de la mía, en su posicionamiento extremamente conservadora contra el GNU/Linux… y cómo el tiempo les ha quitado la razón (yo diría que debería haberles avergonzado). A pesar de los dos enlaces que puse en la posdata, muchos interpretaron que pensaba que la universidad debe enseñar GNU/Linux porque tiene más salida laboral. Otros opinaron (sobre todo en Twitter) sobre lo poco que se aprende en la universidad de las últimas tecnologías [de moda].
Hace cinco años escribí un apunte muy largo sobre este tema: Sintonizar universidades y empresas, pero ¿qué debe saber un ingeniero? (y hay más, de gente más importante y valiosa que yo, como ¿Qué deberíamos enseñar a los nuevos desarrolladores? de Bjarne Stroustrup), ahora intentaré ser muy breve para contestar a esos dos temas.
No creo en ellos, ni afirmé, que se deba enseñar GNU/Linux porque es lo que demanda el mercado, sólo demostré la falacia de justificar su casi prohibición en la universidad basada en el argumento que no es lo que el “mercado quiere”, o que es “poco profesional” (prometo que me cansé de oír esas frases repetida por los burócratas de las TI de mi universidad).
No sé qué tecnologías se usarán dentro de diez años, pero vista la evolución actual (Linux hasta en los bolsillos…), apostaría a que es más probable que siga habiendo un uso importante de Linux y sistemas derivados. Con lo que eso provoca social, económica, y empresarialmente.
Aún así, no me cerraría en ello, si viese que surgen alternativas diferentes, tecnológicamente seductora, prometedora, y con una comunidad de frikis early adopters entusiasmados, lo analizaría con mucha curiosidad y dejaría que esa comunidad crezca y ponga sus herramientas al límite. Si fuese una autoridad académica, haría lo posible para favorecer iniciativas, por que no podemos estar seguro de si será nuestro entorno profesional del futuro.
Lo que nunca haría es basar decisiones universitaria-académicas únicamente a lo que el “mercado demanda”, y mucho menos intentaría perjudicar a iniciativas alternativas al status quo. Sólo de una cosa estoy seguro: el status quo tiene caducidad, aunque no sepamos la fecha.
Por otro lado, son típicas las quejas del tipo (ejemplo real, de Twitter)
Salí de la universidad sin saber qué era un servidor de aplicaciones. ¡Qué atrasados!
En este caso en particular, no veo el problema. Un servidor de aplicaciones es sólo un servidor que implementa paso de mensajes distribuidos con mecanismo de rendevouz cliente-servidor (i.e. el servidor espera por conexiones que inician los clientes), y sincronización general de llamada a procedimientos remoto (i.e. bloqueo del emisor hasta recibir respuesta del receptor, en este caso el servidor), con técnicas para minimizar los tiempos de esperas, como mantener un pool de hilos en marcha (i.e. temas simples de gestión de procesos).
Conociendo esos temas fundamentales -los estudiaron en redes y algoritmos concurrentes y distribuidos- no hace falta conocer al detalle la tecnología de un fabricante o plataforma en particular (en este caso seguramente se refería a la Java 2 Enterprise Edition) para poder coger el manual y empezar a producir en pocas horas.
Otro tipo de queja habitual es (elijo este ejemplo porque además incluye el hype de moda, NoSQL):
Tuve dos asignaturas de bases de datos relacionales, y cuando voy a una empresa usan NoSQL, que nunca vimos en la universidad ¡Qué atrasados!
Parece creer que las base de datos relacionales tuviesen los días contados, y no involucrase conceptos importantes como álgebra, almacenamiento, atomicidad, concurrencia, serialización de operaciones, etc. Pero lo más importante, el NoSQL es sólo volver a usar los viejos sistemas de bases de datos simples con hashes o B-Trees pero con esteroides: replicación, distribución, índices multi columnas. Con saber los conceptos básicos de ficheros, estructuras de árboles de búsquedas, consultas algebraicas (estudiadas en base de datos) y algoritmos distribuidos ya se tienen las nociones importantes para saber cómo funcionan e implementan esos sistemas. No tiene sentido que se pierda tiempo aprendiendo los detalles de Redis, Memcached, Cassandra, MongoDB, etc. durante la carrera. El tiempo es limitado, y quizás cuando acaben la carrera en un par de años, esas herramientas hayan cambiado mucho.
Un problema es no saber distinguir los conceptos fundamentales de las implementaciones tecnológicas particulares (y el hype de los vendedores de la plataforma). El otro problema es no saber que, aunque se quejan del tiempo que pasan en clases, el tiempo es finito y es imposible enseñar y entrenar en cada una de las tecnologías y productos que se usan en el mercado. Menos aún si queremos formar a los alumnos para que sean profesionales en cualquier “mercado”, no sólo en el que rodea a cada universidad.
Estos temas más locales, o de formación más profesional -es decir, con entrenamiento que demanda el mercado- deberían dejarse en todo caso para los master profesionales.
Pequeño bonus
Muchos se preguntarán qué conceptos fundamentales deberían conocerse en la carrera, no puedo hacer una lista exhaustiva, pero aquí van unos pocos ejemplos.
Programación en C. Es un lenguaje muy sencillo, pero que obliga a pensar y programar a un nivel muy próximo a la arquitectura de ordenadores. Por ejemplo, saber cómo se almacenan los datos en memoria, y la necesidad de manipular punteros. Esto de una idea del trabajo de los compiladores e intérpretes de otros lenguajes a la hora de convertir gestión de estructuras sofisticadas al nivel de ejecución.
Estructuras de datos. Arrays, listas, colas, pilas, colas con prioridad, heaps, hashes, árboles balanceados, árboles balanceados de búsqueda, árboles radix, representaciones de grafos, B-Trees.
Algoritmos fundamentales. Se debería conocer los algoritmos de ordenamientos y sus análisis de complejidad, diferencias entre P, NP y NP completo, implementar de memoria al menos el quicksort y mergesort. Recursividad, algoritmos de grafos, se debería saber implementar de memoria un depth-first-search, bread-first search (y su “primo”, el algoritmo del camino más corto de Dijkstra), backtracking, manipulación y operaciones de datos binarios, programación dinámica, algoritmos distribuidos, operaciones matriciales, patrones de strings, expresiones regulares, geometría computacional, etc.
Programación orientada a objetos. Dominar al menos un lenguaje orientado a objetos, como C++, Java, C# o incluso Python (con objetos).
Conceptos básicos de sistemas operativos. Gestión de memoria, de procesos, sistemas de ficheros (se debería ser capaz de implementar un sistema de ficheros completo, uno basado en i-nodos no toma más de 2000 líneas en C, un FAT es aún más sencillo).
Gestión de procesos y concurrencia. Los procesos son la unidad de ejecución fundamental, hay que conocer cómo están estructurados y gestionados por el sistema operativo, y los problemas de acceso concurrente a recursos compartidos (secciones críticas, exclusión mutua, interbloqueo, esperas infinitas, spinlocks, instrucciones de hardware, mutexes, semáforos, monitores, lectores escritores, mensajes, sincronización, etc.)
Administración de Sistemas. Linea de comandos en Unix, programación en shell y en al menos otro lenguaje de scripting como Python, Perl o Ruby. Gestión de procesos, usuarios, grupos y permisos. Comandos más utiles y usados, grep, find, awk, sort, netcat, tcpdump… Sistema de arranque. Configuración de correo, servidores web, interfaces de red, ssh (y derivados), gestión de claves y certificados, manipulación y recuperación de sistemas de ficheros, sistemas de ficheros remotos (NFS, SMB…).
Esta es una lista pequeña e incompleta, pero creo que forman parte del “núcleo”, de lo que considero debe dominar un ingeniero informático cuando acaba su carrera, en cualquier de las ramas. La mayoría de ellos se estudian en clases (o deberían), pero hay otros que son de “cultura general”, o que deberían aprender los alumnos por sí mismos. Por ejemplo, no tiene sentido que se dediquen horas de clases a enseñar programación en shell o ssh, sino que cada uno debe estar motivado para aprenderlo durante su carrera, o el profesor incentivar a que lo hagan, porque también facilitan el trabajo a los alumnos.
Si eres ingeniero informático y hay algunos de esos temas que no sabes, todavía tienes tiempo de aprender. Muchos de los temas que menciono los aprendí después de acabar la carrera -imagina el nivel, además la hice cuando no había libros de textos de algunos de los temas más novedosos-, a otros los aprendí de verdad cuando tuve que enseñarlos. Es en ese momento cuando te das cuenta de los agujeros del conocimiento que tienes (es la mayor ventaja de dar clases).
En mi apunte anterior “Lo que demanda el mercado…” critiqué la obstinación de algunas autoridades universitarias, especialmente las de la mía, en su posicionamiento extremamente conservadora contra el GNU/Linux… y cómo el tiempo les ha quitado la razón (yo diría que debería haberles avergonzado). A pesar de los dos enlaces que puse en la posdata, muchos interpretaron que pensaba que la universidad debe enseñar GNU/Linux porque tiene más salida laboral. Otros opinaron (sobre todo en Twitter) sobre lo poco que se aprende en la universidad de las últimas tecnologías [de moda].
Hace cinco años escribí un apunte muy largo sobre este tema: Sintonizar universidades y empresas, pero ¿qué debe saber un ingeniero? (y hay más, de gente más importante y valiosa que yo, como ¿Qué deberíamos enseñar a los nuevos desarrolladores? de Bjarne Stroustrup), ahora intentaré ser muy breve para contestar a esos dos temas.
No creo en ellos, ni afirmé, que se deba enseñar GNU/Linux porque es lo que demanda el mercado, sólo demostré la falacia de justificar su casi prohibición en la universidad basada en el argumento que no es lo que el “mercado quiere”, o que es “poco profesional” (prometo que me cansé de oír esas frases repetida por los burócratas de las TI de mi universidad).
No sé qué tecnologías se usarán dentro de diez años, pero vista la evolución actual (Linux hasta en los bolsillos…), apostaría a que es más probable que siga habiendo un uso importante de Linux y sistemas derivados. Con lo que eso provoca social, económica, y empresarialmente.
Aún así, no me cerraría en ello, si viese que surgen alternativas diferentes, tecnológicamente seductora, prometedora, y con una comunidad de frikis early adopters entusiasmados, lo analizaría con mucha curiosidad y dejaría que esa comunidad crezca y ponga sus herramientas al límite. Si fuese una autoridad académica, haría lo posible para favorecer iniciativas, por que no podemos estar seguro de si será nuestro entorno profesional del futuro.
Lo que nunca haría es basar decisiones universitaria-académicas únicamente a lo que el “mercado demanda”, y mucho menos intentaría perjudicar a iniciativas alternativas al status quo. Sólo de una cosa estoy seguro: el status quo tiene caducidad, aunque no sepamos la fecha.
Por otro lado, son típicas las quejas del tipo (ejemplo real, de Twitter)
Salí de la universidad sin saber qué era un servidor de aplicaciones. ¡Qué atrasados!
En este caso en particular, no veo el problema. Un servidor de aplicaciones es sólo un servidor que implementa paso de mensajes distribuidos con mecanismo de rendevouz cliente-servidor (i.e. el servidor espera por conexiones que inician los clientes), y sincronización general de llamada a procedimientos remoto (i.e. bloqueo del emisor hasta recibir respuesta del receptor, en este caso el servidor), con técnicas para minimizar los tiempos de esperas, como mantener un pool de hilos en marcha (i.e. temas simples de gestión de procesos).
Conociendo esos temas fundamentales -los estudiaron en redes y algoritmos concurrentes y distribuidos- no hace falta conocer al detalle la tecnología de un fabricante o plataforma en particular (en este caso seguramente se refería a la Java 2 Enterprise Edition) para poder coger el manual y empezar a producir en pocas horas.
Otro tipo de queja habitual es (elijo este ejemplo porque además incluye el hype de moda, NoSQL):
Tuve dos asignaturas de bases de datos relacionales, y cuando voy a una empresa usan NoSQL, que nunca vimos en la universidad ¡Qué atrasados!
Parece creer que las base de datos relacionales tuviesen los días contados, y no involucrase conceptos importantes como álgebra, almacenamiento, atomicidad, concurrencia, serialización de operaciones, etc. Pero lo más importante, el NoSQL es sólo volver a usar los viejos sistemas de bases de datos simples con hashes o B-Trees pero con esteroides: replicación, distribución, índices multi columnas. Con saber los conceptos básicos de ficheros, estructuras de árboles de búsquedas, consultas algebraicas (estudiadas en base de datos) y algoritmos distribuidos ya se tienen las nociones importantes para saber cómo funcionan e implementan esos sistemas. No tiene sentido que se pierda tiempo aprendiendo los detalles de Redis, Memcached, Cassandra, MongoDB, etc. durante la carrera. El tiempo es limitado, y quizás cuando acaben la carrera en un par de años, esas herramientas hayan cambiado mucho.
Un problema es no saber distinguir los conceptos fundamentales de las implementaciones tecnológicas particulares (y el hype de los vendedores de la plataforma). El otro problema es no saber que, aunque se quejan del tiempo que pasan en clases, el tiempo es finito y es imposible enseñar y entrenar en cada una de las tecnologías y productos que se usan en el mercado. Menos aún si queremos formar a los alumnos para que sean profesionales en cualquier “mercado”, no sólo en el que rodea a cada universidad.
Estos temas más locales, o de formación más profesional -es decir, con entrenamiento que demanda el mercado- deberían dejarse en todo caso para los master profesionales.
Pequeño bonus
Muchos se preguntarán qué conceptos fundamentales deberían conocerse en la carrera, no puedo hacer una lista exhaustiva, pero aquí van unos pocos ejemplos.
Programación en C. Es un lenguaje muy sencillo, pero que obliga a pensar y programar a un nivel muy próximo a la arquitectura de ordenadores. Por ejemplo, saber cómo se almacenan los datos en memoria, y la necesidad de manipular punteros. Esto de una idea del trabajo de los compiladores e intérpretes de otros lenguajes a la hora de convertir gestión de estructuras sofisticadas al nivel de ejecución.
Estructuras de datos. Arrays, listas, colas, pilas, colas con prioridad, heaps, hashes, árboles balanceados, árboles balanceados de búsqueda, árboles radix, representaciones de grafos, B-Trees.
Algoritmos fundamentales. Se debería conocer los algoritmos de ordenamientos y sus análisis de complejidad, diferencias entre P, NP y NP completo, implementar de memoria al menos el quicksort y mergesort. Recursividad, algoritmos de grafos, se debería saber implementar de memoria un depth-first-search, bread-first search (y su “primo”, el algoritmo del camino más corto de Dijkstra), backtracking, manipulación y operaciones de datos binarios, programación dinámica, algoritmos distribuidos, operaciones matriciales, patrones de strings, expresiones regulares, geometría computacional, etc.
Programación orientada a objetos. Dominar al menos un lenguaje orientado a objetos, como C++, Java, C# o incluso Python (con objetos).
Conceptos básicos de sistemas operativos. Gestión de memoria, de procesos, sistemas de ficheros (se debería ser capaz de implementar un sistema de ficheros completo, uno basado en i-nodos no toma más de 2000 líneas en C, un FAT es aún más sencillo).
Gestión de procesos y concurrencia. Los procesos son la unidad de ejecución fundamental, hay que conocer cómo están estructurados y gestionados por el sistema operativo, y los problemas de acceso concurrente a recursos compartidos (secciones críticas, exclusión mutua, interbloqueo, esperas infinitas, spinlocks, instrucciones de hardware, mutexes, semáforos, monitores, lectores escritores, mensajes, sincronización, etc.)
Administración de Sistemas. Linea de comandos en Unix, programación en shell y en al menos otro lenguaje de scripting como Python, Perl o Ruby. Gestión de procesos, usuarios, grupos y permisos. Comandos más utiles y usados, grep, find, awk, sort, netcat, tcpdump… Sistema de arranque. Configuración de correo, servidores web, interfaces de red, ssh (y derivados), gestión de claves y certificados, manipulación y recuperación de sistemas de ficheros, sistemas de ficheros remotos (NFS, SMB…).
Esta es una lista pequeña e incompleta, pero creo que forman parte del “núcleo”, de lo que considero debe dominar un ingeniero informático cuando acaba su carrera, en cualquier de las ramas. La mayoría de ellos se estudian en clases (o deberían), pero hay otros que son de “cultura general”, o que deberían aprender los alumnos por sí mismos. Por ejemplo, no tiene sentido que se dediquen horas de clases a enseñar programación en shell o ssh, sino que cada uno debe estar motivado para aprenderlo durante su carrera, o el profesor incentivar a que lo hagan, porque también facilitan el trabajo a los alumnos.
Si eres ingeniero informático y hay algunos de esos temas que no sabes, todavía tienes tiempo de aprender. Muchos de los temas que menciono los aprendí después de acabar la carrera -imagina el nivel, además la hice cuando no había libros de textos de algunos de los temas más novedosos-, a otros los aprendí de verdad cuando tuve que enseñarlos. Es en ese momento cuando te das cuenta de los agujeros del conocimiento que tienes (es la mayor ventaja de dar clases).
