Finally decided to do a dev tools list

One of the most important parts of being a craftsman is your selection of tools, it doesn’t matter if you are a carpenter, a mason, cabinet maker, or even a software developer, your tools allow you to get the work done.   What tools you use really depends on your style and technique and may very greatly depending on the person.  This is a simple list of IDEs, editors, libraries, etc. that I like and work for me, some are pay for, most are not.  This isn't a complete list of the tools I use but it's a good solid overview of what I use on a day to day basis, take a look and see what you like, or don’t.

IDEs

• Visual Studio 2010 – The default editor for doing .NET development, it has it’s share of problems but for the most part it a very sold IDE.
• MonoDevelop – This is where .NET started for me 8 years ago, not a lot of frills, but for a fully functional cross platform IDE for .NET the price is right at free, unless you want to do Android or IOS, then you need to buy monoDroid or monoTouch.
• NetBeans – My go to java and PHP IDE, with good intellisense and built in refactoring tools. 

Visual Studio Plugins

• Resharper – The most valuable IDE plugin I have ever used, providing nUnit support, refactoring, add reference, and the list keeps going.  I honestly have a hard time using Visual Studio with out it.
• DotCover – An important part of test driven development is code coverage, and DotCover is my coverage tool of choice.  It integrates with Resharper’s test runner to provide on request code coverage in the IDE.

Source Control

• AnkhSVN – Provides SVN support for Visual Studio, so far this is the best free SVN plugin I have found for Visual Studio
• Visual SVN server – A simple and easy SVN server that just works, it may not have a lot of bells and whistles but it’s easy to install and manage users.

Text Editors

• Notepad++ – One of the first things I do on any new windows system is install Notepad++, it integrates with Windows explorer making it simple to edit any text file with out having to deal with what the default app is for the ext. with a huge list of plugins for everything from XML to powershell it is the Swiss Army Knife of text editors.

SQL Tools

• Toad For SQL Server – This is a new item on my tools list, I just started using it this week, but I really like it.  The community version has some really nice intellisense, and the way the UI works is just clean.  I’m really interested in seeing a head to head comparison between Redgate’s SQL Tool belt and Toad Development Suite for SqlServer, the features look about the same, but at around $1,300 vs. $2,000 toad is a lot cheaper.
• FluentMigriator – A .NET version of the Ruby Migrations tool.  With a fairly simple syntax and helpers it makes scripting DB changes easy, to read more check out this blog post I did a little while ago, Using Fluentmigrator with nant.

Unit Testing

• NUnit – The work horse of the .NET unit testing world.  It’s a solid testing framework with some of the best tool support out there, with the exception if Visual Studio, but Resharper fixes that.
• Moq – The Simplest mocking framework for .NET.  With a clean fluent syntax that provides ease of use and versatility.   

Build And CI Server

• Team City – By far the easiest to get set up and start running with.  With built in support for most of the tools I use and has DotCover built in, it provides a solid solution out of the box with a very polished UX. 
• Jenkins – A fork of the Hudson project, Jenkins is a solid if less then polished build and CI server solution, but what it lacks in polish it makes up in versatility and flexibility, with a huge selection of plugins for integrating into just about development environment and deploying to just about any other system out there.

Test Driven Development for the management point of view

When I have given presentations on TDD, one of the biggest questions I get is “How do I sell this to my boss?”, and it’s a very valid question, you are basically asking your boss to let you write 2-3x as much code to make sure the code you wrote is correct, that’s a tough sell all on its own.  Software can never be done soon enough, most projects are already behind from the start, and now you want to take more time to write more code? 

Time is Money

There is a cost to Test Driven Development (TDD), you are doing more work, writing tests takes time, maintaining tests takes time, and running tests takes time.  With time equaling money the question is “what are you buying?”, the simple answer is security, and long term cost reduction.

Ever wonder what it would be like to have a car without a check engine light?  For the most part it’s something most of us never look at.  When it turns on we take it to the shop and the mechanic fixes whatever is wrong.  Without the check engine light to tell you something is wrong, what could have been a small repair is now an engine rebuild.  Having tests provides you with the same thing, it lets you know there is a problem before it becomes a larger problem, this could be inconsistent application behavior, data corruption, or the application crashing.

Real world example

At a former employer we were migrating to a new production database for our flagship application, the database it’s self was a very complex system, lots of tables, triggers, stored procedures, etc.   The DBA migrated the schema to the new server, got a snapshot of the data and then ran our integration tests and had failures everywhere, invalid permissions, missing columns, etc.  Even using the failed tests as a road map to took the DBAs 1 ½ days to fix all of the problems.  I can’t even guess how long it would have taken to fix if we would have just done to production, on top of that the company’s main product would have been down, not only affecting us, but also all of our customers that depended on our product to run their businesses.    

We Could have just blamed the DBA for not getting everything right the first time, but at the same time, how much time was he given to do it, would it have been cost effective to spend more time for this one time, verses spending the time writing tests that can test it over and over again.

Spending a little to save a lot

Software bugs have costs: they cost to find, they cost to track, they cost to fix, they cost to verify when fixed, and they cost to push out the fix. 

• Cheap - A developer finds a bug when it was written, he/she fixes it, very little cost
• More Expensive - QA finds the bug, the tester needs to make sure it’s an actual bug, retest to verify how to reproduce it, then records it a bug report, sends the bug report to the developer, the developer fixes the bug, send the fix back to QA, it’s retested, then the bug report is closed.
•  Very Expensive – User finds bug, contacts customer service, customer service sends bug to QA, QA verifies the bug, creates a bug report, developer fixes bug, sends the fix to QA, QA verify bug is fixed, bug fix is redeployed to production.

How much the bug costs depends on how soon it’s discovered, the sooner it’s discovered, the less people touch it and the less it costs.  By writing tests developers are far more likely to find bugs sooner also nothing is more frustrating than having bugs reappear, manually retesting existing functionality takes time, and increases QA cost, also reduces the time QA has to find new bugs, and edge case bugs.  TDD inherently provides regression testing and can greatly reduce your QA time.  

Real world example

At one time I worked as a QA Engineer at a major printer company, a little over half my time was spent not only testing new functionality, but existing functionality as well, the rest of my time was spent sending bug reports to the developers, having the developers asking for clarification, verifying the bug was fixed, etc.    As much as it cost for me to test a printer, the cost of having a driver or even worse a firmware bug get released to the customer where astronomical.  By reducing the time I had to spend retesting and verifying bugs, I could spend more time looking for edge case bugs.

Something else to think about is unlike web development where you are only pushing code to your servers, having hardware in the hands of consumers with a bug requires the added cost of service representatives, service techs, etc.   

Reducing Costs by building on a well build foundation

TDD by it nature encourages good development practices, by breaking up chunks of code into more testable sections, you are turning them into more manageable pieces; this reduces the amount of time and effort required to update and maintain your application and greatly reducing the need for the dreaded rewrite. 

  

Ask any construction contractor what makes the biggest difference on a building remodel, and they are probably going to tell you “How well the original building was built”.  If the foundation isn't level or the walls aren't straight, it’s going to make his job that much harder having to compensate for the existing structure.  The same thing applies to software development, the less old code that needs to change to add new features, the less it costs to add new feature with the added bonus of the tests telling you where your changes affect the rest of the application.

Real world example

I worked on a project that was needed to replace how users authenticated; the user still entered a user name and password, but how they were verified need to be updated for security reasons.  By having the application broken up, all that needed to be changed is adding the new authentication code and changing one line in the existing code to implement the new functionality.

Using TDD isn't required to use these best practices, but trying to do TDD without using them is painful to next to impossible.

More Ajax with MVC – Using Partial Views with Ajax

One the the really nice features in asp.net mvc is the ability to use partial views, not only for breaking up pages and reusing content but also for doing Ajax calls.  In Easy Ajax with ASP.NET MVC and jQuery I showed you how to do a basic Ajax call and display the data returned, now I’m going to show you something a little more useful, actually retuning content to display on the page.
First we take this partial view

   1: @using SampleApplication.Models

   2: @model PartialModel

   3:  

   4: <div>

   5:     @Model.Text

   6: </div>

   7: <input type="button" value="click me" onclick="UpdateView();return false;"/>

Then we add it to the main view like this

   1: <div id="UpdateableContent">

   2:     @{ Html.RenderPartial("Partial",new PartialModel{Text = "Before Clicked"}); }

   3: </div>

Next we need to have a Action to call that returns the rendered view with updates

   1: public ActionResult UpdatePartial()

   2: {

   3:     var model = new PartialModel() {Text = "was updated"};

   4:     return View("Partial", model);

   5: }

In this case we update the model and return the specified partial view with the updated model.

Last we have the Javascript that makes the Ajax call

   1: function UpdateView() {

   2:     var model = { };

   3:     $.post("/home/UpdatePartial",

   4:         model,

   5:         function (data) {

   6:             $("#UpdateableContent").html(data);

   7:         });

   8: }

it’s fairly simple and a lot like what we did in the Easy Ajax post, the major difference is we take the returned rendered partial view and replace the existing rendering of the partial view using JQuery’s .html(),  this replaces the existing content with the passed in content.  This is a very simple and effective way to manipulate your pages.

As always here is the source code for a sample project using it

Using FluentMigrator with nAnt

On a project I was working on a while ago, we all had local copies of the DB in versioned .sql files, and then every time we did an update we would run the sql in the DB files and hope it build the DB.
More often then not it would blow up and so I would spend the first 1/2 hour every time I worked on the project getting things to work again. Well no more! 
FluentMigrator is based on Ruby Migrations, with a fairly simple syntax. The db classes have the attribute [Migration()] that specifies the version, and inherit from the Migration class, and override the two methods Up and Down.

   1: [Migration(20110624232410)]

   2: public class AddUserTables : Migration

   3: {

   4:     public override void Up()

   5:     {

   6:         Create.Table("Users")

   7:             .WithColumn("Id").AsInt32().Identity().NotNullable()

   8:             .WithColumn("Name").AsString().NotNullable()

   9:             .WithColumn("Password").AsAnsiString().NotNullable();

  10:     }

  11:  

  12:     public override void Down()

  13:     {

  14:         Delete.Table("Users");

  15:     }

  16: }

Migrating Up and Down

The Reason for the Up and Down methods is very simple; if the version your migrating to is higher then the version of this class it executes the code in the Up method and if the version is lower then the code in the Down method executes.  Basically whatever you do in the Up is undone in the Down.

Setting The Version Number

Something else you may have noticed is in the Migration tag the version number is fairly large, to make versioning easier on a team, I’m not using consecutive numbers but the date and time(using 24 hour time) of when the I added this class, so the the example class I created was on 6/24/2011 at 23:24 10. The current version number is also stored in the DB, making it very simple to see what DB version you’re on, this can come in handy if your code is based on a specific DB version you can do a simple check to see if you have the correct DB version.

Keeping version iterations small

Just like when creating a business logic class, you should follow the single responsibility principal, and have each class do only one thing, this may mean having a lot of classes but on the other side it will make it a lot easier to keep track of what each version added, modified, or removed.

Adding stuff to the Data Base

Using the Fluent api allows you to very smoothly add tables, columns etc. in a very readable way.  If you look at the Up method in the above example you can see how easy it is to add a table with columns.  This makes it very easy to add your own extension methods to short had it even further.  Here is an example for creating an identity column and a table with time stamps:

   1: internal static class MigrationExtensions

   2: {

   3:     public static ICreateTableColumnOptionOrWithColumnSyntax WithIdColumn(this ICreateTableWithColumnSyntax tableWithColumnSyntax)

   4:     {

   5:         return tableWithColumnSyntax

   6:             .WithColumn("Id")

   7:             .AsInt32()

   8:             .NotNullable()

   9:             .PrimaryKey()

  10:             .Identity();

  11:     }

  12:  

  13:     public static ICreateTableColumnOptionOrWithColumnSyntax WithTimeStamps(this ICreateTableWithColumnSyntax tableWithColumnSyntax)

  14:     {

  15:         return tableWithColumnSyntax

  16:             .WithColumn("CreatedAt").AsDateTime().NotNullable()

  17:             .WithColumn("ModifiedAt").AsDateTime().NotNullable();

  18:     }

  19: }

But the api doesn't have everything you need so you have the option of adding in strait sql using Execute.Sql(). like this example:

   1: Execute.Sql("DELETE FROM `Users` WHERE Name = 'TestUser'");

also you can call sql files like this:

   1: Execute.Script("myscript.sql");

Adding Data

The next step is to add some data. This could be some sample data for development, a larger dataset for QA, QA data for a specific type of customer, or base data for production.  By adding profiles you can abstract away what data you want to add for specific function. This is not where you add data for things the should be constant, things like lookup tables should be handled by a versioned migration class.  Here is an example of a profile class:

   1: [Profile("Development")]

   2: public class DevelopmentProfile : Migration

   3: {

   4:     public override void Up()

   5:     {

   6:             

   7:         Insert.IntoTable("Users").Row(new {Name = "TestUser", Password="12345"});

   8:     }

   9:  

  10:     public override void Down()

  11:     {

  12:         Execute.Sql("DELETE FROM `Users` WHERE Name = 'TestUser'");

  13:     }

  14: }

Just like a Version class it inherits from the Migration class and has an up and a down method, this way when you add one profile it will remove the other profiles.

Deploying/Migrating Your Data Base

Deploying or Migrating your data can be done with a console app or with a build runner like MSBuild, nAnt, or Rake making it easy to integrate into your existing build process.  For this example we are going to use nAnt.  Here is an example nAnt build file:

   1: xml version="1.0" encoding="UTF-8" ?>

   2: <project name="FluentMigratorProof" xmlns="http://nant.sourceforge.net/release/0.90/nant.xsd" default="migrate-Production">

   3:   <loadtasks assembly="./FluentMigrator.NAnt.dll" />

   4:   <target name="Reset" description="Migrate the database to the base version">

   5:     <migrate

   6:     database="sql"

   7:     connection="Data Source=DevBOX\SQLEXPRESS;Initial Catalog=FluentMigratorProof;User Id=BuildUser;Password=xxxxxxx;"

   8:     namespace="FluentMigratorProof"

   9:     target="./FluentMigratorProof.dll"

  10:     task="rollback:all"

  11:     />

  12:   target>

  13:   <target name="migrate-Production" description="Migrate the database to the latest version">

  14:     <migrate

  15:     database="sql"

  16:     connection="Data Source=Production\SQLEXPRESS;Initial Catalog=FluentMigratorProof;User Id=BuildUser;Password=xxxxxxx;"

  17:     namespace="FluentMigratorProof"

  18:     target="./FluentMigratorProof.dll"

  19:     profile="Production"

  20:     />

  21:   target>

  22:   <target name="migrate-Development" description="Migrate the database to the latest version">

  23:     <migrate

  24:     database="sql"

  25:     connection="Data Source=DevBOX\SQLEXPRESS;Initial Catalog=FluentMigratorProof;User Id=BuildUser;Password=xxxxxx;"

  26:     namespace="FluentMigratorProof"

  27:     target="./FluentMigratorProof"

  28:     profile="Development"

  29:     />

  30:   target>

  31: project>

To use FluentMigrator with nAnt you use loadtask to specify the FluentMigrator.dll then you add a migrate task in your target.  Your migrate task will need to have the following properties:

• database – this specifies the type of DB (sql, oracle, sqllight, mysql, etc.)
• connection – this specifies the DataBase your going to connect to and with what permissions
• namespace – this is the application namespace your going to run allowing you to migrate multiple DB in the same project
• target – this is the .Dll you’re calling to migrate from
• Profile – this is what profile your loading
• task(optional) – this is how you specify what version you want to build, or if you want to roll back, etc.

Then to run your migration simply run NAnt.exe with the name of your build file something like:

   1: NAnt.exe -buildfile:ProofBuild.nant.build

A full explanation of using nAnt is a little out of scope for this blog post so if you want more info on nAnt see nAnt Help Page.

As always here is a sample project using this.

Where is the passion?

On the 4th of July I had a really good conversation with @jamis a former member of the rails core team and a fairly prominent member of the ruby community and I was reminded how much the Ruby community appers to be more dedicated to craftmanship then the .net community as a whole. 

This may be just an outsiders view but ruby devs seem to be more dedicated to pair programing,  TDD, CI, etc.  and basicly more interested in writing software to make a living vs. where in the dot net comunity it feels  more like developers write software just to make a living, there are a few leaders that  that push these ideas, but for the most part it seem more previlant in the ruby community.

So my real question is, why?  is the ruby stack just more attractive to people of this disposion?  is it just becouse dot net is just more widely used and thus just has a wider spectrum of developers in it?  Is it just becouse I have a very limmited view of the ruby community and only seeing the cream of the crop, or am I just somewhat jaded and only seeing the negative in the .net community?  To this I don't have a good answer.
 
So the next question is how do we get the passion in the .NET dev stack?  it's not like there is a lack of interesting things to learn and build, can we do more community work?  Boise has a .NET user group (netdug), a software developers group(bsdg) that is mostly .net developers, and a code camp every year, but for the most part it's the same people group presenting.  my open question to the group is how do we get more people interested in presenting, do we start younger? maybe start youth dev groups? maybe as a group pressure each other to be more active?  For my part, I need to step up and do my part, and rededicate myself to blogging.