Pisadas

Justificación Cognitiva del TDD?

2009-03-02T12:59:00.000-08:00

Actualmente, me encuentro trabajando en un aplicación legacy desarrollada en C++ con una interfaz en Java. La parte de C++ no está muy felizmente desarrollada por lo que percibo un ambiente muy propicio para la aplicación de Test-Driven Design/Development, por lo que decidí agiornarme en estas aguas con un poco más de investigación.

En mi recorrido, me encontré con un artículo no muy reciente que intenta "justificar cognitivamente" el TDD, a lo cual quiero aportar, humildemente, mi opinión.

justificación : Expresar las razones por las cuales se va a realizar el trabajo, y los beneficios que se espera obtener del mismo. Término judicial que significa absolver, declarar justo, o proporcionar sentencia favorable.

cognitivo : término utilizado por la psicología moderna, concediendo mayor
importancia a los aspectos intelectuales que a los afectivos y
emocionales, en este sentido se tiene un doble significado: primero, se
refiere a una representación conceptual de los objetos. La segunda, es
la comprensión o explicación de los objetos.

En pocas palabras, Steve Freeman, uno de los impulsores de MockObjects y Need-Driven Development, intenta atrapar el desafío intelectual del practicante de TDD al momento de racionalizar la práctica, basándose en la ruptura de los preconceptos y ensayos mentales iniciales. El propio Michael Feathers comenta el post asimilando una pequeña "vuelta de tuerca" sobre TDD.

Kent Beck y Dave Astels dan un impulso al TDD en el 2003, y Astels un año antes con Extremme Programming con base en the Agile Manifesto (2001) como corriente de pensamiento (Beck es singatario del manifiesto ágil).

Si bien los signatarios del mencionado manifiesto proponen ideas muy importantes que están revolucionando la Ingeniería del Software, tengo la percepción de que se están omitiendo algo que Bertrand Meyer sí tuvo en cuenta al teorizar Design by Contract, basándose en postulados teórico-matemáticos anteriores a esta nueva ola de técnicas de diseño de software.

Una de las claves diferenciadoras de TDD es que los tests se preparan antes de desarrollar la mejora o el código nuevo, al contrario de como se venía haciendo en la práctica. Este concepto clave se entiende en las corrientes de TDD como una mejora muy racional a la práctica de diseño y testeo de software en relación de "como se viene haciendo", pero mi sensación es que esto no es tan revolucionario o nuevo como se lo encuentra en la web.

Me refiero a los conceptos de especificación formal, verificación formal , derivación de programa y la lógica de Hoare. Salvando las distancias, podemos analogar la especificación de un requerimiento con una especificacion formal. De la misma manera, es posible relacionar a la verificación formal con la forma de testear software a la "manera usual". ¿Se ve dónde me dirijo? La derivación de programa se puede analogar con el concepto clave de TDD, y la logica de Hoare como base del testeo unitario y DbC. Ya Dijkstra criticaba la verificación formal y propugnaba la eliminación de la sentencia go to en 1968.

Desde este punto de vista, sería mas viable alguna justificación, inclusive cognitiva, colocando las distancias y medidas en su lugar sin tener q pasar por las subjetividades en que los autores podrían incurrir para defender sus valores por sobre otros, pasando por alto conclusiones previas que pueden dar basamento sólido a la teorización técnicas.

Al fin y al cabo, se trata de eso: una batalla no violenta por la imposición de valores, que no es más que lo que una de las definiciones de la palabra política. Podemos hacer política en cualquier campo, incluyendo en la ingeniería del software, por mal que suene, y es un alivio que así sea.

Considero al TDD una herramienta valiosísima en el desarrollo de software, indispensable en el arsenal de cualquier programador que desee al nivel profesional. Todavía me queda mucho por leer, probar y pensar, pero no quiero perder el sentido teórico-crítico a medida que avanzo entre el pragmatismo influenciante de las nuevas corrientes.

Concluyendo, me quedo con la gran frase anónima "para novedad... los clásico".

Mate querido

2008-11-05T05:06:00.001-08:00

No sé si lo sabían, pero existe una guerra silenciosa entre el mate y el café. Desde siempre se ha dicho que la infusión conocida como mate tiene un alcaloide llamado mateína en mayor medida que cafeína. Esto se discute bastante, quizá hasta el fanatismo.

Me encontré con un artículo que intenta explicar que la mateína es un "alias" de la cafeína, por no decir q no existe.

La palabra clave acá es estereoisómero. Se dice que la mateína es un estereoisómero de la cafeína, esto es, una molecula de iguales componentes, pero distintas conexiones entre sí. Algo como un 4-4-2 y un 5-3-2 en fulbo; tienen los mismos jugadores pero formación diferente.

El artículo en cuestión intenta decir que la cafeína carece de estereoisómeros, por lo tanto la mateína o no existe o es otro nombre de la misma.

Para que un químico tenga estereoisómeros debe tener un estereocentro, un centro alrededor del cual rotan las moléculas para formar los isómeros, y la cafeína no lo posee.
Sin embargo, hay muchas afirmaciones que contradicen este estamento, y provienen de latitudes latinas. La mayoría se basa en la prueba de que personas con hipersensibilidad a la cafeína toman mate sin efectos aversos atribuídos a ella.

Al final de cuentas, no se sabe por que estricticismo guiarse. Y uno que pensaba que la química era exacta y seria...

IDE para Ruby On Rails

2008-10-24T06:15:00.000-07:00

Cuando comencé con RoR, hice los mismo que todos: google -> aptana + radrails + InstantRails. InstantRails fue y es un golazo... útil, rápido, integrado y liviano. Estaba acostumbrado a hacer todo a partir de un eclipse, así que aptana no fue más que una descarga, extracción e instalación de plugins para que todo funcione por primera vez.
Mi problema fue que aptana demoró mucho en hincharme las pelotas. Así que decidí hacer una investigación del ide más popular para el desarrollo en RoR.
Los que conozco q usan aptana, lo usan con desazón o ya se han cambiado de editor. Como uso microchot winXP en la maquina, tenia 3 opciones: RadRails, Scite o JEdit.

Me tiré del lado de JEdit desde que ví la comunidad de gente que ya estuvo en el tema intentando adaptar este editor al desarrollo RoR. Está hecho en java, por lo que se siente pesado aunque menos que un eclipse.

Pasos:

1- descargar jedit
2- instalar y configurar los siguientes plugins:
jedit for ruby on rails
highlight para ruby
instalar SuperAbbrevs y colocar un archivo con abreviaciones en .junit/superabbrevs. Luego colocar el shortcut q no se pise con el show completion popup del sidekick (yo lo tengo en crtl + enter).

Hasta acá tenes el entorno, pero para cambiar un poco, se puede instalar el plugin de Editor Scheme Selector, q dispone de varios skins para poner al editor.. queda cheto.

Otra cosa q es útil, es un manejador de tabs, como BufferTabs y un buscador de archivos en el proyecto actual, yo uso el FastOpen porq nunca pude bajar el EBrowse para probar; algún día andará.

Por ahora anda muy bien, integrado con InstantRails.

Closures

2008-10-21T14:46:00.000-07:00

Estos días sentí la necesidad de definir lo que es una "closure". Si bien conozco su uso, no conocía la definición ni las implicaciones de esta técnica.

Martin Fowler dice que una closure es "essentially a block of code that can be passed as an argument to a function call." (no sé q tiene Don Fowler q vuelve a escribir "essentially" cada 2 parrafos).
Como el lo puso:

File.open(filename) {|f| doSomethingWithFile(f)}

Buenísimo. Realmente estamos enviando un bloque de código como parámetro a una función. Esto ya lo había visto en JavaScript, cuando mandábamos como argumento un bloque de código junto con una llamada ajax para que se ejecutara como callback.

A entender de Fowler, hay 2 grandes diferencias entre las closures y técnicas similares.

una closure es "a block of code plus the bindings to the environment they came from." y,

"languages that support closures allow you to define them with very little syntax.", lo que no es poca cosa. Y eso me hace recuerdo a algo...

Pero.. ¿que significa que "the bindings to the enviroment they came from"?
Neal Gaftner tiene un artículo en su blog sobre la historia de las closures. Me encanta la historia, asi que lo ataqué.

Resumiendo: todo empezó con Lisp, sus function-valued expressions (lambda), y su scope dinámico (cuando la ejecución encuentra una variable, recorre el stack en busca de una definición para la misma). Uno de sus dialectos, Scheme, era lexically scoped (una variable se enlaza con la definicion lexicográfica del bloque que la contiene) y supuso un antes y un después en la programación. Las variables enviadas como argumentos al bloque se llamaron free variables; entonces:

"A closure is a function that captures the bindings of free variables in its lexical context."

El "pero" vino con Smalltalk. Se podía encontrar más que free variables dentro de una closure, como "return" o "self". Así que la definición de closure se tuvo que generalizar, y ahí se ofuscó:

"A closure is a function that captures lexically scoped semantic language constructs."

En realidad, sabiendo a que se refiere, la definición se amplía, pero tambien se vuelve más estricta. Veamos: ¿que es una expresión lambda? El concepto sería:

"Se puede considerar al cálculo lambda como el más pequeño lenguaje universal de programación. Consiste en una regla de transformación simple (sustitución de variables) y un esquema simple para definir funciones."

En un sentido general, una closure es un bloque que captura una expresión lambda junto con construcciones semánticas lexicográficamente vinculadas de un lenguaje específico. Se va complicando, ¿no?

Pero tambien entra en juego el lenguaje: en Java y C no se pueden mandar o retornar funciones como objetos, es decir, las funciones no son first-class citizens (objects/functions).

Bueno, entonces una closure es más que una construcción de un bloque independiente y anónimo que lexicográficamente vincula valores a variables, sino que además esos bloques deben poder ser tratados como objetos.

Una closure "encierra" su scope en su definición, es cerrada, realiza una "closure" de su entorno de definición. Pero cuando su scope no cuenta con nada para encerrar, ¿sigue siendo una closure o es simplemente una funcion lambda?

def suma(x)
return {x = x + 1}
end

def suma()
x = 1
return {x = x + 1}
end

def suma(y)
x = 1
return {x = x + y}
end

¿Cual de estos bloques devuelve una closure? Por lo menos sabemos que son expresiones lambda, y una es abierta.

Este bloque de Groovy:

class C {
private int i = 10;

void f() {
def c = {println i}
......
}
}

¿Es {prntln i} una closure o una expresión lambda? Estrictamente, es una expresión lambda. Pero no se convierte en closure sino hasta que es evaluada en run-time, pues es en ese momento que realiza el binding. Creo que acá está la cuestión:

"A door may be open or closed. An open door may be closed by pushing; this achieves closure. A closed door cannot be closed any further; pushing on a closed door has no effect (and thus is not a closure). In both cases, the door remains a door at all times; it does not become a closure. A closure is the combination of a door and pushing."

Entonces:

Si una expresión lambda cerrada (condición necesaria) que es tratada como una first-class object (condición necesaria) es evaluada en run-time (condición necesaria), ésta produce una closure propiamente dicha.

Estrictamente hablando, esa sería la definición de una closure. Seguro que se van a encontrar mas restricciones. Algunos pueden decir que una lambda es una closure por mas que el número de variables que encierre se aproxime a cero.

Por lo menos pude llegar a algo más concreto que cuando empecé la investigación.

Aún así, existen muchas interpretaciones sobre lo que es una closure y lo que no, y viene del convencimiento de cada programador de lo que una closure es según el lenguaje en el que las realiza.

En ruby se puede hacer varios tipos de expresiones que devuelvan closures, como dice Martin Fowler, pero no siempre son estrictamente eso (tampoco en otros lenguajes), sino una "forma" de llamar a esta muy útil técnica de programación.

Zeitgeist

2008-10-20T07:17:00.000-07:00

Me encantan los documentales; tanto o más que las películas. Como no tengo cable, me las tengo q ingeniar para encontrar alguno por la web. Si bien Discovery/History Channel son mis favoritos, descubrí que hay toda una corriente (por no decir industria) de documentales de producción "independiente". Los sitios freedocumentaries.org y freedocumentaries.net son muy recomendables para esto.
Lo valioso del material de estos sitios es el concepto de contra-información.

Pero a donde quería llegar es a que encontré la segunda parte de Zeitgeist, el documental (en mi opinión) que más puede hacer pensar a una persona sobre la realidad.

Zeitgeist es un documental q consta de 3 partes. Ninguna tiene desperdicio.
Zeitgeist Addendum es la segunda parte de este documental. Se estrenó a ppios de este mes en coincidencia con el "desastre" (*) financiero en yankilandia (para el mundo).

Para muchos (como a mí), los tópicos de estos documentales pueden no ser nuevos. Con una cultura general mediana y un poco de curiosidad es posible haber pasado por estos temas anteriormente, pero de manera aislada. Juntarlo todo, y hacerlo parecer una gran y mundial conspiración, es muy "Dan Brown". La realidad viene dada con muchas falacias e ilusiones que no muestran lo importante e indispensable para romper con nuestra "mental slavery": la verdad.

Y el problema es que la verdad no es un secreto. La historia no es una ciencia exacta, sino un ejercicio de interpretación. Y la realidad también lo es.

Lastimosamente, la educación que tenemos, el sistema en q vivimos, nuestra "realidad", está alimentada y virtualizada por nosotros mismos. Hay quienes dicen q en la ignorancia no hay culpa, pero no estoy de acuerdo. La ignorancia es también desinformación.

Platón ya se preocupaba por eso en su tiempo, y hubo muchos más que interpretaron la realidad. Algunos pocos, atinaron a advertirnos como pudieron. Una de esas "advertencias", mi preferida, es de Mariano Moreno, quien ya en 1810, en el prólogo para su traducción del "Contrato Social" de Rosseau, nos advertía:

(...) si los pueblos no se ilustran, si no se vulgarizan sus derechos, si cada hombre no conoce lo que vale, lo que puede y lo que se le debe, nuevas ilusiones sucederán a las antiguas, y después de vacilar algún tiempo entre mil incertidumbres, será tal vez nuestra suerte mudar de tiranos, sin destruir la tiranía.

Entonces, ilustrémonos sin prisa y sin pausa.

Vuelvo a citar al groso de Goethe:
"None are more hopelessly enslaved than those who falsely believe they are free.

(*) desastre: es el miedo q tenian los antiguos a q los astros (fuente de toda su cultura) se desplomaran sobre sus cabezas

Scrum notes

2008-10-16T12:44:00.000-07:00

En mi trabajo, estoy propuesto como integrante de un equipo de personas que involucraría liderazgo. No se sabe mas que eso (?). Con la experiencia que tengo en el tema de liderazgo, seguro que no me van a dar el traje rojo de los Power Rangers, pero siempre tuve como premisa que se hace camino al andar. Es por eso que en un intento (des) esperado quisiera atomizarme de sapiencias mas menesterosas en el ámbito del liderazgo en la industria del sofware.

Ok, voy al punto: ví un video de Scrum, disertado por el mismo Ken Shwaber en Google Inc.
La verdad, muy interesante. Alguna vez estuve en un sprint de Scrum en el trabajo par aun proyecto interno como una especie de Team/Technical Leader... no mucho más para contar.

De esta disertación pude extraer algunas cosas interesantes sobre Scrum:

"Everything is a timebox and it's done with cross-functional teams that are responsible for managing themselves". Clarísimo.
"Scrum is a manager process for managing product development". ¿Es Scrum una metodología, en el sentido estricto de la palabra? No. Es un método. Y lo mencionan en el video. Si fuera una metodología, casi cualquier problema estaría resuelto (qué y como) en una documentación.
Scrum tiene un goal, un target al cabo de una iteración. Ese target o goal es un producto HECHO, Q ANDA. Si al final de esa iteración se testeó, se documentó, se validaron los estándares a utilizar, pero el producto target no está HECHO, Scrum FALLÓ.
Definición de HECHO (done): "coded to standards, it's been reviewed, it's been documented, it has unit test built to it, and it's been checked in and successfuly built"
Scrum se basa en la transparencia de comunicación. "No se admiten powerpoints que dicen como luciría si estuviera terminado". Se trata de saber realmente DONDE ESTAMOS.
Esa transparencia es ambivalente: transparencia con el cliente y con los team members. El cliente debe saber en que estado está el desarrollo en cualquier momento, y los team members "pueden reunirse diariamente y comentar q hicieron, q no, y q tienen planeado hacer".
En Scrum hay una persona q coordina el sprint, y al final de cada uno mide la diferencia entre "donde estamos" y donde "queremos estar". Si algo falla, esta es la persona a la que se le piden explicaciones. De las muchas implementaciones de Scrum en empresas solamente el 30 o 35% resultaron exitosas debido a la imposibilidad de los proyectos a aceptar cosas que no quieren (malas noticias). Toda (mala o buena) noticia debe ser informada para decidir inteligentemente.
A cerca de las chances incrementar la velocidad de desarrollo cuando no se llega a tiempo: hay varias técnicas
- podemos dejar de lado la calidad, dejar de documentar o seguir estándares, dejar de hacer refactor y corregir el diseño, y pensar que alguien volverá después (con tiempo) a hacer lo que dejamos de hacer.
- podemos no construir unit tests, conformarnos con tests de aceptación.
- podemos trabajar mas horas (y generar un 60% mas de bugs en el código).
La importancia de la Infrastructure or core code: Cada nueva funcionalidad demora 20 veces más porq el infrastructure code tiene 3 caracteristicas:
- fragilidad: cualquier cambio en ese core, tiende a romper otras cosas.
- testability: el core no tiene "test harnesses", o "automated test harnesses". Si se rompe algo no nos damos cuenta hasta q está puesto funcionando y el cliente te avisa q no anda.
- (buscar palabra): hay pocos q saben y tienen ganas de trabajar en ese código, porq el resto se fue a desarrollo. Por eso el infrastructure code tiene menos velocidad de avance. Menor velocidad del core, menos funcionalidades se pueden colgar de él.

En fin, me está empezando a gustar Scrum como metodologia ágil y calculo que se vendrán otros post sobre adoption y management.

In boca veritas.

La alternativa dentro del estilo

2008-09-05T16:00:00.000-07:00

Si tuviera q nombrar un libro q nunca pude terminar, ese sería "A sangre fría" de Truman Capote. Me lo regaló mi vieja cuando tenía 23 años y lo empezé como 5 veces, pero no pude pasar las 250 páginas en ninguna de las oportunidades. Con verguenza, lo dejé encapsulado en la cajita de los "por leer", nunca me había pasado. Al final de cuentas, el chabón revolucionó la literatura al crear un nuevo estilo literario, la non-fiction-novel, que les rompió la cabeza a todos en su momento (1966). ¿Cómo puede ser q no lo pueda leer? Se lo comenté a un amigo, inmensamente más leído q yo, y me recomendó "dejá ese libro insulso... comprate 'Operacion Masacre' de Rodolfo Walsh y vas a ver quien inventó ese estilo."

Curiosamente para mí, "Operación Masacre" fue publicada en julio de 1957, y es una non-fiction-novel. Es más, la segunda edición del libro salió en 1964, ¡2 años antes de que Truman hubiera publicado por primera vez "A sangre fría"!

La lección: no mires sólo para afuera. Acá tenemos de todo...

El libro en sí facinante, fácil de leer y en castellano "argentino". El argumento (los fusilamientos de leon zarez) es desgarrador, indignante y crudo. Ya en las primeras páginas se advierte al autor y su bronca e indignacion. A diferencia de Truman, Walsh se metió a investigar cosas que no tenia que investigar en un país como el nuestro (si sos argentino ya sabrás de que hablo).

Es un libro q recomiendo, y no por su belleza justamente. Es, ppalmente, un documento histórico, con fechas nombres, datos de juicios, investigaciones, testimonios, etc, que se molestó en recopilar SIN MIEDO. El género literario es innovador, y eso uno no puede perdérselo.

IE querido

2008-02-26T05:14:00.000-08:00

En el proyecto en el que vengo trabajando desde hace y un poco más de un año, tuvimos un problemita con una llamada ajax que no debía traer más inconvenientes.

La tarea era reemplazar un "div" con una tabla con updates para un producto que se seleccionaba en un combo. En FireFox anduvo perfecto desde el ppio, pero asumimos que también andaría en Internet Explorer, ya que no introdujimos codigo js nuevo sino que reutilizamos nuestra api de actualización de elementos del dom -una simple callback-.

El problema surgió al testear; en IE no estaba funcionando la actualización. Luego de googlear un poco descubrimos que se trataba de un bug, que es en resumen "IE treats name and id attributes as interchangeable". Esto es, si ponés el id de un elemento igual al name de otro elemento, mandále un mail al tío Bill preguntándole que elemento va a devolver getElementById() cuando le pidas el elemento.

Ah, y no importa si usás el $() de Prototype o el YAHOO.util.Dom.get() de YUI, no va a funcionar. En el caso de YUI de YAHOO, en la version 2.2.2 -usamos ésta-, se comieron el bug: no tienen una simple documentación del caso en el fuente del método que publican en los helps online, y terminan usando getElementById. No me fijé en Dojo, pero calculo que pasa lo mismo.

Ojo, no estoy relajando a las librerías js más copadas del terreno, ya que, honestamente, la spec no dice que hay q soportar bugs de IE. El ánimo proviene de un problema de la falta de acatamiento de estándares en un browser de mierda, entonces confiamos -o queremos confiar- en estas librerías que se han preocupado -y mucho- por dar soluciones cross-browser que al fin de cuentas descuidan un bug tan estúpido y grosero.

En definitiva, el método devolvía otro elemento, así que la actualización del DOM se hacía en cualquier lado.

¿Cuáles eran nuestras opciones?

tomar la sugerencia de sniffear el browser y sobreescribir el metodo getElementById para cuando no se use gecko,
redefinir los parámetros para hacer un getElementsByTagName + for + if y así encontrar el elemento, o
revisar y cambiar los names y ids de los elementos que sean necesarios

La primera opción es, en mi opinión, entretenida para un desarrollador; un hack de js, sobreescribir una función usada mil veces antes -y que se va a seguir usando- por culpa de un bug de IE -otro más-. Ok, sobreescribamos la función, recorremos todo el dom en búsqueda del elemento y lo devolvemos al encontralo, o la volvemos a sobreescribir si se trata de un gecko.

Suena lindo, funciona muy bien cuando la cantidad de elementos de un DOM dado es pequeño... lamentablemente no es nuestro caso, y la performance de js es importante.

Creo que no hace falta agregar mucho comentario para la segunda opción -es lo mismo que la primera-.

La tercera opción es laboriosa por donde se mire: debería llevar a reveer todos los elementos que reciben y/o potencialmente puedan recibir referenciamiento y "serializarlos" para de alguna manera mejorar la estructura del DOM que se tira en el browser y empezar a dejar de preocuparse por inconsistencias js en distintos browsers.

¿Cual parece ser la mejor decisión, en términos de estructura, comportamiento y performance?
En nuestro caso, reestructurar el DOM fue la decisión que seguimos. A mí, la idea de hacer el hack me agradó al ppio, pero es verdad de que si se ordena un poco mejor la estructura del html que generamos en la vista, este tipo de problemas se evitan.

El tip acá es el siguiente: estructurá bien tu html.

Una diferente mirada al networking

2007-10-24T08:22:00.001-07:00

Dando vueltas por del.icio.us links, intentando ver que tipo de solucion de request-headers le convenia a la aplicación en la que trabajo, me encontré con este videito bastante interesante. Contiene una retrospectiva crítica hacia los orígenes de las telecomunicaciones y el networking. El disertante va más allá de la mera historia, para dar su opinión sobre las debilidades y fortalezas de TCP/IP, proponiendo la búsqueda de upgrades al protocolo en lugar de reemplazos.
El videito dura 1 hora 20'.... así que pónganse cómodos!

El video: link...

No seas necio/a

2007-10-19T09:09:00.000-07:00

Si hay algo q considero poco sensato es querer (sí, querer) cometer errores. La trillada frase "dejame equivocarme, quiero cometer mis propios errores" es por un lado estúpida y por otro inspirante. No tengo nada en contra del libre albedrío, pero si tengo contra la necedad. ¿Quién es tan estúpido como para anhelar fallar para aprender? Muy a menudo escucho personas que lucen ávidas en realizar alguna actividad nueva en sus vidas, pero tienen la pereza de reflexionar a cerca de los consejos, avisos, advertencias, etc, de los que disponen de manera GRATIS, esto es, sin pagar el precio de las lecciones aprendidas a los palos, con frustraciones y todo el circo.

El lema deberia ser: "si meto la pata, quiero meterla de manera original... no quiero hacer las mismas cagadas que hicieron otros". ¿No suena mejor?

Las personas realmente interesadas en aprender, primero aprenden de sus errores y de los errores de los demas, las incorporan a su conocimiento y las aplican en cada intento de hacer algo nuevo. De esta manera, se puede evitar andar pegándose la cabeza contra paredes que ya tienen pintadas flechas que indican hacia donde dirigirse cuando se llega a ellas...

"El vino puro hace al hombre un necio, el diluído lo hace alegre..." Goethe.

Prueba

2007-10-19T08:57:00.000-07:00

Este es el primer post serio de mi vida. Este blog quiero destinarlo a comentar mis pasos a traves de todas cosas q me me llamaron la atencion, sea trabajo u ocio, lo compartiré con el objeto de poder inspirar hambre por lo nuevo y lo novedoso...