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.
viernes, 11 de septiembre de 2009
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:
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
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:
Etiquetas:
flex
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.
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" ;-)
En caso de no pasarle ningún argumento, busca dentro del directorio "local" desde el que lanzas el comando.
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.*;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.
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();
}
}
En caso de no pasarle ningún argumento, busca dentro del directorio "local" desde el que lanzas el comando.
Etiquetas:
java
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.
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.
Etiquetas:
ria
Suscribirse a:
Entradas (Atom)
