Desplegando a diferentes instancias de heroku

Lo iba a apuntar en un documento para no olvidarlo, no es gran cosa, pero ya puestos lo hago en el blog por si a alguien le sirve también.

En uno de los proyectos que estoy trabajando es una aplicación rails que está montada en heroku, por lo típico que no quiero andar preocupándome de sistemas y de poder que aumentar de máquinas en caso de ir creciendo. Además del entorno de producción, tenía que montar uno de staging, por lo que tenía que configurar dos instancias/aplicaciones de heroku para la misma base de código.

Para ello el primer paso es añadir el remote al git, en mi caso lo llamo staging.

git remote add staging git@heroku.com:my-app-staging.git

Lo siguiente es hacer el despliegue haciendo push, en este caso trabajo sobre una rama dev que es desde la que hago el despliegue al entorno de staging.

git push staging dev:master

Quede dicho que el manejo de ramas es master para producción y dev para desarrollo/staging, al trabajar sólo (salvo para cosas puntuales de maquetación) por el momento me resulta más que suficiente.

Una de las cosas que pasa es que necesitaremos pasarle el parámetro –app para decirle sobre que instancia queremos hacerlo. Algo así:


heroku rollback --app my-app
heroku run rake db:migrate --app my-app-staging
heroku logs --app my-app

Y ya, en un pispas está todo listo.

Gracias Rails

Gracias a @tomaslin, me encuentro un más que interesante post llamado Thank you, Rails de Jacob Kaplan-Moss, presidente de la Django Software Foundation, con quien no podría estar más de acuerdo!

Es más que habitual ver gente de dentro de una comunidad de un framework inspirado en Rails hacer críticas más o menos feroces hacia el propio Rails, y comparar el framework de turno con Rails para “demostrar” que tiene mejor rendimiento, que escala mejor(en cualquier caso, pienso que sería más correcto decir que es más fácil escalar), etc., afirmaciones que pueden ser más o menos reales, aunque hay por ahí algunos benchmarks/comparativas que hay que cogerlos con pinzas.

A mi, en la mayoría de los casos, me parece una actitud negativa que “enfrenta” comunidades, a ver quien la tiene más larga, y no lleva a ninguna parte. Es mucho más inteligente observar, aplaudir y por qué no copiar o adaptar, los avances de frameworks diferentes al “mío”.

Para mi, el gran mérito de Rails, además de que se haya creado una comunidad más que interesante alrededor suyo, es que replanteó a muchos como se llevaba a cabo el desarrollo web, y por ello que hayan salido tantos frameworks web que lo han tenido como ejemplo para tener algo similar en otros lenguajes de programación (Grails, Django, CakePHP, Symfony, Roo, Zend, Play!, y otros muchos que me dejo).

Y volviendo al post de Jacob Kaplan-Moss, agradece principalmente dos cosas de Rails:

  • La programación debe ser divertida(pienso que Ruby dentro de Rails tiene mucha culpa en este punto): Creo que la mayoría que nos metimos en este mundillo, lo hicimos porque nos parecía que iba a ser divertido (bueno… otra razón era que la informática era el futuro y se iba a cobrar mucho dinero XD).

    Jacob habla de que la comunidad Python a veces se toma a ella misma demasiado en serio: necesitaba ser un lenguaje serio, usado por gente seria, para empresas serias y grandes desarrollos(a.k.a. “enterprisey”).

    Y llegó Rails para recordar que el desarrollo web debería ser algo divertido, la comunidad Rails en general desprende que se pueden desarrollar productos pequeños, divertidos, ligeros y además hacer dinero con ellos.

  • La simplicidad es una feature, o lo que sería menos es más: Pone como anti-ejemplo el caso de los CMS y la típica obsesión de cubrir el máximo de casos de uso posibles, terminando siendo productos mastodónticos. Aunque no exclusivo de los CMS, seguro que muchos de los que hemos trabajado con gestión de contenidos, lo hemos vivido.

    Rails, por un lado no pretende cubrir el máximo de casos de uso reales, para eso hay plugins que pueden facilitar la vida; y por otro, es un framework opinado (aquí entra lo de Convention over Configuration ;)). Lo que quiere decir que el framework tiene un funcionamiento por defecto que no es necesario configurar, para ahorrar decisiones al desarrollador, lo que lo hace más simple.

    Resumiendo, gracias a Rails, estos nuevos frameworks tratan de minimizar el trabajo “genérico” de los desarrolladores, sin querer llegar a cubrir cada caso de uso.

¿He dicho que el lenguaje con el que más he trabajado(y sigo trabajando) es Java? Considerado uno de los lenguajes más “serios” y más complejos en cuanto a configuraciones, especificaciones… pero sobre todo en la forma que se ha venido utilizando. Y gracias a Rails han aparecido algunos frameworks web interesantes como Grails o Play!, y creo que algunos otros de los que no hablo porque no tengo suficientes referencias, que son más divertidos y minimizan el trabajo.

Por esto, además de porque he trabajado con Rails y que tengo pendiente retomarlo XD, gracias!

Los helper son un API a nivel de aplicación para tus vistas

There is an art to effectively writing helper methods, similar in nature to what it takes to write effective APIs. Helper methods are basically a custom, application-level API for your view code.

Extraído de The Rails Way, de Obie Fernandez (a ver si lo termino de leer, que ya toca…)

Aplicable a cualquier framework con helpers/taglibs/… para reutilizar en las vistas, por supuesto.

SQLite, booleanos y buenas prácticas

Hace unas semanas estuve implementando un sencillo sistema de votaciones con la ayuda del plugin acts_as_voteable, para un proyecto con Rails, donde me surgió un problemilla que gracias a los tests resultó menos doloroso.

Tras tener ya prácticamente escrita la acción para votar, implementé el test para el controlador con sus diferentes contextos(que sí, que TDD, pero uno todavía está en la fase de acostumbrarse :P). Cuando ejecuté el test por primera vez, esperando que me diera algunos fallos en mi código, me llevé la sopresa de un error SQL con origen en el plugin, que no existía la columna TRUE ¿¿en el where vote = TRUE??.

Lo primero fue pensar que no era posible, con ActiveRecord de por medio eso era un poco raro, por lo que las sospechas fueron para SQLite, que era el gestor de bases de datos en el entorno de tests. Probando a ejecutar los tests con una base de datos MySQL, fallaba mi código y no el del plugin, se confirmó la sospecha.

Una vez implementada completamente la funcionalidad y los tests pasando, tocó perder unos minutos para ver qué estaba pasando y google contesta rápido. Resulta que para utilizar booleanos en queries con SQLite debe utilizarse ‘true’ y ‘false’, al mirar el código del plugin se confirmaba el problema:


votes = Vote.find(:all, :conditions => [
"voteable_id = ? AND voteable_type = ? AND vote = TRUE",
id, self.type.name
])

El valor de vote estaba hardcoded, pues como tocaba cambiar el código, aproveché a cambiar self.type que está deprecated, por self.class:


votes = Vote.find(:all, :conditions => [
"voteable_id = ? AND voteable_type = ? AND vote = ?",
id, self.class.name, true
])

Y al ejecutar los tests con SQLite, los pasó. Pero luego resulta que había alguien que ya había solucionado el problema, como era de esperar en la comunidad Rails, en el plugin vote_fu (llegando a combinar funcionalidades complementarias de tres plugins distintos).

Después de crear la migración para eliminar la tabla de acts_as_voteable y crear la de vote_fu, ejecuté los tests del controlador para ver si tocaba cambiar algo, pero pasaban correctamente.

Conclusiones, además de lo aprendido con los booleanos de SQLite:

  • Aprovechar (en la medida de lo posible) la independencia de bases de datos que aportan ActiveRecord u otros ORMs, sobre todo si estamos desarrollando componentes reutilizables.
  • Y a procurar seguir mejorando en cuanto a la automatización de tests. Desde que empecé a escribir tests, hago commits con la conciencia más tranquila :).

Un poco sobre Open Web

Ayer me pasé por el Teatro Romano de Zaragoza a ver que se contaba en la conferencia de Tuenti. Siempre se saca aglo interesante de estas charlas, otros puntos de vista o al menos alguna curiosidad.

Cuando llegó la ronda de preguntas, hubo algunas respuestas se fueron un poco por las ramas, pero hubo un momento en el que se preguntó sobre Open Web(aunque sin llamarlo así), exáctamente sobre compartir/exportar contactos a otras redes, que me dejó un poco mosqueado, parece que en Tuenti están bastante lejos de ponerse por la labor.

Para conocer una muy buena explicación sobre Open Web, hay una ponencia de Aitor durante la Conferencia Rails 2008, en la que explica muy bien qué es y qué posibilidades hay actualmente(entre otras cosas). Aunque recomendaría ver el vídeo entero, donde habla sobre Open Web es a partir del minuto 6:30.


tog: Open Web, Social Networks y cintas de video from Linking Paths on Vimeo.

2008 de todo un poco

Acabándose el año, toca mirar un poco atrás para ver como ha ido el año, que para mi ha sido muy movido 🙂

Algunos éxitos, o cosas con las que me siento satisfecho, han sido:

Pero como no todo puede ser bueno, hay cosas que no han salido como esperaba y de lo que no me siento especialmente orgullloso:

  • La evolución de los plugins de Grails(Include y Mor.ph), que debería haber publicado al menos otra versión de cada uno, y no les he podido dedicar el tiempo necesario para hacerlo.
  • La colaboración con el plugin JCR/Jackrabbit, al que en su momento le procuré dedicar tiempo, pero donde no ha salido nada aprovechable
  • El desarrollo de flatee, que formaba parte del internship con Linking Paths para aprender Rails, con lo que me comprometí después del internship a tenerlo para finales de año, y que aunque no sea por mucho(espero) no ha sido posible tenerlo este año

Ha sido un año interesante, aunque como freelance haya pecado de novato en varias ocasiones, me haya metido en más jaleos de los que podía manejar, la crisis… :P, he disfrutado de este trabajo más que nunca. Sólo espero que en 2009 se empiece a ver el trabajo realizado durante este año, además de seguir aprendiendo y disfrutando en esta profesión 😉

PD: Feliz año nuevo!! 😀

Videos navideños… o cosas de resaca

Soy consciente de que no soy demasiado creativo/original para estas cosas de las felicitaciones navideñas, me gusta unvlog y los videos que se comparten allí, y este fin de semana tuve un par de días resacoso-prenavideños. Combinando estas tres variables, acabé montando una web con rails para compartir videos navideños (no se me ha ocurrido ningún dominio que merezca comprarse :P) que me pareciera interesante a mi o a cualquiera que pase por ahí o lo comente.

Al ser una web de temporada, he preferido evitar registros, simplemente usar el plugin recaptcha para tener un mínimo de control al publicar videos o comentarios, el plugin para los videos ha sido acts_as_videoclub por lo que esta web soporta los mismos servicios de video que el plugin :P, acts_as_commentable es el plugin para los comentarios, para la paginación will_paginate, seo_urls para hacerlo un poco más amigable a los buscadores y por último acts_as_taggable_on_steroids para etiquetar los videos; el diseño es de una plantilla con licencia copyleft con pequeñas modificaciones.

Como es de suponer no me supuso mucho tiempo de trabajo, alrededor de 6-7 horas y en días en los que se está lejos del 100% ;), además es una web muy mejorable y no está lo terminada que debería, pero el tiempo es limitado y no quería/podía dedicarle más.

En fin, que si os llegan felicitaciones en forma de video de Google Video, Dailymotion, YouTube o Vimeo; y os llama la atención os animo a compartirlo. Por cierto, feliz navidad 🙂

Por la Conferencia Rails 2008

Los días 13 y 14 estuve en Madrid para asistir a la Conferencia Rails, os recomiendo leer el resumen que ha hecho Jesús Navarrete de algunas de las charlas viendo que coincido mucho con él y que últimamente ando un poco vago para escribir ;), de todas formas sí quiero comentar que por lo general me parecieron más interesantes las que giraban alrededor de cómo trabaja la gente y algunos casos de éxito que las de tecnología pura y dura.

También me pareció curioso el speed dating entre gente que busca programadores y quienes buscamos proyectos interesantes en los que trabajar o para quien busca empleo, aunque la mayoría buscaban contratar empleados y no colaboradores freelance.

Otras cosas que quisiera destacar son por un lado los premios de personaje de año y proyecto del año, el primero fue para Xavier Noria y el segundo para Tog, aunque como ya se dijo en la lista de ror-es, hubiera estado bien dar un par de minutos para conocer a los ganadores; y por el otro lado la keynote de Obie Fernandez, que nos habló mucho de su empresa y de cómo trabajan, lo que resultó realmente interesante.

Como siempre, de lo mejor del evento son los pasillos: hablar con gente que no conocías, poner cara a muchos de los que participan en ror-es, encontrarte con algunos que conoces de forma online, juntarte con la gente con la que colaboras a diario e incluso encontrarte a un ex-compañero de trabajo :).

Actualización 21/11/08:

Ya están disponibles los videos de la conferencia.

Fin del Linking Internship ¿Qué pasa con flatee?

Pues como ya han escrito Aitor en el blog de Linking Paths y Jesús en el suyo, el internship ya ha terminado y no se puede decir que haya sido un éxito, ni mucho menos.

La idea era lanzar flatee al terminar el internship, pero por varias razones no ha sido posible dedicarle todo el tiempo y esfuerzo que requería este proyecto y se nos ha quedado a todos la sensación de que ha sido una decepción, personalmente más cuando alguien se ha interesado por la evolución del proyecto. De todas formas, sacando la parte positiva, a mi me ha servido para aprender bastante rails (sin tog) y que uno no se puede liar en un proyecto de este tipo con medias tintas. A mi me cogió en un momento muy liado con el GSoC, otro proyecto propio, proyectos a terceros… ni trabajando algunos fines de semana daba abasto(y de vez en cuando hay que descansar).

Sobre el futuro de flatee, por ahora voy a seguir trabajando en ello como side project, con el compromiso de sacar la primera versión para finales de año. Aunque sigue sin sobrarme precisamente, tengo algo más de tiempo que durante el verano, es un proyecto que cubre una necesidad propia y soy un poco tozudo(como buen aragonés :P). Esto significará pegarme también algunos fines de semana de código encerrado en casa y tratar de liberarme algunos días para dedicarle más tiempo.

Espero que más adelante Jesús pueda volver a incorporarse y podamos sacar a la luz un proyecto que resulte de utilidad a la gente que busca(mos) compañeros de piso o piso compartido.