Twin Cities Code Camp

Ask a Rails developer how she would tackle a simple business problem. She'll tell you. Put your database scripts here, your functional tests here, html markup here, controller logic here, your unit tests here, and put your model here. To validate your model, add a few lines here. And because of some simple and reasonable naming conventions, it all plays well together. Ask a .Net developer how to tackle the same business problem. She'll start thinking. Well, the UI seems pretty obvious, but from there it gets difficult. You might start by doing the "simplest thing that can possibly work," and drag a dataset onto your screen. But where do you put your database scripts? And how do you test your business logic? Or your UI controller logic? And how do you name things? If this developer has been around for a while, she probably has a few favorite patterns in her toolbox. Maybe she's even got some of the pieces covered with reusable code libraries. But she doesn't have a solid, well-tested, common framework for completing even a simple business scenario. She should! In this presentation, we'll describe how Rails removes many of the common barriers to getting real work done – and discuss how the .Net community might do the same.