Tuesday, October 28, 2008

Touch Typing - i.e., eaking seconds and minutes out of your day

After being forwarded a link to Stevey's Blog Rants: Programming's Dirtiest Little Secret today, I figured I'd do a blog post on this topic too. IMHO, if you sit in front of a computer all day long, especially as a computer programmer, and can't touch type faster than 60wpm, start practicing for 30 minutes a day with one of these tools until you can.
http://www.keybr.com/ (This is the one that I like the best, but a few more follow.)

Tuesday, September 30, 2008

Incorrectly Storing Objects In The ASP.NET Session

In an effort to keep this from happening to someone else, I figured I'd write about it today. I'm surely not the first person to ever write about this, so I'm not claiming to have found something novel. I've personally never written a web application that needed to utilize the ASP.NET Session object, but apparently other folks have not learned that.

Anyway, the following chunk of code was being used to store a reference to the "domain object" currently being viewed/edited.

namespace Your.Web
/// <summary>
/// Summary description for ContainerBase.
/// </summary>
public class ContainerBase : Page
public virtual IDomainObject DomainObject
if (Session["DomainObject"] != null)
return (IDomainObject) Session["DomainObject"];
return null;
set { Session["DomainObject"] = value; }

The result of doing this is that by opening one "domain object" (DO1) for editing in a window (W1), hitting CTRL-N to open a new window (W2) that by default will still show DO1, navigating to a new domain object (DO2) in W2, then switching back to W1 and clicking the Save button without any other operations, the edits in W1 that should be being applied to DO1 are actually being applied to DO2. Dooh!!!! That eliminates a user's ability to have two or more web browser windows open at a time. MS-DOS, here we come!

Moral of the story, don't use the Session object, unless you really truly have read everything there is about using it and are still convinced that you should still use it. And even then, you're probably still wrong!

For further reading, see the ASP.NET Session State Overview on MSDN.

Friday, September 26, 2008

The Overuse of the StringBuilder class in .NET

So this friend of mine Adam wrote this post today. The main point of the post I love, as it correctly abstracts the creation of the query string behind a class and away from the rest of the code that is consuming the query results. Why I'm writing this post is that while his post was not directly having to do with the StringBuilder class, IMHO, he is displaying what I believe is indicative of the over zealous use of the StringBuilder class.

For the sake of convenience, this is how he wrote it:

private static string BuildDefaultViewQuery()
var builder = new StringBuilder();
builder.Append("<Eq><FieldRef Name='DefaultView' /><Value Type='Boolean'>");
return builder.ToString();

This is how I would have written the guts of this method:

private static string BuildDefaultViewQuery()
return String.Format(@"
<FieldRef Name='DefaultView' />
<Value Type='Boolean'>{1}</Value>
I just happen to think that there is too much "noise" when using a StringBuilder for this kind of stuff. Yes, if you're looping through a potentially large set of data and producing a potentially large string as a result, then by all means, use a StringBuilder, as that is what you should be doing. But if you're just building a relatively static string, with a handful of "variables" inserted into the string, use String.Format() in conjunction with a string that supports line breaks (i.e., using the @"" syntax). The resulting code is so much easier to read and understand what is really going on besides the building of a string.

Wednesday, September 24, 2008

SharePoint/MOSS 2007 External Third Party Desktop Application Integration

Today I was presented a scenario where a client wanted to integrate a non-Microsoft Office desktop application into their Microsoft Office SharePoint Server 2007 (MOSS) environment such that documents created/edited in that app and stored in MOSS document libraries were able to be directly opened into that app ready for editing, and ultimately saved back to the document library.

Since Google'ing the answer to this scenario took me more than 30 seconds to find, here is the answer.

Inside SharePoint - Integrating "Office" Applications

And here are some more useful links:

Text Files, Associations, and SharePoint

Sharepoint Beef #3 : Melt-in-your-mouth Native Apps support issue resolved

SharePoint.OpenDocuments Control

How to enable the “Edit in Microsoft Office XXXXX” feature for Office 2007 documents

DocIcon.xml - Adding Notepad and WordPerfect as applications

Adding a Document Template, File Type, and Editing Application to a Site Definition

PDF Integration in SharePoint

Customizing the Shortcut Menu for List Items

Customizing SharePoint Context Menus