Cool URLs don’t change… until your hosting provider says so

February 22nd, 2024

They say cool URLs don’t change, but a lot of the time you don’t get a choice. Google decided that http wasn’t good enough, so bluehost (my hosting provider for this blog) switched me over to https automatically. Then I got to have the fun mixed content warning on an older post that had an embedded image in it. At least they put in redirects.

Now my old university hosting has decided to close off AFS access to alumni. So what? Well, personal web pages are served from AFS, which means the small handful of things I have over there will start 404ing, without even the opportunity to put a 301 redirect on them. (I just noticed that they have changed the URL there too, but with redirects. So now there are two URLs that will go dead when they throw the switch.)

Sorry w3c. Cool URLs might not change, but my providers require me to be cringe.

(Not that anyone links to a basically dead blog anyway, but I was trying to be a good web citizen.)

Full Size Kata Project

October 16th, 2010

So I’m sitting here at SCNA, and it’s great to talk about improving our craftsmanship, but what are we doing about it? And I’m very struck by what Keavy says about artists having a culture of critical review, which we totally don’t have. So I talk to Max, and I say, “We’ve got all the right people in the room, but we’re not pushing the state of the art forward!” And I whine about the state of programming education, and how we don’t have the culture of critique, and all that, and he says, “We need a fully worked example that we can all stand behind, like a Kata, but for a full size problem.”

So, that’s what we’re going to do. Thirty days of development, with review and commentary on the code at each step, hopefully tracking real changes to requirements and being a full sized app. We want reviews of the code at each step, and as much feedback as we can get. Once we get the thing “complete”, We should build a finished “episode” with code, commentary, and reviews. Ultimately, We’d like something that someone can read and get a good example of how software craftsmen work and do a full sized project.

We have a twitter hashtag: #fullsizekata

Questions: What is the best way to foster consensus on each iteration?

Pillar Technology

February 8th, 2010

So, my search is over, as I’ve accepted a position with Pillar Technology. I’ll be doing agile development, agile coaching, and writing code.

Seeking Employment, Again

January 12th, 2010

Well, good things never last, do they?

We had a layoff at my work; I was one of the IT people who got cut. The usual reasons… Money is tight, etc.

If anyone knows of an opening for a programmer in western Michigan, please let me know. I’ve linked my resume on the sidebar.

Why does layout change in IE when UL is alone in a TD vs having an extra empty DIV?

July 31st, 2009

I’m trying to find an answer to my layout question — I posted it to stack overflow:Why does layout change in IE when UL is alone in a TD vs having an extra empty DIV?. I’m posting it here as well, so I can upload a screenshot.

Update: There is now an answer on the stackoverflow question; One of the css rules makes the li tag white — it doesn’t have to, because the a is white. IE takes the spaces between the lis, and puts them in the enclusing td. This pushes the li down, causing it to overlap the border line.


I’m adding css-based tab navigation to a site that is still using table-based layout. When I place my tab list inside a td, there is a visual “gap” that you can see. If I put an empty div with “width: 100%” in the td, then my tab list displays correctly. (It also works fine outside the table.)Why does the div make the tabs lay out correctly, and is there a better way to make them do so without adding a content-free div?Here’s my test case: Test Case: Why does layout change in IE when UL is alone in a TD vs having an extra empty DIV?And a Screen Shot:

Screen shot of the error in IE 7

CAN HAS LOLCODE?

May 23rd, 2008

I know I haven’t posted in a while. I’ve transfered departments at work and getting my feet back under me has taken up a bunch of my free-ish time.

I promise real posts soon. In the mean time, amuse yourself with LOLCODE — the programming language of the future.

YAGNI Football Analogy

May 6th, 2008

There’s been some scuttlebutt recently on the extreme programming mailing list about the value of YAGNI — You Aren’t Going to Need It. Apparently, some people have been interpreting it as “Don’t think about the future.” It’s supposed to be “Don’t build things today that you don’t need today.”

If you know that someday, down the road, you may have to support multiple platforms, It’s entirely reasonable to choose OpenGL over Direct3D — OpenGL will run on Windows, Macs, and X platforms, where Direct3D will only run on Windows.

Contrariwise, if you’re only releasing on Windows this version, there’s no reason to build that classic hierarchy of GenericWindowInterface—->MSWindowsInterface today. You Aren’t Going to Need it. When we do a Mac build, then we’ll add that.

Anyway, here’s my replacement analogy for YAGNI: We only need ten yards. (For those not familiar with American football, the team gets four chances to move the ball ten yards. When you have moved the ball ten yards, this process resets, and you get another four chances to move the ball ten yards. Eventually, you’ll make it over the goal line and score points, but that’s later; This play is to get ten yards. A yard is just slightly shorter than a meter.)

So when someone says, “We need to add extensibility hooks here in case we want to offer plugins later,” you can reply, “We only need ten yards.”

Redefining Test Terminology

April 27th, 2008

So, earlier I mentioned Mock Objects — The TDD variant that requires isolation of the tested component. The Mock Objects technique requires a hierarchy of tests:

  1. At the lowest level, objects are tested in isolation against mocks.
  2. Higher up, objects are tested in collaboration with a few other real objects.
  3. Higher up, the entire system is tested.
  4. At the top level, test define if the system is complete.

That’s a good hierarchy. My only problem is with the names that they use.

Mock Object developers use these names:

  1. Unit
  2. Integration
  3. System
  4. Acceptance

Long before that, I head people use these names:

  1. “Why are you testing at such a low level? Don’t waste your time.”
  2. Unit
  3. “We probably ought to run the whole thing on some sample data.”
  4. Acceptance

On top of which, there are two other things called “Integration Tests”, which long predate Mock Objects:

QA Integration Tests: We’ve upgraded to the latest version of of GUI library. Let’s run some integration tests to make sure nothing broke. (Usually a full regression sweep.)

(Pre-Agile) Developer Integration Tests: We’re merging three new feature branches on Tuesday. We’d better do some testing to make sure they integrate properly.

At this stage of the game, it’s just not a good idea to re-use existing terms for different things. Especially when telling the difference between those things requires you to read the mind of the speaker.

Families of Test Driven Development

April 24th, 2008

So I’ve been looking in at Test Driven Development more lately, and I’m trying to separate the several things that call themselves TDD. Here’s what I’ve got so far:

Classic TDD: as described in Kent Beck’s Test Driven Development by Example, this technique tests and writes code a a very low level. No line of code is written without a failing test. Design comes from refactoring to remove duplication.

Mock Objects: Steve Freeman and co. promote this version of TDD. Its distinguishing feature is a requirement for near-complete isolation of objects under test. Design happens during the writing of the test when new collaborators are discovered.

The Un-named TDD: Maybe we should call it “Test-First”. Medium size tests are written, often close to the level of a use case or scenario. Corner cases are usually not tested. (Disk is full, so you can’t write the file, etc…) Just enough testing is done to verify that the system works. Design is done via refactoring, but the decision of how to refactor is based on the developers taste, not just on removing duplication.

The Un-named TDD (with Mocks): Some people combine the convenient mock generation frameworks of Mock Objects with the unnamed TDD. However, they use them for conveniently removing parts of the app that are annoying to configure, not for isolating the system under test.

Presenter First: Maybe just a sub-species of Mock Objects, this strategy is notable for recommending that the application be built outside-in.

Behavior Driven Development: I know this is related, but I don’t know enough about it to say anything.

I used to do the unnamed TDD, and have only recently discovered that I wasn’t doing Classic TDD. I’ve been trying out Classic TDD, and it’s very intriguing. I learned TDD from a combination of Wiki, XP Explained, Refactoring, and XP Installed. (Sort of.) I wonder if those older sources don’t contain as good a description of it as the TDD book, or if I just missed it.

Flashback: How To Develop Software Faster

April 18th, 2008

In 2006 I wrote an article with Matt Heusser about how to develop
software faster. It’s available here: How to develop software faster