I’m going to start a new practice. Before I even do an estimate for a client, I’m going to ask:

Which is more important to you: having it done by a certain date, or having all your features 100% complete?

Two extremes: I’m dealing with a client right now that has a very firm, but internal, sense of when they want my current project done at. I’ve dealt with clients in the past who don’t care when it’s done, just as long as its perfect when we ship.

These are both legitimate decisions.

In the former case, if your ship date is set, then your development team needs to know it. It can even be in the form of sprints: “how many sprints do we have until ship date: 3, or 6?”. This is important, because it gives me a sense of urgency: how hard do I have to push back when scope increases, how conscious do I have to be about my time?. How closely does the dev team’s PM have to monitor developer’s feelings of progress?

It’s the old Parkinson’s Law in affect: if you tell me 6 sprints I’ll take 6 sprints: I might spend a few hours refactoring something here, or shaving a yack. Stuff that needs to be done, of course, but if you tell me 3 sprints I’ll work that much harder to ignore hairy yacks (”Ok, whatever, it’s taking too much time: I don’t need to fix it now, just get it up and leave a TODO item for later”).

A time limit also forces an agile team to think about pushing back. As scope increases on you, or additional bugs get entered by QA, this deadline determines your behavior. In short: how hard do you (or the direct management of your development team) have to watch your engineering time?

Now, a scope increase could be implicit as well as explicit. Implicit scope increases take the form of: “When we went to implement this, our initial estimates said it would be easy, but it’s now consumed 3 engineer/days… not so easy after all, actually”. Explicit increases take the form of new requirements, and (to an extent) bug reports.

With a firm date you can sit down with your client and have a discussion about these things, approach it in an agile way. Do they still want that “small thing that grew to 3 engineer/days”? Or would they rather get started on implementing different functionality?

Both of these answers are right, in different contexts. That’s why the conversation is there. With a deadline, especially a tight one, you need to make sure you are evaluating from sprint to sprint and making decisions agilely, based on the changing gestalt of the landscape.

I thought there’s a quote, but I can’t seem to find it now, from some military general, about how a plan only lasts a few minutes in actual battle. Same here, in the software development world.

Yes, these are just two sides of the Project Triangle. I’m assuming, for this article, that your team size/cost is set. But maybe it’s not (bully for you!)

So I decided to switch things around and write a sample application in Django. I started a simple project management / bug tracker / projects-have-many-todo-items app.

Hopefully in the near future I can spend some more time on this example app, for example actually finishing up more than just the project level screens :)

Find it at (in a Mercurial repository on bitbucket:) wd_project_dashboard.

So I’ve noticed there’s not one central place for Turbogears newbies to go to see a bunch of sample applications.

I’m trying to fix that.

To gauge interest, and as an easy/no hassle way to collect all these links, I started a public Google Doc that lists all the Turbogears examples on the web that I know about.

Check it out at: Turbogears Examples Public Google Doc.

At some point in time I’d love to work with the Turbogears team to make this part of their website, but I think showing them that there’s enough examples out there is an important first step.

Update: if Google docs gives you an error just hit refresh – it should sort itself out then.

I’ve been working with Rails for 2 years now, and I’ve developed a collection of tools I really like. I’m going to share these with you (eventually I’ll make a Rails template for them, but not now).

Normal Application Stack

• will_paginate
• formtastic: this really cuts back on the amount of HTML I have to write, and, having the input type defaulted from the column type is nice
  I can also script/generate form $MODEL, which is awesome.
• DataMapper: I haven’t had a project to use this on yet, but this is my preferred ORM.

• sentient_user: I very often need to know who the current user is when I’m in my models.

  Yes, I can avoid some of this by querying through the controllers, but sometimes you just need to know who your current user is.

  Instead of worrying about what the latest fashion is in the Rails community, I’ll just let some common code.

• show_for. Formtastic for show actions.
• My annotate_models port: I finally have an annotate_models that works exactly like I want it too. That’s the great thing about Github: the easy network graph.
• Inherited Resources: I really don’t like code in my app that just boilerplate (especially auto generated boilerplate). The boilerplate just gets in the way if I have to customize the controller or view, and just needlessly brings up the line count if you don’t.
• Data Migration: I don’t like putting data changes in the migrations, and db/seed.rb sucks if you add data to it (you have to be careful to not add duplicates!). Data migration gives us a way to add data to a production system in the same way we might add/chage schema

Inherited Resources is great, especially when the controller is in an early stage of development or an admin controller that might not matter.

If the code’s not there I won’t have to maintain it at some point in the future.

On the testing front

• shoulda. I like the simplicity of Test::Unit, but I don’t like typing def test_the_object_should_error_when_the_date_is_invalid_my_fingers_are_bleeding_ackk. Shoulda context and should blocks makes this a lot easier.
• timecop. I love Timecop.
• machinist. The tagline says it all: fixtures aren’t fun, Machinist is.

Utilities

• Mailtrap: enough of mail server to handle ActionMailer communications… and log them to a file.
• rr: easy mocking framework
• jQuery’s timeago plugin: I hate websites that say “created 5 minutes ago.” Do you mean 5 minutes from now, or 5 minutes from when I last refreshed the page? Use some Javascript to avoid this question
• BlueprintCSS
• utility_belt: make IRB way more useful.

Hopefully there’s one or two new things in here for you to add to your Rails setup!

When I first designed the Wilcox Development Solutions website it was meant to say one thing, stylistically: I design simple, clean websites that look functional.

It was 2003 after all: things should look simple. We still have people on 56K modems, running Internet Explorer on the Mac, and nobody’s really figured out a good way to do layout, anyway

About a year ago I noticed that these problems were solved: a whole lot more people got broadband, we have hyper-modern browsers now, and gosh is there some good looking websites out there (thanks in part, I think, to Blueprint CSS. And the world revolves around web apps way more than it did in 2003.

So, time for a refresh. I work towards the refresh in September, 2008.

Ever heard that saying, “The cobbler’s children have no shoes”?. Yeah, it’s like that.

Tonight I put the finishing touches on the site and deployed it.

Because people are curious, here’s how it used to look:

And how it looks now:

Mostly the same content, but with a much more pleasing layout. The old layout had a good, 7 year, run, but it was time for this refresh.

In addition to BlueprintCSS, I have to thank my other partner in crime: Webby. This made (and will make) layout level changes so much easier

The cobbler’s kids now have nice looking shoes!

I’m playing with Turbogears 2 more and more, and as part of this process I wanted to improve and codify my process for getting a new TG2 app up and running.

I also really like virtualenv, and am learning to love pip (mostly for the ease of requirements.txt).

I also know that the Installation for the Impatient make me, well, impatient. Ughh, 5 commands.

So I wanted to see if I could make this slightly better with pip, and I kind of did:


$ pip install -E tg2env -i http://www.turbogears.org/2.1/downloads/current/index/tg.devtools
$ source tg2env/bin/activate
$ paster quickstart my_wonderful_app

Two issues I found when trying to install TG2:

• You want tg.devtools, not Turbogears2: tg.devtools includes the tools to make new projects, where as the Turbogears package just includes the code to run a Turbogears app.
• Ultimately leaving out the -i part should work, but I ran into problems that way (had version conflicts with repoze.who), so ended up having to specify the package source with -i. It could be that these are solved by the time you read this.

or, to install the latest beta (at this point, 2.1b2)

$ pip install -E tg2env\
-e 'hg+http://bitbucket.org/turbogears/tg-dev/@2.1b2#egg=TurboGears2'\
-e 'hg+http://bitbucket.org/turbogears/tgdevtools-dev/@2.1b2#egg=tg.devtools'

Ok, it’s still a lot of commands, but it can be done.

Hope this helps enable great Turbogears apps!

The other week I created Email Form Relay: a Google App Engine app to make it really easy to implement a “Contact Us” style form.

As web developers we find ourselves coding “Contact Us” forms alot. In addition to having the form to write, we also have the backend logic to deal with: gather up the TO information, from, subject, body and send it off.

But that means configuring sendmail email servers, testing the sending capabilities, and making sure you don’t leave yourself open to spammers. Then making sure that email gateway stays up.

But we’ve made that easy: sign up with your Goggle API, register your site. Get an API key, put that in a hidden field, and point your form action to Email Form Relay’s server. On submit, Email Form Relay will do the email sending and redirect the user to a page of your choosing.

And that’s it: you provide the form, we provide the email sending.

So check it out: I hope it speeds up your contact form creating experience!

So I’m on a Rails project, we use Git for source control, and we have a team policy of good test coverage (validated by a CI server – specifically CruiseControl – running tests and alerting the team on a failed build).

Day to day we do work on feature branches which we later merge to the master branch when that sub-system (ticket) is complete.

My typical workflow is to start work on a ticket, make a number of intermediate commits, then merge back to master. However, my coworker was noting today that the intermediate commits mean that I have commits that could technically break the build – which is not an issue normally, but if we were to use git bisect to find a bug the failing tests could get in the way.

This is contrary to centralized version control systems, where you know every commit will pass tests, because you don’t want to break the build. But in Git the CI server only checks the latest commit.

I said that I saw two, potentially equally legitimate, git workflows:

• The commit is the unit of work, by which you want to commit as often as possible to get those benefits, and you publish those intermediate commits (useful for history and code review!)
• The Subsystem is the unit of work: commit as often as possible, but when you’re ready to publish git rebase -i so you don’t pollute history. (Of course, this only works if it’s just a local branch – doing a rebase -i to a remote branch is a bad idea).

I’d love to hear two cents from the various git gurus around the internets…

I find myself writing more and more sample projects for Turbogears 2. These sample projects are actually meant to be read by going through the commit history with GitX and reading the commit messages and reading the diffs.

Anyway, I’ve posted another one, on the form technology in Turbogears: Sprox/FormEncode. Clone it from its Github Repository

Turbogears uses Python’s logger module to perform logging operations. This has an advantage (it uses Python’s logger module) and an disadvantage (it uses Python’s logger module).

Be that as it may, here is the simplest configuration possible for you to log to a file (by default TG logs to your STDOUT device, which might not actually be what you want).

In (environment).ini (aka: development.ini)

Note: The format of logging section of this file follows the format laid down in the logging configuration file format section of the standard library documentation.

Accessing this in your code


import logging
log = logging.getLogger("MY_TG_APP_NAME")

log.info("hi!")