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.

Anuncios

Como implementar Sphinx con symfony

23 noviembre 2009

Como primera aproximación a un buscador simple en la primera versión de Voota, se nos ocurrió utilizar “Google custom search“. Mala idea. Hoy, 5 días después de la puesta online, Google solo ha indexado 267 páginas y teniendo en cuenta que empezábamos con 1.549 políticos con sus 1.549 correspondientes fichas, los resultados no eran muy apropiados. Por ejemplo, buscando “Zapatero” aparecían varios resultados del blog, alguna ficha de otros políticos y varios enlaces al ranking, pero no la ficha del sr. presidente.

Necesitábamos un buscador, sencillo, potente y que escalase bien con los futuros desarrollos que vienen. La solución fue mucho más fácil de lo esperado. Decidimos implementar nuestro propio motor de búsqueda con Sphinx. Así es como lo hicimos:

  1. Lo primero es instalar el motor de búsqueda, que básicamente consta de dos partes: El indexador, que obtiene las palabras clave de la base de datos (Postgresql o mysql) y el demonio o servicio de búsqueda que atiende a las peticiones del servidor web.
    La instalación no tiene más misterio que seguir los pasos que explican en su web: Manual de referencia de Sphinx.
  2. Después viene la fase de configuración. Aquí es donde se le dice a Sphinx que datos tiene que indexar para que puedan ser encontrados en el buscador del sitio web. En nuestro caso, de momento, sólo queríamos indexar los políticos:
    source src1
    {
    type                                    = mysql
    sql_host                                = localhost
    sql_user                                = usuario
    sql_pass                                =
    sql_db                                  = voota
    sql_port                                = 3306  # optional, default is 3306
    sql_query_pre   = SET NAMES utf8
    sql_query                               = \
    SELECT id, vanity, alias, nombre, apellidos, bio, presentacion, residencia, formacion \
    FROM politico
    sql_ranged_throttle     = 0
    sql_query_info          = SELECT * FROM politico WHERE id=$id
    }
    source src1throttled : src1
    {
    sql_ranged_throttle                     = 100
    }
    index politico
    {
    source                  = src1
    path                    = /var/data/voota
    docinfo                 = extern
    mlock                   = 0
    morphology              = none
    min_word_len            = 1
    charset_type            = utf-8
    charset_table   = 0..9, A..Z->a..z, a..z, \
    U+C0->a, U+C1->a, U+C2->a, U+C3->a, \
    U+C4->a, U+C5->a, U+C6->a, \
    U+C7->c,U+E7->c, U+C8->e, U+C9->e, \
    U+CA->e, U+CB->e, U+CC->i, \
    U+CD->i, U+CE->i, U+CF->i, U+D0->d, \
    U+D1->n, U+D2->o, U+D3->o, \
    U+D4->o, U+D5->o, U+D6->o, U+D8->o, \
    U+D9->u, U+DA->u, U+DB->u, \
    U+DC->u, U+DD->y, U+DE->t, U+DF->s, \
    U+E0->a, U+E1->a, U+E2->a, U+E3->a, \
    U+E4->a, U+E5->a, U+E6->a, \
    U+E7->c,U+E7->c, U+E8->e, \
    U+E9->e, U+EA->e, U+EB->e, U+EC->i, \
    U+ED->i, U+EE->i, U+EF->i, \
    U+F0->d, U+F1->n, U+F2->o, U+F3->o, \
    U+F4->o, U+F5->o, U+F6->o, \
    U+F8->o, U+F9->u, U+FA->u, U+FB->u, \
    U+FC->u, U+FD->y, U+FE->t, U+FF->s,
    html_strip                              = 0
    }

    Extracto del fichero de configuración de Sphinx

  3. A continuación se arranca el servicio de búsqueda:
    sudo searchd –config /usr/local/etc/sphinx.conf
    y se da la orden para que Sphinx realice la indexación (Esto será necesario hacerlo periódicamente):
    sudo /usr/local/bin/indexer politico –rotate
    Muy bien, Sphinx configurado y escuchando.
  4. Sólo falta escribir el código Symfony para interrogar al motor de búsqueda:
    $this->q = $request->getParameter(“q”);$cl = new SphinxClient ();
    $cl->SetServer ( ‘localhost’, 3312 );
    $this->limit = 1000;
    $cl->SetLimits ( 0, $this->limit, $this->limit );
    $cl->SetArrayResult ( true );
    $this->res = $cl->Query ( SfVoUtil::stripAccents( $this->q ), ‘politico’ );
    if ( $this->res!==false ) {
    if ( isset($this->res[“matches”]) && is_array($this->res[“matches”]) ) {
    $c = new Criteria();
    $list = array();
    foreach ($this->res[“matches”] as $idx => $match) {
    $list[] = $match[‘id’];
    }
    $c->add(PoliticoPeer::ID, $list, Criteria::IN);
    $c->addDescendingOrderByColumn(PoliticoPeer::SUMU);
    $this->politicosPager = new sfPropelPager(‘Politico’, 10);
    $this->politicosPager->setCriteria($c);
    $this->politicosPager->setPage($this->getRequestParameter(‘page’, 1));
    $this->politicosPager->init();if ($this->politicosPager->getNbResults() == 1){
    $res = $this->politicosPager->getResults();
    $this->redirect( “@politico_”.$this->getUser()->getCulture( ‘es’ ).”?id=”.$res[0]->getVanity() );
    }
    }
    }

    Código Symfony que realiza la búsqueda

Listo, hoy puedes buscar Zapatero, José Luis Rodriguez o ZP en Voota, que seguro que encuentras lo que buscas, a no ser que quieras comprarte unos zapatos nuevos, claro 😉

Voota goes live !

18 noviembre 2009

Después de 3 meses de trabajo y un sencillo paso de puesta en producción, ya se puede opinar y votar sobre nuestros políticos. Voota sale con una versión beta que aporta lo esencial:

  • Opiniones de usuarios sobre políticos
  • Ranking de los políticos más y menos valorados

Por supuesto, esto es solo el principio, pero espero que dejes muchas opiniones/votos y, si quieres, me digas que te parece. Y si te apetece ver qué viene después, puedes echar un vistazo al roadmap de nuestro Trac.

Ale, ¡a Vootar!

Posts relacionados:

La puesta en producción

16 noviembre 2009

Se acerca el día “D”. Voota empieza su andadura esta semana y, como no puede ser de otra manera, estamos llenos de emoción. Y cuando digo emoción, me refiero a lo contentos que estamos y a las ganas que tenemos de verlo funcionando, no a que tenemos los pelos como escarpias por el miedo a la puesta en producción. Veamos algunos consejillos para que esto no ocurra.

Ante todo, ¡orden!

Para que la subida (o puesta en producción) sea un éxito, es fundamental hacer una buena planificación, preparar el proceso unos días antes. Una buena idea es tener un checklist de cosas a preparar/revisar antes de ponerse manos a la obra. Podría ser algo tan simple como:

  • Asegurar que los servidores están correctamente actualizados.
  • Comprobar los datos. Todos están correctamente cargados con la información adecuada.
  • Backups. Asegurarse de que todos los subsistemas se están copiado adecuadamente según la política de backup.
  • Todas las aplicaciones están listas (este punto debería llevar implícito toda una fase de pruebas funcionales)

Otra cosa importante es planificar el día y la hora correctamente. Si se planifica la subida a última hora del día, ante cualquier imprevisto, se condena uno a una de dos: dejar el trabajo a medias, o a hacer horas extras. Lo mejor es hacerlo a media mañana con tranquilidad y sin estrés. Lo mismo pasa con el día. Si se realiza la subida un viernes, se está exponiendo el sitio a que se pasé 3 días offline.

Sube pronto, sube a menudo

Hoja de ruta (roadmap) de Voota

Hoja de ruta (roadmap) de Voota

Una de las máximas del desarrollo ágil es que los “sprints” deben de ser cortos. Esta semana Voota sale con lo esencial, es decir, un sistema de opiniones sobre políticos con un ranking para ver los más votados. Hemos querido reducir tanto que ya tenemos programado otro “sprint” de 7 días para subir la semana que viene. En su Trac se puede ver la hoja de ruta de Voota.

Sólo errores, ¡por favor!

No se puede concebir un desarrollo de software que no tenga incidencias, bugs o errores (depende quien los nombre). Son fallos en el desarrollo que se producen a todos los niveles (datos, aplicación, sistemas, …). Es por esto que es imprescindible una fase de pruebas de software, durante la cual se van identificando y corrigiendo estos fallos. Hasta aquí todo bien, el problema es que, inevitablemente, al revisar las aplicaciones siempre aparecen funcionalidades nuevas con las que se podría dotar al sitio. La tentación de informar como incidencia una nueva funcionalidad que se le ocurre al encargado de hacer la revisión es muy grande.
Es importante no caer en esta tentación a menos que se detecte una funcionalidad importante no detectada en la fase de definición. En este caso debería incluirse en la definición con su correspondiente estimación y retrasar la subida todo lo que sea necesario. Nunca “colarla” como un error. Lo único que se conseguiría con esto es degradar la calidad del software.

Ya está, ¿y ahora qué?

Ramificaciones para gestionar subidas en Voota

Ramificaciones para gestionar subidas en Voota

Un problema clásico de las puestas en producción es el siguiente. Se sube una versión a producción, por ejemplo, “milestone0.5”. Inmediatamente se comienza con el desarrollo del “milestone0.6”, pero dos días después se descubre un error importante en la versión en producción (“mileston0.5”). Si no se ha tenido la precaución de guardar el estado de todos los programas en el momento de hacer la subida, el problema no se podrá solucionar hasta que el “milestone0.6” esté listo. Es por esto importante hacer una “foto” con el estado del proyecto en el momento de la subida. Cualquier gestor de fuentes del mercado (subversion en el caso de Voota) permite crear ramas (branching).
Una rama en el gestor de fuentes es como tomar una foto del estado del proyecto, con la ventaja que se puede cambiar de una rama a otra cuando se necesite.

¡ Vamos, pues, a por el siguiente punto kilométrico !

Así utilizamos Amazon Web Services

2 noviembre 2009

En Voota creemos que cada uno debe dedicarse a lo que mejor sabe hacer. Por eso, desde el primer momento, no quisimos encargarnos de comprar, instalar y configurar servidores. Amazon Web Services (AWS) ofrece un sistema de virtualización que nos abstrae de gran parte de este trabajo de sistemas. De momento empezaremos utilizando 2 de sus servicios:

Así utilizamos EC2

Este es, sin duda, el núcleo de los servicios de virtualización. Permite crear servidores web, servidores de bases de datos y … servidores en general. El concepto es simple: Permite crear todos los servidores que necesite el proyecto desde una interfaz web. Por supuesto son servidores virtuales, pero a todos los efectos es igual que tener un servidor en el despacho de abajo, con la ventaja de que puedes incrementar el número de servidores con un clic de ratón.

Instancias EC2

Lista de instancias en Amazon EC2

Las instancias en EC2 son servidores en ejecución. Se paga por el uso de instancias, lo cual permite tener más o menos servidores sirviendo páginas en función del tráfico del sitio en cada momento.

Otro concepto muy interesante es del AMI (Amazon Machine Image) que no es otra cosa que un servidor “congelado” o, más técnicamente, una imagen de servidor. Cuando se necesita arrancar una nueva instancia, se abre la “nevera” y se le dice a Amazon: “Arráncame uno de estos” y se crea una instancia nueva.

Elegir un AMI

Cualquiera en la comunidad puede crear sus propias imágenes al igual que cualquier distribuidor de software. En el caso de Voota, utilizamos Ubuntu server. Canonical nos lo pone fácil y pone a disposición de cualquier usuario de EC2 su “servidor congelado”. Ya está disponible en Karmic Koala (la nueva versión de ubuntu).

Pero esto es sólo para la primera vez. En Voota, una vez que tuvimos el servidor instalado con el software necesario y listo para servir páginas, le hicimos una foto. Es decir, lo congelamos a un AMI. De esta forma, la próxima vez que sea necesario arrancar una nueva instancia, lo haremos desde nuestro propio AMI, que ya está listo para funcionar.

AMI del servidor web de Voota

AMI del servidor web de Voota

Así utilizamos S3

S3 es un servicio de almacenamiento. Permite almacenar cualquier tipo de información mediante ficheros (imágenes, vídeos, AMIs, backups, etc.). Para nosotros es muy útil a la hora de almacenar las imágenes y los vídeos. Un error muy común en el desarrollo web es almacenar estos ficheros multimedia en un disco del servidor. Todo funciona bien hasta que se necesitan más servidores y por tanto compartir estos ficheros de imágenes. Hay varias soluciones para este problema:

  • Sincronizar continuamente los ficheros entre todos los servidores. Bastante poco práctico sobre todo a medida que va creciendo la estructura.
  • Utilizar una unidad compartida de modo que todos los servidores lean y escriban en el mismo disco. Más cómodo pero se corre el peligro de saturar el disco con lo  cual el balanceo de los servidores no servirá para nada.
  • Crear un servidor de ficheros al que todos los servidores web envíen los ficheros cuando hay que “escribir”. Y que sea este servidor de ficheros el encargado de servirlas directamente al navegador del usuario del sitio web.

Esto último es lo que nos ofrece S3. Cuando algún usuario de Voota carga una fotografía, ésta se envía directamente a S3, quien la almacena. Cuando esta fotografía ha de aparecer en alguna página web, será S3 el encargado de servirla.

Foto de Zapatero almacenada en S3

Esta foto está almacenada en http://imagesvoota.s3.amazonaws.com/politicos/bw_p_238.jpg

Otra utilidad de S3 es el almacenaje de los AMIs o “servidores congelados” que mencionaba antes. Para poder utilizar un AMI en EC2 es obligatorio tenerlo almacenado en S3.

Desarrollo web, desarrollo ágil

13 octubre 2009

Para que “algo” funcione en internet tiene que ser ágil desde todos los puntos de vista. Las páginas web deben pesar poco, el tiempo de respuesta desde que se pide una página hasta que se muestra en el navegador tiene que ser casi inmediato y, dentro de un sitio, si una página ha de ser visitada, más vale que se acceda a ella en pocos clics. Afortunadamente estos conceptos ya han sido aceptados y digeridos por la mayoría de profesionales que se dedican a la “construcción de internet”.

Sin embargo, muchas veces es obviado el concepto de agilidad en la fase de desarrollo. Aunque existen muchas formas y metodologías para aplicarlo, una vez más, lo más importante es aplicar la lógica y entender bien lo que se está haciendo para poder llegar a ser “ágiles”. Se trata de aplicar unos conceptos fundamentales que cada metodología implementará de una manera. Algunas metodologías son Scrum, Programación Extrema (XP) o Agile Unified Process (AUP).

Scrum: Procesos y elementos

Scrum: Procesos y elementos

¿Qué es desarrollo ágil?

Según el manifiesto para el desarrollo ágil de software, éste se basa en 4 pilares básicos:

  • Somos un equipo. Poco aportan unos procedimientos muy estrictos y las herramientas más caras del mercado si el equipo de desarrollo no sabe utilizarlos. Se trata de repartir coherentemente las responsabilidades y el trabajo del desarrollo. Debe haber una cabeza sin duda, pero la implicación y  motivación de cada miembro del equipo es decisiva para el éxito del proyecto. No será fácil aplicar este concepto si se piensa únicamente en horas/hombre (horas/recurso) como un activo del proyecto.
  • Hacemos software, no documentos. El segundo principio dice que hay que dar la importancia justa a la documentación. Si se pretende hacer una documentación exquisita con extensos documentos funcionales que recojan todas y cada una de las necesidades de la aplicación, ocurrirá una de estas dos cosas: En el mejor de los casos, el producto final no se parecerá en nada a lo planteado en estos documentos, o, en el peor, el desarrollo no empezará nunca.
  • Tendremos que hablar con el cliente. Para muchos esto es lo más duro. Trabajando en consultoría es frecuente oír decir que el cliente no sabe lo que quiere, que las especificaciones son malas, que no saben nada de informática o que cambian de opinión cada dos por tres. Seguramente, pero “that’s life”. La solución no es fácil, pero todo pasa por ser flexibles, no hacer rígidos planes al principio y sí hacer continuas iteraciones para ver que se ha hecho y que se va a hacer. Siempre con la aprobación y colaboración del cliente.
  • Ooops, algo ha cambiado. Esta es la piedra filosofal del desarrollo ágil. Hay que estar listo para el cambio. Las iteraciones de desarrollo deben ser cortas. Estar preparado para cambios de prioridades.

En resumidas cuentas, para hacer una super-aplicación, habrá que empezar haciendo un programita, mostrarlo al cliente (aunque sea interno en la empresa), recoger las sugerencias y cambios y preparar la siguiente iteración (seguramente es suficiente con una pequeña lista de tareas). Iteración tras iteración se llegará a la super-aplicación, pero mientras tanto ya tenemos algo. No olvidar nunca que estas iteraciones deben ser cortas (Scrum propone 2 semanas – 1 mes). Si no da tiempo a hacerlo todo en el tiempo prefijado, seguramente habrá alguna tarea que se pueda dejar para la siguiente iteración.

La importancia del backup

29 septiembre 2009

Partiendo de la base de que, en este negocio, todo puede fallar, hay que tener siempre un plan B para cuando la cosa se pone realmente “mal”. Normalmente se intentará evitar siempre llegar a una situación en la que sea necesario “tirar” de la copia de seguridad. Sin embargo, tener un buen backup ofrece ventajas únicas. Hacer copias de ficheros no tiene ninguna dificultad, preparar una buena estrategia sí. Veamos una serie de puntos fundamentales a tener en cuenta antes de diseñar una buena estrategia de backup para el servidor donde se aloja nuestro preciado sitio web.

No es tan importante el dispositivo físico como una buena estrategia

No es tan importante el dispositivo físico como una buena estrategia

  • Cualquier tipo problema. Un backup debe proteger ante cualquier eventualidad.
    • Un fallo de software o de programación puede hacer, por ejemplo, que la base de datos se vaya degradando paulatinamente. Sería deseable guardar una serie de estados (“fotos”) desde, al menos, el día que empezó a corromperse la información. Una copia diaria de la base de datos durante el último mes puede ser suficiente para un sitio web “vivo”.
    • Hardware. Un error común es no hacer copia de un disco duro porque está en raid-1 o espejo. Efectivamente esto salvará la información en caso de que uno de los discos se rompa, pero no lo hará en el caso de que los datos se hayan borrado por cualquier otra razón (errores de software, virus o ataques). Otro error habitual es hacer la copia dentro del mismo disco o del mismo equipo informático. Cuando es este disco o este equipo el que se rompe, de poco sirve la copia.
    • Virus, gusanos, ataques mal intencionados, etc. En realidad se podría tratar este problema como una forma combinada de los dos anteriores.
    • Catástrofes imprevisibles. Incendios, robos, etc. Si se produce un incendio o un robo en la oficina, tener el backup en otro datacenter, oficina o en casa será suficiente. Y esto escala bien, es decir, cuanto más lejos mejor, tanto lógica como físicamente. A una mente paranoica el tener la copia de seguridad en otro país le daría la seguridad de que sus datos estarán a salvo incluso frente a una guerra por ejemplo 😮
Entonces, para que un buen backup soluciones cualquier tipo de problema, hay que hacer copias periódicas. También hay que guardar el historial, hacer la copia en otro equipo físico y guardar los archivos de ésta en una localización diferente a los datos originales
  • Toda la información. A la hora de diseñar la estrategia de copia, es vital listar todos los datos que es necesario proteger. Ficheros de datos, imágenes, ficheros de configuración, bases de datos o repositorios de software. Igual de importante es tener en cuenta que la información que se va a copiar evoluciona con el tiempo y no siempre se va a copiar la misma información. Es necesario, pues, tener un mecanismo que permita mantener esta “lista” de elementos a copiar “viva”.
  • La estrategia. Con los puntos anteriores claros, preparar una estrategia se convierte en una tarea trivial. Definir a que hora se hará (seguramente cuando haya menos usuarios/tráfico) y donde se copiará la información físicamente. Una cosa importante a tener en cuenta es que, casi siempre, se trabaja con ficheros a la hora de hacer el backup. Por eso es importante que, la información que no lo es se pueda convertir antes a fichero. Un ejemplo claro son las bases de datos que, por lo general, tiene su propio sistema de backup. Otra decisión importante es si el backup debe estar cifrado o no. Aunque suene necesario, lo cierto es que muchas veces no compensa.
Para asegurarse que se copia toda la información es tan importante definir bien al principio lo que se va a copiar, como hacer revisiones periódicas de que información nueva debe ser copiada.
  • Recuperable. No sirve de nada tener una copia de seguridad que no se puede restaurar. Parece algo evidente, sin embargo es sorprendente la cantidad de veces que ocurre que al intentar recuperar un dato copiado, el backup está corrupto, vacío o simplemente se descubre que el backup ¡nunca se ha hecho! Ojo también al utilizar cifrado para almacenar las copias. Siempre debe haber, al menos, dos personas con la llave y/o la contraseña y asegurarnos de que realmente es así
La única forma de asegurarse que la información está correctamente guardada es hacer “simulacros” restaurando el backup de vez en cuando.

Herramientas libres para Voota

14 septiembre 2009

Decir que utilizamos únicamente software libre es muy bonito, pero a la hora de ponerte a buscar las herramientas que se van a utilizar, hay que poner mucha atención. Hagamos un pequeño repaso del software más importante que hemos escogido y por qué para construir Voota.

php (vs java)

La única duda que se nos planteó era utilizar java o php. Ambos tienen sin duda puntos a favor y en contra. A favor de Java podemos decir que es, sin duda, uno de los lenguajes más robustos y que mejor implementa aspectos como la herencia y el polimorfismo. Es el lenguaje que yo elegiría para aplicaciones grandes y con cálculos complejos (bancos, compañías de seguros o aplicaciones internas en empresas grandes).

Sin embargo, cuando los requerimientos de agilidad y rendimiento son críticos, php manda. Así, ulizando php ganamos fundamentalmente en dos cosas: Velocidad y velocidad, o lo que es lo mismo, en tiempo de desarrollo y en rendimiento en ejecución. He aquí algunos mitos que hay que ir olvidando:

  • php no es un lenguaje serio: Es posible que esto fuera cierto en las primeras versiones, pero desde php5 ya es un lenguaje orientado a objetos real  y con todas las características necesarias para para hacer software de calidad.
  • php solo lo usan sitios pequeños. No se por qué razón me ha tocado oir tantas veces frases como esta, pero el hecho de que Wikipedia, Facebook o Yahoo estén en php habla por sí solo.

Si la única pega de php es, pues, que no es tan robusto y, quizá, “estricto” como Java, la solución pasa por utilizar un framework que ponga “orden” y estructura en la aplicación.

Herramientas para Voota

Herramientas para Voota

symfony

Hay varios frameworks haciendo la competencia a symfony: CakePHP, Zend y muchos otros. En realidad cualquiera de ellos ofrece servicios similares (diseño 3 capas, scaffolding, etc.). La elección de symfony es, sobre todo, por ser el más utilizado dentro de la comunidad opensource, por la calidad del código y por el soporte (usuarios, plugins y código ya desarrollado). Desde nuestro punto de vista la eterna cuestión de si se debe usar un framework o, por el contrario, cada desarrollo debería llevar su propio código (al menos de base) está obsoleta: No utilizarlo, es colgarse un yunque del cuello.

mysql (vs postgres)

No hay una razón real para no utilizar una base de datos tipo postgres. Realmente las dos son fiables. Utilizamos mysql principalmente porque es la utilizada “por defecto” en entornos LAMP. En cualquier caso utilizaremos siempre un sql lo más estándar posible para mantener la máxima independencia de la base de datos. Cosa que por otro lado también nos proporciona Symfony.

svn (vs git)

A pesar de que últimamente parece estar muy de moda utilizar git como repositorio de software, hemos optado por subversión. Las razones son simples: Es el más maduro, el que mejor se integra con otras herramientas que utilizamos (Eclipse, Trac, etc.) y porque nos da todas las funcionalidades que necesitamos.

Trac

Pocas alternativas tenemos a Trac. Permite publicar todo lo necesario a través del wiki, tiene un sistema de tickets muy potente, se integra a la perfección con el repositorio de software, y sobre todo es muy muy muy simple de manejar. ¿Qué no? Te invito a que lo compruebes 😉

http://trac.voota.org/

Pootle

Una agradable sorpresa. No tenía el gusto de conocer esta pequeña herramienta. De hecho todavía la tenemos como “experimento”, pero cada día nos gusta más. Ofrece una interfaz web para traducir las etiquetas de cualquier aplicación y admite tanto los clásicos “.po” de toda vida, como los modernos “.xliff” utilizados por Voota.es.

Otras herramientas que estamos utilizando para un futuro no muy lejano son OTRS (ticketing system) y OpenERP como aplicación de gestión. A lo mejor próximamente son motivo de un nuevo post …

Libres desde el inicio: Voota con software libre

13 agosto 2009

No hace mucho que Frans me habló de su idea de crear un sitio web de opiniones sobre políticos. En ese momento la idea me pareció genial, pero no tanto como cuando poco después dijo: “¿Te apuntas?” … y me apunté.

¿Por qué me apunté?

  • Por el fin. Hacerte sentir que el sr. Político te representa de verdad. Permitirte participar en la política, informarte y permitirte opinar de la gente que nos gobierna o que aspira a hacerlo.
  • Por los medios: Utilizar software libre. Hace ya tiempo que me puse el objetivo a largo plazo de fomentar y trabajar con software libre. En esta ocasión, pretendo dar a conocer todas las herramientas, procedimientos y desarrollos que vayamos utilizando. La idea es demostrar y explicar como es posible hacer cosas bien hechas utilizando únicamente software libre.
  • Por compartirlo. Crear software libre. Todos los contenidos serán de libre distribución. Pero mucho más que eso, lo que pretendemos es liberar todo el software desarrollado y poner las herramientas necesarias para que otros puedan colaborar y compartir. Y, sobre todo publicar nuestros desarrollos para que otros países y/o personas puedan hacer otro “Voota” con el mismo software.

Herramientas como Trac permiten compartir y gestionar Voota

Trac nos permite compartir y gestionar Voota

Este será, pues, un blog mayormente técnico, donde iré contando y explicando como vamos creando las cosas, desde el lenguajes de programación, frameworks y otras herramientas hasta procedimientos de gestión de ciclo de vida, configuración de servidores, etc.

Espero que te guste.

Más información sobre Voota:

Posts relacionados:

Posts relacionados:

Starting engines

17 junio 2009

Muy pronto … aquí mismo …