Bueno, parece que me han escuchado. El capítulo 4 del tutorial va sobre Ruby más que sobre Rails, para profundizar en el lenguaje y entender conceptos básicos (más allá de lo que viene siendo una variable de instancia…). Lo que voy a hacer es definir un helper para construir el contenido de la etiqueta title, en vez de usar una cadena concatenada a una variable. Para ello edito el app/helpers/application_helper.rb y añado esto:

Siguiendo con el tutorial, ya sé añadir páginas y enrutarlas, va siendo hora de añadir algo de contenido dinámico a las páginas. Voy a hacer que el título cambie según la página en la que este. Y esto es lo que voy a chequear con TDD, es decir, que al solicitar /pages/home el título vale Home y que al solicitar /pages/about, el título vale About. En rspec, quedaría algo así:

Estoy rememorando mi trabajo de hace 8 horas… variables que no sabes si se usan en otro sitio, temor a limpiar cosas, en fín… una pesadilla. Por eso, ESTE es el momento de empezar el testing en la aplicación RoR, he hecho un controlador (vacío, sí) y es hora de asegurarnos que ahora y siempre haga lo que tiene que hacer (nada). El tutorial, aparte de recomendar TDD y contarte que RSpec es un domain specific language para hacer pruebas en Ruby, dice de instalar autotest, una herramienta que ejecuta continuamente las pruebas sobre los archivos cambiados. Vaya, que si toco un controlador me ejecuta las pruebas dándome feedback instantáneo, una primera aproximación a la integración contínua. Amos a ello.

Como el entorno de desarrollo se ha caído y llevo dos horas aburrido, sigo. Segundo Ítem: Usar siempre SIEMPRE la integridad referencial. O lo que es lo mismo, si usamos MySQL NO usar MyIsam, ya que no tiene soporte para integridad referencial. Hay gente que dice que trabajar sin integridad referencial es más rápido y cómodo. Es verdad, pero al final es como dispararse en el pie. Muchas veces la integridad referencial te salva de cometer errores de calado. Por ejemplo, si borramos los usuarios de un foro, ¿quién sale como autor de sus posts? Por tanto no podemos “borrar” los usuarios, hay que recurrir a un “borrado lógico”, es decir, un campo activo o borrado o como se le quiera llamar. El inconveniente, que puede ser que nunca borremos.

En general en una aplicación Java cualquiera los problemas empiezan desde abajo, con el diseño de la base de datos. He visto (y trabajo) con bases de datos en las que una tabla tiene 5 campos de primary key y uno solo de información. Que esto es un desperdicio se ve a simple vista. Después vienen los parches a nivel superior (en Java) y se termina yendo al infierno el rendimiento de la aplicación. Lo bonito, y lo malo del diseño de base de datos es que no te terminas dando cuenta de que esta mal hasta que la aplicación esta avanzada, empieza a crecer y en ese momento es tarde para cambiarlo. Vamos, que es un infierno.