Hanselminutes is a weekly 30-minute podcast with Web developer and technologist Scott Hanselman and hosted by Carl Franklin. The following is a transcript from show number 29, entitled "Dynamic vs. Compiled Languages". You can listen online at www.hanselminutes.com.

Carl Franklin: Today we are doing a show on Disruptive Technologies. What do you mean by that exactly?

Scott Hanselman: Well, I think the disruptive technologies are the ones that come along every few years, and remind us that maybe the way we are doing things is a little more difficult than it needs to be, spending a little more time on things that aren't as important. I think that Ruby is a good example, particularly Ruby on Rails, of something that's come along and reminded us that development on the Web really doesn't need to be this complicated. Now, we spend a lot of time as .NET developers suffering in the ASP - early, early, early ASP.NET years - and things are coming along that are disrupting the way we think. People are moving away from complex Web applications to simpler patterns, and I think that Ruby and Ruby on Rails, and the success of those technologies, are worth exploring, but not just because it's something interesting that's not Microsoft - because most people who listen to this show are Microsofties, meaning in some way Microsoft and .NET pay our mortgages. But as .NET developers, what can we learn from Ruby and Ruby on Rails that we can apply to our lives?

Carl Franklin: Okay.

Scott Hanselman: This doesn't mean we should necessarily jump ship, but you are writing code - for example, the code that you used to manage Hanselminutes and the shows that you work on. It's all written in ASP.NET, right? You can have an administrative counsel, it's mostly using what we call CRUD - Create, Read, Update, Delete. I mean how much code did you use for the Hanselminutes admin?

Carl Franklin: Not a lot of code.

Scott Hanselman: Couple of thousand lines, couple hundred line? What do you think?

Carl Franklin: Oh! Couple hundred lines. Really, not a lot of code at all. Scott Hanselman: So, you use a lot of DataGrids, Data Binding, and things like that. Carl Franklin: Exactly.

Scott Hanselman: Did you write a lot of stored procedures?

Carl Franklin: Just a few, yeah.

Scott Hanselman: You are doing code generation?

Carl Franklin: No.

Scott Hanselman: So, there is an example a middle of the road .NET application that does some Creates, Reads, Updates and Deletes. You probably used a lot of wizards; you took advantage of as much as .NET as possible, and being that you are a trainer on this kind of stuff, you are not going to waste your time writing code that already exists.

Carl Franklin: Exactly. And for us, the only people who have to use it are in-house, maybe three, or four people, and usually only one at a time.

Scott Hanselman: Sure. So it doesn't need to necessarily be pretty, but it is very functional. I mean I've used it and I have done administration on the show, so its not that big of a deal, but it's a good example of the 80% example. It's the adding of information to a system, retrieving it, looking at it, sorting it, adding details. If you were going to do something like an upgrade to it, you would probably do it manually. You'd change the schema and then you would change the code and it would work just fine. Now, in the .NET world, when you go File/New/Web Application you get a blank page. Hello World is really the start when you go File/New/ASP.NET Application. In the Ruby on Rails world, you get a little bit more. Rails assumes that you are probably going to be talking to a database, and has a thing called Scaffolding. You basically say, "I want to scaffold out an application", and when you run scaffolding after installing Ruby on Rails, and maybe something like MySQL, you sit down and you basically go and say, rails (space) and then if I wanted an application called Foo, I'd say, rails (space) Foo, and I would get a whole application created for me, an empty Web application that would run under really any Web server. But typically, you can run it under either their built-in Web server, or under something like Apache. When you start it up, you basically get a Hello World page that says, "Congratulations, you are on Rails."

Carl Franklin: That reminds me of the Visual Basic Application Wizard.

Scott Hanselman: Right, it gives you a lot more I think than we are really used to getting. I think that...

Carl Franklin: But is it good? Is it good code? Is it typical wizard output, or is it something that is actually sustainable?

Scott Hanselman: Well, so here's the thing that's so interesting about Rails. They have a philosophy, which they call Convention over Configuration, we talked about this a little bit in a previous show as a philosophy that we like to apply to .NET code, but they have a lot of conventions, they say that stuff goes in the config folder, and we have a folder called "Test" and we have a folder called "App" you can't change those, right that's what the folder's name is. And this is the generalization, but in a .NET application you typically have some app -- config file where you could overwrite that; the name of that directory as this, or I want this file to be over there. They say, no, we are going to really focus on convention.

Carl Franklin: Standardize that stuff.

Scott Hanselman: Exactly, one less thing to worry about. Now, the code that gets generated, what's interesting about it is that there is so nothing there - it's incredibly simple. And what really makes Rails work is that; it understands how the software development process should work. For example, when you are dealing with a database, you typically have a development database, maybe a test one for running a unit test and a production one. With .NET there is really no built - in way that knows that this is the case, right? You typically will have different connections strings, right? Of a connection string that you would modify in a Web.config. In Rails they have a thing called database.yml file, it's basically like in .ini file, and within that you indicate different environments, you can say, "Well I am going to use the MySQL adapter during development to talk to this database on the local host with this name and password, but when I go to test I will run over here, and when I go to production I'll be using this different adapter." So, it actually knows that there are different modes, it's built that in. So, there is just an example where the way that development is done in software, it's built into the application itself, so the whole framework knows that this is how things happen.

Carl Franklin: Well there is plenty of that stuff in ASP.NET I would argue.

Scott Hanselman: Where in ASP.NET - other than saying debug=falls - do you indicate that now I am developing, now I am testing, now I am in production?

Carl Franklin: No, no, no that's not what I meant. I meant the kind of nice extra things such as the ability to just drag a table from data, and have an editable grid that's a nice high-level feature. The connection strings in the config file is a standardized way, the personalization, I mean there is a lot of high-level features in ASP.NET especially 2.0 that you could consider falling into that same camp of extra stuff.

Scott Hanselman: Okay, let me rephrase then. It's a good point. There are lots of things in ASP.NET that make development easy, but I don't think there are necessarily a whole lot of things that make the development process easy: migrations, for example. When you migrate from one version of an App to another version of an App, right?

Let's say I build an application, I make a table with people, and I have got a first name column, and a last name column. And I have got an object that I am going to be storing in that column. Within ASP.NET, I might create a class Person and he has first name, and a last name and then I might take that user and maybe I will use something like NHibernate. But not a lot of average-Joe developers use tools like that, that are Object Relational Mappers, and typically, they will write the Data Access Layer themselves, right? And they will take that object apart, and make sure that the object gets put into the table appropriately. So, then the application changes. I have to modify the schema, right? So, I'll go into SQL, modify the schema and then generate a SQL file that I have to remember to run on the production database to alter that table and add a new column, and then I have to go into my code and then tell it that there is new middle name field that's going to be added to our Person table, and then update my Data Access code to put that middle name in there. So, it's not hard, its just detail oriented. There is a lot of stuff there.

Within Rails there is this notion of Migrations, where you make a change and it keeps track of what is going to be required to get you from this state, like version 1.0, to this state version 1.1. So, all of this is being handled by a thing called ActiveRecord. And ActiveRecord would let you do things like, class project and then you could say, something like drives from ActiveRecord and a project belongs to a portfolio and a project has one Project Manager, a project has many milestones. It sounds like I am just reading English that's kind of what Ruby looks like when you are using ActiveRecord. You might have in the database the description of what a project looks like and you just write your class like that. I mean the class project might be five lines just exactly as I described it - you would literally write down "class project has one project manager". And those relationships then get managed by this ActiveRecord system. And it handles the persistence of that tune from the database because Ruby is such a dynamic language it handles it. So, if I wanted to migrate from one version of my application to another, I can automatically just generate the migration by describing what's changed, by making a change and saying, "All right I will go from this version, to that version." And it will handle it for you. It also keeps track of irreversible migrations when I move forward, but I can't back up. There is one of the other things that Rails allows you to do is say, "I want to roll back, I just made a goof. I added something to my database. I have changed my application, but it was a bad idea. I need to push the easy button and roll back everything automatically."