Speaking at Richmond Code Camp on NHibernate

On October 3rd, I encourage anyone who wants to learn about NHibernate to come to Richmond Code Camp. I will be giving a 100 level talk describing how to get started using it, and what it really is.

My initial idea is to create a fairly simple ASP.NET MVC application without persistence (use in memory Lists). And, in an hour, make it 100% persisted with transactions, lazy loading, etc. I am a little concerned it will be hard to teach NHibernate and get it done in an hour, but I am going to go for it. My goal is to touch on session factories, sessions, simple XML mapping, attribute mapping, inheritance relationships, associative relationships, criteria queries, HQL queries, and lazy loading. If I get through all that, I’ll throw in some custom types and maybe some fluent NHibernate since I have never used it but have wanted a reason to.

Any suggestions on things to show or things not to show?

PSDefaultVariablizer revisted

A couple of days ago, I had a random post about PSDefaultVariablizer because I thought the name was funny. Well, I did some pretty hardcore refactoring of the class, and am pretty happy with the outcome. Overall, I think it is 100x better. Check it out.

public class PSDefaultVariablizer<T> where T: class
{
    T innerValue;
    IList<Func<T>> defaultValues;
 
    public PSDefaultVariablizer(params Func<T>[] _defaultValues)
    {
        defaultValues = _defaultValues.ToList();
        defaultValues.Insert(0, () => this.innerValue);
    }
 
    public T Value
    {
        get
        {
            return defaultValues.Select(v => v.Invoke())
                .Where(v => v != null)
                .FirstOrDefault();
        }
        set
        {
            innerValue = value;
        }
    }
}
 
//I am using it in a cmdlet similar to this
[Cmdlet("Some", "Command")]
public class SomeCommand : PSCmdlet
{
    private PSDefaultVariablizer<string> someParam;
 
    public SomeCommand ()
    {
        someParam = new PSDefaultVariablizer<string>(() => (string)this.SessionState.PSVariable.GetValue("SomeParam", null));
    }
 
    [Parameter()]
    public string SomeParam
    {
        get
        {
            return someParam.Value;
        }
        set
        {
            someParam.Value = value;
        }
    }
}

Thought it was cool to use Lamba’s to eliminate an entire dependency. I should really call this DefaultVariablizer because it has no dependency to Powershell.

PSDefaultVariablizer – I didn’t know what else to name it!

public class PSDefaultVariablizer<T> where T: class
{
    string variableName;
    T innerValue;
    PSCmdlet cmdlet;
 
    public PSDefaultVariablizer(string _variableName, PSCmdlet _cmdlet)
        : this(_variableName, null, _cmdlet) { }
 
    public PSDefaultVariablizer(string _variableName, T _innerValue, PSCmdlet _cmdlet)
    {
        variableName = _variableName;
        innerValue = _innerValue;
        cmdlet = _cmdlet;
    }
 
    public T Value
    {
        get
        {
            if(innerValue != null)
            {
                return innerValue;
            }
            else
            {
                return (T)cmdlet.SessionState.PSVariable.GetValue(variableName, null);
            }
        }
        set
        {
            innerValue = value;
        }
    }
}

Here is the use case for the class. You have a parameter that a user can input, otherwise it attempts to use a value of a variable in the same scope (think how $ErrorActionPreference works). This class allows you to very simply reuse that functionality.

[Cmdlet("Some", "Command")]
public class SomeCommand : PSCmdlet
{
    private PSDefaultVariablizer<string> someParam;
 
    public SomeCommand ()
    {
        someParam = new PSDefaultVariablizer<string>("SomeParam", this);
    }
 
    [Parameter()]
    public string SomeParam
    {
        get
        {
            return someParam.Value;
        }
        set
        {
            someParam.Value = value;
        }
    }
}

And you would use it from Powershell with the following.

Some-Command -SomeParam 'hello'
#or
$SomeParam = 'hello'
Some-Command

Pretty simple really. I just posted it because I thought the name was hilarious, but I didn’t really know what else to call it.

Let me know if anyone knows of an easier way to this. Unfortunately, there aren’t too many people I can talk to about SnapIn development :)

Using Windows Live Writer to publish this post

I downloaded Windows Live Writer today and am using it to publish this post.

Why Live Writer and not the WordPress interface?  No real reason.  The nice thing about live writer is I get the benefits of using a desktop app instead of a web app.  It is faster, can work offline, and HTML editing is a bit easier (yes, I am a web developer but it is nice to work a layer above HTML sometimes). 

8-22-2009 11-17-08 AM

Some of the really cool things are it is pulling almost all my data from WordPress.  All my categories, tags, settings are here, which is nice. 

My only question is how is uploading this picture going to work?  If you are reading this, you already know whether it worked or not, unfortunately, I have no clue what is going to happen.

Don’t let developers sell themselves short

Good developers have a tendency to learn, which creates a problem. Everything they did yesterday, they want to rewrite to be better. They are NEVER content with their code! To make things even harder, most developers are pessimists and always make the current state of any application worse than it really is.

While these are actually great traits for their role, it can be easy to let developers sell themselves short and miss working on something great in favor of improving the old. Managers have to continually challenge them and make sure they are working on things that will help them achieve greatness.

How do you find the balance?

  • DO fix things that are broken.
  • DON’T sacrifice quality.
  • DO follow the boyscout rule. If you are making things a little better as you go along, you will keep the ship afloat.
  • DON’T rewrite things if you absolutely don’t have to, especially if they aren’t broken.
  • DO push developers to accomplish more than they think they can, while being realistic.
  • DON’T worry about scaling too far in advance. An application has to scale for a few months after launch, but resources are better suiting building things to entice customers, and therefore create a need to scale, instead of scaling before the need. (Just make sure you know when that need is hit)
  • DO eliminate all the waste and make sure your developers are truly working on the most important things.
  • DON’T wait for perfection. As Dharmesh says, if you aren’t a little embarrassed of the features you are developing, you waited too long to release it. The internet is too fast paced to wait a second.

In summary, make sure you are challenging your developers and pushing the envelope on the things they are working on. Developers have an insane desire to make something perfect, even when the business case may not always be there for it.