It's been entirely too long. I've had a new project take over my life for the past few months. I'm trying to get back into things and catch up with the blogs I read, but it's sometimes hard. This is my first big SharePoint-based project and I have to say it's been "an experience." If you're a developer and you haven't heard about how much SharePoint has been taking over, you've probably been living/working in a cave. It's amazing. I've learned a lot, with respect to SharePoint, and I can sum it all up with this: SharePoint is the new VB. I don't say this from the drag-n-drop point of view that made VB so easy to use, but from the ease in which you can get something done. To put it another way, SharePoint is to hobbyist web "developers" what VB was to hobbyist client-side "developers." I say "developers" for a reason. I've been very clear about my thoughts on hobbyists, so I'm not going to get into that.

Perhaps the best way to put it is to liken SharePoint "development" to the creation of a Rube Goldberg device. And, if you want to throw in AJAX features and a standard user experience that looks/feels nothing like SharePoint... well, let's just say you have your work cut out for you. As if portal development wasn't odd enough with respect to deployment. All I can deduce is that SharePoint was built for tech savvy users (not even power users) and not developers... definitely not developers.

As most who know me already know, I've been a fan of DotNetNuke (DNN) for quite a while and even worked on the dev team for a few of the modules. I feel lucky to have gone thru that because DNN gave me a nice perspective to some key issues around portal development. It's also let me experience the difference between portals built for developers instead of for users. This is the key difference between SharePoint and DNN. I know there's been a lot of talk in the past about differences, but it all comes down to that. SharePoint has the polish necessary to make your portal much more user-friendly and feature-complete, but DNN has the dev backing to make it a breeze. I'm really hard-pressed to pick a favorite, that's for sure. I've been in talks with a few key people within the DNN and Microsoft teams to get more involved with DNN in an official capacity, but I think I'm going to back off of that. Between the two portals, I see SharePoint having the most promise for the future. DNN is fantastic and I'll continue to recommend it where it makes sense, but SharePoint is much more powerful. The big hole in SharePoint is the developer experience. I see this as a huge opportunity.

More and more, I hear about how we need to focus on specific technologies. I'm not the type to whole-heartedly dig in to a single technology from top-to-bottom, but I do see value in filling this gap. The training I continue to see around SharePoint is all about small-time hacks. We need an enterprise solution. Some true patterns and practices for enterprise SharePoint development. Given the Rube-Goldberg-ian nature of SharePoint, this may be hard, but someone has to do it. Of course, this is all going to depend on the project opportunities I have. For now, it's just a bag of thoughts I've thrown together, but I'm hoping I'll have a chance to sort them out and pull it all together in the future.

There's so much more I could say about SharePoint, DNN, and the other things I've mentioned here, but I've babbled on long enough.

First off, let me say that this list isn't mine. I saw it on a presentation and wanted to make sure I had it to reference later. Enjoy!

1. Reduce unnecessary invocations of the layout pass -- update a Transform rather than replacing it
2. Use the most efficient Panel where possible -- don't use Grid if you need is Canvas
3. Use Drawing which are cheaper than Shape objects
4. Use StreamGeometry, which is a light-weight alternative to PathGeometry for creating geometric shapes
5. Use DrawingVisual to render shapes, images, or text
6. If you need thumbnail images, create a reduced-sized version of the image
   Note: By default, WPF loads your image and decodes it to its full size
7. Decode the image to desired size and not to the default size
8. Combine images into a single image, such as a film strip composed of multiple images
9. Set BitmapScalingMode to LowQuality for smother animating when scaling bitmap to instruct WPF to use speed-optimized algorithm
10. Set CachingHint when possible, to conserve memory and increase perf
11. Brush selection is critical to good performance; don’t use a VisualBrush or DrawingBrush when an ImageBrush or SolidColorBrush would be sufficient
12. To draw complex, static vector content that may need to be repeatedly re-rendered, consider rendering it into a RenderTargetBitmap first and drawing it as an image instead
    Note: Rendering images is usually faster than rendering vector content
13. Remember to clear event handlers to prevent object from remaining alive (see this post on finding memory leaks) 
14. Use Freezable objects when possible to reduce working set and improve perf
15. Remember to virtualize
16. Share resources -- if you use custom controls, define control resources at the application or window level or in the default theme for the custom controls
17. Share a brush w/o copying by defining it as a resource
18. Use static vs. dynamic resources
19. Don’t use FlowDocument element when all you need is a Label or TextBlock
20. Avoid binding to Label.Content property, use TextBlock instead if source is frequently changes.
    Note: String is immutable, so Label object’s ContentPresenter must regenerate new content
21. Don't convert CLR object to XML if the only purpose is binding
    Note: Binding to XML content is slower than CLR objects
22. Always prefer binding to an ObservableCollection<T> vs. List<T>
23. When a brush is used to set the Fill or Stroke of an element, use the brush's Opacity value rather than element's Opacity property
24. Disable hit testing (IsHitTestVisible = false) when possible
    Note: Hit test on large 3D surfaces is expensive

If you're hungry for more, feel free to dig thru the Optimizing WPF Application Performance section on MSDN.

In early December, I asked myself whether I'd rather go to Mix or SD West this year. I haven't been to either, but have wanted to go to Mix since its inception. After some thought, I've decided to go to SD West. The main reason for that is because I feel like it'll have better content given my focus. The first year of Mix was all about the web and the second year was a mixed designer+developer event, but still heavily rooted in the web world. I definitely feel at home with that mix, but things seem to be changing again. This year, it sounds like there's going to be even more focus on designer content, so I'll let Mix shake itself out one more year and check out SD West. I look forward to it.

A few weeks ago, Mix 08 was announced. I started to check it out and contemplate how much I wanted to attend, since I missed the first one and decided to skip the last one and go to PDC instead... which was cancelled *grumble, grumble* Well, I'm not making that mistake this year. However, another conference I have an interest in attending just popped up: SD West 2008. At first, I was thinking how nice it'd be to check out both. Mix started out being a web developer conference, but has become more about user experience, which I have a great deal of interest in. SD West is an architecture forum. Unfortunately, I just found out they're both happening the same week. Decisions, decisions...

Given the fact that Mix has slightly moved away from the more technical developer content, I think I might opt for SD West. Of course, SD West has more non-Microsoft content I may not be interested in. I'd be lying if I said location doesn't matter. Mix is in Vegas, which is definitely fun; but SD West is in Santa Clara, which would be a first. I've been to San Fancisco, but that was quite a while ago. I'd like to get some feedback from someone who's been to both, but I guess I'll have to take a deeper look at the content of each to see which one would be more valuable.

In preparation for my cert upgrade -- did I mention how much I hate certs? -- I'm skimming thru some of the self-paced training books. For the most part, the books have all been decent. I'm not big on books, tho, so don't take my word for it. I do have one complaint, tho. I open the Designing and Developing Web-Based Applications Using Microsoft .NET Framework book and don't even get 10 pages in before I find a blatant fallacy. With the 5 names on the cover, I'm not sure who's to blame, but I'm inclined to put it on all of their shoulders, as co-authors. What's the problem? I quote, "Use cases and requirements are not the same thing." What!? You've gotta be kidding me, right? What is a use case if not a requirement? What, are shall statements the only way to define requirements? A use case is a requirement -- a functional requirement. Let me defer to Wikipedia: "A use case is a technique used in software and systems engineering to capture the functional requirements of a system."

The book continues by stating that "a use case is a Unified Modeling Language (UML) model meant to describe a set of user steps that accomplish a task." To clarify, a use case has nothing to do with UML. UML is simply a "language" used to visually explain a concept. While there is a use case diagram within UML, all that does is visually depict system use cases and their relationships with each other as well as system actors. You don't need a use case diagram to have a use case; it's just helpful when visualizing the aforementioned interdependencies. Perhaps more useful than the use case diagram, tho, is the activity diagram. An activity diagram visualizes the steps of the use case and, if desired, can also specify who performs those steps. I'd argue that having a visual representation can greatly simplify requirements for all parties involved. Despite the fact that these things might be helpful when documenting your use cases, they are not required. Back to the comment, tho, I will say the latter part is completely right.

I'm not sure how the authors came to these misguided conclusions. Honestly, I question how much they've even used use cases. The term "requirement" is so ambiguous, there's no way to say what does or doesn't qualify. As a matter of fact, any demand of a system can be considered a requirement. Some people may define a requirement as, "the system must have accept usernames of up to 20 characters," while others might define the requirement at a higher level by saying, "the system shall require users to login." Which is correct? Neither. Both. It's all about perception. Use cases are a bit more grounded in reality. A use case for this scenario would define the login process. Within the use case, each of these requirements would be listed to ensure developers know exactly what they are required to implement to satisfy user needs. This is the value of a good use case -- it defines the contract you, as a developer, are signing up for and will be tested against. In some cases, business rules will need to be extracted and referenced from multiple use cases. For instance, password complexity requirements might be managed separately for simplicity, manageability, or purely because they are used or referenced elsewhere.

While I'm on the details of business rules, another problem I had with this section of the book was that it suggested you should avoid adding too much detail to use cases. While I completely agree, the tone of the section gave me the impression the authors were suggesting you avoid most detail. Granted, I may have received the wrong impression, but either way, it didn't do use cases justice. I'd argue use cases should be detailed to whatever level is required to explicate user needs for developers. Use cases should never describe the implementation -- well, unless there are specific implementation details that must be adhered to; however, even then I'd be hesitant to do so. I'd rather leave implementation constraints for the architecture document; but I digress. The level of detail you add to your use cases is going to depend very heavily on the team you're working with and the relationships of team members; especially, those between the business analysts and development staff.

I could go on about this, but I think I've said enough. I'm astounded at how many people don't get requirements, but then again, after working with so many people and projects, I shouldn't be. I am by no means an expert, but I could definitely teach these authors a thing or two about requirements management. Whatever you do, please avoid these discussions in these books and perhaps any other books on the subject by the authors in question.

I'm pretty big on the practice of naming a file after the class it contains. And, yes, I follow the one class per file practice. Ever since .NET 2.0, tho, generics have thrown a kink in the system. We can't have file names with angle brackets (< and >). So, what is the best practice for naming generic class files? Java has the same problem -- perhaps more so since their file names have to be the same as their classes (a restriction I wish .NET had). I haven't touched Java since before generics were introduced, so I'm not sure how it implements that. I'd be interested in seeing, tho. I may have to give that a look at some point. Until then, I started using brackets ([ and ]) to represent generic class file names. For instance, I created a model-view-presenter (MVP) class that extends Control with a signature of Control<TView,TPresenter> and a filename of Control[TView,TPresenter]. That works, of course, but I'm wondering if there's a better way.

On a side, but perhaps related note, GhostDoc will document a generic class/member by HTML encoding the angle brackets; however, Resharper replaces them with curly braces ({ and }). I'm curious as to which is the "right" approach. If it's the latter or both, I might opt to name files with curly braces rather than brackets.

If you're not familiar with Simon Guest , he's on Microsoft's Architecture Strategy Team. While the name may not mean a whole lot to you, you'll probably recognize the Architecture Journal , of which Simon is the editor. If that's still not ringing a bell, I suggest you at least give it a look-see. A lot of devs find the concepts too abstract, so it's not for everyone. Each edition is very themed, so you'll usually have a good idea of how much you'll get out of it pretty early. Either way, that's not what this is all about... Simon started pushing user experience for architects about two years ago, if I remember correctly (probably not). I kind of latched onto this because I'm a huge proponent of user experience. Like most developers, I'm no designer, but I think I do have some artistic ability... at least moreso than most developers I've met. Of course, it's not all about graphic design; behavioral design (aka human-computer interaction or HCI) is actually the biggest part of user experience. Admittedly, I have a lot to learn in this arena. I'm finding out a lot of it has to do with merely thinking outside the box and trying to imagine simpler ways to get tasks done, but even that isn't as simple as it sounds.

I was lucky enough to see a presentation on user experience Simon put on at Microsoft's internal conference for those of us in the field, TechReady. His presentation was absolutely awesome. I left psyched about one thing: getting him and his team out to a project I'm working on. We have a number of systems that could seriously use some re-engineering on the UI front. Then again, what system doesn't? I don't know if it's going to work out or not -- there are a lot of factors that come into play. Nonetheless, I'm hopeful. I'd seriously enjoy the opportunity to leach off the process Simon and his team use.

If you have an opportunity to see Simon's user experience presentation, I highly suggest you take advantage of that. He recently posted the slides from his recent appearance at the San Diego UX Summit, so that's a start; but I have to let you know you won't get the same experience. Simon's presentation is something you need to see in person.

Tyner Blain  posted some comments about using use cases vs flow charts for branching  -- specifically, regarding failure handling.

The first thing I thought was odd is the fact that he used a flow chart. Maybe it's just me, but this should be done with a UML activity diagram. Sure, they both provide the same info in an almost identical format, but I just feel like the standardization of UML is near crucial for requirements management. Again, this is just a small thing.

I'm somewhat confused by the purpose of the post, tho. If you ask me, it's not an either-or situation. I see a need for both. In every use case I create, there's an activity diagram attached. Actually, I put the diagram in the use case specification. Having the visual allows you to briefly run thru the workflow to get the gist of it without having to read all the nitty-gritty details about how it's supposed to work.

Of course, that brings up a good point. Most people under document their use cases, in my opinion. Let me clarify that comment, tho. I, by no means, think a use case should dictate how the system does what it does -- developers need a certain level of creativity in that realm. But, I do think a use case should dictate the workflow and its key business rules. If you ask me, the use case spec should be all a developer needs to get his/her job done. If there are questions after reviewing the spec, then it either wasn't complete or wasn't accurate for one reason or another. Of course, this is completely outside of the realm of concepts like user experience, which I think users should have input on, but not drive. I feel pretty strongly about that, but that's another topic for another time.

The last thing I wanted to mention about the post is the use of 4a, 4a1, 4a2, etc. to document the alternate flows. I've never actually seen this done, but I have to say I don't like it as much as what I've seen, which is to separate alternate flows completely. Of course, this only matters in the textual description of your workflow. The reason I like it separate is because I find it hugely easier to read. This may purely be perspective, tho. I like the idea of reading thru the basic flow and not being interupted by anything. This should provide an end-to-end view of the most common use of the functionality in question. Any big decisions should be left for alternate flows, which reference the basic flow. For instance, in an alternate flow, I would say something like, "This assumes the user has completed steps 1.1 - 1.3 of the basic flow and wants to edit an existing record," assuming the basic flow was to create a new record. Additionally, there would probably be another flow for deleting. For those who like more structured use cases, you can break these out into completely different use cases. It's all up to you. This is yet another one of those simplicity vs. manageability choices.

I read a post about requirements  and there was a brief mention of using shall statements to manage requirements. I have to say I absolutely abhor shall statements. If you ask me, a use case represents a functional requirement. A shall statement just doesn't cut it. Every time I see a shall statement, I just shake my head in disappointment. Luckily, it's been pretty easy to get people to switch sides in the past. I just don't understand why people still use shall statements today, tho. Bleh...