Tag: software

flops in Matlab

Somebody asked how one may count the number of floating point operations in a MATLAB program.
Prior to version 6, one used to be able to do this with the command flops, but this command is no longer available with the newer versions of MATLAB.
flops is a relic from the LINPACK days of MATLAB (LINPACK has since been replaced by LAPACK). With the use of LAPACK in MATLAB, it will be more approrpiate to use tic andtoc to count elapsed CPU time instead (cf. tic,toc).
If you're interested to know why flops is obsolete, you may wish to read the exchanges in NA digest regarding flops.
Nevertheless, if you feel that you really do need a command to count floating point operations in MATLAB, what you can do is to install Tom Minka's Lightspeed MATLAB toolbox and use the flops counting operations therein.


@cise.ufl.edu>

@cise.ufl.edu>
To count flops, we need to first know what they are.  What is a flop?

LAPACK is not the only place where the question "what is a flop?" is
relevant. Sparse matrix codes are another.  Multifrontal and supernodal
factorization algorithms store L and U (and intermediate submatrices, for
the multifrontal method) as a set of dense submatrices.  It's more
efficient that way, since the dense BLAS can be used within the dense
submatrices.  It is often better explicitly store some of the numerical
zeros, so that one ends up with fewer frontal matrices or supernodes.

So what happens when I compute zero times zero plus zero?  Is that a flop
(or two flops)?  I computed it, so one could argue that it counts.  But it
was useless, so one could argue that it shouldn't count.  Computing it
allowed me to use more BLAS-3, so I get a faster algorithm that happens to
do some useless flops.  How do I compare the "mflop rate" of two
algorithms that make different decisions on what flops to perform and
which of those to include in the "flop count"?

A somewhat better measure would be to compare the two algorithms based an
external count.  For example, the "true" flop counts for sparse LU
factorization can be computed in Matlab from the pattern of L and U as:

        [L,U,P] = lu (A) ;
        Lnz = full (sum (spones (L))) - 1 ;    % off diagonal nz in cols of L
        Unz = full (sum (spones (U')))' - 1 ;  % off diagonal nz in rows of U
        flops = 2*Lnz*Unz + sum (Lnz) ;

The same can be done on the LU factors found by any other factorization
code. This does count a few spurious flops, namely the computation a_ij +
l_ik*u_kj is always counted as two flops, even if a_ij is initially zero.

However, even with this "better" measure, the algorithm that does more
flops can be much faster.  You're better off picking the algorithm with
the smallest memory space requirements (which is not always the smallest
nnz (L+U)) and/or fastest run time.

So my vote is to either leave out the the flop count, or at most return a
reasonable agreed-upon estimate (like the "true flop count" for LU, above)
that is somewhat independent of algorithmic details.  Matrix multiply, for
example, should report 2*n^3, as Cleve states in his Winter 2000
newsletter, even though "better" methods with fewer flops (Strassen's
method) are available.

Tim Davis
University of Florida
davis@cise.ufl.edu@cise.ufl.edu>

ProjectLibre

Project management software has the capacity to help plan, organize, and manage resource pools and develop resource estimates. Depending on the sophistication of the software, it can manage estimation and planning, scheduling, cost control and budget management, resource allocation, collaboration software, communication, decision-making, quality management and documentation or administration systems.[1] Today, numerous PC & browser based project management softwares exist and they are finding their way into almost every type of business.

ProjectLibre

In our interview with Marc O’Brien, co-founder ofProjectLibre, we featured a tool with support for task management, resource allocation, tracking, Gantt charts, and much more. ProjectLibre is a good alternative to a commercial software product like Microsoft Project.

In December 2013, ProjectLibre released version 1.5.8, and a full rewrite of the codebase towards an Open Services Gateway Initiative (OSGI) modular architecture is ongoing. This will allow connector modules for better integration with enterprise solutions such as Enterprise Resource Planning (ERP).

ProjectLibre is a Java based client tool. During their 2014 Q1 this year, they will release version 2.0. It is not clear yet when the SaaS version will become available.

ProjectLibre was awarded InfoWorld’s “Best of Open Source” in 2013 and ranks in my personal top 3 favorite open source project management tools.

Control de versión

Los repositorios administrados de documentos son importantes en el trabajo en equipo cuando varios miembros deben trabajar de manera simultánea o coordinada sobre los mismos documentos, pero también es útil en el caso de lobos solitarios. Control de versión es el arte de administrar cambios. Es una herramienta crítica en el desarrollo de software.

Algunos sistemas de control de versión son administradores de software (Software Configuration Management). Estos sistemas están especí­ficamente diseñados para administrar árboles de código fuente y soportan el ciclo de vida de aplicaciones. Otros sistemas son repositorios generales de documentos.

Un repositorio de información para control de versión guarda un registro de los cambios hechos tanto a los datos como a la estructura misma de archivos. Un cliente puede no solo ver la última versión de los documentos guardados, sino también estados previos del sistema de archivos. Por ejemplo un cliente puede hacer consultas del tipo ¿Qué cambios se hicieron en un documento en la última semana?

El problema fundamental es por un lado ¿Cómo compartir información y coordinar modificaciones concurrentes a un grupo de documentos? Y complementariamente ¿Cómo recuperar estados anteriores de los documentos cuando una serie de cambios resultan inapropiados o se requieren variaciones de base común?

Un enfoque para evitar conflictos es reservar-modificar-cambiar (lock-modify-unlock). Este enfoque no siempre garantiza la integridad o coherencia de un sistema cuando se trabaja con múltiples documentos y serializa el trabajo innecesariamente cuando se pudiera hacer cambios independientes. Otro enfoque es copiar-modificar-integrar (copy-modify-merge). El repositorio puede asistir en el manejo de documentos y sus cambios, pero una persona necesita hacer el análisis de si un conjunto de cambios es valido y los miembros de un equipo deben mantener una buena comunicación.

En el caso particular del software algunas de las áreas que soporta un SCM son:

        • Administración de versiones múltiples, permitiendo a usuarios y desarrolladores reportas defectos y cambios con relación a versiones históricas.

       

    • Administración de equipos de desarrollo, permitiendo que varios programadores trabajen en un mismo archivo e integrando los cambios.
    • Auditorias de cambios.

 

Los sistemas de control de versión trabajan con dos elementos base: áreas de trabajo y repositorios. Las áreas de trabajo es donde se hacen cambios y el repositorio es el lugar donde se guardan los documentos de referencia que sincronizan el trabajo de todos y define el estado de la información. El repositorio guarda metadata que permite rastrear cambios y versiones.
El paradigma central de control de versión es Pedir/Aplicar (check out/commit). Todos los documentos se almacenan en el repositorio. El programador registra una copia en su área de trabajo y procede a aplicar cambios a su copia. Cuando los cambios son estables, se aplican al repositorio de acuerdo a polí­ticas de administración de cambios y resolución de conflictos.

Dos conceptos importantes en la administración de cambios son ramas (branches) y etiquetas (tags). La ramificación del código permite mantener el desarrollo del sistema y liberar versiones de acuerdo a plataformas, características y pruebas; O para pruebas de código experimental. Etiquetas son similares a ramas pero puntos de referencia en la misma línea de desarrollo, no a una variante del mismo.

El abuelito y punto de referencia de los sistemas de control de versión es CVS, referenciado a scripts escritos por Dick Grune y publicados en comp.sources.unix en diciembre de 1986.

Sistemas de control de versión:
CVS
Subversion
Perforce (p4)
BitKeeper
VOODOO Server
ClearCase
RCS (Revision Control System)

Herramientas gratuitas para UML

Existen herramientas gratuitas de buena caliadad para UML. Tanto Netbeans como Eclipse soportan esta funcionalidad con el ciclo completo de desarrollo desde generación de código hasta reingenieria. Esto, claro, si se quiere trabajar en Java. En .Net no he encontrado este grado de funcionalidad en herramientas Open Source. Una opción de bajo costo, relativo a RUP y similares, es Visual UML. Visual Paradigm tiene una edición limitada sin costo, Smart Development Environment Community Edition for Visual Studio.

UML, ejemplo sencillo sobre Modelado de un Proyecto Introducción a UML

Zachman y los seis honestos de Kipling

I keep six honest serving-men

(They taught me all I knew)

Their names are What and Why and When And How and Where and Who

Uno de los dichos de mi buen amigo Ángel es sobre la gracia del gringo, ese gringo mítico de poderes de Comic, para tomar algún concepto del sentido común y convertirlo en un producto mercadeable. Un ejemplo interesante de esto es el marco de Zachman para arquitecturas empresariales. Todo un icono en la comunidad de arquitectura de datos. Se basa en el patrón de analizar problemas con una matriz de puntos a revisar. En el marco de Zachman las columnas corresponden a los seis interrogantes en ingles y las hileras a diferentes roles en el desarrollo de una aplicación empresarial. De este sencillo concepto Zachman desarrolla todo una teoría detallada de cómo documentar y administrar un proyecto de desarrollo de un sistema empresarial basado en un modelo entidad-relación.

WHAT’S WRONG WITH THE ZACHMAN FRAMEWORK? Extending the RUP with the Zachman Framework

Eclipse, herramienta universal – IDE abierto y extensible

Eclipse: una herramienta profesional al alcance de todos Pese a que Eclipse está escrito en su mayor parte en Java (salvo el núcleo) y que su uso más popular sea como un IDE para Java, Eclipse es neutral y adaptable a cualquier tipo de lenguaje, por ejemplo C/C++, Cobol, C#, XML, etc. La característica clave de Eclipse es la extensibilidad. Eclipse es una gran estructura formada por un núcleo y muchos plug-ins que van conformando la funcionalidad final. La forma en que los plug-ins interactúan es mediante interfaces o puntos de extensión; así, las nuevas aportaciones se integran sin dificultad ni conflictos.

Eclipse fue producto de una inversión de cuarenta millones de dólares de IBM en su desarrollo antes de ofrecerlo como un producto de código abierto al consorcio Eclipse.org que estaba compuesto inicialmente por Borland e IBM. IBM sigue dirigiendo el desarrollo de Eclipse a través de su subsidiaria OTI (Object Technologies International), creadora de Eclipse. OTI fue adquirida por IBM en 1996 y se consolidó como gran empresa de desarrollo de herramientas orientadas a objeto (O.O.) desde la popularidad del lenguaje Smalltalk. OTI era la división de IBM en la que se generaron los productos Visual Age, que marcaron el estándar de las herramientas de desarrollo Orientado a objetos. Muchos conceptos pioneros en Smalltalk fueron aplicados en Java, creando Visual Age for Java (VA4J). VA4J fue escrito en Smalltalk. Eclipse es una reescritura de VA4J en Java. La base para Eclipse es la Plataforma de cliente enriquecido (del Inglés Rich Client Platform RCP). Los siguientes componentes constituyen la plataforma de cliente enriquecido:

Plataforma principal – inicio de Eclipse, ejecución de plugins OSGi – una plataforma para integrar distribuciones. El Standard Widget Toolkit (SWT) – Un widget toolkit portable. JFace – manejo de archivos, manejo de texto, editores de texto El Workbench de Eclipse – vistas, editores, perspectivas, asistentes

Los widgets de Eclipse están implementados por un herramienta de widget para Java llamada SWT, a diferencia de la mayoría de las aplicaciones Java, que usan las opciones estándar Abstract Window Toolkit (AWT) o Swing. La interfaz de usuario de Eclipse también tiene una capa GUI intermedia llamada JFace, la cual simplifica la construcción de aplicaciones basada en SWT. El entorno integrado de desarrollo (IDE) de Eclipse emplea módulos (plug-in) para proporcionar toda su funcionalidad al frente de la plataforma de cliente rico, a diferencia de otros entornos monolí­ticos donde las funcionalidades están todas incluidas, las necesite el usuario o no. Este mecanismo de módulos es una plataforma ligera para componentes de software. Se provee soporte para Java y CVS en el SDK de Eclipse. En cuanto a las aplicaciones clientes, eclipse provee al programador con frameworks muy ricos para el desarrollo de aplicaciones gráficas, definición y manipulación de modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework – Framework para la edición gráfica) es un plugin de eclipse para el desarrollo de editores visuales que pueden ir desde procesadores de texto wysiwyg hasta editores de diagramas UML, interfaces gráficas para el usuario (GUI), etc. El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un IDE con un compilador de Java interno y un modelo completo de los archivos fuente de Java. Esto permite técnicas avanzadas de refactorización y análisis de código. El IDE también hace uso de un espacio de trabajo, en este caso un grupo de metadata en un espacio para archivos plano, permitiendo modificaciones externas a los archivos en tanto se refresque el espacio de trabajo correspondiente. Núcleo: su tarea es determinar cuales son los plug-ins disponibles en el directorio de plug-ins de Eclipse. Cada plug-in tiene un fichero XML manifest que lista los elementos que necesita de otros plug-ins así­ como los puntos de extensión que ofrece. Como la cantidad de plug-ins puede ser muy grande, solo se cargan los necesarios en el momento de ser utilizados con el objeto de minimizar el tiempo de arranque de Eclipse y recursos. Entorno de trabajo: maneja los recursos del usuario, organizados en uno o más proyectos. Cada proyecto corresponde a un directorio en el directorio de trabajo de Eclipse, y contienen archivos y carpetas. Interfaz de usuario: muestra los menús y herramientas, y se organiza en perspectivas que configuran los editores de código y las vistas. A diferencia de muchas aplicaciones escritas en Java, Eclipse tiene el aspecto y se comporta como una aplicación nativa. Esta programada SWT (Standard Widget Toolkit) y Jface (juego de herramientas construida sobre SWT), que emula los gráficos nativos de cada sistema operativo. Este ha sido un aspecto discutido sobre Eclipse, porque SWT debe ser portada a cada sistema operativo para interactuar con el sistema gráfico. En los proyectos de Java puede usarse AWT y Swing salvo cuando se desarrolle un plug-in para Eclipse. Para descargar Eclipse existen distribuciones con diferentes combinaciones de plug-ins dependiendo del uso que se le quiera dar a la herramienta. Un problema que se presenta con estas distribuciones es que en Windows XP el descompresor integrado a veces falla y es preferible usar un programa externo como 7-zip, WinZIP, o info-zip

subversion

¿Qué es Subversion?

Subversion es un sistema de control de versiones libre y de código fuente abierto. Es decir, Subversion maneja ficheros y directorios a través del tiempo. Hay un Árbol de archivos en un repositorio central. El repositorio es como un servidor de archivos ordinario, excepto que recuerda todos los cambios hechos a sus archivos y directorios. Esto permite recuperar versiones antiguas de datos o examinar el historial de cambios de los mismos. En este aspecto, mucha gente piensa en los sistemas de versiones como en una especie de máquina del tiempo.

Subversion proporciona:

Versionado de directorios
CVS solamente lleva el historial de archivos individuales, pero Subversion implementa un sistema de archivos versionado virtual que sigue los cambios sobre árboles de directorios completos a través del tiempo. Ambos, archivos y directorios, se encuentran bajo el control de versiones.
Verdadero historial de versiones
CVS está limitado al versionado de archivos. Operaciones como copiar y renombrar, las cuales pueden ocurrir sobre archivos, pero realmente son cambios al contenido del directorio en el que se encuentran, no son soportadas por CVS. Adicionalmente, en CVS no puede reemplazar un archivo versionado con algo nuevo que lleve el mismo nombre sin que el nuevo elemento herede el historial del archivo antiguo que quizás sea completamente distinto al anterior. Con Subversion, se puede añadir, borrar, copiar, y renombrar archivos y directorios. Cada fichero nuevo añadido comienza con un historial nuevo, limpio y completamente suyo.
Envíos atómicos
Una colección cualquiera de modificaciones o bien entra por completo al repositorio, o bien no lo hace en absoluto. Ésto permite a los desarrolladores construir y enviar los cambios como fragmentos lógicos e impide que ocurran problemas cuando sólo una parte de los cambios enviados lo hace con éxito.
Versionado de metadatos
Cada archivo o directorio tiene un conjunto de propiedades claves y sus valores asociado. Se puede crear y almacenar cualquier par arbitrario de clave/valor. Las propiedades son versionadas a través del tiempo, al igual que el contenido de los ficheros.
Elección de las capas de red
Subversion tiene una noción abstracta del acceso al repositorio, facilitando a las personas implementar nuevos mecanismos de red. Subversion puede conectarse al servidor HTTP Apache como un módulo de extensión. Ésto proporciona a Subversion una gran ventaja en estabilidad e interoperabilidad, y acceso instantáneo a las caracterí­sticas existentes que ofrece este servidor: autenticación, autorización, compresión de la conexión, etcétera. También tiene disponible un servidor de Subversion independiente, y más ligero. Este servidor habla un protocolo propio, el cual puede ser encaminado fácilmente a través de un túnel SSH.
La versión de default trabaja con apache 2.0 pero es posible bajar un versión para apache 2.2.4
Manipulación consistente de datos
Subversion expresa las diferencias del archivo usando un algoritmo de diferenciación binario, que funciona idénticamente con ficheros de texto (legibles para humanos) y ficheros binarios (ilegibles para humanos). Ambos tipos de ficheros son almacenados igualmente comprimidos en el repositorio, y las diferencias son transmitidas en ambas direcciones a través de la red.
Ramificación y etiquetado eficientes
El coste de ramificación y etiquetado no necesita ser proporcional al tamaño del proyecto. Subversion crea ramas y etiquetas simplemente copiando el proyecto, usando un mecanismo similar al enlace duro. De este modo estas operaciones toman solamente una cantidad de tiempo pequeña y constante.

Subversion almacena todos los datos versionados en un repositorio central. TortoiseSvn is un proyecto hermano que proporciona integración con Windows explorer. Vea Capítulo 6, Configuración del servidor para aprender acerca de los diferentes tipos de procesos servidor disponibles y cómo configurarlos. svnserver puede correr como un servicio de Windows. Para crear el servicio http://svn.haxx.se/dev/archive-2006-11/0348.shtmlhttp://httpd.apache.org/download.cgi

http://svnbook.red-bean.com/en/1.0/ch06s03.html

http://svn.collab.net/repos/svn/trunk/notes/windows-service.txt

Clear code that works

A partir de una visión clara e intima del proceso de desarrollo de software, Kent Beck a creado un enfoque metodológico que  a primera vista pareciera contra intuitivo pero que ha resultado exitoso y ampliamente aceptado en la comunidad de programadores.

En Test Driven Development: By Example (Addison-Wesley Signature Series), el libro seminal de TDD, Beck aplica el refrán de divide y vencerás al precepto de calidad en la producción de código:  Clear code that works.

Beck propone contracorriente que es posible separar las consideraciones de calidad de código, desde la perspectiva de ingeniería de software, de la verificación de la funcionalidad, y que el primer paso en cada iteración del proceso de desarrollo es definir y aplicar las pruebas de funcionalidad.

Beck utiliza un proceso de refactorización para pasar de código funcional a código limpio, utilizando la eliminación de redundancia o duplicidad  como guía metodológica.

Haciendo una analogía con un semáforo,  Beck describe un proceso iterativo de 3 pasos:

  1. Rojo. Empezar con una prueba que debe fallar, tal ves ni compilar siquiera.
  2. Verde. Hacer que el código pase la prueba de la manera más expedita y simple, sin consideración alguna a normas y patrones de calidad de código.
  3. Refactorizar. Eliminar redundancia en código, pruebas, y datos.

De tan sencillo enfoque Beck elabora la metodología de desarrollo dirigido por pruebas.

eXtreme Programming

Uno de los problemas fundamentales con las metodologías de desarrollo, de hecho, con cualquier esfuerzo de normalizar un proceso entre personas, es que el deber ser en un sentido moral idealista obscurece el es. eXtreme Programming es un enfoque contra intuitivo para aumentar la productividad de los programadores.

A pesar de los esfuerzos heroicos del equipo de mercadotecnia y de la necesidad de los usuarios de mantener los costos bajos, un programador es productivo alrededor de 2 a 4 horas diarias en promedio. Un monstro en el closet pero una realidad. Esto anuado al hecho de la programación es una arte en al que unos pocos virtuosos pueden realizarla con soltura, 5% de los programadores (o menos) hacen 95% del trabajo (o más). Por eso los beneficios de programación en pares en realidad no implican un costo en productividad. Antes al contrario, probablemente un equipo de 2 de programadores trabajando bajo el esquema de programación extrema sea 2 a 3 veces más productivo que los mismos programadores trabajando de manera aislada.

El énfasis en diseño y pruebas es simplemente una realidad del ciclo de desarrollo:

  • Un defecto en codificación es un defecto, aunque corregirlo puede generar más defectos.
  • Un error en la fase de diseño produce más de 10 defectos en código
  • Un error en la fase de levantamiento de requerimientos produce más de 100 defectos en código

Por eso el esfuerzo de desarrollo debe concentrarse en el análisis y realizar iteraciones cortas donde rápidamente la funcionalidad del sistema sea aparente al usuario final y este pueda dar la retroalimentación necesaria para mantener las cosas en la dirección correcta de manera eficaz.

El esfuerzo de desarrollo debe seguir aproximadamente la siguiente ponderación:

  • 40 % análisis y diseño
  • 5 % codificación
  • 30 % pruebas y soporte
  • 25 % más análisis, diseño, pruebas.

Referencias

diagrama xtrem programming

Technorati Tags: ,,,,,,,,,,,,,,,