So, what’s new? Well…

• A nice Linq engine which parses IQueryable “stuff” into SQL (thanks to Matt Warren’s excellent work with the IQToolkit, which we stole mercilessly).
• A templating system which allows you to use ActiveRecord, good old Linq in Linq to SQL style, or whatever floats your boat.
• A SimpleRepository which is just about zero-drag and even builds your database for you
• A brand-new project site that will hopefully answer the question “is SubSonic dead”? Or probably not
• A new docs site that has permanently crushed my ability to type. It’s a wiki so if you feel like being helpful and like SubSonic and want to help… nudge… nudge

Should You Care?
That’s a tough question – so it’s the first I’ll address.

• If you like Linq and you’re not working with SQL Server and EF is a bit much for you – yes.
• If you like Linq and you are working with SQL Server… well nobody ever got fired for using Microsoft so “maybe”. Linq to SQL is awesome and it’s not dead .
• If you like a “low-friction” approach from a helper framework – then yes. You can’t get much lower-friction then SimpleRepository.
• If you like SubSonic to begin with, then yes. There’s still the same grooviness here.

Should You Be Afraid?
Hopefully not – I’ve really tried to test the tar out of this thing before letting it go (that’s why this took me so long). I’ve had a lot of help with this (many thanks to Eric, Paul, George Capnias, and Jim Zimmerman) and a lot folks reporting bugs (and a TON) of patches so hopefully it’s solid. That said – this is a major release and it’s also Open Source. You will need to be a bit flexible and hopefully you won’t mind helping us out. Which brings me to my final point…

Our Repo Has Moved. Yes, Again
All was going very well until 3 things happened:

1. I needed to put the 3.0 repo together with the 2.0 repo. It’s not a branch – it’s its own repo for sure. 2.2 is not a “tag” so… what to do? The only thing to do is to have the trunk split into versions which is ALL kinds of messy. I needed another repo for my project, and Google doesn’t let you do that.
2. I needed a really cool, collaborative system for our template sharing, which also should have its own repo.
3. Google SVN began to crumble and crash on me, causing me to drop/reload every week or so.

I’ve been using GitHub for a while and I absolutely LOVE it (more on that later) so with this release, we’ve moved to GitHub. I’ve kept the Google site open so we can work on existing issues, etc but I’ll be closing it in the coming month or so.

The Goods

• The new project site is here
• The new docs site is here
• The new Source site is here.

I’m going to go have a beer or five and then go blow stuff up for the 4th like a good Amrrrcan.

I think, in general, the .NET crowd overthinks and over-engineers just about everything

I said as much in my MIX presentation, where I basically challenged ASP.NET developers to “embrace their inner scripter” and stop building rockets. I have a fairly strong opinion on this – and I’ll save that for another time – but I think it’s high time to remind folks that there’s a lot more to an application then how you get your app gets it’s freak on with your database.

Good Morning!
I remember watching Fight Club for the very first time back in the thick of the very first DotCom bubble. I was feeling pretty ill that day so I stayed home and watched the DVD, and was pulled in pretty dramatically. One line still resonates with me:

You’re not your job. You’re not how much money you have in the bank. You’re not the car you drive. You’re not the contents of your wallet. You’re not your f******* khakis.

I feel the same way about building software: You’re Not Your Data Access.

When I watched that movie I had just bought a nice pair of $180 Kenneth Cole shoes to wear to a client’s VC meeting, to go with my groovy business-casual Cornflower Blue button down shirt. I clearly remember looking over at my closet – the feeling of fashion sobriety coming over me – wondering what I had turned into (if you knew me then you’d know I don’t like wearing that kind of stuff. I’m happy in a white t-shirt and shorts).

I had this same feeling when I popped my head out of the .NET community just 4 years ago (before I worked at Microsoft) to see what this “Rails thing” was all about. I remember the feeling well – and it was very, very sobering and inspiring at the same time. I remember creating an application in fairly short order with all the requisite pieces put where they needed to be put, with every tutorial urging me to “stop thinking – just build”.

Camaro Programming
The .NET platform is pretty dang powerful. It lets you build your own personal Tower of Babel if you so choose, and it can abstract away the very fabric of space-time if you let it. In short it’s a killer set of tools that any mechanically-inclined person would love to use. So naturally it can be very easily abused!

Consider my good friend Eric. I’ve written about Eric a few times before – but in summary he’s my token wrench-head friend that loves his engines and American cars. I lived with this guy for years and he rapidly filled up our garage with parts and *crap* from every car he’d ever owned. And he could dutifully tell you which part went to which car and what that part did – no matter if it was useless.

Eric built and maintained a hunk of junk 1968 Capri which we used to call “The Crappy”. This thing could drive – and I mean really drive – I think Eric pushed it to 180 mph once on a closed race course. It had that sound that all muscle cars make – the sound that makes your ribs shake and your inner 16 yr old say “coooooolll!”.

The problem was that no one ever wanted to drive in it. It smelled, it was ugly, and it absolutely sucked the gas down. Eric would steadfastly defend his Crappy because “it was the easiest car in the world to work on” and “could blow doors on any production car from any country”.

“Yah but when do you really need to go 180 miles an hour man?”

“When I race dammit”

I don’t need to draw the parallels here. I think you get it.

Let it Go Already
I want to be perfectly clear about what it is I’m saying here, and that is that it’s very, very easy for the geek inside us to whisper sweetly in our ears, saying “this Super Massive Paradigm Shifter will be the biggest application EVAR… don’t mess it up!”. I felt this very sensation when starting … well every app that I ever made.

I don’t like being wrong – no one does. So defensively I’ll be sure to include patterning where I can, making sure to separate out my projects whenever it … seems like I’ll crap for not separating out what I’m doing into another project.

I’ll use enums instead of boolean parameters.

Oh wait, no I won’t.

I’ll be sure to avoid Singletons

I’ll absolutely never use Stored Procedures, I mean seriously never, ever, ever (unless Rob Howard tells me to). Or maybe unless my boss tells me to. I’ll let Jeff decide.

I’ll always use Stored Procedures.

I won’t use NHibernate

I won’t use any ORM for that matter. Seriously – Never.

Well I might use both…

I won’t use Code-coverage to tell me anything.

I’ll be sure to use Code-coverage data to tell me everything.

I’ll make sure my method and variables are named properly on Fridays.

Reflection? Not a chance. Unless Rick says it’s OK.

I won’t use Extreme Programming (I’ll be sure to use Lean… whatever that is)

I’ll be sure not to have scrums.

I’ll also be sure not to multi-task.

I won’t use configuration either – hard-coding FTW!

I won’t use static methods

I won’t use extension methods

I’ll keep Native American stereotypes out of my code.

I’ll make sure that all my methods are public and never sealed or internal

I’ll check twice before I use any of these evil keywords.

I’ll also make double damn sure not to use regions in my code – ever.

I won’t use VB (who would?) and I’ll be sure to use C# with great care.

I won’t use Composite Keys in my database

And I’ll be very, very sure to keep away from Norway.

You wake up at Seatac, SFO, LAX. You wake up at O’Hare, Dallas-Fort Worth, BWI. Pacific, mountain, central. Lose an hour, gain an hour. This is your life, and it’s ending one minute at a time. You wake up at Air Harbor International. If you wake up at a different time, in a different place, could you wake up as a different person

Let.

It.

Go.

Summary
Simplicity is beautiful. Simple doesn’t mean hard-coding, it doesn’t mean cutting corners or being sloppy – it means building what you’ve been asked to build, not a rocket to Saturn and most of the time it’s a skateboard to the corner store.

Not every application needs to be stitched together from Codebetter posts and Twitter rants. Focus on what’s important – the experience, not what’s under the hood. You’ll change that quite a few times no matter what you think .

Elevator Summary
ActiveRecord is for people who want the biggest bang for their buck in terms of working with their data. It raises the database implementation right into the application as each object represents, literally, a row in the database.

Ruby on Rails uses the ActiveRecord pattern to great success – essentially telling people to “get over it”. Well, actually they say “F*** You” – but this is a family blog and it would be nice to keep this above board.

ActiveRecord is extremely intuitive and simple to use, but it does have its drawbacks – one of which is testability. But, as you’ll see, SubSonic has some magic here for you. Currently ActiveRecord works with SQL Server, MySQL, and SQLite.

Setting Up ActiveRecord
As with all things SubSonic 3.0 – ActiveRecord is implemented using a set of T4 Templates, which automatically generate the code you need within Visual Studio:

These templates are divided into 4 parts:

• SQLServer.ttinclude talks to SQLServer to get information about your tables
• Settings.ttinclude sets your connection string, database name, namespace, and other goodies (like the names of your classes, etc)
• Context.tt is an IQueryable layer and is akin to the DataContext in Linq to Sql
• ActiveRecord.tt is the class generator

You just set the connection string name in Settings.ttinclude, as well as the namespace, and you’re off to the races.

Working With ActiveRecord
This is designed to be brain-dead simple with no configuration or contexts to set, etc:

var product = Product.SingleOrDefault(x => x.ProductID == 1);

In the old days getting a record from ActiveRecord meant passing the key in through the constructor – but we’ve replaced that with a factory call so you can get a nice null back if the product doesn’t exist.

Each object is created with an IQueryable<T> reference to it’s foreign-key friends. These are two-way references, so you’ll get all objects that reference your main table.

You can grab a list like this:

var products = Product.Find(x => x.ProductID <= 10);

If you want your list paged, you can do that too:

var products = Product.GetPaged(1,10);
Assert.Equal(10, products.Count);
Assert.Equal(100, products.TotalCount);

Finally – if you want to work with LINQ you can using the factory method “All()”:

var products = from p in Product.All()
          join od in OrderDetail.All() on p.ProductID equals od.ProductID
          select p;

Assert.Equal(500, products.Count());

The factory methods are pretty complete and are pretty much sugar for a very Linq-y type of interaction:

The methods at the bottom there – “Setup()” and “ResetTestRepo()” are the goodness which I’ll go into now.

ActiveRecord Is Was Hard To Test

One of the things that people asked for when we rolled out SubSonic 2.0 was better testability. I remember asking Phil about this one day and said “isn’t about time we build this crap in?” and he agreed – but we couldn’t figure out the best way to do it. I thought I’d take a stab at it anyway – so here goes.

Let’s say you have a nice ASP.NET MVC application you’re working up, and you’re a being a Good Person and you’ve created a nice Test Project as well. Now you want to test your ProductController but you have plugged in SubSonic’s ActiveRecord and you don’t want to hit the database because it might make your test fail due to issues not under test (like bad data, for instance).

The good news is you can intercept the call to the database and effectively “Auto-Fake” the ActiveRecord repository, and how you do it is the funnest part. This is the App.Config in a sample Test Application:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <connectionStrings>
        <add name="Site" connectionString="Test"/>
    </connectionStrings>
</configuration>

If SubSonic sees that the the connectionString is “Test”, it will automatically work with an in-memory repository, not use a database. You can test this out by writing a test:

Product.Setup(100);
var products= Product.All().Count();
Assert.AreEqual(100,products);

By using the “Setup()” method, you’re filling the TestRepository that SubSonic uses under the covers – which is basically an IList<Product>. You can tell it how many items you want created or you can pass in your own list.

CRUD operations work as well:

Product.Setup(10);
Assert.AreEqual(10, Product.All().Count());

var newProduct = new Product();
newProduct.ProductID = 1000;
newProduct.Save();
Assert.AreEqual(11, Product.All().Count());

Album.Delete(x=>x.ProductID==1000);
Assert.AreEqual(10, Product.All().Count());

The interception will work 90% of the time for your application – however there are some circumstances where we can’t intercept the DB call – primarly because we don’t know, at the level, that you’re using ActiveRecord.

One of these places is our Linq implementation. It doesn’t know what’s calling it or why – so it won’t know it’s ActiveRecord and moreover won’t know if it’s under test – so we can’t intercept it. It should be a simple matter to test at the execution level of the connection string is “Test”, but the way we work with connections doesn’t allow for this – an Exception is thrown if a connection string can’t be parsed by the DbFactory.

Summary

One thing that I hope will become clear as we launch SubSonic 3.0 is that it’s really a core framework for you to build your DAL on using T4 templates. This is approach #2 to working with your data – tomorrow I’ll go into George Capnias’ excellent “Advanced Templates” which flex the Repository Pattern to present a very Linq to Sql-style experience.

I’ll also have a lot more to say about these on our forthcoming docs site (which I’m 70% of the way through).

It’s Rev 1, Be Gentle! I’ve put peddle to metal with this feature, using it as the backbone of my entire test suite – I think it’s pretty close to being “good to go”. That said – this is Open Source, if you find a bug I’d love your help with a patch. This is not Big Software and we won’t think of every scenario – but hopefully most of them.

Elevator Summary
The SimpleRepository is for people who don’t want a bunch of “fluff and object noise” in their application and who want their objects “to just be persisted somewhere” without having to design a DB to create an object model. It’s all about POCOs first – sort of an Object Database feel where your object is “just saved”.

This Repository is bare-knuckles, get it going quick, ZERO CONFIGURATION “just gimme my damn data and get out of my way and no don’t ask me which DB I’m using” kinda deal. I should have called it “BareKnuckleRepository”… hmmm.

It works with SQL 2005, 2008, MySQL, and SQLite. Oracle drives me crazy and if someone’s inclined the fix to put it in takes all of 30 minutes. Same with PostGres.

How It Works
The first thing is to create a simple object – I’ll use the ubiquitous Product here:

    public class Product {
        public int ProductID { get; set; }
        public Guid Sku { get; set; }
        public int CategoryID { get; set; }
        public string ProductName { get; set; }
        public decimal UnitPrice { get; set; }
        public bool Discontinued { get; set; }
    }

Next, you need to tell SubSonic about your database. You do this by using our ProviderFactory and passing in a connection string, or not:

var provider=ProviderFactory.GetProvider("SubSonicTest");

UPDATE: I just checked in a change so you don’t need to declare the Provider – it will do it for you. You can just pass in the connection string name, or nothing at all and we’ll try and guess what it is.

You can pass in a connection string name, the full connection string, or nothing at all and we’ll do our best to pull it from your config. This is basically a glorified wrapper to your database.

Then you create a SimpleRepository, passing in the provider you just created:

var repo=new SimpleRepository(provider,true);

The boolean argument there is the magic button – I’ll talk more about this in a second. This repository is very, very simple and has things like “Single, Find, Add, Update, Delete” etc. and can save bunches of items in a transaction.

For this example let’s use an empty DB I just created (the connection string above points to it):

Next, work up your Product object:

var newProduct=new Product();
newProduct.Sku=Guid.NewGuid();
newProduct.CategoryID=5;
newProduct.ProductName="Pretzel";
newProduct.UnitPrice=100;
newProduct.Discontinued=false;

And then save it using the Repo:

repo.Add<Product>(newProduct);

This is where the magic happens . By setting “true” in the SimpleRepository constructor, you’re telling it to run Migrations for you – automatically – creating your table if it’s not there.

If you refresh your DB…

Yes – if you change your model then your DB will be synchronized. No, you will not lose data (unless you’re using SQLite , which doesn’t support ALTER of anything). You can change names, types, lengths, add/remove columns etc – all without dropping the table.

Notice that the Primary Key was created for you, and the columns defaulted to nice lengths etc. It also made sure the data was added…

And yes, the Add() method returns the newly inserted key – for all providers.

SimpleRepo Convention

It’s not easy to make decisions as to how to store certain columns – and I had to do something I normally don’t like, and that is create a set of very, very small Attributes to help out.

• Primary Keys: If you call a column “ID” or “Key” or “[ClassName]ID” – no matter it’s type – that will be your Primary Key. If you have other things in mind you can use a primary key attribute (“SubSonicPrimaryKey”) and we’ll use that column.
• String length: there are two ways to tell SubSonic how to handle this – both using attributes. The first is “SubSonicStringLength(int length)” and the second is “SubSonicLongString” which sets to nvarchar(MAX) or LONGTEXT – depending on your provider.
• Nullability: The default is not null, but you can change this by making your propery a nullable type.
• Numeric Precision: the default is a Precision of 10 and a scale of 2 but you can change that with the “SubSonicNumericPrecision(int precision, int scale)” attribute.
• Ignoring a property: you can ignore generation of a property by using “SubSonicIgnore” attribute.

This is my test class:

    public class SubSonicTest {

        public Guid Key { get; set; }
        public int Thinger { get; set; }
        public string Name { get; set; }
        [SubSonic.SubSonicStringLength(500)]
        public string UserName { get; set; }
        public DateTime CreatedOn { get; set; }
        public decimal Price { get; set; }
        public double Discount { get; set; }

        [SubSonic.SubSonicNumericPrecision(10,3)]
        public float? Lat { get; set; }
        [SubSonic.SubSonicNumericPrecision(10, 3)]
        public float? Long { get; set; }

        public bool SomeFlag { get; set; }
        public bool? SomeNullableFlag { get; set; }
        [SubSonic.SubSonicLongString]
        public string LongText { get; set; }
        [SubSonic.SubSonicStringLength(800)]
        public string MediumText { get; set; }
        [SubSonic.SubSonicIgnore]
        public int IgnoreMe { get; set; }
    }

And if you have a look here at our source testing, you can see how this class is used in my unit tests (not an easy thing to do!).

You can also have a look here to see how the SimpleRepository works under test.

Summary Summary

I’m working on perf tweaks right now, and still adding things to the docs so it will be a bit yet until I release this. If you want to have at our source – it’s here.

I’m not going to release 3.0 until I feel that people can get up and going – and there is a TON of stuff going on with 3.0 that people should know about. I’ll have more on this in the coming weeks.

There are a lot of reasons why projects don’t “pop” – but in some ways I think people can tell if they are “gazing wantonly in the pond’s reflection” by constantly asking a set of simple questions:

• What are we doing?
• Why are we doing it?
• What do we hope to get out of it?

A lot of people would say “sure – that’s what ya call a Mission Statement Rob!” and in some ways, I spose it is. But the next part is the hardest:

Does it motivate you?

The Hard Truth
In every human endeavor the 80/20 rule (aka Pareto principle) cruelly applies – which is effort/payoff are inversely related. This principle is at the core of the just about any time/management book/philosophy – and these things usually boil down to constantly shifting your focus to “what’s important” (aka the 20%).

It seems the 80/20 thing is built in to the fabric of the universe, along with some other groovy numbers. Most large software companies have come to realize this – including Microsoft:

"One really exciting thing we learned is how … a relatively small proportion [of bugs] causes most of the errors," Ballmer wrote in his three-page memo. "About 20 percent of the bugs causes 80 percent of all errors, and–this is stunning to me–1 percent of bugs caused half of all errors."

If we apply logic here then the opposite of this statement must be true as well:

80 percent of the bug-free functionality is produced by 20% of the code.

If that’s true – we’re writing way too much crappy code. Let me reword that – 80% of the code we write does 20% of the work and contains the bulk of the bugs (my math skills got lost there). Which side of the 80/20 code pool are you swimming in?

Sherman, Set the Wayback Machine
It’s 2000 and I’ve just ordered a tin of Pringles and The Fragile (Right and Left) from Kozmo. It’s 11pm and I should be at home, but I’m hammering away on my client’s app, trying to get a demo ready for Yet Another VC Who Wants To See Stuff Spin. I’m cranky, tired, and my wife is getting tired of this constant circus of late nights.

The phone rings as the speakers are blaring in our Live/Work Loft/Office on 2nd and Brannan and I’m listening to Trent growl his way through “The Wretched” and I see the area code – it’s New York. My client. Crap.

After 10 minutes of telling him everything’s on pace, he recaps what he wants to see. Amazing – he added 4 new requirements! How very … like him.

I ask him the question:

“What are we doing again? I mean what’s your goal here anyway once all of these demos are done and you’re really rich.”

I hear gasps on the other end of the phone, some choice swear words that involve an ice-pick and my retina, and then *click*.

The phone rings 5 minutes later and it’s The Client. “Do you mind telling me just what the **** you’re asking me these questions for you ****in moron?”. I’m used to “the East Coast” thing by now and I reassure him I know his requirements – I understand the specs and priorities – we’ve been through it a ton. I know about the demo.

I want to know about the day after the demo.

His answer was simple: “We’ll be millionaires. Who gives a **** what else – we’ll be the next tech IPO and you can buy your wife a maserati so **** off and build my ******* app!” (the East Coast thing gets annoying at times – but you get used to it. Don’t get me wrong – I like the other side of the country and all, but they can get pretty spun up over there).

We got the funding – a lot of it. And the company still managed to fail – I think it’s when investors figured out my client was full of crap. I should have figured it out too – but back then everyone was involved in an IPO or buyout. It was a “Craigslist Party” of geeks and power money and you just didn’t ask questions. Or so I thought.

What’s Your Answer?
Twice I’ve worked on a winning application – and it feels great. And by “winning” I mean the client and their clients were stoked, and it literally made people cry. One of my very first applications – an info portal for Ameritech (now PacBell) was one such application. It was so very, very simple that it had to work – it was a classic ASP app (I wrote this in 1998) that used IndexServer to crawl over 12,200 documents scraped from their mainframe.

Their existing app was a terminal-based app and it was all paging and CTRL- shortcuts the user had to memorize. I made a web interface (we called it the “Yahoo UI”) that worked on fuzzy search and BAM – scraped 30 seconds off the average “satisfaction timer”. This meant the call center reps could answer people 30 seconds faster than before without the carpal-tunnel and by using the “new web thing”. I’m not kidding you – one of our User Acceptance participants (an actual rep) started to cry.

If you asked me or any member of that team what we were doing we would have said the following (with minor variations):

• We’re building a web app to reduce the time to answer for call centers
• We’re doing it because our existing app sucks and it’s too hard to learn. Turnover is killing us.
• We hope to have happier call center folks and happier customers

These answers are all kinds of win because they’re grounded in something real: making a job easier/better/faster. They don’t involve greed and aren’t out to change the way the Earth spins – simple and direct and dare I say truthful.

Smelly Answers
I’ve asked these questions various times over the years and aside from my client from hell above, I’ve received some real winners:

• “We’re going to be the Premier [WHATEVER] and direct all buyers of [X] to use our service and we’ll make wads of cash”
• “We’re going to Change the Game with this app, and in doing so make wads of cash”
• “We’re going to dominate the [BLAH BLAH] space – we’ll actually become the internet. We’ll make wads of cash”
• “Right now there’s a massive void out there and we’re going to fill it. We don’t know how we’re going to make money – but we’ll get there soon enough”
• “I don’t know really – I’ve been told to build this thing so I called you. I need a beer.”

People and technology are funny and scary at the same time. Sort of like clowns. When I tell people what I do they get a really weird look in their eye (you know the look I mean) and sometimes I don’t know if I’ll be “fixing their internet” or hearing their great new idea to make tons of money. I, evidently, am a bit like Willy Wonka:

“We are the music makers, and we are the dreamers of dreams”

Mr. Wonka also offered a followup – which I hold to very tightly:

“You should never doubt what no one is sure about”

If we agree, by now, that this 80/20 thing has some merit, then it stands to reason that there’s an 80% chance you’re working on a project with a smelly set of directives. You ended up here by the various laws of the universe that sprinkle geeks across projects like salt and pepper – but you don’t have to be the 80% tripe!

You can change this: you can jump the 20% fence. You just have to help your team face the problem plaguing them – which is usually a weird direction that has to do with wads of cash, changing the game, or shifting some paradigm.

Get their heads back in the game and make sure you’re kicking ass for humanity – and you can figure this out pretty quickly by asking some simple questions and listening for:

1. Delusions of grandeur
2. “Wads of cash”
3. “I don’t know yet” spoken 2 or more times
4. The solution isn’t a win/win (you, client, end-user)
5. Frustration at the question

If you hear these answers or feel like you’re drifting – change things for the better by asking if you can open up conversations about the endgame – about the value for the end user.

If you don’t get concrete answers point to YouTube: a really dead-simple app that makes people really happy. Just like a puppy or a kitten – without the poop. Or Twitter – one of the silliest, most relevant applications ever made (that has yet to make a dime… but anyway).

You can change things – you really can. As long as your team is willing to listen and engage and if they’re not, well maybe it’s time to look for the golden 20% out there.

The Start of BDD
It all started – or so I’ve read – with a guy named Dan North:

I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.

The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.

I felt this exact way when learning up on TDD:

1. where do I start?
2. what do I do next?
3. how do I know when I get there?

Things like that. I still don’t know those answers, but I feel like BDD has helped me see some very interesting ways to address these issues. Moreover, it will help me get along with my PM better – maybe .

The Usual Caveats 
No – I’m not an expert. Please don’t take any of what you’re about to say as guidance. Do take it as  queue to find out more. Do ask a lot of questions and Do challenge yourself to see what some people love to use.

Download it here

Double-click for full screen

As I’ve been going around the world I’ve been meeting with many people who’ve built their companies on non-Microsoft stuff. Some of whom have companies worth billions of dollars now. Some of whom you’ve never heard about unless you read TechCrunch. Here’s 12 reasons Web 2.0 entrepreneurs like Ross tell me that they aren’t using Microsoft’s stuff:

1) Startup costs. Linux is free. Ruby on Rails is free. MySQL is free.
2) Performance per dollar. They perceive that a Linux server running Apache has more performance than IIS running .NET.
3) Finding tech staff is easier. There are a whole new raft of young, highly skilled people willing to work long hours at startups who can build sites using Ruby on Rails.
4) Perception of scalability. The geeks who run these new businesses perceive that they can scale up their data centers with Linux and not with Windows (the old “Google runs on Linux” argument).
5) That Microsoft doesn’t care about small businesses. After all, Microsoft is an evil borg, but Ruby on Rails comes from a single guy: David Heinemeier Hansson. He has a blog and answers questions fast.
6) That open source makes it easier to fix problems and/or build custom solutions. A variant of the old “Google or Amazon couldn’t be built on Windows” argument.
7) On clients, they want to choose the highest-reach platforms. That doesn’t mean a Windows app. Or even an app that runs only in IE. It must run on every variant of Linux and Macintosh too.
They don’t want to take shit from their friends (or, even, their Venture Capitalist). Most of this is just pure cost-control. I can hear the conversation now: “OK, you wanna go with Windows as your platform, but is the extra feature worth the licensing fees for Windows?”
9) No lockin. These new businesses don’t want to be locked into a specific vendor’s problems, er products. Why? Because that way they can’t shop for the best price among tools (or move to something else if the architecture changes).
10) More security. The new businesses perceive Linux, Apache, Firefox, and other open source stuff to have higher security than stuff built on Windows.
11) More agility. I’ve had entrepreneurs tell me they need to be able to buy a server and have it totally up and running in less than 30 minutes and that they say that Linux is better at that.
12) The working set is smaller. Because Linux can be stripped down, the entrepreneurs are telling me that they can make their server-side stuff run faster and with less memory usage.

I’d love to know if these opinions have softened at all – or if they’ve been further reinforced – especially given the release of ASP.NET MVC (and it’s subsequent listing on Codeplex under Ms-PL). I’m going to guess that they’re roughly the same: people will believe what they’re going to believe and for some reason, when it comes to Microsoft, changing people’s minds is really hard.

One thing that’s particularly interesting to me is that Microsoft, at least some divisions, are actively changing their “thinking” if you will to a more open posture. The Ms-PL of ASP.NET MVC (mentioned above), some of the work that Developer Division is doing with the Mono team, and the source availability of the entire .NET stack (yes, I know it’s still not open) are evidence of a shift in thinking.

Great! But now what?

Clearly openness and transparency is super groovy – but then what? I’m a huge champion of the open and transparent thing and I’ve been able to do some great stuff in the open with the MVC Storefront and I’ve taken you along with me. I like to think that I was brought to Microsoft to help keep “rolling the bubble” towards more openness – but I have no way of knowing where the rowers are a-rowing; so I just keep plugging along and thankfully they’re letting me .

The Storefront has been a great learning tool, and a lot of people have thanked me for it (and you’re all very welcome! I learned a ton too). But now what?

It was always my intent to pop what I did up on Codeplex and share it with people with the idea that if it had legs – well hooray! So far I have every reason to think it will become quite the open, flexible, “new thinking” type of application that people can learn from, use, extend, and so on. It fires me up and makes me pretty happy because I really like Open Source and what it can do.

But then again – I’m a Microsoft employee and this is a Microsoft project, after all. They’ve given me tremendous latitude to do with it what I will so people can learn core concepts surrounding ASP.NET MVC. That part is sort of done, and now we have Kona – an app that I’m hoping will be somewhat influential with respect to Open Source apps built on ASP.NET. Nice idea – but then there’s the fact that I work on the ASP.NET team.

What does it mean to you that I’m an MS Employee, on the ASP.NET team, building an OSI-licensed ecommerce app? Do you think Microsoft should do more things like this in a more formal way? Or should it stay out of the picture and let others run with this kind of thing?

There are so many questions that I have in my head – and I’m very, very interested to know what you think here: What do you think Microsoft should do with respect to Open Source and .NET?

“I can’t believe you’re using your blog to pimp you’re book! You’re such a … [not a nice word]”.

I couldn’t agree more, and overall the book is a mess and you shouldn’t buy it. If you do buy it, it will give you bad dreams (I know how to write dream trojans) and your brain could boil, increasing the size of your forehead until it eclipses the sun. Or maybe you’ll like it – who the hell knows – I gave up trying to figure this whole thing out a while ago.

Why This Book Sucks
I’ll be straight with you – we tried to avoid sounding like every other book out there – so it might not work for you. Every chapter I wrote I actually stressed over – trying to make sure that I told a story and made it entertaining. I know I know – swimming upstream… but a guy can dream.

I hate boring books written by guys with huge foreheads and silly looks on their faces – and I have a lot of them (and now I am one of them!). One of the things I said to the editor when we first talked was “dude this book has to be fun and entertaining otherwise it’s a waste. Palermo’s already writing the boring one – we have to write the good one”.

OK I didn’t really say that last part – I’d probably get in trouble if Jeffrey thought I said that – so let’s keep that between us KTHX!

I wrote Chapter 9, the security chapter. Well to be precise – I rewrote it about 5 times. Each time I kept thinking “this is boring, who cares!” and that’s not a good thing – especially with regards to security. So I decided to tell stories along the way – stories about Kevin Mitnick, Kevin Poulsen, and The Ghettohackers pwning the competition at the annual DEF CON in Vegas. Stories about the Srizbi and Storm Worms (which I also wrote about on my blog) and basically tried to take a walk on the wrong side of the digital universe – taking you with me – showing you what kinds of bad guys are out there.

Why This Book Really Sucks
Scott H, Phil and I collaborated on a few of the chapters as well – and we each pushed each other to “speak a bit more plainly”. It’s easy to lapse into author-speak, losing your voice. This was a pretty fun process, and I have to say Scott’s an exceptional writer as well as a speaker. He wrote many of the early chapters in the book, and sums up the WebForms vs. MVC thing pretty well.

He tells it straight, as do Phil and I – so if you like your books milky and Wonder-bread bland, well it’s probably not for you.

What You Get With This Book (Which isn’t Much)
People have been asking “what’s in this book anyway – why should I care?”. So here you go – I’ll tell you specifically:

• 0 to 60 with ScottGu and Nerddinner. Scott writes clean, amazing prose and cuts right to it, showing you how we started Nerddinner.com
• Perspective – Scott H. covers what MVC is in terms of a pattern and discusses the platforms that use it on the web today. He then dives in to “what ASP.NET MVC means” and exhaustively shows, in just about every way, the conceptual difference between WebForms and MVC
• Nuts and Bolts – Phil. The PM of the project himself covers Routes, Controllers, Views, and ActionFilters going into deep detail about each.
• “Higher Concept” stuff – Phil and myself. Phil puts on the rubber gloves and covers every possible aspect of TDD – how to work it with MVC, his secrets, and some interesting strategies you can use. I dive into Testable Design Patterns – the “OK fine so how do I put this altogether” kind of thing where I cover patterns and things I’ve learned from the Storefront. I also do a lengthy chapter on AJAX and show you some interesting tricks.

When You’re Done Reading It…
Burn it. The ideas contained in this book are dangerous and might make you do weird things – things that could make people stare at you and say “why is he doing weird things”. Our hope is that you can dive into any chapter, and we don’t spend too much time on the basics but instead treat you like adults and try to get right to the good stuff – having a good time on the way.

If you’re a sucker and have bought it already – well I hope it helps you somehow. If not, wel

I felt the need to speak up a bit so I left a comment on DotNetKicks:

Please don’t use this "scoring" chart with respect to MVC and WebForms. Honestly – you can’t "score" something like "should I care about Testability" (which rates an against "do I need to use this Server Control" (which scores a 10).  There are so many problems with approaches like this – really the only answer is to *try it* and see if it works for you or your org.

Today I read a post on StackOverflow which was pretty contentious wherein the author says:

I’ve been fiddling with ASP.NET MVC since the CTP, and I like a lot of things they did, but there are things I just don’t get…

<snipped ugly viewcode>

Am I doing something wrong? Because I spent many dark days in classic ASP, and this tag soup reminds me strongly of it.

Everyone preaches how you can do cleaner HTML. Guess, what? 1% of all people look at the outputted HTML. To me, I don’t care if Webforms messes up my indentation in the rendered HTML, as long as I have code that is easy to maintain…This is not!

I have definite opinions on this, and today you get to read them. Note that I pushed Scott Hanselman really hard when we wrote our book (which I think is shipping today!) to come out AND SAY SOMETHING (Chapter 3 – a discussion on MVC and WebForms – and he did an amazingly good job). It’s too easy to think “hey – I’m Microsoft – I need to stay balanced here so I don’t offend” and there’s merit to that.

I, on the other hand, think we should also be able to speak our minds. In that light, I present to you my latest effort at getting in trouble: why you need to read this post, get up, and learn what MVC is all about (if you don’t already know).

The Great Lie
WebForms is a lie. It’s abstraction wrapped in deception covered in lie sauce presented on a plate full of diversion and sleight of hand. Nothing you do with Webforms has anything to do with the web – you let it do the work for you.

This, friends, is a big deal (at least to me): You’re working in a lie. The web is *not* stateful and works with this stuff called HTML sent across wires using another thing called HTTP – you need to know this, love this, and feel it at the bone level. I understand this sentence right here is probably making some of you squirm – please continue squirming (I’ll wait).

If you’re still squirming, then perhaps web development isn’t for you (meant very respectfully and kindly – not being snarky). I say this because you shouldn’t work in a sausage factory if you’re allergic to pork, beef, and ground up animal parts. Nor should you put a wig on your cat and hope that it can sing like Susan Boyle.

These are self-deceptions put in place to make you feel better about something lacking, and it’s usually not healthy. If you’re thinking that you don’t need to know HTTP/HTML to work on the web… you’re doing it again! Please see 2 sentences ago.

If you’re still thinking it – your cat needs a new wig.

MVC Is Elite-test?
I’m sure that WebForms people are probably thinking I’m being a bit of a sh** right now – and I’d like to speak to that. The title of the post here is “You Should Learn MVC” – not that you have to use it (although I wish you would – it’s tons of fun!). That’s all I’m asking – for you to learn it; I’m not telling you that you’re a bad person if you don’t use it (only that you put wigs on your cat).

MVC Is Full of Tag Soup?
Once again, I’ll say this: Spaghetti is as Spaghetti does. I don’t like to see a bunch of if’s and fors on my View the same as any other geek. This, friends, is up to you! Not the platform! Please read this: markup is up to you, as with everything else in MVC. Yes it’s not drag and drop – but nothing ever is in life! It’s new, it’s different – it’s not 1999 if only because we have the power of C# now – not VBScript.

I’m not afraid of HTML – and you shouldn’t be either. Respect it when putting code to page and use DRY as your guide. We can make it through this, together. You can bring your cat, too.

7 Reasons To Stop Calling Me A Jerk
Hopefully you’re still here, and hopefully you’re thinking “enough of the blather already – gimme something to sink my teeth into”. So here goes:

1 – Testability. No – not talking about the TDD variety, just testing in general. If you’re “not a testing person” that’s OK – the rest of the computer science world has embraced the idea that “testing what we build is a pretty good idea”. You don’t really want your clients to catch that silly “InvalidCastException” do ya? There’s LOTS of reasons to want to test – again not TDD – just good old Unit Testing! It’s easy peasy with MVC and this alone should pull you in to at least check it out – along with why testing can save you time and money.

2 – Control over HTML. I’m sure you’ve heard this before – mangled ID’s, non-validating HTML, etc. Why is this important? Because you might want to use client-side programming for something! I won’t bang this gong for too long – but it’s a lot more than “making ViewSource look pretty” – you’re communicating with super-finicky creatures (browsers) that love to argue – being able to smith the markup experience makes you a more valuable developer!

3 – Extensibility. Literally every part of MVC Is pluggable – and in the last 3 apps I wrote (Storefront, Nerddinner, and SubSonic’s MVC Starter) I used my own ViewEngine to save some time and work. I’ve spun up my own ControllerFactory so I can use IoC (which is awesome fun!) Understanding this is the keys to the kingdom for any developer! Have you ever been freaked out because you needed to use Page_PreRender to get something to load into the ControlTree properly so it will show when you need it to? MVC does not lock you into anything – you’re free to do what you want to.

4 – It Makes You Think… This is the one thing I never liked about WebForms – I never felt like I was thinking – just solving. May seem like splitting hairs, but not to me. I’d get a bit of inspiration and then try to figure out “hmmm – how can I make the form show it this way”. MVC is the opposite – the control is in your hands and you get to be free with it. You get to use your noggin! Wow!

5 – …Differently: Javascript Doesn’t Suck. jQuery, Dojo, extJS – whatever. These frameworks make client development so easy it’s actually fun. Phil and I have recently geeked out extensively using jQuery (he more than me) and I distinctly had the feeling that I’ve been missing something. Something that other platforms have had for years – the ability to make a web experience fun and magical (for a user) through client programming. It makes you think completely differently once you “get it” – and soon your server code is being drastically reduced in favor of light, clean client code (thanks to these frameworks) that work up an awesome experience. Cats love jQuery too.

It may seem weird to say it, but developers like to learn a language every few years – make javascript the one you learn this year. You might think you know it, but you probably don’t know it as well as something like C#/VB. Try to – it will change your development entirely from scheming out an interaction to how much code you write.

6 – Learning New Concepts. You’ve seen them everywhere, and seen us fighting about them. We probably shouldn’t argue so much but in a way, this is part of the learning process! Either way – take it upon yourself to learn some things. WebForms is a comfy blanket that can lull you to sleep over time. This has happened to a lot of us (myself included). We’re only now catching up with frameworks that have been creating rocking, compelling sites over the last few years – jog your brain! Wake yourself up and get to know the details that make compelling sites groovy! Learn the things that can help you write more nimble code – if only so you can argue from a point of knowledge!

7 – It’s Fun. This, to me, is the biggest reason. I find MVC fun because I can do what I want, when I want, how I want. I’m free to build an experience that I feel will sell my design, and I’m not hindered by a A Big Lie and a freaky cat with a wig on.

Summary
Bottom line: I’m having fun web programming again and I think that’s pretty motivating, at least for me and my cats. Yet Another Comparison, sure, but hopefully a bit more direct. You have absolutely no reason at all to not learn MVC – but I will concede there may be a reason or two for you to stick with WebForms.

I know many people might think I’m speaking for the rest of Microsoft – hardly. I’m biased and, more importantly, I actually still have my very own brain which forms its own thoughts! I love MVC and I think you will too – just please, please try it before you form an opinion.