This was a much longer and more tedious task than is warranted, and made me realise what a confusion the world of classical music is. Given that most works have been performed and recorded multiple times, I wanted to only pick versions that were well thought of (Spotify availability allowing). But, even if you can judge what the “best” release is, working out which of several albums feature that recording is tricky.
What if the same conductor and orchestra have recorded performances in different years? How do you tell which is which when Amazon only list the year the CD was released (or re-released)? Can you then square that information with Spotify whose metadata is reduced to Track/Artist/Album, a format suitable only for popular music (at best)?
Where Spotify had a choice of recordings for a work I’ve done my best to choose the one that is most well thought of, whether that’s judging by an authoritative sounding BBC review or simply a single comment on an Amazon listing. I should have kept track of the references, and whether the “best” version was available on Spotify or not, but I failed on that score, adding to the confusion. I’ve listed which version I chose, but not how I chose it.
A few handy resources though:
The playlist itself is not something you’d want to listen through from start to finish, and individual tracks are swamped by the occasional opera. But you might find a few things you want to pick out to try. Below is the full listing, split up into parts according to the three TV episodes. Tracks are in the order they were captioned on the show. The rare omissions on Spotify are listed at the end. I’ve linked to Wikipedia for more information on works where possible (failing that, the composer).
(Abbreviations… So: Symphony Orchestra; Po: Philharmonic Orchestra.)
Footnotes:
Not on Spotify:
This is written for people who don’t listen to jazz, but are curious about it, or who would like to try it. And it’s just one guy’s suggestions, nothing more. There might, however, be a sort of hidden benefit in my lack of expertise: being just an average person makes it easy for me to know what other average people go through when trying to expand their musical horizons. That’s my story, anyway, and I think I’ll stick with it.
I love lists of “the best” music/books/etc so, knowing very little about jazz, this was great stuff. So here’s the Spotify playlist and, for posterity, the listing of albums, although you should go and read Mike Johnston’s descriptions, where there are more suggestions in the comments.
The only album not on Spotify is Roy Haynes’ When It Haynes It Roars (1994), which should go after Count Basie in this list.
]]>It’s not 100% successful: for 69 years, I currently have 34 tracks, but given my stringent criteria (below) that seems like good going. You can listen either on Spotify or on YouTube (also possibly embedded below, depending on how you’re reading this). The playlists are slightly different, depending on what’s available, but at the time of writing they have the same number of tracks.
If you can fill a gap with a track, or have better suggestions than something that’s already included, then, so long as it’s available on Spotify and/or YouTube, let me know. Make sure you have familiarised yourself with the following rigorous inclusion criteria:
The track’s title must include the year. Ideally, it’s nothing but the year, so there’s no Sex Crime (1984) by the Eurythmics (instead we have David Bowie’s 1984). Los Campesinos!’s 2007, The Year Punk Broke (My Heart) is allowed because it starts with the year, the rest of the title describes the year, because it satisfies all other criteria, because there’s no competition for 2007, and because it’s Los Campesinos!
The track must be about, or at least mention, the year. So we have no instrumentals such as Boards of Canada’s 1969. Ideally, the lyrics are looking back on a year in the past. Or they might look forward to a future year, or talk about the then present year, or refer to the year in a metaphorical sense (Prince: “I’m gonna party like it’s 1999”), or, if there’s little competition, refer to the year in a sense that makes little sense (David Bowie: “Beware the savage jaw of 1984”). This means Blur’s 1992 doesn’t make it as there’s no reference to the year (I think it was simply a demo recorded in that year). But 2010 by Cornelius appears because virtually its only sung lyric is the year.
The song should be in English. This is because I’m from Britain and we don’t fully trust, never mind speak, other languages. This isn’t always possible, and so foreign language music will fill any gaps. There are a handful of these, such as Amedeo Minghi’s 1950 which Google translates from Italian in a manner that complies with the previous rule (“And your eyes so beautiful, wide on the future, and closed on me, in the nine hundred and fifty”).
I must be able to bear listening to the music. It turns out I can cope with most genres in small doses, but a few songs that would otherwise have been ideal haven’t made the cut because they were dreary sub-Travis-alikes or metal that’s far too tuneless for me. Don’t complain if I won’t add your favourite song because I don’t like it; I don’t make the rules, I only… no, I do make the rules.
Only one track per year is allowed. When there are two suitable tracks they are weighted according to all the above criteria and the highest-rated (using a complex formula and whimsy) is included. Usually one candidate stands out although 1959 proved tricky, with both Sisters of Mercy and Patti Smith singing about it.
Let’s count that as a successful Friday, shall we?
]]>Usually these are “acqui-hires”, acquisitions whose only purpose is to employ the start-up’s staff. This might sound extravagant to those in what we might call the real world, but given the total costs of hiring and keeping qualified and experienced staff, the ability to employ a small, hopefully proven team, and keep them hooked for a couple of years with share options, is seen to be worth a few million.
Because the staff have been hired to be part of Google or Facebook or AOL, they are now part of that company’s grander scheme, a scheme that rarely includes whatever website or service the start-up was originally developing. Consequently, the initial blog post starting:
We’re thrilled to announce that igglypiggly.io is now part of the Facebook family!
is soon followed by:
The igglypiggly.io service will be closing in two weeks and all your photos, writing, updates, check-ins and contacts will be deleted at that time.
Thanks for coming with us on our incredible journey!
Sometimes these announcements will be years, months, or weeks apart. Sometimes they are part of the same announcement, an artful blog post featuring both joy and authoritarian warnings.
Our Incredible Journey is cataloging these announcements. There are many from the past to catch up on, and new ones will feature as they occur. Let me know via Twitter if you think of one that should be included.
In part the website is simply angry, fuelled by a frustration that so much stuff is deleted, so many communities destroyed, after people have taken a punt on a service and started using it. Yes, people have been using a free service, but they’ve also put some level of trust in the enthusiasm and hopes of those creating the service, trust that is too often mis-placed.
But I’m also trying to raise bigger questions. Is this the best way to structure and grow new businesses? Is this the best long-term model for keeping people interested in making and doing amazing things on the internet? Why do almost no websites or online services (my own included) have plans for what happens to their users’ content over the long term? If we should accept that no website or online service, particularly “free” ones, will last a lifetime or longer, what can we do about managing peoples’ expectations better?
I’m not saying, “these companies should keep their services operational forever.” That’s unworkable and we’d end up with millions of barely-used websites, all maintained at the expense of developing anything new. There is no simple answer, and some of these now-shuttered services have handled things as best they can: providing some (although rarely much) notice; offering downloads of data; preparing easy ways to transfer data to other, similar services.
But there is something fury-inducing and, I would say, morally wrong in start-ups persuading thousands of people to devote their time and energy to using a service that is summarily erased once the owners have been paid off. Yes, the owners may have worked hard, but without those users’ efforts they would not have their payday. They may well have had an incredible journey but, time and again, ordinary people are being led up the garden path.
]]>Since the 1920s, Canadian engineers have worn a ring on the little finger of their working hand as a reminder of their undertaking and the results of getting it wrong; the first rings, legend has it, were made from the remains of the Quebec Bridge after its humbling collapse in 1907. That failure, which happened before the bridge was completed, killed 75 workers and was directly attributed to engineers’ miscalculations of the weight of the enormous cantilevered span. The rings (before they were replaced by smooth stainless steel) were made of iron, left sharp and allowed to rust. Petroski celebrates the Canadian ‘iron ring tradition’ — which includes the reading of a poem written by Kipling for the bestowal ceremony, and its later, less poetic offshoot in the US — as a reminder to each engineer that his or her hand could be the one that draws the wrong line in a diagram, or computes the figures that prove inadequate to contend with gravity.
And, later:
Petroski estimates that it takes thirty years, the span of a single professional generation, for the failure encountered within the working life of a cohort to be forgotten. This is the cycle the iron ring tradition was intended to break. Still, we see the same mistakes, the same short cuts, the same temptations, the same disasters, repeating over time.
I love that members of a professions have this permanent reminder of “their responsibility to the public”, as the Wikipedia article on Iron Rings puts it. More from there:
The Iron Ring is worn on the little finger (“pinky”) of the working (dominant) hand. There, the facets act as a sharp reminder of one’s obligation while the engineer works, because it could drag on the writing surface while the engineer is drawing or writing. This is particularly true of recently obligated engineers, whose rings bear sharp, unworn, facets. Protocol dictates that the rings should be returned by retired engineers or by the families of deceased engineers. Some camps offer previously obligated or “experienced” rings, but they are now rare due to medical and practical complications.
Physical, constantly-present items to remind the wearer of their responsibilities.
]]>The first time round, the most tedious, soul-destroying, part of the whole enterprise was adding all the HTML links, 4,800 of them, into the diary texts. (People often say I “typed in” the diary entries, which isn’t the case; the text was already scanned into Project Gutenberg. I’d never have started if I had to type it all in as well.) Given that this process was now complete, there wasn’t much reason not to restart the diary from the beginning. Restarting only involves having the site’s front page and RSS feed automatically update daily with “today’s” diary entry.
Of course, I couldn’t let it be that easy.
The original website was made with Movable Type (MT) which, in 2002, was about the only option for making such a website if you didn’t want to code the entire thing from scratch. There were other tools for running weblogs but I needed something that could cope with what I thought would be some light customisation, and MT’s self-hosted code made that possible.
Over time any website built with a blogging tool — MT, WordPress, whatever — will, if it’s anything more than a very simple, single blog, become an unwieldy mess. The Pepys’ Diary site was no exception, growing from two inter-linked weblogs into six weblogs, templates containing Perl and SQL, custom PHP-based admin tools, and a web of connections that made it increasingly complex to add new features. All built on a platform whose future has seemed precarious for several years.
When I first started the site I didn’t really think through what it meant to begin a site with a built-in ten year lifespan, either in terms of the work involved or the technology’s likely lifetime. I didn’t need to live through much of the project before I realised “starting a website” was exactly what it says. If you start a website you’re only at the very beginning, and most of the work is ahead of you. Celebrating a launch is only the celebration of a birth; the bigger achievement is to have a successful life. This looming thought has, unfortunately, put me off starting many more projects over the past decade, because I’m always considering what’s ahead.
This time round I had a better idea what I was letting myself in for and what issues I should consider. Running the website for another ten years seemed feasible in theory, what with all the ongoing manual labour dealt with. But the practice — living with that clunky, flaky, slow technology for another decade — wasn’t something I looked forward to.
When 2012’s client work finished in December, and I made the decision to kick the project off again, I could see only one course of action: forget taking a much-needed holiday away from computers. I should, instead, re-write the entire site.
So far I’ve spent about ten days writing a new Django site to replace the old one. I was aiming for a minimal viable product of displaying all the existing data, exported from the old MT database but, for now, leaving out many of the nicer additions. I mostly hit my target, and have probably got the first 80% of the site up and running. There’s another 80% of features still to do which will probably take a similar amount of time. And then there’ll be the inevitable third 80% of bug fixes, enhancements, design improvements, and other features I’ve forgotten.
The code, and the data (without users’ comments), is all on Github, as is the simple script I use for publishing @samuelpepys’ tweets.
The process has been reasonably pain-free so far. It helps that I’m merely copying the functionality of an existing site — I know exactly what it needs to do and I don’t have to spend any time agonising over how things should work. My Django skills have also improved a huge amount over the past year, and the frequency with which I run into a brick wall of things not working how I expect has drastically decreased.
I also decided to abdicate most responsibility for the design of the site to Twitter Bootstrap. With limited time available it made sense to focus on the content and features rather than prettiness, and Boostrap has made getting a reasonable-looking site up and running much quicker. It’s not ideal — the site is a pretty characterless home for old Samuel Pepys at the moment — but that can be improved over time. At the moment, it works.
Although I am, inevitably, slightly regretting the task I’ve set myself — that’s January gone — it’s a relief to be wrestling less with Movable Type. I now have a custom-made site that feels much better. Linked parts of the site are joined in a sensible manner rather than with Perl sticky tape and PHP string. There are downsides: the old website was mainly static, MT’s main selling-point really, which was well suited to a large, rarely-changing website. I’m now suffering the teething problems of a site with several thousand dynamically-generated pages. On the plus side, it doesn’t take me an hour to rebuild the website when I want to make a tiny change to each page.
Looking ahead, how will I feel about this Django backend in ten years’ time? I’ve no idea what the state of the platform will be in a decade. It feels like the database is in a better place now — although MT’s data structure is reasonably sensible, its need to be all things to all people makes it a little harder to extract some custom data than is ideal. It does seem like Django has a reasonable process of gradual improvement rather than sudden world-changing shifts that render all old code obsolete, which is reassuring for a project like this. But, whatever platform a site’s built on, there’s going to be plenty of maintenance required over the course of a decade.
On 25th January I’m going to be speaking at The Design of Understanding. I’ll be talking about the experience of running The Diary of Samuel Pepys, and what it means to think about running a website over decades. I don’t know how much individuals and companies habitually think about this. Is it possible to plan for how your online service will work over the next ten years, never mind longer? If you have thoughts about — or, even better, experience with — this kind of thing, do drop me a line.
]]>The website has been completely rewritten, although it’s currently less complete than the previous one. All the diary entries from the previous run-through are still there but the front page and RSS feed are updating in real time again, starting with 1st January 1660.
The @samuelpepys Twitter account is also starting from the beginning. While starting the website’s diary again doesn’t involve any of the laborious work (adding thousands of hyperlinks to the text) this time round, these early tweets all need some preparation. Twitter didn’t exist when the project began (can you even imagine such a time?!) so the first few years were tweetless. But this is a less onerous task than the diary text preparation.
Tell all your friends!
(At some point I’ll write more about the rapid Christmas holiday project of extracting the website from the crusty claws of a decade-old Movable Type installation into the modern robotic hands of Django.)
]]>