Rebuilding after all of these years!
Rebuilding after all of these years. Seriously, it’s been years since I have done a clean install… since Mac OS X 10.2 to be exact. I have been pulling all the crud I have collected over the years along with me like barnacles on the bottom of of the ship of life. And like the real thing, those barnacles have been slowing me down.
This became painfully obvious recently when I made a new user account to make some tutorial movies. The new account was *fast* and *responsive* in a way I hadn’t experienced in years. If this wasn’t evidence enough, I was having a nagging problem with [TaskPaper from Hogbay Software](http://www.hogbaysoftware.com/products/taskpaper “TaskPaper — Simple to-do list software”) where for no obvious reason, it would quite with every launch. Between Jesse and Apple they were able to nail it down to a webcam component that was not proper GC code but was pretending to be. The point is, I have no idea where I ever picked up that component or when even. It was time to nuke and rebuild.
The reason I haven’t in so many years is because I have come to rely on so many hacks over the years, things that Mac OS X wasn’t either capable of or didn’t do well enough. It was a scary thought to try and get by on a stock system or try and replicate those hacks again. For the last little while I’ve been trying to change my habits, trying to use less 3rd party hackery and find native solutions or terminal commands that accomplish the same thing.
For instance, years ago I used to use [USB Overdrive](http://www.usboverdrive.com/ “”) to ramp up my mouse tracking and and assign special functions to various mouse button combinations. When support for it waned I turned to [SteerMouse](http://plentycom.jp/ “Main Page”) which did almost exactly the same thing. But now-a-days I barely use the mouse and when I do all I really need is a speed boost which is easily [achieved in the terminal](http://www.macworld.com/article/49691/2006/03/turbomice.html “Turbocharge mice and trackpads | Mac OS X Hints | Macworld”):
> If you have a mouse:
>> `defaults write -g com.apple.mouse.scaling some_number`
>If you have a trackpad:
>> `defaults write -g com.apple.trackpad.scaling some_number`
>The some_number at the end of each of the above lines must be replaced by, well, an actual number indicating the speed you’d like to use—the higher the number, the faster the tracking will be. As a starting point, the default value for maximum mouse speed is 3.0, and maximum trackpad speed is 1.5. So you might try a starting value of 5.0 for your turbo-charged mouse, and 2.5 or 3.0 for a turbo-charged trackpad.
> The easiest way to make your changes take effect is to log out and then log in again (Apple menu: Log Out user name ).
I guess my point is this (wearing my nutMac/productivity hat), if you are going to spend any time as a developer of any sort, keep your system customizations to a minimum, install only those apps you honestly think you’ll need or use, find native solutions to mods you can’t live without, document those mods carefully and alway be prepared to do a clean install from time to time. The less cluttered your system is the better chance you have using a migration assistant so you don’t have to do it all manually like I did.
That’s where I am at now. I have spent nearly two whole days manually moving preferences and folders for the apps I need so that I can be sure not to take all the other crap with me again. Now that I have done my clean install I should have no trouble keeping it clean every six months now.
SaaS… Free… Cloud computing… Dead
It probably sounds a bit funny to lament the death of web apps on a Mac productivity blog when web apps neither scream Mac or productive. The truth of the matter is though, I was am a heavy user of many web apps, more so than most of the native apps on my machine.
Let’s see, I use a remote time tracker, Google mail/calendar/reader, todo, flickr, Twitter… See where I am going with this? Most of these apps replaced local versions of the same service, and somewhat poorly, I might add. But the all have one really big advantage in that they can be accessed from anywhere and shared with anyone so easily that a monkey could do it.
But their biggest drawback to date is causing me to rethink the value of mobile access… since they only exist in the etherweb, if a developer decides to pull the plug on a service, you’re screwed! This already happened in a pretty big way this week with the loss of iWantSandy, Stickit, and pownce.
While I was only really effected by the loss of Stickit, I was still left scrambling for a desktop alternative that could do everyhing that I required of Stickit, and it such a way that felt familar. That’s how I came to use TaskPaper from HogBay Software. Now that working remotely is not as critical to me it was in my commuting and contracting days, this desktop solution seems to be the way I ought to move with all my other cloud solutions.
To be honest, Mail.app has come a long way since I dropped in the OS X 10.2 days, I already have BusySync syncing my Google calendar to iCal.app, rss feeds are a dime a dozen and would take me long to move back to NewsFire, and there are time tracking apps that actually keep acutate record of what a am really doing and not what a SAY I am doing.
Is your computing in the cloud? Do you feel secure with your choices in software as a service providers? Do you have a backup plan if/when they pull the plug? What do you think is the perfect balance?
To be Strict or not to be
I am about to geek out so bad it will make your eyes roll back and have you snoring before you finish the first paragraph. But to be honest, it’s not for you that I write this stuff, it’s for posterity and so that I can always look it up in the future, if such a thing should ever happen to me again.
I have finally nailed down an obscure little bug in cataLog (and in turn Acumen) that was causing the second level navigation to jump up about 14 or so pixels when the user used the “Tidy” setting in RapidWeaver and when the user used code or content that tripped the “Tidy” setting into converting the document into a Transitional DOCTYPE. The reason the bug remained so illusive is that this set of circumstances was not immediately clear and is not necessarily something the end user is mindful of.
My repeated testing, assuming that there had to be a difference in the content area or navigation area, kept leading me down the wrong path. One assumes, when “Tidy” is at work, that the HTML of the document is somehow being altered or “tidied up” as it were. And this is where I continued to search extensively but came up empty handed every time. Having exhausted nearly all HTML avenues and having run countless DIFF comparisons I finally turned my attention on the one thing in each document that I knew was different; the DOCTYPE. By simply switching the DOCTYPE from Strict to Transitional, regardless of whether the embodied code was in fact one or the other, I could trigger this odd navigational occurrence.
As much as this was a major breakthrough in the tracking of this bug, I now knew that the game had gotten that much more complex. I was no longer dealing with a bug in my code or the theme as a whole. I was now dealing with what was potentially a rendering bug, or interpretational difference in the two DOCTYPE’s, meaning that the bug being presented may very well be an issue in the HTML standard itself. Eeek!
Since I knew that the navigation in question uses inline-block as a value on its display property, and since I am well aware of the lack of widespread support that inline-block has among browsers, I knew that this was probably the place to look. I need to look in the CSS of the second level navigation.
Through considerable trial and error I found that an attempt to display the ancestor, or hidden navigation inline was what was causing the trouble. In DOCTYPE Strict, the combination of ul {display: inline;} and ul ul {dispay:inline-block;} caused the initial ul to have height, despite having tried to suppress it with ul {height:0; margin:0; padding:0;} etc… While in DOCTYPE Transitional, the initial ul rendered correctly (which is to say it didn’t render at all and had no height), so the latter ul would shift up to takes it’s position. The fix was simply this: ul {margin:0; padding:0;} with no attempt at any display value other that what it would naturally inherit (which would be “block”).
So is this in actual fact a bug in the Strict DOCTYPE standard? It’s hard to say really. In the making of RapidWeaver themes, we pour a lot of effort and trickery into making things happen the way we want them too. In the case of split navigation we use the same set of code in multiple locations and simply turn on or off the bits we want shown or hidden. This probably is not a typical practice in web design but a necessity in RapidWeaver theme development. Still, why would one DOCTYPE behave differently from another where such a small property in concerned?
Mighty mouse vs. Speedy Gonzales
How can any self respecting speed freak like myself not make mention of a mouse accelerator or two. That is something that has always driven me nuts about OS X; the maximum mouse speed is just too darn slow. Back in the day when I was running OS X 10.2 on a fruity iMac with a puck mouse, I found a great little preference pane app called [USB Overdrive](http://www.usboverdrive.com/) (now supported by [Senlick](http://www.senlick.com/)). I used [USB Overdrive](http://www.usboverdrive.com/) faithfully up until a few weeks ago. It was great for making a multitude of USB devices go stupid-fast, but I only use one USB device, my mouse. What I wanted (with the onset of carpel tunnel syndrome) is a fast mouse with very fine accuracy and acceleration controls.
What I found was [SteerMouse](http://plentycom.jp/en/steermouse/), another preference pane app that allows for finer tuning of the mouse tracking speed and sensitivity, etc… it also allows for detailed button programing (up to 16 if you like). Though [SteerMouse](http://plentycom.jp/en/steermouse/) is by no means worlds apart from [USB Overdrive](http://www.usboverdrive.com/), I was pleasantly surprised with it’s interface and feature set and think I will stick with it for some time to come.
So just how fast do I have my mouse set? My mouse travels at about 180 ppi. To put that into perspective for you, I can go from adjacent corners on a 23″ HD cinema screen by moving my mouse little more than few inches; just the flick of my wrist.
[tags]USB Overdrive, SteerMouse, mouse acceleration, software[/tags]