Transcending Frontiers

I wanted to integrate some branding functionality into an application we’re developing and so I needed test file upload functionality. We’re using Webrat for integration tests, though this will likely change as we increase the amount of Javascript in the app. I added Paperclip to handle the file attachments for logos, and everything was working.

When I added validation to the model, making sure that the file being attached was an image, this broke the tests. It didn’t seem to matter what type the file was, it would fail no matter what on the file type validation.

I used ruby-debug to debug my test and it seems by default Webrat sends file uploads as plain text. It does have the option to specify the file type when attaching the file, so the easiest way around this is just to specify the MIME type for the file. Now my Cucumber step looks something like this :

When /^I attach "([^\"]*)" image to the "([^\"]*)" file field$/ do |filename, field|
  type = filename.split(".")[1]

  if type == "jpg"
    type = "image/jpeg"
  end

  attach_file field, File.join(RAILS_ROOT, test_asset_path, filename), type
end

Obviously this will need some work as I progress, but it works. At this stage I have an assets folder in my features folder to store any files that I need for my tests.

On the confirmation end of the test I just have a simple tag test to check that the image tag is displaying, and it contains the correct src attribute :

Then /^I should see tag "(.+)"$/ do |selector|
  (Hpricot(response.body)/selector).should_not be_empty
end

So in my feature test I have :

Then I should see tag "img[@src*='']"

This just confirms that there is an image tag that contains the file name of the file that I uploaded in the test.

There is a scheduled network outage planned for this Sunday which will affect all customers:

Outage Details
Sunday 24th May 2009

Outage Window
7:00am – 11:00am

Actual Outage
7:30am – 8:00am

Ward Cunningham has been a contributor to a number of ideas that are used every day by developers and users alike. Besides developing the first ever Wiki, he is also a proponent of Extreme Programming and has contributed to the use and understanding of patterns in OOP.

I ran across a YouTube video he did, explaining the costs and benefits of proper software development practices, using debt as a metaphor. He said he developed this when he was trying to explain the business value of certain practices of good development to someone in the finance realm.

I’m summarizing some of what he said, and I’d recommend you watch the video.

Borrowing Money
Borrowing money allows you to do something right now, but you’ll be paying interest on this in the future. If you continue to borrow then eventually you’ll end up using all of your revenue to pay interest.

Revenue is essentially your development time, it’s a somewhat fixed resource. Debt is what is built up between an optimal implementation against a sub-optimal implementation. Payments are the time you take to refactor the code afterward. Interest is the time difference it takes between the easiest way to add a feature and the way you have to go about adding a feature.

You can continue to borrow to cover interest but at some point then you either increase developer time (more people) or you spend all your time bug fixing and patching rather than adding features. It’s fine to push out parts of the project that are sub-optimal, as long as you go back and improve these later. If you don’t then you end up making your system harder and harder to add features to and so you are paying all of your revenue into paying off your debt.

The idea is that you can put out software that is the best solution you have at the time, as long as you go back and repay the difference between the best solution and the solution you have implemented at a later date. If you continue to add these ‘best at the time’ solutions without using the knowledge you gain along the way to fix the old solutions you implemented, then the system as a whole becomes poorer and poorer in quality. I guess to use an old saying, “A stitch in time saves nine”.

He further explains that he doesn’t think you should build debt through poor code or design. What he means by borrowing is to implement with your best understanding at the time, and then to go back and revisit your design once you have a better understanding of the system. You should always be implementing in a way that documents what it was that you were trying to achieve, it could simply be that what you needed to achieve is different or changes over time.

Smashing Magazine recently published a great article on choosing a domain name for your site, product or company. It’s a problem that many of our customers face, so if you’re in the market for a new domain, or are interested in how your domain stacks up against their recommendations, be sure to check it out.

Programming isn’t a science, it’s more of a craft to me. A craft implies a combination of some creativity and some practicality. You can make a wardrobe that does the job, or you can get a craftsman to do the job and you’ll end up with something that is not only functional, but great to look at. Craftsmen build the furniture you buy from antique stores.

Software can certainly be the same. Software can work, or it can work well. It can be inspiring and fun to work on, or it can be terrible and boring. It generally comes down to the skill and work ethic of the person that is writing it in the first place. I want to build an antique, not an $11 chair from Ikea.

Corey Haines has been doing a series of videos about all matters software related, but he seems to be mainly passionate about Pair Programming. I like how he sometimes delves into the psychology of people in an industry that is populated by so many with unusual profiles.

He operates a blog called On Being a Journeyman Software Craftsman and it contains a bunch of videos and short blurbs about things he’s learned while on his trip. I’d check it out and you might learn a bit about some of the cooler ideas out there in the software world.