Para quien no lo sepa, Engine Yard es una de las empresas líderes en ofrecer hosting para aplicaciones Rails. El actual modelo de negocio consiste en ofrecer una plataforma fiable y escalable donde poder ejecutar aplicaciones Rails. La empresa ofrece porciones de su infraestructura, de manera que si una aplicación necesita escalar, el cliente deberá ir contratando más porciones.
Según comenta en su blog Ezra Zygmuntowicz, uno de los arquitectos de Engine Yard, la tendencia hacia el cloud computing es clara. Es decir, la industria del hosting se está moviendo hacia un nuevo paradigma en el cual se ofrecerá a los desarrolladores una plataforma escalable de forma transparente, altamente disponible y en la que el paso a producción es sencillo.
Es destacable que uno de los inversores en esta ronda ha sido Amazon, quien ya dispone de los Amazon Web Services. ¿Será una jugada para luchar contra la competencia de Google App Engine?
El CERT ha publicado un documento alertando de deficiencias en el protocolo DNS que pueden permitir a un atacante el envenenamiento de las cachés. Es decir, el atacante podría reemplazar en el servidor afectado direcciones de sitios populares de internet por la dirección de un servidor malicioso.
Al parecer, estas deficiencias en el protocolo fueron descubiertas hace meses por Dan Kaminsky, de la empresa IOActive. Los proveedores de servidores de DNS fueron avisados y se pusieron a trabajar, en secreto, en parches para solucionar el problema.
El problema no se ha descrito con detalle todavía. La solución implementada en los parches consiste en aumentar el rango de puertos UDP posibles desde los que se pueden hacer consultas a los servidores de DNS. La única solución definitiva es utilizar DNSSEC, es decir, las extensiones de seguridad de DNS, lo cual no sería ni mucho menos trivial.
El revuelo que esta noticia ha causado tan grande que hasta la prensa generalista se ha hecho eco de ella.
Si utilizamos Ruby 1.8, nuestro MRI no generará bytecode. Por ello, cada llamada a un método, cada utilización de una variable, etc., realizará una búsqueda en el Abstract Syntax Tree (AST), es decir, en una estructura en árbol que representa la sintaxis de nuestro código fuente.
Debemos, por lo tanto, tener en cuenta que abusar de la metaprogramación puede hacer que el rendimiento de nuestra aplicación se vea degradado.
Optimizar para la caché
En relación con el punto anterior, para minimizar las búsquedas en el AST, Ruby MRI mantiene una caché de las variables locales. Es decir, utilizar variables locales será más rápido:
@var = "local variable, which is cached by Ruby, and requires a single lookup"self.var = "requires walking the AST, and results in multiple lookups"
Mejor la interpolación que la concatenación
puts"This string embeds #{var1} and #{var2} through interpolation"# fasterputs"This string concatenates "<< var1 <<" and "<< var 2# slower
Utilizar métodos destructivos
Cuando disponemos de un método no destructivo y su pareja destructiva, como gsub y gsub!, suele ser más eficiente utilizar el método destructivo. Los métodos no destructivos suelen ser más lentos ya que tienen que realizar copias de los objectos.
hash = {}
hash = hash.merge({1=>2})# duplicates the original hash
hash.merge!({1=>2})# equivalent to previous line, and faster
Utilizar bloques en lugar de Symbol.to_proc
@widget_ids = @widgets.map(&:id)# Symbol.to_proc method, order of magniture slower...@widget_ids = @widgets.collect{|w| w.id}# faster and simpler
Compruebalo tú mismo
Si tienes dudas sobré qué código será más rápido, es sencillo comprobarlo:
require'benchmark'
n = 100000Benchmark.bmdo|x|
x.report('copy'){ n.timesdo ; h = {}; h = h.merge({1=>2}); end}
x.report('no copy'){ n.timesdo ; h = {}; h.merge!({1=>2}); end}end
copy 0.3500000.0600000.410000(0.419445)
no copy 0.2500000.0200000.270000(0.276030)
Si utilizamos subversion como software de control de versiones, cada vez que creemos un nuevo proyecto rails, habrá una serie de tareas que tendremos que llevar a cabo.
Supongamos que el repositorio está creado y accesible en la URL:
http://svn.misite.com/miproyecto
Lo primero que tendremos que hacer, siguiendo las buenas prácticas del control de versiones con subversion, es crear tres carpetas: trunk, tags y branches.
$ REPO=http://svn.misite.com/miproyecto
$ svn mkdir --message="Layout inicial" $REPO/trunk $REPO/tags $REPO/branches
Commit de la revisión 1.
Ahora, en lugar de hacer un svn import, lo recomendable es hacer un svn checkout del trunk en el directorio de la aplicación y a continuación añadir la estructura de directorios del proyecto. De esta manera podemos eliminar algunos ficheros del control de versiones antes de hacer el commit:
$ cd miproyecto
$ svn checkout $REPO/trunk .
Revisión obtenida: 1
$ svn add --force .
A lib
A lib/tasks
...
Los ficheros de log no necesitaremos que estén bajo el control de versiones:
$ svn revert log/*
Se revirtió 'log/development.log'
Se revirtió 'log/production.log'
Se revirtió 'log/server.log'
Se revirtió 'log/test.log'
$ svn propset svn:ignore "*.log" log
propiedad 'svn:ignore' asignada en 'log'
De la misma manera, como cada desarrollador puede tener un database.yml diferente, será una buena idea eliminarlo del control de versiones:
![[Valid RSS]](/wp-content/themes/javiervidal/images/valid-rss.png "Validate my RSS feed")