A Post From an iPhone
I’m writing this on my phone. Not because I have to, but because I can.
I just realized that my first day at Apple post never went up like it was supposed to that morning. I guess I can rewrite and publish it late. Way late.
I’m writing this on my phone. Not because I have to, but because I can.
I just realized that my first day at Apple post never went up like it was supposed to that morning. I guess I can rewrite and publish it late. Way late.
I ventured with our summer intern to the Los Gatos Apple Store early on Friday morning: we were in line by 4 AM, and were numbers 23 and 24 in line. We were back at Apple by 9 AM, iPhone 3Gs in hand: we both got the 16 GB model. I went with white (didn’t you hear? It’s the new black!), while he opted for fingerprint-revealing black.
When our iPhones finally unlocked for use and synced with iTunes later that afternoon, the Great App Store Purchase Binge began. I’ve bought somewhere between 30 and 40 apps: most of them have been free, but a few weren’t. Here’s my recommendations in no particular order (and a couple of games that everyone needs to try):
I have one suggestion for developers: in the application’s info on the App Store, post a link to a fifteen or thirty second screencast demo of the app. There’s several apps that I was unsure of, such as Cubes, but seeing a gameplay demo made it obvious that I would enjoy it. This goes for all developers, not just game devs: we want to see how the app works, what the flow is like.
All told, I’ve spent 63 dollars on the App Store so far. Most of the money has gone towards the ten dollar applications like Twitterrific and Exposure Premium. I think most developers are leaving gobs of money on the table: I’d have paid more for Cubes, Masyu, and other games, and applications like Instapaper could charge several dollars and I’d buy them. (Instapaper may have a premium version coming out in the future with more features.)
The maxim of Mac development still holds true for App Store apps: charge more now, you can always lower your price later.
(Edit: My apologies: comments were closed earlier; they closed automatically after 2 weeks. They’re open now.)
CPU History 1.0 was an obvious work in progress. It shipped without multicore support, with a redrawing bug, and with a horrid preference window design. The first two bugs were fixed months ago, when I pushed a beta of 1.1 to a few multicore testers. However, the third bug wasn’t on my radar until Peter Hosey (@boredzo) brought the Apple Human Interface Guidelines (HIG) to my attention.
Without further ado, here’s the 1.0 preference window.
The list of things wrong with this layout is longer than the list of things right. Inconsistent spacing, and no attempt at vertical alignment of labels or controls.
When I added features (namely, multicore graphing) to 1.1, I had to add another control to the preferences. Hence, the 1.1 b1 preference window.
This is the release that compelled Peter to link me the HIG writeup on laying out windows. And rightfully so.
After an hour spent massaging things in Interface Builder, here’s the first 1.1 redesign. (I’ll call this 1.1 b2)
I fixed vertical spacing between elements, horizontal alignment of labels and controls, and a few other tweaks. It was primarily a HIG-compatible spacing fix to the 1.1 b1 layout.
Still, the layout just felt wrong. I visited #macdev on IRC to consult some other developers, and two suggestions surfaced. First, a tab-based layout (from ciaren and ccgus), and a boxed layout (a combination of my thinking and ccgus’s view idea). I set out to implement the tab-based layout first.
That’s tabs one, two and three. I split things based on logical separation: general, floater preferences, and color choices. However, as is evident on tab three, I couldn’t find a good layout in that tab that used the space required by tab one. Onward, then, I ventured, to fix another layout shortcoming.
The separations from the tabs made logical sense, so I wanted to keep those while junking the extra whitespace of the tab layout. So next up was a box-separated (NSBox) layout.
This is the current leader in the window design, and most likely what I’ll be shipping tomorrow. It had the right mix between an all-in-one window, which removed whitespace issues with tabs, and clear splits between controls of different types.
Edit: I posted this three days ago, but Google Maps URLs didn’t cooperate, so here it is, better late than never. Apologies for the technical difficulties.
We landed earlier today in Los Altos. I’ll be in a room in a four bedroom house here for about two weeks, doing a short commute to Apple starting on Monday, June 23. Then, it’s relocation to a room in a six-bedroom house in Woodside, further up I-280 from Apple. I’ve got that room from July 1st to mid-September.
Today was spent on The World’s Windiest Road, Rt. 1. Here’s the route on Rt. 1 and 128, but here’s a detail of Rt. 1 at the beginning. We had to stop twice for driver and passenger nausea.
We drove across the Golden Gate Bridge this afternoon as we headed towards Los Altos. Tomorrow morning, we head back north towards Wine Country. Monday will be spent tripping around San Fran, and Tuesday we have a tour of Alcatraz early in the morning, likely followed by another day in the city. Eric flies out of Oakland International on Wednesday morning, and I have a few days before starting work.
5600 miles from DC to San Francisco: certainly a more scenic route than usual.
We’ve now traveled over 2500 miles. I haven’t totaled gas receipts, but Eric and I are estimating over 350 dollars so far. Thank god for large credit lines with American Express.
Since the last post, we’ve traversed three more states. The morning of the 27th, we headed north from Omaha, through Iowa and into South Dakota. We spent the night camped out at the Badlands. After waking early for sunrise pictures (forthcoming), we visited the Minuteman site off I-90, swung through the ring road back through the Badlands, and headed west. A trip to Mount Rushmore was punctuated with storms on the way, but as we approached the mountain, the skies cleared. The drive through the Black Hills was quite pretty, and I took several photos out the sunroof of the car.
After arriving in Cheyenne for the night and sleeping there, we spent yesterday on the road, stopping often for photos and gas. We made a quick visit to Radio Shack and an Acura dealer in Denver to work around a burned-out cigarette lighter that happened on day one. The rest of the day was spent trekking across Colorado, over some rather large mountains, and then off I-70 to take a backroads trip to my aunt and cousin’s house near Telluride.
It’s the end of day three.
We spent Tuesday traveling to Chicago (a 680 mile haul), and all day Wednesday tagging around the city and watching the Cubs win against the LA Dodgers.
Today was spent traveling to Omaha (480 miles) to stay with a friend of Eric’s. Tomorrow morning, we go north to South Dakota, visiting and camping at the Badlands (low tomorrow night: 50° and breezy). Friday is spent at the Badlands, Mount Rushmore, then south to stay the night in Cheyenne, Wyoming.
Photos will be processed on the road tomorrow, and a large Flickr upload will hopefully happen sometime this weekend when we surface again on someone’s wireless. Best bet for updates between now and then is Twitter and Flickr mobile uploads. Cheers.
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.
© Inert Detritus. Powered by WordPress using the DePo Clean Theme.