« February 2006 | Main | April 2006 »
March 25, 2006
Revealing the Workings: A Trend in Album Art
How many instances of something does it take to make a trend? This week, I bought my third record in recent history that includes, in its liner notes, something of a guide to its production. And I'm not just talking about basic names and places either, but attempts at comprehensive documentation of the means and materials behind the recording.
The first was In Case We Die by Architecture in Helsinki [warning: terrible flash site with auto-playing music]. This excellent, fun, sprawling Australian band includes upwards of ten members and their songs feature surprisingly diverse and varied instrumentation. In order to document the specifics of each song's line-up, the band included an instrumentation grid:
The x-axis, along the top, is labeled with track numbers 01-12. The y-axis lists all the possible instruments (from Roland SH-101 through "Hand and Power Tools"). And the lighter dots indicate the presence of a particular instrument on a particular track -- which is counter-intuitive, but made clear if you look at the lines of dots for Sitar and Electric Guitar. The result resembles nothing so much as a DNA printout:
A similar example is this week's new Loose Fur record, Born Again In The USA. Loose Fur is something of a Chicago all-star band featuring Jeff Tweedy of Wilco, producer, composer, and all-around solo-genius Jim O'Rourke recently of Sonic Youth, and Glen Kotche, drummer for Wilco and much of the Chicago experimental jazz world. Compared to In Case We Die, Born Again In The USA features a more traditional line-up with less instrumental variety. Their instrumental grid is, therefore, much sillier and more playful than Architecture in Helsinki's. Each page of the booklet has a line of incredibly unflattering pictures of each band member (it looks like they simply pressed their faces against the bed of a scanner and shut their eyes while the light passed over them) with close-up snapshots of their instruments arrayed below them:
The result is shambling and informal and feels much like the record: seemingly straight forward but hard to get a complete hold on, easygoing and unprepossessing yet backed by a high level of technical mastery.
The final example, Drum's Not Dead by the Liars takes this idea to the furthest conceivable extreme. The Liars is an itinerant band recording each consecutive record in a different city. Drum's Not Dead found them physically in Berlin, but mining mostly a musical history dominated by New York: the dark abstract physical muscularity of No Wave.
Drum's Not Dead's liner notes seem designed to do nothing less than allow the reader to recreate the record from scratch themselves at home. They describe virtually every aspect of the sound generation and recording process for each song. Here are the first two pages of the booklet:
The text on the left page describes what guitars they used ("Fender Jazz master, Gibson SG, Squire Music Master copy customized by the handsome, talented, and gentle Ole Wolfers") along with their tunings and string gauges. The right page has the notes for the first song:
Julian's kit mic'd with unbalanced Sure microphone through B-26 Pitch Shift setting on Roland Porta Studio activated at the end of the song. Aaron's kit mic'd with same unbalanced microphone through Boss, PS-3 then MXR D+, then RV-5 stereo split through Amplifiers. Drum mics placed facing amplifiers. Regeneration produced differently according to room size and acoustics. Angus & Aaron play guitars tuned to DFFCBB.And then there's a hand-scrawled chart showing how everything was arranged in the room and giving additional technical information. It continues like this for each song on the record.
What does all of this mean? My instinct is to say something about the influence of music on the role of the CD in music distribution and the relationship between bands and their audiences. When anyone anywhere can get any of your songs anytime online, the physical CD has to provide something extra beyond the music. And the most compelling thing it can provide is a sense of being brought into the band's world. Using liner notes to reveal the means used to make the music is a way of doing that, giving everyone a chance to see things from the band's vantage point. This goal stands in stark contrast to the role of albums and the use of album art in the high period for albums as an artistic medium: the late sixties. For bands of that era, albums were complete indivisible aesthetic statements in themselves and their art served to surround their makers with myth and to obfuscate their own making. Think of Sgt. Peppers, Cheap Thrills, and Blue. If these sleeves provided any information about the songs they contained it was in the form of lyrics to be poured over, analyzed, and debated. They were vehicles of their authors' legend.
In the age of file-sharing, mp3 blogs, and the iTunes store, the album is waning, at least as the unit of music distribution if not necessarily of production (it will take a while for the creative and economic advantages of writing, recording, and releasing music in batches to be overcome by the increasing technological ease and omnipresence of all of these processes). And, more importantly, the age of the distant Rock Star Legend is ending. Fans are, increasingly, demanding not the distance required for the creation of mythology, but intimacy. They want bands to blog and make themselves and their music available to bloggers. They want bands to release music under lenient licenses that allow them to become creatively involved with it through remixing and mashups. And they want to see bands play in smaller more intimate venues.
If the album is going to thrive under these circumstances rather than be made irrelevant by them, it is going to change. It will become a vehicle for this intimacy. More, it will have to become just one small piece of traffic in an entire highway network connecting bands to their fans more closely than ever before. Maybe, just maybe, this trend marks the beginning of that change.
Tagged: liner, notes, music, liars, architecture in helsinki, loose fur, album, trendPosted by Greg at 5:17 PM | Comments (1)
March 13, 2006
Why Rails?
While in a less than fully sober state after the Less Distracted Party last night, Chirs made a disturbingly sound suggestion: now that I'm posting Rails tutorials with some regularity, it might be a good idea to write something about why I find Rails so exciting in the first place and, more specifically, how it fits in with the kinds of things I've always posted about here in the past.
Anyway, what's my answer to Why Rails?. My answer doesn't involve any technical mumbo-jumbo about it being a "fully-integrated web mammy-jammy that requires less XML flim-flam"[*], my answer is simple: Rails lets me make my ideas real. Let me give you an example.
For the past week, I've had a couple of ideas cooking for posts. They're both in the classic IDFDZ style: ideas for ways that common technical experiences could be improved or that technology could be made more useful in everyday life. They would fit comfortably amongst posts like: Bloggable Public Space, Hyperlinks for iTunes, and Use Automator to Append from Anywhere -- things I tend put into the category of Useful Web. The thing is, I haven't posted them because, now that I know Rails, writing them up seems like almost as much work as actually executing them myself.
Here are the ideas:
(1) Mp3 Blog-o-Sphere Influence Map - As part of my preparation for the coming At Dusk New Album Promotion Whirlwind and Clambaketm, I spent a big part of a recent evening making a mental map of the mp3 blogosphere. Now, if you're interested in mp3 blogs, but don't have the thousands of hours it would take to even glance briefly at, say, the two hundred most interesting ones, there's a variety of search engines, indexes, and compendia like elbo.ws, Web Nymph and, of course, Hype Machine (which is easily the best of them) to help you out. They're all great for finding a few of the best blogs or some that might happen to cater to your particular taste. But what they won't give you is a sense of the overall geography of the mp3 blogosphere itself: who listens to whom, which are influential but more obscure, who gets the hot leaked tracks first, who sets opinion in each genre, etc. While staring at my text file with more than 250 urls for mp3 blogs, I had an idea for an app that might be able to start to answer some of these questions. It would begin with a database containing those blogs names and their urls. Then, it would include a script that would, periodically, look at each of the blogs to see which ones linked to which others, to start a map of the social connections. Next, you could start to track songs as they appeared on each blog (by looking at the text of links and even the names of the files that get linked to) and tracking their progress as the got picked up by more blogs and moved through the chain of influence. To put a cherry on top, you could even use the Technorati API to find out which blogs talk about which other blogs and which posts shared common tags. With the data I'd already collected and just the tiniest bit of programming elbow grease, you could start to put together a pretty good picture of how the mp3 blogosphere worked, a picture that might be of interest to quite a few people: aspiring bands, recruiting labels, music pr and marketing muscle, etc.
(2) The Useless Flickr Historical Weather Search - The last week, we've been having incredibly bizarre weather in Portland. It even snowed heavily late one night, enough to stick if only for a few hours. Being a night owl, I caught a picture:
While I was uploading it, the thought crossed my mind that the snow's appearance was so brief that, for plenty of Portlanders waking up the next morning, the presence of my picture in their RSS inbox might be their only direct evidence of it having snowed at all. Also, I realized that, in the metadata to my photo (and I'm sure plenty of other people's), there was as cogent a weather report as I'd ever seen. Tags: "portland oregon night snow storm" and Date: "Taken on March 9, 2006". Pretty soon I was clicking around the tag cloud and realizing that you could, with erratic success, use Flickr to tell you what the weather had been like in a particular city on a particular day. I could see an app: type in a city, state, or country and a date in the past, and find out the weather, with pictures. Did it snow in New York on your grandmother's birthday last year? Was it a White Christmas in Chicago? Once you'd correlated the weather, location, and date together, you could show pictures of what it looked like. Graphs! A widget! You get the point: useless, somewhat playful, kind of surprising use of a photo sharing site to reverse-predict the weather.
Now neither of these ideas are particularly technically challenging or all that innovative or exciting. There's probably no money in either of them. What they are, basically is frivolous. The thing is, now, I'm almost sure that I've spent longer writing them up than it would have taken me to build Rails-based sites that would constitute at least basic 0.1 alpha versions of them. Since Rails handles all of the things that get repeated across each new web application project now matter how big or how small (and handles them with a great deal of grace and ease) it makes the small ones almost too easy. Without the overhead, all you're left with is the idea. And if it's modest enough, as these certainly are, and you've articulated it clearly enough to yourself, there's really very little work involved in making it real. Rails makes building frivolous applications practicable.
For example, the biggest single chunk of time on the mp3 blog app would be taken typing in the names and urls of the blogs themselves (in fact, it would almost definitely be faster, at this point, to write a script that would import them wholesale from my text file). On the Flickr app, the big technical challenge is actually talking to the Flickr API (I've been glossing over this: API stands for "application programming interface". With web apps like Blogger, and, especially, Google the companies behind them make their data and functionality publicly available for use by other people over the web. That's how you see Google maps on every new website and blogging software than can send your posts directly to your Blogger blog.). But there are such great tools for talking to the Flickr API in Ruby, that doing so has been compared to writing florid love poetry.
Rails development is so easy and quick that there really doesn't have to be a practical motive (let alone a financial one) for taking on small projects like these. Put another way, Rails makes it possible for web development to become art: an expressive medium whose practice is an end in itself.
Posted by Greg at 4:03 AM | Comments (0)
March 8, 2006
learns_to use migrations
As I mentioned earlier, I was recently hired to do actual paid work as a Rails developer (as unbelievable as that may seem to those of you who've actually met me). I'm beginning to realize that, in addition to this stupefying fact in itself, I also won the employer lottery. My bosses are three guys. They're nice, highly communicative, and -- best of all -- extraordinarily responsive to my input at every level from implementation style all the way up to application design and even business model planning. I can't say too much about the specifics of the job (they actually had us sign an NDA, how 1999!), but I can say that the guys are highly experienced java programmers who have more experience with web development and startups than I probably ever will (check out Jonathan's resume. . .and he's just one third).
This project is their first Rails app so part of what they want is, naturally enough, for me to share whatever inside dope I may have on Rails' workings. I decided that the best way to do this would be for me to write a series of learns_to posts here on the topics I decide to cover and then follow-up in private with specifics that relate to what we're building. That way, some poor Googling sap potentially gets some help on his questions (I was that poor sap not so long ago, so I know how much help the well-written random blog post can be) and the guys some customized documentation to get themselves, and anyone else they bring on in the future, up to speed double quick. So, without further ado, let's learn Migrations!
With Migrations, Rails provides a way for you to abstract your database schema in code. In simple terms, a migration is a chunk of Ruby that represents a set of changes that you want to make to the structure of your database -- which sounds complicated and confusing, but becomes suddenly clear if we look at an example. Say, we're creating a simple blog application. We've got users and posts each of which have a couple of attributes. Here's the migration we'd write to get our database set up.
class OurFirstMigration < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.column :name, :string
t.column :updated_at, :datetime
t.column :created_at, :datetime
end
create_table :posts do |t|
t.column :subject, :string
t.column :body, :text
t.column :updated_at, :datetime
t.column :created_at, :datetime
end
end
def self.down
drop_table :users
drop_table :posts
end
end
Now, this is pretty human readable. Like every migration, ours has two methods, self.up and self.down, the first of which gets run when we're moving up through this particular migration making these changes for the first time, the second when we're going the other way and undoing them (more on the rough-and-tumble details of actually running migrations a little later). The first is obvious: in self.up we create two tables, called "users" and "posts" respectively, each of which has a handful of columns that store various predictable attributes of users and posts. The second method, self.down, rolls back our changes, destroying the two tables we just created. Now, that doesn't seem especially useful when we're just at the point of creating our database in the first place. On the other hand if we were in our seventh or eighth iteration and had made radical (and potentially boneheaded) changes to our schema this method would come in incredibly handy. If we decided that we needed to undo our recent changes (to revert to an earlier database structure), we could do so without nuking the rest of our database schema or any of our data. You can think of these methods as built-in version control for your database.
So, you say: What exactly are the practical advantages of using migrations to manage changes to my database? I already keep my SQL schema under version control. That's how they do it in the Agile Book. What do you know that DHH and Dave Thomas don't? Well, the reason DHH and DT didn't mention migrations in Agile is that, despite their other many achievements, neither of them have (yet) invented a time machine. Migrations are maybe the most exciting of a spate of great additions to Rails that first appeared around in the run up to version 1.0[*]. And their advantage is that they bring all the Rails virtues to database management, making it easy to learn, powerful to use, and beautiful to behold.
First of all, with migrations you'll manage your database schema in Ruby just like the rest of your project; you don't have to jump into SQL (or learn it in the first place) every time you want to make a change. Beyond just the convenience for you, staying within Ruby also means that Rails is able to offer the same two great virtues when you're managing your database that it does everywhere else: abstraction and convenience. Migrations don't care what kind of database you're using. Rails will translate your migration into the right kind of instructions for any of the supported database formats (MySQL, PostgreSQL, SQLite, SQL Server, and Oracle). That means you can develop on MySQL or SQLite (or develop on one and collaborate with someone using the other) and then deploy on Postgres, all without a second thought. Abstracting out the specifics of talking to the database will mean fewer configuration headaches and, therefore, more flexibility to change your system around. And we've already seen the benefit of having access to Rails convenience methods in the concision and clarity of our sample migration. Methods like create_table, drop_table, add_column, and remove_column (see the Active Record Migration documentation for a complete list) make managing our schema as simple and painless as it could reasonably be.
Another almost unreasonably cool side effect of migrations being first class Ruby citizens is that you can use them to populate your tables as you're creating them. Let's say that we wanted to organize the users of our blog application into groups (i.e. Group would have_many :users and User would belong_to :group). We could write a migration that simultaneously creates the groups table, adds the foreign key to the users table, and fills in the necessary data to assign all of our existing users to a group like so:
def self.up
create_table :groups do |t|
t.column :name
end
add_column :users, :group_id, :integer
User.find(:all).each do |p|
p.group_id = 1
end
end
Rails is also smart enough to add an id to each table without having to be told (you actually have to tell it not to by saying something like "created_table :group, id => false do |t|. . ." if you want it not to create an id column, as you would if you were creating a join table).
So far so good. Let's talk implementation. Let's say you've just started creating your blog software. You've run the Rails command to create your project, created your production, development, and test databases, and edited database.yml so that Rails knows how to talk to them. Now it's time time to write your migration. First, we've got to create the file. Rails, of course, gives us a command for this:
> script/generate migration OurFirstMigration
You can give your migration any camel-case name you'd like, Rails doesn't care. In our example, this command would create a file called 001_our_first_migration.rb in /db/migrate. Open it up and you'll find a blank migration with empty self.up and self.down methods. Populate them with your migration methods in the style of our first code example above. Once you've done that, all that's left is to run the migration:
> rake migrate
That comand will bring you up through each of your exiting migrations in turn in order to jibe with the most advanced state of our schema. We've only written one migration so far, but look at your database. It's got tables and columns, created just like we specified, oh my! But wait, that's not all, rake migrate is also smart enough to take a version number. If you want to, say, migrate from the fifteenth iteration of your database schema back down to the seventh, all you've got to do is:
> rake migrate VERSION=7
Clearly, depending on the changes your migrations make to the schema some of your data can get lost in the shuffle. Rails isn't actually magic. If you drop your posts table, the data in it gets dropped, too. So, think carefully when you design the granularity of your migrations. If you lump a bunch of schema changes together then it's going to hurt all the more to roll them back when you've got real data. Conversely, while you're developing feel free to migrate up and down willy nilly anytime you've accumulated too much nonsense data in your tables.
There's probably plenty more to be said about migrations, but this should be enough to get you started. And, of course there's always more reading you can do. For example, there's a pretty good discussion on the Rails wiki under the heading Understanding Migrations and when in doubt you can always RTFM. So, go on. What are you waiting for? Rake migrate!
[*]My copy of the Agile book is dated August 2005, and while the Loud Thinking post announcing migrations went up on July 6th, I'm sure that was after the book had gone to press. Stupid dead tree-based publishing!
Posted by Greg at 2:22 AM | Comments (5)
March 2, 2006
IDFDZ in the WWeek
Here's a weird sentence: IDFDZ was mentioned in a newspaper. The portland alt weekly, Willamette Week, where I was once an intern has joined The Oregonian as part of the swarm of media around the second season of Urban Honking's 'reality blogging competition' Ultimate Blogger. The quote comes in the midst of descriptions of a handful of UrHo blogs:
Ideas for dozens: A techie geekfest by former WW intern Greg Borenstein. From Jan. 24: "I honestly can't remember the last time I listened to commercial radio.... So, what's left? More and more, what's left is: mp3 blogs. Just individuals out there talking about music, bravely posting songs they like despite the potentially quite serious legal consequences of the musicians' and labels' ungratefulness."Its from my post about Hype Machine.
As you can see above, if you've got a keen eye, the photos for the article where taken at Less Distracted, the office/wharehouse space I share with the Urban Honking guys. A photo of LD also accompanied the Oregonian article on Ultimate Blogger making it the second most famous place I've worked recently.
Anyway, congrats Mike, Steve, and Jona! Now, all you've got left is the Tribune and the Mercury and you'll have run the table! How 'bout it?
Tagged: urban honking, blog, press, willamette week, portland, oregon, less distracted, ultimate bloggerPosted by Greg at 11:58 AM | Comments (1)
March 1, 2006
learns_to use the ternary operator to make concise views
Rails' templating system has lots of advantages. It's simple, lightweight, and intuitive. And since it's still just Ruby, you can refer to things exactly the same way as you would anywhere else in your application. The intuition you've built up working in your models and controllers and script/console (you do you use script/console constantly while you're developing, don't you? If not, you're missing out on about half the fun of Rails) about how to call up your user's name will still hold: it's still just @user.name.
The one downside I've found is that the syntax for view logic can get kind of verbose, especially when you're doing repetitive things like displaying defaults for each piece of data you've got that's not set, like so:
<h3>Name:</h3>
<% if @user.name %>
<%= @user.name %>
<% else %>
<em>[no name set]</em>
<% end %>
If you have to do that four or five times on a page, then all of a sudden you've got a template that is getting long and hard to follow.
Here's a quick little trick to handle that kind of situation much more concisely and clearly. It takes advantage of the fact that Ruby almost always provides multiple different ways to accomplish the same thing using different syntaxes. In this case, we'll use a very dense C-style if-then syntax that Ruby supports, which uses a ternary operator (the section on this syntax is well down that page, if you search for "c-style" it should pop right up). It looks like this:
condition ? if_true : if_false
or, in the case of our view logic from above:
<h3>Name:</h3>
<%= @user.name ? @user.name : "<em>[no name set]</em>" %>
How does this work? Ruby evaluates the expression to the left of the question mark. If that expression is true then it returns the expression between the question mark and the colon, if the expression is false, it returns what comes after the colon. Simple. And suddenly we've lost a lot of lines and lot of potential places for confusion from our views.
Like with anything else, there are a couple of small gotchas to look out for. First of all, you've got to make sure that the attribute you're evaluating on (in our case @user.name) will return either nil or false if it's not set. If it has any kind of default value, it will return true and then your conditional expression will do exactly the opposite of what you were expecting. The other danger here is making sure you use proper parentheses if you have any kind of a compound statement as the conditional as either of the outcome. Without them, things can get confusing in a hurry.
This may seem like a small change, but it will make every time you comeback to look at your views in the future and have to figure out what's going on in them from scratch more pleasant. It's also just the Rails thing to do: less code where possible, and code that feels 'beautiful' to you where it's not.
Tagged: ruby, rails, views, syntax, ternaryPosted by Greg at 2:53 PM | Comments (1)
