Cuando comenzamos a pensar cómo debería ser el nuevo sitio de Buenos Aires teníamos en claro que necesitábamos:
- Poner el eje en el ciudadano
- Geolocalización
- Orientacion a servicios
- Usabilidad
- Carga de contenido descentralizado
- Roles y Permisos
- Flexibilidad sin perder coherencia y navegabilidad
- Performance
Teniendo esto como premisa comenzamos a evaluar qué plataformas podíamos emplear para el desarrollo. Todas las flechas apuntaron a Drupal.
No solamente porque cumple con los puntos de arriba sino porque además cuenta con las siguientes ventajas:
- Comunidad
- Escalabilidad
- Software Libre
- Ampliamente utilizado en sitios de e-govermment y sitios de alto tráfico
- Gran cantidad de módulos preexistentes
Una vez elegida la plataforma pasamos a seleccionar los módulos que íbamos a emplear y la infraestructura básica necesaria considerando las necesidades antes planteadas.
Se utilizó un HAProxy para el ruteo de las peticiones, Varnish para cache y balanceo de carga y dos servidores con un stack clásico LAMP.
Los módulos que forma el core de la lógica de negocio son:
- Panels
- Views
- OG
Para la confección del layout utilizamos panels ya que permite que no-programadores puedan agregar bloques sin la necesidad de asistencia por parte del equipo de desarrollo, desafectando al mismo de tales tareas. Si bien el módulo de paneles permite regular el ancho de las columnas, para este fin se empleó 960 Grid System asignando las clases necesarias en los paneles correspondientes.
El módulo de views es sin duda el módulo más empleado de todo el sitio. En algunas circunstancias no es posible realizar un deploy con velocidad que precisa la gestión y es ahí donde contar con una interfaz que nos permita hacer modificaciones críticas on-the-fly es de gran valor.
Por otra parte, el hecho de poder sobreescribir de forma granular hizo más simple el trabajo de maquetación haciendo que nuestro equipo de desarrollo se concentre en la lógica de negocio.
El módulo de OG se hizo necesario al estar frente a una organización tan compleja como lo es un gobierno.
En nuestra lógica cada área de gobierno es un grupo que puede contener n nodos y los cuales a su vez pueden ser áreas. Esta distribución permite relacionar contenido y generar permisos de usuarios por grupo.
Por otra parte OG fue utilizado en el desarrollo del módulo para la geolocalización de contenidos permitiendo asociar n nodos a un tipo de contenido “Mapa”. La Ciudad cuenta con un sistema de mapas propio desarrollado sobre Open Layers el cual nos permite geolocalizar los datos con los que cuenta la misma. Utilizando los servicios expuestos por este sistema se implementó un widget que
permite mostrar dentro del mapa los diferentes nodos que están asociados a este.
Por esto, cada content type contiene un campo “Dirección” que permite la carga de esta dirección, normalizada y transformada en un punto del sistemas de coordenadas propio de la Ciudad. Una view es la encargada de listar los mapas asociados al nodo que se visualice y con un formatter se imprime cada dirección relacionada a ese mapa en forma de marker.
Además al momento de generar el mapa es posible asignarle una de las capas con las cuenta nuestra Unidad de Sistemas de Información Geográfica.
Para la integración del desarrollo utilizamos el módulo Features y Drush. Desarrollamos en Python con Fabric un script que se encarga de hacer update de cada feature antes de realizar un commit y revertir las mismas luego de un pull. El mismo script se encarga de abrir tareas, cerrarlas, actualizarlas y computar horas de desarrollo desde consola hacia el sistema de gestión de proyectos Redmine. El próximo paso es utilizar este script con Jenkins poder efectuar una integración continua.
Si bien el eje del sitio está puesto en el ciudadano también es cierto que el mismo constituye una pieza fundamental en la comunicación de la gestión, es por ello que contamos con un Ad Server Openx y un módulo en Drupal que se encarga de utilizar cada una de las zonas generadas en el Ad Server para mostrar la pauta correspondiente a la zona que se está visualizando. Dicho módulo genera un bloque por cada zona creada y cada bloque es puesto en el panel que corresponda. Cabe aclarar que la “pauta” se administra en relación a las necesidades de comunicación de la gestión y no hay ningún pago de por medio.
Uno de los pedidos más frecuentes con el que nos encontramos es la creación de formularios. Si bien existen varias alternativas en drupal.org, ninguna se adecuaba los suficiente a nuestras necesidades. Por este
motivo creamos un módulo propio que permite generar formularios desde la interfaz del administrador de Drupal y enviarlos en formato serializado a un servicio creado con Python+Django. En dicho servicio, es almacenado también el resultado de los formularios. ¿Por qué? Porque permite sacar decenas de miles de nodos de la base de datos de Drupal y no colocar datos que son de terceros y hacernos responsables del mantenimiento de dichos datos.
Por último y no menos importante utilizamos como motor de búsqueda Apache Solr y lo integramos con un módulo desarrollado por nosotros y que nos permite realizar búsquedas segmentadas.
