huelga informatica, nos afecta a todos..

Es realmente importante que todos digan la verdad…

lo primero la consultoras no estan interesados en que la carrera de informática este regulada, por que en ese caso no podrian seguir contratando gente de otras carreras tales como Fisicos, Matemáticos, Teleco..Industriales, darles una formacion en el lenguaje que les de la gana, y ponerles a trabajar pagandoles 1000 euros al mes. Es justo decir, que hay gente de estas carreras que son brillantisimos informáticos.. y lo demuestran dia a dia son compañeros nuestros y se merecen todo nuestro respeto y admiración.

Pero creo que es justo entender que si alguien decide cursar unos estudios, tambien es justo que se le acrediten unos conocimiento para realizar su profesion de la mejor forma posible. O caso si soy Ingeniero Informático se me permite diseñar un puente o un tunel? O un edificio? O puede realizar tareas de Ingeniero Industrial o Naval?

No verdad? Entonces no estamos jugando con la mismas reglas unos que otros si no que estamos en plena inferioridad.

¿que se consigue con eso? Devaluar unos estudios como son los de Ingenieria Informatica(Tecnica de Gestion y sistemas) que preparan para el analisis, diseño e implementacion y prueba de los diversos(¡ muy diversos!) sistemas informaticos que existen, no solo paginas web..o un pequeños programas de gestión.

Las tecnologías de la informacion cada vez controlan mas y mas areas, algunas vitales para el correcto funcionamiento de la sociedad, es justo el dejar el desarrollo de estos sistemas en manos de gente que no sabemos si tienen la cualificacion suficiente? Yo no dejaria que un médico que no tiene el titulo me tocara.. o no permitiría que que nadie utilizara un puente no diseñado por un Ingeniero de Caminos…

Como Ingeniera estamos muy devaluados, por que al ser una Ingenieria Joven, jamás se nos ha considerado como tal.. y cualquier “artista” se metia a desarrollar hacia cosas que funcionaran. Y eso ha funcionado muchos años. Pero la complejidad y tamaño de los actuales sistemas informáticos hacen necesaria la regulación profesional que de una garantias mínimas de que los procesos básicos de Analisis, Diseño e implementacion y test de un sistema se han dado..

Y eso .. señores politicos es lo que se esta matando ahora.. y para el futuro. Posiblemente solo sea por ignoracia, pero señores policos de este pais.. no podemos permitir que su desconocimiento afecte no solo a las personas(los profesionales de la informática) si no tampoco al desarrollo tecnológico de la sociedad..

creo sinceramente que estan equivocados….

ODF Toolkit Project

Después de una muy larga espera y muchos intentos de tener un toolkit unificado para el manejo del estándar ODF (OpenDocument Format), IBM y Sun Microsystems han anunciado en la OpenOffice.org Conference 2008 el lanzamiento de un nuevo site que unificará todos los esfuerzos desplegados alrededor de ODF:

http://odftoolkit.org/

Dentro del ámbito de Java, han habido dos intentos reseñables de ofrecer un API “pura” para el manejo de ODF, es decir, que no necesitaran acceder a una instalación de OpenOffice corriendo como un servicio:

• odf4j. Implementación dentro del marco de desarrollo de OpenOffice.
• jOpenDocument. Implementación muy completa, con soporte incluso para la conversión de hojas de cálculo a PDF.

Posteriormente, la gente de Sun Microsystems tomaron el control del proyecto odf4j y lo rediseñaron por completo. Con una nueva arquitectura de capas y el “empujón” de tener un grupo de expertos desarrolladores detrás, nació ODFDOM.

Con este nuevo toolkit se ha conseguido unificar esfuerzos de forma que, jOpenDocument ha pasado a basarse en ODFDOM en lugar de realizar su propio mantenimiento del acceso al modelo de objetos de los documentos ODF.

Sólo añadir que, para los desarrolladores .NET, también existe una implementación oficial dentro del proyecto “ODF Toolkit” y se llama AODL.

Glassfish v3 prelude publicada

Ayer jueves se publicó la versión prelude de lo que será la tercera edición de Glassfish, el servidor JEE open source de Sun y la implementación de referencia de JEE 6. Entre las muchas novedades de está edición, destaca el cambio de arquitectura a módulos gestionados por un contenedor OSGi (lo que supone el primer paso oficial de Sun por apoyar esta especificación) y su soporte a lenguajes dinámicos.

Sobre el soporte a OSGI, cabe aclarar que dicho soporte es interno y se usa para modularizar el servidor de aplicaciones y no para soportar aplicaciones web con OSGi como sí lo hace el Spring DM Server. Por ahora usan el contenedor Apache Felix, pero como demostró Ludovic Champenois, se puede usar cualquier otro como Eclipse Equinox.

Acerca del soporte a lenguajes dinámicos, la nueva arquitectura permite instalar plugins para soportarlos. out-of-he-box tenemos soporte para Groovy y Grails, JRuby on Rails, PHP y Scala/Lift. Vivek Pandey ha escrito los detalles de esta integración en su blog. Este concepto, aunado a que el servidor está pensado para poder ser embebido fácilmente (es más ligero que sus predecesores) y a un nuevo sistema de redeployment más dinámico y que conserva el estado de las aplicaciones, colocan a Glassfish como una alternativa muy interesante para el desarrollo ágil de aplicaciones web.

Además de esto, tenemos APIs  relacionadas con JDK y JEE como la implementación de JPA 2.0 (EclipseLink), el framework JMaki con componentes JSF y taglibs JSP para Ajax, Grizzly para Comet, el proyecto Metro para webservices y Jersey para servicios REST, JSF 2.0, EJB 3.1 y un largo etcétera.

La gente de Sun en mi opinión ha hecho muy bien las cosas con Glassfish, soy usuario de la versión 2 y me impresionó la calidad de servidor, a la altura de las alternativas comerciales como WebLogic o WebSphere. Quizás lo que le falta es más marketing en revistas y eventos para managers ;-) para que su uso se extienda en el mundo de aplicaciones empresariales. Por que por el lado de la estabilidad y madurez no tienen ningún problema.

¿Sun abandona Swing?

Kirill Grouchnikov ha escrito en su blog un interesante y triste análisis sobre la situación actual de Swing dentro de Sun. Al parecer, la empresa lleva un tiempo quitando presupuesto y congelando proyectos innovadores dentro de esta plataforma para UIs con el fin de enfocar los esfuerzos hacia el "hermano menor" JavaFX. Esta situación ha provocado bastante molestia entre los empleados de Sun dedicados a Swing y también en los contribuidores open source que apoyaban proyectos de esta tecnología.

La última de estas situaciones sucedió con el proyecto SwingX de SwingLabs. Este proyecto inició en 2004 patrocinado por Sun quien puso dinero y desarrolladores con el fin de desarrollar componentes para Swing. El éxito fue tal que pronto muchos desarrolladores empezaron a contribuir con él y todo apuntaba a que los componentes ahí desarrollados iban a llegar a ser parte del core de Swing. Kirill comenta que en especial los llamados painters (delegates que se conectan a un componente Swing para cambiar su apariencia) generaron mucha participación e interés por parte de Sun para incluirlos en el JDK. Sin embargo, en 2007 Sun de forma unilateral decidió quitar este componente de SwingX, lo que desanimó a muchos de los desarrolladores quienes se fueron del proyecto y no volvieron incluso cuando Sun decidió retirar a sus propios desarrolladores para dejarle más libertad a la comunidad. Ahora, Sun ha anunciado que dejará de patrocinar monetariamente este proyecto.

Esto, como comenta Kirill, es solo uno de muchos casos de lo que está pasando dentro de Swing. Donde toda innovación o mejora ha sido detenida y solo se desarrollan aquellas áreas que puedan servirle al roadmap de JavaFX. En palabras de Richard Bair, uno de los encargados de Swing en Sun:

"Swing es parte del JDK. No va a desaparecer en un futuro cercano. Para muchas aplicaciones empresariales Swing es el mejor toolkit disponible. Continuaremos dándole soporte y trabajando en arreglar bugs en el JDK." 

Al parecer esas son las únicas áreas que atacarán sobre Swing: soporte y bug fixes. Con los problemas económicos de la compañía Sun debe decidir cuidadosamente a que proyectos destinar recursos y por lo que parece en términos de UI ha optado por apoyar con todo a JavaFX y detener cualquier desarrollo de Swing, una tecnología mucho más estable y usada. Guillaume Laforge, en un post sobre el mismo tema en su blog, explica muy bien por que está decisión es por lo menos extraña:

 "¿Por qué abandonar una tecnología tan buena? Sé que no son siempre las mejores tecnologías las que ganan y prevalecen, pero cuando tienes una ventaja competitiva en un área, ¿por qué no mantenerla en lugar de apostarlo todo al nuevo juguete brillante del día?  Un juguete brillante que ha ha venido fallando en todos los demos de las conferencias en las Java One."

¿Qué les pasa a los Servicios Web? (Opinión publicada originalmente en Sólo Programadores)

 ¿Qué les pasa a los Servicios Web? (Opinión publicada originalmente en Sólo Programadores)

José María Arranz, presidente de Innowhere

Es conocida la tradicional rivalidad entre las técnicas de servicios web SOAP y REST, durante años el claro ganador ha sido SOAP, sobre él se han construido montones de estándares (los WS-*) y herramientas. Inicialmente propuesto como forma “simple” (la S de SOAP) de comunicar sistemas heterogéneos alternativa al CORBA, se ha convertido en un mundo complejo donde las herramientas son fundamentales.

Sin embargo aparentemente REST está ganando la batalla, parece que se vislumbra una crisis de los servicios web a lo SOAP. InfoQ.com se hacía eco en el artículo “SOAP Stack an Embarrassing Failure?” citando opiniones muy influyentes como la de Tim Bray, inventor del XML y director de tecnologías web en Sun. Un  dato más objetivo, la web programmableweb.com/apis/directory reporta más del doble de servicios públicos basados en REST (559) que en SOAP (209), como anécdota sigue listado el desaparecido Google Search en SOAP.

Las razones del declinar de SOAP son diversas, la más citada es la sencillez de REST, una simple URL y un navegador permite acceder a servicios de consulta. Sin embargo el infierno está en los detalles, REST es actualmente un mundo muy artesanal, desnormalizado y “pobre”; la “natural” búsqueda de la automatización, la generación de código, la necesidad de vender herramientas, “amenazan” con estandarizar y complicar el reino de taifas REST, por ejemplo con iniciativas como el WADL, una especie de WSDL. ¿La historia acabará repitiéndose?  así es la industria del software…