Superators: creando operadores en Ruby

Superators es un gem de Ruby escrito en Ruby puro que permite crear nuevos operadores, aunque con ciertas limitaciones. Ahora es posible hacer cosas como este ejemplo de Aleks (heh, qué pequeño es el mundo):

["aleks", "bob", "monkey", "zebra"] <~ ["joseph", "xylophone"]

o se me ocurre:

status +-

para negar el valor de una variable (i.e. status = !status). Utilísimo para DSLs o proyectos muy personales. Demasiada magia no es buena.

ActiveRecord hasta en la sopa

PROBLEMA:
Estás aburrido por terminar y te piden hacer algo aburrido con la base de datos, que sería un paseo en el parque si el proyecto fuese Rails y pudieses manejar las tablas con un modelo de ActiveRecord.

SOLUCION:
Leer la historia de Tchaikovski en la Wikipedia.

Pasando a otro tema, si quisieran usar ActiveRecord fuera de Rails, lo más básico es:


require 'rubygems'
require_gem 'activerecord'

ActiveRecord::Base.establish_connection(
  :adapter => 'mysql',
  :host => 'localhost',
  :database => 'chifa',
  :username => 'chifa',
  :password => 'wantan_quemado'
)

y simplemente agregas y usas tus tablas:


class Platos < ActiveRecord::Base end Platos.find :all

Si la pluralización es un problema, entonces simplemente fuerza el nombre de la tabla:


class ColorRojo < ActiveRecord::Base   set_table_name :en_extremo_ff000000 end

Un website cristiano hecho en Django

Tabo me envió por mail (¡gracias!) este post de Luke Plant sobre sus apreciaciones de tiempo y velocidad de desarrollo ilustradas con un proyecto suyo hecho en Django, que es un website para campamentos cristianos.
Es realmente interesante y me he descargado el código fuente para leerlo, ya que siempre se puede aprender muchas cosas de otra persona.

Aparte de Retrazos, otro conejillo de indias para mi aprendizaje de Ruby on Rails es Via7, un website que hice hace tiempo para jóvenes creyentes. Originalmente en PHP, Via7 era un gran hack a un phpBB que quedó en el descuido al expirar el dominio.

Espero que sea muy pronto poder tener el mismo gusto de Luke de anunciarles la finalización del proyecto. Aunque todos sabemos que la web de una comunidad nunca termina. ;)

Retrazos: un pequeño proyecto

No hace mucho publiqué este dibujo hecho con ciertas limitaciones: 5 minutos de tiempo máximo, un canvas de 300×300 pixels y un solo color para acompañar los trazos.
He venido haciendo otros varios más, y como mi cerebro olvida selectivamente lo que prometimos acerca de las amanecidas programando, empecé a armar este pequeño proyecto en esas “horas extras.”

La idea inspiradora de esto provino de las mini-sagas y, más que nada, de este artículo de Kathy Sierra, sobre la “creatividad a velocidad.”

El proyecto se llama “Retrazos” y la dirección es retrazos.jgwong.org.

Es, en esencia, una galería de los dibujos que he venido haciendo todo este tiempo, y que pienso seguir produciendo de manera regular. Poco a poco he ido dejando de lado las limitaciones originales. Los hago a 400×400 pixels, a veces los hago en menos de 5 minutos, a veces no. Ya estoy queriendo dejar la limitante de un solo color también. Y creo que eso es bueno, pues estoy logrando hacer algo que me hincaba a menudo: dibujar más.

Nada reemplaza al trabajo duro y a la práctica constante, así que con esto mato dos pájaros de un tiro: dibujar más y poner en práctica lo que voy aprendiendo de Ruby on Rails. El sistema lo hice en menos de lo que canta un gallo — es sencillo, tiene su backend de administración y hasta su feed RSS. ;)
Suscríbanse y avísenme si no funciona, ya que mi lector de feeds es sólo texto y no he hecho pruebas extensivas.

Espero que les guste. Ahora me toca tener la suficiente disciplina y tiempo para mantenerlo actualizado.

Ultimamente estoy percibiendo que la única forma de obtener más tiempo es reduciéndolo…

Mejorando mi carrera

Una de las metas más relevantes que me he trazado para este año 2006 es “He mejorado en mi carrera, soy más veloz, más eficiente.” A principios de año me sentí estancado, como si hubiese llegado a cierto punto donde mis conocimientos me son suficientes para mi trabajo y todos los proyectos que veía eran más de lo mismo y nada nuevo, ningún reto, a menos que yo mismo me imponga uno para mejorar procesos. Eso es algo que me ha venido preocupando.
He estado intentando aprender cosas nuevas (PEAR DataObjects, AJAX), pero sentía, como le contaba a mis padres, que todos alrededor mío siguen avanzando y yo me estoy quedando atrás.

He tenido muchas sorpresas con lo que el Señor me ha estado enseñando con esta meta trazada, todo por diversos factores como, por ejemplo, mis ideas prehistóricas de cómo debo hacer las cosas o la falta de interactuar más con otras personas, colegas, amis linuxeros.
Voy a darles una vista general de las cosas que me han venido aconteciendo últimamente. Todo esto ha venido sucedido desde Enero y entre punto y punto hay a veces varias semanas o meses de separación. Algunas se solapan entre sí. Bueno, empecemos:

– Primeramente como mencioné ambiguamente en un post atrás, Tabo me habló de Python y Django y ese solo consejo me abrió muchas posibilidades. Ya entendí que PHP no es el futuro, a menos que reescriban todo el lenguaje desde cero y reinventen Python o Ruby.

– Luego encontré este fabuloso blog de Kathy Sierra junto con este todavía más fabuloso post acerca de la neurogénesis y una interesante conclusión: “Aprender cura el cerebro.”

– Me puse a aprender Python y Django simultáneamente.

– Hablando con Antonio acerca de PHP5, Ruby y un poco de Python, llegué a una conclusión importante que me dio mucha confianza: que puedo aprender cualquier cosa. Al descubrir esto me dí cuenta que una parte de mí dejó de creer que tengo la capacidad de aprender, un tipo de “ya estoy muy viejo para aprender tantas cosas,” lo cual me parece absurdo. ¿Desde cuándo he empezado a pensar así y por qué?

– Cuando regresé de Lima volví a visitar el blog de Kathy (tengo mi lector RSS desactivado por motivos productivescos) y me encontré con este post acerca de cómo volverse un experto en cualquier rama. Menciona la diferencia entre expertos, novatos y mediocres, pero lo más interesante es este párrafo que se los traduzco:
“Oh si, acerca de esa cosa de que nunca es tarde… la mayoría de nosotros puede despedirse de la medalla Olímpica de patinaje sobre hielo. Y a mis 5′ 4”, mi carrera de basketball no tiene probablemente esperanzas. Pero piensa en esto… la actriz Geena Davis casi calificó para el equipo Olímpico de tiro con arco de Estados Unidos en un deporte que ella tomó a la edad de 40, menos de tres años antes de las calificaciones Olímpicas.

– Luego Droper compartió este post que me gustó mucho sobre Matemáticas para Programadores.

– De ese post salté a este otro enlace que me pareció todavía más fascinante y, a mitad del artículo pensé “¿Desde cuándo las matemáticas me parecen fascinantes?” Siempre le he tenido miedo a las matemáticas y he tenido muchas dificultades toda mi vida.

– Recordé entonces a mi hermano que nunca fue bueno en matemáticas en el colegio. Cuando ingresó a Ingeniería Civil no se rindió ante la idea de tener que masticar matemáticas. Hoy le gustan las matemáticas y daba clases a los hijos de algunos creyentes en Covida. Creo que una de las cosas que lo inspiró fue Johnny Rico, el protagonista de Starship Troopers (el libro, la película no existe).
Al principio a Johnny le hacen un examen del cual los resultados son: “insuficiente entendimiento intuitivo de relaciones espaciales… insuficiente talento matemático… preparación matemática deficiente… tiempo de reacción adecuado… buena vista.” Como algo paralelo a toda la historia, uno ve a Johnny estudiando duro matemáticas, recibiendo tutoría de diversas personas y preocupándose por haber dejado sus libros en otra nave espacial.
Johnny dice “Matemáticas es trabajo duro y ocupa tu mente — y no duele aprender todo lo que puedas de ello, no importa en qué rango estés; todo lo que sea de importancia está fundado en matemáticas.”
He aprendido que esa última frase es muy cierta. Von Neumann se levantaría de su tumba y te comería el cerebro personalmente si te atreves siquiera a cuestionar eso.

– Mirando en el mismo website de Math a Day, llegué a este artículo y mientras lo leía pensaba, “Esta persona ha trabajado en Amazon, haciendo cosas realmente interesantes — ¿por qué yo no hago esas cosas?” y llegué a muchas conclusiones que todavía quiero terminar de meditar. Mas una de ellas es firme: Amazon usa mucha matemática brillante para funcionar.
El artículo trata acerca de practicar programación, como cuando uno practica pesas. No es algo que haces en tu trabajo diario, sino algo que debes hacer de manera separada, dedicada, aparte.
Si aprecias tu carrera, por favor lee ese artículo. La parte que más me llamó la atención es la siguiente:
De todas tus habilidades como programador, ¿cuáles de ellas podrían ser consideradas “intemporales”? Encáralo: la mayoría de tu conocimiento técnico tiene un tiempo de vida, una fecha de expiración.
[…]
Lo que yo creo que encontrarás es que matemáticas, ciencias de la computación, escritura, y habilidades sociales son en su mayor parte intemporales, habilidades universales. Las tecnologías más específicas, lenguajes y protocolos eventualmente expiran, para ser reemplazadas por mejores alternativas.”

– En un momento dado me dí cuenta que, sin querer, estaba logrando cumplir esta meta que me había trazado. A diferencia de otras metas donde le pongo bastante empeño conciente, esta meta cayó por sí sola y las cosas se movieron “sin esfuerzo” de parte mía. Me dí cuenta que es el Señor quien estaba moviendo las circunstancias.

– Pasaron varias semanas y una noche decidí mirar Ruby y Rails y cambié mi rumbo. Quedé fascinado con el lenguaje Ruby y sigo aprendiendo desde entonces más de Ruby y Rails.

– De un momento a otro me dí cuenta que había crecido. Fue progresivo, y en un tiempo relativamente corto, pero mi vida ha dado muchos giros comparado a lo que “tenía” a principio de año.

– Una vez que estuve en Peruserver cogí por segunda vez un libro de matemáticas que hay en la biblioteca y Antonio me dijo, “Ya que tanto quieres aprender, ¿por qué no te metes a la universidad?”

– Sigo aprendiendo Ruby y Rails. He meditado seriamente la idea de meterme a la universidad, mas por ahora no siento la Voluntad del Señor por esa ruta; otras puertas se han estado abriendo por otra ruta que espero comentar en otro post. Eso no descarta que siga aprendiendo y creciendo por mi cuenta.
Gracias a Savre, voy a hacer averiguaciones para tomar cursos y llenar esas lagunas que tengo.

Y la vida continúa… :) No hay conclusión, no hay punch line. Esta es mi vida y siguen apareciendo oportunidades y puertas que se abren, puertas que se cierran, todo siempre interesante.

Ruby on Rails, o por qué lo elegí en lugar de Django

Sí, el título es una mención directa al post de Tabo, “Django, Or why I chose it over turbogears and ruby on rails.”

¿Por qué elegí Rails en lugar de Django? Una sola palabra: Ruby.

Podría mencionar muchas cosas acerca de la convención sobre configuración, Active Record, erb y el magnífico soporte de AJAX, pero lo cierto es que, tal como dijo David Heinemeier Hansson (el autor de Rails), “Rails no sería Rails si no es por Ruby.”

La belleza de Rails proviene de Ruby, ese lenguaje de programación todavía nuevo, donde es posible hacer cosas de manera tan expresiva y divertidas (uno no escucha esa palabra muy a menudo últimamente) que simplemente tu productividad aumenta considerablemente. Ya no te detienes a pensar cuál era la sintaxis de str_pad(), ni tampoco memorizar “from django.shortcuts import render_to_response, get_object_or_404”, sino simplemente hacer tu aplicación.

Antes de aprender Rails, me puse a aprender Python y Django. Ya había visto un poquito de Python y era un lenguaje que me llamaba la atención. Ruby para mí era exactamente como el japonés — algo desconocido y foráneo. De modo que mi primera elección fue la ruta de la culebra.
Cuando me senté a aprender Django encontré algunas trabas que no me gustaron, pero que alegremente estuve dispuesto a aceptar hasta quizás acostumbrarme. Como por ejemplo, tener que teclear “from django.shortcuts import render_to_response” para mostrar una plantilla, algo que el tutorial mismo dice, es tarea común — y si es común, ¿por qué no viene por defecto? No hay problema, mi editor puede escribir todo eso por mí.
Luego me encontré con esta parte de Generic Views, donde el encabezado de la documentación dice: “Generic Views: Menos código es mejor” y luego proceden a mostrarte unas líneas monstruosas como “django.views.generic.list_detail.object_detail” y “django.views.generic.list_detail.object_detail”.
Me pareció una contradicción, pero no me hice líos. Puedo memorizar todo eso y en su momento lo hice.
No sé si el Magic Removal branch ahorra todo esto, pero veo el mismo código en el tutorial.

Estuve un par de semanas con un par de horas por las noches aprendiendo poco a poco y construyendo una aplicación web sencilla (“chifa,” el website exclusivo para mezclar wantan, palta y chijaukai y ver qué evoluciona del resultado). Django trae un servidor web propio para desarrollar tu aplicación sin trabas, pero extrañamente cuando grababa cambios a un script en Python y éste tenía un error de sintaxis, el servidor web se colgaba con una excepción. Tenía que pulsar CTRL+C y reiniciarlo. Como tengo la costumbre de grabar constantemente esto me fue irritando.
Continué así un tiempo, aprendiendo en silencio hasta que viajé a Lima y Antonio me animó a aprender Ruby (y Rails). En otro post trataré de ahondar en este tema, pues tiene mucho que ver con un montón de sucesos que el Señor me ha ido mostrando en esta primera mitad del año que me parece increíble — um, pero eso es tema de otro post.

Versión resumida: regresé a Ica con el interés en Ruby on Rails y, después de un par de días de resumir mis clases de colegio con Python, me dije “Bueno, vamos a probar ver Ruby por una noche.” No me haría daño, ¿verdad?

El hecho es que probé Ruby y jamás dí la vuelta atrás.

No recuerdo la última vez que me he sentido tan fascinado por un lenguaje. Ahora que lo pienso, creo que nunca me he sentido fascinado por un lenguaje… ni siquiera por PHP, que, tras haber visto Ruby, me parece… prehistórico.

Pero bueno, estamos hablando de Rails y no de Ruby — pero es que la verdad no se puede hablar de Rails sin tropezar con la belleza de Ruby. No entiendo a qué se refiere Tabo cuando dice que el lenguaje no es “limpio” — lo que sé es que es expresivo y legible. Bello. Y uno se siente raro usando esa clase de adjetivos para describir un programa, pero tarde o temprano se vuelve inevitable. Eres feliz.

Basta de sentimientos cursis, vamos a lo técnico.

Convención sobre configuración
Este es un concepto importante de Rails, y quiere decir que, a menos que se especifique lo contrario, existe una convención o forma standard de comportamiento o nombramiento para cosas comunes. Esto nos ahorra bastante tiempo.
Por ejemplo, para una tabla “alumnos” de la base de datos se espera que la clase que va a manejarla se llamará “alumno” (singular). Rails tiene todo un sistema de pluralización que es fácilmente extensible para el caso del español. Pero el concepto va más allá. Y eso nos lleva a…

Rails es menos código
En Django tienes que especificar siempre qué plantilla vas a mostrar retornando un objeto HttpResponse. ¡Para la práctica totalidad de páginas tienes que hacer “from django.shortcuts import render_to_response”!
En Rails, gracias a la convención sobre configuración, se asume que a la acción “lista” le corresponde una vista “lista.rhtml”. No hay nada extra qué especificar. Si quisiéramos que la acción use una vista de distinto nombre, lo decimos de manera simple y expresiva:

render :action => “lista_filtrada”

Oh, la convención es que la extensión de la vista puede ser “.rhtml”, así que tampoco es necesario especificar eso. En Django viene a ser algo así como:

return render_to_response(‘alumnos/lista_filtrada.html’, {‘lista_alumnos’: lista_alumnos})

Igualmente, para usar las bondades el ORM de Django tenemos que especificar el modelo que queremos usar:

from itskool.alumnos.models import Alumno

En Rails no hay necesidad de especificar nada.

RailsRuby es más expresivo
Estoy enamorado de poder decir:

  • if expiracion > 30.seconds.ago
  • limite_maximo = 4.megabytes
  • create_table :alumnos do |t|
      t.column nombre, :string
      t.column apellidos, :string
      t.column fecha_nacimiento, :date
    end

Aparte Ruby nos permite hacer cosas fabulosas que lastimosamente no caben aquí y es materia de otro post.

Rails no tiene URLs flexibles
A diferencia de Django, el routing de Rails no es tan flexible. Esto se debe a que Django usa expresiones regulares, mientras que Rails está basado en elementos separados por slashes (“/”).
La pregunta es, ¿cuántas veces vamos a usar esa flexibilidad? Ok, puede servir para mantener la estructura de URLs de un proyecto que estamos portando a Django, ¿mas cuántas veces sucede eso? Si la idea es tener URLs bonitos, creo que “/noticias/2005/05” es suficientemente bonito y limpio para la gran mayoría de casos.

El problema de la flexibilidad de las URLs Django es que tiene un precio muy alto: los desarrolladores se ven forzados a crear un método en el modelo para generar la URL correcta para la vista (el afamado get_absolute_url()), una clara violación del DRY y del MVC. El mismísimo Adrian Holovaty acepta que esto es feo, pero que no hay mejor solución por el momento.
Esta complicación no me parece que justifique una flexibilidad que en el 80% de los casos no se va a aprovechar.

Rails no sufre de este problema.

Active Record rulez!
En Rails lo normal es crear las tablas en la misma base de datos y Rails automáticamente adopta los campos de cada tabla. Si alteramos una tabla y agregamos un campo lo podemos usar inmediatamente en Rails.
En Django, la estructura de la tabla se define en el mismo modelo de Django, lo cual es genial porque sirve de abstracción a la base de datos — no importa si es MySQL o PostgreSQL, sólo tienes que correr el mismo script. Rails puede hacer lo mismo. Se llama migraciones y es más cool, pero sigamos con Django.
En Django, si altero una tabla para agregar un campo tengo dos opciones:

  • Hacer la modificación en mi modelo y volver a crear la tabla — perdiendo así los datos que tengo en ella. Esto es incómodo en muchos casos.
  • La otra opción es alterar la tabla en la base de datos con un ALTER TABLE y luego agregar el campo en el modelo. Dos veces lo mismo. Y al hacer un ALTER TABLE se pierde la magia de la abstracción que Django pretendía evitar.
  • Si nos interesa tener un esquema de la base de datos así abstraído lindo como Django,existen las migraciones. Lo genial de las migraciones es que se definen en un script donde puedo hacer y deshacer los cambios. Por ejemplo, esta es una migración para renombrar un campo:

    class RenombrarNickAApodo < ActiveRecord::Migration   def self.up     rename_column :alumno, :nick, :apodo   end   def self.down     rename_column :alumno, :apodo, :nick   end end Con este esquema puedo subir estos ficheros de migración a mi servidor de producción y hacer todos los cambios que ya probé localmente. Y si rompí algo, puedo deshacerlo en el instante. Lindo, ¿verdad? Algunas cosas que quería mencionar más en profundidad, pero bueno, me he quedado sin tiempo: Django es una excelente pieza de código, probado y desarrollado "en el campo." Se nota bastante su origen orientado a websites de periodismo, el módulo out-of-the-box de administración es un gran plus, y espero que pronto hagan algo similar en Rails -- una buena idea para un proyecto personal. Mirando debajo del capó de Rails, te das cuenta que su naturaleza es diferente, tanto en su funcionamiento como en su filosofía. Rails tiene un fabuloso soporte de Ajax y la comunidad es mucho más grande que la de Django y crece a un ritmo vertiginoso. Las personas que encabezan esta comunidad son programadores brillantes. Django es bastante capaz, pero Rails lleva, por el momento, la delantera por un gran margen.

    Belleza de código

    La primera vez que leí acerca de “belleza” en programación fue en un escrito de Paul Graham. La segunda vez fue a Tabo haciendo referencia al evangelismo de belleza de David Heinemeier Hansson sobre Ruby y programación en general en el video de Snakes and Rubies.
    Tengo otra idea muy familiar que, personalmente, conozco bajo el nombre de “elegancia.” Código que es “elegante” y soluciones “elegantes” a problemas complejos. En mi cerebro he catalogado “elegancia” y “belleza” como dos ideas no intercambiables. Ojo que esta es mi categorización personal, nada canónico:

    “Belleza” de código es la diferencia motivacional que existe entre:

    inicio = Time.now.beginning_of_day

    y

    $inicio = mktime (0, 0, 0, date (“m”), date (“d”), date (“Y”));

    El primer código, en Ruby, es a todas luces guapísimo. :)

    “Elegancia” es, en mi diccionario, algo que no tiene que ver mucho con cómo se ve el lenguaje, sino pasos ingeniosamente elaborados para la resolución de un problema de la mejor forma posible. El código no será necesariamente bello, pero la solución puede ser elegante.

    PHP es, definitivamente, no bello — por decirlo de una manera agradable. Sin embargo, eso no le quita que podamos escribir código elegante en él.

    Vamos con un ejemplo real.

    Estoy actualmente trabajando en un proyecto sujeto a bastantes cambios estructurales. Escribí una función de búsqueda para cada uno de los tipos de registros que manejamos en base a ciertos criterios. Estas funciones devuelven un array con los resultados. Por ejemplo:

    function actividades_buscar ($db, $vista, $localidad, $linea, $mes, $anyo, $pagina)

    Esta función se llamaba desde un solo lugar inicialmente, luego conforme vinieron los cambios empecé a usarla en algo de cuatro lugares distintos del sistema. En el lugar original no había mucho problema en entender el código, ya que le alimentaba con variables recibidas por GET.
    Sin embargo, en los otros lugares donde hacía búsquedas predefinidas (hardcoded) como que ya no era tan legible:

    $resultados = actividades_buscar ($db, “general”, “0000000000”, -1, -1, -1, $pagina);

    (Ough!)

    Pero lo peor fue cuando el cliente decidió añadir más criterios de búsqueda… así que añadí un par de parámetros más a mi función y actualizar en todos los lados, pero oops! se me escapó en una parte y el cliente detectó el bug. Ok, a corregir.

    Luego el cliente decidió añadir otro criterio más de búsqueda y ya me estaba doliendo (podría decir físicamente) cambiar en N-lados lo mismo y tener un código que era horrible. La gota que derramó el vaso fue cuando el cliente pidió que también se pudiesen ordenar los resultados por columnas y tenía que pasar un parámetro de ordenamiento a mi función de búsqueda quedandome con una definición de:

    function actividades_buscar ($db, $vista, $localidad, $linea, $acciones, $mes, $anyo, $criteria, $mes_inicio, $anyo_inicio, $mes_fin, $anyo_fin,$sort, $pagina)

    (Oh, la humanidad.)

    Obviamente no iba a entender ni papa de qué cosa es qué aquí:

    function actividades_buscar ($db, “regional”, “0000000000”, -1, -1, -1, -1, ”, -1, -1, -1, -1, ”, $pagina)

    Este código era tan horrible que me dije “Es un asco. No puedo creer que esto exista.” No tenía tiempo para corregir eso, pero era tan horrible y tenía tanto miedo que me pidiesen otro cambio en esa parte que decidí dejar de lado todo y sentarme a reescribir todo eso.

    La solución final fue pasar cada uno de los criterios de búsqueda en un array, y si no mencionamos un criterio, éste obtiene un valor por defecto sensible. Eso significó reducir la declaración de mi función a:

    function actividades_buscar ($db, $params)

    y llamar la función con solamente los parámetros necesarios de la siguiente manera mucho más legible y elegante:

    $resultados = actividades_buscar ($db, array (
            ‘vista’ => ‘general’,
            ‘pagina’ => $pagina_actual,
       )
    );

    Ahora sí tengo paz. :)