Autocompletado e historial de métodos en la consola de ruby (irb)

Publicado por blaxter - 16 May 2008 a las 16:16

Hoy le toca el turno a ruby. La consola de ruby, irb, tiene bastantes opciones de configuración, permitiendo, entre otras cosas, el autocompletado de métodos e incluso guardar un historial de comandos entre sesiones.

Muy simple, simplemente añade esto a tu fichero ~/.irbrc (si no existe, lo creas):

require ‘irb/completion’

IRB.conf[:SAVE_HISTORY] = 1000
IRB.conf[:HISTORY_FILE] = "#{ENV['HOME']}/.irb-save-history"
IRB.conf[:AUTO_INDENT]  = true
IRB.conf[:PROMPT_MODE]  = :SIMPLE

Puedes añadir otras opciones, e incluso personalizar el prompt el cual lo tengo a ‘simple‘ porque los otros modos son demasiado informativos para mi gusto (nunca he entendido esa manía de querer incorporar siempre el número de comando en todas las consolas de los lenguajes).

Autocompletado de métodos en la consola de python

Publicado por blaxter - 15 May 2008 a las 17:20

Estemos en el lenguaje que estemos, algo totalmente crucial es tener una consola para hacer pruebas rápidas. Si tú lenguaje no la tiene, es una puta mierda, que lo sepas. Una característica interesante es tener autocompletado de métodos, para ahorrarnos tener que mirar continuamente a la referencia. En python, podemos activar esta opción muy fácilmente en la consola normal ejecutando lo siguiente:

import readline, rlcompleter
readline.parse_and_bind("tab: complete")

Como ejecutarlo cada vez no es una opción, ponemos esas líneas en un fichero ~/.pythonrc.py (por ejemplo) y añadimos a nuestro ~/.bashrc una línea indicando que se ejecute al inicio

$ << EOF cat > ~/.pythonrc.py
> import readline, rlcompleter
> readline.parse_and_bind("tab: complete")
> EOF
$ echo "export PYTHONSTARTUP=~/.pythonrc.py" >> ~/.bashrc

Ya podemos iniciar una consola y tener autocompletado como debe ser :)

$ python
>>> class foo:
…    def ves_que_bien(self):
…       return "¡perrea! ¡perrea!"
…
>>> bar = foo()
>>> bar.<TAB>
bar.__class__     bar.__doc__       bar.__module__    bar.ves_que_bien

Por cierto, otra opción es instalarse ipython, una consola mejorada. Pero ya estás dependiendo de tenerla instalada, la consola python estará siempre, si o si.

RESTful Web Services

Publicado por blaxter - 11 May 2008 a las 18:27

Portada de “RESTful Web Services”Hace ya un tiempo que me acabé este libro. Su tema principal son los servicios web en general y los acordes a los principios REST en particular.

El libro contiene una 400 páginas, las cuales podrían resumirse y condensarse en una cuarta parte sin problemas, pero el autor continuamente está dando ejemplos y situaciones para plasmar cada concepto que explica. Incluso tenemos implementado, mostrando todo el código, un servicio web completo (gracias en parte a la brevedad de ruby).

¿Qué nos podemos esperar después de leerlo? Comprender de una vez por todas qué es eso del REST, término que asiduamente es malinterpretado y se ha convertido en una de las palabras clave a mencionar para quedar como si entendieses del tema (ya si lo nombras junto con rails, j2ee y [algo] business eres el puto amo).

¿Cuáles son los contenidos? En una primera parte nos habla de los servicios web en general, algo que puede servir para poner en contexto a quien no comprenda o este al tanto de qué y cómo son realmente.

Justo a continuación se nos explica toda la teoría y conceptos relacionados con la arquitectura orientada a recursos (ROA), la base y propósito de todo libro. Luego tenemos una aplicación de estos conceptos, tanto a nivel de diseño como a nivel de implementación. Estos capítulos, totalmente prácticos, sirven para afianzar todo lo anteriormente explicado, pues en pocas páginas el autor diseña e implementa aplicaciones reales (diseña un servicio de mapas, e implementa un agregador tipo del.icio.us). Después tenemos explicaciones concretas de aspectos específicos que podría llegar a tomarse como una referencia para crear servicios web que será realmente útil para cuando volvamos a recurrir al libro en momentos concretos de dudas.

Finalmente se hacen unas comparaciones con los WS-*, para mi sorpresa, sin meterse mucho con ellos (y no será por oportunidades…), pero que después de haber leído todo lo anterior choca bastante como todavía pueden existir cosas tan increíblemente estúpidas y absurdas (¡y que encima todavía se usan!). Para concluir también tendremos el capítulo de rigor sobre ajax y sus implicaciones al usar servicios web rest (pues una aplicación ajax puede tomarse como un mero cliente de un servicio web) y un breve recorrido sobre frameworks existentes que tratan REST (rails en ruby, django en python y restlet en java).

Este es un libro que lo recomiendo encarecidamente a cualquiera que esté o vaya a crear aplicaciones Web (que a día de hoy es como decir a todo el mundo). Incluso para quien crea haber usado exitosamente REST. Pues dada su popularidad creciente, es un término que continuamente se está enseñando y usando erróneamente (me incluyo aquí el primero, y eso que mi pfc iba sobre eso). Ha sido uno de los libros más vendidos del 2007 (de desarrollo de software claro) y no ha recibido pocos elogios que digamos.

Every developer working with the Web needs to read this book

David Heinemeier Hansson, creador de Ruby on Rails

Simplemente, un libro magnifico.

Generando javascript con código ruby embebido en rails 2.x

Publicado por blaxter - 03 May 2008 a las 16:05

Hay veces que es bastante útil y cómodo devolver en una petición código javascript para que sea ejecutado en el cliente (y actualice el interfaz del usuario o lo que tenga que hacer). En vez de realizar (1) Petición, (2) Generar datos, (3) recepción y procesamiento, (4) actualizar página; pasamos a (1) Petición, (2) generar código, (3) actualizar página. Es decir nos ahorramos el parseo, además nos ahorramos tener que cargar javascript (que procesa las respuestas) en el cliente y usando jquery/mootools/* se realiza todo el proceso de forma transparente (indicando en la petición ajax que esperamos recibir un script). Esta técnica será válida solo para pequeñas actualizaciones (que son mayoría) y principalmente para temas de interfaz (que suelen ser triviales), pues en definitiva el código que no se ve, es código difícil de mantener.

En Rails tenemos templates RJS que básicamente consiste en lo que acabo de comentar pero generando javascript con wrappers en vez de usar js sin más, algo que me parece absurdo, pero eso es otro tema. Para rails 1.2.x teníamos este maravilloso plugin de Dan Webb que te permite escribir javascript con ruby embebido en él, algo como:

<% @ids_to_modified.each do |id| %>
   $(‘#’ + <%= id %>).removeClass(‘<%= @class_to_remove %>’).highlightFade();
<% end %>

Desde Rails 2.x ya no es necesario el uso del plugin (en parte porque ya no va), pues podemos hacer esto mismo gracias al nuevo formato de las vistas.

Ahora todas las vistas tienen el formato nombre.formato.template_engine, por ejemplo lo típico sería algo como: nombre.html.erb. Pero, ¿por qué no tener plantillas como nombre.js.erb?. De esta forma tendremos, sin incorporar plugins ni nada, la funcionalidad antes comentada, generar javascript permitiendo ruby embebido (es decir, usando erb).

Para hacernos la vida algo más simple, vendría bien incorporar ciertas funciones y helpers. En tu application.rb, no estaría de más tener algo como:

def respond_with_js
    respond_to{|format| format.js }
end

Por lo que nuestras acciones que vayan a ser llamadas mediante xhr tendrán una pinta tal que:

def vote
   # hacer lo que sea…
   respond_with_js
end

Tenemos que tener en cuenta también, que el javascript generado debe de ser válido (por ejemplo escapar comillas en las cadenas, o similares). Para asegurarnos que algo es javascript válido, nada mejor que usar json por lo que podemos pillar prestado del plugin de MinusMOR su helper (y añadirlo a application_helper.rb)

def js(data)
  if data.respond_to? :to_json
    data.to_json
  else
    data.inspect.to_json
  end
end

Por lo que ahora podemos escribir cosas tal que:

$(‘div.cancel’).append(
    <%=js link_to(‘Cancelar’, :action => ‘cancel’) %>
);
# o
alert(<%=js error_message_for(@error) %>);

Finalmente, si queremos usar partial’s tendremos que añadir este helper para soportar el nuevo formato de las plantillas (gracias a mad.ly):

def partial(name, options={})
  old_format = self.template_format
  self.template_format = :html
  js render({ :partial => name }.merge(options))
ensure
  self.template_format = old_format
end

Fíjate que no estamos sobreescribiendo el render :partial típico, es un helper simplemente. Para usarlo tendríamos que hacer algo como:

$(’#some_div’).html(<%=partial ‘movie_information’, :object => @movie %>);

En definitiva una forma mucho más cómoda, potente y simple de generar javascript desde el lado del servidor. Aunque insisto en que solo se debería de usar esta táctica para cosas triviales y pequeñas.

Creative Commons License Esta obra está bajo una licencia de Creative Commons.

Este blog funciona gracias a WordPress con el theme GimpStyle diseñado por Horacio Bella y adaptado por un servidor.
Feed entradas