sábado, 12 de diciembre de 2009

El trabajo ya no es divertido

No se trata de divertirse en el trabajo. Se trata de que el trabajo sea divertido, que te haga realmente feliz venir a trabajar.

Divertirse en el trabajo es más o menos sencillo: disfrazarse un día a la semana, contarse chistes, hacerse bromas, mofas, burlas, intentar ligar con los compañeros, etc. Hay muchas empresas que incluyen juegos en el trabajo: dardos, canastas, futbolín, saltar en el suelo sobre unas celdas pintadas con tiza (cada vez que se pasa, de forma obligatoria), etc. Hay empresas que utilizan "quedadas" grupales de los equipos, para fortalecerlos: quedan para ir de tapas, de cena, para hacer paintballs, hacen un día de convivencia juntos en el campo, etc.

Yo no me refería exactamente a esto, aunque estas técnicas se pueden utilizar con otros fines, sino en convertir el trabajo en algo divertido. Se trata de que cada día, al despertarnos, tengamos ganas de que llegue el momento de entrar a trabajar. Se trata de que cada día, al retirarnos, estemos llenos de orgullo. Se trata de que no tengamos, los jueves, ganas de que llegue el viernes.

El trabajo debería: apasionarnos, hacernos crecer, brindarnos desafíos, ser interesante y divertido. Además, deberíamos: tener un jefe excepcional, excelentes compañeros de trabajo y clientes que nos quieran, que hablen de nosotros, y que nos aprecien por lo que hacemos y por lo que somos.

Es lo que yo llamo "el síndrome de los 7 enanitos (de Blancanieves)". Los siete enanitos cantaban mientras trabajaban:

¡Cavar, cavar, cavar, cavar en la mina quiero yo! ¡Cavar, cavar, cavar, cavar no acabas nunca no! Quien cava más muy rico es... si tu pico das al derecho y al revés ¡Y al cavar... con afán... otros mil diamantes van! ¡Cavar, cavar, cavar, cavar de Sol a Sol! Mas todo puedes arruinar si pierdes el control. Diamantes hay un buen montón... y rubíes miles, y un millón... y sin saber por qué razón... ¡cavamos con ilusión!

Los siete enanitos también cantaban al regresar a casa:

¡Hi-Ho, Hi-Ho, a casa vuelvo yo! ¡Hi-Ho, Hi-Ho, el día ya acabó!

¿Cómo resolvemos esta deficiencia?

  1. Deberíamos recordar la última vez que fuimos felices trabajando y apuntarlo en una lista ¿qué ocurrió? La lista se podría poner en común y podríamos intentar reproducir esos momentos.
  2. Si alguien es bueno en algo, relacionado con las actividades del grupo, debería tener la posibilidad de demostrarlo.
  3. Se debería fomentar la creatividad.
  4. Deberíamos, de vez en cuando, tener la posibilidad de participar en proyectos que representen un reto. Si esto no es posible, deberíamos cada cierto tiempo (cada 3 meses, por ejemplo) proponer pequeños retos (objetivos guinda) dentro de nuestros proyectos y abordarlos, para que alimenten nuestro ego profesional.
  5. La monotonía en el trabajo es el enemigo número 1 del trabajo divertido. Intentaremos desterrarla. Podríamos tener una lista de pequeños proyectos estrella (propuestos por nosotros mismos) que, sin tener una utilidad especial, puedan servirnos para salir de la monotonía. Quizá utilizando técnicas novedosas para su desarrollo.
  6. Podrían incorporarse técnicas que hagan más divertida la (aburrida) gestión de los proyectos: calendario niko, planning poker, técnica pomodoro, etc. (no probar todas a la vez).
  7. Fomentar el uso de herramientas emergentes, sin definir una utilidad especial para ellas: facebook, twitter, wave, etc.
  8. En la relación con nuestros compañeros de trabajo debería haber cordialidad.
  9. El reglamento de funcionamiento interno, como grupo, debería ser conocido, ser claro y aceptado por todos.
  10. Deberíamos ser sinceros (no al 100%) e, incluso, establecer un protocolo para resolver conflictos.

viernes, 11 de diciembre de 2009

Inversión en Capital Humano

Somos humanos con recursos, no somos recursos humanos. Es necesario que estos humanos tengan cada día más recursos para sacar adelante sus tareas, las actuales y las que están por llegar.

Está claro que, hoy en día, no podemos considerar a las personas que forman parte de una Organización como un recurso más, como si se tratase de una parte más del mobiliario. Su valor como Organización estará en función del valor (grado de destreza, experiencia o formación) que tengan las personas que forman parte de ella. Somos realmente su CAPITAL.

Deberíamos exigir a la Organización que haga algo más, por estos humanos, que limitarse a controlar que cumplen con su función hasta que llega la hora de (una vez amortizados) su reemplazo por otro recurso nuevo.

Si somos un capital, lo que debería buscar la Organización es que este capital creciese, tuviese cada día más valor en el mercado. Para ello, debe invertir en él, porque el capital no va a crecer por si solo sin "moverlo".

Intenta hacer el siguiente ejercicio: recupera tu CV previo a la entrada en tu Organización actual, recupera tu CV actual e intenta eliminar todas aquellas destrezas que hayas adquirido y que no se deban a la intervención directa de tu Organización y elimina también todas aquellas destrezas que sean imprescindibles para realizar tu trabajo (quedarían aquellas que no siendo imprescindibles para realizar tu labor han sido aportadas por tu Organización). ¿Crees que la diferencia, lo que la Organización te ha aportado, entre tu primer CV y el segundo CV es sustancial? ¿Crees que tu CV actual tiene un valor de mercado sustancialmente superior al que tenía tu antiguo CV en aquel momento?

¿Cómo resolvemos esta deficiencia?

  1. Lo más sencillo sería exigir a la Organización un Plan de Formación adecuado. Pero, no sólo el adecuado para adquirir las destrezas necesarias para realizar tu labor diaria. Es necesario exigir un Plan de Formación para adquirir destrezas que hagan de nosotros un mejor profesional en todos los aspectos.
  2. Podríamos intentar convencer a la Organización, aunque es muy costoso, que parte del personal pudiese optar a obtener certificaciones reconocidas.
  3. Fomentar la auto-formación, pero de forma gestionada: ¿quién? ¿qué tiempos? ¿con qué objetivos? ¿qué coste? ¿qué frutos da? ¿debe retornar a la Organización? Gastar una hora al día, sin un plan, supone un año sabático cada 7 (¿a costa de quién?).
  4. Deberíamos tener una parte de nuestro CV de acceso público (internamente) para conocer qué destrezas o habilidades tienen nuestros compañeros, de las no conocidas, que podamos aprovechar para hacerlas llegar al resto del equipo.
  5. Es importante institucionalizar la figura del mentor, quien debe preocuparse de nuestros intereses profesionales y hacerse cargo de nuestra educación.
  6. ¿Te permiten tus tareas diarias un aprendizaje continuo? Si la respuesta es que no, deberíamos cambiar la forma en que abordamos nuestras tareas diarias, porque los mecanismos utilizados en el aprendizaje necesitan de un lubricante continuo.
  7. Deberíamos intentar que cada uno de nosotros realizase tareas de un nivel de responsabilidad superior al que nos corresponde por plantilla. Eso sí, extremando las precauciones, sin exigencia de resultados, simplemente como parte del aprendizaje.
  8. Deberíamos conocer qué hacen en su puesto, para sacar adelante sus distintas actividades, nuestros superiores. Para que un día podamos decir "yo también podría/sabría hacerlo".
  9. Una forma de medir si el capital humano está creciendo es medir su productividad. Si con una misma masa de capital físico la productividad aumenta... será porque el capital humano ha mejorado en alguno de sus aspectos. El problema es ¿cómo medir la productividad?

miércoles, 9 de diciembre de 2009

Se ha publicado la versión GWT 2.0.0

Juraría que hace un par de días, cuando pasé por la web de este kit de desarrollo de aplicaciones RIA de Google, sólo estaba disponible la versión 1.7 y solamente buscando por los blogs encontrabas algo sobre la 2.0.0-RC2. Pero, parece que ha llegado el momento de probar la esperadísima nueva versión del GWT-2.0.0

Y viene además acompañada de una nueva herramienta Speed Tracer, que se instala como un plugin del navegador de Google, como no, Google Chrome, para ayudarte a medir y fijar problemas de rendimiento de tus aplicaciones GWT.

Yo no voy a perder ni un instante en descargarme e instalar este nuevo kit de desarrollo.

sábado, 5 de diciembre de 2009

Vocación de servicio

La vocación de servicio es una actitud del individuo (el trabajador, en este caso) y no una capacidad que pueda adquirirse tras un aprendizaje. Parecería, pues, imposible provocarla. Sin embargo, sí es posible crear el clima adecuado (motivación social) que ayude a mejorar este comportamiento.

No se puede entender la vocación de servicio a la Organización sin pasar por el cliente. Sólo si el cliente avala que la Organización está alcanzando la excelencia, en aquellos servicios en los que estemos involucrados, podremos asegurar que la hemos alcanzado realmente. La vocación de servicio nacería en el momento en el que nos demos cuenta de la transcendencia (ir más allá) de nuestro trabajo, que somos capaces de mejorar pequeños aspectos de la vida de nuestros clientes en su relación con la Organización.

¿Cómo crear el clima adecuado para mejorar la vocación de servicio?

  1. Empatía: es importante que en cada actividad del servicio en el que estemos involucrados nos pongamos del lado del usuario que lo va a recibir. Quizá lo más sencillo sea escuchar al usuario o que seamos capaces de medir el impacto que cada actividad tiene sobre él.
  2. Comprender mejor que escuchar a nuestros clientes: esta idea la he plagiado de un artículo, que he leído recientemente, que hacía referencia a un principio de un afamado cocinero español (Ferran Adrià, de El Bulli). Adrià dice que si escuchamos a nuestros clientes no podremos hacerles sentir una experiencia diferente a lo que ya conocen. Además, la mayoría de las veces, la gente no sabe lo que quiere o no todo el mundo quiere lo mismo.
  3. Impacto: utilizaremos encuestas (telemáticas o presenciales) antes de iniciar cada actividad y/o crearemos un modelo que nos permita predecir el impacto, mediante unos puntos de función que podamos definir.
  4. Eliminar los residuos (waste): eliminar del servicio, o castigar en la priorización, todo aquello que no suponga una mejora tangible para el usuario y, posteriormente, para la Organización.
  5. Feed-back: tras la publicación de cada servicio, o mejor de cada actividad del servicio, deberíamos obtener el feed-back del usuario. Las herramientas a utilizar, en este caso, también serían las encuestas. Podríamos utilizar también la medición del uso del servicio mediante nuestros sistemas de log/traza.
  6. Trascender: deberíamos poder participar en proyectos, de vez en cuando, transcendentales. La sensación de que estamos dejando un legado de importancia, para la Organización o de un ámbito mayor, hará que la vocación sea una actitud continua y creciente.
  7. Reconocimiento: es importante que los reconocimientos sean públicos y así tengamos la sensación que la Organización está orgullosa de nosotros. Quizá teniendo un tablón de menciones o provocando que la Organización sea consciente de lo importante que es que realice este tipo de reconocimientos del trabajo bien hecho.

jueves, 3 de diciembre de 2009

La gestión del conocimiento

El conocimiento es una característica propia de las personas, pero también es una característica propia de las personas olvidar aquella parte, no útil hoy, del conocimiento adquirido en un momento dado.

Es cierto que parte de lo que sabemos se lo debemos a la transferencia oral de nuestros mayores (o seniors), pero si el conocimiento no hubiese quedado escrito seguramente se habría perdido parte de él (quizá una parte importante o transcendental).

Lo normal en los departamentos de TI es que la movilidad de las personas sea muy alta. También es normal que estas personas participen en más de un proyecto a la vez y que los proyectos se alarguen en el tiempo (sí, todos los proyectos tienen una "patada de inicio", pero no todos tienen siempre un "cierre").

Esto provoca que muchas personas tengan que adquirir muchos conocimientos, asociados a los diferentes proyectos por los que van pasando, y que solo haciendo fotografías del conocimiento que tiene cada persona en cada momento podamos, algún día, si fuese necesario, recomponer el retrato completo.

Lo sé porque mi departamento de TI deposita todo el conocimiento en las personas, muy poco se pone en "negro sobre blanco", y estamos teniendo problemas.

A veces tenemos la necesidad de recordar por qué tomamos aquella decisión y no otra y... nuestra memoria suele ser muy flaca. También puede ocurrir que los protagonistas de tomar aquellas decisiones ni siquiera estén ya entre nosotros y sea complicado contactar con ellos.

Quizá lo siguiente daría para otro "post", pero... la idea de tener un equipo o "team" de 5 ó 6 personas dedicadas a tiempo completo en un único proyecto hasta completarlo es, al menos en mi departamento, una UTOPÍA.

Hemos optado por abrir un Wiki por cada proyecto, pero tengo la sensación que es como utilizar un lápiz, una escuadra y un cartabón para hacer un diagrama entidad-relación.

martes, 1 de diciembre de 2009

¿Tendrán las Administraciones Públicas los deberes hechos el 1 de enero de 2010?

Los derechos reconocidos a los ciudadanos en la Ley de la Administración Electrónica (Ley 11/2007 en su artículo 6) podrán ser ejercidos a partir del 31 de diciembre de 2009.

Si las Administraciones Públicas no han hecho sus deberes se escudarán en que el problema es de los técnicos y de la tecnología.

¿Creéis que llegaremos a tiempo de cubrir, al menos con mínimos, el expediente?

La respuesta que voy a dar quizá sea un poco pesimista, es mi carácter. Sólo viendo el vaso medio vacío... se puede intentar llenar. Si lo ves ya lleno... igual no haces nada, salvo vaciarlo del todo.

No, no creo que la Administración esté preparada para cumplir con la Ley el próximo mes de enero. Fundamentalmente por falta de previsión, pero también por falta de lideres que "tiren" de este proyecto con decisión.

Muchas Administraciones se han quedado esperando a que algún iluminado "entrase a machete" en la Ley y explicase con claridad por dónde realmente debemos empezar.

Otras Administraciones se han quedado esperando, no sin razón, a que fuese una Administración de orden superior la que diese una solución (al menos tecnológica) universal al problema.

Si la Ley habla de eficiencia económica (ahorro de costes) no sé el porqué la propia Ley no venía acompañada de esta, tan necesaria, solución universal.

Es cierto que desde el MAP ponen a nuestra disposición los productos asociados al proyecto wand@ (basado en el trabajo desarrollado años atrás por la Junta de Andalucía), pero no lo ha hecho con contundencia.

Muchas empresas de tecnología, e incluso otras que no lo son tanto, han visto un hueco por el que colarse ofertando todo tipo de productos asociados a la Administración Electrónica, lo cual, por supuesto, es totalmente lícito.

El "abreté-sésamo" es "PLATAFORMA DE TRAMITACIÓN" y quién hoy diga que dispone de un producto con un conjunto de características mínimas para cubrir lo que se supone que tiene que tener una plataforma de tramitación electrónica... tiene el camino allanado.

¿Era éste el espíritu de la Ley? Yo creo que no.

Se trataba de sentarse a pensar en cómo quería el ciudadano 2.0 que fuese su relación con la Administración. Yo creo que el ciudadano 2.0 no quería encontrase con cientos de PLATAFORMAS DE TRAMITACIÓN (algunas parecidas, otras diferentes) pensadas más para un funcionario 1.5 (ni siquiera pensadas para el verdadero funcionario 2.0) que para facilitarle realmente la vida.

sábado, 28 de noviembre de 2009

Great Place to Work

La palabra trabajo viene del latín tripalium (tres palos). El tripalium era un yugo hecho con tres (tri) palos (palium) en los cuales amarraban a los esclavos para azotarlos. Desde el punto de vista del empresario, tu trabajo es su negocio. Negocio viene de la negación del ocio. Es decir, para el trabajador el trabajo es una esclavitud y además tu empresa te está negando el ocio mientras trabajas.

¿Por qué, pues, trabajamos? ¿Por qué dedicamos un tiempo tan hermoso y escaso en hacer algo que nos esclaviza y que niega nuestro ocio? La respuesta inmediata parece ser: por dinero. Sin embargo, esta concepción simplista del trabajo está cambiando.

Los nuevos trabajadores (los que ya han sido bautizados como Generación Y) buscan algo más de sus empresas, y de sus lideres, que la simple compensación económica. Os invito a leer este PDF, donde se habla de ello.

Las empresas, algunas de ellas, ya se han dado cuenta que la falta de motivación y el estrés les cuesta dinero. Esto repercute directamente en una disminución de su productividad y les resta, además, competitividad.

¿Qué empresas seleccionarán los trabajadores con talento entre sus preferidas para trabajar? Quizá a las empresas GPW...

Esto puede que sea simplemente una moda pasajera que, a futuro, quede como una experiencia sin éxito. Pero, mientras tanto, ¿por qué no nos aprovechamos los trabajadores de esta moda? No tenemos nada que perder...

Hablando de estrés, como con el colesterol, ya se ha descubierto que existe un estrés bueno (eustrés) y un estrés malo (el distrés). Así que, quizá, nuestro estrés (el que todos pensamos que sufrimos) sea solamente del primer tipo, ¿no?

Simplemente Go

Hace tiempo, Google anunció que estaba creando un nuevo lenguaje de programación con características de seguridad y rendimiento similares a C++ pero combinadas con las características de lenguajes dinámicos tipo Python. Lo llamaron "Go" y no tuvo muy buena acogida en los foros.

Es sabido que, Google estaba utilizando Python de forma masiva en todos sus desarrollos (que son muchos), pero desde hace unas semanas está invitando a sus desarrolladores a abandonar Python en favor de otros lenguajes ¿Cuál? Era la pregunta estos días.

Pues parece que ya se ha realizado el anuncio oficial:

http://www.genbeta.com/actualidad/google-lanza-go-su-lenguaje-de-programacion

¿Queréis aprender Go? La página oficial es:

http://golang.org/

"Go to Go", my friend.

martes, 20 de octubre de 2009

Cloud computing se llama esta filosofía

El concepto o filosofía "Cloud computing" (la computación está en la nube o la nube -metáfora de Internet- es el ordenador) es una idea antigua.

Ya Sun habló (fue su eslogan durante años) de "The network is the computer" y mucho antes Bill Gates predijo... "todo estará conectado a la Red" (claro que él pensaba que a su Red).

Lo que ha ocurrido es que ahora es "medio" posible (no se sabe si la posibilidad es madre de la filosofía o la filosofía madre de la posibilidad):
  1. Queremos acceder desde distintos dispositivos a nuestros aplicativos: móviles, netbooks, tv con tdt, pequeñas video-consolas, etc. Estos dispositivos no tienen capacidad para ejecutar pesadas aplicaciones ni discos duros voluminosos... así que "que todo esté en la Red es una ventaja".
  2. Hoy en día, es más o menos fácil y más o menos barato acceder a la Red, en cualquier sitio, con uno de estos dispositivos.
  3. Queremos socializarnos por la fuerza bruta: queremos tener miles de amigos en nuestro facebook, decir hasta "cuándo nos sacamos un moco" en el twitter y saber qué amigos tenemos a nuestro alrededor desde el móvil (hay un servicio Google que ya nos permite hacer esto). Lo extraño, quizá por esto, es que cada vez estemos más alarmados por la información que se tiene de nosotros y el uso que se hace de ella.
  4. Hay empresas que ya han visto negocio (sobre todo Google y Microsoft) pero que no nos dicen que nos espera a la vuelta de la esquina: primero utilízalo gratis, sin leer las condiciones del contrato, luego te mando publicidad y más tarde te hago pagar un poco por servicios "premium".
Suma el precio del dispositivo, el precio de la conexión (seguro que la pagas dos veces), el precio de la publicidad que te tragas y el precio de los X servicios que vas a contratar en modo "premium"... total "lo comido por lo servido".

De todas formas, la filosofía es imparable (los filósofos sólo tienen que pensar en qué, no en los resultados) así que os paso una lista, ejemplo, de Universidades (no hay ninguna española que yo vea) que utilizan uno o varios de estos servicios:

http://www.edustyle.net/gallery_other.php

viernes, 11 de septiembre de 2009

Intenciones de ORACLE para los clientes SUN

ORACLE ha publicado una declaración, sobre sus intenciones, para los clientes de SUN. Ver:

http://www.oracle.com/features/suncustomers.html

Sólo dice que va a gastar más dinero, de lo que SUN gastaba hasta ahora, en el desarrollo de SPARC y en el desarrollo de Solaris.

Además, dice que, pondrá más especialistas (el doble que SUN) asociados a la venta de hardware y servicios.

Pero, la frase más interesante es la que dice que, aumentará el rendimiento del hardware SUN mediante la integración de software ORACLE en esta plataforma.

Con esta última frase, y no diciendo nada con respecto a Java, JavaFX, Glassfish (SJSAS), Netbeans, MySQL... yo creo que ORACLE deja bastante claro cuáles serán sus intenciones con respecto a estos productos SUN.

miércoles, 22 de julio de 2009

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

Más de un lector me había pedido que crease la localización para la versión 3.3 (este SDK lleva un tiempo ya en el "mercado"). La verdad es que, no era consciente de que nadie la estuviese usando/esperando...

En el siguiente enlace FLEXSDK33-framework-locale-es_ES.zip
os dejo un .zip que podéis descomprimir en el directorio de vuestro Flex SDK 3.3 (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 /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.0.2, que realmente utiliza un SDK que viene dentro del directorio "sdks" donde esté instalado este impresionante entorno de desarrollo.

Os dejo las versiones anteriores de estas "localizaciones" en:

domingo, 7 de junio de 2009

Google ha liberado Page-Speed

Google ha (recientemente) abierto el fuente de una herramienta, que ellos utilizan internamente, para optimizar sitios web. Además de "abrirla", la ponen a nuestra disposición.

Lo que se consigue realmente con ella es mayor velocidad en la carga de las páginas, una vez aplicas las recomendaciones dadas.

No es que la herramienta haga que las páginas se carguen más rápidamente, sino que te da pistas para que diseñes páginas que se cargarán más rápidamente.

Te ayuda en el análisis de tus páginas web, optimización de los css, optimización de los javascript, optimización de las imágenes y otras recomendaciones varias.

La he probado, prefiero comentar las cosas tarde pero probadas, y tengo que decir que satisface mis expectativas. De una forma sencilla, simplemente cargando la página a analizar desde el navegador y activando el análisis, nos informa de lo que podemos hacer (de forma sencilla) para mejorar el rendimiento de la misma.

Se llama "Page Speed" (se puede descargar desde http://code.google.com/intl/es-ES/speed/page-speed) y es un añadido al plugin "Firebug" de "Firefox".

La instalación de "Firebug" debería ser una obligación para todos los desarrolladores de contenido/aplicaciones web.

martes, 12 de mayo de 2009

Exception : Unsupported major.minor version

Estaba ya un poco harto de la excepción "Unsupported major.minor version". Mis condiciones de trabajo hacen que no "despliege" mis aplicaciones Java siempre en la misma máquina, con lo que me encuentro con diferentes entornos en los que es necesario que estas aplicaciones funcionen correctamente. Estos entornos, muchas veces, no son controlados por mí.

Uno de los elementos, de estos entornos, que más me influyen es: la versión de la máquina virtual Java (JVM) que hay instalada en ellos. Si la máquina virtual Java es una revisión menor que la de mi entorno de desarrollo... tendré problemas. Si la máquina virtual Java es una revisión menor que la utilizada por quien compiló las librerías (en formato JAR) que utilizo en mis aplicaciones... tendré problemas.

Pero, ¿cómo sé con qué versión de máquina virtual han sido compiladas el conjunto de clases de mi aplicación? Sé que cada .class tiene unos primeros bytes que me informan de ello, pero, ¿alguién ha desarrollado ya alguna utilidad que lea estos bytes y me haga un sencillo informe con el resultado de su lectura?

Curiosamente, me costó menos desarrollar esta pequeña utilidad que encontrarla en Internet (no fuí capaz de encontrarla, realmente).

La he llamado "CheckJvmVersion" y la "dono" ;-)
import java.io.*;
import java.util.*;
import java.util.jar.*;
import java.util.zip.*;

public class CheckJvmVersion {

public static void main(String[] argv) {
JarFile[] jar = null;
String dir = "";
if (argv.length <= 1) {
if (argv.length == 1) {
if (argv[0].endsWith(".jar")) {
jar = new JarFile[1];
try {
jar[0] = new JarFile(argv[0]);
} catch (IOException e) {
System.out.println("No se ha podido leer el fichero jar: " + argv[0]);
System.exit(-1);
}
} else {
dir = argv[0];
int j = 0;
String[] ljar = new File(dir).list();
jar = new JarFile[ljar.length];
for (int i = 0; i < ljar.length; i++) {
if (ljar[i].endsWith(".jar")) {
try {
jar[j++] = new JarFile(argv[0] + System.getProperty("file.separator") + ljar[i]);
} catch (IOException e) {
System.out.println("No se ha podido leer el fichero jar: " + ljar[i]);
System.exit(-1);
}
}
}
}
} else {
dir = ".";
int j = 0;
String[] ljar = new File(dir).list();
jar = new JarFile[ljar.length];
for (int i = 0; i < ljar.length; i++) {
if (ljar[i].endsWith(".jar")) {
try {
jar[j++] = new JarFile(ljar[i]);
} catch (IOException e) {
System.out.println("No se ha podido leer el fichero jar: " + ljar[i]);
System.exit(-1);
}
}
}
}
} else System.out.println("Uso: CheckJvmVersion [<jar-file>]");
if (jar != null && jar.length > 0) {
try {
for (int i = 0; i < jar.length; i++) {
if (jar[i] != null) {
System.out.println("Leyendo el fichero jar [" + jar[i].getName() + "]: ");
List<String> l = new ArrayList<String>();
for (Enumeration e = jar[i].entries(); e.hasMoreElements();) {
ZipEntry ze = (ZipEntry) e.nextElement();
InputStream is = jar[i].getInputStream(ze);
DataInputStream dis = new DataInputStream(is);
try {
int magic = dis.readInt();
if(magic == 0xcafebabe) {
int minor = dis.readUnsignedShort();
int major = dis.readUnsignedShort();
String version = "";
if ((major + "." + minor).equals("45.3")) version = "1.0";
else if ((major + "." + minor).equals("45.3")) version = "1.1";
else if ((major + "." + minor).equals("46.0")) version = "1.2";
else if ((major + "." + minor).equals("47.0")) version = "1.3";
else if ((major + "." + minor).equals("48.0")) version = "1.4";
else if ((major + "." + minor).equals("49.0")) version = "1.5";
else if ((major + "." + minor).equals("50.0")) version = "1.6";
else version = "?";
if (!l.contains(version)) l.add(version);
}
} catch (IOException ie) {}
dis.close();
}
for (Iterator iter = l.iterator(); iter.hasNext();) System.out.println("JVM-" + iter.next() + " " + (isEmpty(dir) ? jar[i].getName() : replace(replace(jar[i].getName(), dir, "", -1), System.getProperty("file.separator"), "", -1)));
}
}
} catch (IOException e) {
System.out.println(e.getMessage());
System.exit(-1);
}
}
}

private static boolean isEmpty(String str) {
return str == null || str.length() == 0;
}

//@param max - maximum number of values to replace, or <code>-1</code> if no maximum
private static String replace(String text, String searchString, String replacement, int max) {
if (isEmpty(text) || isEmpty(searchString) || replacement == null || max == 0) return text;
int start = 0;
int end = text.indexOf(searchString, start);
if (end == -1) return text;
int replLength = searchString.length();
int increase = replacement.length() - replLength;
increase = (increase < 0 ? 0 : increase);
increase *= (max < 0 ? 16 : (max > 64 ? 64 : max));
StringBuffer buf = new StringBuffer(text.length() + increase);
while (end != -1) {
buf.append(text.substring(start, end)).append(replacement);
start = end + replLength;
if (--max == 0) break;
end = text.indexOf(searchString, start);
}
buf.append(text.substring(start));
return buf.toString();
}

}
Recibe un único argumento (que puede ser un fichero JAR o un directorio) y te dice las diferentes versiones de JVM utilizadas para compilar las clases que hay empaquetadas en las librerías (en formato JAR) localizadas.

En caso de no pasarle ningún argumento, busca dentro del directorio "local" desde el que lanzas el comando.

sábado, 9 de mayo de 2009

RIA no quiere decir RapIdAmente

A raíz de mis últimos artículos, sobre tecnologías para el desarrollo de aplicaciones empresariales y "ricas" para la web, he recibido algún comentario argumentando que: "este tipo de tecnologías no nos están ayudando en el desarrollo rápido de nuestros productos".

Algunos programadores tienen la sensación, incluso, de contar con técnicas y herramientas "cavernícolas" para emprender nuevos desarrollos con este tipo de tecnologías. No puedo estar más que "de acuerdo" con esta última sensación.

Como todos sabemos, muchos de los proyectos que abordamos sufren, al final, retrasos o se entregan con funcionalidades faltantes. Muchas veces, la dirección de nuestras empresas de tecnología achacan estos defectos a los propios desarrolladores o a la tecnología seleccionada.

Los desarrolladores y la tecnología seleccionada no suelen ser, casi nunca, la causa de los retrasos de un proyecto (a no ser que contemos con programadores sin experiencia y no se haya seleccionado la tecnología adecuada para abordar el proyecto requerido).

Normalmente la causa de los retrasos está en la mala gestión del propio proyecto. Es decir, la culpa normalmente es de la "dirección". Tampoco son buenas compañeras las prisas...

Además, si la "dirección" quiere contar con una tecnología con la que se desarrolle rápidamente, o que encontremos un entorno de desarrollo que genere aplicaciones enriquecidas con tan solo "pulsar un botón", lo que hay que hacer es... cambiar de "dirección".

El construir aplicaciones RIA (enriquecidas) no quiere decir construir aplicaciones RapIdAmente. Mi experiencia me dice que, ninguna de las tecnologías (que yo conozco) te van a ayudar en "esto" de la rapidez.

Más bien todo lo contrario. Hoy en día, igual te da que selecciones Flex, Silverlight, JSF, GWT, AJAX o ColdFusion o una combinación de alguna de las anteriores. Con ninguna he conseguido rapidez en el desarrollo. La tecnología actualmente tendrá otras virtudes, pero no esta.

Los tiempos han cambiado (aunque parece que aún estamos en el pleístoceno de la programación) y pensar que podemos desarrollar una aplicación (web, enriquecida y con un comportamiento típico de aplicación escritorio) con una única tecnología que nos dé solución a cualquier problema que nos surja... es una utopía.

viernes, 8 de mayo de 2009

Ser un emprendedor o ser, mejor, un prendeador

En un evento, que presencié hace unos días, se hablaba de cómo los emprendedores tecnológicos nos ayudarán a salir de esta dura crisis económica que estamos viviendo. Ya he comentado anteriormente que, no creo en el concepto de emprendedor tal y como se utiliza habitualmente.

Yo "emprendo" todos los días cantidad de acciones y no por ello soy un emprendedor. Ser emprendedor se ha, mal, asociado, en multitud de veces, con aquella persona que tiene éxito (económico) en la creación de empresas, productos y/o servicios.

O, también, con aquella persona que, sin tener éxito, intenta una y otra vez crear empresas, productos y/o servicios.

Quizá sería más acertado utilizar, para estos dos casos, el término empresario o el término tozudo.

A mí me gusta más usar los términos prendedor (de prender) y prendador (de prendar). Quizá sería, pues, necesario acuñar (la propondré a la RAE) una nueva palabra: el prendeador.

Desde mi punto de vista, la característica principal (además del "prender" y "prendar") que define a este tipo de personas, al menos a los prendeadores que yo he conocido, es simplemente la ilusión.

Hoy en día, en tecnología, yo hablo de tres perfiles: ingenieros, artesanos e inventores. Los verdaderos prendeadores deben tener un 60% de inventores, un 30% de artesanos y un 10% de ingenieros.

Dentro de una organización, sin embargo, el porcentaje debe cambiar. Al menos, debe haber un inventor, un par de artesanos y el resto pueden ser ingenieros ;-) Si estas organizaciones cuentan, además, con un prendeador... mucho mejor.

TwinDocs o del buzón al cajón

El pasado miércoles 6 de mayo, un "viejo" conocido (Alfonso Lahuerta) presentó en Zaragoza, junto con sus dos socios, el proyecto TwinDocs. Oficialmente, TwinDocs es un nuevo servicio "on-line" de archivo y gestión de documentos electrónicos oficiales.

La presentación fue respaldada por el Gobierno de Aragón, teniendo lugar en la sala donde se celebran los eventos a los que se les quiere dar gran relevancia. Se aprovechó, también, para hablar de cómo los emprendedores de esta región nos ayudarán a salir de la crisis económica. Sobre todo, según parece, los emprendedores tecnológicos. Yo no creo en la palabra emprendedor.

Pero, ¿qué es realmente TwinDocs? o ¿qué necesidad pretende cubrir?

Presencié el evento por Internet, no sin dificultades técnicas, y me registré como usuario ese mismo día, para probar el servicio. La presentación me había dejado un poco "contrariado". Algunas de las funcionalidades me parecían sorprendentes, otras sonaban más obvias y otras no eran tan originales.

Tenía la sensación de que TwinDocs iba a estar más orientado hacia la Administración Electrónica (aún queda mucho de la Ley 11/2007 por desarrollar en la región), pero, no era así. Este servicio está orientado, fundamentalmente, al ciudadano, dotándole de una herramienta para que "tenga bien ordenados todos sus papeles" y esto lo haga, además, en la propia Red. TwinDocs es, pues, un cajón de documentos en la Red.

Pero, ¿quién dice que el ciudadano necesite tener ordenados sus papeles? ¿Quién dice, tan siquiera, que necesite archivarlos/conservarlos? Respecto al papeleo personal ¿no nos manejamos mejor en el caos, o en la despreocupación, que intentando mantener el orden?

Yo, normalmente, paso los papeles poco importantes del buzón a un cajón "desastre" y los importantes (son los menos) al cajón de la mesita de noche. Cuando se acumulan, o ya no tiene sentido el conservarlos, los "arrojo" al contenedor del reciclaje de papel. ¿TwinDocs hará todo esto por mí, de forma automática? Espero que sí...

Si consiguen incluir, en su servicio, los módulos necesarios para que "esto" se haga de forma transparente para el usuario... tendrán el éxito asegurado.

Es necesario, además, que las compañías que me prestan servicios (bancos, eléctricas, telefónicas, la administración, etc.) puedan enviarme documentación a mi cajón TwinDocs, de forma sencilla. También resultaría útil que TwinDocs sea bidireccional: del ciudadano a la compañía (o administración) y de la compañía (o administración) al ciudadano.

Pero lo más importante, si este servicio ahorra dinero (en papel, trámites e infraestructuras)... lo que el ciudadano quiere es que este ahorro le repercuta a él en su bolsillo. Esto es lo que me hará ser fiel al servicio TwinDocs. Si las compañías ahorran todo ese dinero, que lo inviertan en TwinDocs (que sufraguen ellos el coste del servicio) y en el propio usuario (por ejemplo, mediante descuentos a aquellos usuarios que usen esta herramienta).

lunes, 20 de abril de 2009

Oracle to Buy Sun

Es la noticia de la jornada, llego ya tarde en anunciarlo pero, más vale tarde que nunca. Ver:

http://www.sun.com/third-party/global/oracle
http://www.oracle.com/us/corporate/press/018363

Parece que ya es oficial (el primer enlace es de SUN y el segundo es de ORACLE).

IBM ya había retirado su oferta y se sabía que había varios "interesados" detrás de la compañía. Lo que sí era seguro es que SUN vendía, ya que la noticia no le estaba haciendo más que daño. Se decía que el comprador podía ser uno de los siguientes: ORACLE, HP o CISCO (incluso sonó Google) . Uno de ellos se ha llevado hoy el "gato al agua".

Yo siento nostalgia, más que agrado o tristeza. Llevo 16 años asociando Java con el logotipo de las 4 "eSes" de SUN y se me va a hacer extraña otra combinación.

Si ORACLE ha comprado SUN... ¿qué pasará con SJSAS (ORACLE adquirió hace meses BEA WebLogic), con MySQL (competencia directa) y con la implementación de la JVM de SUN (ORACLE tiene la JRockit de BEA)?

ORACLE, creo que, por lo que no va a apostar es por la continuidad del Sun Java System Application Server o Glassfish. ORACLE está intentando posicionar su producto ORACLE (BEA) WebLogic como el Servidor de Aplicaciones J2EE de referencia.

Además ORACLE, con la compra de BEA, se ha hecho con, lo que en boca de "algunos", es la mejor implementación de la JVM (JRockit) de las existentes... con lo que sí puede intentar sustituir la implementación de SUN.

Yo no temo demasiado por MySQL... seguramente la llevará a un mejor lugar (en los gestores de bases de datos es donde tiene toda su fortaleza/conocimiento).

Otro producto que sí puede estar comprometido, en un futuro cercano, es Netbeans. ORACLE apostará (lo ha hecho ya, realmente) por Eclipse y no creo que mantenga vivos los dos productos. Además, en mi opinión, Netbeans es un producto menor, comparándolo con Eclipse.

Sí me preocupa un poco más el mercado de los servidores (hardware), ya que es aquí donde ORACLE tiene menos experiencia.

Más en:

http://java.dzone.com/news/oracle-buys-sun
http://www.elmundo.es/elmundo/2009/04/20/navegante/1240228857.html

sábado, 4 de abril de 2009

And The Winner is... Flex

Siguiendo con los últimos artículos sobre tecnologías existentes, para el desarrollo de aplicaciones empresariales y "ricas" para la web, me atreveré a elaborar un cuadro comparativo con las seleccionadas: Flex, Silverlight, JavaFX, GWT, AJAX y JSF.

Sé que la lista de tecnologías podría ser más amplia pero, sólo me atrevo a elaborar este cuadro con aquellas que conozco, al menos, un poco. Si queréis podéis enviarme comentarios con vuestras opiniones sobre el resultado o para corregir o ampliar la lista y tener, así, una visión más completa.

Los criterios a valorar son los siguientes:
  1. madura, duradera, con una masa de usuarios tras ella y con bibliografía publicada
  2. ligera y que dé un rendimiento aceptable
  3. que me permita desarrollar aplicaciones empresariales
  4. que me permita "persistir" información (acceder a bases de datos) sin dificultad
  5. con la que pueda invocar web services de forma sencilla
  6. que disponga de un conjunto de widgets "potentes" y orientados hacia la creación de formularios y grids (tablas) de datos
  7. con la que puedan generar información en forma gráfica (charts)
  8. con la que pueda generar informes y listados pensados para imprimir
  9. que me permita crear aplicaciones multi-idioma de forma sencilla
  10. que me permita crear interfaces que sean amigables, usables y realmente enriquecidos
  11. con la posibilidad de cambiar de skins (pieles) y que proporcione por defecto, al menos, un conjunto de estas (pieles) atractivo
  12. que no tenga que preocuparme del entorno donde va a ejecutarse la aplicación (sistema operativo y navegador) o que la preocupación sea mínima
  13. que tenga un buen entorno de desarrollo de referencia
Y la tabla con las puntuaciones (cada elemento de la lista anterior puede tener una puntuación de 0 a 10, siendo 0 el peor y 10 el mejor) es:
   Flex Silverlight JavaFX GWT AJAX JSF
-- ---- ----------- ------ --- ---- ---
1 7 6 2 5 8 7
2 6 7 5 5 6 7
3 8 8 4 7 5 9
4 7 6 6 7 3 9
5 9 9 6 6 5 6
6 8 8 2 8 3 6 (*) integrando con otras tecnologías
7 7 7 5 6 3 7
8 4 4 2 2 2 4 (*) integrando con otros productos
9 4 4 5 4 2 8
10 8 8 2 8 5 6
11 7 6 2 7 2 5
12 8 6 7 7 5 8
13 9 9 7 3 6 5
-- ---- ----------- ------ --- ---- ---
T= 92 88 55 75 55 87
Así que, en mi opinión, ¡el ganador es... Flex!

viernes, 3 de abril de 2009

¿Qué pasa con JSF?

En mi artículo anterior, que trataba sobre las tecnologías disponibles para ayudarnos en el desarrollo de aplicaciones empresariales para la web, se me olvidó citar una. Además es la tecnología que realmente utilizo para desarrollar el 80% de mis proyectos, en los últimos 3 años.

Por algo será el olvido ;-)

Se trata de JSF o Java Server Faces. Realmente JSF es un estándar más que una tecnología. Yo utilizo una de sus implementaciones: MyFaces de Apache. Aunque hay otras...

JSF nos permitirá construir aplicaciones de usuario desde el lado del servidor. Es decir, nuestro código JSF se ejecutará en el servidor de aplicaciones (debe ser un servidor J2EE), haciendo uso de componentes del servidor (beans para acceder a las bases de datos, por ejemplo) y generando automáticamente páginas HTML resultado, que serán las que realmente reciba el usuario en el navegador. En esto, JSF es diferente a Flex, Silverlight, JavaFX, GWT o AJAX (que se ejecutan del lado del cliente comunicándose asíncronamente con el servidor cuando necesitan de él).

En principio, el uso de JSF facilitará el desarrollo de nuestra aplicación, porque de forma natural hará que cumplamos con el patrón de desarrollo MVC.

Si estás desarrollando aplicaciones empresariales con JSP o servlets, te darás cuenta de lo fácil que es crear código "difícil de mantener". La complejidad va en aumento a lo largo del ciclo de vida de la aplicación. JSF viene a evitar esta complejidad.

JSF te proporciona un control más fino de la navegación, componentes de usuario, validadores, conversores, etc. Además puedes intergarlo fácilmente con un sistema de plantillas llamado Facelets y con otros componentes extendidos: Tomahawk, Trinidad, Tobago, ICEfaces, PrimeFaces, etc.

Algunas de estas librerías de componentes te permiten generar, incluso, verdaderos componentes "AJAXizados". Es decir, generarás el HTML, el JavaScript y las llamadas asíncronas AJAX de forma automática.

Respecto al desarrollo... desarrollaremos la vista de nuestra aplicación con un XHTML extendido con los tags JSF/Facelets. El controlador (las reglas de navegación entre las vistas) se programará mediante la configuración de un XML (faces-config.xml) o mediante anotaciones. El modelo (¿cómo accedo a los datos?) podrá ser desarrollado en Java (mejor dicho, en J2EE). Te aconsejaría utilizar el estándar JPA (Hibernate, EclipseLink, OpenJPA, etc.) para resolver el problema de la persistencia de datos.

Como entorno de desarrollo puedes utilizar tanto Netbeans como Eclipse. Los dos entornos disponen de paquetes, lo suficientemente potentes, que te ayudarán en el desarrollo JSF.

Hasta ahora parecen todo virtudes, entonces ¿cuál es el problema? ¿qué ocasionó mi olvido?

A simple vista, con JSF, el desarrollo de aplicaciones empresariales iba a simplificarse, JSF venía a hacernos la vida más sencilla a los desarrolladores, y... realmente esto no es así. La curva de aprendizaje es alta y al final el paquete (la aplicación) resulta complejo.

Además, algo muy importante para mí, pierdes el control sobre lo que el usuario va a recibir en su navegador, ya que todo va a ser generado automáticamente según las reglas que marca la tecnología. No resulta fácil, ni favorable, "forzar" el saltarse estas reglas. Así que, te tienes que adaptar a ellas.

Mi consejo es, si tu jefe (empresa o cliente) no quiere apostar por una tecnología con capacidades para crear verdaderas aplicaciones enriquecidas (léase Flex, Silverlight o GWT) deberás optar por desarrollar con JSF. Piensa, además, en incluir Facelets, Tomahawk y/o ICEfaces.

La apuesta no es muy arriesgada, te lo aseguro, aunque sí un poco "aburrida".

jueves, 2 de abril de 2009

Flex vs Silverlight vs JavaFX vs GWT vs AJAX

Desde hace meses, tantos como los que llevo sin escribir un nuevo post, he estado estudiando otras tecnologías, que el "mercado" oferta, para cubrir la necesidad de desarrollar aplicaciones enriquecidas para la web.

La lista seleccionada, es simplemente una muestra, hay más, es la siguiente (da pie al título del post): Flex, Silverlight, JavaFX, GWT y AJAX.

Mi objetivo es: quiero tener claro cuál de ellas cumple con los requisitos mínimos que exijo, a la tecnología seleccionada, para desarrollar mis proyectos con garantía de éxito. Por supuesto es indispensable que sea lo más "abierta" posible... hay que leer con lupa la letra pequeña del apartado "licencias" en cada una de ellas. Con la tecnología seleccionada quiero poder desarrollar aplicaciones (con ánimo de lucro ;-) ) sin que esto suponga un coste añadido para mi empresa.

Quiero una tecnología:
  1. madura, duradera, con una masa de usuarios tras ella y con bibliografía publicada
  2. ligera y que dé un rendimiento aceptable
  3. que me permita desarrollar aplicaciones empresariales
  4. que me permita "persistir" información (acceder a bases de datos) sin dificultad
  5. con la que pueda invocar web services de forma sencilla
  6. que disponga de un conjunto de widgets "potentes" y orientados hacia la creación de formularios y grids (tablas) de datos
  7. con la que puedan generar información en forma gráfica (charts)
  8. con la que pueda generar informes y listados pensados para imprimir
  9. que me permita crear aplicaciones multi-idioma de forma sencilla
  10. que me permita crear interfaces que sean amigables, usables y realmente enriquecidos
  11. con la posibilidad de cambiar de skins (pieles) y que proporcione por defecto, al menos, un conjunto de estas (pieles) atractivo
  12. que no tenga que preocuparme del entorno donde va a ejecutarse la aplicación (sistema operativo y navegador) o que la preocupación sea mínima
  13. que tenga un buen entorno de desarrollo de referencia
En otro artículo mostraré una tabla comparativa, pero "a bote pronto" puedo decir que:
  • Flex: sobre esta tecnología, de Adobe, ya he escrito varios artículos en este blog. Desarrollaremos la vista en XML (MXML) y, parte de, la lógica en ActionScript3. La lógica de negocio "dura" (por ejemplo: el acceso a bases de datos o la generación de PDFs) puede ser desarrollada, de forma más natural, en J2EE pero también podría ser en .NET, PHP o cualquier otra tecnología del lado del servidor conocida. Al final, la aplicación generada es un SWF (FlashPlayer) aunque también se puede generar, sin mucho esfuerzo, una aplicación escritorio (con AIR). El entorno de desarrollo de referencia es FlexBuilder (de pago). Ya he construido un par de aplicaciones reales, en producción, con ella y me ha generado bastante satisfacción.
  • Silverlight: tecnología de Microsoft. Empezó un poco rezagada, con respecto a Flex, pero está cogiendo "velocidad de crucero". El principal problema es que, como a todo lo que sale de la factoría de Microsoft, le cuesta adquirir la confianza necesaria por parte de los desarrolladores (por "recelo" no siempre fundado). Desarrollaremos la vista en XML (XAML) aunque la lógica de negocio "dura" será desarrollada de forma natural en .NET o invocando, fácilmente, servicios web (por ejemplo, desarrollados en Java). Al final, la aplicación generada necesita que instales un componente (Silverlight) en tu navegador, que aún no está disponible para todas las plataformas y navegadores. El entorno de desarrollo de referencia es Visual Studio (hay una versión Express). La sensación general es de expectación, parece bastante interesante, lástima que sea de Microsoft.
  • JavaFX: tecnología de Sun. Mi experiencia, llevo más de 15 años desarrollando con Java, me había creado bastante ansiedad por probar la primera versión de esta tecnología. A los dos días me aburrió "soberanamente" y ya la he abandonado. Le queda mucho por madurar (aconsejo que, incluso, por repensar). Desarrollaremos en un exotérico lenguaje "JSONenizado" feo y desagradable. Menos mal que por detrás seguimos teniendo a Java al rescate. La aplicación necesitará, para ejecutarse, del plugin Java instalado en tu navegador. El entorno de desarrollo de referencia es Netbeans, aunque también disponemos de un plugin para Eclipse. Si quieres desarrollar una aplicación triste y fea... prueba JavaFX. La sensación general es de decepción... quizá si orientas tu aplicación hacía el entorno móvil (¿alianza Android/JavaFX?) tenga algún sentido.
  • GWT: tecnología de Google. Trata de hacer más sencilla la tarea de desarrollar una aplicación AJAX. La idea es sorprendente... desarrollamos en Java y el compilador GWT nos genera código JavaScript. Es bastante sencillo invocar servicios desarrollados del lado del servidor mediante RPC. No hay un entorno de desarrollo de referencia, tenemos que conformarnos con algún plugin para Eclipse y algún módulo para Netbeans. El resultado final resulta un poco austero (como todo lo que hace Google) y debe ser reforzado con alguna librería de widgets adicional (GWT-EXT o SmartGWT)... lo que siempre resulta un problema añadido (ahora mismo, por ejemplo, no está muy clara la continuidad de GWT-EXT y el esfuerzo de migrar a SmartGWT puede ser alto). La sensación es de gran utilidad, despierta mi interés, alguna vez nos sacará de un apuro... pero, no depositaría todo mi desarrollo en esta tecnología (por si acaso).
  • AJAX: está tecnología realmente es un conjunto de tecnologías (XHTML, CSS, JavaScript, DOM y XMLHttpRequest) con la que se consigue una "mejor experiencia de nuestros usuarios" al usar aplicaciones o contenido simple en la Web. Si queremos que nuestra experiencia, como desarrollador, sea también mejor debemos hacer uso de alguna librería que nos facilite la vida: jQuery, Prototype, Mootools, etc. (pruébalas en este orden). No te aconsejo crear una aplicación empresarial en AJAX (salvo que sea con GWT)... simplemente "enriquece" con ella tus contenidos webs.
Mi consejo final es: hoy en día puedes apostar por Flex (la curva de aprendizaje no será muy alta), acércate poco a poco y sin prisas a GWT, observa de cerca a Silverlight (no lo deseches sólo por la marca) y, de momento, olvídate de desarrollar aplicaciones empresariales con JavaFX o con AJAX.