Hace unos días un amigo me preguntó acerca de cómo decidir cuanto cobrar por su trabajo de diseño web. En la plática salieron algunos puntos interesantes que pensé sería bueno compartir en este artículo.

Una vez estaba en una clase de “Pricing Strategies” y estábamos discutiendo acerca de como definir el precio de un producto. Hay muchas formulas y conceptos de economía acerca costos fijos, variables, análisis de la competencia, etc. para definir el precio de productos manufacturados.

Pero cuando hablamos del precio de un servicio profesional, no todos estos conceptos aplican y entramos al mundo del dicho “según el sapo es la pedrada” … donde el sapo puede ser el cliente, el consultor o ambos.

Para dar contexto al tema usaremos siempre el ejemplo de un consultor que ofrece servicios de diseño web.

Primero debemos analizar algunos detalles que se esconden tras ese numerito llamado precio…

Qué es el precio?

• El precio es la semilla de lo que después se convierte en nuestros ingresos totales. De este monto debe salir el dinero para pagar los costos fijos, variables, inversión en equipo, impuestos y compensar al dueño del negocio por el riesgo y costo de oportunidad. Desde este enfoque podemos deducir un precio en base a COSTO.

• El precio también puede ser un mecanismo de branding que sugiera la calidad del servicio que ofrecemos. Un precio muy bajo puede dar a entender que nuestro producto o servicio es de mala calidad y un precio alto por otro lado denota mayor calidad. En el caso de servicios profesionales de consultoría, la calidad corresponde a “que tan experto o especialista” es el consultor y de acuerdo a esto se espera que será el nivel de calidad del trabajo realizado. 
De este enfoque podemos deducir un precio en base a VALOR AGREGADO.

• El precio también es un mecanismo de equilibrio de mercado. Si tenemos precios muy bajos y nuestra capacidad de producción es baja, es posible que no podamos abastecer toda la demanda. A medida que subimos el precio, vamos filtrando la demanda y quedando solo con los clientes que está dispuestos a pagar más… llegando a un equilibrio y encontramos el segmento en que vamos a competir. De este enfoque podemos deducir un precio en base a COMPETENCIA DE MERCADO.

Entonces … cuanto? cuanto vale?

Cómo podemos responder a la pregunta que nos hace un cliente potencial cuando quiere que le desarrollemos un sitio web?

… Depende

Depende en parte del mercado. Vivimos en un mundo competitivo donde hay muchas personas ofreciendo “su sitio web por sólo $100” … pero la competencia a nivel de precios bajos no es sana, lleva a malos resultados y baja calidad.

Que tiene de malo contratar la oferta hipotética del sitio web por sólo $100?

A la larga no se puede retener la atención de un diseñador/consultor por mucho tiempo a ese monto… lo que puede terminar pasando después es:

• Llega el punto en que este consultor necesita más ingresos y busca más clientes… y en consecuencia ya no te contesta las llamadas ni responde tus emails (se te pierde) porque está ocupado atendiendo a otros.

• El consultor ya no puede con sus gastos y consigue un trabajo fijo con un sueldo mensual entre 10 a 15 veces lo que te estaba cobrando y en que no tiene que preocuparse por andar buscando clientes… siempre le pagan su sueldo mes a mes.

• El consultor se aburre de hacer sitio web y ya no se dedica a eso… y busca otro negocio (vende casas o carros por comisión).

Al final, el cliente termina con un sitio web a medias, sin mantenimiento y en busca de alguien que tome el proyecto desde cero nuevamente (y a veces con el nombre de dominio secuestrado por el consultor anterior).

Entonces, no es bueno competir con esos precios bajos, ya que quienes operan en ese mercado terminan mal. Como consultores serios hay que pensar en el largo plazo, pensar en desarrollar una carrera estable y prospera dedicada a ofrecer tus servicios a clientes que puedan contar con tu disponibilidad por varios años.

La pregunta no es cuanto vale un sitio web… es cuanto vale tu tiempo

Una vez hicimos un estudio de mercado, comparando precios y servicios ofrecidos por 7 empresas de diseño web en Honduras. A todas enviamos la misma requisición y las ofertas que nos enviaron iban desde los $350 hasta los $2,600 … todas básicamente en respuesta a la misma solicitud.

Al final de cuentas, no importa si estás diseñando sitios web, casas, puentes, compuestos químicos o haciendo estudios de impacto ambiental… cuando trabajas como consultor, lo que vendes es tu tiempo y atención para dedicarla a solucionar un problema que no es tuyo… es de tu cliente, pero por medio de una transacción comercial se vuelve tuyo.

Al ver la pregunta de ‘cuanto cobrar’ bajo este enfoque y tomando en cuenta los enfoques de 1) costos, 2) valor agregado y 3) competencia de mercado, entonces podemos hacer un análisis para determinar nuestro precio.

Un análisis en base a costos puede ser:

• Si tu única fuente de ingresos por muchos años será la que venga de cobrar por tu tiempo, considerando que el día solo tiene 24 horas y no se pueden agregar más… hay que determinar cuantas horas productivas al día podes dedicar a clientes y hacer números en base a eso. Para el ejemplo usemos 5 horas diarias en trabajos de clientes, 5 días a la semana.

• Al dedicarte a ser consultor estás tomando un riesgo… estás dejando ir la oportunidad de un empleo bien pagado (asumiendo que lo podes obtener) y eso representa al menos una referencia para tu costo de oportunidad

• Si tomas tu costo de oportunidad mensual en base a un salario (por ejemplo $1,500) y lo dividís entre las horas efectivas al mes que podes dedicar a clientes (por ejemplo 100) entonces tu costo por hora es $15.00

• Pero que pasa con los ahorros, vacaciones, aumentos en tus ingresos, retiro, seguro médico, etc.? Y a quien le cobro todas las horas que involucra conseguir un cliente, escribir propuestas, reuniones pre-venta, etc.? Al decidir ser consultor independiente vos sos el dueño de tu carrera y lo que pase con ella… debes hacer un plan financiero que considera todo esto. Probablemente el monto de $15 por hora deba en realidad incrementarse en un 50%, para un valor total de $22.50

Entonces, si un sitio web te tomaría unas 50 horas de trabajo, tu cotización sería $22.50 x 50 horas = “Sitio Web $1,125.00”

Valor Agregado

Pero lo anterior sólo toma en cuenta el extremo inferior de la ecuación… el costo. ¿Qué pasa con el ‘valor agregado’ que el consultor aporta al ser un experto en el tema?

A medida que un consultor obtiene más experiencia y se especializa, su trabajo es más valioso, agrega más valor a los proyectos en que trabaja, es más eficiente (le toma menos horas completar un trabajo) y otros beneficios.

Además, llega a conocer mejor el mercado y descubre que hay ciertos segmentos de mercado en que los clientes tienen un nivel de presupuesto más alto para proyectos de web debido a que para ellos significa más ventas, mejor posicionamiento de marca o algo que realmente genera valor. Si este consultor llega a un cliente grande y descubre que el valor agregado que sus servicios representan para el cliente es de $8,000.00 (entregando un sitio web en 6 semanas) entonces automáticamente el nivel de precio del consultor sube y se ajusta a esto.

Cuando vengan nuevos clientes potenciales, el costo de oportunidad de este consultor ahora se basa en $8,000 por un website que le tome 6 semanas completar… entonces ahora basa su precio en $8,000 / 6 semanas / 5 días / 5 horas = $53.33

Ahora por ese website de 50 horas de trabajo, el consultor cotizaría 50 x $53.33 = $2,666.00

Según el Sapo es la Pedrada…

Normalmente este dicho significa que se le puede cobrar más a clientes grandes… pero creo que en realidad lo que se hace es cobrarle el precio justo a los clientes grandes y darles un descuento a los pequeños (que sabes que no pueden pagar lo que vale el trabajo)… eso sólo si es que realmente queres ayudarles.

Cada caso es diferente en cuanto a precios de consultores y en cuanto a valor que el cliente asigna al sitio web (su presupuesto). Cada consultor tiene sus planes y metas financieras diferentes que lo llevan a valorar de forma diferente su trabajo.

Algunos trabajan como parte de un equipo y entran otros factores en juego. Por eso hay firmas de desarrollo web como Hashrocket que cobran entre $150 y $250 por hora. En el sitio de preguntas y respuestas StackOverflow surgió una discusión interesante en que los rangos anduvieron entre $25, $75 y hasta $200 por hora para desarrollo en Ruby on Rails.

En conclusión

En respuesta a mi amigo desarrollador de web, lastimosamente no hay una respuesta correcta … cada quien decide como quiere cobrar y luego se mide en el mercado para encontrar a los clientes que ven valor en lo que ofreces.

A medida que obtenés más experiencia trabajando con clientes debes ir identificando cual es tu área especialidad, el área específica en que más agregas valor. Al identificar esto, verás que hay segmentos de mercado que valoran bastante tu aporte de experto y no tienen inconveniente pagando lo que tu trabajo vale.

Algunos puntos finales:

• Consejo: Difícilmente un cliente te pague por hora… debes hacer tu análisis de horas internamente y cotizar ‘por proyecto’ con buena definición del alcance del mismo (que incluye y que no).

• Aclaración: No soy experto en precios… siempre es un trabajo complicado decidir como cobrar y este artículo sólo es un análisis con valores hipotéticos. Hay muchas otras formas de abordar el tema.

• Opinen: Sus opiniones son bienvenidas para compartir experiencias en el proceso de definir precios en sus mercados locales.

Desde finales de marzo comencé a implementar ciertas tácticas enfocadas a evitar distracciones y ser más productivo en las actividades más importantes y quería completar el experimento para escribir algo al respecto en el blog. En este artículo quiero compartir algunas de estas tácticas y lo que he aprendido en el proceso.

La decisión de cambiar

Recuerdo los tiempos en que podía trabajar 3 horas corridas sin interrupciones en un proyecto… esos tiempos han terminado para siempre. Ahora con emails, twitts, notificaciones de facebook, messengers (gtalk, skype, etc…), llamadas al celular, mensajes de texto (sms), wifi en todos lados es casi imposible tener 30 minutos corridos sin una interrupción (sin contar cuando alguien entra abruptamente a tu oficina y te roba una hora sin sentido).

Normalmente ‘trabajo’ (estoy frente a mi computadora) de 9AM a 9PM con un break de almuerzo de dos horas. De acuerdo a ese horario, bebería completar 10 horas de trabajo productivo cada día. Pero debido a todas las interrupciones y tratar de multi-task entre varios proyectos a la vez, al finalizar el día sentía que no había avanzado significativamente en las tareas importantes.

Decidí comenzar a cronometrar mis actividades para determinar cuanto tiempo realmente productivo trabajaba cada día. Los resultados fueron decepcionantes… en promedio estaba completando solamente 2 horas de trabajo realmente productivo cada día.

¿Qué pasaba con las otras 8 horas?
Se perdían en actividades sin importancia que se iniciaban gracias a una interrupción… cada una tomando entre 40 y 90 minutos.

El plan

Después de medir el tiempo desperdiciado, decidí formular y seguir un plan de trabajo más ordenado.

El objetivo era reemplazar el comportamiento compulsivo de estar revisando email y sitios sociales todo el tiempo por revisar compulsivamente herramientas de productividad que me ayuden a mantenerme enfocado en las tareas que necesito completar.

Las bases del plan eran sencillas:

• Crear un horario en mi Google Calendar para definir bloques de tiempo a seguir todos los días, semana a semana. La idea de los bloques de tiempo de 3 a 4 horas es que durante ese tiempo te dediques exclusivamente a ese tipo de tareas. A veces no hay nada que hacer en uno de los bloques y se puede reemplazar el bloque de un día por el de otro (lo del lunes pasa al miércoles y viceversa).
  .
• Definir una hora para leer correos en la mañana, luego un seguimiento a medio día y otro en la tarde. La idea es solo leer y responder correo tres veces al día.
  .
• Reservar el lunes para “Apagar Incendios”, es decir, situaciones de urgencia impredecibles de algún cliente, empleado o socio que inevitablemente caerán en tu inbox al inicio de la semana.
  .
• Reservar un día a la semana para actividades personales y ‘Learning Day’ en que me dedico a leer, ver videos de charlas, entrevistas, etc.
  Experimenté con los jueves y los viernes… el mejor día resultó ser viernes. Si hay algún blog post, artículo, video, podcast o cualquier otro contenido interesante que me mandan o encuentro por allí, lo salvo a evernote y el viernes los reviso durante mi ‘learning day’.
  .
• Utilizar el feature de ‘multiple-desktops’ del sistema operativo (en mi caso MacOSX, pero ahora Windows y desde hace tiempos Linux tienen esta función). De esta forma dividiré mi pantalla en 4 categorías:
  

  1. Tracking de productividad (google calendar, PivotalTracker y Toggl)
  2. Producción: los programas que necesite para la tarea en cuestión, ya sea programar, escribir propuestas o diseñar.
  3. Comunicación (gmail)
  4. Social (twitter, facebook, blipea)

• Desactivar las notificaciones automáticas de todos los programas y sitios web, y aparecer offline de GTalk y Skype la mayor parte del tiempo.
  .
• Crear filtros en mi email para mantener el inbox lo más vacío posible (siguiendo consejos de inbox zero)
  .
• Llevar bitácora de tiempo de todas las actividades en que trabajo… para esto siempre uso toggl.com
  .
• Algo importante es no tratar de tener más de 3 proyectos o bloques de tareas importantes por día… debes enfocar los bloques productivos sólo en esas tareas.
  .

Por ejemplo, mi calendario de Google se ve así actualmente:

La disciplina

Como han de estar pensando, seguir un plan así al pie de la letra es bien difícil y casi imposible… pues sí, lo es…

A medida pasaban las semanas y lo probaba en la vida real, resultaba bastante difícil seguir el calendario al pie de la letra ya que  las situaciones ‘imprevistas’ son precisamente eso… no se pueden predecir. Si tengo el lunes reservados para incendios, pero no ocurre nada ese día… significa que otro día algo pasará y tendré que dedicarle tiempo entonces. Claro que, como el mismo plan indica, podría usar las horas del lunes en una actividad planeada del miércoles y luego dedicar el miércoles para los incendios… pero se vuelve complicado llevar control de que cambios se hicieron en el plan.

Pero bueno, el calendario sirve como un plan aspiracional de “Lo que debería estar haciendo”.

Este calendario son bloques de tiempo generales, en los que puedo designar un bloque de 4 horas en la mañana del martes para “proyectos propios”, pero el detalle de qué tareas específicas debo hacer en ese momento debe ser llevado en otra herramienta. Para esto yo uso PivotalTracker.com que me permite organizar listas de to-do para múltiples proyectos. También he usado Basecamp en ocasiones pero al final de cuentas el que más me ha servido para proyectos de desarrollo de software es PivotalTracker.

Las tareas específicas que tengo en el PivotalTracker, organizadas por proyecto representan mi organización de “Lo que tengo que hacer” .

Finalmente, necesitaba una forma de llevar control de “Lo que estoy haciendo” … las actividades que realmente estoy haciendo y contabilizar el tiempo que le dedico a cada una… esto para aprender de mí mismo y la forma en que trabajo… así puedo ir ajustando el plan, cada vez haciéndolo más realista.

Como ya había mencionado antes, para este control uso toggl.com (antes usaba una hoja de excel), que es excelente para ‘marcar tarjeta’ cada vez que inicias y terminas una tarea.

Entonces, al final he terminado con tres herramientas web que me ayudan a mantenerme enfocado mis actividades productivas, organizando mi vida en tres niveles:

Lo aprendido

Desde mucho antes de esto, mis amigos cercanos, con quienes he trabajado en algún proyecto antes me apodaron “RoboCorp” porque siempre he sido bien organizado, puntual y todo. Creo que algunos de ustedes pensarán que esta metodología de trabajo es demasiado extrema y que solo un robot puede seguirla, pero creo que lo importante que he aprendido es que:

1. Es bastante complicado seguir este plan al pie de la letra, pero ayuda a enfocarse y tener por lo menos una metodología definida de trabajo para no perderse en la nube de “tengo miles de cosas que hacer y no se por donde comenzar”.
   .
2. Cada quien debe diseñar su propio plan de trabajo y seleccionar sus propias herramientas… esto es lo que ha servido para mí, pero no necesariamente sirva para todos.
   .
3. Lo más importante es “conocerte a ti mismo” y con el uso de estas herramientas y disciplinas podes llegar a conocer detalles como “cuantas horas realmente puedo avanzar a la semana en un proyecto propio o de un cliente”.
   .
4. Lo que más me gusta de trabajar así es que al final de la semana puedo ver que realmente he avanzado en las cosas importantes, puedo medirlo y verlo tangiblemente en un reporte de toggl.
   .
5. Como todo vicio, el primer paso para eliminar la perdida de tiempo que viene del consumo desordenado de ‘social media’ es aceptar que tenemos un problema. Si controlas el consumo de contenidos de una forma ordenada, no perderás tanto tiempo.
   

Recursos útiles

Algunos artículos y libros recomendados para este tema:

• The Power of Less
• Inbox Zero
• 43folders
• The 4-hour Workweek

Herramientas:

• Basecamp: to-do lists y project management simplificado
• Pivotal Tracker: seguimiento de tareas de desarrollo de software
• Toggl: cronómetro de trabajo con reportes de time-sheets
• Evernote: para capturar ideas, notas, pensamientos y URLs desde tu PC o móvil

En junio del año pasado disfrutamos de la conferencia WebConfLatino junto a 300 centroamericanos, evento que organizamos con el objetivo de traer a Centroamérica un evento de calidad centrado en temas de negocios en la web.

La conferencia fue un éxito… los participantes, patrocinadores y expositores quedaron muy satisfechos y sorprendidos, lo que nos dejó claro que WebConfLatino es un evento que debería realizarse todos los años.

Desde septiembre comenzamos ya con los detalles de organización del evento de WebConfLatino 2010. Hoy estamos en las etapas finales de confirmación de conferencistas, comenzando el contacto con patrocinadores locales y actualizando el look y contenido del sitio web.

El 12 de Abril lanzaremos el nuevo website en http://www.webconflatino.com … por el momento puedes ver detalles del evento del año pasado. Por ahora podemos adelantar que el evento se llevará a cabo el viernes 23 de Julio 2010 en el Campus de UNITEC en Tegucigalpa, Honduras. Al igual que el año pasado tendremos conferencistas internacionales representando a España, Colombia, Estados Unidos, Chile, Guatemala entre otros. Esperamos nuevamente recibir participantes de varias ciudades de Honduras y de todos los países vecinos, Guatemala, El Salvador, Nicaragua, Costa Rica y todos quienes quieran venir.

Este 29 de Marzo hice una presentación en Pio.LA, una comunidad en línea de innovadores latinoamericanos que organiza des-conferencias. En esta ocasión la des-conferencia se trataba de las comunidades y movimientos de emprendimiento web en Latinoamérica y me invitaron a dar una presentación acerca de WebConf.

A continuación les dejo el video de la presentación:

Hace unos meses tuve la idea de una nueva aplicación web a la que llamé KidsAbacus. Durante varias semanas lo he platicado con algunos amigos y colaboradores para conocer sus opiniones e ideas.

En ese proceso me di cuenta que para explicar bien la aplicación necesitaría hacer un prototipo funcional (mockup) para describir de forma rápida lo que esta aplicación web haría y como sería la interacción básica con los usuarios.

Normalmente he usado papel y lápiz (cuando solamente hago bosquejos de mis ideas) o me ha tocado hacer simulaciones más completas en Photoshop para mostrar a clientes (que les gusta ver todo bien acabado), pero en esta ocasión lo que necesitaba era algo más básico, pero no tan simple como papel y lápiz… allí fue que encontré MockingBird.

Qué es?

MockingBird es una excelente herramienta web que sirve para crear ‘mockups’ o ‘bosquejos’ de aplicaciones web de forma fácil, rápida y hospedada en ‘la nube’ para facilitar el proceso de compartir tus ideas con colaboradores y amigos.

La aplicación está desarrollada en el framework cappuccino, no necesita flash para funcionar y es bastante intuitivo y gratis (por el momento). Creo que comencé a usar la herramienta pocas semanas después de que esta se lanzó en beta, el primer post del blog de MockingBird  tiene fecha 3 de Noviembre 2009 (yo lo comencé a usar a mediados de Noviembre).

Algunas de las funcionalidades que me gustan de la versión gratis de MockingBird:

• Compatible con Firefox, Chrome y Safari (Internet Explorer no importa… ese solo lo utilizan los usuarios)
• No necesita Flash para funcionar
• Permite múltiples proyectos bajo la misma cuenta
• Export a PDF y PNG
• Opción para compartir un URL público con tu prototipo
• Enlaces de pantalla a pantalla para simular funcionalidad
• Gran cantidad de elementos de interface de usuario (drop downs, checkboxes, inputs de fecha, iconos, etc)

Cosas que no me gustar y/o me preocupan:

• Si un proyecto crece mucho, los elementos comunes (como barras/menús de navegación) no son parte de una plantilla, entonces hay que hacer cambios manualmente en cada pantalla
• Privacidad de la información… ya que lo que los usuarios hacen en este sitio son básicamente ‘planos de diseño’ de nuevas aplicaciones web, prácticamente ‘ellos’ (los dueños del sistema) pueden espiar las ideas de otros y ejecutar las que más les gusten rápidamente. Si tu proyecto es demasiado ‘top secret’ probablemente no te sientas tranquilo al utilizar MockingBird.

Conclusión

En general me gusta mucho MockingBird y lo estaré usandolo en algunos proyectos en que necesito explicar fácilmente a otros miembros del equipo lo que deseo que el producto final haga.

Aunque sigo pensando que en la mayoría de los casos lo mejor es papel y lápiz, MockingBird es una excelente opción para cuando necesitas compartir tus ideas de aplicaciones web con otros.

Hace unas semanas estaba buscando un archivo antiguo en un disco duro de backup y encontré el folder de mi proyecto de graduación de la Universidad. En el año 2000 registré el dominio miCajita.com y hospedé allí mi proyecto para la presentación a la terna de graduación, pero despues de unos meses no continué el proyecto ni volví a renovar dominio… hoy es un proyecto muerto.

Fue mi segunda aplicación web en PHP/MySQL, unos meses antes había desarrollado junto a @rbreve un portal multiservicios llamado SiliconAlien, proyecto que hoy tampoco existe (siliconalien en archive.org)

En que consistía?

La idea de miCajita era simple y apta para aquellos días en que no existía Gmail y las cuentas de correo gratuitas (e incluso las pagadas) tenían límites de espacio demasiado bajas.

En esos días era muy común que uno no podía enviar correos con attachments de más de 1MB porque posiblemente la casilla de el receptor estaba llena. miCajita era una solución en que cada usuario podía crear su cuenta de 10 a 100MB de espacio para subir archivos que quisiera tener disponibles para compartir con otros.

El sistema incluía opciones como:

• File Manager web con folders públicos y privados
• Control de accesos para lectura y escritura a nivel de archivo y folder para usuarios individuales y grupos
• Envío de archivos desde miCajita hacia direcciones de email

Por qué murió?

Era un proyecto que inicié por razones académicas (para graduarme) y en esos días estaba más metido en la onda de iniciar mi  empresa de consultoría, desarrollando websites para clientes.

Me pasó por la mente lanzarlo públicamente pero le tuve miedo a varios aspectos como:

• Competencia existente: servicios como Xdrive, el cual hasta tenía un software instalable para integrase al File Explorer de Windows, creando un disco virtual al podías drag and drop archivos para subirlos.

• Falta de dinero: me preocupaba el costo de hosting, ya que el plan era regalar unos 100MB por usuario si lanzaba el servicio al público. En ese entonces el hosting era más caro que ahora y no tenía fondos propios para soportar el costo.

• Falta de interés: los dos factores anteriores hicieron que mi interés por lanzar el proyecto públicamente muriera. Si volviera al pasado, posiblemente hubiera seguido con el proyecto buscando apoyo financiero externo…

Lo positivo…

Creo que todo proyecto y experiencia en la vida deja algo positivo.
De este proyecto puedo mencionar unas cuantas consecuencias positivas:

• Aprendizaje: siendo uno de mis primeros proyectos de desarrollo web aprendí mucho en un tiempo bastante corto. Esto me sirvió en mi objetivo de desarrollo profesional como consultor y empresario.

• Dinero: Fue la base de un sistema privado de folders compartidos que vendimos a varios clientes para sus intranets. Logré monetizar el tiempo invertido en la programación vendiendolo al menos 10 veces y creando un buen nombre para mi empresa.

• Quedar con ganas de hacer más: el haber realizado el proyecto y seguirle los pasos a los servicios similares que existían en ese momento me hizo ver (a la larga) que las buenas ideas surgen y evolucionan rápidamente… me dejó picado por intentar nuevamente con proyectos propios.

Documentación

En el folder del backup que mencioné al inicio encontré dos documentos relevantes:

• Manual de Usuario – 350 KB
• Manual de Técnico – 569 KB

Son suvenirs de hace 10 años… mucho ha cambiado desde ese momento y si volviera a programar el sistema lo haría completamente de otra forma, pero allí les dejo para quienes tengan curiosidad de leer más acerca de lo que fue miCajita en su momento.

El problema…

Todo estaba funcionando bien en mi computadora cuando hice la integración usando el gem “hpricot”, pero al subirlo al grid container tuve problemas. El log de Rails indicaba que el archivo hpricot_scan.so no era accesible.

Encontré la solución en un blog, el problema era que la versión de Ruby bajo la que operan los grid containers es la 1.8.5 y para esta versión hay unos problemas que requiren que se modifique el código fuente del gem.

OK, procedí a hacer los cambios en el código fuente tal como dice el artículo, pero me surgió otro problema…

/usr/lib/ruby/1.8/fileutils.rb:754: command not found: ragel -v

El  “rake” para regenerar el gem con los cambios requería “ragel” en el servidor…

Ya que los containers son pedazos virtuales de una maquina, no tengo acceso root para instalar nuevos paquetes, esto me impidió solucionar el problema:

• Instalando una versión más nueva de Ruby, por ejemplo 1.8.6 o 1.8.7
• Instalando Ragel y completar el proceso de regenerar la gem hpricot

Otra opción era pasar todo a un servidor dedicado y volver a preparar el ambiente de desarrollo, pasar la base de datos, etc… esto es factible pero no cuando necesito que mi cliente vea el update mañana.

La otra opción era hacer la integración nuevamente con algo diferente a  hpricot… opte por esta.

La Solución

Encontré un blog post que compara tres formas de leer XML desde Rails… este me salvó ya que pude hacer la integración utilizando un método que no requiere librerías externas.

El artículo compara REXML, Hpricot y libxml-ruby … de todas la más lenta es REXML, pero es la que no depende de librerías externas y por lo tanto la que termine utilizando (probé con libxml pero tuve un problema similar).

Claro que esta es una solución temporal, solo para que mi contraparte en el proyecto pueda ver el avance.

Ejemplo de Uso de REXML

La solución con REXML es fácil de implementar y quiero compartirla en caso que alguien necesite leer XMLs desde una aplicación de Rails sin necesidad de usar librerías separadas.

Para el ejemplo usaremos el API de Twitter… este es el XML de mi timeline: http://twitter.com/statuses/user_timeline/corp.xml

Primero crearemos una función que recibe como parametro el usuario de twitter que queremos consultar, luego lee el XML correspondiente, lo almacena en un arreglo llamado twitts y lo devuelve con return twitts:

Ahora ya podríamos usar esta función en nuestro controller, enviandole el usuario como parámetro.

Para mostrar los twitts que almacenamos en el controller, la vista sería algo así:

Conclusión

Hay muchas formas de leer XML desde Rails, de hecho las mejores y más elegantes facilitan mucho más el acceso a los datos por medio de integración con los modelos.

Lo que pude implementar con REXML es una solución rápida y simple que sirve para la etapa en que estas en desarrollo y para que tu cliente (socio o contraparte) pueda ver los resultados de la integración al API deseado.

Para producción conviene utilizar soluciones más eficientes. Mientras investigaba encontré esta presentación que describe muchas formas elegantes y más eficientes de leer XML con Rails: