The ten commandments of development

I wrote these a long time ago for an internal project that was ramping up.  Now I’ve been placed on a new project and have revisited these once more.  I think they’re pretty good, considering I originally wrote them two years ago.  Number ten is the only new one of the list.  Enjoy.

  • Thou shalt always follow the Framework Design Guidelines in thine namings
    • Any sketchy names should be used to mock the namer relentlessly
  • Thou shall not wrap thy code in try/catch blocks unless absolutely necessary
    • Less debug code during development means less code thrown away as the design changes
    • Trust your debugger and your call stack during pre-release development
    • When you must catch for debugging, wrap and rethrow, preferably with a custom exception
    • Exception handling should be performed at the last responsible moment, not indiscriminately!
  • Thou shall not spill thine logging code indiscriminately
    • Logging without planning leads to lousy logging code
    • It might be possible we use a type of “event sourcing” to publish changes in application state which can be consumed by both the UI and a logger by leveraging domain events via Rx
    • Wait and find out where you actually need logging, rather than where you *think* you need it
    • Don’t use logs to help test your design; look into adding tracing wrapped in preprocessor directives for this purpose
  • Thine code shall be well documented, within and without
    • XML Comments shall be placed on all methods and properties, private, protected, internal and public
    • Regular comments shall be placed on all fields and all tricky algorithms
  • Thine types shall be sealed, unless thou planneth for extension
    • Not thinking of inheritance when designing your types is an abomination
  • Thou shalt encapsulate thy Arguments, Returns and Exceptions when thy method is complex
    • Rather than have an ever expanding number of Arguments, wrap arguments in a new type
    • Avoid out Arguments by returning a new type that encapsulates the result of the method
    • Create a custom Exception type which holds more information about the method call
    • Is a method complex or trivial? If you don’t know, its trivial.
  • Thou shalt not worship One Object To Encapsulate Them All
    • If an object representing a domain of functions gets too large, split the domain into logical parts
    • Composition over inheritance should always be your guide in these matters
  • Thou shalt always strive to keep it simple, stupid
    • Simplicity = maintainability
    • For example, forego massive, obscure and complex ORMs for Micro ORMs
  • Thou shalt write at least one Unit Test for every public method of thine classes
    • This should test the primary (most important) assertion of the method (i.e., its most important function)
    • Your documentation should say what your method does, your tests should validate these statements
  • Thou shalt write thy API asynchronous and asynchronous shall thine API be
    • You should be asynchronous by default, and only synchronous when it is determined that they should be.

You know what I like?

This.

 

Tools, options, environment, keyboard, use new shortcut in solution explorer, open folder in file explorer

ctrl-shift-o and you’re ready to go

Damn, that’s nice.

Accessing the DataContext within a ToolTip

Man, its dusty in here.

Anyhow, I’m always encountering this every once in a year, and it takes awhile to rediscover the solution, etc etc, so here it is.

(sorry, can’t look for a decent prettify WP addin right now)

<Border>
    <Border.ToolTip>    
        <ToolTip
            DataContext="{Binding Path=PlacementTarget.DataContext, RelativeSource={RelativeSource Self}}">
            <TextBlock Text="{Binding}"/>
        </ToolTip>
    </Border.ToolTip>
</Border>

This example is on a Border, but it could be on any control with a ToolTip. We’re simply transferring over the DataContext of the FrameworkElement that the ToolTip is placed on over to the ToolTip itself.

I’m still not sure why the hell this isn’t the friggen status quo. Sup with that? Sup?

If I get unlazy I’ll extend the ToolTip class to set that binding automatically from within code.

TFS 2010 Over VPN Woes?

On vacation, so I have a few seconds to post! 

WARNING:  Dirty hack ahead.

Here’s a little annoyance that’s been biting at my heels the past few days—how to connect to Team Foundation Server 2010 Source Control over a virtual private network (VPN).

I think it might be a common enough occurrence; people leave the office domain and still need to connect to source control.  So they fire up a VPN connection and try to access the server. 

In my case, I would experience timeouts.  Whether I tried to connect through Visual Studio, or to the “server/tfs/web” website, whatever I tried would simply hang until the operation times out.  I wasn’t able to locate any errors in the event log, in the firewall dropped packet log, or in IIS.

While attempting various solutions,  I stumbled upon a dirty hack which can help you if you’re suffering the same issue. 

What I did was I added a new binding to the Team Foundation Server for port 80.  I had to delete the default website in IIS first, since it was already bound to port 80; I could have changed its binding to something other than 80 or specified a domain, but its useless and so into the recycle bin it went.  I also didn’t change the default binding for TFS (port 8080) so I didn’t have to tell anybody to update their settings.

So, why did this work?

I.  Don’t.  Know.

That’s why (at this point) it’s a dirty hack.  I guess I could spend an hour or so tracing through the settings within the firewall and IIS to find exactly what is different between a website bound to port 80 and the rules set up for TFS, but I decided to post the hack up instead.

Hope this helped! 

Has automatic checkout stopped working for you in Visual Studio?

This has happened to me twice on my current project; the last time it was passed from me to two other people in the team like the common cold. 

Although I’m hoping to steer this blog from a “To do X perform these steps” snoozefest into a more meta-ish discussion of software development, I record the solution here for the benefit of super annoyed developers everywhere.

Problem:  Automatic checkout on edit in Visual Studio has stopped working.

Possible causes:  Visual Studio crashes; project files are corrupted in source control by these crashes.

Always check first:  Tools -> Options -> Source Control -> Environment -> Editing: -> Check out automatically

Ready?  Put on your grass skirt, grab your totem, snort some yopo and do the following:

  1. Check in everything
  2. Close visual studio
  3. Make sure every file is set to read only in the solution directory (set it on the root solution folder and configure it to propagate to children)
  4. Search for all files under the root projet directory *.user and *.vssscc and delete them (this might be overkill; one or the other may be the culprit but deleting both types won’t hurt you)
  5. Open VS and load the solution
  6. Check everything back out and then check everything back in

Some of these steps may be cargo-cultish, but the problem is so nebulous its not for us to fully understand the meaning, but to mindlessly repeat the rituals so the source control gods will once again be in their good graces.  Step 4 is definitely required; the others may be unnecessary.  I’d test it but I hate when this bug happens; its like a paper cut in between your fingers.  Not anything to stop you from functioning, but damnably annoying.

What CS departments don’t tell you…

… And what to do about it.

I'm giving a presentation today to graduate and other students at USC about software development.  I wrote a slideshow about it.  Like to see it?  Here it goes.

Does this compile?

Taking a momentary break from an internal beta…

Does this compile?

var foo = newFooType()

    {

        AnInt = 1,

        AnotherInt = 1,

        MyBar = bar,

    };

If you’re wondering what’s strange here, its the pointless last comma in the type initializer.

Apparently, the compiler doesn’t care. Which is a good thing, if you’re lazy. However, it could be an indication that you’ve forgotten something.

I’m voting its a bug in the compiler.

(Long after the fact update: Its not a bug. Its a common practice to allow the last comma in situations like this (delimited lists).  This has been done for a long time in order to make it easier for automated code generators.)

Warn before navigating away using jQuery

I have to relearn this every time I want to do it, so I record it here for my benefit.  You can stop reading now (unless you’re trying to do this yourself).

You’d think jQuery would have a nice little function/event you could hook into to handle this situation.  Unfortunately, as far as I can see (and with 1.2.6), jQuery doesn’t provide an obvious way to do this.  So if you’re here wondering how to do this using jQuery itself, you can stop reading now.

Now that we’ve gotten rid of the people who don’t care, lets get this done.

The Code

With the following html page snippet:

<span class="kwrd">&lt;</span><span class="html">div</span><span class="kwrd">&gt;</span>
    <span class="kwrd">&lt;</span><span class="html">textarea</span> <span class="attr">cols</span><span class="kwrd">="120"</span> <span class="attr">id</span><span class="kwrd">="editor"</span> <span class="attr">name</span><span class="kwrd">="editor"</span> <span class="attr">rows</span><span class="kwrd">="10"</span><span class="kwrd">&gt;&lt;/</span><span class="html">textarea</span><span class="kwrd">&gt;</span>
<span class="kwrd">&lt;/</span><span class="html">div</span><span class="kwrd">&gt;</span>
<span class="kwrd">&lt;</span><span class="html">button</span> <span class="attr">id</span><span class="kwrd">="subby"</span> <span class="attr">type</span><span class="kwrd">="submit"</span> <span class="attr">value</span><span class="kwrd">="Save"</span><span class="kwrd">&gt;</span>Save<span class="kwrd">&lt;/</span><span class="html">button</span><span class="kwrd">&gt;</span> 

The following script will warn users before browsing away:

&lt;script type=<span class="str">"text/javascript"</span>&gt;
    <span class="rem">// After our HTML has loaded...</span>
    $(document).ready(function() {
        <span class="rem">// disable the submit button until we have something to submit</span>
        $(<span class="str">"#subby"</span>).attr(<span class="str">"disabled"</span>, <span class="str">"disabled"</span>);
        <span class="rem">// when the user types in the editor...</span>
        $(<span class="str">"#editor"</span>).keydown(function() {
            <span class="rem">// enable the submit button</span>
            $(<span class="str">"#subby"</span>).attr(<span class="str">"disabled"</span>, <span class="str">""</span>);
            <span class="rem">// tell the browser to warn before navigating away</span>
            window.onbeforeunload = function() { <span class="kwrd">return</span> <span class="str">"Don't do it."</span>; };});
        <span class="rem">// when the submit button is clicked, disable the warning</span>
        $(<span class="str">"#subby"</span>).click(function() { window.onbeforeunload = <span class="kwrd">null</span>; });
        });
    });
&lt;/script&gt;

What’s going on here?

When the edit page loads, we don’t want the user to submit the exact same thing back to the server, so we disable the submit button.  Also, if nothing’s happened, we don’t want to bug the user about navigating away, so we don’t immediately set that warning.

If the user types in the textarea, we use this indication as a cheap and quick way to indicate that Changes Have Been Made.  Of course, they might be useless changes depending on the context; if you want to do some additional work to determine if a “real” change has been made, go for it.  Also note, this happens every time a keydown event fires in the textarea.  I’m not claiming its good javascript, I just claim it warns the user before losing changes.

So, when the textarea has changes, I enable the submit button (by removing its disabled attribute value), and set the window.onbeforeunload callback function.

Note, you can’t access this function via $(“window”), you have to access it directly.  I can’t tell you what that says about browser support; I can tell you that it works in gte IE7 and Chrome.  And that’s not bad.

This callback function must return a string.  This string is displayed in a warning dialog shown to the user prior to the browser leaving this particular page.

Lastly, when the submit button is clicked, we want to disable this warning lest the user get bugged before we post back to the server.  You can do this by setting the window.onbeforeunload callback function to null.

Caveats

Again, the keydown function I add to the textarea fires every time a key is pressed when the textarea has focus.  I’d fix that, but I’m struggling with posting this from my laptop.  I trust you’ll fix this issue.  Also, since you’re touching the window in javascript directly and not through the soothing jQuery API, you might have issues in some browsers.  I can confirm, agian, that it works fine in IE7 and Chrome. 

New XAML goodness in 4.0?

Was just scoping out the .NET 4.0 poster here when I zoomed in on core and saw…

new xaml goodness

 

 

Looks like there’s movement on making XAML more available to developers for serializing plain old CLR objects.  Unfortunately, my Google-fu is failing me; I can’t find any more information about what’s happening here…

Finally! Calculator is getting a well-needed update!

I present to you a first peek at… Calculator 2008!

Calculator 2.0!

(Yes, its a joke.  Picture ganked from this great article about ribbon UI at MSDN)