La última moda disruptiva son los sistemas de almacenamiento distribuido no relacional pero ¿está realmente lista esta tecnología para dejar su etapa de adoptadores tempranos y entrar en una fase de uso generalizado mainstream?

Todos los programadores se quejan de que no les dejan hacer un trabajo decente y de calidad ¿Qué razón de mercado existe para esto?

A los partidarios de Ruby on Rails les gusta decir que Java es como COBOL (por aquello de que lo usan los bancos). Y quienes usan un lenguaje compilado tienden a menospreciar a los “programadores de scripting”, esos que escriben código guarro sin objetos ni declaración de variables ni nada. ¿Qué hay realmente detrás de todas estas enconadas discusiones?

Una buena base y una gran atención a los detalles es lo que que diferencia a una buena interfaz de usuario. Y un poco de todo (conceptos básicos y detalles) es lo que nos describe este artículo: 10 Useful Techniques To Improve Your User Interface Designs.

Desde una utilización adecuada del espacio y del contraste hasta pequeños detalles como situar el foco de usuario en el formulario adecuado. Solo una advertencia: En mi opinión la novena técnica descrita, mostrar determinados controles sólo al pasar el ratón por encima, no siempre funciona bien. Corremos el peligro de que el usuario ni llegue a conocer que existen esas opciones al estar ocultas a la vista.

Ya he comentado alguna vez por aquí que una de las cosas a las que se les puede sacar mayor provecho en programación es al uso de expresiones regulares. No importa el lenguaje que estemos usando, una expresión regular puede solucionar con elegancia lo que requeriría muchísimas líneas de código.

Por eso nunca vienen mal herramientas que nos ayuden a entender las expresiones regulares y a aplicarlas, como este strfriend.

Escribes una expresión, y el sistema te la analiza y te la muestra con un gráfico que te puede ayudar a entender su funcionamiento. Sencillo y muy útil.

Ángel me ha pedido que escriba sobre un e-mail en la lista privada del Grupo Tibi acerca de Meta4. Contar los entresijos de las empresas es, en general, indiscreto. Pero ya han pasado casi nueve años desde que dejé voluntariamente Meta4, de modo que supongo que las cosas han cambiado mucho allí desde entonces, y también que puedo contar lo que yo creo que pasó, desde la prespectiva que da el tiempo y sin perjudicar a nadie. Yo trabajaba en el departamento de I+D, tenía un jefe güay, y un jefe de mi jefe güay, hasta que un día las cosas empezaron a cambiar…

Hoy estuve en el chat con un amigo a quien llamaré el Capitán del Proyecto para preservar su anonimato. El Capitán me contaba lo que estaba pasando en su proyecto, que no es nada nuevo, ni nada sorprendente. Pero no por ello menos impactante.

97 Things es un proyecto colaborativo que pretende recopilar 97 axiomas que todo arquitecto de software debe conocer.

La idea de esta lista es que es creada por la comunidad. Puedes registrarte en el sitio y valorar los axiomas enviados. Además, si alguno de los axiomas enviados por ti es aceptado, te conviertes en un autor del sitio, con la posibilidad de crear una página con tu “biografía” y participar de modo más activo en la página.

Todos este trabajo queda disponible bajo una licencia creative commons pero además estos axiomas serán luego recopilados en un libro que O’Reilly Media publicará próximamente.

Por ahora tienen ya seleccionados 49 axiomas y contando.

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.

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?

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.

No va a ser solamente Google Analytics quien pueda poner unas estupendas gráficas. Si necesitas mostrar este tipo de información en tus aplicaciones web, aquí tienes un par de opciones que creo que son interesantes:

• Open Chart Flash utiliza la tecnología flash para mostrar gráficas.

Los datos se bajan de un fichero xml con lo que es muy sencillo generarlos dinámicamente en cualquier lenguaje de servidor. La cantidad de tipos de gráficas y opciones es increíble.

• Flot. Si preferimos huir de la tecnología Flash, Flot es un plugin para jQuery que nos proporciona las funciones básicas de gráficas directamente desde javascript.

Esta es una solución menos potente que la anterior (es también una versión inicial, que se supone que irá mejorando) pero puede ser más conveniente en ocasiones.