Digo yo que si en el mundo REST un POst te permite crear (Create) un recurso; un Get te permite obtener una representación de un recurso (leer, Read); un PUt te permite modificar (Update) un recurso; y un Delete te permite borrar (Delete), un recurso… POGPUD será la versión RESTful de CRUD.

Vamos, digo yo xD

Asís y yo hemos decidido hablar un poco sobre JRuby en el seminario introductorio de Rails del jueves, ya que esperamos que la mayoría de los asistententes vengan del mundo Java.

Para preparar el material he vuelto a revisitar la página del proyecto que tenía un poco abandonada. Me ha sorprendido lo mucho que han avanzado y como han mejorado la integración con Java. Es bastante sencillo:

1
2
3
4
5
6
7
8
9
10
11
12
13

include Java
import 'java.util.ArrayList'

list = ArrayList.new
list.add "uno"
list.add "dos"
list.add "tres"
list.each do |n|
  puts "num: #{n}"
end

list.class.name # => "Java::JavaUtil::ArrayList
list.java_class.name # => "java.util.ArrayList"

Esto y mucho más, en el wiki. La verdad, crear ventanas swing desde jirb hace que un escalofrio te recorra toda la espalda. Curioso cuanto menos.

NOTA: Un día de estos pruebo a desplegar alguna de nuestras aplicaciones con JRuby en un Tomcat utilizando Goldspike y os cuento.

Ayer, mientras estabamos introduciendo a un profano al mundo de Ruby on Rails surgió una breve pero interesante discusión, acerca del uso de métodos como delegate_method frente a su contrapartida “procedural”. Esto es:

1

delegate_method :country_name, :to => :country, :as => :name, :default => 'Unknown'

frente a:

1
2
3

def country_name
  country.name || 'Unknown'
end

que viene siendo, más o menos, el código que genera dinámicamente delegate_method.

Sin entrar en temas acerca de reutilización de código, mejor gestión del cambio, etc. etc. (que me parecen bastante obvios), la discusión se centraba en que nuestro “profano” (y lo digo con todo el cariño, porque confío en que será un fervoroso converso en el futuro) consideraba que el segundo pedazo de código era más claro y sencillo. Asís, por el contrario, indicaba que la versión declarativa era mejor, más expresiva y autodocumentada, ya que, por su propia naturaleza, declara lo que se está haciendo y no cómo se está haciendo. Yo no puedo estar más de acuerdo con Asís. El segundo código “pide a gritos” un comentario para “declarar” qué hace y no obligar a un posible lector a discernirlo en función de cómo lo hace.

Quizás el ejemplo es demasiado simple para convencerse, así que propongo aquí otro código como ejercicio filosófico-mental, utilizando la librería has_finder, cuya funcionalidad va a ser introducida en el core de Rails. Echadle un ojo.

1
2
3

class Order
  has_finder :unpaid, :conditions => {:paid => false}
end