I’d be lying if I said that dating someone as you leave college is a terrible idea. If you hit it off in the final days and weeks of school, then that’s how life played out. Enjoy every last moment you get, and don’t hate yourself or the circumstances for being inconvenient.
While this won’t make graduation any less bittersweet, at least I’ll have some fantastic memories of my final months and weeks here. I can’t think of a better send-off as I leave.
From warpedvisions.org » Blog Archive » Quote: Good breakage
“I like an escalator because an escalator can never break, it can only become stairs. There would never be an escalator temporarily out of order sign, only an escalator temporarily stairs. Sorry for the convenience.” Mitch Hedberg
The Escapist just did a very intriguing interview with Jason Rohrer on design, development, and perfection.
After pushing an app out the door earlier this semester (CPU History), and actively developing the website at my part-time job (at VBI), I understand the fine balance between timeliness of release and striving for perfection.
When writing CPU History, I knew there were certain things that absolutely, positively had to be correct: the values for CPU usage had to be both timely and accurate: an app that lags a half-second behind what’s really happening is useless.
Other parts, however, weren’t so critical. I wrote CPU History primarily because Activity Monitor in Leopard took 18-22% of my total CPU on my iBook G4. Knowing two things, I decided that multicore support wasn’t on my list for a 1.0 release: I was on a single-core system, and when my new MacBook Pro arrived, I could afford the CPU cycles to run Activity Monitor instead.
(Small aside: the limitations of Activity Monitor’s history graphing, especially with no way to change display color, bar width, or update frequency are driving me slightly insane, however, and I will be refining code from @dsandler to get full dual-core support up and working.)
I released CPU History 1.0 with a few known bugs, too. Adjusting the update frequency or other graphing preferences clears the graph history, for example. It wasn’t a catastrophic bug (which I define as anything that causes data loss, corruption, or makes the app so unusable as to make it useless to the user), but it was bothersome, and it drove me to spend an hour regressing the bug so I could accurately reproduce it. I tried digging into the code a bit to see why it was happening, but it quickly became clear that it lay in the interaction between code I had written and some parts of Memory Monitor that were reused with no alterations. I decided to back off and release the app as-is: releasing the 1.0 was more important.
Perfection, while achievable, would mean never shipping anything out the door. There’s a fine balance between tolerating a minor issue in the interest of getting something out the door, and stopping everything else to fix a catastrophic bug
This preference pane deserves a whole blog post. SmartSleep is a tiny preference pane that changes the sleeping behaviour of any Mac that supports hibernation. Here’s some quick background information (skip the next two paragraphs if you know how hibernation works).
By default, new Intel-based laptops save part of their RAM to disk every time they’re put to sleep (all active pages not all ready in on-disk virtual memory, and all wired pages, for the VM nerds out there). If the machine loses power while it’s asleep (battery drains, or because of a battery swap), OS X is able to read in the hibernated memory contents and restore the current state of the machine, thereby preserving all open work, documents, applications, et cetera.
As you might imagine, on machines with 2 or more GB of RAM with more than a few applications open, this can take a while (upwards of 30-40 seconds). When you consider that new MacBook Pros come with 2 GB standard, and most users don’t need this “safety net”, there’s a plethora of hints and widgets online for turning off hibernation to make the machine sleep faster.
But this means that hibernation is permanenly turned off when you need it most: when your battery is very low. SmartSleep takes care of all that. It lets you set the typical modes: “sleep and hibernate” (the out-of-the-box behaviour for OS X), “sleep only” (so hibernation is off), and “hibernate only” (can’t think of a time I’d use that, but it’s there anyway), but it adds one more: “smart sleep”. “Smart sleep” puts the machine to regular sleep if the battery is above a user-specified percentage. Below that percentage, it changes to “sleep and hibernate”, and below 5% or less than 5 minutes remaining, it changes to hibernate only (I disagree with that decision).
I have my machine set to “smart sleep”, and the percentage set to 10%: the vast majority of the time, I don’t need hibernation turned on, but if I’m on campus, run my battery down to 3-4%, and it’ll be several hours before I’ll find a charger, it’ll hibernate memory and save whatever I have open (thereby protecting me from the remaining battery power draining while the machine is asleep).
SmartSleep is fantastic: Apple should build auto-switching of hibernation modes into OS X in the future.
Jonathan Rentzsch showed us the anti-caps lock bias of the new Apple aluminum keyboards. With the arrival of my new MacBook Pro today, I’ve observed the same bias with the built-in keyboard: the caps lock keys have to be pressed and held down to turn on caps lock, but will turn off caps lock with the slightest press. Apple to bloggers, IRC denizens, and email authors everywhere: STOP YELLING.
Today marks the release of my first application for Mac OS X: CPU History. CPU History is a 10.5-compatible shameless ripoff of Apple’s original CPU Monitor, which I used in 10.2 to 10.4, but stopped working in 10.5.
CPU History is designed to do one thing, and do it well: graph your CPU usage history. It graphs the user, system, nice, and idle usage in the Dock icon, and optionally in a window which can be set to float above all others. CPU History lets you change the update frequency and the bar width, along with setting colors for each type of CPU usage.
Activity Monitor is a resource hog for this simple Dock icon graphing: between Activity Monitor and its pmTool background process, the two consumed 15-20% CPU on my iBook G4 in 10.5. By comparison, CPU History consumes 0.8-1.2%.
CPU History 1.0.1 is available over at its new home on cbowns.com, along with a git repository of the source code.
Much thanks to Bernhard Baehr and Peter Hosey for their applications, Memory Monitor and CPU Usage. Thanks to their source code, I was able to graft pieces of each onto the other and come up with a useful new application.
Toast 8, a CD/DVD burning utility for the Mac, introduced a new feature: when you add files to a data CD above what a single disc can hold, it offers to burn them onto separate discs. When I went to back up (and remove from my hard drive) about 40 GB of ripped DVDs, this looked like a fantastic feature. However, I wanted to make sure that, should I need to use the discs on a PC, on a Unix machine, or on a newer or older Mac. I couldn’t let myself be tied to a platform, OS, or application.
Fortunately, Roxio has ensured that, short of losing one of the discs, you’ll be able to get at your data somehow.
First, Toast copies a text-editable Disc Index.plist to each disc, hidden at the root level of the drive, gzipped to save space. It’s identical across all discs in the session, so any disc has a complete copy. It contains a dictionary of all the files in the session, including their size, whether they’re invisible, their date modified, whether to copy them onto a PC, and for a spanned file, the discs on which to find the file.
I first tested the included Mac version of their disc spanning utility: it simply copies the pieces of the files and concatenates them together (more on that in a minute). The discs also include a Windows exe, though I haven’t tested it. The spanned and remerged files emerging from the utility are, as you would hope, binary identical to the original.
Initially, I was wary of using disc spanning: a proprietary utility to reassemble files? An unknown format to recover them from? But it turns out that their utility is a very pretty interface for a couple of simple Unix commands. By concatenating together the two (or more) pieces of the files, in order, you produce an exact copy of the original file. I tested this on a split AVI: cat file1.spanned > testfile; cat file2.spanned >> testfile; md5sum testfile originalfile; will produce identical MD5 checksums.
So, at the end of the day, I went ahead and burned a 10 disc session of movies to DVDs. If I lose any of the discs, sure, the data is lost and the remainder is unrecoverable, but I have a list of what was lost in the Disc Index.plist, and can BitTorrent as needed to replace it. Would I span a disk image with a backup across two pieces of media? Probably not without burning two or three copies of the session, and testing each. But for movies, it’s a great way to back them up.
Inspired by warpedvisions:
“It’s all geek to me.”
(Dear reader: I’m sorry. It’s finals, and I’m scraping the barrel for something to post here. I swear, I’ll make it up to you after this is all done.)
We have our PHP error logging turned back to E_ERROR | E_PARSE_ERROR. Why, you ask, if it’s in the log, and it’s good to know what’s going on? Why, because if we turn on E_ALL, the logfile grows very fast (!) and the server goes down when it’s over 2 GB.
*shakes head* WHAT?!? That’s the dumbest thing I’ve heard today. Either fix your damn errors so a logfile doesn’t kill things, or have a cronjob take care of log rotation/compression/deletion. Good god.
Rixstep just published an article about why spatial file navigation doesn’t work in today’s file systems: there’s just too many files. And if you assume you’re trying to assign a unique location on screen to each folder, you’re absolutely right: you’d have to be insane. But navigating in (for the moment, we’ll use the OS 9 Finder as our benchmark, seeing as OS X’s brokenness) Ye Olde Finder, I never have more than a few folders open at once, and when I do, they relate to each other. What are the odds that I’ll be opening ~/Documents/Desktop Pictures at the same time as /usr/share/lib? Or, for that matter, why in the world would I navigate the Unix underpinning (/bin, /dev, /var) with Finder at all? Any manipulations I want to perform on the contents of those folders are only available in a shell to begin with, so why bother navigating through them spatially?
I suppose that very flaw may be part of their argument, but, if you separate out navigation into “Duh, use zsh” for the Unix underside of OS X, and, “Let me drag and drop my files!” in ~/Documents or ~/Desktop or ~/Pictures, spatial navigation becomes more useful. I’ll say it again: spatial navigation makes blindingly obvious sense in certain cases, and just because it doesn’t work everywhere doesn’t mean it never works anywhere.
© Inert Detritus. Powered by WordPress using the DePo Clean Theme.
