Y como todo lo bueno siempre se acaba, la PHP Conference 2010 ha dado cerrojazo.
No sin polémica ya que el ganador de la XBOX del sorteo general se llevó también el iPad del sorteo de emagister… la suerte está mal repartida :p (hay que aclarar que el sorteo ha sido legal y a la vista de todos, hay poco que añadir a parte de que la mecánica pueda -posiblemente- cambiarse para el año que viene y unir ambos sorteos).
Y esta fue la elección para el segundo día. Creo que bastante más acertada que el primer día, aunque con alguna decepción:
- Graphs in the database: RDBMS in the social networks age by Lorenzo Alberton
- APC & Memcached: the high performance duo by Ilia Alshanetsky
- Database version control without pain by Harrie Verveer
- Continuous Improvement in PHP projects by Thorsten Rihnne
- PHP Team organisation by Damien Seguy
Seguidamente, un resumen de cada una de ellas.
Graphs in the database: RDBMS in the social networks age by Lorenzo Alberton
- Twitter: @lorenzoalberton
- Blog: http://www.alberton.info
De nuevo, tras haber ya asistido el año pasado a otra charla magistral, otra interesantísima chala de Lorenzo sobre grafos, árboles y bases de datos. Esta vez centrada en dos puntos, las CTE (Common Table Expressions) y Window Functions.
Pese a ser una charla compleja debido a que la presentación se basa en ejemplos SQL y en la teoría, Lorenzo realiza un esfuerzo inhumano para hacerlo entendible desde un primer momento. Además, este año mostró ejemplos reales y concretos que todos conocíamos en la web y que nos destripó a nivel de base de datos.
Tras una breve introducción a los gráficos y sus componentes nos mostró diversas soluciones posibles a la hora de plantear una estructura de árbol en una base de datos a la que seguro que todos nos hemos enfrentado alguna vez. Tras unos consejos básicos de rendimiento y eficiencia y demostrar como realizar cualquier tipo de consulta que abarcara más de un nivel (por ejemplo coger los hijos hasta n niveles), mostró las CTE gracias a WITH (y WITH RECURSIVE). Como si de una función o proceso almacenado se tratase pero viviendo únicamente en el momento de la ejecución, con sus partes bien diferenciadas (inicialización, recursividad y llamada), nos mostró ejemplos desde la clásica sucesión de Fibonacci hasta cómo se pueden encontrar combinaciones de vuelo o transporte mediante varios saltos, los grados de separación en LinkedIn, cómo encontrar los contactos (de camino mínimo) entre tú y otra persona o los «quizás conozcas». Todos estos últimos ejemplos usando Transitive Closures.
También nos mostró como a veces técnicas como esta pueden ser un embrollo y un simple INTERSECT puede solucionar el problema de una forma muy sencilla y rápida.
El segundo caso, las Window Functions (SQL-2003) que nos permiten agrupar cierto número de filas que tienen una relación y extraer datos concretos (por ejemplo, una media de salarios por departamento) y usar ese dato para cada fila, pero sin agruparlas ya que perderíamos cada usuario, es decir, sin usar un GROUP BY. La sintaxis es bastante liosa en un inicio y mucho más potente de lo que a primeras aparenta pero sin duda, gracias a ciertas funciones complementarias, con aplicaciones muy interesantes como poder extraer en una misma petición lo datos completos de venta un día y también agrupados por usuario o los datos agrupados y paginados de los contactos telefónicos.
Por último nos llamó a la reflexión ante qué debe ser bueno ejecutar sobre base de datos y que no ya que se puede ver con los ejemplos como podemos quitar carga de procesado en la parte de aplicación, eliminando conexiones y RTT entre la base de datos y la aplicación, pero que ello conlleva sobrecargar la base de datos.
APC & Memcached: the high performance duo by Ilia Alshanetsky
- Twitter: @iliaa
- Blog: http://ilia.ws/
- Charla: http://ilia.ws/archives/229-APC-Memcache-the-High-Performance-Duo-Slides.html
La charla empezó la charla dando cuál iba a ser el slogan: «Slide motto: not everything has to be real-time». Y lo siguiente en darme cuenta fue que es realmente un crack y que su trepidante velocidad y conocimiento hace que perderte unos segundos escribiendo algo en el portátil puede hacer que te pierdas gran parte de un slide.
La estructura de la charla en mi opinión fue perfecta: breve introducción de las aplicaciones y cómo instalarlas (que estoy seguro que eran conocidas para la amplia mayoría de los asistentes) y tras esto, una serie de consejos, buenas prácticas y trucos de cada una de ellas. Eso sí, yo creo que el oxígeno se lo inyectaba, porque no creo que le diese tiempo a respirar entre frase y frase, jeje.
En cuanto a APC, lo primero a tener en cuenta es que tenemos el cacheo propio y transparente que hace de los opcodes, con la consecuente mejora de rendimiento que conlleva y que además podemos usar para cachear datos en shared memory. Y lo más importante, lo que se cachea no es el valor, sino el propio opcode. La ventaja de este método es radical ya que si comparamos con un método trandicional de cacheo mediante serialización de datos (aunque sea binario), siempre hay que realizar la propio acción de serialización y deserialización, desmaterializando y materializando los objetos, mientras que APC cachea el propio opcode, el dato en sí, algo que es mucho más rápido y efectivo.
Otros trucos: cómo saber cuando apc_fetch nos ha devuelto información o no y es gracias a un segundo parámetro que tenemos que pasar por referencia ya que lo que se retorna es el dato y puede ser cualquiera de los valores posibles (null, true, false, array, objeto…) por lo tanto necesitamos un punto de referencia.
Y como consejo muy importante, evitar todo lo posible el borrado de caché: «Don t delete: deleting from cache is expensive as it may need to re-structure internal hash tables». A veces el mejor borrar todos los datos de un usuario que un dato concreto debido a todo el proceso que puede desencadenar.
Como contra, APC es un sistema de cache única y exclusivamente para PHP, nadie más puede usarlo y es local, no distribuído, lo que limita su radio de acción.
En cuanto a memcached, lo primero que nos hizo notar fue la necesidad de usar la extensión de Andrei Zmievski y no la otra existente que no lleva d al final ya que la diferencia y mejoras es notable: serialización binaria mediante igbinary, compresión fastlz, interface multiservidor y soporte ante fallos de caídas.
Con esta extensión, tenemos (entre otras muchas cosas, a destacar):
- getResultCode() para saber si hemos recuperado un ejemplo o no (comparándolo con MemCached::RES_SUCCESS)
- podemos asignar y recuperar varios valores simultáneamente con [get|set]Multi()
- se pueden añadir varios servidores son prioridad o balanceo usando addServers() y el tercer parámetro para cada servidor
- podemos segmentar información indicando el servidor concreto donde se almacenará (sin dejar que memcached decida) gracias a [add|get|set|delete]ByKey()
- segmentar varios datos a la vez [add|get|set|delete]MultiByKey()
- utilizar contadores atómicos increment() y decrement()
- …
Y por último, destacar el hecho de poder pedir datos de forma retardada (delayed fetch) de modo que nuestra aplicación no tenga que esperar, sino que puede hacerlo más tarde, continuando con la ejecución de nuestra aplicación. Lo que hay que tener muy en cuenta es que la información es probable que no venga en orden.
Database version control without pain by Harrie Verveer
- Twitter: @harrieverveer
- Blog: http://www.harrieverveer.com/
Tengo que decir que esta charla me defraudó mucho. Con un título tan potente ante un tema que realmente da muchos quebraderos de cabeza, no esperaba que diese el quid que solucionase completamente el problema (algo que parece que sí dice el título o eso esperábamos todos los presentes), pero sí que parecía algo importante.
Pero más allá de la realidad, nos dio varias de las herramientas que actualmente existen y que intentan facilitar el trabajo y declarar que el problema es muy importante y hay que llevarlo con cautela. Sí que me quedo con una frase que me parece muy importante: «Never modify a patch file once it is version control». Es decir, en caso de que hagas un patch file y tenga un error, no debes corregir ese, sino crear «el patch del patch» que lo solucione.
Estas son las herramientas recomendadas:
En las preguntas finales: el propio ponente declaró que su estrategia es un «homebrew script» aunque otros equipos en su empresa usan DB deploy y parecen estar muy contentos.
Continuous Improvement in PHP projects by Thorsten Rihnne
En esta charla en primer lugar se mostró cómo un código que se mejora constantemente funciona mucho mejor, demostrando además como técnicas ágiles y la integración continua van de la mano. Tras mostrar estos conceptos muy relacionados principalmente con scrum, se mostraron una serie de herramientas desarrolladas en su empresa (o mejoradas) que ayudan a la hora de controlar un proyecto e intentar que mejore.
Las aplicaciones que se mostraron fueron:
PHP Team organisation by Damien Seguy
De manos del genial Damien Seguy asistimos a una charla sobre cómo realizar gestión de equipos, mejorar su implicación y como gestionar impedimentos. Fueron muchos los consejos, pero podemos resumirla en la siguiente lista que se explica por sí sola:
- Weekly meeting
- Discussion of future stuff
- Specific training on tools, methods
- Read indicators (audits, PI, ec)
- Review reference documents
- One question each (helps prepare for the meeting
- Name domain gurus
- Create domain experts
- Specific domain
- Unit test, IHM, database
- Willing team member
- Name it after he has taken the responsability
- Healthy competition
- Number of unit tests
- Lines of codes
- Number of methods
- Number of commits
- …
- Learn to say no
- 5 minutes meeting daily
- Short cycles
- References
- PHP Mantra: short version of conventions
- Evangelize
- Name your teams/projects
- Tag your code
- Cross audits