Krzysztof Cwalina, author of the book Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries has released a second revision of the Framework Design Guidelines Digest.

I’ve read Framework Design Guidelines a couple of years back and learned a whole lot from it. It definitely makes it to my top 5.

However, I’ve had problems convincing my staff members to read it, as it contains~400 pages of design tips, which are quite hard to read in succession.

The Framework Design Guidelines Digest narrows the basics down to 9 pages. I recommend everyone to download and read it every once in a while.

Quoting Krzysztof:

This document is a distillation and a simplification of the most basic guidelines described in detail in a book titled Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams. Framework Design Guidelines were created in the early days of .NET Framework development. They started as a small set of naming and design conventions but have been enhanced, scrutinized, and refined to a point where they are generally considered the canonical way to design frameworks at Microsoft. They carry the experience and cumulative wisdom of thousands of developer hours over several versions of the .NET Framework.

Get it here.

I found myself in an interesting coaching spot - I am going to teach Alt.NET to a programming infant. I’m going to create the first Alt.NET baby.

Real life sometime brings you to strange situations. I lead a development team which is building a web application and we recruited a new member a couple of weeks ago. I’ll refer to him as “the baby”, since he never wrote a single line of code.

Why is he on board, you ask? Well, he’s a fresh computer science student and knows his way around the presentation side of websites (good knowledge of HTML, CSS, Javascript and good ol’ web black magic) so this seemed like a good trade-off for both sides - the baby will join the team and help us out with his mighty presentation powers and in exchange will be part of a real project for the first time and will get on-job-training.

This is an interesting spot. Computer science has brought his knowledge to a certain level so far (basic C) and I need to catch him up with:

1. Object Oriented Programming,
2. What design is,
3. Separation of Concerns,
4. Liskov Substitution Principal,
5. The .NET Framework (3.5),
6. A whole bunch of BCL,
7. C#,
8. Relational databases & SQL,
9. Active record & SubSonic,
10. MVC,
11. Dependency Injection & Inversion of Control,
12. Test Driven Development & MbUnit,
13. Mocking with Rhino Mocks,
14. Design patterns,
15. Scrum,
16. Continuous integration,
17. Source Control Management with Subversion,
18. Tools.

Oh, and this needs to be done as we go on with the project.

Can you think of anything I forgot to mention?

Does the order make sense or would you suggest a different one?

Eeek.

Perhaps this is a well-known feature and I’m a moron for posting about it, but I just noticed the switch code snippet.

I was working with this enum:

    public enum AvatarSource

    {

        Gravatar, Uploaded, Web

    }

and I wanted some conditional logic performed, depending on an AvatarSource instance. So I started to type switch and then thought I might use a code snippet for it, so I pressed TAB twice.

Well, I didn’t see this coming.

            switch (avatarSource)

            {

                case AvatarSource.Gravatar:

                    break;

                case AvatarSource.Uploaded:

                    break;

                case AvatarSource.Web:

                    break;

                default:

                    break;

            }

Once you enter the variable for your switch block, the snippet automatically adds a block for each value in your enum.

Sweet.

I just saw the reddit.com comments regarding my screencast on Speed Coding with Regionerate & GhostDoc.

I just had to point out that the purpose of the screencast wasn’t to show how fast programming can be done using these tools. What I wanted to show was how to reduce typing using these tools. My only way to "impress" the audience was to do it quickly.

Programming fast reminds me of constructing the book cabinet we just bought from IKEA. The manual states that in order to construct the cabinet, all you need is a screwdriver. I used one to build half of the cabinet. However, using an electric screwdriver I was able to reduce time it took me to build the other half down to a friction of the time. It doesn’t mean that I didn’t have to understand exactly what to put where and carefully consider each step. It’s just that when I needed to do a brainless activity like screwing the damn screw, I got a lot of help from my power tool. If I wouldn’t have paused to think between each step, I would have probably attached the whole thang to the ceiling.

The same goes for programming. Personally, I think 10 times before adding a member to a class. I think carefully about the overall plan and about every step of the way. But when I do decide that I want to create a property, it is easily & quickly available by a power tool. Using these tools elevates the communication level between my thoughts and the literal representation of them (a.k.a. code). I no longer need to think about the syntax of a property and that I need to replace every reference to the exposed member inside my class, I need to think about "Encapsulate Field". Sort of like macros for the ol’ kicker.

Regarding the automatic documentation generated by GhostDoc, if anyone uses it as a complete documentation generator without manually tweaking its results, he might as well throw it to the recycle bin. GhostDoc is great when you -

1. Have a complex method and need a tool to generate the structure for you. After generating it you should definitely tweak it to explain what your method does.
2. Have a simple method or property which looks like

   1:          public XmlNode ParentNode

   2:          {

   3:              get;

   4:              set;

   5:          }

In such a case, running GhostDoc on it will result in -

   1:          /// <summary>

   2:          /// Gets or sets the parent node.

   3:          /// </summary>

   4:          /// <value>The parent node.</value>

   5:          public XmlNode ParentNode

   6:          {

   7:              get;

   8:              set;

   9:          }

which doesn’t really add a lot of information, but keeps things consistent with the rest of your application. This is very important when you generate big documentation files using NDoc (or any other tool) as it prevents missing / inconsistent documentation areas.

About comparing Visual Studio.Net’s refactoring tools to ReSharper, well, did I not make myself clear with free alternative?

After yesterday’s adventure of adding buttons to Visual Studio’s Solution Explorer, I just had to post a short follow-up that shows how easily the same task can be done in #develop’s Projects pad. To remind you, what I wanted to do was add two buttons - one for the project context menu and one for the solution context menu.

While the Solution Explorer adventure required some coding, the Projects pad one is almost nothing but XML.

Simply open up your .addin file and add two Path elements under your AddIn element.

   1:  <AddIn name        = “My Add-in”

   2:         author      = “Omer Rauchwerger (rauchy)”

   3:         url         = “http://blog.rauchy.net”

   4:         description = “Does stuff.”>

   5:   

   6:    …

   7:    

   8:      <Path name=”/SharpDevelop/Pads/ProjectBrowser/ContextMenu/ProjectNode”>

   9:              <MenuItem id = “DoStuffOnProject”

  10:                    label = “Do stuff on this project”

  11:                    class = “MyNamespace.ProjectCommand”/>

  12:      </Path>

  13:      <Path name=”/SharpDevelop/Pads/ProjectBrowser/ContextMenu/SolutionNode”>

  14:              <MenuItem id = “DoStuffOnSolution”

  15:                    label = “Do stuff on this solution”

  16:                    class = “MyNamespace.SolutionCommand”/>

  17:      </Path>

  18:  </AddIn>

The first Path element creates a button labeled “Do stuff on this project” and places it on the context menu that pops up when your right-click a project in the Projects pad. It also hooks it up with the “MyNamespace.ProjectCommand” class. The second Path element does the same but for solutions, and hooks it up with the “MyNameSpace.SolutionCommand” class.

ProjectCommand and SolutionCommand are two classes you should create which inherit from AbstractMenuCommand. All you need to implement in these classes is the Run method. The Run method will run whenever someone clicks on the button.

   1:  using ICSharpCode.Core;

   2:   

   3:  namespace MyNamespace

   4:  {    

   5:      public class SolutionCommand : AbstractMenuCommand

   6:      {

   7:          public override void Run()

   8:          {

   9:              // TODO: Handle the Click event.

  10:          }

  11:      }

  12:  }

Gosh I love #develop extensibility