Apple Music + iCloud Music Library is a brilliant pairing, and finally lets us access our personal music collections from anywhere. But it’s not without its warts – duplicated tracks and bad/missing cover art has been a sore spot for iCloud Music Library users since the service launched. In my first piece for Medium.com, I walk readers through the reasons – and the fixes – for those two problems.
Video of my Djangocon 2015 presentation has been posted:
in case you’re interested in a glimpse of the kinds of problems I’ve been wrestling with over the past six months (I’m on to other projects now). Warning: This is a really dry topic (tried to juice it up the best I could).
Would love to present again, but on a less academic topic…
For years, I’ve resisted – and argued against – using web ad blockers of any kind. After spending a decade working at a journalism school and watching publishers large and small struggle (and mostly fail) to find a way to be paid for their essential efforts, it felt like bearing a certain amount of advertising was the very least we-the-public could do to support quality journalism. Paywalls don’t work for almost any publications – what else is there?
But the rise of the mobile web tipped the scales – the “social contract” around advertising was no longer a fair one. The mobile experience is far less tolerant of intrusion, and network speeds are slower. But because monetization is more difficult, publishers were “forced” to insert more, and more intrusive advertising. The cumulative effect has been a steady decline in the quality of mobile browsing. Today, many news sites are close to unusable on a smart phone, having become choked out by network and screen-stealing crap.
While many admins and blog posts tell users that length is by far the most important factor in creating strong passwords/passphrases, the majority of password input fields are giving them a set of hide-bound rules: Eight characters, at least one upper- and one lowercase letter, some digits and punctuation marks, etc.
Even though it includes dictionary words, a passphrase like:
Sgt. Pepper's Mr. Kite
is far stronger than:
(there’s a world of difference between 22 characters and 9, from a cracking perspective). But many password input fields would reject the first one. No wonder users are confused by the process of creating strong passwords!
I’ve been thinking recently about how some people have jobs that most everyone can “understand” more or less – we all know kinda sorta what a teacher or a policeman does – while others work in areas that are virtually inaccessible to the general public. I’m often reminded how little my family and closest friends understand about how I spend my days.
So Paul Ford of Businessweek has written this colossal, 38,000-word article “What Is Code” that attempts to bridge that gap. I’m not sure it succeeds (or that any article could) but it’s a fine attempt and a damn good read. Even for coders. It took hours to get through, and reading is not generally how I like to spend my weekend time, but it was time very well spent. Super recommend.
More images in the Flickr Set.
This year was the 10th birthday of “The Greatest Show and Tell on Earth” – that Rainbow Gathering of robot makers, sculptors, hackers, welders, Burning Man attendees with kids, benders of light, food artisans, bicycle tweakers, DJs and artistic misfits.
I’m proud to be able to say I’ve taken my child to Maker Faire @ San Mateo every single year since 2006, meaning we haven’t missed a single event.
Despite the annoying aspect of the ever-growing crowds, it’s become a father-son tradition we look forward to every year, and we can’t imagine ever skipping it at this point. Every year is both “more of the same” and completely different.
Certain exhibits seem almost perennial, but there are always tons of new surprises. It was especially nice to have cooler temperatures this year – low 60s meant we were able to do a full eight hours on the fairgrounds without missing a beat.
More fire-breathing giant beastie sculptures than ever before:
Riding Cyclecide’s collection of hacked bicycles is always our favorite part of the day. Bikes with hinges in the middle of the frame are almost impossible to ride, but you do kind of get the hang of it after a while.
Same with the reverse-steering-gear bike that turns the opposite of the direction you turn the wheels. Our fave this time was the bike with off-center axles, making it feel like it’s navigating bumpy terrain even on flat ground.
The “dark room” seemed better than ever, with more sophisticated interactives, plus a truly gorgeous wall-sized mixed-materials glowing sculpture reminiscent of a time tunnel receding into space.
We’ve admired the masking tape cities and gardens every year (now represening 10,000 hours of work and more than 27 miles of tape!), and for the first time this year we actually sat down for a 30-minute lesson on masking tape “origami.”
And Miles had his first opportunity to sit at the helm of an original Apple IIe, just like the ones we used in high school in the early 80s:
Totally loved the “junk” drumming of John F. King:
More images in the Flickr Set.
A Django project I’m working on defines two databases in its config: The standard/default internal db as well as a remote legacy read-only database belonging to my organization. Models for the read-only db were generated by
inspectdb, and naturally have
managed = False in their Meta class, which prevents Django from attempting any form of migration on them.
Unfortunately, that also prevents the Django test runner from trying to create a schema mirror of it during test runs. But what if you want to stub out some sample data from the read-only database into a fixture that can be loaded and accessed during unit tests? You’ll need to do the following:
- Tell Django to create the second test database locally rather than on the remote host
- Disable any routers you have that route queries for certain models through the remote db
- Tell Django to override the
Managed = Falseattribute in the Meta class during the test run
Putting that all together turned out to be a bit tricky, but it’s not bad once you understand how and why you need to take these steps. Because you’ll need to override a few settings during test runs only, it makes sense to create a separate
test_settings.py to keep everything together:
from project.local_settings import * from django.test.runner import DiscoverRunner class UnManagedModelTestRunner(DiscoverRunner): ''' Test runner that automatically makes all unmanaged models in your Django project managed for the duration of the test run. Many thanks to the Caktus Group: http://bit.ly/1N8TcHW ''' def setup_test_environment(self, *args, **kwargs): from django.db.models.loading import get_models self.unmanaged_models = [m for m in get_models() if not m._meta.managed] for m in self.unmanaged_models: m._meta.managed = True super(UnManagedModelTestRunner, self).setup_test_environment(*args, **kwargs) def teardown_test_environment(self, *args, **kwargs): super(UnManagedModelTestRunner, self).teardown_test_environment(*args, **kwargs) # reset unmanaged models for m in self.unmanaged_models: m._meta.managed = False # Since we can't create a test db on the read-only host, and we # want our test dbs created with postgres rather than the default, override # some of the global db settings, only to be in effect when "test" is present # in the command line arguments: if 'test' in sys.argv or 'test_coverage' in sys.argv: # Covers regular testing and django-coverage DATABASES['default']['ENGINE'] = 'django.db.backends.postgresql_psycopg2' DATABASES['default']['HOST'] = '127.0.0.1' DATABASES['default']['USER'] = 'username' DATABASES['default']['PASSWORD'] = 'secret' DATABASES['tmi']['ENGINE'] = 'django.db.backends.postgresql_psycopg2' DATABASES['tmi']['HOST'] = '127.0.0.1' DATABASES['tmi']['USER'] = 'username' DATABASES['tmi']['PASSWORD'] = 'secret' # The custom routers we're using to route certain ORM queries # to the remote host conflict with our overridden db settings. # Set DATABASE_ROUTERS to an empty list to return to the defaults # during the test run. DATABASE_ROUTERS =  # Set Django's test runner to the custom class defined above TEST_RUNNER = 'project.test_settings.UnManagedModelTestRunner'
With that in place, you can now run your tests with:
./manage.py test --settings=project.test_settings
… leaving settings untouched during normal site operations. You can now serialize some data from your read-only host and load it as a fixture in your tests:
class DirappTests(TestCase): # Load test data into both dbs: fixtures = ['auth_group.json', 'sample_people.json'] ... def test_stub_data(self): # Guarantees that our sample data is being loaded in the test suite person = Foo.objects.get(id=7000533) self.assertEqual(person.first_name, "Quillen")
In the olden days, a typical worker’s desk had an “inbox” and an “outbox.” The “inbox” represented things that needed to be dealt with, and the “outbox” represented things that were done. When email came along, its designers wisely emulated this metaphor.
Your email inbox represents everything you haven’t dealt with yet, but that needs to be. While managing your email, you’re engaged in an ongoing process of deleting things you don’t need to ever see again, or archiving things that have been dealt with but need to be kept for reference. If it doesn’t need to be dealt with, it has no excuse to exist in your inbox. At the end of every day, what’s left in your inbox is the (hopefully very small) list of things you haven’t gotten around to. But you know they’ll still be there tomorrow – they won’t be lost. Your inbox is, in essence, the most important on-going to-do list you’ve got.
Text messaging apps have no such concept. When a text is new, you get an alert. But the moment you glance at it, there is no mechanism for separating it out from all of the thousands of other texts piled up in your app – it becomes part of the noise. There is no way to know what in your text app needs responding to and what does not.
Therefore, when you send me a text, I have two choices:
- Drop everything and respond right now so your message doesn’t get forgotten
- Add your message to the “mental stack” of things that need to be dealt with later.
Most of the time, when a new text rolls in, I’m not able to deal with it right now. Ipso facto, most of the time, when a new text rolls in, it’s bound to get forgotten – I’ll never see it again. Unless I add it to my mental stack, i.e. unless I incur a cognitive burden.
Case in point: A few days ago a text rolled in while I was on a long bike ride, asking for information I didn’t have access to at the time. When I arrived home six hours later, that text was the absolute last thing on my mind. It was gone, virtually forgotten. There was nothing to remind me that it ever existed. If it had been an email, the fact of it existing in my inbox would have ensured that it got the response it deserved. The sender had simply chosen the wrong tool for the job.
Because of this reality, when you send me a text, you are putting a burden on me. You are saying, “Drop what you’re doing and respond to me right now, regardless whether it’s convenient for you, lest this communication be forgotten.”
When you email me, you’re saying “Please respond to this when the timing is convenient for you.” With email, I have the luxury of being able to delay my response a day or two if needed. There is no cognitive burden – I don’t have to remember to respond. I’ll know to respond later, because your message is there in my inbox.
So in what occasions is a text more appropriate than email?
- We’re arranging details about something that’s happening now or in a few hours
- You just want say hello or share something simple that doesn’t demand an immediate response
- Computer is on fire.
If you’re planning something that is not happening today, please don’t text. If you’re communicating important information, that needs real typing to work out, please don’t text. If you’re communicating information I might want to be able to refer to later, please don’t text.
I know there’s a lot of talk about how “email is dead” and “email belongs to the old,” and about how some young people actually prefer text over email. I say it’s not about youth – it’s about respecting people’s time, regardless of age (and everyone is busy!). Also: Claims about the death of email are grossly exaggerated – for me and millions of others, email is still the centerpiece of online communication.
I’m not asking you never to text me. I’m asking to ask yourself whether what you have to say rises to the level of deserving a time-stealing text.
Whether you’re talking about LPs or MP3s, people have really different ideas about what constitutes “the ultimate music collection.” For some, it means a process of endless refinement, boiling down a set of music to the purest essentials: All signal, no noise. For others, it’s an archival process (“Why have one Bix Biederbeck CD when you could have 23?”)
It’s possible to have the best of both worlds: Maintain a large collection so you have access to everything, but create a playback system so you only end up hearing what you truly love.
I’ve been an eMusic subscriber for nearly a decade. I’ve spent a good deal of my spare time over the past four years digitizing my entire record collection, followed by my entire CD collection, followed by the large CD collections of six record-collecting friends (one of which alone was basically the Musical Library of Alexandria). All told, I’ve managed to amass a collection of ~120,000 tracks spanning ~9,100 albums, mostly in lossless format, and all with high-quality album art.
The accreted set now weighs around 2.25 terabytes – large enough to have “special needs.” Over the past four years of building the collection, I’ve picked up a few tips. Thought I’d share some of the most useful bits here, in case anyone finds them helpful.
Love it or hate it, iTunes has enough traction to be considered the “default” music player for almost everyone, so I’m going on the assumption that it’s your player too. If you use something else, power to you! Everything below assumes you use iTunes 11 or 12.
This guide is split up into four major sections:
- Remote Control (Playback techniques)
- Miscellaneous iTunes Tips (Rare B-sides)
- Digitization Notes
- Building a Server
Django’s Messages framework is an elegant workhorse, and I’ve never built a Django site that didn’t use it for displaying success/failure/info messages to users after certain actions are taken (like logging in successfully or adding an item to a cart).
But wouldn’t it be cool if you could use that functionality client-side, delivering user messages to be processed as JSON data rather than statically outputting messages to generated HTML? On a recent project, I needed to do this because Varnish caching doesn’t let you mark page fragments as non-cacheable, so statically generated messages were not an option. But there are all sorts of reasons you might want to handle Django Messages client-side.