Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2021

Gruber weighs in on the rumored iTunes reboot:

What do you see when you open the Spotify or Pandora apps? Just the streaming music you have access to. That makes them less complicated, by definition. “Everything you see is in the cloud, and you have access to it because you are a subscriber” is easy to understand. “Some of this is in the cloud, some of this you own” is more complicated.

He's joining a reasonably long list of Apple pundits with the request to split Apple Music into its own app, the most recent I can think of offhand was Jared Sinclair, whose step two of four ways to reorg Music was, "Bye, Bye, iPod - Break out all the legacy iPod features into another app."

The worst part is that, sort of like the Big Jennifer Null stuff I've mentioned recently, the iTunes confusion really was preventable.

Gruber leaves the door open on the preventable part, saying,

Maybe there’s a way to design “all your music in one app” that is completely clear, convenient, and obvious.

The four sets of Apple Music

Well, the idea Apple had was bang on. It shouldn't matter where your music lives, you should be able to sync it all. There are really only four sets of music files from iTunes' perspective:

Files that you brought to Apple music (no DRM)
Files Apple thinks it's matched from 1.) on another of your devices (no DRM)
Files Apple didn't match from 1.) and allows you to copy to your other devices via their cloud (no DRM)
- This is really another version of 1, just copied to a new device.
Files you've only ever gotten from an Apple Music subscription (DRM)

Doomsday hub with covered red button

Apple should keep 1.) around like those files are gold. Never let the user whack those without going through some sort of "locked button with cover" removal process. As Jason Snell points out, there's a real UI issue here, but also a serious functional one. "Remove download" should never throw your original files in the trash. Warn that those are files that you brought to Apple Music, and that deleting them will irrevocably remove the originals. And even then, after they're deleted, make sure users can redownload matched versions at the worst, if they were matched, without DRM, until their subscription lapses. Better is to immediately create a backup of that original file, though I realize there are cases where the user might really rather that original disappear immediately.

Files from 2.) should similarly always be downloaded without DRM. There should also be the possibility of saying, "That's a bad match; give me my original file." Maybe in version two you let the user pick from other possible matches, and then you cloud source the right matches after you get a better idea what goes where.

Files from 3.) are pretty simple. You didn't match 'em, so you let folks copy them anywhere they are logged into iTunes. It's pretty much what Dropbox does.

For the fourth, well, the only real gotcha is when they really do match something from 1.), and Apple mismatched it. But then you've already got both files. If someone tries to delete their original because it's now "duplicated", you should send them through that "locked button cover" process, and possibly have a, "duplicate match" reason there. Then you should delete the file from 4, not 1.

Note that there's another category that we're going to ignore to make things simpler -- things that should be matches that aren't matched. I'd provide a mechanism to say when something's mismatched, but if there isn't a match found and should've been, having the original file from 1.) on another machine isn't too bad. That is, there's Category 5: Things Apple should've matched with AACs they have on file and didn't. Instead of providing a way to say so in order that you get more 2.), just leave them in Category 3 until you get everything else straight. That often happens now, and it's fine.

When your Apple Music subscription lapses, you should probably also be given a final download session (that could take weeks to finish), possibly even on more than one device. "Your Apple Music subscription has ended. Would you like to download your matched and/or original files that are currently missing on this Mac/PC?"

Notice that the first three categories make up iTunes Match.

iTunes Match should've let Apple know that they weren't doing a great job of providing its eponymous function -- matching -- and they really needed to make sure they could get 1.), 2.), & 3.) right before going whole hog into a unified Apple Music. But it's still just a database management problem. They "simply" should have been much more defensive with Apple Music for when matching failed. If your user doesn't have a file three places, don't delete it.

But as long as you have a space for a flag on each file to say which it is -- an unDRM'd original*, an unDRM'd "likely match", or a DRM'd file that's never been matched -- you don't have this trouble.

It takes some great QA, but it's a straightforward, at worst tedious, process. I could make such a system without the issues Apple's seen in, let's say, six months, and I could recommend a good five or so folks that could as well.

"UnDRM'd" could also included files purchased before iTunes removed DRM.

Labels: apple fail, Apple Music, coding, fail, gruber, iTunes, qa, rdbms

I'm going out of my mind with stuff to do, which usually means I take on yet another project, if only to make sure I take a little time for myself.

This time, that's a personal budgeting application made in RealBasic, and boy, does RealBasic have some pokey edges. One is the way that you can extend UI objects. It's insane. You can't make up your own object type, like in Java where MyFancyFrame might extend JFrame and provide a few new methods. Instead, you can extend the objects by creating new methods that act like the belong to the UI object from the start, but, and this is the important part, you can't actually put the methods on the UI objects themselves.

Instead, you have to declare the methods in a stand-alone module and ensure that the first parameter is the type of object that it should act, but only act, like it's attached to. So if I want to override the way a cell's rendered in a Listbox (as partially described in this thread and this thread before it, I have to create a module -- let's call it mdlExtensions -- insert the method I want to tack onto the Listbox -- we'll call that PopUpCellChoices -- and have a line like this for params:

extends lb As Listbox, row As Integer, column As Integer, astrChoices() As String

When I actually call the method, which is, again, sitting in its own module, as I might from my Listbox's CellClick event handler, I do it like this:

bOut = me.PopUpCellChoices(row, column, astrChoices)

That's right... it's not mdlExtensions.PopUpCellChoices, but Me., though the method is nowhere near me. In that method, however, "Me" is gone. It's all lb. All I did was obfuscate that I sent "Me" in as lb the Listbox.

Why don't I just call mdlExtensions.PopUpCellChoices(Me, row, column, astrChoices) I have no idea.

In other news, RealBasic's POP3Socket's MIME parsing ability is exactly zero when it comes to UTF-8, which sorta stink0rz. Still, I think I'll shell out for the Personal edition this time. I've been testing RealBasic for years, since OS 9 (maybe before?), and there really isn't any way to create a crossplatform codebase that acts native and has an embedded, SQL-literate database as quickly. Java's great, but I've finally given up on its being a good way to make a app for the masses. RealBasic can apparently even make it to the Mac App Store, so I think I'm going to code up one The Wrong Way (not ugly, just not up to my normal standards of overengineering) and see how difficult it'll be to publish.

Should be [mostly] fun, anyhow.

Labels: apple, java, rdbms, realbasic, shareware

title: Put the knife down and take a green herb, dude.	descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and, when you bike, always wear white. As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
x MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include... MarkUpDown Multiline Table & Bootstrap Grid support. Beautiful Easy Actions that keep the Markdown flowing. HTML paste to paste HTML source into your documents. You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now!

Monday, May 09, 2016
Apple Music's bad DBMS design Gruber weighs in on the rumored iTunes reboot: What do you see when you open the Spotify or Pandora apps? Just the streaming music you have access to. That makes them less complicated, by definition. “Everything you see is in the cloud, and you have access to it because you are a subscriber” is easy to understand. “Some of this is in the cloud, some of this you own” is more complicated. He's joining a reasonably long list of Apple pundits with the request to split Apple Music into its own app, the most recent I can think of offhand was Jared Sinclair, whose step two of four ways to reorg Music was, "Bye, Bye, iPod - Break out all the legacy iPod features into another app." The worst part is that, sort of like the Big Jennifer Null stuff I've mentioned recently, the iTunes confusion really was preventable. Gruber leaves the door open on the preventable part, saying, Maybe there’s a way to design “all your music in one app” that is completely clear, convenient, and obvious. The four sets of Apple Music Well, the idea Apple had was bang on. It shouldn't matter where your music lives, you should be able to sync it all. There are really only four sets of music files from iTunes' perspective: Files that you brought to Apple music (no DRM) Files Apple thinks it's matched from 1.) on another of your devices (no DRM) Files Apple didn't match from 1.) and allows you to copy to your other devices via their cloud (no DRM) This is really another version of 1, just copied to a new device. Files you've only ever gotten from an Apple Music subscription (DRM) Apple should keep 1.) around like those files are gold. Never let the user whack those without going through some sort of "locked button with cover" removal process. As Jason Snell points out, there's a real UI issue here, but also a serious functional one. "Remove download" should never throw your original files in the trash. Warn that those are files that you brought to Apple Music, and that deleting them will irrevocably remove the originals. And even then, after they're deleted, make sure users can redownload matched versions at the worst, if they were matched, without DRM, until their subscription lapses. Better is to immediately create a backup of that original file, though I realize there are cases where the user might really rather that original disappear immediately. Files from 2.) should similarly always be downloaded without DRM. There should also be the possibility of saying, "That's a bad match; give me my original file." Maybe in version two you let the user pick from other possible matches, and then you cloud source the right matches after you get a better idea what goes where. Files from 3.) are pretty simple. You didn't match 'em, so you let folks copy them anywhere they are logged into iTunes. It's pretty much what Dropbox does. For the fourth, well, the only real gotcha is when they really do match something from 1.), and Apple mismatched it. But then you've already got both files. If someone tries to delete their original because it's now "duplicated", you should send them through that "locked button cover" process, and possibly have a, "duplicate match" reason there. Then you should delete the file from 4, not 1. Note that there's another category that we're going to ignore to make things simpler -- things that should be matches that aren't matched. I'd provide a mechanism to say when something's mismatched, but if there isn't a match found and should've been, having the original file from 1.) on another machine isn't too bad. That is, there's Category 5: Things Apple should've matched with AACs they have on file and didn't. Instead of providing a way to say so in order that you get more 2.), just leave them in Category 3 until you get everything else straight. That often happens now, and it's fine. When your Apple Music subscription lapses, you should probably also be given a final download session (that could take weeks to finish), possibly even on more than one device. "Your Apple Music subscription has ended. Would you like to download your matched and/or original files that are currently missing on this Mac/PC?" Notice that the first three categories make up iTunes Match. iTunes Match should've let Apple know that they weren't doing a great job of providing its eponymous function -- matching -- and they really needed to make sure they could get 1.), 2.), & 3.) right before going whole hog into a unified Apple Music. But it's still just a database management problem. They "simply" should have been much more defensive with Apple Music for when matching failed. If your user doesn't have a file three places, don't delete it. But as long as you have a space for a flag on each file to say which it is -- an unDRM'd original, an unDRM'd "likely match", or a DRM'd file that's never been matched -- you don't have this trouble. It takes some great QA, but it's a straightforward, at worst* tedious, process. I could make such a system without the issues Apple's seen in, let's say, six months, and I could recommend a good five or so folks that could as well. "UnDRM'd" could also included files purchased before iTunes removed DRM. Labels: apple fail, Apple Music, coding, fail, gruber, iTunes, qa, rdbms posted by ruffin at 5/09/2016 12:42:00 PM

Thursday, June 23, 2011
PHP PDO, Drupal, and platform lock-in General concepts \| drupal.org: The Drupal database layer is built atop PHP's PDO library. PDO provides a unified, object-oriented API for accessing different databases but it does not provide an abstraction for the different dialects of SQL used by different databases. I believe the implication is that Drupal has those drivers to attach to multiple SQL rdbms. Look, hiding the SQL is all well and good, but what you really end up with isn't a savings. It's platform lock-in. If I know Drupal's flavor of PDO, I can't do anything with an ANSI SQL compliant rdbms in Java. I can't do it with VB.NET/ADO.NET. I can't do it with RealBasic's crazy database features. I only know PDO. If I already knew ANSI SQL, I have to learn a whole new language, not just a dialect. I've SQuirreL-SQL'd my way from MS SQL Server to Jet to Postgres to MySQL to Oracle to Sybase to Derby to... you get the point. There are minor flavor changes from one rdbms to another, but nothing, nothing as involved as learning this PDO crap. There's really only one place an abstraction layer like this makes sense, and that's if you're looking to move to another rdbms. Perhaps many develop on AMP and move to MS SQL or Oracle, but I kind of doubt it. If you've normalized [your code] well, even that's not that big a task. There are too many SQL abstraction layers out there when you really should just learn SQL. Instead of marrying yourself to a single MVC platform, you'll be ready to do your thing anywhere and in any language. This is why the guy who taught me to be a dba always said to stick as much logic as you can into the database where it belongs. I don't think we'll see many cursors or triggers or, most importantly, sprocs with either or both in PDO. Put your logic in the database system that's not going to change, and move from Drupal to Joolma to roll-your-own as quickly as possible. Save your data, not your interface. (Now, I understand. They want you to use Drupal, not rdbms X. They want every Drupal module to work with every combo of available platforms. I get it. It's a mistake. ;^D) You're always picking a platform when you code. Make sure you lock-in intelligently. (Although the more I look at this, the greater the possibility that they may be working on doing just that with PDO. Still, any time you have to learn a new OM to hit a database, you've wasted a developer's time.) Labels: Drupal, rdbms posted by ruffin at 6/23/2011 02:48:00 PM

Wednesday, June 22, 2011
RealBasic Extends -- Hello, kludgey I'm going out of my mind with stuff to do, which usually means I take on yet another project, if only to make sure I take a little time for myself. This time, that's a personal budgeting application made in RealBasic, and boy, does RealBasic have some pokey edges. One is the way that you can extend UI objects. It's insane. You can't make up your own object type, like in Java where MyFancyFrame might extend JFrame and provide a few new methods. Instead, you can extend the objects by creating new methods that act like the belong to the UI object from the start, but, and this is the important part, you can't actually put the methods on the UI objects themselves. Instead, you have to declare the methods in a stand-alone module and ensure that the first parameter is the type of object that it should act, but only act, like it's attached to. So if I want to override the way a cell's rendered in a Listbox (as partially described in this thread and this thread before it, I have to create a module -- let's call it mdlExtensions -- insert the method I want to tack onto the Listbox -- we'll call that PopUpCellChoices -- and have a line like this for params: `extends lb As Listbox, row As Integer, column As Integer, astrChoices() As String` When I actually call the method, which is, again, sitting in its own module, as I might from my Listbox's CellClick event handler, I do it like this: `bOut = me.PopUpCellChoices(row, column, astrChoices)` That's right... it's not mdlExtensions.PopUpCellChoices, but Me., though the method is nowhere near me. In that method, however, "Me" is gone. It's all lb. All I did was obfuscate that I sent "Me" in as lb the Listbox. Why don't I just call `mdlExtensions.PopUpCellChoices(Me, row, column, astrChoices)` I have no idea. In other news, RealBasic's POP3Socket's MIME parsing ability is exactly zero when it comes to UTF-8, which sorta stink0rz. Still, I think I'll shell out for the Personal edition this time. I've been testing RealBasic for years, since OS 9 (maybe before?), and there really isn't any way to create a crossplatform codebase that acts native and has an embedded, SQL-literate database as quickly. Java's great, but I've finally given up on its being a good way to make a app for the masses. RealBasic can apparently even make it to the Mac App Store, so I think I'm going to code up one The Wrong Way (not ugly, just not up to my normal standards of overengineering) and see how difficult it'll be to publish. Should be [mostly] fun, anyhow. Labels: apple, java, rdbms, realbasic, shareware posted by ruffin at 6/22/2011 04:29:00 PM

<< Older \| Newer >>