Buscar
Social
Ofertas laborales ES
jueves
may222008

Neil Young en 2008 JavaOne Conference

Neil Young estuvo presente en la 2008 JavaOne Conference para presentar su nuevo proyecto, en colaboración con Sun Microsystems, que se llamará 'Archives' y que aglutinará todo su arsenal musical en plan cronología  (albumes, videos, temas inéditos, etc.) en Blu-Ray y apoyado con tecnología Java.

En el video del enlace podemos ver a los capos de Sun Jonathan Schwartz y Rich Green presentando el nuevo proyecto junto al bueno de Neil.

Es bonito ver como 2 mundos distintos que a uno le apasionan como el Software y la Música se unen en este revolucionario proyecto. Y sobretodo que Sun tenga buen gusto musical...........

 

miércoles
may212008

Oracle da la bienvenida a los desarrolladores de BEA

 Con un post del editor en jefe de OTN, Justin Kestelyn; Oracle le da la bienvenida a los desarrolladores de BEA.

Sunrise: The BEA and Oracle Developer Communities Come Together

Dentro de su Oracle Mix portal han creado un grupo especial para esta fusion.

 La gente de Dev2Dev tambien ha escrito algo sobre el tema.

Confluence of BEA and Oracle Developer Communities Begins

 Ahora sí, creo, empieza a sentirse la unión.

Por el momento, me auto-doy la bienvenida XD !! 

RuGI 

miércoles
may212008

Análisis del consumo de memoria de Eclipse

Markus Kohler ha publicado en su blog el resultado de un análisis del consumo de memoria de Eclipse usando la herramienta Eclipse Memory Analyzer (MAT) de la cual es comitter. Esta herramienta es un plugin que analiza los heap dumps generados por la JVM, en específico aquellos con el formato HPROF. Formato soportado por la JVM de Sun, de HP y SAP (no se menciona si BEA JRockit lo soporta).

El análisis se realizó usando la JDK 1.6_10 y Eclipse 3.4 M7 con el proyecto de Winstone cargado. Los resultados son muy interesantes. Como podrás ver en el post de Markus en el resumen del análisis se aprecia que el corrector ortográfico es el objeto que ocupa más memoria memoria del IDE: 5,6 Mbyte lo que equivale a casi el 25% del total de 22,7 Mbytes ocupados por Eclipse. Este corrector ortográfico se incluye desde Eclipse 3.3 (Europa) y para mi es una de las características más molestas del IDE: sólo tiene soporte para Inglés y lo último que necesito es que mi IDE me diga si escribí bien o mal un comentario y además me lo marqué en rojo. Además de que siempre está activado por defecto.

La siguiente sorpresa viene cuando Markus decidió ver porqué esta herramienta ocupa tanta memoria y la respuesta es toda una sorpresa: el corrector está implementado como un enorme HashMap que hace un map de un String a una lista de Strings. Markus planea poner un bug sobre este tema, esperemos que lo hayan arreglado para cuando Eclipse 3.4 sea publicado.

El segundo punto que revisa es lo que llama su truco favorito para análisis de consumo de memoria: buscar Strings duplicados. Eclipse MAT tiene una herramienta que le ayudó en este trabajo y con la cual pudo detectar que los objetos String ocupan 12Mbytes del total de 22,7; de esos 4 son ocupados por el corrector ortográfico. Al hacer unh group by de los Strings, Markus pudo detectar los duplicados que muestran que Strings como "id" están duplicados 1988 veces o "name" 1210. El siguiente paso fue ver que clases eran la responsables de estas duplicaciones y encontró que ConfigurationElement es la clase responsable por mucho de la mayor cantidad con 13242.

Como dice Markus, que existan tantos Strings duplicados en una aplicación es el mayor problema de desempeño presente en la mayoría de las aplicaciones Java, esta herramienta nos permite detectarlo e incluso nos determina las clases responsables.

En mi experiencia este tipo de análisis en el mejor de los casos sólo se hacen cuando las cosas empiezan a fallar con típicos OutOfMemory y una vez que el desarrollo ha terminado. Markus nos demuestra en este artículo como de una forma bastante sencilla fue posible detectar dos objetos que consumen una cantidad de memoria importante (la implementación del corrector ortográfico y los Strings duplicados de la clase ConfigurationElement) que de arreglarse tendrían un impacto bastante bueno en el consumo de memoria de Eclipse. Con este tipo de herramientas ya no hay excusas para dejar estos análisis hasta que los errores empiecen a surgir.

Por cierto, Markus tiene planeado realizar el mismo análisis de Netbeans así que no está de más revisar su blog para cuando lo publique.

martes
may202008

Quake Live no estará hecho en Java

Quake Live [en] [es] (antes Quake Zero) es un proyecto secundario de id Software que pretende llevar Quake III a los navegadores web.

Se anunció ya el año pasado en QuakeCon y es interesante desde un punto de vista técnico. Aunque el juego en sí sea el mismo que el original y no aporte nada nuevo, llevar un juego de este estilo a los navegadores (según cómo se haga) puede suponer una solución técnica interesante. Y aunque lo único que se ha comentado a nivel técnico es que seguramente se base en algún tipo de plugin (es decir, tranquilos, no pretenden hacer el Q3 en Javascritp :p) los rumores -como era de esperar- abundan

Algo que se sabe desde hace unos meses es que no, Quake Live no se está haciendo en Java. Sin embargo, algunos se preguntan si es que eso sería necesariamente malo.

Basándose en la experiencia de jugar con Jake 2 sobre LWJGL en un applet y en los resultados comprobados (woho! 123FPS a 1152 x 864 en pantalla completa), uno podría plantearse qué más hace falta.

Desde luego en lo que respecta al motor, probablemente no haría falta mucho más. Lo que yo me pregunto es si no estará la decisión influenciada por el problema de la distribución. Los requisitos establecidos originalmente para Quake Live pretenden que uno pueda acceder desde el navegador, bajar un runtime mínimo e inmediatamente entrar en al menos una parte del juego mientras se va cargando el resto. Ya sabemos todos que esto mismo es lo que se quiere que pueda hacer el JRE y ya hemos hablado de esto con el último update de Java6, pero también hay que tener en cuenta que cualquier cosa que se desarrolle sobre un plugin ya existente va a necesitar cubrir primero los requerimientos de ese plugin y luego los del propio juego. ¿Es razonable por ello hacer un desarrollo propio en lugar de usar Java?

¿Qué otras razones podéis ver para hacer o no hacer Quake Live con Java?

martes
may202008

Informe sobre navegación en móviles de Opera

OperaMini es hoy en día el navegador para móviles más usado en el mundo, con más de 44 millones de usuarios. En este informe, presentan los resultados de analizar el tráfico de estos usuarios. Como dice el CEO de la compañía Jon S. von Teszchner en la presentación, la tendencia actual es hacia tener una sola web, que la información que puedas consultar en tu navegador de tu ordenador esté también disponible en tu navegador de móvil.

Para ello los ingenieros de Opera han trabajado desde 1998 con el fin de crear un navegador que se pueda ejecutar en pequeños dispositivos con las mismas características de su contraparte para ordenadores. En 2006 publicaron la primer versión de este navegador, cuya versión para telefonos móviles esta hecha con JavaME.

Pasando a los datos de este informe, en el primer apartado de "Tendencias" lo primero que resalta es que el las redes sociales dominan el tráfico de la web móvil, con un 40% del total del tráfico registrado, cifra que en algunos países como Estados Unidos llega al 60%.

Otro dato importante: el 77% del tráfico es a webs HTML normales, mientras que sólo el 23% restante es a páginas WAP y dominios .mobi.

En la primera parte del informe, se resume el crecimiento que ha tenido tanto el uso de OperaMini como las páginas vistas con este navgeador y la cantidad de los datos descargados con él. En los tres rubros, se ha registrado un crecimiento continuo (26%, 58% y 88% respectivamente en el último cuatrimestre del 2007). Lo que confirma que el acceso a la web a través de los dispositivos móviles sigue aumentando, aunque habría que revisar estos datos para España y algunos países Latinoamericanos donde las tarifas de las operadoras móviles siguen siendo una barrera para este tipo de acceso.

En la segunda parte, se resume el tipo de tráfico registrado por los usuarios de OperaMini. Como ya he dicho con anterioridad, casi la mitad es hacia redes sociales; mientras que un cuarto es hacia buscadores. En el resumen también aparecen el top 10 de webs visitadas par algunos países clave para Opera, como Rusia y Estados Unidos.

Esperemos que Opera continue con este tipo de informes, que arrojan datos bastante interesantes sobre el uso de la web a través de móviles. Datos que son posibles dado que todo el tráfico a los navegadores OperaMini tiene que pasar por los servidores de la empresa con el fin de optimizarlo para los anchos de banda de este tipo de rede.