A Los Angeles Slytherin

I was in the city and saw this car. I’m pretty sure the best part is the broom in the bike rack but the reference to page 394 was pretty good too. This post is an excellent companion piece to my encounter with Obi Shawn.

MPU 73: Podcasting How and Why

Mac Power Users Episode 73, Podcasting, How and Why, is live. We’ve been receiving requests for a nuts and bolts podcasting show since the beginning and I’ve been resistant. It seems to me a lot of people don’t really care. This show did, however, give me a chance to talk yet again about that fantastic talk John Gruber and Merlin Mann did at SXSW, which is always fun. Get the episode over at 5by5. Also, don’t forget to subscribe in iTunes.

Markdown Service Tools

Recently, I’ve switched my billing workflow in the day job over to markdown. As a result of the way I’m jumping between platforms, I’m not always getting proper markdown line breaks. (to force a <br> code in markdown, you need to insert three spaces before hitting return.)

So I wrote my friend Brett Terpstra yesterday lamenting this hitch in my giddyup and Brett wrote back in ten minutes explaining: 1. This is solvable with a service; 2. He already solved it. Today you can download it with the latest update to Brett’s Markdown Services. These are so ridiculously useful. I ♥ Brett.

Citizens United Explained

“A democracy cannot function effectively when its constituent members believe laws are being bought and sold.”
Citizens United v. FEC, 130 S. Ct. 876, 954 (2010) (Stevens, J., dissenting)

This whole thing makes me nuts. When the next presidential election goes completely bat-shit crazy (it will), go back and read this explanation of why.

Sandboxing and the Mac App Store

As I met with developer friends at Macworld this year, a common discussion point was Apple’s forthcoming implementation of sandboxing on the Mac. As part of the continuing effort to keep the Mac secure, Apple is preparing to require that all apps sold through the Mac App Store comply with Apple’s sandboxing rules. Sandboxing in Mac OS X is the process of requiring apps to obtain permission for access to different parts of your Mac’s memory and file system. For instance, if you are create a text editor app, you shouldn’t need access to the Mac’s Address Book database. Indeed, making an app that seems harmless but then grabs and uploads personal information and data is exactly the kind of behavior Apple seeks to prevent. In essence, sandboxing partitions the different areas of your Mac only giving software developers access to those particular assets their apps reasonably require. A photo editing app, for instance, will not get access to your admin files. A calculator will not get access to your documents folder. I’m simplifying, but you get the point.

As such, Apple is adding sandboxing to Mac OS X. Sandboxing makes a lot of sense. It worked out really well for iOS and now Apple wants the same level of security on the Mac. However, there still are a lot of questions. For instance, what about apps that necessarily need to work across your Mac? Macro applications and text expansion tools work within several apps and, by their very nature, need access throughout your system in order to serve you. Likewise, some of our favorite productivity apps use small menu bar apps to provide an ever-present gateway into their functionality. Another example are FTP clients that allow you to upload files from anywhere in your computer. All of these applications are incredibly useful. Unfortunately, it also appears that all of these applications would violate of Apple’s looming sandboxing rules.

Nothing is in stone yet. The policy hasn’t been made final or implemented. However, the writing is on the wall and longtime Mac app developers are concerned. Is Apple’s efforts to implement sandboxing going to kill their apps? Nobody knows: everyone is worried.

At some point, Apple is going to throw the switch and start vetting all apps submitted for sale in the Mac App Store. Apps that don’t meet the sandboxing standards, it appears, will not be sold through the Mac App Store. This is a serious problem for app developers as users become more and more accustomed to buying their applications exclusively through the Mac App Store. (I buy nearly all of my apps there.) Moreover, it is not beyond the realm of possibility that one day the only way you can buy an app will be through the Mac App Store.

Sandboxing was originally set to begin in November, 2011. As both Apple and developers struggled to understand exactly what this meant, the deadline was pushed back further. Frankly, having talked to several developers, it seems like there is still a lot of confusion over sandboxing and, in my opinion, this should get pushed back to the next major Mac OS X release, 10.8.

While I have no objection to the idea of sandboxing on the Mac, I hope that Apple doesn’t throw out the baby with the bathwater. From the outside, it appears that the Apple steamroller is gassing up and a lot of our favorite apps are sitting in its path. I believe there is a middle path here. Sandboxing can work if Apple is willing to consider being reasonable with apps that necessarily require broad access to your Mac, particularly from established developers. Maybe the reason this keeps getting delayed is because Apple is internally figuring out how to make that happen. Regardless, I can report that many developers are agitated about the possibility of sandboxing rolling them over in the future. I can only hope Apple will use enough foresight to keep that from happening. It would be a shame if we lost some of our favorite apps in this effort to make the platform more secure.

So as users what does all of this mean for us right now? It is hard to say. We could be looking at a serious threat to some of our favorite software or we could be tilting at windmills. Hopefully it is the latter not the former. In the meantime, as a software purchaser, this causes me to pause with respect to purchasing applications in the Mac App Store. While generally I’m a big fan of the Mac App Store, when it comes to apps that could potentially tread on the sandboxing rules, I’m hesitant. My concern is that they will eventually be banned from the Mac App Store, and any licenses I purchased there will no longer be available to me. As a result, if it’s an app that may run afoul of these new rules, buy it from the developer directly for now. Maybe in six months this will work out and not be a problem, but why take the risk?

Sponsor: kooaba Shortcut

kooaba Shortcut is a shortcut between real life and the Internet. Take a picture of what you are reading in a newspaper or magazine and instantly get connected to the digital version.

Using image-recognition technology, Shortcut recognizes what you’re reading. Once recognized, you can share the digital version of the pages via Facebook, Twitter, SMS, and email, or store them in Evernote. This works with over 1,000 newspapers and magazines worldwide. (See http://www.kooaba.com/products/shortcut for a list of publications.)

Shortcut also works with advertisements in newspapers and magazines, and billboards with the Shortcut icon. After taking a picture of such an ad, you gain access to extras such as coupons, sweepstakes, or store locators.

With Shortcut you no longer need to type links into your phone, google for information, or cut out articles – Just take a picture instead!

Shortcut is available for iPhone, Android, and Windows Phone 7.

Speculative Developers

Between the day job and visiting Macworld, I’ve spent a lot of time with application developers over the last several months. I think because I’m a Mac user, I have an idealistic impression of software developers. They are artists. They sweat the details. They work long days making beautiful things for my Mac, iPad, and iPhone that make it possible for me to get the things done that need getting done.

For the software I truly love and use all the time, I still believe this is true. From the smallest one-man shop, like Marco Arment’s Instapaper, to the larger developers, like The Omni Group, there are indeed developers out there who fit this idyllic view.

My revelation the last few months is the large number of developers who don’t work this way. In particular, I’ve bumped into several iOS developers with a different view of software development. I call them “speculative developers”. I always knew speculative developers existed but witnessing them work first hand is something else entirely. They barf out as many apps as possible in the shortest time possible in hopes that they strike gold in the App Store lottery. They run a never ending treadmill with little thought about the user experience except (sometimes) making sure their apps don’t crash. Some of these “developers” don’t know a lick of programming code. Instead, they are fountain of ideas with a group of somewhat ambivalent programmers on speed dial in India, Russia, and other far away places.

I “get” their business plan. There are a lot of apps on the App Store. It’s really hard to get noticed. They think the more apps they submit, the more likely they are to find lightning in a bottle. They are, however, completely wrong. Their chance of hitting it big with two (or twenty) crappy apps instead of one good one is about the same as their chance of retiring with their lotto winnings. Infinitesimally small.

If you want to develop apps, take your time and make something awesome. Make it fast. Make it beautiful. Make something you’re proud of. Don’t make 60 crappy apps: Make one really good one.