Charla: Compiere, un ERP open source en Java

cartel-compiere-small

El próximo jueves 14 de mayo a las 12:30 h. en el Salón de Grados de la Escuela Politécnica (Edificio I), en un acto organizado por el Título de Especialista Universitario en Java Enterprise, la empresa Directive Soft impartirá la charla ‘Compiere, un ERP open source en Java’, en la que se tratarán los siguientes temas:

  • Conociendo el liderazgo de Compiere ERP
  • Código abierto
  • Funcionalidades de Compiere
  • Personalizaciones Avanzadas
  • Diccionario de Datos
  • Workflow

Oracle compra Sun

Hoy se acaba de hacer público el acuerdo de adquisición de Sun por parte de Oracle. En la nota de prensa que se ha publicado tanto Scott McNealy como Jonathan Schwartz por parte de Sun se felicitan por el acuerdo. Por el lado de Oracle, Larry Ellison hace hincapié en que tras el acuerdo Oracle va a poder ofrecer a sus clientes un completo stack de productos que abarca desde el sistema operativo Solaris (de Sun) hasta bases de datos, Java y software de gestión de negocios.

¿Qué sucederá con el SAI? No lo sabemos. Es una de las muchas incógnitas en este momento. En el documento de preguntas más frecuentes dicen explícitamente que Oracle continuará con la estrategia de formación y cursos de Sun (y suponemos que con su política de apertura hacia las universidades). Habrá que esperar unos meses a que concluya la integración de las compañías.

Otras preguntas todavía sin respuesta: ¿qué sucederá con los productos duplicados (o triplicados) en el stack? Muchos de los productos de Sun ya tienen su equivalente en Oracle: GlassFish (servidor JavaEE), MySQL, NetBeans (entorno de desarrollo). Muchos pensamos que los productos de Sun (a excepción de la base de datos) son mejores, pero al final serán criterios de negocio los que primen. ¿Qué sucederá con la apuesta de Sun por el open source? Oracle ya ha dicho que quiere rentabilizar rápidamente la inversión y convertir a Sun en una máquina de hacer millones. Mucho me temo que los experimentos han terminado. ¿Qué sucederá con el JCP, el proceso de definición de estándares de Java? Esta pregunta es más fácil de responder. Supongo que no cambiará demasiado, aunque ahora otros jugadores (léase IBM) estarán algo más reticentes a que sea controlado/dirigido por el nuevo gigante. ¿Qué sucederá con Java en el escritorio? JavaFX era una de las grandes apuestas de Sun y no parece encajar muy bien en una empresa como Oracle orientada al mundo de los servidores. Son muchas preguntas que se irán respondiendo en los próximos meses.

Una cosa segura, sin embargo, es que la nueva empresa Oracle/Sun va apostar igual de fuerte que la antigua Sun por el lenguaje y la plataforma Java. Todos los productos de Oracle dependen de este lenguaje y de esta plataforma. Eso sí, quizás se va a ralentizar su evolución y no vamos a ver demasiadas novedades en bastante tiempo (por parte de Oracle; sin embargo, la comunidad seguirá innovando como siempre: Groovy, Scala, …).

Como reflexión final, es bastante triste que el destino de una empresa como Sun sea el ser comprada por otra. Han estado más de 20 años innovando y, como dice Jonathan Schwartz en un correo enviado a los trabajadores de Sun, pensando y diseñando a diez años vista. Pero los resultados a corto plazo son los que mandan en la actualidad y algunos han terminado perdiendo la paciencia.

Comunicado de prensa

Preguntas más frecuentes

Noticia y comentarios en InfoQ

Un Enfoque Pragmático (I)

Buenas, ya estamos de vuelta. ¡ Han pasado las Navidades, y casi la Pascua !

Para que no se haga eterno y pueda publicarse antes de que cambiemos de milenio, he dividido este articulo en dos. Aquí va la primera parte.

En el primer apartado, La Maldad del Duplicado, se nos recomienda que no debemos duplicar el conocimiento a lo largo de nuestro sistema, y además, no dividir una pieza de conocimiento entre múltiples componentes del sistema. Es decir, que cada pieza de conocimiento tenga una representación única, fiable y sin ambigüedades.

Tip 11: DRY – No te repitas (Don’t Repeat Yourself)

DRY

¿Algo da más rabia para un desarrollador que hacer lo mismo dos veces? Pues aunque parezca que no, al final siempre nos acaba sucediendo. Es más, al tener partes de la aplicación duplicada (reglas de negocio, métodos, menús, etc…), con cada cambio, nos toca retocar cada parte por duplicado/triplicado/…

¿Y por qué aparecen los duplicados? porque (1) no podemos evitarlos, o (2) no nos damos cuenta, (3) por pereza o al compartir código, (4) por duplicación del mismo trabajo por diferentes desarrolladores.

¿Y como evitar la duplicación? ¿Es posible? En el primer caso, cuando no podemos evitarla, por temas de diferente representación de la información, los generadores de código pueden ayudarnos. Cuando documentamos el código, estamos duplicando. Y los comentarios,en ocasiones son imprescindibles. ¿Solución? Simplifica el código. ¿Y si el código se basa en un documento de especificación? ¿Y qué pasa con los lenguajes de programación que nos hacen repetir mucho código (no hay que ir más lejos que la separación interfaz/implementación)? Aquí la refactorización y los IDEs juegan un papel muy importante. Cuando los duplicados aparecen por nuestra negligencia (suena mejor descuido), solo nos queda aprender de los errores. Respecto a la pereza (o las prisas), os dejo dos refranes. No dejes para mañana lo que puedes hacer hoy y Vísteme despacio que tengo prisa. 🙂 Y finalmente, para la debida al trabajo en equipo, lo mejor es la comunicación, abierta, activa, bidireccional y entre todos los miembros del equipo.

Tip 12: Facilita la Reutilización (Make It Easy to Reuse)

Para evitar duplicados, si nuestro código es reusable y está localizable en un lugar adecuado, nuestro equipo no va a reimplementar algo que ya está hecho. Si el código no es reusable, o su uso no es facil/amigable, nadie lo usará, e inevitablemente, aparecerán duplicados 🙁

En el segundo apartado, titulado Ortogonalidad, se trata la cohesión y el acoplamiento (2 de los conceptos más importantes dentro de la ingenieria del software). 2 lineas son ortogonales si forman un angulo recto. 2 vectores son ortogonales si son independientes. 2 componentes son ortogonales si al modificar uno, el otro no se ve afectado. La base de datos es ortogonal del interfaz de usuario, si al modificar la base de datos, no tenemos que modificar ninguna pantalla  ¿esto es posible?

Tip 13: Elimina los Efectos entre las Cosas que No Están Relacionadas (Eliminate Effect Between Unrelated Things)

Al diseñar componentes cohesionados y con bajo acoplamiento, un cambio en un componentes evita tener que cambiar otros. Con esto, ganaremos productividad, ya que aquello que es modificable está localizado, y por tanto, los cambios se hacen estimable, las pruebas viables, y además, se reduce el riesgo.

Respecto a como eliminar los efectos, con una buena organización del equipo de desarrollo, un diseño basado en capas, con un buen uso (y no abuso) de los patrones de diseño, con ayuda de la AOP, etc…

El tercer apartado, Reversible, trata sobre la inestabilidad de las decisiones. Lo que hoy es blanco, mañana es negro y la semana siguiente es gris. El problema viene cuando estas decisiones son críticas, como elegir un proveedor de base de dastos o un patrón arquitectónico, ya que el coste de deshacer esta decisión suele rechazar de antemano la posibilidad del cambio.

Dentro del marco de las metodologías ágiles, donde se abrazan los cambios y el diseño se minimiza para favorecer la producción temprana de código, el cual va mejorando día a día mediante refactorizaciones, nuestra aplicación va a cambiar siempre. Lo que hoy nos vale como solución, puede que dentro de un mes no. Hoy hacemos un prototipo, y la semana que viene lo tiramos a la basura.

Tip 14: No Hay Decisiones Finales (There Are No Final Decisions)

Por esto, necesitamos que nuestra arquitectura sea flexible, que vea los cambios como algo bueno (al fin y al cabo, una petición de cambio por parte del cliente supone más trabajo, y más trabajo debe suponer más ingresos). ¿Como conseguimos una arquitectura flexible? Una arquitectura en capas (lógicas, más que físicas) es imprescindible, así como un buen uso (y no abuso – me repito) de los patrones de diseño.

Bueno, hasta aquí medio capítulo más … espero que os haya gustado. La segunda mitad, si no pasa nada raro, estará para después de vacaciones. A disfrutar del merecido descanso, y que la fuerza os acompañe 😉

Master class de Sun Microsystems

La Delegación de Alumnos de la EPS nos informa que Sun Microsystems vuelve a la Universidad de Alicante. Esta vez para impartir una master class sobre Java, SAI (Sun Academic Initiative),  los caminos curriculares de Sun Learning Services, y los certificados oficiales de Sun. Será el próximo viernes 27 de Marzo a las 13:00 en el salón de actos de la EPS (Edificio IV)

Además del interés de los temas a tratar, otro aliciente para asistir a la charla es que se sorteará una certificación oficial entre los asistentes.

Charla de Sun Microsystems

Mañana jueves 12 de marzo a las 12:00 en el Salón de Grados de la Escuela Politécnica Superior se presentará la sesión informativa ‘Sun Opensource Technologies’ a cargo de los ingenieros del programa ‘Sun OpenSource Technologies Tour’, orientada a profesores, investigadores y alumnos de últimos cursos de Informática.

La sesión tendrá una duración de 2:00 horas, repartidas de la siguiente manera: Sesión OpenSolaris (50 min.), Sesión OpenSPARC (50 min.), y exposición Programas Formativos gratuitos para Universidades en tecnología Java, etc. (20 min.).

Una Filosofía Pragmática

Me encanta el modo en que empieza el capítulo. Ser un programador pragmático es una actitud, un estilo, un filosofía a la hora de enfocar los problemas y sus soluciones. Consiste en pensar más allá del problema inmediato, siempre intentando situar el problema en su contexto global, siempre intentando ser conscientes del todo (bigger picture).

Y qué decir del título del primer apartado: El Gato Se Comió El Código Fuente 🙂 Parece la excusa de un niño de primaria cuando le piden los deberes en clase.

Un programador pragmático se equivoca, como todos los programadores, pero reconoce sus errores sin excusas. No tiene miedo ni vergüenza de admitir los errores o el desconocimiento. Las cosas siempre terminan, en algún momento, por ir mal. Las entregas se retrasan, aparecen problemas técnicos inesperados, … y en ese momento, aparece la grandeza del programador pragmático que de una manera honesta y directa, reconoce su parte de culpa.

Tip 3: Ofrece Soluciones, No Des Excusas Baratas (Provide Options, Don’t Make Lame Excuses)

Y antes de dar excusas, mírate a un espejo, y date a ti mismo las mismas excusas ¿tienen algún sentido? ¿te sirven de algo? ¿van a arreglar o mejorar algo? Pues entonces ahórratelas, y busca soluciones. Quizás el uso de prototipos, la refactorización, una mayor cobertura de pruebas, etc .. habrían evitado el problema.

Ventanas Rotas

El segundo apartado, Entropía del Software, relata una de las historias más conocidas de este libro. La entropía se relaciona con el orden dentro del caos, y más directamente, se define como la cantidad de desorden de un sistema. Esto siempre me recuerda a mi escritorio físico (no virtual), cuando vivía con mis padres. Mi madre decía que mi escritorio era un caos, pero yo sabia donde estaba todo. Si extrapolamos mi escritorio al software, hemos de tener nuestro código ordenado, saber donde está todo, y evitar que nuestro software se pudra. Para evitar que nuestro código huela mal y se deteriore poco a poco, requiere de un cuidado continuo para evitar la tendencia al desorden.

Tip 4: No Vivas Con Ventanas Rotas (Don’t Live with Broken Windows)

Mediante esta moraleja, los autores comparan una aplicación con un edificio, en tanto que cuando un edificio, estando deshabitado pero manteniendo una apariencia visual agradable, se mantiene en buen estado. En cuanto se rompe una ventana, y aparecen pintadas, en poco tiempo, todo el edificio se deteriora, se rompen todas las ventanas, y pasa de estar deshabitado a abandonado.

¿Qué tenemos que hacer nosotros como programadores pragmáticos? Cuando se rompe una ventana (una funcionalidad) de nuestra aplicación, tenemos que arreglarla. Seguro que alguna vez has visto algún bug en la aplicación que estás desarrollando, pero por no tocar, o no perder el tiempo, o porque no lo has provocado tú, no te has parado a arreglarlo. Mal. Muy mal. No hay nada peor que mirar hacia el otro lado. Ese no es el camino.

Puedes pensar que ya vendrá alguien y lo arreglará, pero si todos pensamos así, el fallo estará ahí siempre. ¿Y qué decir de una aplicación que constantemente falla? No apetece nada ponerse a arreglarla, más cuando todo el código es un caos, no hay dos lineas iguales, diferente nomenclatura, sin convenciones de código. Para evitar una aplicación con todas la ventanas rotas, hay que mantenerlas limpias desde el principio. Lo que no se ensucia, no hace falta limpiarlo. Dicho de otro, quien no mancha, no tiene que limpiar. ¿Está claro? Pues entonces desde un principio, vamos a ser limpios y cuidadosos con nuestro código. Sin chapuzas ni trozos de código para salir al paso. Siempre con la mejor solución. Al menos, la mejor solución que nosotros conocemos.

El tercer apartado, Sopa de Piedras y Sapos Hervidos, comienza con un cuento muy bonito sobre unos soldados hambrientos que llegan a un poblado donde los aldeanos también pasan hambre y son reacios a abrirles la puerta para darles de comer, pero los soldados son muy listos, y se aprovechan de la curiosidad de los aldeanos para obtener a partir de una sopa de piedras un poco de su preciado alimento. A partir de lo que aporta cada aldeano, consiguen crear una sopa “rica, rica”. Moraleja: la unión hace la fuerza. Es más, estos aldeanos no sabían que si unían sus recursos a los de sus vecinos, iban a mejorar, tanto ellos mismos como personas cómo sus recursos (el producto final).

Tip 5: Sé El Catalizador del Cambio (Be a Catalyst for Change)

Nosotros como pragmáticos que somos, tenemos que ver la necesidad de dar ese empujón a nuestros compañeros para mejorar. ¿Cuantas veces te has dicho “que mal se hacen las cosas en esta empresa”, y no has hecho nada para arreglarlo? Pues si has sido capaz de darte cuenta que había algo mal, también serás capaz de encontrar la solución. Y una vez tengas la solución, difúndela, propágala dentro de la empresa, haz participe a todos los que te rodean, para que la solución se haga realidad.

La segunda mitad de la moraleja se centra en como los soldados engañan a los aldeanos. El truco de las piedras hace que los aldeanos se centren en lo que están haciendo los soldados, y no en lo que éstos quieres conseguir.

Tip 6: Recuerda el Todo (Remeber the Big Picture)

Si solo nos fijamos en lo que hacemos ahora, en nuestra pequeña parcela, el todo, la aplicación entera, va a ir creciendo y deteriorándose poco a poco, normalmente en los puntos de unión de nuestras parcelas con las de nuestros vecinos más cercanos.

Recuerda el Todo

Mediante la historia del sapo hervido se transmite la idea de que cuando los cambios llegan poco a poco, nadie se da cuenta, y al final, un gran cúmulo de pequeños fallos hace un gran fallo irreversible. No seas sapo, y ten un ojo siempre en lo que sucede a tu alrededor.

El cuarto apartado, Software Suficientemente Bueno, comienza con la utopía de los chips. Ojala al desarrollar software pudiésemos saber de antemano los errores que tiene una aplicación. Como no somos capaces, lo único que podemos hacer es un software lo suficientemente bueno, desde el punto de vista del cliente, algo que resuelva los requisitos y que sea mantenible. Por esto, cuando se definen los requisitos de un proyecto, además de los requisitos funcionales, se debe definir la calidad y el alcance del proyecto.

Tip 7: Haz de la Calidad un Requisito (Make Quality a Requirements Issue)

Y este no es un tip, pero qué gran frase: “Un buen software hoy es mejor que un software perfecto mañana”. La temprana retroalimentación del software mejora nuestra aplicación, y por esto, es mejor que vayamos haciendo entregas desde el principio, entregas evolutivas que van a implementar de forma creciente los requisitos del proyecto, y permitirá pulir los requisitos ya implementados.

Continuando con lo de suficientemente bueno, no hay que quedarse corto, ni pasarse de largo. Ni mucho ni poco. El software es suficientemente bueno cuando no tenemos que hacer nada más y no nos falta nada por hacer. Hay que saber cuando parar, porque la sobreingeniería cuesta, recursos temporales y económicos.

En estos tiempos de crisis, quiero resaltar la entradilla del quinto apartado, Tu Portafolio de Conocimiento, la frase de Benjamin Franklin, que dice así: “Una inversión en conocimiento siempre devenga los mejores intereses”. Aquello que nos define como profesionales es nuestro conocimiento y nuestra experiencia.

El problema con el conocimiento, aparte de lo que cuesta adquirirlo, es que caduca. Las tecnologías avanzan a ritmos vertiginosos. No paran de aparecer nuevos lenguajes, nuevas librerías, APIs, sistemas de comunicación, etc… Tenemos que adquirir conocimiento y renovar el que tenemos de una forma constante.

Tip 8: Invierte Regularmente en tu Portafolio de Conocimiento (Invest Regularly in Your Knowledge Portfolio)

Para invertir en nuestro portafolio (símil financiero) de conocimiento, debemos invertir regularmente (coger un hábito de estudio, lectura), diversificar (cuantas más cosas diferentes sepamos, más valiosos somos), gestionar los riesgos (si solo centramos nuestro conocimiento en una sola tecnología, si ésta se va a pique, nosotros seguiremos su camino), comprar barato y vender caro (aprender tecnologías emergentes puede darnos gran ventaja competitiva) y revisar y hacer balance (mirar la vista atrás, revisar lo que sabemos , preguntarnos si deberíamos reciclarnos, …).

Comprar barato y vender caro. ¿Qué crees que deberías aprender ahora para poder ser más competitivo en el mercado, es decir, optar a un puesto de trabajo bien remunerado? ¿JavaEE? ¿Algún lenguaje de scripting (Ruby/Groovy) con su framework web (Rails/Grails)? ¿Quizás .Net?

Lo que está claro, es que no tenemos que parar de aprender, de reciclarnos. Una vez nos veamos cómodos en un campo, saltar. Otra tecnología, otro lenguaje, …

Y que hay de las oportunidades de aprender. El libro comenta el reto que supone cuando alguien recurre a ti, porque se supone que eres experto (o tienes un nivel aceptable) sobre alguna tecnología, y te hace una pregunta que nos sabes responder. Acaba de lanzarte un reto que no debes rechazar. Busca la respuesta, apoyate en tu guru personal (ese compañero de trabajo, algún ex-compañero de otra empresa, amigo de estudios, etc..), busca en la biblioteca, Internet, haz lo que sea, pero encuentra la respuesta. Así conseguimos que nuestro portafolio crezca.

Y luego están los foros, los RSS, los libros tecnológicos, y si nos parece poco, hay multitud de sitios que nos plantean artículos de los que podemos aprender. ¿ Y cuando leerlos ? Hay quien prefiere irse de la oficina 30 minutos más tarde para dedicarse a leer, o bien después de comer. Hay quien prefiere escribir en papel, y aprovecha los viajes en autobús, metro, las visitas al dentista/médico de cabecera, etc… Lo que esta claro es que tienes que buscarte tus huecos para leer.

Vale, ya tenemos tiempo para leer, y estoy leyendo. Pero ¿vale la pena lo que estoy leyendo? La información de la que dispongo, ¿es objetiva? Hay que tener mucho cuidado con el marketing. Que un libro aparezca en Internet no significa que sea bueno, del mismo modo, que si un articulo dice que el mejor producto es X, posiblemente sea porque el artículo lo ha escrito el creador de X.

Tip 9: Analiza Críticamente Lo Que Lees y Escuchas (Critically Analyze What You Read and Hear)

Conforme uno adquiere más conocimiento, tenemos mayor capacidad de análisis, y sabremos si lo que leemos y escuchamos es verdad o una verdad a medias. Además, el hecho de dudar de lo que estamos leyendo, buscarle las tres patas al gato, esa pregunta “puñetera” que nadie se atreve a hacer pero a ti se te ocurre, … todo esto mejora la calidad de nuestro conocimiento.

Comunicate

El sexto y último apartado, Comunícate, se plantea la idea de que como todo el idea nos estamos comunicando, via email, foros, documentos, código fuente, etc… hemos de hacerlo bien. Para ello tenemos que saber que es lo que queremos decir (¿porque no hacerse un guion de lo que vamos a decir?), conocer a nuestra audiencia (no seamos demasiado técnicos cuando no debemos serlo, ni viceversa), elegir el momento (seguro que cuando erais pequeño no le pediais dinero a vuestro padre cuando estaba cansado o con hambre, ¿verdad?), elegir un estilo (a veces hay que enrollarse, otras veces, cuando más escueto es uno, mejor), darle una buena apariencia (una buena comida mal presentada no es una buena comida, y que hay de esas delicatessen tan bonitas que luego no saben a nada, …. cuidado con la ortografia), involucra a la audiencia (mediante borradores), escucha (escucha para ser escuchado, pide consejos, pregunta por la opinión sobre lo que has comunicado), contesta (si no contestamos a los que nos preguntan/piden, luego nosotros seremos los ignorados). Y de cosecha propia, hay que predicar con el ejemplo, nada de “a Dios rogando, y con el mazo dando”.

Tip 10: Es Tan importante Lo Que Dices Como La Manera En Que Lo Dices (It’s Both What You Say and The Way You Say It)

Cuanto mejor nos comuniquemos, más influyentes seremos.

Conforme voy releyendo cada apartado, aparte de la idea que los autores quieren transmitir, observo que hay múltiples consejos que quedan en el camino, pero son tan importantes como los aquí resaltados. Si te has leído el capítulo, y luego todo este rollo, vuelve a leerte el capítulo a ver si consigues obtener nuevas conclusiones. Cuéntanoslas. Comunícate 🙂

Bueno, espero que os haya gustado … para aquellos que no os habeis leido el capítulo, a ver si así os pica la curiosidad. El segundo capítulo es un poco más extenso, asi que volveré despues de las navidades. Feliz 2009 🙂

Anímate a Leer

Hace ya algún tiempo que me rondaba por la cabeza la idea de promover o unirme a algún club de lectura. Sí, de lectura, pero tecnológica 🙂

Personalmente, la lectura es uno de mis hobbies, y concretamente suelo leerme unos 3 o 4 libros técnicos al año. Así que al grano, voy a animaros a que nos leamos (yo releer) el pedazo de libro que es “The Pragmatic Programmer” (en inglés, of course). Es un libro que si rebuscáis por Google veréis que gusta mucho. En poco más de 300 páginas te aconseja y guía en como convertirte en un mejor programador.

Portada de Pragmatic Programmer

Este libro se escribió en el año 1999, me lo leí en el 2004 y luego me lo compré al año siguiente. Sí, me lo leí de la biblioteca de la universidad. Acabo de ver que hay tres copias disponibles. Si os lo queréis comprar, ronda los 40€ … también hay otros medios de conseguirlo que yo no os voy a decir cómo, pero que seguro que ya sabéis 😉

Pero ¿Qué es un programador pragmático? Es aquel que es efectivo y productivo, y según los autores:

  • se adapta rápidamente a los cambios, nuevas tecnologías, herramientas
  • es curioso, se pregunta el porqué y cómo funcionan las cosas
  • tiene pensamientos críticos, y duda de las justificaciones del tipo porque sí, o porque siempre se ha hecho así.
  • es realista, comprende la naturaleza y dificultad de los problemas
  • es aprendiz de todo, manitas en múltiples tecnologías y entornos

A lo largo de libro se enumeran 70 consejos repartidos en 8 capítulos. He pensado que para llevar un buen ritmo, sin saturar pero sin aburrir, escribiré una entrada comentando un capítulo más o menos cada tres semanas. Así pues, dentro de tres semanas, comentaremos el capítulo 1 “A Pragmatic Philosophy“.

En el prefacio de libro te motiva a leerte el libro y ya plantea los dos primeros consejos (no soy traductor profesional, así que puede que no encuentre la mejor traducción posible):

Tip 1: Preocúpate por lo que haces (Care About Your Craft)

Cuando estés programando, tu principal objetivo debe ser hacer las cosas bien.

Tip 2: Piensa ! Piensa en lo que estas haciendo (Think! About Your Work)

Si tus cinco sentidos no están en lo que tienes que estar, mejor no deberías estar programando. No tenemos que hacer las cosas con el piloto automático, hay que pensar. Piensa!

Estos dos tips/consejos van a provocar que empleemos más tiempo en realizar nuestras tareas, pero el resultado va a ser más satisfactorio para nosotros, para el código y para nuestros jefes.

Aquí podéis leer el listado completo de todos los consejos que ofrece el libro y que iré comentando en posteriores entregas: http://www.codinghorror.com/blog/files/Pragmatic Quick Reference.htm.

Bueno, de momento, hasta aquí la presentación del libro. Espero que os pique el gusanillo y os animéis a leer el libro. ¿Os parece acertada la elección del libro? ¿Ya os lo habéis leído? ¿Os gustaría que tras este planteemos la lectura de algún otro libro?

Ánimo, y a leer.

Java SE u10, EJB 3.1 y resultados de Sun

Java SE 6 Update 10

Esta semana se ha hecho pública la esperada actualización 10 de Java SE 6. Entre las mejoras de la nueva versión se encuentra una nueva implementación del Java Plug-In en la que los applets corren como procesos independientes del navegador.  Esto servirá para mejorar la robustez de las aplicaciones RIA JavaFX y hacer verdaderas filigranas desde los navegadores.

En el aspecto gráfico, se introduce un elegante look-and-feel (nimbus) que complementa el existente metal. Es un diseño moderno, con tonos grises y azulados, reflejos suaves y ligeros efectos de profundidad. Todo está vectorizado, basándose en Java 2D, por lo que ocupa poco espacio y es compatible con distintas resoluciones de pantalla .

Se ha mejorado también la eficiencia y se ha disminuido notablemente el tamaño de la distribución, al incluir sólo el llamado Java Kernel, que contiene las clases más usadas de la plataforma.

La actualización está disponible para Linux, Solaris y Windows. Los usuarios de Mac tendremos que esperar bastante, al ser Apple (y no Sun) la encargada de portar el desarrollo. O quizás lo tendremos antes via otros ports, como FreeBSD Java Project, o OpenJDK.

Introducing Java SE 6 update 10 (Artículo de Sun Developer Network)
Special Event: Java SE 6u10 Release (Entrada en el blog The Planetarium)
JavaOne ’08: Sun brings back Java applets (Vídeo)

EJB 3.1 Public Draft

Ya está disponible el borrador público de la nueva versión de EJB. El líder del grupo de especificación, Ken Saks, destaca en una entrada de su blog las siguientes características:

  • Portabilidad en los nombres JNDI globales
  • Invocaciones asíncronas de los beans de sesión
  • Beans de sesión Singleton
  • Mejoras en los Timer
  • Despliegue de componentes EJB en un .war sin un ejb-jar
  • EJB “Lite” una versión ligera de la API EJB
  • EJB Embebido: un API para la ejecución de componentes EJB en Java SE

La especificación 3.1 se incorporará en la nueva versión de Java EE (Java EE 6) que se lanzará seguramente en la JavaOne 2009.

Malas noticias para Sun

Termino con una noticia económica sobre Sun. Han publicado resultados prelimares que anuncian pérdidas en este último cuatrimestre. Han ingresado unos 3.000 millones de dólares, bajando de los 3.200 millones del primer cuatrimestre. Malos tiempos para los servidores Sun. Esperemos que no el tema no le afecte a la plataforma Java.

Sun Microsystems anuncia pérdidas (siliconnews.es)

Por cierto…

¡Felicidades Netbeans! Cumple 10 años.