0 Comments

I read this post the other day: How To Compete Against Yourself: Don’t Do Your Best, Do Better Than Your Personal Average. It’s got some great points on how to establish better habits and be more productive.

One of the big points was to find measurable stats and track them, and try to beat your average (not your best, because you’re putting out a high level of effort constantly which will burn you out).

I though to myself, “self, what’s a good stat for coding?” Doesn’t have to be a perfect model, but something simple and traceable. I thought of grabbing lines changed per day.

I did a bunch of research, and there’s not an easy way to get that data, not from git tools, not from github stats.

So I wrote the following PowerShell snippet that grabs the entire git log by author and date, parses the insertion/deletion counts, and sums it all up:

git log --pretty=oneline --shortstat --no-notes -C --after 2016-01-22 --before 2016-01-23 --author=chris | # grab git log. replace dates and author
Select-String '(\d+) insertion.*?(\d+) deletion' -AllMatches | # find insertion/deletion line and capture values
ForEach-Object { $_.Matches } | # pull in the regex
ForEach-Object { New-Object psobject -Property @{ Adds = $_.Groups[1].Value; Deletes = $_.Groups[2].Value } } | # for each match, capture adds/deletes into a ps object
Measure-Object -Property @("Adds","Deletes") -Sum # sum up the values

Replace my name with yours and use the dates you want (after yesterday and before today) and you’ll get some useful output like:

Count    : 7
Average  :
Sum      : 704
Maximum  :
Minimum  :
Property : Adds

Count    : 7
Average  :
Sum      : 95
Maximum  :
Minimum  :
Property : Deletes

I’m sure someone with some better PowerShell-fu could simplify the snippet. If that’s you, let me know!

1 Comments

Although I hate Visual SourceSafe with a passion, my current job requires it. I much prefer SourceGear Vault, and can't wait until the day I'm back on a Vault SCC system. But for now, I must use VSS. I recently had the problem of VSS integration not working in Visual Studio 2005. I found the following steps, based on reregistering the VSS MSSCCI (MS Source Code Control Interface) dll's:

In the VSS folder (usually C:\Program Files\Microsoft Visual SourceSafe\), register the following dll's:

  • ssscc.dll
  • remotevssscc.dll
  • tdnamespaceextension.dll

Using regsvr32, that would look like:

regsvr32 ssscc.dll
regsvr32 remotevssscc.dll
regsvr32 tdnamespaceextension.dll

Then open VS 2005, and go to the Tools->Options and the Source Control/Plug-in Selection page. You should now be able to select Microsoft Visual SourceSafe from the plugin dropdown.

NOTE: Source control integration is not supported in the express editions of Visual Studio.

Thanks for these instructions goes toMichael Daniel.

2 Comments

I've run across a few ASP.NET based issue tracking tools. Here's a list of the best ones I found:

  • Gemini [CounterSoft]
    This is a lightweight, but powerful issue tracking tool. It has a very simple install, and a free license option (up to 10 users, and only on an internal server). The full enterprise license is just $280. I set this up at Assisted Solutions and Data Research Group, and they have been very happy with it thus far. It has a few quirks, but supports all the main functionality needed in an issue tracking tool.
  • Dragnet [SourceGear]
    Dragnet is SourceGear's entry into the issue tracking arena. It's got a prettier interface than Gemini, but as far as I can tell, doesn't have a whole lot more functionality. And the price is sky high, comparatively, at $129 per user. I use SourceGear's Vault system for source control, and have been very satisfied with that, so it would seem that Dragnet would be high quality, and continuing to develop in features. But is it really worth the price premium? Perhaps Eric Sinkcan weigh in with more information on that.
  • BugTracker.NET [free]
    This is a free bug tracking system in .NET. Looks interesting, and still fairly active after several years of development
  • Issue Tracker Starter Kit [free]
    There is also, of course, the Microsoft Issue Tracking starter kit.
  • BugNet [free]
    Another free bug tracker.

With the amount of free or cheap bug tracking tools, it's hard to justify having one not set up. In team development, it's invaluable. For individual developers, it's still a great tool to keep track of customer issues and todos.

If anyone has a favorite bug tracking tool, definitely drop me a comment and I'll add it to the list. And if you want a more in depth review, let me know.

UPDATE: wikipedia has a fairly exhaustive grid of bug tracking systems.

UPDATE: another list of bug tracking systems

1 Comments

Most ASP.NET development shops have multiple projects, each with multiple developers working on them. Keeping track of these projects, and making sure they are available in a common location for review can be quite a chore. Recently, I set up a staging server for my company using CruiseControl.NET. This enables any developer, project manager, or other stakeholder to have access to the latest version of the site as it is being built. Because it is an automated process, there is no developer time required to generate and post updates to the central development staging server. This method is also useful for teams practicing Continuous Integration, but the main goal is to use easily available tools to create an automated staging server for ASP.NET web applications.

This post outlines the steps required to create an automated staging server using CruiseControl.NET. It also goes through several gotchas that can cause issues if you aren't prepared for them.

What is CruiseControl.NET?

CruiseControl.NET (CCNet) consists of a suite of applications, but at its core is the CruiseControl.NET Server which is an automated integration server. The Server automates the integration process by monitoring the team's source control repository directly. Every time a developer commits a new set of modifications, the server will automatically launch an integration build to validate the changes. When the build is complete, the server notifies the developer whether the changes that they committed integrated successfully or not.
-- From the CruiseControl.NET site

What is Continuous Integration?

The practice of continuous integration represents a fundamental shift in the process of building software. It takes integration, commonly an infrequent and painful exercise, and makes it a simple, core part of a developer's daily activities. Integrating continuously makes integration a part of the natural rhythm of coding, an integral part of the test-code-refactor cycle. Continuous integration is about progressing steadily forward by taking small steps. ... A successful integration is a measure of progress. It provides feedback that the new code runs correctly in the integration environment and successfully interoperates with the rest of the code base. Code sitting unintegrated in a developer's workspace simply does not exist. It is not part of the code base, it cannot be accessed by other developers or tested by the customer. Only when it has been successfully integrated is the benefit of the new code realised.
-- From the CruiseControl.NET site

Requirements

Server running IIS and ASP.NET 2.0 -- this will most likely be a normal Windows Server 2003 box, but a Windows XP box could be used if necessary. This should also work with Mono on a linux box or other platforms Mono supports, but I haven't tested that configuration.

CruiseControl.NET - Download [.zip]

MSBuild XML logger

Source control software - this example uses SourceGear Vault, but any other source control tool supported by CruiseControl.NET should work. Here's a list of the scc tools supported by CruiseControl.

Setting up CruiseControl

Setting up CruiseControl.NET is very simple.

  1. Grab the .zip.
  2. Extract it to a folder on your server.
  3. Create a virtual directory to the webdashboard folder.

Adding an application to CruiseControl

Create a folder to hold the root of your source repository. I generally put this in c:\dev, or some other simple folder on the server.

Use your source control to pull down the root folder of your application. This ensures that the folder structure is created properly. After adding the application to CruiseControl.NET, the source will be updated automatically.

Drop the MSBuild XML logger dll into the root folder of the application. Because the MSBuild task is a CruiseControl.NET addon, it doesn't include support for parsing the MSBuild build log.

Open the ccnet.config file in the server folder of the CruiseControl.NET application. I pulled out a template application configuration from my setup. Descriptions of each section follow.

<cruisecontrol>
<project name="project">
<webURL>http://server/project/</webURL>
<triggers>
<intervalTrigger seconds="60" />
</triggers>
<sourcecontrol type="vault" autoGetSource="true" applyLabel="false">
<executable>c:\program files\sourcegear\vault client\vault.exe</executable>
<username>user</username>
<password>password</password>
<host>source.company.com</host>
<repository>repository</repository>
<folder>$/project/trunk</folder>
<ssl>false</ssl>
<useWorkingDirectory>false</useWorkingDirectory>
<workingDirectory>c:\dev\project\trunk</workingDirectory>
</sourcecontrol>
<tasks>
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingDirectory>c:\dev\project\trunk</workingDirectory>
<projectFile>project.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs>
<targets>Build</targets>
<timeout>15</timeout>
<logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
</tasks>
</project>
</cruisecontrol>

This config file has only one project, but you can add additional projects by adding additional project sections. The important parts of this configuration are the webURL key (which we will use later in the dashboard page, so make sure this points to the location where you intend to set up the application virtual directory), and the configuration settings and locations for scc and the build task. The scc task points at a folder on the repository to bring down, and a location to put it in locally. Make sure this points properly to the application root directory you set up in the local dev tree by pulling the source manually. The projectFile key of the msbuild task should point to the solution file for the project. The workingDirectory key of the msbuild task points to the location locally where the solution file can be found.

For more information on the config file, check out the relevant section of the CruiseControl.NET documentation.

NOTE: If your app has binaries that are referenced in the projects, but included elsewhere in the source tree, you will have to create another task to pull the component binaries. You can do this by creating a seperate project section, but only including a scc task and not a build task. CruiseControl.NET does not require a build task in a project. This will pull the binaries as they are updated, eliminating another manual step.

<project name="Components">
<triggers>
<intervalTrigger seconds="60" />
</triggers>
<sourcecontrol type="vault" autoGetSource="true" applyLabel="false">
<executable>c:\program files\sourcegear\vault client\vault.exe</executable>
<username>user</username>
<password>password</password>
<host>source.company.com</host>
<repository>repository</repository>
<folder>$/Components</folder>
<ssl>false</ssl>
<useWorkingDirectory>false</useWorkingDirectory>
<workingDirectory>c:\dev\Components</workingDirectory>
</sourcecontrol>
</project>

NOTE: If the site you are using is an ASP.NET Web Application project, you will need to install the Web App Project support files on the server. You can get them from Microsoft here. If the server doesn't have VS 2005 installed, the installers will fail, but you can still get a web app project to build by copying over the msbuild support files manually. Follow these steps:

  • On a development machine with VS and the web app project support files installed, go to C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications
  • Get the Microsoft.WebApplication.targets file
  • Create a C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications folder on your server
  • Put the .targets file there

NOTE: If you are using an ASP.NET Web Site Project, and have dependancies, most likely they will not get copied properly during the compilation process. Here is an additional msbuild file you can add as a seperate task to copy the files over from the compiled web folder:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<SourceDlls Include=".\PrecompiledWeb\client\bin\*.*" />
</ItemGroup>
<Target Name="Build">
<Copy sourcefiles="@(SourceDlls)" DestinationFolder=".\client\Bin" SkipUnchangedFiles="false" />
</Target>
</Project>

Call this with an additional msbuild task like so:

<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingDirectory>C:\dev\project\client</workingDirectory>
<projectFile>copyassemblies.msbuild</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs>
<targets>Build</targets>
<timeout>15</timeout>
<logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>

Building and checking status in CruiseControl

Run ccnet.exe. This will start a dos box that shows the CruiseControl.NET status as it parses the config file, pulls source from scc, and builds the application.

Open a browser and point it to the location where you installed the web console.

Unless you make pulling from scc and building directly a regular practice, you will probably run into some reference and other build issues. Most of these should be fairly simple to resolve, and by resolving these issues you increase the quality of your repository source tree.

Setting up the application virtual directory

Now that the application builds successfully, you can create a virtual directory in IIS to make it accessible.

Open IIS and create a virtual directory that points to the web application folder in the source tree. Use the same name you specified for the application url above.

Open a browser and navigate to the virtual directory you created. If all the build steps went properly and the application is configured directly, you'll see your app in all its automated build glory.

Setting up CruiseControl.NET as a service

Up till now, we've been running CruiseControl.NET as an interactive application. This is great for testing, but doesn't work so well in a production environment. Setting CruiseControl.NET up as a service is fairly straightforward. Here is a tutorial that will walk you through the process.

Creating a dashboard page

The final step is to create a dashboard page that pulls together all the applications you've set up and provides an easy way to navigate to them. This is a great page to hand to a non-techical person, manager etc., so they can easily keep track of application status and review or test applications at any time. I've created a sample page that pulls the app information from the ccnet.config file. Just drop the .aspx and web.config in a folder on the staging server. You'll need to change the ccnetConfigLocation appSettings key to point to the ccnet.config file, and the ccnetConsoleLocation to point to the web console url. Feel free to modify this as necessary to fit your organization. If you come up with any innovations, it'd be great to have them so I can merge them in so everyone can take advantage of them.

Files generated

  • Sample dashboard page and web.config
  • Sample ccnet.config
  • copyassemblies.msbuild

Download