require 'autotest/redgreen'
require 'autotest/html_report'
require 'autotest/menu'
module Autotest::Growl

  def self.growl msg, options={}
    salida = "growlnotify -n autotest --image \"#{options[:img]}\"  -p #{options[:pri]} -d #{rand(100)} -m \"#{msg}\" \"Tests\" #{options[:sticky]}"
    system salida
  end

  Autotest.add_hook :ran_command do |at|
    results = [at.results].flatten.join("\n")
    output = results.slice(/(\d+)\s+assertions?,\s*(\d+)\s+failures?,\s*(\d+)\s+errors?/)
    failures = $~[3].to_i + $~[2].to_i
    options = (failures > 0)? {:img=>"/Users/#{ENV["USER"]}/Library/Autotest/rails_fail.png", :pri => 0, :sticky => "" } : {:img => "/Users/#{ENV["USER"]}/Library/Autotest/rails_ok.png", :pri => 0,:sticky => "" }
    if output
      growl "#{output}", options
    end
  end
end

Aquí tenéis las imágenes que se tienen que copiar en ~/Libreria/Autotest

Fuente: Mabishu

¡Nos vemos en Madrid!

Para reducir el tamaño de los archivos JS disponemos de una aplicación llamada JSMin que elimina los espacios en blanco y los saltos de linea innecesarios, llegando a reducir el tamaño del archivo en algunos casos hasta la mitad.

Se puede descargar el código y compilarlo, bajar el ejecutable para Windows o bajarlo en diferentes lenguajes, entre los que se encuentra Ruby

AVISO: la conversión la hace sobre el archivo original, os recomiendo que guardéis una copia antes de aplicarle JSMin por si tuviérais que volver a modificarlo.

http://www.crockford.com/javascript/jsmin.html

Aquí tenéis algunos consejos para optimizar las consultas a la base de datos y conseguir aumentar considerablemente el redimiento de vuestra aplicación.

Haz pruebas en un entorno real

Las pruebas en local y con una base de datos vacía no sirven de nada. Llena tu base de datos con miles de registros y súbelo al servidor. Haz las pruebas en staging simulando el entorno en el que se ejecutará la aplicación.

Mira la consola y los logs

No cierres la consola donde lances el servidor, verás continuamente que está pasando, las consultas que ejecuta y el tiempo que tardan en ejecutarse. Pega la nariz a la pantalla y revisa linea por linea que está haciendo la aplicación en cada momento.

Reduce el tamaño de los datos que estás accediendo

Extrae de la tabla únicamente aquellos campos que necesitas, normalmente no necesitamos todos los campos de un modelo

User.find(:all) # No
User.find(:all, :select => "user.id, user.name, user.email")

Reduce el número de consultas a las base de datos

Vamos a mostrar diez posts y sus comentarios, la manera “normal” sería

@posts = Post.find(:all, :limit => 10) # 1 consulta

@posts.comments.each do |c|
…
end # 10 consultas

Esto se puede mejorar bastante incluyendo los comentarios en la consulta donde sacamos los posts

@posts = Post.find(:all, :limit => 10, :include[:comment]) # 2 consultas

De esta manera nos hemos ahorrado 9 consultas y no es necesario cambiar ni úna línea de código en las vistas para mostrar los comentarios.

Reduce aún más

Combinado los dos ejemplo anteriores podriamos tener algo como

Post.find(:all, :limit => 10, :select => "post.id, post.title, post.excerpt", :include => [:comment])

Esto está muy bien, hemos reducido considerablemente el numero de accesos a la base de datos, sobretodo si el parámetro :limit es muy grande, pero aún se están cargando todos los campos del modelo asociado, en este caso los somentarios. Podemos utilizar el parámetro :joins para especificar qué campos del modelo asociado queremos

@posts = Post.find(:all, :limit => 10, :select => "post.id, post.title, post.excerpt, comment.body AS comment_body', :joins => [:comment])

Utiliza find_by_sql

Algunas consultas son difíciles de optimizar, pero siempre podemos recurrir al método find_by_sql que nos permitirá realizar las consultas exactamente como las queremos.

User.find_by_name("Pepe") # No
User.find_by_sql(SELECT user.* WHERE user.name = 'Pepe')

No utilices consultas complejas, mejor varias consultas simples

No os volváis unos talibanes de la optimización y pretendáis hacerlo todo con una consulta enorme, a veces es mejor realizar más consultas pequeñas, ya que aunque se realicen varios accesos a la base de datos, la suma de los tiempos de latencia puede ser menor que el tiempo que tarda en ejecutarse una mega-consulta.

stuff = Stuff.find_by_sql("SELECT everything.* FROM everything JOIN (box_1, box_2) ON (everything.id = box_1.everything_id box_2.box1_id = box_1.id") # Consulta lenta

# Alternativa
boxes = Boxes.find_by_sql("SELECT box_1.everything_id FROM box_1 JOIN box_2 ON box_2.box1_id = box_1.id")

boxes.each do |box_1|
stuff = Stuff.find_by_sql("SELECT everything.* FROM everything WHERE id = #{box_1.everything_id}
end

Usa tablas MyISAM en lugar de InnoDB

A no ser que necesites transacciones, bloqueos o el nivel de escrituras en tu aplicación sea muy elevado, usa MyISAM, notarás una mejora considerable del rendimiento. Cuando se realiza una migración en Rails, por defecto se crean tablas InnoDB, esto se puede cambiar en las migraciones de la siguiente manera

def self.up
     create_table :users, :options => 'engine=MyISAM' do |t|
       t.string   :name
       t.string   :surname
       t.string   :email

       t.timestamps
    end
  end

Puedes crear una migración que pase todas tus tablas InnoDB a MyISAM

class ConvertToMyIsam < ActiveRecord::Migration
  def self.up
    execute 'ALTER TABLE users ENGINE = MyISAM'
    execute 'ALTER TABLE posts ENGINE = MyISAM'
    ...
  end

  def self.down
    execute 'ALTER TABLE users ENGINE = InnoDB'
    execute 'ALTER TABLE posts ENGINE = InnoDB'
   ...
  end
end

Utiliza cache de modelos

Rails 2.1 proporciona más opciones de cache que pueden ser muy útiles para reducir el número de consultas. Supongamos que nuestra aplicación muestra siempre los diez usuarios registrados. Continuamente estaremo realizando una consulta como esta

@users = User.find(:all, :limit => 10, :order => "created_at desc")

Utilizando cahé podemos ahorrarnos esta consulta mientras no haya nuevos usuarios registrados. En el modelo User definimos

def self.recent_cached
  Rails.cache.fetch('User.recent_cached') { User.recent }
end

def self.recent
  User.find(:all, :limit => 10, :order => 'created_at desc')
end

Utiliza índices

En todos aquellos campos que no sean índices primarios sobre los cuales estés realizando búsquedas, crea un índice que te permita encontrarlos más rápidamente. Por ejemplo si continuamente buscas usuarios por su nickname

@user = User.find_by_sql(SELECT user.* WHERE user.nickname = 'PepeGrillo')

Crea un índice sobre el campo nickname y verás reducido el tiempo de la consulta considerablemente, sobretodo si tienes 100.000 usuarios. Crea una migración

./script/generate migration add_index_to_user

y añade el índice de esta manera

class AddIndexToUser < ActiveRecord::Migration
  def self.up
    add_index :users, :nickname
end

De momento es todo, espero que estos trucos te sirvan para poder aumentar el rendimento de tu aplicación, pero aún hay más técnicas que puedes utilizar. Las explicaré en un próximo post.

Que una aplicación escale es la suma de muchos factores, y el más importante es el humano. No hay ni un solo lenguaje o framework que escale “out of the box”, hay que meterle mano y saber lo que haces. Por tanto que alguien argumente que Rails no está a la altura de otros lenguajes por que no escala, únicamente demuestra que no sabe demasiado de que habla o que critica por criticar.

Si detrás del desarrollo y puesta en marcha de la aplicación hay buenos profesionales que han optimizado el código, han definido la arquitectura de sistemas correcta y han tenido en cuenta los múltiples factores que afectan al rendimiento de una aplicación, dicha aplicación va a ser escalable esté hecha en el lenguaje o framework que sea: Rails, Java, PHP, Python…

Y para hechar por tierra las teorias de los que argumentan que Rails no escala, aquí os dejo un listado de las 100 aplicaciones hechas en Rails con más tráfico. Destacar que la primera, yellowpages.com, soporta 20 millones de visitas únicas al mes, ahí es nada.

http://rails100.pbwiki.com/Compete+Rankings

sudo port selfupdate

y a continuación insalamos Git

sudo port install git-core

Una vez instalado podemos personalizarlo un poco

# Utilizar opendiff (FileMerge) para resolver los conflictos
git config --global merge.tool opendiff

# Ignorando archivos
git config --global core.excludesfile ~/.gitignore
touch               "$HOME/.gitignore"
echo '.DS_Store' >> "$HOME/.gitignore"
echo '._*'       >> "$HOME/.gitignore"
echo '.svn'      >> "$HOME/.gitignore"
echo '.hg'       >> "$HOME/.gitignore"

# Añadiendo alias
git config –global alias.st status
git config –global alias.ci commit
git config –global alias.co checkout
git config –global alias.br branch

# Un poco de color
git config –global color.ui auto

barceloneses = User.find(:all, :conditions => "city = 'Barcelona'")
user = User.find_by_name('Emili')
if barceloneses.include?(user.id)
....
end

El método include?(objeto) devuelve true o false en función de si el objeto se encuentra dentro del array.

Más información
www.ruby-doc.org/core/classes/Array.html

mysql -u root -p

grant ALL on base_de_datos.* to usuario@localhost identified by ‘password’;

Más información

http://www.mysql-hispano.org/page.php?id=4&pag=5
http://www.webtaller.com/construccion/lenguajes/mysql/lecciones/gestion_usuarios_mysql.php

/users/4/posts/34/comments/10

Lo que devolvería el comentario 10 que pertenece al post 34 que a su vez pertence al usuario 4. Una de las ventajas de anidar los recursos es que podemos hacer esto:

/users/30/posts

y nos devuelve todos los posts del usuario 30.

Como véis tiene mucho sentido anidar los recursos para relacionarlos entre ellos. Si queréis saber más sobre recursos anidados podéis consultar:

http://www.norellana.com/2007/07/28/recursos-anidados-en-rails/

http://www.jaimeiniesta.com/2007/12/22/tutorial-recursos-anidados-con-rest-y-rails-2/

Bien, el problema aparece cuando necesitamos tener un recurso que sea anidado en algunas ocasiones y que no lo sea en otras. Me explico. Supongamos una aplicación con empresas que publican ofertas de empleo. Las ofertas de empleo están anidadas a los usuarios ya que una oferta pertenece a una empresa. Así podremos acceder a las ofertas de la siguiente manera

/companies/34/jobs/889

¿Pero que pasa cuando queremos mostrar un listado de todas las ofertas? O lo que es lo mismo, hacer la petición

/jobs

Rails nos va a dar un error ya que necesita saber el id de la empresa para poder listar las ofertas de trabajo. Para poder crear un recurso anidado (o no) según nos convenga hay que hacer lo siguiente:

En el routes.rb crear las rutas

map.resources :companies do |company|
   company.resources :jobs
end

map.resources :jobs

Cambiamos el método index del controlador

def index
   @jobs = target.find(:all)
end

y añadimos los siguientes métodos

protected
def target
   @user ? @user.jobs : Job
end

def get_user
    return if params[:user_id].blank?
    @user = User.find(params[:user_id])
    rescue ActiveRecord::RecordNotFound
    redirect_to jobs_url
  end

def get_job
    @job = Job.find(:all)
end

De esta manera si se accede a una oferta de empleo se ejecutará el método get_user que devolverá el id del usuario para poder acceder al recurso anidado, si se está accediendo directamente al listado de ofertas de empleo, get_user hará un return y se ejecutará el código de get_job, de manera que obtendremos el listado de ofertas de empleo.

De esta manera podemos disponer de un recurso anidado cuando lo necesitemos, pero también accesible directamente para realizar ciertas funciones.

Otro ejemplo es éste que propuso Xavier Noria en la lista de Rails:

Hay que tener presente que las URLs que dan acceso a un mismo recurso
pueden ser multiples, por ejemplo

/releases/my-app-1.1.tar.gz

/releases/latest.tar.gz

Las URLs con caminos que indican jerarquía pueden indicar nesting (pertenencia), scope, y en general lo que tenga sentido en la aplicacion.

Pero supongamos ahora que estás en una central de reservas de hoteles. Para hacer una reserva puede quedar bien una URLS así:

POST /chains/sol-melia/hotel/54/bookings

Eso daría una reserva. En una aplicación web podrías ir al show de esa reserva despues. Si estuvieramos en un web service devolveríamos un 201 Created con una cabecera Location a la dirección de ese recurso nuevo. Esa dirección puede perfectamente ya no reflejar la jerarquia (aunque podría hacerlo y se pueden ofrecer ambos accesos):

GET /bookings/789123

Por ejemplo, cancelar una reserva es más fácil que se ofrezca como

DELETE /bookings/789123

a no ser que el cliente deba añadir la jerarquía que es redundante y puede que le suponga un GET previo. La reserva ya sabe a quien pertenece.

En una API así, BookingsController ha de estar preparado para servir peticiones con scope y sin scope. Si las consultas y las cancelaciones solo son accesibles con URLs directas entonces show y destroy no han
de lidiar con el scope opcional. Si index se publica con y sin scope entonces la acción debe entender ambas llamadas.

rake db:fixtures:load FIXTURES=users,categories

Si no especificamos la variable RAILS_ENV lo cargará en la base de datos del entorno en el que nos encontramos, si no debe ser así podemos ejecutar

rake db:fixtures:load FIXTURES=users RAILS_ENV=production