Mostrando las entradas con la etiqueta codigo. Mostrar todas las entradas
Mostrando las entradas con la etiqueta codigo. Mostrar todas las entradas

lunes, 7 de diciembre de 2015

32. Build 2016

La tecnología avanza día a día, y es muy importante conocer los nuevos retos y conocer las nuevas herramientas que tenemos para poderla usar a nuestro beneficio.

Microsoft anuncia el día de hoy la fecha del Build 2016, el máximo evento de esa empresa para los desarrolladores.

El evento sea en San Francisco del 30 de Marzo al 1 de Abril, no importa que no puedan asistir en forma presencial, este evento se trasmite en tiempo real por diversos canales, les dejo la pagina de dicho evento.


Felices lineas

jueves, 3 de diciembre de 2015

30. Usabilidad

Como técnicos perdemos rápidamente la vista del usuario, a veces pensamos que el sistema debe tener un comportamiento y que el usuario se debe adaptar al sistema.

No debemos perder algo de vista que es muy importante en nuestro trabajo, nos debemos al usuario, somos por el usuario, nuestra principal función es hacer que cualquier actividad sea más rápida y sencilla.

Sea análisis de información, sea automatizar un proceso, o una acceso a una base de datos, todas estas tareas siempre deben ser más fáciles de hacer para el usuario que lo que eran antes de que el sistema se implemente.

Debemos hablar su idioma, acercarnos a él para saber que quiere que busca y darle algo de acuerdo a sus necesidades.

Un error muy común es implementar algo, porque sabemos que es bueno o porque lo conocemos y olvidarnos del como el usuario hace sus actividades en el día a día, muchos de los sistemas impuestos, se convierten en un fracaso, porque la imposición genera resistencia.

Si yo obligo a alguien a hacer algo así este sea el mejor sistema lo va a rechazar de manera automática, lo mejor es buscar que la aceptación sede de manera natural.

Me preguntaran ¿Y cómo logro esto? Hay varias formas, la mejor es observar al usuario para determinar sus necesidades, si yo le pregunto al usuario ¿Qué necesitas? Muchas veces no lo sabe, y ¿Por qué no lo sabe? Porque con los medios con los que dispone en la actualidad ya están cubiertas sus necesidades, puede pedir más cosas, pero siempre es mejor involucrarse con las actividades para detectar los puntos de mejora, y buscar que estos se acepten de manera natural.

¿Pero cómo logro que el usuario se sienta cómodo con mi sistema? Jakob Nielsen es uno de los grandes gurús de la usabilidad, él ha establecido 10 principios que deberíamos considerar en todo sistema, estos principios ayudan a que el usuario se sienta cómodo y seguro dentro del sistema, sus principios son:

1.       Visibilidad del estado del sistema: en este punto normalmente fallamos, olvidamos informar que ocurre en el sistema y dejamos que este opere por sí solo, si bien esto es eficiente, hace que el usuario se desespere, no sabe que está pasando, peor aún puede pensar que está generando errores, que se trabo, el no informar el estado del sistema trae como consecuencia frustración, y como consecuencia nuestro sistema no será exitoso.

2.       Relación entre el sistema y el mundo real: Es muy importante tener el mismo vocabulario, que el sistema hable el vocabulario del usuario en sus términos y conceptos, que todo esté acorde a lo que el usuario conozca, y que el sistema no se convierta en tener un ente que requiera un traductor para su operación.

3.       Control y libertad del usuario: Funciones de deshacer y rehacer, que pasa si el usuario entro a una función a la que no quería por error, su proceso para salir de ella debe ser sencillo, no debería perderse en un mundo de menús, para deshacer un error.

4.       Consistencia y estándares: ¿Cuáles son los estándares del usuario? El debería entender el sistema por que el sistema habla su idioma.

5.       Prevención de errores: Un error común prevenir errores es enviar mensajes de error, esto no es la prevención de errores, un mensaje de error debe ser nuestra última opción, en muchos casos los sistema envían mensajes de error cuando ya no se puede hacer nada, y el proceso para recuperarse de ellos es largo y costoso, los sistemas deben tener un control de errores, para evitarlos, que no sea enviar un mensaje de error.

6.       Reconocimiento antes que recuerdo: El usuario no debe saberse los procesos de memoria, si se depende de la memoria para que estos se ejecuten en un orden correcto, es probable que se induzca error por parte de la misma operación del sistema, el usuario debería reconocer los pasos y actividades a realizar, y estos deben ser accesibles para el usuario todo el tiempo.

7.       Flexibilidad y eficiencia de uso: Hay varios tipos de usuarios, avanzados y básicos se debe brindar al usuario avanzado aceleradores y métodos para que este pueda mejorar la eficiencia de su trabajo, por dar un ejemplo de esto tenemos las combinaciones de teclas.

8.       Estética y diseño minimalista: Cada unidad extra de información irrelevante compite con la información relevante, se debe brindar únicamente la información importante, para que el usuario pueda interpretarla y entenderla.

9.       Ayuda a los usuarios a reconocer: Otro punto muy importante, que en la mayoría de los sistemas no se hace, cuando ocurre un error este se debe presentar en un lenguaje claro y simple, que indique el problema en forma precisa y ayude a construir su solución. El mensaje muy típico en los sistemas “Error fatal, consulte a su administrador del sistema” no es un error que cumpla con estas características, y menos cuando dicho error le da al administrador del sistema.

10.   Ayuda y documentación: Mas vale la más pálida tinta que la más brillante memoria, hoy conocemos el sistema pero que tan en 5 años cuando lo volvemos a ver, lo que para unos es lógico para otros no lo será, debemos dejar de pensar que un sistema se puede emplear con sentido común, dicen que el sentido común es el menos común de todos los sentidos, por esto hay que documentar, crear ayudas ¿Cómo trabaja?, ¿Cuáles son las reglas de negocio?  ¿Cómo se configura?, si soy un nuevo usuario ¿Cómo voy a usar el sistema?, cometemos un error muy grave aquí los desarrolladores, decimos es que el usuario no lee, si no lee los manuales para que los hago, no es lo mismo el que no los lea, pero que en caso de una duda pueda recurrir a ellos, a que en caso de una duda no exista nada a donde recurrir.

Bueno me despido por hoy, felices líneas


Carlos

martes, 1 de diciembre de 2015

27. Parpadeo en DataGridView (Ayuda Rápida IV)

Un problema muy común al momento de usar un DataGridView dentro de un winForm es el molesto parpadeo que se da cada vez que se cargan los datos, esto ocurre sobre todo en casos en que la información que se encuentra en la tabla se encuentra actualizándose de manera continua.

La solución a este problema es muy sencilla, y analizando el código parecería que nosotros causaríamos parpadeo al implementar esta solución pero esto no es cierto, lo que se debe hace es ocultar el DataGridView, cargar este elemento con la nueva información y volverlo a mostrar.

Al cargar el control sin que este se muestre, la carga de sus columnas es muy rápida, por lo que el parpadeo que provocamos al ocultarlo y mostrar el control se vuelve imperceptible, eliminando de esta forma el molesto parpadeo que se da en este tipo de controles.

 dgVisor.Hide();
 dgVisor.DataSource = [Datos];
 dgVisor.Refresh();
 dgVisor.Show();


Felices lineas

martes, 13 de octubre de 2015

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

viernes, 25 de septiembre de 2015

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

jueves, 24 de septiembre de 2015

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

martes, 8 de septiembre de 2015

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

lunes, 20 de julio de 2015

7. Programar en paralelo (I)

A partir de .Net 4.0 llego a su madures la programación en paralelo por .net, la posibilidad de efectuar múltiples operaciones en forma simultánea con la finalidad de reducir tiempos, y emplear mejor los recursos de sistema.

El nuevo modelo nos permite emplear de forma simultanea los núcleos del procesador, anteriormente se requería un manejo a un nivel más bajo para lograr que las tareas se distribuyeran en forma paralela, hoy esto no es necesario.

Pero antes de considerar el uso de las funciones de .Net para programar en paralelo tenemos que hacer unas consideraciones.

¿Cuáles serán los recursos en los que se empleara la programación en paralelo?

Al emplear este tipo de programación se debe considerar que si el recurso no soporta cierta cantidad de peticiones, el rendimiento en vez de incrementarse puede verse afectado, esto es por ejemplo mandar un gran número de peticiones a una base de datos, o escritura a un disco.

¿Realmente será perceptible el cambio?

Si la cantidad de peticiones es tal que al emplear este tipo de programación se vea un cambio perceptible en el rendimiento, hay que usarla, pero si el cambio no es perceptible, no es conveniente incrementar la complejidad del código.

Bueno y como se emplea, el modelo más sencillo de programación en paralelo es la invocación de más de una función en el mismo instante de tiempo.

Para ello emplearemos Task Parallel Library, esta se encuentra dentro del espacio de nombres System.Threading.Tasks.
 
Y su invocación es tan sencilla como:
 
Parallel.Invoke(() => Tarea1(), () => Tarea2());
 
Lo mas interesante de esto es que podemos enviar la cantidad de tareas en paralelo que deseemos
 
Parallel.Invoke(() => Tarea1(), () => Tarea2(), ()=> … TareaN());
 
Sin embrago siempre estamos limitados por los recursos del equipo, un gran número de proceso paralelos puede tener como consecuencia que el sistema baje su rendimiento.

Otro punto muy importante, por lo regular los equipos productivos tienen una potencia mucho mayor que los equipos de desarrollo, por tal motivo cuando se construye un proceso en paralelo se debe tener esto en mente.


Hasta la próxima semana.

jueves, 9 de julio de 2015

6. Pensamiento Mágico, ayuda divina

Una actividad interesante, que debería desaparecer de nuestra mente, es emplear el pensamiento mágico de que solo se va a arreglar algo, si se arregla solo es que hay algo mal, algo esta tan inestable que el solo volverlo a hacer hace que funcione.

¿A qué se debe ese pensamiento mágico?, podríamos adjudicarlo a muchas cosas desde la inseguridad de que los pasos que se efectuaron son los correctos o la falta de conocimiento sobre cómo opera una aplicación.

Qué caso tiene hacer 100 veces la misma operación esperando que por pura casualidad en la 97 funcione, la computadora sigue una serie de pasos, específicos que no debería cambiar por ejecutar nuevamente una operación.

Pero, ¿Qué pasa si esto ocurre?, entonces no es que el programa se arreglara por sí solo, lo más probable es que exista un problema en la inicialización de algún objeto.

Ahora me dirán, es que la primera vez fallo, pero luego continuo, en este caso puede ser algún archivo temporal que sea necesario para que opere su programa.

Es común que digan reinicia y funciona, y esto en muchos de los casos es cierto, pero si esto ocurre realmente de lo que hablamos es de una inestabilidad del sistema operativo.

Es importante entender que nada se soluciona por arte de magia y menos en un mundo en el que todo se reduce a bits, a unos y ceros, en donde sí a la computadora se le dice enciende, esta enciende, 

Cuando un sistema esta inestable se debe hacer un análisis completo, de que estamos haciendo, cual es el flujo que sigue, esto nos ayudara a tener una mayor calidad en nuestros programas.

Hay que ser curiosos y no confiar en la solución mágica.


Hasta pronto

viernes, 3 de julio de 2015

5. Herramientas - Mi propio NuGet



Divide y vencerás es una frase muy común en muchos de los entornos en los que nos desarrollamos, y en el software es algo que tiene una gran verdad, el hecho de que yo trabaje con componentes altamente especializados me ayuda a erradicar rápidamente errores y nos permite que el código sea altamente reutilizable.

Uno de los grandes problemas que ha existido a través del tiempo es como organizo mis versiones de código, para que de una manera sencilla los cambios en estos módulos especializados puedan llegar a los proyectos de mayor tamaño.

Bueno ante esto podemos hacer uso de la herramienta de administración de Paquetes llamada NuGet, NuGet es un administrador de paquetes de código abierto que trabaja sobre Visual Studio a partir de la versión 2010.

¿Qué tipos de archivos podemos poner en nuestra solución?

Prácticamente cualquier tipo de archivo, incluso en diferentes versiones de Framework dándole la posibilidad de emplear la dll en múltiples proyectos.

NuGet me permite que yo publique en la red mis dll pero también las puedo publicar en una red local, dentro de una carpeta compartida y que las consuman dentro de mi organización.
Para ello tengo que hacer lo siguiente:

1.       Descargar el NuGet Package Explorer desde la siguiente ruta:  https://npe.codeplex.com/, esta herramienta me permite generar los packetes de NuGet

2.       Al abrirlo me muestra esta pantalla:


3.       Se selecciona Create a new package

4.       Esto nos muestra la siguiente pantalla



5.       Se debe seleccionar el botón edición para editar las características del paquete


6.       Agrega la o las dll al proyecto



7.       Selecciona guardar como… y guarda este módulo en la carpeta que en que se creara tu NuGet personal.




8.       Ahora es necesario que visual studio conozca la ruta, inicia Visual Studio

Ve a Herramientas -> Administración de paquetes NuGet -> Configuración del administrador de paquetes.




9.       Y una vez dentro se selecciona la ruta en donde se encuentra nuestro paquete.



10.   Cuando buscamos el paquete este ya lo podemos usar en todos nuestros proyectos, es muy importante que se maneje el número de versión cada vez que se tengan nuevos dll ya que de esta manera NuGet tendrá la forma de asignar la nueva versión




Nos leemos pronto

miércoles, 1 de julio de 2015

4. Patrones de diseño

Un código bien diseñado, puede ser reusado con facilidad en otros proyectos,  adaptado para necesidades futuras y este operara de una manera correcta.

Pero que pasa en la programación salvaje, muchos códigos se diseñan para cumplir con un cliente específico, se tiene miedo a reutilizarlos porque se teme a que en algún momento se modifiquen y se pierda la funcionalidad original, el componente pertenece a otro más grande y reutilizarlo llega a ser complicado por el nivel de acoplamiento entre clases.

La gran cantidad de programadores que modifican un código y la poca o nula capacitación hace que cada uno de ellos implemente en sus proyectos funciones que anteriormente ya se implementaron.

Y bueno si supero esos obstáculos ¿Cómo logro hacer un código flexible que pueda emplear en múltiples proyectos y que realmente cumpla con la característica de ser reutilizable?

Un método para lograr esto es la implementación de patrones, por desgracia en .net existe muy poca gente que hace uso de ellos, a veces por tiempo, otras por desconocimiento, o porque en su organización no existen reglas para ello.

Un patrón de diseño es una solución que ya ha sido probada y que cuenta con una efectividad probada.

Así pues desde 1990 se han creado un conjunto de patrones de diseño, que permiten hacer software de mejor calidad.

En ese 1990 se recogieron 23 patrones de diseño estos fueron agrupados en la literatura por Erich Gamma, Richard Helm, Ralph Johnson,y John Vlissides, hoy son el conjunto básico de patrones que deberíamos conocer todos los desarrolladores, estos 23 patrones se dividieron en 3 grupos creacionales, estructurales y de comportamiento.

Existen 7 patrones estructurales que son:


  • ·         Decorator
  • ·         Proxy
  • ·         Bridge
  • ·         Composite
  • ·         Flyweight
  • ·         Adapter
  • ·         Facade

Existen 5 patrones creacionales


  • ·         Prototype
  • ·         Factory Method
  • ·         Singleton
  • ·         Abstract Factory
  • ·         Builder

Y existen 11 patrones de comportamiento


  • ·         Strategy
  • ·         State
  • ·         Template Method
  • ·         Chain of Responsibility
  • ·         Command
  • ·         Iterator
  • ·         Mediator
  • ·         Observer
  • ·         Visitor
  • ·         Interpreter
  • ·         Memento

La calidad que se obtiene en un código de programación mejora cuando el desarrollador ocupa dichos patrones, ya que con esto se logra una verdadera estandarización en la codificación, y con ello acabaremos con esa programación salvaje.


jueves, 25 de junio de 2015

3. Desarrollando

De qué trata todo esto, todo esto surge de una inquietud, la inquietud de ver que muchos profesionales del cómputo se encasillan en solo hacer ABC, la inquietud de ver que todo mundo sabe programar pero solo conoce las estructuras básicas, la inquietud de ver que el tiempo pasa hay grandes logros pero en mi impresión nos estamos quedando cortos.

Tenemos el acceso a la información, pero la empleamos con fuerza bruta, ya no la depuramos, podemos construir grandes cosas pero en vez de ahorrar recursos construimos torres con más piezas de las necesarias.

Estamos cayendo en un exceso de confianza, en una facilidad por hacer entregas rápidas, a fin de cuentas si no es lo suficiente mente rápido, con más potencia al equipo con eso basta.

Hay exceso de metodologías tratando de solucionar las crisis del desarrollo, de cómputo, viendo el desarrollo desde muchos puntos de vista.

Hay otras que tratan de hacer que gente que no es de computo entienda los procesos, y buscando que las TI trabajen como una fábrica del siglo pasado.

Calidad, rapidez, costos, son palabras que están en nuestro vocabulario todos los días, sin embargo en muchos casos parece que no las entendemos.

Este blog tocara varios puntos, comentarios sobre algún tema normalmente enfocados al desarrollo, claro estos desde el punto de vista de un desarrollador más.

Técnicas y metodologías para mejorar nuestro código pienso empezar con patrones y anti patrones de diseño.

Y bueno algo que valla más allá de las bases de datos y que mejor que un poco de gráficos y animación, así que trabajaremos en un buen tutorial de DirectX, ya que realmente hay pocos que enseñen a fondo lo que es, así que hay mucho trabajo por delante.


Si una computadora más pequeña que tu celular llego a la luna, ¿Tu hasta donde podrás llegar?

miércoles, 24 de junio de 2015

2. Optimizar el performance (análisis)


Las 4 tareas de una optimización de performance son:

- Medición
- Diagnósticos de cuellos de botella
- Selección de optimizaciones
- Implementación de las optimizaciones

Nuestra principal herramienta son los contadores de rendimiento, algunas herramientas de desarrollo también nos permiten tomar una imagen de aquello que está ocurriendo en disco memoria y procesador.

Es necesario conocer el tiempo de cada una de las partes del proceso, para poder efectuar un análisis de cada uno de los componentes del mismo.

Se debe tomar en cuenta la velocidad de los componentes, una escritura en disco es más lenta que una escritura en memoria, y la memoria siempre será más lenta que el procesador, peor aún, si vive el almacenamiento en red, si está en la nube, si consume servicios, es necesario identificar en donde se encuentran cada uno de los cuellos de botella.

¿Cómo vamos a optimizar?, podemos iniciar procesos paralelos y aprovechar la capacidad del procesador, si algo se guarda en disco podemos mantenerlo más tiempo en memoria, si tenemos mucha información podemos hacer objetos más ligeros, divide y vencerás, has tareas específicas para que puedan ser medidas e incluso separadas y agrupadas.

Este punto es muy importante, tener cargada solo la información que vamos a emplear, muchas veces por hacer objetos genéricos se carga información que no es necesaria, al final todo esto se traduce en lecturas y escrituras que cuando se habla de grandes cantidades de información pueden representar el colapso del sistema.

Por más que tengamos mucha memoria disponible, hay que pensar que esta no es infinita, liberarla cuando sea necesario, analizar los objetos para determinar cómo se libera la memoria en cada parte del proceso.

¿Los componentes externos responden adecuadamente?, ¿cómo está la velocidad de acceso a discos?, ¿tengo errores?, ¿Se me encolan peticiones?

Hay que ver el sistema como un todo, y este todo abarca el sistema como tal, el sistema operativo, los dispositivos de hardware (tarjetas de red, discos, memoria), bases de datos, los desarrolladores tendemos a cegarnos y pensar que todo está en el código, es muy importante conocer toda la pintura y no solo los personajes que se encuentran en ella.

¿Cómo es nuestro diseño?, hay 2 puntos importantes que muchas veces nos generar grandes problemas de rendimiento y cuellos de botella, y tienen que ver directamente con el diseño.

-Arquitectura
-Frameworks

Porque la arquitectura, la premisa fundamental al construir una arquitectura es que esta deberá ser lo más sencilla posible, ¿Por qué?, porque una arquitectura sencilla es entendible, es fácil de implementar, y es rápida.

Al tener menos capas, la información pasa por menos lugares, cada capa se traduce en tiempo, objetos demasiado genéricos pueden ser muy grandes, o efectuar una gran cantidad de operaciones para llegar al resultado, como consecuencia se pierde el desempeño, crea una arquitectura acorde a tus necesidades, cada sistema es diferente, tiene diferentes requisitos por lo que su arquitectura debe ser diferente.

Frameworks, los frameworks son muy útiles, ya que implementan las mejores prácticas o nos facilitan el trabajo, pero muchos de ellos tienen el gran error que mencione en el punto anterior, objetos demasiado genéricos, objetos que son muy grandes, accesos a memoria para obtener tipos u objetos hacen una gran cantidad de operaciones para estar listos para los diferentes eventos para los que son programados, todo esto reduce el desempeño de tu sistema.

Mientras más cerca estemos del lenguaje maquina más rápido operara el sistema, no digo con esto que empleemos ensamblador en el desarrollo, lo que digo es que hay que buscar emplear funciones nativas del lenguaje, que sean ligeras y que controlemos completamente.

Si cumplimos todo lo anterior, saldremos de esa computación salvaje, en la que dependemos de la velocidad de los procesadores y no de un orden en la programación.

No todo lo que brilla es oro y no todo lo nuevo es lo mejor.

Pero recuerda como diría algún arquitecto de sistemas, todo depende… depende de la situación en la que te encuentres y de que tan alto requieras la optimización de tu código.

Bueno esto solo es un comentario

Carlos


Referencia
                Enhancing Performance Optimization of Multicore/Multichip Nodes with Data Structure Metrics

                Ashay Rane, James Browne

lunes, 22 de junio de 2015

1. Reflexión sobre el papel del Arquitecto

Vivimos una época de cambios, en las que tenemos mucha información al alcance de nuestras manos, mucha más información que en cualquier otra época de la humanidad, el día de hoy es muy fácil creerse experto en uno o varios temas, y sistemas es uno de esos temas en los que existen muchas personas que se consideran expertas en el área.

La computación es fácil, es lógica dicen muchos.

Si hay tantos expertos ¿Por qué hay tantos problemas en los sistemas? ¿Por qué muchos no son exitosos? Y ¿Por qué otros que si tienen cierto éxito se caen en cuanto empiezan a crecer? ¿Por qué antes con equipos menores a lo que es un celular de hoy en día se podía hacer el mismo trabajo de cómputo?, ¿Quién es el responsable?, ¿Qué herramientas tengo?

El mundo de computo cambia muy rápido hace solo unos cuantos años una computadora no tenía más de 4 Megas en RAM, 100 Megas de disco y un procesador de 33 MHz, hoy incluso un celular tiene más poder que eso.

La mayoría de los sistemas no hacen más almacenar información y consultarla, pese a los cambios tecnológicos siguen siendo ABC, si esto es así, ¿no deberíamos ser expertos en ellos?, y ser la mayoría de ellos exitosos.

La respuesta es Sí, entonces ¿Qué es lo que está pasando?

Bueno todo esto puede recaer en un individuo que día a día ha perdido su función, porque cada vez hay más personas que toman ese roll sin saber realmente que es lo que debería de hacer, esto hablando de un Arquitecto de sistemas.

¿Por qué el?, porque él es el principal responsable en la construcción de una aplicación. Él es el que debe conocer el ADN de la aplicación, sin embargo, el arquitecto de sistemas no necesariamente es el mejor desarrollador, o el mejor DBA, tampoco es el genio que vive encerrado en su cubículo y lo ven solo las noches de luna llena.

El arquitecto es aquel, que sabe que es lo que se quiere, que conoce las piezas, que puede defenderlas, que puede armarlas y lo más importante que puede transmitir que es lo que quiere, alguien que puede separar el todo y convertirlo en algo tan abstracto como un programa, sin necesidad de que él lo desarrolle.

Él debe conocer a todos aquellos involucrados en el sistema tener la capacidad para traducir entre diversos idiomas, traducir una imagen que vive en la mente de aquel que desea el sistema en imágenes que puedan servir para que uno o más desarrolladores puedan darle vida a este nuevo ser.


Platiquemos un poco, y veamos una gran analogía, la analogía de la palabra arquitecto, un arquitecto se define según la real academia de la lengua española como la persona que ejerce la arquitectura, y la arquitectura se define como el Arte de proyectar y construir edificios.

Ahí caemos en 2 cosas primero que nada es un Arte, sistemas por si solo es un Arte, es un trabajo que si bien tiene reglas, tiene mejores prácticas, muy pocos realmente las conocen, y aún menos las aplican, de construir edificios, realmente es lo que hacemos nosotros construimos edificios sobre los que circula la información.

Entonces que es un arquitecto, es aquel que es capaz de construir una torre de babel sin que esta colapse en el intento, y lo más importante debe manejar la complejidad nunca incrementarla, el mejor diseño de arquitectura no es aquel que tiene más capas, y que solo es capaz de entender el que lo creo y un grupo de personas cercanas, no el mejor diseño es el que es el más sencillo, aquel que puede entender cualquiera de los desarrolladores que conforman el equipo, y que cumpla con todo aquello que sea necesario en el proyecto.

Sencillez ante todo, el arquitecto no debe demostrar que él sabe lo que otros no saben, por el contrario debe balancear el proyecto para que aquellos que no saben puedan participar en él. No es un dios, es un maestro, no tiene la verdad absoluta, pero debe tener la visión de un todo.


Debe conocer, lo que fue, lo que es y lo que será. Ver el mapa desde arriba, pero poder entrar y revisar un detalle, debe tener ambas visiones la visión macro y la visión micro.

Entonces ¿Quién puede ser un arquitecto?

Aquel que comprenda el proyecto, que conozca, los requerimientos, que sepa quiénes son sus programadores, que pueda balancear sus complejidad, que pueda proponer, que sepa decidir que conviene al proyecto y que no necesariamente escoja lo más reciente en el mercado.

Un maestro, un aprendiz, un director, un escucha y un orador.

Es el papel más complicado en el desarrollo, porque realmente de él depende el éxito o el fracaso.

Imaginen que un arquitecto, que construye un rascacielos, realmente no entendiera el concepto, o ideara algo tan complejo que nadie pudiera construirlo, ¿Qué pasaría? Los proyectos se irían al fracaso, bueno lo mismo ocurre con un arquitecto de software, él debe comprender su verdadera responsabilidad, que no es eso diseñar, sino conocer el todo comprenderlo, transformarlo y obtener el resultado que espera que solicito el proyecto.

No es una tarea fácil, y hacerlo bien mucho menos.

Bueno solo es un comentario...Carlos