Canonical Voices

Posts tagged with 'python'

Gavin Panella

Preparing for Python 3 in MAAS

Something we've done in MAAS — which is Python 2 only so far — is to put:

from __future__ import (
absolute_import,
print_function,
unicode_literals,
)

__metaclass__ = type

str = None

at the top of every source file. We knew that we would port MAAS to Python 3 at some point, and we hoped that doing this would help that effort. We'll find out if that's the case soon enough: one of our goals for this cycle is to port MAAS to Python 3.

The str = None line forces us to use the bytes synonym, and thus think more about what we're actually doing, but it doesn't save us from implicit conversions.

In places like data ingress and egress points we also assert unicode or byte strings, as appropriate, to try and catch ourselves slipping up. We also encode and decode at these points, with the goal of using only unicode strings internally for textual data.

We never coerce between unicode and byte strings either, because that involves implicit recoding; we always encode or decode explicitly.

In maas-test — which is a newer and smaller codebase than MAAS — we drop the str = None line, but use tox to test on both Python 2.7 and 3.3. Unfortunately we've recently had to use a Python-2-only dependency and have had to disable 3.3 tests until it's ported.

maas-test started the same as maas: a Python 2 codebase with the same prologue in every source file. It's anecdotal, but it turned out that few changes were needed to get it working with Python 3.3, and I think that's in part because of the hoops we forced ourselves to jump through. We used six to bridge some gaps (text_type in a few places, PY3 in setup.py too), but nothing invasive. My fingers are crossed that this experience is repeated with MAAS.

Read more
facundo


Hola!!

Charlando en el viaje a/desde la PyCon de Rosario, surgió la idea de armar un Circo Errante (flying circus, la referencia es obvia) con el objetivo de acercar PyAr a las Universidades de una forma distinta a las actuales.

Hoy por hoy, el principal contacto de PyAr con las Universidades es de gente que arma PyDays en ese ámbito. Esto, normalmente, sucede en las Universidades con carreras afines a la programación. Y el contenido y dinámica de estos PyDays están pensados en función de ese público.

La idea es cambiar eso. Y llegar desde PyAr a Universidades con las cuales normalmente no tenemos mucho contacto. Ejemplo de esto son las carreras de derecho, sociología, matemática, psicología, astronomía, ingenierías no informáticas, etc. Estas son carreras en las que los profesionales podrían hacer un buen uso de Python como herramienta, donde no les interesa tanto  el razonamiento "quiero hacer un programa que haga algo", sino más bien "necesito hacer algo y un programa podría ser una herramienta, aparte del excel y la calculadora que es lo que estoy usando ahora".

Más en detalle, lo que se nos ocurrió es armar una especie de presentación basada en ejemplos de distintas especialidades. O sea, cómo usar Python para solucionar tal problema en astronomía, cómo usarlo para encontrar tal resultado en sociología, o cómo aprovecharlo para mejorar un análisis en ingeniería en alimentos. Una presentación semigenérica, de 30-40 minutos, que sea como la punta de lanza: si les gusta la idea luego se puede mostrar Python más formalmente; en el peor de los casos se quedarán sólo con conocer la herramienta y tener idea de qué se trata, que no está tan mal.  Obviamente, la idea es armar una presentación que todos podamos usar, no que cada uno arme la suya.

Para organizar esto, armé una página en el wiki con (por ahora) tres secciones: una de ejemplos, para ir juntando ejemplos piolas en los cuales basar la presentación, una de ideas para folletería/merchandising (ver más abajo) y otra de gente interesada en dar estas charlas y la "zona de cobertura".

Luego, habría que ir buscando contactos en las Universidades, para poder charlar con alguien que nos dé un aula con un proyector y que organice internamente para que vaya gente a la presentación.

Con respecto a la folletería/merchandising, tenemos que pensar en algo para llevar a estas reuniones: algo que les muestre el uso de la herramienta más allá del lenguaje (ejemplo: no mostrar como se escribe un for, sino lo fácil que es hacer una normalización de un conjunto de datos). Algo que se lleven los asistentes con ellos, para poder verlo más tarde, y tener el contacto con PyAr para poder venir por más info.

¿Qué les parece?

Read more
facundo


Aparecieron muy cerca en el tiempo dos necesidades muy parecidas: hacer certificados de asistencia para PyCon Argentina 2013, y hacer los certificados para mi curso de Python.

Así nació certg, un generador de certificados, que a la vez es simple, versátil, y útil. El proceso para usarlo es simple:

  1. Armás un .SVG (con Inkscape, por ejemplo), poniendole todo el arte que quieras para que el certificado quede lindo. Pero no lo hacés específico a nadie, sino que dejás escrito variables que se van a reemplazar, como {{nombre}} o {{direccion}} o lo que te guste
  2. Armás un archivo de configuración, donde ponés el nombre del .SVG que creaste, qué variable de las que elegiste es única (se usa luego), y luego una lista de grupos de variables, donde a partir de cada grupo se va a generar un certificado.
  3. Ejecutás el programita en Python, pasándole la configuración que armaste. El programita va a leer el .SVG, y por cada grupo en la config, reemplazar esos valores, y generar un certificado (en PDF) usando el nombre unívoco que indicaste.

La verdad, quedó piola: no es dificil de usar, y es lo suficientemente flexible para las distintas necesidades que tuve. Este es como quedó mi certificado de la PyCon:

Fuí a la PyCon!
El proyecto, con ejemplos y todo, acá.

Read more
facundo

PyCon Argentina 2013


Salimos el miércoles tarde (porque yo tenía el curso de Python en el centro), en auto, Julia, Marcos y yo. Llegamos a Rosario, al hostel, a la una y cuarto de la mañana, derechito a dormir. Esperábamos no molestar a Mariano y Claudio, con los que compartíamos habitación, y efectivamente fue así porque ellos todavía no se habían acostado :p.

Al otro día nos levantamos bien tempranito, porque yo tenía que llevar los tutoriales y posavasos para que se repartieran cuando la gente se registraba al evento. Llegamos con tiempo, tanto que luego de entregar los materiales, saludar y etc, nos quedamos tomando mate y desayunando a la vera del rio, durante como media hora...

Y finalmente arrancó la conferencia.  El primer bloque de charlas me gustó entero, y mucho, lo cual hace rato que no me pasaba en una PyCon. Fuí primero a "Recorriendo Nodos con Python" (de Martín Alderete y alguien más que el sitio de PyCon no me deja ver quién es :( ), después a "Aprendizaje automático con scikit-learn" (de Rafa Carrascosa), y finalmente a "Monitoreo de procesos industriales utilizando Python" (de Joac).

Después salimos a almorzar, lo cual es siempre una aventura en este tipo de eventos (imagínense centenares de personas atacando de repente los locales cercanos). Pero teníamos una hora y media, así que no hubo mayor inconveniente que la quemazón generalizada de caras y brazos porque el sol estaba fuerte y nadie se avivó :/.

A la tarde ví una charla que no me gustó tanto, y luego dí Bindings, default mutable arguments, y otros qu... detalles. Luego de eso, algo de pasillo, las lightning talks (bien en general), y luego la plenaria.

La charla plenaria la dió Robert Lefkowitz, sobre "Literacy, Programming, and Open Source", una de las mejores plenarias que vi en la vida. Estuvo genial, sinceramente, tengo ganas de que suban el video a algún lado y agregarle subtítulos en castellano, para que la pueda disfrutar más gente.

Robert, al final de la charla, hizo una invitación general a ir a tomar algo. Pero Emiliano tenía pre-armado unos pescados a la parrilla, así que subimos la apuesta y armamos (previa recolección de dinero) un asado para treinta y pico en un club cercano. Fue una corrida ir a la carnicería, al supermercado por bebidas, pan y etcéteras, y por la casa de Emi para buscar algunos elementos generales, mientras Juan Pablo y Marcos arrancaban con el fuego en el club. Al final se asaron un dorado y un sábalo enormes ambos, más dos bondiolas de cerdo y un pedazote de bife de chorizo. Todo regado con fernet, cerveza, vino, y mucha, mucha charla copada.

La foto grupal

El viernes nos levantamos tarde, tanto que desayunamos en el hostel, y llegamos a la conferencia un rato antes que diera mi segunda charla, Las perlas de Python 3 (¡un estreno!). Luego estuve en un par de charlas, pero la que más me gustó fue la de Alecu, "Juegos electromecánicos con Arduino", tengo muchas ganas de arrancar con algún proyecto de electrónica o electromecánica!

Al final del día vinieron más lightning talks, y la plenaria de Claudo Freire sobre Paralelismo. Luego sorteos, palabras, saludos, y todos los etcéteras del cierre de la conferencia.

Esa noche era la cena "de invitados", donde volvimos a repetir asado (pero esta vez en un restaurant muy bonito), y luego varios nos fuimos a reventar la noche (not really) a una fiesta del CEC.

En fin, pasó otra PyCon Argentina, la cual me gustó mucho mucho. Felicitaciones a todos los que trabajaron para que salga tan lindo todo!  Yo no llevé cámara, pero hay muchas fotos acá, acá, y acá.

Read more
facundo


Porque PyAr no descansa, acabamos de tener la PyCon y ya salimos con el armado del PyCamp del año que viene. Este es un llamado a co-organizadores, locales (o cercanos) a sitios posibles de hacerse el evento.

La idea es hacer el PyCamp del 1 al 4 de Marzo, del 21 al 24 de Marzo, o del 22 al 25 de Marzo.

Yo lo voy a estar coordinando en general, pero la idea es que encontremos el mejor venue posible, buscando de a varios. Es lo mismo que hicimos el año pasado.

¿Cómo es la dinámica? si alguien sabe de un lugar en el que se podría hacer el PyCamp, que vaya o llame y averigüe. Hay que recabar varios datos:

  • Formas de llegar
  • Qué onda el lugar
  • Qué onda las habitaciones
  • Qué onda la comida
  • Tres puntos a favor
  • Tres puntos en contra
  • Disponibilidad
  • Precio

Algo piola para revisar es la página que les acabo de pasar sobre posibles sedes, para tener una idea del tipo de data que hay que juntar. Luego me contactan (por privado) y vamos definiendo todo para dejar el lugar listo para la votación.

¡Gracias! :)

Read more
Jussi Pakkanen

With the release of C++11 something quite extraordinary has happened. Its focus on usable libraries, value types and other niceties has turned C++, conceptually, into a scripting language.

This seems like a weird statement to make, so let’s define exactly what we mean by that. Scripting languages differ from classical compiled languages such as C in the following ways:

  • no need to manually manage memory
  • expressive syntax, complex functionality can be implemented in just a couple of lines of code
  • powerful string manipulation functions
  • large standard library

As of C++11 all these hold true for C++. Let’s examine this with a simple example. Suppose we want to write a program that reads all lines from a file and writes them in a different file in sorted order. This is classical scripting language territory. In C++11 this code would look something like the following (ignoring error cases such as missing input arguments).

#include<string>
#include<vector>
#include<algorithm>
#include<fstream>

using namespace std;

int main(int argc, char **argv) {
  ifstream ifile(argv[1]);
  ofstream ofile(argv[2]);
  string line;
  vector<string> data;
  while(getline(ifile, line)) {
    data.push_back(line);
  }
  sort(data.begin(), data.end());
  for(const auto &i : data) {
    ofile << i << std::endl;
  }
  return 0;
}

That is some tightly packed code. Ignoring include boilerplate and the like leaves us with roughly ten lines of code. If you were to do this with plain C using only its standard library merely implementing getline functionality reliably would take more lines of code. Not to mention it would be tricky to get right.

Other benefits include:

  • every single line of code is clear, understandable and expressive
  • memory leaks can not happen, could be reworked into a library function easily
  • smaller memory footprint due to not needing a VM
  • compile time with -O3 is roughly the same as Python VM startup and has to be done only once
  • faster than any non-JITted scripting language

Now, obviously, this won’t mean that scripting languages will disappear any time soon (you can have my Python when you pry it from my cold, dead hands). What it does do is indicate that C++ is quite usable in fields one traditionally has not expected it to be.

Read more
facundo

Curso de Python confirmado


Estoy muy contento porque el primer Curso Abierto de Python que armé ya está 100% confirmado, :).

El curso es de 18 horas en total, de 19 a 22, los días Miércoles 25 de Septiembre, 2 y 9 de Octubre, saltamos un miércoles, 23 y 30 de Octubre y 6 de Noviembre.

Quedan sólo un par de plazas disponibles, si quieren anotarse tienen todos los datos en la paginita que armé. Una novedad es que ahora también se puede pagar por DineroMail: no me conviene demasiado, pero permite pagar con tarjeta de crédito, RapiPago, PagoFácil, etc., así que supongo que podría ser cómodo para alguien en algunos casos...

Read more
facundo

PyDay en Junín 2013


Este fin de semana se sucedió otro evento en Junín. Organizado por Juan Rodriguez Monti, con la colaboración de varios de los chicos de siempre, y con el apoyo indiscutible de la facultad, armaron otro PyDay que salió muy muy bien.

No estuve en todas las charlas, pero fui a varias; las que más me gustaron fueron la de Alecu "Controlando Python desde Arduino", la de Juanjo Ciarlante "Software Libre en las nubes", y la de Daniel Coletti "Ser emprendedor con Software Libre".

Alecu en su charla

Yo dí una charla nueva, "Emulando paralelismo de forma asincrónica", una charla bastante complicada pero que salió bastante bien. Eso sí, tardé una hora en darla, así que le tengo que pegar una revisada para ajustarla y simplificarla un poco.

Además, fueeeeeeeera de programa, dí un tallercito de "Introducción a Python" el día anterior en la Universidad, pero la asistencia fue muy baja, :(. Por otro lado, estuve jugando un poco al tenis el domingo a la mañana, así que eso compensó, :D.

En fin. Ir a los eventos de Junín siempre está bueno, y los disfruto bastante.

Read more
facundo


Finalmente me decidí, y armé un curso grupal para aquellos que quieren aprender Python, no como parte de un grupo cerrado para una empresa o institución, sino abierto al público en general.

Será un Curso Introductorio a Python, apuntado a aquellos que no saben nada de este lenguaje, o saben algo pero quieren profundizar o formalizar conocimientos.

El nivel es introductorio, lo que significa que se van a ver muchos conceptos del lenguaje de manera profunda, pero no se tocarán temas avanzados ni satélites a lo que es Python en sí, con la intención que el asistente gane sólidos conocimientos que luego le permitan explorar el resto a su gusto.  Se necesita tener conocimientos previos de programación (pero no hace falta ser un programador avanzado).  En detalle, el contenido del curso versará sobre los siguientes ítems:

  • Introducción: ¿Qué es Python?; Primeros pasos; Recursos
  • Tipos de Datos: Haciendo números, y más números; Cadenas de texto; Tuplas y listas; Conjuntos; Diccionarios
  • Controles de flujo: if/elif/else; loops while y for; Excepciones
  • Encapsulando código: Funciones; Clases; Módulos; Espacios de nombres
  • Otros temas: Archivos; Trabajando en Red; Conexión con Bases de Datos

El formato del curso será presencial, en un ambiente "tipo aula" con pizarrón y proyector, pero no basado en filminas, sino totalmente dinámico y adaptativo.  Se hace un foco especial en la interacción profesor-asistente, de forma de ir resolviendo las dudas de todos y lograr un aprendizaje más profundo en el mismo tiempo.  En función de esto también se limita el cupo, con una cantidad máxima de asistentes de alrededor de diez personas.

Como parte del curso se entregará un certificado de asistencia al mismo, basado en una evaluación sobre un proyecto personal o grupal, totalmente a decisión de el/la/los/las participante(s).  Este proyecto se arranca durante el curso, pero puede continuar después del mismo, bajo mi supervisión/tutoría (sin costo extra).  También se entregará documentación de forma digital.  No se necesita asistir al curso con computadoras, pero pueden traer laptops/netbooks si lo desean (van a disponer de conexión a internet via wifi y conexión eléctrica).

El curso es de 18 horas en total (tres horas por clase, un día a la semana, seis semanas), de 19 a 22.  En esta primera oportunidad se hará el curso en un lugar céntrico de la Ciudad de Buenos Aires, los días Miércoles 25 de Septiembre, 2 y 9 de Octubre, saltamos un miércoles, 23 y 30 de Octubre y 6 de Noviembre.

El costo total del curso será de $920; es necesario abonar al menos el 50% para reservar la posición (recuerden que, como indicaba arriba, hay un máximo de lugares disponibles), abonando el saldo restante el primer día de clases.  El curso comienza con un cupo mínimo de 4 alumnos, a confirmar como máximo los primeros días de Septiembre. En el caso de no formarse el grupo, se postergará el inicio o se reintegrará el dinero completo de la seña.

Para reservar, entonces, deberán depositar o transferir el dinero a mi cuenta del banco, para lo cual coordinamos por mail. Si se les complica esta manera de pago, lo charlamos.

Bueno, creo que cubrí la mayoría de los puntos.  Si tienen alguna duda, pueden preguntar por acá, o en privado al mail, sin ningún problema.

Read more
facundo


Bueno, todos los saben, porque no sólo tenemos una página de los proyectos que íbamos a encarar, sino que también armamos un video el último día con todo lo que se hizo durante el PyCamp!




Para completar el ciclo, pueden ver fotos del evento acá, acá, acá y acá.

Read more
pitti

While GNOME as a whole does not have a planned 3.8.3 release, I got some requests to do a new stable release of PyGObject with some important bug fixes, so here it is: version 3.8.3. Thanks to all contributors!

  • Add marshalling of GI_TYPE_TAG_VOID held in a GValue to int. While not particularly useful this allows some callbacks in WebKit to function without causing a segfault. (Simon Feltman) (#694233)
  • pygtkcompat: Fix for missing methods on Windows (Martin Pitt) (#702787)
  • gi/pygi-info.c: Avoid C99-style variable declaration (Chun-wei Fan) (#702786)
  • Clear return value of closures to zero when an exception occures (Simon Feltman) (#702552)
  • Re-add support for passing GValue’s by reference (Simon Feltman) (#701058)
  • Don’t use doctest syntax in docstrings for examples, to fix test failures with pyflakes 0.7.x (Martin Pitt) (#701009)
  • examples/option.py: Port to GI and Python 3 (Martin Pitt)

Read more
niemeyer

In an effort to polish the recently released draft of the strepr v1 specification, I’ve spent the last couple of days in a Go reference implementation.

The implemented algorithm is relatively simple, efficient, and consumes a conservative amount of memory. The aspect of it that deserved the most attention is the efficient encoding of a float number when it carries an integer value, as covered before. The provided tests are a useful reference as well.

The API offered by the implemented package is minimal, and matches existing conventions. For example, this simple snippet will generate a hash for the stable representation of the provided value:

value := map[string]interface{}{"a": 1, "b": []int{2, 3}}
hash := sha1.New()
strepr.NewEncoder(hash).Encode(value)
fmt.Printf("%x\n", hash.Sum(nil))
// Outputs: 29a77d09441528e02a27dc498d0a757da06250a0

Along with the reference implementation comes a simple command line tool to play with the concept. It allows easily arriving at the same result obtained above by processing a JSON value instead:

$ echo '{"a": 1.0, "b": [2, 3]}' | ./strepr -in-json -out-sha1
29a77d09441528e02a27dc498d0a757da06250a0

Or YAML:

$ cat | ./strepr -in-yaml -out-sha1                 
a: 1
b:
   - 2
   - 3
29a77d09441528e02a27dc498d0a757da06250a0

Or even BSON, the binary format used by MongoDB:

$ bsondump dump.bson
{ "a" : 1, "b" : [ 2, 3 ] }
1 objects found
$ cat dump.bson | ./strepr -in-bson -out-sha1
29a77d09441528e02a27dc498d0a757da06250a0

In all of those cases the hash obtained is the same, despite the fact that the processed values were typed differently in some occasions. For example, due to its Javascript background, some JSON libraries may unmarshal numbers as binary floating point values, while others distinguish the value based on the formatting used. The strepr algorithm flattens out that distinction so that different platforms can easily agree on a common result.

To visualize (or debug) the stable representation defined by strepr, the reference implementation has a debug dump facility which is also exposed in the command line tool:

$ echo '{"a": 1.0, "b": [2, 3]}' | ./strepr -in-json -out-debug
map with 2 pairs (0x6d02):
   string of 1 byte (0x7301) "a" (0x61)
    => uint 1 (0x7001)
   string of 1 byte (0x7301) "b" (0x62)
    => list with 2 items (0x6c02):
          - uint 2 (0x7002)
          - uint 3 (0x7003)

Assuming a Go compiler and the go tool are available, the command line strepr tool may be installed with:

$ go get launchpad.net/strepr/cmd/strepr

As a result of the reference implementation work, a few clarifications and improvements were made to the specification:

  • Enforce the use of UTF-8 for Unicode strings and explain why normalization is being left out.
  • Enforce a single NaN representation for floats.
  • Explain that map key uniqueness refers to the representation.
  • Don’t claim the specification is easy to implement; floats require attention.
  • Mention reference implementation.

Read more
facundo

Enjuewemela modo PyAr


No es la primera vez que les comento algo sobre Enjuewemela, mi jueguito similar a los populares Bejeweled o Diamond Mine, que se basa en alinear 3 o más gemas, tanto verticalmente como horizontalmente, intercambiando gemas adyacentes.

Pero quizás este post sea el último que hago sobre el juego. Y es que me aburrí de pulirle detalles, tratar de hacerlo lindo, jugable, divertido... son cosas que llevan mucho tiempo, no tan evidentes al usarlo... y nada, me aburrió.

Para "despedirme", le implementé algo que tenía en mente hace rato y que quería que esté: un "modo Python Argentina", donde en vez de las piezas usuales, hay personajes de juegos hechos por el grupo.

Enjuewemela modo PyAr

Lo consiguen en el lugar de siempre :)

Read more
niemeyer

Here is a small programming brain teaser for the weekend:

Assume uf is an unsigned integer with 64 bits that holds the IEEE-754 representation for a binary floating point number of that size.

The questions are:

1. How to tell if uf represents an integer number?

2. How to serialize the absolute value of such an integer number in the minimum number of bytes possible, using big-endian ordering and the 8th bit as a continuation flag? For example, float64(1<<70 + 3<<21) serializes as:

"\x81\x80\x80\x80\x80\x80\x80\x83\x80\x80\x00"

The background for this problem is that the current draft of the strepr specification mentions that serialization. Some languages, such as Python and Ruby, implement transparent arbitrary precision integers, and that makes implementing the specification easier.

For example, here is a simple Python interactive session that arrives at the result provided above exploring the native integer representation.

>>> f = float((1<<70) + (3<<21))
>>> v = int(f)
>>> l = [v&0x7f]
>>> v >>= 7
>>> while v > 0:
...     l.append(0x80 | (v&0x7f))
...     v >>= 7
... 
>>> l.reverse()
>>> "".join("%02x" % i for i in l)
'8180808080808083808000'

Python makes the procedure simpler because it is internally converting the float into an integer of appropriate precision via standard C functions, and then offering bit operations on the resulting value.

The suggested brain teaser can be efficiently solved using just the IEEE-754 representation, though, and it’s relatively easy because the problem is being constrained to the integer space.

A link to an implementation will be provided next week.

UPDATE: The logic is now available as part of the reference implementation of strepr.

Read more
facundo

PyCamp 2013


El viaje

Moni me dejó en Retiro a eso de las 20:35, cerquita de las 20:45 que era la hora que tenía mi micro. No sabía si viajaba con alguien, pero me encontré con Ricardo Kirkner en la terminal, que viajaba en mi mismo micro. También nos cruzamos a Felipe Lerena, pero tenía otro viaje, y supimos que estaba más gente por ahí que iba a Villa Giardino al PyCamp, pero no nos las cruzamos.

Yo tenía un boleto electrónico (había comprado los pasajes por internet e impreso un PDF que te dan), y no estaba seguro que eso sirviera para subirme directamente al micro, así que pregunté por ventanilla que onda. Me enteré que con eso era suficiente, y también que el micro venía con retraso. Bueno a esperar.

Esperamos, esperamos, y esperamos. Al final, llegó el momento de subirnos al micro, con dos horas de demora, :(. En fin, ya estábamos arriba y moviéndonos, era cuestión sólo de llegar, ¿no? No.

A eso de medianoche me despierto y veo que el micro está en la terminal de Campana. Pasa un rato, y el bondi no se movía. Tenía el motor prendido, pero no nos íbamos nunca. Veinte minutos después, nada. Bajo a preguntar (la mayoría de la gente dornmía), y el chofer me dice que el micro estaba roto (luego me enteré que "no aceleraba"), que estábamos esperando un reemplazo. Uff.

Como media hora después llega otro micro, el chofer nos dice que nos cambiemos de coche, la gente se despierta, nos movemos, etc. Arranca el nuevo vehículo y abandonamos Campana. Ahora sí el viaje arrancaba, y era sólo cuestión de llegar, ¿no? No.

Ya de día, y saliendo de Córdoba Capital, me parece que el micro va sospechosamente lento por la ruta. Antes de llegar al primer peaje, se tira a un costado y viene el chofer y dice que el micro estaba roto (en esta oportunidad: se había roto la manguera del hidráulico que movía el ventilador del radiador, y el motor calentaba demasiado).

Not angry

La gente re molesta, se baja del micro, unas señoras llamaron a un remis para volver a Córdoba y ahí tomar otro micro de corta distancia, otros sólo protestaban, nadie sabía mucho qué hacer. Yo quería llegar pronto a Villa Giardino para no perderme mucho PyCamp, así que no quería esperar indefinidamente hasta que viniera otro micro.

Charlando, me doy cuenta que una pareja de chicos iban hasta La Falda, que queda muy cerquita de Villa Giardino, y les digo: ¿por qué no nos tomamos los cuatro un remis? Yo tenía en los contactos el número de un remis de córdoba, llamé, me dijeron que el viaje salía alrededor de $300, y le dije que se viniera.

Un rato después nos pasó a buscar el auto, nos subimos los cuatro, y ahí si ya pudimos hacer el último trecho que nos separaba de PyCamp. Llegamos quince minutos antes del almuerzo, con cinco horas de retraso del plan original. Pero llegamos.

Y en la vida me vuelvo a tomar un micro de Mercobus/PlusUltra.


El resto del Jueves

Al llegar fueron todos saludos, presentaciones con varias personas a las que no conocía personalmente, el almuerzo, más saludos y presentaciones, y el arranque con el PyCamp propiamente dicho.

Schedule

Esa tarde laburé con TOMy, un cliente lindo y útil de consola para conectarse a muchas bases de datos (MySQL, Postgresql, etc), mejorando por mucho los clientes que trae cada motor. Le refactoreé un par de cosas a la hora de importar unos plugins, aunque lo que quería realmente hacer era otra cosa (que finalmente pude hacer luego, ver abajo).

No pude seguir con TOMy porque llegó la hora asignada de empezar con LocoLander, un proyecto idea mía. Se armó un grupito, pero la verdad los que siguieron prendidos al proyecto (durante una buena parte del resto del PyCamp, y que trabajaron mucho mucho) fueron Ricardo, Nati Bidart, y Matías Bordese. Yo hice un par de cosas, charlé mucho del diseño, pero no estuve echando tanto código con esto.

Lo groso es que se logró muchísimo. Pueden ver acá el código, ya con mucho hecho de la interfaz de registro de proyectos y de seguimiento del proceso, así como también toda la infraestructura para armar imágenes de distintos linuxes y configurarlos con las dependencias necesarias para correr los tests necesarios sobre los branches de los proyectos registrados.

Luego de la cena, y para cerrar el día, jugamos una partida de Belfort, un juego muy muy divertido que tiene Alecu. Los jugamos de a tres parejas: él y Matías, Nati y yo, y Elvio y Gisele, una pareja que yo no conocía hasta el PyCamp. Estuvo muy bueno, y con Nati lo ganamos en una serie de movimientos maestros cerca del final, sorprendiendo incluso a Alecu porque logramos el máximo de puntos del juego.


Segundo día, el viernes

Este fue el último día que me levanté temprano, con bastante frio porque el radiador de la pieza no andaba!. Desayuné y luego me puse cerca del gran Hugo Ruscitti que le contó a mucha gente sobre Pilas y su proyecto para que los chicos en las escuelas aprendan a programar usando el editor web. Yo ya había charlado mucho con Hugo sobre esto, así qu eno participé demasiado, pero estaba con la oreja parada mientras seguía laburando un poquito en LocoLander y TOMy.

Y seguí con eso incluso después del almuerzo, hasta que llegó la hora de Kilink, el otro proyecto nuevo que llevaba al PyCamp. Se me juntaron varios chicos para arrancar... y cuando les quise mostrar como estaba lo que ya estaba, no andaba en mi máquina, :(.

Ahí me puse a ver por qué, tratar de configurarlo, pregunté, no lo pudimos hacer andar como estaba, y decidí cambiar el approach. Instalé Apache, lo empecé a configurar, y luego de varias chanchadas y cosas de apuro, hice que pudiera correr.

Ya a esa altura había perdido la mitad de la gente, pero los que quedaron les gustó mucho. Les mostré lo que había a nivel de código... y llegamos a la conclusión que era todo viejo y complicado, :/ (tener en cuenta que en este proyecto Nico César y yo laburamos algunas horas a las apuradas hace dos años!).

El problema estaba en tres niveles. Primero, la forma de servir los datos... usaba flup y con José Massón pasamos a usar Flask: mucho más fácil, directo, sacamos magia del medio, y hasta los tests quedaron más sencillos. Segundo, la interfaz a nivel de html/css/js... estaba todo mezclado, desordenado, y hasta yo había hecho la chanchada de meter algo de javascript en el template para poder renderizar el árbol de versiones directamente. Acá estuvieron trabajando muchísimo Miss Filly y Juan Carizza, por muchas, muchas horas. Y lo tercero a corregir, que todavía no se hizo, es reemplazar SQLObject por SAW, un wrapper a SQLAlchemy que hizo Emiliano Dalla Verde Marcozzi.

El hotel

No todo terminó ahí con Kilink, especialmente los dos días siguientes. Filly y Juan estuvieron trabajando bastante para tratar de reemplazar el javascript que arma el árbol, y aunque todavía no lo terminaron parece que estaría sirviendo D3 para esto. Y José implementó toda la API, para poder usar Kilink programáticamente, porque se necesitaba para que el editor web de Pilas pudiera usarlo para guardar los scripts que se escriben.

El jueves también lo cerramos con un juego: el Galaxy Trucker, que yo ya había jugado una vez en un PyDay en Córdoba, pero no me acordaba mucho. Igual, lo jugué bastante bien y gané por UN puntito, muy muy justo.


Sábado

Habiéndome acostado la noche anterior a las tres de la mañana, era obvio que no me iba a levantar demasiado temprano. Pero nueve y media ya estaba bañadito y listo para comenzar a trabajar.

Luego de un viajecito al pueblo a llevar al hospital a un chico que se sentía mal y comprar algunas cosas en el almacén para tener a la muchachada engordando mientras programaban, sí me puse a trabajar.

Seguí con Kilink y Locolander, hasta que se hizo hora de arrancar con la CDPedia. Habían dos cosas que quería empujar con respecto a este proyecto. El primer punto era que CDPedia pudiera correr en Android (para tenerla en teléfonos y tablets); Diego Mascialino y Manu Quiñones se pusieron con esto, pero se les complicó bastante porque el Python que corre en Android se ve que está un poco recortado, y justo en donde lo necesitábamos, :(. Tenemos que seguir explorando a ver qué opciones hay para hacerla andar.

El segundo punto era lograr un sistema de generación continua de CDPedias. O sea, un sistema que de forma autónoma vaya generando CDPedias en distintos lenguajes, uno atrás del otro, y que luego vuelva a arrancar con el primero, como para garantizar tener algo siempre más o menos actualizado. Con esto nos pusimos Emiliano, en la parte de montar un buildbot para que ejecute, supervise y muestre los resultados de la ejecución, y yo, para armar un único script que realice la cantidad de pasos manuales que se hacen hoy en día. ¡Y casi casi lo tenemos listo!

El cierre del día lo dió la reunión número 61 de PyAr, pegadita a la cena. Los dos temas principales de la reunión fueron las cosas buenas y malas del PyCamp actual, qué cosas deberíamos cambiar para la próxima, etc, y charlamos también sobre la próxima PyCon, qué hacía falta, etc. Claro, satélites a estos temas se tocaron muchos otros, por ejemplo la interacción entre los eventos y las empresas, o también una idea de Nico Echaniz de construir algo en Quintana para que pueda usarse por las distintas comunidades libres para ir a trabajar, hacer sprints, etc.

Reunión de PyAr

Cuando volvimos a buscar las cosas al salón era como la una de la mañana. Yo estaba listo para irme a dormir, pero salió la idea de jugar nuevamente al Belfort... en esta oportunidad jugamos individualmente Nati, Matías, Ricardo, Lucio, y yo. Sorprendentemente volví a ganar, por unos buenos tres puntos.


Último día

Obviamente, luego de haberme acostado a las cuatro y media, no iba a levantarme temprano. Pero no fue tan tarde, nueve y media me desperté solito, y a las diez ya estaba bañado y en el salón para trabajar.

Hice alguna que otra cosa, pero lo importante de la mañana fue la presentación que hicieron las distintas personas de todas las cosas que se hicieron durante los días del PyCamp. La verdad es que estuvo genial, ¡tantas cosas en tan poco tiempo! Se filmó un video, yo tengo que editarlo y sacarle los espacios muertos, así es más dinámico para ver. Luego se los paso.

Mientras almorzábamos surgió el tema de que en este PyCamp no habíamos ido a hacer ninguna actividad física grupal. Y así medio de golpe decidimos salir a pegar una vuelta. Avisé, la gente se enganchó, y finalmente cambiamos una "reunión para charlar de cómo ayudar a organizar PyCon" por una "caminata para charlar de...". No fuimos demasiado lejos: caminamos hasta un dique cercano, nos quedamos un rato y volvimos; no más de una hora en total, pero estuvo bueno. Charlamos de PyCon, pero también nos despejamos bastante y nos sacamos de encima ese cansancio crónico que teníamos, lo que nos permitió encarar distinto la tarde que nos quedaba.

Luego del dique

Bah, que nos quedaba a algunos que nos volvíamos ya de noche. La mayoría que vivía en Córdoba Capital se fue durante la tarde, para llegar a sus hogares más o menos temprano.Yo dentro de todo me fui bastante temprano, a las siete de la tarde, porque mi plan fue llegar lo suficientemente temprano a casa como para llevar a Felu al jardín.

Y bueno, es por eso que luego de ir despidiendo gente durante la tarde un grupito reducido de nueve personas fuimos acomodando y limpiando todo al final, nos tomamos unas cervezas antes de partir, y dimos por finiquitado el sexto PyCamp de Python Argentina.  Acá están todas las fotos.

Read more
niemeyer

Note: This is a candidate version of the specification. This note will be removed once v1 is closed, and any changes will be described at the end. Please get in touch if you’re implementing it.

Contents


Introduction

This specification defines strepr, a stable representation that enables computing hashes and cryptographic signatures out of a defined set of composite values that is commonly found across a number of languages and applications.

Although the defined representation is a serialization format, it isn’t meant to be used as a traditional one. It may not be seen entirely in memory at once, or written to disk, or sent across the network. Its role is specifically in aiding the generation of hashes and signatures for values that are serialized via other means (JSON, BSON, YAML, HTTP headers or query parameters, configuration files, etc).

The format is designed with the following principles in mind:

Understandable — The representation must be easy to understand to increase the chances of it being implemented correctly.

Portable — The defined logic works properly when the data is being transferred across different platforms and implementations, independently from the choice of protocol and serialization implementation.

Unambiguous — As a natural requirement for producing stable hashes, there is a single way to process any supported value being held in the native form of the host language.

Meaning-oriented — The stable representation holds the meaning of the data being transferred, not its type. For example, the number 7 must be represented in the same way whether it’s being held in a float64 or in an uint16.


Supported values

The following values are supported:

  • nil: the nil/null/none singleton
  • bool: the true and false singletons
  • string: raw sequence of bytes
  • integers: positive, zero, and negative integer numbers
  • floats: IEEE754 binary floating point numbers
  • list: sequence of values
  • map: associative value→value pairs


Representation

nil = 'z'

The nil/null/none singleton is represented by the single byte 'z' (0x7a).

bool = 't' / 'f'

The true and false singletons are represented by the bytes 't' (0x74) and 'f' (0x66), respectively.

unsigned integer = 'p' <value>

Positive and zero integers are represented by the byte 'p' (0x70) followed by the variable-length encoding of the number.

For example, the number 131 is always represented as {0x70, 0x81, 0x03}, independently from the type that holds it in the host language.

negative integer = 'n' <absolute value>

Negative integers are represented by the byte 'n' (0x6e) followed by the variable-length encoding of the absolute value of the number.

For example, the number -131 is always represented as {0x6e, 0x81, 0x03}, independently from the type that holds it in the host language.

string = 's' <num bytes> <bytes>

Strings are represented by the byte 's' (0x73) followed by the variable-length encoding of the number of bytes in the string, followed by the specified number of raw bytes. If the string holds a list of Unicode code points, the raw bytes must contain their UTF-8 encoding.

For example, the string hi is represented as {0x73, 0x02, 'h', 'i'}

Due to the complexity involved in Unicode normalization, it is not required for the implementation of this specification. Consequently, Unicode strings that if normalized would be equal may have different stable representations.

binary float = 'd' <binary64>

32-bit or 64-bit IEEE754 binary floating point numbers that are not holding integers are represented by the byte 'd' (0x64) followed by the big-endian 64-bit IEEE754 binary floating point encoding of the number.

There are two exceptions to that rule:

1. If the floating point value is holding a NaN, it must necessarily be encoded by the following sequence of bytes: {0x64, 0x7f, 0xf8, 0x00 0x00, 0x00, 0x00, 0x00, 0x00}. This ensures all NaN values have a single representation.

2. If the floating point value is holding an integer number it must instead be encoded as an unsigned or negative integer, as appropriate. Floating point values that hold integer numbers are defined as those where floor(v) == v && abs(v) != ∞.

For example, the value 1.1 is represented as {0x64, 0x3f, 0xf1, 0x99, 0x99, 0x99, 0x99, 0x99, 0x9a}, but the value 1.0 is represented as {0x70, 0x01}, and -0.0 is represented as {0x70, 0x00}.

This distinction means all supported numbers have a single representation, independently from the data type used by the host language and serialization format.

list = 'l' <num items> [<item> ...]

Lists of values are represented by the byte 'l' (0x6c), followed by the variable-length encoding of the number of pairs in the list, followed by the stable representation of each item in the list in the original order.

For example, the value [131, -131] is represented as {0x6c, 0x70, 0x81, 0x03, 0x6e, 0x81, 0x03, 0x65}

map = 'm' <num pairs> [<item key> <item value>  ...]

Associative maps of values are represented by the byte 'm' (0x6d) followed by the variable-length encoding of the number of pairs in the map, followed by an ordered sequence of the stable representation of each key and value in the map. The pairs must be sorted so that the stable representation of the keys is in ascending lexicographical order. A map must not have multiple keys with the same representation.

For example, the map {"a": 4, 5: "b"} is always represented as {0x6d, 0x02, 0x70, 0x05, 0x73, 0x01, 'b', 0x73, 0x01, 'a', 0x70, 0x04}.


Variable-length encoding

Integers are variable-length encoded so that they can be represented in short space and with unbounded size. In an encoded number, the last byte holds the 7 least significant bits of the unsigned value, and zero as the eight bit. If there are remaining non-zero bits, the previous byte holds the next 7 bits, and the eight bit is set on to flag the continuation to the next byte. The process continues until there are non-zero bits remaining. The most significant bits end up in the first byte of the encoded value, which must necessarily not be 0x80.

For example, the number 128 is variable-length encoded as {0x81, 0x00}.


Reference implementation

A reference implementation is available, including a test suite which should be considered when implementing the specification.


Changes

draft1 → draft2

  • Enforce the use of UTF-8 for Unicode strings and explain why normalization is being left out.
  • Enforce a single NaN representation for floats.
  • Explain that map key uniqueness refers to the representation.
  • Don’t claim the specification is easy to implement; floats require attention.
  • Mention reference implementation.

Read more
niemeyer

The very first time the concepts behind the juju project were presented, by then still under the prototype name of Ubuntu Pipes, was about four years ago, in July of 2009. It was a short meeting with Mark Shuttleworth, Simon Wardley, and myself, when Canonical still had an office on a tall building by the Thames. That was just the seed of a long road of meetings and presentations that eventually led to the codification of these ideas into what today is a major component of the Ubuntu strategy on servers.

Despite having covered the core concepts many times in those meetings and presentations, it recently occurred to me that they were never properly written down in any reasonable form. This is an omission that I’ll attempt to fix with this post while still holding the proper context in mind and while things haven’t changed too much.

It’s worth noting that I’ve stepped aside as the project technical lead in January, which makes more likely for some of these ideas to take a turn, but they are still of historical value, and true for the time being.

Contents

This post is long enough to deserve an index, but these sections do build up concepts incrementally, so for a full understanding sequential reading is best:


Classical deployments

In a simplistic sense, deploying an application means configuring and running a set of processes in one or more machines to compose an integrated system. This procedure includes not only configuring the processes for particular needs, but also appropriately interconnecting the processes that compose the system.

The following figure depicts a simple example of such a scenario, with two frontend machines that had the Wordpress software configured on them to serve the same content out of a single backend machine running the MySQL database.

Deploying even that simple environment already requires the administrator to deal with a variety of tasks, such as setting up physical or virtual machines, provisioning the operating system, installing the applications and the necessary dependencies, configuring web servers, configuring the database, configuring the communication across the processes including addresses and credentials, firewall rules, and so on. Then, once the system is up, the deployed system must be managed throughout its whole lifecycle, with upgrades, configuration changes, new services integrated, and more.

The lack of a good mechanism to turn all of these tasks into high-level operations that are convenient, repeatable, and extensible, is what motivated the development of juju. The next sections provide an overview of how these problems are solved.


Preparing a blank slate

Before diving into the way in which juju environments are organized, a few words must be said about what a juju environment is in the first place.

All resources managed by juju are said to be within a juju environment, and such an environment may be prepared by juju itself as long as the administrator has access to one of the supported infrastructure providers (AWS, OpenStack, MAAS, etc).

In practice, creating an environment is done by running juju’s bootstrap command:

$ juju bootstrap

This will start a machine in the configured infrastructure provider and prepare the machine for running the juju state server to control the whole environment. Once the machine and the state server are up, they’ll wait for future instructions that are provided via follow up commands or alternative user interfaces.


Service topologies

The high-level perspective that juju takes about an environment and its lifecycle is similar to the perspective that a person has about them. For instance, although the classical deployment example provided above is simple, the mental model that describes it is even simpler, and consists of just a couple of communicating services:

That’s pretty much the model that an administrator using juju has to input into the system for that deployment to be realized. This may be achieved with the following commands:

$ juju deploy cs:precise/wordpress
$ juju deploy cs:precise/mysql
$ juju add-relation wordpress mysql

These commands will communicate with the previously bootstrapped environment, and will input into the system the desired model. The commands themselves don’t actually change the current state of the deployed software, but rather inform the juju infrastructure of the state that the environment should be in. After the commands take place, the juju state server will act to transform the current state of the deployment into the desired one.

In the example described, for instance, juju starts by deploying two new machines that are able to run the service units responsible for Wordpress and MySQL, and configures the machines to run agents that manipulate the system as needed to realize the requested model. An intermediate stage of that process might conceptually be represented as:

topology-step-1

The service units are then provided with the information necessary to configure and start the real software that is responsible for the requested workload (Wordpress and MySQL themselves, in this example), and are also provided with a mechanism that enables service units that were related together to easily exchange data such as addresses, credentials, and so on.

At this point, the service units are able to realize the requested model:

topology-step-2

This is close to the original scenario described, except that there’s a single frontend machine running Wordpress. The next section details how to add that second frontend machine.


Scaling services horizontally

The next step to match the original scenario described is to add a second service unit that can run Wordpress, and that can be achieved by the single command:

$ juju add-unit wordpress

No further commands or information are necessary, because the juju state server understands what the model of the deployment is. That model includes both the configuration of the involved services and the fact that units of the wordpress service should talk to units of the mysql service.

This final step makes the deployed system look equivalent to the original scenario depicted:

topology-step-3

Although that is equivalent to the classic deployment first described, as hinted by these examples an environment managed by juju isn’t static. Services may be added, removed, reconfigured, upgraded, expanded, contracted, and related together, and these actions may take place at any time during the lifetime of an environment.

The way that the service reacts to such changes isn’t enforced by the juju infrastructure. Instead, juju delegates service-specific decisions to the charm that implements the service behavior, as described in the following section.


Charms

A juju-managed environment wouldn't be nearly as interesting if all it could do was constrained by preconceived ideas that the juju developers had about what services should be supported and how they should interact among themselves and with the world.

Instead, the activities within a service deployed by juju are all orchestrated by a juju charm, which is generally named after the main software it exposes. A charm is defined by its metadata, one or more executable hooks that are called after certain events take place, and optionally some custom content.

The charm metadata contains basic declarative information, such as the name and description of the charm, relationships the charm may participate in, and configuration options that the charm is able to handle.

The charm hooks are executable files with well-defined names that may be written in any language. These hooks are run non-concurrently to inform the charm that something happened, and they give a chance for the charm to react to such events in arbitrary ways. There are hooks to inform that the service is supposed to be first installed, or started, or configured, or for when a relation was joined, departed, and so on.

This means that in the previous example the service units depicted are in fact reporting relevant events to the hooks that live within the wordpress charm, and those hooks are the ones responsible for bringing the Wordpress software and any other dependencies up.

wordpress-service-unit

The interface offered by juju to the charm implementation is the same, independently from which infrastructure provider is being used. As long as the charm author takes some care, one can create entire service stacks that can be moved around among different infrastructure providers.


Relations

In the examples above, the concept of service relationships was introduced naturally, because it’s indeed a common and critical aspect of any system that depends on more than a single process. Interestingly, despite it being such a foundational idea, most management systems in fact pay little attention to how the interconnections are modeled.

With juju, it’s fair to say that service relations were part of the system since inception, and have driven the whole mindset around it.

Relations in juju have three main properties: an interface, a kind, and a name.

The relation interface is simply a unique name that represents the protocol that is conventionally followed by the service units to exchange information via their respective hooks. As long as the name is the same, the charms are assumed to have been written in a compatible way, and thus the relation is allowed to be established via the user interface. Relations with different interfaces cannot be established.

The relation kind informs whether a service unit that deploys the given charm will act as a provider, a requirer, or a peer in the relation. Providers and requirers are complementary, in the sense that a service that provides an interface can only have that specific relation established with a service that requires the same interface, and vice-versa. Peer relations are automatically established internally across the units of the service that declares the relation, and enable easily clustering together these units to setup masters and slaves, rings, or any other structural organization that the underlying software supports.

The relation name uniquely identifies the given relation within the charm, and allows a single charm (and service and service units that use it) to have multiple relations with the same interface but different purposes. That identifier is then used in hook names relative to the given relation, user interfaces, and so on.

For example, the two communicating services described in examples might hold relations defined as:

wordpress-mysql-relation-details

When that service model is realized, juju will eventually inform all service units of the wordpress service that a relation was established with the respective service units of the mysql service. That event is communicated via hooks being called on both units, in a way resembling the following representation:

wordpress-mysql-relation-workflow

As depicted above, such an exchange might take the following form:

  1. The administrator establishes a relation between the wordpress service and the mysql service, which causes the service units of these services (wordpress/1 and mysql/0 in the example) to relate.
  2. Both service units concurrently call the relation-joined hook for the respective relation. Note that the hook is named after the local relation name for each unit. Given the conventions established for the mysql interface, the requirer side of the relation does nothing, and the provider informs the credentials and database name that should be used.
  3. The requirer side of the relation is informed that relation settings have changed via the relation-changed hook. This hook implementation may pick up the provided settings and configure the software to talk to the remote side.
  4. The Wordpress software itself is run, and establishes the required TCP connection to the configured database.

In that workflow, neither side knows for sure what service is being related to. It would be feasible (and probably welcome) to have the mysql service replaced by a mariadb service that provided a compatible mysql interface, and the wordpress charm wouldn’t have to be changed to communicate with it.

Also, although this example and many real world scenarios will have relations reflecting TCP connections, this may not always be the case. It’s reasonable to have relations conveying any kind of metadata across the related services.


Configuration

Service configuration follows the same model of metadata plus executable hooks that was described above for relations. A charm can declare what configuration settings it expects in its metadata, and how to react to setting changes in an executable hook named config-changed. Then, once a valid setting is changed for a service, all of the respective service units will have that hook called to reflect the new configuration.

Changing a service setting via the command line may be as simple as:

$ juju set wordpress title="My Blog"

This will communicate with the juju state server, record the new configuration, and consequently incite the service units to realize the new configuration as described. For clarity, this process may be represented as:

config-changed


Taking from here

This conceptual overview hopefully provides some insight into the original thinking that went into designing the juju project. For more in-depth information on any of the topics covered here, the following resources are good starting points:

Read more
Michael

logo-jujuHave you ever wished you could just declare the installed state of your juju charm like this?

deploy_user:
    group.present:
        - gid: 1800
    user.present:
        - uid: 1800
        - gid: 1800
        - createhome: False
        - require:
            - group: deploy_user

exampleapp:
    group.present:
        - gid: 1500
    user.present:
        - uid: 1500
        - gid: 1500
        - createhome: False
        - require:
            - group: exampleapp


/srv/{{ service_name }}:
    file.directory:
        - group: exampleapp
        - user: exampleapp
        - require:
            - user: exampleapp
        - recurse:
            - user
            - group


/srv/{{ service_name }}/{{ instance_type }}-logs:
    file.directory:
        - makedirs: True

While writing charms for Juju a long time ago, one of the things that I struggled with was testing the hook code – specifically the install hook code where the machine state is set up (ie. packages installed, directories created with correct permissions, config files setup etc.) Often the test code would be fragile – at best you can patch some attributes of your module (like “code_location = ‘/srv/example.com/code'”) to a tmp dir and test the state correctly, but at worst you end up testing the behaviour of your code (ie. os.mkdir was called with the correct user/group etc.). Either way, it wasn’t fun to write and iterate those tests.

But support has improved over the past year with the charmhelpers library. And recently I landed a branch adding support for declaring saltstack states in yaml, like the above example. That means that the install hook of your hooks.py can be reduced to something like:

import charmhelpers.core.hookenv
import charmhelpers.payload.execd
import charmhelpers.contrib.saltstack


hooks = charmhelpers.core.hookenv.Hooks()


@hooks.hook()
def install():
    """Setup the machine dependencies and installed state."""
    charmhelpers.contrib.saltstack.install_salt_support()
    charmhelpers.contrib.saltstack.update_machine_state(
        'machine_states/dependencies.yaml')
    charmhelpers.contrib.saltstack.update_machine_state(
        'machine_states/installed.yaml')


# Other hooks...

if __name__ == "__main__":
    hooks.execute(sys.argv)

…letting you focus on testing and writing the actual hook functionality (like relation-set’s etc. I’d like to add some test helpers that will automatically check the syntax of the state yaml files and template rendering output, but haven’t yet).

Hopefully we can add similar support for puppet and Ansible soon too, so that the charmer can choose the tools they want to use to declare the local machine state.

A few other things that I found valuable while writing my charm:

  • Use a branch for charmhelpers – this way you can make improvements to the library as you develop and not be dependent on your changes landing straight away to deploy (thanks Sidnei – I think I just copied that idea from one of his charms). The easiest way that I found for that was to install the branch into mycharm/lib so that it’s included in both dev and when you deploy (with a small snippet in your hooks.py.
  • Make it easy to deploy your local charm from the branch… the easiest way I found was a link-test-juju-repo make target – I’m not sure what other people do here?
  • In terms of writing actual hook functionality (like relation-set events etc), I found the easiest way to develop the charm was to iterate within a debug-hook session. Something like:
    1. write new test+code then juju upgrade-charm or add-relation
    2. run the hook and if it fails…
    3. fix and test right there within the debug-hook
    4. put the code back into my actual charm branch and update the test
    5. restore the system state in debug hook
    6. then juju upgrade-charm again to ensure it works, if it fails, iterate from 3.
  • Use the built-in support of template rendering from saltstack for rendering any config files that you need.

I don’t think I’d really appreciated the beauty of what juju is doing until, after testing my charm locally together with a gunicorn charm and a solr backend, I then setup a config using juju-deployer to create a full stack with an Apache front-end, a cache load balancer for multiple squid caches, as well as a load balancer in front of potentially multiple instances of my charms wsgi app, then a back-end loadbalancer in between my app and the (multiple) solr backends… and it just works.


Filed under: juju, python, testing

Read more
Michael

logo-jujuHave you ever wished you could just declare the installed state of your juju charm like this?

deploy_user:
    group.present:
        - gid: 1800
    user.present:
        - uid: 1800
        - gid: 1800
        - createhome: False
        - require:
            - group: deploy_user

exampleapp:
    group.present:
        - gid: 1500
    user.present:
        - uid: 1500
        - gid: 1500
        - createhome: False
        - require:
            - group: exampleapp


/srv/{{ service_name }}:
    file.directory:
        - group: exampleapp
        - user: exampleapp
        - require:
            - user: exampleapp
        - recurse:
            - user
            - group


/srv/{{ service_name }}/{{ instance_type }}-logs:
    file.directory:
        - makedirs: True

While writing charms for Juju a long time ago, one of the things that I struggled with was testing the hook code – specifically the install hook code where the machine state is set up (ie. packages installed, directories created with correct permissions, config files setup etc.) Often the test code would be fragile – at best you can patch some attributes of your module (like “code_location = ‘/srv/example.com/code’”) to a tmp dir and test the state correctly, but at worst you end up testing the behaviour of your code (ie. os.mkdir was called with the correct user/group etc.). Either way, it wasn’t fun to write and iterate those tests.

But support has improved over the past year with the charmhelpers library. And recently I landed a branch adding support for declaring saltstack states in yaml, like the above example. That means that the install hook of your hooks.py can be reduced to something like:

import charmhelpers.core.hookenv
import charmhelpers.payload.execd
import charmhelpers.contrib.saltstack


hooks = charmhelpers.core.hookenv.Hooks()


@hooks.hook()
def install():
    """Setup the machine dependencies and installed state."""
    charmhelpers.contrib.saltstack.install_salt_support()
    charmhelpers.contrib.saltstack.update_machine_state(
        'machine_states/dependencies.yaml')
    charmhelpers.contrib.saltstack.update_machine_state(
        'machine_states/installed.yaml')


# Other hooks...

if __name__ == "__main__":
    hooks.execute(sys.argv)

…letting you focus on testing and writing the actual hook functionality (like relation-set’s etc. I’d like to add some test helpers that will automatically check the syntax of the state yaml files and template rendering output, but haven’t yet).

Hopefully we can add similar support for puppet and Ansible soon too, so that the charmer can choose the tools they want to use to declare the local machine state.

A few other things that I found valuable while writing my charm:

  • Use a branch for charmhelpers – this way you can make improvements to the library as you develop and not be dependent on your changes landing straight away to deploy (thanks Sidnei – I think I just copied that idea from one of his charms). The easiest way that I found for that was to install the branch into mycharm/lib so that it’s included in both dev and when you deploy (with a small snippet in your hooks.py.
  • Make it easy to deploy your local charm from the branch… the easiest way I found was a link-test-juju-repo make target – I’m not sure what other people do here?
  • In terms of writing actual hook functionality (like relation-set events etc), I found the easiest way to develop the charm was to iterate within a debug-hook session. Something like:
    1. write new test+code then juju upgrade-charm or add-relation
    2. run the hook and if it fails…
    3. fix and test right there within the debug-hook
    4. put the code back into my actual charm branch and update the test
    5. restore the system state in debug hook
    6. then juju upgrade-charm again to ensure it works, if it fails, iterate from 3.
  • Use the built-in support of template rendering from saltstack for rendering any config files that you need.

I don’t think I’d really appreciated the beauty of what juju is doing until, after testing my charm locally together with a gunicorn charm and a solr backend, I then setup a config using juju-deployer to create a full stack with an Apache front-end, a cache load balancer for multiple squid caches, as well as a load balancer in front of potentially multiple instances of my charms wsgi app, then a back-end loadbalancer in between my app and the (multiple) solr backends… and it just works.


Filed under: juju, python, testing

Read more
facundo

CDPedia al cubo


Tres cositas tres, sobre CDPedia, en orden cronológico.

El once de Mayo pasado salió al aire por CN23 la emisión de Geekye en la que Irina Sternik me entrevista, justamente, sobre la CDPedia. El programa entero está subido acá en iutúb (arranca desde la parte que nos compete).

CDPedia en Geekye

Además, el martes que viene, a la mañana, es la presentación de Huayra Linux, el sistema operativo libre del Programa Conectar Igualdad (el logo y el motto es genial, "el día en el que las vacas vuelan ha llegado", :p). Esto es relevante acá porque Huayra sale de entrada con CDPedia instalada... o sea que todos los chicos que reciban una compu de Conectar Igualdad van a usar y disfrutar CDPedia! Están todos invitados al acto, es en Tecnópolis, 10:30hs.

Finalmente, les cuento que la semana que viene tenemos PyCamp 2013. Entre los proyectos que voy a empujar está obviamente CDPedia (acá están todos los proyectos, un lujo!), y en particular quiero ver si logramos dos cosas: por un lado un sistema de generación continua (algo que esté armando todo el tiempo CDPedias en distintos idiomas) y por otro lado que esta aplicación funcione en Android (con lo que se tendría todo el contenido de Wikipedia, offline, en los teléfonos y tablets).

Read more