Say Hello To My Little Friend

A great rant over at jbrains.info about Shotgun Programmers. These are the programmers who randomly shoot code at the compiler and hope it hits the problem they’re dealing with. Scary.

From the post:

As soon as something connects, whether or not it happens to actually be the pinata, you beat the hell out of it. Of course, you never take the blindfold off to see what you’re doing, so you end up with a bloody pulp of code.

Laziness

Chris is a developer after my own heart. He’s lazy, anal retentive and artistic. And those are complements!

I’ve always felt laziness was one of the keys to being a good software developer. At IIA I named a project that ran-a-muck through the engineering department. It was called “S.E.A.L.” which stood for “Software Engineers Are Lazy”. The initial project used XML and XSLT to generate code for communication protocols. It made it very easy for a message protocol to be defined in XML and C++, Java and Perl code to be auto-generated through XSLT. It made it _way_ easier to change protocols down the road. Before I knew it, the same technique was being used all over the place for everything from statistics definitions to stored procedure interfaces. Since my name was in most of the XSLT files, my name endedup in a truckload of generated code used at IIA, despite the fact that I wrote it only once. Now _that_ is lazy paying off.

Rails 1.1.5 on Debian

Apparently there is a giant security hole in Rails, which has been fixed. See here for further details on the issue.

For me the usual ‘gem install rails’ didn’t work right away on Debian.

I got an error that looked something like

I have no idea what this means, but on a whim I did an ‘apt-get upgrade’ and then did ‘gem install rails’. The second time everything worked fine.

Shuffle Kafuffle

I got me an iPod Shuffle about five months ago and up until early last week I was loving it. It is small, convenient, and makes yard work, commuting, and walking the dogs a little more interesting. However last Monday my shuffle decided to die on me. It started showing signs of the infamous orange and green flash of death problem. Basically, the shuffle wasn’t recognized by either my Mac or Windows machine and when I tried to play it, the front orange and green lights would flash. I scoured the internet and found much talk and many proposed solutions, but nothing seemed to work. All the help on the Apple site didn’t seem to help either.

At that point I started looking into geting the shuffle repaired or replaced. It has only been five months since I bought so I was hoping the exchange/repair would be free. There is no Apple store here in Calgary so I went online and started to make a service request. Unfortunately my shuffle’s serial number was not recognized, so at this point, a little frustrated I called up Apple’s support line and waited. Only a short time passed before an Apple rep came on the line and helped me properly register my shuffle (which apparently I had screwed up last time) and got me on my way. I then went back online and continued to schedule my service. Although the cost of the replacement did turn out to be $0, they still wanted my credit card (in order to charge me for my replacement if I didn’t send back my busted shuffle) but when the credit card submission timed out, I was back on the phone to Apple support. Again, just a short wait and another helpful Apple rep helped me out and my service was scheduled.

Long story short, 48 hours I had a new shuffle and my old dead one was back in the pre-paid package ready to be picked up for the return to Apple and the huge shuffle graveyard I’m sure they have somewhere. All in all, I was really happy with the whole replacement process. Mind you, I would have rather the shuffle not explode in the first place, but if it had to happen, I’m glad the replacement was as seamless as one can reasonably expect these days.

Editor’s Note: Kafuffle is one of those words I don’t think I’ve ever written down in the past, but I’ve used quite a bit in speech. Weird.

Summer Fun

Well, I’ve been slacking off in writing here for the last month or so. Between an Alaskan Cruise and visit from the nephews, this July has been extremely busy. Add to my increased frequency of posts to pliantalliance.org and you can see why July has been a non restful summer month. Let’s hope I get a bit more sleep in August.

lighttpd on Debian

There’s a slight issue with the init.d script for lighttpd on debian. If you try to reload or start the application, it doesn’t properly detach itself from the process. I discovered this when I stopped getting my web stats update email from logrotate. The reason was logrotate was never finishing because lighttpd was holding onto it.

Anyway, here’s the diff for /etc/init.d/lighttpd that fixes the problem.

Podcast Roundup

Ever since I got the shuffle I’ve been listening to a lot of podcasts. I monitor about 10 or so podcasts in iTunes for interesting episodes but there is a core group of casts that I always make a point to listen to. Here they are for your listening pleasure.

• Drunk and Retired - This was probably the first podcast I listened to and boy, what an introduction to this whole thing. Drunk and Retired covers a bunch of software development and technical topics, although the guys (Charles and Cote) have been known to get a little off topic (zombies, anyone?). Note to listeners, this one isn’t for the kiddies.
• Twit - Leo Laporte and gang talk about the latest tech news. Lots of good general technical info if you are into that sort of geeky stuff.
• Inside the Net - This one is also on the TWIT network and is hosted by Leo Laporte and Amber MacArthur. The content has more of a web bent to it and is less general news and more interviews with significant people in the industry. Amber is a maritimer too, so that’s cool.
• Plumbers@Work - This Calgary based podcast hosted by John Bristowe and his gang of .Net experts looks into current goings on in the software development industry. Although focused on .Net, the guys often talk about non .Net tech issues/news as well.
• Redmonk Radio - Another tech industry news podcast, hosted by Cote (of DrunkandRetired) and his colleagues at Redmonk, an industry analyst firm. Lots of good industry information but not stuffy and boring as one might expect.
• RubyonRails - Geoffrey Grossenbach interviews luminaries in the RubyOnRails community. Good insight into the cool stuff people are doing with Rails.

Caught in an Oily .Net

Once again I’ve switched employment situations. I’m back in the .Net world and surprise, surprise, back in the oil & gas industry. I’ll be working in downtown Calgary for the next 6 months (at least) at a major oil & gas product company. I’m back working with a large user group (not in the 100000s like AOL, but still more than 2) so that should be good. I’ve made it through the first two weeks and I’m still excited about the position which is different for me. We’ll see how it goes.

Capistrano and CVS

In the world of Rails, Capistrano is a great tool to automate deployments. I started using it several weeks ago and it makes rolling out new versions of your web app very easy. Installation was as easy as doing ‘gem install capistrano’ and then doing a ‘cap -A’ in my application directory.

The only glitch I came up against was that my production server doesn’t have remote access to my cvs repository. By default, Capistrano works with svn by remotely downloading the application from the repository to the production server. There is a cvs module for Capistrano, but it still requires the production server to have access to the cvs repo. I dug around a bit on the rails mailing list and found this post which not only clued me into the fact that any of the standard deploy targets can be overridden in my deploy.rb file, but also gave me the code to override the update_code task to do exactly what I wanted.

The following makes a local tarball of the application code, uploads the tarball to the production server and untars it into the release directory. The rest of the deployment is the same as normal. Works like a charm. Thanks to Jim Morris for the above posting. I tweaked the target for my own environment, but the credit mostly goes to him.

desc <<DESC
Update all servers with the latest release of the source code.
This is a modified version that copies a local copy to the remote site
DESC

task :update_code, :roles => [:app, :db, :web] do
    on_rollback { delete release_path, :recursive => true }

    # puts "doing my update_code"
    temp_dest="tmp_code"
    tar_file="#{application}_update.tar.gz"

    #puts "...get a local copy of the code into #{temp_dest} from local svn"
    # but this could also just be your local development folder
    system("mkdir #{temp_dest}")
    system("cd #{temp_dest} && cvs export -d #{temp_dest} -r HEAD #{application}
                && cd -")

    #puts "...tar the folder"
    # you could exclude files here that you don't want on your production server
    system("tar -C #{temp_dest}/* -c -z -f #{tar_file} .")

    #puts "...Sending tar file to remote server"
    put(File.read("#{tar_file}"), "#{tar_file}")

    #puts "...detar code on server"
    run <<-CMD
        mkdir -p #{release_path} &&
        tar -C #{release_path} -x -z -f #{tar_file} &&
        rm -rf #{tar_file} &&
        rm -rf #{release_path}/log #{release_path}/public/system &&
        ln -nfs #{shared_path}/log #{release_path}/log &&
        ln -nfs #{shared_path}/system #{release_path}/public/system
    CMD

    #puts "...cleanup"
    system("rm -rf #{temp_dest} #{tar_file}")
end

Lighttpd and Debian

Everyone knows that lighttpd is the popular choice for deploying rails applications. Although Apache can get the job done with mod_fastcgi, Apache+fastcgi seems somewhat unstable and prone to zombie processes and poor performance (at least in my experience). So when I finally needed my rails application to actually consistantly work, I decided to install lighttpd (apt-get from Debian testing). I chose the apache proxy approach so that I didn’t have to completely switch over for all my websites. Instructions here and here got me most of the way.

For reference, and your enterainment, here’s the apache proxy configuration. This took me a while to figure out and I was getting 502 Bad Gateway errors until I stumbled on the <Proxy> directive.

  ProxyPass / http://localhost:81/
  ProxyPassReverse / http://localhost:81/
  ProxyPreserveHost on
  <Proxy *>
     Order deny,allow
     Allow from all
  </Proxy>

Obviously this is only the proxy part of my vhost config and you’ll have to make sure you are forwarding to the correct port on your lightty server.

As for the lightty configuration, the above instructions worked great, except for one Debian specific thing. In the default lighttpd.conf there is this which can be used to access the Debian Policy Manual

$HTTP["host"] == "localhost" {
       global {
               alias.url += (
                       "/doc/" => "/usr/share/doc/",
                       "/images/" => "/usr/share/images/"
               )
       }
       dir-listing.activate = "enable"
}

Apparently, this sets up two global aliases for “doc” and “images”. And guess what, rails.png is not in /usr/share/images/. That is, your public/images directory in your rails app is not the /images directory that lightty is accessing with the above configuration in place. Comment out those lines and you should be good to go.