Showing posts from May, 2008

Syntax Highlighting for Ruby Made Very Easy

So I've been making do with lame-o 'pre' tags for my code snippets and my blog looks, well, lame. But the various alternatives for highlighting ruby either didn't work for Blogger or smacked of effort (and you know how I feel about effort). Well, recently I joined Obtiva and I was being all nosy looking at my new co-worker's blogs, when I found Tyler Jennings post about creating Spotlight . Take some ruby code, paste it into the text box, press a button, and you get some html which you copy and past into your blog. You'll have to include the default css in your css file the first time, but that's not too hard. Output looks like this: 1 class Echo < ActionMailer :: Base 2 def copy formatted_message, incident_id 3 users_with_echo_emails = User .find( :all , 4 :conditions => " echo_email is not NULL " ) 5 users_with_echo_emails.reject! {|user| !user.receive_echo?} 6 r

Saving in TextMate

So today, for something like the fifth time, I sat down in front of a TextMate installation that didn't have saving set up the way I like it: Auto save on loss of focus and when running a test (or spec). And, for the fifth time, I had to dig around the internet for the answer. So, as a public service to my future self: Save files when focus is lost: TextMate --> Preferences --> Advanced --> Saving Save all files when running a test (or spec): for specs: Bundles --> Bundle Editor --> Edit Commands --> Rspec --> Run Single Example Bundles --> Bundle Editor --> Edit Commands --> Rspec --> Run Examples for tests: Bundles --> Bundle Editor --> Edit Commands --> Ruby --> Run Bundles --> Bundle Editor --> Edit Commands --> Rspec --> Run Focused Unit Test Change the save drop down to "All Files in Project" Hope this he

Metric_fu Now Measures Churn

Sometimes a class does too much. It's used everywhere, does everything, knows all about the nasty internals of all the other classes, and every time you change anything in the application it has to change. Or maybe you have a class that everyone loves to refactor because it's so bad. One developer changes it to be better, then another changes it to be a different kind of better, and this keeps happening without it ever getting any easier to use. There's a lot of bad reasons why a class might change all the time so I added a churn report capability to metric_fu version 0.6.0. Now you can use metric_fu to create a report like this: By issuing this command: rake metrics:churn And use the results to find classes that might have problems. It uses 'svn log' to create this report so currently you need to be using subversion. (If anyone out there want to contribute some code to get it working with git, lemme know.) The default is to start counting changes f