Algunas de las características que me han llamado más la atención por el uso inmediato que voy a hacer de ellas o por su potencial futuro:

- Internacionalización i18n. Aún existiendo numerosas opciones para internacionalización (tal como gettext, globalize, etc), sin duda es una de las características que más se le echaban en falta a Rails desde hacía tiempo. Nosotros en Tog habíamos empezado a internacionalizar utilizando esta característica que estaba disponible en el Edge.

- Compatibilidad con Ruby 1.9 y con JRuby. Mucho es el trabajo que se ha realizado para utilizar las nuevas características del lenguaje mejorando el rendimiento y adaptándose a la nueva versión de Ruby.

- Documentación. En este sentido caben destacar las guías, donde se está realizando una labor de documentación increíble. Aquí podemos apuntar un nombre de alguien que a todos os sonará por su labor: Xavier Noria. Sin duda uno de los puntitos para haber sido elegido personaje Rails 2008 .

- Mejoras en HTTP. Soporte de ETag y Last-Modified que responderán con una respuesta vacía si la página no ha cambiado.

- Thread Safety. Threads en rails; sin duda un tema complejo, para el cual os recomiendo leer una explicación realizada por Charles Nutter.

- Migraciones transaccionales. Desde ahora los errores producidos en una migración harán que la migración no se ejecute, como hasta ahora, pero también que quede registrado todo el proceso de la misma como inválido, restableciendo el estado de la base de datos a la migración anterior.

- Pool de conexiones. Podemos manejar un pool de conexiones para conectarnos con la base de datos, fácilmente configurable en nuestro database.yml.

- Resources con acciones específicas. Hasta ahora cuando creabas los resources automáticamente para un modelo se creaban las 7 acciones por defecto: index, show, create, new, edit, update y destroy. Sin embargo esto tiene un gasto de memoria extra y crea una lógica que en ocasiones no tienes porqué usar, por lo que ahora puedes seleccionar cuales te interesan:

map.resources :articles,  nly => [:index, :show]

- Action Mailer: Ahora dispone de soporte para layouts; tal como el resto de nuestras vistas.

- Se incluye también soporte para cuentas de Gmail, aunque esto requiere de la versión 1.8.7 de ruby.

Existen más características e información ampliada de todo lo aquí mostrado en la nota publicada de esta release.

Paso uno e indispensable, instalación del plugin:

script/plugin install http://svn.ambethia.com/pub/rails/plugins/recaptcha

Si queréis, podéis utilizar la última versión del plugin, que está alojada ahora en github, por lo que si no habéis experimentado con git aún, os lo recomiendo como experiencia para empezar a utiliar git.

Por si os interesa lo anterior, el plugin ahora se encuentra en: http://github.com/ambethia/recaptcha.

Lo primero que os recomiendo es que vayáis a Recaptcha y obtengáis vuestras llaves, pública y privada, que hacen falta para poder utilizar el plugin; en mi caso ya las estaba utilizando en este blog. No os las pego por seguridad y porque no os servirían, dado que están asociadas a la url en cuestión.

Una vez las tenéis, deben ser añadidas a environment.rb de la forma:

ENV['RECAPTCHA_PUBLIC_KEY'] = 'tullavepublica'
ENV['RECAPTCHA_PRIVATE_KEY'] = 'tullaveprivada'

En la vista, para mostrarlo, sólo tendríamos que añadir:

<%= recaptcha_tags %>

en caso de estar utilizando ssl, deberéis cambiarlo a:

<%= recaptcha_tags :ssl => true %>

Y ahora en nuestro método de publicación, debéis comprobar la validez del Recaptcha, de la forma:

if verify_recaptcha
      ...
      else
      flash[:error] = "Ha habido un error en el envio."
      render :action => 'show'
    end

Nosotros lo utilizamos para publicar comentarios, por lo que el método en cuestión queda como sigue:

if verify_recaptcha
      @entry = Entry.find(params[:id])
      comment = Comment.new(params[:comment])
      @entry.add_comment comment
      comment.save!
      flash[:notice] = "Comentario añadido con éxito"
    else
      flash[:error] = "Ha habido un error en el envio del comentario."
    end
    redirect_to :action => 'show'

Pues nada, listo, ya tenéis validación con Recaptcha en vuestros comentarios.

Algunas de las funcionalidades aportadas son:

• avanzar y retroceder en nuestro código mientras debugeamos.
• ejecutar o saltar líneas de codigo
• listar el contexto actual en el que estamos detenidos
• realizar cambios en caliente sobre el código y poder recargar
• usar el modo irb, además de tener un modo consola propio más potente que el anterior

Para comenzar a utilizarlo, basta con tenerlo instalado, para ello:

sudo gem install ruby-debug

He observado que en algunos lugares, te recomiendan estar atento a la instalación, para seleccionar la plataforma sobre la que se va a instalar: Linux/Mac o Windows. Aquí tengo que decir que en mi caso, sobre Mac OS X, no tuve que elegir plataforma, dado que fue seleccionada de forma automática.

Para empezar a hacer uso del plugin, debemos configurar algunas cosas; la primera de ellas es añadir una línea a nuestro environment.rb:

SCRIPT_LINES__ = {} if ENV['RAILS_ENV'] == ‘development’

Con esto debemos de ser cautelosos. SCRIPT_LINES__ almacena todos los ficheros ruby leidos en un hash para poder decir luego en qué línea de código estamos. Esto sin duda puede causar problemas de rendimiento y algunos de consumo de memoria, de ahí que hayamos puesto que sólo se use en desarrollo. Debemos tener mucho cuidado para que no activemos el debug en entornos de producción.

Una vez, tenemos esto, bastaría con situarnos en nuestro código y añadir lo siguiente para poder empezar a debugear allí mismo:

require ‘ruby-debug’
…
def your_method
…
debugger if ENV['RAILS_ENV'] == ‘development’
…
end

El debug se parará justo en debugger.

Ahora arrancamos el servidor web el cual se detendrá en nuestro breakpoint y estaremos en modo consola en el mismo terminal en el que el servidor estaba trabajando, como decíamos es una consola más potente que IRB, algunos la comparan a GDB, el debugger de GNU para C.

En este momento, ya podemos interacturar, bastaría con conocer los comandos y podríamos debugear. Una lista de los más indispensables:

list: te muestra unas líneas de código y te dice donde estás detenido.

irb: pasas a la consola de IRB, puedes interactuar con los objetos, obtener valores, etc. Por ejemplo para ver el valor de una propiedad:

@users.name

exit: salir del IRB

PP (pretty print): para ver el contenido de forma bonita, por ejemplo un formulario:

pp params[:user][:email]
o
pp params

cont: continúa la ejecución

next: avanza a la siguiente línea de código

method: para listar los métodos de un objeto:

method instance @user

o si queremos listar los métodos de una clase:

method User

break: para ir a un sitio dado y saltar todo lo demás:

break Entry#create

para ir al método create de Entry

set autoreload: recarga el código para aceptar los cambios

Cual ha sido mi sorpresa cuando en una de las actualizaciones del sistema venía la nueva versión del JDK. Sin embargo esta release no se convierte en la release por defecto, sino que si deseas utilizarla, debes hacer los cambios por ti mismo.

Investigando un poco logramos la ruta física donde se instalan todas las versiones de los JDK de java descargados:

/System/Library/Frameworks/JavaVM.framework/Versions

Además de todas las versiones, existen tres directorios llamativos: A, Current y CurrentJDK; estos dos últimos directorios son symbolic links a la versión que interesa. Lo que significa que para cambiar de versión del JDK sólo hay que cambiarlos a ellos.

Si buscáis por internet encontraréis un script bastante utilizado, que nos muestra las JDKS que existen instaladas en vuestra máquina y cambia el CurrentJDK a la versión que queramos. Sin embargo, habría que completar este script. Ambos Current y CurrentJDK deben ser cambiados o algunos programas os dejarán de funcionar. La verdad es que por lo que he encontrado, lo único que he podido sacar en claro es que hay algunas razones por las que no cambiar CurrentJDK:

it affects the system globally, it changes the system from how Apple shipped it (things under /System are Apple managed), and it can cause updates to fail and/or have unintended side effects.

Si aún así queréis seguir adelante con el cambio podéis hacer lo siguiente.

Un vistazo rápido al directorio : /System/Library/Frameworks/JavaVM.framework/Versions/ os devolverá algo parecido a:

weemac:Versions jenaiz$ ls -la
total 56
drwxr-xr-x 14 root wheel 476 15 jul 08:59 .
drwxr-xr-x 11 root wheel 374 4 jul 08:08 ..
lrwxr-xr-x 1 root wheel 5 7 may 20:39 1.3 -> 1.3.1
drwxr-xr-x 3 root wheel 102 29 sep 2007 1.3.1
lrwxr-xr-x 1 root wheel 5 21 oct 2007 1.4 -> 1.4.2
lrwxr-xr-x 1 root wheel 3 7 may 20:39 1.4.1 -> 1.4
drwxr-xr-x 8 root wheel 272 21 oct 2007 1.4.2
lrwxr-xr-x 1 root wheel 5 21 oct 2007 1.5 -> 1.5.0
drwxr-xr-x 8 root wheel 272 21 oct 2007 1.5.0
lrwxr-xr-x 1 root wheel 5 7 may 20:39 1.6 -> 1.6.0
drwxr-xr-x 8 root wheel 272 7 may 20:39 1.6.0
drwxr-xr-x 8 root wheel 272 7 may 20:40 A
lrwxr-xr-x 1 root wheel 1 15 jul 08:57 Current -> A
lrwxr-xr-x 1 root wheel 3 15 jul 08:59 CurrentJDK -> 1.5

Como podéis ver, en estos momentos mi CurrentJDK está usando la 1.5 y mi Current apunta a A.

Para hacer que el JDK 1.6 sea el actual, tendréis que hacer:

ln -hfs 1.6 Current
y
ln -hfs 1.6 CurrentJDK

Así es tal como darrell lo explica, y es parecido a como el script lo hace. Todo esto hay que hacerlo como super usuario.

El porqué algunas aplicaciones dejan de funcionar hay que encontrarlo a que existen algunos problemas en esta versión, que Apple no ha considerado en solucionar aún:

- Sólo soporta 64 bits: adios a los applets en Safari.
- No hay soporte para Cocoa: aplicaciones como Cyberdurk dejarán de funcionar. Esto no sólo significa que no podamos tener look&feel de Mac OS sino que también perderemos algunas de las utilidades tales, como poder usar Growl como sistema de notificación, por ejemplo.

Si el tema de cómo está organizado el directorio de versiones de Java y el porqué de esta cosas, os interesa realmente, os dejo unos links interesantes sobre todo esto, no sólo aplicable al JDK:

Anatomy of Framework Bundles
Framework Versions
What are Frameworks?

La respuesta viene de varias fuentes, pero la conclusión es la misma. La versión 1.9.0 no es estable, es una versión para desarrollo, no para entornos de producción. Se recomienda hacer compatible tu código con ella, para que el paso a la nueva versión de producción sea menos traumático, pero no se recomienda hacer uso de ella en entornos de producción, sino esperar a la release que sí será lanzada para ello, la 2.0.

El cambio puede ser algo traumático, así que un listado de las características nuevas ha sido publicado en eigenclass; es aconsejable echarle un vistazo, pues vienen ejemplos de lo nuevo.

Si queréis leer opiniones al respecto, quizás la trazada por Dave Thomas en su blog os guste; os advierto que la conclusión es la misma.

En realidad su código actual dicta mucho de ser bueno, teniendo en cuenta que está en sus primeras fases, y que de momento no se ha buscado una gran amalgama de funcionalidades, sino más bien cerrar una versión 0 de la que partir y ampliar.

He leido en algunos lugares, que para que la gente se anime a mirarlo, probarlo y quizás hasta a participar en el desarrollo, es bueno tener una versión descargable, no del subversión, sino en un zip y unas instrucciones básicas con las que se pueda empezar.

En estos momentos está planificada una versión light de belegost, con unas funcionalidades mínimas que hacen al sistema usable, pero sólo para un desarrollador, no es apto para entornos productivos, solo para jugar con él. El problema es que al leer por la red determinados artículos, me da la sensación de que no he logrado mucho hasta ahora, y de que quizás esto no anime sino que tire para atrás a personas que quisiesen participar en el desarrollo.

Por no hablar de que si alguien está valorando sistemas de weblogs, se podría llevar una impresión horrorosa comparado con los demás sistemas que existen en la red.

Así que ahí van unas preguntas al aire, ¿sería bueno lanzar un versión 0.0.0 – beta – development? o ¿sería mejor esperar a tener una versión 0.0.1 – beta para entornos productivos?

He visto en la web de IBM que los sistemas operativos para los que que esta JVM es distribuida son:

- Linux® on x86
- Linux® on PowerPC® 32-bit
- Linux® on PowerPC® 64-bit
- Linux® on AMD64/EM64T
- IBM AIX® on PowerPC 32-bit
- IBM AIX® on PowerPC 64-bit

Al ver esto, se me plantea una duda con respecto a la elección de IBM de no soportar plataformas Windows. Siendo totalmente prácticos e irreflexivos, podríamos pensar que esta estrategia está totalmente equivocada, tengamos en cuenta que la mayor parte de usuarios cuentan con Windows como sistema operativo; y claro, esto podría llevarnos a fabricar la hipótesis, ¿algo errada!, de que su estrategia empresarial está totalmente equivocada, dado que de esta forma no van a conseguir que su JVM sea utilizada por el público en general, ni por los desarrolladores que tengan que trabajar en entornos Windows, que son unos pocos.

Quizás, la hipótesis pueda ser otra. IBM como gigante de la informática que es, cuenta con muchas vías de negocio dentro de la compañía y una que no debemos olvidar son sus máquinas. Dispone de una vía de negocio muy amplia con el negocio de servidores. No parece extraño pensar, por lo tanto, que si optimizas un JVM para los sistemas operativos que más se utilizan en tus máquinas, a la vez estás haciendo más atractivo el potencial que ofrecen tus servidores frente a los del mercado. En este punto no podemos olvidar que el principal representante de Java, Sun MicroSystems, también trabaja en ese mercado.

Por otro lado, me asalta la curiosidad. Si planteo un caso hipotético, un caso en el que el usuario de partida trabaja sobre windows, y realiza todo su desarrollo en dicha plataforma, necesita utilizar un JDK para ella, pongamos por caso que utiliza el de Sun, tras meses de desarrollo, su aplicación a sido preparada para un JDK, y ha sido más que probada, hasta la saciedad si se ha contemplado bien el tiempo de pruebas dentro del proyecto. Cabe hacerse la pregunta de si verdaderamente dicho software debe terminar o no ejecutándose en una JVM para la que apenás ha sido probada. Podrían presentarse, ¿incompatibilidades? Entiendo que no deberían de ser con respecto al lenguaje, pero cuando uno hace las cosas de diferente manera (me refiero a la JVM de IBM) se enfrenta a que quizás lo que el programador consideró más óptimo en un JDK-SUN no lo es en un JDK-IBM, por lo que parte del trabajo que se realizó en la fase de pruebas de desarrollo se ha perdido por completo. Además si hacemos bien las cosas, el salto de desarrollo a preproducción, implicará en la mayoría de los casos un tiempo extra para ver si el JDK-IBM continúa funcionando correctamente y nos ese mayor rendimiento del que hablábamos.

Preguntas que se me ocurren para aquellos que hayáis cambiado de un JDK-SUN a un JDK-IBM: ¿Es considerable el tiempo empleado en probar con un JDK y luego con el otro? Dado el modo en el que se suelen hacer las cosas para los cambios de desarrollo a preproducción y finalmente a producción, ¿os arriesgaríais a cambiar de una a otra?

A todo esto, ¿no os parece que así se pierde, un poco, una de las principales características de java, la multiplataforma?

(Más características).

Una de mis principales necesidades era que el sistema debía de ser ligero y ofrecer la mejor respuesta con una máquina algo lenta. El mayor problema que se presentaba a este respecto era de memoria Ram. Valoré principalmente sistemas basados en PHP y algunos en java.

Algo a tener en cuenta es el uso que se le va a dar a la herramienta que buscamos, en mi caso es sencillo, máximo 365 post al año (algo que no he alcanzado nunca) textos de una media de 2500 caracteres, un único usuario, y algunos plugins que hagan esta labor más sencilla; aquí incluyo: últimos comentarios, calendario, estadísticas y similares.

Aquí va un análisis particular de los sistemas que estuve valorando.

mambo: corre sobre php + mysql, es open source, multisitio, multilenguaje, puede emplearse para ecommerce, dispone de foros dinámicos y encuestas, válido en múltiples sistemas operativos (Linux, FreeBSD, MacOSX server, Solaris, AIX, SCO, WinNT y Win2K). Todas las características aquí.

El caso es que mambo no es un sistema de blogs es un gestor de contenidos, un CMS. Y la inmensidad de utilidades, tareas, herramientas, plugins, etc. Están pensadas para convertirlo en algo profesional, bastante ideal para generar el contenido de un web de empresa con multitud de documentos y de usuarios.

Lo descargué, instalé y empezé a jugar con él, y ciertamente, yo lo había visto utilizar como sistema de blog, pero en seguida noté la inmensidad del mismo. Era un sistema demasiado complejo, demasiado avanzado para utilizarlo gestionando los post que yo realizo en el sistema. El sistema de administración, su gestión multiusuarios con distintos tipos de privilegio, la gestión de los temas a publicar, etc. Me pareció demasiado completo y amplio para lo que yo estaba buscando.

Entre todo el laberinto que me ofrecía Mambo y por el que estaba viendo que me perdía, por la grandiosidad de la aplicación, descubrí a Joomla, y al final decidí que era mucho más de lo que andaba buscando.

Roller: fue mi segundo candidato. Digamos que para utilizar este, no llegué a dar el paso de instalarlo y probarlo. Ya lo conocía de usarlo en jH y conocía los problemas que había dado en su administración, y que se debía de dedicar bastante tiempo a la administración y mantenimiento del sistema. La verdad es que en este caso había sido utilizado por bastantes más usuarios de los que yo había pensado tener en ningún momento, pero aún así, la mala experiencia con él no me motivaba demasiado.

No sólo esto fue por lo que quedó descartado, sino que el equipo con el que contaba tampoco ayudaba demasiado a probar. 256 Mb de Ram con un apache+java+tomcat+mysql no es una buena combinación. De hecho cuando medía rendimientos con la instalación básica de este equipo, veía que era totalmente inviable utilizar nada desarrollado con java, puesto que no podría dar un servicio ni tan siquiera medio decente.

serendipity: Bueno, la verdad es que empecé a mirar más los sistemas basados en php y en mysql frente a otros. Montar un sistema con un apache+php+mysql no requiere de tanta potencia como uno desarrollado en java. Y en mi caso no tenía ninguna pretensión de tocar el código, sólo quería que funcionase, adaptar algún template y a correr.

serendipity me costó muy poco instalarlo, sólo tuve que cambiar algunos permisos de escritura en disco, para que el sistema estuviese totalmente funcional y operativo. La instalación se bifurca en simple y compleja (para usuarios avanzados) por ser mi primera vez utilizé la primera, y el sistema estuvo instalado en breve.

Es un sistema sencillo de utilizar, orientado exactamente a publicar un blog, en el que pueden darse cabida varios autores, multiples lenguajes, se puede configurar el lenguaje, puedes con una instalación configurar múltiples blogs, sistema de plugins, importación de post de diferentes sistemas de blogs, etc.

WordPress: De este puedo decir poco, salvo que cometí un pequeño error que debo corregir. En su valoración inicial, aún estudiaba la posibilidad de no disponer de servidor propio sino de utilizar sistemas como WordPress.com. Los problemas a los que me refería, estaban (no encuentro el link que lo demuestre) relacionados con no poder poner publicidad en el blog (tipo adwords de google). Dado esto dejé de pensar en él. Veo ahora que puedes utilizar WordPress como software con la libertad que la licencia GNU te permita, que para mi es suficiente. Gracias a Iban por la corrección. Un detalle importante, es que no podía contrastar wordpress con alguien que lo estuviese utilizando y pudiese contarme cosas sobre su experiencia.

Algunos otros sistemas que luego he ido viendo utilizar, que no consideré en su momento, porque no estaba afectado por RoR son: mephisto, typo, simpleblog.

Tras este paso inicial, decidí iniciar un desarrollo personal y open source. El nombre de la criatura es: Belegost. Voy camino de un mes desarrollándola, y modificándola a cada paso que doy dentro de ror. Con pasos muy pequeños, pero con mucha energía. La decisión de iniciar el proyecto fue extraña, por así decirlo; sin embargo puse en él desde sus inicios una gran ilusión, tanto que desde entonces encuentro una mayor motivación personal hacia el desarrollo. Ganas, energía y motivación, son la esencia del nacimiento del Belegost.

Su cometido es:

Belegost is an weblog system based in Ruby on Rails technology. We want to be faithful to three principles: easy to use; more secure and stable; and hot updates. With an easy interface, install and configuration.

Creo que esta descripción lo dice todo. Pero por si aún no queda claro, lo comento. La misión es crear un sistema de weblogs, en principio para un sólo usuario, con pretensiones de convertirse en multiusuario, mono blog, con opciones de conseguir un “sistema” de blogs, y un largo etcétera. Eso sí, para mi en estos momentos existen tres principios fundamentales: easy, secure y hot-updates.

Easy: Fácil de manejar, de instalar, de configurar. Porque sino es sencillo, no tiene sentido, y seguro existen otros.

Secure: Si cualquiera puede reventarte tus post, puede hacer que tus comentarios crezcan, o puede entrar en tu zona de administración y hacer lo que quiera, entonces nos debemos preocupar por algo más que administrar nuestro blog, y, eso es inadmisible.

hot-updates: Una vez se haya instalado por primera vez, las actualizaciones deben ser cuestión de unos cuantos clicks. De nada sirve tener todo lo anterior y que la actualización deba hacerse casi como si instalases desde cero, pudiéndose perder los datos hasta ese momento generados.

En el aire hay muchas opciones, pero no quiero tan siquiera comentarlas en voz alta para que no queden en saco roto desde su primera fase.

En mi afán de investigación para tener los conocimientos necesarios para hacer un buen mantenimiento y una buena administración del servidor que aloja este blog, me he topado con este libro.

Cuando decides montar un servidor web, muchas son las dudas que te pueden asaltar, algunas muy sencillas acerca de problemas de instalación u otras más complejas acerca de cuando considerar actualizaciones de software, añadir una nueva web al servidor, nuevas cuentas de mail, subdominios, configurar tu máquina linux y tu servidor apache para ser lo más seguros posibles, filtros antispam, backups, recuperaciones en caso de desastre, etc.

Este libro nos introduce en ese tipo de tareas. Instala una Fedora Core 4 como sistema base y nos enseña lo básico sobre el sistema; nos acerca a la línea de comandos; nos explica cómo son las unidades de un sistema linux; herramientas de administración del mismo; instalación de apache, mysql y php; utiliza webmin para administrar el servidor, viendo algunos de sus plugins; administración remota con ssh o vnc; cómo realizar backups, estudio de los ficheros de logs del sistema; y por último se preocupa de la seguridad del servidor. Nueve capítulos donde se tratan cada uno de estos temas.

No es demasiado profundo en las materias, además de que tiene un nivel básico, a mi parecer; sin embargo toca todos los temas que uno debe mirar y configurar para tener un servidor web completamente funcional. Y establece un buen marco de partida. Más aún cuando nuestros conocimientos de linux no son muy profundos.

El libro.