Archive for category Code
I’ve been using a new MacBook Pro with Retina display for the past week or so and it’s by far the best Mac laptop upgrade in quite awhile. For various reasons I’ve used a whole bunch of different Mac laptops over the past few years leading up to it:
- Pre-unibody 15″ MacBook Pro
- 13″ unibody MacBook Pro (core 2 duo)
- 15″ unibody MacBook Pro (i7 dual core)
- 13″ MacBook Air (i7 dual core)
- 15″ unibody MacBook Pro (i7 quad core)
Of these, everything up through the last 2011 MacBook Pro was not a desktop replacement. In fact, the inability to be one is what pushed me towards the MacBook Air to at least have something light and small for travel and meetings since at both work an home I had separate 27-inch iMacs for the heavy lifting. The quad-core MacBook Pro with an SSD upgrade and ability to take 16GB of RAM finally made a totally viable desktop replacement again, and became pretty much the only computer I used for the last six months. But, it was painful after having embraced the MacBook Air to be back to such a (relative) clunker. Since most of the features continuing to date the unibody design were things I had long given up using (optical drive, ethernet, firewire) I was more than ready for a slim MacBook Pro without these.
The Retina MacBook Pro was is this plus a whole bunch of display awesomeness. It’s nearly the agility of a MacBook Air with RAM, CPU, and storage that performs like a really fast desktop. But the display… well, having spent a lot of time using retina displays on the iPhone and new iPad it’s exactly the beauty you’d expect, now happily married to desktop tasks like software development. As an iOS developer, it especially stands out having Xcode and the iOS Simulator quietly render all of the Retina assets at full quality using the @2x versions just like the real device would, and working with high-res assets in Photoshop is also a joy. But even simply scrolling and reading tons of text (an inescapable part of writing code) is much easier on the eyes with the Retina display, and of course everything about the core OS just looks great with it as well.
I was also surprised by how useful the other scaled HiDPI resolutions are. Going up from the Retina default of 1440×900 (which is perfectly doubled) to 1680×1050 (the old 15″ hi-res native resolution) is quite readable and sharp, great for lots of workspace when the MBP is your only display. Going up to 1920×1200 still stays quite clear in terms of scaling but is a touch small for my taste, and 2880×1800 – absolute native resolution, and only achievable through a third-party display utility like SwitchResX – is quite absurd, really only good for marveling at what your display is capable of and then quickly changing back to avoid a headache!
Of course I obviously don’t miss the lack of optical, ethernet, or firewire, but beyond the slim form factor and display my favorite sleeper feature has been finally having a multitude of external display ports. While single thunderbolt works well for a cinema display or iMac in target display mode, a basic side-by-side setup of multiple 1080p LCD’s (a cheap and common desktop setup) always required some imperfect solution until now: either get a display splitter that connects two displays to the single DVI connection and acts like one giant desktop across them (menu bar and dock with a monitor edge down the center? no thanks), or connecting one natively and sacracifing the other to a very mediocre and laggy DVI-over-USB connection like DisplayLink. But with the new MBP it’s possible to connect not just two but three external displays, all with full hardware-accelerated capability.
It’s worth mentioning that the flash storage is ridiculously fast as well, but having already converted to exclusive use of SSDs over the past couple years I can’t say I noticed a difference; it’s just something that finally comes standard without a ridiculous add-on price or need for a third-party drive swap anymore. Battery life seems as good as the previous MacBook Pro which is not stellar but good enough (I’m going to be charging this thing every day anyway), and other minor upgrades like better speakers and inclusion of USB 3.0 are handy but not something I use on a daily basis.
If there is one downside to the Retina display it’s probably the unavoidable glare of a glossy screen, and while it’s a huge improvement over the earlier MacBook Pro’s (and from what I can tell, also a tad better than the recent MacBook Air), side-by-side with a matte screen in front of any direct window light or unfortunate overhead fluorescent lightning it’s still quite obvious. I’m sure this would bother me more in a typical corporate office, but since I’m using it for now at a scrappy startup loft, random coffee shops, or on the couch at home it hasn’t been a problem. But on the flip side I can’t say I use the display for watching a whole bunch of movies where the glossy finish might shine either so it’s sort of a non-feature for me.
A supposed downside I keep reading about is the lack of upgradability. There were basically two things the last MacBook Pro let a user easily upgrade: the storage drive and RAM. While not user-upgradeable now, it’s a reasonably-priced BTO option to include 16GB of RAM (the most that could be upgraded with current sticks and two RAM slots anyway), and of course the built-in flash storage, while expensive, is equally fast and high quality. For a laptop I’m going to replace every 1-2 years anyway this is more than a fair trade for slender, light form factor, and having already embraced it with the MacBook Air it doesn’t bother me at all.
Overall, if a Mac is your daily laptop you will love the Retina MacBook Pro. It’s a huge upgrade and undoubtedly sets the bar for a new generation of power-user laptops led by Apple.
After a couple months of hard work I’m proud to see MobileDay in the App Store! If you join or create conference calls from your iPhone check it out and share it with others. It’s a great tool for easy one-touch calling to any conference service from any meeting in your calendar and we have much more to come! You can also read more about the company and app at mobileday.com.
I recently posted steps for setting up iOS unit testing with Jenkins, but working on a new project realized I wanted to take this a step further and start seeing code coverage metrics. The configuration has evolved quite a bit but fortunately there’s a great Code Coverage with Xcode 4.2 guide from Infinite Loop that covers this and seems to work with both Xcode 4.3 and 4.4 in my testing. Be sure to check the included links, related posts, and followup in comments for troubleshooting various errors that creep up across different Xcode versions. Once tests have been run against instrumented code you can view the coverage output graphically in CoverStory on a Mac. Finally, if you want to convert this output to Cobertura-style for display in Jenkins using gcovr you’ll want to configure your Jenkins build as described in iOS Code Coverage, Cobertura and Jenkins. Good stuff!
I don’t usually get deep into the fray on iOS vs. Android. Yes, I’m a completely devout Apple fan myself: I use a Mac at home and work, own pretty much every other Apple device on top of that, and have such a strong iPhone preference that I happily eBayed not one but both Androids I got for free at Google IO a few years back because, well, after a week of serious benefit-of-the-doubt were still worthless pieces of junk compared to my aging iPhone 3G that could actually join WiFi networks and check my corporate email. And then a month later I bought an iPhone 4.
But again, I usually don’t go out of my way to rant about this. Tonight is an exception. I’m working at a startup again that’s heavily focused on mobile applications and as such am getting quite a bit more plugged in to the Android experience, even though I’m still doing the most hands-on work with our iOS offerings. To that end it was high time I ditch the simulator and start running our Android app on a Real Device for some side-by-side comparison, and today picked up a brand new Droid Razr for the task. Even though I’m basically planning to use the device for nothing beyond Phone, Email, Calendar, and our in-development application, I thought I might indulge in one tiny personalization and set the wallpaper to a recent photo of my kid. I’m a proud dad after all, and spend a hell of a lot of time staring at these screens. That’s where the fun began.
As an Apple user I’m of course all synced up with Photo Stream and iCloud but that doesn’t help me much on my new Android. No worries though, I also use Flickr to share with family and have lots of great original-size photos in albums there. This will be a piece cake! Paging quickly through the installed apps and device setup wizard I find, of course, Picasa and Photobucket but no Flickr. Oh well, guess I lost to the OEM dice on this one, so over to the Market to grab the Flickr app. The app crashes on launch. Not Android’s fault I guess, the Flickr guys probably just have better things to do than make their Android app stable and obviously the Market will let you publish anything. On second launch I’m able to access the login screen, and being on an Android figure I’ll use the option for Google auth since that’ll probably be seamless. Alas, it kicks me over to the same generic Google web SSO screen I’d see in a browser – even though I have entered my Google ID in at least five places on this phone – and it’s an Android FFS.
Just as I’m about to start typing my email address something else catches me eye. The keyboard has a little microphone key at the bottom! I know this key, it’s there on my brand new iPad and hails all manner of bleeding-edge voice recognition at my disposal. So I click it and humbly but articulately recite my beloved email address. The phone thinks briefly and seconds later comes back with a perfect match. That is, a perfect match that is completely useless in this field and would be so much work to edit that I end up just clearing the field and typing it anyway: it had entered, literally, “dustin dot mallory at gmail.com”. What could be a more glaring UX failure than engineers who have so perfected this fast, accurate recognition yet it has absolutely no clue I’m in an email field? Especially considering that the field asserts this specifically – which is why I’m seeing an emailish keyboard and not the generic text keyboard – is wiring up the same basic context to the dictation button too much to ask?
I suspected not, so of course I immediately jumped over the the Flickr login screen via Google auth on my iPad. And again, I used the dictation button and recited “dustin dot mallory at gmail dot com”. Guess what it entered? You’re damn right it did. That’s how a device is supposed to work!
But the fun doesn’t end there. This filled me with such glee I thought I’d take some screenshots so I could show my wife, rage-blog about it, and poke fun at everyone using an Android at the office tomorrow. So I quickly pressed home and sleep to grab an iPad screenshot knowing it would immediately be synced via Photo Stream to my Mac for easy access. I would probably have to email the Android version, but whatever, I can handle email. I wonder how I take an Android screenshot? Seems like there were issues with it when I tried it on those phones from Google a couple years back but I’m sure it’s better now after, what, three major versions of the OS. So for kicks I try a few combinations of the power button, the side button, and whatever the hell you call those four buttons along the bottom where my home button should be. Nothing. I poke through the apps and settings looking for something screen capturish. Still nothing.
I pull up the Market and search for “screenshot”. There are definitely a handful of apps that do it, but most have sketchy reviews and all-caps warnings that U MUST ROOT UR PHONE 4 THIS 2 WERK. Really? So I download one of the free ones just to try it for myself. I clearly picked a loser not only in its ability to take screenshots successfully but also at engaging in the English language. For the guy who wrote this thing’s sake, I really wish someone who cared was reviewing these apps and giving some pointers in the right direction.
I consider shelling out 4.99 for the super pro version that will work, guaranteed, even if I don’t want to root my phone or speak English. But then I remember that I have an iPad that actually works sitting next to me, so I just take a couple physical physical pictures of it the old-fashioned way and they’re ready to go. Not just captured, but happily synced over iCloud, already over on my Mac, so I can finally rage-blog to my heart’s content.
Don’t worry Apple. If there was any remote chance I might stray from my aging iPhone 4 to this shiny new imposter it was obliteated not just by the epic failure I ran into doing something so basic, but the somber realization that this is no longer a bleeding-edge technology being adopted only by uber geeks like myself as it was a few years ago, it’s mainstream with years of experience, vendors, and community behind it. A whole pile of things contributed to the failure you’re seeing here, but the platform surely enabled most of them. Then again that never stopped something from gaining cheap, grudging acceptance by the masses even though it sucks, and making both the peddler and their OEM cronies a pile of money in the process. Just ask Microsoft. But I’m glad Apple is (finally) making more because it’s well deserved.
Now back to doing something fun on my iPad.
After installing the OS X 10.8 Mountain Lion Developer Preview I noticed that while git and svn both worked independently, I started receiving the following error trying to use git svn:
Can't locate SVN/Core.pm in @INC (@INC contains: /Applications/Xcode.app/Contents/Developer/usr/share/git-core/perl /usr/../Library/Perl/5.12/darwin-thread-multi-2level /usr/share/git-core/perl /Library/Perl/5.12/darwin-thread-multi-2level /Library/Perl/5.12 /Network/Library/Perl/5.12/darwin-thread-multi-2level /Network/Library/Perl/5.12 /Library/Perl/Updates/5.12.4 /System/Library/Perl/5.12/darwin-thread-multi-2level /System/Library/Perl/5.12 /System/Library/Perl/Extras/5.12/darwin-thread-multi-2level /System/Library/Perl/Extras/5.12 .) at /usr/libexec/git-core/git-svn line 61.
It turns out the path for the svn perl library has moved as part of the Xcode 4.4 restructuring. Since most package managers like Homebrew or MacPorts may not work correctly on the 10.8 preview yet, and the CollabNet svn binary installer is also not updated, it’s easiest to continue using the versions of git and svn bundled with the Xcode 4.4 command line tools and adjust the perl include path to work with the new layout.
To do this:
- Ensure that the Xcode 4.4 command line tools are installed (this is now done from within Xcode under Preferences -> Downloads -> Components).
- Add the following environment variable (or append to it as needed if you’re already setting it elsewhere):
After this git svn should work correctly again!