The best solution to this warning: Giving a path to render :action is deprecated.

I for one welcome this change and deprecation warning. It means that you should stop using this:

render :action => :index

And, if necessary, you should start using this:

render :index

The code is simpler and prettier. Don’t use render :template, unless you really need to.

If you use vim, you can use this search and replace string:

:%s/render :action => /render /g
Posted in open source, programming, Ruby programming, web programming | Tagged , , , , , , | Leave a comment

Por qué deberías usar `git pull –rebase` en vez de `git pull` solo

Al usar

  "git pull --rebase"

Git utiliza git-rebase en vez de git-merge.

git-merge nos genera un commit con todos los cambios entre el branch local y el branch que estamos bajando.

git-rebase va hacia atrás, hasta donde los branches divergieron, hace un reset y empieza a aplicar los cambios progresivamente, hasta llegar al último commit. Esto nos deja un log mucho más fácil de leer que con el commit generado por git-merge.

Así vamos a dejar de ver tantos:

  "Merge branch 'master' of github.com:etagwerker/whuffiebank"

Para más información: http://progit.org/book/es/ch3-6.html

Posted in developer tools, open source, programming | Tagged , , , , | Leave a comment

Cómo usamos Pivotal Tracker en Ombu Shop

Este es el workflow que usamos en Ombu Shop para seguir las stories con Pivotal Tracker.

Objetivo

Atender todas las tareas pendientes sin que se nos escape nada. En base a la velocidad del equipo, tener una idea de fechas de entrega de cada story.

Prioridades

Se dividen por columnas. Current es más importante que Backlog. Backlog más importante que Icebox. Mientras más arriba en la columna se encuentre una story más prioridad tiene.

1. Toda mejora, bug o tarea debe figurar como una story en Pivotal

Bug: Comportamiento inesperado del sistema. Un error según lo especificado por una story previo.

Requester: La persona que pide la story. El requester es el que finalmente deberá aceptar la story.

Owner: La persona indicada para resolver la story. El requester elige al owner.

2. Antes de empezar, el owner debe estimar la tarea

Para estimar se usan los palitos horizontales a la derecha de la story. Más palitos, más complicado. Los bugs no se estiman.

Ejemplo de una story:

3. Una vez que el owner empieza debe darle Start a la tarea

Esto sirve para calcular la velocidad de nuestro equipo.

4. Una vez que termina debe darle Finish

Esto pondrá a la story lista para darle Deliver.

5. Una vez que se sube a producción debe darle Deliver

Solo se le dá Deliver cuando está en producción.

8. Recién ahí el requester debe darle Accept o Reject

El requester va a ser siempre el responsable de aceptar la story. Si uno le dá Reject hay que ser lo más claro y específico posible para decir por qué no se acepta.

Si la story fue aceptada y estaba relacionada con un cliente, avisarle. Eso queda a cargo del requester

Si la story fue rechazada, el owner va a tener que darle Restart (Ver #3) una vez que vuelva a trabajar sobre la tarea.

Posted in developer tools, entrepreneur life, software engineering | Tagged , , | Leave a comment