Clik here to view.
After finally getting my web mashup code into GitHub I spent a lot of time ensuring the code was easy to read and well commented. The code still needs testing on another box than that used by my webhost, volunteers? I use my collection of web mashups as a test suite of sorts for the codebase. I’ve tracked down a lot of bugs, but as the codebase has grown and more APIs have been added I think it runs less efficiently.
I have a number of theories on why the CD Cover Gallery in particular works less well:
- Far from optimal PHP coding technique
- Too much overhead from adding more APIs
- Slow WiFi based Internet connection
- Use of flat files for caching
- Large dataset with lots of difficult data
- Lack of underlying database
- Browser or server limitations
- Use of lightbox javascript
- API throttling
I tried altering my code but I use multiple APIs to increase the odds of finding the information I’m looking for. Methods that used to check a single API now check two or three. Removing APIs is an option, as is some sort of configuration system so how much effort to spend searching APIs could be controlled, a third option is to write a new lean CD Cover Gallery. All of these are work, I tried a few things and my previous attempts to improve my existing code or create a better CD Cover Gallery were less than successful.
There are 545 lines in my CSV file. Each of these lines corresponds to one or more CDs not all of which have a ‘cover’ that can be found in Amazon, iTunes, or Last.fm. Perhaps someone has some better ideas? In addition to making my PHP code available, you can download my CSV file. Caching the CD covers locally is probably a violation of API terms of usage, even caching the XML responses is potentially a TOS issue, but is necessary to avoid throttling. With all the caching I do the gallery should run better over time but lately 137 CD covers is the most it seems to return.
Another approach such as showing one CD Cover while continuing to fetch 100s of other CD covers is probably the way to go, that is what a lot of Web 2.0 darlings do, even some WordPress themes take that approach.
UPDATE: I think there may be a bug or issue with the last.fm API or Matt’s code. Someone was allowed to make a tiny fix 8 months ago, I don’t think any of the fixes I sent Matt were ever added. Apparently the code has been forked 17 times not counting the version I included with my code, perhaps one of them is working better, but I’m also not sure it isn’t a throttling issue as things used to work better. The album version of getInfo($methodVars) along with the caching code seems to fail. Fetching info about an artist seems to still work… There seems to be an issue with album titles or artist names containing an apostrophe, such as Howlin’ Wolf.
UPDATE: Now that I’ve taken steps to prevent an apostrophe from wrecking havoc with Matt’s last.fm API code, I’m able to display 187 album covers from a list of 545. This is a slight improvement though it runs SLOW. I keep having to add conditionals and workarounds, I wonder if I wouldn’t have more success not using last.fm. It is hard to find large images of album covers. MusicBrainz might be able to help phpBrainz is also long in the tooth.
