James Ward sobre Java

James Ward, de Salesforce, escribió el pasado mes de diciembre una  nota sobre Java (y alrededores). Una excelente lectura sobre java para aplicaciones web, y seguramente adaptable a otros escenarios. En realidad, se trata de una recomendación basada en experiencia acerca de la adopción de métodos ágiles y el recurso a herramientas de automatización y sistematización del proceso de contrucción (e implementación) de aplicaciones. No quiero repetirlo, pero sí recomendarlo. En todo caso, quisiera citar su reflexión sobre el mantenimiento de releases "monolíticos" (trabajar para entregas en series de tiempo y desarrollo prolongadas):

Monolithic Releases Suck

Unless you work for NASA there is no reason to have release cycles longer than two weeks. It is likely that the reason you have such long release cycles is because a manager somewhere is trying to reduce risk. That manager probably used to do waterfall and then switched to Agile but never changed the actually delivery model to one that is also more Agile. So you have your short sprints but the code doesn’t reach production for months because it would be too risky to release more often. The truth is that Continuous Delivery (CD) actually lowers the cumulative risk of releases. No matter how often you release, things will sometimes break. But with small and more frequent releases fixing that breakage is much easier. When a monolithic release goes south, there goes your weekend, week, or sometimes month. Besides… Releasing feels good. Why not do it all the time?
Moving to Continuous Delivery has a lot of parts and can take years to fully embrace (unless like all startups today, you started with CD). Here are some of the most crucial elements to CD that you can implement one-at-a-time:

• Friction-less App Provisioning & Deployment: Every developer should be able to instantly provision & deploy a new app.
• Microservices: Logically group services/apps into independent deployables. This makes it easy for teams to move forward at their own pace.
• Rollbacks: Make rolling back to a previous version of the app as simple as flipping a switch. There is an obvious deployment side to this but there is also some policy that usually needs to go into place around schema changes.
• Decoupled Schema & Code Changes: When schema changes and code changes depend on each other rollbacks are really hard. Decoupling the two isolates risk and makes it possible to go back to a previous version of an app without having to also figure out what schema changes need to be made at the same time.
• Immutable Deployments: Knowing the correlation between what is deployed and an exact point-in-time in your SCM is essential to troubleshooting problems. If you ssh into a server and change something on a deployed system you significantly reduce your ability to reproduce and understand the problem.
• Zero Intervention Deployments: The environment you are deploying to should own the app’s config. If you have to edit files or perform other manual steps post-deployment then your process is brittle. Deployment should be no more than copying a tested artifact to a server and starting it’s process.
• Automate Deployment: Provisioning virtual servers, adding & removing servers behind load balancers, auto-starting server processes, and restarting dead processes should be automated.
• Disposable Servers: Don’t let the Chaos Monkey cause chaos. Servers die. Prepare for it by having a stateless architecture and ephemeral disks. Put persistent state in external, persistent data stores.
• Central Logging Service: Don’t use the local disk for logs because it prevents disposability and makes it really hard to search across multiple servers.
• Monitor & Notify: Setup automated health checks, performance monitoring, and log monitoring. Know before your users when something goes wrong.

There are a ton of details to these that I won’t go into here. If you’d like to see me expand on any of these in a future blog, let me know in the comments.

Un punto importante, pero recordado sólo con el propósito de que lea completa la reflexión de James Ward, que lo merece.

Lenguajes de programación y rankings

Reviendo dos rankings de lenguajes de programación: Tiobe y The Transparent Language Popularity Index, éste último, en Source Forge (apuntado por Jean Bezivin). Coincidencias básicas entre ambos para los primeros puestos: con leves diferencias, Java, C, C++, PHP, C#. En ambos rankings, no se habla de número de aplicaciones, líneas de código, ponderación de la importancia de las aplicaciones involucradas. Fundamentalemnte, lo que establece su importancia es la popularidad del lenguaje. La fórmula de Tiobe lo explica:

The ratings are calculated by counting hits of the most popular search engines. The search query that is used is

+" programming"

This search query is executed for the top 6 websites of Alexa that meet the following conditions:

• The entry page of the site contains a search facility
• The result of querying the site contains an indication of the number of page hits

Based on these criteria currently Google (32%), YouTube (10%), Yahoo! (3%), Bing (3%), Wikipedia (16%), Blogger (32%) and Baidu (3%) are used as search engines. The number of hits determine the ratings of a language. The counted hits are normalized for each search engine for the first 50 languages. In other words, the first 50 languages together have a score of 100%. Let's define "hits50(SE)" as the sum of the number of hits for the first 50 languages for search engine SE and "hits(PL,SE)" as the number of hits for programming language PL for search engine SE. Possible false positives for a query are already filtered out in the definition of "hits(PL,SE)". This is done by using a manually determined confidence factor per query. A query such as "Basic programming" also returns pages that contain "Improve your basic programming skills in Java". The first 100 pages per search engine are checked for possible false positives and this is used to define the confidence factor. If this factor is 90%, then only 90% of the hits are used for "hits(PL,SE)". An overview of the confidence factor can be found in the groupings table below.
The ratings are calculated with the following formula:

((hits(PL,SE1)/hits50(SE1) + ... + hits(PL,SEn)/hits50(SEn))/n

where n is the number of search engines used.

¿Son importantes estos índices? La popularidad implica que han ocupado la atención pública, que fue analizado para su adopción, que distintas comunidades recurrieron a consultas para resolver problemas o educarse, en fin, que estuvieron en el foco de la atención de la comunidad de la industria. Pero no habla en todo caso de los consolidados, aquellos que se usan sin ruido, y que pueden ser usados también en abundancia, como sin duda sucede con COBOL, RPG y otros.
En el último tiempo, suele hablarse de Java como un lenguaje "corporativo", igualándolo a "legacy". Su continuidad en la primera línea en todo caso muestra que su interés no se ha amortiguado.

Extendiendo java...

Artículo leído hace algunos días. Me llamó la atención por su autor, Jack Herrington, que hace unos pocos años creara Code Generation Network, inicialmente asociada a su literatura sobre generación de código. Luego de algún tiempo, Jack se retiró de la conducción del sitio, tomado y reformado por Mark Dalgarno.
Jack explica el uso de lenguajes encajados (embedded languages) en java, como una manera de extender el alcance de aplicaciones agregando o integrando funcionalidad no disponible o no incluíble fácilmente bajo java. Lo he agendado, y en algún momento lo trataré de poner en marcha. La posibilidad de hacer flexible una aplicación al modo en que las macros de Office lo hacen, es algo necesario: forma parte de las características esperadas hoy, de tal forma que la extensibilidad sea posible en tiempo de ejecución. El único punto que me sorprende es que esta capacidad sea encarada desde el punto de vista de java, y no desde un nivel superior. Fundamentalmente, considerando que Jack ha sido abogado de la generación de código. Creo que es perfectamente posible extender sus ejemplos encajándolos en un patrón, al modo en que ActiveX y Java Beans se incluyen hoy en Plex. Tarea para mi (imposible de cumplir) lista.