25. Nuestra historia (I)

Cada ciencia conoce su historia, creo que solo nosotros no, es decepcionante ver que muy poca gente de TI tenga idea de quienes son los grandes personajes que han dado valor a la industria, que han hecho descubrimientos que nos han permitido llegar a lo que es hoy en día.

Cuando se habla de otras áreas, la gente conoce a sus predecesores, me temo que en TI no los conocemos, sabemos como arreglar un equipo, como hacer un programa, recordamos de nuestras clases que existen generaciones de computadoras, pero la cultura en nuestra área es algo realmente bajo.

Demasiado técnicos para pensar en otra cosa.

Las novedades tecnologías las da la industria, todos saben que surgió un Windows 10, que Apple saco un nuevo dispositivo, que Oracle tiene una nueva base de datos, que hay un nuevo procesador, pero nos olvidamos del quien.

El área se encuentra muy deshumanizada, todos sabemos quien es Steve Jobs y Bill Gates, pero nos olvidamos de todos aquellos que han hecho algún aporte a el área y que nos han llevado a donde estamos.

Peor aun hay quienes escuchan Premios Turing y no saben que es eso, siendo que es el mayor galardón que se puede obtener en ciencias de la computación, un premio al que se le ha llamado el Nobel de la computación.

El premio Turing lo entrega ACM (Association for Computing Machinery)desde 1966 en New York y año con año reconoce a aquellos que han hecho grandes aportaciones a la industria.

Revisaremos en futuros post de Nuestra historia a cada uno de los premiados por eso mismo omito la lista de ellos en este momento, dejando en el aire lo siguiente, sin las contribuciones de este grupo, muchas de las cosas que haces habitualmente no serian posibles, ellos son los verdaderos forjadores de lo que hoy tenemos, los verdaderos revolucionarios, que entendieron el valor de la información.

Felices lineas

24. FileSystemWatcher (Ayuda Rápida III)

FileSystemWatcher, es un componente muy útil de .NET ya que nos permite el monitoreo de directorios para comprobar uso.

Todo programador debe ser curioso, y esa curiosidad implica el saber cómo funcionan las cosas, por eso también es interesante este método, este nos dice en que momento un archivo se escribe en disco esto nos sirve principalmente para 2 cosas, para construir sistemas que se inicien cuando la escritura ocurra, o para dar seguimiento a procesos que realicen escritura en disco pero que para nosotros sean una caja negra, nos ayuda a hacer un poco de ingeniería inversa…

No es un método perfecto ya que cuenta con 2 problemas que debemos tomar en cuenta durante el diseño.

1.       Si estamos observando un archivo que se encuentra en una unidad de red, y por algún motivo tenemos una intermitencia en la misma, en método se detiene y deja de reportar los cambios.

2.       No podemos iniciar libremente una cantidad muy grande de objetos (genera problemas de memoria o que no se ejecuten todos los eventos)

Pero una vez considerando estos puntos es una herramienta realmente útil.

El código en cuestión es el siguiente:

¿Qué es lo que hace?

System.IO.FileSystemWatcher se encarga de observar un directorio para que se dispare el evento

Path Nos indica el directorio base que se estará observando

IncludeSubdirectories se emplea para indicar que se observe el directorio raíz y todos sus directorios

NotifyFilter indica en que casos se notificara el acceso al directorio

Changed, Created y Deleted son 3 eventos que se disparan cuando el objeto cambia, se crea o se borra.

EnableRaisingEvents, activa el FilesystemWatcher.

Saludos

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