HtmlCleaner 2.0

HtmlCleaner es una librería Java que permite generar HTML bien formado a partir de (en principio) cualquier tipo de documento HTML. Se distribuye bajo una licencia libre y acaba de anunciar su versión 2.0. Esta nueva versión incorpora un soporte parcial de XPath y soporte para aplicar modificaciones al documento HTML a través de métodos de la API de la librería que permiten modificar el contenido de los nodos y los atributos de éstos.

Tutorial sobre HttpClient por Fabio Haider de SAP

Fabian Haider - de SAP- nos ha enviado este tutorial sobre la librería de Apache Jakarta. HttpClient permite realizar conexiones sobre HTTP desde Java de forma sencilla. El tutorial está enfocado a principiantes que nunca la han usado.

Flex / Java Excelente combinación para aplicaciones RIA.

Ya es por todos muy conocido la excelente integración que existe entre las tecnologías Java/Flex.

Generalmente, apreciamos la tecnología Flex en aplicaciones de poco utilización, o utilización complementaria, en forma de multimedia interactivas asociadas a páginas web o aplicaciones enfocadas a tareas pequeñas, como configurar un producto X, o un buscador de propiedades, etc.

Aún y cuando la tecnología Flex tiene infinidad de posibilidades, pocas veces la podemos observar en aplicaciones robustas, que requieran de un uso diario y periódico por parte de sus usuarios y con grandes volúmenes de datos, tablas y objetos, como sí visualizamos aplicaciones Swing o Web.

Hace aproximadamente 1.5 años nos embarcamos en la aventura de desarrollar una aplicación tipo ERP llamada KINETIK-ERP, sobre arquitecturas Java/Flex, y hasta el momento la combinación de ambas tecnologías ha sido todo un éxito, tanto en la parte técnica, como en la parte funcional y de usabilidad, ambas tecnologías se han integrado de una forma completamente natural.

En el inicio de este proyecto, valoramos varias tecnologías para realizar la parte Cliente, entre estas se encontraban OpenLaszlo, Flex y Swing. Luego de varias pruebas y analizar el ambiente particular de cada tecnología, descartamos OpenLaszlo y Swing. En general, OpenLaszlo en ese momento estaba muy verde y aún cuando sé que muchos amantes de Swing puedan decir lo contrario, a mi parecer, Swing sigue siendo una arquitectura muy pesada y rígida en muchos sentidos.

Actualmente, KINETIK-ERP consta de más 16000 líneas java y más de 5000 líneas Flex. La arquitectura de la aplicación en la parte servidor consta de las tecnologías Java/Spring/Hibernate/Acegi/JasperReports y GraniteDS. En la parte de cliente, la aplicación esta implementada sobre Flex/Cairngorm/Modules, más innumerables clases que hemos desarrollo de nuestra parte.

Durante este proceso, nuestro aprendizaje ha sido constante, y hemos tenido que ir solucionando algunos baches de integración entre ambas tecnologías, que no se encuentran completamente satisfechos a la actualidad, pero en general nuestra experiencia ha sido muy positiva.

Algunos problemas de integración que hemos ido solucionando son:
  Integración, manejo y vencimiento de la sesión Web.
  Optimizaciones de comunicación entre plataformas.
  Integración de Flex con JasperReports.
  Reportes Dinámicos.
 
En resumen y basado en nuestra experiencia, les recomiendo el uso e integración de ambas tecnologías.

A continuación un link de nuestra aplicación con el fin que puedan observar la aplicación comentada.

KINETIK - ERP.

Saludos,
Kibsaim Vindas L.
www.alivebox.com

Sun despide a 2500 empleados y el trabajo del CEO Schwartz está en riesgo

Debido a pérdidas de USD$34 millones en el último cuatrimestre fiscal, SUN planea despedir a 1000 empleados de su división estadounidense y en sus otras divisiones a un número entre 500 y 1500. Lo que podría sumar un total de 2500 empleados despedidos a nivel mundial, el 7% del total de sus empleados.

El principal problema de Sun es que sus ganacias en Estados Unidos han venido cayendo año tras año en un 10% y dicha región representa alrededor del 40% del total de ganacias de la empresa. De acuerdo al CEO Jonathan Schwartz, continuarán con su estrategia de diversificar sus negocios con proyectos como la compra de MySql y no cambiarán su idea de regalar software para vender hardware.

Por otro lado, ya hay rumores de que Sun tendrá que buscar una fusión con otra empresa del sector para poder sobrevivir. Los analistas ponen a Fujitsu como la empresa más adecuada para fusionarse, aunque tampoco descartan a HP.

Además, dado que desde que Schwartz llegó al puesto de CEO, las acciones de la empresa han caído un 50%, ya se habla de que Sun ha iniciado la búsqueda de un remplazo que corrija el rumbo de una compañía que continúa perdiendo terreno ante IBM y HP en el mercado de servidores.

Esperemos que toda esta turbulencia en el mundo financiero de Sun y las posibles fusiones y cambios de liderazgo no afecten a su estrategia Java que en mi opinión desde que Schwartz está al mando ha tomado un rumbo muy provechoso para los desarrolladores. Basta ver el compromiso con el opensource que ha llevado a liberar el JDK, el desarrollo de Glassfish que por fin ha logrado que Sun tenga un servidor de aplicaciones JEE que puede competir con los líderes del mercado y Netbeans que se está convirtiendo en una plataforma muy interesante.

Si el rendimiento es importante, considera usar "Ropes" en vez de Strings

Los Ropes son una representación alternativa para las cadenas de caracteres. Habitualmente, una cadena de caracteres es representada internamente por un array de tamaño fijo. Desde hace bastante tiempo, se conocen estructuras para representar cadenas de caracteres que presenta mucho mejor rendimiento para operaciones como concatenación o reemplazado de caracteres. Ambas operaciones, si se representa la cadena de caracteres con un array, tienen una complejidad (en el mejor de los casos) lineal.

Sin embargo, representando la cadena de caracteres mediante un árbol es posible efectuar ambas operaciones en un tiempo logarítmico. En esto es, precisamente, en lo que consisten los "Ropes". No es una idea nueva en absoluto (podéis leer sobre los Ropes en este artículo de 1995).

Lo que sí es bastante reciente es que Amin Ahmad ha publicado en su web una implementación 100% Java de Ropes. Esta implementación tiene una complejidad logaritmica respecto al tamaño de la cadena de caracteres en operaciones de concatenar, borrar, reemplazar e insertar; complejidad muy inferior tanto a la de String (que puede llegar a ser cuadrática en algunos casos) y a la de StringBuffer (lineal).

Eso sí, un Rope, al representarse mediante un árbol, va a consumir más memoria que un String de toda la vida. De todos modos, si tu problema en la CPU y no la memoria, no estaría de más echarle un vistazo. La implementación de Ropes se distribuye bajo licencia GPL.