Java legacy, II

A propósito de las afirmaciones sobre la declinación de Java, mayores hacia inicios de año que ahora, Martijn Verburg, en su revista de Java para 2012, se refiere al tema y lo refuta claramente:

The community continues to thrive despite many main stream tech media reports of ‘developers leaving the Java platform’ or ‘Java is dead’. There are more Java User Groups (JUGs) than ever before, consisting of ~400,000 developers world wide.
Notably, one of them, the London Java Community won several awards including the Duke’s Choice award and JCP Member of the Year (along with SouJava – the major Brazilian JUG).
The conference circuit is bursting at the seams with large, sold out in advance, world-class Java conferences such as JFokus, Devoxx and of course JavaOne. In addition to this the host of regional conferences that often pack in an audience of over 1000 people all continued to do well.
Oracle’s Java Magazine was launched and has grown to over 100,000 subscribers. Stalwarts like JaxEnter, Coderanch and the Javaposse continue to grow in audience sizes.

OpenJDK

Further OpenJDK reforms happened over 2012 and a new scorecard is now in place for the wider community to give feedback on governance, openness and transparency.
2012 also saw a record number of individuals and organisations joining OpenJDK. In particular, the port to the ARM processor and support for running Java on graphic cards (Project Sumatra) were highlights this year.

Java Community Process (JCP)

The Java Community Process (JCP), Java’s standards body also continued its revival with record numbers of new sign-ups and a hotly contested election. As well as dealing with the important business of trademarks, IP and licensing for Java, a re-focus on the technical aspects for Java Specification Requests (JSRs) occurred. In particular the new Adopt a JSR programme is being strongly supported by the JCP.

Java and the JVM

The JVM continues to improve rapidly through OpenJDK – the number of Java Enhancement Proposals (JEPs) going into Java 8 is enormous. Jigsaw dropping out was a disappointing but given the lack of broader vendor support and the vast amount of technical work required, it was the correct decision.

JEE / Spring

JEE7 is moving along nicely (and will be out soon), bringing Java developers a standard way to deal with the modern web (JSON, Web Sockets, etc). Of course many developers are already using the SpringSource suite of APIs but it’s good to see advancement in the underlying specs.

Rapid Web Development

Java/JVM based rapid web development frameworks are finally gaining the recognition they deserve. Frameworks like JBoss’s SEAM, Spring Roo, Grails, Play etc all give Java developers parity with the Rails and Django crowd.

Mechanical Sympathy

A major focus of 2012 was on Mechanical Sympathy (as coined by Martin Thompson in his blog). The tide has turned, and we now have to contend with having multi-core machines and virtualised O/S’s. Java developers have had to start thinking about how Java and the JVM interacts with the underlying platform and hardware.
Performance companies like jClarity are building tooling to help developers understand this complex space, but it certainly doesn’t hurt to get those hardware manuals off the shelf again!

Y cuando Martijn se refiere a las perspectivas de 2013, la expectativa persiste, con Java 8 en deliberación. Pero mejor vea el artículo, o siga Java Code Geeks. Al menos en mi caso, encuentro usualmente excelente material práctico con ellos.

¿Java Legacy?

Esta es una noticia "vieja": InfoQ comenta la migración de Twitter de Ruby a Java a propósito de la exitosa travesía de Twitter durante las elecciones estadounidenses. Twitter resistió 327.452 tweets por minuto, hasta 15.107 tweets por segundo en algunos momentos, sin caídas de proceso ni congestionamientos. InfoQ atribuye (en parte) esta mejora a la migración desde Ruby hacia java:

[ dice Mazen Rawashdeh, VP de Infrastructure Operations Engineering en Twitter]Part of the reason Twitter was able to sustain this level of traffic was down to a set of changes the company has been making to their infrastructure, including, as InfoQ previously reported, a gradual shift away from Ruby to a set of services written in a mixture of Java and Scala and running on the JVM.

InfoQ historia este proceso gradual de migración:

Twitter was at one time thought to be the largest Ruby on Rails shop in the world, and has made a substantial investment in its Ruby stack, going as far as developing its own generational garbage collector for Ruby called Kiji, which, unlike the standard Ruby collector, divides objects into generations and, on most cycles, will place only the objects of a subset of generations into the initial white (condemned) set.
In 2010, however the firm announced that it was shifting some of its development focus. For the front-end the firm followed the HTML5 trend of shifting rendering code into browser-based JavaScript, and, in so doing, it ceased to gain much benefit from Rails' templating model for building web pages. Then, citing both performance and code-encapsulation as drivers, the engineering team re-wrote both its back-end message queue and tweet storage engine in Scala.

 Respecto a los clientes móviles, Rawashdeh dice: As part of our ongoing migration away from Ruby we've reconfigured the service so traffic from our mobile clients hits the Java Virtual Machine (JVM) stack, avoiding the Ruby stack altogether.

Respecto a su motor de búsqueda, también el cambio se inclinó por java: in 2011 the engineering team announced that they had replaced the Ruby on Rails front-end for search with a Java server they called Blender. This resulted in a 3x drop in search latencies.

En años anteriores se comenzó a hablar de Java como un lenguaje legacy, y de su toma por parte de Oracle, como su sentencia de muerte. Sin embargo, ha corrido agua, y la muerte no se produce: Java 7 en marcha, y preparativos para Java 8. En mi experiencia personal, con un uso más extenso de Java, observo estabilidad, confiabilidad, y buena performace. Cada vez que he tenido problemas con la JVM se ha debido a fallos en la preparación de funciones, y he podido contar con buena ayuda de la  consola de java en primer lugar, y de la documentación y la buena capacidad de manejo de errores. Tanto como soporte servidor, como en funciones cliente, la respuesta ha sido normal. Como máquina servidora para aplicaciones web basados en HTML + Javascript, su servicio es transparente y robusto. Y esto, sin contar con su ubicuidad: en cierto modo, "multiplataforma" en mi caso implica Java. En fin, mi experiencia es coincidente con esto dicho en InfoQ.

La ética en la profesión informática

Nuevamente, Javier Garzás se ocupa de la informática en España desde el punto de vista de ésta como profesión. Aunque esta vez, el punto discutido trasciende el perfil de TI en España: es sin duda válido para cualquier medio. Javier propone un "juramento de no compromiso" con una práctica de desarrollo de software determinada, de tal forma que un profesional no adhiera a ultranza con una idea, particularmente en un universo en el que el cambio y la renovación conceptual es frecuente. Dice Javier:

Estoy cansado de la gente que es de una escuela de pensamiento y que rechaza las ideas de otra escuela de pensamiento. Tengo hambre de gente que no le importe de donde vienen las ideas, que les importe sólo lo que significan y lo que producen. Así que se me ocurrió esto del “juramento de no lealtad”.
Esto significa el fin de afirmaciones como “eso no está bien – no es ágil / orientado a objetos / puro / etc.”, en vez de discutir sobre si la idea (ágil o tradicional o impura o lo que sea) funciona bien en las condiciones del momento.
Los anteriores párrafos no son míos, aunque coincido tanto con ellos que es como si los hubiese escrito.
El anterior texto es el “juramento de no lealtad” escrito por Alistair Cockburn hace ya unos años y firmado por muchos profesionales que coinciden con él en rechazar esa mala práctica, tan común en nuestra profesión: casarse hasta el extremismo con una única manera de ver cómo gestionar y desarrollar software, hasta el punto de rechazar cualquier idea alternativa.
Así que si piensas igual, si se te ha pasado por la cabeza más de una vez que hacer y gestionar bien el software no pasa por casarse con una práctica de desarrollo, que una metodología no es ni un equipo de futbol, ni un partido político, ni una religión… que sepas que no estás sólo.

Confieso que, desde el punto de vista de adhesión a ideas, puedo incluírme en el bando de los "comprometidos", porque tengo algunos prejuicios, o quizá prevenciones, respecto a algunas prácticas y también a algunos "marcos de trabajo". Creo tener fundamento para ello, pero soy conciente de que corro este riesgo. Sin embargo, podríamos decir que hasta aquí estamos en un umbral de "autenticidad", es decir, cuando algo se hace por convencimiento, aunque pueda cometer errores gruesos por omisión o confrontación de otras soluciones posibles.
Pero existe algo más, que este juramento alcanza: cuando un argumento es defendido de mala fe. La informática es una profesión, que procura ingresos a partir de un servicio, especialmente para la inmensa mayoría de los profesionales que no son miembros de un grupo académico, o de una organización sin fines de lucro. Quisiera saber cuántos profesionales responsables o gerenciadores de alguna una gran empresa de informática, consultora, o asesora, no tienen sobre su conciencia el haber ocultado un fallo por omisión, una característica problemática en un producto en oferta, una obsolescencia frente a la competencia. Y eso dejando a un lado otras prácticas que caen en el delito, quizá más propias y abundantes en el "tercer mundo informático".
Quisiera ver un colegio profesional capaz de montar un tribunal de ética que condenara prácticas agresivas en la obtención de contratos, o que demandara promesas contractuales incumplidas. El día que así sucediera, les daré mayor valor. En tanto, veo pocas posibilidades de implantar el juramento de no-compromiso en nuestra profesión, y con ello, poco alcance de la credibilidad de un colegio.

Mejoras en el proceso de desarrollo de Plex

De interés para usuarios de Plex/2E: Acabo de recibir el boletín de noticias de CA, CA Tech Insider - CA Application Development, que trae una noticia que probablemente sea de importancia para muchos clientes, particularmente aquellos que puedan dedicar un pequeño equipo a laboratorio: CA aplicará Scrum al desarrollo de 2E y Plex, comenzando ya con 2E. Desarrollarán pre-releases mensuales con participación de clientes y retroalimentación de resultados: To boost ongoing collaboration with customers, the CA 2E 8.6 release used the Agile Scrum methodology. This approach provided monthly pre-release feature reviews with select customers. These reviews allowed customers to provide substantive feature feedback during the development cycle which allowed us to incorporate changes and provide customers with the features they wanted and needed. In 2013, we will continue to use the Agile Scrum methodology for CA 2E and will begin using Agile Scrum for CA Plex. 
Mejor solución que el sistema actual, basado en la participación en los programas beta, más espaciados, que agrupan la recolección de solicitudes de mejora en puntos anuales o bianuales, con participación en alrededor de un trimestre. Este estilo se puede sumar a la mejora que implica el proceso de Ideas, en marcha desde hace algún tiempo, por el que se pueden postular y explicar las mejoras y direcciones de desarrollo de importancia en el parecer de los usuarios y clientes, con un sistema de apoyo que ayuda a destacar su prioridad para la comunidad de usuarios. Este sistema se usó en la preparación del próximo beta, todavía organizado al estilo anterior.

Silverlight: Crónica de una muerte anunciada

Tim Anderson,  (¿ex?) entusiasta de Silverlight, informa que el sitio oficial del producto (Silverlight.net), ha desaparecido, y que ahora redirecciona a MSDN. La degradación (en términos militares) del producto queda evidente en que, si a grandes rasgos los contenidos principales fueron migrados, muchos contenidos dependientes y relacionados ahora conducen a enlaces perdidos ("shattered into a million broken urls"). Tim piensa en términos condicionales acerca de lo que Silverlight hubiera podido ser pero no fue. Algunos lectores apuntan otros casos de discontinuidad. Una vez más, para mí esta declinación planificada (¿obsolescencia programada?) refuerza la idea de que el software debe construírse a salvo de los proveedores de productos o plataformas, a nivel de modelo, de tal forma que sea capaz de sobreponerse a las conveniencias ajenas. Dejemos hablar a Tim:

There has been some Twitter chatter about the closure of silverlight.net, Microsoft’s official site for its lightweight .NET client platform. multimedia player and browser plug-in.
I am not sure when it happened, but it is true. Silverlight.net now redirects to a page on MSDN. Some but not all of the content has been migrated to MSDN, but Microsoft has not bothered to redirect the URLs, so most of the links out there to resources and discussions on Silverlight will dump you to the aforementioned generic page.
One of the things this demonstrates is how short-sighted it is to create these mini-sites with their own top-level domain. It illustrates how fractured Microsoft is, with individual teams doing their own thing regardless. Microsoft has dozens of these sites, such as windowsazure.com, windowsphone.com, asp.net, and so on; there is little consistency of style, and when someone decides to fold one of these back to the main site, all the links die.
What about Silverlight though? It was always going to be a struggle against Flash, but Silverlight was a great technical achievement and I see it as client-side .NET done right, lightweight, secure, and powerful. It is easy to find flaws. Microsoft should have retained the cross-platform vision it started with; it should have worked wholeheartedly with the Mono team for Linux-based platforms; it should have retained parity between Windows and Mac; it should never have compromised Silverlight with the COM support that arrived in Silverlight 4.
The reasons for the absence of Silverlight in the Windows Runtime on Windows 8, and in both Metro and desktop environments in Windows RT, are likely political. The ability to run Silverlight apps on Surface RT would enhance the platform, and if COM support were removed, without compromising security.
XAML and .NET in the Windows Runtime is akin to Silverlight, but with enough differences to make porting difficult. There is an argument that supporting Silverlight there would confuse matters, though since Silverlight is still the development platform for Windows Phone 8 it is already confusing. Silverlight is a mature platform and if Microsoft had supported it in the Windows Runtime, we would have had a better set of apps at launch as well as more developer engagement.
I posted that Microsoft’s Silverlight dream is over in October 2010, during Microsoft’s final Professional Developers Conference, which is when the end of Silverlight became obvious. It lives on in Windows Phone, but I would guess that Windows Phone 8.5 or 9.0 will deprecate Silverlight in favour of the Windows Runtime. A shame, though of course it will be supported on the x86 Windows desktop and in x86 Internet Explorer for years to come.