Posts Tagged ‘desarrollo web’

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 😉

Anuncios

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 !

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.

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: