2 consejos para usar Ruby/Amazon

Ruby/Amazon es una “biblioteca desarrollada en Ruby que provee acceso programático a las versiones REST de los Web Services de Amazon”. Básicamente la única dependencia de Ruby/Amazon es el procesador REXML, que es parte de la instalación de Ruby desde la versión 1.8.x, por lo que es bastante fácil comenzar a utilizarla minutos después de instalarla.

Comencé a trabajar con esta biblioteca durante el fin de semana debido al proyecto del que hablamos antes. Nuestro proyecto involucra proporcionar servicios de compra a través de Amazon, (evidentemente ) agregando cierta personalización a las búsquedas.

En el proceso de comenzar a utilizar la bilioteca, noté algunas puntos importantes, por lo que tengo 2 consejos para quienes quieran utilizar Ruby/Amazon:

1. Explora la documentación: En la página inicial de la documentación de Ruby/Amazon hay dos ejemplos sencillos que pueden utilizarse como introducción para entender el funcionamiento de la biblioteca. Si estás acostumbrado a la interfaz directa (REST o SOAP) de los Web Services, es recomendable que le des una revisada a toda la documentación porque el comportamiento de la biblioteca no coincide exactamente con el de los Web Services.

Por ejemplo, Amazon tiene un catálogo de búsquedas llamado “Blended”. Este catálogo sirve para realizar búsquedas sobre un conjunto de catálogos predefinidos, para cuando no sabes exactamente cuál deberías usar. Existe un parámetro en las búsquedas en donde se indica que el catálogo es “blended”. Sin embargo, en Ruby/Amazon, las búsquedas blended están implementadas en clases diferentes a las búsquedas que utilizan el resto de catálogos.

2. Actualiza el listado de catálogos: Los catálogos de Amazon están predefinidos y han sido modificados con las actualizaciones de la API de Amazon. La versión de Ruby/Amazon que está disponible actualmente en su sitio contiene un listado de catálogos desactualizada, por lo que deberás actualizarla y mantenerte al tanto de las actualizaciones de Amazon.

Para actualizar este listado, debes modificar el código de Ruby/Amazon, específicamente el archivo search.rb que se encuentra, en teoría en \lib\amazon\ dentro del directorio de instalación de Ruby, pero en mi instalación de ruby (en Windows) se ecuentra en \lib\ruby\site_ruby\1.8\amazon\

Puedes encontrar la información más actualizada de los catálogos en la documentación técnica de Amazon Web Services. La versión más actualizada en este momento es: Amazon E-Commerce Service API Version 2007-10-29. Los diferentes catálogos los puedes obtener de esta sección.

Actualmente no existe una forma automatizada de obtener de Amazon las actualizaciones a su listado de catálogos, pero es recomendable que esta información pueda ser actualizada de otra forma que no sea modificar el código fuente de la biblioteca. Quizás obtenerlo de otra fuente de datos administrable como una base de datos u otro Web Service, por ejemplo.

Adicionalmente, recomiendo mucho el sitio AWS Zone, que permite realizar pruebas reales de las interfaces de Amazon Web Services de forma bastante sencilla y amigable.

Espero que estos consejos te ayuden de alguna forma a echar andar facilmente tu desarrollo con Ruby/Amazon.

Traducción de proyecto sobre ruedas

Una de las intenciones de este blog es que sea fácil de entender para cualquier persona que no necesariamente está familiarizada con la terminología técnica indispensable para comprender posts relacionados directamente con implementaciones de tecnología, sino que esté expresado de tal forma que cualquier persona entienda la esencia del artículo aunque no sea un experto en, nada. Como yo. Así que permítanme hacer una breve traducción del artículo de frntk.

Por varios meses hemos tenido en diseño un proyecto que en concepto resultaba ser muy atractivo y aparentemente sencillo de desarrollar. El concepto era simple: unificar búsquedas en sitios predeterminados basándonos en palabras claves para usos comerciales, o sea, obtener un buscador genérico en el que el usuario delimita los sitios en los que se hará la búsqueda.

Sin embargo, hemos detectado varios retos para poder llevar a cabo el proyecto y llegar a una versión beta (versión de pruebas). Para facilitarnos un poco las cosas, tomamos alguna decisiones que encaminan un poco el proyecto. La primera decisión que tomamos sobre el proyecto fue limitar la cantidad de recursos económicos a invertir en él. Por lo tanto, empezamos a utilizar una herramienta open source. La segunda decisión fue sobre el tiempo que íbamos a invertir para desarrollar el proyecto – los domingos en la tarde. Finalmente, acordamos en llevar un diario sobre el desarrollo del proyecto y es así como este artículo nace.

Así que, damas y caballeros, geeks y nerds… ok, mayormente geeks, estaremos publicando con relativa frecuencia los avances de nuestro proyecto, con la intención de ofrecer una versión de pruebas al público lo más pronto posible. En otras palabras, para ponerle presión pública a la mitad de nuestro equipo de desarrollo. El día domingo 28 de octubre estaremos haciéndolos partícipes de nuestra odisea para la primera versión de pruebas.

Son más que bienvenidos sus comentarios, sugerencias y críticas (preferiblemente constructivas).

Our New Project On Rails

Pensé en nombrar este post en español, pero decir que tenemos un “nuevo proyecto en rieles” no sonaba bien.

Y es que después de algunos bastantes meses, hemos comenzado a trabajar en un proyecto que teníamos en el pizarrón. Hasta hace unas semanas, el pizarrón estaba completamente lleno de polvo, arañas y otros bichos que nunca identificamos y perdimos de vista la idea. Tuvimos que utilizar un rastrillo y un arma especial para limpiarlo.

Luego compramos otro pizarrón.

Lo importante, es que por ahora, estoy en la fase de “entrenamiento” para la tecnología que decidimos usar: Ruby On Rails. Honestamente, quedé impresionado cuando vi el screencast donde David Heinemeier Hansson crea un blog en 15 minutos.

Debido a la forma en que Ruby On Rails funciona, algunos expertos dicen que se trata de una herramienta que únicamente sirve para realizar prototipos o aplicaciones que no demandan mucha eficiencia. No estoy muy seguro de esto, pues hay otros expertos que dicen lo contrario. En tal caso, creo que lo mejor es probarlo por mi propia cuenta y determinar por mí mismo de qué es capaz. El alcance de nuestro proyecto me lo permite, por ahora.

Estoy seguro de que será algo interesante e ire comentando aquí los avances que tengamos. Estoy emocionado con poder darles más detalles sobre de qué se trata todo esto. Espero que sea pronto.

Hasta luego.

El trabajo correcto.

Relacionado con el último post. ¿Estoy en el trabajo correcto?

http://www.insiderjobsecrets.com/career-choices.htm

Animación. Requiere flash. Con sonido. Inicia sin preguntar…

Quiero trabajar, ¡quítese de mi camino!

Hace unos días en el segundo post de la serie de Atención a Clientes, Martha Molina nos dejó un comentario interesante.

Su comentario me hizo recordar un post algo antiguo en Creating Passionate Users. Aquí, Kathy Sierra propone una idea interesante:

“The company should behave just like a good user interface — support people in doing what they’re trying to do, and stay the hell out of their way.”

O sea,

“Una empresa debería comportarse como una buena interfaz de usuario – ayudar a las personas a hacer lo que intentan hacer y quitarse del camino.”

…más o menos.

Poniéndolo en otras palabras la analogía va algo así:

Un empleado que tiene que atender un cliente y para hacerlo bien necesita:

recordar procedimientos, llenar formularios, sacar fotocopias, conseguir autorizaciones, volver a llenar formularios, volver a sacar fotocopias, consultar datos en “el sistema”, llenar formularios, sacar fotocopias… ¡Es infernal!

Se siente como un usuario que utiliza un programa que da mensajes como:

“Ha seleccionado abrir el documento, continuar?”, “Ha decidido imprimir el documento, continuar?”, “Los datos que introdujo en el formulario (si, los 15 campos del formulario) son incorrectos.”

O como programas con controles extraños que no sabemos como funcionan.

Pero me estoy desviando del tema… el post de Kathy Sierra va más allá de comparar interfaces de usuario con empresas. La afirmación principal que hace es que no podemos pedir que los usuarios se sientan apasionados por la empresa o por su trabajo. Deben sentirse apasionados por lo que hacen. La empresa debe ser sólo un vehículo. Si cada vez que un empleado hace algo en su trabajo debe preocuparse por las consecuencias que eso pueda tener debido a las normas corporativas, la empresa es un obstáculo. Y es paradójico que la empresa quiera ser productiva mientras se dedica a ponerle obstáculos a sus empleados, que los hacen sentirse frustrados al final del día y transmiten, de una forma u otra, esa frustración a los clientes.

Pero no podemos culpar sólo a la empresa. ¿Qué pasa con la actitud del personal? Y esto justamente coincide con lo que menciona Martha.

¿Cuántos de nosotros sentimos pasión por lo que hacemos? Cuando nos quedamos hasta tarde en el trabajo, ¿por qué lo hacemos? ¿porque nos gusta? o ¿siempre después de las salidas tarde nos quejamos y maldecimos al jefe? No trato de justificar las salidas tarde. En lo personal me confieso culpable. Muchas veces salí de mi trabajo maldiciendo a mi jefe por haber pedido el reporte a las 4:57 pm.

Pero en nuestro medio la típica actitud será: “pero ni modo, necesito el trabajo.” Desde cierto punto de vista, esta bien. Pero quizás estamos en el trabajo equivocado…

Hay muchos factores culturales involucrados acá. En nuestro país el trabajo es escaso, las oportunidades son pocas. Las empresas no son paraísos laborales como en otros lugares. Todo es más difícil. Tenemos que conformarnos. ¿verdad?

No. Creo que es difícil, pero no en el modo en el que normalmente lo vemos.

Hay dos formas de atacar este problema:

• Cambiar de trabajo.
• Cambiar de actitud.

Bueno, en realidad hay tres formas:

• No hacer nada y aguantarse.

Pero esa última es la peor de todas, así que no hablaré de ella.

En cualquiera de los dos casos es una decisión que involucra cambio y el cambio generalmente crea resistencia. Qué decisión tomar dependerá de muchas aspectos personales. Por ejemplo, alguien que está trabajando en un área que realmente le gusta, probablemente preferirá evaluar su actitud y la forma en que hace las cosas. Pero alguien que definitivamente no está haciendo lo que le gusta, deberá evaluar sus objetivos en la vida. Algo más profundo (y dificil) pero que definitivamente vale la pena.

El ideal es poder decir (y decirlo en serio): “Nunca me cansaré de hacer lo que hago”, como lo dijo Martha.

Así que, para que una empresa pueda tener empleados apasionados tiene que facilitarle las cosas a sus empleados y quitarse del camino. Pero los empleados tienen que querer estar en ese trabajo en primer lugar.

–

Nota: Este blog ha estado un poco desolado en las últimas semanas. Trataremos de mejorar eso.