As a small software development shop, we have always used VSS. At first we had VPN issues so we jumped through all of the hoops to get it running on IIS with their provided webservice, But then it was always a pain getting a new project added to VSS properly (anyone else have projects like $/MyProject/MyProject - isn’t that annoying). And then whenever we had to get a new developer working on a project it was a difficult process to add a windows account, then a VSS account, then give them instructions on how to connect VSS using https and most of the time one little setting was off and they could not get connected.

On top of all of that, we could not view version history from within Visual Studio (the vss internet plugin does not support it). And when offsite, we could not even connect to sourcesafe using the regular client.

Checkin/Checkout kills productivity. I cannot tell you how many times I used to sit and wait on IM for one of my programmer to checkin the project file so I could add a form to our project. Or else wait for them to checkin a file (that they had not even finished testing) so I could make a small change to the file myself. But for years, I just thought that is how source control worked.

Then one day – my eyes were opened to concurrent development. I had heard of it before on open source projects, but didn’t really know anything about trunks, branches and merges. I knew visual studio team system worked this way, but every time I looked at the price tag on vsts, I knew that was not an option.

I read about CVS style source control and SourceGear Vault. Now my team and I have eliminated all of our connectivity issues, we are no longer waiting for checkins, and we can easily view file history (and even line history!). Vault has changed the way we develop and even the way we deploy websites and applications. Our deployment scripts grab the latest version right out of source control (we did this before with VSS, but their command line app did not work over http).

In Vault, setting up new projects is a breeze. I love the idea of creating a separate repository for each project (in vss we had to keep all our projects in one database so we could use http). And storing the repositories in SQL makes my backups much easier to maintain since they are already automated thru my existing SQL backup routine.

In my opinion, SQL Profiler is one of the least known and yet most powerful programmer tools out there. For those of you unfamiliar with Profiler, it basically lets you watch under the hood of your application to see all of the calls to your SQL database. It not only tells you each query or stored procedure call, it includes the read count, and duration, along with many other bits of helpful info.

I have given a handful of interviews for .net developers over the past few years and I always ask if they use SQL Profiler. There have been a couple of candidates that had heard of it but never really used it, and the only ones that had used it were dbas and not coders.

Today’s development tools make it super easy to have your database do a whole lot of unnecessary work. SQL Profiler the first app I open up when I am about to review or test one of my developers’ work. Sure enough, no matter how much I cram profiler down their throats it never fails. I can tell right away whether they had it open when they were testing their own code.

Here is what I find most:

• LINQ queries that check for .Count > 0 or .Any() before binding (yes that’s one call to get the count and another to retrieve the results)
• Binding controls multiple times, or even multiple Page.Databind calls
• Frequent calls to “Settings” tables or lookup tables where the data rarely changes and should be cached
• Calling the same function from within a loop instead of calling it once and setting a local variable
• Poorly written LINQ queries that are executing much slower than they should
• LINQ queries that are referenced or bound multiple times without being saved to a generic list
• Tables that are missing indexes (high read counts/durations)

SQL Profiler is also extremely useful for debugging production applications since it can spy into a web.winforms app without affecting its execution. And when you are ready to optimize for performance, just filter for query durations over 500-1000 milliseconds.

Tips

1. Uncheck all events except RPC:Completed and SQL:BatchCompleted
2. Filter by Login name or Application name (set in the connection string) to filter out other activity.
3. Filter for TextData Not Like exec sp_reset_connection.
4. Save the Trace Template with the filters for that project so you do not have to set them again.