I’m a big fan of ConEmu. I’ve recently starting making use of the split console capability, as shown below

Getting the split screen is easy, you just have to select the option in the new console window dialog

Here’s the triple split that I typically use for Node.js development:

What I really want though is my split screen setup in one easy step. Fortunately that’s possible with little effort through some additional commands in ConEmu’s Tasks option. What I did was created a new task called Node.js with the following options:

Explanation:

Node.js – this is just the task name

Commands

The > before powershell.exe means that I want this console to be the active one when I start the task

powershell.exe is listed three times, delimited by empty lines, this means I want powershell to open 3 times

The second powershell.exe has the option -cur_console:as30H, meaning that I want it to be a horizontal split at the size of 30%

The third powershell.exe has the option -cur_console:as30V, meaning that I want it to be a vertical split at the size of 30%. Since this comes after the second command, it will be split under the second console, as shown in the screenshot above

Additional option: -noexit -command “$host.UI.RawUI.WindowTitle=’NodeJS'” means that I want to set the title of the tab to NodeJS

I recently started using Lync 2013, but with a couple of hacks to get it work with our Communicator 2007 server. While trying to apply various registry hacks to get things like Outlook 2013 integration to work, I somehow broke my capability to search for contacts in Lync.

The fix turned out to be just exiting Lync, deleting this registry key, and opening Lync again. Then voila, I can now search my contacts again.

Being a bit of a font geek (a little, not much), I am always on the lookout for a better coding font. As a long time user of Microsoft’s Consolas, and Damien Guard’s Envy Code R, I was excited to try out Adobe’s new entry, Source Code Pro. I always want to see a comparison between what I use and the new font in question. So here are the comparisons:

The first thing that I notice between Envy Code R and Source Code Pro is the difference in width. I have both of these dialed up to 11. Envy Code R is a little more subtle on distinguishing letters which can be commonly confused, such as 1 and l, O and 0, and so on. Even though I can fit more code on the screen with Envy Code R, it might be worth trying Source Code Pro for a while to see if it is generally easier to read.

(Source Code Pro on top, Envy Code R on the bottom)

Next we have Microsoft’s Consolas vs Adobe’s Source Code Pro. Again, more code fits onto the screen with Consolas over Source Code Pro; not only horizontally, but also vertically. I do like the sweeping bottoms of Source Code Pro’s lower case L and I over Consolas, which are conversely flat. Compared to Source Code Pro, Consolas just looks harsh. Of course it’s not nearly as harsh as something like Courier New, but in this comparison, it’s clearly not the winner.

(Source Code Pro on top, Consolas on the bottom)

I’m pretty much over using Consolas. It’s still a nice font, but when I start to focus in on the parts of it that I really don’t care for, those parts become difficult to ignore. Envy Code R is my font of choice, but I will give Source Code Pro at least a week of trial before giving it a final thumbs up or down.

Converting from the Brail View Engine to the Spark View Engine for MonoRail apps might not be interesting to many people, but here it is nonetheless. (We’re having to convert a project over due to switching our dependency management to Nuget.. hence the old Brail View Engine does not like the newer Castle.Core.)

Tags:

Brail property bag shortcuts:

<head>
<title>${Title}</title>
</head>

Spark equivalent :

<head>
<title>${PropertyBag["Title"]}</title>
</head>

The only problem with this is it’s not as clean as the Brail version. However, there’s a solution. By using the

and in the Main layout, you specify where the view content is rendered like so:

<div>
${ChildOutput}
</div>

This doesn’t work in Spark. If you provide a second layout parameter to the Layout attribute on your controller, Spark will use that for the view content. So to fix this, we have to remove the second Layout attribute parameter:

and then adjust our HTML to have the <use /> tag instead (I think this is cleaner)

<div>
<use file="myPartialPage" />
<use content="view" />
</div>

Other things:
Brail has a handy ${SiteRoot} variable added to the view context, which will give you the root path of the site for things like including scripts and css. With Spark, you can also use ${SiteRoot}, you just have to setup a couple of things first:

So Scott Koon and I going through converting a project from using MBUnit / Gallio to NUnit instead, mainly for the speed benefits, but also for complying with the direction of our development moving forward. One gotcha we just ran into is in the way NUnit handles custom attributes.

The test where the attributed class is instantiated has not been hit yet by NUnit. Instead, it seems that NUnit is gleaning over the text fixtures in the assembly, finding all of the custom attributes, and instantiating those attributes before running any of the tests. We ran into this issue because of an attribute that had an IoC container lookup (I know what you’re going to say, but we didn’t write it) in the constructor of the attribute. Due to the container not yet being initialized, an exception was thrown.

Hopefully Charlie Poole can provide some insight into this strange behavior on NUnit’s part.

Giles, my pet auto test runner project for .NET applications, has just grown up to v0.1.1.2 and been released on Nuget. Included in this release (and some previous releases) are:

v0.1.1.2 - Sept 12, 2011
- Added x86 version of Giles to support testing of x86 target applications. A giles-x86.ps1 script has also been included to launch the x86 Giles instead of the AnyCPU version
- Added Giles version output to help window and to the console window title
v0.1.1.1 - Sept 2, 2011
- Added giles.ps1 & init script. Now instead of having to run Giles manually from the nuget package, you just need to run giles.ps1 from the root of the solution. Giles will find the correct .sln files and start watching straight away.
- Added MIT license
v0.1.1.0 - Sept 1, 2011
- Fixed Machine.Specification versioning issue where the test project needed to have the same version of mspec that Giles was using. Giles no longer has a dependancy on Machine.Specifications.dll, so we're version independent now!
v0.1.0.2 - Aug 29, 2011
- Introduced Giles own runners instead of relying on console runners for each test framework
- The only command line option required now is the solution file to watch, the test assembly is determined automatically. If Giles gets the test assembly incorrect, then you can specify the test assembly location with the -t parameter

Most importantly with v0.1.1.0, through the magic of anonymous types and dynamics in .NET 4, Giles no longer cares which version of Machine.Specifications (mspec) you are running. Check it out!

Also in the latest version, v0.1.1.2, Giles now ships with a good ol’ x86 version for your thunking pleasure.