Roberto Sánchez Programador/Desarrollador .NET

NOTICIAS

Microsoft .NET Framework 4.8.

Ya está lista la última versión de .NET Framework. Contiene multitud de correcciones de anteriores errores, parches de seguridad y mejoras en el lenguaje común en tiempo de ejecución, ASP, Windows Forms, WPF y WCF. Ya está disponible el enlace de descarga del paquete de intalación.

Como novedades principales, se pueden destacar las siguientes:

- Mejoras de accesibilidad en Windows Forms que afecta a la comunicación de datos de la aplicación y las personas con discapacidad visual.

- Resuelto un problema de ASP de manipulación de encabezados HTTP.

- Resueltos varios problemas que afectaban al CLR.

- Habilitación de etiquetas de alto contraste en color en Windows Forms cuando el modo de contraste alto está activado.

- Se añade soporte para Monitor V2 y modo mixto de DPI en WPF.

- En WCF se corrige problema existente en controles ComboBox cuando el modo de alto contraste está activado.

Visual Studio 2019.

Desde el día 2 de abril ya podemos disfrutar del nuevo Visual Studio 2019 en sus tres versiones, Community, Enterprise y Professional.

Sus novedades más importantes son las siguientes:

- Visual Studio Live Share permite a los programadores la colaboración con otros usuarios de forma mucho más sencilla mediante la posibilidad de edición y depuración de código fuente en tiempo real.

- Creación de nuevos proyectos con una búsqueda mejorada de implementación de plantillas.

- Nueva ventana de inicio para comenzar a picar código con más rapidez y que permite trabajar con repositorios de código fuente.

- Utilización de la versión 8 de C#.

- Mejoras en integración de lenguaje Python y soporte de .NET Core 3.0.

Liberado el código fuente de librería 'Maths'.

En el día de hoy he liberado el código fuente completo de la versión 1.1 de la librería 'Maths', un ensamblado de cálculo matemático avanzado que permite las siguientes funcionalidades:

- Números complejos.

- Matrices de dos, tres y cuatro dimensiones.

- Vectores de dos y tres dimensiones.

- Operadores de sumatorio, multiplicatorio, factoriales y factorización.

- Resolución de incógnita mediante expresiones algebraicas.

- Cálculo geométrico en dos dimensiones: rayos, círculos y cuadrados.

- Cálculo geométrico en tres dimensiones: cubos, cilindros, pirámides, esperas y tetrahedros.

Descarga habilitada en este enlace.

Fin del soporte técnico para Windows 7.

Microsoft ha anunciado el final definitivo para el soporte del sistema operativo Windows 7. La fecha prevista es el próximo 14 de enero de 2020.

Tal y como en su día le ocurrió a Windows XP, Microsoft no actualizará el sistema con nuevos parches de seguridad a medida que se detecten nuevas debilidades o potenciales ataques, lo que lo hará potencialmente vulnerable a ataques cibercriminales.

Según los datos analizados por Net Market Share, el 35% de los usuarios de Windows disponen de Windows 7, frente al 52% que ya se han actualizado a Windows 10. Curiosamente, un año antes de que Microsoft abandonara Windows XP, el porcentaje de usuarios que utilizaban dicho sistema operativo era de casi el 25%, cifra sustancialmente inferior al 35% que utiliza a día de hoy Windows 7.

Según fuentes especializadas, la diferencia podría deberse a la satisfacción general de los usuarios que utilizan Windows 7 unida a la mala acogida que ha tenido Windows 10 por parte de algunos de sus clientes. La compañía ha explicado que seguirá dando apoyo a aquellas empresas y agencias gubernamentales que lo deseen.

En cualquier caso, a partir de abril de 2019, los usuarios de Windows 7 verán periódicamente en pantalla un aviso de Microsoft indicando el fin definitivo del soporte.

El síndrome de Burnout, o desgaste profesional del programador.

La profesión de programador, contrariamente a lo que la gente cree, sufre de multitud de problemas y dificultades propias de la actividad. Es falsa la apariencia de ser una profesión en la que sus trabajadores desarrollan su actividad en un entorno amable, con flexibilidad horia, conciliación familiar e, incluso, instalaciones con posibilidades recreativas para el descanso. Muy al contrario, gran número de programadores se encuentran en un ambiente de gran presión trabajando en proyectos muy largos y complicados con plazos excesivamente ajustados. Estas situaciones provocan el llamado síndrome de Burnout.

El síndrome de Burnout puede producir los siguientes síntomas:

- Fatiga crónica.

- Imsomnio.

- Falta de concentración.

- Depresión inmunológica.

- Pérdida de apetito.

- Ansiedad.

- Depresión.

De no tomar medidas y corregir el problema, sus consecuencias más inmediatas pueden ser:

- Falta de disfrute en el trabajo.

- Pesimismo y negatividad.

- Desapego al trabajo y al entorno.

- Aislamiento social.

- Apatía, sentimiento de inutilidad y desasosiego.

- Irascibilidad.

- Falta de productividad y rendimiento.

Generalmente el síndrome se produce por las siguientes causas:

- Estar todo el día sentado delante del ordenador no es nada sano.

- Es un trabajo cognitivo muy intensivo y estresante.

- Trabajas encerrado en ti mismo y las medallas, muchas veces, se las cuelgan otros.

- De forma repetida haces muchos sacrificios y pones mucho esfuerzo en solucionar problemas que corren un gran riesgo de no poder ser solucionados fácilmente y se fracasa por norma. Lo raro es solucionarlos.

Es importante cumplir una serie de normas para evitar todo lo anterior:

- Llevar una buena alimentación y hacer deporte.

- Respetar los horarios de descanso y dormir las suficientes horas.

- Evitar trabajar más horas de las habituales, pues es bien sabido que, sobrepasado un cierto umbral de esfuerzo, la curva de resultados y productividad cae rápidamente.

- Evitar pasar todas las horas de trabajo detrás de las pantallas, pues hay mucho más trabajo de diseño en el desarrollo de software que solamente picar código.

- Emplear tiempo en el dominio de las herramientas de desarrollo, pues a través de ellas simplificaremos el trabajo y reduciremos el tiempo.

- Si el proyecto es excesivamente complicado o, por su dilatación en el tiempo queda estancado, no dudes en pasar a otra cosa.

Estas medidas pueden no ser la solución perfecta, pues cada persona es un mundo; pero sin duda ayudarán a solucionarlo o, al menos, a que el problema no vaya a más. Sin embargo, es importantísimo diagnosticar el problema antes de que éste se haga intratable y acabe por sobrepasar las soluciones.

Diez reglas de oro para un código de calidad.

Escribir código fuente de calidad es mucho más que conocer un lenguaje de programación. Es como escribir una buena novela: no es suficiente saber escribir bien, es también necesario tener grandes conocimientos de estilos literarios. PAra que el código fuente de un programa llegue a las cotas más altaas de calidad, es necesario cumplir varios requisitos que podemos resumirlos en las siguientes diez reglas de oro del código de calidad:

Regla 1: no duplicar.

No hay ninguna situación o contexto que justifique duplicidades de código fuente, absolutamente ninguna. Evidentemente (y esto es de primaria de programación) cualquier operación que se deba repetir en más de una ocasión debe estar contenida en un método aparte al que se llamará cada vez que sea necesaria su realización, aunque para ello sea necesario declararlo como un método estático para acceder a él desde varios puntos de la aplicación.

Sobra decir que el principal problema del código fuente duplicado es que si hay que realizar un cambio en él, debe ser neceario su cambio en todas y cada una de sus repeticiones, lo que aumenta el riesgo de errores y bugs que a la larga pueden ser muy costosos de solventar.

Regla 2: documentar.

Ya no me refiero a comentar líneas, práctica que a mi personalmente no me gusta mucho. Me refiero a la documentación XML del código fuente, que en la plataforma .NET nos permite un método estandarizado de documentación de los métodos, clases, etc. del código fuente.

La documentación, además de ser estandarizada según el sistema para .NET, debe ser sencilla y clara, orientada principalmente para que lo entienda cualquier otro programador además del autor. Hay que tener presente que cuando un proyecto queda "muerto" durante un tiempo, puede ser muy difícil el estudio del código fuente si no está correctamente documentado.

Regla 3: priorizar la herencia de clases.

La herencia es una de las principales características de la programación orientada a objetos, y es también un modo más de ahorro y simplificación de código fuente. Cualquier aplicación medianamente complicada que no haga uso de la herencia es que no está bien construida y caerá en duplicidades innecesarias. Para aplicar una buena estructura de herencia es necesario, antes de comenzar a escribir una sola línea de código, plantear correctamente el esquema de la aplicación e insertar la herencia allí donde sea necesaria.

Regla 4: revisión de código.

Cuántas veces hemos publicado una aplicación que hemos visto que aparentemente funciona correctamente y después hemos comprobado bugs no detectados en el proceso de prueba. Para evitarlo, además de un completo proceso de prueba, es necesario revisar el código profundamente, especialmente en aquellas áreas más susceptibles de errores. Es un proceso largo y tedioso, pero eliminará errores que a la larga pueden darnos muchos problemas.

Regla 5: un método - una acción.

No debes construir métodos que realicen más de una acción concreta. La definición de "acción concreta" serás tú el que la determine en consecuencia con las necesidades del proceso, pero básicamente queda claro que un método únicamente debe realizar una acción concreta. Esto nos repercutirá positivamente de dos maneras: métodos no excesivamente largos, y facilidad de reutilización.

Regla 6: código fácilmente entendible.

Es evidente, pero aun así, cuántas veces hemnos escrito código fuente excesivamente complicado porque la tarea a realizar también era excesivamente complicada. El objetivo es que, aunque la tarea a realizar sea muy compleja, el código sea lo más simplificado y sencillo de entender posible. De no lograrlo, debes estudiar la manera de simplificar ese código lo más posible, pues de lo contrario, a la larga, cualquier cambio en él será una tarea complicadísima.

Si para entender plenamente el funcionamiento de un método relativamente complicado debes emplear más de 5 ó 10 minutos, entonces es que ese método necesita simplificación y claridad.

Regla 7: piensa antes de escribir.

Como ya he dicho antes cuando me refería a la herencia. Es importante tener claro el esquema y la estructura de la aplicación. Es común en muchos desarrolladores comenzar a escribir código a o loco, y cuántas veces hemos acabado eliminando o modificando sustancialmente lo ya escrito en un principio... Piensa bien cómo hacer las cosas y luego escribe sobre seguro.

Regla 8: nombres con significación.

Los nombres de los atributos, propiedades, métodos, clases, etc. deben tener una significación clara respecto a su funcionalidad. Por ejemplo, si tenemos una propiedad llamada 'Connected' que evalúa el estado de conexión de la aplicación con un determinado dispositivo, este mismo nombre nos da una clara idea de su funcionalidad, y sería absurdo ponerle otro nombre como 'Conn', 'cnntd', 'DisCon', etc.

Regla 9: reutilización.

O dicho de otra manera, hacer uso de la no duplicación del código fuente. Cualquier aplicación medianamente complicada realizará unas determinadas acciones de forma repetitiva en muchas ocasiones. Para reutilizar ese código, debe estar escrito de forma genérica, es decir, que sea posible llamarlo desde donde sea necesario y que cumpla correctamente su función independientemente de donde sea llamado.

Regla 10: depuración.

Depura el código fuente una y otra vez, detenidamente, despacio, sin prisas, comprobando todas y cada una de las ramas de acción de la aplicación. Una parte del funcionamiento puede parecernos trivial y sencilla y solamente con escribirla parecemos estar seguros de su correcto funcionamiento, pero luego nos damos cuenta de un error absurdo que nos compromete cuando lo menos lo esperamos.

Revisa, revisa y vuelve a revisar. Y si tenemos alquien que pueda revisar la aplicación "desde fuera" mejor, pues será alguien no condicionado por el esquema mental del funcionamiento de ese código fuente y será más fácil encontrar bugs no detectados.

Reparación de archivos de Windows.

Cuando un archivo de Windows 10 se estropea o queda corrupto el sistema operativo puede comenzar a hacer cosas raras, se bloquea, no reinicia correctamente, va lento o directamente aparece la temida pantalla azul de Windows. Afortunadamente disponemos de una herramienta del sistema para prevenir estas situaciones, y se trata del comprobador de archivos del sistema. Para ejecutar esta solución debes abrir la consola de Windows con permisos de administrador y ejecutar la siguiente línea de comandos:

Un indicador de progeso te informará de la situación del análisis. Cuando éste finalice el sistema te informará que la operación se completó con éxito.

A continuación debes ejecutar otro comando:

Ahora el proceso será más lento y tardará varios minutos. Igual que antes, el sistema irá informando del progreso de la operación y, al finalizar, en el caso de que haya algún error efectuará la reparación.

Los mejores programadores del mundo.

La comunidad de desarrolladores HackerRank ha realizado una publicación relativa a la calidad de los programadores de prácticamente todos los países del mundo. Para ello se han basado en un puntuaciones obtenidas a la hora de analizar código fuente teniendo en cuenta la calidad del mismo y el tiempo empleado en la resolución de diferentes algoritmos. Han recopilado todos los datos y han ofrecido un ránking mundial que sorprende por sus resultados... y es que la fama no implica profesionalidad:

¿Qué ha pasado con Estados Unidos y Reino Unido? Pues eso, que se trata únicamente de la fama. Los programadores chinos han obtenido una puntuación máxima al resolver correctamente todos y cada uno de los desafíos en el tiempo establecido, y los rusos, los polacos y los suizos se han quedado muy de cerca. España no sale mal parada, ocupando el puesto número 18, lo cual sorprende bastante teniendo en cuanta la baja cualificación de programación en los estudios reglados en este país. EEUU, Reino Unido e India quedan por debajo de nosotros, lo cual es muy llamativo y nos ayudará a tener un poco más de confianza en nosotros mismos. Lástima que estas noticias no salgan en los medios de comunicación y la gente siga pensando que los mejores programadores están en los países que siguen teniendo más fama.