]]>Run this:
[cc lang="bash" width="700" line_numbers="false"]
/Developer/Library/uninstall-devtools
[/cc]
Simply download and install.
Simply run this one liner in your Terminal.
Simply run that one liner in your Terminal.
Like this:
[cc lang="bash" width="700" line_numbers="false"]
CC=/usr/bin/gcc-4.2 rvm install 1.9.2 –enable-shared
[/cc]
I hope this helps.
]]>[cc lang="bash" width="800" line_numbers="false"]
Building native extensions. This could take a while…
ERROR: Error installing mysql2:
ERROR: Failed to build gem native extension.
1.9.1/ruby/ruby.h:108: error: size of array ‘ruby_check_sizeof_long’ is negative
/Users/etagwerker/.rvm/rubies/ruby-1.9.2-p180/include/ruby-1.9.1/ruby/ruby.h:112: error: size of array ‘ruby_check_sizeof_voidp’ is negative
In file included from /Users/etagwerker/.rvm/rubies/ruby-1.9.2-p180/include/ruby-1.9.1/ruby/intern.h:29,
from /Users/etagwerker/.rvm/rubies/ruby-1.9.2-p180/include/ruby-1.9.1/ruby/ruby.h:1327,
from /Users/etagwerker/.rvm/rubies/ruby-1.9.2-p180/include/ruby-1.9.1/ruby.h:32,
from ./mysql2_ext.h:4,
from client.c:1:
/Users/etagwerker/.rvm/rubies/ruby-1.9.2-p180/include/ruby-1.9.1/ruby/st.h:69: error: size of array ‘st_check_for_sizeof_st_index_t’ is negative
[/cc]
Sadly, the only way to fix it is to uninstall and re-install your MySQL.
You can follow these instructions.
Before you do that, you should back up your /usr/local/mysql/data directory (which contains all your MySQL databases)
Even though that article is for 10.6 it will still work for 10.7
]]>Hopefully they will graciously solve that problem soon. Until then, here is the workaround.
Whenever you modify anything in a submodule, you will need to commit it and push it:
[cc lang="bash" width="700"]
$ cd ~/your-project
$ cd path/to/submodule
$ git commit . -m ‘I changed X and Y because Z’
$ git push
$ cd ~/your-project
[/cc]
Once you’ve done that, you can sync your main repository with Github for Mac.
That’s it!
For more information on Git, this is a useful page: $ cheat git
]]>The faster way:
The painful way takes time.
Backing up 400GB takes time.
Installing Snow Leopard takes time.
Installing Lion takes time.
It’s painful because you should re-install MySQL Server and recover your databases from the TimeMachine backup.
You will need to re-install PostgreSQL. Thankfully it’s just:
[cc lang="bash" line_numbers="off"]
brew install postgres
initdb
createuser postgres
[/cc]
It’s painful because you will have to re-install XCode. (or you’ll run into an issue like this trying to install git)
Installing XCode is not just installing it using the App Store, it’s also running Install XCode. Talk about mixed messages.
It’s painful because the version of gcc (LLVM based) won’t be the one you want. Thankfully there is a solution for that too.
Finally you can install RVM and the Ruby versions you want (1.9.2 and 1.9.3 for me)
And you are all set.
]]>You probably want to use stub just to simulate a behavior, one that you don’t want to test in your current test.
For example: You may want to use stub with a remote service, an API call.
Also, the method is stub not stub! (at least in RSpec 2.6.0)
This will not work but will not fail.
[cc lang="ruby" width="820" line_numbers="false"]
# This won’t work
DineroMailIpn::Client.any_instance.stub!(
:consulta_pago).and_return(@response_with_pays)
[/cc]
This is what you are looking for.
[cc lang="ruby" width="820" line_numbers="false"]
# This will work
DineroMailIpn::Client.any_instance.stub(
:consulta_pago).and_return(@response_with_pays)
[/cc]
I don’t know exactly why stub! doesn’t fail, but it wasn’t doing what I was expecting (to actually stub that method and return the mock object I wanted)
]]>
]]>[cc lang="ruby" width="600" line_numbers="false"]
render :action => :index
[/cc]
And, if necessary, you should start using this:
[cc lang="ruby" width="600" line_numbers="false"]
render :index
[/cc]
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:
[cc lang="bash" width="600" line_numbers="false"]
:%s/render :action => /render /g
[/cc]
]]>
]]>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:
[cc lang="bash" line_numbers="false" width="600"]
“Merge branch ‘master’ of github.com:etagwerker/whuffiebank”
[/cc]
Para más información: http://progit.org/book/es/ch3-6.html
]]>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.
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.
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.
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:
Esto sirve para calcular la velocidad de nuestro equipo.
Esto pondrá a la story lista para darle Deliver.
Solo se le dá Deliver cuando está en producción.
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.
]]>I had to google a lot until I found the answer here, on Matt’s blog: “Please install the postgres adapter”
As usual, it was a stupid mistake in the database.yml:
[cc lang="ruby" width="600"]
development:
adapter: postgres
database: ombu_development
pool: 5
timeout: 5000
[/cc]
The adapter is called “postgresql” not “postgres”
[cc lang="ruby" width="600"]
development:
adapter: postgresql
database: ombu_development
pool: 5
timeout: 5000
[/cc]
I hope this saves you time.
]]>Yet another good reason is performance! (From @tenderlove’s blog post)
So, if you still keep all your gems in ‘system’, you should seriously consider switching to rvm gemsets per project.
]]>