Betabeers Barcelona decepcionante

BetabeersEste pasado jueves 29 de Noviembre asistí a la reunión Betabeers que acostumbra a realizarse mensualmente en La Salle (Barcelona) desde hace algunos meses gracias al esfuerzo de Cristian González, cofundador de Pickate .

El programa parecía interesante, durante la primera parte se hablaría sobre patrones de diseño en la plataforma Android, seguidamente presentarían un programa de colaboración con la IESE Business School para un curso práctico sobre creación de empresas, y más tarde dos empresas (Nubelo y Firstclap) presentarían sus respectivos proyectos. Pero nada más lejos de la realidad, pocas veces he sentido tan fuertemente la sensación de estar desperdiciando miserablemente mi tiempo.

Empecemos, llego puntual. El inicio se retrasa unos 10 minutos para que los que llegan un poco tarde (entre los que me acostumbro a encontrar) no se pierdan nada. Cristian se presenta y da inicio al evento, dando paso a publicidad sobre la BcnDevCon (bastante interesante, pero no apta para el estado actual de mi bolsillo), no sin antes preguntar quien ha asistido ya a algún otro Betabeers, y preguntándose en voz alta por qué siempre hay más gente nueva que repetidora.

Hasta ahí todo normal, se intenta amenizar la reunión, se publicita un evento potencialmente interesante para los desarrolladores, y de paso, si eso ha servido para financiar a Betabeers, pues mejor. Lo malo empieza con la "chicha" (allí donde uno esperaría encontrar lo mejor). El nivel de la primera charla (a cargo de Fernando Cejas) fue espantosamente bajo, nada técnico (ni a nivel ingenieril, ni a nivel de diseño): empezó definiendo lo que es una interfaz de usuario [sic], y continuó con diapositivas robadas de la web de Google, explicando datos evidentes o que se podrían encontrar con 2 minutos de búsqueda, nada de know-how, ninguna novedad, ninguna reflexión verdaderamente interesante, en definitiva, nada que valiese la pena. De hecho, yo me dormí a causa del aburrimiento que me provocó.

Se acaba la charla, el silencio súbito me despierta, justo a tiempo para aplaudir con desgana al conferenciante, agradeciéndole que acabara, claro. No me da tiempo ni a comerme la galleta que mi estómago pide ansiosamente cuando Luis Martín Cabiedes ya ha entrado en el escenario para presentar su programa de creación de empresas, me toca joderme, no quiero molestar a los demás oyentes con el ruido del envoltorio y el crujir de la galleta.

Empieza, como todos los demás, presentándose ante nosotros y explicando a qué se dedica. Un tío interesante pienso yo, debe ser buen profesor, de esas personas con las que se puede hablar de cualquier cosa, de las que uno siempre puede aprender algo nuevo.

Pero las cosas se tuercen, aunque sigo pensando lo que he comentado, él tiene otras obligaciones: hablar de ese programa... que viene a ser algo como: nuestros estudiantes pijos necesitan técnicos para que se unan a sus equipos y les monten una página web promocional ¿quien se apunta? Lo olvidaba, como es un programa formativo, nadie cobrará.

Evidentemente juegan con la idea de que, aunque no se cobre, codearse con futuros empresarios nunca está de más, aunque no lo dice explícitamente, está claro que es uno de sus ganchos. No, no se trata de crear empresas de base tecnológica, se trata de supeditar la tecnología a las ideas y propósitos de sus futuros hombres de negocio (grupo profesional que, por lo demás, nunca ha acostumbrado a innovar demasiado ni presentar ideas especialmente interesantes).

Y llega la guinda, las empresas invitadas se presentan. No me extenderé mucho, se trata de charlas descaradamente promocionales, y nada más. Entiendo que quieran aprovechar la ocasión para darse a conocer y ganarse algún que otro nuevo cliente, pero ellos también deberían entender que, a cambio de esta oportunidad que se les da, deberían aportar algo más a su audiencia. Ninguna de las dos habló sobre las tecnologías que usaban, ni los retos tecnológicos a los que se han enfrentado o esperan enfrentarse, y eso esperaba yo. Esperaba alguna charla mínimamente técnica, pues no. Solo se limitaron a decir que usaban PHP y MySql, joder, pues para decir eso, mejor que no hagan el esfuerzo, eso es lo que se usa en el 99% de los proyectos web. ¿Realmente no tenían nada más interesante que contar?

Y aquí mi respuesta para la pregunta de Cristian, las sesiones de Betabeers en Barcelona son completamente decepcionantes, falta nivel técnico y sobra humo.

Scaling PHP Book

Scaling PHP ApplicationsRecientemente tuve la suerte de empezar a leer "Scaling PHP Applications", escrito Steven Corona (CTO de Twitpic), pues la empresa donde trabajo (Bananity) lo adquirió a petición del equipo de desarrollo :) .

El libro se puede comprar por 39$ o bien por 59$, dependiendo de si se quieren leer los casos de estudio y capítulos extra que añade a cambio del incremento de precio. Sinceramente, recomiendo gastar esos 20$ extra, se tratan de una gran inversión.

Actualmente el libro se encuentra en fase beta, por lo que algunos capítulos no están terminados y otros ni tan siquiera se han añadido todavía, pero ya está disponible a la venta, ofreciendo a los compradores tempranos actualizaciones gratuitas hasta que éste se de por finalizado. Ante esto, entiendo que la tendencia natural pueda ser la de esperar, pero después de haberlo leído casi entero (es muy ameno) puedo afirmar que ha valido la pena tenerlo ya entre las manos, aunque todavía no esté terminado.

Si tenéis planeado desarrollar una plataforma online que deba escalar de forma aceptable, este libro puede ayudaros mucho. Su título es ligeramente engañoso, pues el texto no se centra enteramente en PHP. Éste está bastante centrado el apartado de sistemas, combinando elegantemente la descripción de principios generales con multitud de "recetas" y casos de estudio, con lo que consigue una mezcla casi inmejorable entre conocimiento teórico y práctico.

Aunque aun hoy casi todo lo que se explica en este libro nos sigue resultando útil dentro de Bananity, puedo afirmar con rotundidad que, de haberlo tenido entre las manos meses atrás, nos hubiéramos ahorrado muchos errores y sufrimiento.

Lo dicho, se trata de una gran lectura, útil y entretenida, totalmente recomendada, así que no sería mala idea añadirla a la lista de reyes de este año ;) .

Vert.x, nuevo competidor para Node.JS

Vert.x se perfila como un serio competidor para Node.JS, nació el día 17 de Junio de 2011 con un solo archivo README, y en poco más de un año y un mes ya podemos afirmar que hace sombra a Node.JS en cuanto a rendimiento y características.

El nuevo framework ha sido creado por Tim Fox (@purplefox en Github) sobre Netty y Hazelcast, y se podría decir que tiene el soporte de VMWare, que es la compañía para la que trabaja Tim. Dado que Vert.x trabaja con Rhino (la JVM de Mozilla), Netty está soportado por RedHat y Hazelcast se ha constituido como una compañía en sí misma, se puede decir que hay un respaldo empresarial indirecto bastante sólido (mayor que el de Node.JS, que solo tiene detrás a Joyent, y a Google por su máquina virtual V8).

¿Qué podemos esperar?

La primera característica notable que podemos encontrar es la cantidad de lenguajes de programación que soporta Vert.x: Java, Groovy, Ruby (JRuby), Python (JPython), JavaScript y CoffeeScript. Además, se está planteando la integración de Scala y Clojure en el stack de lenguajes soportados. Como bien dice Tim Fox, Vert.x es un framework políglota, y no hay mucho que decir sobre las ventajas que eso supone, que presumo obvias.

El segundo punto que llama fuertemente la atención es su baja latencia y su alta escalabilidad. Su creador ya dedicó una entrada del blog oficial a mostrar sus benchmarks ¹, pero puedo asegurar por experiencia personal que supera con holgura a Node.JS (junto con mis compañeros de trabajo hemos realizado nuestros propios tests).

Un aspecto que me parece esencial es que su estructura permite un mayor control de los recursos de la máquina que Node.JS, y a su vez, hay gestión automática (más eficiente que la humana) allí donde Node.JS obliga a que definamos schedulers rudimentarios chupándonos el dedo y levantándolo para ver por donde sopla el viento ².

Aunque para muchos javeros esto es algo prácticamente evidente, la cantidad de librerías que se pueden usar en Vert.x es mucho más grande que las que podemos encontrar para Node.JS, y hay más, hasta donde he visto, son más eficientes y estables, y están mejor programadas (esto se puede deber a que el ecosistema de Java es ya muy maduro, y a que el nivel de exigencia ha aumentado en parte debido a eso).

¿Qué falta?

Bien, no todo puede ser de color de rosa. Vamos a por la parte "desagradable". Vert.x tiene un ritmo de desarrollo muy bueno, pero eso es así porque Tim Fox da el callo como nadie, el problema es que la comunidad todavía no es lo suficientemente grande (y aquí estoy yo, intentando hacerla crecer). De momento los desarrolladores del proyecto y sus beneficiarios discuten en un grupo de Google Groups ³, que está bastante activo, pero ni de lejos como la comunidad de Node.JS.

Cambiando drásticamente nuestro punto de mira, pasaremos a algunas deficiencias técnicas. La primera (y única, pero muy jodida) que me he encontrado es la falta de gestión de peticiones HTTP POST multipart. En estos momentos hay una pull request pendiente de ser aprobada ⁴ que implementa la gestión de esas peticiones, pero todavía no está documentada y de momento solo soporta Java. Tim Fox da por buena la implementación, aunque no está de acuerdo en algunos aspectos, pero aceptará al contribución si esta se documenta y extiende al resto de lenguajes siempre y cuando no aparezca otra que le agrade más.

Integración con MsgPack. Java tiene algunas librerías muy buenas para manejar estructuras de datos serializadas con MsgPack que se podrían usar directamente, pero me parece interesante la posibilidad de lograr una integración similar a la que goza JSON para poder usar el bus de Vert.x con MsgPack.

Bien, esto es todo :) . Os animo a que lo probéis y hagáis vuestros pinitos con él, no os arrepentiréis.

Referencias

  1. http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/
  2. http://blog.andrewvc.com/vertx-node-on-ropes
  3. https://groups.google.com/forum/?fromgroups#!forum/vertx
  4. https://github.com/vert-x/vert.x/pull/235

superAjaxForm 0.1

A lo largo de varias semanas he ido desarrollando (con mucha calma) un nuevo plugin jQuery para poder enviar formularios (con archivos incluidos) vía AJAX en el máximo número posible de navegadores [1].

El código no es trivial, he tenido que leer toneladas de documentación, y aun así quedan algunos navegadores sin cubrir (básicamente la saga de Internet Explorer).

Queda mucho por testear, y probablemente aparezcan algunos bugs a medida que la gente le eche mano, pero espero ir solventándolos con la mayor brevedad posible.

En cuanto al soporte para Internet Explorer, desgraciadamente tengo que anunciar que no lo veo factible (al menos de momento) debido a la falta de alternativas que provee dicho navegador (se tiene que optar por soluciones parciales, como los típicos uploaders programados en Adobe Flash).

Un punto que me parece importante es lo que me ha motivado a desarrollarlo. Actualmente no había ninguna solución "integral" que permitiera enviar formularios completos vía AJAX, o bien solo enviaban formularios sin ficheros, o bien solo eran capaces de enviar ficheros (y muchos se respaldaban, a mi juicio, excesivamente en Adobe Flash). Es por todo esto que he creado superAjaxForm.

No me explayaré mucho contando minucias técnicas, pero os dejaré una serie de referencias sobre la documentación que he tenido que leer.

Referencias

  1. Repositorio de superAjaxForm: https://github.com/castarco/superAjaxForm/
  2. Documentación de superAjaxForm: https://github.com/castarco/superAjaxForm/wiki/Documentation
  3. [RFC 1867] Form-based File Upload in HTML: http://www.ietf.org/rfc/rfc1867.txt
  4. [RFC 2388] Returning Values from Forms: multipart/form-data : http://www.ietf.org/rfc/rfc2388.txt
  5. Implementación de XHR.sendAsBinary en Chrome: http://code.google.com/p/chromium/issues/detail?id=35705
  6. Truco sucio para implementar sleep dentro de un bucle: http://stackoverflow.com/questions/3583724/how-do-i-add-a-delay-in-a-javascript-loop
  7. Javascript File API Draft: http://www.w3.org/TR/file-upload/
  8. Documentación XmlHttpRequest de Mozilla: https://developer.mozilla.org/en/DOM/XMLHttpRequest/
  9. Tutorial sobre XHR2: http://www.html5rocks.com/es/tutorials/file/xhr2/
  10. Tutorial sobre File API: http://www.html5rocks.com/es/tutorials/file/dndfiles/
  11. Documentación sobre FileReader de Mozilla: https://developer.mozilla.org/en/DOM/FileReader

PHP, sesiones y alta concurrencia

Hoy voy a escribir brevemente sobre cierta problemática asociada al manejo de sesiones en PHP que surge cuando nuestra aplicación web debe soportar un alto nivel de concurrencia.

PHP guarda las sesiones en archivos por defecto, aunque hay otros mecanismos posibles: por ejemplo usar bases de datos como MySQL (o bien SQLite), tirar de Memcache, guardar la información cifrada dentro de cookies, etc.

Ninguno de estos sistemas alternativos está exento de problemas. Las bases de datos al uso añaden una latencia inaceptable en la mayoría de casos, SQLite permite lecturas muy rápidas, pero como contrapartida bloquea la base de datos entera cuando se escribe, Memcache puede sobrecargar nuestra memoria y tiene el riesgo potencial de pérdida de datos por la volatilidad de su sistema de almacenaje, y por último, guardar las sesiones en cookies aumenta ligeramente el riesgo de robo de datos y puede añadir un overhead importante a todas las peticiones HTTP.

¿Y qué pasa con las sesiones en ficheros? Pues también tienen su problemática. Cada petición HTTP llega acompañada de la cookie con el ID de sesión, cuando se llama al método session_start se abre un descriptor de fichero que guarda la información asociada a la sesión con el ID ya mencionado y... se bloquea el archivo para poder escribir sobre él los cambios que hagamos en las variables de sesión sin que haya conflictos entre peticiones distintas que usan la misma sesión.

El bloqueo que menciono desaparece por defecto en cuanto finaliza la ejecución del script PHP. Esto significa que si en cierto sitio web realizamos (por ejemplo) 5 llamadas AJAX de forma paralela a scripts que hacen uso de la información de sesión, el resultado que obtendremos es una serie de respuestas serializadas en el tiempo, una detrás de otra.

Una solución parcial para conseguir aumentar el nivel de paralelización de las llamadas AJAX (o cualquier otro tipo de petición HTTP) es desbloquear el archivo de sesión lo antes posible, es decir, cuando sepamos que ya no vamos a modificar las variables de sesión y solo vamos a realizar operaciones de lectura. Para ello podemos usar la función session_write_close, en algunos casos se puede conseguir una reducción impresionante de los tiempos de carga, por lo que os recomiendo tenerlo muy en cuenta.

Otro detalle importante: es desaconsejable permitir que PHP inicie la sesión de forma automática (es preferible iniciarla solo cuando sea estrictamente necesario). Si podéis, intentad que la opción session.auto_start esté a false en el fichero de configuración php.ini.

Espero que os haya servido :) .