M.F.O.N.D

Genoma - Visualización - UserControl TreeMap

noreply@blogger.com (David Giordano) — Mon, 30 Nov 2009 03:55:00 +0000

Según Wikipedia, Visualización es la generación de una imagen mental o una imagen real de algo abstracto o invisible. http://es.wikipedia.org/wiki/Visualizaci%C3%B3n

Como parte del Proyecto Genoma, tengo la tarea de implementar algunos controles de visualización los cuales serán utilizados en el módulo GenomaServer.
La idea detrás de la creación de estos controles es que sean implementados como User Controls de GeneXus y luego sean liberados para uso de la comunidad (independiente del proyecto Genoma).

La implementación de estos user controls va a tomar su tiempo (aprender actionscript, flash, usercontrols y muchas cosas más), sin embargo para ir dando un adelanto de los avances y de cual es la idea detrás de los controles de visualización del proyecto, les presento una prueba de concepto del control denominado GenomaTreeMap (una implementación de Treemapping)

Tomé información de la KB pública de GXWiki (versión 3.0) en GeneXus Server y calculé la métrica de "cantidad de líneas de código por programa" (sin comentarios ni lineas vacías).

La idea detrás de GenomaServer es que puedan escoger sobre un conjunto variado de medidas y sea posible compararlas entre si de forma visual (las que sean implementadas mediante GenomaExtensions).
Por el momento la más simple de implementar para demostrar algo fue "cantidad de líneas de código", espero pronto mostrarles ejemplos más complejos como los mencionados en el proyecto.

Para ver el ejemplo, simplemente sigan el siguiente link:

Ver GXWiki 3.0 en GenomaTreeMap

Por el momento lo que hay es un poco pobre, espero que de todas formas les guste y les permita comenzar a hacerse de una idea sobre el proyecto Genoma.

UPDATE 30/03/2010:

Se publica versión inicial del User Control GeneXus en gallery.genexus.com

Bajar User Control GenomaTreeMap

Se publica una demo de una versión más avanzada del control.

Ver Ejemplo de GXWiki 3.0 con GenomaTreeMap

Se publica una demo del control con proyectos GXOpen

Ver Ejemplo de GXOpen Projects con GenomaTreeMap

Recursos:

Para finalizar, les dejo un poco de información con referencia sobre visualización.

Visualization of Practices and Metrics
http://www.squale.org/quality-models-site/research-deliverables/WP1.2_Visualization-of-Practices-and-Metrics_v1.pdf

Treemaps for space-constrained visualization of hierarchies
http://www.cs.umd.edu/hcil/treemap-history/

GeneXus - Medición y Análisis de Productos

noreply@blogger.com (David Giordano) — Fri, 27 Nov 2009 20:00:00 +0000

Imagínese que entra en la cabina del piloto de un moderno avión a reacción, y ve que allí hay un único instrumento. ¿qué pensaría usted con respecto a viajar en ese avión?

Pilotear el desarrollo de una aplicación, el apoyo de las herramientas de medición y análisis

Si no se mide lo que se hace, no se puede controlar y si no se puede controlar, no se puede dirigir y si no se puede dirigir no se puede mejorar.

El objetivo de la medición y el análisis es aportar a la empresa herramientas que le ayuden a seguir el camino correcto en búsqueda de su metas y objetivos fijados.

Proceso de medición y análisis

"La medición es el proceso mediante el que se asignan números o símbolos a los atributos de las entidades del mundo real de manera que dichos atributos sean descritos de acuerdo a unas reglas previamente definidas". http://portal.acm.org/citation.cfm?id=580949

El propósito del proceso de medición y análisis es identificar en qué problemas debe enfocarse la empresa, permitiendo definir acciones correctivas, asignando los recursos necesarios que permitan mejorar los procesos. Las mejoras deberán enfocarse en solucionar los problemas de raíz a efectos de mitigar la posibilidad en que los problemas vuelvan a ocurrir.

Las empresas de TI generalmente agrupan las métricas en las siguientes categorías:

Producto físico
Gestión de Proyectos
Desarrollo de Productos
Servicios
Satisfacción del Cliente

Como mencioné en el título del artículo, me voy a enfocar en los puntos asociados al producto (Producto físico y Desarrollo de Productos)

Las métricas que generalmente se definen sobre las agrupaciones anteriormente mencionadas son las siguientes:

Producto físico

Tamaño - Número de componentes, líneas de código, volumen de software, puntos de función
Reutilización - Número de componentes llamados más de n veces, número de llamadas, volumen de reutilización, ratio de reutilización

Desarrollo de Productos

Documentación - Calidad de la documentación del proyecto, calidad de la documentación de soporte.
Calidad de código - Porcentaje de código comentado, complejidad ciclomática, código muerto.
Calidad de pruebas - Cobertura de pruebas, densidad de defectos.

Proceso de medición y análisis; modelos de calidad y estándares

Pueden encontrar mucha más información sobre el proceso de medición y análisis en internet, libros y también en estándares y modelos de madurez (calidad) que actualmente son muy difundidos en el sector de TI.

Les menciono un par que se apoyan fuertemente en el proceso de medición y análisis.: CMMI (CMMI-DEV) e ISO/IEC 15504

Si desarrollo mis sistemas con GeneXus... ¿que herramientas tengo para implementar medición y análisis sobre mis productos?

Las herramientas base para implementar herramientas de medición y análisis existen desde hace ya un tiempo (analizando XPW's,XPZ, GXPublic y más recientemente el SDK de GeneXus X+). Sin embargo no logré localizar ninguna implementación 100% enfocada a la medición y análisis.
Con anterioridad les mencioné un poco lo referente a "Análisis estático de código", en donde localicé varias herramientas asociadas al análisis de código, pero nada muy relacionado a la medición, ni tampoco encontré algún método o base sobre la cual implementar este tipo de herramientas.

Proyecto Genoma (CP 2.0)

Infraestructura para implementar tus propias herramientas de medición y análisis (y mucho +) en GeneXus.

"El objetivo principal del proyecto es implementar la infraestructura necesaria que permita a programadores GeneXus (o programadores de extensiones) desarrollar herramientas de medición, análisis y procesamiento sobre la información contenida en las bases de conocimiento GeneXus."

Me imagino un futuro en el cual el desarrollo de sistemas GeneXus se encuentre guiado por herramientas automáticas, herramientas que te permitan tener acceso a un conjunto de reportes de métricas así como ayudar a detectar puntos en donde realizar mejoras, o listar informes de anomalías o "faltas" a las políticas o guías o simplemente un conjunto de informes con los resultados de las actividades de integración, generación, compilación, pruebas o deploy, los cuales podrían ser ejecutados de forma desatendida o automática.

Por el momento es un proyecto para comenzar a experimentar sobre la marcha, comenzando por algo más modesto, la medición (con algo de análisis), claro que sin dejar la puerta abierta a la posibles extensiones sobre la infraestructura planteada. La idea es ir aprendiendo con cada paso todas las nuevas posibilidades brindadas por las herramientas y tecnologías detrás de GeneXus.

Como siempre, se acepta todo tipo de sugerencias y apoyo, la idea de la herramienta es que sea para uso público (Comunidad GeneXus). Nos queda mucho camino por recorrer :-)

Si les interesa conocer sobre el proyecto Genoma, les dejo algunos links relacionados.

Proyecto Genoma :
http://wiki.gxtechnical.com/commwiki/servlet/hwiki?CP+2.0+-+Proyecto+Genoma,

Entrevista CP2.0 Genoma:
http://www2.gxtechnical.com/portal/hgxpp001.aspx?15,7,3,O,S,0,PAG;CONC;3;14;D;24181;1;PAG;,

Otros Recursos

Quienes quieran conocer más sobre " la cabina de un avión con un único instrumento", les recomiendo leer la introducción del libro "The Balanced Scorecard: Translating streategy into action" de Kaplan y Norton. Pueden leerlo en inglés en Google Books aquí (lamentablemente Google Books no tiene publicada la preview de la edición en español, "Cuadro de mando integral").

Existe una guía en internet que trae un buen resumen sobre medición y análisis. INTECO - Calidad de Software - Guía práctica de medición y análisis.
INTECO (Instituto Nacional de Tecnologías de la Comunicación de España) proporciona un buen catálogo de materiales relacionado a calidad de software. Les recomiendo que vean el listado de guías el cual pueden acceder desde aquí.

Sobre métricas de software, les recomiendo la siguiente presentación: Métricas técnicas de Software es un buen resumen de las métricas más comúnmente utilizadas (No encontré la fuente origen de la misma).
También relacionado a lo mencionado por INTECO y la presentación anterior, les adjunto una presentación en donde presenta "Conceptos básicos, definición y formalización", pueden bajarse la misma desde aquí.

Existe mucho material en internet, pueden encontrar toneladas de información, pero muy pocas "guías prácticas" al respecto, recomiendo lecturas sobre métricas en Wikipedia, libros y pegarle una ojeada a estándares o normas como CMMI e ISO (15504, 9126 y 12.207 entre otros) que generalmente ayudan como guías muy generales sobre el tema (te dicen que cosas tienes que hacer, pero no te dicen exactamente cómo).

GeneXus - Estilo de codificación y refactorización del código fuente

noreply@blogger.com (David Giordano) — Thu, 05 Nov 2009 15:11:00 +0000

En el artículo anterior les comenté un poco sobre "análisis estático de código".

Me quedaron un par de temas pendientes a tratar (si bien los mencioné en la sección de recursos):

Programming style (Estilo de programación o codificación) http://en.wikipedia.org/wiki/Programming_style
Code refactoring (Refactorización de código) http://en.wikipedia.org/wiki/Code_refactoring

¿Cuál es la correlación con análisis estático de código?

Las "guías o reglas de estilo" ayudan a detectar cuales son las infracciones (desviaciones a los estándares definidos).
Y la refactorización del código, permite la corrección automática de esas infracciones.

De esta forma sería posible que una herramienta corrija código aplicando los patrones de estilos, buscando además patrones de código con "malas prácticas" y transformando los mismos en una codificación válida y unificada.

Para que realmente exista utilidad, debería de permitir aplicar diferentes estándares (propios o usar de terceros) y permitir incorporar conocimiento sobre los patrones a identificar (malas prácticas). Todo el proceso de corrección debería de ser efectuado de forma automática o asistida.

Ejemplos prácticos en GeneXus

Marcos Crispino nos comentó (en enero) sobre temas relacionados a Refactoring http://blog.marcoscrispino.com/2009/01/refactoring-de-cdigo-genexus.html

Algo que menciona Marcos, es referente al trabajo realizado por Matias Barrios, sobre el proyecto GxVisualindent (http://www.gxopen.com/gxopen/servlet/projectinformation?755), el cual se encarga de la indentación de código fuente en GeneXus 9.

Luego Matías basándose seguramente en las ideas de Marcos instauró el proyecto RefactorinGX (http://www.gxopen.com/gxopen/servlet/projectinformation?757), el cual implementa métodos que permiten identificar algunos casos, aplicando correcciones o informándolas.

Sin embargo no encontré en la comunidad ejemplos que mezclen los conceptos de "declaración o definición de estilo de codificación" y detección de patrones (que se encuentren declarados) para luego ser detectados y refactorizados.

Espero que a futuro aparezcan herramientas que permitan implementar análisis estático de código y refactorización de programas GeneXus.

Por el momento, solamente puedo adelantarles que estoy trabajando en un proyecto relacionado a estos temas (Pero que no necesariamente se atacarán estos temas a corto plazo).
Seguramente pronto tendrán novedades sobre el mismo en éste mismo medio.

Recursos

Para el caso de "Las guías o estándares", no conozco mucho que se encuentre de acceso público en internet.
Los que pude localizar son los mencionadas a continuación (si conocen alguna más, se agradece el aporte para irlo incorporando al listado)

Nomenclatura GIK : http://wiki.gxtechnical.com/commwiki/servlet/hwiki?GIK,

GIK & GxSoft Nomenclaturas :
http://gxsoft.googlepages.com/gik%26gxsoftnomenclaturas
http://www.scribd.com/doc/289187/Nomenclatura-GxSoft-vs-GIK

Ejemplo usado en el proyecto ModsGX (Facultad de Ingeniería)http://www.fing.edu.uy/inco/cursos/ingsoft/pis/memoria/experiencia2002/ModsGX/modelo/introduc/metgen.htm#_Toc16527191

Seguramente en las empresas existen documentos del tipo "manual de nomenclaturas" o "manual de estándares de programación" o algún documento del tipo "buenas prácticas de programación", en donde traten los temas relacionados a estándares de codificación.
Principalmente lo que busca cada uno de estos estándares es unificar, permitiendo que cualquier programador que conozca el estándar, pueda leer y entender los programas sin mayores problemas (mejor comprensión para revisión y mantenimiento).

Para finalizar les dejo algunos ejemplos aplicados para otros lenguajes de programación:
http://en.wikipedia.org/wiki/Programming_style#Coding_conventions_for_languages

Para refactorización tienen la sección de "Automated code refactoring" mencionado en la Wikipedia
http://en.wikipedia.org/wiki/Code_refactoring#Automated_code_refactoring

GeneXus - Análisis estático de código

noreply@blogger.com (David Giordano) — Tue, 27 Oct 2009 13:53:00 +0000

A todos los programadores!!!

No importa la buena educación en programación tengas, ni que tan experimentado seas, o todo el esfuerzo y buena voluntad que pongas en tu trabajo, está comprobado que en algún momento se termina colando algún error o bug en el sistema.

El incremento en la complejidad de los sistemas, hace que sea imposible programar libre de errores, somos humanos, por lo tanto existe la posibilidad de que por descuido o error, un defecto termine en la casa del cliente.

Es por ese motivo que cada día se necesita de la ayuda de herramientas que realicen un análisis totalmente automático del código fuente, (a efectos de no permitir fugas de errores ya conocidos).

¿Análisis del código fuente?

El concepto de "análisis de código" es muy amplio, seguramente si le preguntamos a un conjunto de programadores llegaremos a una lista muy larga de posibles definiciones. Al ser un tema tan diverso y confuso, es necesario que se aclare el mismo desde un principio.

Análisis estático de código

Formalmente se denomina "Análisis estático de código" (Static Code Analysis en inglés).
Estático se refiere a que se analiza el software (código) sin que el mismo se encuentre en ejecución.

Existen varios tipos de análisis, algunos de los cuales pueden ser divididos en diferentes categorías dependiendo del valor que cada uno de estos provea.
Intentaré mencionar solamente las categorías más comúnmente utilizadas:

Revisión de Código
Este tipo de herramientas generalmente realizan análisis automatizado mediante la carga y "parseo" del código, en búsqueda de patrones de programación particulares que violen un conjunto de reglas establecidas.
Dependencia de código
Examina la relación entre el código fuente y sus dependencias para crear un mapa de toda la arquitectura de la aplicación.
Complejidad de código
Analizan y comparan la complejidad del código de los programas (métricas) para determinar que parte del sistema es innecesariamente complejo.
Tendencias
Las herramientas de análisis de tendencias, no usan los artefactos de código de forma directa, de lo que se encargan es del estudio de las mejoras o degradaciones en la calidad del código, basándose en los resultados de los análisis de las otras categorías anteriormente mencionados.
Se intentaría responder la siguiente pregunta: ¿Estamos logrando un mejor código o estamos empeorando la situación?

Beneficios del análisis estático de código.

Algunos beneficios ya fueron mencionados "entre líneas", sin embargo, es mucho más básico como dos razones simples: ahorrar tiempo para ahorrar dinero.

Uno de los aspectos del ahorro de tiempo es muy obvio, se toma mucho menos tiempo en obtener código de mejor calidad frente a la realización de la inspección por método manual.
El detectar los errores de forma temprana permiten a su vez ahorrar tiempo y dinero, pero no solo eso, ahorrarse inconvenientes en etapas en donde dar vuelta atrás y perder tiempo para corregir un problema ya no sería aceptable (y menos cuando el problema sucede en casa del cliente).

Para finalizar, quiero dejar claro que este tipo de herramientas son simplemente una herramienta complementaria que nos ayudan en mejorar la calidad del sistema, por lo tanto no debe de tomarse como sustituto de la revisión realizada de forma manual (y del uso de otras técnicas y herramientas relacionadas a la calidad de nuestro producto).

Recursos

A continuación algunos recursos para aquellos que quieran conocer más del tema (o algunas de sus ramificaciones)

En la Wikipedia:

Static Code Analysis http://en.wikipedia.org/wiki/Static_code_analysis
La categoría http://en.wikipedia.org/wiki/Category:Static_code_analysis

Software Metrics http://en.wikipedia.org/wiki/Software_metric
La categoría http://en.wikipedia.org/wiki/Category:Software_metrics

Automated Code Review http://en.wikipedia.org/wiki/Automated_code_review

Programming Style http://en.wikipedia.org/wiki/Programming_style

Code Refactoring http://en.wikipedia.org/wiki/Code_refactoring

En la comunidad GeneXus:

Métricas y complejidad
GXPoints Counter http://www2.gxtechnical.com/portal/hgxpp001.aspx?15,8,8,O,S,0,,1761s

Descuidos, dependencias y limpieza (cosas en desuso):
KBDoctor http://wiki.gxtechnical.com/commwiki/servlet/hwiki?KBDoctor

Visualización de dependencias:
The GXArchitect http://www2.gxtechnical.com/portal/hgxpp001.aspx?15,27,347,O,S,0,APP;E;1010;0;APP;APA;1010;0;4;APA;MNU;E;90;4;MNU;,

Si conocen alguna herramienta GX relacionada con estos temas y no la tengo en la lista, avisen.

GeneXus - Liberación de GXLicInfo v0.2

noreply@blogger.com (David Giordano) — Mon, 19 Oct 2009 19:03:00 +0000

En anterior oportunidad mencioné sobre un proyecto llamado GXLicInfo.

Si bien aún no fue liberado su código fuente, logré cerrar algunos temas de estética y compatibilidad (Incorporando por ejemplo el soporte de GXtest de Abstracta).

Hoy fue liberada para uso público y gratuito la versión 0.2 de GXLicInfo.
La misma se encuentra libre y sin restricciones de uso para toda la Comunidad GeneXus.

Quien piense que le puede ser de utilidad y quiera unirse al "Betatesting" ¡¡¡puede hacerlo!!!

Se encuentra de forma pública en GX Plataform Gallery bajo la sección External Tools: http://gallery.genexus.com/

Lamento no brindar una buena documentación, sin embargo les dejo el dato de que si tienen instalado GeneXus X o X Evo 1, es solo cuestión de correr desde línea de comando el programa GXLicInfo.exe o desde el explorador de Windows el archivo RunForest.cmd (para listar la misma información en una ventana de comando emergente).

Para aquellos que tienen versiones anteriores a la X y quieren utilizarlo, existe una alternativa para hacerlo (la cual funciona pero no recomiendo). Para ese caso, recomiendo leer el documento notas.txt proporcionado con el archivo de instalación.

Espero sea de utilidad

Kaizen - Filosofía Japonesa enfocada en la mejora continua

noreply@blogger.com (David Giordano) — Fri, 28 Aug 2009 19:00:00 +0000

Siguiendo un poco con mis anteriores artículos (Manufactura Esbelta), pasaré a comentarles un poco sobre la filosofía denominada Kaizen.

Kaizen : Una filosofía japonesa enfocada en la mejora continua.

La palabra Kaizen es una derivación de dos ideogramas japonesas (Kanjis), uno es KAI que significa "Cambio" y ZEN que significa "Bueno".

La filosofía se encuentra orientada hacia la eliminación de residuos o desperdicios, los cuales son eliminados de forma sistemática mediante la ejecución continua de mejoras.
Kaizen no solamente aplicable a nivel organizacional, sino que puede ser aplicado sobre todos los aspectos de la vida.

Una de las frases que identifican a Kaizen es: "¡Hoy mejor que ayer, mañana mejor que hoy!".

Muchas prácticas, metodologías y conceptos se encuentran relacionadas la filosofía de mejora continua en Kaizen, algunas de ellas son:

Control de calidad total / Gerencia de Calidad Total (TQC y TQM)

Un sistema de producción justo a tiempo (JIT)

Mantenimiento productivo total (TPM)

Teoría de restricciones (TOC)

Manufactura esbelta (LM)

El método de las 5's (5S)

Circulo de Calidad (QC)

La capacidad de analizar, motivar, dirigir, controlar y evaluar constituyen la razón de ser del Kaizen. Otra de las consignas que identifican a Kaizen: “Cuanto más simple y sencillo mejor”.

El mejoramiento continuo se logra a través de todas las acciones diarias (por pequeñas que éstas sean), Trabajando en que los procesos y la empresa sean más competitivas en la satisfacción de nuestros clientes.

La velocidad del cambio dependerá del número de acciones de mejoramiento que se realicen día a día y de la efectividad con que éstas se realicen, por lo que es importante que la mejora continua sea una idea o un sentimiento adoptado como conducta de todos los miembros de la organización, hasta convertirse en una filosofía de trabajo y de vida.

Uno de los aspectos del Kaizen es que no requiere de técnicas sofisticadas o tecnologías avanzadas.

Según Manuel Suarez en su libro "El Kaizen":

"Lo más interesante y práctico del Kaizen a diferencia de la innovación es que no necesita una tecnología complicada, altamente sofisticada, ni siquiera una enorme inversión para implantarlo; sólo se requiere de sistemas, mecanismos y herramientas sencillas, convencionales, que con sentido común son fáciles de aplicar. El verdadero catalizador de su aplicación es el Know-how, es decir, el conocimiento aprendido por los empleados a lo largo de los años, que operando bajo una filosofía Kaizen se vuelve en una estrategia básica de la supervivencia de la organización en los mercados."

Las compañías japonesas son las que en un principio aplicando Kaizen lograron avances tan significativos que les permitieron no solo mejorar su nivel de calidad y competitividad dentro de Japón, sino que les permitió de forma estratégica lograr conquistar los mercados internacionales.

Kaizen vs Innovación (Kairyo)

Se suele hacer comparaciones entre el concepto de Kaizen e Innovación, comparar es un método simple y efectivo para demostrar el fuerte de cada una de estas filosofías.

Les adjunto un cuadro del libro "El Kaizen" (anteriormente mencionado) que muestra claramente las diferencias entre las mismas.

Kaizen e Innovación no son excluyentes, sino que deben de usarse de forma complementaria para lograr lo que se denomina como "mejora sostenible".

Seguramente en algún futuro post les comentaré un poco sobre la correlación entre Kaizen e Innovación (Kayrio).

Estos temas son muy amplios para tratar en un solo artículo, es por eso que les dejo algunos línk's para aquellos curiosos que quieran conocer más sobre Kaizen.

Recursos:

El Padre de Kaizen: Masaaki Imai
http://en.wikipedia.org/wiki/Masaaki_Imai

Wikipedia Kaizen http://en.wikipedia.org/wiki/Kaizen

Wikilearning - Manufactura Esbelta - Mejora Continua Kaizen http://www.wikilearning.com/monografia/manufactura_esbelta-mejora_continua_kaizen/12502-17

Libro "El Kaizen" por Manuel Francisco Suarez Barraza http://books.google.com.uy/books?id=l3FXNs-q_CYC

Libros sobre Kaizen en Amazon http://www.amazon.com/s/ref=nb_ss?url=search-alias%3Dstripbooks&field-keywords=Kaizen&x=13&y=21

GeneXus - Manufactura Esbelta - Poka Yoke

noreply@blogger.com (David Giordano) — Fri, 17 Jul 2009 14:00:00 +0000

Continuando con Manufactura Esbelta (Post 1 y 2), les comentaré un poco sobre Poka Yoke y su aplicación como herramienta.

Poka Yoke (Prevención de errores)

El término Poka Yoke proviene de la palabra japonesa "poka" que significa "error inadvertido" y "yoke" que significa "prevenir".

Por lo tanto una herramienta Poka Yoke es una herramienta que intenta prevenir los errores antes de que estos mismos sucedan.

Los sistemas Poka Yoke implican el llevar a cabo dos funciones primordiales, por un lado realizar la inspección del 100% de las partes y por otro, en caso de que ocurra alguna anomalía, permitir dar retroalimentación permitiendo realizar lo antes posible acciones correctivas.

Las herramientas Poka Yoke pueden intervenir en todo el ciclo de una línea de producción.

Se definen 3 niveles de Poka Yoke:

Nivel 1 : Eliminar el error desde su origen
Nivel 2 : Detectar un error en el momento en que ocurre
Nivel 3 : Detectar los defectos inmediatamente, no permitiendo proseguir

Cuanto más anticipado en el proceso se instale un Poka Yoke, con mayor anticipación se detectarán los errores (en etapas más tardías el costo de solución un posible defecto será mayor).
Módulos Poka Yoke

En artículos anteriores comenté un poco sobre la herramienta de automatización que permitió mejorar el proceso de Release en la empresa (ver artículos de Manufactura Esbelta y Jidoka) .

La herramienta Quirón (el orquestador de todo el proceso) actualmente tiene 4 tipos de módulos Poka Yoke implementados:

Inspección
Inspecciona los elementos a procesar (Basado en los reglas de negocio establecidas)
Análisis de impacto
Detecta impactos directos e indirectos antes de que los mismos ocurran
Corrección
Detecta anomalías y corrige las mismas "en caliente"
Autodiagnóstico
Comparando resultado final contra el esperado es posible detectar anomalías en los módulos anteriormente mencionados.

En caso de detectar una anomalía será iniciado inmediatamente un proceso Jidoka.
Este proceso procura que los problemas no vuelvan a suceder, permitiendo ingresar en un proceso de mejora continua (del proceso y sus herramientas Poka Yoke).

Los errores son inevitables

Las personas siempre cometen errores, algo que debe tomarse como natural por ser parte de nuestra naturaleza humana.
Una distracción, un olvido, malos entendidos, ignorar reglas o políticas y el no cumplir alguno de los estándares, son algunos de los factores que pueden derivar en error.

Tratar de pensar que es posible eliminar el 100% de los errores humanos (mediante educación, capacitación o comunicación), sólo logrará minimizar la probabilidad de ocurrencia, sin embargo seguirá existiendo la probabilidad de que los mismos ocurran (y realmente seguirán ocurriendo).

Existen varios factores y condiciones que aumentan la probabilidad de errores:

Ajustes continuos (Producto o proceso)
Falta de Especificaciones adecuadas (Requerimientos o Procesos)
Alta complejidad (Producto o Procesos)
Entorno de trabajo (Condiciones de trabajo y relaciones)

Nadie quiere cometer errores!!. Mientras exista trabajo, seguirán existiendo errores, es un proceso inevitable. Las herramientas Poka Yoke nos ayudarán en el proceso en prevenir que los defectos ocurran, y principalmente, nos ayudará a detectar los errores que podrían pasar de forma inadvertida (esos errores que pueden llegar al final de la cadena de producción o inclusive a nuestros clientes).

Recomendaciones para crear un buen Poka Yoke

Piensa simple
Es mejor muchos Poka Yokes simples, en donde cada uno de ellos tenga un único propósito, que tener un gran Poka Yoke con alta complejidad.
Piensa específicamente
Trabaja en analizar los errores que comúnmente ocurren para crear Poka Yokes que corrijan o detecten los mismos.
Piensa modularmente
No esperes a que toda la aplicación se encuentre terminada, puedes ir trabajando sobre los módulos que pueden ser verificados de forma independiente.
Piensa anticipándote
Tan pronto como sea posible, trabaja en detectar y corregir los errores antes que se conviertan en defectos en las manos de un cliente.
Piensa activamente
Cuando te encuentres con defectos, trabaja en corregir lo antes posible el error que lo ocasionó.
Piensa en reutilizar
Un Poka Yoke útil y bien pensando, puede ser modificado o reutilizado para otros propósitos.

Referencias:

Poka Yoke en la Wikipedia en español http://es.wikipedia.org/wiki/Poka-yoke
La versión en inglés en donde existe mayor referencia y ejemplos http://en.wikipedia.org/wiki/Poka-yoke

Libros sobre Poka Yoke http://www.amazon.com/s/ref=nb_ss_b?url=search-alias%3Dstripbooks&field-keywords=Poka+Yoke&x=11&y=14

GeneXus - Manufactura Esbelta - Jidoka

noreply@blogger.com (David Giordano) — Tue, 14 Jul 2009 20:30:00 +0000

En mi anterior artículo les comenté a modo introductorio un poco de mi experiencia con la filosofía de Lean Manufacturing (Manufactura Esbelta).

Continuando con el tema, les presentare la filosofía Jidoka y las herramientas implementadas bajo esta filosofía, la cual influye principalmente en el proceso de Release de los productos desarrollados con GeneXus en la empresa en donde trabajo (de Larrobla & Asociados y su producto Bantotal).

Jidoka

Jidoka es un término japonés que significa "Automatización" y también relacionado con el concepto de "Verificación de proceso".

Generalmente cuando se instala Jidoka en un proceso de producción se están refiriendo a la verificación de la calidad integrada al proceso.

La filosofía Jidoka establece cuales son los parámetros de calidad en el proceso, los mismos luego se comparan contra los resultados obtenidos de la ejecución real del proceso.
Si algún estándar no es cumplido, el proceso se detiene a efectos de no permitir un resultados de mala calidad. En el momento en que la cadena se detiene, se reporta el incidente y no vuelve a restablecerse el proceso hasta que no sea corregido el problema.

Jidoka se aplica también cuando un miembro del equipo encuentra un problema en su estación de trabajo, permitiendo frenar la línea de producción a efectos de no propagar los problemas.

Los miembros del equipo son responsables de corregir el problema lo antes posible minimizando los tiempos en que se detiene la línea de trabajo.

Una nueva forma de trabajo

Implementar una herramienta Jidoka produjo un cambio en la forma del trabajo diario.
Se cambio las tareas rutinarias (y con alto costo en horas hombre) por un trabajo proactivo, en pro de solucionar los problemas cuando los mismos ocurren.

Jidoka no funcionaría simplemente con el hecho de detectar anomalías y frenar la línea de producción. El trabajo fuerte de Jidoka está en corregir la anormalidad e investigar la causa raíz para eliminarla definitivamente el problema a efectos de que los mismos no vuelvan a suceder. De esta forma se instaura un ciclo de mejora continua.

Una buena ejecución de Jidoka

Por lo tanto los pasos esenciales para definir una buena ejecución de Jidoka se resume en:

Detectar la anormalidad
Parar
Fijar o corregir la condición anormal
Investigar la causa raíz
Instalar las contramedidas

Los primeros dos puntos son posibles de automatiz, sin embargo los otros puntos son totalmente del dominio de las personas, requieren del diagnóstico y análisis, así como de una resolución al problema.

Es por eso que Jidoka también se le denomina "Automatización con un toque humano", la automatización no sería posible sin el esfuerzo de las personas por mejorar y evolucionar el conocimiento en sus herramientas.

La herramienta basada en Jidoka

En mi anterior articulo les comente sobre mi cliente "vedette", el "sector de fuentes" (Encargado de la integración, build y distribución de los productos de trabajo del ciclo de desarrollo con GeneXus).

Basado en los "estándares" y criterios definidos, se implemento una herramienta encargada de automatizar el proceso (denominada internamente como Quirón).

También se crearon herramientas que permiten frenar el proceso, así como otras que ayudan en la detección del problema y su posible diagnóstico.

Nunca había trabajado en un proyecto de tal magnitud, no solo era necesario automatizar la línea de proceso, sino que se requería de herramientas que ayudaran a diagnosticar los problemas.

La gran mayoría de las herramientas implementadas son utilizadas en la línea de proceso automatizada (orquestadas por Quirón), luego muchas de ellas son reutilizadas para realizar tareas preventivas, de mantenimiento, corrección y diagnóstico.

Cuando todo funciona correctamente, los productos de trabajo son entregados sin problemas, cuando se detecta un error, el personal trabaja en solucionar la avería lo antes posible. En caso que se requiera detener la línea de trabajo, se cuenta con las herramientas para realizarlo (Cumpliendo con la filosofía).

Lo bueno del método de trabajo y el haber logrado automatizar el proceso, es que actualmente por más que el sector se encuentre trabajando en solucionar un problema en una de las líneas, el resto de las líneas de trabajo seguirán funcionando sin inconvenientes (Actualmente es posible procesar hasta 10 líneas de trabajo de forma concurrente, las 24 horas del día los 365 días del año).

Todo el automatismo se encuentra realizando tareas que anteriormente eran imposibles de ser realizados por el sector y lo mejor de todo es que ejecutan el 100% de las tareas especificadas, todo sin que nadie del sector tenga que "sudar una gota" por tener que procesar tanto trabajo.

Es un trabajo de "Todo o nada", si el producto de trabajo no pasa uno de los pasos del proceso, se tomará el paso de ese proceso como fallido, por lo tanto "saltarse pasos" o definir excepciones es algo no valido en el proceso.

Cada actividad planteada tiene un propósito, el saltearse alguna de ellas genera un problema a largo plazo, por lo tanto se buscará que nuestro producto cumplan con todas las exigencias necesarias.

Actualmente ejecutamos de forma automática el proceso de Release con soporte de más de 4 plataformas en simultaneo, cada programa debe de cumplir los estándares definidos para cada una de ellas, por lo tanto, un programa es aprobado cuando logra pasar las inspecciones, ser generado, compilado y distribuido para cada una de ellas.

Finalizando, les dejo una referencia sobre Jidoka proporcionada por la propia gente de Toyota: http://www2.toyota.co.jp/en/vision/production_system/jidoka.html

También les dejo información sobre la historia de los telares automáticos http://www.yoshida-mc.co.jp/history/loom.htm en donde podrán notar la evolución por la cual el desarrollo de software también está incursionando.

En el próximo artículo les seguiré mencionando sobre filosofías y herramientas relacionadas a la Manufactura Esbelta aplicadas en el proyecto Quirón (y en futuros artículos espero poder introducirlos un poco más sobre los futuros proyectos y sus filosofías/metodologías utilizadas).

GeneXus - Manufactura Esbelta

noreply@blogger.com (David Giordano) — Mon, 13 Jul 2009 04:00:00 +0000

Comentaré un poco sobre una de las filosofías que vengo utilizando hace ya un tiempo en la implementación de herramientas de automatización.

¿Que es Manufactura Esbelta? (Lean Manufacturing)

Según la Wikipedia http://es.wikipedia.org/wiki/Lean_Manufacturing

"Es una filosofía de gestión enfocada a la reducción de los 7 tipos de "desperdicios" (sobreproducción, tiempo de espera, transporte, exceso de procesado, inventario, movimiento y defectos) en productos manufacturados.
Eliminando el despilfarro, la calidad mejora, el tiempo de producción y el costo se reducen. Las herramientas "lean" (en inglés, "sin grasa") incluyen procesos continuos de análisis (kaizen), producción "pull" (en el sentido de kanban), y elementos y procesos "a prueba de fallos" (poka yoke)."

Los principios clave de Manufactura Esbelta:

Calidad perfecta a la primera
Minimización del despilfarro
Mejora continua
Procesos "pull"
Flexibilidad
Construcción/Mantenimiento de relaciones

En internet pueden encontrar mucho material sobre el tema, por lo tanto no los voy a aburrir haciendo más largo el artículo.

¿Que relación existe con la Ingeniería de Software?

Si bien los orígenes provienen de la ingeniería industrial, la filosofía y sus conceptos son aplicables en todas las ramas de la ingeniería.

Hoy en día, los clientes exigen una mayor flexibilidad en los productos, quieren entregas más pequeñas y con más frecuencia, y claro, requieren que todo producto resultante tenga mayor calidad a un precio mucho menor.

Por lo tanto, si los clientes demandan más de nosotros, nosotros tendremos que hacer mucho más para lograr dejarlos satisfechos, ya que cada necesidad del cliente afectará de alguna forma cada parte del proceso de fabricación (hasta la entrega,instalación y mantenimiento del producto).

Solamente un factor puede hacer la diferencia, y un solo factor puede hacer que una empresa logre el éxito (o el fracaso?).

Con el fin de satisfacer a los "clientes", los fabricantes de software están ampliando su alcance y enfocando (entre tantas otras) en intentar seguir la filosofía de la Manufactura Esbelta.
El objetivo que persiguen: abarcar la mayor cantidad de procesos en busca de contribuir en mejorar la calidad y el aumento de las utilidades.

Mi experiencia

Mi experiencia con "la filosofía" es muy personal (no es impuesto por la empresa en donde trabajo), la misma la vengo aplicando en el sector en donde trabajo, tanto en las cosas que hago como en las cosas que desarrollo (y por transitiva, llegará a los otros sectores en donde las herramientas tomen un papel importante).

Estas herramientas tomarán un papel primordial en el proceso de "Release Management" de los productos desarrollados con GeneXus.

¿Quienes son mis clientes?

Mi trabajo es implementar herramientas (uso interno y externo), por lo tanto "mis clientes" es un espectro muy variado.

El proyecto en el cual estoy trabajando implica que el producto de salida final, tenga "Calidad perfecta" a la primera, buscando minimizar el "despilfarro" y el "retrabajo".

La empresa me planteó la necesidad, se analizaron los problemas y se llegó a una conclusión.
No es posible lograr mejorar la calidad del producto final con solamente mejorar el último eslabón de la cadena de producción.

Era necesario implementar mejoras en etapas más tempranas, incorporando calidad y automatismos en cada paso de la línea de trabajo.

Por lo tanto a efectos de ser posible lograr ese cometido, se buscó y localizó el punto de quiebre en donde se debía de comenzar a trabajar para lograr un producto de salida de 5 estrellas.

Automatismos en procesos cotidianos

El cliente "vedette" de los últimos tiempos es el sector encargado de la integración, build y ditribución de los productos de trabajo (desarrollo y mantenimiento).
Internamente lo denominamos "El sector de Fuentes y Envíos".

En ese escenario se aplicaron los principios clave y se desarrollaron herramientas que ayudan al sector en sus procesos diarios. La intención: inyectar en el menor tiempo posible y de la mejor forma posible la mayor cantidad de automatismos que aseguren la calidad del proceso completo.

Quiero dejar claro que este tipo de proyectos no es posible sin la gente.
Ahora el personal deja de ver el árbol para comenzar a ver el bosque. Y, ¿por qué me refiero a esto precisamente? Porque muchas personas asocian el automatismo y la eliminación de tareas sin valor con los despidos y remociones de cargos.
Sin embargo esto no es así, las personas solamente dejan de picar piedra para comenzar a trabajar en problemas más complejos, realizando tareas con mayor nivel de complejidad, permitiéndoles brindar soluciones a problemas complejos, lo cual se alinea con la filosofía de Manufactura Esbelta.

Actualmente es muy temprano como para medir resultados y solo se trabajó en un conjunto de eslabones (aún queda llegar al final de la cadena producción: al cliente de mis clientes); más que nada les quería presentar la filosofía de Manufactura Esbelta en el proceso de automatización de la línea de producción.

Más adelante les comentaré un poco sobre el proceso completo, su correlación con Manufactura Esbelta y también sobre algunas otras prácticas y filosofías relacionadas, tales como Poka Yoke y Jidoka. Y claro, no faltará algún comentario sobre la experiencia obtenida en todo el camino transcurrido.

¿Alguien en la comunidad ha tenido experiencias con automatización de la línea de producción?

GeneXus - Información de Licencias Instaladas

noreply@blogger.com (David Giordano) — Mon, 22 Jun 2009 09:00:00 +0000

Próximamente voy a liberar el código fuente de una herramienta que permitirá acceder a la información de las licencias instaladas de los diferentes productos GeneXus.

Actualmente estoy en un proyecto en el cual necesito tener control sobre el estado de las licencias GeneXus.
La herramienta se encuentra implementada en .NET y utiliza GXPublic para especificar y generar programas.

Como su ejecución es de forma desatendida (batch/servicio), todo mensaje emitido por el especificador y generador asociado al estado de las licencias son un problema.

Por varios motivos puede ocurrir que las licencias den problemas en el proceso:
- Un apagón hizo perder las licencias
- Licencias a punto de expirar (En la empresa manejamos licencias temporarias)
- O un determinado generador que debe de ser utilizado nunca se le solicitó la licencia.

En el proceso, un mensaje como "No autorizado" o "Expiró la licencia" o "Te quedan tantos días..", puede hacer que el proceso completo quede bloqueado en espera de una respuesta del usuario.

Con información proporcionada por la gente de Artech, hice una pequeña rutina para obtener el estado de las licencias antes de utilizar un determinado generador.

Luego con la rutina, comencé a implementar una herramienta que me permite por línea de comando listar todas las licencias que tengo instaladas en mi máquina.

Una funcionalidad que siempre esperé tener en el License Manager era de permitir ver el árbol de autorizaciones (Si tengo autorizado DevEnv de GX 9.0 y no tengo autorizado DevEnv GX 8, muestro que DevEnv de GX 8 depende de esa licencia para funcionar).

Adjunto ejemplo de un listado de Licencias generador por GXLicInfo:

GXLicInfo v0.1
----------------------------------------
GeneXus X Evolution 1
RPG Generator (X Evolution 1) Remain Days:20
- RPG for iSeries Generator (9.0)
- RPG/400 Generator (7.5)
.NET Mobile Generator (X Evolution 1) Remain Days:20
- .NET Mobile Generator (9.0)

----------------------------------------
GeneXus X
Development Environment (X) Remain Days:10
- Development Environment (9.0)
- Development Environment (7.5)
Java Generator (X) Remain Days:10
- Java Generator (9.0)
- Java Generator (7.5)
.NET Generator (X) Remain Days:10
- .NET Generator (9.0)
- .NET Generator (7.5)

----------------------------------------
GeneXus X (Beta)
Ruby Generator (X) (EXPIRED)

----------------------------------------
GeneXus 8.0
Development Environment (8.0) Remain Days:80
RPG/400 Generator (8.0) Remain Days:80
Java Generator (8.0) Remain Days:80
.NET Generator (8.0) Remain Days:80

Próximamente voy a liberar el código fuente de GXLicInfo a la comunidad para que la misma vea de utilizarla en proyectos propios o en futuras herramientas.

¿Que herramientas se les ocurriría implementar con estas rutinas básicas?

Yo tengo algunas en mente, a ver si se les ocurre alguna a ustedes.

- Una herramienta que permita ver el estado de todas las licencias de toda las máquinas conectadas a la red.
- Incorporar soporte de solicitud de licencias de forma automática (Cuando pierdo licencias o se me vencen, avisar y permitir solicitar las mismas nuevamente de forma automática).
- Un servicio que esté observando el estado de las licencias y ayude informando o recordando el estado de las licencias (Me lo imagino para un GXServer o para un Servidor al cual se conectan por Terminal)

Actualmente sigo trabajando en GXLicInfo, por lo cual si alguien tiene ansiedad en probarla y desea ser un Betatester, me la piden y yo se las envío por mail.

GeneXus - Acelerando la compilación Java (Alternativa a SUN JDK)

noreply@blogger.com (David Giordano) — Wed, 06 May 2009 17:40:00 +0000

El tiempo pasa y cada día la demanda de integración con otras aplicaciones externas es mayor.

Muchos tienen suerte y no necesitan utilizar librerías externas (o código Java embebido en programas), muchos con crear su aplicación 100% GeneXus y utilizar viejas versiones de Java les es suficiente (Anteriores a Java 1.5).

Sin embargo, hay casos en los que se requiere integrarse la aplicación contra implementaciones de terceros para que tu aplicación pueda funcionar, como por ejemplo; módulos de seguridad o interfaces de consulta o integración con otros sistemas (NO SOAP, NO GX).

En mi caso por ejemplo, tengo un producto con muchas dependencias a módulos (clases) implementados en múltiples versiones de Java (Desde cosas simples J 1.1 a cosas más avanzadas en Java 1.5+).

Actualmente estoy en un proceso de recompilación completa de la aplicación.

¿Que opciones tenía?

Quería velocidad en la compilación, recompilar una gran base de conocimiento no era algo de un día para el otro y necesitaba hacerlo de forma completa en el mínimo tiempo posible.

Los descartados:

Microsoft SDK for Java murió con la compatibilidad 1.1.
Jikes 1.22 murió con compatibilidad 1.4 (y algo de la 1.5)

Yo necesito Java 1.5+ !!!

No tenía otra que morir con el indiscutible ganador en Java, el compilador de SUN y su JDK.

Sin embargo el compilador de SUN siempre se lo vio como "Un compilador lento".

Investigando descubrí que no era el único en el mundo que se quejaba de su lentitud y de no tener alternativas.

Ahora bien, si bien no encontré ningún truco o pisadita para acelerar el JDK 1.6 de Sun, encontré que muchos elogiaban la diferencia en velocidad obtenida por los IDE's como el de Netbeans y Eclipse.

¿En donde estaba la diferencia?

En el fondo tanto NetBeans como Eclipse tienen que morir en el compilador de Sun (o eso yo pensaba), por lo que algo no me cerraba.
Investigando un poco más, llegué a lo que se denomina como JSR 199 (Java Compiler API).

A partir del momento en que Sun implementa en la máquina virtual de Java la posibilidad de compilación nativa (directamente por lenguaje), las cosas cambiaron.

A partir de ese momento dejó la puerta abierta a terceros a que sea posible implementarse sus propios compiladores (en realidad sus propias optimizaciones al momento de compilar, el que compila y genera el bytecode es la máquina virtual).

Tanto Eclipse como Netbeans hoy en día aprovechan estas funcionalidades para realizar las compilaciones directamente desde el IDE, independizándose del compilador binario, e implementando algoritmos mejorados que permitan compilar de la forma más optima posible.

Por el momento solamente conseguí conocer algunas implementaciones que aprovechan el JSR 199 a fondo:

- Netbean Compiler
Tengo entendido que sería posible utilizar los métodos y simular un javac de línea de comando.
Actualmente Netbeans no tiene publicada su api como para ser utilizado por terceros, hay que investigar un poquito más. Lo dejo en mi lista de cosas a investigar cuando tenga tiempo.

- Eclipse JDT Core Batch Compiler
Si, estos amigos de Eclipse vieron que la comunidad lo necesitaba, y lo liberaron como un módulo independiente del IDE de Eclipse. Gracias Eclipse!!!

- OpenJDK
Como aún no fue liberado oficialmente no le hice pruebas, pero en cuanto tenga tiempo lo probaré.
Existe la posibilidad de usarse en modo "Batch javac compatible" mediante la compilación de un módulo específico de compilación (que dará origen a un javac.jar, busquen en internet sobre Netbeans y javac.jar y encontrarán como crearlo desde los fuentes).
Lo que habría que probar es que si usa JSR 199 sería posible utilizar el Jar de OpenJDK con la máquina virtual de SUN 1.6. Habría que hacer la prueba también.

Como no he tenido tiempo para investigar el caso de Netbean o el de OpenJDK, se lo dejo a la comunidad para que vea si puede dar algún aporte o no.

Yo me voy a encargar de presentarles el caso que si pude probar.

¿Quien quiere compilar java 1.5+ a un velocidad mucho mejor que la del compilador de SUN?

Les presento a ...

Eclipse JDT Core Batch Compiler

Requisitos: Runtime de Java 1.6+ (SUN Java 6.0 por ejemplo o cualquier otra que implemente el JSR199)

Donde Bajarlo: Sitio o Directo

¿Como utilizarlo en GeneXus?

Para poder simular el compilador de Sun, deben de crearse un script de línea de comando que instancia el jar de eclipse y simule los parámetro del compilador original.

Ejemplo: ECJJavaC.cmd

@echo off
java -jar pathdeljar\ecj-3.4.2.jar -nowarn -source 1.5 -target 1.5 -cp "%CLASSPATH%" %1 %2 %3 %4 %5 %6 %7 %8 %9

En donde "pathdeljar" se debe de indicar el path en donde se encuentra el jar del compilador.

Los parámetros "source" y "target" deben de indicar la versión de Java origen (cuanto mas arrimada a la realidad mejor será la optimización) y destino que quieren generar, si no especifican nada se utilizará la última versión soportada por el runtime. (Si es java 6, utilizará 1.6)

Si por ejemplo nuestra aplicación es 100% implementada con GeneXus, sabemos que GeneXus es Java 1.1 compatible, por lo tanto en source le indicamos 1.3 (es lo mínimo que acepta).

Si queremos que sea compilado como por ejemplo en Java 1.5 compatible, en target le indicamos 1.5.

De esta forma pueden "jugar" con los orígenes y destinos que requieran, esto ayudará al compilador a detectar que técnicas de análisis de código debe de utilizar para lograr compilar sus fuentes.

Es posible compilar bytecode de cualquier versión de Java, por lo que pueden crear una versión de cada comando para cada versión destino y seleccionar en las producciones de cada versión el comando asociado a cada una de ellas.

Si quieren mayor información sobre los parámetros del compilador (o en la página de eclipse):
java -jar pathdeljar\ecj-3.4.2.jar -help

Los que me parecieron útiles
-time
Muestra el tiempo en que demora el compilador, muy buena info a nivel de líneas de código por segundo procesado y cantidad de clases generadas.
-verbose
Muestra internamente las lecturas y análisis de las dependencias, da muy buena información de donde saca las mismas (Cuando tienen mal el classpath esto les puede ayudar)
-log
Permite almacenar el resultado del procesamiento en un archivo log (En otro artículo les enseñaré como aprovechar este parámetro).

Ahora bien, lo que queda es ir a GeneXus y en la propiedad en donde se debe de indicar el compilador de SUN, se debe de apuntar al archivo de comando ECJJavaC.cmd que hemos creado.

Resultados

Las pruebas que hice me dieron que el compilador de Microsoft y Jikes siguen siendo indiscutiblemente los más rápidos (Para versiones viejas de Java).

Sin embargo utilizando el compilador de Eclipse frente al nativo de SUN logré mucho mejores resultados en los tiempos (En algunos casos hasta 4 veces más rápido que el de SUN).

Mejoras que pude detectar en el compilador de Eclipse frente al compilar de SUN.

- Tiempos en análisis de dependencias (Si tengo un classpath monumental con múltiples JAR's)
- Mejora en la utilización de recursos (Múltiples Cores, CPU, Memoria e IO)

Compatibilidad

Se hicieron pruebas con GeneXus 8.0, GeneXus 9.0 y GeneXus X, corroborando un correcto funcionamiento de la solución planteada.

Agradecimiento especiales a Matías Reina por sus ayuda en las pruebas del compilador en GeneXus 9.0 y X.

Les dejo un link en donde menciona un poco la historia del compilador de Eclipse (Para los curiosos, el compilador es una evolución del compilador de VisualAge Micro Edition - VAME).

Espero que les sea de utilidad.

Décadas de ideas innovadoras (Parte III - El Final)

noreply@blogger.com (David Giordano) — Tue, 05 May 2009 15:41:00 +0000

Bueno, por fin llegó el día en que terminaré de contar la historia de la saga de artículos relacionados a "Décadas de ideas innovadoras" (Continuación de la Parte II)

La nueva revolución detrás de la revolución industrial.

Una nueva revolución se estaba gestando en la década de la post guerra.

Por un lado los avances en la tecnología como la mecánica y la electrónica, fueron los que dieron al nacimiento del transistor, los circuitos integrados y lo que fueron las primeras computadoras.

Sin embargo, también se estaba gestando una revolución en el método de fabricación.

Entre algunos de las innovaciones se encuentra lo que se conoce como “Calidad Total”, “la Mejora Continua”,” Gestión del Conocimiento” y la “Reingeniería de los Procesos”.

A partir de la década del 40, Estados Unidos se encontraba en la vanguardia, tanto de la tecnología como en la gestión de Empresas.

Hasta que un país muy ingenioso comenzó a globalizar sus productos y demostró cómo en base al esfuerzo y el ingenio era posible mejorar la forma de hacer las cosas.

Ese país era Japón, y demostró que era posible innovar teniendo recursos muy limitados.
Logró demostrar que era posible mejorar la tecnología actual y los procesos de fabricación existentes a la época.

Increíblemente era su única salida a la crisis post guerra ocasionada por los Estados Unidos.

Fueron los creadores de "Control Total de Calidad" y la "Mejora continua" (Kaizen), así como muchos otros temas relacionados con la calidad y los procesos de construcción.

En esas décadas el país invirtió enormemente en tecnología, matemáticas, física, procesos, calidad y administración de empresas.

La época la denominan algunos como la "Tercera revolución industrial".

Japón comenzó a trabajar a partir de 1950, y durante 20 años, logró demostrar al mundo de lo que eran capaces de lograr.

Comenzó a hacer las cosas a su manera (Shafu), sin embargo el resto de las empresas del mercado demoraron en comenzar a aprender de ellos (captar conocimiento).

Sus competidores demoraron 20 año más en comprobar que Japón lo que hacía era realmente cierto, ya que Estados Unidos y Europa creían que la calidad y los productos que eran desarrollados en Japón, por su alto nivel de calidad, eran en realidad parte de una estrategia de mercadeo (dumping y exportación de productos seleccionados de alta calidad para demoler mercados extranjeros).

Sin embargo, las empresas corroboraron que tanto su producción interna como en sus productos exportados, tenían la vanguardia en tecnología.

Lograron bajar costes de producción, aumentaron productividad e incrementaron la calidad de sus productos.

Algunos de los pilares sobre los cuales se apoyaron fueron "Los tres métodos" (la mecanización, la especialización y las técnicas de dirección), así como las "5S" (Organización, Orden, Limpieza, Estandarizar y Disciplinar).

Sin embargo no solo logró innovar con sus procesos de calidad, sino que logro innovar en la tecnología, lo cual hizo despertar a las grandes potencias, haciendo que las mismas comenzaran un proceso similar por temor a perder el liderazgo de los mercados.

Uno de las grandes inversiones realizadas en Japón asociadas a la innovación se conoce como "La Quinta Generación de computadoras".

Algunos de los temas enmarcados en el proyecto:

- Tecnologías para el proceso del conocimiento.
- Tecnologías para procesar bases de datos y bases de conocimiento masivo.
- Sitios de trabajo del alto rendimiento.
- Informáticas funcionales distribuidas.
- Supercomputadoras para el cálculo científico.

Fue una verdadera revolución, el proyecto generó un impacto tan importante a nivel mundial, que otros países del mundo comenzaron a invertir de igual manera en los mismos temas de investigación.

Es así que Estados Unidos creó la “Corporación de Microelectrónica y Tecnologías de la Computación”.
Inglaterra siguió los pasos de Estados Unidos, creando el “Alves”, y en Europa se conformó el “Programa Europeo en Investigación Estratégica de la Tecnología de la Información”.

Algunos de los resultados obtenidos de estos proyectos de investigación:

- 5 Máquinas de Inferencia Paralela (Parallel Inference Machine - PIM) PIM/m, PIM/p, PIM/i, PIM/k, PIM/c.
- Un lenguaje de programación deductivo y orientado a objetos (Quixote)
- Parallel constraint logic programming language, GDCC
- Sistemas Heterogéneos de Solución de Problemas Distribuidos.
- Sistema Paralelo de Gerencia de Bases de Datos (Kappa-P)
- Sistema de Razonamiento Legal HELIC-II
- Teorema Autómata de Aprobaciones MGTP.
- Análisis Genético de ADN y Secuencia proteínica
- Base de datos Biológicas y KBMS (Knowledge Base Management Systems)

Todo esto, dio originen a grandes avances en las siguientes áreas:

- Procesamiento Paralelo (Arquitectura)
- Bases de Datos con procesamiento Paralelo
- Programación Lógica
- Lenguajes de Acceso a Datos
- Inteligencia Artificial
- Sistemas Expertos y gestión de Conocimiento.

¿Y qué sucedió con todo esto?

Los proyectos fracasaron a mediado de los 90's.

Se cree que el fracaso es debido a que la tecnología creada era muy adelantada a las necesidades de los usuarios.

Es así que el mundo entero le dio la espalda a estos proyectos de investigación.
Fue el momento en que los mercados comenzaron a "enfocarse” hacia otras nuevas tecnologías que llegaban más al usuario “común”.

La aparición de computadores con interfaces gráficas y la utilización de Microprocesadores (Intel).

Hoy en día se ha mirado hacia el pasado, intentando volver a reflotar las viejas ideas, con respecto al tratamiento del conocimiento, la ejecución paralela y la inteligencia artificial.

Muchos de los avances que hoy en día se están presentando, tienen en gran medida conceptos o ideas generadas en la década de los 70 a los 90's.
Sin embargo, nadie recuerda del pasado, se sigue reinventando la rueda.

De la misma forma en que el proyecto dio sus grandes avances y fue olvidado por las nuevas generaciones de computadores, así también sucedió con todo lo aprendido e implementado desde la época del 50 a los 80's (arquitecturas, sistemas operativos y lenguajes de programación).

La era del microprocesador y las computadoras personales hicieron un "borrón y cuenta nueva".

Solamente sobrevivieron aquellos inventos que fueron denominadas como “Prácticos” para la nueva plataforma.

En hardware, lo positivo fue que dió origen a la aparición del Disquete, el CD-ROM, los Monitores, Discos Rígidos, el Modem y las Impresoras.

En la parte del Software, lenguajes de programación generales fueron los primeros en trasladarse a las nuevas arquitecturas, dejando de lado lenguajes más especializados y de dominio.

Sin embargo, los Sistemas operativos fueron "reinventados" para la nueva arquitectura (ya que existía un nuevo tipo de cliente).

Los Dinosaurios siguieron existiendo, pero con el paso del tiempo fueron olvidados (sus mentores fueron muriendo y el mercado los fue desplazando).

Solo en algunos casos, se migraron o se tomaron algunos de sus conceptos para las nuevas versiones del software.

Hoy estamos presenciando una nueva revolución.

El auge de los lenguajes dinámicos, los multiprocesadores, los lenguajes paralelos, lenguajes funcionales, nuevos sistemas operativos “como servicios”, la nube, las redes sociales, Web 2.0 y un sinfín de nuevas tecnologías.

Espero no encontrarme dentro de unas décadas con el reinvento de la ruda.

De la misma forma, espero que toda la tecnología actualmente emergente se esté basando en lecciones aprendidas del pasado (que no es tan lejano).

Les recomiendo leer la Historia de la Computación en la Wikipedia.

Vean cuales fueron los avances a partir de 1990 y verán que la computación cambió de rumbo.

http://es.wikipedia.org/wiki/Historia_de_la_computaci%C3%B3n

De la misma forma, vean la evolución de los lenguajes en su historia.

http://es.wikipedia.org/wiki/Historia_de_los_lenguajes_de_programaci%C3%B3n http://oreilly.com/news/graphics/prog_lang_poster.pdf

Estos artículos que he publicado, de alguna forma intentan resumir cuales son en general mis temas de interés.

Algunas analogías que quiero dejar clara con estos post.

El caso de Japón y la tecnología creada por ellos me hizo pensar mucho en lo que Artech en Uruguay logró implementar en los años 90's creando lo que hoy conocemos como GeneXus.

Estar adelantados 20 años, el enfocarse en el conocimiento y no "en lo general", el basarse en mucha investigación realizadas en la época pre 90's y el lograr realizar en práctica lo que otros "ni se lo imaginaban posible", todo eso en parte es lo que define a GeneXus.

¿Que se vendrá en los próximos años?

Pienso que estamos en épocas en donde la forma de desarrollar software cambiará.
El Software está recorriendo el mismo camino que otras industrias recorrieron en el pasado, por lo que es predecible hacia donde todo se moverá.

No será de la misma forma, pero seguirán en general los mismo principios.

Al estilo Star Wars, les dejo el Link de la Parte I, en donde entenderán hacia donde quería ir con toda esta historia desde un principio.

Décadas de ideas innovadoras (Parte II)

noreply@blogger.com (David Giordano) — Fri, 14 Nov 2008 02:32:00 +0000

El post anterior (Parte I), comencé mencionando un poco sobre algunos temas que surgieron en la década de los 90’s asociado a lenguajes de programación, y lenguajes declarativos u orientados a modelos.

La idea de estos artículos era comenzar de una forma cronológica, pero al mejor estilo de George Lucas (StarWar) comienzo a contar la historia desde “Casi el Final” como para luego hacer la película que contará el comienzo de la historia.

La presión que me “auto” impuse en el momento del primer post me obligó a que esto fuera así.

Sin embargo de la misma forma que en el anterior post, vuelvo a obligarme a “postear” algo, con lo cual vuelvo a generar una “Disrupción” cronológica en el órden de los mismos.

Años previos a la segunda Guerra Mundial

En la historia de la humanidad, las guerras siempre han traído avances tecnológicos, en el caso de la primera y segunda guerra mundial, trajeron grandes avances en la ingeniería, las cuales fueron volcadas en la fabricación de productos (Revoluciones Industriales).

Principalmente, de forma previa a la segunda guerra mundial, el proceso de la fabricación industrializada no se encontraba totalmente automatizado.

Era muy extraño que en una fábrica existiera maquinaria especializada y altamente productiva.

Las pocas máquinas existentes no realizaban tareas complejas y eran de construcción muy simple (unión de componentes básicos). Por lo tanto su mantenimiento y reparación era de fácil aplicación.

Eran máquinas que generaban más producción que la que realmente se necesitaba para la época, por lo cual en ese momento se pensó que ese tipo de maquinaria producía más costos que beneficios. Fue uno de los motivos por los cuales no se difundieron rápidamente e hizo que su potencial no fuera aprovechado.

Una de las cosas que sucedía, era que si las mismas comenzaban a fallar, no era de gran prioridad su reparación, y generalmente el mantenimiento que se le aplicaba era reactivo o de reparación, no existiendo lo que se conoce como mantenimiento Preventivo y Predictivo.

Años posteriores a la Guerra

Luego de la post guerra, surgió una explosión en la demanda de los consumidores, lo que ocasionó que se comenzara a aplicar tecnología para satisfacer las necesidades de los consumidores.

Con el aumento de la demanda, muchas de las fábricas vieron “el negocio” o la necesidad de comenzar a automatizar las mismas.

Las fábricas comenzaron a crear maquinarias que automatizaban el proceso de construcción.

Con el paso de los años éstas máquinas se volvieron más complejas, y al mismo tiempo, mejoraban los tiempos de producción de forma exponencial.

En esos momentos, el objetivo de las fábricas era mejorar sus procesos para reducir los tiempos, buscando en la medida de lo posible (con la tecnología existente) automatizar la mayor cantidad de actividades pertenecientes a la elaboración.

Sin embargo con el tiempo las empresas detectaron que no era suficiente mejorar la cadena de producción, ya que existían fallos en gran parte de la cadena de proceso.

Las fallas se asociaban a la rotura continua de las maquinarias, lo cual ocasionaba grandes pérdidas por tiempo de improductividad.

A partir de ese momento, las empresas se dieron cuenta que tenían que trabajar en prevenir esos fallos a efectos de que los tiempos de improductividad sean lo más cortos posibles.

A partir de ese momento se comenzó a aplicar lo que hoy en día se conoce como “Mantenimiento preventivo”.

Increíblemente, en cuanto comenzaron a solucionar los problemas asociados con el mantenimiento preventivo, las mismas comenzaron a darse cuenta que no era suficiente.

Lo que se comenzó a implementarse para mitigar esos problemas era un estilo de “Sistema de control” muy rudimentario.

Algo surgió en ésta época, sin embargo no generó ninguna revolución en su momento.
El nacimiento de las Computadoras.

Luego de “La Guerra de las Galaxias” (Post Carrera Espacial y Guerra Fría)

En la década de los Setenta, los avances en tecnología e investigación generaron grandes cambios y revoluciones.

Gracias a esos avances, se comenzó a mejorar enormemente la mecanización y automatización.
De forma paralela comenzó a aumentar enormemente las necesidades de los consumidores.

Uno de los factores que se piensa como factor clave, es el hecho de que la humanidad comenzó a tener dependencia frente a las maquinas, ya no era humanamente posible competir contra ellas, y sin ellas ya no era posible subsistir.

Todo lo que sucedió en las décadas anteriores comenzó a incrementarse.
Se vuelven más complejas las máquinas, se realizan más tareas y se trabaja mucho más para que las mismas nunca dejen de trabajar.

Esto produce una espiral viciosa la cual obliga a que se produzca mayor cantidad de productos en tiempos cada vez menores.

Sin embargo, las fábricas comenzaron a fallar en satisfacer las necesidades de sus clientes.
Al producir más, se estaba dejando de lado cosas como la calidad, la seguridad, y la protección del medio ambiente.

De la misma forma en que aumentaba la demanda, las empresas crecían aun más, y comenzaron a crecer de forma geográfica.
Comenzaron a instalarse en regiones geográficamente distantes a su origen, con el objetivo de satisfacer necesidades de nuevos clientes.

A partir de ese momento comenzó lo que se conoce con el nombre de "Globalización".

Es así que la globalización comenzó a generar nuevos problemas.
No se gestionaba y controlaba una única fábrica, se gestionaban decenas de ellas en lugares distantes.

No solo se competía regionalmente, se comenzaba a competir a nivel internacional, con todos los problemas que esto conlleva (Idioma, regulaciones, diferentes “normas” y “Costumbres").

A lo largo de la historia, frente a cada problema detectado, las soluciones eran encontradas mediante técnica de prueba y error.

Para eliminar el hecho de “Suerte”, se comenzó a utilizar métodos científico y de investigación para poder llegar a mitigar los sucesos antes de que los mismos ocurrieran.

Estos avances han logrado que los procesos de fabricación hayan logrado altos niveles de Madurez, logrando que el proceso de fabricación cambiara para siempre.

Continuará....

¿No les suena similar toda esta historia de la industrialización con respecto a lo que está sucediendo en la industria del software en las últimas décadas?

Décadas de ideas innovadoras (Parte I)

noreply@blogger.com (David Giordano) — Fri, 31 Oct 2008 19:46:00 +0000

Los 90’s:

En la historia de la computación, y especialmente en la de los lenguajes de programación, encontrarán cómo, a partir de los años 90, son pocos los lenguajes de programación que lograron ser populares o destacarse a la fecha. La mayoría de los que se volvieron populares, se encuentran relacionados más con la simplicidad, generalidad y portabilidad que con la relación de abstracción, patrones, manejo del conocimiento o especializaciones en sectores como: manejo de Lógica de Negocio, Base de datos, Inteligencia Artificial, o lo relacionado a lenguajes Case o Lenguajes Funcionales.

Son pocos los lenguajes “exóticos” que lograron sobrevivir, y los que lo lograron, en su mayoría fue gracias al apoyo de Universidades o centros de Investigación en los sectores de Aeronautica, Astronomía, Medicina, Genética y Química (entre otros).

Sin embargo de la década de los 90’s comenzaron a surgir investigaciones en varias ramas que derivaron en lo que hoy se conoce como "Lenguajes Específico de Dominio”, “Modelado Específico de Dominio" y “Arquitectura Dirigida por Modelos” (Domain Specific Language - DSL, Domain Specific Modelling – DSM , Model Driven Architecture - DMA).

Si bien las ideas asociadas a los lenguajes de cuarta y quinta generación comenzaron en la década de los 80 y 90, la utilización de Metamodelos, Patrones, y Lenguajes de Dominio, no se han hecho de uso "popular" a nivel mundial.

En la región (Latinoamérica) existe una excepción, GeneXus, un lenguaje (y un entorno de programación) que desde la década del 90 viene revolucionado la forma de programar aplicaciones de negocio.

- GeneXus (1989) - Una herramienta con soluciones reales.

Les dejo algunas reseñas de la presentación realizada por Artech sobre GeneXus en 1995, en el marco del Premio Nacional de Ingeniería (AIU - Asociación de Ingenieros del Uruguay).

"En toda investigación, y mucho más en una de largo alcance como esta, es imprescindible "no reinventar la rueda", no perder tiempo y esfuerzo tratando de resolver problemas que otros ya han resuelto. En la informática, además, suele ser un gran error tratar de desarrollar software que se pueda comprar. En consecuencia se tomó la decisión de trabajar con PCs, los cuales y el software necesario eran accesibles a las posibilidades de un proyecto que comenzó con muy pocos recursos económicos. En consecuencia, se partió del "estado del arte", de los resultados publicados por otros investigadores, y de las mejores herramientas que estaban en el mercado. Es casi imposible obtener el éxito de otra manera. Con estos supuestos se inició en 1985 la investigación formal."
...
"Con estos resultados a la vista se hicieron contactos con varias de las mayores empresas de software del mundo. Nadie tenía nada parecido, nadie había resuelto el problema del diseño de grandes bases de datos.

Entonces parecía existir una importante oportunidad de licenciar esta tecnología a algunas de esas empresas.

El intento comercial terminó en el fracaso total por una serie de razones: la tecnología era mucho más avanzada de la que esperaban los interlocutores, que no tenían su mente preparada para ella (no la consideraban necesaria ni posible).

El problema de credibilidad del país era (es) muy serio. Era muy difícil que una empresa de alta tecnología, en un país desarrollado, pudiera entender que en el Uruguay pudiera desarrollarse una tecnología tan avanzada."
...
"se seguía investigando, se descubrió en 1986 algo muy interesante: se había sistematizado el conocimiento capturado de las visiones de los usuarios, de forma de permitir el diseño automático de la base de datos óptima, lo que cumplía los objetivos originales, sin embargo, refinando el proceso de sistematización, se podía obtener una Base de Conocimiento tal que permitiera, además de lo anterior, generar los programas necesarios para recrear visiones"
....
"GENEXUS es una herramienta diferente que, sin embargo, lucha en buena parte del mundo por un segmento de un mercado extremadamente competitivo: el de herramientas para mejorar la productividad en el desarrollo y mantenimiento de aplicaciones."
...
"El éxito de este proyecto se basa en una gran dosis de investigación permanente. El éxito comercial se basa en la superioridad tecnológica, la cual es muy difícil mantener en un mercado tan competitivo como este.

Pensamos que se está sólo en el comienzo, que probablemente se ha utilizado en GENEXUS tan sólo un 20% de la tecnología que se ha desarrollado.

Una duda existencial que hemos tenido desde el principio es: entendiendo que el camino que hemos seguido es bastante obvio, ¿por qué no hemos sido alcanzados por competidores con muchos más recursos?. Quizás el problema (y la singular oportunidad) que se enfrenta es que se está utilizando una tecnología bastante más adelantada que la de los competidores y que, por ello, no está de moda."

El texto completo se encuentra en el siguiente Link:
http://www.aiu.org.uy/gxpsites/agxppdwn?2,1,4,O,S,0,79%3BS%3B1%3B21,

Les dejo algunas referencias para los que quieran conocer un poco más al respecto sobre estos temas.

Sobre GeneXus:
http://en.wikipedia.org/wiki/GeneXus
http://www.genexus.com/
http://wiki.gxtechnical.com/commwiki/servlet/hwiki?La+historia+de+GeneXus

Sobre Lenguajes Específico de Dominio, Modelado Específico de Dominio y Arquitectura Dirigida por Modelos:
http://en.wikipedia.org/wiki/Domain_Specific_Language
http://en.wikipedia.org/wiki/Domain-specific_modelling
http://en.wikipedia.org/wiki/Model-driven_architecture

No conformarnos nunca

noreply@blogger.com (David Giordano) — Tue, 07 Oct 2008 17:40:00 +0000

La filosofía de Google se resumen en las siguientes palabras...

"No conformarnos nunca"

Lista de "Conclusiones" a las cuales arribó Google en base a su experiencia:

1. Lo más importante es pensar en el usuario.
2. Es mejor especializarse en algo y hacerlo realmente bien.
3. La velocidad es un valor seguro.
4. La democracia en la Web funciona.
5. No tiene por qué estar en su despacho para obtener una respuesta.
6. Es posible obtener ingresos actuando de forma ética.
7. Es imposible abarcar toda la información disponible.
8. La necesidad de información supera todas las fronteras.
9. Es posible ser profesional sin llevar traje.
10. No nos conformamos con unos resultados estupendos.

Comparto en gran medida los temas tratados en la lista.

Seguramente encontrarán cosas con las cuales están de acuerdo y otras a las cuales no.

Les doy el link con el detalle de cada conclusión http://www.google.es/intl/es/corporate/tenthings.html

Cuando lean el detalle llegarán a sus propias conclusiones.

Me gustaría conocer más a fondo como funciona la Fábrica de Software de Google (simple curiosidad).

Si alguien conoce algo de su interna, se agradece su aporte.

Y se hizo público...

noreply@blogger.com (David Giordano) — Mon, 06 Oct 2008 15:43:00 +0000

¡¡ Bienvenidos !!!

Hoy es un gran día.

La puesta en producción de uno de mis pendientes, mi Blog.
Di vida a este Blog en septiembre del año 2007, sin embargo no logré en ese momento consolidar fuerzas para publicar algo en el mismo...
Hoy es el día doy a luz mi primer post (un parto de 12 meses sin dolor).

Les voy a poner un poco en contexto, explicándoles el motivo del nombre del Blog.

¿De donde proviene "Moving Forward, Opening New Doors"?

Las palabras provienen de una frase célebre mencionada por alguien con quien me he identificado siempre.

"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths."
Walt Disney.

Si quieren conocer un poco más Walt, les recomiendo ver la Wikipedia en donde hay una buena reseña sobre su vida y sus hazañas. http://es.wikipedia.org/wiki/Walt_Disney

Ahora bien, volviendo al tema "Blog".

En éste blog podrán encontrar de todo tipo de cosas, sueños, "mundos ideales", noticias, sobre tecnología, programación, y claro, los problemas y soluciones que encuentre día a día en mi vida personal y profesional.

Espero que disfruten de los futuros contenidos.

Saludos

David