Ayuda con problemilla básico de Arrays JAVA (SPOILER: Soy muy malo)

[Drumpi]

¡Ah! No sé, yo para iOS desarrollo con Xamarin, no en nativo, y todo el diseño de interfaz va a través de las librerías de Xamarin.Forms. De hecho, las APPs las hago desde un Windows, y para iOS conecto VS remotamente con un MacInCloud, y sólo para compilar. Yo propuse pillar un MacMini de segunda zarpa para esto, pero salía más rentable "alquilar" el Mac virtual por meses, porque ningún cliente nos pide ya la APP para iOS (hay uno que los usa, pero parece que les sale más rentable cambiarles el móvil a los empleados que pagarnos por el port).

De hecho, yo no uso ni designer, voy todo a xaml "pelao", porque vaya porquería de interfaz: es lentísima, responde cuando le da la gana, y se arma la p*ch* un lío en cuanto haces binding a cualquier variable del modelo.

[swapd0]

Yo no uso Swift, uso Objective-C, tengo bastantes cosas en C/C++ y es facil integrarlo, no se si en Swift es igual de facil.

Y de iOS he tocado muy poco, lo que vi es que no tienes los los binding para "enganchar" los controles a las propiedades de los objetos. Supongo por problemas de rendimiento o memoria.

Lo que es un dolor en el culo es la parte del Layout, como tengas que meter algo a mano sin el IB... ufff, no he llegado a ese punto que haces click y lo ves todo claro.

[selecter25]

@Drumpi con Xamarin.Forms sí que he visto que puedes hacer cosillas a nivel de UI, pero no sé hasta qué nivel distará de lo que puedes hacer en las nativas, que estoy viendo que son una caña.

@swapd0 justo he estado viendo tutos esta mañana y me autorespondo, sí se necesita UIkit, para todo lo que no se haya implementado en SwiftUI, por ejemplo un visor de mapas. Pero es tan sencillo como importar UIkit y meter una vista de este dentro de una de SwiftUI.

En cuanto a manejo de propiedades del layout, bindings e intercambio de datos entre los componentes(aquí son vistas), tiene varios property wrappers, se hace todo por anotaciones dependiendo de lo que pases, y el mecanismo es sencillo como el de un botijo, al menos mucho más fácil o al mismo nivel que en Android. La mayoría de cambios entre vistas los manejas por programación reactiva, observables y listo, también todo mucho más sencillo que por ejemplo lo que venía de ver en Angular.

Imagino que UIkit Swift/SwiftUI ha simplificado todo mucho, de hecho hacer un layout parece cosa de niños si lo comparamos con Jetpack Compose o Flutter, en 5 minutos tienes cosas pintadas que en Android me pegaría como 10 veces más, incluso con layouts en xml que más o menos domino.

Llevo solo unas horas y he de decir que venía con muchos prejuicios, pero el hecho de que todo viene a medida para el famoso "ecosistema" y que no tienes que manejar tooda la fragmentación de dispositivos que sí maneja Android o a nivel web, hace muchas cosas terriblememte sencillas.

[Drumpi]

Con Xamarin.Forms haces formularios usando herramientas de Xamarin.Forms. Estas son las típicas que encuentras en todas partes, e intenta mantener la estética de Android e iOS, poniendo las pestañas arriba o abajo, y mostrando el texto o el icono, según el sistema, por poner un ejemplo.
Ahora bien ¿No te gusta cómo se ve algo? ¿Te falta funcionalidad? ¿no puedes crear una vista con lo que te hace falta? ¿O quieres acceder a cosas más internas del sistema? Pues puedes crear un "custom renderer", para lo cual tienes que crear código "nativo" (no sé hasta qué punto es nativo, porque me sigue pareciendo C# lo que escribes) tanto en el proyecto Android como en el de iOS, dentro de la solución, y ahí puedes acceder a librerías específicas de cada sistema... pero yo no he llegado a profundizar tanto.

De todas formas, parece que M$ ha decidido poner fin a Xamarin, y ha empezado con una cosa llamada Maui, que por lo que me han contado es el mismo perro pero con otro collar... o más bien, que han reescrito Xamarin desde cero, para hacer limpieza y arreglar cosas que no se pueden con un simple parche.
Después de 5 versiones (y de tener a sus usuarios actualizando constantemente y arreglando problemas de compatibilidad) durante ¿7 años? Pues como que la gente estaba ya quemada. Es que parecían SplinterGU en sus buenos tiempos

[selecter25]

Con Xamarin.Forms haces formularios usando herramientas de Xamarin.Forms. Estas son las típicas que encuentras en todas partes, e intenta mantener la estética de Android e iOS, poniendo las pestañas arriba o abajo, y mostrando el texto o el icono, según el sistema, por poner un ejemplo.
Ahora bien ¿No te gusta cómo se ve algo? ¿Te falta funcionalidad? ¿no puedes crear una vista con lo que te hace falta? ¿O quieres acceder a cosas más internas del sistema? Pues puedes crear un "custom renderer", para lo cual tienes que crear código "nativo" (no sé hasta qué punto es nativo, porque me sigue pareciendo C# lo que escribes) tanto en el proyecto Android como en el de iOS, dentro de la solución, y ahí puedes acceder a librerías específicas de cada sistema... pero yo no he llegado a profundizar tanto.

De todas formas, parece que M$ ha decidido poner fin a Xamarin, y ha empezado con una cosa llamada Maui, que por lo que me han contado es el mismo perro pero con otro collar... o más bien, que han reescrito Xamarin desde cero, para hacer limpieza y arreglar cosas que no se pueden con un simple parche.
Después de 5 versiones (y de tener a sus usuarios actualizando constantemente y arreglando problemas de compatibilidad) durante ¿7 años? Pues como que la gente estaba ya quemada. Es que parecían SplinterGU en sus buenos tiempos

Ajaja, buena referencia. Yo últimamente solo he escuchado que MS lo estaba haciendo muy bien con .NET, según me dice gente que está currando en ese stack, ese vuelco a open-source y multiplataforma le ha sentado muy bien.

Yo sigo con mi andadura en iOS. Este finde me monté una VM de Monterey (Ventura me dio muchos problemas) y me metí de lleno a trastear, tras revisar algunos tutoriales y partes de cursos. Del SO ya sacaremos conclusiones en una máquina real, no comentaré mucho.

El IDE (XCode) no está mal, en cuanto a rendimiento sin quejas objetivas por ir en una VM (lento), pero es bastante parco y realmente palidece ante otros como Visual Code Studio, que es una navaja suiza. Pese a esta simpleza, se me ha bugeado varias veces, en la última literalmente perdí el Inspector de Atributos por la cara . Cuando te da por pensar que es algo puntual, buscas por la red y hay 3000 casos. Lo curioso es que tal cual se fue, volvió, y así con todo.

El lenguaje (Swift) y el framework (SwiftUI) bastante bien, como cualquier lenguaje orientado a objetos relativamente moderno. Está orientado a una arquitectura MVVM, como ya venía haciendo en Kotlin, pero es bastante distinto en muchas cosas.

Estos días me he limitado a probar cosas, sin arquitecturas (he metido una pequeña capa de servicios que hace de controlador para consumir la API Rest), y he intentado replicar funcionalidad del proyecto Angular, el cual tiene una segunda parte de funcionalidades que solo hará el compi que se queda haciendo React, yo ya no voy a implementarlo, definitivamente nos pasan a iOS y ando 100% centrado en ello.

No voy del todo mal encaminado, tengo el login funcional y ya estoy usando el token para traerme las comunidades y pintarlas en otra vista. Tengo ya todo enfocado a manejar los vecinos, seguramente empiece mañana. Al no estar usando MVVM estoy pasando datos entre vistas a lo burro, sin usar más Property Wrappers que el @State y algún que otro @Binding. Probé a adaptar lo que ya tenía y a utilizar @Environment/@Published junto con @ObservedObject para no tener que pasar el mismo dato 40 veces entre las vistas, pero se me fue todo a la verga. Ya tendré tiempo de estudiarlo bien y de rehacerlo todo, me motiva más trastear a modo de Playground hasta que me llegue el equipo.

Hoy me ha llegado desde IT la confirmación del request, oficialmente han solicitado el equipo (uno para mí y otro para mi compañera) y ya hay un empleado asignado trabajando en ello, así que habemus Mac, solo queda ver si me envían un MacBook o un Mini.

Mientras estaba escribiendo esto me han confirmado: MacBook al canto. Ahora queda ver si es reciente o del año de la tos.

Seguiremos informando!

[selecter25]

Actualizo esto que seguimos en la brecha.

Finalmente me llegó el Macbook Pro hace como 1 semana, no es un M2 pero bueno, un i7 del 2019, para tirar me sirve.

A base de practicar he acabado dominando el uso de los Property Wrappers y con ello empecé de nuevo la app con un patrón de diseño MVVM, algo que ha sido diferencial. Creo que me he adaptado bien, me gusta el nativo y le estoy sacando mucho partido, aunque me dio algo de penilla abandonar web una vez me había hecho con Angular/React, incluso porté a React Native el proyecto. En iOS, he integrado todas las funcionalidades de la primera tanda y ahora ando con las de la segunda, todo con una navegación limpia y muy decente a nivel visual, vistas opcionales y virguerías varias.

A falta de que me integren algunos endpoints en el backend para cumplir con los requisitos funcionales que me piden, lo tengo hecho. El próximo reto es portar mi TFG de Android a iOS. Los instructores de mobile me dejan a mis anchas, me atienden dudas o movidas del backend sin problemas, pero a nivel formación han visto lo que voy consiguiendo por mi cuenta y están contentos, de hecho tampoco pueden asignarme a nadie del center, porque no tienen devs de iOS (sí, 1800 empleados), de hecho en el proyecto que supuestamente me voy a quedar, no tienen a nadie al mando para ello.

Para más inri, mi compañera entró en pánico con Swift/SwiftUI (viene de web y lo ve muy complejo) y me he quedado solo, la han pasado a un proyectito de Vue que necesita un empujón, y el mismo día ha solicitado devolver el Mac . Ya no sé si soy valiente o idiota . Por un lado bien, veo que en la actualidad es un sector con oferta moderada, pero con muy pocos devs, por lo que están bastante bien cotizados.

También me cuadra más la metodología de trabajo, normalmente la parte mobile la lleva un tipo o dos, no es como web que te meten a picar componentes con 10 tipos más.

Queda un mes, seguiremos informando!

[Drumpi]

Ser el único de la empresa que sabe algo es un arma de doble filo: por un lado, te vuelves un valor muy importante para la empresa, porque les abres el campo de negocio, y pueden usar tu experiencia para formar a otros.
Por otro lado, tu permanencia en la empresa depende de que la rama en la que trabajas tenga siempre cosas por hacer, si no, tienes muchas papeletas para irte, o ser el primero en el que piensen a la hora de recortar.

Yo espero que seas de lo primero A mi me pasó lo segundo: una empresa orientada al testeo, que tenía un pequeño grupo de desarrollo de aplicaciones. Los desarrollos daban mucho dinero en largos periodos de tiempo, el testeo cantidades más modestas pero muchas veces en poco tiempo. Cuando hubo que recortar, el primero en caer el desarrollador, más tarde los que hacían mantenimiento de lo desarrollado.

Pero bueno, usuarios de iOS hay muchos (no tanto como Android, pero bueno), pagan bien y son muy fieles. Nosotros hemos dejado los desarrollos iOS... de momento, tenemos un cliente debatiéndose entre comprar terminales Android a todos sus trabajadores, o pagarnos a nosotros por portar una APP a iOS.

[selecter25]

Ser el único de la empresa que sabe algo es un arma de doble filo: por un lado, te vuelves un valor muy importante para la empresa, porque les abres el campo de negocio, y pueden usar tu experiencia para formar a otros.
Por otro lado, tu permanencia en la empresa depende de que la rama en la que trabajas tenga siempre cosas por hacer, si no, tienes muchas papeletas para irte, o ser el primero en el que piensen a la hora de recortar.

Yo espero que seas de lo primero A mi me pasó lo segundo: una empresa orientada al testeo, que tenía un pequeño grupo de desarrollo de aplicaciones. Los desarrollos daban mucho dinero en largos periodos de tiempo, el testeo cantidades más modestas pero muchas veces en poco tiempo. Cuando hubo que recortar, el primero en caer el desarrollador, más tarde los que hacían mantenimiento de lo desarrollado.

Pero bueno, usuarios de iOS hay muchos (no tanto como Android, pero bueno), pagan bien y son muy fieles. Nosotros hemos dejado los desarrollos iOS... de momento, tenemos un cliente debatiéndose entre comprar terminales Android a todos sus trabajadores, o pagarnos a nosotros por portar una APP a iOS.

Imagino que a alguien tendrán, pero no en este center, de hecho si miras por linkedin o Infojobs, en esta cárnica (NT...) están buscando devs de iOS como locos. También me han dicho que hay muchísima demanda y que no la cubren por eso, porque no tienen personal, de ahí que vayan a abrir este nuevo departamento de movilidad.

En un futuro quieren orientarlo todo al desarrollo híbrido, pero de momento dicen que hay muchos clientes con pasta que lo quieren todo bien separadito, con su parte nativa, porque son pijitos, fanboys y/o porque tienen mucha pasta y les da cierto status.

Lo bueno de estas consultoras tan grandes, es que (según el proyecto) las condiciones a nivel trabajo son bastante buenas, 100% remoto con horario flexible, mucho personal y bajas expectativas en juniors, con una carga laboral muy asumible y 0 crunch.

Las pegas? Definitivamente los salarios, y las revisiones. Y es por ello 100% que no tienen devs, las ofertas en iOS que ves en portales o que mandan recruiters parten de 30/35k, y aquí no cobrarías eso ni revisando en 7/8 años, los juniors parten de unos 16.5k y las revisiones de salario (anuales) rondan el 10%. Es por eso que tienen tantísima rotación, la gente aprende y se va, y la gente que se queda lo hace porque antepone comodidad a las aspiraciones económicas.

Pero bueno, aún perdiendo dinero con respecto a mi curro actual, creo que es una buena lanzadera, me tratan bien y hay que hacer currículum como sea. Otra ventaja es esa, que esto es tan grande que si por lo que sea no tienes curro en cierta tecnología, te reciclan y te meten en otro proyecto en cuestión de días.

[swapd0]

Dan ganas de trastear un poco con iOS en vez del OS-X...

[selecter25]

Dan ganas de trastear un poco con iOS en vez del OS-X...

Ya que tienes experiencia, te peleas igualmente con Xcode y dominas Objective-C, yo le daría una oportunidad.

Swift es algo más durillo si empezases de 0 (que no es tu caso, seguro que en unos días lo tienes dominado), pero ofrece muchas más posibilidades y tiene algunos frameworks exclusivos más modernos que facilitan enormemente las cosas, por ejemplo venía haciendo programación reactiva/asíncrona con Combine, y ahora estoy viendo RxSwift y me está flipando.

Si miras ofertas de trabajo, ya se suele pedir Swift/SwiftUI en todas, como mucho alguna experiencia en UIkit, pero creo que hay muy pocas cosas que le falten a SwiftUI con respecto a UIkit.

Luego en mercado Apple no hace más que crecer, y sorprendentemente parece que están tratando de cuidar algo más a los desarrolladores con los "revenue" (bajaron las comisiones en 2021 del 30% al 15%, como en la Play Store). En EU les están obligando a aceptar stores de terceros a partir de iOS 17, además de obligarles también a poder meter apps mediante sideload por ejemplo vía web, o como ahora con cualquier apk que te bajes para Android, por lo que yo creo que es un buen nicho también para ir haciendo proyectillos de freelance.

[bitrider]

Yo estoy ya casi en los exámenes finales de 1º. Aún no sé porqué me he tenido que tragar Empresa y FOL. El profesor de Programación no me ha enseñado nada y pone unos exámenes que ni él es capaz de resolver en las 5 horas que duran... todas las prácticas con 10 y luego no hay narices con el examen, por tiempo.
Sobre todo, no me gusta nada la asignatura de Entornos de desarrollo y mira que el profesor es majísimo. Tengo la sensación que es donde han metido todo lo que les ha sobrado y no sabían donde meter. Bien las pruebas unitarias, pasamos de puntillas por la depuración, optimización y refactorización... Pero estoy harto de diagramas (de flujo, de clases, de casos de uso...) ¿De verdad se utilizan en el día a día trabajando en un grupo y con las metodologías ágiles?
De todas formas como diría alguno por aquí no sé ni para qué sigo si total, la IA va a hacer que no pueda trabajar... es broma seguiré hasta el final XD XD XD XD XD
Por cierto, estoy intrigadísimo por saber cómo te va una vez acabes las prácticas...

[selecter25]

Yo estoy ya casi en los exámenes finales de 1º. Aún no sé porqué me he tenido que tragar Empresa y FOL. El profesor de Programación no me ha enseñado nada y pone unos exámenes que ni él es capaz de resolver en las 5 horas que duran... todas las prácticas con 10 y luego no hay narices con el examen, por tiempo.
Sobre todo, no me gusta nada la asignatura de Entornos de desarrollo y mira que el profesor es majísimo. Tengo la sensación que es donde han metido todo lo que les ha sobrado y no sabían donde meter. Bien las pruebas unitarias, pasamos de puntillas por la depuración, optimización y refactorización... Pero estoy harto de diagramas (de flujo, de clases, de casos de uso...) ¿De verdad se utilizan en el día a día trabajando en un grupo y con las metodologías ágiles?
De todas formas como diría alguno por aquí no sé ni para qué sigo si total, la IA va a hacer que no pueda trabajar... es broma seguiré hasta el final XD XD XD XD XD
Por cierto, estoy intrigadísimo por saber cómo te va una vez acabes las prácticas...

Ánimo que ya tienes mitad del camino hecho!

De acuerdo con FOL y EIE, lo comenté con los compis becarios, podrían eliminarlas y en DAW meter por ejemplo frameworks de JS, y en DAM algo de Big Data o algún lenguaje en auge como Python.

Entornos y Sistemas Informáticos me parecieron rellenazos también, realmente de lo que aprendes te va a ir bien Bases de datos/Acceso a Datos si llegas a ver Spring Boot y las asignaturas de Programación, el resto es paja. Y si haces DAW es peor todavía, como mucho la base de JS, porque hacen php y mierdas obsoletas, si vas a alguna cárnica se mueven 99% por frameworks con TS.

En segundo también me comí Sistemas de Gestión Empresarial que es una basura, básicamente ves ERP y mínimamente algo de Docker.

A mí en las prácticas me hicieron hincapié en dominar Git desde un principio para no liarla en ningún desarrollo, te recomiendo que una vez acabes le metas caña.

A mí me quedan 2 semanas de prácticas, en teoría nos quedamos los 3 compañeros (más otros 4 que estaban haciendo la dual) en el nuevo grupo de movilidad, asignados al proyecto de Zurich, el problema es que al ser nuevo proyecto, está un poco en pañales y no sabemos si arrancará en Junio o Septiembre, por lo que andamos un poco moscas.

A malas, no sé si pegarme unas vacaciones en las que aprovecharía para formarme en iOS hasta Septiembre si no sale directamente, si volver a mi curro temporalmente o si tirar de linkedin y probar suerte en otro sitio, dependerán de lo que me digan en un par de semanas.

[Drumpi]

Pues mira, en el entorno laboral no se usarán los diagramas de ningún tipo, porque tampoco se estila hacer documentación... bueno, sí se suele estilar, pero no dan tiempo para ello.
El caso es que no es un "relleno", es algo que hay que saber, porque aunque no lo hagas para la empresa, conviene hacerlo para ti, para cuando tengas que retomar el código 2 meses después para solucionar un problema, o hacer una ampliación, y ya no te acuerdes porque el proyecto tiene 1000000 líneas de código, y has estado en otros dos distintos entre medias

Para las APPs móviles que hago, también me conviene tener capturas actualizadas de cada página que hago, para refrescar la memoria de cómo funciona cada una, porque después de 5 versiones empiezas a confundirlas.

Luego, el GIT es BÁSICO. Yo todavía me peleo con él, y cuanto más lo simplifican en el Visual Studio, peor (he llegado a perder código porque alguien corrigió un ";" días después de haber cambiado yo toda la clase, y haber hecho el commit a la vez).

Y lo de depuración de errores... a menos que tengas una habilidad para ello, y muy buena memoria, es algo que se debería enseñar desde primero. La de tiempo que llegué a perder con el depurador porque no me enseñaron técnicas para mejorar los tiempos de testeo.

Ya sé que a todos nos gusta picar código, y que se pierde muchísimo tiempo en documentar y demás... pero a la larga es vital tener esos conocimientos, y si no es por la empresa, hacerlo para ti, aunque sea en papel. Mis compañeros han visto lo útiles que son las notas que tengo en mis carpetas, y de vez en cuando tengo que mandarles una foto o tengo que pasarlo al sistema de documentación que tenemos en la nube.

[selecter25]

Pues mira, en el entorno laboral no se usarán los diagramas de ningún tipo, porque tampoco se estila hacer documentación... bueno, sí se suele estilar, pero no dan tiempo para ello.
El caso es que no es un "relleno", es algo que hay que saber, porque aunque no lo hagas para la empresa, conviene hacerlo para ti, para cuando tengas que retomar el código 2 meses después para solucionar un problema, o hacer una ampliación, y ya no te acuerdes porque el proyecto tiene 1000000 líneas de código, y has estado en otros dos distintos entre medias

Para las APPs móviles que hago, también me conviene tener capturas actualizadas de cada página que hago, para refrescar la memoria de cómo funciona cada una, porque después de 5 versiones empiezas a confundirlas.

Luego, el GIT es BÁSICO. Yo todavía me peleo con él, y cuanto más lo simplifican en el Visual Studio, peor (he llegado a perder código porque alguien corrigió un ";" días después de haber cambiado yo toda la clase, y haber hecho el commit a la vez).

Y lo de depuración de errores... a menos que tengas una habilidad para ello, y muy buena memoria, es algo que se debería enseñar desde primero. La de tiempo que llegué a perder con el depurador porque no me enseñaron técnicas para mejorar los tiempos de testeo.

Ya sé que a todos nos gusta picar código, y que se pierde muchísimo tiempo en documentar y demás... pero a la larga es vital tener esos conocimientos, y si no es por la empresa, hacerlo para ti, aunque sea en papel. Mis compañeros han visto lo útiles que son las notas que tengo en mis carpetas, y de vez en cuando tengo que mandarles una foto o tengo que pasarlo al sistema de documentación que tenemos en la nube.

El problema no es precisamente ese tipo de contenido, hay contenido mucho más relleno que ese, hay asignaturas que en una FP técnológica en 2023 son de memorizar, como mi madre hacía con las preposiciones, seguimos con un modelo de educación que se limita a memorizar quién era Von Neumann y en qué año nació, en qué año se pasó de las válvulas de vacío a los transistores o la historia y desarrollo de los sistemas distribuidos, todo en ello en cientos de páginas de teoría, para luego escupirlo en un examen y olvidarte a la semana. Toda esa basura es irrelevante a la hora de picar, y si a alguien le interesa, lo tiene todo a una búsqueda en Google.

En cuanto a documentación, hay herramientas e IA que te documentan todo automáticamente o te explican de cabo a rabo qué hace cada cosa. Eso no quita que cada uno sea responsable y haga lo suyo, yo soy de documentarlo todo, y de guardar hasta vídeos en donde lo comento todo a nivel de unidades funcionales, pero hoy en día son tareas que puedes casi automatizar. En el FP, como solo ves JAVA, me enseñan el tostonazo de Javadoc que no vas a usar nunca, y listo.

Los diagramas, te van a mostrar 5000 diagramas (flujo, UML, clases, casos de uso) con 5000 formalidades que vas a olvidar, y de los cuales vas a usar 2 o 3, que también se autogeneran en la mayoría de IDEs. En curro real (hablando de web), directamente me pasan desde diseño uno muy simple con los componentes, vistas y funcionalidades, y listo.

Testing, como solo ves JAVA, tiras de unitarios muy simples en JUnit y ya, en cuanto caigas en otro lado, te sirve 0, aquí me tocó aprender Selenium y Jenkins.

Y así con todo, todo el temario se siente desfasado, la mayoría de prácticas que haces son antiguas, con herramientas en desuso o deprecadas, hasta el punto en que es imposible hacerlas si no las replicas en todo su "esplendor", usando librerías deprecadas, con fallos de vulnerabilidad notorios, y con el dolor de saber que existen alternativas "modernas", más ágiles o sencillas. Recuerdo algunas prácticas de Acceso a Datos, en las que solo configurar el proyecto Maven y que todas las librerías funcionasen para poder hacer la práctica, llevaba 10 veces más que la práctica en sí.

Para más inri, muchas de estas asignaturas desconocen el contenido del resto, y se solapan, viendo muchas cosas 2 y 3 veces en el mismo curso en distintas asignaturas. Si ya vienes de hacer SMR (el grado medio), te quieres suicidar, puesto que la asignatura Sistemas Informáticos es un resumen (literal) de todo el grado medio, y no convalida. Por suerte FOL y EIE sí, otro tostón de memorizar contratos, riesgos laborales, proceso de búsqueda de trabajo, discriminación de género.... Todo eso con más de 20 años ya cotizados, se te hace un poco bola, al padre le van a enseñar a hacer hijos.

[Drumpi]

Pues a ver, si es para un curso específico o una FP, sí que es cierto que muchas de esas cosas sobran. Pero si es una carrera o un curso genérico, todo eso es lo normal.

Empezando por un primer año/asignatura que es un repaso de lo que se ha visto anteriormente, porque nuestro sistema educativo es tan fragmentado y variado que no todo el mundo se ha visto todo el contenido del Grado Medio (y te aseguro que la mitad de los que entran contigo, se olvidaron de lo que dieron tan pronto terminó el examen). Ese curso/asignatura es necesario para que todos empiecen al mismo nivel.

Luego me dices de las lecciones de historia... Wikipedia la ha tenido que rellenar alguien, para empezar. Y sí, las válvulas de vacío están en desuso y al informático les da igual y... No sé por qué os lo enseñan a vosotros. A mi, todavía, porque aunque usamos transistores de silicio. conviene saber de dónde viene la electrónica actual... y nunca sabes cuándo un IEM nos va a mandar a la Edad Media (y oye, un sistema con válvulas de vacío sobrevive a un holocausto nuclear, no es descabellado hacer armas con ellas ).
Pero bueno, quejarse de las lecciones de Historia es como quejarse de aprender mates en el colegio porque de mayor se va a ser "influencer"

Luego, seguro que hay mucho que dices "pero si yo voy a usar esto, y no esto". Vale, céntrate en eso, pero no descartes el resto de información. Puede que uses un sistema de diagramas concreto, y que esté automatizado (cosa que me gustaría ver, por cierto), pero todo el mundo tiende a compartimentar la información, y yo eso lo veo un error. No han sido pocas las veces que he aplicado conocimientos de un campo a otro que no tenía nada que ver, porque me daban ventajas que no tenía ese sistema de diagramas, o ese lenguaje en concreto, y facilitaba mucho el pensamiento "fuera de la caja".

No digo que el sistema de enseñanza no pueda ser más eficiente, específicamente en cursos concretos, pero muchas de tus quejas me las han dicho muchos compañeros de clase, en todos los niveles (colegio, instituto, universidad, máster, FPO...) y casi siempre gente que sacaba aprobados raspados, que a lo mejor no ven el conjunto (y yo tampoco, que para eso estaba aprendiendo), y es probable que tengas razón, que mucho de lo que veas no lo uses nunca... hasta que lo necesites, o decidas que has tenido suficiente y que quieres cambiar.

No sabes lo bien que me ha venido haber visto XPath cuando en Java trabajaba con documentos Office, o usar VB6, cuando ahora me tengo que enfrentar a HTML y JS, por no hablar de ciertos juegos, que me han servido de base para optimizar la construcción de SQLs (mis compañeros tendían a escribirlas enteras, y a repetirlas según los filtros, subqueries y demás que necesitaban), vistas en Xamarin o el HTML en las Razor Pages.


Ya sobre código obsoleto e inseguro no puedo más que darte la razón. No hay excusa, salvo la flojera de los profesores por mantener el temario al día, o porque al iluminado del sillón no le da la gana de emplear recursos (dinero) en ello. Mientras no caigan las cifras de aprobados/ganancias, les da igual.