I finally got around to signing up for a FeedBurner feed for DevHawk today. It’s available here. I’ve updated my site template, but existing readers are still getting the old feed. Scott has built support for FeedBurner into dasBlog, but it isn’t released yet. Feel free to switch over on your own if you want, but I’ll get the automatic redirection working soon enough.

Update: Apparently I didn’t look hard enough. FeedBurner support made it into the currently shipping version of dasBlog, so I’ve turned it on. Thanks to Tomas Restrepo for the heads up.

One of the topics that comes up regularly in the context of Web 2.0 is the idea that social software gets better the more people use it. Tim O’Reilly wrote about it when describing Web 2.0 and brought it up when he was on stage with Bill Gates at MIX06.

Tim called it a principle of Web 2.0. But I don’t think getting better with use is exclusive to social software. Alan Cooper wrote about building software that learns how the user works and optimizes itself for that usage pattern. For example, Windows Vista has a new feature called SuperFetch that “understands which applications you use most, and preloads these applications into memory, so your system is more responsive when you first boot or when you switch to a different user profile.”

The big difference that I see is that personal software has to be designed to learn where social software automatically improves with use.

I saw reference to ChucK on Prompt Criticality, a Second Life Blog. I wanted to blog it for my own reference if for no other reason. ChucK is “a new audio programming language for real-time synthesis, composition, and performance” that “presents a new time-based concurrent programming model, which supports a more precise and fundamental level of expressiveness, as well as multiple, simultaneous, dynamic control rates, a precise and straightforward concurrency, and the ability to add, remove, and modify code, on-the-fly, while the program is running, without stopping or restarting”.

Sounds facinating, esp. given my recent discussion of internal vs. external DSLs w/ Neal Ford. Plus it deals w/ concurrency and is dynamic.

I wrote of my meeting w/ Neal Ford a few weeks ago. Today he has a long post on what he calls Eating Sacred Hamburger that goes into more detail of some of the things we discussed:

Software development cults tend to create sacred cows: habits and idioms that might have meant something at one time but only remain as baggage now. I tend to like to kill sacred cows and grill them up, with some nice lettuce, tomato, and a sesame seed bun. On my current project, we’re actively killing some sacred cows.

The main sacred cow he’s talking about slaughtering is Hungarian Notation for interfaces. You know, interfaces like IDbConnection and IHttpHandler.

Thankfully, Hungarian Notation has mostly been banished, except for one lingering, annoying location in the .NET world: the stupid “I” preface on interfaces. In fact, if you understand how interfaces should be used, this is exactly the opposite of what you want. In our application, every important semantic type is represented by an interface. Using interfaces like this makes it easier to do a whole host of things, including mocking out complex dependencies for testing. Why would you destroy the most important names in your application with Hungarian Notation telling you it’s an interface? Ironically enough, that your semantic type is an interface is an implementation detail — exactly the kind of detail you want to keep out of interfaces. I suspect this nasty habit developed in the .NET world because interfaces first came to the Microsoft world as COM (or, back when it started, OLE). It’s a stupid cow now, and should be slaughtered.

I agree 100% with this, though I’m guessing the next time I write an interface, I’ll have to go back and delete the stupid “I” because I’m so used to writing it.

The other convention he’s looking to do away with camel and pascal casing, which is convention in .NET. He’s a bigger fan of using underscores between words (which is big in the Ruby world). So far, he’s only using underscores in his test methods since they tend to be longer, such as “Verify_end_to_end_security_connectivity_to_infrastructure”. Frankly, I’m ambivalent on this one. I’m pretty good at reading camel and pascal casing and I would hope never to see a production method name like that.

So that’s two down, but there’s still an entire herd of sacred cows out there. What other ones do we need to get rid of?

When I wrote about the Dual Schema problem a few weeks ago, I specifically wrote that the Rails model is backwards because it derives the in-memory schema from the database schema. While I still believe that, Rails’ ActiveRecord::Migration library does make it significantly easier to manage the database from Ruby code. For those not familiar, ActiveRecord::Migration is a series of Ruby script files that define the database schema. Inside each migration script is an up and down method, so you can migrate forward and backward in the history of your project. And it provides easy to use abstractions such as create_table and add_column so you don’t have to geek out on SQL syntax (unless you want to). Once you have a collection of these scripts, simply calling rake migrate will bring your database instance up to the current schema (rake is Ruby’s equivalent of make). Or, you can set your database to a specific version of the schema by running rake migrate VERSION=X.

I wonder why the Rolling on Rails tutorial uses the database tools directly instead of ActiveRecord::Migrate? I’m thinking it wasn’t available when the tutorial was written. Whatever the reason, they really should update the tutorial to reflect the current state of Rails.