Replacing Rdio

I guess we’ve all heard of the impending demise of Rdio.

As one of the 500k subscribers with good taste in their streaming apps, it’s now time to consider a replacement. Here are my criteria – some of them may vary for you, but it’ll hopefully give you an idea for how you can choose, too.

Must Have

  • Offline sync to mobile (I listen to music when I’m flying a lot)
  • Ability to play from my Mac (I listen when I’m working)
  • Ability to play on Sonos (the rest of my house)
  • Family accounts

Should Have

  • Desktop App (I kill my browser pretty regularly, I don’t want that to interfere with my music)

Nice To Have

  • Android Auto support (I don’t have an Android Auto device, but I’m likely to buy one in the near future)
  • Account sharing instead of family accounts (it’s cheaper, and my wife and I mostly don’t use the account in different locations at the same time)

Given that the death of Rdio was most likely due to its lack of market share, I decided to only go with major players – this quickly narrowed it down to Google Play Music, Apple Music, and Spotify.

Google Play Music

Out of the box, Google Play Music does okay – it has an excellent selection of music, the mobile app isn’t terrible, and it works on Sonos. YouTube Red is supposed to be pretty nice, too, but it’s currently not available in Australia.

It falls down heavily when using it on my desktop, though. There’s a Chrome extension to hook into my keyboard media buttons, or there are third party apps available, none of which are very good.

Finally, it becomes completely unusable to share with my wife – I obviously can’t sign into my Google account on her phone, and Google still don’t have family accounts (though they have been announce as “coming soon”).

Apple Music

I’ve never had a good relationship with iTunes – it’s always been a clunky beast, and my recent experiments seem to indicate that not much has changed, except for a re-skin of some of the UI. It feels really hacked together. It is a native app, though, so it wins points by not being associated with my browser.

The family account was super janky to setup, I found the UI kept dying on me. Eventually I got through, however, and I hopefully will never need to touch that again (famous last words…).

On the bright side, the Apple Music app for Android is really nice, despite being a recent beta release. There’s no word on if it supports Android Auto, but that’s not an immediate requirement for me, so I’m happy to let it go.

Spotify

Spotify’s biggest benefit is that it’s not attached to a personal account. Unlike with Google or Apple, my wife and I could share the same account, without needing to share our personal logins. It’s cheating the system slightly, but it’d save us $6/month, so I’m not too concerned about it.

Spotify’s apps have been severely ugly in the past, but the good news is that the Android app is much more useable now. Unfortunately, I was unable to try out the OSX app, because the downloader was broken. The web app requires Adobe Flash, which is a total non-starter.

Conclusion

In the end, I chose Apple Music, for two reasons. One, it was the only one with a desktop app that actually worked. And two, it’s the only service that I can play Taylor Swift’s 1989 on. If the other services can’t get their act together enough to negotiate for a popular album to be on their service, then I’m concerned about their future ability to do so.

I may end up needing to re-evaluate this decision, particularly if the Sonos support doesn’t happen before Rdio finally closes it’s doors (I’m maintaining my Rdio account just for that). But for now, this will do.

The Basics: The Age of Entitlement

The first new album from The Basics in several years, and it’s a good ‘un.

They’ve been making use of their time off – Wally became an international star as Gotye, Kris spent 2 years working in Kenya with the Red Cross, and both Tim and Kris ran for parliament in the recent Victorian state election.

Now, mix those experiences together, you have an idea of what’s on the new album. A combination of politically aware rock, both locally focussed 1 with Whatever Happened To The Working Class?, globally focussed with Tunaomba Saidia; and some Gotye-esque pop such as Good Times, Sunshine!.

Anyway, listen to it now below, then go out and buy it.

  1. Is it too much to call them a modern Midnight Oil? I don’t think so. ↩

How I Would Solve Plugin Dependencies

lol, I wouldn’t1.

1. If I absolutely had to, I wouldn’t do it the same as Ryan.

WordPress isn’t (and will never be) Linux

ZYpp is the dependency solver used by OpenSUSE (and its PHP port in Composer), it was born of the need to solve complex dependency trees. The good news is, WordPress doesn’t have the same problem, and we shouldn’t create that problem for ourselves.

One of the most common-yet-complex issues is determining how to handle different version requirements by different packages. If My Amazing Plugin requires WP-API 1.9, but Your Wonderful Plugin requires WP-API 2.0, we have a problem. There are two ways to solve it – Windows solves it by installing multiple versions of the dependency, and loading the correct version for each package. This isn’t a particularly viable option in PHP, because trying to load two different versions of the same code in the same process is not my idea of a fun time.

The second option, which ZYpp solves, is to try and find a mutually compatible version of the dependency that each plugin can use. The biggest problem with this method is that it can’t always find a solution. If there’s no compatible way of installing the libraries, it has to throw back to the user to make the decision. This isn’t a viable option, as 99.999*% worth of users wouldn’t be able to tell the difference between WP-API versions 1.9 and 2.0, and nor should they.

But there’s a third option.

Technical Debt as a Service

Code libraries are, by their nature, developer facing. A user never really needs to know that they exist, in the same way that they don’t need to know about WP_Query. In WordPress Core, we strive for (and often achieve) 100% backwards compatibility between major versions. If we were going to implement plugin dependencies, I would make it a requirement that the code libraries shoulder the same burden: don’t make a user choose between upgrades, just always keep the code backwards compatible. If you need to make architectural changes, include a backwards compatible shim to keep things working nicely.

This intentionally moves the burden of upgrading to the developer, rather than the end user.

What Version?

If we’re going to require library developers to maintain backwards compatibility, we can do away with version requirements (and thus, removing the need for a dependency solver). If a plugin needs a library, it can just specify the library slug.

Better Living Through Auto Updates

If we were to implement plugin dependencies, I think it’d be a great place to introduce auto updates being enable by default. There’s no existing architecture for us to take into account, so we can have this use the current WordPress best practices. On top of that, it’s a step towards enabling auto updates for all Core releases, and it encourages developers to create backwards compatible libraries, because their library will almost certainly be updated before a plugin using it is.

Let’s Wrap This Up

I’m still not convinced plugin dependencies is a good thing to put in Core – it introduces significant complexities to plugin updates, as well as adding another dependency on WordPress.org to Core. But it’s definitely a conversation worth having.

Oh Hai ?

 

Rohan Victor

Rohan Victor Pendergast, born 18:33 on 10/5/15.

Boy and Bear seemed to be what got him moving, so here they are now.

(PS: Should you ever find yourself in such a position, I highly recommend finding a hospital that gives the parents champagne for having a babby on Mother’s Day.)

JSON Encoding in WordPress 4.1

Earlier in the year, we noticed a problem with JSON in WordPress. The JSON spec very explicitly notes that it only supports UTF-8, whereas WordPress can use any character set that MySQL supports. So, for sites that didn’t use MySQL’s utf8 or utf8mb4 character sets, this generally presented itself as json_encode() returning false; which resulted in either invalid JSON being returned from an Ajax request, or a JavaScript error in some embedded code.

To fix this, WordPress 4.1 now includes a shiny new function that we recommend for all plugins and themes:

wp_json_encode()

Usage for wp_json_encode() is identical to json_encode(). It works by trying a json_encode(), then checking if that encoded properly. If it failed, wp_json_encode() will go through whatever lump of data you passed to it, convert it to UTF-8, then return it as JSON.

Have fun with WordPress 4.1, and see you next year for new and exciting functionality coming to a WordPress install near you!

Let’s have a chat about Reddit

Reddit AlienBefore I start, I should warn you that I’ll be commenting on some of the awful things that Reddit implicitly condones, which include sex crimes, animal abuse and what can euphemistically be described as “disrespectful” behaviour towards the dead. I know these topics can be traumatic for people, so if you’d prefer to avoid reading them, please close this window.

Continue reading “Let’s have a chat about Reddit”