t+1: Matt Wilson’s blog

I’m team-teaching a course at Tri-C in the visual communications department this Fall. The class is for graphic designers, and we go through the experience of meeting with a client, building a prototype web site, revising it, then releasing it on the world, then going back and fixing any post-release issues.

The students all have excellent graphic design skills, but nothing in previous courses covers anything programming-related. The other instructor has the graphic design chops, and that’s really the meat of the course, but they do want to punch up the level of instruction beyond building static HTML into building simple web apps.

I need a short list of skills you wish all graphic designers have. Here’s what I plan to cover so far:

1. How to use subversion. Probably we’ll use google code.
2. How to use tools like Fiddler and Firebug to look at page weight and watch the requests go back and forth.
3. How to check for valid HTML.
4. How to do some simple AJAX (by hand at first and then later with jQuery).
5. What’s the terminal in OS X for?
6. HTTP gets versus posts and what the heck does caching mean?
7. PHP fundamentals.

I think I’m going to use PHP rather than anything else, but I’d like to hear arguments against that.

Also, the class lab has a bunch of expensive Mac machines, so if there are really good tools out there, I’d love to hear about them.

I read a neat article in the last issue of Backyard Poultry. Modern breeds of chicken are really good at eating lots and lots of food so that they can grow really big as quickly as possible. So, now that prices for feed have gone way, way up, the costs of raising these birds have gone up just the same.

Meanwhile, there are other breeds of chickens that aren’t nearly as good at translating high-calorie feed into protein, but these birds need a lot less feed. They’re tougher animals — given enough pasture, they can survive almost entirely on scratching up bugs. Since feed has been cheap for so long, everybody lost interest in these breeds. After all, a skinny bird that just barely got by eating grubs and potato peels isn’t going to taste nearly as good as one that got fat really quickly off corn kernels.

Three comments:

1. Why did they have a team of people ready to run out with visual shields to block the stage? Are horrifying injuries so expected that they plan how to hide them quickly?
2. Who decided to play the slow-mo replay, followed by the super slo-mo replay?
3. I’m using some hebrew font for the numbers in this list. Isn’t that neat?

He’s been gone since December. I’ve been following this since I saw people searching for “Matt Wilson” visiting my site. I don’t know if he ran away, or got abducted, or what else. It sounds like a nightmare for his family.

I hope the kid is OK. There’s a message board on that site and some guy asserts that Matt is living on the streets in Berkeley.

I have some HTML links and I want to display them as buttons. I spent a few hours appying CSS styles, but never got something that appears identical to a button.

So this is what I’m doing now. It is obvious to read, and seems to work.

<a href="/blah"><input type="button" value="get blah" /></a>


The W3 validator approved it in HTML 4 strict. So, all signs suggest that this is the way to go, but I don’t follow the semantic web conversation very closely.

So, for those of you that do pay attention to all that stuff, what’s bad about this approach?

This is the first year I planted any flowers. I bought a sack of gladiolus bulbs from the big box hardware store. They’ve been really fun to watch.

I never dug up a few of the onions from last year, and they survived the winter. Now they are making seeds at the top of each shoot. Onions and carrots take a few years to be able to reproduce.

I have a lot of respect for these onions now. They’re able to repel the hordes of rabbits in my backyard, they survived a freezing winter, and now they’re getting ready to spawn more. It’s a good thing humans and onions are allies.

Corn is doing well too, despite a late start and seed that is two years old. Last year, some critter in a single day ate all twenty stalks down to the ground. I think it was a deer that somehow found its way into my back yard. I’ve seen deer on Fairmount blvd in the morning, so it’s not impossible.

I spotted this cicada relaxing on one of my tomato stalks. He’s in the center of the picture, on the left side of the wooden stick. This photo doesn’t show his colorations well. His wings are iridescent like a dragonfly’s wings, and his shell is really shiny turquoise.

When Charlie was just learning to speak, he and I talked about what sounds we would hear. When we heard cicadas in the trees, he would say “train”. I guess they reminded him of trains. Now we call cicadas train bugs.

What else — this year, I’m growing brandywine tomatoes (some heirloom variety) and I’ve got plenty of of fat green ones. Brandywine tomatoes have pleats sort of like pumpkins.

In between rows of corn, I planted pumpkins and beans. Rabbits destroyed all the beans, but they ignored the pumpkins, and the vines now all have big orange flowers. I found two bees inside one flower.

Finally, I’ve been letting our 14-year old cat out into the backyard a lot to sun herself. The rabbits stay away when she’s around.

So, yeah, gardening is pretty fun.

This story articulates my inchoate thoughts when I walked out of the theater after seeing The Dark Knight.

This blockquote will hook you or repel you:

Wayne uses his position as an Anglo-Saxon capitalist to marshal vast resources to develop military grade technology and materiel in the ‘fight’ against the ‘gangs’ in Gotham. Missiles, grenades, various projectiles, military or special-forces transportation methods (Fox borrows ideas from the CIA’s assassination squads quite overtly, i.e. “Skyhook”), mass surveillance, and old-fashioned brutality are Wayne’s stock-in-trade. All the while, he obfuscates his identity as the “Batman” in order to protect his position as capitalist, and to avoid public responsibility for his extra-legal violence. Of course, the actual Gotham police have no intention of arresting Batman for vigilante savagery, despite public acrimony over the rule of law.

I’ve written stuff in this tone, but this fellow is a master.

Offline version control is nice. Reviewing logs, viewing diffs, and applying merges is dramatically faster when everything is local.

It would be nice to be able to use my ticketing system offline also. I don’t like the context switch of leaving my editor to go over to my web-based ticket system when I want to make a note of something to do later.

Completely unrelated to offline access is the idea that most of the time, my ticketing system and my source control systems are barely aware of eachother.

For example, when I write a “fix this low-priority bug” ticket, it isn’t obvious what revision and branch of my code I’m talking about. Sure, I can add that information manually, and maybe my ticket system will even require me to do that, but I can very easily put incorrect information in there.

I’m thinking about starting an open-source project to make this happen. Please leave a comment with your thoughts (if you have any).

Goals

• Allow offline access to reading and writing tickets.
• Unify source control with ticketing so that tasks, requested features, and bug reports are linked with the relevant code.

What fields are in a ticket?

I’ve used bugzilla, various homemade ticketing systems, trac, and redmine. They all have at least these fields in every ticket:

• Globally unique ID
• Title
• Description
• Comments
• Deadline
• Status
• Priority
• Assigned To

A decent ticketing system usually also supports category keywords, lists of interested people that want to be included in discussions, links to external files, estimated time cost, etc.

Also, a decent ticketing system has lots of nice aggregate views of tickets.

I don’t want to talk about building a *decent* distributed system. I’ll settle for a toy one that just barely works.

Text file approach

Put each ticket in a separate file. Name the files like “make-login-box-green.txt”. Use some markup to divide the file into fields.

Append comments and follow-up notes to the end of the ticket.

This is easy and intuitive. I can use vim to write the tickets. The source control system can track changes in the text file itself to notice changes. So, the source control system reveals if I renamed the title.

The disadvantage is that doing diffs on different versions of a text file just notices text differences.

For example, if I rename a ticket’s title from one line to two lines, and then also change the deadline, all I can see in my report of what changes is the information about what characters on what lines are different.

Local client approach

Use something like the text file approach, with a few bells and whistles.

Instead of just firing up vim/emacs/notepad/textmate and starting typing, I want to use a simple local app like this:

    $ cd ~/projects/myproj1/trunk/tickets
    $ dist-ticket new --title "Change color of login buttons from green to pink"

Then the app would open $EDITOR with a new file that includes the template of a new ticket, populated with the command-line options passed in.

This local client could create the new file with a file name that includes a UUID function to generate globally unique file names.

The app would also be able to compare diffs between revisions of tickets, like this:

    $ dist-ticket diff -r 1:2 ticket-123.txt
    Title renamed from "Change color of login buttons from green to pink"
    to "Change login buttons style"
    Deadline extended by six months.
    Changed priority from High to Low.

Of course, the underlying source control system would still be able to show the text differences between the two files. But the dist-ticket script would apply a little bit more intelligence.

Stuff I’m pretty sure about

I want this thing to be agnostic to the underlying source control system. People using centralized source control should still be able to use it and people using some homemade crap should all be able to use it.

Initially it might not be possible to have dist-ticket go and talk to the VCS and get revisions. Instead of the dist-ticket diff thing above, we might need to do this at first:

    $ bzr cat -r 1 ticket-123.txt > /tmp/rev1.txt
    $ bzr cat -r 2 ticket-123.txt > /tmp/rev2.txt
    $ dist-ticket diff /tmp/rev1.txt /tmp/rev2.txt

So after the interface is defined, I can build the implementations for the VCS that I care about. The first two lines could be built into dist-ticket.

Associating tickets, branches, and revisions

I know I want to link my source control system somehow to my ticketing system. I see a couple of ways to do it:

• Underneath each branch, make a top-level directory called tickets. Then tickets would be seen as related to that branch. One ticket would be linked to exactly one branch.

  OR

• Keep tickets in some place completely outside the branches directory.

  Make some other intermediate data structure that holds a many-to-many relationsip between tickets and branches.

I like the second approach a lot more than the first approach. I would love to be able to look backward and see how I started working on feature X95321 as of revision 123, and then marked it complete as of revision 148. It would be nice to easily see which files are relevant and which ones are not relevant.

Maybe I would need to hack the VCS commit process somehow track relevant tickets per each commit. Maybe I could just store extra text in the comment part of the commit.

Sometimes when I’m feeling batty,I’ll put the Three Laws of Robotics in my source code. Usually, this is an veiled insult aimed at myself; the comment is my script is gotten so morbidly complex that it threatens to wake up and kill me.

On a completely unrelated note, I’ve been picking at the edges of prolog for the last couple of years. I’ve worked my way through a free Prolog textbook, and now I’m very slowly working my way through Language, Proof and Logic in order to learn me some predicate calculus.

Now I thought of a project that combines these two. I’m gonna build daydream about defining an ontology suitable for making robots comply with those three laws of robotics. Once I finished, it would work like this:


> Eat baby
Violates law #1!
> Mop floor
OK
> Burn down abandoned house
OK


You get the idea.

The Columbus Metro Library offered a fantastic location for us. Wireless internet, multiple meeting rooms, one room with about 30 workstations, etc. Really great location. A $15 donation makes you a “friend” of the library, and gets you a 15% discount at the coffee booth.

Catherine Devlin led the charge of organizing this conference, and she did it amazingly well.

The slides from my decorator talk are available here. I’ll be breaking them down into a series of blog posts with a lot more commentary, so stay tuned.