markhneedham/blog huggingface dataset:
Auto complete with tab in DOS
Date: 2008-08-13 23:55:38

It's becoming quite a couple of weeks of learning for me around DOS and I have another tip that I just learnt today.

I always found it really frustrating when using the windows command prompt that I couldn't get Unix style tab auto completion. To navigate my way to a directory I would do the following:+++<table class="CodeRay" border="0">++++++<tbody>++++++<tr>++++++<td class="line_numbers" title="click to toggle" onclick="with (this.firstChild.style) { display = (display == '') ? 'none' : '' }">++++++<pre>+++1+++<tt>++++++</tt>+++2+++<tt>++++++</tt>+++3+++<tt>++++++</tt>+++4+++<tt>++++++</tt>+++5+++<tt>++++++</tt>+++6+++<tt>++++++</tt>+++7+++<tt>++++++</tt>+++~~~
</td>
+++<td class="code">++++++<pre ondblclick="with (this.style) { overflow = (overflow == 'auto' || overflow == '') ? 'visible' : 'auto' }">+++C:\>cd Downloads+++<tt>++++++</tt>++++++<tt>++++++</tt>+++C:\Downloads>cd nant-0.85+++<tt>++++++</tt>++++++<tt>++++++</tt>+++C:\Downloads\nant-0.85>cd bin+++<tt>++++++</tt>++++++<tt>++++++</tt>+++C:\Downloads\nant-0.85\bin>~~~
</td>
</tr>
</tbody></table>
It is very tedious as you might imagine. I would try placing a forward slash after each directory in the hope that it would allow me to scroll through the next directory down but to no avail.

Little did I know that in fact I needed to be using the backslash. The above can now be done in one line using Unix style tabbing auto completion:
+++<table class="CodeRay" border="0">++++++<tbody>++++++<tr>++++++<td class="line_numbers" title="click to toggle" onclick="with (this.firstChild.style) { display = (display == '') ? 'none' : '' }">++++++<pre>+++1+++<tt>++++++</tt>+++2+++<tt>++++++</tt>+++3+++<tt>++++++</tt>+++~~~
</td>
+++<td class="code">++++++<pre ondblclick="with (this.style) { overflow = (overflow == 'auto' || overflow == '') ? 'visible' : 'auto' }">+++C:\>cd Downloads\nant-0.85\bin+++<tt>++++++</tt>++++++<tt>++++++</tt>+++C:\Downloads\nant-0.85\bin>~~~
</td>
</tr>
</tbody></table>+++</pre>++++++</td>++++++</pre>++++++</td>++++++</tr>++++++</tbody>++++++</table>++++++</pre>++++++</td>++++++</pre>++++++</td>++++++</tr>++++++</tbody>++++++</table>+++
If Else statements in batch files
Date: 2008-08-13 22:27:40

I mentioned in a couple of http://www.markhneedham.com/blog/2008/08/12/getting-the-current-working-directory-from-dos-or-batch-file/[earlier] http://www.markhneedham.com/blog/2008/08/08/spaces-in-batch-scripts/[posts] that I've been doing quite a bit of work with batch files and the windows command line, and today I wanted to do an If Else statement in one of my scripts.

I thought it would be relatively simple, but after various searches and having read articles that suggested that there wasn't an ELSE construct in batch land I finally found a http://www.codeguru.com/forum/showthread.php?t=377124[forum post] which explained how to do it.

The script I'm working on takes in a working directory as one of the arguments and what I wanted to do was either set a variable to be the value passed in, or if the value passed in was '.' then to set it to the link:2008/08/12/getting-the-current-working-directory-from-dos-or-batch-file/[current working directory].+++<table class="CodeRay">++++++<tr>++++++<td class="line_numbers" title="click to toggle" onclick="with (this.firstChild.style) { display = (display == '') ? 'none' : '' }">++++++<pre>+++1+++<tt>++++++</tt>+++2+++<tt>++++++</tt>+++3+++<tt>++++++</tt>+++4+++<tt>++++++</tt>+++5+++<tt>++++++</tt>+++~~~</td>
  +++<td class="code">++++++<pre ondblclick="with (this.style) { overflow = (overflow == 'auto' || overflow == '') ? 'visible' : 'auto' }">+++IF &quot;%1&quot;==&quot;.&quot;  (+++<tt>++++++</tt>+++  set WORKING_DIRECTORY=%cd%+++<tt>++++++</tt>+++) ELSE (+++<tt>++++++</tt>+++  set WORKING_DIRECTORY=%1+++<tt>++++++</tt>+++)~~~</td>
</tr></table>

I played around with this a little bit and it does seem that the brackets need to be in that exact format otherwise it doesn't work at all. Even putting brackets around the IF part of the statement will stop the script from working as expected.

IF statements on their own are much easier to deal with. To check for an empty argument for example either of the following will work:

+++<table class="CodeRay">++++++<tr>++++++<td class="line_numbers" title="click to toggle" onclick="with (this.firstChild.style) { display = (display == '') ? 'none' : '' }">++++++<pre>+++1+++<tt>++++++</tt>+++2+++<tt>++++++</tt>+++3+++<tt>++++++</tt>+++~~~</td>
  +++<td class="code">++++++<pre ondblclick="with (this.style) { overflow = (overflow == 'auto' || overflow == '') ? 'visible' : 'auto' }">+++IF &quot;%1&quot;==&quot;&quot; GOTO usage+++<tt>++++++</tt>++++++<tt>++++++</tt>+++IF [%1]==[] GOTO usage~~~</td>
</tr></table>

It does all seem a bit fiddly and +++<a href="http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx">+++Powershell+++</a>+++ is probably the way forwards, but for now batch scripts it is!+++</pre>++++++</td>++++++</pre>++++++</td>++++++</tr>++++++</table>++++++</pre>++++++</td>++++++</pre>++++++</td>++++++</tr>++++++</table>+++
msbuild - Use OutputPath instead of OutDir
Date: 2008-08-14 19:54:03

We've been using msbuild to build our project files on my current project and http://www.floydprice.com/[a colleague] and I noticed some strange behaviour when trying to set the directory that the output should be built to.

The problem was whenever we tried to set the output directory (using OutDir) to somewhere where there was a space in the directory name it would just fail catastrophically. We spent ages searching for the command line documentation before finding it http://msdn.microsoft.com/en-us/library/bb629394.aspx[here].

According to this though:

"OutputPath: This property is typically specified in the project file and resembles OutDir. OutputPath has been deprecated and OutDir should be used instead whenever possible. "

We decided to try changing OutDir to OutputPath and it started working again! The code is simple, but for those wondering:+++<table class="CodeRay" border="0">++++++<tbody>++++++<tr>++++++<td class="line_numbers" title="click to toggle" onclick="with (this.firstChild.style) { display = (display == '') ? 'none' : '' }">++++++<pre>+++1+++<tt>++++++</tt>+++2+++<tt>++++++</tt>+++3+++<tt>++++++</tt>+++4+++<tt>++++++</tt>+++~~~
</td>
+++<td class="code">++++++<pre ondblclick="with (this.style) { overflow = (overflow == 'auto' || overflow == '') ? 'visible' : 'auto' }">++++++<exec program="\path\to\msbuild35">++++++<tt>++++++</tt>+++  +++<arg value="${projectfile}">++++++</arg>++++++<tt>++++++</tt>+++  +++<arg value="/p:OutputPath=${build.dir}\${project.name}\">++++++</arg>++++++<tt>++++++</tt>++++++</exec>+++~~~
</td>
</tr>
</tbody></table>
I can't decide whether the documentation is just wrong or if it's now a convention that you can't have spaces in your build output path. Surely the former?+++</pre>++++++</td>++++++</pre>++++++</td>++++++</tr>++++++</tbody>++++++</table>+++
What are your personal practices?
Date: 2008-12-02 21:18:54

I've been reviewing http://apprenticeship.oreilly.com/wiki[Apprenticeship Patterns] over the last week or so and one of the cool ideas I came across is that of creating a http://www.xpdeveloper.net/xpdwiki/Wiki.jsp?page=PersonalPracticesMap[Personal Practices Map].

The idea is that you draw up a list of your 10 most important practices for coding and design and draw out any relationships between them.

This is mine as of now:

image::{{<siteurl>}}/uploads/2008/12/personal-practices.jpg[personal-practices.jpg]

I wouldn't say I follow all of these all the time, but they are the practices that I try to follow whenever possible.

Why these?

* *Separation of concerns* - code is much easier to test and understand when everything is in the right place.
* *Keep behaviour with data* - again makes the code easier to understand but also makes it easier to change later on as the code is in nice cohesive units.
* *Intention revealing methods* - should be able to tell what the code does without having to go into the method to work it out. Makes browsing of code much quicker.
* +++<strong>+++Compose Method +++</strong>+++- the best way to make code more readable from my experience. Helps keep methods short and easy to follow.
* *Keep it simple* - don't do something clever when something simple solves the same problem. Easier said than done.
* *Avoid debugger* - the debugger is invaluable when tracing through 3rd party code but with our own code we should test it well enough that we don't need to use the debugger often. Ideas like the http://www.markhneedham.com/blog/2008/11/21/saff-squeeze-first-thoughts/[Saff Squeeze] can help achieve this.
* *Short feedback loops* - keeping the steps as small as possible whatever we are doing is vital for making progress I've found. Every time I try to be clever and do two things in one step it ends up taking much more time than taking small steps would have done.
* *Always test first* - I wrote last week about the http://www.markhneedham.com/blog/2008/11/28/tdd-suffering-from-testing-last/[pain of testing last] and writing code without having a test to verify whether what you've done actually works is something I find very difficult. Code without tests to tell us whether it actually does what we want it to is a disaster waiting to happen in my book.
* *Understand how it fits together* - Understanding how different parts of a design fit together is important for knowing how to solve any problems that pop up and also useful for understanding the big picture and why certain decisions were made.
* *Learning by teaching* - I've found this is the most effective method for knowing whether you truly understand something or not. Having to explain it to someone else requires you to not only understand something but be able to articulate it in a way that someone else can understand.
jQuery Validation & Firefox Refresh Behaviour
Date: 2008-12-02 22:54:52

We've been working quite a bit with http://jquery.com/[jQuery] and cross browser compatibility and one of the interesting differences we came across today was the behaviour of Firefox and Internet Explorer when it comes to refreshing a page.

When you press refresh in Internet Explorer the page gets refreshed to the state that it was in when you first loaded the URL, meaning that the state of the data in forms is returned to its original state.

Doing the same in Firefox doesn't have the same behaviour - the page refreshes but it keeps the most recent data that was entered into the form. In theory this is quite nice behaviour because it means if you accidentally hit refresh it keeps all your data.

For us it was quite annoying as we had hooked up a http://docs.jquery.com/Plugins/Validation[validator] and some other custom code which declared certain parts of the page invalid if any data had changed from what was on the page when it first loaded.

The way we got around the problem was to fire the validation events on jQuery's document ready as well as firing them on the change events for each of the form elements.

[source,javascript]
----

$(document).ready(function(){
   // validation code here as well as on change events for form elements
 });
----

Although it does mean that we are calling the validation in more places it has helped us to get around the problem.
Testing: What is a defect?
Date: 2008-12-18 22:34:48

One of the key ideas that I have learnt from my readings of http://www.markhneedham.com/blog/2008/11/19/the-toyota-way-book-review/[The Toyota Way] and http://www.markhneedham.com/blog/2008/12/09/taiichi-ohnos-workplace-management-book-review/[Taaichi Ohno's Workplace Management] is that we should *strive not to pass defects through the system to the next process*, which you should consider to be your customer.

As a developer the next process for each story is the testing phase where the testers will (amongst other things) run through the acceptance criteria and then do some exploratory testing for scenarios which weren't explicitly part of the acceptance criteria.

The question is how far should we go down this route and what exactly is a defect using this terminology - if a tester finds a bug which was listed in the acceptance criteria then I think it's reasonable enough to suggest that the developer has moved a defect onto the next stage.

But what about if that bug only appears on one particular browser and that's one that the developer didn't test against but the tester did. Clearly automating tests against different browsers can help solve this problem but there are still some types of tests (particularly ones requiring visual verification) where it's much more grey.

We want developers to write code with as few defects as possible but at the end of the day testers are much better at using software in ways that is likely to expose defects that developers wouldn't even think about and I think this is definitely a good thing.

My current thinking around this area is that a *defect is something which was covered by the acceptance criteria or something which has been previously exposed by exploratory testing and reappears*.

Anything else is a normal part of the process.
C# lambdas: How much context should you need?
Date: 2008-12-27 23:15:31

I had an interesting discussion with a colleague last week about the names that we give to variables inside lambda expressions which got me thinking about the context that we should need to hold when reading code like this.

The particular discussion was around an example like this:

[source,csharp]
----

public class Foo
{
    private String bar;
    private String baz;

    public Foo(String bar, String baz)
    {
        this.bar = bar;
        this.baz = baz;
    }

    public override string ToString()
    {
        return string.Format("{0} - {1}", bar, baz);
    }

}
----

[source,csharp]
----

var oneFoo = new Foo("bar", "baz");
var anotherFoo = new Foo("otherBar", "otherBaz");

new List<Foo> {oneFoo, anotherFoo}.Select(foo => foo.ToString().ToUpper()).ForEach(Console.WriteLine);
----

I suggested that we could just replace the 'foo' with 'x' since it was obvious that the context we were talking about was applying a function on every item in the collection.

My colleague correctly pointed out that by naming the variable 'x' anyone reading the code would need to read more code to understand that x was actually referring to every 'Foo' in the collection. In addition naming the variable 'x' is quite lazy and is maybe equally bad as naming normal variables x,y and z (unless they're loop indexes) since it is completely non descriptive.

The only real argument I can think of for having it as 'x' is that it makes the code a bit more concise and for this particular example I had to change the name of my first Foo to be 'oneFoo' so that I could use the variable name 'foo' inside the block since other variables in the same method are accessible from the closure.

I'm not sure what the good practice is in this area. I've done a little bit of work with Ruby closures/blocks and the convention there seemed to be that using single letter variables for blocks was fine.

In this case the extra context wouldn't be that great anyway but I think trying to keep the necessary context that someone needs to remember as small as possible seems to be a reasonable rule to follow.
Code for positive data values not negative
Date: 2008-12-11 06:48:42

While reading Pat Kua's latest post about how http://www.thekua.com/atwork/2008/12/coding-styles-leads-to-or-prevents-certain-classes-of-bugs/[coding a certain way can help you avoid certain classes of bugs] I was reminded of a technique taught to me by a colleague with regards to writing functions/methods.

The idea is that it is more effective to *code for positive data values rather than trying to work out all the possible negative combinations*, since there are likely to be cases which we hadn't considered if we do the latter.

For example, given the following method outline:

[source,java]
----

public void someMethod(int someValue) {
		
}
----

We might know that this method should only be allowed to take in non zero values. Therefore it makes more sense to code for this knowledge than to infer which values are not allowed.

The following code snippet...

[source,java]
----

public void someMethod(int someValue) {
	if(someValue != 0) {
		// throw exception
	}		
	// someOtherMethod();
}
----

...would therefore be preferable to this code snippet...
[source,java]
----

public void someMethod(int someValue) {
	if(someValue < 0) {
		// throw exception
	}		
	// someOtherMethod();
}
----

...since in the latter we are making the assumption that less than 0 is invalid whereas the actual requirement was for non 0 values to be invalid.

I know this is a highly contrived example but in theory this approach should prevent unexpected behaviour in our functions.

I have been following this approach since I was shown it and my first thoughts are that it leads to code which is *more expressive and easier to write* since we are working with what we know rather than trying to infer what we don't know.

I think that following a test driven approach would eventually lead to us writing code similar to this anyway, but it's an interesting idea to keep in mind.
Internal/External Domain Models
Date: 2008-12-28 00:19:13

One of the underlying characteristic of most of the projects I have worked on is that we have defined our own domain model.

On my current project due to the fact that most of the logic in the system is being handled through other services we decided to use http://hotmail.com/[WCF] messages as the domain model, meaning that our domain model is being defined externally by the team defining the message contracts.

== Internal Domain Model

This is the approach I have seen on my previous projects and if our system does have some level of business logic/behaviour in then it is the approach we want to take if we are following a domain driven approach.

We can then make use of an http://moffdub.wordpress.com/2008/09/21/anatomy-of-an-anti-corruption-layer-part-1/[anti corruption] http://www.domaindrivendesign.org/practitioner_reports/peng_sam_2007_06.pdf[layer] to ensure that incoming data from other systems is converted into a format that had meaning in our domain before we made use of it.

If we don't have sufficient behaviour then the anti corruption layer will start to become a burden for the benefit it provides and we might be better off not defining our own domain model.

== External Domain Model

The reason you might decide to take the approach we have chosen is if the domain in our system is the same as that defined elsewhere, in which case the mapping code would not be adding much value.

The problem with this approach is that we don't have control over the messages and when changes are made to it our code breaks all over the place. I guess one way to try and overcome this problem would be to use http://iansrobinson.com/2008/03/22/consumer-driven-contracts-a-retrospective/[consumer driven contracts].

An additional problem is that it is quite difficult to change the domain when we learn new information since this would require changing the message definitions which are being done by another team. The domain model we have therefore seems less expressive than ones on other projects I've worked on and I don't think we achieve the http://domaindrivendesign.org/discussion/messageboardarchive/UbiquitousLanguage.html[ubiquitous language] as much although certainly the domain terms exist in the code.

== Overall

Both of these approaches have their merits and each may be appropriate given the right situation.

From my experience the majority of the time we will want to build our own domain model of rich objects. I actually think coding is much more fun when you have your own domain model.

I've started to come to the conclusion, while writing this, that if your domain is defined as message contracts then maybe it's not Domain Driven Design at all, perhaps it's more about SOA with a Ubiquitous language.

It does feel to me like some of the aspects of DDD are present though, just not all of them.
TDD: Mock expectations in Setup
Date: 2008-12-19 20:57:23

One of the ideas that I mentioned in a recent post about what I consider to be a http://www.markhneedham.com/blog/2008/12/04/what-make-a-good-unit-test/[good unit test] was the ideas that we shouldn't necessarily consider the http://en.wikipedia.org/wiki/Don%27t_repeat_yourself[DRY] (Don't Repeat Yourself) principle to be our number one driver.

I consider putting mock expectations in the setup methods of our tests to be one of those occasions where we shouldn't obey this principle and I thought this would be fairly unanimously agreed upon but http://twitter.com/markhneedham/status/1050794791[putting the question to the Twittersphere] led to http://twitter.com/the_chrismo/status/1050828782[mixed] http://twitter.com/tirsen/status/1050872945[opinions].

== The case for expectations in setup

The argument for putting expectations in the setup method is that it helps *remove duplication and helps us to fail more quickly*.

This would certainly be the case if, for example, we instantiated our object under test in the setup method and there were some expectations on its dependencies on creation.

== The case against expectations in setup

The reason I'm so against putting expectations in setup methods derives from the pain of trying to debug http://www.nmock.org/[NMock] error messages when we put expectations and stubs in the setup method on a project I worked on about a year ago.

The number of times we were caught out by a failure which seemed 'impossible' from looking at the failing test was ridiculous.

After that experience we made sure that it was always obvious which expectations  belonged to which test by inlining them and taking the duplication hit.

I believe a lot of the value of tests comes from the way that they fail, and if we can write tests in a way that the *failure message and subsequent fix are really obvious* then we are going the right way.

== My current approach

My current approach to try and get the best of both worlds is to follow the approach http://fragmental.tw[Phil] describes in his post on http://fragmental.tw/2008/07/02/domain-driven-tests/[Domain Driven Tests].

If we have repeated expectations across different tests then I now try to extract those into an appropriately named methods which can be called from each test.

[source,csharp]
----


[Test]
public void ShouldDoSomething()
{
	ExpectServiceToReturnSomeValue();
	
	// rest
	// of
	// test
}

private void ExpectServiceToReturnSomeValue()
{
	// code describing expectations
}
----

This creates a little bit of duplication in that we have to call this method individually in each test which uses it but I think it makes the test more readable and easier to debug.

I'm still not sure what I consider the best way to name these types of methods - Phil uses a combination of a comment and method name to create readable tests but I'm keen to try and have the intent completely described by a method name if possible.