Leyendo variados artículos en la blogósfera, he visto que una buena dupla como software “plataforma base de Rails” es el uso de Mongrel y Nginx, siendo el primero el servidor de aplicaciones y el último el frontend HTTP. Esta combinación nos permite instalar una aplicación web en un servidor de recursos no muy abundantes, y aún así servir a una buena cantidad de usuarios concurrentes. Obvio que no he hecho métricas propias, pero Internet está lleno de este tipo de análisis.

El problema entonces se divide en dos:

• Instalar el software base necesario en los servidores
• Realizar el despliegue (deploy) de la aplicación en si

En este artículo vamos a ver cómo hago yo para mantener el software base (mongrel, nginx, gemas, …) instalado y configurado en los servidores que correspondan. Esta tarea la hago con Puppet, una herramienta que en un artículo anterior he comentado que me permite administrar una gran cantidad de servidores sin tener que volverme un esclavo.A modo de preámbulo, les voy a contar que mis servidores son todos Debian Lenny (stable) y usamos Rails 2.3.x.

Como primera medida, vamos a definir en Puppet lo necesario para que Ruby y Rails estén instalados, ya que son el sistema operativo de nuestra aplicación web.

Para poder instalar Rails 2.3.x desde el instalador de gemas, tenemos primero que instalar rubygems y rubygems1.8, pero Debian Lenny no trae la versión 1.3.1 que es la necesaria, por lo tanto acá es el único lugar donde vamos a hacer un poco de trampa, y vamos a instalar el paquete que podemos bajar desde la versión experimental acá y acá.

¿Cómo instalar un paquete que no está en la distribución actual? Mi solución seguro no fue la mejor, pero anduvo! Lo que hago es vía Puppet envío el paquete al servidor en cuestión y después le digo que lo instale usando dpkg, de esta manera:

# Instalamos rubygems 1.3.1 desde paquetes de experimental, ya que Lenny no lo tiene
# La versión 1.3.1 es necesaria para rails 2.3.x

class rubygems {
    file {
        "/usr/src/rubygems1.8_1.3.1-1_all.deb":
            source => "puppet://puppet.marketingsur.com/files/packages/rubygems1.8_1.3.1-1_all.deb",
            owner => root,
            group => root,
            mode => 0644;
        "/usr/src/rubygems_1.3.1-1_all.deb":
            source => "puppet://puppet.marketingsur.com/files/packages/rubygems_1.3.1-1_all.deb",
            owner => root,
            group => root,
            mode => 0644;
    }

    package {
        "ruby1.8":
            ensure => installed;
        "ruby1.8-dev":
            ensure => installed;
        "make":
            ensure => installed;
        "rubygems1.8_1.3.1":
            source => "/usr/src/rubygems1.8_1.3.1-1_all.deb",
            provider => dpkg,
            ensure => installed,
            require => File["/usr/src/rubygems1.8_1.3.1-1_all.deb"];
        "rubygems_1.3.1":
            source => "/usr/src/rubygems_1.3.1-1_all.deb",
            provider => dpkg,
            ensure => installed,
            require => [ Package["ruby1.8"], Package["rubygems1.8_1.3.1"],
                         File["/usr/src/rubygems_1.3.1-1_all.deb"] ];
    }
}

Con esto ya puedo definir la clase que me va a mantener instalado rails desde gemas:

# Instalamos rails desde gems porque la versión Debian es muy vieja
class rails {

    include rubygems

    package {
        "rails":
            provider => gem,
            ensure => installed,
            require => Package["rubygems_1.3.1"];
    }
}

Nótese la libertad que Puppet no provee al mantenerse independiente del sistema de paquetes, mediante la palabra clave provider puedo decirle que instale paquetes desde otras fuentes, permitiendonos seguir tratando a ese recurso como un paquete abstracto.

Hasta aquí tenemos entonces el lenguaje ruby 1.8 instalado, y rails 2.3.x listo para ser usado.

Mongrel Cluster

Mongrel es una biblioteca Ruby que se usa para armar servidores web, está diseñada para tener buena performance sirviendo contenido dinámico, pero no estático… es por eso que lo último se lo dejamos a Nginx, como explico más abajo.

Volviendo a mongrel, la distribución Debian tiene un paquete llamado mongrel-cluster que nos deja todo bastante listo para usar, con scripts de inicio y apagado de los clusters, por lo que el trabajo adicional que hay que hacer es relativamente poco.

Primero armamos una clase para instalar el software y mantener funcionando el servicio:

class mongrel {
    include rails

    package {
        "mongrel-cluster":
            ensure => installed,
            require => Package["rails"];
    }

    service {
        "mongrel-cluster":
            ensure => running,
            enable => true,
            hasrestart => true,
            hasstatus => true,
            require => Package["mongrel-cluster"];
    }
}

Luego escribimos la definición que va a permitir dar vida a varios clusters mongrel:

define mongrel-cluster-app ( $ipaddr="127.0.0.1",
                             $appdir="",
                             $port=8000,
                             $servers=3) {
    $root = $appdir ? {
        "" => "/var/www/${name}",
        default => "${appdir}",
    }

    include mongrel

    file {
        "/etc/mongrel-cluster/sites-available/${name}.conf":
            owner => root,
            group => root,
            mode => 0644,
            content => template("mongrel/cluster-app.conf.erb"),
            require => Package["mongrel-cluster"],
            notify => Service["mongrel-cluster"];

        "/etc/mongrel-cluster/sites-enabled/${name}.conf":
            ensure => "/etc/mongrel-cluster/sites-available/${name}.conf",
            require => File["/etc/mongrel-cluster/sites-available/${name}.conf"],
            notify => Service["mongrel-cluster"];
    }
}

Esto configura el cluster mongrel en cuestión, activándolo y escribiendo el archivo de configuración a partir del siguiente simple template:

---
address: <%= ipaddr %>
log_file: log/mongrel.log
port: "<%= port %>"
cwd: <%= root %>/current
environment: production
pid_file: tmp/pids/mongrel.pid
servers: <%= servers %>

Con esto, tenemos el software mongrel-cluster instalado, y el cluster específico que va a ejecutar nuestra aplicación configurado y corriendo, listo para atender los requerimientos de los usuarios cuando le lleguen a través de nginx.

Nginx

Primero vamos a empezar con el webserver, el que se encarga de atender a los requests de los usuarios. Éste es un proyecto Ruso que está ganando popularidad por su gran velocidad y poco consumo de memoria. Mi anterior favorito era lighttpd, pero he tenido varios problemas de uso de memoria, y por lo que vi el proyecto está bastante frenado.

Del lado de Puppet, primero defino una clase que mantiene instalado y corriendo el servidor nginx, nada del otro mundo:

class nginx {
    package {
        "nginx":
            ensure => installed;
    }

    service {
        "nginx":
            ensure => running,
            enable => true,
            hasrestart => true,
            hasstatus => false,
            require => Package["nginx"];
    }
}

Luego, tengo una definición que me permite generar varias configuraciones de sitios basados en nginx y mongrel:

define nginx-railsapp ( $rootdir="",
                        $ipaddr="",
                        $port=80,
                        $mongrels=["127.0.0.1, 8000, 3"] ) {
    $root = $rootdir ? {
        "" => "/var/www/${name}",
        default => "${rootdir}",
    }
    $listen = $ipaddr ? {
        "" => "${port}",
        default => "${ipaddr}:${port}",
    }
    $upstream_name = "mongrel-${name}"

    include nginx

    file {
        "${root}":
            ensure => directory,
            owner => www-data,
            group => www-data,
            mode => 0755;
        "/etc/nginx/sites-available/${name}":
            content => template("nginx/railsapp.conf.erb"),
            owner => root,
            group => root,
            mode => 0644,
            require => Package["nginx"],
            notify => Service["nginx"];
        "/etc/nginx/sites-enabled/${name}":
            ensure => "/etc/nginx/sites-available/${name}",
            require => File["/etc/nginx/sites-available/${name}"],
            notify => Service["nginx"];
    }
}

Esta definición acepta 4 parámetros: el directorio raíz donde va a estar la app, la dirección IP en la que va a atender el webserver, su puerto, y las instancias mongrel que van a darle vida a la aplicación. Noten que por defecto todos los parámetros tienen un valor configurado, por lo que son opcionales.

Otro detalle a tener en cuenta es el parámetro mongrels, se puede ver que es una lista de strings, esa string define una tupla de 3 valores separados por coma, el primero corresponde al IP donde los mongrels atienden, el segundo es el puerto inicial, y el tercer valor la cantidad de instancias.

La receta configura un par de directorios y además el archivo de configuración de la aplicación, que obtiene a partir de un template (railsapp.conf.erb) que incluyo acá abajo:

###
# ATENCION: Archivo de configuración manejado por Puppet!
###

upstream <%= upstream_name %> {
    #fair;
<% mongrels.each do |mongrel| -%>
<% mongrel_ip, mongrel_port, mongrel_qty = mongrel.gsub(' ', '').split(',') -%>
<% mongrel_qty.to_i.times do |n| -%>
    server <%= mongrel_ip %>:<%= mongrel_port.to_i + n %>;
<% end -%>
<% end -%>
}

server {
    listen <%= listen %>;
    server_name <%= name %> www.<%= name %>;
    charset off;

    # this rewrites all the requests to the maintenance.html
    # page if it exists in the doc root. This is for capistrano’s
    # disable web task
    if (-f <%= root %>/system/maintenance.html) {
        rewrite ^(.*)$ /system/maintenance.html last;
        break;
    }

    location / {
        root <%= root %>/current;
        index index.html index.htm;
    }

    # / -> first search for local index.html then go to <%= upstream_name %>
    location ~ ^/$ {
        if (-f /index.html) {
            rewrite (.*) /index.html last;
        }
        proxy_pass http://<%= upstream_name %>;
    }

    # rails caching: searching first for $action.html local pages
    location / {
        if (!-f $request_filename.html) {
            proxy_pass http://<%= upstream_name %>;
        }
        rewrite (.*) $1.html last;
    }

    # serve static files directly
    location ~ .html {
        root <%= root %>/current/public;
    }

    location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov)$ {
        root <%= root %>/current/public;
    }

    # resend everything else to <%= upstream_name %>
    location / {
        proxy_pass  http://<%= upstream_name %>;
        proxy_redirect     off;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

Éste es un archivo de configuración que encontré por ahi y que lo adapté al formato de templates de ERB. Básicamente lo que hace es servir todo lo que sea contenido estático, y para lo dinámico (la aplicación web en si) hace de proxy ruteando los requests a el o los clusters mongrel que hayamos definido. Esto nos permitiría tener varios servidores atendiendo a la aplicación web, para repartir la carga.

El toque final

Luego de definir todos estos recursos, no nos queda más que usarlos. Ésto lo podemos hacer con una clase que defina la aplicación en cuestión, de la siguiente manera:

# midominio.com Web App (proxy balancer + backend)
class midominio-webapp {
    include rails
    include mongrel

    $mongrel_ipaddr = "127.0.0.1"
    $mongrel_port = 8000
    $mongrel_servers = 5

    $needed_gems = ["gema1", "gema2", "gema3"]

    nginx-railsapp {
        "midominio.com":
            ipaddr => "1.2.3.4",
            mongrels => ["${mongrel_ipaddr}, ${mongrel_port}, ${mongrel_servers}"];
    }
    mongrel-cluster-app {
        "midominio.com":
            ipaddr => "${mongrel_ipaddr}",
            port => "${mongrel_port}",
            servers => "${mongrel_servers}";
    }

    package {
        $needed_gems:
            provider => gem,
            ensure => installed,
            require => Package["rails"];
    }
}

Luego esta clase la incluímos en el nodo que corresponda, y listo… al rato tenemos instalada la infraestructura para hostear nuestra aplicación web.

Espero se animen a usar Puppet si aún no lo han hecho. Su sintaxis no es de lo mas hermoso que puede existir, pero los beneficios que trae hacen ese tema algo insignificante.

En la segunda parte vamos a hablar de cómo automatizar la instalación de la aplicación en los servidores, usando Capistrano.

No es noticia nueva que tener una computadora conectada a Internet la deja expuesta a una serie de riesgos de seguridad, y es por eso que los administradores de sistemas, normalmente tomamos una serie de medidas básicas preventivas para evitar un disgusto posterior.

Si bien mis servidores normalmente tienen un nivel de seguridad más que aceptable, los molestos bots de estas personas no dejan de intentar adivinar las claves de mis cuentas para poder acceder con privilegios de administrador a los servidores. Esto me causa un problema, pero no de seguridad, sino que me ocupan los recursos que tengo para otras cosas y a veces hasta producen enlentecimientos notables en los servidores virtuales mas pequeños.

Es por esto que me puse manos a la obra, a averiguar alguna manera de mantener a raya a estos muchachos, y lo que me encontré fue con un software pensado justamente para esto: fail2ban.

Este programa está ya listo para ser instalado y usado en mi distribución favorita (Debian GNU/Linux), y al instalarse comienza a chequear los accesos fallidos de conexión por SSH, dejando 6 intentos y prohibiendo el acceso por IP por 10 minutos. Para prohibir el acceso utiliza reglas de iptables, y su funcionamiento es en modo daemon, un pequeño programa queda corriendo (muy chiquito, sirve hasta en VPS de 256 MB de RAM) revisando los distintos archivos de registros de sistema.

Lo interesante además es que trae una serie de plantillas para poder chequear otros tipos de servicios como FTP, SMTP, Web, etc. todo esto mediante reglas de análisis y acciones acordes, que se pueden personalizar para un uso específico.

En resumen, una muy simpática herramienta para los administradores de sistemas GNU/Linux, fácil de instalar y poner a funcionar, y el beneficio es enorme.

¡Que la disfruten!

Bien, luego de varios meses de no escribir, me siento en la obligación de al menos informar que este blog corre en la última versión disponible de wordpress: la 2.7

¿Mejoras con respecto a la anterior? Seguro debe haberlas, pero como no he sido usuario asiduo de la rama 2.5.x, a mi no me pregunten

Lo que si, la interfaz está mejor organizada, da una sensación de tener todo a mano sin tener que scrollear mucho hacia abajo.

De paso, ya que andaba con ganas, cambié el tema por uno que soporte widgets, y le agregué el plugin que la gente de Sociable ha escrito para darle capacidades de FacebookConnect, lo que permite a los usuarios loguearse a mi blog con su cuenta de Facebook, y compartir contenidos del blog en esa red social.

Lo curioso de este sitio es que nos permite subir nuestros proyectos para luego hacer un análisis del código fuente, detectando los lenguajes utilizados, y sacando estadísticas. Como primera medida subí el proyecto GNOME War Pad a partir de mi repositorio git público, y en un par de horas el sistema había importado el código fuente y había analizado su contenido, detectando los contribuidores y su nivel de actividad en el proyecto.

Pueden ver además que a partir del código fuente, el sitio arma una especie de perfil de cada desarrollador, con información sobre el nivel de experiencia en cada lenguaje, cantidad de commits, etc. En fin, me pareció una idea original armar una red de desarrolladores cuya información sea extraída directamente de su trabajo, puede ser una buena fuente de contactos a la hora de buscar gente para un nuevo proyecto.

DNS no es más que una base de datos jerárquica y distribuída que permite a personas de distintos puntos del globo aportar datos de tal manera que los servicios que todos conocemos, funcionen correctamente. Gracias al DNS los servidores de correo electrónico pueden intercambiar mensajes, los navegadores web pueden encontrar los servidores donde pedir las páginas, etc.

Los administradores de sistemas tenemos como tarea, la de configurar los servidores de nombres para que los datos de nuestros dominios sean correctamente publicados en Internet. Lo cierto es que muy pocos administradores de sistemas conocen realmente la manera correcta de configurar un servidor de nombres, y muchas veces caemos en errores que luego sufrimos por cortes de servicio de correos y otros similares.

Por suerte, en GNU/Linux contamos con varias herramientas que nos ayudan a corroborar que la configuración de un dominio está correcta, hoy voy a comentar “zonecheck” una herramienta que tiene la particularidad de no necesitar analizar un archivo de configuración, sino que hace las consultas a los servidores de nombres públicos en Internet.

Zonecheck viene en Debian, así que para aquellos felices usuarios de esta maravillosa distribución de Linux, solo hace falta ejecutar “apt-get install zonecheck” y comenzar a utilizarlo. El comando posee muchas opciones y realmente es conveniente leer con detenimiento su páginal de manual, pero para aquellas personas ansiosas, acá les va un ejemplo:

$ zonecheck -4 -q -vi,x,d fileextensionunknown.com
ZONE  : fileextensionunknown.com.
NS <= : ns1.name.com. [4.79.81.159]
NS    : ns2.name.com. [38.97.225.164]
NS    : ns4.name.com. [38.97.225.165]
NS    : ns3.name.com. [4.79.81.160]

w> The format of the serial number is not YYYYMMDDnn
 | Ref: RFC1912 (p.3)
 |   The recommended syntax is YYYYMMDDnn (YYYY=year, MM=month, DD=day,
 | nn=revision number).
 `----- -- -- - -  -
 :   The serial 1 doesn't seem to be in the YYYYMMDDnn format.
 `..... .. .. . .  .
=> ns2.name.com./38.97.225.164
=> ns4.name.com./38.97.225.165
=> ns3.name.com./4.79.81.160
=> ns1.name.com./4.79.81.159

w> [TEST delegated domain is not an open relay]: No route to host - connect(2)
=> generic

w> [TEST can deliver email to 'postmaster']: No route to host - connect(2)
=> generic

w> [TEST domain of the hostmaster email is not an open relay]: No route to host - connect(2)
=> generic

f> [TEST can deliver email to hostmaster]: No route to host - connect(2)
=> generic

==> FAILURE (and 7 warning(s))

Zonecheck realiza numerosas pruebas, y nos va diciendo cuales son advertencias, cuales son errores fatales y en algunas ocasiones, cómo solucionarlo.

Además, para aquellos administradores que no usen GNU/Linux, acabo de poner en línea una herramienta web que utiliza zonecheck de fondo, para poder acceder a esta ventaja aún estando en un Windows: Free DNS Report. ¡Que la disfruten!

La administración de servidores involucra variadas tareas, desde la elección de hardware para un nuevo servidor, la instalación del sistema operativo, aplicaciones, su configuración, pruebas y puesta en producción, para luego terminar con el mantenimiento de dicho servidor, que puede incluir más tareas como por ejemplo: actualización periódica del software instalado, la corrección de mínimos errores que podamos haber tenido en la configuración inicial, el agregado de pequeñas herramientas que nos ayudan a mantener los servicios funcionando, copias de respaldo de datos, y quizás también del sistema base… la lista continúa pero creo que la idea está planteada: Administrar servidores no es una tarea simple.

A medida que sumamos servidores a nuestra carga administrativa, cada uno con sus peculiaridades, servicios diferentes, configuraciones personalizadas, etc. nos vemos más y más inmersos en un problema latente:

• Nuestra carga horaria necesaria para tener todo funcionando es cada vez mayor, ya que por cada servicio en cada servidor, los problemas que aparecen son únicos y muy pocas veces se repiten en otros casos. Esto significa que con casi cualquier problema que surge, el tiempo que tenemos que dedicarle a la investigación y resolución del mismo es tanto como el tiempo que le vamos a tener que dedicarle al siguiente, y así.
• Por más minuciosos que seamos, las soluciones que aplicamos en un servidor hace 1 año serán distintas a las que utilicemos en la implementación de servidores hoy en día, por más que la funcionalidad de ellos sea similar. Día a día pulimos métodos, mejoramos algoritmos, aprendemos nuevas formas de hacer lo mismo que nos ahorran tiempo, y todo eso lo aplicamos a los servicios que tenemos a cargo, pero actualizar esos métodos en servidores donde los tenemos funcionando en alguna manera hoy antigua, es o bien muy costoso o simplemente imposible. En consecuencia: los métodos que utilizamos a través de los años quedan dispersos en la línea temporal que forman los equipos generados por nosotros.
• ¿Y que me cuentan de la gestión de software? Habíamos visto que parte de nuestras tareas era la de mantener actualizado el software instalado en los equipos. Si bien hay administradores que tienen como política la frase “Si funciona, no lo toques”, yo creo que si la distribución te ofrece la estabilidad y confianza suficientes como para saber que las actualizaciones de seguridad no te van a romper nada, el actualizar es una necesidad, no sólo en los servidores expuestos a redes públicas como Internet. ¿Qué pasa cuando tenemos que actualizar 10 servidores? ¿Y cuando son 100? ¿Qué pasa cuando tenemos que instalar un nuevo software en 10, 50, o 100 servidores? Nos arremangamos, respiramos hondo, y o bien planeamos los siguientes 2 meses implementando el mismo software una y otra vez, o descartamos nuestros preciados fines de semana para acelerar el paso. De más está decir que si en vez de servidores hablamos de estaciones de trabajo…se complica un poquito más la cosa.
• A medida que la infraestructura aumenta de tamaño, vamos necesitando gente que nos ayude. Si las políticas administrativas no están estandarizadas de alguna manera, lo único que haremos es sumar un ancla más sobre nuestro pescuezo, ya que las nuevas personas tendrán sus propios criterios y formas de hacer las cosas, multiplicando la variedad en la que los problemas son solucionados y por lo tanto, haciendo cada vez más necesaria gente altamente capacitada para el mantenimiento. De más está decir que es difícil conseguir gente con mucha experiencia que esté interesada en mantener un verdadero caos, ¡ellos tienen mejores cosas que hacer de su vida, y vos también deberías!

En mi haber tengo casi 10 años de experiencia en la administración de servidores, y esto sólo lo digo para recalcar el hecho que las problemáticas arriba expresadas sólo se hicieron evidentes cuando ya era tarde, cuando tenía encima casi 40 servidores, todos configurados artesanalmente y cada uno con sus peculiaridades. Ni yo me acuerdo de todos los detalles que hay ocultos en cada servicio que todas esas máquinas dieron. Si alguien me hubiera advertido, es probable que haya empezado a planear una estandarización temprana que me hubieran permitido administrar 400 servidores sin mayores problemas.

Aquí es cuando entra Puppet al rescate, ésta es una herramienta que nos ayuda solucionar los problemas antes mencionados. Puppet tiene varios componentes, entre ellos se encuentra el servidor, que distribuye las recetas que los clientes deben aplicar en cada servidor. Y ya que hablamos de recetas, éstas están escritas en un lenguaje declarativo, es decir, un lenguaje que expresa el estado de cómo debería estar el servidor, sin caer en una receta paso a paso para llegar a ese estado. Una receta en Puppet se refiere entonces a recursos, y su estado en el equpo, como por ejemplo: el paquete vim debe estar instalado y debe ser el editor por defecto, entonces Puppet se encarga que esto sea aplicado, ya sea en un Debian, un Redhat, Ubuntu o SuSE, nosotros nos olvidamos de los detalles menores.

Este alto nivel de expresión nos permite escribir recetas que luego podemos compartir con otros colegas, tal cual el software libre! esto es algo que muy pocas veces se ha hecho ya que las herramientas que los administradores de sistemas realizamos son normalmente muy ad hoc, poco portables a otros entornos.

Entre los recursos que Puppet nos permite administrar, están los paquetes de software, archivos y directorios, usuarios, tareas de cron, etc. y además como la herramienta está escrita en el lenguaje Ruby, es fácilmente extensible para agregar nuevos recursos.

El caso ideal luego de haber aprendido esta herramienta, sería que con cada servidor nuevo, lo único que haya que instalar sea el sistema base, el cliente Puppet, y luego éste se encarga del resto, manteniendo el estado que se expresa en las recetas a rajatabla, chequeando que se cumplan cada tanto, y nosotros mientras tanto pudiendo regresar a casa temprano, olvidandonos que estamos de guardia y que de un momento a otro, el celular podría sonar por algún incendio.

Les dejo disponible los slides de mi charla por si les sirve de algo.

Hoy 15 de Septiembre festejamos el dìa del Software Libre, en donde se pretende promocionar su uso en todos los ámbitos, desde el hogareño hasta el gubernamental.

Para esta oportunidad, el grupo de Software Libre de la Universidad Nacional del Litoral, UNLibre, organizó un evento con charlas e instalaciones de linux para el que quiera acercarce.

El problema que veo que tiene, es que es horrendamente lento…si bien mi máquina no es la gran cosa (AMD Sempron 2400+ con 512 MB de RAM), me di cuenta que cuantos más sitios sindicados tengo, más lerdo se pone. Además, al menos en mi experiencia de usuario, a netvibes lo uso sólo para la lectura de mis feeds, lo demás son chiches que no uso…

Luego de leer un artículo de un blog de por ahi, me propuse ver nuevamente que tal anda el Google Reader, hacía tiempo lo había probado y no me había gustado para nada, y me sorprendo al ver una interfaz de usuario completamente diferente. Aprovecho las funcionalidades de exportación e importación OPML que tienen ambos sitios y rápidamente me migro a este lector.

Luego de pasar un día utilizandolo, debo decir que realmente me encantó. No sólo por su velocidad de manejo (que Google nos tiene acostumbrados en todas sus aplicaciones web), sino además le encontré tres funcionalidades que al menos a mi me parecen excelentes:

• Navegación por teclado: Muy al estilo GMail, hace la experiencia de usuario mucho más ágil sólo con aprenderse un par de teclas.
• Compartir noticias: Si algún artículo nos da ganas compartirlo, luego podremos incluir el listado de noticias/artículos compartidos en nuestro sitio web (lo acabo de agregar en la barra lateral de mi blog)
• El enlace “Next”: Agregando el enlace “next” a la barra de bookmarks de nuestro navegador, podemos en cualquier instante ir a ver la siguiente noticia que no hayamos leído. Parecería una estupidez pero es realmente práctico.

Si sos de leer noticias en RSS, realmente te recomiendo probarlo.