Try-Catch-FAIL

Stack Overflow Careers

matt.nospam@nospam.trycatchfail.com (Matt) — Thu, 05 Nov 2009 03:13:14 -1300

Joel just announced the launch of Stack Overflow Careers. Like most things Joel, this seems to be built around his idea of how the world should be, which is actually pretty cool, since in his world we’d all be treated like super stars. I do however take issue with one of his statements:

Instead of submitting a resume, you’ll fill out a CV, which links back to your Stack Overflow account, so that you can demonstrate your reputation in the community and show us all how smart you really are. To a hiring manager, the fact that you took the time to help a fellow programmer with a detailed answer in some obscure corner of programming knowledge, and demonstrated mastery, is a lot more relevant than the Latin Club you joined in school.

Maybe I’m wrong, but I actually disagree. I don’t think having an uber Stack Overflow reputation means that you’re a great catch for a potential employer. In fact, I think it may mean the opposite. Along the same lines, I don’t think not having 50 bajillion points on Stack Overflow means you are not knowledgable and skilled.

Why do I say these things? Well, the day consists of 24 hours. Let’s assume you sleep for 8 of those (I know that’s probably on the high side for most of us). Let’s assume preparing for and commuting to/from work eats up another 2 hours a day on average. We’re down to 14 hours. Let’s assume we don’t work for all of that, let’s say we spend 4 hours doing things outside of work. That leaves 10 hours a day. Let’s say I don’t work much overtime, so my employer gets 9 of those hours. That leaves me with one hour a day. Exactly when am I going to fit in time to read and answer 50,000 questions on Stack Overflow to rack up some serious reputation? I don’t think people are doing it in the “free time” on Saturday and Sunday. Are they doing so on the clock for their employers? I bet most of them are. While I agree that participating in Stack Overflow can be a good thing, I see people that spend entirely too much time on there. If I was their employer, I’d be cutting their pay.

If I’m an employer, I’m paying people to add value to the business, not to chit-chat with their peers. If I see a resume that lists a ridiculously high Stack Overflow reputation, I’m throwing that resume in the trash, because I’m pretty sure that person is going to spend more time on Stack Overflow than on doing real work.

Let’s look at someone else (me). I don’t spend much time on Stack Overflow at all. I lurk on quite a few mailing lists and forums, I follow several good blogs, and I read any spare chance I get, but I don’t participate much. If I can’t find an answer to a problem through other channels (such as newsgroups, forums, and mailing lists), I might post a question or discussion, but that’s about it. I don’t spend a lot of time participating because I’m too busy doing real work. Simply put, while I’d love to participate, I don’t have time. I’m too busy adding value to our products.

The same goes for Twitter and blogs. I actually know of several cases where someone was hired partly because they had a lot of followers either on their blog or on their Twitter account. If I see someone that’s hyper-active on either Twitter or their blog, I’m going to have the exact opposite reaction.

Thoughts? Am I being totally selfish to use Stack Overflow (and other sites) in a mostly read-only manner? How exactly am I a worse dev because I don’t spend time on Stack Overflow grinding out reputation points?

Fun little ASP.NET MVC bug

matt.nospam@nospam.trycatchfail.com (Matt) — Thu, 29 Oct 2009 05:34:52 -1300

I have a master page that serves as a template for a few related pages. Both the master page and the views that use it are strongly typed, and they all use the same view model data type. The declarations look like this:

<%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage<SearchDataModel>" MasterPageFile="~/Views/Shared/InSpire.Master" %>
...

<%@ Page Language="C#" MasterPageFile="Search.Master" Inherits="System.Web.Mvc.ViewPage<SearchDataModel>" %>
...

Access the model works just fine on the views, but trying to access properties of the model from the master page results in this error message:

CS1061: 'object' does not contain a definition for 'Query' and no extension method 'Query' accepting a first argument of type 'object' could be found.

Note the part in bold: it thinks my model is of type object! This is despite the fact that I told it the type when I declared the page. If I first cast the Model property on the master page to the view model type, it works fine. Anyone know what’s going on?

An auto-hiding menu bar with jQuery

matt.nospam@nospam.trycatchfail.com (Matt) — Thu, 29 Oct 2009 04:52:16 -1300

What do you do with links/buttons/actions that are likely to be infrequently used, but should still be available to users anywhere in the system? That’s the question I had to answer for the new InSpire search engine we’re working on at my day job. The sort of links I am talking about are logout, preferences, help, and various admin commands (for administrators only). These actions are not really part of the application per se, they are more part of the basic application framework that needs to be available to the user. We didn’t want to take up valuable space in our UI with these things (plus we wanted to keep the UI as basic as possible), so where do you put these things?

I decided I would try an auto-hiding sliding menu. The behavior I wanted was identical to the Windows task bar when the Auto-hide the task bar option is selected. After a little jQuery and CSS magic, and some help from Jeff Robbin’s great article on an auto-hiding search box, I had a solution that works in IE 8, Firefox, and Chrome.

First, check out the demo. The menu bar is themed using jQuery UI, so if your app uses jQuery UI, you will get a consistent look-and-feel. Also note that my menu bar doesn’t suffer from the same bug that Jeff Robbin’s article does: when you mouse-over and mouse-out my menu bar very quickly a few times, it doesn’t get stuck in a show/hide loop. Let’s look at the code to see why. First, the markup and CSS:

<style type="text/css">
#siteMenuBar
{
    position: fixed;
    top: 0px;
    left: 0px;
    width: 100%;
    height: 30px;
    margin-top: -27px;
}

#siteMenuBar > #menuContainer
{
    margin-left: auto;
    margin-right: auto;
    width: 100%;
    height: 25px;
    padding-top: 5px;
}

#siteMenuBar ul
{
    float: right;
    list-style-type: none;
    margin: 0;
    padding: 0;
    font-size: 0.9em;
}

#siteMenuBar li
{
    display: inline-block;
    margin: 0;
    padding: 0 5px 0 5px;
    margin-right: 10px;
}

#siteMenuBar ul:first-child
{
    float: left;
    margin-left: 10px;
}
</style>
...
<div id="siteMenuBar" class="ui-widget">
    <div id="menuContainer" class="ui-widget-header">
        <ul>
            <li><a href="#">Administration</a></li>
            <li><a href="#">Design Guidelines</a></li>
            <li><a href="#">Other Link</a></li>
        </ul>
        <ul>
            <li><a href="#">Preferences?</a></li>
            <li><a href="#">Logout</a></li>
        </ul>
    </div>
</div>

The markup is pretty clean. There is an outer container for the menu, then an inner container for the actual menu. The inner container is probably not necessary, but having it allows you the opportunity to do some neat style nesting. The actual menu is implemented as two unordered lists. The CSS floats one of the menus to the left, and the other to the right, giving you two groups to add menu items to.

The styles are a little more complex. The outer container is giving a fixed position at the top of the window, then positioned mostly off screen with negative margin. This leaves a small handle visible that the user can mouse-over to show the menu. The inner container applies a little padding to the menus and could be used to make the menu bar appear to be less than 100% of the window width (though in this case it is allowed to fully fill the menu bar area). Next, the actual menus are styled and positioned. Note that both are initially floated to the right, but using the pseudo-selector first-child, we bump the first menu back to the left.

Now let’s look at the code:

var timeout = null;
var initialMargin = parseInt($("#siteMenuBar").css("margin-top"));

$("#siteMenuBar").hover(
    function() {
        if (timeout) {
            clearTimeout(timeout);
            timeout = null;
        }
        $(this).animate({ marginTop: 0 }, 'fast');
    },
    function() {
        var menuBar = $(this);
        timeout = setTimeout(function() {
            timeout = null;
            menuBar.animate({ marginTop: initialMargin }, 'slow');
        }, 1000);
    }
);

Note the timeout variable. This is key in fixing the bug that exists on auto-hiding search box. For flexibility, we also grab the top margin so that we can hide the menu back to its original state.

The real core of the technique is the jQuery hover handler. We supply two functions: one to execute when the mouse hovers over the menu bar, the other to handle mouse out. The first time the mouse over handler is executed, the timeout will be null, so it will immediately animate the menu bar, removing the negative margin and making it visible. On mouse out, the setTimeout function is used to schedule the menu to be hidden one second later. Note that I’m assigning the return of setTimeout to my timeout variable. This is what prevents the menu bar from ending up in a bounce-loop like the search box. It allows me to cancel the hide action. If the bar is scheduled to be hidden and the user moves the mouse back over the menu bar, the mouse over handler clears the timeout. Without that bit of logic, even if you move mouse back over the menu bar, the setTimeout function will hide the menu out from under the user, which can lead to that funky show/hide cycle.

So, there you have it: a simple, clean auto-hide menu with jQuery. This could easily be encapsulated in a jQuery plug-in for easy re-use (not really needed in my case though since the master page is responsible for rendering it). Anyway, let me know if you have any suggestions!

A simple WCF host application

matt.nospam@nospam.trycatchfail.com (Matt) — Tue, 27 Oct 2009 06:59:58 -1300

I’ve been struggling with getting some of our backend components to play nice over WCF for the past couple of days. Our situation is a little more complex than most I think; our systems have dependencies on a variety of COM libraries, uses some Java APIs via IKVM.NET, and has differing capabilities as far as 64-bit goes.

What didn’t work

So I tried many things over the course of the last week. The following is basically a brain dump of every issue I ran in to as well as solutions if I ever found one:

IIS Hosting

The services we were trying to host were to be exposed over the NetTcpBinding, which works fine with IIS7+. I was able to get stripped-down “Hello, World!” prototype working quite quickly. What didn’t work was hosting our service in IIS7. As it turns out, there are apparently some major issues with using IKVM.NET in an ASP.NET environment, which is apparently how even NetTcpBinding services are hosted in IIS. Bummer. I never found a solution to this problem.

Sending large objects

Some of the objects we were transmitting over the wire were up to 10MB in size. Out of the box, WCF will explode with helpful messages about buffer sizes and such. This was easy to fix through configuration, just be sure you put the config on the right end of the channel (the server-side):

<system.serviceModel>
<services>
  <service ... >
    <endpoint binding="netTcpBinding" bindingConfiguration="MyCustomBinding" ...>
    </endpoint>
    ...
  </service>
</services>
...
<bindings>
  <netTcpBinding>
    <binding name="MyCustomBinding" ... maxBufferSize="20971520" maxReceivedMessageSize="20971520" >
      <readerQuotas maxArrayLength="10485760" maxStringContentLength="10485760" />
    </binding>
  </netTcpBinding>
</bindings>
</system.serviceModel>

Sending too many objects too quickly

We ran into some timeout issues when many threads tried to hammer the service with large amounts of data in parallel. By default, WCF communications will time out after 1:00. While that should be enough most of the time, it isn’t always the case. Fortunately again, it’s a pretty easy fix, just increase the timeout values. The timeout can be configured on the proxy client-side and on the server-side. You will probably need to change it on both sides (I did).

IDisposawhat?

It’s well-known that WCF proxies are in fact broken. See my previous article about how we created a better base class for our proxies.

Port Sharing

If the service you are trying to expose over WCF implements multiple contracts, you will need to expose multiple endpoints. You probably don’t want to have each contract on a separate port, but by default, that’s what you will have to do, because you can’t have two listeners on the same port. Net.Tcp Port Sharing Service to the rescue! This Windows Service, installed along with the .NET Framework, enables your WCF NetTcpBinding endpoints share ports. After making sure the service is enabled (it is disabled by default), you can take advantage of it by setting the portSharingEnabled attribute to true on the binding configuration, like so:

<system.serviceModel>
    <services>
        <service ...>
            <endpoint binding="netTcpBinding" bindingConfiguration="MyCustomBinding" ...>
            </endpoint>
            ...
        </service>
    </services>
    ...
    <bindings>
        <netTcpBinding>
            <binding name="MyCustomBinding" portSharingEnabled="true" ...>
                ...
            </binding>
        </netTcpBinding>
    </bindings>
</system.serviceModel>

The Final Host

As I said, our services were not compatible with IIS hosting due to various COM issues as well as IKVM.NET dependencies. That left us with two options: self-host the services in a custom application, or create Windows Services to serve as hosts. We decided to go the self-host route so that deploying our services would remain dirt-simple (it doesn’t get much simpler than XCOPY). Below is a skeleton class that you can use to host a WCF service in a console application. Pressing Ctrl+C will shut the service down gracefully and exit:

class Program
{
    //Log4net logger
    private static readonly ILog mLogger = LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);

    private static readonly AutoResetEvent mStopFlag = new AutoResetEvent(false);

    static void Main(string[] args)
    {
        //When the user hits Ctrl+C, the server will be shut down. 
        Console.CancelKeyPress += delegate
                                    {
                                        mLogger.Info("Shutting down server thread.");
                                        mStopFlag.Set();
                                    };

        var serverThread = new Thread(ServerThread) {IsBackground = true};
        serverThread.Start();

        serverThread.Join();
    }

    private static void ServerThread()
    {
        //This will grab the WCF configuration from the app.config file.
        using (ServiceHost host = new ServiceHost(new MyService()))
        {
            host.Open();

            mLogger.Debug("Service is online and awaiting requests...");

            Console.WriteLine("running");
            mStopFlag.WaitOne();
        }

        Console.WriteLine("stopped");
    }
}

Suggestions

I confess to being a total WCF newb, so it’s quite likely that I’ve done something wrong. If you see any incorrect information or have suggestions for things we could do better, please let me know. :)

**UPDATE – 10/29/09**

There is actually a bug in the host application I presented. While it will allow the background thread to shut down gracefully, it will still cause the application to abort abnormally, which means any pending finalizers and things won’t be executed. To resolve the issue, use the following CancelKeyPress handler instead:

Console.CancelKeyPress += delegate(object sender, ConsoleCancelEventArgs cancelEventArgs)
                            {
                                mLogger.Info("Shutting down server thread.");
                                mStopFlag.Set();
                                //This is IMPORTANT.
                                cancelEventArgs.Cancel = true;
                            };

Thanks go to James for pointing this out.

Please stop over-using the var keyword

matt.nospam@nospam.trycatchfail.com (Matt) — Wed, 21 Oct 2009 05:21:05 -1300

I just watched an excellent presentation by Jimmy Bogard on UI testing with ASP.NET MVC. While I really enjoyed the presentation and got a lot of really good ideas for how to improve how I work with MVC, I saw something that I really did not like: lots of var keywords. Here’s an example (recreated from memory so it might not be exactly right) of one of the methods he showed during his presentation:

...

var id = UINameHelper.GetName(expression);

var func = expression.Compile();

var value = func(model);

...

What’s wrong with that code? Well, unless I know the API, which I don’t, I don’t know the types of the variables. I can make certain assumptions about their types (the first is probably a string, the next is presumably a Func<T1,T2>, the third I’m not sure about), but I don’t know for sure unless I inspect the code further. Sure, intellisense is going to help, but I don’t have intellisense when I’m watching a presentation or looking at a code sample over someone’s shoulder. I have the code, and that’s it. The code should be readable without an IDE. It should be just as clear when I’m using Notepad++ or looking at it on your blog as when I’m digging through it with VS.NET.

There are times when the var keyword can make code more readable. A great example is when working with complex generics:

//Less readable
Dictionary<int,Pair<Foo,Bar>> lookup = new Dictionary<int,Pair<Foo,Bar>>();

//More readable
var lookup = new Dictionary<int,Pair<Foo,Bar>>();

So, a request to all my fellow developers out there: please use the var keyword carefully. I don’t think it should ever be used when assigning a variable to a method’s return value. I think it should only be used when it actually *improves* readability of the code, and never when it takes away from it.

Thoughts? Is var the best thing since sliced bread or the worst thing since IE6? When do you think it’s ok to use var?

The long road to fixing delete behavior in liteGrid

matt.nospam@nospam.trycatchfail.com (Matt) — Mon, 19 Oct 2009 03:46:12 -1300

A lot has been going on with liteGrid recently. The application at my day job that necessitated its creation is nearing production, and numerous additional features are being implemented in support of finishing that app. One of the big things that recently came up was making sure delete operations worked when the grid was in “tree grid” mode (meaning the TreeGridModule was loaded). While liteGrid has supported deletes for some time, it didn’t work correctly with tree grids. When I was tasked with fixing this deficiency, I initially thought “this will be easy, I just need to remove the children when the parent is deleted!” As is often the case in software, this was a gross oversimplification of the issue.

Why so complex?

If the grid was static, yeah, it would be a simple matter of deleting children once a parent has been deleted. Unfortunately, the grid is no longer static. Users can add new rows (via RowAdditionModule) and now they can re-arrange rows and change the parent/child relationships (via DraggableRowsModule). Deletes in liteGrid have always been a synchronous operation, while everything else is asynchronous. Why is this bad? Well, think about it for a second. Let’s assume I have the following structure initially:

This is the structure the server knows about: I have 4 widgets that are not related. Now let’s say that I re-arrange things like so:

Let’s assume I haven’t saved yet. At this point, the client has a very different view of the relationships than the server does. The client knows that everything is now nested under Test 1 while the server still thinks everything is a singleton leaf. Under the old model, what happens when I click the delete button for Test 1? The server will remove Test 1, and that’s it. As far as it knows, Test 1 had no children. But the client knows that Test 1 had children and will assume that they’ve been deleted, too. See the problem?

Let’s consider another case. Say we start out with the parts nested as in the second figure, but flatten them out so that they are all singleton leaves as in the first diagram. Again, until we save, the server and client have very different views. If we delete Test 1 on the client, the server will also delete Test 2, 3, and 4, since it thinks those items are nested under Test 1.

The root of the problem is that deletes are synchronous while all other operations are batched.

The solution

Once the root problem is well-understood, fixing it was seemingly straight-forward: make deletes a batch operation just like adds, moves, and edits. Batching everything allows the server to update its state so that its view of the world matches the client before it starts nuking things. While this sounds easy, it was, in fact, not.

First, there were the expected problems with Internet Explorer. I won’t dive into too many details, suffice to say that Internet Explorer 8’s table rendering is absolute junk. I don’t know how, but they actually made it worse than it was in IE 7.

Ignoring the IE8 problems, I still had to do a fair amount of work to get the user experience that I wanted. Since deletes would be batched until the user clicked the Save button, I wanted deleted rows to be clearly visible, effectively disabled (meaning they couldn’t be edited or moved), and I wanted the delete operation to be undoable. This would have been fairly simple if not for the tree grid module, which makes everything more complex. HTML tables really aren’t well-suited for rendering nested sets like this.

Disabling the rows was a problem. I didn’t want the delete module to have to know about all the current and future modules that might have added behavior to the grid, so removing the behavior manually was not an option. Instead, I used jQuery’s clone method to create a copy of the deleted row and its children. The clones maintained the classes and data of the originals but none of the event handlers, effectively disabling them. I replaced the original rows with the clones and provided a button to undo the delete operation. When clicked, the rows are re-bound to their data items, which (thankfully) restores all the functionality added by other liteGrid modules. At the end of the day, I had a nice batch solution that was not much more complex than my original solution for handling deletes.

You can check out the latest demo online. Code as always is available on the SVN repository.

Improving jQuery’s Validation Plug-in

matt.nospam@nospam.trycatchfail.com (Matt) — Wed, 14 Oct 2009 08:24:12 -1300

One of the 50 or so tasks I’m juggling at my day job deals with coming up with UI standards for one of our applications. I’m trying to think through every common scenario we have, design how it should work from a UI stand point (both the perceived UI as well as the HTML markup and CSS), and create examples to illustrate the standards. One of the scenarios I thought of was forms and validation. Ugh. I have spent the better part of a day now fighting with the jQuery Validation plug-in. It is the defacto standard for validation in jQuery. While it is powerful, and I really like being able to specify validation rules by simply applying CSS classes, it leaves a lot to be desired in the area of flexibility.

What I wanted

Here’s what I wanted for our forms and validation: fluid width, labels for each element, and (hidden) labels for element validation messages when needed. If I didn’t want to display a validation message, I just wanted to be able to omit the label. I didn’t want to have to do a bunch of JavaScript config. I also wanted exact control over how the error labels were rendered. Sometimes I wanted error labels to have a special class or other styles. Basically, I wanted to be able to write zero JavaScript code to get a nicely-formatted, validated form that I had complete control over.

Out of the box, while it does allow you to use your own error labels, the Validation plug-in is very dumb in how it uses them. First, it strips all CSS classes from the labels when it unhides them. Very, very annoying. There does not seem to be a good way to override this behavior without resorting to major hacking (like I did below). Second, if you do specify a custom label, it will only use it for the first validator applied to an element. If you have multiple validators applied to a single element, it will still add a new label element for the second validator. I ran into this as soon as I tried to have a required E-mail field. Ugh.

The good news is that it is possible to get the simple layout I wanted with minimal JavaScript config. The bad news is that it was an incredible pain in the rear to get there and involved a lot of browsing through the Validation plug-in’s source code.

How I did it

One of the nice things about jQuery Validation is that you can specify defaults that will apply to all instances. So once I figured out how to get the behavior I wanted, it was easy to encapsulate it where the entire application would be able to leverage it easily. So what’s the solution? Fugliness.

First, you need to specify a showErrors callback. When specified, this is invoked and allows you to fully control the display of error messages. It receives two parameters, an errorMap which is useless, and an errorList that contains validation errors. My approach was to loop through the errorList, get the name of each element, look for a corresponding label element with class error, and unhide it. This allowed me to fully control validation messages via markup, and it made it easy to choose not to display a validation message at all. Yes, this does mean that I lost the ability to display a different error message for different validators (such as one when an E-mail field is blank versus when it has an invalid address), but I prefer to have a single validation message for each element anyway.

Unhiding the error label is only part of the solution. You also need to highlight the element that the error corresponds to. This can be achieved by using the optional highlight callback. In this callback, you can add the error class. Be warned, you must manually call your own callback from your showErrors callback, otherwise highlight and the corresponding unhighlight callbacks will never be invoked. This is the part that is fugly.

Here’s the full source code, which I wrapped in a .js file and included alongside the main jQuery Validation .js file. This insures consistent behavior everywhere we use the jQuery Validation plug-in in our project.

$.validator.setDefaults({
    showErrors: function(errorMap, errorList) {
        var validation = this;
        $(errorList).each(function() {
            var error = this;
            var errorLabel = $("label[for='" + error.element.name + "'].error");
            errorLabel.css("display", "inline-block");
            validation.settings.highlight(error.element);
        })

        for (var i = 0, elements = this.validElements(); elements[i]; i++) {
            validation.settings.unhighlight(elements[i], validation.settings.errorClass, validation.settings.validClass);
        }
    },
    highlight: function(element) {
        $(element).addClass("error");
    },
    unhighlight: function(element) {
        $(element).removeClass("error");
        $("label[for='" + element.name + "'].error").hide();
    }
});

This is the final product:

And the corresponding markup:

<fieldset>
    <legend>A simple comment form with submit validation and default messages</legend>
    <div class="wrapper">
        <p>
            <label for="name">
                Name:</label>
            <input type="text" id="name" name="name" size="25" class="required" minlength="2" />
            <label for="name" class="error">
                Please enter a valid name.</label>
        </p>
        <p>
            <label for="email">
                E-Mail:</label>
            <input type="text" id="email" name="email" size="25" class="required email" />
            <label for="email" class="error">
                Please enter a valid E-mail address.</label>
        </p>
        <p>
            <label for="url">
                URL:</label>
            <input type="text" id="url" name="url" size="25" class="url" value="" />
            <label for="url" class="error">
                Please enter a valid URL.</label>
        </p>
        <p>
            <label for="state">
                State:</label>
            <select name="state" id="state" class="required">
                <option></option>
                <option>Tennessee</option>
                <option>Georgia</option>
                <option>South Carolina</option>
            </select>
            <label for="state" class="error">
                Please select a state.</label>
        </p>
        <p>
            <label for="terms">&nbsp;</label>
            <input type="checkbox" name="terms" value="terms" class="required" />
            <label for="terms" class="checkbox">I have read and accept the terms.</label>
            <label for="terms" class="error">You must accept the terms.</label>
        </p>
        <p>
            <label for="comment" class="textarea">
                Your comment:</label><br />
            <textarea id="comment" name="comment" cols="22" class="required"></textarea>
        </p>
        <p>
            <input class="submit" type="submit" value="Submit" />
        </p>
    </div>
</fieldset>

It’s not perfect, but I’m happy with the markup, and I’m happy with the UI. Hopefully I didn’t miss something obvious with the Validation plug-in that would have saved me half a days work. If I did, feel free to tell me how stupid I am. :)

The additive nature of bad code

matt.nospam@nospam.trycatchfail.com (Matt) — Mon, 12 Oct 2009 03:06:09 -1300

It really shouldn’t be a surprise, but I have recently witnessed firsthand how a little bad code sprinkled here-and-there quickly adds up to a lot of BAD code that’s painful to work with. That’s the scenario we’re facing now with our ASP.NET MVC application. Our team conducts peer reviews for every bug/feature, but we’ve still built up a small mountain of technical debt that we’re going to have to pay sooner or later. Our once-clean code base has become complex and difficult to work with. Even simple changes are starting to take progressively longer to implement.

How did this happen? There are probably several reasons, but I think one cause is that we’re still too lax in our peer reviews. If we don’t see something that’s HOLY CRAP THAT’S BAD, we let it slide, even if we don’t really like the solution. At least, I think that’s how I’m contributing to the problem. Starting today though, I’m going to resolve to be a lot more strict on my reviews. If something doesn’t feel right, even if I can’t put my finger on it immediately, I’m going to spend the time to find a better solution. The alternative is what we’ve done: start with good code, then progressively keep adding a little bad code here and there until we’ve ended up with a big heaping mess of poorly-structured code.

liteGrid – now with draggable rows!

matt.nospam@nospam.trycatchfail.com (Matt) — Fri, 09 Oct 2009 05:14:59 -1300

I’ve just finished up the draggable rows module for liteGrid. You can check out the demo page here. The module supports the tree-grid module (but does not require it). It’s built using jQuery UI’s draggable and droppable behaviors. I’ve tested it on IE 8, Firefox 3.5, and Chrome, and it seems to work fine everywhere. If you find a bug, please report it.

As part of this change, I’ve altered the behavior of the tree-grid module. Prior to this release, it added it’s own column for the tree expander. As of this release, it (and the draggable rows module) requires that you define a “utils” column. Both the drag handle and the row expander will be added to this column. If the column isn’t defined, an error will be logged to the console, and both modules will abort initialization.

In other liteGrid news, I noticed that the resizable columns are no longer working Chrome. I will try to fix this ASAP. If anyone would like to tackle that bug, please feel free.

Product Review: Balsamiq Mockups for Desktop

matt.nospam@nospam.trycatchfail.com (Matt) — Sun, 04 Oct 2009 05:57:06 -1300

It seems like I’ve been doing a lot of user-experience (UX) design at my day job lately. It’s not an area I consider one of my core strengths. Up until recently, I would actually say it was a major weakness, but I was fortunate enough to take a HCI (human-computer interface) class while working on my masters degree. That class got me pointed in the right direction (I think). I still suck at matching colors and coming up with pretty graphics, but I like to think that I can usually come up with good ideas for how things should be laid out and what the user experience should be like.

One of the valuable practices that I picked up was using rough mockups to prototype the UX. When I say rough, I mean it. I’m talking about prototypes drawn with simple lines and boxes in MS Paint. Many people don’t even go that far and will instead stick to paper-and-pen. I’ve even read about design sessions where they literally use paper, glue, and odds-and-ends lying around the office to come up with new UIs. The benefit to taking such a low-quality approach to the prototypes is that it helps people focus on the interaction and experience instead of tripping over issues like button color and fonts.

While MS Paint works, and I’ve done quite a few mockups using it, making a mockup in Paint is not a fast process. It involves a lot of copy-and-paste, and a lot of try-this-didn’t-work-undo-it. Fortunately there are tools to help you build rough mockups. Today, I’ll be doing a review of one: Balsamiq Mockups.

About Balsamiq Mockups

Mockups is a tool for creating mockups with a pen-and-paper feel, but using a more productive drag-and-drop approach. There are a variety of versions available. There is a free (but limited) web version, a desktop edition, and plug-in versions for a variety of wiki and bug trackers. According to their site, the current version features over 75 controls, 150+ icons, and a slew of keyboard shortcuts, which I’m still trying to learn.

Impressions

I have been using the online version of Balsamiq Mockups for a few odd things over the last couple of months, but I only recently took the plunge and got the desktop version (thanks to Balsamiq giving me a license so that I could fully evaluate it!). Mockups is an Adobe AIR application, so not surprisingly, the web version and the desktop version feel almost identical. The bulk of the UI is across the top while the canvas occupies most of the remaining space below. In the desktop version, there are tabs across the bottom for each open mockup. Getting started is easy: simply drag a control onto the canvas, and you’re off! Controls like labels and text boxes that can hold values will immediately go into edit mode. Clicking on an existing control brings up a floating panel with fairly standard options: move to front, move to back, group/ungroup, etc.

For advanced users, there is also a quick-add box that allows you to type the name of a control and add it to the canvas. Once you have a good feel for what controls are available to you, you will probably find that this is faster than hunting for controls with your mouse.

Things I liked…

Overall, I was very pleased with Mockups. Building a prototype UI with it was significantly more efficient than my old method of sketching things out in MS Paint. I found that most of the controls that I wanted to use where built-in and flexible enough (for the most part) to support what I wanted to prototype. Unlike the web version, the desktop version supports multiple open documents via a tabbed interface, which is really helpful when you’re fleshing out multiple screens for an application and want to quickly switch between them.

One of the cool things about Mockups is how open and flexible Balsamiq is with its development. They issue new releases almost weekly (as can be seen here), and bugs, suggestions, and questions can be submitted easily through their Get Satisfaction portal. They also have a community-driven site for sharing mockups and new controls called Mockups To Go.

Another area where the openness of Mockups shines is the native file format. Your mockups are stored as XML and can easily be consumed by other applications. In fact, there are numerous 3rd party tools that you can use to help take your mockups to the next step, such as Napkee and a tool to convert from Mockups to Image Maps.

One other nice thing I noticed is that I can actually drag-and-drop files on Mockups to open them. Drag-and-drop works for both the native BMML files as well as XML exports from the web version of the tool.

Things I didn’t like…

First, and this is very nitpicky, I only counted 74 controls, not the 75 that are claimed (and yeah, I double-checked my tally twice). Maybe the 75th icon doesn’t show up under “All”? Fortunately the controls available via Mockups to Go more than makes up for the missing 75th control.

Probably the biggest annoyance I encountered while using Mockups was controls randomly shifting slightly when selected. Sometimes things appear to move by a few pixels even though they’re really still in the same place. When selected, sometimes controls would appear to jump down and to the right by one or two pixels. Tapping “left” to nudge it would cause it to bounce back up where it was before. I know it isn’t actually moving since it doesn’t register with Undo/Redo. NOTE: I didn’t notice it until just now, but this is actually a well-known bug, described by this issue. I hope it gets fixed soon, because it is very annoying.

Another random annoyance was the options panel. While it manages to stay out of the way most of the time, I did frequently find that its default placement was very much in the way. Especially when working in or near a corner of the canvas, the panel would seem to inevitable be right where I didn’t want it to be. While you can drag it out of the way, it seems like it could position itself a little more intelligently. I also question why the panel is needed at all. Why not make it a context-sensitive toolbar or “ribbon” instead? There seems to be plenty of free space available in the existing toolbar at the top of the application.

Another thing I noticed was that I sometimes received “file exists” warnings when saving a mockup even when the file actually didn’t exist yet. Apparently mockups does not pay attention to the file extension, so trying to save “Mockup.bmml” into a folder that contains “Mockup.xml” will cause these incorrect warnings to occur.

Suggestions

After making over a dozen different mockups, I have come up with a few things I’d like to see. First, I’d really like to see some sort of toolbar or ribbon-like interface instead of the floating control properties panel. Second, creating a tab for a new mockup can currently be accomplished by right-clicking on an existing tab and selecting the appropriate option, but I’d love to see a Firefox-like “+” button for adding a new tab with a single click. Also related to the tabs, they currently order themselves alphabetically, but this isn’t always the way I want to order my open documents. Being able to reorder them would be a nice, simple addition.

A final suggestion: consider lowering the price. At $79, it’s too high for my impulse-buy reflex. If it was priced at $30, for example, I probably would have bought it without spending more than a few minutes playing with the web version. As it is though, $79 isn’t expensive, but it means that I have to think a little harder before buying it.

Final Thoughts

I still haven’t decided if Mockups is for me. There are alternatives, such as Microsoft Sketchflow, and I need to spend time playing with those to decide which tool is really the best fit for me. I do strongly recommend that anyone needing to do UI development consider some sort of tool for doing quick mockups, and Balsamiq Mockups is definitely an option to consider.