Mashed Articles

The new social/iTunes friendly interface is available now.

All work in the office temporarily stopped in the name of playing with the new Spotify client - until we remembered that we can actually get away with calling that work, and therefore hurrah. It’s an interesting release. The iTunes import is… finnicky. Having the option is handy, and long overdue, but so far we’re mostly hearing complaints about how it actually converts a standard library into Spotify form. Once integrated though, there are some snappy new features, including starring tracks and sorting by online and local music.

It’s the Social functions that stand out more though, and not necessarily in a good way. You can share tracks and playlists via Twitter, but there’s no URL shortening – giving you tweets like this:

http://open.spotify.com/user/probablyrichard/playlist/18iOaRSKX3IrrPz5pCRnc8 Spotify playlist: Bioshock 2 Soundtrack

Whoops. The Facebook integration isn’t much better, in my case titling the import as “”Playlist by probablyrichard – Spotify” instead of anything useful, with no album art, and only the standard description block for details.

What really annoys me though, as with most social sites, is the presumption that we all want to share everything. Click the button to allow Facebook connections and by default, all of your playlist information is made public. You can switch this off for future playlists and manually switch off your recent tracks and top artists, but that’s still vital seconds where your friends and family can learn you listen to nothing but the Banana Splits theme song on a perpetual loop. Hypothetically, of course. Whatever Mark Zuckerberg wants, I like to pick and choose what I broadcast to people I know. Trust me, it’s better for all of us.

I do have a sneaky selfish reason for wanting social features though, despite all this. I guarantee that following me, you’ll learn nothing about music and pick up no tunes worth listening to. My musical knowledge is zero, and actually falling on a yearly basis. On the other hand, having easy access to friends’ stashes is helpful. I don’t have to keep asking “what should I listen to” and adding things to my own secret library is easy.

Even so, I don’t want to see all their stuff, just the recommendations.

The new Spotify is available to download now, and will be auto-updating in the next few days. Alex just asked “How can I go back to the nice clean interface without all this Twitter rubbish?” The answer is: you can’t. The future is apparently here, and to judge from our office, largely atonal.

(Seriously, drum and bass? Buckets being smacked with a rake.)

While enjoying holidays, I read the book “Programming Amazon Web Services” by James Murty. As explained in my earlier post, I was most interested to learn how cloud computing could be leveraged for developing integration solutions.

The book discusses 5 Amazon Web Services (AWS):

• Simple Storage Service (S3)
• Elastic Cloud Computing (EC2), virtual Linux servers on demand
• Simple Queue Service (SQS), to deliver short messages
• Flexible Payment Service
• SimpleDB – simple database with no SQL support

The book goes into quite some technical detail and has code snippets showing in detail how to interact with the Amazon services. All the samples are written in Ruby. I don’t know Ruby, but the code is quite readable (should read Enterprise Integration with Ruby some day). The author prefers the REST and the Query API. Unfortunately, he does not show anywhere the use of the SOAP API to access Amazon WS.

The 1st chapter is introductory and e.g. explains how to use self-signed certificates to connect with AWS, explains how AWS were developed for internal use by Amazon and later turned into a products, come without an SLA (except for S3) and without real support.

In the 2nd chapter, the author builds up a library of Ruby code to access the Amazon Web Services. This is very well written and gives an immediate feeling for some aspects to take into account, e.g. clock differences.

S3 is covered in chapters 3 and 4. No standard file access but the use of buckets and objects through a non-standard API (REST or SOAP); no FTP, WebDAV or SFTP. And objects cannot be modified: only deleted and re-created (after the deletion has propagated). Ruby code is shown for all the options the API offers: bucket creation/lookup/deletion, object creation/listing/deletion, ACL update/retrieval and access logging file retrieval. Tricks with HTTP header fields (object metadata), posting data through forms, alternative hostnames and BitTorrent are discussed. The last part discusses signed URI’s: this is a neat trick to make S3 resources temporarily accessible to users without Amazon account.

Chapter 4 shows some applications of the S3 service: large file transfer, backup, turning S3 into a file system (with FTP or WebDAV). Interesting to note that the author has his doubts wrt. exposing S3 as a file system. The author also discusses his own Java open source application: JetS3t. This application is a “gatekeeper” for S3 resources and authorizes local agent applications after acquiring signed URL to upload files to S3 and download files from S3.

Chapter 5, 6 and 7 dive into EC2 and how virtual Linux systems (based on Xen) can be configured using Amazon Machine Images. Ruby code is shown for every available API: keypairs (for SSH access), network security (dynamically configure the firewall), images and instances. Chapter 6 explains instances in more detail and discusses how to create new images. This involves quite some commands and scripts at the Linux command prompt. Chapter 7 discusses some sample applications: VPN server, web photo album thereby backing up data on S3. Chapter 7 also discusses issues around dynamically assigned IP addresses and the use of dynamic DNS.

The Simple Queue Service (SQS) is discussed in chapters 8 and 9. Because of the small message size, SQS is clearly meant for events with actual data stored on S3 (or elsewhere). Again Ruby code to manipulate queues and messages. Chapter 9 describes a Messaging Simulator application, not that relevant in my opinion. The 2nd application – leveraging a video conversion tool – shows how to build generic service for implementing “batch” services (Command Message pattern). The 3rd application – LifeGuard – leverages SQS to manage EC2 instance pools and dynamically scale the number of EC2 instances.

The chapter on payment service I skipped and I only skimmed through the SimpleDB chapter. Enough to learn that SimpleDB is not an RDBMS but a basic storage mechanism (no data types) with proprietary query facilities (no SQL).

The author writes fluently and gives a non-biased view on the Amazon Web Services. Sometimes the code goes into too much detail, showing how to invoke every available method of the API. Although the book is very recent (March 2008), important new features such as elastic IP addresses, persistent storage for EC2 and availability zones weren’t yet available at the time of writing. The book definitely taught me that AWS is quite proprietary and not that trivial. And to use Amazon’s cloud computing and AWS, you’d better “think like Amazon”.