Archive for December 15, 2014

Monday, December 15, 2014

NSPPL: Persistent Property Lists

David Smith notes that in 1998 Apple removed the NSPPL class from Foundation and open-sourced it. Today, property lists can be serialized in XML and binary formats. In both cases, these are chunks of data that are read and written atomically. The old NeXT system supported ASCII plists as well as a lazy binary format and a persistent property list (PPL) format that supported incremental access and caching in memory:

You can store a property list in three different ways: as an ASCII file, in a serialized binary format, and as a persistent property list (PPL). Each of these approaches has its advantages. For example, an ASCII property list is human-readable, but access is slow. Serialization, which stores property lists in a binary format, offers faster access than an ASCII property list and it’s also lazy, meaning that you can read parts of files without accessing the whole thing. But serialization doesn’t allow you to modify your data and then only re-serialize the part that changed.

Like serialization, a persistent property list stores data in a binary format, provides fast access, and is lazy. It also allows you to make incremental changes to an PPL (even one that contains tens of megabytes of data), while still ensuring that your data is never corrupted. In this sense, an PPL is analogous to a database. Because of their ability to incrementally store and retrieve data, PPLs are particularly well-suited for working with large amounts of data (that is, data that has several elements, that occupies a large number of bytes, or both).

After creating an NSPPL, you could read or write to it by using the -rootDictionary method to get a mutable dictionary proxy object (with its own lazy NSEnumerator).

Persistent property lists are atomic, meaning that if a save operation fails, the PPL reverts to its previously saved state. An PPL is never left in an intermediate state. Changes to an PPL are applied incrementally (in memory, but not to disk) as you make them and are reflected in the store and log files. A save operation has the effect of committing the changes you’ve made to disk.

The file extension for the store was .ppl, and there was a ppl command-line tool for converting between persistent and ASCII property lists.

Hopper + lldb for iOS Developers

Bart Cone:

Have you ever wondered how people get pseduo-code of some private API like the image below? It’s actually very simple and is a great way to chase down those annoying bugs in UIKit or some other binary you don’t have source code for. Getting this pseudo-code can literally be accomplished in just a couple clicks with a tool such as Hopper. What’s even cooler though, is we don’t have to stop there. With the Obj-C runtime and lldb we can make the pseudo-code even more readable if not syntactically correct!

The Dawn of Trustworthy Computing

Nick Szabo:

On the Internet, instead of securely and reliably handing over cash and getting our goods or services, or at least a ticket, we have to fill out forms and make ourselves vulnerable to identity theft in order to participate in e-commerce, and it often is very difficult to prohibitive to conduct many kinds of commerce, even purely online kinds, across borders and other trust boundaries. Today’s computers are not very trustworthy, but they are so astronomically faster than humans at so many important tasks that we use them heavily anyway. We reap the tremendous benefits of computers and public networks at large costs of identity fraud and other increasingly disastrous attacks.

Recently developed and developing technology, often called “the block chain”, is starting to change this. A block chain computer is a virtual computer, a computer in the cloud, shared across many traditional computers and protected by cryptography and consensus technology. A Turing-complete block chain with large state gives us this shared computer. Earlier efforts included state-machine replication (see list of papers linked below). QuixCoin is a recent and Ethereum is a current project that has implemented such a scheme. These block chain computers will allow us to put the most crucial parts of our online protocols on a far more reliable and secure footing, and make possible fiduciary interactions that we previously dared not do on a global network.

Aperture Exporter

Aperture Exporter:

There are plenty of guides on the internet detailing how to get your images out of Aperture and into another photo manager such as Adobe Lightroom. It’s a multistep and complicated process that is easy to get wrong. Aperture Exporter consolidates the process into just a few clicks and provides features not possible with any manual process.

Aperture Exporter is also a great way to back up your Aperture Libraries in a format that is not reliant on the future use of Aperture.

Exporting will always generate files for your originals without adjustments. Versions with Aperture adjustments baked-in can be generated optionally.

Hack Transpiler

Facebook:

Today, we’re proud to announce a first, experimental release of h2tp, or the “HH (Hack) Transpiler,” a tool which allows projects that have converted from PHP to Hack to still make releases that target the PHP language.

[…]

But transforming Hack code using collections is not merely about using equivalent constructs from the hacklib library. For example, on HHVM, empty Hack collections universally convert to false when used in a boolean context, something a standard PHP object can never do. This means that any arbitrary expression or statement that involves a boolean comparison, or any cast, might invoke this special rule if it involves a collection. So unless the expression being treated as boolean is trivially not a collection, we have to treat it as if it might potentially contain a collection. Hence, we have to be very cautious when making transformations.

[…]

In a few rare cases we actually have to choose not to support a feature. For instance, we do not support Instance variables using literal syntax in the class declaration.

Software Subscriptions

Alex Tyagulsky:

Every successful software product in the world is subscription based. It might sound wrong, but it’s true and I am going to prove it.

[…]

Whatever the case may be, the fact is that if you rely on a certain software, you’re paying for it regularly, not just once. And this in and of itself is a kind of subscription.

[…]

Subscription-based models in a competitive market are a rare example of a win-win situation for both consumers and companies. Any product you use single day requires you to pay in some way, whether with your money or personal data. We are just being honest with you and aim to create the best in class software that will save your time and money.

How Broken is Discovery on the App Store?

Gedeon Maheux:

The following list was generated by a manual App Store (iPhone) search on Nov 15th, 2014 for the term “Twitter”. To make the list easier to parse, I’ve called out all apps that allow a user to directly read AND post to Twitter in bold. Everything else is either a game, a utility, or some other social network enhancement. The official app from Twitter is naturally the first result, but the next actual Twitter client (Hootsuite) doesn’t appear on the list until #20 and the next one after that comes in at #62. Even the mega-popular Tweetbot isn’t returned in the results until position #81 and even then, the older v2 of Tweetbot (for iOS 6) comes first. Where’s Twitterrific? Although it contains the word “Twitter” in the app’s name, Twitterrific isn’t seen in the list until you scroll all the way down to #100.

[…]

Every app in bold on this list should precede every other app (save the official client) in the results. This is especially true of apps that are not optimized for iOS 8, yet some apps built for iOS 6 (not iOS 7, 6!) come first. Why? Why games appear on this list at all is a mystery, they are by far the least relevant and don’t even get me started on #18 “Alarm Clock HD” and #93 “Jedi Lightsaber” (really?). Twitter’s own Vine app doesn’t appear here until #34 and some would argue it should be result #2, and rightfully so. It’s obvious that Apple’s search algorithm needs adjusting so it’s weighted not towards downloads or popularity, but relevance.

Finding apps for a small niche category like Twitter clients is relatively easy. Imagine how hard it must be to find a particular game in the vast wilderness that is the App Store if you don’t know exactly what you’re looking for. Until Apple decides to take definitive steps to improve search results, either via human curation, or by lowering dependencies on popularity, easy discovery in the store will continue to be a major problem. Unfortunately for small developers who need paying customers to survive, time is quickly running out.

Update (2014-12-17): Marco Arment:

You can see similar ranking problems with almost any common search term. I searched earlier today for an iPad Instagram client — the iPad App Store search list for “Instagram” is just as spammy and unhelpful as this. I was only able to find what I was actually looking for by searching Google and asking people on Twitter.

Nick Heer:

It’s so bad that it‘s almost as if it’s programmed to be deliberately obtuse. If the App Store were a barista, it would bring you a wrench instead of your coffee and then come around to your house a few weeks later to take it back for unclear reasons.

Update (2014-12-18): John Gruber:

It has always been the case that a Google web search for “whatever iPhone app” provides far superior results to searching the App Store for “whatever”. Sometimes the difference is as vast as perfect (Google’s results) and useless (the App Store’s), as we can see searching for “Twitter iPhone client” in Google and “Twitter” on the App Store.

Lucien W. Dupont:

This is how bad App Store search is. 3rd in search for TurboTax [is Turbotax, below Blackjack Domination].