martes, noviembre 22, 2005

Como reportar problemas

En mi trabajo me toca muy seguido reportar problemas, pero también me toca recibir reportes realizados por otras personas. A veces no es fácil reproducir un problema, por eso es necesario contar con la mayor cantidad de información posible.

Cuando nos encontramos con un problema, lo primero que debemos hacer antes de reportarlo, es asegurarnos que efectivamente es un problema. Puede parecer algo trivial, pero hay algunas cosas que debemos preguntarnos:
  • ¿Estoy haciendo algo mal? Si es posible, tratar de leer la documentación correspondiente y ver si estoy haciendo las cosas de forma correcta. A veces pasa que estoy tratando de usar algo, pero en realidad no se bien como funciona.
  • ¿Es un caso particular o es un problema genérico? Deberíamos probar si el problema se da solo en este caso, o si ocurre también en casos similares.
  • ¿Pasa también en otros equipos, le ocurre a otros usuarios? Algunos problemas dependen de la configuración del PC y es importante saber si esto es así.
Luego de determinar que sí es un problema, debemos reportarlo a quien corresponda. Sin embargo, esta tarea también implica algo de trabajo de nuestra parte:
  • Tratar de aislar el problema. Por lo general la persona que recibe el reporte tiene menos idea del caso particular que se está probando. Es conveniente tratar de aislar lo más posible el problema, para facilitarle la tarea a quien lo tiene que corregir.
  • Explicar lo más claramente posible lo que se está haciendo. Si es un problema que involucra varios pasos, tratar de explicar en detalle, aunque parezca trivial, cada uno de ellos.
  • Dar información de las pruebas que se hicieron, por ejemplo si se probó otro caso similar, si encontré documentación que dice que el funcionamiento debería ser otro, etc.
  • Indicar con que datos estoy probando. Muchas veces los problemas pueden ser errores o inconsistencias en los datos, por lo que es información muy importante.
  • Cualquier otra cosa que se nos ocurra que puede resultar útil (que no por aparecer en el último punto deja de ser importante): una foto de la pantalla, el nombre del programa, los parámetros de configuración del equipo que parezcan relevantes, la base de datos, etc.
Con todos estos pasos, puede parecer algo pesado reportar un problema, y a veces no tenemos el tiempo necesario para hacerlo. Sin embargo, esto no debe verse como trabajo extra sino como una forma de contribuir a que el problema se solucione lo más rápidamente posible.

miércoles, octubre 05, 2005

Profiler de SQL

Hace un tiempo había escrito un artículo sobre el Profiler de SQL Server, en el que se explicaba como utilizar esta herramienta para analizar la necesidad de crear índices para una determinada consulta, utilizando el Index Tunning Wizard.

En ese momento recién lo empezabamos a usar, por lo que no tenía mucha experiencia en ese tema. Después de haberlo usado un tiempo para varias cosas, tenemos un conjunto de tareas en las que resulta muy útil.

Básicamente esta herramienta permite registrar la actividad en la base de datos. Los usos que le estamos dando son:
  • Análisis de programas
    Podemos ver todas las sentencias que se están ejecutando en la base de datos. Además es posible filtrar por varios valores, entre ellos el número de proceso y el identificador de la base de datos.

    Esto nos permite analizar un programa desde otra perspectiva, viendo exáctamente lo que está haciendo en la base de datos.

  • Buscar las consultas que más demoran
    Uno de los datos más útiles que tenemos es la duración que tuvo cada consulta en la ejecución, lo que permite, cuando se están analizando problemas de performance, que nos concentremos en las consultas con mayor duración, que son las primeras candidadtas a analizar.

    Junto con la información de las duraciones, suele ser útil ver también la cantidad de lecturas, escrituras y el uso de CPU de cada consulta.

    Muchas veces al analizar un problema de performance, teníamos que intuir donde estaba el problema, pero con el Profiler podemos estar seguros de que estamos atacando el cuello de botella.

  • Ver los planes de ejecución
    Es posible ver los planes de ejecución de las sentencias, agregando el tipo de evento correspondiente (Excecution plan dentro de Performance).

    Los planes de ejecución también se pueden ver en forma gráfica desde el Query Analizer, pero el que nos muestra el Profiler es el que efectivamente fue utilizado por el DBMS para resolver la consulta.

  • Determinar pérdidas en la integridad transaccional
    Cuando nos encontramos con un programa que perdió la integridad transaccional, porque se está haciendo un commit en alguna parte que no debería, con GeneXus no siempre es fácil determinar donde se produce.

    Con el Profiler, vemos exáctamente donde se hizo el commit, y por lo tanto podemos rastrear a partir de las consultas cual fue el programa que lo hizo.
La información que genera el Profiler, además de poder verse en pantalla se puede guardar a un archivo o a una tabla. El archivo es útil cuando tenemos la salida del Profiler generada por ejemplo en un cliente y la queremos traer para analizar. Guardar los datos como tabla permite hacer consultas sobre la información, para buscar por ejemplo las sentencias que más demoran o las que se ejecutan más veces.

martes, octubre 04, 2005

Principals, Securables, Permissions

En la documentación de SQL Server 2005, se usan frecuentemente los términos "Principals", "Securables" y "Permissions" para expresar aspectos de seguridad de SQL Server 2005. Este artículo describe estos 3 conceptos.

Principals: Es a quien se asignan los permisos ( logins, usuarios, roles, etc )
En el contexto de SQL Server los "Principals" existen en 3 niveles diferentes:
- A nivel del sistema operativo Windows : usuarios(locales y de dominio) y grupos de usuarios
- A nivel de instancia SQL Server: logins (windows y sqlserver logins) y server roles
- A nivel de base de datos: usuarios, roles y roles de aplicación

Securables: Los recursos sobre los que se asigna permisos( bases de datos, tablas, archivos, etc)
Los "Securables" también existen a diferentes niveles:
- A nivel de windows, consisten de a archivos y claves de la registry que usa SQL Server.
- A nivel de SQL Server, están organizados en forma jerárquica:
- El nivel superior es la instancia, en este nivel los "Securables" son logins, http endpoints, bases de datos, etc.
- El siguiente nivel es la base de datos, en este nivel los "Securables" son servicios, assemblies, esquemas, etc.
- El siguiente nivel es el esquema, en este nivel los "Securables" son tablas, vistas, procedures, etc.

Permissions: Son los privilegios que se otorgan a los "Principals" para controlar la acciones que estos pueden realizar sobre los "Securables". ( permisos de write sobre un archivo, delete sobre una tabla, etc )
- A nivel de Windows, se usan ACL's para otorgar o denegar "Permissions"
- A nivel de SQL Server se usan las sentencias GRANT, REVOKE y DENY para otorgar o denegar "Permissions". Los "Permissions" asignados a determinado nivel son heredados de forma implícita en los niveles inferiores. Por ejemplo si a un rol se le asigna permiso de select sobre un esquema, el rol va a tener permisos de select sobre los "Securables" de ese esquema (típicamente tablas)

lunes, septiembre 26, 2005

¿Qué es RSS?

RSS es una sigla que significa Really Simple Syndication. Básicamente es un protocolo basado en XML que permite suscribirse a páginas web, para recibir en un formato similar al correo electrónico las modificaciones realizadas a una página web.

Es una tecnología que se está utilizando mucho sobre todo en los sitios de noticias y en los web logs (Blogs).

Por más información, se puede ver http://en.wikipedia.org/wiki/RSS_Feed.

Se puede obtener una lista de los programas para leer RSS en http://en.wikipedia.org/wiki/List_of_news_aggregators.

viernes, septiembre 23, 2005

Como migrar de Visual FoxPro a Java y no morir en el intento - Charla en XV Encuentro Internacional Genexus

En el mes de setiembre de 2005, se realizó en Montevideo, Uruguay el XV Encuentro Internacional Genexus.

En el mismo dimos junto con Marcos Crispino una charla de como realizamos en 8 meses una migración de Visual FoxPro a Java de 2 aplicaciones de mas de 5000 programas y 500 tablas.

Recomendaciones y tips para:
* Eleccion de la plataforma WIN y WEB.
* Problemas encontrados y soluciones

Contamos las dificultades encontradas en las diferentes etapas del proyecto (desarrollo, testeo, instalacion, ejecucion) y como los hemos solucionado.
* Desarrollos futuros
Migracion a Linux
MySQL/Db2
Tres Capas
GeneXus 9.0

Ver presentacion y video online
Bajar Video

Enrique Almeida
Concepto

¿Vale la Pena el BetaTesting? - Charla en XV Encuentro Internacional GeneXus -

En el mes de setiembre se realizo en Montevideo, Uruguay, el XV Encuentro Internacional GeneXus

Toda empresa tecnológica tiene que destinar parte de sus energías en la investigación de nuevas metodologías y tecnologías. En la charla contaremos la experiencia de Concepto.
Descripción:
El betatesting de aplicaciones y de GeneXus en particular es la mejor forma de adaptar las herramientas a nuestras necesidades. Esta charla es para tratar de incentivar la participación de todas las empresas de la GeneXus Alliance en los procesos de pruebas de herramientas y de intercambio de experiencias .
Muchas veces las empresas de desarrollo de software, se ven en la necesidad de optar entre hacer investigación sobre diversas herramientas o el trabajo del día a día. El betatesting de aplicaciones y de GeneXus en particular es la mejor forma de adaptar las herramientas a nuestras necesidades.Esta charla es para tratar de incentivar la participación de todas las empresas de la GeneXus Alliance en los procesos de pruebas de herramientas y de intercambio de experiencias

Presentación PowerPoint
Ver online video de la Charla
Bajar video de presentación

Enrique Almeida
Concepto

lunes, septiembre 19, 2005

Petroglifo en formato Blog

Desde hoy estamos comenzando a editar el Petroglifo en un nuevo formato.

Los blogs son una tecnología que a esta altura está muy difundida en Internet, y se ha vuelto algo muy común. Mantener el Petroglifo en formato blog nos simplifica bastante el trabajo, además que nos da posibilidades que en el sitio anterior no teníamos.

Por suepuesto, las notas anteriores siguen estando disponibles en http://www.concepto.com.uy/petrocsharp