• Phil Haack’s Announcement
• Scott Guthrie’s Announcement

Again, Microsoft is going in the the right direction. I like the support for dynamic views. UIs - especially present-day, well-built UIs - tend to be very dynamic with the information displayed on the screen.

I Love Razor

The new preview of MVC 3 includes support for the Razor View Engine. Finally! Something new from Microsoft that doesn’t completely suck! Everything I look at here, I completely love. Bye, bye, bee sting (that’s <%=, in case you were wondering).

I Hate Razor

I really wish that MS wouldn’t have written their own. I saw two really good alternatives out there already: NHaml and Spark. Both have their own strong following, and both do so much work for you when putting together your views.

When MS jumped on the jQuery bandwagon, I really hoped that there was more to follow. So far, that hasn’t happened. Along with fully adopting an existing view engine, I wish MS would jump into bed with NHibernate, Ninject, and NUnit. But that’s not going to happen, so I should just get over it.

Once again, it comes down to options. The Rails community will tell you that options are bad. If you have to consider options, then you’re not working on the business problems. What data access layer are we using? That’s decided for you. What validation framework are we using? That’s decided for you. What IoC container are we using? Silly kid, dynamic languages don’t use IoC. Don’t get me wrong: you can still use Haml and Less, but those aren’t things that you have to worry about out of the gate.

At the end of the day, it comes down to MS. MS will do what MS wants to do, developer community be damned.

Today, I refactored this…

public bool CanUse(string id)
{
    bool rtn = true;
    for (int i = 0; i <= _innerArray.Count - 1; i++)
    {
        Medi cur = (Medi)_innerArray[i];
        if (cur.Id == id)
        {
            rtn = false;
            break;
        }
    }
    return rtn;
}

Into this…

public bool CanUse(string id)
{
    return _innerCollection.Any(x => x.Id == id) == false;
}

The code was completely undocumented, and there wasn’t a test project at all with the solution. It was pretty easy to tell what was going on, but this is production code that has been migrated from .NET 1.1 up to 3.5SP1. Lots of ArrayLists and loosely typed data sets.

So let’s take the opportunity to leave the code cleaner than when you found it.

[TestMethod]
public void Returns_False_If_Medi_Is_Already_In_List()
{
    var collection = new MediList();
    collection.AddToList("AAAAA", "1");
    var result = collection.CanUse("1");

    Assert.IsFalse(result);
}

[TestMethod]
public void Returns_True_If_Medi_Is_Not_In_List()
{
    var collection = new MediList();
    collection.AddToList("AAAAA", "1");
    var result = collection.CanUse("99");

    Assert.IsTrue(result);
}

Before we do any refactoring at all, write the unit tests. Make sure that the block of code is really doing what we think the block of code should be doing. Tests are green? Good. Refactor. Tests are still green? Great! Check in and move on to the next problem.

Software Application Lifecycle Management

Business Relationship Management

Process Management Leadership Organization

These are such big words, and it’s just too much. And it fully represents a big part of what’s wrong with enterprise applications.

Let’s suppose you write (to use my boss’ favorite example) insurance software. There are tons of regulations in this line of work. Your ability to be agile or even modestly flexible with your coding styles and standards are severely limited. And you should know that before you go into that line of work.

I work in a big enterprise, but I don’t write enterprise software. Most of the applications I work on are used by 20 or fewer employees. But they still want to apply all of the standards and methodology for the little one-off applications as the big ones.

And that’s wrong. Every developer sees it. You can’t apply the same rules to the little as you do for the the huge. Well you can, but…

Exactly.

A one-size-fits-all solution fits no one. Big projects are delayed no matter how much management is involved. Where I work, this means years of delays. (Does the presence of management cause delays? Discuss.) And little projects are small enough that anything beyond the basic source control documentation means that you spend more time documenting than doing.

I really like iterative development. So do my fellow programmers. As far as I can tell, so do our customers. They like the speed and responsiveness. They like seeing their application grow just as much as we like building it. I’m mostly certain that everyone likes iterative development except for management, especially because of the scope creep that, in my experience, comes along for the ride in iterative development. Scope creep messes up signed estimates and previously contracted delivery SLRs. Me? I like scope creep. It means that I’ve shown the customer they hadn’t thought of, and it should make the program more valuable.

So, anytime you hear the phrase, “Let’s lock down this database,” you should run. Run far, far away.

I’ve gotten really used to writing my controller constructors like this…

public SomeController(IAppContext appContext, IRepository repository) {
    _appContext = appContext;
    _repository = repository;
}

And that’s fine, I suppose. Honestly, though, I don’t really like it. Instead, I like how FubuMVC embraces the fact that its built with IoC in mind. Is it really easier to test a controller like this? Why not build a controller factory for testing purposes which populates a testing service factory with all of my mocks.

Then I could just say something like this…

public ActionResult Show(int id) {
    var person = ServiceFactory.Data
        .GetRepositoryFor<Person>()
        .Single(x => x.Id == id && x.Active);
    return View(person);
}

No need for a default constructor at all. The controller is that much simpler. Certainly worth a ponder.

On July 1, 2010, the single worst of my life took place. My best friend, Larry Hurt, passed away right before my eyes. I was most shocking, terrible thing that I have ever seen. I want that sight out of my mind. I want it gone. Now. Please, God, take this memory away from me. I have never known such pain.

I am starting to get over this pain, but it takes time. I have surrounded myself with friends and loved ones. I am making it back to work. I am able to focus on things besides my grief. And there are times, still today, three weeks later, that I still cry. I should not be ashamed to say it. Humans have an amazing capacity to feel and share emotion.

Larry was so many things to me, and I confided everything in him. He was my best friend, keeping many of my secrets. I must admit, I’ve shared things with him that I’ve never told another soul on this planet, including my bride. He was my father, when mine chooses not to be a part of my life. He was my spiritual mentor.

He taught me that there is so much beauty in this world. He taught me that there is beauty in the people around us. Larry taught me that we are all remarkable people; we all will leave an impact. Larry is still teaching me, even as I write this.

He also taught me that when we mourn, God mourns with us.

Of my biggest regrets, I never told Larry how I felt about him. Everyone I speak with says, “Jarrett, Larry knew.” I know he knew. But there’s a difference when you say it. In the four years that I knew him, the right moment for one person to say to another, “I love you,” never came up.

I miss you, Larry.