Serializando con tag-helpers

[juanvvc]

Puedes dividir el fichero JavaScript en cuántos ficheros creas necesarios para organizarte, y cargarlos todos uno a uno.

Aún así, en un producción, se prefiere tenerlo todo en un solo Java Script por eficiencia: que la web solo realice una descarga del servidor hace ganar unos milisegundos y juntando todos son muchos a finales de año.

¿Cómo se conjuga que los programadores prefieran dividir el Java Script en varios archivos para organizarse, pero la web prefiera un solo archivo por eficiencia? Con empaquetadores: son herramientas que juntan todos tus archivos .js de desarrollo en un solo .js de producción. Los empaquetadores también añaden gestión de namespaces y librerías, cosa que es tremendamente útil.

No te digo que uses empaquetadores, simplemente te los presento para que los conozcas por si quieres seguir aprendiendo.

[Drumpi]

Sí, durante el curso nos presentaron una herramienta que venía con VS... no sé si para juntar ficheros, pero sí para miminizarlos... o no sé cómo es la palabra correcta. Esto te coge el js y le borra los espacios, tabulaciones y saltos de línea y te los compacta, generando un fichero .min.js, supongo que para ahorrar espacio (y digo yo, para ahorrar espacio ¿por qué no se compila en un fichero binario, como BennuGD? ).
Según recuerdo, esa herramienta era semi-automática, y los cambios al fichero .js se reflejaban en su .min.js... pero como vamos con prisas, de momento, vamos a ir haciendo que funcione y luego ya nos preocuparemos de eso.

[juanvvc]

Sí, los empaquetadores hacen eso: juntar todos los .js que tiene tu proyecto en uno solo y minimizarlo. Y sí, lo hacen de forma automática cada vez que detectan un cambio en tus .js. Y sí también, esto es muy parecido a una compilación. De hecho la moda moderna es escribir en TypeScript, que primero se compila a JavaScript y después se empaqueta.

No se te ocurra configurar esto manualmente, eh. Si necesitas usar estas cosas entonces mejor aprendes algún entorno donde lo tenga todo integrado. Normalmente van asociados a alguna librería grande: Vue, Angular ó React. Y no se hace "luego", si quieres usarlo lo mejor es hacerlo desde el principio. Con el proyecto ya empezado va a ser un follón usar empaquetadores. Por eso digo que te informaba, no recomendaba.

[Drumpi]

Bueno, compilación no sé, no me he puesto a leerme un .min.js (ni ganas), pero sigue en texto plano y se puede leer, por lo que necesita un proceso previo de interpretación de comandos de varios caracteres y tamaño indeterminado... Lo siento, soy un carca, anclado en la época en que la eficiencia lo es todo, y ver código interpretado me parece un consumo innecesario de recursos

Respecto a lo otro, creo que me he explicado mal: cuando dije que lo iba a hacer "luego" me refería a una versión posterior, no después de compilar La idea sería, más adelante, configurar VS para que minimice los ficheros, volver a compilar (para que se generen los ficheros minimizados) y volver a desplegar.
Ya digo que eso de Vue, Angular o React no lo usamos, todas las automatizaciones dependen de VS y ASP.Net Core, de momento.

[juanvvc]

Chrome (más bien, su ejecutor de JavaScript V8) hasta hace poco siempre compilaba el JS a código máquina antes de ejecutarlo. No tenía forma de interpretar JS sin compilarlo antes: https://stackoverflow.com/questions/...pilation-in-v8 Es normal en los lenguajes interpretados: se convierten a un bytecode que a su vez se convierte a código máquina. Suele ser transparente para el programador que ni se entera de que esto se hace en el background.

Y sí, te entendí. Te he dicho que meter un empaquetador en un proyecto ya empezado es un follón. O lo haces desde el principio o apechugas con lo que tienes. No digo que sea imposible, pero no le veo el beneficio comparado con el esfuerzo.

[josepzin]

Capas sobre capas sobre capas. Yo prefiero tenerlo todo mas simple y directo.

Enviado desde mi M2101K7AG mediante Tapatalk

[Drumpi]

Capas sobre capas sobre capas. Yo prefiero tenerlo todo mas simple y directo.

Enviado desde mi M2101K7AG mediante Tapatalk

Te daría un abrazo pero no encuentro el emoticono

[josepzin]

Somos dinosaurios en extinción :P

-----Actualizado-----

En su momento me resistí a usas SAS porque eso de tener un intérprete de CSS ya no me gustó nada.
Lo de minificar, a menos que sea una librería externa que ya viene así tampoco lo uso, total mis scripts no son kilométricos.
Ademas si el servidor ya se encarga de servir contenidos comprimidos, pues ya está. Y además con el cacheo que hacen los navegadores o servicios como CloudFlare, entonces menos que menos me voy a estar liando yo con cosas intermedias.

Pero bueno, ahora se usa Wordpress mastodónico con cienes de plugins que cargan cienes de archivos y cienes de librerías con cienes de efectos, asi que lo mio es porque estoy viejo!

[masteries]

Capas sobre capas sobre capas. Yo prefiero tenerlo todo mas simple y directo.

Hay ocasiones y escenarios donde no te queda otra,

Me he encontrado aquellos que para ejecutar un algoritmo de control en Tiempo-Real, que lee sensores a través de interfaces
físicas (como bus CAN o UART) y dar órdenes a actuadores en forma de motores sin escobilla; todo con un tiempo de respuesta
máximo de 10 ms o incluso de 5 ms ...

quieren utilizar un sistema operativo tipo Linux, y sobre ese Linux, una máquina virtual, y en esa máquina virtual
ejecutar el algoritmo, leer los sensores, dar la orden al actuador y hacer una comprobación al actuador para saber
si le llegó la última orden, y querer hacerlo dentro de ese plazo... y si es posible que el computador consuma menos de 2 Wattios...

Cuando les comentas que tienen que usar interrupciones, transacciones DMA para recibir / enviar los datos, pues ahorrarán mucho tiempo de cómputo...
se te quedan mirando y te dicen... es que soy informático... no sé de qué estás hablando, quieren hacer cualquier cosa con algo que se asemeje a
un PC... bueno, un PC no, un teléfono móvil... sólo me faltaría que quisieran ejecutar código interpretado xD

[Drumpi]

Hay ocasiones y escenarios donde no te queda otra,

Me he encontrado aquellos que para ejecutar un algoritmo de control en Tiempo-Real, que lee sensores a través de interfaces
físicas (como bus CAN o UART) y dar órdenes a actuadores en forma de motores sin escobilla; todo con un tiempo de respuesta
máximo de 10 ms o incluso de 5 ms ...

quieren utilizar un sistema operativo tipo Linux, y sobre ese Linux, una máquina virtual, y en esa máquina virtual
ejecutar el algoritmo, leer los sensores, dar la orden al actuador y hacer una comprobación al actuador para saber
si le llegó la última orden, y querer hacerlo dentro de ese plazo... y si es posible que el computador consuma menos de 2 Wattios...

Cuando les comentas que tienen que usar interrupciones, transacciones DMA para recibir / enviar los datos, pues ahorrarán mucho tiempo de cómputo...
se te quedan mirando y te dicen... es que soy informático... no sé de qué estás hablando, quieren hacer cualquier cosa con algo que se asemeje a
un PC... bueno, un PC no, un teléfono móvil... sólo me faltaría que quisieran ejecutar código interpretado xD

Primero: no.
En serio, yo no sé cómo puedes encontrar a gente, que incluso estando en tercero de la carrera de informática, que se las da de saber más que tú, un "simple teleco", y que no sepa ni cambiar una tarjeta gráfica... A ver, entiendo la típica madre que dice que su hijo es informático porque hizo un curso de Office ¿pero esta otra fauna? No.
Y lo dice un "simple telequito" que de informática sólo saber hacer intrusismo laboral

Segundo: hoy día hay herramientas (HW y SW) para controlar HW externo con cualquier SO. Implementar un SO virtual sobre un Linux... Juer, si te vale una Raspberry Pi Zero, y tiene 20 veces la potencia de cálculo de los aviones comerciales de hace 35 años (Cifra obtenida con un ábaco inca del sigo XIV AC).
No sé, yo he controlado un motor con Matlab, he efectuado medidas en remoto con un osciloscopio mediante ¿protocolo I2C? , e incluso he creado programas que reaccionan de forma diferente según medidas obtenidas por otros aparatos del laboratorio usando LabView. Muy crítico tiene que ser el sistema si estás usando un PC con Linux, interrupciones y DMA, cuando usando un DSP por cuatro perras, conectado por USB a cualquier sistema, tienes de sobra (según mi profe de Circuitos Integrados hace 15 años).

Y volviendo al tema, entiendo el uso de HTML, aun siendo interpretado. Entiendo la necesidad de JS para interactuar y modificar el mismo desde el ordenador cliente. Puedo incluso llegar a comprender la necesidad de muchos de usar librerías sobre JS, porque no se atreven a aprender algo nuevo y quieren ir sobre seguro, en algo que está demostrado que funciona, y que no merece la pena el esfuerzo para cambiarlo.
Pero si encima de todo eso pones otra capa y luego otra capa más, es que hay un problema que debería arreglarse desde la misma base. Cuando empiezo a oír que si tal o cual para no escribir más JS, o para simplificar al otro, me suenan a las mismas excusas que ponía (y sigo poniendo, la verdad) para no tener que aprender una funcionalidad nueva de un lenguaje o pasarme a otro más potente. ¿No se suponía que HTML5 iba a cargarse todo esto? ¿Qué ha pasado?

PD: hoy he tenido reunión con mi "tutor" en el trabajo, y me ha dicho que tengo que replantear todo el sistema de navegación de mis apps de Xamarin ^^U Lo dicho, lo que tengo hecho funciona, y lo veo innecesario, y él me ha dicho que eso era hace ya muchos años, y que ahora hay sistemas que te ahorran ese trabajo, así que me toca pasar por reciclaje.

[juanvvc]

él me ha dicho que eso era hace ya muchos años, y que ahora hay sistemas que te ahorran ese trabajo, así que me toca pasar por reciclaje.

Pues eso. Llevas semanas para hacer una tabla editable, cuando es algo solucionado hace años y que las librerías actuales te lo dan de gratis.

¿Que pierdes un poco el control? Bueno, pero haces en horas lo que llevas semanas tratando de hacer y seguramente también mucho mejor y con menos errores. ¡Toca reciclarse!

[masteries]

En serio, yo no sé cómo puedes encontrar a gente

Segundo: hoy día hay herramientas (HW y SW) para controlar HW externo con cualquier SO. Implementar un SO virtual sobre un Linux...

Editado: Pedazo de offtopic largo que me ha salido...

Están por todas partes Drumpi; incluso los contratan y cuando llegan al puesto de trabajo WTF? ¿Pero esto qué es? Sino cuadra con mi perfil...
Hace tiempo que he detectado un problema gordo de entendimiento por parte de RR.HH. , en empresas bastante grandecitas,
para hacer el matching entre lo que les han pedido desde dptos. de la empresa, y los candidat@s que van localizando


Lo segundo no les está funcionando, es para implementar el sistema de control vital de una nave espacial en la que
van tripulantes dentro (presión, mezcla de gases, control de humedad, captación del CO2, filtrado del mismo, temperatura...);
si funciona mal se mueren, así de simple.

El sistema de control no debiera ser complejo en lo que a capas software se refiere, y por supuesto,
montarlo por triplicado (para hacer un sistema votador) y a su vez duplicar ese sistema.


La opción a la que están recurriendo (como medida de emergencia), es la de reemplazar el sistema comercial, carete, endurecido frente a radiación y tal que ya tenían;
y todo lo relacionado con entrada/salida por diseños custom que están haciendo en la empresa, en VHDL para que los datos
vayan directamente a regiones de memoria, de las asignadas por linux a la máquina virtual; una amalgama que ya cuesta hasta entenderla...
La interrupciones y los DMA de, no es un PC, porque emplea un MIPS; no las están usando porque no saben.


En fin una mezcla de churras y meninas; tuvimos una reunión con ellos y nos explicaron el invento;
el concepto de un móvil para todo eso... yo y los asistentes del dpto. de electrónica estábamos flipando,


Expusimos que cada concepto de computador tiene su escenario de aplicación,
y que el hecho de que les resultase difícil hacer un acceso de entrada/salida
ya les estaba poniendo sobre la mesa que el camino no es muy acertado,
para el uso que necesitan,

Para otros usos, puede ser una maravilla, ahí ya no íbamos a entrar;
pero para añadir el control de estas cosas mejor que no,


Así que están ignorando las especificaciones del contrato con la ESA,
en las que les pedían que este viaje, hardware custom no querían;
y es justo a lo que están recurriendo, a meter más custom que antes... en fin

Desconozco como querrán justificarlo, pero los revisores se lo van a echar para atrás
y les van a pedir la devolución íntegra del presupuesto recibido; desde 2023 es así,
si no permaneces estricto en los límites que te han impuesto, tanto en especificaciones
como en plazo de tiempo para desarrollar, devolución en la revisión.


Y cómo bien indicabas Drumpi, todo esto con unos micros o DSP, sería mucho más sencillo
, que existen ya endurecidos contra radiación por 300€ la unidad; que no son nada caros
(y son ARM-Cortex M4 con coma flotante a 180 MHz, con su plétora de interfaces:
CAN, I2C, UART y SpaceWire, éste último puedes entenderlo como un CAN más rapido);
El sistema triplicado y a su vez todo duplicado, en DSPs te sale por 1800€, ahora pon
los transceivers también Rad-Hard... vamos todo por 3500€ o 4000€ si nos vamos lejos,
y empiezas a montar tu sistema de control vital con todo eso tan robusto (esos micros llevan
ECC en la RAM y en la ROM, por si cambia de forma súbita hasta 2 bits por cada 32, se corrigen solitos
y son micros de 300€, y aguantan una dosis de radiación que nos dejarían a todos tiesos unas cuántas veces...)

el MIPS que están usando, sólo el micro son 425.000€ , lo han desechado y la
FPGA custom que están usando ronda el millón;





Creo que me ha faltado comentar que los buenos que tenían haciendo
y dirigiendo (si, el director, que también participaba en lo técnico
diseñando las arquitecturas y por cierto, que es muy simpatico y accesible,
ya no está y ha entrado alguien que sólo desea dirigir y de lo técnico o arquitecturas ni idea)

todos estos se han marchado a la empresa del al lado, todos
sabemos por qué; y los han reemplazado con personal de batalla y sin
experiencia en el campo donde los han puesto a trabajar; excepto los
expertos en VHDL que ya tienen, éstos últimos están flipando también

Y no es un caso aislado,


Y hasta aquí el offtopic,

[Drumpi]

Pues eso. Llevas semanas para hacer una tabla editable, cuando es algo solucionado hace años y que las librerías actuales te lo dan de gratis.

¿Que pierdes un poco el control? Bueno, pero haces en horas lo que llevas semanas tratando de hacer y seguramente también mucho mejor y con menos errores. ¡Toca reciclarse!

A ver, creo que lo de la tabla editable hace ya bastante que está resuelto
Lo cierto es que el nivel de interactividad que he conseguido en esta página era impensable hace un mes Creo que ya voy entendiendo un poco el uso de JS y JQuery, sólo necesito más ejercicios guiados para terminar de aprender sintaxis y funciones básicas, para poder escribir mi propio código.

Pero una cosa es aprender algo que no se sabe, y para lo que hay que ir desde lo más básico (léase HTML+JS+whatever), y otra cosa es reciclarse con algo que ya más o menos dominas, que es ir un paso más allá.
Yo siempre he tenido tendencia a acomodarme en lo que sé: mantenerme en una versión del lenguaje, usar las mismas funciones, de vez en cuando voy inventando cosas o leo alguna cosilla nueva... pero no me pongo a leer y experimentar con las cosas del changelog de los desarrolladores, y bueno, con el tiempo, me pasa factura, pero en los proyectos del trabajo hay que trabajar así, sobre todo porque cambiar de versión las librerías de un proyecto causan (siempre) dolores muy gordos de cabeza

[Drumpi]

Están por todas partes Drumpi; incluso los contratan y cuando llegan al puesto de trabajo WTF? ¿Pero esto qué es? Sino cuadra con mi perfil...
Hace tiempo que he detectado un problema gordo de entendimiento por parte de RR.HH. , en empresas bastante grandecitas,
para hacer el matching entre lo que les han pedido desde dptos. de la empresa, y los candidat@s que van localizando

Aquí voy a romper también una lanza en favor de los curritos nuevos, porque es lo que dices: la mitad de las veces, los de RRHH no saben lo que les están pidiendo desde los departamentos técnicos. Pero es que claro, los de RRHH entienden de personas, no de ingeniería, y su labor es conseguir construir un grupo de gente competente, que trabaje junta (o que al menos, no terminen matándose entre ellos), o como mínimo, sea gente que trabaje.
Pero es que es eso, hay informáticos que no saben montar un PC, y luego hay quien miente descaradamente sobre lo que sabe hacer y lo que no.

...y a veces, es la propia empresa, que pone un trabalenguas de siglas y nombres en los requisitos mínimos, que ni su programador senior más experimentado tiene esos conocimientos

Lo segundo no les está funcionando, es para implementar el sistema de control vital de una nave espacial...

Ya está, ya lo has dicho todo.
Con eso hasta Linux sobra. A no ser que metan un kernel y generen un SO a medida para uso en tiempo real (o algún SO de tiempo real, que los hay). Pero no, para eso un DSP, y cuanto menos código mejor... aunque con los sistemas de hoy día, con una Wiz forrada de plomo ya tienen más potencia de cálculo que en todo el conjunto del Apolo 11

Aún recuerdo el esquema que nos ponía nuestro profesor: primero un recuadro grande, representando el problema hace 30 años, y dentro, un montón de piezas de "tetris" que representaban distintos CI específicos. Al lado, el esquema actual, que consistía en un cuadrado grande, y otro más pequeño dentro, en una esquina: el cuadrado grande era un CI estándar (por ejemplo, un DSP), y el pequeño era el problema a resolver

De hecho, en mi carrera, a los dos años de irme, dejaron de enseñar ASM, porque en la única asignatura que se enseñaba, que usábamos el 68K, lo sustituyeron por otro micro que ya se programaba en C. ASM son para los nostálgicos y los masoquistas, decían, porque la potencia de cómputo actual hace innecesario tener que ir a tan bajo nivel.
No voy a discutirlo, porque no he tenido que comprobarlo, pero temo el día que llegue el IEM que nos mande a todos a la Edad Media, y no haya nadie capaz de desarrollar tecnologías primitivas para poder recuperar las más actuales

[juanvvc]

El desarrollo web moderno está tan alejado de html+js+css que creo que ya no es eficiente empezar así.. Sería (exegerando, pero tampoco mucho) como empezar a estudiar programación de PC enseñando ensamblador. No és una forma eficiente de llegar a algo productivo y moderno.

Los navegadores siguen interpretando solo html+js+css, pero las webs no se programa así. Todo el desarrollo actual se hace en otros lenguajes "de alto nivel" y sistemas que después se compilan/empaquetan a html+js+css "de bajo nivel". Por ejemplo, poca gente escribe ya nada de HTML puro (son todo componentes) y TypeScript se está haciendo dueño y señor del mundillo, creo yo. Incluso si usas JavaScript, lo harás a través de un framework. Vamos, que prácticamente solo escribes "addons" para alguna librería grande.

Ahora que ya tienes el ritmo, cualquier fin de semana pilla un tutorial de Vue/React para hacer algo simple y verás lo diferente que es.