One thing I usually forget to do when I backup a computer is back up my MySQL databases. Partly, because they’re not stored in my Library (I don’t think); partly because I forget how many I have. mysqldump only backs up one database at a time, unfortunately. What would be great is something that dumps all of the databases in the system.

Anyhow, whilst on hold to my ISP this morning, I decided to solve this problem once and for all.

The end result is a pair of Ruby scripts which you can get from github.

The first will iterate over every db on your system (when run with an appropriate username and password) and spit out a .sql file with a filename corresponding to that database. The second look at a folder of .sql files named similarly, and for each one, drop a databases with that name, re-create it, and restore from the .sql file.

I’m sure I could do it just fine in a bash script, but it made sense to use the tool that comes most quickly to my hands, and that means Ruby. Once you’ve got Ruby installed, the rest is easy. Clone them, patch them, fix them; they’re basic, as maintenance goes, but handy.

Get the scripts from github.

A pet peeve of mine is the lack of a documented shortcut in Ruby’s #strftime to function to return the hour of the day, in twelve-hour clock, without a leading zero. To wit:

puts Time.now.strftime("%I:%M") # >> 03:29

That’s not particularly attractive. I could strip the leading zero with some string manipulation, but this is getting sledgehammer-ish to crack a nut. Fortunately, this works:

puts Time.now.strftime("%l:%M") # >> 3:29

That’s a lowercase L in the formatting string, which returns the number of hours in a twelve-hour clock sans leading zero. Result! And yes, that’s undocumented everywhere I’ve looked. Thanks to my colleague Colin for pointing that trick out.

Now, if only I could get it to return am/pm without having to call #downcase

Rob Orsini’s got a nice little shell script for opening iTerm with everything he needs for his app: a vim window or two, a dev server, the Rails console, and a final tab to tail the development logs.

Of course, I’m a TextMate man myself, and so a bit of tweaking this morning brought out my own version of it. The first tab opens the project in Textmate and puts your shell into the project root, all ready for running tests and specs (unless you’ve already caught the autotest bug); the second tab fires up Mongrel on port 3000; the third fires up the console; the fourth tails development.log . The changes in filenames/commands are mainly my personal environment, so tweak away. Hardly warrants a blogpost, really, but thought I’d share, because it’s really going to be useful in future. Requires iTerm, TextMate, and the mate command (which should be set up by default when you install TextMate).

#!/bin/sh

if [[ $# == 0 ]]; then
  PROJECT_DIR=$PWD
elif [[ $# == 1 && -d "$1" ]]; then
  PROJECT_DIR="$@"
else
  print "usage: railsterm.sh [rails project directory]"
  return 1
fi
    
osascript <<-eof
  tell application "iTerm"

    make new terminal

    tell the last terminal

      activate current session

      launch session "Default Session"

      tell the last session
          set name to "$PROJECT_DIR"
          write text "cd \"$PROJECT_DIR\""
	      write text "mate .;"
          write text "clear; ls;"
      end tell
		
      launch session "Default Session"
      tell the last session
          set name to "server"
          write text "cd \"$PROJECT_DIR\""
          write text "mongrel_rails start"
      end tell

      launch session "Default Session"
      tell the last session
          set name to "console"
          write text "cd \"$PROJECT_DIR\""
          write text "./script/console"
      end tell

      launch session "Default Session"
      tell the last session
        set name to "development log"
        write text "cd \"$PROJECT_DIR\""
        write text "cd log"
        write text "tail -f development.log"
      end tell

    end tell
  end tell
eof

Don't forget to chmod +x the file if you want to make it executable.

So the CSS Redundnacy Checker has done a fair bit of traffic recently. Wow, etc. I hope it’s turning out to be useful. I’ve committed a few minor fixes, and there could be more improvements to come thanks to some useful feedback. I’ll be getting in touch with people about it over the next few days, I hope.

When I sat down to write the tool, I knew it would only be possible with a decent CSS parser (because you need a proper parser, and can’t do this with regex magic). The two that leaped to mind immediately were Hpricot and jQuery. In the end, I went with the former, because a commandline script seemed a good starting point, and something that could be built open in many ways.

In the comments thread, Tom at WorkingIdea alerted me to his jQuery-powered CSS Redundancy checker. It’s a Greasemonkey script with built-in jQuery that dumps redundant classes either to the Firebug console or to a Javascript console if you don’t have Firebug. Sounds like it might not be quite as fast as the Ruby one – or as flexible – but if you don’t have Ruby installed or just want to run something from your browser, it’s a great idea. And it’s the same principle as my script – harnessing somebody else’s CSS parser in a really simple way.

So now there are two ways into the same usefulness. It only seemed fair to link this up, given what a neat solution it is – and how close I came to doing it myself.

(Incidentally, the reason there’s not an online version of my script is because it is a slow process, and I’d have to write some kind of queueing solution on the frontend, and it could all get messy fast. It’s not for that. Get it yourself, run it locally; there are instructions on setting it up for people who don’t have Ruby in the README).

I’ve just had my first patch accepted on an open source project. Quite chuffed with that! As of this weekend, the Rails calendar_helper plugin is now at version 0.21. My changes are very minimal, and only really to do with the markup.

Firstly, the default table markup’s had an overhaul. The date now goes into a %lt;caption> tag, outside the <thead>, as is appropriate. The <th>‘s in the thead now have scope="col" applied to them, again, as is appropriate.

The only other change is optional. If you pass in an option of :accessible => true, any dates in the grid which fall outside the current month will have <span> class="hidden"> monthName</span> appended to them. It could be reasonably inferred that plain numbers are dates that relate to the caption of the table, but the numbers outside the current month should probably be clarified.

You can come up with your own method of hiding content marked as .hidden; at NPG, we use the following:

.hidden {
	position:absolute;
 	left:0px;
 	top:-500px;
 	width:1px;
 	height:1px;
 	overflow:hidden;
}

but really, use whatever you’re most comfortable with.

You can get the plugin from Geoffrey Grosenbach’s subversion:

http://topfunky.net/svn/plugins/calendar_helper/

via the usual Rails plugin installation method.

There comes a point in every developer’s life when your realise the problem isn’t your work, but the tools you’ve got to hand. Toolsmithery is an important part of the job, and so I spent a few hours yesterday crafting a tool useful to any front-end developer.

The result is the CSS Redundancy Checker.

When you’re writing HTML, over time, your CSS files begin to fill up a lot. If you’re working on a large project, you might even end up with several people contributing to the CSS file, not to mention refactoring each other’s work. The result is a directory full of HTML files, and a very large CSS file.

What tends to happen is that not ever selector in the CSS file actually applies to your HTML; many are rendered redundant by refactoring, or by changes in HTML. But when you’ve got a 70k+ CSS file, it’s not easy to check precisely which selectors aren’t in use any more.

Enter the CSS Redundancy Checker. It’s a very simple tool, really. You pass in a single css file, and either a directory of HTML files, or a .txt file listing URLs (one to a line). It then proceeds to look at each file in turn, and at the end, list all the selectors in your css file that aren’t used by any of the HTML files.

That’s it. I’m pretty sure it’s accurate, and it should work with most CSS files. Most of the magic isn’t down to me, but down to _why the lucky stiff‘s marvelous Hpricot HTML parser. The script itself is about 50 lines of reasonably tidy Ruby. You’ll need Ruby, and Hpricot, in order to run it. There’s more full documentation over at the Google Code site where I’m hosting it. Please add any issues there, or get in touch if you want to contribute.

Things it doesn’t do: listing line numbers of where the selectors are. I wrote that functionality on the train this morning, but I can’t find a way to make it 100% accurate, so thought it best to leave it out – inaccurate line numbers are of no use to anyone. If you can come up with a way that works, let me know. Also, at some point I might turn it into a Textmate command. All in good time, though.

The need for the tool came out of a large project we’re working on at NPG, but I felt it would be useful to pretty much any HTML developer. So I’ve released it to the world. Let me know what you think, and do spread the word. You can get it via svn checkout, for now:

svn checkout http://css-redundancy-checker.googlecode.com/svn/trunk/ css-redundancy-checker

As you probably know, when it comes to code (both in and out of work) I’m a Ruby and Rails guy. It’s not necessary to go into much detail “why”: the expressiveness of Ruby and the dynamism and speed of development in Rails are big wins for me.

But it’s not always possible – or practical – to knock out Rails applications for every task, and right now, I need to deploy something in PHP. Something very simple, that doesn’t warrant the deployment overheads of Rails (which we’re all aware of, right?)

Refusing to get caught up in WordPress if at all possible (not going into that again, either), I set out to look for a nice, well-documented, lightweight PHP web framework.

Oh dear.

As a Rubyist and Textmate user, you’ll probably be aware that def will tab-expand to stub out a method definition. You might also be aware that, for the purposes of Test::Unit, deft will tab-expand to a test method beginning def test_, allowing you to append the name of your test.

But that’s not much more help, because if we’re naming our tests properly, they’re probably going to have very_long_names, and hitting underscore all those times is a bit of a pain. So I rectified that, with this command (and it’s a command, rather than a snippet, because of all the processing it does). Pull up the commands dialog (Command-Opt-Control-C), create a new command in the Ruby bundle, and give it the following code:

#!/usr/bin/env ruby

name = STDIN.read.strip
testname = name.gsub(" ", "_").downcase
print <<OUTPUT
	def test_#{testname}
		\$0
	end
OUTPUT

The command’s Input should be “Selected Text” or “Line”; its Output should be “Insert as Snippet”. The scope should be set to source.ruby. And give it whatever key definition you want; I’ve got it on ctrl-opt-shift-t.

Usage is easy. On a new line in your test file, type the name of your test in plain English with no punctuation, eg:

get to index should list all items

and then hit your shortcut. You’ll get the following out:

def test_get_to_index_should_list_all_items

end

and your cursor will be slap bang in the middle of the test, indented, ready to write. That’s what I really want from a test definition snippet – something more than deft supplies. It’s another minute or two’s work to make it strip punctuation, so you can convert real sentences to test cases. I just decided to condition myself to save on coding on this morning’s commute.

(I wasted about half an hour on this last night, and am now kicking myself about how simple it was. Given that… definitely worth documenting the problem, so that no-one else gets held up on it.)

I’m currently working on some forum software (before you yawn: it’s not your average forum, it’s not worth the effort forking Beast, and besides, it’s a learning exercise). In this forum, when you create a topic, you also create the first post in the topic at the same time. Here’s how that happens (I don’t think I need to show the form view – the controller will suffice):

@topic = Topic.new params[:topic].merge(:user => current_user, 
                                :forum => Forum.find(params[:id]))

post = @topic.posts.build(params[:post].merge(:user => current_user))

Unfortunately, I was running into all sorts of problems – in that even though the forms were filled out and being passed to the controller, the topic wasn’t being created. This was because the post wasn’t validating. Turns out the problem was that in my post.rb, I’d said that a Post validates_presence_of :topic_id. This validation was clearly being run before the topic was created; given we’re using build to make sure the post is attached to the topic, I don’t think we need that validation. Once I stripped that out, everything worked fine.

A pretty trivial error, I know, but once my tests started failing, I had to take the application apart a little to find out what was going on. In a nutshell: I don’t think you always need to validate relationships that have to exist for the model to make any sense.

Of course, if there’s a way I can keep the validation of topic present but still build the topic/post combination as above… comments are very welcome.

I wrote my first proper Unit Tests in Ruby today. It felt good.

That probably sounds slightly gauche and hypocritical coming from a Rails developer. But remember – I’ve come from a front-end background; most of the time, other people make the tests; it’s up to me not to break them. I’m perfectly capable of editing tests to bring them in line with updated functionality; it just tends to have been the case that I’ve never really got my head around testing properly.

That changed recently, mainly thanks to Geoffrey Grosenbach’s excellent Peepcode screencasts. I’ve read a fair amount on testing up to now – Mark Pilgrim’s Dive Into Python is very good on the subject – but it was Geoffrey’s material that really clicked with me. (I’m watching his Capistrano one at the moment, and it’s certainly proving to be as good as the testing one).

I’ve always understood the point – and the utility – of test suites, but I’m pleased to have got my head around writing my own, starting with one (of several) projects on the back burner. Small steps at first, but it’s really satisfying to be working in a relatively test-driven manner.

And so I’ve been enjoying watching the dots fly by before those magic words come up: 0 errors, 0 failures. The Peepcode screencasts come strongly recommended, as well. Here’s to slightly more watertight code from now on.