Joomla

Hoy creo lo escuché por primera vez: Joomla [wiki] [otra][articulo].
Por lo visto es un CMS open source que están usando en yell.
En la wikipedia tienen un directorio de CMS open source, y una lista de CMS.

Desarrollados python tenemos:

• MoinMoin
. Aunque parece mas bien un wiki.
• Nuxeo CPS. Usa Zope (el cual es un servidor de aplicaciones). En la proxima versión van a migrar a Java.
  
• Plone. Usa Zope.
  
• PyLucid. Usa django.

Java World

Que mundillo este de los Javeros... Tan lleno de siglas. Mundo en el que yo mas o menos me he mantenido al margen.

Tengo que reconocer que no me apasiona el lenguaje, ya que cuando surgió yo era muy de C++ y eso marca... Jeje.
Sin embargo el que ahora me apasiona es Python. Curioso... ¿Porque? Porque Python está mucho mas alejado de C++ que Java. Java es como que se queda a medio camino...
Mira si dejas ya un lenguaje como C++, lo dejas con todas las consecuencias. Eso si, está bien que apareciese Java y que exista. Tiene un nicho claro.

Hace tiempo estuve trasteando un poco con Java y CORBA, y realmente respecto a manejar CORBA con C++ es una gozada. Pero tras conocer python y volver a tocarlo, tengo mas fundamentos para ver que realmente se queda a medio camino. Hay que teclear mucho...

Un lenguaje como Python también tiene sus desventajas, pero para desarrolladores digamos 'avezados', que hagan buen uso de él, es una gozada.

Bueno... tras esta introducción a continuar con el típico post mio de recopilar enlaces que traten de un tema determinado...
Post que claramente tiene su origen en el curso que estoy haciendo... que me está sirviendo y mucho para refrescar estos temas.
Bueno al lio...

El curso que estoy haciendo es una introducción a J2EE. Bueno y ni siquiera eso, ya que que se quedan fuera los EJBs, u Enterprise Java Beans (que no confundir con los Java Beans). O los WebServices (esto ya si que es un cristo...), por mencionar un par de cosas. Vamos... que vemos solo parte realmente web, la que se ejecutarça en el servidor web.



Los EJBs son objetos distribuidos, mientras los Java Beans son objetos java reutilizables que deben implementar un determinado interfaz.

¿Entonces que es lo que vemos en el curso? Pues básicamente Servlets (que sería el equivalente a los Applets en un navegador, pero en el servidor) y JSPs . Bueno también las TagsLibs, y lo que de tiempo al final. Parece poco, pero es muy practico y ya se sabe... la practica lleva tiempo...

Sobre los JSPs... Los JSPs es una tecnología que te facilita la generación de Servlets (lo que se genera, dinámicamente, es un Servlet). Te facilita la integración de codigo Java (o no Java) con otro contenido (típicamente html). Vamos... es como si fuera una especie de template.

Como herramientas usamos.... adivina, adivinanza... Tomcat, Apache, y Eclipse.
Si usasemos EJBs ya no serviría Tomcat, ya que Tomcat sólo un contenedor de Servlets. Necesitaríamos un servidor de apliaciones, y seguramente habríamos usado JBoss, que es posiblemente el mas extendido.

Aunque los Servlets y las JSPs es la base del desarrollo web en Java, la tendencia es a usarlos poco directamente. La gente suele usar frameworks, siendo el mas oido struts (que es una implementación del patrón MVC).

Los frameworsks también tienen sus peros; siendo el principal el que mientras las cosas van bien, todos contentos, pero cuando van mal... a ver quien es el guapo que pilla que es lo que va mal.
Pero claro... como estos javeros lo que no quieren es tirar lineas de código... ;).

Contra esta tendencia a la complejidad y embarullar todo un poco han surgido cosillas como los POJO. También como reacción a lenguajes que vienen pisando fuerte: python y ruby.

Ya sobre como se da el curso en si...
Pues está bastante bien. Teoría la justa, la necesaria; y a practicar, que es como realmente se aprende.
Me preguntaba el cheriff si lo que estabamos viendo era la Pet Store... ¡Pues no! Estamos integrando una aplicacioncilla superchorra que se ha currado el profe. Y cuando digo integrando es realmente eso: nos dedicamos a montar la 'cola' entre el diseño web y la capa de negocio. Ambas cosas ya las tenemos hechas.

En Java BluePrints [wiki], aparte de la Pet Store, hay otra aplicación demo, la Java Adventure Builder Reference application; pero que no es tan popular. Los downloads.
Ummmmm, habrá que hacer una Python Pet Store ;)...

Y con esto y un bizcocho hasta mañana a las ocho (nunca mejor dicho).

Mas sobre PHP

Continuando un post anterior. Y tras este empape en tecnología web, no podia faltar leer algo mas sobre PHP.

No ya sobre como es el lenguaje, sino sobre su posición frente otras alternativas. Resumiendo:

• PHP: es el lider en muchos sitios populares. Se podría decir que es el lider a desbancar. El que debería escoger alguien que quiera montare algo web, sin experiencia en desarrollo.
  
• Java: gracias a la gran labor comercial que se ha hecho con él tiene un nicho enorme. Tiene ventajas sobre PHP, a cambio de complejidad. Este le gustaría mas a un Ingeniero Software, por el lenguaje y framework en si. Si ya estudiamos otros temas... puede que no. Los desarrollos son lentos y complejos. Un Ingeniero con PHP debería hacer las cosas tan correctamente como con Java, sólo necesitaría metodoloría.
  
• RoR: Nueva alternativa. Le gusta a los Javeros.
  
• Python: ¿tiene futuro? Si lo tiene será por el lenguaje en sí.
  

El nicho que debería ocupar python sería el que tiene Java ahora mismo, pero metiendose incluso en el nicho de PHP. ¿Será esto posible? Dificil lo tiene.
Por lo que he podido leer PHP está muy fuertemente afianzado. Bueno a los links... Vía barrapunto he leido unos artículos interesantes:

• Python never had a chance against PHP. Tiene una referencia al siguiente articulo de Ian Bicking que todavía no he leido: Why Web Programming Matters Most.
• What PHP deployment gets right
• The PHP Scalability Myth: Este no está tan bien como los anteriores pero tiene unos gráficos explicativos sobre las arquitecturas de J2EE y PHP. Esa parte está muy bien. No me gusta el concepto de escalabilidad que usa.
  

Parseando html

Hace tiempo estuvimos decidiendo que parser usar, para procesar el html en mi proyecto actual. En su momento fue una labor nada sencilla. Había dos requisitos básicos: tenía que ser rápido y se tenía que tragar html defectuoso. El ganador fue libxml2.

Hoy me he encontrado un blog muy interesante, el de Ian Bicking. En su blog tiene un artículo reciente sobre el parseo de html. En dicho artículo llega a la conclusión de que el mejor parser es lxml.

Llega a la misma conclusión que llegué yo, pero bajo unos requerimientos diferentes.

Sería interesante probar cuanto tiempo ganamos usando libxml2 y nuestras propias estructuras de datos frente a usar directamente lxml.

Documentando código

En el blog ya puse alguna mas entrada sobre documentación de código, al menos para python.
He visto en la wikipedia que tienen una comparativa de generadores de documentación.

BDs libres

El otro día comentaba sobre BDs para almacenar pares de datos.
Para completar ese post ahí va uno para reseñar algunas de las BDs que disponemos for free:

• SQLite
  
• MySQL
  
• PostgreSQL
  

La diferencia entre SQLite y las otras dos, es que las otras con sistemas cliente-servidor y SQLite es una libreria.
Con todo lo reseñados ya tenemos un abanico lo suficientemente amplio para escoger la solución que mas nos convenga... ¿no?

Web framewoks

Este post viene por mi inquietud al respecto por varios motivos:

• Me gustaría hacer algo en la web
• Voy a dar un curso sobre J2EE. Realmente no me interesa NADA todo lo que tenga que ver con Java, pero si lo considero educativo. Tengo que aprovechar que dadas las circunstacias del proyecto ahora puedo... Ademas en mi proyecto actual si tenemos un servicio web montado con tecnología J2EE.
• Ayer JJ tras comentarle sobre lo de google, me volvió a hablar de RoR.

Si nunca has desarrollado para web (como yo) y tienes la libertad absoluta para hacerla, ¿con que lenguaje y framework hacerlo? La verdad... ambas cosas están relacionadas.
Empezando con el lenguaje, ¿que usar? php, ruby, java, perl, python, ...
Luego para cada lenguaje puedes disponer de varios frameworks, para liar mas la cosa...

Lo que si parece estar claro es que el dominante en los sitios populares es php.
Otra cosa curiosa es que los desarrolladores de Java tienen predilección por ruby y su RoR (Ruby on Rails). Como en este caso JJ.

Sobre python, entre los númerosos frameworks (a ver si encuentro un artículo bueno que los compare) que tiene el que parece está teniendo bastante tirón es django.
Sobre python no voy a profundizar, ya que será motivo para otro post.

Mi curiosidad se centra en RoR. A ver que hay detrás. Entonces que mejor que echar un vistazo a lo que hay por la red:

• Ruby on Rails vs PHP: una falsa comparación
• RoR vs Django
• RoR and J2EE

Notas finales:

• Al buscar la imagen, encontré esta página, que compara también php, java y ruby.
  
• Estas comparaciones hay que tomarlas con recelo ya que en muchos casos no son objetivas.
• Visto lo visto, como que paso ni de mirar mas fondo RoR.
  

Autotools

¿Quien no conoce el famoso script configure?
Parece mentira que hasta la fecha nunca haya tenido que hacer uno. Pero creo que va siendo el momento...
Aprovechando que tenemos un momento de parón en el proyecto y la ocasión perfecta.
Estoy generando un rpm que tienen dependencias de unas librerías externas y claro... no está nada bien el tener rutas a piñón... Estoy ante la ocasión perfecta.
Pongamonos a ello...

Las principales herramientas de autotools son:

• automake [wiki]: nos permitirá generar mejores makefiles, mas portables, ...
  
• autoconf [wiki]: es la que nos va asegurarnos que disponemos de todo lo necesario. Usa para ello macros escritas en M4. Existe un repositorio de macros, por si necesitamos macros aparte de las que ya acompañan al paquete.
• libtool [wiki]: Por lo visto si lo que queremos es generar una libreria, la necesitaremos.

En principio, creo me voy a limitar a usar autoconf, y a mantener el makefile a mano.

Una cosa superinteresante de automake es que te detecta las dependencias dinámicamente. Cuando haces un makefile a mano, son estáticas, ya que tu las tienes que meter en las reglas. O bien montarte tu dicho mecanismo. Pues bien... automake esto te lo da.

Este post lo iré actualizando sobre la marcha..

Pares clave-valor persistentes

Para almacenar persistentemente pares clave-valor disponemos de GDBM - The GNU database manager. La cual es la reimplementacion de dbm para gnu.
Como no podia ser de otra manera tenemos un módulo en python para hacer uso de ella.

Otra implementacion es bdb.

Como otros almacenamientos persistentes tenemos:

• InnoDB. Esta es mas mejor porque es ACID.


• MyISAM
  

Mondrian Code Review On The Web

Creo que fue en el video sobre Google App Engine, donde escuché sobre Mondrian.
Aprovechando que ahora tengo tiempo lo he estado viendo... y merece la pena verlo.

La charla, impartida por Guido, empieza mostrando lo que usaban antes de que implementaran Mondrian, lo que aporta Mondrian y sus ventajas. Básicamente usaban varios scripts.
Ah! antes de nada comenta sobre la filosofía de trabajo. Parte de él es hacer reviews del código fuente.

Hacer revisiones es una alternativa a la xp. Eso si con el mismo objetivo, mejorar la calidad. ¿Donde he visto yo estas practicas? ¿En ningún sitio?

Gracias al video me enterado de cosillas, como por ejemplo que prácticamente no usan branches, y que como sistema de control de versiones usan Perforce [wikipedia][site].

Lo que hace en pocas palabras
Lo que tienen ahora es una aplicación web que gestiona todo el tema de las reviews.
Como desarrollador te revisan y revisas. En la pantalla puedes ver en 2 paneles codigo antiguo y nuevo, poner comentarios....
Ademas se hace uso del correo para enviar notificaciones, ...
Todas estas cosillas siempre se guardan, usandose para ello BigTable+GFS.
Lógicamente también tienen que acceder al servidores de Perforce, y a los entornos de los usuarios (soportan SSH y NFS).

Como lo hacen
Guido comenta que casi podría correr en una maquina, ya que casi todo el trabajo pesado se hace fuera (Perforce, GFS, rendering de html), pero que lo tienen montado en dos maquinas: una para el mail server y otra para el web server.

Y como no podría ser de otra manera usan python a saco: el mail server es wsgiref (multithread y estandard) y el mail server smtpd.py (monothread).

El interfaz es html+css, usando las templates de django, y como no podía ser de otra manera, usan AJAX.

Para hacer los diffs usan la librería de python difflib.

Tanto smtpd, como wsgiref y difflib son módulos estándares de la distribución de python.

Visual Test

Hablando ayer con mi futura cuñaaaaaaaa, le comentaba que hace años mil yo usaba Visual Test para la automaticación de pruebas de interfaces graficas.

El motivo de la conversación era porque estabamos generando .avi's a parter de dvds. El problema de dejar lanzado un lote de generaciones es que si te sale un popup, por algun problema o alerta, el proceso se para (usamos autogk). Le comenté que eso se podría solventar con un script realizado con visual test, y de ahí este dejavú.

La verdad es que era supercomodo de usar. Te grababas las accciones y automáticamente se generaba un script. Script que luego podrias adaptar.
Con N de estos scripts te montabas ya una batería de pruebas. Era la caña...

Me he quedao sorprendido de, ya no sólo que pasara a ser de Rational, sino que Rational ha pasado a ser de IBM.

Esta es la lista de los productos de rational.
Y como no, el sucesor de visual test está: IBM Rational Robot.

Referencias:

• GUI automation.
• GUI Testing Tools
• DogTail: como no... en python algo tenía que haber.
• Software QA Resouces Center. (SQARC)
  
• Linux Desktop (GUI Application) Testing Project (LDTP)
• En APTest hay un listado todavía mas impresionante que el de SQARC.

Actualización

• Para la automatización en unix, disponemos de expect.
• Como no podia ser de otra manera hay un flavour en python: pexpect.
• Y una par de herramientas for free para windows: autohotkey y autoit.
  

Google App Engine

He flipado un poco cuando lo he visto en barrapunto. Esto puede ser un buen empujón para python y django.

Este artículo lo cuenta muy clarito.
Y os recomiendo ver los videos en youtube del Campfire One: Google App Engine.

De momento su uso está cerrado, pero puedes indicar que te avisen cuando vuelvan a ofrecer el servicio. De momento para probar y enredar se puede usar el SDK en local.

La idea de todo esto, es desarrollar y olvidarte del manteniento de la aplicación online, de cuanta maquina necesitas, cuanto espacio en disco, el que este online 24x7,.... Google se ocupa de todo esto.
¿Interesante verdad?
Bueno... la chicha:

• google apps engine: el home, api, sdk, doc, articles, ...
  


• aplicaciones ya hechas

Relacionado:

• Big Table.
• AWS: "AWS offers into a singular package: storage like S3, auto-scaling and processing power like EC2, and a datastore like SimpleDB." (Simple db: BD hecha en java).
  

Python IDEs

Jonathan Ellis comenta que a raiz de un post en un blog ha estado organizando el listado de los editores python 'reales' existentes.
También hay un listado de editores que tienen algún soporte para python, pero que no pueden ser considerados editores 'reales'.

La diferencia entre los primeros y los segundos está principalmente en las facilidades que te den para hacer introspección, depuración y ayuda a la codificación.