An Experiment in Scotch

"I write to discover what I believe." Michael Lopp on Twitter

Month: October 2008 (page 2 of 4)

First Brisket Temp

We’re in our 8th hour and the brisket is sit­ting on 150. Hope we can get 40 more degrees in 8 more hours. She’s start­ing to look good though and def­i­nitely seems juicy.

BBQ Land">Trouble In BBQ Land

Hav­ing trou­ble keep­ing the temps in the range I want tonight for some rea­son and I’m hop­ing that doesn’t spell trou­ble with a cap­i­tal T for this poor brisket. Didn’t help that I fell asleep for a lit­tle 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 cou­ple of hours go. I have the feel­ing this may be one of those nights that ends up with a brisket fin­ish­ing in the oven.

Virtual Brisket

Now there’s a man after my own heart. I love see­ing what other peo­ple 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 min­utes late but I was on the phone with my par­ents. Didn’t get the mop started until just now so it will be another 30 min­utes before I get it mopped. Also had a lit­tle episode where my timer wasn’t on and the temp got up to 318 but it’s back down to 240 and rea­son­ably steady at this point.

BBQ isn’t dif­fi­cult but it does take patience and a lit­tle bit of fore­sight to make it work cor­rectly. Brisket is the hard­est meat I think to smoke and I’m hop­ing this one is a lit­tle for­giv­ing of my lack of atten­tion. Next turn will be at 10:30 so we’ll see then.

So It Begins

The brisket is room tem­per­a­ture and hap­pily rubbed down with secret stuff. The coals are hot. The smoker is 219 degrees mov­ing towards 235. The hick­ory chunks are pre­pared. It’s time to start smok­ing. 14 pound brisket, 8 PM start time, so that baby should be done tomor­row morn­ing around 10:30 or so. Then the Vio­lated Chicken goes on.

Now the ques­tion is, do I work on some­thing inter­est­ing or drink beer? Hmmm…

Windows 7

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

TDD With Python and Pylons">TDD With Python and Pylons

I’ve been doing some devel­op­ment on a web­site using Python and the Pylons web frame­work. I’m try­ing to stay pretty strict with Test Dri­ven Devel­op­ment (TDD) though I run into prob­lems because I’m still a com­plete novice with Pylons and a half-complete novice with Python. In my expe­ri­ence so far, unit tests are mod­er­ately dif­fi­cult in Pylons and turn out to be some­thing closer to the bas­tard stepchild of a red­neck unit test and a 5th Avenue socialite mom. I feel that way because the unit tests require the Pylons frame­work to be set up cor­rectly. They also often go out­side their bound­aries and I haven’t looked into any mock frame­works, though I have the feel­ing that using a mock frame­work with a dynamic lan­guage like Python is prob­a­bly a stu­pid thing to say in public.

Regard­less, I have really started to enjoy work­ing with Pylons and that stems from the actual func­tional tests that are avail­able through the frame­work. Specif­i­cally, my devel­op­ment flow has been some­thing like this:

  • Write new func­tional test of the web site
  • Run tests to see them error out. Typ­i­cal error mes­sage is that an action isn’t imple­mented on the controller.
  • Imple­ment the basic con­troller and the action but leave out the func­tion­al­ity under test.
  • Rerun the test to see it fail.
  • Imple­ment the func­tion­al­ity nec­es­sary to get a pass­ing test. This often includes imple­ment­ing data­base tables, keys, get­ting SqlAlchemy set up to cor­rectly map data to objects and cre­at­ing new tem­plates for HTML.

The func­tional tests are nice because while they aren’t con­firm­ing look and feel type stuff, they at least put the flow of the appli­ca­tion under test. I’m a purist when it comes to hav­ing unit tests only test the code they are intended for but I’m not a purist when it comes to writ­ing unit tests first as the only way to design the appli­ca­tion. With a web­site like this, I’m pretty happy writ­ing func­tional tests to drive out the design of the web site.

Here are some code snip­pets from my cur­rent web­site (try to ignore the fact that this looks like it might have some­thing to do with horses and the Ken­tucky Derby, espe­cially if you work for the NSA.)

First a test:

from darlydowns.tests import *
from darlydowns.model import meta
from darlydowns.model import horse

class TestHorseController(TestController):
    def test_index(self):
        # setting up a temp horse to make sure one exists for the test
        tempHorse = horse.Horse('my temp', 'my description')
        response ='horse'))
        ## Test response...
        assert len(response.c.horses) > 0


Here we have a test that tests the response from a request for a URL that is han­dled by the con­troller “horse”. This con­troller grabs all the horses in the data­base and dis­plays them in a table. The test saves a temp horse, gets the list, ver­i­fies the list con­tains at least 1 horse and then deletes the temp horse to clean up after itself.

Here’s the con­troller code that allows the test to pass:

import logging

from darlydowns.model import meta
from darlydowns.lib.base import *
from darlydowns.model import horse
from import Horse

log = logging.getLogger(__name__)

class HorseController(BaseController):

    def index(self):
        c.horses = [horse for horse in meta.Session.query(Horse).all()]
        return render('/horses.mako')

One of the beau­ties of Pylons is how lit­tle code is required to do some­thing, once the project is set up. Here our HorseC­on­troller has an action of “index” which is defined as a method. It grabs all the horses from the data­base and then uses a list com­pre­hen­sion to col­lect them into the c.horses vari­able. It then ren­ders the tem­plate “horses.mako” which knows how to lay­out the web page using the horses found in the database.

Once this was done, I wrote code to save a horse, all dri­ven out by the func­tional tests. I’ve been pretty happy with how the design is dri­ven from these tests as it’s often quite clear where to pro­ceed next in the appli­ca­tion from the last test. Lots of times, other func­tion­al­ity comes up that doesn’t log­i­cally flow next but I just add that to a grow­ing todo list in the project to make sure noth­ing is skipped.

Pylons takes a lit­tle get­ting used to, espe­cially since I come from a sta­tic, every­thing in once solu­tion sort of back­ground. 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: Wel­come to every­one com­ing here from the Python sub­red­dit. If you have any tips for test­ing using Pylons, feel free to drop me a com­ment. I’d love to hear about other people’s experiences.

Too Many Functions

Don’t worry about too many func­tions, worry that your code sucks.


The more pro­gram­mers I work with and the more code I read, the more I real­ize that every­one has their own unwrit­ten style guide­lines in their head for writ­ing code. Some peo­ple are more self-consistent than oth­ers in their imple­men­ta­tion of their style guide­lines but it seems that most peo­ple at least have some sem­blance of cod­ing guide­lines that they fol­low. This is expected behav­ior as pro­gram­mers come from dif­fer­ent back­grounds and expe­ri­ence lev­els. In and of itself, this isn’t a big problem.

Unfor­tu­nately, it becomes a big prob­lem when you form teams of pro­gram­mers because just like an essay writ­ten by mul­ti­ple authors, it becomes dif­fi­cult to get past the style issues of mul­ti­ple pro­gram­mers in the same code­base. A team should write code that is self-consistent across the team. This pro­vides sev­eral ben­e­fits, among them a greater under­stand­ing of a com­mon code­base, eas­ier pair pro­gram­ming and code reviews, and less frus­tra­tion for cur­rent and future main­tain­ers of the code­base. When you form teams with no guide­lines for cod­ing style, you get a mish­mash of sytles that becomes increas­ingly frus­trat­ing for every­one involved. If you have to main­tain a large code­base writ­ten by a team with­out cod­ing stan­dards, you’ll quickly grow tired of try­ing to remem­ber whether pro­gram­mer A liked to pre­fix or suf­fix TextBox on all his text boxes or if in this class the pri­vate vari­ables have under­scores or not.

Cod­ing stan­dards are one of the skele­tons in the closet for soft­ware devel­op­ers. Most devel­op­ers scoff at imple­ment­ing them, chaf­ing at the con­cept of hav­ing to bend their style to a com­mon one. That’s too bad because it’s a big drag on pro­duc­tiv­ity on teams larger than 1. Look, I love regions as much as the next guy but that doesn’t mean I can’t eas­ily alter my “style” to avoid regions in the code I write for the ben­e­fit of con­sis­tency. It’s a joy to read a code­base that is self-consistent whether it was writ­ten by 1 devel­oper or 50 because you don’t have to spend any cycles try­ing to remem­ber what an under­score means or expand­ing regions in one class but not in another or search­ing for pri­vate fields at the top of a class or at the bot­tom or wher­ever the devel­oper felt like declar­ing them.

For con­sult­ing com­pa­nies, I’d think it would be a com­pet­i­tive advan­tage to have cod­ing stan­dards defined for the orga­ni­za­tion. When hired by clients that didn’t have their own stan­dards, a com­mon stan­dard for con­sul­tants would result in teams that were more pro­duc­tive as well as clients that were hap­pier in the main­te­nance of the code­base. On top of that, if dif­fer­ent con­sul­tants from the same com­pany even­tu­ally came out for a fol­lowup, they could come up to speed more quickly because the code­base would be orga­nized in a con­sis­tent man­ner. A final ben­e­fit would be from a sales per­spec­tive. Being able to say that all code on all projects writ­ten by a com­pany was con­sis­tent to the same style regard­less of which con­sul­tants par­tic­i­pated would show prospec­tive clients that all con­sul­tants with the com­pany oper­ated as if on the same team and val­ued a com­mon set of standards.

Emer­son wrote “A fool­ish con­sis­tency is the hob­gob­lin of lit­tle minds” and he was cer­tainly right. Con­sis­tency in cod­ing stan­dards isn’t fool­ish though and adds plenty of happy side effects to teams that write from the same stan­dards. It’s a shame more devel­op­ers and com­pa­nies don’t under­stand this.

TV For You, Old Person">No More TV For You, Old Person


Older posts Newer posts