industriousone

"…the terror of knowing that I can't keep up with all of it. It's like finding a river of flowing gold when you haven't even got a cup to save a cupfull…you've but a thimble, and that thimble is your pathetic brain and labour and humanness." —Jack Kerouac

When I began capturing notes and seeing them actually get completed, the floodgates opened and out came more good stuff than I knew what to do with. Attempting to improve my workflow by getting more granular has only added fuel to that fire. After much pain, suffering, and suboptimal productivity I think I've got things whipped back into shape. For the sake of my future self, here's a moment to capture these hard-earned lessons, just in case I find myself wandering off into the wilderness again (not like that would ever happen, of course).

The Someday List

If you've got more projects than you can handle, take the ones you aren't actively working and put them somewhere else. Duh. I call it a backlog so the agile folks at work will know what I'm talking about, but in GTD parlance it's a Someday/Maybe list. Whatever you call it, it's the place you put the things that you're not ready or able to do right now.

A sampling of the Someday list

So the first step to getting my lists under control was to shove everything I could on to the backlog. And I didn't kid around: if I wasn't actively working on it today I pushed it off. Which brings up my rule number one:

Use it aggressively. I mean like every day. If you aren't going to work on a project today, and you aren't going to work on it tomorrow, seriously consider pushing it off to the someday list. If you aren't going to work on it this week definitely push it off. Get everything out of your sight you possibly can; focus on your most important work. If you find yourself with nothing to do—lucky you!—then you can go grab the next thing off the backlog.

Okay, so I pushed everything off, cutting several dozen active projects down to six, and now I've got a big long list of someday. Here's the rub: the Someday/Maybe list only works if someday eventually arrives. Otherwise it's the "Never/No way/No how" list and the kiss of death. And it killed me: I had a backlog, and I used it. More and more new ideas came in and it grew and grew, with no end in sight, until I started losing stuff, losing the big picture. I became afraid to push off ideas, fearing they would never be seen or heard from again. So I kept them active, so I was looking at all of them every day, feeling overwhelmed and unorganized. I couldn't push them off without killing them, and I couldn't keep them around without killing me.

Like I said, I did manage to get it sorted, and here are my rules for making sure someday does arrive. Note that if you use the list aggressively, like I mentioned above, most of these will fall out all on their own. I mention them here for my own edification. Read more...

At long last: 4.2! Many, many thanks to everyone who assisted by using the early releases, providing feedback, reporting bugs, and contributing patches. This release, and every release, is better because of your help.

Download 4.2 now

The final change log:

• Feature 1526976: Add support for Apple Xcode 3
• Feature 2900623: Add targetsuffix and implibsuffix properties
• Feature 2839002: Add gcc switch to improve header dependency generation (Johannes Spohr)
• Feature 2832906: Global variable (_SCRIPT) for current script path
• Feature 2905303: Enable better folder matching in file lists
• Feature 2919629: Add help target for makefiles
• Feature 2820644: Add Xbox360 deployment and image options
• Bug 2909463: Fix Xcode handling of Obj-C++ .mm files
• Bug 2903430: Using relative instead of absolute paths with $() macro
• Bug 2910691: Duplicate build options
• Bug 2910639: Nil reference on dylib project dependency
• Bug 2872066: Two test failures in 4.1.2
• Bug 2912756: dylibs missing lib prefix
• Bug 2910202: Code::Blocks building C files as C++
• Bug 2926917: Use target name for Visual Studio PDB file
• Bug 2927604: Unable to build Premake with Visual Studio
• Added project kind to list of configuration filters
• Clean action now removes MonoDevelop .pidb files correctly
• added os.executef()

Enjoy!

I spent the start of the holiday break upgrading my studio gear, adding an HP LP2475w monitor and Logitech Z-523 speakers, both of which are excellent. My Macbook now runs in clamshell mode, with a wireless keyboard and mouse.

The new studio setup in action

Games in particular are vastly improved on the new widescreen, but I had a devil of a time getting the wireless keyboard working under Boot Camp and Windows XP. Let me save you the hours (!!) I spent getting it sorted.

Note that this is for Windows XP. It might work for Windows 7—if you try it let me know what you find out. And although I haven't tried it, I think this process should work for the wireless mouse as well. I've got a Magic Mouse on order and will post an update once I've had a chance to try it out (Update: yep, it works the same, just choose "No passcode". Note that initially it said that the drivers failed to install properly, but a few seconds later the mouse kicked in and has been working fine ever since.)

The magic formula

I started by unpairing the keyboard from OS X. I don't think this is strictly necessary, but I'll mention it just in case. If you follow the steps below and it still isn't working you might want to try it out. In System Preferences > Bluetooth, select the keyboard and then press the minus button at the bottom of the list and confirm the warning dialog.

In Windows XP, bring up the Bluetooth control panel. Make sure the keyboard is turned on, then let it scan for devices. After several seconds the keyboard should appear in the list. Right-click on it and choose Properties and then Services. You'll see a checkbox options for drivers; check it and click Apply.

Now return to the device list, select the keyboard and hit Next to begin the setup. When asked for a passkey, choose Use the passkey found in the documentation and enter 0000 (that's four zeros; of course this requires that you have a keyboard connected! If you don't, use the On-Screen Keyboard application found under Accessories > Accessibility). Hit Next again and you'll be prompted to verify the passkey on the wireless keyboard. Enter the four zeros and press Enter (on the wireless keyboard). After a second it should confirm the device setup.

That's it, you're paired. Reboot XP once just to verify it will pair. Note that the special keys (brightness, eject, etc.) only work if you're running on one of the newest iMacs, or are using the 2.2 (Leopard) version of Boot Camp. Hopefully this will get fixed in a Boot Camp update, but considering how long us MacBook users have been suffering with audio issues I won't hold my breath.

Hopefully you're up and running at this point. If you unpaired the keyboard in OS X you can now reconnect it. And in case you're still stuck, here's Microsoft's troubleshooting guide.

Update: If you are having problems with your Magic Mouse "freezing" for several seconds at a time, particularly when doing CPU intensive stuff like playing games, see this thread on the Apple support site for a suggestion that might help.

My return to racing continues...well, not racing per se: these days I drive more like a mechanic who stole the keys. I just did a quick bit of math and realized that is has been almost five years (!!) since I last dusted off the wheel, and nearly as long since I did any simulation coding. Kids will do that to you, I guess.

It is too close to the gift-giving season to pick up any (relatively) new sims for myself, and honestly I'm so out of the scene that I don't even know which ones are any good. So for now the retro racing revolution continues, this time with the-sim-that-will-not-die Grand Prix Legends.

I really expected to find this sim—initially released in 1998—pretty much where I left it. I knew about the GPL Preservation Society, the massive track database, and the active modding community, but really how much can you do with a decade old, closed source sim? Quite a bit, as it turns out! Case in point: the jaw-dropping Targa Florio, 72 km of pure road racing joy. Grand Prix Legends is like Steve McQueen's Le Mans: a classic!

Because of all the mods and patches, there is some hoop jumping involved to get up and running. The hardest part was figuring out which bits I needed and where to get them; I'll save you that trouble with a full play-by-play below. Installation was straightforward from there, and it runs great on my MacBook Pro under both Boot Camp and VMware Fusion 3.0 (be sure to switch to full screen before starting the game; it doesn't like Unity).

Okay, enough chit-chat. Here's my installation guide. Read more...

After a long slog, we're finally ready to begin the countdown to the 4.2 release. Whew!

Get 4.2-beta1 from SourceForge

The big news is the freshly minted support for Apple's Xcode IDE. This was a complicated one, so give it a good beating and help shake the bugs out. And while you're doing that, I'll be squeezing in a few more small features, applying your patches, and generally cleaning things up. I'm hoping to get to a release candidate before the end of the year.

The changes so far:

• Feature 1526976: Add support for Apple Xcode 3
• clean now removes MonoDevelop .pidb files correctly
• added os.executef()

Enjoy, and be sure to send in those bug reports!

Ah, the original Need for Speed! Alpine, Coastal, Vertigo Ridge—great tracks now trapped in an out-dated game, passed by in time. As an avid road-tripper, I loved those open road tracks and the opportunity to drive with traffic in an environment that, for the time, felt realistic. I even plunked down the cash for a Thrustmaster T1 wheel and pedals.

Several years ago I had the idea to rip out those tracks and convert them to run in a modern simulator. With some help from Denis Auroux (the author of TRACKED, to my knowledge the first player-created editor for a commercial game) I was able to decode the track segments and textures. But then I got distracted, my attention turned elsewhere, life and children caught me up, and the code was left to collect dust.

Now the driving bug is biting again and I'm blowing the dust off this project as a first, small step back into simulation coding. I dug up my circa 1995 NFS SE CD and got it running on my 2009 MacBook Pro. It is…dated, as you can imagine. The steering and handling is all over the place compared to a modern sim; I have no idea how we managed those quick laps back in the day!

(As an aside, I used to run the AutoSim World Records Site back then, which you can still find in the Internet Archive. None of those records are mine though; too much time building websites and not enough racing.)

In case you feel like following along, here's how I got it working. Read more...

Premake 4.1.2 is now released and available for download! This release includes...

• Fixed ManagedExtension setting for Visual Studio (managed C++ code will now build properly)
• Fixed os.match() bug for large result sets (David Raulo)
• Patch 2840052: Order problem of static link (fixes linking to static libraries in GNU makefiles)
• Patch 2802722: Add floating point model flags FloatFast and FloatStrict (Suigintou)
• Patch 2865333: Support for ObjC and ObjC++ sources (Johannes Spohr)
• Bug 2814179: Xbox 360 precompiled headers not working

Enjoy!

Ugh.

I'm at home today, the first of two days of vacation. I had hoped to use this time to crank out some Industriousness, like a new article or progress on Xcode for Premake. But I find myself unmotivated, uninspired, lacking in enthusiasm or energy. Humbug.

One needs time to recharge now and again, I know. I ought to go out on the deck and read a book or scribble in my sketchpad; noodle around on the Danelectro or take a drive out Crum Creek way. But I feel a certain obligation to my work, to be making steady progress, especially on an "opportunity day" like this one.

To take the edge off my self-imposed guilt I've dropped back to structured procrastication, checking off odds-and-ends around the house like ripping the new movies to the Playstation, fixing the mower, getting Aiden some bike riding practice. This has a certain satisfaction, and if it lacks in glamour it still shortens the backlog.

I guess what bugs me most is the correlation between the vacation and the drop in motivation. I have an entire day available for my own work, and so I feel no urgency to get started. Coincidence or causation? Is it worth creating a false deadline for myself, or better to just let it ride? Push through and get something done knowing that it will be uninspired, or live to fight another day?

I have no answer. But these books on my desk could be put away, and those shelves could be dusted...

Update: Apparently I just needed to vent and organize. I felt better as soon as I posted, and by the time I finished decluttering the studio my brain was turning over Xcode ideas. I ended up making decent progress on the day.

Premake 4.1.1 is now released and available for download! This release includes important fixes for the Xbox 360 and Mac OS X Universal binary support which introduced in version 4.1.

The full change log:

• Use libtool instead of ar for Mac OS X Universal static libraries
• Fixed Xbox 360 linker settings in Visual Studio
• Remove platform-specific intermediate objects on clean
• Bug 2819232: Buildoptions not used when creating Makefile for C#
• Bug 2813297: OS X universal config should be "univ" (William Burnson)
• Bug 2814179: Xbox 360 precompiled headers not working

A lesson learned from the development of Premake 4.1: keep your active projects specific. I mean really specific.

I started development by creating a new project, naming it Premake 4.1, and dropping in a bunch of actions from my backlog. Technically this is a valid approach; the only definition of a project I've ever encountered in this context is "any result that requires more than one action." Now older and a little wiser I realize how incredibly vague that is. Consider: Program TV remote vs. Achieve world peace. Both technically valid projects. One doable, the other not so much (which one is an exercise left to the reader).

My project started out with a reasonable list of actions, but inevitably new ideas came up, features and refactorings, bugs that needed fixing. Because my project was vague enough to encompass all of this new work it soon did, growing larger and less focused, and I started to feel like I was losing ground. Rather than stepping back and fixing it as I should, I tried crunching harder which just made the problem worse. Ack!

Looking back at this trainwreck learning experience, I've come up with some rules to help keep my projects manageable going forward:

• Projects should be a dozen actions or less, a number I pulled out of thin air based on past experience. If it requires more than a dozen steps it is probably larger than I can get my head around in one go, and likely contains hidden work. Better to split it up.
• If I have to think about whether an action belongs in the project or not, one of them is too vague. Either the action needs to be more specific (or become its own project) or the project needs a tighter focus.
• Project names should always start with a verb. What is it I'm trying to achieve with the completion of this project? That doesn't prevent Do stuff projects but it at least makes me think about it for a second.
• When in doubt, split it up.

There are probably more rules, I can't remember. I reserve the right to edit this post later.

I've been doing this for about three weeks now and while I thought it would help my planning a little, the gain in clarity has been quite remarkable. Read more...