Spring is for Concerts

Spring is for concerts

That's a famous quote, eh?

Actually, it's not. While "Spring is for" turns up something like 2.3 billion results on the Google, "Spring is for concerts" turns up two. And, coincidentally, one of those results happens to refer to a different stop on of a tour that spawned this post.

Did that make sense?

Regardless of the nonsensicalness of the previous couple of sentences, I've seen a bunch of shows this spring (both with and without my wonderful girlfriend). Much of that has been documented on ye old Twitter and previously on ye old blog.

But, we lucked into some good seats to a couple of really great shows, and felt that it deserved a bit of verbage.

A little over a week ago, I saw Nada Surf play for the fifth or sixth time. As always, they were just fantastic. There are bands that just know how to play to a crowd and they connect in that way where it's not just the music, but you feel like you're actually hanging out with a big group of people and experiencing something unique (even if it's quite likely they pull off the same schtick in every city). Nada Surf is always like that.

This time did feel a bit more unique, as they covered a tune by The Gravel Pit (a Boston band they toured with back in the day), which probably doesn't happen everywhere (though, judging by setlists, at least happened in New York as well.)

About a week later, the girlfriend and I went to see Snow Patrol. There's a bit of backstory here. This was sort of our "bonding" band, as 2005-era Snow Patrol was a perfect bridge band between poppier music and "indie rock." So, they're kind of a foundation for our relationship.

Go us.

A few years back, we got ok seats to see Snow Patrol open for U2 at Gillette Stadium. We left super early so we could get to our seats and catch the opener. What could go wrong?

3.5 hours of traffic (on what should be a 40 minute drive) got us to the arena in time to have Snow Patrol leave the stage.

Perfect.

Cut to a couple of months ago. Snow Patrol sold out The Orpheum, but I found some "obstructed view" seats on StubHub.

Turns out, we were obstructed by the stage. Probably the best seats I've ever had for a "big" show. And, with the exception of not playing "Spitting Games", Snow Patrol were another band that made a big, likely routine for them, show feel somewhat unique and intimate.

Being in the front row didn't hurt.

You Dig My New Threads?

I'm sort of continually looking for a simple WordPress theme that will let me get most of the cruft out of the way, and just focus (mostly) on the text. I generally (stress generally) dig Tumblr's themes because they're, quite often, "here's a picture, here's some text". Simple. (Except when someone MySpace's their Tumblr up and turns it into a sea of icons and badges and animated gifs.)

Anyway, wp-svbtle came out, based on svbtle.com. Me likes.

So, I grabbed it off GitHub, messed around with things a tiny bit, and here we are. I'm sure I'll tweak it a bit more, and then get bored by it and change it again in three months. But for now, I'm happy with my new clothes. It's spring, the weather is nice, and it feels like I've just done a bit of spring cleaning on the old blog.

Feels like this, really:

(This is my street. Walking out to go to work some mornings can be quite inspiring.)

Reading List to Instapaper on GitHub

The Reading List to Instapaper sync tool that I built and mentioned about a week ago is up on GitHub.

I haven't had a ton of time to document it, but it's up live and you can clone it and get it running on your own machine.

It's been working for me for over a week now and I haven't run into any issues. I'm happy to answer any questions (or fix bugs) should they crop up.

Holy Sheet, Google is Fast

After posting my last post, I figured I'd do what I should have done before I typed it up&emdash;see if someone else had ever done the same thing.

Google had already indexed my post. Jesus, they are creepy fast.

(It is not on Bing or DuckDuckGo yet. A victory for the new evil empire.)

Using Safari's Reading List to Feed Instapaper

A week or so back, I started thinking that it might be nice to get away from using the Instapaper bookmarklet (which is great, don't get me wrong) and see if there was a way to use Safari's Reading List (which works on the iPad, iPhone, Mac, and presumably the PC) to send links to Instapaper.

This is about the Mac implementation, but presumably, a PC implementation would work similarly.

Getting the Reading List info to feed into Instapaper was surprisingly easy. I used Ruby, but you could certainly use pretty much any scripting language. The Reading List entries are stored in the Bookmarks.plist file that lives in your ~/Library/Safari directory. It's a binary plist, so you have to run a magic plist command on it to convert it into a text plist.

At that point, if you want to, you can throw that through a regular expression, or into a plist/XML parser to deal with it like an object.

You find the set of entries that define the Reading List links, parse the URLs out of them, and then you can send the links to the Instapaper Simple API to store in your Instapaper account.

I've got some extra jazz in there that keeps track of the last time it ran, only grabs links newer than that, and after submitting, throws up a little Growl message that lets me know the link was submitted successfully.

It's about 83 lines of code (and I'm a pretty crappy ruby programmer) and, so far, it works pretty flawlessly.

But, what good is that if I have to run a script every time I want to sync up my Reading List and Instapaper? Wouldn't it be awesome if there was a way to automatically run the script whenever the Reading List is updated?

It would be.

And there is.

launchd is a nifty cron-like thing that runs on the Mac. You tell it to do automatic stuff and it does it. One of the automatic things you can tell it to do is "watch this file, and if it changes, run this command."

After a bunch of trial and error, I got my little LaunchAgent working, and now, every time I add something to the Reading List in Safari, I wait about 10 seconds, and I get my little Growl notification that the link has been submitted to Instapaper.

Awesome, right?

Even better, now I can add things to my Reading List on Safari on my iPad or iPhone. When my computer next syncs up its bookmarks, it'll submit those links to Instapaper.

Even better than that, if I put the little touch file (that keeps track of when I last updated) onto something like Dropbox, I can run this utility on any computer I want, adding links to the Reading List all the while, and things should appropriately get added to Instapaper.

All in all, it's a nifty little system.

I'm going to throw the whole thing up on Github at some point this week, so you can download it and play with it yourself (and probably make it better).

iOS 5.1 and iTunes Match, Part 2: It Mostly Works Now

As I mentioned earlier this week, the recent iOS 5.1 (and iTunes 10.6) releases fixed a handful of the lingering issues that existed with iTunes Match.

The big remaining issue was really the fact that Smart Playlists that rely on the "limit" option in iTunes still didn't work. (There were a couple of other issues, with tracks that were tricky to get into iTunes Match, and sporadic play count updates.) Well, I spent some time this weekend poking around with things to see if there were any other improvements in the latest release.

And there are. Big ones.

First, I had two tracks that I had never been able to get into iTunes Match. They are some old mp3s I ripped in college (legal rips, even!) and burned to an archive CD during one of my moves between computers. The media seems to have corrupted a bit overtime, and no magic mp3 repair could get them into a state that would make iTunes Match happy. But, you know, new iTunes, new iOS, why not give it a shot?

Well, it worked. They were added and uploaded to iTunes Match in about 30 seconds. No errors, no problems.

So, if you've got some old tracks hanging around that you were never able to get into iTunes Match, it's probably worth another shot.

That brings us to those dreaded Smart Playlists. My big one that had been nerfed by iTunes Match was my "Best Recent Adds", which is the best 50 songs (by rating) that were most recently added to my iTunes. It was useless on iTunes Match, as it seemed to go off of the date the songs were added to my iPhone (or iPad) rather than the date they were added to my collection.

Googling around, I found this Apple support discussion where someone mentioned turning iTunes Match off and back on on your iOS device seemed to make these Smart Playlists work. "What the hell?", I figured.

Well, again, it worked.

I went onto my iPhone, turned off iTunes Match, force killed the Music app (probably not necessary, but I'm impatient), and then turned iTunes Match back on. I waited about 15 minutes for things to load again (here's a tip: go to your Podcasts screen, where there should be a nice iCloud cloud and progress bar -- that'll show you how far you are). Once it had loaded, I checked out my smart playlists&emdash;and now they worked!

Most of them, at least. There's still one or two that seem to act a bit weird (those based off of updating play counts). But the ones based off limits seem to work.

With iTunes 10.6 and iOS 5.1, iTunes Match seems to now:

• Handle a much larger variety of "difficult" tracks
• Handle artwork much more reliably
• Added back Genius Mixes and Genius Playlists
• Fixed the handling of (most) Smart Playlists

The only thing left, as far as I can tell, is getting play count syncing working. It still only seems to sync the first track you play, never updating the rest of the play counts (which is why some smart playlists won't look like they are working). Something to hope for in iTunes 10.6.1 or iOS 5.1.1, I suppose.

I would say that, if you were waiting for iTunes Match to sort itself out, it's pretty darn close. For my money ($24.99/year, in fact), it's easily worth it, just for the off-site backup of my music (and the streaming to my Apple TV).

iOS 5.1 and iTunes Match (Genius is back, baby!)

As mentioned in previous posts, there were a few things (Genius, better artwork syncing) that would probably have required an iOS update to get working.

Well, iOS 5.1 is here and Genius is back and it is glorious. Right under playlists is "Genius Playlist", like it used to be, pre-iTunes Match. One thing to be aware of, though, is that it will pull in music that isn't local to your phone so if you're somewhere without an internet connection, your Genius playlist might not have quite as much music as you'd hoped. And, your phone will download the songs that are in the cloud, so if you keep a carefully cultivated music library on your iOS device, you'll be littering it with anything that gets thrown into your Genius playlist.

The jury is still out a bit on artwork, but my iPhone does seem to be far more responsive downloading artwork, and it will load the artwork without having to leave and come back to the song. And once downloaded, at least in my very, very early testing, the phone seemed to be doing a better job of caching that artwork. That's at least promising.

Slowly, Apple is ironing out the wrinkles in iCloud and iTunes Match.

Kaiser Chiefs (and a giant pole) at The Paradise

Really fun show, better than I expected.

Fanfarlo at Brighton Music Hall

A Quick Bit About WordPress Caching

WordPress, being a PHP-heavy, database driven CMS, can hit some performance issues. Namely, without some basic caching turned on, WordPress can be dog slow.

Working for a shared web hoster, WordPress performance can be a problem. It sort of hits the sweet spot of everything that can possibly go wrong with shared hosting: loads of php file opens, a bunch of database requests, very little that can be easily cached up stream with a caching proxy like Varnish or Squid.

So, both out of curiosity and a desire to make things better for customers, I did some quick benchmarks of WordPress with no caching, with Hyper Cache, and with W3 Total Cache.

Based off my past experience (and, really, based off of little more than a bit of speculation), I figured Hyper Cache might perform best on shared hosting. It's simple, uses disk based caching, and doesn't seem to require a lot of overhead. I speculated it would perform a bit better than W3 Total Cache (as I thought, on a shared host) the overhead of W3 Total Cache might slow it down.

I was very wrong.

I ran a couple of tests. First, a sort of low traffic test (1000 requests, 20 at a time). The details:

Test 1, Low Traffic (1000 requests, 20 at a time)

No Caching

Metric	Time (seconds)
Average Request	0.8
Longest Request	3.9
80% of Requests Handled In	1.2

That's not so bad, but this is a pretty light traffic load.

Hyper Cache

Metric	Time (seconds)
Average Request	0.4
Longest Request	3.7
80% of Requests Handled In	0.4

Well, that's a good bit better, isn't it? Caching, not surprisingly, helps.

W3 Total Cache

Metric	Time (seconds)
Average Request	0.07
Longest Request	0.3
80% of Requests Handled In	0.09

Crikey. That's not just better, that's basically as fast as you can load static content. That's insanely good.

Ok, well, under low traffic load, W3 Total Cache wins. What happens when we crank it up a bit?

Test 2, High Traffic (5000 requests, 100 at a time)

No Caching

Metric	Time (seconds)
Average Request	1.7
Longest Request	11.3
80% of Requests Handled In	2.6

As expected, performance goes down as we start getting our big traffic influx. 11 seconds to handle the longest request, and it's about twice as bad as under light load.

Hyper Cache

Metric	Time (seconds)
Average Request	1.8
Longest Request	15.3
80% of Requests Handled In	3.5

The first real surprise: Hyper Cache basically tips over under this load. I'm not sure why this would be (maybe Hyper Cache doesn't play well with NFS), but this is bad news for making our site run quickly.

W3 Total Cache

Metric	Time (seconds)
Average Request	0.3
Longest Request	3.5
80% of Requests Handled In	0.4

Wow. W3 Total Cache just crushes it. Sure, it's slower than it was under light load, but it's basically still performing as well as it would if it was a static site.

That's pretty unreal performance. And, that's out of the box with almost no tuning. I'm guessing if I played a bit more, I could squeeze a bit more performance out of W3 Total Cache.

There are a million other caching plugins. I'm not sure, though, that'd I'd look much further. Even if another plugin could perform better than W3 Total Cache, it can't perform that much better. Given how widely used W3 Total Cache is, meaning loads of tips, tricks, and support on the web, I'm pretty sure this is my recommended caching plugin (and something that we might start installing automatically in our hosted WordPress install at work).

← Older Newer →