Mensajes

El tiempo es oro. No pidas que revisen todo tu código para buscar fallos. Aparte que hay diferentes tipos de fallos, comenzando por el enfoque del problema...

Es infinitamente mejor (si quieres recibir ayuda), señalar que te falla. Así quien quiera ayudar se centra en la parte del código específica... para indicarte porqué falla.

Dejando aparte si el vaticinio es o no factible, como mínimo para darlo visos de certidumbre, faltaría restringirlo añadiendo al título: "en las grandes empresas".
"Los 5 trabajadores digitales con más demanda para el 2019 en las grandes empresas".

Medianas y pequeñas empresas, no van a  demandar prácticamente ninguno de ese tipo de trabajadores... lo que llaman "arquitecto cloud", quizás sea lo que quede más cerca de la necesidad en las empresas medianas.

Esto se soluciona poniéndole una multa y gorda...

Queda  fuera de toda duda que la única razón obedece a engañar al usuario, aunque al final el engaño sea autoengaño por falta de conocimiento del usuario.
Sin embargo es engaño, por cuanto ellos preparan la trampa y ponen el cebo, que el usuario luego acabe cayendo, es lo de menos... Todas las trampas son así.

[adiós]

Esto no dice "adiós", solo lo pone más difícil en determinados casos, pués ni siquiera será obligatorio.

Además, es un problema, porque en su momento se les dijo "hola"... a que el mismo cable (más precisamente conector) de carga lo sea también para datos.
¿El mismo cable...? Bien...
¿El mismo conector?. Vale...
Pero ¿por qué no diferenciarlo? por ejemplo, posicionándolos al revés... si lo conectaras en una posición solo carga y lo posicionas de la otra, solo comunica datos. Con un diseño de un cable simétrico bilateral, hubiera sido suficiente (como lo es ahora el USB-C, pero con una mejor diferenciación y dedicación del patillaje)...

Hummm... siempre dando datos que con matemáticas es fácil demostrar que son falsas, ya vengan de donde digan que vengan tales cifras...

No me creo de entrada que el 1'1% de las muertes sean suicidios... pero es que yendo más lejos, tampoco me creo que haya 360.000-370.000 muertes al año en Europa...

Veamos; Supongamos con cifras redondas que los suicidios son el 1%, como dan la cifra de 3.650 (como punto intermedio), como eso es solo un 1%, si lo multiplicamos por 100, llegamos a 365.000 muertes en Europa en un año (100%)...

Bien, veamos cuantos moriría en 100 años, es decir 100 veces más: 36.500.000
Que es lo mismo que decir, que o bien la población total de Europa es inferior a 36'5 millones de personas o que las personas vivirán unos 2000 años, porque Europa tiene una población de unos 740 millones de personas. 20 veces más que los que supuestamente morirían en 100 años.

Así que el artículo por algún lado cojea con un error, y no voy a perder el tiempo en averiguar dónde... y por lo mismo ni en molestarme en leer el artículo.

[Microsoft .NET Framework NGEN]

Evidentemente aunque hayas leído algo de información al respecto, estás lejos de haber entendido el proceso.

- De entrada, no todos los ejecutables están en formato PE, se puede compilar a código nativo.

- Cuando compilas un programa, si el compilador detecta que se importa una librería pero que luego nunca se llama (queda desierta), en general (suele ser opcional), descartará esas referencias y por tanto en el ensamblado final no hay noción a ellas. Es decir no tiene que resolver direcciones de funciones que ni siquiera serán invocadas, porque aún declaradas, no aparecen llamadas para usarlas en el código.

- Cuando se compila un programa, las direcciones de variables, funciones etc... son relativas, es decir el programa comienza la dirección 0 para la primera instrucción del programa (a grosso modo), luego cuando el loader (cargador), actúa localiza  memoria libre en el equipo, supongamos que es: 0010346AB1, pués el loader tiene como misión hacer las direcciones locales absolutas añadiendo ese valor a todas las direcciones relativas en el programa. Y esto se hace sí o sí siempre excepto que el programa sea un '.com', lo hace el S.O. Además es algo muy rápido... a no ser que tengas un ejecutable de 500Mb.

- Si bien el cargador se encarga de las direcciones relativas, fue el linker, el que se encargó de las direcciones de las librerías externas, y es ahora el loader, quien de nuevo tiene que resolver esas direcciones relativas a absolutas... y en el caso de que una librería no esté cargada ya en memoria debe cargarla, para así poder tomar su dirección. Aún así, los objetos se cargan a medida que se usan, es decir en tiempo de ejcución todavía queda por resolver algunas direcciones, pués para ciertos objetos ni siquiera se conoce su naturaleza. Estos enlaces selen llamarse 'Late binding', y para ellos si hay impacto en tiempo (en relación comparativa a 'early binding'), pero sigue siendo inapreciable a efectos humanos...

- La cpu, no tiene que "resolver" todas las funciones, a no ser que con 'resolver' quieras decir formalizar sus direcciones, que entonces sí es así, pero si con 'resolver' te refieres a ejecutar, no.
Solo se invoca y ejecuta el código que está en ese preciso instante en la CPU (el programa yace en memoria), en realidad una única instrucción a la vez (salvo paralelismo)... Es decir en un instante dado, la CPU sólo atiende a un único proceso (dejamos aparte los cores que tenga), da igual que tu programa tenga 20 funciones o solo 2, que llame a chorrocientas funciones externas o a ninguna, solo 1 proceso se está ejecutando en la CPU a la vez, pero no todo es tan así... hay algo llamado pipeline (cascada), que no es más ni menos que una especie de túnel de ejecución de modo que cuando una instrucción se está ejecutando, otra se está preparando, etc... similar a un ssistema de montaje en serie de coches, por ejemplo... Así, la cascada tiene varios niveles, además hay sistemas de predicción (para eso sirve la caché de la CPU), cuando se equivoca o se cambia de proceso, se tiene que limpiar toda la cascada... (algo así como si en el sistema d emontaje de coches deciden cambiar el modelo del vehículo, o incluso algo tan nimio como la pintura) y guardar en la pila el estado actual de la CPU para ese proceso, hasta su próximo turno.... esto siempre supone un pequeño retraso.

- Si un programa tiene (pongamos) 300 referencias de direcciones de librerías que resolver,  el impacto de carga es nulo (no observable a nivel humano), un pestañeo y ya...

Donde si se observa un notable impacto, es en dos casos muy concretos y claros:
--- Cuando se procede con código interpretado. El código interpretado puede ser entre 10 y 100 veces más lento, depende del intérprete.
--- Cuando previo a la ejecución hay una compilación (una traducción del bytecode (código intermedio igual que PE, pero por ejemplo en NET es CIL)). En NET, el caso es más severo (que en COM), ya que el código al compilar (desde el IDE) lo hace en código CIL, y es en tiempo de ejecución cuando CLR lo compila a código nativo, optimizado para el procesador que calza el equipo... Es un pequeño sobrecoste de carga a cambio de una mayor optimización personalizada para la CPU presente en el equipo en cuestión (durante toda la ejecución del programa), luego... quién tiene motivos de queja por ello... con todo, puede forzarse para programas que asíduamente se usan en un equipo dado, se compilen a código nativo... de hecho hay un servicio en el equipo que se encarga de ello: Microsoft .NET Framework NGEN. Este caso también se da con los programas en JAVA

Los compiladores modernos siguen el esquema UNCOL de Tanenbaum, que aunque jamás llegó a término, si mostró el camino a seguir. Actualmente una especificación similar es el CLI (Common Language Infrastructure) de Mocosoft.
Desde diferentes lenguajes, se compila a un código intermedio (CIL para NET), y luego desde código intermedio al código nativo en la máquina destino, así basta un único ejecutable para diferentes máquinas. Y a su vez puede haber un ecosistema de lenguajes aprovechandose de las mismas características del compilador, por ejemplo en NET tienes Visual Basic, C#, F#, Q#,  el suspendido J#, incluso uno mismo podría escribir su propio lenguaje y compilador.


Por último, señalarte que no tiene nada que ver el tiempo de carga de un programa con el rendimiento durante la ejecución del programa o de una determinada funcionalidad del mismo o llamada externa.

[pero me temo que]

Es indiscutible que resulta útil poder controlar los aparatos sin la necesidad de tener que tocarlos. se evitarían desde las simples manchas, hasta roturas, etc... la cuestión es siempre más d elo mismo, la seguridad.

Si por ejemplo se puede manejar hasta una distancia de 40-50 cm. para un móvil podría resultar útil, pero más útil aún si puede activarse y desactivarse a voluntad...
Basta imaginarse dentro del metro, una mañana mientras vas al trabajo, abrrotado de gente, no creo que a nadie le hiciera mucha gracia que alguien por el mero hecho de estar pegado a ti, pudiera tener acceso a tu tf. Que de entrada no somos mla pensados, pero como siempre es cuestión de tiempo que los delincuentes tomen en cuenta la posibilidad de tener acceso a dispositivos móviles de esa manera, y lo mismo que los carteristas pululan por el metro, con la finalidad de robar carteras, bolsos, etc... estos serían una nueva oleada de 'carteristas tecnológicos'.

Si se pudiera activar y desactivar a voluntad, o incluso graduar la distancia máxima de alcance, cuando entras al metro, lo desactvas, y lo usas de modo táctil, en la oficina dle trabajo le aplicas distancia media y encasa distancia total...

...pero me temo que, si la idea sale adelante (quiero decir si es aceptada por el público, porque tecnológicamente parece que saldrá adelante),su objetivo será la de remplazar las pantallas táctiles en vez de complementar dicha utilidad (que es donde tendría su mejor utilidad), algo que no veo ni necesario, ni adecuado.

Otra postura en contra... es que como tal el dispositivo, no solo se prestaría para la utilidad definida, sino también se sumaría masivamente al espionaje que las grandes empresas (o aplicaciones) hacen de sus 'clientes', al registrar acciones cuando ni siquiera estuviéramos interactuando con el dispositivo, y enviarlo de vuelta a quien sabe donde... Trata de imaginar tu móvil encima de la mesita de noche, y tú con tu pareja en la cama en medio de juegos de amor... Aunque el dispositivo inicialmente tuviere un alcance bastante limitado, es seguro que al paso del tiempo mejoraría tanto, que incluso no precisaría estar orientado frente a frente al usuario, e incluso podría  funcionar bocaabajo o dentro de algún embalaje no opaco a las ondas, que sería el refugio que nos quedaría... meterlo dentro de alguna caja metálica. Es decir, se tomará google las molestias necesarias y gastará el dinero preciso para garantizar que el sistema además de funcionar para los propósitos descritos en el artículo, no dejarán puertas (manifiestamente) abiertas a la seguridad y manipulación?????. Con puertas abiertas, quiero señalar aquello que es de perogrullo, bugs extraños es razonable que pudieran coexistir, y que se intentarían solucionar tan pronto se descubran.

El framework de NET no remplaza ningún fichero existente (solo así mismo, es decir si se diera el caso que tienes un framework 2.0 dañado, pués obviamente si, pero lo remplaza por lo mismo que es o debería ser), crea nuevos ficheros. Incluso si tienes una versión previa, no la sobrescribe.

Pués nada, pronto surgirán 'programadores  nuevos' unidos a esos proyectos, con ganas de 'renovar' dichas aplicaciones y bajo un alias, crearán nuevo código, para 3 meses más tarde bajo otro alias distinto o ahora tal vez sí su verdadero nombre, reclamar haber 'encontrado' un bug (el mismo que crearon ellos 3 meses atrás más o menos bien camuflado) para reclamar la recompensa...

He realizado algunos cambios, siguiendo tus observaciones:
- El tipo de letra a Arial.
- Los colores los he atenuado, son casi blancos. El color amarillo en el fondo de un textbox, viene a indicar que no es editable por el usuario.
- La imagen de la calculadora, la he movido a la esquina superior izquierda (cordenadas 0,0)
- El título a la derecha de la imagen, movido un poco a la derecha.
- Los textos "Billetes", "Cantidad" e "Importe", movidos un poco más abajo...
- He puesto el espacio que se me escapó para los 50 céntimos,
- He retirado el cero para los billetes de 5 euros.
- El botón total no sobra, no es preciso usarlo si no se quiere.
- El título del programa lo he cambiado ligeramente con la info que aportas.
- El sonido se produce siempre que se pulsan ciertas teclas en un textbox editable (por ejemplo teclas: intro, escape)... para evitarlo, usad la tecla Tabulador (la tecla a la izquierda de la "Q"), cumple la misma funcionalidad que buscabas en la tecla intro... pero sin ese molesto sonido.

Debajo la imagen de como es ahora y como se veía antes (para comparar).
Espero que los cambios te satisfagan...

https://workupload.com/file/LLnV5LSM