Envío erróneo o controvertido, por favor lee los comentarios.
(...)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 (...) 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.
|
etiquetas: informática , mercado laboral , ingeniero 
Con respecto a la persecución de Linux.... me da a mi que la Universidad de Gallir es un poco del siglo XIX porque en la mía hace 10 años se daba (y se da) el 90% de asignaturas en entornos Unix.
1. Ingeniería de Software, sobre todo en levantamiento "perfecto" de requisitos que no dejen duda alguna para el cliente e ingeniero que es lo que se va a desarrollar.
2. Métricas de software, para que sepa cuanto tiempo real toma un desarrollo y no el cálculo a ojo.
3. Un poco de economía y contabilidad... que los clientes hablan de dinero todo el tiempo hasta en los requisitos.
4. Pragmatismo... si es una sencilla aplicación móvil se hace con PhoneGap y listo, no es obsesionarse con hacer aplicaciones nativas para cada plataforma. Aplique lo mismo para mucho software que ya está hecho, no es necesario desarrollar siempre de cero.
5. Trabajo en grupo y liderazgo
6. Relaciones sociales, interpersonales, laborales... que es preferible alguien bueno en su oficio y amable/amistoso/discreto a un megamaster excelente pero pedante/conflictivo/siembra cizaña
7. Recursivo, que si se llega a una empresa y todavía el servidor es Windows 2000 Server y los puestos con Windows XP, no pegue el grito en el cielo, hay que defenderse con lo que se tiene y mejorarlo en lo posible.
8. Pedagógico, que hay muchos colegas en la empresa que son muy buenos en su oficio pero son malos en cuanto a informática se refiere, así que debe facilitar muchísimo la adopción de las nuevas tecnologías.
gist.github.com/dchest/1091803#
Sobre lo demás, mirando el código de la implentación de FAT en software libre te aprendes el sistema de ficheros (es jodidamente simple).
Y no lo dice un ingeniero, si no un futuro técnico superior.
Respecto a su explicación del C, con esos motivos, veo mejor enseñar a usar un lenguaje ensamblador.
De Sistemas Operativos me enseñaron bastante poco. No he trabajado con ellos, pero me hubiera gustado alguna asignatura algo más dedicada a eso (mi asignatura de sistemas operativos era una de estas en las que no se aprende gran cosa porque el profesor pasa bastante)
Por lo demás estoy bastante de acuerdo, sobre todo en el tema de concurrencia, que se trata un poco de refilón y luego en algunas aplicaciones pasa lo que pasa (y no hay quien detecte por qué).
Echo de menos algo sobre redes. Sé que eso es más de telecomunicaciones, pero parece que la tendencia es a confluir.
Quiero decir que en terminos de eficiencia y capacidad de llegar a optimización a bajo nivel el C es comparable al ensamblador, pero encima se gana en legibilidad y mantenimiento, además de en portabilidad. No en vano Unix (como Linux) está escrito en C y nadie duda de ni de su rendimiento ni de su portabilidad ni de su legibilidad.
Por eso tiene sentido enseñar C muy por encima de enseñar un ensamblador.
Yo creo que, a efectos educativos, es más instructivo enseñar un emsamblador que C.
www.meneame.net/story/aprender-gestionar-emociones
www.meneame.net/search.php?q=inteligencia+emocional
Y a protegerse de
www.meneame.net/c/12507016
¿y las enseñanzas toxicas que no se deberian enseñar, ni aprender?
www.meneame.net/c/12559703
Uhm, O eres un genio o no sé como lo harás para programar en ASM para m68k , ARM y X86_64 a la vez.
Además que UNIX y C son como uña y carne. Aprender la API de UNIX es aprender C, ( Y viceversa) y es el SO más portable y a la vez de los más simples en diseño que existe.
Encima la mayoría de implementaciones son libres y abiertas . Killer combo.
Creo que así aprendes de ambos, de compiladores y además ves las relaciones entre los dos de forma más clara que si solo te centrases en uno de ellos.
- Que un programador no es el chico de los recados. Que programar bien es un trabajo costoso, complicado y que requiere ingenio. Y que los resultados se notan cuando algo lo ha hecho un buen programador frente a lo que pueda hacer un aprendiz.
- Que los proyectos debe liderarlos alguien que sepa lo que tiene entre manos, no D. Ramón, el jefe de toda la vida.
- Que los sistemas requieren recursos hardware, y ahorrar en máquina es penar durante años en todo lo demás.
- ¡Que los informáticos existen para algo, coño!
Tenía que desahogarme.
Tipos de datos.
Estructuras y referencias a lss mismas.
Algoritmos.
Y si para eso tienen que programar en asembler o C, pues vale.
Estoy harto de ver como la gente programa como si tuviese todos los recursos del mundo mundial y todo fuese a ir bien.
Y es que el secreto de un buen sistema es que no falle ni se cuelgue jamas.
(Estoy en movil, acentos no).
Era muy divertido lo del PDP-11 ya que era emular mac con basilisk y luego emular la maquina PDP-11 en basilisk.
Por supuesto ahora con Bolonia ha cambiado y Paralelismo es obligatoria en alguna especialidad propia del Grado.. pero sigo pensando que van algo 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).
Esto puede definir a un servidor de red justo unos milisegundos antes de convertirse en un auténtico servidor de aplicaciones... o no. Con lo que queda demostrado lo que argumentaban en Twitter:
> Salí de la universidad sin saber qué era un servidor de aplicaciones. ¡Qué atrasados!
Bueno, aparte del COBOL en realidad hay otra, la capacidad de seguir aprendiendo. El que piense que lo que sabe ahora va a servir de mucho dentro de 20 años (salvo el COBOL) está equivocado.
Tu vas para economista o para RRHH ¿verdad?
1. Es muy importante la ingenieria del software, pero si has trabajado en una empresa privada (lejos del mundo académico) sabrás que el "levantamiento perfecto" de los requisitos no existe. Así de duro y categórico lo digo: no existe, ni se puede. Hay casos en los que tratas con gente que medianamente entiende la parte técnica del problema y se es más certero, pero siempre, siempre siempre quedan cosas sin definir que no salen hasta mediados de proyecto o que incluso cuando se le entrega al cliente saca cosas nuevas o directamente modifica las anteriores. En este caso la única herramienta que se acerca a la realidad son las que dan las metodologías ágiles, un backlog modificable e intentar recibir feedback del cliente lo más temprano y frecuente posible.
2. Métricas: Completamente en desacuerdo contigo. Esta es la mayor mentira que les cuelan a los estudiantes de ingenieria del software, que existen métricas formales que te dicen con exactitud la estimación de tiempo de un proyecto o incluso la productividad de un desarrollador. Me gustan técnicas como los puntos de esfuerzo asociadas a historias de usuario tanto para medir la productividad como estimar la velocidad del equipo (y por tanto estimar en tiempo) pero aún así son estimaciones hechas a ojo según la experiencia y que incluso éstas hay muchas veces que no se hacen bien (siempre hay algún impedimento o algo que no se tuvo en cuenta que da al traste con toda tu estimación).
3. Si, aunque no es tan necesario. Todo el mundo sabe lo básico, un proyecto tiene costes y hay que ajustarse al presupuesto, más allá de eso de poco ayuda saber hacer asientos contables ..., exigir a un desarrollador que sepa de contabilidad para que sea capaz de ajustarse al presupuesto me parece un poco overkill
4. Aunque tiene mucha lógica lo que dices estoy muy en desacuerdo, de hecho yo lo plantería al revés. Hay que ser pragmático pero hasta cierto punto, sin pasarse. Si a tu aplicación le basta con hacerse en PhoneGap, es que no necesita ser una aplicación, haces una web móvil y punto (mejor una web que una mierda de webapp). Si el cliente quiere una aplicación visible en la appstore, por dios, que se haga en condiciones, si vas a hacer una mierda deberías comunicarle al cliente que su aplicación va a ser una mierda, que va a cosechar criticas que van a dejar bien claro lo mierda que es la aplicación y va a empeorar su imagen de marca (ver el caso de la app de facebook cuando fue hecha en html5). Las cosas o se hacen bien o mejor no hacerlas (a menos que queramos estafar al cliente, coger la pasta y salir corriendo).
5. Muy de acuerdo.
6. Si, y me atrevería decir que como en todos lados y a cualquier puesto de trabajo.
7. No estoy del todo de acuerdo contigo, claro que hay que poner el grito en el cielo, hacer notar desde el principio qué es lo que falla en la empresa. Si un equipo está anticuado y empobreciendo la productividad de la empresa o la calidad del software, hay que ponerlo de relieve cuanto antes. Si nos resignamos la mierda se acumula y acaba estallandonos a todos (y al que no se quejó es al primero que le estalla).
8. Muy de acuerdo contigo, hay que reciclarse, incluso dentro de una misma tecnología. Si aprendiste a resolver un problema de una forma, no te acomodes y lo resuelvas siempre de la misma forma cada vez que surja, prueba nuevas maneras que seguro que se encuentran mejores.
Un saludo
Ensamblador yo vi el MIPS R2000, no es práctico, pero tampoco Haskell. Hay que ver los distintos paradigmas y los distintos niveles.
Son puntos importantes, no cabe duda, que luego tengan sus limitaciones es otra cosa.
Teniendo en cuenta lo que se hace en España informáticamente hablando, no prepararles para lo que el mercado demanda, es abocarlos directamente al paro o a la emigración.
Una opción es buena, la otra no.
#36 para eso estudio para programador.
#0 ¿ ingeniería de sistemas informáticos?, ¿ ingeniería de software?, ¿ ingeniería en ciencias de la computación?, a que ingeniería estas enfocándote?, todos los ingenieros son desarrolladores?, todos los ingenieros son programadores?, todos analistas funcionales?, todos operativos?, todos administradores?...