When you are learning how to program, you think that most of your time is going to be spent writing code. The reality is most of your coding time is actually spent reading code. Other people’s code. Code with comments that lie. Code with bizarre short cuts. Code whose original authors are long gone or unresponsive.
And that’s the real skill of a good programmer, the ability to read this kind of code, and make sense of it. Maybe even make it a little better as you come across it.
After nearly a month of tinkering with code, nearly giving up twice, and realizing that I was going to actually need to relearn my linear algebra to get a real solution, I managed to create this graph. It is the position of the moons of Jupiter relative to the planet as seen from earth.
Thanks to Thor for helping me get to the realization that straight up geometry wasn’t going to be good enough, and help boot strap my relearning of vector math. Once I started using real linear algebra I didn’t even have to cheat on generating the sign. Next step… JNI.
We’re 1 step closer to the launch of the new Poughkeepsie Farm Project website, so it’s down to some final edits before it gets flipped live. While I was looking over the test site the other day, I realized we still had some links, and images that referred to the existing site, which would break once we did the final domain switcheroo.
I came up with the following snippet of jquery to highlight bad links and images client side so that editors would realize they needed to do something about them:
So every time we find a link or image that starts with an absolute url to one of the addresses the site has had inside the content block, we highlight it. This has been incredibly effective so far in catching some things I didn’t even realize was an issue. This with the combo of drupal’s broken link detector internally is helping us ensure the content is consistent prior to launch.
For the npr shows that don’t podcast, I use icecream to save them off for my own time shifting. The files end up with names like “car_talk_2008_01_17.mp3″. Until recently, that was good enough, but the new Sandisk players that both my wife and I have only function on tags, not on filenames. Last night I wrote this small ruby script to fix that:
require "date"
require "rubygems"
require "mp3info"
ARGV.each do |file|
title, datestr = file.scan(/(\w+)_(\d+_\d+_\d+).mp3/)[0]
if title and datestr
date = DateTime.parse(datestr.gsub!(/_/,"-"))
title.gsub!(/_/, " ")
title = title.split.map {|a| a.capitalize}.join(" ")
puts date
puts title
Mp3Info.open(file) do |mp3|
if not mp3.tag.album == "#{title} #{date.strftime("%Y")}"
mp3.tag.album = "#{title} #{date.strftime("%Y")}"
mp3.tag.artist = "WAMC Recordings"
mp3.tag.title = date.strftime("%Y %m %d – #{title}")
end
end
end
end
What’s going on should be pretty clear, but I’ll highlight a few things. First we are iterating over ARGV, so this takes a list of files on the command line. DateTime has a parser, which is actually pretty good. Anything that looks like a standard date can be converted back to one.
Ruby methods always return object instances, which let you do things like
where you split on white space, capitalize the components in the array, and join it back into a string.
And to wrap it all up, we’ve got a great Mp3Info library as a gem. Wondering where the save call is? Well that’s one of the wonderful things about ruby do blocks, the save is implicit when we end the block as mp3 goes out of scope. No need to make sure you clean up those resources or sync manually, because by doing the action in the do block all the setup / teardown is handled by the system. I used to be confused about do blocks, now I love them for this very reason.