Archive for February 2, 2015

Monday, February 2, 2015

Neil Young’s PonoPlayer

David Pogue:

The results surprised even me. Whether wearing earbuds or expensive headphones, my test subjects usually thought that the iPhone playback sounded better than the Pono Player.


The company says it has 2 million songs for sale, but 90 percent of it is in 44.1kHz format — no better than what’s on a CD. The remaining 10 percent, the good stuff, the remastered high-resolution songs, is hard to find.

There’s no way to view only albums available in high resolution. In fact, when you search for a band, a list of its albums appears — but you can’t see what resolution they’re available in until you click a button below the album art. Over and over for each album.


But maybe you’re different. Maybe you believe that high-res music has more “soul” or is less “tiring” to listen to, as fans claim, even if you can’t actually hear a difference.

In that case, you should note that Pono is not the only high-res player. It has many rivals, like the Astell & Kern AK100 Mk II, iBasso DX50, and the new Sony NWZ-ZX1 Walkman. In fact, Android phones can play the same FLAC-format files, if you get right down to it.

Sam Machkovech:

We took the Pono Player on the go for an entire day, which proved to be a bit of a logistical nightmare. This isn’t just a bad device to put in a pocket—the triangular shape feels noticeable and obnoxious in your pants pocket—but it’s also lousy in a messenger bag. The creators elected not to include a hardware “hold” button of any sort. As a result, the volume and multi-function buttons got pressed on a regular basis during our testing—meaning this thing reached its maximum, incredibly high volume level so quickly that we had to rip earbuds out. We soon opted for handheld use, which was fine enough in terms of quickly adjusting volume, skipping current songs, or pausing. However, we couldn’t disable the screen turning on every time we tapped the volume dial, and turning the screen off required holding the multi-function button down for way too long (so we reduced the auto-sleep timer accordingly).

The best thing we could say about on-the-go Pono use was that the unit fit neatly into our palm and felt like a media-player version of a drum stick. When this thing was cranked to high volume on a good song, we couldn’t help but flick our wrist along and rock out in public.

Cloak and Private Internet Access

Matt Henderson:

The killer feature of Cloak is that it will automatically connect your device—both Mac and iOS—to the VPN whenever you connect to an untrusted wifi network. Furthermore, during that short period of time between connecting to the untrusted wifi network and when the VPN service is enabled, Cloak will block all internet traffic. (How they got all that working in iOS appears to be magic. But it works!)


So in conclusion, if you connect to public wifi networks, you need to use a VPN service. Cloak provides a great user experience, and just as importantly, is designed to work even when you forget you need it. For most people, it will be the perfect solution. If you travel around enough to run into those rare situations in which Cloak has issues, Private Internet Access is a great backup alternative.

Learn You a Haskell

Miran Lipovača (via Greg Titus):

Hey yo! This is Learn You a Haskell, the funkiest way to learn Haskell, which is the best functional programming language around. You may have heard of it. This guide is meant for people who have programmed already, but have yet to try functional programming.

The whole thing is completely free to read online, but it’s also available in print and I encourage you to buy as many copies as you can afford!

Swift Resistance

David Owens II (Open Radar):

The fundamental problem with Swift, with regards to performance, is that it is impossible to reason what the performance of your code is going to be. It is impossible to know if your code is just horrendously slow in debug, or if the optimizing is going to get ride of all of the extra crap that is going on.


If most of your code is Swift code that is simply bridging into ObjC or C, you will probably read this post and not have a clue what I’m talking about. You are benefiting from the speed of ObjC.

Profiling showed that a lot of the slowness was from ARC adding unnecessary retains and releases that are only removed when doing an optimized build. Debugging is harder with optimization on, however, and the Swift compiler doesn’t let you selectively disable optimization for a file you are trying to debug.

David Owens II:

Now, had this performance been like 300% slower, I might have been able to take that and the safety justifications… maybe. At least if it was only 300% slower I’d still be in a spot where I could run my game at 30Hz with reasonable head room left over for other logic to run.

But no… we are talking about this loop taking 1 entire SECOND to compute. It was nearly 28,000% slower…


OK, so let’s be explicitly clear here: this post is not about how Swift is horrendously slow in builds you’ll be giving your customers. No, it’s about how terribly slow and painful your life as a developer will be trying to write any amount of Swift code that works on any reasonable amount of data inside of arrays in Swift. However, you can see that none of the Swift options are faster or even as fast as the C version. And frankly, none of them are really that much clearer… but that’s a different topic.

Joseph Lord:

Where I would dispute with David is his view that this is an absolute showstopper than cripple’s Swift’s usefulness. There are ways to manage without the debugger, it still works with the assembly if needed anyway and as I illustrate there are workarounds for the issue.

However in the repo I show the workaround of moving performance critical code to a library or framework that can be built optimised while the bulk of the complexity and logic in the project is run without optimisation for simplicity of debugging.

David Owens II:

The other problem with this statement (and the solution presented) is that it assumes that we can optimize the slow parts of the game by putting the code into a framework. Ok… besides the annoying mess that is to pull stuff in and out of there, and completely ignoring that this is a trivial example of one algorithm that would need to be moved, it completely misses the fact that it’s that very slow part that I need to debug because something strange is going on. If my debug build is now running at 2 or 3 Hz, it becomes extremely difficult (impossible really) to actually play to game to get the error that is to be debugged.


I do take back what I said yesterday somewhat, to the extent that:

(Apple bug 1) not only do per-file flags seem to be completely ignored altogether on Swift source files (I tried with -toto, it did not appear in the command line while building), contrary to what I implied yesterday,

(Apple bug 2) but also Swift code does not appear to be supported at the moment in static library targets (it failed when I tried and I found reports that appear to confirm this),

(Apple bug 3) and framework targets containing Swift code do not play well with command line tool targets,

I am forced to reach the conclusion that, since you can’t reasonably put it in a separate area where it can be optimized differently (and be accessed by command-line targets, which is essential for specifically testing that code instead of having to do it through an app), Swift is unsuitable for multimedia code at the time being (Mac OS X Yosemite and Xcode 6.1.1, if you’re an Apple engineer reading…). Period.


Justin Spahr-Summers’s GHRunLoopWatchdog is a class forlogging excessive blocking on the main thread (via iOS Dev Weekly).

Why Can’t Twitter Fix Their Mac App?

Matt Henderson:

When Twitter announced dropping support for third-party developers and clients, the stated justification was that Twitter wanted ensure that every user received the best Twitter experience possible, and that could only be achieved if Twitter themselves controlled all vehicles through which users experienced the platform.

Fine, but how can we reconcile that position with the awful state of Twitter for Mac today, and the fact that it is apparently receiving zero attention within the company?

React Native

Facebook’s Tom Occhino introduces React Native (via Ole Begemann, comments).

Josh Abernathy:

React Native is not a write-once-run-everywhere solution. The phrase Facebook has used so far is “learn-once-write-everywhere.” They’re interested in sharing the paradigm of React across platforms, not the code necessarily.


React let us describe our entire UI for a given state, and then it does the hard work of figuring out what needs to change. It abstracts all the fragile, error-prone code out away from us. We describe what we want, React figures out how to accomplish it.

UIs become composable, immutable, stateless value types.

Andy Matuschak:

I say with confidence as a former UIKit author: React’s model for the UI layer is vastly better than UIKit’s. React Native is a huge deal.

People asked why I like React’s model over UIKit’s: it does a better job of promoting isolation and confining effects, while being simpler.

Jordan Walke (via Nick Lockwood):

This is not the DOM. This is not a web view. If you know ReactJS, you can build native apps with React Native.

How to Mount a Disk on Startup

Ovidiu Predescu:

MacOS X Yosemite removed few capabilities that existed in previous versions of MacOS X. Notably the StartupItems feature which allowed you to run scripts when the system boots up.

On my machine I want to be able to mount an internal disk as soon as the machine boots up, but before a user logs in. A common solution in the past involved a custom StartupItems script, but this no longer works on Yosemite.

He shows how to do this with a launchd file in the LaunchDaemons folder.

Hydra Camera App

Creaceed (App Store):

Thanks to innovative capture technology, Hydra lets you take beautiful pictures even in the most difficult lighting conditions. That makes it a great companion to the built-in Camera app on your iPhone or iPad.

How does it work? Hydra merges up to 60 individual images to make a single high-quality picture, effectively getting more light from the scene. That way, Hydra produces up to 32-megapixel high-resolution images (4x the 8-megapixel sensor resolution), enhanced HDR, better 2x/4x zoom, and reduced camera noise in low-light scenes.

Sounds promising for photographing static subjects.

Prefer Composition to Inheritance

Soroush Khanlou:

But this is inelegant and we wish we could just force our users to subclass something so that we can hide this behavior away. But don’t fret! We have options outside of inheritance. To add behavior in a composition-friendly way, we use the Decorator pattern.


A particularly elegant note on this solution: the wrapper itself doesn’t conform to SKRequestTemplate, even though its parameter does. This means that if we add a new method to the protocol and try to use it from the safe template, the compiler will groan at us. It must be defined on the safe template before we can use it, and we’ll be reminded to add it there as well. Normally, with inheritance, your “contract” with the outside world includes all of your superclass’s methods; with decoration, you only have to provide what you say you’ll provide. Aaron Patterson documents a case where the rails/core team got bitten by this exact problem.