Al menos de acuerdo a este test, lo soy. Incluso soy cuatro quintas partes Hombre Araña y tres cuartas partes Superman:
Creo que no me quedará más remedio que repetir:
En el día más brillante, en la noche más oscura,
el mal no escapará de mi vista.
Aquellos que adoran al mal
que teman mi poder,
la luz de Linterna Verde
(Y lo primero que haré con mis super poderes será hacer pagar al que incluyó esos 55% Supergirl y 45% Mujer Maravilla ;-) )
Y tú, ¿qué super héroe eres?
Desde que me enteré de la existencia de Google Earth había esperado la aparición de alguna aplicación web para crear y documentar rutas de bicicleta. Sabía que la espera no podía ser muy larga.
He encontrado, hasta ahora tres aplicaciones con ese objetivo. Las tres tienen características básicas en común: dibujo e información de la ruta y de los puntos por lo que pasa. Las tres comparten también una carencia (aunque no muy desalentadora) para nosotros los que vivimos fuera del primer mundo: no hay información de Google Maps en esta parte del planeta, sólo información satelital (imágenes de Google Earth).
La primera y más sencilla aplicación, Dave's Running Route Database, solo permite dibujar la ruta, sin información detallada de ella. Aunque en una primera prueba que hice, al consultar la ruta terminada, la dibujó en algún lugar del Atlántico Sur, cerca del Antártico. Habría que pedalear mucho en esas condiciones ;-)
La segunda aplicación es Bikely. Tiene información de la ruta, de los puntos por donde se pasa, distancia, gráficos de elevación, una hoja de ruta (Cue sheet) y exporta la ruta en un archivo para GPS. Rapmax tiene un muy buen post más detallado sobre esta aplicación.
La tercera aplicación, y mi favorita hasta ahora, es RouteSlip. Además de las opciones ya mencionadas en las otras dos, tiene un área de edición más grande (que aparece al principio siempre como "mapa", así que hay que cambiar a "satélite"), más detalles de los tipos de puntos por donde pasa la ruta (doblar a la izquerda/derecha, pasar, cruzar, reagruparse aquí, etc.) y un diario o bitácora, para registrar información del ciclista y de las rutas hechas (fechas, paseos, distancias, escaladas, condiciones ambientales, etc.).
Como prueba registré una ruta sencilla y muy popular entre los ciclistas de Barquisimeto, la ruta Barquisimeto – Yaritagua:
Ojalá veamos pronto muchas rutas cercanas registradas allí.Nota mental: Necesitas reparar la bicicleta y empezar a entrenar de nuevo.
Una pregunta es una de las mejores oportunidades para aprender. Otra de esas oportunidades se dan cuando uno se tropieza con cosas que nos invitan a investigar, curiosear. En este caso es sobre el uso de la palabra "gocho" como gentilicio de los andinos venezolanos, su significado y el supuesto origen francés de la palabra.
El diccionario de la lengua española define "gocho" como "Voz con que se llama al cerdo", o un coloquialismo para "cerdo". En otro sitio en Internet ubican el origen de la palabra en el Norte de España (Asturias, León). Se entiende aquí "cerdo" como "mamífero artiodáctilo", ese que con palabras menos difíciles de pronunciar, como "especias", "salsa", "asado", etc., es tan sabroso, y que hasta fiesta tiene (aunque no pareciera que este "gocho" la disfrute mucho); no el otro coloquialismo de "cerdo", como persona de "poco cuidado personal".
En la fabulosa, y últimamente tan controvertida, Wikipedia aparece un artículo donde se relata un posible origen del por qué a los andinos venezolanos se les llama "gochos":
Durante la Revolución Restauradora de Cipriano Castro, éste convocó (reclutó, para ser exactos) a algunos de sus "revolucionarios" entre la población campesina del Táchira, a aquellos que se resistían a este reclutamiento se les marcaba cortándoles (seccionándoles) una parte de la oreja, de la misma forma que se hacía con los porcinos (gochos). Los mismos andinos tachirenses comenzaron a llamar gochos a aquellos que habían sido marcados de esta forma y la voz se hizo modismo general entre la población de la región central a medida que los andinos tomaban el poder.
Nada que ver con "cuidado personal".
En francés hay en uso una palabra "gocho", aunque el Dictionnaire de l'Académie française no la tenga registrada. Este "gocho" en francés es usado, de manera despectiva, para referirse a la persona de tendencia política de izquierda, derivada naturalmente de la palabra "gauche", izquierda. Es decir, se refieren a un izquierdista, un socialista, etc., definitivamente no a una persona que "hace las cosas de manera contraria a como regularmente se hace" (por mucho que al Frente Nacional le encantara esa definición). Una búsqueda y lectura rápida en Google nos muestra algunos foros y comentarios en francés donde es fácil ver cuán despectivo es su uso (no hay que hablar mucho francés para entender la expresión "gocho de merde" de uno de los comentarios de este artículo)
Como siempre he dicho, prudencia y Google siempre nos pueden evitar un chapuceo innecesario, y hasta inocente.
No, ni una bufanda, ni un tapetico, ni un mantel: ella quería un Ferrari, así que se tejió uno.
A Lauren Porter, estudiante de la Escuela de Arte y Diseño de la Universidad Bath Spa en Inglaterra, le tomó diez meses y casi 20 km de hilo tejer un Ferrari de tamaño natural, el cual presentó en su graduación.
En la web de Lauren se pueden ver más detalles, un video del emsamblaje del carro para la exposición y algunos de sus otros trabajos.
Si, soy un adicto*. ¿Adicto a qué? Las opciones son muy variadas: TV, Internet, código limpio y elegante, maní japonés, cine, Joaquín Sabina, trotar… la lista sigue, dependiendo de las circunstancias y el momento. Ese no es el problema. La cuestión es que cuando algo me gusta en muy poco tiempo, incluso en cuestión de días, ya me ha llegado a la médula, y se convierte en un "imperativo categórico kantiano"... Si, también soy un poco adicto a la exageración ;-)
Uno de mis días normales incluye al menos 12 horas cosido al computador. A veces, no muy raras las veces, incluso algunas horas más. Siempre hay algo que hacer, que leer, que revisar, que aprender, etc. Así que cuando logro descoserme de la silla y salir al mundo real, suelo disfrutar al máximo cada una de esas otras actividades a las que dedico tiempo (si, normalmente alguna otra adicción).
Entre esas otras adicciones está la regular reunión para jugar UNO. Un lugar tranquilo, un grupo variopinto de amigos que, al igual que yo, deja cualquier cosa que les perturbe fuera de la mesa de juego, y se dedican a sólo pasarla bien, a dejar que un poco de estrategia, mucha de suerte, y el pacto de caballeros de siempre jugar limpio y sin trampas, nos haga la noche, nos haga reír, y a veces, nos haga ganar.
En algún momento de sus inicios, cuando la cosa se empezó a regularizar, alguien empezó a llevar en un cuaderno (y luego en Excel) el registro de los juegos, las estadísticas de la adicción. Hace poco alguien sugirió que sería bueno tener una web para esas estadísticas. A ver, ¿ya mencioné entre mis adicciones a Internet, el código limpio y elegante, y el UNO? ¿Acaso me faltó mencionar que entre las nuevas adquisiciones a mi lista de adicciones está Ruby on Rails? El resultado era inevitable.
UNO: la aplicación web
El diseño de la aplicación es bastante sencillo: tenemos temporadas, jugadores, juegos (cada noche de reunión es un "juego") y partidas (en cada juego hacemos cuatro partidas, que están conformadas por n manos, y que duran hasta que algún jugador alcanza los 500 puntos en la partida; las manos no se registran en la aplicación, sólo el orden final de los jugadores en la partida).
| Posición | Puntos |
| 1 | 10 |
| 2 | 6 |
| 3 | 4 |
| 4 | 3 |
| 5 | 2 |
| 6 | 1 |
| 7 y posteriores | 0 |
A los lugares resultantes de cada partida se les asigna puntos según la tabla de al lado, sistema de puntos basado en las carreras de Fórmula 1 (¿Quién de Uds. ya había adivinado esa adicción en mi lista, adicción también compartida por la mayoría de los recurrentes a esta mesa de UNO?). Esos puntos se suman para generar los resultados generales del juego. Y las posiciones resultantes de cada juego se pasan por esta misma tabla de puntos para generar los resultados generales de la temporada.
La página inicial muestra un resumen de cada temporada: posiciones generales de la temporada (lugares, puntos y promedios, en texto y gráficos) y posiciones resumidas de cada juego uno de los juegos.
Y la página de cada jugador incluye estadísticas del jugador, por temporada: frecuencia de posiciones finales (en texto y gráficos), total de puntos y promedios.
Cada uno de estos elementos es bastante flexible, desde la aplicación misma, que no necesariamente tiene que ser usada solo para registros de UNO, sino que pudieran registrarse juegos en general, o cualquier serie de eventos con registro de lugares o posiciones finales. Las temporadas pueden ser un período de tiempo, o pueden usarse como registro de equipos o ligas, o cualquier otra cosa en que se quieran separar un grupo de juegos. Cada juego puede tener desde una hasta el número de partidas que se quiera, y desde uno hasta el número de jugadores que se quiera. Lo único fijo, por ahora, es el sistema de puntuación para las posiciones resultantes, tanto por juego, como por temporada.
En este momento el acceso está restringido sólo a nosotros, los que jugamos en este grupo de UNO, pero si alguien está interesado en tener acceso a una web de este tipo para su propio grupo, podría escribirme un correo: si hay suficiente interés yo estaría dispuesto a publicar la web para crear grupos nuevos. Incluso, si me mandas una buena historia de obsesos de UNO, te podría mandar el código de la aplicación :-)
* Uso el término "adicción" como una manera de fácil de hacerme entender, sin explicar mucho mis razones detrás de cada una de estas actividades. Yo en realidad las considero "las cosas que me apasionan". En el blog Creating Passionate Users, Kathy Sierra tiene un excelente artículo sobre las cosas que nos apasionan, y las razones detrás de ellas
¿Te gustó este artículo? Digg it!
Estaba buscando algún plugin para Rails para manejar los parámetros (preferencias, opciones, settings, etc.) de una web que estoy haciendo.
En el wiki de Rails encontré este ConfigurationGenerator que parecía muy atractivo, y que se adaptaba exactamente a lo que yo estaba necesitando, pero no pude encontrar el código de él por ningún lado, ni he obtenido respuesta a un post que coloqué en el foro de Rails sobre este generador.
Luego conseguí este otro Settings plugin, que me pareció fantástico, pero no era exactamente lo que yo quería.
Así que decidí emprender la tarea de hacer mi propio modelo para el manejo de los parámetros de mi aplicación web, tomando como base un poco de esos otros pulgins que ya había visto.
Lo que me interesaba era tener una tabla que siempre tendría un sólo registro, y con una columna para cada opción que hubiese en los parámetros. Eso me permitiría guardar cada opción en el tipo de dato y tamaño de columna adecuado. Además me interesaba poder acceder a cualquier parámetro, desde cualquier lugar de la aplicación, con algo simple como:
Parametros.opción
Los parámetros con que arranqué eran el nombre de la aplicación y un texto del tipo "about us", o "quienes somos", para la página principal de la web. La migración quedó asi:
class AgregarParametros < ActiveRecord::Migration
def self.up
# Archivo de parámetros de la aplicación
create_table :parametros do |table|
table.column :aplicacion, :string, :limit => 100
table.column :quienes_somos, :text
table.column :updated_at, :datetime
end
execute "Insert into parametros (aplicacion, quienes_somos) Values ('App. web', 'Somos...')"
end
def self.down
drop_table :parametros
end
end
Este archivo contendrá siempre un registro único, ni más, ni menos, así que se incluye automáticamente durante la migración misma, con valores iniciales cualesquiera. Los valores reales se asignaran en la aplicación web.
Y el modelo de Rails quedó de esta manera:
class Parametros < ActiveRecord::Base
set_table_name "parametros"
validates_presence_of :aplicacion, :quienes_somos
private_class_method :new, :create, :destroy, :destroy_all, :delete, :delete_all
@@p = find(:first)
def self.method_missing(method, *args)
opcion = method.to_s
if opcion.include? '='
# Asignar un valor a la opción
nombre_var = opcion.gsub('=', '')
valor = args.first
@@p[nombre_var] = valor
else
# Retornar el valor de la opción
@@p[opcion]
end
end
def self.save
@@p.save
end
def self.update_attributes(atributos)
@@p.update_attributes(atributos)
end
def self.errors
@@p.errors
end
end
Me interesaba accesar los parámetros con la forma en plural Parametros (en contra de las convenciones de Rails), y la tabla que uso tiene el mismo nombre en plural (esta vez si como lo indican las convenciones de Rails), así que debí incluir set_table_name "parametros" para saltarme la convención del nombre del modelo.
Haría uso de la clase directamente, sin instanciarla, así que debía prevenir que se crearan objetos de la clase con la línea private_class_method :new, :create. A esa lista se agregan :destroy, :destroy_all, :delete, :delete_all porque ciertamente no me interesa que se borre ese registro único de la tabla de parámetros. La lista de métodos se puede alargar a cualquier otro del que se quiera bloquear el acceso.
No quería ir a la base de datos cada vez que necesitara un parámetro, así que usé una variable de clase para hacer un cache de los valores, que sería inicializada la primera vez que se llame a los parámetros, con el contenido de ese registro único de la tabla: @@p = find(:first)
Los métodos save, update_attributes y errors se definen como métodos de clase, con self, para poder llamarlos sin tener necesidad de instanciar la clase.
Se pueden asignar todos los valores a los parámetros, uno por uno, y al final llamar a save para grabarlos en una sola operación en la base de datos. O se puede llamar a update_attributes con un "hash" como parámetro, con todos los valores de los parámetros a grabar (al grabar desde una forma, en una página de parámetros, por ejemplo). El método errors se define para poder utilizar el "helper" error_messages_for 'parametros' en una forma.
Para actualizar los parámetros se puede hacer algo como lo que sigue. En el controlador adecuado:
def parametros
@parametros = Parametros
end
def grabar_param
@parametros = Parametros
if @parametros.update_attributes(params[:parametros])
flash[:notice] = 'Parámetros grabados'
redirect_to :action => "index"
else
render :action => "parametros"
end
end
Y en la vista hacer:
<h1>Parámetros de la web</h1> <br> <%= start_form_tag :action => 'grabar_param' %> <%= error_messages_for 'parametros' %> <p><label for="parametros_aplicacion">Nombre de la web:</label><br/> <%= text_field_tag 'parametros[aplicacion]', @parametros.aplicacion %></p> <p><label for="parametros_quienes_somos">Quienes somos:</label><br/> <%= text_area_tag "parametros[quienes_somos]", @parametros.quienes_somos %></p> <br> <%= submit_tag 'Aceptar' %> <%= end_form_tag %>
Esta es la mejor manera que se me ha ocurrido para manejar los parámetros de la manera que yo quería. Si conocen de una manera mejor, estaré gustoso de escucharla.
¿Te gustó este artículo? Digg it!
