miCajita.com – Hace casi 10 años

corp — Thu, 19 Nov 2009 01:15:01 +0000

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.

Leyendo APIs desde Rails

corp — Thu, 12 Nov 2009 23:12:01 +0000

Esta semana tuve que integrar un sitio hecho en Rails con el API de wine.com. Mientras esta aplicación está en desarrollo se hospeda en un grid container pequeño de media temple.

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:

def get_twitts(user)
apiurl = "http://twitter.com/statuses/user_timeline/#{user}.xml"
url = URI.parse(apiurl)
request = Net::HTTP::Get.new(apiurl)
response,body = Net::HTTP.new(url.host, url.port).start {|http| http.request(request) }
twitts=[]
doc = REXML::Document.new(body)
doc.elements.each(‘statuses/status’) do |s|
h = {}
%w[created_at text source].each do |a|
h[a.intern] = s.elements[a].text
end
h[:screen_name] = s.elements[‘user’].elements[‘screen_name’].text
h[:profile_image_url] = s.elements[‘user’].elements[‘profile_image_url’].text
twitts << h
end
return twitts
end

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

def show_mytwitts
@twitts = get_twitts("corp")
end

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

<%for twitt in @twitts do%>
"<%=twitt[:profile_image_url]%>" width="25" />
<%=twitt[:screen_name]%>: <%=twitt[:text]%>
Enviado desde <%=twitt[:source]%>
<%end%>

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:

Ruby Xml Mapping

View more documents from Marc Seeger.

alejandro corpeño » programación