Disabling services using powershell

Today I needed to disable around 80 services after instalation of some environment stuff on my machine (only one needed to be active). My workflow was something like: select service, goto properties, select startup type manual, confirm. This gets a bit tedious after two of three services especially because they were all in the same order because of a shared prefix.

So I did some googling around and came up with this Powershell command:
Get-Service | where {$.displayName -like “SomeServiceName*”} | ForEach-Object { Set-Service $.name -startuptype manual }

Worked like a charm.

Posted in Productivity | Leave a comment

added-little-schemer-source-to-github

I’m a bit daunted by all the info I had process today at my new gig, but as promised yesterday I have upped the source for the Little Schemer in javascript.

You can find the sources in this github repo.

The specs are a bit rough here and there, but I will revise and complete them when I find the time.

Posted in functional | Leave a comment

introduction-to-little-schemer

If you’ve never heard of functional programming, go may go here to find out why it matters.

There have been written many books on the topic, but I found the little schemer very good. The book uses Scheme to illustrate the material, but you can easily use javascript as well (as noted by Douglas Crockford here).

Initially I did all the examples using my mind as a debugger, but with all the ((())) in Scheme you get confused easily. Getting started with javascript was easy, especially when I combined some tools: LiveReload, Sublime TextEdit2, Jasmin BDD
and Firefox.
Using Sublime I can navigate really quickly between source and specs; Livereload runs all the tests (100+) in about a second and Firefox is used as a hook to livereload to display the test results. I’m planning to do a screencast on how this exactly works.

For now, I’m leaving with a promise to make the specs and implementation available on Github soon, but I don’t have the time right now to make that happen.

Posted in functional | Tagged , , | Leave a comment

blogging in markdown

Continue reading

Posted in Productivity | Leave a comment

testing routes in MVC3

So I wanted to do a series on testing in asp.net mvc3. How do you test routes properly?

Searching on stackoverflow did not reveal much help. In Pro ASP.NET MVC3 the writer introduces several utility helper classes (which I’m not going to copy due to copyright stuff, but also because the next method is much better). In short they test a route by mocking a bunch of classes that the routing needs, feed the url to the routing system and then verify whether the ‘controller’ and ‘action’ entries in the RouteData result match up against the expected values in the test.
Using their helpers one eventually comes to the following syntax:

I have several problems with this approach:

  1. The test uses hidden Asserts. Deep down in the TestRouteMatch method is the actual assert performed (actually many asserts)
  2. Because of this, when the test fails you need to dive into TestRouteMatch to troubleshoot
  3. It does not show immediately what is tested and what the outcome really means… so you have two parameters that represent the outcome, hmmn, why?

I immediately started refactoring the classes towards a more fluent assertion style but in the meantime I was eager to read more on mvc3 so I bought the Mvc3 in Action book that is currently in MEAP. Of course my refactoring towards a better assertion style had already been completed and documented… In it there is an excellent part on testing routes that refers to the mvccontrib TestHelper class.

Mvccontrib’s TestHelper

Testing routes can be done much cleaner using mvccontrib’s (awesome) TestHelper class. Have a look at the following:

`

The intent of the test is obvious to any reader of the code. Note that I’m using the word code here; in my view test code is most often more important than the actual code as it makes understanding the actual code that much easier.

You can get the mvccontrib extensions using this NuGet command:

Install-Package MvcContrib.Mvc3.TestHelper-ci

Enjoy!

Posted in Mvc | Leave a comment

New setup syntax in Moq is nice

I have used Rhino Mocks quite a bit in the past but recently starting using Moq. We were using an old version of the library (2.0) but when I switched to 4.0 I noticed a nice little detail.

Previously you would have to setup your tests in the AAA syntax, Arrange, Act, Assert. With the new syntax you can skip the Arrange and describe that in the Assert part of the test.

Let’s have a look. I’m going to assert that my homebrew Each extension will execute an action on all items in a collection.

public static class IEnumerableExtensions
{
    public static void Each<T>(
        this IEnumerable<T> target, Action<T> action)
    {
        foreach (var item in target)
        {
            action(item);
    }
}

}

public interface IFakeEachOperator
{
void PerformSomeActionOn(int i);
}

Nothing fancy here, but have a look at the test:

[Test]
public void acation_is_called_on_Each_old_style()
{
    //Arrange
    var ints = new[] { 1, 2, 3, 4 };
    var mock = new Mock<IFakeEachOperator>();
    mock.Setup(s => s.PerformSomeActionOn(It.IsAny<int>()))
        .AtMost(4);
<span style="color: green">//Act
</span>ints.Each(s =&gt; mock.Object.PerformSomeActionOn(s));

<span style="color: green">//Assert
</span>mock.Verify();

}

You’ll notice that I’m asserting against AtMost here; not very elegant as I’m looking for an exact match. In Moq 2.0 this was not possible (as far as I know), thus installed the latest and greatest and all of a sudden we are allowed to do this:

[Test]
public void acation_is_called_on_Each_new_style()
{
    //Setup
    var ints = new[] { 1, 2, 3, 4 };
    var mock = new Mock<IFakeEachOperator>();
<span style="color: green">//Act
</span>ints.Each(s =&gt; mock.Object.PerformSomeActionOn(s));

<span style="color: green">//Arrange &amp; Assert
</span>mock.Verify(s =&gt; s.PerformSomeActionOn(<span style="color: #2b91af">It</span>.IsAny&lt;<span style="color: blue">int</span>&gt;())
    , <span style="color: #2b91af">Times</span>.Exactly(4));

}

I have replaced the first Arrange by Setup because that’s all it is really doing. The arrangement and assertion can now be combined and to me that makes for much better readability in the test.

Posted in c#, TDD, test patterns | Tagged , , | Leave a comment

Using totalfinder dual mode

I have been battling OSX for quite a while now. In all honesty, the apple hardware is top notch but without some additional apps I just don’t seem to be productive on my mac.
Working with files in Finder has been a real pain in the butt to me. Today I found out some handy tricks using totalfinder dual mode.
Dual mode simply does what it’s supposed to do, it opens two windows next to each other in Finder so that you can easily manipulate the filesystem.

Totalfinder Dual Mode

These are some of the basic keystrokes I use quite often:

Total finder
CMD-U -> toggle dual mode
OPT-TAB -> switch tabs

Finder
CMD-SFT-N -> create new dir
CMD-O -> open directory selected
CMD-up -> move one directory up
CMD-Backspace -> delete file(s)

[update: I've included a screenshot...blogmate is just fantastic!]

Posted in Uncategorized | Tagged , , | Leave a comment

EnumHelper

EnumHelper is a utility class that I use quite a lot to map a string value to an Enum.

So instead of:
static StoreLocation GetStoreLocation()
{
var storeLocation = AppSettings.ServiceHuis_StoreLocation;
return !Enum.IsDefined(typeof(StoreLocation), storeLocation)
? StoreLocation.LocalMachine
: (StoreLocation)Enum.Parse(typeof(StoreLocation), storeLocation);
}

Moving the Enum lookup logic to a separate helper class:
public class EnumHelper
{
public static T UseIfNotFoundFor(string key, T @default)
{
return !Enum.IsDefined(typeof(T), key) ? @default : (T)Enum.Parse(typeof(T), key);
}
}

We can write:
static StoreLocation GetStoreLocation()
{
return EnumHelper.UseIfNotFoundFor(AppSettings.ServiceHuis_StoreLocation, StoreLocation.LocalMachine);
}

Much, much cleaner!

Posted in Uncategorized | Tagged , , , | Leave a comment

Refactoring the SCRUM

We have issues with preventing tasks being added to our todo queue. Sometimes it’s done explicit by adding items to the board without consulting the SCRUM master, but most of the time some team member receives a direct request be it by eamail, or worse, in person.

Why is this bad? Well, if you don’t finish your iterations on time these interruptions may have something to do with it ;-)

This week the program manager of our other team gave me quite the insight. During our SCRUM everybody informs the others what they have been up to / are going to do. Most of the time these activities would not be or get onto the board!

So how can you manage workload by the board when most of the activity is not on it?! Nothing too complicated here, but it means that you can ask anybody who is enlarging the scope of the iteration “But hey, is that actually on the board?”.

If not, it should be added to the board only if something else is removed. If it is still added you need to communicate that the consequence is that your estimated completion date moves further in time and thus other features will not be completed.

Posted in Uncategorized | Leave a comment

Automatic deployment & smoke testing

Recently we have made some substantial improvements in our development process. Yesterday I spent the most of the day working (pairing of course) on our CI setup. We already had a working build, but we lacked (big time) in auto deployment. Our auto deployments are scheduled at 03:00 in the morning but can be triggered easily from the Teamcity administration pages.

We have taken a bit different route in our deployment strategy than you would normaly expect. First we grab the artifacts (7zips) generated from the build and copy those to our test environment. We then launch a scheduled job on the test server using psexec that handles the instalation of (in this case) our web application.
Having a job on the test server that controls the instalation is quite different approach as you would normally do this from Teamcity. We couldn’t do this due to stability issues with psexec.

The downside of having the testserver control the deployment is lack of control on the buildserver. How do you know when the deployment has been completed? It’s actually very easy to do (with Teamcity): we have the job on the test server launch a buildstep at the Teamcity server that launches a smoke test to verify if the deployment was succesful.

One thing we have not figured out (yet) is how to integrate the logs generated during instalation on the test server into teamcity. Ideally you’d have Teamcity control the whole process but having the test server ask the build server for a smoke test is quite elegantly. You could say that we have decoupled the build server with the instalation of the product.

We have all instalation steps scripted in the good old cmd files. Next week we’ll probably invest some time exploring powershell as it also provides some nice hooks for running the smoke test assemblies written in .Net easily.

Posted in Uncategorized | Leave a comment