Con dos meses de retraso, ahí va la segunda parte de esta retrospectiva.

Siento que éste artículo no tenga la calidad habitual, pero añadir enlaces es lo que más tiempo me consume y… sinceramente, tengo muchos proyectos en la cabeza y poco tiempo. Algunos de ellos tienen que ver con la web y con artículos :)

Más charlas

Ticketea

Miquel e Iñaki nos contaron algunas cosas de esta empresa, que comenzó con 4 personas, y han crecido hasta 12.

Utilizan AWS y solían utilizar .Net, aunque cambiaron a PHP con Yii y posteriormente a PHP con un framework propio.

Tienen proyectos como “Odín”, de Business Intelligence, con lo que explotan PDFs, que están hechos en Django. Han tenido problemas con el modelo de Admin.User, por lo que han tenido que parchearlo. Además, el backend de sesiones es propio, gestionado con Memcached.

Utilizan pylongtables, que es una mezcla de LaTeX y Jinja, y “forseti” como herramienta de despliegue.

Migraron de Nginx + gunicorn + supervisor a Nginx + Chaussette + Circus, ya que Circus permite mantener el socket y evita perder peticiones.

De Django no aprovechan los models de contrib.auth, model forms, o db, pero sí templates, sessions y CVBs. Para gestionar la configuración utilizan django-configurations.

Utilizan muchos mixins, wrappers de los generics de Django. Extienden de FormView para mejorar la gestión de errores de forms, así como tener gestión automática de los mismos mediante django-crispy-forms.

Otra herramienta es “Heracles”, que consiste en una cola de ejecución de tareas en segundo plano.

Para ello cuentan con una API en PHP que encola tareas en un RabbitMQ y se procesan con Celery. Se han creado una BaseTask que permite reintentos. Reciben alertas si la tasa de fallos es muy alta.

Por su experiencia, no es buena idea utilizar una configuración Activo/Activo en RabbitMQ con AWS, y lo tienen configurado como Activo/Pasivo.

También nos hablaron de “Thor”, otra de sus herramientas que permite independizar el resto de servicios, actuando como sistema de validación.

Tiene una estructura similar al anterior, con una API en PHP, RabbitMQ y Celery., aunque sólo usan RabbitMQ cuando su caché “Thor DEBLs (Domain Business Logic)” falla.

Más importante que un Equipo A es tener un Plan B.

Para monitorizar y loggear utilizan sentry + graphite + graphana + rsyslog + logstash + cabot, usando un transaction ID que pueden seguir. Así mismo, tienen distintos niveles de autoescalado.

La parte monetaria es la única que siempre es transaccional y síncrona.

Buildout

Aitzol Naberan nos habló de cómo usan Buildout en CodeSyntax como herramienta de creación y despliegue, y un poco de la historia de Zope.

CodeSyntax es una empresa que se creó en 2001 y comenzó usando Zope. Las versiones 2.5 y 2.6 sólo permitían un despligue manual, y cuando les cierran el CPD y tienen que realizar una migración manual, buscan urgentemente una manera de automatizarlo para la próxima vez.

En las versions 2.7, 2.8 y 2.9 basta con hacer:

.7configure && make && make install

En estas versiones también aparece el concepto de Zope Instance.

Aparece Plone 2.1, cuya instalación es un tgz. La versión 3.1, ya con Zope 3, comienza a usar small reusable components.

CodeSyntax necesitaba desplegar 150 componentes en Plone 3.0; 250 en Plone 4.0. Sin embargo, bastaban 2-3 comandos y era reproducible.

Utilizan un fichero de configuración tipo INI (buildout.cfg). Cada parte ejecuta una receta. Las versiones las mantienen fijas en el archivo. Usan una extensión de buildout que permite modificar versiones para desarrollo.

Clases en Python: Lo estás haciendo mal

Victor Terrón nos contó cosas muy interesantes de python 3, como por qué heredamos de object: permite distinguir entre clases de python 2 y clases de python 3. En Python 3… no es necesario, ya que todas heredan de object de forma implícita.

Algo así ocurre con super, que en Python 3 no require argumentos y los toma de forma implícita.

Nos contó qué es el MRO, que es el diagrama de clases pero aplanado. En definitiva, es el encargado de resolver la herencia múltiple.

Una buena práctica es usar self en lugar del nombre de la clase para referirse a las constantes. De esta manera no es necesario tocar más que el nombre si la clase se renombra.

Pero… ¿Por qué todos los métodos tienen que recibir self de forma implícita? Pues porque de esta manera se puede invocar la clase pasándole el objeto como primer argumento, es decir: se puede usar cualquier método como un método estático:

object.method()
# is the same than
class.method(object)

Además permite añadir métodos al vuelo y utilizar decoradores.

Las variables de clase están compartidas por todas las instancias y son estáticas. Realmente no es necesario definirlas en __init__ y en la clase, ya que puede dar errores debido a typos.

Me gustó lo que dijo de que Python no tenga variables privadas: “We’re all consenting adults; Es como ir en el coche y agarrarse para ir más seguro”.

El Mangling que consiste en un mecanismo interno por el que el compilador nombra las variables con doble guión bajo (también llamado “dunder”) con el nombre de la clase para evitar colisiones en la herencia.

Es interesante diferenciar los métodos estáticos y de clase: @staticmethod no tiene argumentos relacionados con el objeto, mientras que @classmethos recibe la clase como primer argumento.

Nos contó el principio de acceso uniforme, por el cuál deberíamos usar properties para todos los métodos de acceso.

También le dio tiempo a comentar __init__ y __new__: al contrario de lo que pensamos habitualmente, el constructor es __new__, mientras que __init__ es el inicializador.

Lightning Talks

Miimetiq

Oriol Rius nos habló de Miimetiq, una empresa de menos de un año que se encuentra en Barcelona, Londres y Oxford.

Utilizan AMQP como protocolo de comunicaciones entre sensores, embedded devices, productos, sensores, …

Luke, yo soy tu padre

Eduardo Ferro, de Alea Soluciones, nos habló de Herencia y Composición.

La herencia fuerza a tener dependencia de fuentes, dependencia de runtime y de los ancestros, lo que implica una dependencia muy alta.

La composición, sin embargo, sólo tiene dependencia de runtime y los métodos usados, por lo que es mucho menor.

Así que deberíamos usar la composición por defecto, salvo para excepciones que es mejor la herencia. En cualquier caso, permitir usar la composición, evitando forzar la herencia.

Django Oscar

Eyad Toma nos habló de este framework poco conocido.

Pros:

• muchas características
• personalizable
• classband views
• templates subclassing

Contras:

• Malos ejemplos
• comunidad pequeña
• Personalizar es duro

iMathCloud

Íñigo Zubizarreta nos mostró la evolución de este producto, que permite trabajos matemáticos colaborativos. Es una especie de ipython online para matemáticos.

Está implementado con MPI con una librería propia, y usa Colossus y Colossus FS.

Problema C10K, la nube y la supercomputación

Guillermo Borrel nos contó que la arquitectura cliente-servidor no funciona en supercomputación. Hay que pensar a lo grande.

Nos recordó que paralelo no es lo mismo que concurrente. Por eso ellos utilizan paralelización por mensajes.

Usan tecnologías como MPI, RabbitMQ, Gevent, Twisted, 0MQ, Accelio, nanomsg, websockedd.

En supercomputación lo primero es hacerlo paralelo, y luego escalable.

Nos recordó la ley de Ambdall: Aquello que va peor es lo que limita tu velocidad. Es decir: Hay que optimizar lo que es más lento.

La métrica más utilizada en supercomputación es la desviación estándar de la latencia. Habitualmente, escribir en disco suele ser el problema ya que genera latencia.

Los centros de datos de supercomputación llevan años usando BBDDs de tipo clave valor, con estructura de caché -> índices/métodos -> Datos. Utilizan URLs como índices.

Ley de Conway: Si hay 5 desarrolladores, habrá 4 módulos y 1 jefe.

En supercomputación es importante buscar la homogeneidad. Y óptimo significa que ahorra dinero.

Travisify

Mi charla XD

Creo que no fue muy divertida, la verdad. No sé si era lo que la gente esperaba escuchar, aunque las preguntas fueron bastante interesantes.

Conclusión

Lo peor de todo fue el edificio. Aunque se encuentra en muy buena ubicación, con 3 hoteles cerca y a 5 minutos de la estación de trenes y autobuses, el arquitecto se lució con él. Para encontrar las salas han tenido que pintar líneas en el suelo y evitar así que nos perdamos. Entre el Auditorio y las salas podía haber, fácil 5 minutos a paso normal, lo que hacía que te planteases el cambio de sala. Además, había una puerta atrás que nadie vigilaba, aunque era poco probable que alguien viniera por allí. En general, casi todo el espacio estaba destinado a poner pasillos y escaleras.

El reparto de charlas no estuvo muy acertado, ya que coincidían charlas similares, lo que provocaba que fuera difícil evitarlas y que si te interesaba el tema pudieras ir a ambas. En una ocasión nos cambiamos de sala ya que estábamos casi todos en la sala pequeña y el auditorio estaba casi vacío.

Los chicos de la organización estuvieron muy amables en todo momento, velando porque todo saliera lo mejor posible.

Alguien del trabajo me dijo que lo normal en los congresos es que sólo el 50% de las charlas fueran interesantes. Por ello he ido evaluando cada una de ellas con un +1 si son interesantes, 0 si no lo son y -1 si me han hecho perder el tiempo. Por lo tanto, un resultado positivo implica éxito. En este caso el resultado es de 6/13, lo que significa que ha sido una experiencia muy enriquecedora.

Sin lugar a dudas, vuelvo con ganas de investigar no pocos frentes. Hay mucho que procesar ahora :D