Portada
mis comunidades
otras secciones
#1:
Informatica deberia preparar a los estudiantes para montar pcs, pasar antivirus, descargar musica de internet y conseguir programas crakeados gratis
Es lo que el mercado demanda a todo chico de la informatica profesional.
Es lo que el mercado demanda a todo chico de la informatica profesional.
#2:
Yo estoy harto de defender lo que dice Gallir en esta entrada pero la mayoría se deja guiar por el hype de algunos "gurus".
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.
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.
#5:
"Esta es una lista pequeña e incompleta", si que lo es, porque el ingeniero en informática también debe entender a sus futuros clientes, luego es muy importante:
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.
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.
#11:
#8 Es un absurdo enseñar un lenguaje ensamblador, pues solo te vas a ceñir a una arquitectura. El C al fin y al cabo un es un "ensamblador" multiplataforma, con además de esa ventaja, tener una estructura de programación más limpia y funcional que cualquier ensamblador.
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.
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.
#33:
#5 Desde mi experiencia, hay cosas con las que estoy de acuerdo y cosas con las que no:
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
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
Comentarios
Informatica deberia preparar a los estudiantes para montar pcs, pasar antivirus, descargar musica de internet y conseguir programas crakeados gratis
Es lo que el mercado demanda a todo chico de la informatica profesional.
#1 Troll-azo...
#3 Nov-ato...
#1 : Pues estás en el mercado equivocado.
#1 Eso ya existe, se llama Técnico en Administración de sistemas y es un grado medio
#1 lo hace, pero aun sin curricula oficial.
#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?...
Yo estoy harto de defender lo que dice Gallir en esta entrada pero la mayoría se deja guiar por el hype de algunos "gurus".
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.
"Esta es una lista pequeña e incompleta", si que lo es, porque el ingeniero en informática también debe entender a sus futuros clientes, luego es muy importante:
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.
#5
Tu vas para economista o para RRHH ¿verdad?
#5 Desde mi experiencia, hay cosas con las que estoy de acuerdo y cosas con las que no:
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
#33 En los dos primeros puntos tengo que decir, que estoy de acuerdo contigo, pero tampoco eso hace que sea totalmente fútil hacerlo. Es un error esperar que toda la planificación se cumpla a raja tabla, pero no tener planificación porque no se va a cumplir tampoco es mejor.
Son puntos importantes, no cabe duda, que luego tengan sus limitaciones es otra cosa.
#39 Estoy de acuerdo contigo y me gusta que lo puntualices. Algo hay que hacer, por eso por ejemplo menciono de pasada las metodologías ágiles (que tampoco son la panacea). Hay que intentar ser certeros y sobre todo saber gestionar los riesgos: Que una funcionalidad no se haya estimado bien, que el cliente cambie de opinión, que un desarrollador se te vaya a mitad de proyecto.... etc.
Mejor habría que escribir un artículo llamado "lo que deberían aprender las empresas sobre informática".
- 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.
"implementar de memoria al menos el quicksort y mergesort" y luego ni siquiera una mención a algoritmos genéticos, redes neuronales, ni siquiera un clasificador bayesiano... creo que se le ha ido la perola a
gallir
Lo bonito de Unix es que los algoritmos y la programación en C te la puedes aprender matando dós pájaros de un tiro aprendiéndote, por ejemplo, el funcionamiento de las Coreutils de openBSD, Cuyo código es ultraclaro y mínimo.
https://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.
Sabía que el enlace era de Gallir solo leyendo el titular en candidatas.
¿Y lo que se deberia aprender en la vida?
Aprender a gestionar las emociones
Aprender a gestionar las emociones
rtve.eshttp://www.meneame.net/search.php?q=inteligencia emocional
Y a protegerse de
El BdE pide al Gobierno que se estudie en los institutos cómo protegerse ante la banca/c3#c-3
¿y las enseñanzas toxicas que no se deberian enseñar, ni aprender?
Lo que demanda el mercado, y el conservadurismo en la universidad/c25#c-25
Yo acabé la carrera hace 20 años. Solo hay una cosa de las que aprendí que tiene vigencia hoy en día y la tendrá dentro de otros 20: el COBOL.
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.
¿Nos pasamos por el forro el "Computing Curricula" de IEEE y ACM?
Todo lo que incluye en la lista (incluido Linux y unix, en una época en la que linux ni por asomo era lo que es ahora) es lo que me enseñaron a mí.
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.
#8 Es un absurdo enseñar un lenguaje ensamblador, pues solo te vas a ceñir a una arquitectura. El C al fin y al cabo un es un "ensamblador" multiplataforma, con además de esa ventaja, tener una estructura de programación más limpia y funcional que cualquier ensamblador.
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.
#11 Para mí no es un absurdo. Es la mejor forma de comprender referencias, reservas de memoria... lo hagas en la arquitectura que lo hagas.
Yo creo que, a efectos educativos, es más instructivo enseñar un emsamblador que C.
#13 "Es la mejor forma de comprender referencias, reservas de memoria... lo hagas en la arquitectura que lo hagas."
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.
#16 "Aprender ensamblador" no significa "aprender a programar en ensamblador para cualquier tipo de procesador". En muchas universidades se enseña MIPS, en otras x86. No necesitas aprender a programar en todas, pero sí necesitas aprender al menos una para saber cómo funciona un microprocesador.
#20 En la UIB en computadores se hacía en PDP-11 hace años, creo que ya no, cambiaron a PowerPC o x86(pero creo que esta no)
Era muy divertido lo del PDP-11 ya que era emular mac con basilisk y luego emular la maquina PDP-11 en basilisk.
#11 #13 Pues a mi la mejor solución me parece que es con la que yo aprendí en la carrera. Se aprendía ensamblador y C de forma simultánea, a veces teniendo que implementar lo mismo en los dos, y otras requiriendo que aunque el programa fuese en C determinadas funcionalidades se hiciesen en librerías separadas en ensamblador que luego se llamaban desde C.
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.
#8: Respecto a su explicación del C, con esos motivos, veo mejor enseñar a usar un lenguaje ensamblador.
Si, pero primero pasando por C, que no es cuestión de hacer que la gente abandone la carrera.
como te dice #11, ensamblador no se debería aprender de una manera excesivamente profunda, puesto que es específico de cada plataforma, y sería mejor dejar ya que cada uno se adapte a su plataforma preferida cuando termine
de estudiarla carrera.#11 Yo creo que hay que estudiar/utilizar varios lenguajes como: ensamblador, C, Python, Java, Haskell, Prolog, Matlab.
Ensamblador yo vi el MIPS R2000, no es práctico, pero tampoco Haskell. Hay que ver los distintos paradigmas y los distintos niveles.
#8 las redes no es un asunto sólo de telecos, hoy en día la mayoría de los sistemas son distribuidos y hay que entender los protocolos de red. También hay muchos asuntos de seguridad informática que tienen que ver con redes.
Yo lo único que encuentro imperdonable (al menos en mi universidad, en Girona, es así) es que no se enseñe ni una pizca de programación web. Ya no digo un lenguaje, eso lo puedes aprender tú en tu casa, sino cómo funciona una aplicación web (estructura cliente-servidor, qué se ejecuta dónde), el patrón MVC, cómo funciona el protocolo HTTP, etc. Nosotros sólo hemos dado una asignatura de éste temario, y ha sido en 5º curso (o sea, que si has hecho la ingeniería técnica no lo ves) y optativa.
#23 Por mi parte, en la Facultad de Informática de Barcelona (UPC), encuentro imperdonable que la formación en temas de paralelismo y concurrencia sea tan "light". Existía una optativa y en Sistemas Operativos se enseña algo, pero no dejaba de ser casi una curiosidad, y eso que no hacen tantos años.
Por supuesto ahora con Bolonia ha cambiado y Paralelismo es obligatoria en alguna especialidad propia del Grado.. pero sigo pensando que van algo atrasados.
#23 Estoy contigo, en mi caso estudio en la UAB (Univsersitat Autònoma de Barcelona) y muchos estudiantes nos quejamos de lo mismo: de web... nada. Y no hablo sólo de webs, sino de interfícies y/o usabilidad, algo que, dado que es lo que hay entre cliente/usuario y aplicación , creo que es bastante importante. Lo mismo pasa en cuanto a administración de sistemas, servidores... Estoy en quinto de carrera y me queda una asignatura y el proyecto, así que sé lo que digo. Antes existían cómo libre elección, pero las quitaron primero por recortes y luego por que los precios eran simplemente prohibitivos.
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.
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.
Yo echo en falta en la carrera más asignaturas de Gráficos 3D y algoritmos de renderizado y demás cosas relacionadas con el mundo 3D.
La propia definición del artículo de lo que es un servidor de aplicaciones es incorrecta/incompleta:
> 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!
Me parece increíble que esta noticia sea calificada por muchos de irrelevante o sensacionalista. Una prueba mas de que esa parte de meneame que potencia las ínfulas censoras de los usuarios es un disparate.
Pues realmente, creo que los informaticos deberian saber programar, y no un determinado lenguaje. Quiero decir que deberian conocer al dedillo:
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).
Superficial y pedante.
#15
#15: Devuelvo el servicio por el comentario de "Snipwned" que me enviaste antes.
Menudos pardillos los linuxeros, los que somos cool programamos en objective c
#19 ¿Objective-C? Los que de verdad molamos somos los políglotas. Yo un proyecto con menos de dos lenguajes distintos no lo acepto
#19 http://www.gnustep.org/
#19, Entonces debes tener un buen cacao mental
Tipico post en el que los asociales informaticos tienen bandera verde para llorar y quejarse porque son intelectualoides y nadie los entiende. Pringaos, os robaba el bocadillo.