Por qué el fundador de CD baby ha abandonado Rails y vuelto a PHP

Ya sé que la historia no tienen nada que ver con Java, pero sí tiene mucho que ver con la programación y creo que todos podemos aprender alguna lección de ella. CD baby es un portal dedicado a la venta de música de artistas independientes; tiene bastante éxito y emplea a cerca de un centenar de personas. Su fundador, Derek Sivers, decidió hace dos años migrar todo el portal de PHP a Rails; en su día fue una noticia bastante sonada y los defensores de Rails lo consideraban como una medalla que se podían colgar en el pecho.

 Dos años más tarde, y a pesar de haber contratado a un gran gurú de Rails, el proyecto se ha estrellado completamente y Derek Sivers ha decidido abandonar la base de código Rails y volver a PHP. En una extensa entrada en su blog explica los motivos que le ha llevado a tomar esa decisión. Uno de los motivos, algo que he escuchado en más ocasiones, ha sido la falta de flexibilidad de Rails cuando intentas hacer algo en lo que no han pensado sus desarrolladores. Otro, la complicación para integrar Rails con todas sus aplicaciones "legacy".

Derek Sivers hace varios comentarios muy interesantes:

For 2 years, I thought Rails is genius, PHP is shit. Rails is powerful, PHP is crap. I was nearly killing mycompany in the name of blindly insisting Rails was the answer to all questions, timeframes be damned. But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much. Ruby is prettier. Rails has nice shortcuts. But no big shortcuts I can’t code-up myself in a day if needed. Looked at from a real practical point of view, I could do anything in PHP, and there were many business reasons to do so.

O su opinión sobre los lenguajes de programación: cuántos más aprendas mejor programador serás, porque las lecciones que aprendas en un lenguaje que permitirá programar mejor en los demás, incluso si los otros lenguajes no tiene soporte directo para lo que has aprendido:

PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER

 Rails was an amazing teacher. I loved it’s “do exactly as I say” paint-by-numbers framework that taught me some great guidelines. I love Ruby for making me really understand OOP. God, Ruby is so beautiful. I love you, Ruby. But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now! You look back at your old ugly PHP code, compared to your new beautiful Ruby code, and think, “God that PHP is ugly!” But don’t forget you wrote that PHP years ago and are unfairly discriminating against it now. It’s not the language (entirely). It’s you, dude. You’re better now. Give yourself some credit.

 Sólo añadir una cosa más: bravo a Derek Sivers por hacer algo que prácticamente nadie se atreve a hacer: fracasar y contar a todo el mundo su fracaso para que los demás podamos aprender de él. Muchas gracias Derek .

Liberada la versión 1.0 de PDT, PHP Development Tools for Eclipse

Hace unos pocos días se ha anunciado la versión 1.0 del proyecto PDT, PHP Development Tools for Eclipse, proyecto que pretende crear un entorno de desarrollo PHP basado en eclipse. Podéis descargarlo desde aquí .

Aplicaciones Spring MVC Seguras con HDIV 2.0

Se ha publicado la nueva versión 2.0 del framework web de Seguridad (HDIV), dirigido a solucionar las vulnerabilidades web de nivel aplicación (parameter tampering, SQL Injection, XSS), con soporte para Spring MVC y JSTL 1.1. Además esta nueva versión es compatible con las versiones Struts 1.3.8 y Struts 2.0.9.

Las funcionalidades de seguridad añadidas a los frameworks Struts 1.x, Struts 2.x y Spring MVC son las siguientes:

• Integridad: HDIV garantiza la integridad (la no modificación) de todos los datos generados en el servidor que no pueden ser modificados por la parte cliente (links, campos ocultos, listas seleccionables, valores de radio, páginas destino, cookies, etc.). Gracias a esta propiedad se eliminan todas las vulnerabilidades basadas en la técnica parameter tampering.

• Validación de datos editables: HDIV elimina gran parte del riesgo originado por ataques de tipo Cross-site scripting (XSS) y SQL Injection mediante validaciones genéricas de datos editables (text y textarea).

• Confidencialidad: HDIV garantiza la confidencialidad de todos los datos generados en el servidor. Habitualmente muchos de los datos enviados al cliente aportan información clave para los posibles atacantes como identificadores de registros de Bases de Datos, nombre de columnas o tabla, nombres de directorios web, etc.

Para más información podéis consultar http://www.hdiv.org

Libro gratuito sobre desarrollo de juegos con Java 6 3D

Andrew Davidson, autor de "Killer programming in Java" está escribiendo un nuevo libro llamado "Pro Java 6 3D Game Development" y ha publicado los capítulos  y el código fuente de los ejemplos en su sitio para recibir retroalimentación sobre el contenido.

Un gran recurso para iniciarse en el mundo de los juegos y aprender sobre las nuevas características de 3D incluidas en Java 6. 

Las 10 razones por las que Java no sirve

En realidad el título en inglés es "Top 10 reasons why Java sucks ass" pero no encontré como traducirlo adecuadamente :-P. El autor es un desarrollador de Ruby llamdo Obie Fernández. Como podrás ver muchas de sus razones no tienen sentido alguno pero en mi opinión son una muestra del tipo de ideas preconcebidas existentes en el mundo del desarrollo de software contra Java. Aquí va la lista:

"1) Java tiene un compilador. Al demonio con los compiladores y su falso sentido de seguridad. Con demasiada frecuencia código malo es subido e incluso desplegado en servidores simplemente porque es compilado. En ruby no tenemos ese lujo."  Si alguien entiende este punto que me lo explique. Supongo que tiene que ver con que a menudo se confía en los compiladores para que nos indiquen errores u optimicen el código mientras que en lenguajes interpretados es el programador quien realiza esa labor. 

 "2) Lo creadores de los frameworks Java no son desarrolladores de aplicaciones." Pone como ejemplo a los empleados de JBoss. Bueno, este punto es tan estúpido que no vale la pena debatirlo. Creo que la gran mayoría de los frameworks Java han sido creados por desarrolladores de aplicaciones buscando facilitarse la vida.

"3) La mayoría de los programadores Java son tontos". Aquí el brillante autor realiza simple estadística, dice que si hay 2 millones de programadores Java, es imposible que todos sean buenos porque el número de buenos programadores en el mundo es menor. Sin comentarios.

"4) Java está demasiado fragmentado". Por fin un buen argumento, ese sí es un problema real de Java: demasiadas opciones que confunden a los principiantes sobre el camino a seguir. Pero decir que Ruby es mejor porque solo tiene Rails me parece una tontería. Basta ver lo que paso con Twitter donde Rails no pudo con la escalabilidad y se tuvieron que crear un framework propio.

"5) Java es demasiado lento". Otra idea preconcebida que data de los tiempos de java 1.2 y 1.3; pero sobre todo un argumento muy raro para defender a Ruby que es más lento incluso que Groovy que a su vez es 30 veces más lento que Java.

"6) Java no tiene blocks ni closures". Bueno, closures los tendrá a partir de la 7,  

"7) Java tiene IDEs. (...) Todos saben que los buenos programadores usan VIM o Emacs. (..). Si necesitas un IDE no sirves, punto". ¿Alguién quiere debatirlo? Si las herramientas existen, úsalas. Si te permiten desarrollar en menor tiempo y cometer menos errores, ¿por qué no?. 

"8) Java tiene buen soporte para debugging. (...) Ruby tiene un soporte ridículo para debugging, lo que quiere decir que nuestro código debe ser probado y legible". Supongo que este punto es una broma.

" 9) Java genera mucho dinero para las empresas". Un buen punto a debatir, ¿hasta qué punto los intereses corporativos han ayudado o perjudicado el mundo Java? Al parecer el mundo Java tiene su mayor fuerza en los proyectos open source y en los desarrollos independientes que han moldeado en gran medida el lenguaje y la forma en que lo usamos. Por ejemplo, las empresas han apoyado EJB2 (incluyendo esos horribles EJB de entidad), JSQL, BPEL; mientras que los desarrolladores los contenedores ligeros, el ORM y el uso intensivo de POJOs. ¿Qué es lo que usamos actualmente en nuestros desarrollos?

"10) Java no tiene a DHH." DHH-> David Heinemeier Hansson, el creador de Ruby. Pues no, no lo tiene ..¿y?.

En fin, bastante encendida y llena de ideas preconcebidas esta lista. La verdad nunca he entendido porque los de Ruby siempre han criticado con tanto ahínco a Java, vamos creo que ni Microsoft y eso que es su verdadero rival, mientras que Ruby tiene un mercado un tanto distinto (más enfocado a creación de aplicaciones web 2.0, mientras que Java si bien sirve para eso obtiene sus mayores ingresos de aplicaciones empresariales -basadas en la web o no- y móviles).

La lista también está siendo debatida en Javalobby quienes han propuesto su lista por las que Ruby sucks ass.