First Brisket Temp

We’re in our 8th hour and the brisket is sitting on 150. Hope we can get 40 more degrees in 8 more hours. She’s starting to look good though and definitely seems juicy.

Trouble In BBQ Land

Having trouble keeping the temps in the range I want tonight for some reason and I’m hoping that doesn’t spell trouble with a capital T for this poor brisket. Didn’t help that I fell asleep for a little while only to wake up and find the temps down around 160.

Back up to 253 at this point and we’ll see how the next couple of hours go. I have the feeling this may be one of those nights that ends up with a brisket finishing in the oven.

Virtual Brisket

Now there’s a man after my own heart. I love seeing what other people do with their brisket. I’d never to so such lengths but it’s pretty cool.

First Turn

Turned the brisket at 9:30, about 15 minutes late but I was on the phone with my parents. Didn’t get the mop started until just now so it will be another 30 minutes before I get it mopped. Also had a little episode where my timer wasn’t on and the temp got up to 318 but it’s back down to 240 and reasonably steady at this point.

BBQ isn’t difficult but it does take patience and a little bit of foresight to make it work correctly. Brisket is the hardest meat I think to smoke and I’m hoping this one is a little forgiving of my lack of attention. Next turn will be at 10:30 so we’ll see then.

So It Begins

The brisket is room temperature and happily rubbed down with secret stuff. The coals are hot. The smoker is 219 degrees moving towards 235. The hickory chunks are prepared. It’s time to start smoking. 14 pound brisket, 8 PM start time, so that baby should be done tomorrow morning around 10:30 or so. Then the Violated Chicken goes on.

Now the question is, do I work on something interesting or drink beer? Hmmm. . .

Windows 7

So will Vista be the 21st century’s Windows ME now that Windows 7 is looming?

TDD With Python and Pylons

I’ve been doing some development on a website using Python and the Pylons web framework. I’m trying to stay pretty strict with Test Driven Development (TDD) though I run into problems because I’m still a complete novice with Pylons and a half-complete novice with Python. In my experience so far, unit tests are moderately difficult in Pylons and turn out to be something closer to the bastard stepchild of a redneck unit test and a 5th Avenue socialite mom. I feel that way because the unit tests require the Pylons framework to be set up correctly. They also often go outside their boundaries and I haven’t looked into any mock frameworks, though I have the feeling that using a mock framework with a dynamic language like Python is probably a stupid thing to say in public.

Regardless, I have really started to enjoy working with Pylons and that stems from the actual functional tests that are available through the framework. Specifically, my development flow has been something like this:

  • Write new functional test of the web site
  • Run tests to see them error out. Typical error message is that an action isn’t implemented on the controller.
  • Implement the basic controller and the action but leave out the functionality under test.
  • Rerun the test to see it fail.
  • Implement the functionality necessary to get a passing test. This often includes implementing database tables, keys, getting SqlAlchemy set up to correctly map data to objects and creating new templates for HTML.

The functional tests are nice because while they aren’t confirming look and feel type stuff, they at least put the flow of the application under test. I’m a purist when it comes to having unit tests only test the code they are intended for but I’m not a purist when it comes to writing unit tests first as the only way to design the application. With a website like this, I’m pretty happy writing functional tests to drive out the design of the web site.

Here are some code snippets from my current website (try to ignore the fact that this looks like it might have something to do with horses and the Kentucky Derby, especially if you work for the NSA.)

First a test:

Here we have a test that tests the response from a request for a URL that is handled by the controller “horse”. This controller grabs all the horses in the database and displays them in a table. The test saves a temp horse, gets the list, verifies the list contains at least 1 horse and then deletes the temp horse to clean up after itself.

Here’s the controller code that allows the test to pass:

One of the beauties of Pylons is how little code is required to do something, once the project is set up. Here our HorseController has an action of “index” which is defined as a method. It grabs all the horses from the database and then uses a list comprehension to collect them into the c.horses variable. It then renders the template “horses.mako” which knows how to layout the web page using the horses found in the database.

Once this was done, I wrote code to save a horse, all driven out by the functional tests. I’ve been pretty happy with how the design is driven from these tests as it’s often quite clear where to proceed next in the application from the last test. Lots of times, other functionality comes up that doesn’t logically flow next but I just add that to a growing todo list in the project to make sure nothing is skipped.

Pylons takes a little getting used to, especially since I come from a static, everything in once solution sort of background. With Pylons, you need to learn Routes and Mako and SqlAlchemy but once you get your head around all those tools, it’s a joy to work with.

UPDATE: Welcome to everyone coming here from the Python subreddit. If you have any tips for testing using Pylons, feel free to drop me a comment. I’d love to hear about other people’s experiences.

Too Many Functions

Don’t worry about too many functions, worry that your code sucks.


The more programmers I work with and the more code I read, the more I realize that everyone has their own unwritten style guidelines in their head for writing code. Some people are more self-consistent than others in their implementation of their style guidelines but it seems that most people at least have some semblance of coding guidelines that they follow. This is expected behavior as programmers come from different backgrounds and experience levels. In and of itself, this isn’t a big problem.

Unfortunately, it becomes a big problem when you form teams of programmers because just like an essay written by multiple authors, it becomes difficult to get past the style issues of multiple programmers in the same codebase. A team should write code that is self-consistent across the team. This provides several benefits, among them a greater understanding of a common codebase, easier pair programming and code reviews, and less frustration for current and future maintainers of the codebase. When you form teams with no guidelines for coding style, you get a mishmash of sytles that becomes increasingly frustrating for everyone involved. If you have to maintain a large codebase written by a team without coding standards, you’ll quickly grow tired of trying to remember whether programmer A liked to prefix or suffix TextBox on all his text boxes or if in this class the private variables have underscores or not.

Coding standards are one of the skeletons in the closet for software developers. Most developers scoff at implementing them, chafing at the concept of having to bend their style to a common one. That’s too bad because it’s a big drag on productivity on teams larger than 1. Look, I love regions as much as the next guy but that doesn’t mean I can’t easily alter my “style” to avoid regions in the code I write for the benefit of consistency. It’s a joy to read a codebase that is self-consistent whether it was written by 1 developer or 50 because you don’t have to spend any cycles trying to remember what an underscore means or expanding regions in one class but not in another or searching for private fields at the top of a class or at the bottom or wherever the developer felt like declaring them.

For consulting companies, I’d think it would be a competitive advantage to have coding standards defined for the organization. When hired by clients that didn’t have their own standards, a common standard for consultants would result in teams that were more productive as well as clients that were happier in the maintenance of the codebase. On top of that, if different consultants from the same company eventually came out for a followup, they could come up to speed more quickly because the codebase would be organized in a consistent manner. A final benefit would be from a sales perspective. Being able to say that all code on all projects written by a company was consistent to the same style regardless of which consultants participated would show prospective clients that all consultants with the company operated as if on the same team and valued a common set of standards.

Emerson wrote “A foolish consistency is the hobgoblin of little minds” and he was certainly right. Consistency in coding standards isn’t foolish though and adds plenty of happy side effects to teams that write from the same standards. It’s a shame more developers and companies don’t understand this.

No More TV For You, Old Person