Linux 32bits Google Gears Firefox 3.6

Hola,

Hace poco Google sacó la versión 0.5.36.0 de Google Gears que tiene compatibilidad con Firefox 3.6. Pero seguro al tratar de instalarla Firefox dice:

"Google Gears" no se pudo instalar porque no es compatible con su tipo de versión de Firefox (Linux_x86-gcc3). Contacte al autor de este ítem acerca de este problema.

Y apuesto a que ese mensaje ha salido más de una vez inclusive con Firefox 3.5 ¿Verdad? Seguro cuando revisas la lista de complementos dice que tienes instalado Google Gears 0.5.32.0.

Bueno resulta que en la página de Google Gears desde la versión 0.5.33.0 está disponible sólo la versión de 64 bits. Si tienes instalado openSUSE 11.2 o Ubuntu 9.10 pero de 32bits debes estar sufriendo el mismo problema.

Entonces lo que hay que hacer es bajar se código fuente y compilarlo para tener la versión de 32bits. Resulta que al intentarlo a la primera, no compila y es porque hay que modificar el código para que compile con el compilador que tenemos instalado (gcc 4.3 en mi caso).

En lo que tenga tiempo modificaré este post para incorporar las instrucciones de como modificar el código y hacerlo compilar con gcc4 (Ojo no es más que agregar unos includes en un montón de archivos).

Pero mientras eso pasa aquí les dejo el plugin compilado de Google Gears ( versión 0.5.36.0) que funciona en Firefox 3.6 y openSUSE 11.2 32Bits. Imagino que funciona también en ubuntu 9.10 pero no lo he probado:

Google Gears versión 0.5.36.0 para Firefox 3.6 y Linux 32 Bits (no usar en Firefox 3.5, windows o Linux 64bits)

Espero sus comentarios a ve que tal les va.

kde4 uso eficiente del plasma (uso no evidente)

Hola,

Hasta hace muy poco utilicé openSUSE con KDE 3 y una de las cosas que extrañé cuando definitivamente me moví a KDE 4 en openSUSE 11.2, es que en KDE 3 uno puede invocar el menú inicio (K menú) poniendo el cursor en la esquina inferior izquierda de la pantalla sin hacer clic. Una tontería, pero buscando una característica similar en KDE 4 me encontré con una muchísimo más poderosa.. el tablero de mandos del plasma.

Y es que combinando 3 cosas:

1. El tablero de mandos del plasma.
2. Los elementos gráficos.
3. Los bordes de escritorio y los efectos de KWin.

Se puede tener una especie de mesa de trabajo (escritorio) con el menú K desplegado, una calculadora, un calendario, el selector de color, etc. Que está a sólo mover el ratón a una de las esquinas de la pantalla. Aquí unas imágenes de lo que estoy tratando de explicar:

Pasos a seguir:

1. Asignar el tablero de mandos a una de las esquinas del escritorio (prefiero esquina inferior izquierda):
   
   
   
   
2. Separar el tablero de mandos del escritorio. Ésto lo hago porque en el escritorio me gusta tener un fondo algo que haga juego con las ventanas y no herramientas de trabajo que haga que se parezca a mi escritorio real (un desastre).
   
   
   
   
3. Invocar el tablero de mandos y agregar los elementos gráficos que más usemos. Yo en lo particular recomiendo el menú K (Lanzador de aplicaciones) ponerlo del mismo tamaño que el menú real (se puede presionar la tecla Ctrl mientras cambiamos su tamaño para mayor control; una calculadora; un conversor de unidades; un calendario y algunos iconos de los programas más usados. No recomiendo colocar alguno que nos mantenga más de unos segundos en el tablero (como un terminal).

Adicionalmente:

Asigno la Rejilla del escritorio y Presentar las ventanas a las otras esquinas del escritorio:

Conclusión

Por ensayo y error conseguí el increíble poder que tiene el plasma y de por qué se le da tanta fuerza dentro de KDE y openSUSE. Lamentablemente como me sucedió a mi, su uso eficiente no es tan evidente como se quisiera. Yo le recomiendo a la gente de KDE y openSUSE que saquen una configuración de plasma por omisión, para sacarle el mayor provecho sin tener que configurar.

Queremos escuchar tus experiencias, publica tus comentarios de como te fue con los tips o si ¿Tienes otros mejores? ¿Qué piensas del Plasma?

Hasta la próxima...

Javadocs fuera de línea con google gears y grease monkey

Hola,

Una de las herramientas indispensables cuando se está usando un API (biblioteca de código) es su documentación. Para las APIs en Java, su documentación está en un formato muy específico el javadoc. Ésta es una especie de interfaz web autogenerada de los comentarios en cierto formato que se coloca en el código. La naturaleza web del javadoc permite colocarlo en un sitio web sin mayores complicaciones. Ésto es perfecto para buscar rápidamente la documentación de una clase, siempre está disponible, excepto claro, cuando no tenemos conexión a Internet.

Una de las opciones para tener el javadoc cuando no tenemos conexión a Internet o cuando está lenta es, descargar el javadoc en formato zip expandirlo en un directorio y abrir el archivo index.html en un navegador. Ésto claro cuando el desarrollador de la biblioteca lo provee. Me ha pasado un par de veces que el javadoc está en línea pero no está en formato descargable.

Bueno existe una forma de descargar el javadoc directamente desde el sitio en línea (sin usar wget) y poder acceder a la información descargada con sólo poner la misma dirección en el navegador (aún sin conexión a Internet) que la versión en línea.

Esta magia la hace un plugin llamado Google Gears. Gears permite descargar páginas completas, tener una base de datos entre otras facilidades. Y usamos Greasemonkey un plugin que permite inyectar código javascript en cualquier página. Por fortuna el javascript que necesitamos también está listo para descargar, así que es cuestión de clics.

Pasos:

1. Descargar e instalar Google Gears: http://gears.google.com/
2. Descargar e instalar Greasemonkey: https://addons.mozilla.org/en-US/firefox/addon/748
3. Una vez reiniciado firefox, ir a: http://userscripts.org/scripts/show/42560 y presionar el botón Install.

Listo vamos a probarlo:

Probemos con la documentación de persistencia de EJB 3.0 en el sitio de Hibernate. https://www.hibernate.org/hib_docs/ejb3-api/ al introducir este url en el navegador aparecerá un mensaje de Google Gears preguntando si permitimos este sitio usar Google Gears. Presionar permitir:


Luego vemos que se carga la página del javadoc, pero en la esquina superior derecha aparece un contador.


Se están contando las páginas del javadoc que están siendo descargadas. Al finalizar tendremos todo el javadoc en nuestra pc. Pruébalo quita la conexión a Internet e ingresa la url: https://www.hibernate.org/hib_docs/ejb3-api/ y navega verás que es como si hubiera conexión a internet.

El procedimiento anterior se puede usar con cualquier javadoc que esté en línea.

Ahora no necesitas tener internet para ver la documentación... Hasta la próxima...

Validando xml con xsd usando msv

Hola,

Parte del proceso de utilizar xml para el intercambio de datos, por ejemplo importación y exportación de datos hacia y desde nuestro sistema respectivamente, es tener clara una definición del archivo xml que se va a utilizar. Para ello generamos un archivo xsd (XML Schema) con la definición de nuestro xml.

Ahora bien antes de intentar cargar una data en formato xml en nuestro sistema, es aconsejable primero verificar que el archivo está bien formado y luego si cumple con nuestra definición. Bueno hoy les enseñaré como hacerlo en Java.

Primero necesitamos una biblioteca llamada msv (Multi Schema Validator) se puede descargar desde aquí: https://msv.dev.java.net/ . Este paquete funciona de dos maneras:

1. Como un programa de línea de comandos para validar xmls con un xsd que se especifique.
2. Como una biblioteca que permite validar xmls con xsds directamente desde nuestro código en Java.

Para probar como funciona, vamos a descargar el zip del msv y expandirlo en cualquier directorio (tiene su propia carpeta) ahora para probarlo ejecutamos la siguiente línea de comandos:

java -jar msv.jar mi.xsd mi.xml

Si todo sale bien y el documento es válido debería soltar:

start parsing a grammar.
validating mi.xml
the document is valid.

Ahora bien para usarlo desde nuestro código Java lo primero que hay que hacer es incluir todos los jar de la carpeta msv en nuestro classpath (isorelax.jar, relaxngDatatype.jar, xmlParserAPIs.jar, msv.jar, xercesImpl.jar, xsdlib.jar). Luego el siguiente código nos permite validar nuestro xml:

/* Paso 1 creamos el fabricador de verificadores */
VerifierFactory factory = new com.sun.msv.verifier.jarv.TheFactoryImpl();

/* Paso 2 compilamos el esquema (nuestro archivo xsd) */
Schema schema = factory.compileSchema(new File("mi.xsd"));

/* Paso 3 creamos el verificador */
Verifier verifier = schema.newVerifier();

/* Paso 4 validamos */
if(verifier.verify(new File("mi.xml"))) {
// el documentos es válido
} else {
// el documento es inválido
}


Con ésto estamos listos. Algo muy importante si la verificación la estamos haciendo en una PC que no tiene conexión al Internet, vamos a tener que agregar el componente resolver de Apache XML Commons al classpath. Se puede descargar aquí: http://xml.apache.org.


Hasta la próxima...

Nota: Si esta información te es de utilidad o piensas que se puede mejorar, por favor deja un comentario con tus observaciones.

Utilizar wine para probar aplicaciones Java en ambiente Windows desde Linux

Al leer este título, lo primero que viene a la mente es: ¿Para qué correr aplicaciones Java sobre wine si Java existe para Linux? Además las aplicaciones Java son multiplataforma. Ajá, paremos ahí y revisemos la última palabra de la frase: multiplataforma.

Muchas veces queremos verificar que tal corre nuestra aplicación en otra plataforma, para precisamente verificar que es multiplataforma. Hay varias cosas que pueden dejar de funcionar (o funcionar diferente) cuando se corre en otra plataforma:

• Nombres de archivo: Los separadores de nombres de archivo es lo más cambiante entre plataformas.


• Llamadas a comandos externos: Hay unos cuántos problemas que se solucionan fácilmente en Linux invocando comandos ¿Y en Windows?. Un ejemplo a éste respecto es el método listRoots() de la clase File. Si se quiere saber los volúmenes montados, en Windows funciona perfecto, pero en Linux únicamente retorna "/", entonces una de las maneras de resolverlo es invocando al comando df (entre otros) parsear su salida y obtener las unidades montadas.


• Codificación de caracteres: Nuestras letras acentuadas comúnmente se ven mal en otras plataformas si no tenemos el debido cuidado.


• Applets: Probar nuestros applets en navegadores que no corren en nuestra plataforma de desarrollo. Por ejemplo, Internet Explorer sobre Linux. No sólo estaríamos probando nuestra aplicación en otra plataforma sino además en otro navegador.

Para los casos antes mencionados y algunos otros, nos gustaría verificar que tal corre nuestra aplicación en otra plataforma. Específicamente si estamos desarrollando en Linux, poder correr la aplicación en Windows. Si tenemos dual boot, perfecto, reiniciamos la PC en Windows y listo. El problema es todo lo que tenemos que esperar para hacer una prueba. Para ésto podríamos usar wine.

Para utilizar java sobre wine, simplemente se instala la versión Windows de la máquina virtual de Java usando wine así:

wine jre-6u11-windows-i586-p.exe

Una vez instalado, simplemente corremos nuestro programa en "Windows" así:

wine java -jar ~/jdk/demo/jfc/SwingSet2/SwingSet2.jar

Fíjense que la única diferencia es colocar wine adelante. Si tienen instalada java 6 de la actualización 10 en adelante y la aplicación que van a ejecutar es gráfica, deben deshabilitar el soporte Direct3D para Swing ya que no funciona bien con wine. Así que la línea de comandos queda:

wine java -Dsun.java2d.d3d=false -jar ~/jdk/demo/jfc/SwingSet2/SwingSet2.jar

Les va a impresionar lo bien que corre.

Applets

Uno de los usos más frecuentes para wine es correr Internet Explorer en Linux y así probar como se ven nuestros sitios web. Bueno si somos desarrolladores de Applets, podríamos usar Internet Explorer sobre wine para poder verlos sin tener que salir de Linux. Basta con tener instalado Internet Explorer antes de instalar java. ¿Y que tal un applet en Firefox sobre windows?

Aquí les presento las instrucciones para hacer correr applets en java 1.4 Internet Explorer 6.0 Windows 98, escojo esta configuración porque todo corre casi perfecto.

1. Instalar Internet Explorer 6.0 en wine simulando Windows 98, en este paso no me extenderé ya que hay sin número de artículos que lo explican. Usen winetricks para ello. Si tienen Crossover (versión comercial de wine) es cuestión de unos clics.
2. Instalar Java 1.4 para Windows 98 en wine. Aquí les dejo el enlace: http://java.sun.com/products/archive/j2se/1.4.2_19/index.html
3. Hasta aquí los applets deberían correr perfectamente. Pues no, así como la versión 6 de java tiene problemas con Direct3D en wine, java 1.4 los tiene con DirectDraw, cosa que no es tan sencilla desactivar para los applets. Lo que hay que hacer es ejecutar a mano el panel de control de java en wine, desactivando el directdraw para poderlo mostrar y ahí desactivar el directdaw para los applets. Aqui el comando:
   cd ~/.wine/drive_c/Program\ Files/Java/j2re1.4.2_19/lib/

wine java.exe -Dsun.java2d.noddraw=true -Xbootclasspath/a:plugin.jar sun.plugin.panel.ControlPanel

   Cuando se esté ejecutando el panel de control, se debe ir a la pestaña Avanzado y escribir -Dsun.java2d.noddraw=true en al campo Parámetros del entorno de ejecución y presionar Aplicar.
   

Con los pasos anteriores ya los applets deberían correr en Internet Explorer en Linux. Para versiones posteriores es posible que se necesite la misma técnica para deshabilitar el Direct3D en java. Cuando tenga una buena prueba actualizaré este post.

Para hacer el proceso inverso. Se podría instalar java para linux sobre Cygwin en Windows. No se si estoy diciendo una locura porque no lo he probado. Si alguien lo ha hecho, cuéntanos tu experiencia.

Hasta la próxima...

Nota: Si esta información te es de utilidad o piensas que se puede mejorar, por favor deja un comentario con tus observaciones.

Mejora el rendimiento de tu aplicación web usando compresión

Una de las características que tienen los navegadores de hoy en día, es poder aceptar contenido comprimido con gzip o con zip. Esto supone una enorme reducción en el peso de nuestras páginas, ya que el código HTML tiene muchas repeticiones en su contenido. Estamos hablando que en general (sin contar imágenes) nuestras páginas y código javaScript obtienen una reducción de mucho más del 50% (estamos hablando de alrededor de un 70%). Eso se traduce directamente en que nuestras páginas cargan más rápido.

Ya los grandes como Google o Yahoo están utilizando esta capacidad para mejorar el rendimiento de sus sitios. Ahora, ¿Por qué los servidores web (Apache, tomcat, Jboss, etc) no tienen esa opción habilitada por omisión? La razón es que los browsers antiguos contenían errores y soporte muy precario para el contenido comprimido.

Yendo al grano. ¿Cómo habilitar la compresión?

Tomcat / JBoss:

• Abrir el archivo server.xml, localizar los conectores:

<connector port="8080" maxhttpheadersize="8192" maxthreads="150" minsparethreads="25" maxsparethreads="75" enablelookups="false" redirectport="8443" acceptcount="100" connectiontimeout="20000" disableuploadtimeout="true" emptysessionpath="true" >

• Agregar los siguientes atributos:
  
• compression = "on"
• compressableMimeType = "text/html,text/css,text/javascript,text/xml"


Estos atributos le dicen al tomcat que comprima todo el contenido de los tipos especificados.

Se deben colocar en todos los conectores, para así habilitar la compresión para SSL y las conexiones que vienen a través de un servidor Apache o IIS.

Si estamos sirviendo contenido para internet, lo más probable es que tengamos un Apache que sirve el contenido estático y le pase a tomcat/jboss el control para procesar el contenido dinámico. En este caso debemos también configurar Apache para que sirva el contenido estático comprimido.

Otra de las razones por las que no se habilita por omisión la compresión, es por el impacto en rendimiento que puede causar en los servidores. Con los servidores que hay ahorita pienso que es seguro habilitarla. Sin embargo, no está demás considerarlo y hacer las pruebas respectivas. Existe la manera de utilizar contenido precomprimido, pero eso aún no lo he investigado. Cuando lo tenga claro escribo otro post.

Si se tiene sólo al tomcat/jboss atendiendo las peticiones, recomiendo habilitar las librerías nativas APR. Las instrucciones están en otro post (Librerías nativas Tomcat 5.5 y 6.0).

Apache:

Hay dos formas equivalentes, o se crean archivos .htaccess o se edita el archivo httpd.conf, /etc/apache2/default-server.conf o sus equivalentes. Pero el contenido que se coloca es el mismo:

# compress all text & html:
AddOutputFilterByType DEFLATE text/html text/css text/xml text/javascript application/xhtml+xml application/x-javascript text/x-js

Esto se pone tal cual en los .htaccess y dentro de los tags <Directory> en los otros archivos como el httpd.conf o el /etc/apache2/default-server.conf. Esta instrucción le dice al servidor que todos los tipos de archivo ahí especificados los mande comprimidos. Ejemplo:

<Directory "/srv/www/htdocs">
  # Possible values for the Options directive are "None", "All",
  # or any combination of:
  #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
  #
  # Note that "MultiViews" must be named *explicitly* --- "Options All"
  # doesn't give it to you.
  #
  # The Options directive is both complicated and important.  Please see
  # http://httpd.apache.org/docs-2.2/mod/core.html#options
  # for more information.
Options All
  # AllowOverride controls what directives may be placed in .htaccess files.
  # It can be "All", "None", or any combination of the keywords:
  #   Options FileInfo AuthConfig Limit
AllowOverride None
  # Controls who can get stuff from this server.
Order allow,deny
Allow from all


    AddOutputFilterByType DEFLATE text/html text/css text/xml text/javascript application/xhtml+xml application/x-javascript text/x-js

</Directory>

Hay que asegurarse que el módulo mod_deflate está instalado. Eso en Linux se verifica en la variable de /etc/sysconfig/apache2 APACHE_MODULES. Ejemplo:

APACHE_MODULES="unique_id  ... mod_jk jk mod_deflate"

¿Alguna pregunta? Bienvenida

Hasta la próxima...

Nota: Si esta información te es de utilidad o piensas que se puede mejorar, por favor deja un comentario con tus observaciones.

Java 1.5 Usar autoboxing o métodos valueOf para mejorar el rendimiento (Ventajas)

Java 1.5 vino con varias mejoras en el lenguaje. Entre ellas autoboxing y autounboxing. ¿Y para que sirve? si tienes que usar un objeto "wrapper" para meter enteros en una lista por ejemplo, en vez de usar new Integer(numero), usas directamente número. Entonces imaginemos que queremos meter 3 números en una lista, en Java 1.4 se haría así:

List lista = new ArrayList();

lista.add( new Integer( 1));
lista.add( new Integer( 2));
lista.add( new Integer( 3));

En Java 1.5 se haría así:

List <Integer> lista = new ArrayList<Integer>();

lista.add( 1);
lista.add( 2);
lista.add( 3);

El compilador se encarga de crear los objetos wrapper por uno.

Esta característica pareciera sólo cosmética, es decir, que sólo serviría para poner el código más bonito. Pero resulta que por dentro tiene una optimización.

Las clases wrapper en Java 1.5 ahora tienen unos métodos llamados valueOf. Que simplemente reciben un número y devuelven la clase wrapper correspondiente. Bueno resulta que cuando java hace autoboxing no usa los constructores (new Integer) sino los métodos valueOf. La ventaja de estos métodos es que guardan un caché de instancias de números más usados (-127..128). en general rara vez los números pasan de ese rengo. Como las clases wrapper son inmutables no importa tener la misma instancia para todos los Integer que representen el número 1. Así en vez de tener innumerables instancias de Integer que embasuren la memoria y enlentezcan el Garbage Collector(ya que en su mayoría son objetos que tienen muy corta vida) y que además todos representen el mismo número, se tenga una única instancia por cada número distinto.

En resumen, usar el autoboxing no sólo hace más sencillo el código, sino que además es más eficiente en cuanto al consumo de memoria se refiere.

Si no se quiere usar el autoboxing porque puede ser confuso, al menos deberían usarse los métodos valueOf. El código anterior quedaría así:

List <Integer> lista = new ArrayList<Integer>();

lista.add( Integer.valueOf( 1));
lista.add( Integer.valueOf( 2));
lista.add( Integer.valueOf( 3));

Hasta la próxima...

Nota: Si esta información te es de utilidad o piensas que se puede mejorar, por favor deja un comentario con tus observaciones.