Archive for the ‘Voota’ Category

Vídeo de la ponencia en Decharlas

2 agosto 2010

Dicen que más vale tarde que nunca, así que aquí va el vídeo de mi ponencia en la primera edición de las Jornadas Symfony celebradas los pasados 5 y 6 de Julio en Castellón. He de decir que, a parte de disfrutar de un alto nivel en las charlas del resto de los ponentes, me divertí como un enano y tuve la oportunidad de conocer a un montón de gente realmente interesante. Un aplauso para la organización y en especial a David Castelló por el brillante trabajo.

Symfony en España. Caso práctico I: voota.es – decharlas 2010 from decharlas.com on Vimeo.

Y la presentación de la ponencia:

Un workflow sencillo con git

4 junio 2010

Uno de los grandes quebraderos de cabeza del desarrollo web es el control del ciclo de vida. Cuando la cosa se pone seria, muchos desarrolladores, muchos cambios etcétera, se hace imprescindible alguna metodología compleja tipo integración continua. Sin embargo, en la mayoría de los casos es suficiente con tener un poco de orden y unos procedimientos claros.

Gráfico GitHub de los commits de Voota

Gráfico GitHub de los commits de Voota

Es, sin duda, el gestor de versiones el principal aliado para gestionar correctamente el ciclo de vida. Este es el workflow que utilizamos en Voota con git:

  1. Cada desarrollador “sube” sus cambios al repositorio de software cada vez que realiza un desarrollo. Para ello se utiliza la rama “master” en git, que es, por decirlo de alguna manera, la arteria principal del desarrollo. Es el proyecto vivo que se irá actualizando diariamente.
    git commit -am “Resuelto el ticket #nnn”
    git push
  2. Cuando hay un “change set” razonable, o lo que es lo mismo, ya se tienen unos cuantos cambios que queremos que sean revisados, se envían al servidor de pruebas (“stage”). En el servidor de pruebas hay una copia (“clone”) exacta del código fuente, pero que, para que funcione en modo test, se realizan algunos cambios básicos. En el caso de Voota se copian los scripts de php que ponen a Symfony en modo test (en realidad esto sólo se hace una vez al instalar el servidor):
    mv frontend_test.php a index.php
    mv backend_test.php a backend.php

    A continuación se utiliza la magia de git. Se actualizan los fuentes con rebase. La gracia de “rebase” es que re-aplica las acciones que se han realizado (como los mv de arriba) sobre la copia local después de actualizar los cambios desde el repositorio. De este modo no es necesario volver a hacer las modificaciones.

    git pull –rebase
  3. Para el paso a producción hace falta un poco más de control. Se debe implementar un mecanismo que permita al desarrollador retomar el código en el estado exacto que está en producción. Este es el uso que damos a las etiquetas (tags) de git:
    git tag milestone1_8_5
    git push –tags

    Esto creará una foto del proyecto en su estado actual, con todo el conjunto de fuentes agrupado bajo el nombre de etiqueta milestone1_8_5. Como curiosidad, se pueden ver aquí las etiquetas que tenemos en el git de Voota.
    El resto es similar al entorno de pruebas, con la diferencia que no se actualizarán los programas de la rama “master” como antes, si no que se hará de la etiqueta recién creada:

    git pull –rebase origin refs/tags/milestone1_8_5

Alguien que conozco diría “Todo perfecto. Invitar a cañas” 😉 … pero, ¿que pasa si se sigue desarrollando en la rama “master” y se detecta un error importante en producción?¿a alguien le ha pasado alguna vez? Nada, se arregla y listo. Ahí va el procedimiento:

# Por si algún otro desarrollador ya lo ha hecho antes, se actualizan las etiquetas desde el repositorio:
git fetch –tags

# Se crea una rama basada en la etiqueta de la versión en producción:
git checkout milestone1_8_5 -b b_milestone1_8_5

#####################################
# Se hacen cosas: Arreglar el bug por ejemplo 😉
#####################################

# Se suben los cambios a git:
git commit -am ‘se explica lo que se ha hecho un poco’

# Se actualiza la etiqueta:
git tag -f milestone1_8_5

# Se “empuja” al repositorio
git push –tags

# Volvemos a la rama principal en la copia local
git checkout master

# Se aplica el parche a la versión en desarrollo para que no se pierda en la siguiente release
git merge b_milestone1_8_5

# Se borra la rama creada para la ocasión
git branch -d b_milestone1_8_5

Ahora en el servidor de producción se actualiza la versión “tirando” de la etiqueta:

git pull –rebase origin refs/tags/milestone1_8_5

Trabajar con git tiene muchas ventajas y una de ellas es hacer las cosas fáciles y rápidas. Creo que este es un buen ejemplo.

VootaDroid: Voota en Android

14 abril 2010

Hace poco hablábamos de la recién creada API de Voota. Hoy ya tenemos un ejemplo para enseñar: VootaDroid. Se trata de una aplicación para Android que hace uso intensivo de la API.

Si eres desarrollador o, simplemente curioso, ahí van unos enlaces de las tripas de la aplicación:

Javier Yohn nos cuenta para que sirve la aplicación en este vídeo:

Y, por si sólo quieres probarla en tu teléfono Android, búscala en el market como VootaDroid o escanea este qr:

qrcode

Para más datos, aquí tienes el anuncio oficial: http://blog.voota.es/pon-a-voota-es-en-tu-movil-vootadroid/

Una API para Voota

5 abril 2010

Si todo va bien, a lo largo de esta semana publicaremos la API de Voota, en versión beta, claro. Por decirlo de manera sencilla, una API es un mecanismo para intercambiar información con otras webs o aplicaciones.  Desde el principio hemos tenido claro que era necesaria, pero no siempre hemos estado seguros de cómo era de prioritario. Puede que, de entrada, no sea fácil ver la utilidad, sin embargo, pienso que en un proyecto como Voota es incluso necesaria:

  • Voota, como asociación, tiene por principio ser transparente en todo y para todos. Lo hacemos con los socios, con la financiación, con el software y con la información que generamos (Voota y Creative Commons son amigos de toda la vida). No contentos con publicarlo, nos esforzamos en facilitar el acceso a toda esta información. Con los datos no queremos hacer una excepción. Esta API permitirá leer las valoraciones y comentarios sobre nuestros políticos no sólo desde la web de Voota, si no desde cualquier otra web, aplicación o dispositivo que quiera hacerlo.
  • Los estatutos de Voota rezan: “… La existencia de esta asociación tiene como fines fomentar la participación ciudadana en la política … “. No veo mejor forma de fomentar la participación que ofreciendo toda la información de la manera más abierta posible y aceptando en forma de opiniones/votos la información que generan terceros.

Pero, ¿qué utilidad se le puede dar a esta API?

Hay tantas formas de utilizar una API como mentes pensantes, pero por poner algún ejemplo:

  • Otras webs de política que quieran publicar lo que la gente opina de los políticos/partidos.
  • Otras webs, aplicaciones o dispositivos móviles que permitan “vootar” a los políticos/partidos.
  • Herramientas de generación es estadísticas o rankings.
  • Widgets o pequeñas aplicaciones que mantengan información continuamente actualizada sobre algún político o partido.
  • Por nuestra parte ya estamos preparando una pequeña aplicación para Android que la utilice. Por supuesto, será de código abierto 😉

    VootaDroid

    VootaDroid. Ejemplo de consumidor de la API de Voota

Sobre la tecnología no hay mucho que decir aun, salvo que, como viene siendo habitual, hemos intentado utilizar los más abierto y estándar que nos ofrece el mercado: OAuth, REST, json. También pretendemos ofrecer un par de de interfaces de comunicación como ejemplo. Una en php y otra en java.

Lo dicho, tendréis noticias muuuy pronto …

github: Un nuevo hogar para el código fuente de Voota

8 marzo 2010

Siguiendo la política de transpariencia de Voota, esta semana hemos dado otro pasito. Nos hemos quitado de encima todo el código y le hemos buscado un sitio donde, pensamos, estará más cómodo.

Voota en github

Voota en github

Hasta ahora lo teníamos alojado en un servidor propio gestionado con subversion. Hoy Voota está en github, un servicio especializado en alojar software libre, donde cualquiera podrá acceder, comentar, reportar errores y muchos otro servicios. Además, pasamos de subversion a git que nos trae algunas funcionalidades nuevas.

¿Por qué este cambio?

Pensamos que es el lugar natural para un proyecto de estas características:

  • Porque el código fuente de Voota será más accesible, más fácilmente localizable para cualquiera que lo busque o lo quiera ver.
  • Porque estará más cerca de la comunidad de desarrolladores, gente que puede estar interesada y/o que puede aportar conocimiento.
  • Porque estará gestionado por expertos en el tema.
  • … y, además, quitará parte del trabajo de gestión a éste que suscribe. Eso siempre es bueno 😉

… y con el paso a git (vs. subversion):

  • Ganamos un entorno distribuido en el que no hace falta estar conectado con un servidor para utilizar el control de versiones.
  • Mejora sustancial de la gestión de ramas (branching).
  • Flexibilidad y eficiencia. Poco se puede decir de git que no esté dicho ya. Sólo puedo añadir que uno no es consciente de su potencia hasta que comienza a utilizarlo.

Dicho esto, estáis todos invitados a ver, descargar, comentar y cotillear por el código de Voota. Estará encantado de recibiros en su nueva casa 😉

Traducción web rápida y fácil con Symfony y Pootle

8 febrero 2010

El tema de las traducciones es, muchas veces un verdadero dolor de cabeza. La creación del código multi-idioma, la extracción de etiquetas y el envío y recepción de los textos al traductor son tareas que se pueden simplificar notablemente utilizando las herramientas apropiadas. Ahí va nuestra propuesta:

  • Codificación de las vistas (páginas) con etiquetas traducibles. El ejemplo a continuación es un extracto de una vista de Symfony :

    […]

    <li><h2><?php echo __(‘Comparte opiniones sobre políticos de España.’) ?></h2></li>

    […]

    Codificar las vistas de esta forma permite ver el html casi como será generado en el idioma original pero dando la posibilidad de traducir todos los literales que se encuentren entre ‘__(‘ y ‘)’.

  • Extracción de etiquetas. Un simple comando permite extraer todas las etiquetas a un fichero XLIFF:
    php symfony i18n:extract –auto-save frontend ca

    Este comando generará un fichero para almacenar las traducciones al catalán (‘ca’) de cada etiqueta encontrada en todas y cada una de las vistas de la aplicación (‘frontend’). Algo así como ‘…/ca/messages.xml’.
    Lo ideal es almacenar este fichero en un repositorio de software junto con el resto del código del proyecto. En nuestro caso utilizamos un servidor svn.

  • La magia de Pootle. La aplicación de Pootle deberá estar instalada en un servidor con acceso al repositorio svn. Habrá que configurar permisos y accesos para cada traductor. Una vez esté listo, Pootle permite conectarse con svn para obtener el fichero de etiquetas generado por Symfony. El traductor podrá conectarse vía web a la aplicación para ver y traducir todas aquellas que pertenezcan a sus proyectos y lenguajes asignados.
    Interfaz de traducciones - Pootle

    Interfaz de traducciones - Pootle

    Desde el propio interfaz de Pootle, siempre con los permisos apropiados, se puede enviar de nuevo el fichero con las traducciones realizadas de nuevo al repositorio de software. Sobra decir que, además, Pootle ofrece un montón de utilidades más sobre las traducciones, como estadísticas, traducciones dudosas o poco claras, perfiles para sugerir y otros para confirmar, etc..
    Te invitamos a que eches un vistazo al Pootle de Voota: http://pootle.voota.org/

Nunca fue tan fácil tener sitios en varios idiomas. Ahora solo necesitamos los traductores que, por el momento, seguirán siendo humanos 😉

SfReviewPlugin 1.0: Nueva versión del plugin de opiniones para Symfony

18 enero 2010

Hoy ya hemos puesto a disposición de todos la versión 1.0 de SfReviewPlugin. Se trata del plugin de symfony que desarrollamos y utilizamos en Voota para la gestión de opiniones sobre políticos (y muy pronto sobre partidos).

Aunque sigue siendo una versión beta, hemos decidido etiquetarla 1.0 para seguir con la numeración de los milestones de voota.

Descarga

Puedes obtener la versión instalable directamente del sitio de symfony:

http://www.symfony-project.org/plugins/sfReviewPlugin

Para obtener los últimos cambios día a día, puedes bajarte los fuentes del repositorio svn de Voota:

http://trac.voota.org/browser/trunk/www/plugins/sfReviewPlugin

Novedades

  • La novedad principal, sin duda, es la posibilidad de opinar/votar sobre otras opiniones.

    Opinando sobre un comentario

    Opinando sobre un comentario

  • Opiniones “culturizadas”. Hemos introducido el idioma del usuario a la opinión para, de esta forma, poder distinguir el idioma en la página donde aparecen los comentarios.
  • Paginación “tipo twitter”. Para mejorar la experiencia de usuario hemos introducido un botoncito que dice “más” cuando no caben todos los comentarios. Al pulsarlo aparecerá otra página de comentarios “inline” por ajax (sin necesidad de recargar la página). Ej.: Página de Zapatero en Voota
  • Mejoras en el sistema de moderación: Más filtros, más facilidad para encontrar comentarios y mejor interfaz para visualizar el comentario con enlace a la “entidad comentada”.

    Moderación de comentarios

    Moderación de comentarios

  • Y, como siempre, un montón de pequeñas mejoras y correcciones que hacen la vida un poco más fácil 😉

En definitiva, seguimos trabajando en el sistema de opiniones como uno de los módulos principales de Voota. Ójala te sea útil a tí también y compartas con nosotros tus impresiones.

nginx + fast-cgi: Nueva arquitectura para Voota

31 diciembre 2009

Tras tener varios problemas de servidores en Voota, nos tocó investigar como mejorar los sistemas. Como siempre, lo primero es preguntar a los expertos. Nuestros amigos de amplicate.com y masquemedicos.com lo tenían claro. Junto con muchas otras recomendaciones, nos convencieron para cambiar el servidor web a una arquitectura más moderna.

Adiós Apache y gracias por todo

Apache ha sido durante mucho tiempo (y sigue siendo) el servidor web más utilizado y popular para servir tanto páginas estáticas (html) como aplicaciones desarrolladas en php, perl o python. Pero como pasa con todo, poco a poco ha ido quedándose atrás en favor de otras arquitecturas más modernas.

Nginx

Arquitectura nginx con fast-cgi

Nginx es un servidor mucho más ligero que apache y que, por lo tanto, realiza menos funciones. La idea de es utilizar Nginx en la primera línea de fuego para servir todo el contenido estático del sitio web: Pagínas html, imágenes, javascript, hojas de estilo, etc. El resto de las tareas se delegarán a un servidor específico.

fast-cgi

Es la evolución de CGI (Common Gateway Interface), aquél protocolo concebido allá por 1993 para responder a la demanda de páginas dinámicas. Hoy fast-cgi permite conectar (por tcp) un servidor web estilo Nginx con otro servidor independiente que ejecuta las aplicaciones. En el caso de Voota, estás aplicaciones están desarrolladas en php y el servidor de aplicación es php-fpm.

En resumen, nada radicalmente nuevo. Mismos programas, mismo lenguaje, pero con una arquitectura mucho más moderna, flexible, rápida y escalable.

Mejorando el rendimiento de Symfony a base de caché

17 diciembre 2009

Symfony no es lento

Se dice que utilizar un framework en general y Symfony en particular penaliza el rendimiento de una aplicación web. Es cierto, al menos a priori. Por mucho trabajo de optimización que se haga, las propias clases del framework consumirán tiempo y recursos y tampoco serán las óptimas las queries de acceso a base de datos generadas. Siempre será más eficiente un código personalizado para la ocasión que un código genérico.

Dicho así podría parecer que es preferible invertir tiempo en hacer código a medida que utilizar herramientas como Symfony. Nada más lejos de la realidad. Una de las cosas que proporciona Symfony, y que compensa con creces “su lentitud”, es un sistema de caché que con muy poco esfuerzo permitirá a una aplicación desarrollada en Symfony “correr” mucho más rápido que una aplicación hecha “a mano”. ¡Ojo! Esto no quita la responsabilidad de hacer un código eficiente.

Activando la caché de página

Efectivamente, hay muchas formas de optimizar el rendimiento de una aplicación, pero sin duda, la caché de página es la que marca la diferencia. Para activarla en Symfony solo hay que crear el fichero cache.yml en el directorio config del módulo (ej. apps/frontend/modules/politico/config/) activando la cache para cada acción en la que se quiera poner en caché:

ranking:
 enabled: on
 with_layout: false
 lifetime: 60

show:
 enabled: on
 with_layout: false
 lifetime: 360

“ranking” y “show” son dos de las acciones del módulo. “with_layou: false” indica que sólo ha de guardarse el código específico de esta vista, no el de layout.php. “lifetime” es el tiempo en segundos que tardará en limpiarse la caché automáticamente.

Limpiando la caché manualmente

Symfony proporciona información del estado de la caché si se necesita

Una de las opciones para limpiar la caché de una página es esperar a que pase el tiempo indicado en “lifetime” en el fichero de configuración. Como esto muchas veces no es una opción, Symfony proporciona un mecanismo para limpiarla por código. El siguiente snipplet (pedacito de código) muestra como, en Voota, se limpia la caché de la página de un político cada vez que alguien deja un comentario:

$cacheManager = $this->getContext()->getViewCacheManager();
if ($cacheManager != null) {
$cacheManager->remove(“politico/show?id=”.$politico->getVanity().”&sf_culture=es”);
$cacheManager->remove(“politico/show?id=”.$politico->getVanity().”&sf_culture=ca”);
}

La clase sfViewCacheManager permite interactuar con el sistema de caché de Symfony. El método “remove” limpia la página que se quiera.

Más rápido incluso

Otra de las funcionalidades que ofrece Symfony es delegar la gestión de la caché a un sistema externo. Unos de los sistemas más conocidos y utilizados dentro y fuera de Symfony es memcached. Una buena idea será dejarle la gestión a él. Esto se configura en el fichero de factorías de la aplicación (apps/frontend/config/factories.yml):

dev:
 view_cache:
  class: sfMemcacheCache
   param:
    lifetime:                  86400 #24h
    prefix:                    vo
    servers:
     server_01:
      host: localhost
      post: 11211

El resto exactamente igual. No será necesario tocar ni una línea de código para esto.

sfReviewPlugin: Plugin symfony para dejar opiniones sobre “cualquier cosa”

30 noviembre 2009

Como parte del desarrollo de Voota estamos creando un plugin genérico para dejar opiniones: sfReviewPlugin. En su primera versión, Voota permite opinar sobre políticos, pero pronto permitirá opinar sobre partidos políticos y, más adelante, sobre otras “entidades”.

Como se puede ver en el decálogo  de Voota, parte de nuestro compromiso es con el software libre y, por lo tanto, pretendemos ir a aportando cualquier pieza de software que vayamos produciendo. Hoy tenemos ya publicada la primera versión del sistema de opiniones:

¿Qué es sfReviewPlugin?

Editando una opinión con sfReviewPlugin

Es un plugin genérico para valorar y opinar sobre cualquier elemento de un sitio web desarrollado con Symfony. Está basado en sfGuardPlugin como gestor de usuarios y en JQuery (sfJqueryReloadedPlugin) como api javascript/ajax.

Donde bajarlo y cómo instalarlo

El plugin está alojado en el propio sitio de symfony:

http://www.symfony-project.org/plugins/sfReviewPlugin

En la pestaña “Readme” se pueden encontrar las instrucciones para descargarlo, instalarlo y realizar una configuración básica.

Los fuentes están disponibles en el repositorio de software de Voota:

http://trac.voota.org/browser/trunk/www/plugins/sfReviewPlugin

Cualquier duda / problema / sugerencia será muy bien recibida en este blog, en mi twitter o en la dirección de email de temas técnicos de Voota: tech [arr0ba] voota.es

Suma y sigue

Como todas las primeras versiones esto no es más que una beta del plugin. Para el siguiente milestone de Voota ya estamos trabajando en las opiniones sobre opiniones (para permitir el debate entre usuarios) y, muy pronto, este mismo plugin permitirá cargar imágenes y vídeos con el comentario.