I wanted to get away from rvm and start using rbenv. As of January 2012, there were some issues with installing ree on ubuntu 11.10 because of the openssl v2 issue found here. Here is how I set up my machine and with good success:
1) Remove all traces of rvm from my system: sudo apt-get remove rvm-ruby clean up my .bashrc (.bash_profile if that's you) to remove rvm
3) Install ree. Now the trick to getting around the openssl issue here is not to use ree-1.8.7-2011.03 but to use ree-1.8.7-2011.12 instead: ruby-build ree-1.8.7-2011.12
4) Set up my local environment using ~/.bash_profile Here is what I put in mine: export GEM_HOME="$HOME/.localgems" # I created a ~/.localgems directory export PATH="$HOME/.rbenv/bin:$HOME/.localgems/bin:$PATH" # Added the rbenv binary and .localgems/bin to my path
5) Set up my rails project to use the ruby I installed using ruby-build: cd ~/Rails/my_project rbenv local ree-1.8.7-2011.12
You should now have a .rbenv-version file in your project directory. This translates roughly to a .rvmrc file.
6) Bundler. I want bundler to manage my project gems instead of relying on rvm gemsets. To do this, I created the bundle config file for my user: mkdir ~/.bundle echo 'BUNDLE_PATH: vendor/bundle' >> ~/.bundle/config
7) Source your .bash_profile: source ~/.bash_profile
8) Install bundler. Note: you will need rubygems installed. You can use sudo apt-get install rubygems if you are using ubuntu gem install bundler
9) Enter your project and do your bundle install cd ~/Rails/my_project bundle install
In my svn toolbox, I reach for these the most. I hope you find them useful too.
Creating a new branch based on a pre-existing one:
svn copy
Quickly see what files will be merged before actually doing a merge:
cd my_checked_out_repo svn merge --dry-run -r123:HEAD .
Merging a single commit (the closest thing I can find to a GIT cherry pick):
svn merge -c 123 .
svn merge -c 124 -c 126 .
svn merge -c -r123:126
You can even just grab the part you need within a revision cd trunk/path/to/file.rb svn merge -c 123 http://../branches/mybranch/path/to/file.rb file.rb
Say I want to merge my branch into trunk or another branch. I first want to find the revision where my branch actually first became a branch. To do it, use the --stop-on-copy flag.
cd my_checked_out_repo svn log --stop-on-copy
The result is that I split my branch at revision 123
This gives me a revision number to start from - then:
cd path/to/trunk_or_branch_to_merge_into svn merge -r123:HEAD .
There may be conflicts. I choose to postpone them so I can do a side by side diff and merge. I use Rubymine for this - but there are other good tools like kdiff3 (excellent tool)
Say you want to move to an entirely new Subversion repository and you want a brand new clean slate - no past revision info - just code: svn export https://my.subversionhost.com/space_ghost_repo/trunk clean_export svn co https://my.new_subversionhost.com/new_space_ghost_repo new_project cp -r clean_export/* new_project/trunk/ cd new_project svn add * svn commit -m "First clean slate commit"
I scoured the web trying to find good examples of how to do this. There were quite a few suggestions, but none of them captured the output of this system command:
fping -C 5 -q www.example.com
In the end, I found a sure way to capture it:
f = IO.popen("date; fping -C 5 -q www.example.com 2>&1").readlines
It's a pain to run a capistrano deployment just to find out something failed - perhaps in one of your migrations. At this point, you are getting upset because --trace wasn't run and you couldn't see where the actual issue was. Never fear. Open your Rakefile and add:
Rake.application.options.trace = true
After adding that and committing, run your cap deploy again and you will see that stack trace.
I couldn't for the life of me figure out why my 200 simple rspec tests were running so painfully slow on my Ubuntu partition and so quickly in Debian on VirtualBox running in a Windows 7 Host. Apparently, Ubuntu allows the use of barriers on ext4 partitions by default.
Recently I built a gem for rails called wepay-rails. I cloned a copy of it locally so that I can work on it. Eventually though, I wanted to test it with my rails app and make changes to the gem code. So I then put it in my vendor/gems directory while I developed it. The problem I was running into though was making sure that the changes I was making in my vendor-ed version made it into my cloned version. It was a hassle to remember all the changes and make sure that the code moved across ok. I found the solution to this problem: Diff and Patch.
Here are some steps to create a patch from the vendor-ed gem and apply it to the cloned gem for release:
We are going to replicate our database to have a single slave for readonly access and a master for our writes. I chose Octopus because it is actively maintained, does sharding (a future project), allows selects to happen on the slave and writes to happen on the master out of the box without me having to touch every single "find" in my code base.
We are going to do this on EC2. Your files might be in different locations than mine are.
This is where the instructions for replication are written by mysql. We also give this mysql server an id of 1.
On your slave, modify the my.cnf and do this: [mysqld] ... ... server-id = 2
Now open a mysql client on your master db and do: mysql> grant replication slave on *.* to 'replication'@XXX.XXX.XXX.XXX identified by 'my_secret_password'
change the above to use an actual ip address after 'replication'@ and also use a real password.
Restart mysql.
Next, do a read lock mysql> FLUSH TABLES WITH READ LOCK;
Record the file and position on the master. It should give you output like this. Record the file and position to use later.