Según una nota de prensa del pasado 17 de marzo, Eclipse ha anunciado que construirá un nuevo super runtime alrededor de Equinox combinando sus subproyectos Eclipse Communication Framework , EclipseLink , Rich Ajax Platform , Riena , y Swordfish

El propósito de este proyecto es crear un modelo común de desarrollo multiplataforma en cliente y servidor mediante un concepto que en Eclipse denominan Component Oriented Development and Assembly (CODA).

Equinox es el núcleo de Eclipse Framework, se trata de una implementación de OSGi R4 un sistema que define la arquitectura para desarrollar y desplegar aplicaciones modulares. Hay un par de demos sobre el funcionamiento de OSGi en el portal de Equinox Equinox también es la implementación de referencia de JSR 291 y en gran medida un producto substitutivo del JSR 277 liderado por Sun.

Una de las fortalezas de Equinox es que hoy por hoy es la implementación de referencia de OSGi. Si se visita la web OSGi.org y se solicita una implementación de referencia lo que se obtiene es un enlace a Equinox. Existen también Knopplerfish y Apache Felix aunque, a día de hoy, Felix no pasa todavía los test de conformidad con la release 4 de OSGi.

Según la nota de prensa de Eclipse, ya son más de 20 las empresas que se han unido al desarrollo del nuevo runtime. Empezando por IBM y BEA quienes usan Equinox para cimentar otros de sus productos como Notes o Symphony.

Sin embargo, no todo han sido cantos de alabanza para el nuevo runtime. En la EclipseCon 2008 de Santa Clara, los hay que piensan que de un tiempo a esta parte Eclipse está excesivamente controlada por IBM, que estos sistemas comunes de componentes añaden más complejidad de la que quitan y que, en general, todo lo que tocan los ingenieros de Eclipse se convierte en una cacharrada dificilísima de entender.

Desde el punto de vista del posicionamiento de mercado, hay que ver el anuncio como una forma de desmarcarse del IDE puro y duro para convertir a Eclipse en una plataforma integral de desarrollo y ejecución de aplicaciones.

Artículo relacionado: How OSGi Changed My Life (Peter Kriens)

En esto de Scrum y las metodologías de gestión de proyectos en general existen dos corrientes de pensamiento principales. Una es la encabezada por Jeff Sutherland, co-creador de Scrum y gurú de las metodologías Ágiles: según él, para que Scrum funcione hay que ceñirse estrictamente a las reglas, y todo lo que no pase el checklist completo no puede llamarse Scrum (y de hecho debería estar perseguido por la iglesia y garantizarte una buena temporada en los fuegos del infierno).

Otra la forman los que piensan que no hay una policía del Scrum que vaya a venir a detenerte si decides formar equipos de 14 personas cuando la norma es de entre cuatro y diez personas por equipo, o que rodeen el edificio con sirenas y megáfonos si llegáis a la conclusión de que los Sprints de duración fija no son para vosotros.

Leer completo...

A través del artículo Dip into concept programming de Phil Manchester en Reg Developer he estado leyendo unas Diapositivas sobre Concept Programming de Christophe de Dinechin y el lenguaje de programación extensible XLR

La idea, hasta donde yo la entiendo, es un lenguaje que te permita definir tu propia sintaxis para expresar conceptos.

En principio, la idea está muy bien, todos sabemos que en ocasiones es preciso escribir un código muy retorcido para expresar algo muy simple.

Por ejemplo: “Devolver true si el elemento x está en la lista {a, b, c, d}” En los lenguajes imperativos esto requiere escribir un bucle o usar un iterador, en los funcionales ese tipo de funciones se expresan de forma más natural, aunque la notación todavía puede quedar bastante inintelegible.

Lo que propone Dinechin es un lenguaje donde esté permitido escribir cosas como:
function Add (A, B : array) return array written A+B
dando así la notación del lenguaje para expresar el concepto de sumar dos matrices.

El problema es que esto ya se ha intentado, y no ha salido bien. El lenguaje conceptual por excelencia son las matemáticas clásicas. Cuya notación es tan críptica que resulta imposible de leer sin años de formación previa. Los matemáticos te calzan una hache mayúscula negrita para expresar Dios sabe qué espacio vectorial H y si te encuentras una â con acento circunflejo ya agárrate los nachos a saber lo que significa. Para colmo de males, fuera del cálculo y el álgebra básicos, ni siquiera hay una notación totalmente estándar o un manual de referencia general sobre notación matemática que puedas consultar.

Es decir, que yo creo que la idea está bien, pero no estoy seguro de que sea una buena cosa abrir la veda y que cada cual se invente su propio idioma de programación según le venga en gana.

Cada cierto tiempo se oyen voces críticas sobre la falta de rigor con la que trabajan la mayoría de los programadores. La falta de métodos formales de verificación y benchmarking produce muchos programas lentos y nada fiables. Pero ¿es la programación sólo una extensión de las matemáticas por otros medios?

Leer completo...

Interesante el artículo de Variable not found donde nos da 13 consejos para comentar nuestro código.

Son todos consejos muy bien traídos y me gusta sobre todo que van más allá de la implementación concreta en un lenguaje concreto y en lugar de eso se centra en cual debe ser el espíritu de los comentarios: No comentar lo evidente, escribir código que esté autocomentado, comentar como parte del proceso de programación, no después, etc.

Ya he dicho por aquí en varias ocasiones que creo que OWASP es un proyecto estupendo. Dedicado a proporcionar información y herramientas para la programación segura de aplicaciones web, creo que es una web indispensable para cualquiera que se quiera llamar desarrollador web.

Uno de los últimos componentes que ha lanzado es AntySamy, una librería que nos permite validar que un texto html/css se adhiere a una serie de reglas de seguridad. Sirve para cuando queremos aceptar una serie de html/css del usuario (por ejemplo, para un comentario o una página de perfil) pero no queremos que eso nos suponga un problema de seguridad.

Lo interesante de la solución es que es completamente configurable en cuanto a qué aceptaremos. De hecho, la librería se distribuye con varios perfiles que imitan lo que se acepta en varias sitios web muy conocidos (slashdot, ebay, myspace).

Es una librería Java, pero anuncian versiones para .Net y para PHP.

Buenas noticias para los desarrolladores Ruby: Parece que la próxima versión “1.9” mejorará ampliamente el rendimiento. Y no solo respecto a la versión actual, sino respecto a los distintos interpretes alternativos que han ido surgiendo y que hasta ahora superaban en muchos casos al interprete “oficial”.

En el siguiente gráfico podemos ver una comparativa entre las distintas alternativas:

Algunos consejos prácticos sobre cómo poner precio a tu aplicación web: How to price your web application. Es una lectura interesante en la que se nos habla de cómo diferenciar los distintos planes, qué estrategia de precios puede resultar interesante, etc.

Si os interesa este tema y no lo habéis leído, es imprescindible leer Camels and Rubber Duckies de Joel Spolsky.

Por cierto, leyendo el artículo sobre Endeve en Alzado la respuesta parece ser: En España, mejor no le pongas precio.

Resumiendo: Endeve es una aplicación para gestionar nuestras facturas, especialmente recomendado para autónomos y pequeñas empresas. Hace un año, decidieron abrir la plataforma y poner gratuita una buena parte de su funcionalidad. Aunque han conseguido multiplicar sus usuarios (gratuitos) un 800%, parece que muy pocos usuarios pagan por el servicio (o por lo menos esa es mi impresión tras leer el artículo).

¿Cual es el problema? ¿Quizá esa aplicación no interesa a su publico objetivo? ¿O es que en España nadie quiere pagar por una aplicación web? ¿Alguna empresa ha conseguido vivir de una aplicación web?

De las mejores anécdotas que he leído sobre programadores chapuceros. Se puede leer en esta entrada de Worse Than Failure, donde un programador implementa una hastable en lugar de utilizar la que viene por defecto con la plataforma.

Lo de menos es que haga un trabajo inútil y que su implementación sea posiblemente la peor de la historia de la programación. Lo hilarante es que cuando se le pregunta por qué lo ha hecho, responde que la clase que venía con la plataforma tenía demasiadas funciones por lo que obviamente sería más lenta que su versión, que sólo tenía las tres funciones que él necesitaba X-D

Y seguimos con gráficas. Google lanzó ayer mismo un API remoto para desarrolladores que les permite crear gráficas en su página web, sin más que incluir llamadas a una url de Google (http://chart.apis.google.com/chart) pasando los parámetros adecuados. Esta llamada devuelve un PNG que será insertado en la página.

Tiene multitud de opciones y tipos de gráficas que se soportan y como gran ventaja tiene el que no requiere instalar ningún componente en absoluto en nuestro servidor. Ejemplo de gráfica servida en tiempo real:

Como defecto, decir que tiene un límite de 50.000 accesos por usuario y día. Dado que en un mensaje del grupo de discusión aclaran que por usuario se refieren a sitio web donde la gráfica es insertada, pues quizá queda un poco limitado para sitios extremadamente populares o que bruscamente reciben multitud de visitas por ser referenciados en un un sitio web popular.

• Información, faq y grupos de discusión sobre Goggle Chart API.