rake db:fixtures:load

Cómo cargar las fixtures en un entorno diferente al que nos encontramos

rake db:fixtures:load RAILS_ENV=development
rake db:fixtures:load RAILS_ENV=test
rake db:fixtures:load RAILS_ENV=production

Cómo cargar sólo unas determinadas fixtures en la base de datos

rake db:fixtures:load FIXTURES=users,products

Bajo el patrón de diseño MVC, los objetos se dividen en tres partes diferenciadas:

• El Modelo. Es una representación lógica de objetos. Define los objetos como usuarios, productos, empleados etc, las relaciones entre ellos y los procesos que ocurren. En Rails, los modelos están basados en ActiveRecord. Lo más importante sobre los modelos de una aplicación Rails es que te dan la información correcta cuando el controlador se la pide.

• La Vista. La vista es responsable de generar la interfaz de usuario (lo que vemos en el navegador), basándose en los datos del modelo. En Rails la vista se genera usando RHTML (HTML con código Ruby) o RXML (XML con código Ruby). El controlador elige qué vista usar, y hace disponible los datos que necesita.

• El Controlador. El controlador une el modelo y la vista. En una aplicación web el controlador recibe la petición del usuario, interactúa con el modelo para procesar los datos y hace disponible esos datos a la vista. Los controladores son la única parte del MVC que deben ser definidos. El controlador puede procesar los datos y mostrarlos, es autosuficiente.

Una de las ventajas del sistema MVC es que, al aplicar esta separación, se hace posible crear más de una vista para el mismo modelo (una vista abreviada, una vista detallada o una vista en XML), y reutilizar el modelo y el código que guarda el modelo de manera permanente, para escribir librerias relacionadas, o incorporar datos del dominio original en programas más grandes.

En la jerarquia de directorios de una aplicación Rails se ve que esta estructura está bien diferenciada, y que para cada modelo existe un directorio donde colocar los archivos correspondientes. Esto facilita la programación ya que se suelen tener pequeños archivos con poco código donde se ve claramente que función desempeñan y que son más fáciles de mantener.

Este es un artículo original de Javier Cañada publicado en Terremoto.

http://www.amaiac.net/conferenciarails2007/

ftp://hades.udg.edu/conferenciarails2007

http://www.conferenciarails.org/archivo/2007/12/4/videos_de_las_ponencias_por/

También se pueden consultar en Google Video

/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.

• ADDITIONAL_LOAD_PATHS
• ARGF
• ARGV
• ActionController
• ActionView
• ActiveRecord
• ArgumentError
• Array
• BasicSocket
• Benchmark
• Bignum
• Binding
• CGI
• CGIMethods
• CROSS_COMPILING
• Class
• ClassInheritableAttributes
• Comparable
• ConditionVariable
• Config
• Continuation
• DRb
• DRbIdConv
• DRbObject
• DRbUndumped
• Data
• Date
• DateTime
• Delegater
• Delegator
• Digest
• Dir
• ENV
• EOFError
• ERB
• Enumerable
• Errno
• Exception
• FALSE
• FalseClass
• Fcntl
• File
• FileList
• FileTask
• FileTest
• FileUtils
• Fixnum
• Float
• FloatDomainError
• GC
• Gem
• GetoptLong
• Hash
• IO
• IOError
• IPSocket
• IPsocket
• IndexError
• Inflector
• Integer
• Interrupt
• Kernel
• LN_SUPPORTED
• LoadError
• LocalJumpError
• Logger
• Marshal
• MatchData
• MatchingData
• Math
• Method
• Module
• Mutex
• Mysql
• MysqlError
• MysqlField
• MysqlRes
• NIL
• NameError
• NilClass
• NoMemoryError
• NoMethodError
• NoWrite
• NotImplementedError
• Numeric
• OPT_TABLE
• Object
• ObjectSpace
• Observable
• Observer
• PGError
• PGconn
• PGlarge
• PGresult
• PLATFORM
• PStore
• ParseDate
• Precision
• Proc
• Process
• Queue
• RAKEVERSION
• RELEASE_DATE
• RUBY
• RUBY_PLATFORM
• RUBY_RELEASE_DATE
• RUBY_VERSION
• Rake
• RakeApp
• RakeFileUtils
• Range
• RangeError
• Rational
• Regexp
• RegexpError
• Request
• RuntimeError
• STDERR
• STDIN
• STDOUT
• ScanError
• ScriptError
• SecurityError
• Signal
• SignalException
• SimpleDelegater
• SimpleDelegator
• Singleton
• SizedQueue
• Socket
• SocketError
• StandardError
• String
• StringScanner
• Struct
• Symbol
• SyntaxError
• SystemCallError
• SystemExit
• SystemStackError
• TCPServer
• TCPSocket
• TCPserver
• TCPsocket
• TOPLEVEL_BINDING
• TRUE
• Task
• Text
• Thread
• ThreadError
• ThreadGroup
• Time
• Transaction
• TrueClass
• TypeError
• UDPSocket
• UDPsocket
• UNIXServer
• UNIXSocket
• UNIXserver
• UNIXsocket
• UnboundMethod
• Url
• VERSION
• Verbose
• YAML
• ZeroDivisionError

Más información en http://wiki.rubyonrails.org/rails/pages/ReservedWords

http://railsify.com/

http://svn.techno-weenie.net/projects/plugins/

http://agilewebdevelopment.com/plugins/rails_rcov

Incorpora muchas mejoras que por lo que he visto nos van a hacer la vida aún más fácil. Si queréis más detalles en el blog de RoR está el anuncio con un resumen. Para saber exactamente cuáles son las novedades os recomiendo el PDF de Peepcode sobre Rails 2

La cifra de negocio B2C en 2006 ha sido de 2.778 millones de euros, un 29,6% (635 millones) más que el año anterior. Cabe destacar la progresión desde el año 2000 al 2006, donde la cifra de negocio se ha multiplicado por más de 13, pasando de los 204 millones en el 2000 a los citados 2.778 millones el año pasado.

Más de 5 millones de personas compraron por Internet en el 2006, esto representa un 13,6% del total de la población mayor de 15 años. En numeros relativos a internautas, el 27,3% realizo alguna compra el año pasado.

Entre los datos del perfil del comprados cabe destacar que el 59% son hombres, el 67% tiene entre 25 y 49 años y el 50% reside en ciudades de más de 100.000 habitantes.

En cuanto al tipo de compra. El numero medio de compras por usuario es de 4,7 compras al año, con un gasto medio de 523,6€ (un 8% más que el año anterior). Entre los tipos de productos comprados destacan: transporte (36,5%), entradas para espectáculos (16,9%), libros (13,9%), reservas para alojamiento (14,4%) y ropa y complementos (10,1%).

En lo que se refiere a los pagos, se sigue imponiendo el uso de tarjeta de débito o crédito (60,9%) frente al contrareembolso (25,7%) y la transferencia bancaria (8,4%). Otros medios (principalmente Paypal) se usaron en el 5% de las compras.

El 64,4% de los compradores declararon que las compras por Internet cubrieron siempre sus expectativas, y el 34,4% declararon que casi siempre. Con lo cual el índice de compradores satisfechos es del 98,7%.

Un dato interesante, que ha cambiado respecto al 2005, son las razones que dan los no compradores para no realizar sus compras en Internet. El 36% declara que prefiere comprar en un tienda física, el 24,6% tiene miedo a dar sus datos personales, el 23% desconfía de las formas de pago y el 15,9% cree que no lo necesita o que no es interesante.

El 72,8% de los compradores considera que en España hay una oferta suficiente para la adquisición de productos o servicios por Internet.

De estas cifras se desprende que el comercio electrónico en España sigue evolucionando, creo que no lo rápido que debería hacerlo para estar al nivel de otros paises de Europa (no digo ya de Estados Unidos), y es bueno que cada vez haya más gente que considere las compras por Internet como algo totalmente normal y seguro. En esto han tenido mucho que ver la venta de billetes de avión, reservas de hotel y entradas de espectáculos, que han introducido y normalizado el uso de Internet para adquirir los productos que están buscando los usuarios, y han abierto la puerta a otros productos o servicios.

Si queréis más detalles os podéis descargar el estudio completo.

No estoy de acuerdo del todo con esta definición, para mí debería ser “[…] independientemente de sus medios técnicos y de sus capacidades físicas.” La expresión “[..] independientemente de sus capacidades técnicas […]” para mí está más relacionada con la usabilidad, el problema es que a veces, ambas disciplinas se solapan.

La tendencia es considerar un sitio accesible si cumple las normas de la WAI y pasa los numerosos validadores que existen. Nada más lejos de la realidad. Es común considerar que el resultado positivo de los validadores automáticos de la accesibilidad es equivalente a cumplir con la norma WAI y por extensión, que el sitio es 100% accesible, pero no siempre es así (gracias Jorge por la matización). Veamos un ejemplo: supongamos que yo soy un discapacitado visual con una reducción de visión del 50% y utilizo Linux y Ópera. Accedo a una web que es accesible según los validadores automáticos, perfecto, pero resulta que está optimizada para Internet Explorer 6 o superior y en Ópera (más aún en Linux) se ve todo descuadrado, se solapan textos, imágenes… Teniendo en cuenta mi discapacidad, aún contando con ayuda, voy a ser incapaz de navegar por este sitio. ¿De que sirve que la web pase el test de la WAI si no se ve bien en mi navegador?, ¿consideráis que esta web es accesible?

El primer paso para conseguir una web accesible es asegurarnos de que cualquier usuario, independientemente de sus medios técnicos, puede visualizar e interactuar correctamente con nuestro sitio web. Debe ser indiferente si utiliza IE 7, o IE 6, o Firefox, o Safari, o Linux, o Windows, o Mac OSX, u otro sistema operativo, o si tiene Javascript deshabilitado, o si utiliza codificación iso, o si tiene el plugin de flash instalado…Una vez conseguido este propósito y la web sea accesible por cualquiera, es cuando debemos centrarnos en hacerla accesible, además, a los usuarios con discapacidades físicas. Sólo de esta manera tendremos una web accesible para todo el mundo.

Hay casos en los que parece imposible conseguir esto, pero siempre hay alternativas. Otra cosa es que no queramos o no podamos adoptarlas, en este caso se tiene que encontrar un punto de equilibrio. Si nos piden que realicemos una web en Flash, está claro que no va a ser accesible por todo el mundo. Podemos dejarlo así o hacer una versión en HTML del sitio y entonces sí lo será.

Hace pocos días estaba consultando una web de reservas de Hotel para ir a Madrid. Realicé una búsqueda y me devolvió este mensaje: “Opción no disponible para Safari”. Está claro que esta web no es accesible, pero al menos te indican que no soportan tu navegador, cosa que la mayoría no hace. Hay que informar siempre al usuario. Cómo deben ser los mensajes de error, es algo que corresponde más a la usabilidad. Con este ejemplo podéis ver, como decía más arriba, que las dos disciplinas a veces se solapan.

Hay que promover la accesibilidad y tenerla siempre en cuenta en nuestros proyectos, pero no lo olvidemos, primero hacer la web accesible a todo el mundo independientemente de sus medios técnicos, y sólo luego, hacer la web accesible a todo el mundo independientemente de sus capacidades físicas.