Wika2

Desarrollando con Flex, flexmdi, PureMVC, BlazeDS, Spring, JPA, Hibernate,... (parte 3)

2008-06-13T08:20:00.006+02:00

Aunque el artículo anterior habrá sonado un poco descorazonador, tengo que confesar que la aplicación está casi terminada. Pronto pasará a estar en producción y podremos comprobar el éxito o el fracaso -espero que sea lo primero- del producto desarrollado y de las decisiones que he ido tomando a lo largo del proyecto.

Algunas cosas que han cambiado con respecto a lo previsto:

Estoy utilizando MySQL como base de datos, para la fase de desarrollo. La aplicación en producción funcionará contra un Oracle 10g. El coste de crear una aplicación que permita seleccionar una base de datos u otra ha sido... "cero"!!! (gracias JPA).
Estoy utilizando Tomcat 5.5 como "servidor de aplicaciones", para la fase de desarrollo. La aplicación en producción funcionará sobre un Oracle Application Server (realmente un OC4J 10.1.3). En mis pruebas funciona, además, perfectamente sobre un JBoss 4.2. El coste de crear una aplicación que permita seleccionar un servidor de aplicaciones u otro ha sido... "cero"!!! (gracias J2EE).
Como entorno de desarrollo utilizo, exclusivamente, Eclipse y aunque tengo montado Flex Builder (la versión Trial) como un plugin de éste... apenas lo utilizo, al menos intento no utilizarlo. Me las apaño con Apache Ant y con las Flex Ant Tasks para compilar mi librería SWC y mi proyecto SWF. No he encontrado ninguna herramienta Open Source y/o gratuita con la que pueda desarrollar con Flex (parece mentira a estas alturas).
Del resto de los productos que pretendía utilizar, menos de la librería flexmdi (y creo que me arrepentiré de no haberlo hecho) he hecho uso de TODOS ellos. Esto se llama... puntería ;-)
Además he incorporado JasperReports y su diseñador de informes iReport para generar informes, que exporto a PDF y que muestro desde la aplicación Flex (realmente los muestro sobre el navegador web). El tema de los informes en Flex debería estar un poco mejor tratado.... debería estar tratado, al menos.
Una ayuda muy especial para depurar nuestro código es ThunderBolt, una extensión para "tracear" aplicaciones Flex sobre la consola de Firebug del "add-on" para Firefox.

Desarrollando con Flex, flexmdi, PureMVC, BlazeDS, Spring, JPA, Hibernate,... (parte 2)

2008-06-13T08:03:00.005+02:00

Después de 2 meses sin dar señales de vida he querido, al menos, escribir sobre la marcha de mi primer proyecto Flex. La verdad es que con esta experiencia estoy teniendo sentimientos contradictorios según el día.

Hay días que me digo: "que bueno haber descubierto Flex". Hay otros que me desconsuelo y me digo: "en qué demonios estaba yo pensando cuando me metí en esto de los RIAs".

Creo que el principal problema es que había puesto demasiadas expectativas.

No nos engañemos, el desarrollo de RIAs era ya posible, estaba en nuestra manos, desde el principio de los tiempos.

No nos engañemos el desarrollo de RIAs para la web estaba en nuestras manos desde los primeros días JAVA, mediante la creación de applets que hacían uso del vetusto API AWT. Yo he visto hace más de 10 años aplicaciones, incluso participado en ellas, alucinantes, que no tenían nada que envidiar a las actuales aplicaciones Flex.

Flex ha venido a recordarnos que esto es posible, mejora un poco -faltaría más- las dificultades que nos encontrábamos con el AWT y añade bonitas animaciones y sombras a nuestros componentes.

Respecto a esto, creo que Flex está poniendo mucho más énfasis en que podamos cambiar los estilos y las "pieles" de nuestras aplicaciones y componentes, hasta extremos innecesarios, que el potenciar aquello que realmente nos hace la vida más fácil a los desarrolladores de productos para la web. Creo que deberían buscar un equilibrio...

Desarrollando con Flex, flexmdi, PureMVC, BlazeDS, Spring, JPA, Hibernate,... (parte 1)

2008-04-19T09:59:00.007+02:00

Estoy desarrollando mi primera aplicación con Flex y quería ir comentando mis "desavenencias" en este blog, por si os sirve -o me sirve a mi- de algo, en un futuro, mi experiencia.

El "producto" es una sencilla aplicación Flex que, previa autenticación del usuario y una vez comprobados sus privilegios, nos permitirá mantener la información guardada en una base de datos, mediante sencillos formularios.

El primer problema es encontrar el conjunto de herramientas que me van a acompañar en el desarrollo de este producto. Esta es mi lista, creo, definitiva:

Base de datos: aunque trabajo normalmente con Oracle, el producto podrá funcionar con cualquier base de datos del mercado para la que tengamos un driver JDBC disponible. Es decir, casi todas las existentes o conocidas.
Servidor de aplicaciones: casi toda la lógica de negocio de mi aplicación correrá del lado del servidor. He decidido, de momento, por aprovechar al máximo mi conocimiento en este campo, trabajar con la plataforma J2EE. El servidor de aplicaciones que utilizaré es JBoss, pero la aplicación funcionará en cualquier otro servidor, compatible J2EE, sin dificultad. Incluso, lo haré funcionar en un sencillo contenedor Apache Tomcat.
Como herramientas de desarrollo, seleccionaré Eclipse y me aprovecharé, también, de la ventaja que supone poder utilizar el Flex Builder en modo trial durante unos meses.
Para acceder a la base de datos y desarrollar la lógica de negocio más dura, del lado del servidor, he decidido utilizar la siguiente combinación: algunas clases del proyecto AppFuse (más concretamente la appfuse-jpa.jar y la appfuse-service.jar), el framework Spring y finalmente como implementación de JPA (persistencia Java) he seleccionado Hibernate (pero servirían también Toplink u OpenJPA).
Para acceder desde Flex a los POJOs, los POJOs que desarrollaré del lado del servidor de aplicaciones, me he decidido por BlazeDS, por su madurez y potencia accediendo a objetos remotos. Además integraré BlazeDS con Spring de forma muy sencilla, con una factoría especial (llamada SpringFactory)... ya os contaré cómo. Esta factoría está disponible dentro de otro proyecto de integración llamado "RemoteDestination annotation for Spring".
He decidido utilizar para la parte cliente (la desarrollada con Flex) un framework para construir aplicaciones basadas en el modelo MVC (model-view-controller). He seleccionado PureMVC, que tiene un "port" para Flex y que, aunque al principio me ha costado entender su funcionamiento, creo que le sacaré bastante provecho.
Seguramente utilizaré, a futuro, múltiples librerías SWC. de momento me he descargado la flexmdi (no puedo vivir ;-) sin crear ventanas en modo MDI en mis aplicaciones). Quizá la utilicé o quizá no, ya veremos.
Por supuesto, necesitaré el SDK de Java (una versión 5.0 ó superior) y el SDK de Flex (una versión 3 o superior).

Intentaré dejar en algún sitio, próximamente, un esqueleto de aplicación con todo esto en un paquete, para que sea más fácil empezar con el desarrollo.

Trabajar con ficheros XML, diferentes opciones

2008-04-09T18:15:00.004+02:00

Como sabéis, los más potentes validadores XML y transformadores XSLT son los navegadores que tenemos instalados en nuestros equipos: IE, Firefox, Opera, etc.

Arrastrando sobre ellos un XML nos lo validan, nos lo transforman (si hay un XSLT asociado), nos lo muestran en forma de árbol, nos permiten navegar por sus nodos, etc.

No necesitamos instalar nada para ello!!!

Si no es suficiente:

Editores XML:

1. ECLIPSE: de serie incluye un sencillo editor XML, pero podemos "pegarles" otros más potentes mediante plugins, como el XMLBuddy.

Ver: http://www.eclipse.org
Ver: http://xmlbuddy.com/2.0/products.html

2. FOXE: muy sencillo (para instalar con un simple zip), consume muy pocos recursos y más que suficiente, la mayor parte de las veces. Yo lo utilizo mucho.

Ver: http://www.firstobject.com/dn_editor.htm

3. WMHELP XMLPAD: un poco más potente que el anterior.

Ver: http://www.wmhelp.com/download.htm

4. Y de pago tenemos... OXIGEN y ALTOVA XMLSPY: son dos de los productos más maduros, famosos y profesionales del mercado.

Trabajar con XML (fundamentalmente con APIs JAVA) :

1. Java incorpora un API (JAXP) en su JVM para trabajar con ficheros XML.

2. También son muy interesantes los proyectos XALAN y XERCES de Apache, que tienen "ports" en Java y en C++.

3. A mi, personalmente, me gusta mucho DOM4J (http://www.dom4j.org) que es el que yo utilicé, en su día, para los proyectos de la empresa donde trabajo.

4. Uno de los APIs Java más interesantes lo proporciona, también, Apache en su proyecto commons-digester (http://commons.apache.org/digester). Este API te permite mapear ficheros XML a clases Java.

Este proyecto es utilizado internamente por muchos de los productos con los que trabajamos, día a día, y que utilizan XML como ficheros de configuración, por ejemplo.

5. Hay más: JDOM (http://www.jdom.org), Jaxen (http://jaxen.org) que es un motor XPath, etc.

Generar ficheros XML en nuestras aplicaciones:

DOM4J y JDOM (y otros) permiten generar ficheros XML mediante la exportación a texto (por ejemplo) de documentos XML que vamos generando con estos APIs: creando el objeto documento, generando los nodos, enganchándolos al documento (o a otros nodos) y luego "serializando" este objeto documento a un fichero de texto.

A veces resulta tedioso y es más sencillo generar un fichero de texto, como un fichero de texto más de los que genera nuestra aplicación, que cumpla con las reglas de un fichero XML (claro está).

Proyectos, gestión, gestores y programadores

2008-03-26T11:24:00.000+01:00

Me he encontrado un libro gratuito y en castellano, en:

http://escolaxaviersoto.org/edicions/E3.pdf

Se llama "Dirección de grupos y reuniones. Gestión del tiempo."

Así que, creo que, NO nos interesa mucho ;-) no sea que empecemos ahora a hacerlo bien (lo de dirigir grupos, dirigir reuniones y gestionar el tiempo).

Además os invito a leer este otro pequeño artículo (me ha resultado interesante por expresar una teoría tan "real como la vida misma" de forma tan sencilla):

http://www.navegapolis.net/content/view/761

Según esta teoría, los proyectos que solo necesitan previsión de fechas y costes requieren de metodologías más tradicionales, con gestores que controlen a su equipo y den "palos" y con programadores a los que NO les guste su trabajo (que lo hagan solo por dinero, vamos).

Sin embargo, los proyectos que se preocupan realmente por el VALOR del producto requieren de metodologías más ágiles, con gestores que velen por su equipo y realmente comprometidos y con programadores que trabajen en "esto" por algo más que por dinero (porque realmente les guste su trabajo).

Traduciendo el framework de Flex a otros idiomas: catalán, francés, etc.

2008-03-24T09:08:00.007+01:00

En mi artículo anterior dejé pendiente comentar cómo había conseguido traducir el framework del Adobe Flex SDK 3 al español. En este nuevo artículo os intentaré comentar los pasos, de forma sencilla, que yo realicé, para que podáis hacer vuestras propias traducciones:

Lo más sencillo es tomar como punto de partida una localización de las disponibles (la del inglés que aporta Adobe en su SDK o la del español que os dejé la semana pasada). Están en el directorio <sdk_home>/frameworks/locale. Así que lo mejor es hacer un "copy-paste" de la carpeta que más os guste y renombrarla con el código del nuevo idioma a traducir (por ejemplo "ca_ES" para el catalán, "fr_FR" para el francés, etcétera).
Dentro de la carpeta encontraréis 3 ficheros con extensión ".swc". Debéis cambiarle la extensión por ".zip" y descomprimirlos cada uno en una carpeta diferente.
Cada carpeta tiene 3 elementos diferenciados: una nueva carpeta de nombre "locale", un fichero "catalog.xml" y un fichero "library.swf".
Editaremos el fichero "catalog.xml" cambiando toda referencia a la localización que hemos tomado como base por los códigos de nuestra nueva localización. Están todas al final del fichero dentro de una etiqueta <files>
Después debemos ir a la carpeta "locale" (al mismo nivel que el fichero "catalog.xml" anterior) y renombrar la subcarpeta que hay dentro de ella con el nuevo código del idioma que estoy traduciendo.
Dentro de esta subcarpeta hay varios ficheros, que son los que realmente debo traducir. Son ficheros de textos (recomiendo que el formato usado para estos ficheros sea el UTF-8 o tendremos problemas con acentos y demás caracteres "extraños") no muy extensos y, creo que, sencillos de traducir. Atentos a la configuración de fechas y formatos numéricos, también configurables desde estos ficheros de texto.
Finalmente, cuando tenga todos los textos ya traducidos, debo volver a comprimir la carpeta que descomprimí en el punto 2 y cambiarle la extensión por su extensión original ".swc".
Debo seguir todos estos pasos para los 3 ficheros ".swc" originales.
Y finalmente... ¡ya tenemos el Flex SDK 3 traducido a nuestro nuevo idioma!

Como os decía en el artículo anterior, simplemente añadiendo la siguiente opción al compilador "-locale ca_ES" (por ejemplo) tendréis resuelto el asunto... al menos, el asunto catalán ;-)

Creo que también se pueden especificar varios códigos al compilador separados por comas (o espacios) de la forma "-locale ca-ES, fr_FR" y luego desde código activar uno u otro al vuelo.

También podéis modificar el fichero <sdk_home>/frameworks/flex-config.xml para activar esta localización como la localización por defecto de vuestras compilaciones (es sencillo encontrar el lugar).

Flex y locale es_ES... por fin, Flex en español!

2008-03-21T11:28:00.005+01:00

Nunca entendí el motivo por el que Adobe no incorporaba al SDK de FLEX la localización en múltiples idiomas (solo lo hace para el inglés y creo que también para el japonés).

Pensaba que era por no disponer todavía de versiones definitivas del SDK... pero, no hemos mejorado en nada tras la liberación del SDK 3.

Esto hace que la localización de nuestras aplicaciones Flex se vea dificultada, al no poder traducir los mensajes (de validación y formateo, por ejemplo) convenientemente a nuestro idioma.

¡Pues al final, buceando por la web de Adobe, un poco por Google y con un poco/bastante de esfuerzo por mi parte, he conseguido resolver el problema!

En el siguiente enlace FLEXSDK3-framework-locale-es_ES.zip
os dejo un .zip que podéis descomprimir en el directorio de vuestro SDK (primero creáis un directorio "es_ES" dentro del directorio "frameworks/locale" y luego copiáis allí los tres ficheros .swc que os dejo dentro del .zip) y simplemente añadiendo la siguiente opción al compilador "-locale es_ES" tendréis resuelto el asunto... al menos, el asunto español ;-)

También podéis modificar el fichero <sdk-home>/frameworks/flex-config.xml para activar esta localización como la localización por defecto de vuestras compilaciones (es sencillo encontrar el lugar).

También podemos activar esta localización en el Flex Builder 3, que realmente utiliza un SDK que viene dentro del directorio "sdks" donde esté instalado este impresionante entorno de desarrollo.

En un próximo artículo os cuento como lo he conseguido y como activar múltiples idiomas en vuestras aplicaciones.

Generación de informes

2008-03-14T13:45:00.004+01:00

Ampliando el artículo anterior sobre la generación de charts, voy a recomendar también algunas herramientas o APIs que he utilizado en la generación de informes de mis aplicaciones:

a) Para la generación de códigos de barras:

Barbecue: http://barbecue.sourceforge.net

b) Generación de informes y generación de PDFs:

iReport: http://www.jasperforge.org/sf/projects/ireport
iText: http://www.lowagie.com/iText

c) Generación de otros documentos en formato Word, Excel u OpenOffice:

POI: http://poi.apache.org
OpenOffice API: http://api.openoffice.org

Espero que ambos dos artículos os sean de utilidad,

Generación de gráficos estadísticos o charts

2008-03-14T13:33:00.005+01:00

He recopilado, esta mañana, cuatro categorías de posibilidades para cubrir el requisito de la "generación de gráficos estadísticos (o charts)" en nuestras aplicaciones:

a) Generarlos en el cliente (navegador) con Javascript. Ej:

PlotKit: http://www.liquidx.net/plotkit
Plotr: http://solutoire.com/plotr
JFlot: http://moblur.org/workshop/jflot_intro
Otros: en este bloq hay una relación, también muy interesante.

b) Generarlos en el cliente (navegador) en formato SWF (Flash), resultan super-atractivos. Ej:

amCharts: http://www.amcharts.com
Open Flash Chart: http://teethgrinder.co.uk/open-flash-chart

c) Mediante el uso de APIs JAVA (permite integración con JSF). Ej:

JFreeChart: http://www.jfree.org/jfreechart
JCharts: http://jcharts.sourceforge.net

d) Mediante un servlet que podamos invocar directamente desde mis tags <img>. Ej:

Google charts: http://code.google.com/apis/chart
EastWoord: http://www.jfree.org/eastwood

Adobe Flex 3.0 y Adobe AIR 1.0 ya disponibles

2008-02-25T08:26:00.007+01:00

El título lo dice todo. ¡Por fin ha llegado el gran día!

Flex Builder 3.0 en: http://www.adobe.com/products/flex
Flex SDK 3.0 en: http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK
AIR 1.0 en: http://www.adobe.com/products/air
Blaze DS (la última versión disponible) en: http://opensource.adobe.com/wiki/display/blazeds/BlazeDS

Además, no dejes de pasarte por el portal "Adobe Open Source". En él se mostrarán las actividades emprendidas por Adobe para la comunidad: http://opensource.adobe.com

¡Enhorabuena al equipo!

Programa y llora

2008-01-31T08:04:00.000+01:00

Desde hace meses estamos, en mi empresa, inmersos en un proceso de valoración de los puestos de trabajo (VPT) que componen el departamento de informática donde trabajo.

Básicamente se trata de adecuar los salarios a las tareas, responsabilidades, habilidades, capacidades, etc. que ponemos a disposición de nuestros usuarios/clientes.

Tengo que comentar, antes que nada, que trabajo como programador para la Administración. Sí, soy funcionario, pero... esto no es óbice para que tenga sentimientos!!!

Siempre me ha gustado el término "programador". Es un término lleno de romanticismo, pero hoy en día... poco valorado. Bill Gates, Paul Allen, Steve Jobs, Larry Ellison, Linus Torvalds, Richard Stallman, etc. seguro que se sienten orgullosos de decir que son, simplemente: programadores.

Pues en mi empresa, tras esta valoración realizada por una empresa consultora en RRHH de prestigio, de la zona donde trabajo, hemos decidido cambiar el término "programador" por el de "Técnico Medio en Informática". Triste, muy triste, pero... nos hemos visto obligados.

El resultado del informe, que esta empresa realizó, nos "dibuja" como profesionales con una iniciativa en la misma línea que el resto de los trabajadores de la "casa", sin un especial interés por estar formándonos continuamente (parece que no lo necesitamos para desarrollar nuestro trabajo), el grado de influencia de nuestros errores es bajo, tampoco realizamos un trabajo que requiera un gran esfuerzo mental y, además, es bastante fácil que cualquier persona con una experiencia similar a la nuestra se adapte al puesto y realice las mismas tareas que yo realizo y de forma adecuada.

Vamos que casi somos un fraude.

Yo, de momento, voy a intentar que me publiquen el libro Programa y llora (de la Editorial O'reilly) y, así, comprobar si puedo ganarme la vida mejor de este modo ;-)

Cambiando el estilo visual de una aplicación Flex

2008-01-29T11:01:00.000+01:00

El estilo visual, por defecto, de una aplicación Flex es bastante bonito: ventanas con esquinas redondeadas, sombras, degradados, transiciones, etc.

Si bien, al final todas nuestras aplicaciones parecerán iguales. Esto puede ser bueno para los usuarios, que llegan a reconocer, a la primera, una aplicación y por intuición ya saben como manejarla... pero, para los desarrolladores o creadores, esto, hace de su tarea de creación algo aburrido y tedioso.

Para modificar el estilo de los componentes Flex de nuestras aplicaciones podemos hacer uso de CSS (sí, una cosa menos que aprender) y así cambiar la forma y color de nuestros botones, grids, selectores de fechas, etc.

Es tan fácil como poner al principio de nuestro documento mxml la siguiente línea de código:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Style source="myStyle.css"></mx:Style>
</mx:Application>

Aún así, nos queda el trabajo de diseña un estilo propio y bonito... pues aquí viene en nuestra ayuda la siguiente aplicación (desarrollada íntegramente en Flex y de la que podemos ver, incluso, su código fuente): Style Creator

Visualmente podéis editar el cómo os gustaría que quedasen vuestros componentes Flex y finalmente pulsar el botón "Download CSS", que os descargará el fichero CSS a utilizar en vuestra aplicación. Espero que disfrutéis de ella,

Integrando Flex con .NET

2008-01-23T09:28:00.000+01:00

Piensa en una aplicación web "enriquecida" sin acceso a información corporativa (bases de datos, servicios web, otros recursos corporativos, etcétera).

Es como pensar en un huevo sin yema (queda muy soso).

Para desarrollar este tipo de aplicaciones, con Flex, teníamos que:

Desarrollar servicios http o servicios web y manejarlos directamente desde Flex.
Acceder a objetos remotos mediante el Live Cycle Data Services (LCDS), que es un producto de pago (creo que $20,000 US por CPU) de Adobe y que además funciona como una aplicación sobre un servidor de aplicaciones J2EE (tipo JBoss, Tomcat, Apache-Geronimo, Glassfish, etc.)

Hace meses Adobe liberó un nuevo producto, llamado BlazeDS, que ofrece acceso gratuito a alguna de las características de LCDS, como acceso remoto a Java usando el protocolo AMF.

Este producto, BlazeDS, también funciona como una aplicación sobre un servidor J2EE.

Parecía que solo íbamos a poder acceder a nuestros recursos corporativos desde una aplicación Flex si disponíamos de una plataforma J2EE... dejando a la plataforma .NET huérfana de estos servicios.

Pues esta importante carencia es la que viene a cubrir FluorineFX:

Flex, Flash Remoting (RPC)
Flex Messaging (parcialmente)
Flex Data Services (parcialmente)
Soporte de protocolos AMF0, AMF3 y RTMP
Servicios de navegador
Generador de código basado en plantillas (sintaxis similar a ASP.NET)
Fácil integración con Adobe Integrated Runtime (Adobe AIR™)

Parece que ya tenemos yema para todos nuestros huevos!!!

Elementos de colaboración de equipos

2008-01-14T09:11:00.000+01:00

He encontrado una tabla periódica de elementos de colaboración. Son los 74 elementos de colaboración identificados para mejorar tu equipo de trabajo, la productividad y la creatividad.

Ver más en:

http://www.mindquarry.com/community/articles/elements-collaboration

Estos patrones (o elementos) están agrupados en 4 categorías:

* Gente
* Herramientas
* Software colaborativo
* Métodos

Propongo no documentar

2008-01-03T20:06:00.000+01:00

Ya no se recomienda la documentación de los elementos que intervienen en un proyecto fuera del propio elemento.

Unos cuantos miles de los nuevos filósofos/pensadores que han surgido alrededor del proceso de desarrollo de proyectos software están de acuerdo conmigo. Es en serio.

Cada parte de un proyecto (programas, modelos de datos, etc.) debe estar autodocumentada. Si documentamos un elemento fuera de éste... lo más normal es que, pronto, la documentación quede "desalineada" con lo documentado. Fundamentalmente, por lo costoso de mantener dos cosas tan alejadas (la técnica y la documentación) a la vez y alineadas.

Ya ha quedado demostrado empíricamente que la documentación no conlleva ningún beneficio y además tiene un coste importante. Lo que ahora está de moda es la "agilidad" y la documentación no aporta nada en beneficio de esta "agilidad".

Además, a los programadores no nos gusta documentar, es un hecho, así que dejamos esta aburrida tarea siempre para el final (cuando ya nos viene "pisando los talones" un nuevo proyecto mucho más interesante) y por ello no nos la tomamos en serio y la "salvamos" como podemos.

Y ¿qué hay peor que algo no documentado? Algo mal documentado.

La siguiente pregunta refuerza más lo que digo ¿cuántas herramientas de ayuda a la documentación de proyectos software conocéis, de memoria, que mantengan versiones actualizadas y que no estén ancladas en técnicas de los años 80? (no vale decir el word, la excel o el notepad).

Actualmente, casi todos los nuevos lenguajes de programación permiten al programador autodocumentar mientras programa. Parte de esta documentación tiene "coste cero" porque hay herramientas que extraen información del propio código y generan la documentación. Así para que alguien tenga una versión actualizada solo necesita pedirle a la herramienta que se la genere ¿chachi, no?

Lo que creo es que: deberíamos esforzarnos en hacer las cosas lo más sencillas posibles, autodocumentadas/autoentendibles, utilizando "modos" conocidos y aceptados por todos. Que todos tengamos las habilidades suficientes para entender esos "modos" de forma natural (sin depender de otros elementos), que esos "modos" estén escritos (no documentados) en la forma de un reglamento básico (que dice cómo se deben hacer las cosas) y que, además, este reglamento básico se alteré lo menos posible a lo largo del tiempo.

Y, por supuesto, que todos sigamos ese reglamento básico, nos guste mucho o poco, como si fuesen mandamientos divinos (no se cuestionan... se acatan, simplemente).

Un API de Google para generar fácilmente gráficas

2007-12-15T09:45:00.000+01:00

Google ha sacado un nuevo servicio (dicen que es un API, pero realmente a día de hoy es solo un servicio en pruebas) que permite generar gráficas (de barras, de tartas, etc.) mediante el lanzamiento de una petición por URL a uno de sus servidores.

Ver un ejemplo:

http://chart.apis.google.com/chart?cht=p3&chd=s:hW&chs=250x100&chl=Hello |World

Existe un API con el que, mediante parámetros a esta URL, se pueden generar multitud de gráficas (que el servidor te devuelve como una imagen en formato PNG) para incorporar a tus webs.

Ver la documentación del API en: http://code.google.com/apis/chart/

El problema es que Google no ha liberado este desarrollo y hay que depender de la disponibilidad del servidor de Google (al que además le puedes estar enviando información sensible que el va a guardar).

Solamente atiende 50.000 peticiones al día por usuario :-)

Pues bien, no han tardado en clonar este servicio y crear una aplicación para que cualquiera de nosotros (con un simple Tomcat) podamos montar un servicio de chart compatible con el de Google.

La empresa que nos "dona" este desarrollo es de reconocido prestigio, es la autora del API JFreeChat, y el proyecto, en concreto, se llama Eastwood.

Ver más en: http://www.jfree.org/eastwood

Google se "saca de la manga" un Android

2007-12-15T09:43:00.000+01:00

Google ha lanzado una nueva tecnología para el desarrollo de software para dispositivo móviles, llamado Android, que está revolucionando estos días los foros de desarrolladores (por lo que supone de ruptura con los actuales APIs de desarrollo para estos dispositivos).

La fuerza de Google hace que ya tenga apoyos de compañías como T-Mobile, Teléfonica, HTC, Motorola, etc.

Lo interesante es que, si a lo largo del 2008 presentáis un proyecto "guapo" utilizando esta tecnología (hay un SDK y un plugin para Eclipse) podéis optar a 10.000 dolares en premios.

Ver más en: http://code.google.com/android/adc.html

Oracle elige Flex

2007-12-15T09:42:00.000+01:00

Parece que Oracle ha apostado por Flex, la tecnología de Adobe para el desarrollo de aplicaciones web "RICAS" (RIA).

Por lo visto, ya tiene versiones de Metalink, del Enterprise Manager y de otros productos desarrollados con esta tecnología.

Ver más en este interesante blog del "Cowboy de los RIA":

http://www.jamesward.org/wordpress/2007/11/12/oracle-chooses-flex-part-1

Estrés y conflictos con nuestros usuarios

2007-11-16T08:00:00.000+01:00

¿Cuál es el origen de los dos principales problemas que aparecen en nuestros departamentos de informática (sobrecarga de trabajo ¿estrés? y conflictos con nuestros usuarios)?

He identificado una relación, que puede ser ilustrativa:

No hay una clara relación de responsabilidades
Asignación de tareas poco homogéneas
La trampa de la asignación de tareas por porcentajes
Falta de gestión de proyectos
Falta de planificación
El problema de los recursos infinitos
Mala gestión de los imprevistos previstos
No hay uniformidad (visión conjunta) en la forma de abordar proyectos
Mala gestión del conocimiento
Procesos poco claros, desconocidos o no comunicados
Pensamos demasiado en clientes con nombres y apellidos
Interrupciones imprevistas pero poco importantes
El "si no lo hacemos malo, si lo hacemos... peor"
Los objetivos estratégicos a largo plazo no se abordan convenientemente
Procesos de aprobación inexistentes, insuficientes o mal definidos
Estimaciones pobres o planificación super-optimista
Inadecuada visibilidad del estado de cada proyecto
Inadecuada o no clara relación de las prioridades, del proyecto, y en la gestión de las mismas

Sin embargo, creo que nosotros tenemos pendiente, el adquirir más habilidades en la gestión de los proyectos y que ahí está parte del problema (al menos de los problemas que en nuestras manos está solucionar).

Para que podamos adquirir alguna habilidad más, dejaré un enlace a un documento:

http://www.4shared.com/file/22860361/c448caa5/PMBOK.html?dirPwdVerified=b64de899

en castellano y de interés para todos nuestros gestores de proyectos.

Se trata de una guía estándar (IEEE Std 1490-2003) que provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de proyectos, incluyendo construcción, software, ingeniería, etc.

He descubierto que incluso existe una certificación para el "Gestor de Proyectos" -la PMP- reconocida internacionalmente.

Señalando a la gestión de proyectos

2007-10-26T08:52:00.001+02:00

En todo departamento, que se precie, involucrado en el desarrollo de productos software, aparecen siempre problemas asociados a la falta de motivación y de satisfacción de los profesionales de las TI.

Muchos de estos problemas tienen un relación directa con el fracaso de los proyectos en los que éste personal está participando.

Algún día los tecnólogos involucrados en estos proyectos nos levantaremos y diremos toda la verdad sobre lo que pensamos respecto a la gestión de proyectos (o al menos sobre lo que pensamos que se está haciendo hoy en día).

De momento quizá os ayude, para comenzar a meditar, la siguiente URL que he encontrado:

http://itfact.blogspot.com/2007/10/10-warning-signs-of-project-failure.html

En ella se habla de... el problema fundamental del fracaso de los proyectos TI está relacionado con la mala gestión y planificación de los mismos y nunca es resultado de la tecnología. Como yo soy simplemente un tecnólogo esta afirmación la elevo a los altares :-)

¿Qué señales se identifican? (a ver si nos suenan): falta de apoyo ejecutivo, cambios continuos en el alcance del proyecto, falta de gestión del cambio, no establecer las expectativas de forma clara con el cliente, plazos poco realistas, requisitos indefinidos o mal definidos, falta de planificación, falta de participación de los interesados, etc.

Planning Poker

2007-10-26T08:47:00.000+02:00

Uno de los aspectos más importantes para asegurarnos el "éxito" en nuestros proyectos es... la estimación.

Otro aspecto es hacer divertida la propia gestión del proyecto (para mi incluso más importante que la anterior).

Os dejo un par de enlaces de esta nueva técnica que está haciendo furor (por lo simpática) en los foros sobre desarrollo ágil de proyectos: es la llamada "Plannig Poker".

http://www.codinghorror.com/blog/archives/000981.html
http://www.planningpoker.com
http://www.crisp.se/planningpoker

Aunque no lo parezca es una técnica que, aún siendo divertida, es bastante seria y tiene hasta su propia literatura (a mi me parece buenísima).

Siguiendo el último enlace se puede comprar el juego de cartas "real" para comenzar a estimar.

Si mezclamos esta técnica con el "Strip Poker" (el que falla se quita una prenda) esto puede ser la bomba!!!

¿Es Adobe FLEX flexible?

2007-09-21T14:42:00.000+02:00

Ahora mismo veo a FLEX como "algo" ilusionante/refrescante, que ha entrado en este aburrido, hasta ahora, mundo del desarrollo de aplicaciones web.

Por fin, verdaderos interfaces de usuario ricos (e interactivos y bonitos), pero...

A día de hoy tengo la sensación que FLEX es una tecnología poco madura, no muy extendida y que tiene un largo camino por recorrer.

Es decir, mi duda es ¿acometer proyectos con FLEX es hoy en día arriesgado? ¿Puedo presentarlo a mis clientes como una tecnología sólida y pedirles que apuesten -ellos ponen el dinero- por ella?

En mi opinión Adobe tendría que aprender de la historia de Java (que yo conozco desde sus inicios) ya que creo van a ser dos tecnologías que pueden tener historias parejas (con una diferencia de 15 años, claro está).

Ya sé que Adobe no es SUN (SUN vende máquinas, pero hoy vende más máquinas gracias a JAVA) ya que se dedica solo a vender software pero, debería repensar (si queremos que FLEX llegue a algún sitio y si quiere mantener la pugna con Microsoft/Silverlight y con SUN/JavaFX) en liberar su entorno de desarrollo.

Hoy en día no tiene mucho sentido pagar 500 EURs por él y lo hará (liberarlo) seguro en un futuro o, quizá también, aparecerá otro que lo haga por él.

Sería algo bueno para FLEX que lo hiciese ya mismo para que la expansión de esta tecnología sea mucho mayor y rápida.

Pienso que lo mismo debería ocurrir para sus "LiveCycle solutions" ya que no tiene mucho sentido pagar por un producto que simplemente me permite conectarme con objetos de mi servidor de "negocio" o para generar gráficos o para generar PDFs.

Digamos que si FLEX, en mi modesta opinión, no me proporciona estas funcionalidades básicas y solo se consiguen mediante otros productos (y no baratos, claro) es como si se quedase un poco "cojo" para emprender esta carrera ¿no?

RIA (Aplicaciones Ricas de Internet) con más ventajas que las tradicionales aplicaciones Web

2007-09-21T14:35:00.000+02:00

¿De qué se habla estos días en los foros tecnológicos del "mundo mundial"?

Del "tan manido" RIA o enriquecimiento de las aplicaciones web... o cómo hacer de la web un verdadero escritorio de aplicaciones ricas en su interface, intuitivas y realmente interactivas.

La verdad es que en ninguno de estos foros se habla de JSF :-( tecnología que uso hace varios meses y a la que el equipo de desarrollo de mi empresa se ha "comprometido" para los próximos años (junto con facelets, jpa, hibernate, etc.) y de la que ya os comentaré otro día.

Sí se habla desde hace tiempo de AJAX, pero... ya casi esta tecnología está pasada de moda (que suerte no haberla considerado en su momento). Estos días lo que "mola" es hablar de Flex (Adobe), Silverlight (Microsoft) o JavaFX (Sun) y como una de estas tecnologías sobrevivirá y hará nuestras delicias como usuarios y como desarrolladores de aplicaciones.

Enlaces:

http://www.adobe.com/es/products/flex
http://www.openlaszlo.org (Laszlo es otra implementación Open de Flex)
http://www.microsoft.com/silverlight
http://java.sun.com/javafx
https://openjfx.dev.java.net

Algunos ejemplos (por favor, no os los perdáis)!!!

http://www.adobe.com/devnet/flex/?tab:samples=1
http://www.openlaszlo.org/demos
https://openjfx.dev.java.net

SCRUM y la vida en la oficina

2007-09-21T14:26:00.000+02:00

Durante estas vacaciones me he dedicado a hacer un poco de deporte... es decir, he estado todo el día tumbado en la playa, leyendo de "aquello" que no puedes leer durante el resto del año.

Han pasado por mis manos algunos libros/lecturas interesantes que os quiero recomendar (sobre todo, el primero):

a) Scrum y XP desde las trincheras: es un libro gratuito, en inglés y en formato PDF, que habla sobre SCRUM.

SCRUM es una metodología (o framework, mejor dicho) para el desarrollo ágil de productos y sobre la gestión del tiempo en proyectos/equipos de software.

La verdad es que suena bastante "divertida" y diferente a lo visto hasta ahora (¿alguien se acuerda ya de METRICA?). Algunos conceptos son muy interesantes, fáciles de entender y poner en marcha en equipos nuevos (si son nuevos y "quemados"... no sirve y entonces es mejor pasar al libro que os recomiendo en el punto siguiente).

El libro es gratuito, ya lo he dicho, y descargable en:

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Pero también os recomiendo los siguiente enlaces sobre SCRUM:

http://es.wikipedia.org/wiki/Scrum
http://en.wikipedia.org/wiki/Scrum_(development)
http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx
http://www.chuidiang.com/ood/metodologia/scrum.php
http://scrumforteamsystem.com

Y el sitio oficial de SCRUM: http://www.controlchaos.com

Algo interesante es que como herramientas básicas se utiliza una EXCEL, un WIKI, un BugTracker y (lo más alucinante) una ventana grande de cristal y unos post-its!!!

En esta metodología, por ejemplo, se habla de cerdos y pollos o gallinas. Los cerdos son aquellos que realmente están comprometidos en el proyecto, son los responsables de llevarlo a cabo y serán medidos en su desempeño profesional por los resultados del proyecto. Las gallinas son aquellos que aún estando involucrados en el proyecto y teniendo interés en él y mucho que aportar... no están directamente involucrados en llevarlo a cabo. ¿Qué quieres ser, cerdo o gallina?

Y debe ser divertida de verdad, porque tiene hasta una web que le dedica tiras cómicas: http://www.implementingscrum.com/cartoons

b) Mi segunda lectura ha sido "Los muertos vivientes de David Bolchover". Tiene capítulos también realmente divertidos (por ejemplo, el de las estadísticas sobre la práctica de sexo en la oficina). Habla de la "escandalosa verdad sobre la vida en la oficina". Más en:

http://cesaralonso-comunica.blogspot.com/2007/04/los-muertos-vivientes-la-escandalosa.html

c) Mi tercera lectura ha sido "El libro negro del emprendedor de Fernando Trías". Identifica los puntos clave de fracaso a los que se enfrenta un emprendedor y que sirven para detectar si uno lo es o no lo es. Yo he detectado que no lo soy (un emprendedor), así que voy a releer el anterior libro sobre lo aburrida que es la vida en la oficina ;-)

¿Tu proyecto "aguanta el tipo"?

2007-09-21T14:21:00.000+02:00

Cómo si de un combate de boxeo se tratase, pondremos a prueba nuestros proyectos identificando las 101 formas de saber si está condenado (al fracaso, entiendo).

Lee el 30, por ejemplo, dice: su encargado/director pierde 7 horas a la semana pidiendo informes sobre la marcha de los trabajos.