Category Archives: Programación

¿Qué es la programación?

Ya sabemos cómo podríamos comparar el desarrollo del software. Pero, ¿cómo podríamos definir la programación? (Visto en coding horror).

Programming is all about knowing when to boil the orange sponge donkey across the phillipines with an orangutang gorilla crossed with a ham sandwich to the fourth power of twelve across the nile with an awful headache from the previous night when all of alfred’s naughty jalapeno peppers frog-marched the nordic elves across the loom-lined geronimo induced swamp donkey over and above the fortran fortified kilomanjaro fence past the meticulously crafted anti disgusting sponge cake scenario where all the hats doth quoteth the milk which is not unlike the super werewolf from the infinite realm of ninja-step. it’s hard to define, really.

Una traducción pésima podría ser algo así como:

En la programación todo consiste en saber cuándo hervir la esponja del mono naranja en las Filipinas con un gorila orangután cruzado con un bocata de jamón a la cuarta potencia de doce a lo largo del Nilo con un espantoso dolor de cabeza de la noche anterior cuando todas las traviesas guindillas de paco llevaron a la fuerza a los elfos nórdicos por el telar geronimo provocados por el burro del pantano por encima de la fortificada valla del Kilimanjaro pasada la lucha contra el meticulosamente preparado bizcocho asqueroso donde todos los sombreros citaban la leche la cual no se diferencia de los super hombres lobo del infinito dominio de los ninja. Es difícil de definir, en serio.

Breve y conciso.

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

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

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.

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

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.

Comparando reales sin terminos naturales

Lo sé, el título no tiene mucho sentido, pero quería hacer una rima. Veamos una pequeña sesión en la consola de ruby

>> value = 69.99
=> 69.99
>> value * 100
=> 6999.0
>> value * 100 == 6999.0
=> false
>> a = value * 100
=> 6999.0
>> b = 6999.0
=> 6999.0
>> a.class == b.class && a.is_a?(Float)
=> true
>> print "#{a} es distinto a #{b} obviamente" unless a == b
6999.0 es distinto a 6999.0 obviamente
>> a.floor
=> 6998

Nada fuera de lo normal, ¿no?. ¿O si?.

Erlang: software para un mundo concurrente

Desde hace muchos meses quería meterle mano a Erlang. Lenguaje de programación funcional, concurrente y dinámico. Cada vez es más latente la importancia de la concurrencia, en unos años lo raro será ver procesadores de un solo core, o sistemas de un único nodo.

Acabo de empezar (con calma, que solo suelo leer en el bus) el libro de Programming Erlang de Joe Armstrong, que dado que es de la editorial de Dave Thomas, The Pragmatic Bookshelf me da muy buenas vibraciones.

Traduciré uno de los párrafos inicial del libro que crea unas expectativas realmente interesantes sobre este lenguaje creado por Ericson hace 21 años:

Erlang es un lenguaje donde la concurrencia pertenece al lenguaje de programación y no al sistema operativo. Erlang hace fácil la programación paralela modelando el mundo como un conjunto de procesos paralelos que únicamente pueden interactuar entre si mediante intercambio de mensajes. En el mundo de Erlang, hay procesos paralelos, pero no bloqueos ni métodos de sincronización y tampoco posibilidad de corrupción de memoria compartida, ya que no hay memoria compartida.

Los programas en Erlang pueden estar formados desde miles a millones de procesos extremadamente ligeros que pueden ejecutarse en un solo procesador, en uno de varios núcleos o en una red de procesadores.

Ahí queda eso. No sé si luego podré usarlo en entornos del MundoReal™ tan fácilmente como otros lenguajes más conocidos, pero solo por ver su enfoque al tratar los problemas creo que valdrá la pena. Por ahora ya tengo el interprete instalado y su equivalente a CPAN, llamado cean. Instrucciones para dummies, como un servidor (o eso me dice Amazon), en Ubuntu 7.10:

$ sudo aptitude install erlang
$ wget http://cean.process-one.net/download/cean.tar.gz
$ tar xfz cean.tar.gz
$ sudo mv cean-1.3/ /usr/lib/erlang/lib/
$ erl
Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [kernel-poll:false]
 
Eshell V5.5.5  (abort with ^G)
1> cean:version().
"CEAN Erlang/OTP"