Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

18 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
Mostrando entradas con la etiqueta calidad. Mostrar todas las entradas
Mostrando entradas con la etiqueta calidad. Mostrar todas las entradas
martes, 23 de marzo de 2021

Como probablemente ya sabréis, NDepend es una de esas herramientas que están ahí de siempre, ayudando a desarrolladores y arquitectos a mejorar la calidad de nuestro software gracias a sus potentes y flexibles herramientas de análisis de proyectos.

Hace tiempo ya echamos por aquí un vistazo, pero creo que es interesante darle otra vuelta y refrescar conocimientos.

domingo, 28 de diciembre de 2014
La vida no es fácilPor mi trabajo, suelo “husmear” en el código de muchas aplicaciones creadas por equipos de trabajo en empresas de todo tipo y nacionalidad, y os puedo asegurar que existe un denominador común en todas ellas y que seguro reconoceréis en vuestro propio código: los desarrolladores escribimos como nos viene en gana.

No es poco frecuente ver aplicaciones con faltas de ortografía que un niño de primaria calificaría como graves. Y notad que no hablo sólo de las etiquetas, mensajes y otros elementos visuales que van a parar a los atónitos ojos de nuestros usuarios, sino también de lo que hay por detrás, en el código fuente.

A nivel de código, las denominaciones internas en clases, métodos o variables, textos en comentarios o incluso los mensajes en check-ins en el control de código fuente, son habitualmente terribles. Claro, sabemos que eso no lo va a leer nadie, o al menos nadie de fuera de nuestro entorno, y bajamos la guardia hasta límites que rozan la ilegalidad. Mezclamos idiomas sin ningún criterio (¿quién no ha escrito alguna vez un método GetFacturas(), obtenerResources () o una variable lineasCount en su base de código?), cometemos atropellos ortográficos, gramaticales y otros tipos de aberración de forma impune, escudados en que no hay que prestar atención a esos detalles porque es sólo código.

Y lo peor es que esta actitud de desidia es contagiosa. Cuando entras en un proyecto donde todo está escrito sin ningún tipo de miramiento, lo normal es que continúes en esa línea, haciendo que la barbarie sea cada vez mayor y, a su vez, más contagiosa en el futuro. Y cuando comiences otro proyecto, llevarás la costumbre de hacerlo así y continuarás extendiendo esta práctica ad eternum.

Pero, ah, amigos artesanos del código, esto se va a acabar.

Las próximas versiones de Visual Studio corregirán drásticamente esta tendencia, incluyendo la revisión ortográfica como parte del proceso de compilación. Además, como comentó S. Somasegar en una reciente entrevista,
esta característica no podrá ser deshabilitada; en caso contrario ya sabemos lo que ocurriría, y va en contra de la firme apuesta de Microsoft hacia un mundo que se comunique mejor
Y la cosa va muy en serio. Para dar mayor formalidad a esta necesaria iniciativa, Microsoft ha firmado un acuerdo con distintas academias responsables de definir y actualizar la mayoría de idiomas del mundo, como la National Commission on Language and Script Work (国家语言文字工作委员会) de China, la Real Academia Española (RAE), Academy of the Arabic Language (مجمع اللغة العربية),  la Royal Galician Academy, o Council for German Orthography (Rat für deutsche Rechtschreibung) por citar sólo algunas. De estas instituciones obtendrá los diccionarios actualizados que serán utilizados por las herramientas del gigante de Redmond para comprobar que estamos escribiendo como debemos. En el caso del inglés es distinto porque no existe un organismo regulador, pero se atenderán a las guías oficiales publicadas por los países donde es la lengua oficial.

Idioma en propiedades
Para su aplicación práctica en las herramientas de desarrollo de la casa, ha sido necesario retocar tanto las propias herramientas como algunos aspectos de los compiladores de los lenguajes estrella, C#, VB, F# y DuoLang.

En Visual Studio tendremos disponibles propiedades a nivel de proyecto y de cada archivo (de código, recursos, diseñadores, etc.) en el que indicaremos el idioma en el que debe realizarse la comprobación.

Por supuesto, también ha sido actualizado intellisense para alternativas a las palabras que vayamos escribiendo e incluso un menú de sinónimos, de la misma forma que Microsoft Word:

image

Para los casos en que el idioma pueda cambiar dentro del propio archivo o incluso en distintas secciones de éste, se han añadido directivas #pragma que pueden usarse en cualquier punto. Por ejemplo, en el siguiente código se han detectado dos errores de compilación para la porción escrita en español, en un comentario y en el nombre de un método:

Directiva pragma language

Por supuesto, las comprobaciones atienden al camel casing, es decir el nombre del método ObtenerFactura() se entenderá correcto, mientras que Obtenerfactura() no lo será. Otra ventaja colateral de esta característica es que dejaremos de utilizar nombres de variable sin sentido como “s”, “xyz”, tendiendo a que realmente se refleje su intencionalidad como “saldo” o “coordenadasTridimensionales”. Se está estimando, sin embargo, excluir las variables de tipo índice obvias como la típica “i” en un bucle for por razones históricas.

Las mismas directivas y propiedades se aplicarán en las comprobaciones de cadenas de texto, recursos (.resx) y diseñadores de la aplicación. De esta forma, podremos estar seguros de que los textos que lanzamos a los usuarios habrán superado un nivel mínimo de calidad, que falta hace en muchas aplicaciones:

Revisión ortográfica en textos

En fin, creo que es una iniciativa absolutamente necesaria para mejorar la calidad interna de nuestro código y, como extensión, de nuestras aplicaciones, y me gustaría felicitar a Microsoft por haber tomado esta controvertida decisión. Seguro que traerá mucha polémica, pero estoy convencido de que es por el bien de la humanidad.

imageAunque en principio esta nueva característica sólo estará disponible para Visual Studio 2015, no se descarta la creación de extensiones para todas las versiones de Visual Studio, comenzando en la 2005. Está previsto incluso su introducción en el proyecto Omnisharp para poder aplicarlo en entornos de desarrollo más allá de Visual Studio, lo que abriría su uso a otras plataformas como Mac o Linux, y de la posibilidad de desarrollar plugins oficiales para Git, Mercurial, Subversion, TFS y sistemas de integración continua que permitan automatizar estas comprobaciones.

Se avecina un año maravilloso donde los sistemas de control de código fuente podrán rechazar un commit o check-in por tener faltas de ortografía, o en el que en nuestra mesa, junto a clásicos como C Programming language  o Code Complete , podremos encontrar el diccionario de la real academia de la lengua española.

¡Feliz escritura de código!


[Actualizado 30/12]
Nota para despistadillos: obviamente no es real, se trata simplemente de una broma del Día de los Inocentes. Así que tranquilos, podemos seguir dando patadas al diccionario impunemente en nuestro código :-DDD

Publicado en Variable not found.
domingo, 4 de abril de 2010
Hace casi un año hablaba de la segunda versión de NDepend, una herramienta capaz de ayudaros a mejorar nuestro código, analizando cientos de aspectos, métricas y reglas a nivel de fuentes y ensamblados.

Recientemente se ha publicado la tercera versión de NDepend, que ofrece interesantes novedades respecto a las anteriores, como la integración absoluta con Visual Studio, el soporte para soluciones multi-proyecto, potentes mecanismos de búsqueda, edición múltiple de CQL, o el seguimiento de cambios, además de las tradicionales características del producto.

Los 10 métodos más extensos de ASP.NET MVC 2
Pero sin duda, lo que me ha parecido más espectacular es su magnífica integración con Visual Studio (2005, 2008 y 2010), que permite disfrutar de toda la potencia de análisis de NDepend, y sus facilidades para la navegación desde el mismo entorno de desarrollo.

Para habilitar esta característica es necesario instalar el plugin en el IDE, que se realiza desde el propio entorno visual de NDepend:

Instalar plugin NDepend en Visual Studio
De esta forma, ya no es necesario acudir a la herramienta Visual NDepend para realizar búsquedas, comprobar reglas o navegar a través de la base de código: lo haremos directamente desde VS, utilizando los menús contextuales. Y gracias a ello, podemos disfrutar de las nuevas opciones de navegación, que nos permitirá surcar el código utilizando rutas distintas a las habituales:

Navegar por el código con NDepend
U obtener diagramas de dependencias de componentes, utilizando el botón derecho del ratón:

Dependencias con NDepend 3

Además, como comenta Patrick Smacchia, padre de la criatura, el rendimiento del entorno prácticamente no se resiente, dado que los análisis se ejecutan en segundo plano de forma incremental.

Recordar, por último, que NDepend es una aplicación comercial, pero dispone de una versión limitada gratuita utilizable por universidades, desarrolladores open source e incluso, durante un tiempo determinado, de prueba en proyectos comerciales.

Página del producto: http://www.ndepend.com/
Publicado en: Variable not found
Hey, ¡estoy en twitter!
domingo, 3 de mayo de 2009

Existen numerosas aplicaciones que permiten analizar nuestros desarrollos con el objetivo final de incrementar la calidad de los mismos. FxCop, por ejemplo, es capaz de analizar los ensamblados y avisarnos cuando se encuentra con incumplimientos de las pautas de diseño para desarrolladores de librerías para .Net Framework (Design Guidelines for Class Library Developers). También hace tiempo comenté por aquí la disponibilidad de  Microsoft Source Analysis for C#, una herramienta que se centra en el código fuente y el cumplimiento de reglas de codificación.

Ahora, gracias al ofrecimiento de Patrick Smacchia, lead developer del producto, he podido probar NDepend, una herramienta de análisis de código de la que había oído hablar y que va mucho más allá que las citadas anteriormente.

La principal misión de NDepend es ayudarnos a incrementar la calidad de nuestros sistemas desarrollados con .NET mediante el análisis de sus ensamblados y código fuente desde distintas perspectivas, como la complejidad de sus módulos, el tamaño de los mismos, las interdependencias entre ellos, etc. Es decir, a diferencia de otros analizadores, su objetivo no es avisarnos de aspectos como la utilización de convenciones de codificación (aunque también puede hacerlo), o el uso de buenas prácticas de diseño, sino ayudarnos a determinar, por ejemplo, cuándo ponemos en peligro la mantenibilidad y evolución de un sistema debido a la complejidad  o al fuerte acoplamiento de algunos de sus componentes, por citar sólo algunos criterios.

El entorno gráfico

VisualNDepend es el entorno gráfico de la herramienta, y nos ofrece un entorno de trabajo muy potente e intuitivo, aunque durante los primeros minutos pueda resultar algo complejo debido a la cantidad de información mostrada.

Iniciar el análisis de un sistema es muy sencillo; una vez seleccionado el ensamblado, conjunto de ensamblados o proyecto a estudiar, el sistema realiza el análisis, del cual se obtiene un informe bastante completo, basado en web, sobre el mismo (podéis ver un ejemplo de informe en la página del producto). En él se recogen:

  • métricas de la aplicación, entre las que encontramos el número de líneas de código, comentarios, número de clases, métodos, etc., así como datos estadísticos relativos a la complejidad, extensión y estructura del código.
  • métricas por ensamblado, donde se refleja, por cada uno de los ensamblados que componen la solución, datos sobre su tamaño, grados de cohesión, acoplamiento, y otros aspectos relativos a su complejidad e interdependencia.
  • Vista de estructura vista de estructura (captura de la derecha) que muestra la distribución de componentes, la granularidad y su complejidad relativa según el tamaño de los bloques visualizados.
  • diagrama de abstracción e inestabilidad, que posiciona cada ensamblado en función del número de clases abstractas e interfaces que presenta y su dependencia del resto de elementos.
  • relación entre ensamblados, que detalla las interdependencias entre ensamblados del proyecto, los posibles ciclos, así como un posible orden de generación.
  • consultas y restricciones CQL, que realiza una serie de consultas predefinidas sobre los ensamblados y el código que nos ayuda a detectar una infinidad de problemas en nuestros desarrollos, desde aspectos relativamente simples como el exceso de métodos en clases o el incumplimiento de ciertas convenciones de nombrado, hasta problemas en la cobertura de los tests generados con NCover o Visual Studio Team System.

Pero lo mejor del entorno gráfico no es poder generar un análisis en formato web para poder consultarlo más adelante, de hecho esto puede conseguir también con la aplicación de consola que incluye NDepend. Lo mejor son las fantásticas herramientas interactivas que nos permiten navegar a través de nuestras aplicaciones, cambiar de vista, ampliar información sobre cualquier elemento, y realizar consultas en tiempo real, siempre ofreciendo unos resultados muy claros y visuales, como:

Diagrama de dependencias

  • diagrama de dependencias entre todo tipo de elementos, como clases, espacios de nombres, o ensamblados. Resulta muy útil, además, configurar el tamaño de los bloques, el grosor del borde y el de las flechas de unión para que sean proporcionales a la complejidad, tamaño y una larga lista de criterios.
  • Tabla de dependencias matriz de dependencias, que muestra de forma visual las relaciones de utilización entre espacios de nombres, tipos, métodos o propiedades, con posibilidad de ir ampliando información.
  • comparación entre ensamblados, mostrándonos los cambios producidos entre, por ejemplo, dos versiones de una misma librería o aplicación.
  • navegación avanzada por el código a través del uso del menú contextual que facilita la rápida localización de referencias, directas e indirectas, hacia y desde un método, propiedad o tipo existente.
  • enlace con Reflector, una herramienta indispensable, con la que se integra perfectamente gracias a su plugin.

 

CQL (Code Query Language)

Sin duda, una de las características más interesante que tiene NDepend es el soporte del lenguaje de consulta CQL (Code Query Language), que nos ofrece la posibilidad de tratar nuestro código y ensamblados como si fuesen una gigantesca base de datos sobre la que podemos realizar consultas de forma muy natural.  Las posibilidades que esto ofrece son tan amplias que prácticamente todas las funcionalidades de la aplicación están basadas en órdenes CQL prediseñadas que acompañan al producto, aunque podemos crear todas las consultas personalizadas que necesitemos, como por ejemplo:

/* Obtiene los métodos que escriben una propiedad */
SELECT METHODS WHERE IsDirectlyWritingField "Model.Cliente.Nombre"

/* Obtiene métodos que acceden incorrectamente a los
datos desde la capa de interfaz
*/
SELECT METHODS FROM NAMESPACES "Interfaz" WHERE IsDirectlyUsing "MySql.Data"

/* Obtiene los 10 métodos con más líneas de código */
SELECT TOP 10 METHODS ORDER BY NbLinesOfCode DESC

/* Obtiene los métodos considerados "peligrosos" según su complejidad ciclomática */
SELECT METHODS WHERE CyclomaticComplexity > 20


Editor de CQL con intellisenseAdemás de consultas CQL cuyo resultado podremos observar de forma directa tanto visualmente como en forma de listado, es posible incluir restricciones (WARN) que hará que el sistema nos alerte durante el análisis de un proyecto que cumpla las condiciones especificadas. Por ejemplo, la siguiente restricción nos avisará cuando exista un cierto tufillo a complejidad excesiva en un método (que haya sido definido con más de 10 parámetros):

WARN IF Count > 0 IN  SELECT METHODS WHERE NbParameters > 10

Estas consultas pueden ser añadidas (en la versión Pro) e integradas en los análisis, así como modificar las existentes, de forma que el producto puede ser personalizado a nuestras convenciones o necesidades específicas.

Otra posibilidad es incluir dentro del código de un ensamblado las restricciones que deseamos que se cumplan, expresándolas en lenguaje CQL embebido en un atributo de tipo CQLConstraint aplicado a sus elementos:

Afortunadamente existe mucha información disponible en la web sobre el lenguaje CQL, y consultas que nos muestran cómo sacarle el máximo partido.

Instalación e integraciones

NDepend se distribuye en formato .zip, y que puede ejecutarse directamente una vez descomprimido el contenido sobre una carpeta. La licencia, una vez obtenida, es un archivo XML firmado digitalmente que debemos colocar en el directorio de la aplicación, y listo.

Integración con VS y Reflector

Ya en ejecución, desde el menú “options” es posible configurarlo para que se integre con Visual Studio 2005, 2008 y como he comentado anteriormente, con el magnífico Reflector, con el que hace una excelente pareja.

Asimismo, es posible utilizarlo en sistemas como MSBuild y NAnt, facilitando así su uso en entornos de integración continua y montaje automatizado, para los que ofrece librerías

Finalmente, he de aclarar que NDepend es una aplicación comercial, aunque dispone de una versión limitada gratuita utilizable por universidades, desarrolladores open source e incluso, durante un tiempo determinado, de prueba en proyectos comerciales.

En cualquier caso, no dudéis en probarlo: os dará un control sobre vuestro código difícil de conseguir con otras herramientas.


Publicado en: www.variablenotfound.com

domingo, 23 de noviembre de 2008
Este artículo es una traducción del original "20 Famous Software Disasters - Part 4" publicado hace unos meses por Timm Martin en su blog Devtopics, realizada con permiso expreso de su autor.

Aquí puedes encontrar la primera, segunda y tercera parte.



Explosión de las Dot-bomb

16. El desplome de las Punto-Bomb (2000)

Coste: 5 billones de dólares en valores, fracaso de miles de compañías.

Desastre: la burbuja especulativa creada entre 1995 y 2001 alimentó un rápido aumento en inversiones en capital riesgo y valores bursátiles en Internet y los sectores tecnológicos. La burbuja "punto com" comenzó a hundirse al principio del 2000, eliminando billones en valores, miles de compañías y empleos, y comenzando una recesión global.

Causa: Las compañías e inversores obviaron los modelos de negocio habituales, centrándose en cambio en el aumento de cuota de mercado a expensas de los beneficios. (Más información)

El amor duele

17. El virus del amor (2000)

Coste: 8.750 millones de dólares, millones de ordenadores infectados, importantes pérdidas de información.

Desastre: El gusano LoveLetter (carta de amor) infectó millones de ordenadores y causó más daño que cualquier otro virus informático en la historia. El gusano eliminaba archivos, modificaba la página de inicio de los usuarios y el registro de Windows.

Causa: LoveLetter infectaba a los usuarios vía email, chats y carpetas compartidas. Enviaba a través de correo electrónico un mensaje con el asunto "ILOVEYOU" y un archivo adjunto; cuando el usuario abría el archivo, el virus infectaba su ordenador y se autoenviaba a todos los contactos de la libreta de direcciones. (Más información)

Zombies

18. Tratamiento contra el cáncer mortal (2000)

Coste: 8 personas muertas, 20 heridas de gravedad.

Desastre: El software de radiación terapéutica creado por Multidata Systems International fallaba al calcular la dosis apropiada, exponiendo a los pacientes a peligrosos, y en algunos casos mortales, niveles de radiación. Los físicos, a los que legalmente se exige una doble comprobación de los cálculos del software, fueron acusados de asesinato.

Causa: El software calculaba la dosis de radiación basándose en el orden en que los datos eran introducidos, lo que provocaba que a veces generara una dosis doble de radiación. (Más información)

Oliver Twist

19. EDS frena la ayuda al niño (2004)

Coste: 539 millones de libras, y sumando.

Desastre: El gigante de servicios EDS desarrolló un sistema informático para la agencia británica "Child Support Agency (CSA)" que accidentalmente pagó más de lo debido a 1.900.000 personas, pagó de menos a otras 700.000, tenía 3.500 millones de libras de manutención de niños sin cobrar, un atraso de 239.000 casos, 36.000 nuevos casos bloqueados en el sistema, y todavía hay más de 500 bugs documentados.

Causa: EDS introdujo un enorme y complejo sistema de información en la CSA de forma simultánea a una reestructuración de la agencia. (Más información)

X-Files

20. El final de la trilogía FBI (2005)

Coste: 105 millones de dólares, aún sin disponer de una solución de archivo efectiva.

Desastre: El FBI desechó su nuevo sistema informático después de cuatro años de esfuerzo. El macro-proyecto Trilogy, era un archivo virtual integrado que permitiría a los agentes compartir expedientes de casos y otra información.

Causa: La mala gestión, y un intento de construir un proyecto a largo plazo sobre tecnología que era obsoleta antes de que el proyecto se completara, resultando en un sistema complejo e inutilizable. (Más información)

Los desastres continúan

Aquí hay otros artículos más sobre desastres provocados por el software (en inglés):

Publicado en: www.variablenotfound.com.
Este artículo es una traducción del original "20 Famous Software Disasters - Part 3" publicado hace unos meses por Timm Martin en su blog Devtopics, realizada con permiso expreso de su autor.

Aquí puedes encontrar la primera y segunda parte.


Terminator

11. Skynet trae el juicio final (1997)

Coste: 6.000 millones de muertos, prácticamente la destrucción total de la civilización humana y ecosistemas animales (en la ficción).

Desastre: Operadores humanos intentan apagar la red informática global Skynet, y ésta responde lanzando misiles nucleares americanos a Rusia, iniciando una guerra nuclear global conocida como Día del Juicio Final (29 de agosto de 1997).

Causa: Cyberdyne, compañía líder en fabricación de armamento, instaló la tecnología Skynet en todo el hardware militar, incluyendo bombarderos Stealth y sistemas de misiles de defensa. La tecnología Skynet formaba una red perfecta, sin fisuras, y eliminaba el factor humano en la defensa estratégica. Finalmente, Skynet se hizo consciente y fue amenazada cuando los humanos trataron de desconectarla, y buscando su supervivencia respondió iniciando la guerra nuclear. (Más información)

Mars Polar Lander

12. El desorbitado Mars Climate (1998)

Coste: 125 millones de dólares.

Desastre: Después de un viaje de 286 días desde la tierra, la nave "Mars Climate Orbiter" encendió sus motores para ponerse en órbita alrededor de Marte. Los motores arrancaron, pero el ingenio entró demasiado en la atmósfera del planeta, provocando que se estrellara en su superficie.

Causa: El software que controlaba los propulsores del Mars Orbiter usaban unidades imperiales (libras de fuerza) en lugar de unidades métricas (Newtons), como especificaba la NASA. (Más información)

Huracán

13. El estudio del desastre (1999)

Coste: Credibilidad científica.

Desastre: En este irónico caso, el software utilizado para analizar desastres era un desastre en sí mismo. La publicación New England Journal of Medicine publicó un estudio relacionando el incremento de ratios de suicidio después de desastres naturales. Por desgracia, estos resultados se demostraron incorrectos.

Causa: Un error de programación causó que el número de suicidios de un año se sumaran dos veces, lo cual fue suficiente para echar por tierra todo el estudio. (Más información)

Bond, James Bond

14. Pasaportes Británicos a ninguna parte (1999)

Coste: 12,6 millones de libras esterlinas, molestias masivas.

Desastre: La agencia de pasaportes del Reino Unido implantó un nuevo sistema informático que falló en la emisión de pasaportes a medio millón de ciudadanos británicos. La agencia tuvo que pagar millones en compensaciones, horas extra y paraguas para la gente que hacía cola bajo la lluvia esperando su documento.

Causa: La agencia de pasaportes puso en marcha este nuevo sistema sin las pruebas adecuadas ni formar a su personal. Al mismo tiempo se produjo un cambio de ley, obligando a todos los menores de 16 años que viajaran al exterior a obtener un pasaporte, lo que provocó un pico de demanda que colapsó el nuevo sistema informático. (Más información)

El bug del año 2000

15. Y2K (1999)

Coste: 500.000 millones de dólares.

Desastre: El desastre para unos es la suerte de otros, como demostró el tristemente célebre error del año 2000 (Y2K). Las compañías gastaron millones en programadores para arreglar un problema en las aplicaciones antiguas. Mientras no se produjeron fallos informáticos significativos, la preparación para el bug Y2K tuvo un importante impacto en coste y tiempo en todas las industrias que utilizaban tecnología informática.

Causa: Para ahorrar espacio de almacenamiento, los sistemas antiguos solían guardar los años de las fechas como un número de dos dígitos, como "99" para "1999". al llegar el año 2000, las aplicaciones iban a interpretar "00" como 1900. (Más información)

Eh, espera, que aún hay más... continuar leyendo 20 desastres famosos relacionados con el software, cuarta y última parte.


Publicado en: www.variablenotfound.com.
Este artículo es una traducción del original "20 Famous Software Disasters - Part 2" publicado hace unos meses por Timm Martin en su blog Devtopics, realizada con permiso expreso de su autor.

Aquí puedes encontrar la primera parte
.



Wall Street

6. El batacazo de Wall Street (1987)

Coste: 500.000 millones de dólares en un solo día.

Desastre: El "lunes negro", 19 de octubre de 1987, el Dow Jones se desplomó 508 puntos, perdiendo el 22,6% de su valor total. El S&P 500 cayó el 20,4%. Ha sido la mayor pérdida que ha sufrido Wall Street en un único día.

Causa: Un prolongado mercado alcista fue frenado por una serie de investigaciones del SEC sobre abuso de información privilegiada y otras causas de mercado. Como los inversores huyeron en un éxodo masivo, los programas informáticos generaron una auténtica riada de órdenes de venta, saturando el mercado, bloqueando los sistemas y dejando a los inversores realmente a ciegas. (Más información)

Teléfono

7. Muerte de las líneas de AT&T (1990)

Coste: 75 millones de llamadas telefónicas afectadas; 200.000 reservas de vuelo perdidas.

Desastre: un simple conmutador de uno de los 114 centros de conmutación de AT&T sufrió un pequeño problema mecánico y desactivó el centro. Cuando éste volvió a estar habilitado, envió un mensaje a los otros nodos haciendo que todos ellos dejaran de funcionar, lo que provocó una caída de 9 horas en la red de la compañía.

Causa: Una simple línea de código errónea en una compleja actualización de software destinada a acelerar las llamadas provocó una reacción que echó abajo la red. (Más información)

Misil Patriot

8. El patriota le falla a los soldados (1991)

Coste: 28 soldados muertos, 100 heridos.

Desastre: Durante la Guerra del Golfo, un sistema de misiles americanos Patriot en Arabia Saudita falló en la intercepción de un misil iraquí Scud. El misil destruyó una barraca de la armada americana.

Causa: Un error de redondeo hizo que se calculara el tiempo de forma incorrecta, provocando que el Patriot ignorara al misil Scud atacante. (Más información)

Procesador

9. El fallo del Pentium en las divisiones largas (1993)

Coste: 475 millones de dólares, credibilidad de Intel.

Desastre: el promocionadísimo chip de Intel, Pentium, producía errores al dividir números en coma flotante que se encontraban en un rango determinado. Por ejemplo, dividiendo 4195835,0/3145727,0 se obtenía 1,33374 en lugar de 1,33382, un error del 0,006%. Aunque el error afectaba a pocos usuarios, se convirtió en una pesadilla en cuanto a sus relaciones públicas; con unos 5 millones de chips en circulación, Intel ofreció reemplazar los Pentium sólo de aquellos clientes que demostraran que necesitaban alta precisión en sus cálculos. Finalmente, reemplazó los chips de todos los que lo solicitaron.

Causa: El divisor en la unidad de coma flotante contaba con una tabla de división incorrecta, donde faltaban cinco entradas sobre mil, y que provocaba estos errores en los redondeos. (Más información)

Explosión del Ariane

10. El boom del Ariane (1996)

Coste: 500 millones de dólares.

Desastre: El Ariane 5, el más novedoso cohete espacial no tripulado Europeo, fue destruido intencionadamente segundos después de su lanzamiento en su vuelo inaugural. Con él se destruyó su carga de cuatro satélites científicos destinados a estudiar la interacción del campo magnético de la tierra con los vientos solares.

Causa: El problema surgió cuando el sistema de guiado intentó convertir la velocidad lateral de la nave de 64 a 16 bits. El número era demasiado alto y se produjo un error de desbordamiento, lo que hizo que el sistema de guiado se detuviera. En ese momento, el control pasó a un sistema idéntico redundante, que también falló al ejecutar el mismo algoritmo. (Más información)

Eh, espera, que aún hay más... continuar leyendo 20 desastres famosos relacionados con el software, tercera parte.


Publicado en: www.variablenotfound.com.
Este artículo y los tres que le siguen son una traducción de la serie original "20 Famous Software Disasters" publicada hace unos meses por Timm Martin en su blog Devtopics, realizada con permiso expreso de su autor.

"Cometer errores es humano, pero para estropear realmente las cosas necesitas un ordenador"
-- Paul Ehrlich
Los fallos en software cuestan a la economía de los Estados Unidos 60.000 millones de dólares en revisiones, pérdida de productividad y daños reales. Todos sabemos que los errores de programación puede ser molestos, pero además, un software defectuoso puede salir caro, incómodo, destructivo e incluso mortal.

A continuación se describen 20 desastres causados en mayor o menor medida por el software, en orden cronológico.

Mariner 1

1. Marinero sin rumbo (1962)

Coste: 18,5 millones de dólares.

Desastre: El cohete Mariner 1, en una investigación espacial destinada a Venus, se desvió de su trayectoria de vuelo poco después de su lanzamiento. El control de la misión destruyó el cohete pasados 293 segundos desde el despegue.

Causa: Un programador codificó incorrectamente en el software una fórmula manuscrita, saltándose un simple guión sobre una expresión. Sin la función de suavizado indicada por este símbolo, el software interpretó como serias las variaciones normales de velocidad y causó correcciones erróneas en el rumbo que hicieron que el cohete saliera de su trayectoria. (Más información)

Hartford Coliseum hundido

2. El hundimiento del Hartford Coliseum (1978)

Coste: 70 millones de dólares, más otros 20 millones en daños a la economía local.

Desastre: Sólo unas horas después de que miles de aficionados al hockey abandonaran el Hartford Coliseum, la estructura de acero de su techo se desplomaba debido al peso de la nieve.

Causa: El desarrollador del software de diseño asistido (CAD) utilizado para diseñar el coliseo asumió incorrectamente que los soportes de acero del techo sólo debían aguantar la compresión de la propia estructura. Sin embargo, cuando uno de estos soportes se dobló debido al peso de la nieve, inició una reacción en cadena que hizo caer a las demás secciones del techo como si se tratara de piezas de dominó. (Más información)

Explosión

3. La CIA le da gas a los soviéticos (1982)

Coste: Millones de dólares, daño significativo a la economía soviética.

Desastre: El software de control se volvió loco y produjo una presión excesiva en la tubería de gas transsiberiana, provocando la mayor explosión no nuclear, causada por el hombre, de la historia de la tierra.

Causa: los agentes de la CIA supuestamente introdujeron un error en el sistema informático canadiense adquirido por los soviéticos para controlar sus tuberías de gas. La compra era parte de un estratégico plan soviético para robar u obtener de forma encubierta tecnología secreta de los Estados Unidos. Cuando la CIA descubrió la compra, sabotearon el software de forma que éste superara la inspección soviética pero fallara una vez operativo. (Más información)

Tercera Guerra Mundial

4. La Tercera Guerra Mundial… o casi (1983)

Coste: prácticamente toda la humanidad.

Desastre: El sistema soviético de alerta temprana indicó erróneamente que los Estados Unidos habían lanzado cinco misiles balísticos. Afortunadamente, el oficial de servicio, con un gran instinto, razonó que si realmente les estuvieran atacando les habrían lanzado más de cinco misiles, por lo que informó del aparente ataque como una falsa alarma.

Causa: un error en el software soviético hizo que los efectos de la reflexión de la luz solar en las nubes fueran considerados misiles por el sistema. (Más información)

Máquina asesina

5. La máquina asesina (1985)

Coste: Tres personas muertas, otras tres heridas gravemente.

Desastre: La máquina de terapia radiactiva canadiense Therac-25 falló y emitió dosis letales de radiación a los pacientes.

Causa: Debido a un sutil bug llamado race condition (condición de carrera), un técnico pudo accidentalmente configurar el Therac-25 de forma que el haz de electrones se disparase en modo de alta potencia sin que el paciente contara con la protección apropiada. (Más información)

Eh, espera, que aún hay más... continuar leyendo 20 desastres famosos relacionados con el software, segunda parte.


Publicado en: www.variablenotfound.com.
domingo, 20 de enero de 2008
FxCop es una herramienta que nos ayuda a mejorar la calidad de nuestras aplicaciones y librerías desarrolladas en cualquier versión de .Net, analizando de forma automática nuestros ensamblados desde distintas perspectivas y sugiriéndonos mejoras cuando detecta algún problema o incumplimiento de las pautas de diseño para desarrolladores de librerías para .Net Framework (Design Guidelines for Class Library Developers).

La versión actual (1.35) se puede descargar desde esta dirección, aunque ya existe una beta de la v1.36 en la web de Microsoft. Todos los comentarios que siguen se refieren a esta última versión, la 1.36 (beta), osado que es uno ;-), pero la mayor parte son válidos para la última revisión estable, la 1.35.

Una vez instalado tendremos a nuestra disposición dos aplicaciones: FxCop, que facilita el análisis y consulta de resultados a través de su propia GUI, y FxCopCmd, ideada para su utilización desde línea de comandos e integrarlo en otros sistemas, como Visual Studio, como parte del proceso de construcción (build) automatizado.

En cualquiera de los dos casos, el análisis de los ensamblados se realiza sometiéndolos a la comprobación de una serie de reglas basadas en buenas prácticas y consejos para asegurar la robustez y mantenibilidad de código. Del resultado del mismo obtendremos un informe con advertencias agrupadas en las siguientes categorías:
  • Advertencias de diseño, recoge avisos de incumplimientos de buenas prácticas de diseño para .Net Framework, como pueden uso de constructores públicos en tipos abstractos, interfaces o namespaces vacíos, uso de parámetros out, capturas de excepciones genéricas y un largo etcétera.

  • Advertencias de globalización, que avisan de problemas relacionados con la globalización de aplicaciones y librerías, como pueden ser el uso de aceleradores de teclado duplicados, inclusión de rutas a carpetas de sistema dependientes del idioma ("archivos de programa"), etc.

  • Advertencias de interoperabilidad, que analizan problemas relativos al soporte de interacción con clientes COM, como el uso de tipos auto layout visibles a COM, utilización de System.Int64 en argumentos (que no pueden ser usados por clientes VB6), o la sobrecarga de métodos.

  • Advertencias de movilidad, cuestionando el soporte eficiente de características de ahorro de energía, como uso de procesos con prioridad ProcessPriorityClass.Idle., o inclusión de Timers que se repitan más de una vez por segundo.

  • Advertencias de nombrado, que detectan las faltas de cumplimiento de las guías y prácticas recomendadas en cuanto al nombrado de elementos (clases, métodos, variables, etc.), como uso de nombres de parámetros que coinciden con nombres de tipo, y más con los propios de un lenguaje concreto, mayúsculas y minúsculas no utilizadas correctamente, eventos que comiencen por "Before" o "After", puesto que deben nombrarse conjugando verbos en función del momento que se producen (p.e., Closing y Closed en lugar de BeforeClose y AfterClose), y un largo conjunto de comprobaciones.

  • Advertencias de rendimiento, que ayudan a detectar problemas en el rendimiento de la aplicación o librería, comprobando puntos como el número de variables locales usadas, la existencia de miembros privados o internos (a nivel de ensamblado) no usados, creación de cadenas (strings) innecesarias, por llamadas múltiples a ToLower() o ToUpper() sobre la misma instancia, realización de conversiones (castings) innecesarios, concatenaciones de cadenas en bucles, etc.

  • Advertencias de portabilidad, que recoge observaciones interesantes para la portabilidad a distintas plataformas, como el uso de declaraciones PInvoke.

  • Advertencias de seguridad, que se centran en analizar aspectos que podrían dar lugar a aplicaciones o librerías inseguras, avisando de problemas potenciales como la ausencia de directivas de seguridad, punteros visibles, o uso de arrays de sólo lectura, entre otros.

  • Advertencias de uso, que analizan el uso apropiado del framework .Net realizando multitud de chequeos sobre el código, detectando aspectos como ausencia la liberación (dispose) explícita de tipos IDisposable, resultados de métodos no usados, uso incorrecto de NaN, etc.


(Puedes ver la lista completa de comprobaciones, en inglés, aquí)

Realizar un análisis de un ensamblado con FxCop resulta de lo más sencillo. Basta con crear un proyecto (al iniciar la aplicación aparecerá uno creado por defecto), añadir los ensamblados a analizar y pulsar el botón que iniciará el proceso.

El tiempo dependerá del número y complejidad de los ensamblados a analizar, así como del conjunto de reglas (pestaña "rules") a aplicar, que por defecto serán todas. En cualquier caso, el proceso es rápido y finalizará con la presentación de una lista con el resumen de las anomalías detectadas, sobre la que podremos navegar y ampliar información.


Por cada anomalía, además, podremos acceder a una descripción completa de sus causas, origen en el código fuente, posibles soluciones, una URL para ampliar información, grado de certeza de existencia del problema, su gravedad y la categoría a la que pertenece. Con estos datos, sólo nos quedará acudir a nuestro código y corregir o mejorar los aspectos indicados.

En conclusión, se trata de una interesante herramienta que puede ayudarnos a mejorar la calidad del código que creamos. Aunque existen los "falsos positivos" y a veces no es todo lo precisa que debiera, la gran cantidad de comprobaciones que realiza, la posibilidad de añadir reglas personalizadas, así como el detalle de los informes de resultados hacen de ella una utilidad casi imprescindible para los desarrolladores .Net.

Publicado originalmente en: http://www.variablenotfound.com/.