a glob of nerdishness

Someone posted a lengthy article today (here, and cross-posted here) claiming that even though Snow Leopard ignores creator codes, applications can use Uniform Type Identifiers to match a file in a generic format to a specific editor. As far as I can tell, someone is wrong on the internet.

There are two potential problems with expecting UTIs to take the place of creator codes as the article claims. The first is that applications are not encouraged to make their own app-specific UTI if one already exists. Consider the case of a JPEG file, which is a common format that many apps can open. With creator codes, an app that creates a JPEG file could make it easy for the user to re-open it later in the same app by setting its creator code. In common practice, an application would just be using the predefined “public.jpeg” UTI when dealing with JPEG files, instead of an app-specific code, as Apple had never encouraged otherwise.

Using an application-specific UTI even when a predefined one exists is a clever idea. Update: no it’s not. Doing so would mean no other app could open your app’s files. That would be bad, too. Or it would be, if not for the second problem. A file’s UTI is determined by Launch Services, and there isn’t a good way for an app to set one itself. (I would love to be wrong on this!) When Launch Services needs to know a file’s UTI, it looks at the file’s extension and picks just one of potentially many matching system and application defined UTIs.

Launch Services’ behavior in this regard is no better than file extensions. It’s worse, in fact. Consider a “.log” file: This common extension could be used for a system log, an application history, a GPS tracklog or any number of file types. If an application lets a user open any file with the “log” extension, it will be able to open its own files just fine. If, on the other hand, an application wants to use the new, shiny, recommend UTI system and offers to open files with UTIs of “com.example.tracklog” instead, it sets itself up for failure. If Launch Services has decided that the “.log” extension means “public.systemlog”, all .log files will have that type and the user won’t even be able to open a file from within our tracklog application itself.

Uniform Type Identifiers are a neat concept, and I recommend you use them. They do offer many advantages, including the potential to eventually replace creator codes in a future version of OS X. But you must use them with care. The main pitfall is Launch Services. You can use UTIs and UTI concepts so long as you always keep in mind that a file may have a completely different UTI on a user’s machine than it does on yours. When creating an open dialog, include the extensions you may be able to open in addition to UTIs. When defining a document type in your Info.plist, use the old (deprecated!?) CFBundleTypeExtensions instead of LSItemContentTypes. Otherwise, another application on your user’s system could end up overriding your extension’s UTI and your application will be unable to open its own files.

Launch Services should really report a different UTI based on which application is requesting a file’s type, or report a set of all potentially matching UTIs instead. This would affect some file-handling parts of the Cocoa framework as well. I reported this problem with the current way file UTIs are assigned in rdar://problem/6590416 this past February. I hope it can be fixed, because Uniform Type Identifiers are a win in the long run.

Mike Ash just finished another accurate and detailed series covering an interesting low-level topic, this time explaining all about Grand Central Dispatch.

Apple’s thread pools help reduce processor contention, but I’d been mulling over how to best use queues for performing file operations optimally. Mike nails it in this last post: create a hierarchy of custom queues that end up funneling operations through one custom queue per disk. It’d be interesting to wrap this technique in a higher-level API that dealt with disk and other bottlenecks in a more automatic manner.

My iPod touch’s home button was growing gradually unreliable, and finally stopped letting me switch between apps right before this week’s iPod press event. I was hoping Apple would finally announce a new iPod touch that could serve as an iPhone without the phone, with a camera and mic and compass and GPS. Instead they announced the opposite.

This was the second time the iPod touch’s home button had failed me. The first one failed under warranty, but between two bad hardware experiences (actually three, long story…), a lack of compelling new features, the lack of independently published applications and my own lack of income, buying an expensive replacement seemed like a bad idea.

Instead I spent $3.98 to have OWC ship me some nylon iPod case opener tools. Once inside I found a lot of lint, dozens of tiny screws and chips and connectors, and underneath it all:

My iPod’s home button!

I used some rubbing alcohol on a q-tip to clean it and its target off a bit, then used a very short slice of electrical tape to hold the little clicker sticker back in place.

Take a look at this iPod Touch repair guide for a better walkthrough of the internals. Because of the way the lower assembly is glued down, the screen does need to be taken off to safely pry the button board from its sticky bondage. There was dust under the glass anyway, so it was nice to get a PEC*PAD in there for some cleanup.

In addition to the case opener (good for prying PCBs from their glue as well) and a very tiny Phillips screwdriver, I found a brownie cutter useful. Its large surface area helped me pry up the battery pack without the acute pressure of a flathead’s blade; a metal spatula or wide paint scraper could work as well.

After reassembling most of the device, I was relieved and more than a bit surprised to see it spring back to life. Despite the second-rate button, some impressive engineering went into this device. It is incredibly small, yet was able to survive an hour of my (very careful!) amateur hamfisting. I can now return to my Home screen at will; all other systems are still go, too!

Trail Location is a subproject I’ve been working on at Calf Trail. Its primary goal is to be a drop-in replacement for Core Location that can use position data from any location service.

This enables a number of new possibilities.

But first a demonstration

More interesting location data in the simulator

Testing a Core Location app in the simulator is really boring. Apple might eventually wire the simulator up to Snow Leopard’s Core Location implementation, but that would just move your app from Apple’s headquarters to yours. Trail Location lets you send your own test data, which your app receives just as from Core Location.

Trail Location includes a sample app for your device that can send locations to the simulator as you pan around the map. It should also be easy to make an app that plays back recorded location patterns.

Send real GPS data to an iPod touch during development

This one’s a bit more complicated, but worth mentioning. The first two iPod touch models (hopefully NOT the third, but we’ll see) don’t have GPS chips and rely exclusively on Skyhook positioning, which is based on visible wireless networks. With Trail Location, you can use a laptop and a GPS receiver for better results in rural areas. (I bought an Amod ABG 108 Bluetooth GPS mouse for about $20! Unfortunately, you can’t use a Bluetooth GPS directly even with a second-generation iPod touch, because it would degrade the core experience or something.)

Trail Location includes a sample Mac app that can pass locations from gpsd to a listening iPhone app via WiFi.

Better Core Location on the desktop?

Snow Leopard adds the Core Location API to Mac OS X. This is interesting, because while on current hardware the Core Location framework itself is still limited to Skyhook positioning, the rest of the Mac platform is much, much more developer friendly. Trail Location could serve as the glue that connects third-party apps to third-party GPS receivers using the same well-designed API that Core Location provides. Just like you can use your device to send data to Trail Location on the simulator, you could use an iPhone as a GPS mouse for a desktop app.

Eventually, I hope Trail Location can grow mature enough to be left in code that ships to end-users, giving more people the benefits of an open location platform. Currently, you should consider it as an alpha release, NOT ready for anything but debug builds. Right now the code is overbuilt (debatably) but under-implemented (definitely). We’ve released it now so that it can help other developers test their Core Location apps, and so that any progress towards the long-term goals can be influenced by other developers. Get the source at Google code; it’s shared under a non-viral license but your patches are welcome.

This post, subtitled “Intellectual Property for the Independent Developer”, was originally put together as a Blitz talk submission for this year’s C4 conference. I was reminded by the latest Core Intuition podcast to share it here.

Intellectuwha?

As creators, we have this sense of ownership over our work. This concept has many legal “implementations” under a framework known as Intellectual Property. Intellectual property (IP) is a blanket term for the idea that it’s not just wrong to steal Suzie’s crayons, but it’s also wrong to rip off her work as well.

Intellectual Property rights help one monetize their mind. Unlike physical property, violating someone’s IP rights doesn’t rob them of the thing itself, but it does deprive them of control over how — and for how much! — their work is used.

Disclaimer

I should make one thing clear: I am NOT a lawyer, and this is not legal advice. There’s a lot of depth and detail in this realm, these concepts are an architecture whose requirements keep shifting, and my advice here may not be in your best interest.

This post is a high-level overview of a few specific IP rights. I’m defining them based on my understanding of US law. Most other countries have similar protections, but they differ in the details.

Copyright: Control your creations

Copyright is for creative work, like programs and icons and documentation. These things are way easier to copy than they are to make, so the law says that creators have the right to decide — to control — what copies are made and under what terms.

It’s actually the owner who controls the work. Ownership can be transfered (talk with your graphic designers about it) and if you’re employed or doing contract work you’ll want to make sure it’s clear who owns the things you create.

Most of the time as an independent developer, you’ll want to share copies of your work, so long as you profit somehow. When you “license” your software or source code, you get to set the terms for that to happen the way you want. For example, if your binary ends up on one of those shady “pay $4 to download” sites you may be able to use your copyright and/or trademark rights to have it taken down.

Trademarks: Control your brand.

Trademark is for your “brand elements”: company and product names, identifying logos and slogans, even elements of industrial design (like the iPod’s shape). You are given some control over them to prevent misuse.

You automatically get trademark protection as soon as you start using a brand; you can draw attention to that with the little ™ symbol. Copyright is similar; it’s an automatic right upon publishing. But with both, if you can afford to register, you get better weapons in court (at least in the US, where IP law is biased towards larger interests).

Trademarks don’t give you complete control. People can still criticize your brand using your own trademarks, for example. Copyright has some fair use exceptions, too. Remember, there’s a lot of depth to IP law. All of this is just legal control: you still may need to pay lawyers and go to court to claim (defend, really!) your rights.

Patents: Control your HOWTO (for a while)

Speaking of paying lawyers! A patent is basically a HOWTO with benefits — you reveal and explain a new mechanism or method, in exchange for about twenty years of control over your specific invention. Patents are the nuclear weapons of the software business…they’re expensive to file and even more costly to deploy in court. It’s typically only large corporations who can afford to parade their patent portfolios, though little rogue nations do like to ride the bombs down now and then.

Trade secrets: Control your knowledge (forever…maybe)

Trade secrets are probably a better solution than patents for most indies. You can control this form of IP as long as you can keep it a secret. Most legal systems provide penalties against leaks, but once the damage is done, you have lost control.

One way to encourage secrecy is through the use of Non-Disclosure Agreements. Some *cough* companies do NDAs in a big way as a sort of trade secret bunker around their patents, but indies can make use of the same legal protections of these contracts to control things like beta releases and details about under-the-hood secret sauce.

IANANAL

In some ways, Intellectual Property is the bedrock of the software business, and pressing it to full advantage might yield good financial returns. But my unofficial, could be wrong, might be bad, advice is to take it easy. Know your rights and don’t violate others’ rights, but don’t forget what keeps you in business either. One great part of the indie ethos is the desire not to control the world, but to contribute to it.

“Create more value than you capture” is a phrase Tim O’Reilly often uses, and I think it’s an apropos motto when it comes to Intellectual Property. Here are a few ways that you can use your IP rights to contribute, rather than control. You aren’t in the indie Mac community long before you see these practices in action:

• Respect your customers
• Spread knowledge
• Share source
• Boost others’ brands

Al fin

I think it’s important that developers have an awareness of their rights and their responsibilities regarding Intellectual Property, so I hope this was a helpful overview. If you’re looking for further reading, I’ve got a growing list of bookmarks tagged with iplaw and related terms that may be of interest.

Call this the second of a two part series. The first looked at the past, and now you get a glimpse of THE FUTURE!

Tobias Vander Wilt will be one month old this weekend, and d.v. will grow up faster than we can imagine.

It’s my hope that, whatever his occupation, he’ll have the freedom to wholeheartedly serve our creator, discovering — and sharing — innovative responses to what is broken in this world. And it’s my hope that even if doing so goes against powerful interests, he’ll still do right.

It’s been a little over a year since Calf Trail Software, LLC was formed, and a nearly a year and a half since I started working at it full time. I must have learned a lot in those months, even though it always seems I’ve barely scratched the surface of writing software and running a small business.

Mercatalog was my first project, and its biggest lesson was the cost of too much research. I spent a year working out solutions to dozens of problems, in the scope of just one release. Before I had barely begun to succeed, the application became largely unneeded.

From that experience, and from that code, another app was born. Geotagalog is already the easiest tracklog-based geotagging utility on the market, and will only get better through its next major version. Watching Geotagalog gradually gain fans has been teaching us patience and persistence.

…”us” being me and Calf Trail co-founder Jon Hjelle. (And my wife Hannah, who has been helping us with our artwork, and learning patience while we try to make something resembling a living off of this calling!) While I’ve been focusing on the desktop apps and the website, Hjon has been busy developing Resistulator, Cheap GPS and Inbugz, as well as keeping our store and servers running.

It’s been a good year in many ways, though we have yet to even recoup all of our initial expenses. We’ve learned enough to make some good products available, but are still learning how to let people know about them. Besides continuing to grow as programmers and marketers, it’s quite likely we will also offer our iPhone and Mac programming skills as contractors in the coming year.

So there’s a lot of excitement in just my job these days, but that’s not all. I hope to share details regarding another source of excitement and responsibility here soon!

If you follow the Apple news/rumor sites, you’ll have heard that Apple has been (pre-)releasing software like crazy lately. I can neither confirm nor deny these rumors. Between my marginal ISP and the dank, dusty cellars underneath Apple’s public website, I get plenty of half-finished large downloads regardless of what Apple is up to.

When Safari thinks it’s finished downloading an incomplete file, I like to use curl to finish. My usual trick isn’t enough for the Apple Developer Connection’s password-protected files, and it took me a while to figure those out. Eventually, with the help of two helpful posts and some trial-and-error, this is the method I’ve settled on:

1. Copy partially downloaded file if it’s fairly large (because sometimes I mess up)
2. Log into ADC in a browser, and copy the download link
3. curl -c $(mktemp -t curl) -L -o '<Partially Downloaded File>' -C - '<Download URL>'

It is very important to quote the Download URL, because it may contain special shell characters! This is the main reason I copy the partial download; I don’t want to blow away a large partial download with a bit of error page HTML.

This works as follows: -c $(mktemp -t curl) tells curl to keep track of cookies in a temporary file, and -L means to follow redirects. The downloaded output file is specified via -o and -C - means to continue at the offset where this output file stops. I don’t include an option to automatically retry on failure, because if the session expires this could lead to a loss of the newly appended data if the download is replaced by an error page.

Recently the topic of selections in Cocoa apps came up again. While most of the discussion has centered around selections in text, the majority of sane developers use AppKit’s built-in text views and leave it at that. However, when we were developing Mercatalog’s interface over at Calf Trail, we needed to handle mouse selection and dragging of photo icons in a consistent way. Not only did our map and timeline layers need to behave similarly, they had to work like the rest of the operating system.

Cocoa leaves selection handling completely up to each individual view. As our view code developed, we realized that this task was less trivial than it first seemed. Playing around with various views in other apps to determine the “correct” behaviour was even less encouraging — there are many selection idiosyncrasies among Apple’s applications and views.

So we tried to solve the problem once and for all, in a separate class intended to manage selection and drag source behaviour for any view/cell/layer that needs it. It’s mostly geared towards mouse selection at this point, but Calf Trail is making it available as open source in the hopes it will spark discussion and progress towards good selection behaviour. You can find details and source for TLSelectionManager on Google Code.

I tend to let perfectionism get in the way of progress in my software development. This can happen on many levels:

• coding *too* carefully, not leaving any time to write tests or leave good notes
• delaying new code to overdo structure, even though refactoring is always inevitable (and usually fun!)
• overplanning an architecture, in ignorance of all the problems it will *actually* have to solve
• constantly trying to re-”decide” if a product is worthwhile, instead of seeing what users think
• worrying about mastery in a given domain, before even setting foot in it

This isn’t to say that I don’t try to do my best at all levels. It’s to say that time spent practicing — time spent making mistakes and learning from them — is rarely time wasted. Sometimes I catch myself spending as much time trying to make the best decision as it would take to actually try one good option or another. Other times I don’t catch myself!

Is perfect the enemy of better? Grace is someone willing to pay for my mistakes themselves. I see many of my weaknesses as a programmer and designer, I know there are more I don’t see, and I’m not proud of any of them. My pride ends up working against itself, though. There is just enough grace in the world for me to waste time not making mistakes when I should be making things better.