Contar Olivos con Ortofoto: Parte I (Algoritmo Secuencial de Etiquetado)

Contar Olivos con Ortofoto: Parte I (Algoritmo Secuencial de Etiquetado)

Introducción

Hace muchos años, trabaje en Tragsatec, donde trabajaba manteniendo el GIS Dinamap. Había una parte del programa que me fascinaba. A partir de una ortofoto de un campo de olivos, Dinamap, contaba los olivos. De esta forma, se podría saber los olivos de un terreno y la subvención correspondiente. De esta forma, se evitaba que una persona, se trasladase al lugar y contarlos.

Siempre me pregunte que tipo de algoritmo se usaba. ¿Como los contaba? Y siempre me quedo esa espinita. Y creo que hoy, poco a poco, me lo voy sacando.

Pero, es lo mismo que contar estrella en una foto, solo que aquí, el fondo es negro y los elementos a contar blancos o más claros.

Mi implementación - Algoritmo Secuencial de Etiquetado

Primeramente, no he implementado todo el proceso, pero si una parte. Los pasos que yo veo para contar olivos, o estrellas...es el siguiente.

1-  Extraer todos los elementos de la imagen sean o no olivos. (Algoritmo Secuencial de Etiquetado)

2. - Determinar si el elemento extraído es un olivo.

En este post se ha implementado la primera parte, extraer todos los elementos de la imagen. Para este proceso se el algoritmo de tipo Algoritmo Secuencial de Etiquetado.

https://en.wikipedia.org/wiki/Connected-component_labeling

Implementación Algoritmo Secuencial de Etiquetado.

Imagen de test.

Dado una imagen en una escala de grises, se transforma esta imagen una matrix nxm donde n es la anchura de la imagen y m la altura de la imagen. Así, obtenemos una imagen donde los ceros, será el fondo de la imagen y los 1s, definiran los elementos contendidos en la imagen.

Aquí se ve como los 1s forman tres figuras, tres circulos. Ahora, con el algoritmo de etiquetado secuencial, se etiqueta cada figura, dando lugar a la extracción de la información de cada figura, lo que ocupa en ancho y algo en la imagen y su etiqueta asociada. Asi, el numero de figuras en la imagen, nos daría el numero de olivos aproximados.l

Aunque, claro, las figuras etiquetadas, pueden ser otra cosa que no sean olivos, como casas, o zonas osucaras de carreteras, y entonces, habría que pasar las matrices que forman las figuras, por otra fase, que detecte que figuras son olivos.

-Determinar si el elemento extraído es un olivo.

Aquí se puede usar redes neuronales la cuales, habrán sido entrenadas para reconocer patrones de imágenes de olivos. Como una imagen de un olivo puede estar en 20x15 pixeles, o en 15x17 pixeles, se realiza una transformación de la imagen a una conocida, por ejemplo a 5x5, Y asi, entrenaremos la red neuronal con imágenes de olivos de 5x5 pixelesy también de no olivos con esta resolución. Y también importante, entrenar a esta red neuronal contra el fraude, por si pusiesen en el campo olivos de cartón para que en la ortofoto se cuente como un olivo. Pero esta parte, ya se realizará en otro post.

CounterOlives

CounterOlives es el programa de testeo para probar la primera fase de esta implantación de contar olivos. 

En este link esta un fichero comprimido con el ejecutable y algunas ortofotos en formato .bmp.

En el siguiente ejemplo, se ve como cuenta como olivos, figuras que no son olivos. Aquí, es donde un segundo algoritmo (redes neuronales por ejemplo) debería de clasificar cada figura y asi contar verdaderamente los olivos que hay en la imagen.

Conclusión

Con unas pocas modificaciones, se podría contar el número de piscinas en un municipio, el numero de estrellas, número de personas en una concentración...lo mismo he pecado de optimista con 'unas pocas modificaciones'..pero se podría intentar.

Noticias relacionadas:

"Google Earth es utilizada para encontrar piscinas ilegales": 
http://www.marketingdirecto.com/actualidad/digital/google-earth-es-utilizada-para-encontrar-piscinas-ilegales/

Redes Bayesianas : Simulación Accidentes petroleros

Introducción

Hace ya un tiempo, en la máquina del café de mi trabajo, charlando, se comento los escenarios de no-masa, es decir, escenarios donde hay muy pocos datos para hacer uso de métodos estadísticos. Por ejemplo, los accidentes de barcos, aviones, cohetes,...

También, quería meterme con este tema de las redes bayesianas, ya que en su día, me metí con los Naives Bayes classifier (clasificador bayesiano ingenuo ¿?)

Entonces, ví que con redes bayesianas se podría simular escenarios de no masa, y escogí el escenario de los accidentes de los petroleros.

Red Bayesiana Accidentes Petroleros

No soy ningun experto en las causas que pueden provocarlos, ni mucho menos la probabilidad de cada uno de ellos, pero aquí está la red que use.

Aquí supuse que el Fuego (Fire) depende de si la tripulación no tiene experiencia, es junior y si el casco es de tipo casco simple.

Después, en daños estructurales (Structural Damage) supuse que si un barca sufre fuertes olas, mayor probabilidad de que sufrir daños, y las fuertes olas (strong swell) dependen de donde este el barco, el que mar u océano esté.

Las tablas de probabilidad para los nodos dependientes fueron:

Simulación

Lanzamos 1000 simulaciones, con una probabilidad baja de tener tripulacion junior y que el barco esté en el océano atlántico y con baja probabilidad que el barco tenga un casco simple.

Esto nos da que el fuego y daños estructurales están a la par, entre 30-40 accidentes.

Cambiamos la probabilidad de la tripulación junior a más alta, esto nos dará más incendios.

Ha subido hasta del orden de 500 incendios.

Aquí se ve, que cambiando las probabilidades, los resultados de la simulación varia. Aquí es donde los expertos en el dominio, en este caso los accidentes de petroleros, deben de crear el modelo con las variables y dependencias adecuadas, y las probabilidades más o menos correctas. Aunque a medida que se van conociendo datos, este modelo se actualidad, tanto con variables nuevas como con actualizar las probabilidades.

Conclusión

Aunque este método podría ayudar en este tipo de problemas, no sé si en la comunidad actuarial, al no ser un método estadístico, sería muy aceptado o tendrían sus reticencias. Pero, es aquí donde esta su fortaleza, la información estadística la guarda en las probabilidades dadas por el experto o conjunto de expertos.

Por otra parte, también este tipo de escenarios, se podría resolver con lógica difusa. Como por ejemplo, en un programa que desarrolle que usaba lógica difusa para frenar los coches (como lo hace, salvando las distancias claro, el metro de Japón).

Si te interesa el código fuente, envíame un correo.

Félix Romo

felix.romo.sanchezseco@gmail.com

Threading: Actualizando Winforms

Introducción

Es muy posible que estando en proyecto de gráficos y al inicio de él, las prioridades serán que el gráfico se visualice correctamente en la ventana, con la información correcta, que se pueda manipular el objeto que se saca por pantalla, y dejando otras funcionalidades para la siguiente iteración.

Para ilustrar este post, imaginemos un proyecto software de tipo SIG (Sistema de Información Geográfica) donde hay muchas entidades geográficas a visualizar,

tantas, que se almacenan en una base de datos, y solo se pintan las entidades que corresponden con el área que se visualiza en pantalla.

Bien, en un principio...era la nada...luego el big bag..ok..al tema. Se visualizarían las entidades de una región en pantalla, pero luego el usuario, va moviendo esa región, o se aleja, esto generará que haya más entidades de mapa a visualizar, como no están en memoria, se piden a la base de datos,

la base de datos las retorna, y una vez retornadas se invalidará (Invalidate()) la ventana para que se repinte el mapa con la nueva información.

Threading

Entonces, llega el cliente o jefe..en fin un stakeholder del proyecto y dice:

"¿Y no se puede dibujar las entidades a la vez que las va leyendo de la base de datos?". Y en ese momento, empieza la cabeza a meterse en el código y ver que modificaciones habría que hacer, cual sería el nivel del impacto, y el resultado al cabo de un segundo es.."uff..no es inmediato..".

Solución

En el pequeño ejemplo que me he inventado, parece muy simple, pero cuando estas en un proyecto real, las cosas no son tan simples, pero hay que intentar reducir la complejidad al mínimo posible.

Aquí se ha intentado reducir la complejidad o ocultarla en la clase BackgroundPainter, que su responsabilidad sería la de leer de la base de datos, y pintar las entidades del mapa leídas, además de añadirlas al mapa. Aunque el leer de la base de datos estarías en la clase EntitiesDDBB y el dibujar en las clases hijas de MapEntity. Es decir que BackgroundPainter sería una clase controlador.

Se ha derivado de la clase BackgroundWorker, para de estar forma hacer la concurrencia más fácil, ya que cuando se termina de pintar todas, se lanzará

el evento RunWorkerCompleted, donde se invalidará la ventana y se repintará con la nueva información.

Se sobreescribe el método OnDoWork para que en este método se haga el trabajo de obtener las entidades de base de datos, añadir al mapa y dibujarlas.

En la aplicación, el botón "Get entities from DDBB", simula que el usuario a cambiado de región o alguna circunstancia que haga que se tenga que cargar nuevas entidades de base de datos. 

Se puede ver mientras se pinta las entidades, como se puede interactuar con el UI:

El código fuente se puede descargar aquí.

Conclusión

Habrá mucha soluciones, pero esta me ha parecido curiosa por el hecho de crear una clase que derive de BackgroundWorker y así, crear un worker en background donde ocultar

la complejidad de la aplicación y no llevar esta complejidad en MainForm.cs o en otra clase existente. He incluso para complicarlos más, esta clase BackgroundPainter podría recuperar

la textura del terreno en background con otro thread.

Testear El Interfaz Usuario

Testear El Interfaz Usuario

Introducción

El Visual Studio ofrece un framework muy bueno para testear las clases del dominio del problema. Y todas o casi todas las clases que no tienen relación con el interfaz de usuario.

La cosa cambia, cuando se quiere testear el interfaz de usuario, ya que, el software también habría que testearlo en su capa de interfaz. Una modificación en la capa de negocio, puede afectar a como se presentan los datos en el interfaz.

En su día, empece a investigar como crear test de interfaz de usuario con el visual studio 2010 y cuando ya tenía unos cuantos definidos, al día siguiente al correrlos, me fallaban los test y no había realizado ningún cambio, y yo veía que tenían que pasar, ya que lo estaba viendo en el interfaz. Daba excepciones al leer de una celda de un grid, al realizar un click en un menú..y claro..no pasaba el test.

Por ejemplo, si tenemos una aplicación que realiza un calculo, además de los test que comprueba que el algoritmo de calculo es correcto y arroja los resultados esperados, estos resultados se verán luego en pantalla de alguna forma, en forma de grid, gráfico,..y es aquí donde interviene los test de intefaz de usuario.

Aunque en un principio pueda parecer un gasto de tiempo, estos test te aseguran una alta calidad, y sobre todo, te evitan el bug más tonto ante una o varias modificaciones.

Estos test de interfaz de usuario, incluso tiene una variante, que es, cuando tienes un software que lee ficheros en un determinado formato propio, y este formato va variando con el tiempo para ajustarse a los nuevos requisitos de usuario, y la aplicación debe leer cualquier versión del formato, se puede crear un test para leer todos los ficheros de entrada que hay en un directorio y comprobar que todos se cargan bien, y se visualizan correctamente en la interfaz de usuario. Esto me ha pasado en un proyecto y se detectaron más de 50 ficheros antiguos que no se cargaban bien. Ahora, cualquier modificación en el formato, se pasa un directorio donde están todas las versiones de los ficheros y comprueba que se cargan en la aplicación más de 100 ficheros de diferentes versiones. De esta forma, automáticamente se comprueba la carga de todas las versiones de ficheros existentes con el consiguiente ahorro de tiempo y mejora en la calidad del producto.

Mini Framework Test

He cogido un pequeño proyecto que desarrolle para crearme mi vocabulario en ingles y así, no anotarme en un cuaderno, dos o tres veces la misma palabra, que era el problema que tenía. Además, de poder exportar a un fichero cada Topic e imprimirlo o meterlo en el móvil para repasar, pero bueno, este es otro tema.

Para testear myVocabulary, añadí el proyecto 'testerUI', este proyecto es una aplicación de consola, que tiene una referencia a myVocabulary para que pueda crear la ventana principal, el MainForm, y así poder testear el interfaz.

La chicha está en la clase 'TesterAgent'. Esta clase, a través de reflexión que proporciona .Net, recoge todas las clases que se han definido en el proyecto 'testerUI' con el atributo [TestClassUI]. Y una vez que tiene la lista de todos los tipos, crea cada instancia y va llamando a cada método público, que es al final, la ejecución de un test de interfaz de usuario.

Cada método público recibe como parámetro un objeto de tipo MainForm, para poder llamar a sus métodos y simular la interacción del usuario. Aquí, estos métodos públicos, deben llamar al objeto MainForm con el Invoke, ya que como el test se está ejecutando en un Thread que no es el thread de interfaz de usuario.

Ejemplo:

/// <summary>
        /// testNumberTopicsAndWords_OnFile
        ///
        /// Testea la carga del fichero
        /// </summary>
        /// <param name="mainForm"></param>
        public void testNumberTopicsAndWords_OnFile(MainForm mainForm)
        {
            int numberOftopics =0;
            int numberOfWordsOnTopics = 0;
            string solutionPath = TestDirectory.GetSolutionPath();
            string fullTestFileName = solutionPath + @"\testerUI\TestFiles\myVocabularyTest.xml";
            mainForm.Invoke((MethodInvoker)delegate
            {
                mainForm.openVocabularyXML(fullTestFileName);
                numberOftopics  = mainForm.GetNumberOfTopicsInUI();
                mainForm.SelectTopicUI("Adverbs");
                numberOfWordsOnTopics = mainForm.GetNumberOfWordsOnRightView();
            }
            );
            if (numberOftopics != 1)
            {
                String sError = "Numero de Topics incorrecto en el xml";
                throw new TestException(sError);
            }
            if (numberOfWordsOnTopics != 3)
            {
                String sError = "Numero incorrecto de palabras";
                throw new TestException(sError);
            }
        }

En el test se ve como se llama a openVocabularyXML, a SelectTopicUI, dentro del Invoke, y es que estos métodos, interinamente llaman a controles del interfaz de usuario. Y por eso necesitan ser llamados desde Invoke.

Luego, se obtienen los datos que se quieren testear, en este caso, el número de Topics que se cargo en el árbol del interfaz de usuario, y el numero de palabra que hay en el listview de la parte derecha del interfaz de usuario.

Corremos el proyecto 'testerUI', se ejecutaran los test, y nos mostrará lo siguiente.

En la pantalla, está el resultado del ultimo test, que comprobaba que al seleccionar la palabra whereabouts en el listview, se mostraba en la ventana de detalle, el significado correcto de la palabra, donde, - paradero,...

TestingProject

Este proyecto es un proyecto normal de test que genera el visual estudio que normalmente se usa, por lo menos de momento yo, para testear la capa de negocio. Pero, hay algunas veces, dependiendo del tipo de test y de los tipos de controles a testear en la interfaz de usuario que se puede testear desde este tipo de proyectos.

Por ejemplo, vemos en TestingProject una clase de test que se llama LoadFileTest, que contiene dos test:

testNumberTopicsAndWords_OnFile
testTextOfMeaningOfaWord

Bien, el test testNumberTopicsAndWords_OnFile, funciona bien, pasa el test, pero el otro test testTextOfMeaningOfaWord, no funciona por que no se da la cascada de eventos que se tiene que dar para pasar el test. Y esto es por que el interfaz de usuario no es visible. En estos casos, estos test que necesitan una secuencia de eventos igual que como si estuviera visible al interfaz de usuario, se pasaría el test al proyecto 'testerUI'.

Conclusión

Dejo aquí el código fuente de todo, ya que será más auto explicativo que dos páginas escritas. 

El crear test de interfaz de usuario para cubrir todo el interfaz llevaría mucho tiempo, pero creo que si se crean test para cubrir partes del interfaz de usuario donde se cree que puede ser la principal fuente de bugs, o que debe ser la parte mejor testeada, puede ser de gran utilidad. Por ejemplo, si estamos desarrollando una aplicación que visualiza una onda en una gráfica, se generaría una onda conocida, y luego comprobar que la gráfica tiene los puntos en las coordenadas esperadas.

También este tipo de test, permite detectar cierres inesperados de la aplicación rápidamente, sobre todo, si el programa permite la carga de fichero, y isa dada una lista de ficheros, cárgalos y comprobar que no...estalla...el programa al cargarlos.

Félix Romo

felix.romo.sanchezseco@gmail.com

Desarrollo Software Futuro (+5 años)

Desarrollo Software Futuro (+5 años)

Introducción

En este post, me voy a poner la gorra de Nostradamus, y mi bola de cristal..virtual claro, pensar un poco como será el desarrollo de software en el futuro. ¿Y para qué? el futuro vendrá cuando vendrá y cuando venga ya no será futuro sino presente. Pero creo que si levantamos la vista y miramos a años vista sobre el futuro desarrollo, lo mismo encontramos algo que nos interese entrar en ese campo y nos llene más, o algo más practico, estar mejor posicionado para encontrar trabajo en el futuro.

Nos montamos en el Delorean, fijamos año 2020, y en el año 2020, si el de arriba quiere, veremos cuan errados estábamos, aunque lo mismo alguna cosa ya existe.

2020

- Electrodomesticos:

Ya la tv y el telefono son smart. Y por inercia, la lavadora, frigorífico y lavavajillas también serán smart. Es decir, llevaran androi. Tienen funciones ya muy avanzadas, como por ejemplo, un modelo de lavavajillas que ví que media la suciedad del agua que pasaba por abajo para ajustar los tiempos, y ahorrar agua.
Pero de momento, estos programas vienen de fábrica. Pero lo mismo, en el 2020, tendrán un puerto USB, una pantalla táctil, y poder instalar el programa de lavadora que te has programado o te has descargado. Aunque según escribo esto, veo que ya hay una que va por ese camino. Lo que pasa que el software es el de la casa,..claro.

Esto me lleva a pensar, que un salto de gigante que al igual que hubo una explosión de ofertas de desarrolladores para smart phones, el día que exista otro dispositivo distinto al smart phone y que contenga un sistema operativo, habrá otra explosión de ofertas de empleo para eso tipo.

¿Y que dispositivos podrían ser? Drones

- Drones

Los drones cuando se ven por la tv, parece que son juguetes para mayores, pero no. Solo basta echar un vistazo a lo siguiente:

- Global Hawk: aquí si que se puede ver su tamaño en comparativa.

https://www.youtube.com/watch?v=IiGnaqouUfA

- Drone para la infanteria: con este casi si que pudiera parecer un juguete..

https://www.youtube.com/watch?v=X0xI4EbKUXs

- Estudiantes de la EETAC y la ETSEIAT construyen un 'drone' para salvar rinocerontes y elefantes de la caza furtiva en África

http://www.upc.edu/saladepremsa/al-dia/mes-noticies/estudiantes-de-la-upc-construyen-un-drone-para-salvar-rinocerontes-y-elefantes-de-la-caza-furtiva-en-africa

- Drones construyendo colaborativamente:
https://www.youtube.com/watch?v=xvN9Ri1GmuY



Y eso es solo un ejemplo, pero se puede aplicar muchas cosas. Por ejemplo:
- Vigilar los bosques españoles (y del Mundo vale..). Unos drones con camaras termicas, detectores de humo, y esos drones colaborando entre sí.

¿Qué los bosques son muy amplios? se le puede meter un mini motor a reacción

- Ayudar en buscar desaparecidos en montañas. Otra vez, drones colaborativos.

- Ayudar en vigilancia de costas.

¿Pero como podría afectar en el desarrollo de sofware?

El día que estos aparatos tengan un sistema operativo como Androi para los smart phones, habrá empresas que buscarán programadores para desarrollar aplicaciones para drones. Un ejemplo, hace tiempo trabaje en un GIS, donde este GIS, con las fotos aéreas recibidas de los campos de los olivos, contaba automáticamente los olivos. Pero estas fotos eran realizadas desde aviones, claro, pero..¿y un dron que se dedique ha hacer ortofotos de una región? más barato!.


Por lo que he visto, hay de momento:
- AR.Drone: su sdk para manejar el drone está en linux y windows. Su alcanze está limitado al alcanze de la wifi, pero para experimentar puede estar muy bien.


- Airware: parece que apostando por crear un S.O. con todos los dispositivos que se puedan conectar a su S.O. (en vez de teclados, cámaras, sensores,...) y ofreciendo una API para desarrollar aplicaciones a las necesidades del cliente.

Creo que está dando sus primeros pasos, y poco a poco se están viendo las posibilidades de los drones. Pero cuando sea relativamente fácil, programar sobre el S.O. que lleva el dron y probar. Habrá más proyectos con drones. Supongo que tendrán que ofrecer de alguna forma el S.O. gratuito  para que más desarrollen la investigen, prueben y programen..adquieran experiencia sobre ella, y luego, dejar pagar a la empresas por ello.

Realidad Virtual

Allá por los años 90s (me encanto la película "El cortador de césped", estaba en auge la realidad virtual , que luego cayo casi en el olvido, pero de nuevo se empieza a mirar a ella. Yo creo que por que se ha reducido el coste de los dispositivos.

Ya en otro blog que tengo, escribí (allá por el año 2005) varios post sobre como la realidad virtual podría ser usada para terapias de reducción de la ansiedad y del miedo. Y al reducir el coste de los dispositivos, y poder usarse en un ordenador personal, se podría instalar en cualquier consulta.
Otras aplicaciones como ayudar a hablar en público.

Para quién ya quiera picar algo:

Virtual Reality in the .Net Framework, Part 1:

Conclusión

Pero..¿que habrá en infojobs en el 2020? 

- Habrá más ofertas de desarrolladores para androi, ya que no serán solo los smartphones y las tables quién use este sistema operativo, sino que habrá otros dispositivos que lo usen.

- Habrá más desarrolladores que trabajen como freelances. Creo que las causas pueden ser evitar los atascos, trabajar desde casa, ser uno su propio jefe, ...etc, etc,..y lo mismo tiene éxito por que los clientes al contratar la persona, saben que esa persona va a desarrollar el trabajo. Una de las pegas que veo es que el cliente tema que al cabo del tiempo, no tendrá soporte, pero ahí están los contratos...

- Habrá más profesores de informática, o mejor dicho, profesionales que se pasen a la enseñanza, ya que demandará profesores especializados en diferencias campos del desarrollo de software.

happy coding...

Félix Romo

felix.romo.sanchezseco@gmail.com

Analisis de Rendimiento

Analisis de Rendimiento

Introducción

Empiezas un proyecto y empiezas a aplicar todo lo que has aprendido en la universidad y en los libros, blogs, consejos que has ido leyendo e intentar aplicar toda la ingeniera del software al nuevo desarrollo. Te creas tus diagramas de clases, secuencia, estás un minutos o más pensando que nombre dar a una clase, y las relaciones entre ellas.

Un mes despues..

Han surgido nuevos requisitos que estaban ocultos, otros se han derivado en otros requisitos y los jefes quieren ver resultados.  ¿Solucion? tiras lineas de código a casco porro, y a usar el copy&paste más que nunca (esto ya debería ser una señal de aviso..que algo no va bien). Sacas una versión, y los testeadores y usuarios: "esto parece que va más lento.."

Efectivamente, se ha dedicado el tiempo a tirar lineas de código y a sacar funcionalidad, sin reparar en el rendimiento de la aplicación.

Creo que durante todas las fases del desarrollo hay que parar de tirar lineas de código y mirar como va el rendimiento de la aplicación. El Visual Studio ofrece mucha información, que la verdad, uno casi se pierde entre tanta información. Y con este post, intentaré que me sirva para tener una especie de protocolo para cuando quiere hacer dicho analisis seguir esos pasos y hacerlo de la manera más efectiva. También, entender un poco más el tema del rendimiento.

Para ver el tema de rendimiento, me he creado un pequeño programa que genera 1000 primitivas, y según está generando las primitivas de la lotería, va dibujando la frecuencia de cada numero en la ventana. Y final de la simulación, se ve una casi distribución uniforme.

Así uno puede ver si tienes mucho histórico sobre las primitivas, la probabilidad se parece y si una tiene poco histórico, casi no tienes patrones para hacer cálculos y jugar a la Primitiva. En fin, en su día incorpore a un programa a la posición del Sol y de la Luna por los efectos gravitacionales sobre las bolas del bombo, pero nada...las variables a tomar en cuenta sin inmensas..pero bueno, nos entretenemos pensando en como...pero bueno, vamos al grano...

Variables

Hay muchas páginas que hablan sobre las variables, a si que, no voy enumerarlas, solo voy a comentar lo que me parecen y así, entenderlas mejor.

El método  public List<Primitive> Generate(int numberOfPrimis, onPrimitiveGenerated handle) es el método donde empieza a ejecutar todo. Y este método tarda alrededor de 7.062 milisegundos.

Lanzamos el profiler en modo "intrumentalización".

Paso 1:
Ponemos Current view a "Funtions"

Paso 2:
Ordenamos los resultados por la la columna "Funtion Name". Aquí algunos dirán por alguna columna donde están los resultados de los tiempos, pero como me quiero centrar solo en los tiempos de las funciones que he creado, lo ordeno por los nombres (seguro que hay una manera de filtrar, pero aún la desconozco).

Paso 3:

Buscamos la función que tenga el tiempo "Elapsed Inclusive Time", y este tiempo es el de la función
primiLotto.Kernel.PrimitivesGenerator.Generate(int32,class primiLotto.Kernel.onPrimitiveGenerated)

y sus tiempos en el profiler es de:

6.991,38(Elapsed Time Inclusive)

que, casualmente es muy parecido a con el otro tiempo calculado por el Stopwatch de 7062mseg.

Entonces, ya tenemos una correlacion. El "Elapsed Time Inclusive" mide el tiempo dentro de una función y también el tiempo de las funciones a las que llama. Es decir, el tiempo total, desde que se inicia hasta que termina.

De aquí, vamos a ver si derivamos el significado de las demás variables.

"Elapsed Exclusive Time" en el ejemplo para el método Generate es de 0.59 mseg. ¿como es posible?? esta variable lo que mide es el tiempo que es ha ejecutado el método, sin incluir las funciones hijas. Es como si cuando se llama a una función hija (en este caso por ejemplo al método generatePrimi ) es como si se parase el cronometro y a la vuelta de la función, se pone de nuevo el cronometro.

Entonces, el método que tenga mayor "Elapsed Exclusive Time" es la que me va a decir, que función esta siendo un cuello de botella.

Si ahora nos fijamos en que función tiene mayor ""Elapsed Exclusive Time" , esta es:

Y la función es drawProbability con un tiempo de 23.77mseg. Pero ojo!, hay si tiempo "Elapsed Inclusive Time", es de 1042.92, con lo cual, hay hay 'algo' en la función, que la hace ir más lenta.

Pero vamos a ver que nos dice el Visual Studio, generando el el árbol con las llamadas más costosas.

Nos dice el VS que el cuello de botella está en efectivamente en drawProbability . Y las llamadas a la API del GDI+ es lo que le está haciendo ir más lento. Mirando el código se ve que en cada iteración del bucle, se crea Pen y Brush que se puede crear al principio, ahorrando la creación de estos objetos 49 veces.

Optimizando

Creando los objetos Pen y Brush fuera del bucle en el método drawProbability , en tiempo "Elapsed Time Inclusive" es de 6564 msg.

7062 - 6564 = 498 msg ahora más rápido para 1000 simulaciones.

Truquito

Una de las cosas que se podría hacer para detectar a tiempo que una función está tardando mucho es por poner lo siguiente

public void DoSameThink()

{

    Stopwatch stopwatch = new Stopwatch();

            stopwatch.Start();

  //codigo de la función

//...............................

//...............................

    stopwatch.Stop();

Debug.Assert(stopwatch.ElapsedMilliseconds < 1000, "El método DoSameThink ha superado 1 segundo");

}

ejemplo:

Conclusión No he contado nada que este escrito por otros blogs, libros, pero a mí me ha servido para asimiliar mejor el tema del rendimiento, de como analizar y ver los cuellos de botella. Si tu también estabas en ese caso y te ha ayudado, estupendo!!! Como se ve, hay muchas variables que da el visual studio que aquí no se han nombrado, pero ya con estas dos variables que hemos nombrado, podemos mejorar algo el rendimiento de nuestro código. El código fuente por está aquí por alguien quiere bajarlo y trastear con ello modificandolo. En próximas, a ver si me adentro más en este campo. Félix Romo felix.romo.sanchezseco@gmail.com

Como construir un control Acordeon (Accordion control)

Como construir un control Acordeon (Accordion control c#)

Introducción

A lo largo del desarrollo de un proyecto, van surgiendo nuevos requisitos, o normalmente, son ampliaciones de los requisitos existentes. También por esto, es muy conveniente, antes de escribir código, contar hasta diez, es decir, diseñar, hasta que el diseño sea estable y pueda soportar los requisitos presentes y los posibles futuros (también hay que diseñar para estos). Aunque claro, muchos jefes, verán este trabajo como no productivo por que no hay lineas de código escritas, pero puede ahorrar días e incluso meses, a lo largo de la vida del código. Pero en fin, esto es otra historia...

Algo que me paso en un proyecto. Había que mostrar unos resultados de datos en una ventana provenientes de unos cálculos, podrían ser un resultado o muchos, y luego también añadir más resultados o borrar resultados que no interesaban. Aquí estime que uno de los controles que podrían encajar era de tipo acordeón.

Estupendo, ya tengo la idea que tendrá la vista, la diseño a portaminas y folio, y aquí que vemos que .Net no tiene un control de acordeón. Entonces, investigando por la red, para ver otros desarrolladores lo hacían. Me encontré con varios ejemplos, pero quería desarrollar el mío propio y así, ya tendríamos el control total sobre este control por si la vista necesitaba algo adicional que no tuviesen los demás controles.

Al lío..

Una de las fuentes en las que me base para construir el mío fue este:

http://sourceforge.net/projects/accordion/

Y empecé a investigar como estaba diseñado, una vez que capte la idea general, empeze a desarrollar el mío propio.

Las clases principales son:
Accordion: es la clase que representa el control..claro..

CheckBox: es una clase de .Net que aquí se usa como control que cuando se hace click, se oculta o aparece el control que hay debajo de este.
Control2: es una clase que une los objetos CheckBox y FLP.
FLP: es un clase que representa un FlowLayoutPanel. Mejor dicho deriva. Y es quién controla, cuando aparece un control o se oculta.

A partir de esta idea, empeze a desarrolar mi acordeón....

Mi Accordion Control

ownAccordion: clase que representa al control acordeón.
TitleControl: clase que representa el control que se va a quedar como cabezera de los controles que se añadan. Aquí se usa un usercontrol y asi poder añadir botones. En este caso, '+' y '-' para asi, añadir más controles al propio acordeón o borrarlos directamente.
myFLP: es la clase que deriva de un FlowLayoutPanel, y controla el añadir o borrar los objetos Control que se añaden al acordeón. En este ejemplo, los objetos ClientDataControl

Sé que le falta mucho a este control para que tenga una buena apariencia, pero creo que la base para seguir desarrollando. Aquí, por ejemplo, en un equipo de desarrollo, este control lo desarrollaría un programador senior, analista/programador, ingeniero software o el mismo jefe de proyecto (los cuales lo desarrollarían no acoplado el proyecto actual, sino de forma que se pueda usar en otros proyectos), y luego pasarlo otro desarrollado para que lo vaya ampliando, y además, aprendiendo. Una forma de ser mentor también.

¿Como queda?

La parte izquierda es de http://sourceforge.net/projects/accordion/

El código fuente se puede descargar de aquí.

Conclusión

Aparte de leer libros, revistas, investigar códificando, probando,..el leer código que hay por la red, intentar desarrollar los mismo, es otra forma de aprender. Y además, te habrá la mente a hacer las cosas de otra manera y lo mismo, más fácil.

Félix Romo

felix.romo.sanchezseco@gmail.com