Sinatra Modular Applications with Ruby 1.9

Disclaimer: what I write here is something that is working for me, but I am not an expert, so I cannot declare this to be the best solution.

I am working on a small application that I know it will grow, so the traditional Sinatra application could be a mess when I have more than 10 routes.

So the strategy I have chosen is to create a base class called BaseController inheriting from Sinatra::Application, this base clase will handle global application settings.


#./base_controller.rb
require 'sinatra/base'

class BaseController < Sinatra::Base
  get '/' do
    'Home (base controller)'
  end
end

Then, I create one controller class for each application module, each of this controllers should inherit from my BaseController.

#/controllers/module1_controller.rb
require File.join(File.dirname(__FILE__),'..', 'base_controller.rb')

class Module1Controller < BaseController
  get '/' do
    'Module 1'
  end
end

Finally, in the config.ru file I define the base routes for each controller.

# config.ru
require './base_controller.rb'
require './controllers/module1_controller.rb'

map '/' do
  run BaseController
end

map '/module1' do
  run Module1Controller
end

Note: the code snippets above assume that the base_controller.rb and config.ru files are located in the root directory while every all controller files are located under “/controllers” directory.

You can download the source code from here.

(FIUBA + Pharo)++

El próximo lunes 19 de diciembre a las 17 hs. en el Laboratorio “E” del 4to. piso, el estudiante Diego Kogan presentará su Trabajo Profesional titulado “Herramienta de integración continua para sistemas desarrollados en Pharo”, que desarrollara  bajo la dirección del Ing. Guillermo Pantaleo.

El trabajo consiste en el desarrollo de una herramienta que da soporte a la práctica de integración continua para sistemas desarrollados en Pharo. Dicha herramienta esta desarrollada íntegramente en Pharo. La herramienta permite ejecutar un conjunto de tareas de verificación  de software sobre un proyecto Pharo, entre ellas:

  • Test.
  • Cobertura de Tests.
  • Inspecciones de Código.
  • Reportes de Builds.
  • Integración con Monticello (SCM para squeak/pharo).

En verdad suena interesante, porque si bien la práctica de integración contínua es común en Pharo, en general suele utilizarse Jenkins. Espero poder hacer un rato para asistir.

Censo Docente UBA (+1)

Hace un tiempo escribí sobre mi experiencia completando el censo docente de UBA. La buena noticia es que el mensaje que envié vía la página de visitas de la UBA, llegó a buen puerto y me contactaron vía mail. En el mail me daban algunas explicaciones y me pedían más detalles sobre los puntos flojos que yo mencionaba. Algo que me llamó la atención es que algo que yo veía como un issue, para los responsables del censo es en realidad un feature. Puntualmente estoy hablando del feature/issue que impide que uno regrese a modificar los datos ingresados en una sección del censo luego de haberla completado.

En fin, ayer me senté y contesté el mail, dando tantos detalles como recordaba (pues el sistema no me permite ingresar otra vez para analizarlo). Al mismo tiempo, para cada punto mencionado, intenté sugerir una posible solución y finalmente envié un link al material de usabilidad que vemos en algo3.

Más allá de las opiniones y de si tienen en cuenta mis comentarios o no, creo que lo importante es que dieron una respuesta a mi inquietud a pesar de que la misma fue enviada por un canal informal. Esto es algo que en instituciones tan grandes y burocráticas como UBA muchas veces es difícil.

Censo Docente UBA (-10)

Ayer completé el censo docente de UBA. Me cuesta describir el sentimiento que me generó, creo que está en tristeza e indignación:

  • Tristeza porque a nivel usabilidad el sistema del censo deja mucho que desear y dado que estoy muy involucrado con la institución, me duele que contando con excelentes profesionales, no se haya podido generar un sistema mejor.
  • Indignación, porque a los a que hicieron ese sistema habría que encarcelarlos de por vida. No entiendo que pasó por la cabeza de quien hizo el sistema. Es evidente que no es una cuestión de un programador solamente, sino también del usuario que encargó el sistema.

El censo es básicamente un serie de preguntas divididas en varias páginas, donde la cantidad de preguntas es dinámica. Entre los puntos destacados están:

  • Positivo: al final de cada página es posible guardar las respuestas y seguir completando el resto en otro momento.
  • Negativo: una vez completada y guarda una página, no es posible volver a modificar un dato ingresado.
  • Negativo: el sistema no ofrece ningún medio de contacto para consultas técnicas y/o envió de feedback.
  • Negativo: campos de selección (lo que técnicamente llamamos dropdown list) con muuuuuchos items, lo cual resulta muy incómodo
  • Negativo: algunas preguntas no estaban redactadas de forma clara, con lo cual es posible que haya mandado frutanga.

Una vez que lo completé quise enviar feedback, pero como no encontré ningún medio para hacerlo en el sitio del censo, terminé enviando el feedback vía el libro de visitas de la página de la UBA.

Como la crítica por si sola no suma, me ofrezco a dar una mano (en forma totalmente gratuita) para mejorar el sitio o incluso para actuar como consultor en la construcción de otros sistemas de la universidad.

Con lo cual, si alguien conoce a los responsables del sistema del censo, por favor que no dejen de contactarme.