Resizing NTFS Partitions

Quite simply, the very idea freaks me out. The way NTFS partitions are managed in Windows… well, let’s just say resizing appears to be less straightforward than it makes me comfortable. And yes, there are some tool$ available to do the job securely, but again, in an emerging economy, some tool$ are just not priced affordably. Hello, GParted.

Defrag your NTFS partition (mostly ‘cos it invokes a layer of warm and fuzzy doing so)
Download the GParted LiveCD, burn the ISO (while we’re on the topic of burning ISO’s from Windows, again, it really is a bit of a unaffordable freeware/shareware mission)
Boot up with the LiveCD
Resize your NTFS
Reboot back into Windows (this allows windows to do it’s own CHKDSK on the “new” partition)

That’s it. Did it work? Oh yeah, it works. No corrupt programs, data, files, nada. Even my Lenovo SecureDrive volume is still intact…

… as you can see.

Owning Your Continous Integration

The ideas here is to “own” your continous integration process and make it work for you. Afterall, you spent some time setting up CruiseControl.Net and it’s ticking along nicely. At some stage, you need to make it “yours” and let it reflect your needs in terms of your process and record build data that you use [need] to make decisions.

In fact, i’d encourage you to really push into making it your own. Not just the look ‘n feel- but the real nitty gritty. Define and extend and experiment with your continuous integration process to make it add value…

the Scenario
Our automated build process runs a series of tests against a database. Before we start the tests, we need to record some information about the database; this being gathered by means of a stored procedure. We also need to persist the results as part of the build so we can monitor trends.

the Tools
* Nant build script
* Nant custom user task
* stored procedure
* xslt template
* config files

The Nant build script is included as part of the build process kickstarted by the configured in cc. For more information on setting up, review the documentation that comes as part of the distribution. The ccnet.config file should include a nant <node> under tasks, similar to this…


The Nant build script then calls a Nant custom user task which has the responsibility of executing the stored procedure and formatting the results into an xml file. To execute the custom task, somewhere along your build path, you will include something like…

<project name="ccnetLaunch" default="go">
<target name="go">
<loadtasks assembly="${nant::get-base-directory()}/mytask.dll" />
<myTask ConnectionString="MY_CONNECTION_STRING" SqlStatement="sp_myTask"
LogFile="myTask.xml" />

<loadtasks/> helps define <myTask/> which is built into an assembly and in this case, placed into the nant/bin directory. The nant custom user task is straightforward and the nant distribution includes a basic template sample which you can follow easily enough. another sample here

The xml output file itself is then merged into the cc build report. Again, your ccnet.config file handles this easily with…

<xmllogger />

Finally, you need to add the xslt which transforms the xml output into the dashboard. Add the xslt file to the webdashboard xslt folder and append to the dashboard.config file, something similar to this…

<xslReportBuildPlugin description="My Results" actionName="MyDataReport" xslFileName="xsl\mytask.xsl" />

Now each build successfully calls your custom user task, saves the result of the stored procedure to an xml file which is merged into the build output and accessible from the dashboard for as long as you got build logs 🙂

Following this concept should give you an idea of how to start owning your process and not just going with the stock standard install. Set it up, take some risks and call it your own.