miércoles, 24 de junio de 2009

Nueva versión de Sonar MetricsAnalytics

Hace unos minutos hemos lanzado una nueva versión de corrección de errores del plugin para Sonar MetricsAnalytics.

Como siempre, puede descargarse desde la página del proyecto en isotrol.org.

miércoles, 10 de junio de 2009

Sonar Metrics Analytics Plugin

Sonar[1] es un sistema para la gestión de la calida del código de los proyectos de desarrollo que, como le gusta decir a uno de los fundadores de SonarSource[2], trata de dar caza a los siete pecados capitales aplicados al código fuente. Pero, hasta ahora, siempre se escapaban un par de ellos, el mal diseño y arquitectura. Hasta ahora porque gracias a Sonar Metrics Analytics Plugin[3], a JDepend[4] y Ckjm[5] están cerca de caer.

El plugin trata de acercar el funcionamiento de XRadar[6] al mundo de Sonar, sin llegar a entrar tan en detalle como sí lo hace él. Esto es así porque el objetivo es otro, dotar de métricas de diseño y arquitectura y buscar un valor (relativamente objetivo) de la calidad del proyecto.

Sonar Metrics Analytics añade nuevos dominios y nuevas métricas a Sonar, y un punto de extensión en el dashboard.


Los dominios "Design" y "Architecture", y las métricas a nivel de clase por ckjm y a nivel de paquete por jdepend. Así, obtenidas a nivel de paquete por jdepend,
  • tc, Number of Classes and Interfaces. Número total de clases concretas y abstractas (e interfaces) en un paquete, como un indicador de la extensibilidad del paquete. Introducido en el dominio "Size".
  • cc, Concrete Class Count. Número de clases concretas (instanciables) en un paquete, introducido en el dominio "Size" de sonar.
  • ac, Abstract Class (and Interface) Count. Número de clases abstractas (e interfaces) en un paquete, introducido en el dominio "Size".
  • ca, Afferent Couplings. El número de otros paquetes que dependen de las clases del paquete, como indicador de su responsabilidad. Introducido en "Architecture".
  • ce, Efferent Couplings. Número de otros paquetes de los que dependen las clases del paquete, como indicador de su independencia. Introducido en "Architecture".
  • a, Abstractness. El porcentaje del número de clases no instanciables frente al total de clases del paquete, donde 0% indica que el paquete es totalmente concreto y el 100% que es completamente abstracto. Introducido en "Architecture".
  • i, Instability. El ratio del acoplamiento eferente frente al acoplamiento total tal que i = ce / (ce + ca). Es un indicador de la resistencia al cambio del paquete donde un 0% indica que es completamente estable y el 100% indica una inestabilidad total. Introducido en el dominio "Architecture".
  • d, Distance from the Main Sequence. Es la distancia de un paquete frente a la línea ideal a + i = 100%, indicando el balance del paquete entre abstracción y estabilidad. Los paquetes "perfectos" son los que son completamente abstractos y estables, y los que son totalmente concretos e inestables. Esta métrica está medida porcentualmente donde 0% indica que el paquete coincide con la línea ideal y el 100% que se encuentra muy retirado. Se incorpora como los anteriores en el dominio de "Architecture".
  • dc, Package Dependency Cycles. Es un valor que indica el número de ciclos en los que se ve implicado el paquete. En cero es el mejor valor posible para esta métrica incluida en "Architecture".

Obtenidas a nivel de clase por ckjm tenemos,
  • dit, Depth of Inheritance Tree. Proporciona una medida de los niveles de herencia (profundidad) desde la raíz de la jerarquía empezando en 1, quedando incluida en el dominio "Design". Cuanto mayor sea el valor peor será el diseño.
  • cbo, Coupling between object classes. Número de clases acopladas a una dada (acoplamiento eferente), y puede darse desde llamadas a métodos, accesos a atributos, herencia, tipos de respuesta, argumentos y excepciones. Incluida en "Design". Cuanto mayor sea el valor peor será el diseño.
  • rfc, Response for a Class. Indica el número de métodos diferentes que pueden ser ejecutados cuando un método del objeto de la clase es invocado. Se incluye en "Design" y cuanto mayor sea su valor peor será el diseño.
  • lcom, Lack of cohesion in methods. Cuenta los conjuntos de métodos que no usan ninguno de sus atributos, debiendo tender a cero para buscar un mejor diseño. Se incluye en el dominio "Design".

Posteriormente, se agregan y combinan dando lugar a, desde el punto de vista de la arquitectura,
  • COH, Cohesion. Número de paquetes con ciclos dividido entre el total. Incluido en "Architecture" a nivel de proyecto. A nivel de paquete también se agrega la métrica pero con dos únicos valores posibles, 0 o 100, donde 0 quiere decir que el paquete tiene ciclos y el 100 que está limpio de ellos.
  • ADI, Distance. Número de paquetes con distancia superior a 20% (este dato es configurable) dividido entre el total de paquetes, a nivel de proyecto. A nivel de paquete se incluye también pero, como en el caso anterior sólo tiene dos valores posibles, 0 que indica que la distancia del paquete es superior a 20 y 100 que indica que es inferior.
  • ARCH, Architecture. El valor medio de las dos métricas de arquitectura (COH y ADI), añadidas a nivel de proyecto y paquetes en el dominio "Architecture".

desde el punto de vista del diseño,
  • NOM, Number of Methods. Controla la complejidad de los métodos y se calcula sumando el número de clases con complejidad por método menor que 20 (este valor es configurable) dividido entre el total de clases de un paquete. A nivel de proyecto se calcula haciendo la media de los NOM de los paquetes, y se añade en "Design".
  • RFC, Response for Class. Número de clases de un paquete con rfc menor que 50 (este valor es configurable) dividido entre el total de clases del paquete. A nivel de proyecto se calcula haciendo la media de los paquetes. Incluido en "Design".
  • CBO, Coupling Between Objects. Número de clases con cbo menor que 5 (valor configurable) dividido entre el total de clases (todas del paquete). Como en los anteriores a nivel de proyecto se calcula con la media, y se incluye en "Design".
  • DIT, Depth of Inheritance Tree. Se calcula contando las clases con dit inferior a 5 (valor configurable) dividido entre el total de clases del paquete. Para los proyectos el cálculo se realiza haciendo la media de los DITs de sus paquetes. Se incluye en "Design".
  • DESIGN, Design. Se obtiene sumando el 20% de NOM, más el 30% de RFC, más el 30% de CBO, más el 20% de DIT, tanto en paquetes como en proyectos, y se incluye en "Design".

desde el punto de vista de las pruebas,
  • COVERAGE, Code coverage by unit tests. Tomado directamente de las métricas del core de Sonar.

desde el punto de vista del código,


  • DOC, Documentation. Se obtiene multiplicado por 10/4 el valor de la métrica de Sonar Documentation (%). Incluida en "Documentation" tanto a nivel de paquete como a nivel de proyecto.
  • DRY, Dryness. Es el inverso del % de líneas duplicadas, a nivel de paquete y proyecto, e incluyendolo en el dominio "Size".
  • RULES, Rules compliance. Tomado directamente de las métricas del core de Sonar.
  • CODE, Code Quality. Se obtiene sumando el 15% de DOC, más el 40% de DRY, y el 45% de RULES, tanto en paquetes como en proyectos, y se incluye en "Rules"

por último, la calidad total,
  • TQ, Total Quality. Se obtiene haciendo la media de los valores obtenidos en arquitectura, diseño, pruebas, y código, tanto en proyectos como en paquetes. Incluido en el dominio "General".


Permite configurar desde la administración, como se ha comentado, los siguientes valores,
  • cota para el cálculo de ADI.
  • cota para el cálculo de NOM.
  • cota para el cálculo de RFC.
  • cota para el cálculo de CBO.
  • cota para el cálculo de DIT.

Y por cierto andaluces, ya está en Madeja[7].

Uso e Instalación [8]
- Descargar el jar [9]
- Copiarlo en el directorio /extensions/plugins/ y reiniciar el servidor. Si has construido el war tendrás que volver a hacerlo cada vez que instales un nuevo plguin.
- Lanzar un nuevo análisis y las métricas empezará a entrar.

Temas pendientes y para futuras versiones,
- Una página de resumen más completa usando un punto de extensión de página.
- Gráfico de distribución de las distancias de los paquetes.
- Ampliación de las métricas de Arquitectura.
- Ampliación de las métricas de Pruebas Unitarias y de Integración.

El equipo que ha dedicado Isotrol, SA[10] para el desarrollo del plugin,
- Nicolas Bertet, responsable funcional.
- Emilio Escobar Reyero, responsable técnico.

Enlaces
[1] http://sonar.codehaus.org
[2] http://www.sonarsource.com
[3] http://redmine.isotrol.org/projects/show/org00003-mtrcsnlytcs
[4] http://clarkware.com/software/JDepend.html
[5] http://www.spinellis.gr/sw/ckjm/
[6] http://xradar.sourceforge.net/
[7] http://www.juntadeandalucia.es/xwiki/bin/view/MADEJADGIAP/VerRecursoSonar
[8] http://docs.codehaus.org/display/SONAR/Install+a+new+plugin
[9] http://redmine.isotrol.org/wiki/org00003-mtrcsnlytcs/Downloads
[10] http://www.isotrol.com
[11] http://www.isotrol.org

martes, 9 de junio de 2009

Hard Reset en Omnia

Sencillo,

1. Presiona el pulsador del soft reset con un lápiz.

2. Presiona los botones de colgar y llamar a la vez cuando veas en la pantalla de inicio

3. Ya tienes la pantalla de opciones de reset.


Con esto no borras nada de la memoria de 8GB, para hacer eso debes ir a las opciones de configuración del teléfono.

lunes, 8 de junio de 2009

Los 8 puntos de mejora del rendimiento

Wille Faler[1] propone en su blog 8 consejos para ayudarte a mejorar el rendimiento y la escalabilidad de tus sistemas, entre los que destacan la descarga de la base de datos, el uso de caché, y minimizar el tráfico de red.
  1. Descargar la base de datos. Mejor cuanto más lejos, no establezcas conexiones ni inicies transacciones a menos que sea estrictamente necesario. Y en los casos que así parezca, intenta buscar una alternativa.
  2. La caché marca la diferencia. Una buena caché descargará en gran medida la carga de la base de datos, especialmente en accesos de sólo lectura. Mejor en memoria que en disco y, aun así, mejor en disco que en una base de datos remota.
  3. Almacena en la caché objetos completos, y recupéralos con sus relaciones. Eso te garantizará disminuir la necesidad de consumo de CPU.
  4. No almacenes información de estado en la base de datos si no es necesario.
  5. Localiza, pon las cosas cerca de quien las necesite.
  6. Controla el acceso concurrente a recursos concretos. Si más de una petición necesita de un mismo cálculo para acceder a un recurso es mejor realizarlo una vez y hacer que las siguientes peticiones esperen para reutilizar los resultados.
  7. Usa procesos asícronos.
  8. Minimiza el tráfico de red ya que las comunicaciones serán mucho peores por red que en memoria.
Todo parece obvio pero no siempre se toman en cuenta, ¿no?


Enlaces

[1] http://faler.wordpress.com/2009/05/08/best-practices-for-scalable-high-performance-systems/