Google compro JotSpot

Realmente es una buena compra la que hizo Google porque los productos de JotSpot (http://www.jotspot.com/) , son muy buenos.
Es un wiki, con aplicaciones pre-armadas, para el seguimiento de proyectos, seguimiento de bugs, y varias aplicaciones mas, que son muy buenas (al menos las que pude probar)
Lamentablemente con unas pocas pruebas se supera el limite de paginas que se pueden usar en forma gratuita.

Es un buen complemento a las herramientas de Google y falta ver como logran integrarlas.
Para tener muy en cuenta.

Test de Joel

En joelonsoftware, Joel el autor, planteó (hace bastante) un test que intenta medir que tan maduro es el proceso de desarrollo de software de la empresa/persona.

Una puntuación de 12 es perfecta, 11 es tolerable, pero si has sacado 10 o menos estás en apuros. La verdad es que la mayoría de las empresas de software sacarían un 2 o un 3 y necesitan ayuda porque empresas como Microsoft están funcionando con una puntuación de 12 en todo momento.
Voy a publicar los resultados de mi evaluación en Concepto, aunque los resultados han sido variables cuando lo hacen diferentes personas.

¿Utilizas software de control de versiones?

No utilizamos software de control de versiones en en sentido estricto, pero si tenemos una historia de los cambios que sufre cada uno de los objetos de las KB imortantes. Todas las noches se registra una foto de los objetos cambiados y tenemos una herramienta (KBCVSP - son las siglas de Control de Versiones Sin Pretensiones) que permite guardar el fuente de un objeto modificado en un xml y comparar las diferencias con las anteriores.

Resultado: 1/2

¿Puedes generar el producto en un solo paso?

Para esto tenemos una herramienta que se llama KBFullCycle que sobre GeneXus realiza la mayoria de trabajo para tener algo pronto en el cliente. Se impacta/especifica/genera y compila y tambien genera el help, e informa si hay algun inconveniente. Aun no permite instalar en el ambiente de testeo.

Resultado : 1/2.

¿Compilas el producto diariamente?

Con la herramienta anterior, se corre en forma nocturna y compila los main de una Kb (o varias) e informa cuales son los que tienen problemas.

Resultado: 1

¿Tienes una base de datos para los bugs?

Si, tenemos una base de datos con los errores y se registra cuales son y comos son tratados.

Resultado: 1

¿Corriges los bugs antes de añadir más código?

En este punto, tengo alguna diferencia con Joel, aunque reconozco que los agumentos que esgrime son valederos. No cumplimos con esta regla y ademas muchas veces si agregamos mas codigo, a pesar de tener bugs abiertos. Los errores graves se tratan con prioridad alta, pero no todos los bugs paralizan el resto del codigo.

Resultado=0

¿Tienes una planificación actualizada?

Se hacen planes mensuales y ajustes semanales. Ademas se evalua mensualmente las desviaciones de dichos planes. En este punto creo que estamos bien.

Resultado=1

¿Tienes un documento de especificaciones?

Nuestras especificaciones, si bien existen, son bastante difusas. Hemos mejorado notoriamente en los ultimos tiempos en esto, pero igualmente tenemos cosas por mejorar aun.
Es algo en lo que hay que dedicar mas recursos.

Resultado=0

¿Están los programadores en un lugar tranquilo?

El ambiente de trabajo, es razonablemente tranquilo. La excepcion a esta regla es cuando se realiza alguna instalación grande.

Resultado=1

¿Utilizas las mejores herramientas que puedes comprar?

Usamos Genexus que creo que es la mejor herramienta para el tipo de aplicaciones que escribimos y desarrollamos nuestras propias herramientas para complementarlo.

Resultado=1

¿Tienes gente para probar los productos?

En esta fallamos estrepitosamente. Somos nosotros mismos quienes testeamos la aplicacion, a pesar de cruzar nuestros esfuerzos.

El tema del testeo, es algo que hemos intentado encarar en varias oportunidades, y no hemos podido solucionar en forma satisfactoria. Hemos realizado experimentos (desde tercerizar el testeo, hasta dedicar personas a testear). No nos han dado los resultados deseados.

Resultado=0

¿Haces escribir código a los nuevos candidatos en las entrevistas?

La mayoria de las veces, contratamos gente sin experiencia y los capacitamos, por lo que es dificil hacerlos programar. Nos lleva unos 6 meses capacitar a un estudiante avanzado, para que pueda incorporarse a alguno de los grupos de trabajo. Los resultados han sido muy buenos, por lo que creo que nuestro proceso de seleccion es bastante bueno, o al menos a nosotros nos sirve.

Resultado=0

¿Haces pruebas de usabilidad "de vestíbulo"?

Si, hacemos

Resultado=1

Resultado total: 7 .

Por lo que joel opina, estamos en problemas. :(

En varias de las áreas que tenemos malos puntajes, hemos querido avanzar y mejorar, pero no siempres hemos podido encontrarle la mejor solucion.
Seguiremos intentando :)

Mejorar la performance de una aplicación GeneXus / Sqlserver

La semana pasada un cliente, al cual le habíamos brindado apoyo de consultoría hace unos años, nos pidió ayuda pues tenía una aplicación con problemas de performance.
El proyecto terminó hace mas de de dos años, por lo que si bien conocíamos la aplicación, a la misma le habían realizado varios cambios.

El problema

Una aplicacion generada en GeneXus 8.0, con .NET y SQL Server 2000, con componentes win/2 capas, webservices y páginas web. La cantidad de usuarios, es de unos 400 para la aplicación win y algunos miles para la aplicacion web.
El problema concreto que tenían era una aplicación que recibe mensajes xml en una cola (en realidad utiliza el File System para esto), los procesa y los responde. Este proceso estaba demorando muchísimo cuando recibía mensajes xml de mas de 4Mb, que llegaba a demorar mas de una hora en procesarlos, produciendo atrasos importantísimos en el procesamiento de los mensajes posteriores.

El proceso

Cuento un poco el proceso que seguimos para solucionarlo, pues puede servirle a alguien mas en la comunidad. Antes que me lo reprochen, fue un trabajo en equipo, donde con Ruben, Gabriel, Gustavo y yo.

Tratamos de encarar el problema desde varios puntos en forma simultánea y fue fundamental hacerse algunas preguntas básicas que ayudan a resolverlo.

Las que nos hicimos fueron:

1) Demora solo en xml grandes?
2) Se necesitan xml grandes?
3) Se puede ejecutar en paralelo mas de un proceso?
4) El proceso demora en algun punto en particular?

1) Demora solo en xml grandes?

La respuesta a esta pregunta fue SI.

2) Se necesitan xml grandes?

Rápidamente y conversando con los usuarios funcionales de la aplicación, se vió que no era necesario la utilizacion del nivel de detalle que se estaba utilizando, por lo que se podía reducir muchísimo el tiempo de procesamiento, las necesidades de almacenamiento y el uso de ancho de banda, con una modificación en la forma que se solicitaban los mensajes xml. Este cambio, que no implica cambiar nada en la programacion, es el que puede brindar las mayores mejoras en el mediano plazo.

3) Se puede ejecutar mas de un proceso en paralelo?

Se pusieron a funcionar mas de un proceso procesando los mensajes en paralelo con lo cual, sin hacerle ningun cambio a los programa, se logró bajar el tiempo de respuesta a los mensajes, de una forma muy importante. Lo bueno de este punto, es que agregando mas procesos/hardware, se puede escalar muy bien en la solución.

4) El proceso demora en algun punto en particular?.

Recien en esta etapa, llegamos a ver que es lo necesario cambiar en la programación para lograr mejorar la performance.
Como regla general, cada vez que una aplicación Genexus demora, conviene revisar cuales son las sentencias que esta ejecutando en la base de datos, para ver donde se pueden tener problemas.

4.1) Registrar Sentencias ejecutadas

Para este caso, utilizamos el SQL Server Profiler, que permite capturar las sentencias que se ejecutan en la base de datos. Para esto, tenemos un template definido para java y otro para .NET, donde se capturan datos como

• Sentencia ejecutada
• Cantidad de lecturas
• Cantidad de escrituras
• Duracion en ms
• Cantidad de CPU utilizada

Luego corremos el proceso que se quiere optimizar, con un usuario especifico (y diferente a todos los demas) y nos quedamos unicamente con las sentencias ejecutadas por ese usuario.
Se salva la informacion capturada, en tabla en otra base de datos.

4.2) Detectar sentencias ofensivas

Luego agrupando por la sentencia ejecutada, hacemos agrupaciones y sumas consultando:

• Las diez sentencias ejecutadas mas veces
• Las diez sentencias cuya suma de duracion es mayor
• Las diez sentencias cuya suma de CPU es mayor
• Las diez sentencias cuya suma de lecturas es mayor
• Las diez sentencias cuya suma de escrituras es mayor

Con este proceso (que ya tenemos bastante automatizado) logramos obtener un conjunto mucho mas manejable de puntos donde pueden estar los problemas de performance.
De un conjunto de unas 520.000 sentencias que se ejecutaron, logramos un subconjuto de unas 30 "sentencias ofensivas", que son mucho mas manejable.

4.3) Detectar en que objetos GeneXus se ejecutan dichas sentencias.

Despues esta la tarea (nada facil) de ver en que objetos se ejecutan estas sentencias.
Para esto, lo mejor es utilizar algun buscador de texto (yo uso el Search&Replace) , para buscar en los fuentes generados por Genexus.

En este caso por ejemplo tenemos que encontrar que objeto ejecuta esta sentencia:

"SELECT [SINUME_SERIE], [SICLASE], [PICODI_ADUAN], [PIANO_PRESE], [PINUME_CORRE], [PINRO_SECUE] FROM [SERINC] (NOLOCK) WHERE [SINUME_SERIE] = @P1 ORDER BY [PICODI_ADUAN], [PIANO_PRESE], [PINUME_CORRE], [SINUME_SERIE], [PINRO_SECUE]"

Hay que tener cuidado , pues los parametros en este caso @P1 no estan en el codigo de esta forma, por lo que hay que hacer algunas modificaciones en lo que hay que buscar.

Como regla sencilla, se puede buscar lo que hay hasta el primer parametro

"SELECT [SINUME_SERIE], [SICLASE], [PICODI_ADUAN], [PIANO_PRESE], [PINUME_CORRE], [PINRO_SECUE] FROM [SERINC] (NOLOCK) WHERE [SINUME_SERIE] ="

en todos los fuentes *.CS del directorio del modelo, y no incluir el directorio web (en este caso no estabamos buscando objetos web).

En caso de que devuelva mas de un objeto, hay que estudiar bastante mas los fuentes generados y la logica en GeneXu para entender cual (o cuales ) son los que se estan ejecutando.

4.4) Corregir los Objetos.

Una vez identificado dichos objetos, hay que cambiar la programación para lograr que genere sentencias mas eficientes.

Los problemas que aparecen mas a menudo son:

4.4.1) Sentencias que no le llegan condiciones al Where

Algunas veces pasa que aunque en programa GeneXus diga que tiene un condición, la misma no se pasa al where de la sentencia, sino que se resuelve con un if. En este caso estaba pasando esto, por lo que cuando llegaba un xml con muchos elementos, los mismos se guardaban en la base de datos y luego se recorrian varias veces y una sentencia que debia traer 1 registro, estaba devolviendolos todos (llegue a ver con 8000 registros) y lo filtraba en el programa. Reformulando un poco la condicion del for each, logramos mejorar la performance de esa parte.

4.4.2) Sentencias que estan ordenando en forma innecesaria

Algunas sentencias estaban devolviendo el resultado en forma ordenada, y no era necesrio.

Se les agrego un "order none" y esto mejoró un poquito la performance.

4.4.3) Sentencias que realizan joins complejos

En este caso no se nos presento este problema, pero muchas veces se logran simplifcar joins.

4.4.4) Sentencias que demoran aunque esten bien formadas

En esots casos, paso las sentencias a los DBAs, que hacen sus magias habituales que incluyen

• Estudio de estadisticas de la tablas
• Estudio sobre los histogramas de distribución
• Defragmentación de indices
• Tamaño de tablas
• Definición de indices
• Parametros de la sentencias (tipos de datos)
• Borrar datos innecesarios

4.4.5) Sentencias que se ejecutan muchas veces

Muchas veces estas sentencias son ejecutadas leyendo tablas de parametros o metadatos que varian poco. Habilitando el cache de sentencias, se logran mejoras importantes, se carga menos el servidor de base de datos y ademas el habilitarlo da muy poco trabajo y las mejoras son instantaneas.

4.4.6) Locks y Deadlocks

La explicación de como lidiar con estos problemas, lo dejo para otro post, pues este ya quedó demasiado largo.

Alguien quiere seguirla?.

Esta metodologia ya le hemos usado en varias aplicaciones, y ha dado muy buenos resultado, tanto en aplicaciones java y .NET y con Oracle y SQL Server.

Muchas de estas tareas, pueden servir para muchas plataformas y creo que si alguien se anima se podria armar con algo parecido a un Collaborative Project, para automatizar toda esta metodología y hacer una herramienta similar al Profiler, para todas las plataformas soportadas por GeneXus (procesando el log generado por GeneXus?) y también identificar que objeto GeneXus ejecuta las sentencias.

Faster Development Through Modeling

Estaba leyendo en Dr. Dobb's Journal , un articulo sobre MDA .

En el mismo hacen una referencia al MofEditor, al glorioso INCO de la facultad de Ingenieria de Uruguay, donde supe trabajar. Felicitaciones a los que lo desarrollaron.!!. Siempre es lindo ver que una publicacion de prestigio, hace referencia a productos uruguayos. Seria bueno que en la pagina pusieran el nombre de quienes lo desarrollaron o lo mantienen.

Vi una presentacion sobre este tema cuando estaban comenzando hace unos cuantos años (aun no tenian un producto desarrollado, solo prototipos) y creo ques una buena area de investigación.