Sorry for those who aren’t nerdy, because here’s another post. Ha, who am I kidding, who reads this blog?

anyway, heres a meme i found via:

macbeezy:thehungrylion benny$ history|awk '{a[$2]++} END{for(i in a){printf "%5d\t%s\n",a[i],i}}'|sort -rn|head
  104   git
   68   cd
   55   svn
   50   l
   47   ls
   23   vim
   22   sqlite3
   14   ruby
   14   rm
   13   cp

Yeah its been a while, but hey, its what i do. A lot a lot has happened since the last post (I’m apparently not a loser, who knew?) but I’m going to be lazy and leave you guys hanging and talk about random crap.

So recently, I’ve been on a total nerderiffic mood recently. “But benny, aren’t you always a nerd?” Good point, but believe it or not its even worse than usual.

Since discovering http://open.blogs.nytimes.com, I’ve been reading a lot and the most recent thing that I’ve come upon is a version control system called ‘git‘. I found a google techtalk and also read somewhere that Ruby on Rails is moving over to git, i thought it was worth a look.

Anyway, after listening to him talk, some reading, and messing around with git, I’m convinced its the right vcs for me (and you) and I havent even tried it!. Here are two points really stand out to me and just make sense:

1. Distributed and relatedly Local Commits - description here. Now, not having a central repository might seem weird at first, but if you think about it a bit, it kind of makes sense.

   Having a centralized respository, as with subversion or CVS, means that any code you want to track will reside there. Thats all fine and dandy and I like that because there is a central place where my code resides. But what about the situation when you’re messing around with your own code and experimenting, but also want to keep track your changes. In svn or cvs, you would have to create a branch, track your changes there, and somewhere down the line, merged it all back together.

   That, to me, seems very silly. I don’t see the need for my experimental changes, which I may very not use in the future, to be forever reside in the central repository. It dirties the repository and wastes space. I should be able to branch on my local repository, track my changes, and when the time comes, decide whether or not to merge them into my main branch.

   But what if you want a “main” public repository that will have the de facto version of the code? That is also possible (and easy!) in git. If you do a quick google for “git public repository“, you find help in no time.

   Linus also makes a valid point that if you’re disconnected, ie. on an airplane, there’s no reason why my revision control software shouldn’t be able to keep track of my code changes. Isn’t that the whole point of a VCS! In svn/cvs, the only way to commit changes is if you can access the repository, which can be extremely inconvenient. I want my vcs to track my changes, no matter where/how connected I am. period.

2. Separate orthogonal changes - have you worked on a project where you were making two independent changes? No? Well, that’s ridiculous

   Anyway, for the rest of the 99.9% of people who have, a problem with most VCSs is that it is either: an atomic commit of the working tree, or atomic commits based on files. Let me explain.

   In svn, if you do a svn status, it shows you all the files you have changed. If you have more than one logical change, like a new feature and a bug fix, you have to commit them at the same time (as far as I know, let me know if not!). So all the changes that you’ve made, whether they’re related or not, is committed. This doesn’t seem very logical to me. What if I wanted to put in the bug fix first before I polish the new feature a bit. I’m not sure how I would do it with SVN without some manual fiddling around. I stand corrected. I guess I haven’t used subversion (or forgot it :P) enough. whoops

   This is partially solved by other VCSs, such as Perforce (what we use at work). In Perforce, there is an idea of “Changelists”. Changelists are lists where you can separate the files that you want to commit. Like in the example above, the files that are affected by the bug fix can go into one changelist, while the new feature can go into another one. Then I can commit the bug fix without having to commit the changes I made for the new feature.

   But yes, there is even a problem with that! What if those two changes affect the same file? How can you commit the changes for the bug fix, without partially submitted some changes associate with the new feature? File level commits aren’t good enough.

   Git to the rescue! Git allows you to pick and choose what content, not files you want to commit to the repository. Git lets you pick the changes you want to add to your index (which is like a changelist) before committing them. Controlling what content is committed, rather than the file, is much more logical to me.

There are many more things about git that are really pretty great, but those are the two that are most iimportant to me. Git’s popularity has been gaining momentum since Linus’ talk so I’m sure if you look around, you’ll find that a lot of people love a lot of different aspects of git, so I suggest you at least take a look at it if you’re using any type of source control.

There a problem in today’s world. It’s widespread and is very crippling, in some cases. The problem, of course, is that of the “jaggies” (so maybe not the technical term). Many computers with LCDs and many laptops suffer from this. This is when the fancier, (usually) more interesting fonts on a webpage or elsewhere looks very jagged on LCD monitors. On the CRT monitors, the text will display fine. Take a look at the example of bwong.net below:

On the left, we have the jagged letters. As you can see, the letters look very crude and just plain ugly. On the right, however, we have text that is rendered using what is called “ClearType.” See the difference? The font is much smoother and much easier on the eyes than the one on the right. There’s an interesting reason behind it, but I won’t bother explaining since the Wikipedia article can do it far better.
Instead, I’ll show you guys step-by-step (there’s only three) how to alleviate this problem on Windows (as far as I know, Macs don’t have this problem)

Step 1:

Right click your desktop and click on “Properties”:

Step 2:

Click on the “Appearance” tab, and then the “Effects” button:

Step 3:

Click the checkbox “Use the following method…” and then choose “ClearType” from the pull-down menu:

And voila! Smooooove letters.

Being new to Ruby on Rails, I didn’t really understand the whole session business and was caught off guard when I looked into my tmp/sessions directory. I found upwards of 20,000 Rails session files. After poking around, there are many different ways to store these sessions (and alter them) and ultimately decided I’m too lazy to change it from the default session storing.

I had found this code snippet which allows me to remove stale Rails sessions using cron. However, on Dreamhost, cron does not have an environment so you have to tweak to the following:

* * */4 * * /usr/bin/find /home/benny/ -name "ruby_sess*" -cmin +6000 -exec rm \{} \;

How do you add it? ssh into your dreamhost machine and enter the following line:

$ crontab -i