Last Saturday, Riley and I took our car to compete at Cub Pack 32's pinewood derby race, placing 2nd among the 33 racers submitting cars.

The Design

Last year's car didn't make it out of the shaping phase.  We got the car down to the shape and added weight, but I forgot to weigh it with the wheels.  When I tried to take some wood out of the center with a rotary saw, it went haywire, taking out way too much wood, extremely weakening the car frame, and still coming out overweight.  We had to bow out of the race.  But not this year.

We started concept work on the car months ago, beginning with me asking Riley what theme we should strive for this year.  His vehicles are all named after animals that are not typically known for their fast movement. The Penguin might go fast in the water, but it certainly doesn't through the air of a rocket derby. The Turtle is well known for its slow movement. October's rocket derby featured Riley's Skunk, which took first place.  This year's theme?  The Squid.

We looked online for some squid designs for inspiration, and found a few good ones.  We settled on one and I drew up some mock-ups.  Riley liked what we came up with, so we pressed forward.

I'm both surprised and not surprised that nobody asked about the process we used to paint the car.  All of the cars were styled differently, and Riley's was certainly done with a different technique from the rest.

After the car was sealed and primed (which Riley helped with), I transferred the squid design using tracing paper onto the primer coat.  I then painted the "water" area with frisket, which is a rubber cement-like substance that covers an area that you don't want to paint, then peels off later.  With the frisket dry, Riley used an air brush to paint the squid.  The use of the airbrush gave the car a fantastic flat paint quality that a regular brush couldn't come close to.  There were some other cars that obviously used spraypaint, but didn't include the frisket for detail.  Anyway, I'm happy with how that turned out.

I intended to use the frisket again to cover the squid parts and allow Riley to airbrush the water blue, but I was afraid the frisket would take off the squid-colored paint, since we didn't have a lot of time to let it cure to the primer.  So instead, I hand-painted the water with some dry-brushed black "seaweed" at the front of the car.  This even had the effect of making the blue water look watery, which was a cool side-effect.  Overall, I think the car looked great.

The Engineering

The pinewood derby is a hot contest among some scout dads who go into the race for the competition.  Some people complain that it becomes a contest between dads, rather than a fun activity for the scouts.  I wanted it to be as much of a learning experience for Riley as possible, but it's simply impractical for him to use a band saw at age 9.  So I involved him as much as I could, and made sure he understood the science behind the things I was doing to the car, even if he wasn't doing those things directly.

There were many things we did to make the car go fast.  I cut the wood block thinly, with a narrow, "aerodynamic" front, and space in the back for weights.  We drilled the axle holes with a tool that guaranteed straight axles, and lifted one wheel entirely from the track to reduce friction.  I drilled out holes for the weights in the back of the car, so that the weight could stay on the down-slope for as long as possible to give the car that extra "push".  We put slightly more than the allowed 5 ounces of weight in the car with weighted putty, so that we could slowly remove the extra weight and hit the 5 ounce limit from above, rather than trying to raise the weight from below.  The wheels were selected for consistent spin and balance from a large set, then the bores were polished.  The axles were polished with increasingly finer sandpaper until they were absent of visible scratches under a magnifying glass.  The axles were ever-so-slightly bent to allow them to be aligned in a particular way.  The alignment of the car was tested and re-tested to go not completely straight, but to allow the three-wheeled car to effectively track the rail while racing.

And that's just the stuff off the top of my head.

Riley helped with many of these things, and watched the things that were not safe for him to do (or he was too nervous about to handle himself).  I was particularly proud of him polishing the axles after I told him it was one of the most important parts.  He took to the tedious process and did a great job.

Overall, I think you can ask Riley about any aspect of the car, and he'll at least know why we did it, if not having had a hand in it himself.  I think this combined with having the chance for us to work on a project together are the most important parts of the derby, and I think we did alright.

The Race

I volunteered to chair the race committee in 2015, so I wanted to be involved in the race this year to know how everything was set up.  Our pack has a good track record of smooth events, so I feel getting knowledge passed on from a predecessor is an important part of keeping things running smoothly.  As such, I showed up early on the day of registration to help set up the race area, the track and electronics, and registration itself.

Our track races four cars at once and uses an electronic timer to detect race starts and finishing places.  This is all hooked to a computer with software to schedule races, monitor the race outcomes, and produce the result reports.

On the day of the race, I volunteered to place the cars on the track and release the gate to start the race.  This was a lot of fun, but also a bit nerve-wracking, since setting a car on the track at the wrong angle could cause it to lose, and many cars were balanced very weirdly, making them harder to place on the track than you might think.  Really, it's a complex job!

The downside of this position is that I could not easily watch the races.  There is a mechanism in the release that resets the timer in the electronics, and it was too much of a temptation to reset the release right after the cars crossed the finish line, rather than waiting the appropriate amount of time so that the results could be seen and recorded.  The end result is that I didn't actually watch many of the races.  In fact, I did watch the very first race (which had Riley's car in it), and I screwed it up, which led me not to watch any of the other races.

That said, from what I heard and what little I did see myself, Riley's car did very well.  His average speed on our track was around 233.7 MPH, scaled to the size of real cars.  As far as I know, this average speed was faster than anything else on the track.  In many of Riley's races, his car seemed to pull away from the other cars on the flat, which seems to defy a car's capabilities.  Really, this is all about weight placement and center of gravity, something that Riley and I spent a lot of time talking about and working on.

The races were broken into 3 sets of heats.  The first set was all 33 cars racing against each other.  These races determined winners within each den.  The second set was a semi-final, racing the top 16 cars to obtain the top 4 finishers for the pack results.  We ended up with some ties in that second set, so our final set of races had 6 racers.

Riley took first place in his den during the initial heats, which earned him a medal.  My dad took video of some of these races.  His car placed first in the semi-final, moving on to the final race.  In the final set of races, he won the first race, but came in second place for the next two.  This was fairly disappointing, considering his consistent first place finishes in all the other races.

Later, we found that the axle locks (small hex screws we used on the bottom of the car to hold the axles in and at a specific position) on three of the wheels had been ripped out of the bottom of the car.  The end of the track has some rubber ramps to keep the cars from shooting off the end, and these probably caused the damage.  When we handled the wheels, at least one of the axles was very loose, sliding in and out with very little effort.  It's surprising that the car did as well as it did in this condition, and I can only assume that had the axle locks held up, Riley would have passed the first place car, just as it had on every prior race in which they had been matched.

Still, second place is a great showing, and the races at the end were all very, very close.  In fact, the race data shows that Riley's car and the winning car had the exact same average speed in the final set of races, down to the tenths of a MPH.  It just nosed out the Squid in those last two races, putting him ahead.  Good job, Christopher.

There was also a people's choice award, where the scouts vote for their favorite car design.  In previous years, only the top car would receive an award.  This year, we did first through third place medals, which I think is a great idea, considering how much time scouts and their parents spend on these cars.  Riley's friend, Colin, won second place with his classic Batmobile-like car, which was shaped out of the wood block with a Dremel tool.  Pretty cool.

Placing in the top three in our pack means that we get to advance to the district race.  This year, the Horseshoe Trail District pinewood derby race will be May 10th at the Exton Mall.  I'm excited to see Riley's car compete in this cool public venue, and to actually be able to watch the race!  We should have adequate time between now and then to repair the damaged axle locks, and to re-tune the wheels to run perfectly again.  There are even some small things that we didn't have time for that I think will make a difference in this race against the best cars in the district.  It's exciting to get a chance to race again against Christopher's first place car.

Next Year

I have some subtle ideas for improving the race next year.  Nothing too fancy, but it could make the experience better for the boys.

Next year, I think I will allow each scout three votes for people's choice instead of just one.  It may make tallying a little more complex, but I think it'll even out the distribution.  The car that won people's choice this year was another (this is a running theme since we've been in scouts) Minecraft-themed car.  It was admittedly a very nicely done car, and in my opinion, deserved first place.  But it would be nice to see some leveling-out of the votes.  If a kid's first vote goes to the one his friends voted for, then the other two might go to cars based on their actual design.  Just a thought.

Also, I'm thinking to make some upgrades and repairs to the track components.  The rubber stoppers at the end of the track need replaced.  They're very worn and don't always work.  We had to put a blanket at the end of the track to catch many of the cars that shot right past the rubber.

I want to do some work on the gate mechanism, so that the gate works the way I've seen on other systems.  Our gate is held up by rubber bands.  To release the gate, you twist the board that holds the pegs that hold back the cars, and have to hold it down until the race is recorded.  What should happen is the gate should be locked in place.  When a chuck is pulled, a spring or rubber band should pull the gate open, and it should remain open without holding it until someone lifts it back into place and re-locks it with the chuck.  Ideally, the chuck would be controlled by the same computer that records race results.

That's probably enough change, though I'd love to add that instant-replay capability I've seen to our track so that the end of each race can be played in slow-motion on the projector.  That would be pretty slick.

There's a handful of good programs on "TV" these days.  Berta and I have been enjoying House of Cards, True Detectives, and The Walking Dead, for example.  Game of Thrones is soon to return to the screen, and we watched the first episode of Black Sails last night, which wasn't bad.  But none of these shows are appropriate for our kids, aged 9 and 12.

Well, that's not completely true.  There are shows that are designed for 9 or 12-year-olds.  But those shows are of no interest to Berta or me.  They're all trite and lack complexity.  And I'm not against cartoons, but it would be nice to watch something together that's not a cartoon.

The last thing we really enjoyed watching together was a cartoon, Avatar the Last Airbender. The sequel, Korra, isn't bad, but it's not quite as good.  And since there's only that show, we've been turning to other cartoons - recently Fullmetal Alchemist - to get that fix of complex theme with kid-approachable topic.

My conclusion: There is no great family TV.

I don't want to return to ABC Family Nights and Disney movies.  Sure, they're fine, but I think they've drifted and so has their audience.  Disney family movies get weirdly preachy while demonstrating child behavior that looks ok but really isn't.  For example, they'll show kids sneaking out of bedroom windows like it's a normal thing.  Simultaneously, they're ridiculously trite and kid-relationship-heavy.  What used to be something the family could enjoy watching together without having heavy-handed lessons has become something I can't stand watching for more than a few minutes.

At the same time, I would love for these shows to be even more gritty.  Our world isn't always the clean, sterile set of 7th Heaven.  It's why Almost Human is on the edge of attractive to me as a family show.  It has complex future themes and nice character banter.  It makes you think without forcing the issue.  And yet, it's occasionally a bit on the wrong side of discretion for the kids -- A little heavy on the sex, a little heavy on the violence.

Elementary is a favorite show of mine.  I would like to watch it with the kids, because it's interesting and complex.  Sure, it's not as nuanced as other shows, but it's a good evening's entertainment.  That said, it's hit-or-miss with the kids due to its occasional foray into adult themes.  Every so often Sherlock comes out of his bedroom with three women, implying things I'd rather not need to explain to 9-year-old Riley.  While it's a good show, I'd rather watch a show once with everyone than screen it once with Berta before deciding if it's kid-appropriate and watching it again.

As a typical American, I'm more ok with violence than sex. We watch Bones, which isn't so much about the violence but the aftermath of the violence.  I'm ok with some violence for the kids, since they're unavoidably exposed to it elsewhere in our culture.  As long as it's not explicit, gratuitous, or excessive, that's not too bad.  The theme of a show can't be violence alone, though.

I've been re-watching Veronica Mars prior to the upcoming movie release.  It's a great show, and just the kind of complex story I'd want the kids to get into.  Except for the rape that colors the entire first season.  And third season.  Ugh.  It's not that they shouldn't eventually be exposed to these realities, but that it feels too casual to introduce via a TV program.

Mind you, I'm not looking to teach any lessons with TV.  TV, as far as I'm concerned, is lesson-free mindless recreation.  Sure, you can take topics out of TV to discuss, but I don't set out watching a show with the intent to talk to the kids about it afterward.  We watch TV with them all too little to bother.  I'm really just looking for a show that we can all enjoy, so that we're not forced to wait until after their bed time to turn on a program.

I'm looking for something squarely between Game of Thrones and Wizards of Waverly Place. No vampires.  Ideally, Veronica Mars without going into the sexual themes.  Something with some real conflict/intrigue, and that doesn't focus on tween puppy love.

Got any ideas?

Hear me out. I'm a UX designer by trade; while not a developer, I do understand software and technology very well. I spend a lot of time testing and tinkering with ideas by trying to hack them together the best I can. My goal is to build a small but real feeling version of my idea to understand and test if there's actually value. I continually hit the wall or spend hours getting caught up on something trivial (I understand this is part of the learning process). Like for most people, time is an issue for me and I'm really looking for something to help me prototype quickly. I consider Ruby and Python too big for that (am I wrong)? What should I focus on, a Javascript framework, just jQuery, something like Haskell, etc.? 

First, it's admirable to want to learn something new.  Programming is a tough discipline to master.  In spite of every startup CEO telling you they themselves coded their launch project, and that you should just learn to code it all yourself, this is not a practical approach.  The statistic we don't have is how many of those startups continue to be a success without having their code re-written by competent programmers.

That said... there's a big different between prototyping and building for production.  I'm glad that's clear to you.  The trick is that - and if you're a UX designer by trade, you should already know this, so I have some skepticism - prototyping is pretty easy to do on paper.  In most cases, it's probably easier than trying to iterate code through a design review process.  Sure, it's not clicking buttons on a screen, giving you the feel, but you should at least be able to determine if your idea has value from paper prototypes.

I think the bottom line is this:

You shouldn't be programming anything.

There are many questions remaining in your request.  What type of app are you building?  Is it for desktop?  Web?  Mobile?  What platform, Windows, Mac, or Linux?  Are there collaborative features?  Realtime updates?  All of these questions lend toward choosing the best language for the project.  But if all you want to do is prototype, use paper.  Or get a copy of Axure.

After you prove out your ideas on paper, pay a developer to build your live prototype for you.  They'll know what they're doing and do it faster and better than you will, even if you learned a programming language.  Not only will you see a result faster than you would if you have to learn to code while you go, but if your developer is worth his salt, you'll have a prototype that can be used to help move your product forward to production.  Ultimately, you will have saved money.

Sadly, you'll probably get a bunch of responses like, "Use jQuery," or worse, "Use Ruby!"  These recommendations coming without any questions about what you're trying to build are most likely from novice fans of a particular language.  I can't blame anyone for being a fan of the language they love, but all too many times I've heard (especially with Ruby) things like, "Oh, I never understood programming until I tried X language.  It'll be perfect for you, too."  Don't be fooled by this.  There is no perfect language for your application, especially when nobody's even heard what the application is!

I'm a big proponent of the best tool for the job, wielded by the best craftsman.  Get a recommendation from someone who knows how the different languages compare, has used all of them, and is qualified to make a recommendation.

Today is the first day of a new year.  In years past, I've set aside the whole concept of resolutions.  Resolutions are stupid.  To me, it implies that making significant changes in life can only happen one time of the year, as if there's some magic about the new year that allows these changes to effortlessly happen.  We all know that's not true.  What it might be is more drawing a line in the sand, and saying this day is the day I start, and having some hard line to observe rather than some random date along the way.

On Needing a Plan

The trick with the new year "resolution" (a word that I will no longer use here), is that things like "eating better" and particularly things like "waking up with the alarm" are really hard to do on the day that follows staying up partying to late hours.  We've still got guests in our house as I write this, and Berta is off work making pancakes and sausage for breakfast, and I've already slept in until 10am, and it's looking like I've already tread off the path I've set myself for the new year before even locating the trailhead!

A theme that I hope to continue with throughout the new year (the new, revised Owen!) is looking at these outlying situations and making them part of the plan, rather than saying, "Oops, guess we broke it." The end result should be more success and an ability to easily return to the plan when before it might have been foiled by a bad day.

Budget Up

Something that should be but is not (yet?) part of the plan for the new year is budgeting.  I've been looking at this app called You Need A Budget, which is highly recommended.  Budgeting issues aside, one of the basic concepts of this software is something that I think will come in huge use with my planning for the unplannable: Plan only for the future.

You can look at past spending to predict for the future, but ideally, the concept is to take the money you know you have on hand and spend it on bills you know you have now.  Do not plan for beyond this current unit of time.  It's not so much living check to check, but bases its method on getting the current bills paid.

With that, if I miss a day of what changes I've intended here or there, I shouldn't look back.  I should plan to continue the next day and get back on track.  No making up for the miss, no eating less today to make up for yesterday's Twinkie.  Just plowing forward with it.

Seems pretty simplistic, but I think it's an interesting psychological shift.

Habit Change

I read a good portion of this book, The Power of Habit, which talks all about how stopping bad habits is harder than creating new habits to replace them.  I'm looking for a key habit to create that will help affect the rest of my bad habits and start to create the set of good habits I'm looking for.

After doing no research at all, I've decided that the key habit I need to change is waking up earlier.  I think this will give me time to focus my mental energies, get myself together, get done miscellaneous things I keep wanting to do but not making time for, get better rest (since I'll want/have to go to bed earlier), and a bunch of other cascading things.

So that's the simple plan, such as it is: Get Up Earlier.

You see portfolio sites all over the web from web designers showcasing the sites that they've designed.  And now and then you see web developers posting a portfolio including a few sites they've managed the HTML coding for.  But you never see a portfolio of a developer showing the site architecture that they've rocked.

Here's a weird paradox:  I want to showcase the work I've done for clients.  The work I do is primarily writing site-specific code to enable a certain unique feature on a site, or assembling the parts to produce that feature.  But often I can't realistically use a screenshot of the site to characterize that work, since the screenshot is of the graphic design, which is something I had nothing to do with.

Consider a simple example of configuring a Drupal (urg) site to manage an email newsletter.  I can assemble and configure all of the parts to achieve this goal.  It is not uncomplicated, since it has many moving parts and often involves some server knowledge to ensure email deliverability.  Often, the only point to the site is to provide a few static pages and this mail feature, so it's a pretty significant item for the project.  But I can't very well take a screenshot of "managing/sending email subscriptions" like I can the graphic design of the site, can I?

This is a topic that has perplexed me for a long time, since I am not (primarily) an HTML guy.  People never hired me explicitly to convert their graphic designs into HTML.  Primarily, I'm an architecture guy.  I write the platforms that drive your sites.  I write the plugins, modules, and apps that the HTML-writing folks use to build your site.  So how do I put my code portfolio on display?

I was recently reminded of this portfolio issue by Geri's Credits and Recognition article at 24 Ways.  She presents many good thoughts on creating a portfolio and properly crediting those who are involved for the parts in which they are involved.  All too often I feel like designers take credit for the entire work of a website with their credit links, when the site wouldn't actually function without the behind-the-scenes work of the developers -- the work that can't actually be seen by a visitor.

It's gotten so bad in my head that I don't like to show a screenshot of sites I've worked on at all because I don't want people who view my portfolio to think that I do graphic design, and I want people to understand that it's the functionality that I produce, not the pretty design parts.  (Yes, yes, UXers, I know, just shut up.)  It's hard to convey what work is done with an image, and it's hard to call a thing a "web site portfolio" without an image.  So hard, in fact, that I don't really bother.

Some might say that my GitHub page (or something like it) serves as a better portfolio of work.  To a degree I think that's true.  But man, wouldn't it be nice to have a pretty graphic portfolio that characterizes what I have accomplished in images, rather than having to explain code to people that, by definition if they're hiring me, don't understand what I do?