Last.fm's shame aggregator
Most Unwanted Scrobbles - Last.fm aggregates the tracks and artists that people don’t want the internet-at-large to know they listen to. Britney Spears appears twice in the top five songs, along with Nelly Furtado, Amy Winehouse and Avril Lavigne. The Beatles, Radiohead, Britney Spears and Avril Lavigne are the top 5 arists (along with Unknown.)
So I guess Last.fm users are just too damn cool to admit to some of their tastes. Me, I’m fine with letting you know I listened to Sir Mix-A-Lot’s Mack Daddy in its entirety this week.
Domain Driven Design
Designing software is a tricky thing. It’s tempting to front-load it on a project. That won’t work because the start of a project is when you know the least about it. So some folks try to do as little design as possible. I’m guilty of this. However, that can lead to software that doesn’t adequately express the problem it’s trying to solve. Further, there is often a temptation to over-design software with lots of ceremony and architecture. Contrary to this is the temptation to not design it at all, which again leads to software that doesn’t express itself.
There’s a book that draws a reasonable compromise between these forces. I’ve been meaning to read Eric Evans' Domain Driven Design for a while now. The emphasis of the book is in collaborating with domain experts and other developers to find the essence of the problem space and then express that in software (as objects). I’ve often pointed out the utility of building applications from the language up and the problem domain down. DDD focuses precisely on the latter.
One of the core concepts in the book is the ubiquitous language that is used to describe the problem at hand. This language is used by the domain experts (customers) and the developers. The language is then woven into the design of the system. This leads to software that is more likely to succeed, both in business terms and in terms of development effort. Evans spends the first part of the book describing the particulars of this language.
He then moves on to describing the technical side of the software. Entities, value objects, services, factories, modules and repositories are terms I was already somewhat familiar with that Evans gave a more crisp and satisfying definition to. For most people, this is probably the tasty meat of the book, illuminating the way from a competent developer to an outstanding developer.
The last part of the book focuses on the larger scale issues of deep design. I was particularly pleased that he covers how software design is affected by various good and bad social issues. It also gives a strategic view of the forest, where most books on software development focus on a more tactical view of each tree.
I’m fond of pointing out books that are inflection points in my way of thinking about software development. Code Complete, The Pragmatic Programmer, The Dragon Book and My Job Went To India all fall under this category. Domain Driven Design is certainly the latest edition. It makes sense of trends I see in great software and illuminates a path to make software like it myself.
If reading this review didn’t make you want to vomit, you should probably read the book posthaste.
Interview with David Flanagan, part 2
The second part of my interview with David Flanagan is online. This time around we talk about the craft of programming in general. Its good stuff.
Io's intriguing design
I didn’t manage to touch on this in What Has Ruby Done For You Lately, but Io is a really impressive language. Mostly in the minimal number of concepts one needs to grasp in order to deeply understand the language.
To pick on Java (sorry), a list of concepts you need in order to grasp Java:
- Primitive types
- Objects
- Classes
- Interfaces
- Inheritance
- Iteration
- Conditionals
- Operators
- Type casting
- Generics
- Method calls
I’m sure I’m missing some. Further, that’s just what you need to write a program with one class. To build a realistic system you need to know about class paths, packages and all sorts of arcane details.
In comparison, to build a simplistic Io program, you need to understand:
- Lazy evaluation
- Objects as prototypes
- Short circuit evaluation
- Messages
- Closures
That list ended up about twice as long as I thought it would, actually. Really, all the average practicing programmer needs to learn is prototypes and lazy evaluation.
Io's guiding design principle is simplicity and power through conceptual unification.
That quote, from the Io Programming Guide, pulls it all together and summarizes why the language nerd in me is quite interested in Io.
Catch up with 30 Rock
OK, here’s the deal. If you’re not watching 30 Rock, you’re not watching the best show on TV. There I said it. Fortunately, you’ve got time to catch up; the show doesn’t come back until October 30th. To whet your appetite, I give you clips summarizing the “lives” of the two main characters, played by Alec Baldwin and Tina Fey.
Interview with David Flanagan
Last week I interviewed the author of The Ruby Programming Langauge, David Flanagan. We posted the first part of it today - Five Questions with David Flanagan, Part 1. The second part will go up next week. Enjoy!
American demographic inversion
In the past three decades, Chicago has undergone changes that are routinely described as gentrification, but are in fact more complicated and more profound than the process that term suggests. A better description would be "demographic inversion." Chicago is gradually coming to resemble a traditional European city--Vienna or Paris in the nineteenth century, or, for that matter, Paris today. The poor and the newcomers are living on the outskirts. The people who live near the center--some of them black or Hispanic but most of them white--are those who can afford to do so.
A fascinating read for those who like to think about how our cities evolve.
Refactoring to more code
Refactor my code is a neat site where you can post your code and watch others refactor it. I saw an interesting bit of code whiz past and thought I’d take a crack at it.
Removing conditionals from code is one of the little games I sometimes play while coding. Here, I’ve extracted the logic of the conditional into another class. The resulting class is much more code than the original. So why do that?
Well, I say you get a few benefits:
- The logic is now far easier to test. It’s a standalone object now rather than a Rails functional test.
- The flow of what’s being done and tested is more decomposed and easier to follow.
- Most importantly, the code explains itself. No need for comments (which will undoubtedly go out of sync over time) here!
While I delight in deleting code and writing as little as possible, refactoring this to more code seems the right way. What say you?
Update: Make sure you check out Marcel Molina’s refactoring. Its probably better than mine ;)
Program is information.
Its retro, its cool. It’ll come in handy when I need slides on the sameness of code and data in good programming languages.
Via Square America.
Realtime challenges
beyond rest - if publishing data in realtime, XMPP, Comet and scaling HTTP services pique your interest, this thread is an excellent read. Lots of smart people disagreeing here.
Some Grieg
Please to enjoy, Grieg’s Piano Concerto in A minor. Brought to you by Artur Rubinstein and the London Symphony.
The rest of the first movement, the second movement and third movement, also for your enjoyment.
Thor and agility
Watching Thor at his agility classes is really interesting. It’s fun to see the dogs constantly looking up to their person to see what jump or obstacle to go to next. Of course, the class is half dog training and half people training.
I’ve noticed a distinct change in Thor’s obediance since he started taking the classes. He’s more receptive to good boy/bad boy commands now. And, of course, he’ll do anything for food!
Here’s some video I took of Courtney and Thor doing their agility thing.
HTTP wrappers with ease
httparty looks really cool. It’s a little library for making writing tiny REST clients easier. From the examples (edited for length):
class Twitter
include HTTParty
base_uri 'twitter.com'
def initialize(user, pass)
self.class.basic_auth user, pass
end
# which can be :friends, :user or :public
# options[:query] can be things like since, since_id, count, etc.
def timeline(which=:friends, options={})
self.class.get("/statuses/#{which}_timeline.xml", options)['statuses'].map { |s| s.to_struct }
end
end
twitter = Twitter.new('bob@example.com', 'bobtime')
twitter.timeline.each do |s|
puts s.user.name, s.text, "#{s.created_at} #{s.id}", ''
end
Great job, John!
Agility course made of people
Wow.