Bien batido y revuelto

Como aquella escena de Tron en la que los protagonistas abandonan el grid, en “A List Apart” se nos presenta un artículo que pretende darnos algunas ideas sobre cómo abandonar los diseños cuadriculados. Quizás pueda ser una reflexión interesante, habrá que tenerla en cuenta.

Hace poco publicaba rvr en su bitácora barrapuntera una reflexión muy interesante a raíz de un comentario sobre Ruby vs Python, en el que veia como con cada lenguaje hay que reimplementar todas las librerías ya existentes en otros lenguajes.

la aparición de un nuevo lenguaje no supusiera perder el tiempo en reprogramar funciones básicas, ni la aparición de un nuevo ‘framework’, aprender un lenguaje nuevo.

En ese sentido ve de lo más acertadas las decisiones que Microsoft tomó para basar su plataforma .Net en un CLR que permitiera ejecutar de forma compatible programas y librerías escritas en distintos lenguajes. Aunque no tan claramente como .Net, en Java esto también es posible, y desde hace mucho hay muchos lenguajes capaces de ejecutarse en la máquina virtual de Java.

¿Es Parrot la apuesta adecuada? No lo se, pero creo que el sistema debería ofrecer algún tipo de solución a esos problemas, y mayor interactuación entre los distintos componentes y librerías, independientemente de su lenguaje. Eso creo que siempre se le ha dado mejor a Microsoft

Ruby on Rails es uno de los frameworks más populares en la actualidad, y como no podía ser de otra forma, llevo un tiempo cacharreando con él. Hay muchos recursos, quizás demasiados orientados a principiantes y a como construir una pequeña aplicación, y eso me ha llevado a pensar que se le da demasiada importancia al scaffolding (¿andamiaje?)

Creo que la generación de código que ofrece RoR es muy versátil para crear algunas partes de una aplicación y para ir desarrollando mediante distintas iteraciones, desde un prototipo funcional hasta una aplicación más potente, pero que en el momento que la aplicación llega a un cierto tamaño esas herramientas dejan de tener su utilidad y entonces es cuando Ruby y las estructuras de RoR demuestran su verdadera versatilidad.

Y parece que no soy el único que piensa así, como demuestran la mayoría de comentarios a una nota en Slashdot sobre la escalabilidad de Ruby on Rails.

Cada vez que usamos un lenguaje de programación distinto nos podemos encontrar con muchas diferencias, y quizás una de las principales sean los tipos de datos que manejan. Los lenguajes de scripting modernos soportan tipos bastante complejos de forma muy sencilla e integrada en el lenguaje, las listas son muy características de Python, Perl soporta el tratamiento de cadenas y listas de forma muy eficiente y PHP tiene sus cosas. Cuando pasamos a lenguajes más estructurados como Java o C# a veces podemos echar en menos esas estructuras tan cómodas, pero a cambio tenemos otras cosas.

Y tras esta parrafada, enlazo a un artículo que compara los tipos de datos soportados en PHP y en Perl, una entrada con cierto olor a flamewar eterno de nueva generación.

A través de un mensaje de Ovillo con más razones contra el uso de XHTML. El primero, “XHTML is not for beginners” expone una serie de inconvenientes que puede encontrarse un diseñador al trabajar con XHTML, cuando se da cuenta de que algunas cosas no funcionan como pensaría. El otro artículo sigue la línea de enunciar los problemas que surgen al usar XHTML correctamente, “The perils of using XHTML properly“.

Uno de los textos críticos con XHTML que más repercusión ha tenido es “Sending XHTML as text/html Considered Harmful, escrito por Ian Hickson (implicado en el desarrollo de Mozilla), en el que se describe como se gestionan incorrectamente los ficheros XHTML, tanto por parte del servidor (casi ninguno lo sirve como application/xhtml+XML) como por parte de los clientes, que no suelen tener un buen comportamiento ante esos ficheros.

Y por darle un tono (más) agrio a la nota, reseñar algo que cualquiera que haya trabajado implementando (X)HTML ya sabe: Internet Explorer es una gran culpable del estado actual de los estándares.

En developerWorks publican un interesante artículo sobre depuración PHP con Eclipse. Personalmente encuentro PHP Eclipse como algo excesivamente pesado, peroes una plataforma de desarrollo muy potente y mucha gente está muy familiarizada con ella. En el artículo se explican varias técnicas de depuración, desde los rudimentarios print hasta la gestión de mensajes de error, concluyendo la parte más interesante en el uso de DBG, integrando su uso con Eclipse.

En otro orden de cosas, me gustaría recordar que si usamos Smarty podemos emular de una forma un poco más elegante el clásico método de los print mediante el uso de la consola de depuración, que para algunos pequeños problemas o como herramienta para un sistema en producción puede ser una solución aceptable.

Por cierto, que no es la primera vez que hablo sobre depuración y perfilado. ¿Alguna experiencia que queráis contar?