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 Apa...

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 ...

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_n...