Last  Thursday and Friday I was in Coruña attending to the GUADEC-ES, the most important event of GNOME and “hispanic version” of GNOME Users and Developers Conference.
It was my first event focused in GNOME and was simply amazing. I met a lot of GNOME Hackers and get the feeling that I’m in a collaborate with great community.

I enjoy all the talks but I have to highlight some of them.

• Git it done! by Mario Sánchez. I use git for more than 2 years but Mario gave us a glorifious crash course about it. You can find the slides [ES] in the next link: http://tinyurl.com/2wzqy6d
• Other of the talks that I prefer is “GNOME 3 para desarrolladores” (GNOME 3 for developers). Carlos Garcia Campos explain us the main differences between last GNOME libraries and what was done to achieve GNOME 3. Clean up !!
• The great discovery talk was “Vala, un lenguaje para Gnome 3.0” by Roberto Majadas. I heared just a little about Vala but Roberto with a lot of examples explain us the posibilities that Vala has to develop with a high-level language but with the benefits of optimization and speed of C language.
• And finally  ”cómo estudiar y participar en software libre sin morir en el intento” (How to study and participate in Free Software without die trying). Diego Escalante, developer of Epiphany, IMHO is the best speaker I have the pleasure to attend. The talk had a funny tone mixed with real experiences. Again you can find the slides here: http://people.gnome.org/~diegoe/slides/20100723_Coru%25C3%25B1a_Estudiar-y-participar.pdf

GPUL, coorganizers of this GUADEC, promised to make accesible all the videos recorded there. When this happen I’ll update this post to link them.

Conclusion: I recommend all to go this type of conferences cause you can learn a lot in just some hours and you’ll meet a lot of amazing people.

“Si un millón de personas está utilizando tu código, por lo menos la mitad de ellos percibirá si algo está mal en él. Un cuarto de ese medio millón puede que tenga el tiempo necesario para cambiarlo, si posee la destreza para hacerlo. Una décima parte de esos 12.500 no sólo tiene el tiempo y los conocimientos, si no también la inclinación a desarrollar un poco. Un pequeno porcentaje de las 12.500 personas no tendrán hijos, por lo que será capaz de concentrarse lo suficiente como para completar el esfuerzo. Al final, llegarán tres parches de tres personas diferentes y rechazarás dos de ellos porque no te gusta nada la solución o su estilo de programación.”

Extracto del artículo “Encontrar programadores” de Jon “Maddog” Hall en la revista Linux Magazine

Continuamos con el procesado de documentos XML con Ruby pero esta vez vamos a utilizar otro parser proporcionado en REXML.

La plase StreamParser delega la gestión de nodos en un XML a una clase definida por el usuario, la clase non será más que un Listener que implementa unas funciones predefinidas. Otra de las ventajas que ofrece StreamParser es que no hace falta cargar el flujo XML de forma íntegra en memoria, haciéndolo especialmente aconsejable para tratamientos de flujos XML muy grandes o para entornos con pocos recursos, el análisis de este flujo se hace de forma progresiva. La desventaja principal es que tenemos que asegurarnos que el flujo XML de entrada es válido ya que StreamParser no lo gestiona, en caso contrario el Listener no funcionará correctamente.

Con un poco de metaprogramación podemos analizar como funciona un parser de flujos XML, para ello aprovechamos la método method_missing que es llamado cada vez que un método no está definido dentro de un módulo o clase, de esta forma podemos hacer lo siguiente:

require "net/http"
require "rexml/document"
include REXML

class NovasListener
  def method_missing(method_id, *args)
    puts "El método #{method_id.id2name} fue llamado"
  end
end

Document.parse_stream(
  Net::HTTP.get("www.mabishu.com", "/blog/feed/rss/"),
  NovasListener.new
)

Read the rest of this entry »

Continuamos con el periplo de configurar Nginx siguiente con las dos anteriores entradas.
Ahora lo que trataremos es de ejecutar nuestras apps o scripts escritos en PHP 5. Let’s go.

Instalación de PHP

La instalación de PHP no tiene mucha ciencia en GNU/Linux:

$ sudo apt-get install php5-cli php5-cgi php5-mysql
$ php -v
PHP 5.2.0-8+etch9 (cli) (built: Dec 29 2007 14:49:25)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies

Instalación de FastCGI

Ya que nginx no cuenta con módulo integrado de php, precisamente porque no encuadra en su arquitectura, la ejecución del código PHP lo vamos a hacer a través de FastCGI. Para eso utilizaremos la implementación que viene con lighttpd. Básicamente lo que haremos será compilar lighttpd, para luego copiar simplemente el spawn-fcgi

wget http://www.lighttpd.net/download/lighttpd-1.4.18.tar.gz
gunzip lighttpd-1.4.18.tar.gz
tar xvf lighttpd-1.4.18.tar
cd lighttpd-1.4.18/
./configure
make
sudo cp src/spawn-fcgi /usr/bin/spawn-fcgi

Ahora tendremos que crear un ejecutable:

#!/bin/sh
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -f /usr/bin/php5-cgi

Y su script de control

#!/bin/bash
PHP_SCRIPT=/usr/bin/php-fastcgi
RETVAL=0
case "$1" in
    start)
      $PHP_SCRIPT
      RETVAL=$?
  ;;
    stop)
      killall -9 php5-cgi
      RETVAL=$?
  ;;
    restart)
      killall -9 php5-cgi
      $PHP_SCRIPT
      RETVAL=$?
  ;;
    *)
      echo "Usage: php-fastcgi {start|stop|restart}"
      exit 1
  ;;
esac
exit $RETVAL

al que arreglamos sus permisos y lo hacemos ejecutar al inicio del sistema:

sudo chmod 755 /etc/init.d/php-fastcgi
sudo chmod 755 /usr/bin/php-fastcgi
sudo /usr/sbin/update-rc.d -f php-fastcgi defaults

y escribir una serie de parámetros que necesita el spawn para hacer que todo funcione correcto en la comunicación con nginx insertando el siguiente bloque de configuración en

/etc/nginx/fastcgi.conf

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

bastaría añadir la configuración a nuestro virtual host para tener soporte por fin y finalmente de php

location ~ \.php$ {
  fastcgi_pass   127.0.0.1:9000;
  fastcgi_index  index.php;
  fastcgi_param  SCRIPT_FILENAME  /var/www/blog.codefront.net$fastcgi_script_name;
  include        /etc/nginx/fastcgi.conf;
}

Espero os haya sido productivo.