I really hate Experts Exchange - I'm not even going to provide a link to them because I don't want to help their page rank. Please do not sign up for this site. They take content normally available through other (free and hassle-free and pester-free) channels and hold it hostage so they can get your personal information and sell you ads. They have a right to do it. I have a right to hate it.

I created a javascript link that I use for tech searches that will pass the "-site:experts-exchange.com" parameter so I can prevent their hijacked content from popping up in my search results. If you want that link just drag this link Search Google (no EE) to your browser toolbar to use it too.

In work, or even life in general, you don’t meet many people that you are better off having known. My uncle collectively referred to these people in general as “the good guys”. Well Joe is one of the good guys. Thanks, Joe, for everything you do.

Pubb just posted this tweet “in your c# code: this. or no this.? why?” and my reply was too long for Twitter so I’ll post it here.

The “this” keyword refers to the current instance of the class. When a variables in the local scope have different names than the instance fields the “this” keyword can be used to differentiate an instance field from a variable (or input parameter) in the local scope. If an input parameter has the same name as the instance field then you are required to use the “this” keyword to access the instance field.

Some developers prefer to use a prefix on instance fields such as an underscore “” or “m” to differentiate them from other variables. In this case I think the use of “this” is redundant and should be omitted.

I prefer to follow the .NET Design Guidelines Field Usage Guidelines which states “Do not apply a prefix to field names or static field names” so I don’t have “” or “m” prefixes on my instance fields. If I am accessing a field from other members I try to keep those members short enough so that you can clearly see the definitions of all variables/parameters without scrolling which makes it very easy to determine what is a local variable or input parameter and what is an instance field. In this case I only wind up using “this” in my constructors if the input parameters to the constructor have the same name as the instance field.

I have been digging through log files to try to find information about errors that I’m troubleshooting. I start out with some information that I’m searching the log files for. For example:

    # find the troublesome user
    $occurrences = ls -r -i *.log | select-string 'Dan'

Great. Now I have an array of Microsoft.PowerShell.Commands.MatchInfo objects in my $occurrences variable. The MatchInfo has the following members (some members removed for clarity):

    TypeName: Microsoft.PowerShell.Commands.MatchInfo

    RelativePath   Method     System.String RelativePath(String directory)
    Filename       Property   System.String Filename {get;}
    IgnoreCase     Property   System.Boolean IgnoreCase {get;set;}
    Line           Property   System.String Line {get;set;}
    LineNumber     Property   System.Int32 LineNumber {get;set;}
    Path           Property   System.String Path {get;set;}
    Pattern        Property   System.String Pattern {get;set;}

Now I want to run through all the matches and take a peek at the 20 text lines above and below the match like this:

    # show the context around each match and pause 
    $occurrences | %{ (get-content $_.Path)[$($_.LineNumber - 20)..$($_.LineNumber + 20)]; pause; }

Pause is not a built-in command. I’m using the pause function described here Pause on PowerShell Team Blog

The pragmatic programmers wrote an article titled Software Entropy that discussed the concept of a “broken window” in software.

The gist of the article was that, when coding, there are things in the code that you know are not right and that you should fix them. If you don’t fix them it will lead to an overall perception that the quality of the software is not great but that state is acceptable. This perception will spread throughout the project and other developers will allow other quality issues to pass and eventually the total quality of the system will suffer. I believe that the authors highlight a very important human behavior here.

Notice that I didn’t say coder or developer behavior but I said human behavior. I believe that the observations are founded and that the behavior pertains to people as a whole. The reference to research on crime and urban decay support this belief. Suppose for a moment that this is true. If so, then that leads me to ask myself the question “Are there broken windows in teams?”

I think there are definitely broken windows in teams. What do I mean by that, you might be asking. Have you ever been on a team where someone wasn’t contributing to their full potential and everyone knew it? Have you ever been on a team where someone was extremely negative or corrosive and was creating a bad team chemistry? Have you ever been on a team where someone was arrogant and aggressive?

I think these are broken windows too. If you don’t do something about it then the total quality of your team will suffer and I believe this will surely affect the total quality of the solution too. If you have a cancerous person on your team you need to turn them around, isolate them, or send them packing.

I’ve been working on a project that is using a Model-View-Presenter pattern. I’ve noticed something in the view code that I want to write a quick post about: views that are way smarter than they should be.

The presenter represents the workflow or process that the user is working on. It encapsulates the state of a use case instance. It has the responsibility of responding to the user’s interaction. The view simply displays data and sends messages back to the presenter when the user interacts with an element in the view.

If you have code like this in your view:

// some button click event handler

presenter.DoSomething();

presenter.RefreshTheView();

then you have a bad smell. It should look like this:

// some button click event handler

presenter.DoSomething();

// presenter’s code

public void DoSomething()

{

// build a request from the view data

// do something

// refresh the view

this.RefreshTheView();

}

Unless you have a lot of formatting to do in the view, your view should be comprised of a lot of one line method calls back to the presenter (or preferably raised events). The presenter should tell the view “show this to the user” and, optionally, “action XYZ is not available”. The view should tell the presenter “the user did something”. I like to specify this as events on the view interface so the complete communication contract is documented in one spot – but that’s another post.

Hi, all. John and I took the blog down for a while since we weren’t doing much blogging at the time. We both despise blogs that stagnate and ours was becoming one so we decided to take it down for a while. A lot has happened since then.

The short story is that John and I used to work at a company called Inetium . It was there that we started working on HumanStuff as a concept or hobby company. In December John and I made HumanStuff a reality. We are providing consulting services in the Twin Cities. We still have plans for developing products as well but that will be secondary to consulting.

It is currently just the two of us. However, hiring is in our plan so we’ll keep you posted. I think the interview process will be sitting down and writing a simple application given a set of requirements (see “How to hire a juggler” in Peopleware ) but we’ll see.

I’ll be blogging about the experience of building the business, development, stuff we’re working on, etc. If you have tips on how to improve the blog please send me an e-mail at yourblogsucks (seriously – I have an address set up for that and am looking for feedback) at humanstuff dot com.

Cheers, Dan