I’ve spent some time and money on a development rig for home, and I ended up with te following experience numbers.

That is great result for a complete machine under 1500€. Here are my first impressions on some of the components.

Intel X25-M 80Gb hard drive

You notice at once the at once, the difference between a traditional hard drive and this SSD from Intel. File operations are blazingly fast, and I use this disc as my system disc and have a traditional Western Digital Caviar Green as my main storage for games, programs, music and movies. With this drive my Windows 7 boots in no more than 10 seconds from POST, which is nothing short of amazing.

Gigabyte ATI Radeon 5750

I was looking for a low budget graphics card, since my focus is not playing games but development. I do not want to exclude the posibility, so a card that does not sound like a motor way and with low power consumption. Today, my girlfriend fired up The Sims 3 in full HD resolution without any complaints from the graphics card with neither lag nor noicy fan. I’m very happy with this choice!

Asus P7P55D and Intel i5 750

I found out that Intel i5 750 actually outperformed the old Intel i7 920 and is cheaper at the same time. This is the best choice for any budget computer, but still has a very sharp edge. It seems like a very happy combination together with the Asus P7P55D mother board, which was a joy to install in my system. I have not found any real annoyances with this mother board yet, and troubleshooting failing components is a blast with on board leds that tells you whats wrong. No more looking up short beeps, long beeps in the manuall to try to interpretate why system boot is failing.

Complete specifications

Here is a complete specification of my system. Enjoy!

• Chassis: Antec miditower nine hundret two
• PSU: Corsair TX 650W
• Motherboard: Asus P7P55D P55 S-1156
• CPU: Intel Core i5 750 2.66Ghz
• CPU cooler: Noctua NH-U12P
• System drive: Intel X25-M 80Gb
• Storage drive: Western Digital Caviar Green 1Tb
• RAM: Kingston DIMM DDR3 4Gb 1333Mhz CL9
• GPU: Gigabyte Radeon HD5750 1Gb GDDR5

So, I had an unnerving experience trying to install Windows 7 the last couple of days. After the files where extracted from the dvd and the splash animation had run, the installation would hang, showing only the end of the splash animation with the frisky message “Starting Windows”.

It took me a total of 8 hours to figure it out. Many of the tips you will find on the Internet tells you to

• Jank out all USB devices and disable USB in the BIOS if possible
• Make sure that 1397 is disabled in the BIOS
• Disconnect everything in the computer that is not needed for the installation, including expansion cards and extra hard drives.
• Update the bios with the latest version from your vendor
• Reset the bios and make sure that APCI is enabled

None of these did the the trick for me. What made the installation process hang was the second 2GB memory module that I’ve installed in my system. By removing all memory modules except one, the installation could proceed.

There does not seem to be any silver bullet for solving this issue, and it does seem to be different for each and every failed installation. It would be nice to get some kind of error message to ease troubleshooting.

I wish you good luck if you have a similiar problem!

I’ll write this post to clear out the differences of these two CMSes. Note that these are my viewpoints and not the ones of my employer.

Why choose EPiServer over N2?

1. EPiServer has customer support.
   If your main line of business is not education, you can send your editors to a course at EPiServer, where they’ll learn how to maintain a website. This is a security for you as a developer as well as for the customer.
2. EPiServer is a company with a product.
   This means that you can get guarantees and support for an amount of time in the future. You can demand that bugs should be fixed and you have a contract to lean on.
3. EPiServer lets your editor create user input forms and gather the data.
   Most developers fear this functionality since it is not very well implemented, but I’ve seen customers make good use of it. The argument ”it saves you money since you don’t need a developer to gather input data” is false, because these forms always needs some tweaking before working as they should. It is a nice and selling idea though.
4. EPiServer has scheduled jobs.
   Indeed, you do not have to create your own windows services for your scheduled tasks. You will also get a control panel within EPiServer Administrators Mode that can be used by the administrator to control behaviour of the scheduled job.
5. EPiServer has lots of plugins like Community and Relate+.
   This is a pit of failure that customers will fall into thinking that they will need community functionality in the future. It is great for sales people that wants to lure the customer in with the immense diversity of EPiServer, but then they have never considered yagni.
6. EPiServer has Office integration.
   Also a great selling point, but do you really need it?
7. EPiServer has lots of documentation.
   And this makes it easier to get new developers start working with EPiServer. It also makes it much easier to find developers that can maintain your website.
8. EPiServer will scale horizontally by a custom made cache system.
   If you have a website with enough traffic for two or more web servers, EPiServer makes it easier to share cache between these clustered servers.

Why choose N2 over EPiServer?

1. There is no license fee.
   When creating a small business website you don’t want one quarter of the cost being licensing fees.
2. It’s open source.
   If developers finds a bug they can fix it, to opposed to EPiServer where they would have to work around it. Also if you need to know how something is working you can look at the source, which is very easily read, and don’t have to rely so much on updated documentation.
3. It is lightweight.
   You feel it when you’re working in it as an editor – it responds very fast, and you feel it when you’re working in it as a developer – it never gets in your way. I would claim that this is the main reason why N2 development is faster than EPiServer development. Less is more.
4. N2 CMS is easier to use.
   The editors interface is much easier to use because it does not have the complexity of EPiServer. The base functionality is very simple, and then it is up to the developer to make it complex. N2 CMS is also very easy to get started with as a developer. The API has a much nicer and extendable design than EPiServer that makes it easier to test and easier to maintain – read: lower cost.

Everywhere you have EPiServer offering a functionality you can easily substitute this. When you need scheduled jobs, you bring in Quartz.NET. If you want to gather customer feedback you don’t need a forms builder, but User Voice (or Kundo in Sweden). When you need to scale out your website, you use Velocity caching for NHibernate instead of syscache2 that comes out of the box. That N2 is lightweight means that you extend it when you need to, and not try to solve global warming out of the box.

Cases – when I should use one over another

1. You’re a multi billion company that needs a new multilingual website. You have a hundred editors in 15 countries and you need the right tool to make this work.
   EPiServer is the right tool when it comes to websites that will have tens of thousands of pages over several languages. You will also have much better support for workflows, where one user is writer, another is editor and there is a publishing mechanism that makes sure that the correct people have seen the content before it goes live.
2. Your main business is not content, but you need a CMS to host your service.
   This is a solid case for N2, the CMS that will not get in your way as you focus on producing your service, but will give you all the advantages of managing your content. In this case the content management system will work more as a control panel than a publishing platform.

Many customers thinks that they need everything and would go for any system that has it all, but what they care to ignore is that larger systems always are more complex and will be more expensive to maintain. It is developers responsibility to guide clients into making right decisions.

I’ve always had problems with JavaScript, because the lack of tooling, no good source for documentation and the most advanced way of debugging being alert. It has become easier over the years with jQuery and Firebug, but being used to C# I’m still a bit lost when it comes to JavaScript.

I was recently required to write some validation logic in JavaScript, and to make sure that I was on track the whole time, I adopted TDD in JavaScript with QUnit.

QUnit

Writing tests for JavaScript is actually much easier than unit testing C# code. You have so much more freedom in a dynamically typed language that makes it easier to write tests that will not pass, such as code in a statically typed language would not compile.

Getting started

Download jQuery, qunit.js and qunit.css and include them in an HTML document that will be host of your test suite.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Required field validation</title>
    <script type="text/javascript" src="jquery-1.3.2.min.js"></script>
	<script type="text/javascript" src="qunit.js"></script>
    <link rel="stylesheet" href="qunit.css" type="text/css" media="screen" />

	<!-- SYSTEM UNDER TEST -->
	<script type="text/javascript" src="Validation.js"></script>
    <script type="text/javascript">
        $(document).ready(function () {
			/* TESTS GO HERE */
        });
    </script>
</head>
<body>
	<!-- QUNIT REQUIRED HTML -->
    <h1 id="qunit-header">Required field validation</h1>
    <h2 id="qunit-banner"></h2>
    <h2 id="qunit-userAgent"></h2>
    <ol id="qunit-tests"></ol>

	<!-- TEST STRUCTURE -->
    <div id="test-container" style="display: none">
    </div>
</body>
</html>

Keywords

You write your tests in the HTML document that you’ve created, and you use different HTML documents to divide your test suite in sections as it grows. My first test looks like this.

module("Validate on blur()");
test("Should validate required field as false when input value is empty", function() {
	expect(1);

	/* Initialize the validation */
	heartbeat.initialize();

	/* Select the required 'Name' field and execute blur() event */
	$('#Name').blur();

	equals($('#name-field').data('isValid'), false, 'Expected the field to be marked as invalid on blur()');
});

• module([string] heading) – A way to group tests together under a common heading
• test([string] name, function()) – The name of the test and the test code
• expect(1) – tells the test runner that I will use 1 assert
• equals([obj] actual, [obj] expecting, [string] message) – compares actual object with expecting object and fails if they are not equal. The message describes the failing condition.
• ok([boolean] condition) – though not present here, you can use the ok method instead of equals if you want to check that a condition is true.

It runs on the following HTML part.

<div id="name-field" class="field name required">
	<label for="Name">Your name</label>
	<input id="Name" name="Name" type="text" value="" />
</div>

The beautiful thing about this is that I can write this test and get a red result without having implemented the actual validation logic yet. So, I implement the logic to make the test green and in my browser it looks like this.

One test executed successfully!

Setup and Teardown

Using the same HTML structure for all tests in the test suite is however not a good idea, because it will accuire state that will effectivly affect all other tests in the test suite. This means that we will have to recreate the HTML structure for every test run.

/* SETUP / TEARDOWN */
QUnit.testStart = function (name) {
	$('#test-container').append('<div id="name-field" class="field name required"><label for="Name">Your name</label><input id="Name" name="Name" type="text" value="" /></div>');
};

QUnit.testDone = function (name, failures, total) {
	$('#test-container').empty();
}
/* ************* */

There is no longer any reason not to unit test your JavaScript. You can download the whole example from here.