John Markoff (via Matt Levine):
System engineers at Nasdaq, the New York-based stock exchange, recently began testing an algorithm and software that they hope can synchronize a giant network of computers with that nanosecond precision. They say they have built a prototype, and are in the process of deploying a bigger version.
[…]
Because the orders are placed from locations around the world, they frequently arrive at the exchange’s computers out of sequence. The new system allows each computer to time stamp an order when it takes place.
As a result, the trades can be sorted and executed in correct sequence. In a networked marketplace, this precision is necessary not only to prevent illicit trading on advance information known as “front-running,” but also to ensure the fair placement of orders.
[…]
Because software and data are no longer in the same place, correctly calculating the order of the events that may be separated by feet or miles has become the dominant factor in the speed with which data can be processed.
Financial Syncing Time
Scott Porch:
The podcast business has been wringing its hands for years about when a “Netflix for podcasts” would emerge to generate subscription revenue for contact creators–either in place of or in addition to advertising revenue. Now CastBox is introducing a paid-podcast platform similar to Stitcher’s Stitcher Premium–though, technically speaking, both resemble Hulu—allowing subscribers to pay a little bit extra to ditch the ads—more than Netflix.
[…]
Currently, Apple is the closest thing the podcast business has to a Netflix–albeit one which doesn’t charge–but dominant players don’t dominate forever. Apple Podcasts and iTunes’ share of the U.S. podcast player market slipped from 69.3% in May 2017 to 63.3% in May 2018, according to data provided to Fast Company by podcast hosting company Libsyn. That six-point slide was largely Spotify’s gain, and Google’s new Google Podcasts app for Android is entering the market at a time when smart speakers like Google Home are just beginning to show up in the listening metrics.
Matt Birchler:
I believe the “Netflix of podcasts” nomenclature is misleading. Netflix disrupted the video market by making it cheaper and easier to watch the movies and TV shows that you love, and to do it all form a unified interface. It’s already cheap to listen to the shows you love in the unified interface of your choice, and it’s pretty darn easy to find the shows you want. The types of services suggested by Stitcher and CastBox would make listening to podcasts less unified, cost more, and Mayne, just maybe be a little easier to subscribe to. You know, how Google Meet only works in Chrome for some stupid reason, or how many sites only worked in IE6 years ago.
Update (2018-07-03): Marco Arment:
Nobody wants a “Netflix of podcasts”.
Producers already control their own distribution and monetization, and have no reason to add middlemen.
And listeners don’t want to use (or pay for) many separate apps and services to get all of their podcasts.
Advertising Business Podcasts Web
Jeff Johnson (tweet):
I’m going to discuss one change in the Objective-C API, because it is both illustrative and egregious. In the 10.14 SDK, the Objective-C constants NSOnState, NSOffState, and NSMixedState have been deprecated:
typedef NSControlStateValue NSCellStateValue NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSControlStateValue", 10_0, 10_14);
static const NSControlStateValue NSMixedState NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSControlStateValueMixed", 10_0, 10_14) = NSControlStateValueMixed;
static const NSControlStateValue NSOffState NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSControlStateValueOff", 10_0, 10_14) = NSControlStateValueOff;
static const NSControlStateValue NSOnState NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSControlStateValueOn", 10_0, 10_14) = NSControlStateValueOn;
Notice that these Objective-C constants were introduced in the 10.0 SDK. They’ve been around for the entire history of Mac OS X.
Kevin Ballard:
This change is good even ignoring Swift because it makes the constant consistent with the vast majority of other SDK constants. This makes it more discoverable, easier to remember, and is much better and less confusing for people new to AppKit.
Jeff Johnson:
It seems pretty clear to me that the original Cocoa API designers made the conscious choice to put the most important and informative part of a symbol name first rather than last.
This is a legit philosophy. You may agree or disagree, but in any case it’s consistent.
It was, but they’ve been gradually reversing the order in the names since before Swift existed. In most cases I think this is for the better, although in the interim it means that Cocoa has been internally inconsistent for a long time.
The two points I would add are:
NSControlStateValueOn may be easier to discover or understand, but it’s worse to read: longer and with the most important part at the end. Aside from the practical concerns of breaking builds, documentation, and sample code, I think renaming this commonly used constant everywhere will make the code read less well. There’s a balance to be struck between competing concerns. The same arguments in favor of this change could also apply to renaming YES to something like NSBooleanValueYes or BOOL_YES, but I think people would agree that would not be beneficial.
Adding the new names does solve some real problems, but I’m not sure that removing the old ones does. Perhaps they shouldn’t fill up the autocomplete menu, but I don’t see why they have to become compiler errors. Am I greatly bothered by this? No. I’m not personally going to be confused by this, and most of my new code is in Swift, anyway. But it does seem unnecessary.
Jeff Johnson:
Seriously, though, imagine a newcomer, how do they learn? A good way is to download sample code. Except the sample code doesn’t get updated frequently, so their first experience with AppKit and Objective-C is deprecation build warnings. How would you feel about that as a learner?
Cocoa macOS 10.14 Mojave Objective-C Programming Swift Programming Language Xcode
Aral Balkan (via Matt Birchler):
Before Twitter, before algorithmic timelines filtered our reality for us, before surveillance capitalism, there was RSS: Really Simple Syndication.
[…]
Time was, you couldn’t browse the web without seeing RSS icons of all persuasions gracing the façades of Web 1.0’s finest. This was before they were mercilessly devoured by the tracking devices … ahem … “social sharing buttons” of people farmers like Google and Facebook.
There was also once a push for browsers to auto-detect and expose RSS feeds. Currently, none of the major browsers appears to do so.
Andy Baio:
Google ostensibly killed Reader because of declining usage, but it was a self-inflicted wound. A 2011 redesign removed all its social features, replaced with Google+ integration, destroying an amazing community in the process.
The audience for Google Reader would never be as large or as active as modern social networks, but it was a critical and useful tool for independent writers and journalists, and for the dedicated readers who subscribed to their work.
There are great feedreaders out there — I use Feedly myself, but people love Newsblur, Feedbin, Inoreader, The Old Reader, etc. But Google Reader was a community and not easily replaced. Google fragmented an entire ecosystem, for no good reason, and it never recovered.
Previously: Google’s Lost Social Network, Google Reader Over and Out, Google Reader Apocalypse.
Update (2018-07-05): Nick Heer:
Badges, buttons, and links to RSS feeds used to be all over the web; now, they’re almost like a nerd calling card — it’s an indication that a website is cool with an audience reading new material on their terms. I’d like to think there’s a certain confidence in a website indicating to its readers that it doesn’t need a precise count of how many people visited the website, nor does it need all the tracking and surveillance nonsense that comes with that.
Google Reader History RSS Web
Owen Williams (tweet):
I’m back to say I was wrong, and I’ve found a machine that not only matches Apple’s standard of hardware quality, but goes far beyond it to demonstrate how a laptop of the future should work.
That machine is the 15-inch Surface Book 2 and somehow Microsoft has made the 2-in-1 that Apple should’ve been building all along, to the same level of quality I’d expect from anyone other than Microsoft.
I’ve used the Surface Book 2 as my daily computer for three months now and it’s consistently blown me away with how well considered it is across the board, how great the software works and has completely converted me into the touchscreen laptop camp.
Update (2018-07-04): Marco Arment:
The Huawei Matebook X (the one with the pop-up camera in the function keys) looks and feels like it’s an entire generation ahead of Apple.
13.9” 3000x2000 screen, almost no bezel, in the same size and weight as the 13” MBP. A nice-feeling low-travel keyboard. 2 USB-C, 1 USB-A.
If this ran macOS, I’d buy it in a second.
The Surface Book 2 is also the real deal. Massive 15” 3:2 screen, detachable to a great-feeling tablet with a great pen that stows easily.
Touch/tablet-hybrid laptops aren’t just the future — they’re the present. Apple’s either being coy about future products or is in denial.
Hardware Microsoft Microsoft Surface Windows
