Convenciones

Tengo una teoría: todo profesional del código -sea frontend, backend-, con la suficiente dosis de presión, ñapeará su código, independientemente del punto de partida rompiendo las convenciones.

De Rails me resulta fascinante la idea de que, en un framework con cierta complejidad, se hayan creado convenciones coherentes. Si ya hay problemas, desacuerdos y cierto caos cuando estás creando una plantilla sencilla de HTML o una CSS, imagínate la tendencia al caos que puede tener desarrollar un framework por "muy bello" que pueda resultar Ruby .

De hecho... así son las cosas: tienes un framework limpito y ordenado como punto de partida sobre el que vas desarrollando, y poco a poco te das cuenta de que pierdes el criterio a la hora de nombrar métodos, componentes, etc.

Ese es el poder de las convenciones: tener las cosas claras y empezar en pequeñito, o sino, échale un vistazo a los microformatos. (Si te suenan pero no sabes lo que son lee aquí: Microformatos. La Web Semántica para Torpes )

Cambios en Rails 2.0

Nada dura para siempre, y la versión de Rails 2.0 va a eliminar antiguas maneras de trabajar para crear convenciones más coherentes con lo desarrollado hasta ahora.

Así, trabajando en la consola van apareciendo los famosos "DEPRECATION WARNING", o avisos de código que no será soportado en el futuro como es el caso de la etiqueta del helper end_form_tag: DEPRECATION WARNING: end_form_tag is deprecated and will be removed from Rails 2.0 See http://www.rubyonrails.org/deprecation for details.

No es el único cambio. Hazles caso y échale un vistazo a Rails 2.0 Deprecation.