Test rails api using curl

curl -i 127.0.0.1:3003/hotels?token=SECRET_TOKEN


Git remove untracked files and directories


git clean -df PATH


Kill detached screen session


screen -XS SESSION NAME quit


Free up disk space from Dropbox sync

Ran out of disk space on my puny Macbook Air SSD. After tuning down using "Selective Sync", OSX disk utility still reports 7.9GB of space used by ~/Dropbox folder.


rm -rf ~/Dropbox/.dropbox.cache/*


That solved it. Apparently that hidden folder caches files for easy undelete within 3 days.

reference: http://forums.dropbox.com/topic.php?id=31679

Check disk usage in OSX


du -sh *


Fix Terminal in OSX not sourcing .bashrc

Bash in OSX looks for ~/.profile rather than ~/.bashrc so just create the former and add the following.


if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi


Write testable Git commit messages

Having been a project manager for a couple of projects, I often find myself having to decipher team mate's code commits by digging into code diffs. Take for example.


# Poor commit message with lack of information
fix bugs on email template


Hmm. What bugs is he trying to fix? How would I know if it's really fixed? What if he wrote instead


# Slightly better with description of what the bug is
fix bugs on email template that caused HTML misalignment


Ah, that's better. At least now there's a WHAT context that I can focus on when looking through the diffs. This could possibly be enhanced with a HOW context.


# Even better message
fix bugs on email template that caused HTML misalignment by declaring inline styles on elements


Great, now the only thing left to the piece of the puzzle is WHO determined that those were bugs?


# Almost perfect
[#31] fix bugs on email template that caused HTML misalignment by declaring inline styles on elements


Ok a reference to the bug request on Github would help me find out who requested the issue.

This leads me to the concept of writing good testable commit messages. Example,


# A great testable commit message.
# Format: [REFERENCE] HOW to DO WHAT
[#55] Added inline styles on HTML elements to fix bug that caused misalignment on email templates


That's a great commit message because it can be tested. I could fire up the email mailer and check that the email is indeed aligned properly. And it saves the project manager and the other team mates valuable time by cutting down time spent deciphering what the code was meant to do. Even more important if the commit messages were to be viewed many months down the road.