Jake Scruggs

I moved to the newest version of Ubuntu over the weekend: Feisty Fawn. I was having troubles getting my wireless working (Intel PRO/Wireless 3945) and I had heard it works in Feisty. The upgrade, um, took out my system. Yep. Everything was chugging along just fine until it tried to upgrade Tomcat and then I got a cryptic error message saying the update had failed and I should email them. No real indication of what to do next. So I tried to get the upgrade running again, but I'm not savvy enough with the Linux. Tried to restart the machine... Big mistake. Not so much with the booting. So I had to wipe that partition and reinstall. I didn't lose anything except time.

Then today when I was setting up my machine I couldn't get Tomcat5.5 to work (we use SOLR which uses Tomcat behind the scenes for fast searching). Lost more time trying to figure out what was wrong. Finally I thought maybe Aptitude's version was bad, so I removed it and got Tomcat straight from Apache. Everything works fine now. So if you're moving from Edgy to Feisty, maybe should remove Tomcat from the package management before upgrading.

Good news is that my wireless works now. Long way to go, however.

When you first start a project and you set up bug tracking software there tends to be 3 levels of bugs: Low, Medium, and High. After awhile you might notice there are now ‘critical’ bugs. Come back a little while later and there’ll be a ‘showstopper’ or ‘blocker’ bug level. And the funny thing is, most of the bugs will be logged at the highest levels. Literally 50% of bugs are given such a status as to make you think the app is in shambles. Except that when you actually open up qny of them to see what could possibly be so horrible, you find things like: missing fields, pages that should be pop-ups, and misspelled text. How is it that these things are given the highest level of importance?

Today, while I was working on a super ultra critical showstopper bug, I had some time to reflect on this phenomena. The bug was this: One of our models was missing a field. And the business wanted this field to be entered before the user could perform some task. Now, I should point out that nothing in the app was giving an error message, except that the user could get away without entering a field that had no functionality except to be displayed on the screen later. In my humble opinion, the app could have gone live without fixing this bug and nothing terrible would have happened.

But, you might say, it’s not my call to decide that. Absolutely right. But it’s also true that sitting next to it, at the same level of priority, were bugs that really were super ultra critical (such as the temporary inability to edit anything at all in our content management system – yipes!). So how do we let the business decide what gets done first but also have a rational system of ranking bugs? Well you need to have ranking system that actually means something. If high isn’t defined then everything gets rated as ‘high’ (especially cause manager X is gonna freak if it doesn’t get fixed – and every bug has a manager X) so we create ‘critical’ and then everyone calls things critical, and this continues until you have a very long list of bug ratings (and only the top two will ever get used). On a previous project we had the same problem and so moved to this rating system:

• Priority 1: The app is down. No part of the app runs at all.
• Priority 2: A large part of the app is not functional, but some parts still work.
  
• Priority 3: An important function does not work, but there is a workaround.
  
• Priority 4: Satellite functionality does not work.
  
• Priority 5: Cosmetic change.

This worked pretty well: important things got fixed and if the client wanted to get something moved up in priority it could always be played as a card (like while technically misspelling the name of the application is a cosmetic change and therefore priority 5, but still…)

Snow turned to freezing rain which turned to rain and then, just to mess with me and my 30 minute walk, tiny hail. The hail hurt my face. That'll teach me to brag about my commute.

So in a previous post I complained about not being able to mock/stub a partial from within a partial, but with Peter Ryan and Mike Ward's help we got it all figured out.
Normally in your test(spec) you call a partial like this:

  
  render :partial => 'partial_name',
    locals => {:page_variable => mock_page_variable }

But if you want to intercept all or some calls to render with partial, them you can't do that. But what you can do is call a partial like so:

  
  render '_partial_name'

If you need some locals you can stub them out like so:

  
  @controller.template.stub!(:page_variable).
    and_return(mock_page_variable)
  render '_partial_name'

So if I wanted to stub out all calls to render, and assert that the string "Blargh" appears on the page, it would look a little something like this:

  
  @controller.template.stub!(:render)
  @controller.template.stub!(:page_variable).
    and_return(mock_page_variable)
  render '_partial_name'

  response.body.should include("Blargh")

Now why does that work while "render :partial =>..." does not? I, uh, really don't know. Ideas?