23. C# - HASH - Calculo de digestivo SHA1 para un archivo (Ayuda Rápida II)

Problema: Calcular el digestivo (HASH) SHA1 de un archivo
Proyecto: Genérico

Solución:

Esta función es muy útil por que nos permite obtener el hash de un archivo, por este medio podemos validar la integridad del mismo, una función hash nos entrega una cadena de caracteres que es equivalente a otra que se ha dado como entrada, estas funciones entregan una cadena de un tamaño arbitrario.

Una función hash es muy utilizada en la autenticación de usuarios o en la validación de la integridad de un archivo como es este caso, al ejecutar esta función sobre un archivo se obtiene una cadena especial que la podemos usar para determinar si dicho archivo ha sufrido una modificación.

Bueno la función para calcular el SHA-1 es la siguiente:

Y que hace?

Bueno el proceso que hacemos para obtener este digestivo es el siguiente:

1. Inicializamos el motor de criptografía

System.Security.Cryptography.SHA1CryptoServiceProvider oSHA1 =
            new System.Security.Cryptography.SHA1CryptoServiceProvider();

2. Leemos el archivo como un stream

            System.IO.FileStream fArchivo = new System.IO.FileStream(Archivo, System.IO.FileMode.Open,
                      System.IO.FileAccess.Read, System.IO.FileShare.ReadWrite);

3. Obtenemos el digestivo como un arreglo de datos

byte[] arrbytHashValue = oSHA1.ComputeHash(fArchivo);

4. Cerramos el stream como buena practica

fArchivo.Close();

5. Convertimos el arreglo de bytes a una cadena para que pueda ser visualizado

            string strHashData = System.BitConverter.ToString(arrbytHashValue);
            strHashData = strHashData.Replace("-", "");
            return strHashData;


Continuaremos con esta serie de Ayuda Rápida, sin embargo no he olvidado los pendientes que tengo con ustedes

Felices lineas

22. WinForm - ListBox - Copiar todos los elementos (Ayuda Rápida I)

Problema : Deseo copiar todos los elementos de un listbox
Proyecto: Winform

Solución:
El proceso para hacer esto es realmente sencillo, solo es necesario recorrer cada uno de los items que integra el listbox y agregarlo a un StringBuilder, ¿Por que a un StringBuilder? por que esta es la mejor opción cuando construimos cadenas, tiene un rendimiento mucho mayor a concatenar cadenas, aprovechamos que el StringBuilder nos permite formar una cadena con saltos de pagina, y esto lo enviamos al portapaleles.

Para este ejemplo, mi listbox tiene comonombre lstDetalle

Esta sección del blog incluirá tip sencillos para poder hacer ciertas actividades de desarrollo, en busca de facilitarnos el desarrollo, sin embargo continuare con todas las otras secciones y los temas que tengo pendientes con ustedes,

Saludos

21. Agua en Marte!!!! (noticia)

Hola, esta entrada no tiene que ver nada con desarrollo, sin embargo por la importancia de la noticia, tengo que compartirla 28 de Septiembre de 2015, la NASA ha encontrado que bajo determinadas circunstancias hay agua liquida en Marte, esto abre realmente un universo de posibilidades, para lo que puede ser el futuro, y bueno el software es una parte primordial de ese futuro, así que hoy en un día que debería ser recordado como un logro para la humanidad, es tiempo de hacer un compromiso, para poder ver el futuro que nos espera, con errores y aciertos la humanidad ha crecido, bienvenida una nueva época.

Agua en Marte http://edition.cnn.com/2015/09/28/us/mars-nasa-announcement/

Saludos

20. Métricas (Indice de Mantenibilidad)

Tengo varios temas que retomar con ustedes, temas que he dejado en este blog, pero que continuare escribiendo sobre estos, principalmente los patrones de diseño y el análisis de queries, ambos parte fundamental en el proceso de desarrollo.

Como he comentado en otros Post, Visual Studio, nos proporciona herramientas para poder medir el código, para darle una valoración al mismo, esto es importante ya que el código debe ser sencillo de entender por más de un desarrollador, es decir debe poder dársele mantenimiento de una manera sencilla.

Mientras más especializados son los componentes son más fáciles de controlar, estos se convierten en piezas esenciales de algo más grande.

Hoy vamos a hablar de la última métrica, que se encuentra en Visual Studio, el índice de mantenimiento, ¿Por qué la deje al último? Porque esta es la más sencilla, su nombre nos dice por si sola que es, esta nos dice que tan fácil es modificar  nuestro código, y mejor aún, nos lo indica con una bandera que va de rojo a verde.

Mientras el valor se encuentre más cercano al 100 es mejor, pero entonces me dirá, un índice de mantenimiento de 59 es bueno, la respuesta es sí, para el caso de .NET, como lo veremos a continuación.

Se puede decir que es un resumen de las otras métricas, el índice de mantenimiento  es una métrica creada allá por 1992 por Pau Oman y Jack Hagermeister, esta métrica agrupa varias otras como son el Volumen de Halstead (HV) esta es la única métrica que no hemos tocado en esta serie de post esta se define como el número de operaciones por el logaritmo base dos de operaciones distintas (N log2 n) , la complejidad ciclomatica (CC), las líneas de código (LOC) y la cantidad de comentarios.

Con estos valores se propuso una fórmula que nos da que tan mantenible es el código, la formula propuesta fue:

171-25ln(HV) – 0.23CC – 16.2ln(LOC) + 50.0Sin sqr(2.46*COM)

El paper original se encuentra en esta liga: ColemanPaper.pdf

Visual Studio no implementa en su totalidad esta fórmula, Visual Studio implementa una versión reducida de la misma, esta es:

Indice de Mantenibilidad = MAX(0,171-5.2 * ln(HV) – 0.23(CC) – 16.2*ln(LOC) * 100/171

Como se puede ver el equipo de Visual Studio elimino la parte que corresponde a los comentarios en el código.

Microsoft toma en cuenta estos rangos para limitar la mantenibilidad del código

El índice de mantenimiento cambia a amarillo entre 10 y 19 y a rojo ente 0 y 9, pero que es realmente el índice de mantenimiento.

0 – 9 Índice pobre

10 – 19 Índice Moderado

20 – 100 Índice Alto

Codificar no es solo colocar una instrucción tras otra, es necesario que seamos constructores de código de calidad, para reducir el esfuerzo de construcción, mejorar la calidad, disminuir los errores, mejorar el rendimiento, y lo más importante reducir el stress que se genera por códigos con problemas, que al final repercuten en la salud del desarrollador

Felices líneas

19. Métricas (Numero de lineas)

Número de líneas, esta es una de las métricas clásicas, incluso durante mucho tiempo se medían los programas por la cantidad de líneas de código que hubiera en ellos.

¿Pero que tan útil es?

Cuando hablamos de un desarrollo una operación puede ser por pocas o por muchas líneas de código dependiendo del desarrollador, por lo que una complejidad real de la solución no nos la puede dar.

Medir el trabajo en líneas de código no es una buena idea.

Sin embargo si nos ayuda en algo, nos ayuda a ver que métodos y funciones poseen gran tamaño, cuando un método es de un tamaño elevado, este se vuelve muy complejo, empieza a tener una responsabilidad muy alta, como consecuencia es más difícil de manipular.

Tradicionalmente se ha dicho que un método debe ocupar únicamente el espacio de la pantalla del equipo para ser correcto, esta observación no es del todo correcta, un método debe ser un ente altamente especializado, encargado de una actividad, esto muchas veces se puede lograr con muchas o con pocas líneas de código, el hecho de que un método tenga muchas líneas de código no necesariamente dice que está mal, o el hecho de tener muchos métodos muy pequeños con muy pocas líneas nos dice que es lo mejor. Hay que analizar cada caso, ver en que las operaciones se encuentren agrupadas, si bien divide y vencerás debe ser nuestra política, una división muy alta puede provocar que la complejidad se incremente.

Un método puede tener muchas líneas de código (no es lo deseable) pero si esto es justificado, es correcto.

Felices lineas

18. Métricas (profundidad de herencia)

Continuemos con las métricas que nos proporciona Visual Studio, la siguiente métrica, es útil porque nos ayuda a saber que tan complejo es un código.

Pero antes necesitamos un poco de teoría básica, para determinar que es la herencia, bueno la herencia es una de las principales características de la programación Orientada a Objetos, la herencia nos permita que un objeto sea creado a partir de otro, de esta forma el nuevo objeto toma los métodos y atributos que tenía el original.

Esto nos permite agregar funcionalidad sin reescribir todo el código, por lo que la reutilización del mismo es muy alta.

Bueno que nos indica la métrica de profundidad de la herencia nos indicia que tan grande es este árbol de herencia hasta llegar a la clase base.

¿Por qué nos afecta esto?, si bien el código se puede reutilizar, manejar clases con herencia de la herencia como se diría coloquialmente, hace que los flujos se vuelvan complejos, para seguir un flujo se deben hacer muchos saltos entre las clases ¿Quién la heredo? ¿Quién la modifico la primera vez? ¿Quién lo hizo la segunda vez? Y así sucesivamente.

El resultado el código se torna complejo, y entre mayor sea este número el código se vuelve más difícil de entender.

Manejar este número en valores menores 4 es lo mejor siempre.

Sin embrago no hay que asustarse si este número es alto, muchas características de código autogenerado de Visual Studio, nacen con este número en valores mayores a 4, así que analicen en que caso es su código y en qué caso es Visual Studio el que genero este número.

Y como la obtengo, siguiendo el mismo procedimiento que hemos discutido en artículos anteriores.

Las métricas son útiles porque nos ayudan a tener un mejor código, hasta la próxima.

Saludos

17. ¿Qué nos hace programadores?

Hay características muy especiales que todo programador debe tener, que si bien no son indispensables nos ayudan día a día en nuestro trabajo, he hecho esta lista basado en lo que he observado, es mi propia lista espero día a día complementarla, para saber qué es lo que hay en el ADN del programador.

 Capacidad de abstracción: Convertir una idea que muchas veces el cliente no puede visualizar en código y hacer que eso sea exitoso es una de las principales habilidades que debe tener el programador, ¿Cuántas veces un cliente ha dicho necesito algo que haga algo?, es decir el mismo cliente no sabe que es lo que quiere pero sabe que existe ese algo que lo va ayudar a mejorar sus procesos, a controlar su información, a hacer aquella tarea que siempre ha hecho de una forma pero que puede ser mejorada.

Aprendizaje rápido: El programador puede entrar en cualquier área, y debe entenderla rápidamente para poder desarrollar su trabajo, entenderla, y prácticamente hacerse un experto en ella, y no solo eso tener la capacidad de eliminar la ceguera de taller de todos aquellos que día a día realizaron esa actividad, debe tener la visión de mejorar los procesos, todo lo creado por el ser humano es mejorable, esa debe ser su máxima

Reacciones rápidas: Los sistemas son rápidos, y cada día son más rápidos y manejan más información, un programador debe ser capaz de tomar toda esa información que está fluyendo y encontrar soluciones muchas veces al instante en el que ocurre el problema, muchos de los problemas que llegan a ocurrir en un proceso productivo se dan por variables no consideradas en el flujo, y en muchos casos se requieren soluciones en periodos muy cortos de tiempo.

Capacidad de trabajar bajo presión: Todas las metodologías hablan de que existen tiempos para hacer las cosas, pero el mercado no da dichos tiempo, el tiempo es clave para ganar o perder un negocio, el tiempo siempre juega en nuestra contra

  Creatividad: Las soluciones planteadas no siempre están escritas, gran parte del trabajo de desarrollo es artesanal, el programador debe poder armar todas las piezas que tiene en un gran rompecabezas y darle vida, debe ser creativo e inteligente en cómo poner esas piezas para que interactúen de la manera correcta entre ellas.

Auto-aprendizaje: En una ciencia hay leyes que no cambian a través del tiempo, nosotros tenemos tendencias (lenguajes que surgen, nuevas características) que cambian todo el tiempo, lo peor lo que nosotros tenemos esta hecho por humanos que cambian de parecer de un momento a otro, así el lenguaje evoluciona, y de un año a otro puede cambiar completamente, debemos afrontar que hay que aprender todo el tiempo, y lo peor debemos afrontar que hay casos en que hay que desechar conocimientos.

 Obsesivos – Detallistas: Esto puede traducirse en calidad, los procesos tienen muchas entradas, salidas, variables, todo aquello que les da vida, debemos tener esa obsesión de mejorarlos de ser parte de ellos de entenderlos para que hagan aquello para lo que fueron hechos

 Capacidad de comunicación (hablar y escuchar): El usuario se comunica con nosotros y nos narra algo que no existe, nosotros narramos algo que tampoco existe, pero que en las dos cabezas debe formar un nuevo ser que cumpla con una expectativa.

 Memoria: recordar un dato de manera rápida, una regla casi olvidada que si bien esta en el diseño, debe estar en tu memoria, recordar mil funciones y cuando usarlas todo eso está en tu memoria Seguridad (No temer equivocarse): Tu eres el experto, el que lo construyo y dio vida, debes tener seguridad para caminar con pasos firmes, ya que si el constructor duda se genera desconfianza en el cliente, si el cliente no confía en ti, un éxito se convertirá irrevocablemente en un fracaso.

Todo cambio es bueno: En nuestro mundo todo cambia constantemente

Felices líneas

16. Metricas (Cohesión y Acoplamiento)

Cuántas veces hemos escuchado, un buen diseño tiene alta cohesión y bajo acoplamiento, en cuantos documentos hemos leído… una de las características de este diseño es su alta cohesión.

¿Qué es eso?

Ambas son características de la programación orientada a objetos características que son muy importantes durante la etapa de diseño que pueden ser definidas de la siguiente forma:

Cohesión: Lo podemos entender como que cada uno de nuestros módulos sea altamente especializado en sus características o componentes, dicho en un lenguaje más coloquial, hablar siempre del mismo tema, esto nos facilita el diseño, la programación, las pruebas y el mantenimiento, así mientras mayor sea la cohesión mejor es el resultado en el sistema.

Sin embargo este es un concepto abstracto, que no puede ser fácilmente evaluado por una máquina, para determinar el grado de cohesión de un sistema es necesario validar el diseño, y ver que cada módulo sea un módulo especializado.

Y que pasa con el acoplamiento, bueno este es el grado en que una clase conoce a otras, las clases no son independientes, pese a que se recomienda un acoplamiento bajo, las clases requieren conocer a otras, este grado de conocimiento entre las clases genera el acoplamiento, de tal forma que una clase con alto acoplamiento tiene acceso a muchos métodos de diferentes clases, como consecuencia la clase es más compleja, y esta complejidad es la que debemos cuidar cuando tenemos un acoplamiento muy alto.

Mientras más compleja sea una clase, más difícil será el mantenimiento, mayor cantidad y complejidad de pruebas tendrá y será más propensa a errores.

Pero también hay que considerar algo, clases sin acoplamiento no son útiles, porque ningún ente vive aislado en este mundo.

A diferencia de la coherencia, para el acoplamiento, Visual Studio si nos permite obtener por medio de una herramienta el acoplamiento, para ello debemos ir al menú analizar y solicitar las métricas de la solución.

 “Calcular métricas de código para la solución”

Visual Studio inicia con la compilación del código y posteriormente, obtenemos los resultados.

¿Qué valor es óptimo? Este número siempre se debe encontrar en un valor inferior a 9, que incluso puede ser validado por medio de la herramienta de Code análisis de Visual Studio.

Hasta pronto

15. Métricas (Complejidad Ciclomatica)

¿Qué es eso?

Cuando hablamos de arquitectura, empezamos a buscar medidas que nos indiquen la calidad de nuestros diseños, una medida que es ampliamente usada es la complejidad ciclomatica, en palabras sencillas esta nos indica que tan compleja es una función o una clase, es decir la cantidad de rutas que existen para ella. ¿Y en que no ayuda esto? Nos enseña la cantidad de casos de prueba que se necesitan para que este componente se pueda probar al 100%.

Una declaración como esta lo hace muy importante, si bien es prácticamente imposible probar un software al 100%, mientras más complejas sean las pruebas, es más difícil garantizar la calidad del software.

Esta es una de las métricas más importantes en la ingeniería de software, principalmente por 2 características:

1.       Da una visión general de la calidad de la solución

2.       Es independiente del lenguaje

Ahora bien para nosotros como programadores de .NET Visual Studio es capaz de calcular esta métrica, para que nosotros la verifiquemos.

¿Y cómo lo interpretamos? Esto es algo que es importante de esta medida, se interpreta de una forma muy sencilla, mientras en número sea menor es mejor.

Entonces, ¿Qué valores se recomiendan? , Los valores de la complejidad ciclomatica dependen de la organización, pero es recomendable seguir la siguiente tabla:

Mínimo	Máximo	Descripción
1	10	Riesgo pequeño
11	20	Riesgo Moderado
21	50	Alto Riesgo
50		Muy alto riesgo

Bueno ya que entendemos esto, ¿Cómo lo usamos en Visual Studio?

Realmente es muy sencillo, el menú de Visual Studio, nos da una opción que es analizar

Y en esta opción tenemos un menú que dice “Calcular métricas de código para la solución”, simplemente lo seleccionamos, Visual Studio inicia con la compilación del código y posteriormente, obtenemos los resultados.

Pero entonces me dirán, ese código que les muestro tiene una complejidad ciclomatica de 173, es muy alta, sí y no.

Estoy mostrando la complejidad de toda una solución, cada uno de los métodos que da vida a la solución es evaluado, de tal forma que un método solo por el hecho de existir sube en uno dicha complejidad.

¿En qué casos se enciende una alarma? Cuando un método tiene una complejidad ciclomatica alta, es decir hace demasiadas cosa tiene muchas posibilidades, el método ya no es controlable.

Saludos

14. Calidad

Y el reloj avanza sin parar y ya es hora de entregar esa nueva versión del nuevo producto, el programa todavía no se encuentra listo, los minutos corren, los equipos de trabajo se encuentran produciendo líneas de código bajo presión, se empiezan a eliminar características deseables o no esenciales, se hace la entrega y resulta que los programadores tienen mucha ceguera de taller y hay más errores de los que esperábamos, los flujos que se probaron y se diseñaron son muy estrictos, tan así que el menor cambio hace que la aplicación falle.

La entrega al cliente es mala o se retrasa, se genera insatisfacción y además el esfuerzo extra de las últimas horas quemo a el equipo de trabajo, la cantidad de errores excesivos, hace que muchos pierdan la paciencia.

Y acabamos de perder un proyecto que pudo haber sido el proyecto mejor planeado.

Dentro de este mundo del código salvaje quiero platicar un mal habito que tenemos casi todos los programadores, una frase muy común llamada “trabajo mejor bajo presión”, que no es más que la justificación de “Se acabó el tiempo y tengo que codificar muy rápido”.

¿Realmente se acabó el tiempo?

Cuando nos encontramos del lado de la programación tenemos la tendencia a perdernos en un mar de líneas de código pensando en flujos y pensando que el tiempo siempre alcanza. Perdiendo muchas veces día a día productividad desviándonos en actividades fuera del producto original, al final ese esfuerzo extra tan común en el final de un proyecto se puede dar sin pensarlo.

¿Pero qué tan conveniente es? La respuesta es nada, no es conveniente, como humanos al estar cansados nuestra mente no reacciona igual comete más errores.

Es importante que todo el equipo sepa cómo se encuentra el estado de un proyecto, para poder hacer correcciones a tiempo, las correcciones no es trabajar más, la corrección es como encontrar la manera de dedicar el tiempo adecuado a cada actividad.

Un proyecto que se encuentre con errores tiene un costo mucho mayor a una entrega fuera de tiempo, ya que genera una mayor insatisfacción, puede ser hasta peligroso porque un flujo no probado puede causar que un sistema pierda información valiosa.

Nosotros somos los guardianes de la información, eso es para nosotros lo más importante, si la información se daña, perdemos realmente el fin por el que estamos aquí.

La imagen de la empresa, la imagen de nosotros mismos, se daña más con un producto de mala calidad, que con un producto en el que se habló a tiempo el estado del mismo y se aplicaron las medidas para que el producto sea satisfactorio para el cliente.

Terminar un proyecto no es entregar un código.

Terminar un proyecto es que el usuario se sienta bien con el programa, que lo sienta una extensión de él, y que cumpla una de las características más importantes por las que estamos aquí, simplificar las cosas hacer que el sistema sea tan sencillo que realmente permita al usuario dedicar su tiempo en otras actividades.

Un sistema debe ser de tal forma que un usuario debe saber que existe, usarlo pero sin que esto represente que se convierta en un dolor de cabeza.

Las nuevas generaciones no leen manuales, eso lo tenemos que tener en cuenta, por eso cada flujo debe ser confiable, fácil de entender y agradable en su hacer.

Saludos

13. Plan de ejecución (I)

Como desarrolladores muchas veces perdemos la visión, sentimos que el código lo es todo y que todo lo que no es código va más allá de nuestras funciones.

¿Por qué digo esto?

Por un tema llamado base de datos, muchas veces como desarrolladores pensamos que el sistema es todo aquello que no es la base de datos, lo cual es un error, ya que nosotros nos dedicamos a procesar, a interpretar y a darle un valor a la información.

En cualquiera que sea nuestra área, siempre estamos trabajando con la información, por ello no debemos perder el contexto de la base de datos.

Tenemos un gran defecto, que se ve sobre todo en desarrolladores novatos, confiamos demasiado en la velocidad de los sistemas actuales, y poco en si el código que estamos empleando es el mejor para el caso en el que nos encontramos.

A este punto es al que me trae el artículo del día de hoy.

¿Si es un blog de desarrollo, por que analizar los Queries?, bueno porque al final si la base de datos no se comporta de la mejor manera, el sistema que estamos desarrollando no reunirá las expectativas para un cliente.

La herramienta que usaremos para ver esto, son los planes de ejecución. ¿Qué es un plan de ejecución?, es una herramienta que nos proporciona SQL Management Studio para comprender den forma gráfica (en realidad es un XML) que es lo que hace un Query que se ejecuta en la base de datos para que nosotros obtengamos un resultado en específico.

Desde un plan de ejecución, nosotros podemos ver ¿Qué elemento consume un mayor tiempo de procesador?, verificar si requerimos algún cambio a la estructura de la base de datos (índices, claves primarias, foráneas) o simplemente comparar cual de 2 queries es el mejor para resolver una situación.

¿Cómo lo generamos?

Generar un plan de ejecución es muy sencillo, lo único que debemos hacer es entrar a SQL Management Studio y escribir el query que queremos tomar.

Ahora bien tenemos 2 tipos de plan de ejecución el estimado, que se presenta antes de la ejecución del Query, y el Real.

Mi recomendación es que siempre trabajemos con el real, este se muestra una vez que el query termino su ejecución y nos muestra que es lo que realmente hizo la base de datos.

Bien, creemos un ejemplo de un plan de ejecución:

Paso 1: Escribamos un pequeño query

Paso 2: Activemos el plan de ejecución, para eso es necesario ir a menú consultas (query) y activar la opción Desplegar plan de ejecución Real (Include Actual Execution Plan)

Paso 3 Ejecutemos el Query

Al ejecutarlo nos aparece una nueva pestaña

Que muestra el plan de ejecución

Ahora falta analizarlo lo cual será el tema del próximo artículo, hasta pronto