Great Tool for Virtual CD/DVD Drives on Vista

For years, I've used the Microsoft Virtual CD tool even though it hasn't been officially supported. Today, I needed to mount an .ISO DVD ROM image to install Visual Studio on my home machine, but I'm running Windows Vista.

Unfortunately, Vista doesn't play well with the MSVCD tool. Not to be deterred, a little Web research unveiled Virtual Clone Drive, which is a tool that works very very well on Vista for mounting ISO images, among other formats. You can download it here.

Error Enabling MOSS Publishing Feature

I've been working on a new Extranet project (details to follow once it is publicly announced), and I need to enable the MOSS Publishing features. Unfortunately, I ran into the following exception when I tried:

Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))

A little research uncovered extensive conversation about this on Microsoft Technet. The solution suggested was a series of STSADM commands to manually enable the handful of publishing features, and it worked! So, reproduced below to help anyone else who runs into this problem, is the series of commands that make this little problem go away. (Obviously, you'll want to replace http://siteurl with the location of your site collection.)

stsadm -o activatefeature -filename publishing\feature.xml -url http://siteurl -force

stsadm -o activatefeature -filename publishingresources\feature.xml -url http://siteurl -force

stsadm -o activatefeature -filename publishingSite\feature.xml -url http://siteurl -force

stsadm -o activatefeature -filename publishingweb\feature.xml -url http://siteurl -force

stsadm -o activatefeature -filename publishinglayouts\feature.xml -url http://siteurl -force

stsadm -o activatefeature -filename navigation\feature.xml -url http://siteurl -force

I found it helpful to wrap these in a nice little batch file for future use, but you could just as easily run them one at a time.

Another Certification

Well, yesterday I passed the 70-630 SharePoint exam, so I have a slick new acronym: MCTS (Microsoft Certified Technology Specialist).

I suppose it also qualifies me to speak on the subject, which is a good thing because SharePoint is my focus at work, so that's what I'll be posting about anyway.

Stay tuned -- good things are coming.

The Machine is Using Us

A colleague of mine sent me a link to a wonderful YouTube video. It's definitely worth taking a peek. I personally find it thought provoking to say the least.

ASP.NET 2.0 GridView Control Bug

Okay, I'm posting this in the hopes of saving some other poor sod some hair pulling. It turns out there's a bug in the 2.0 version of the GridView control that causes a double-postback when the OnRowCommand event fires for a row that's defined as a ButtonField with the type set to Image.

There's a creative way to get around this. Rather than setting the type to Image and specifying the ImageUrl, leave the type blank and put HTML for the text property that will display the image.

There's good information about this problem posted here.

IIS Manager Shortcut

Here's something cool if you're a command-line junky like me. The Run command to open up the MMC console for IIS is "inetmgr". Give it a try!

Shifting Focus

I've been doing some thinking, and one question that has been nagging at me is whether or not the world really need another blog that harps about the importance of understanding how to implement generics in .NET? I'm not so sure it does. Fortunately, there is an abundance of information available in very intricate detail for the programmers out there who are grappling with such things.

So then, if I acknowledge that there is plenty of technical information about the nitty-gritty of programming, the question then becomes one of how I might be able to add value to the community with this blog? I think the answer is simple.

A few months ago, I accepted a position as the Director of Software Development for a company that is a rising star providing sorely-needed technology to the legal industry. This places me in the unique position of being able to provide valuable insight into the trials and tribulations of successful software development -- not only for the techies out there, but also for the "business folks". It is with that in mind, that I proceed on a slightly altered course for this blog.

Microsoft Confirms My VB Assertions

Tom Archer, the MSDN Program Manager and Content Strategist for Windows Vista, the Windows SDK and Visual C++, seems to have confirmed my thoughts about VB programmers in a recent blog post in which he explains why so much of the example .NET code is written in VB. He first notes that there are many more VB programmers than C# or C++, but then goes into a more dubiuos explaination:

"These statistics show that the majority of C++ and C# developers are more
apt to read an article that contains Visual Basic.NET material than the reverse.
In other words, a very high percentage of Visual Basic developers will not read
an article if it contains C++ or C#. "

Translation: The C#/C++ programmers have no trouble with VB, but the VB programmers can't hack the C#/C++ examples.

The Great Debate

The Visual Basic versus C# debate has raged since Microsoft released the very first version of .NET. Is one language better than the other? Does one offer superior processing performance? What about development time?



The short answer (and the answer Microsoft is carefully conveying) is that the languages are functionally equivalent. So what does that mean? Basically, you can do the same things in each language with relatively the same performance.



I read an interesting article a while back that pointed out something beyond the functional nuts-and-bolts of the languages; namely, the type of developer each language attracts. In this case, I tend to agree that there is a difference.



Speaking as someone who came up through the Visual Basic ranks, I can now say that I have a bit of a bad taste in my mouth for VB. I think it encourages sloppy programming practices, bad habits, and poor coding in general. Sadly, for these very reasons, VB tends to be a magnet for sub-par programmers.



By contrast, C# is a more elegant language, and in many cases, forces the developer to take an object-oriented approach. Since both languages are billeted as "Object Oriented", I see this as a plus. On the whole, I find that most C# code is less bloated and more streamlined than most of the VB code I come across.



It's been said that 80% of C# programmers are good, whereas 80% of VB programmers are bad, but because there are so many VB programmers, there are roughly the same number of good VB developers as good C# developers. Of course, that's not to say that all VB programmers are bad. Quiet the contrary, I've met several amazing developers who sling VB code.



I was extremely disappointed to find out that Microsoft has further soiled the .NET implementation of VB by, among other things, taking a step backward and allowing form references without instantiation. For example, assuming you have a form named "Form1". In VB 8 (Visual Studio 2005) you no longer have to create an instance of that form in order to interact with it. All forms are effectively static (or in VB terms, Shared).



Furthermore, some of the language enhancements in VB 8 are just plain silly. For example, Microsoft introduced the IsNot operator. The reasoning is to improve the readability. For example, the old way of testing the value of an object looked something like this:

If Not someObject Is Nothing Then ....

With the IsNot operator, that same line of code would look like this:

If someObject IsNot Nothing Then ...

If you ask me, neither approach is as elegant or intuitive as the C# equivalent:

if (someObject != null) ...

The list goes on and on, but at the end of the day, I'm afraid I have to cast my vote in favor of C#.

Quote of the Day

Unfortunately, I'm forced to agree:

"Programmers have huge and fragile egos."

- Philip Greenspun, MIT Professor
From his article "Managing Software Engineers"

Veteran's Day Code

foreach (Soldier thisSoldier in US.Population)
{
   ThankSoldier(thisSoldier, DateTime.Now());
}

Speeding Up MSDN Downloads

I normally try to avoid regurgitating other peoples' posts, but in this case I'll make an exception (System.PlagerismException?) because the information is so valueable. We actually use this technique with great success where I work, but I'll cite the blog the started it all:

If you're an MSDN subscriber and have ever tried to download a huge set of files, I'm sure you know how long it can take when you're only getting about 25kbps speed from Microsoft's MSDN Subscriber Downloads. The problem is, you may be hitting a non-US mirror site. So, here's a way to speed things up a bit.

In the hosts file on the machine doing the downloading (%windir%\system32\drivers\etc\hosts) add an entry for the Microsoft server:
207.46.252.185 global.ds.microsoft.com

Then, in Internet Explorer, add https://global.ds.microsoft.com in the list of trusted sites under Tools > Internet Options > Security > Trusted Sites. Also, under the privacy tab click the 'Sites' button and enter https://global.ds.microsoft.com so that microsoft.com is a trusted domain.

We did this at work and saw a speed increase from about 25kbps to ~150kbps.

Source: Jason Mauss' Blog Cabin

Comments

Okay, I realize this is a techie blog, so there should be some technical meaning to this post. Accordingly, I'll post my thoughts on commenting the code you write.



The real reason for this post, however, is mostly to point out that I've turned the comment feature back on for this blog. As I pointed out in a post to my personal blog, Blog*Spot had some trouble with spam. It seems to be all better now, and I've had the commented turned on in my other blogs with no trouble for more than a week now.



Back to the relevant topic: comments. Developers have been arguing for years over what should be commented, and what shouldn't be. The rule of thumb I use is that the code itself should tell the what, not the comments. If you can't look at the code and easily determine what it's doing, you need to refactor it.



So then, what are comments for? The comments should tell the why. That's my rule of thumb: the code tells the what, the comments tell the why.



Maybe you wrote some code that deletes a file. The what will be fairly obvious. But why are you deleting this particular file? Here's an example:



In C#, you can also include XML comments. Visual Studio will automatically create an XML comment stub for you if you type 3 comment slashes (///) immediately preceeding a method, or other commentable element. (Note that there are several 3rd party add-ins that allow you to auto-create XML comments in Visual Basic).



When you're finished, it looks something like this:



XML comments are exceptionally useful, and I recommend them highly. First, they remove the need for those painful block comment headers that some companies require. You know the ones - they have such important information as the programmer's name and the date the method was written (because nothing will help me debug like knowing that something was written 3 months ago).



If you specify a file path in your project properties, Visual Studio will create an XML file of all the comments for you during compilation. To set this up, set the XML Documentation File in build section under Configuration Properties from the project properties window as in the following example:




If you create an XML, then a snazzy tool like NDoc will pick up the file, use a little reflection, and create an instanct CHM help file to document your code. Viola! Instant documentation. Few things make a developer happier than not having to waste time writing doc.



Even if you don't plan on creating documentation, there's another reason to use XML commenting. Intellisense looks for it when showing you a method signature. Look what happens when I use the UserHasPermission method from the example above:



This could be extremely helpful if you need to reuse someone else's code, or if somebody needs to use yours.



So the lesson in all this is:

1. Code tells the what, comments tell the why
2. Use the XML comments feature of visual studio
3. I turned the comments back on for this blog, so you can leave some

Happy coding!

Programming Evolution

The other day I was talking to a friend about how programming has changed in the last 15 years. What used to be required (to be a decent programmer, anyway) was an extreme depth of knowledge. You had to really understand that hardware your apps were running on, and we used to make every effort to optimize for performance, and yes, size.



Fast forward 15 years...



Nowadays, the hardware has been largely abstracted away from most programmers (don't argue - I know there will always be a need for people to write device drivers, and I also understand that the Linux camp thinks they are 1337). It's no longer necessary to squeeze the most out of every byte because, quite frankly, there is plenty of memory and hard drive to spare.



We also have nice GUI development tools that provide slick WYSIWYG interfaces. What used to take hours of painstaking coding in a text editor can now be accomplished literally in minutes via drag-and-drop.



These things considered, is it easier to be a programmer now than it was 15 or so years ago? I don't think so. In fact, I think quite the opposite is true.



While we're not wasting time coding as much stuff by hand, and we don't need quiet the depth of knowledge about the hardware, the breadth of knowledge required to be a decent programmer has increased exponentially.



15 years ago we didn't have to worry about the Internet. Programmers these days not only need to know their core programming language (be it C#, C++, VB, Java, Perl, Python, Ruby, or something else), they also need to understand the Internet. That means having an understanding of the network infrastructure itself, as well as the relevant protocols (TCP, IP, HTTP, FTP, etc).



We need to understand interoperability better than ever before, and we also have to have specific knowledge relative to the challenges of distributed computing. I won't even get into the different database options, and what developers need to know. Clearly, the number of areas in which we all really need to have some level of knowledge, if not specialization, is staggering.



All things considered, I think it's actually a little more difficult to be a modern day Software Engineer. Our predecessors may complain of punch cards, command-line compiling, and text-based development tools, but at least they had enough time to do the work without the tools we enjoy today. It'll be interesting to see how the field changes in the next 15 years.

Making a Sortable Collection

Today I needed a collection that would be self-sorting, and I came up with this handy technique for making one. This approach should work for any object that inherits the System.Collections.CollectionBase object.



The key to this approach is that part of the underlying plumbing of the CollectionBase is an ArrayList. Since ArrayLists are self-sorting, wiring this up is a breeze.



The sort method of an ArrayList have a few overloads. One takes no parameters, and the other takes an IComparer object. What does it mean? Well, if you don't specify a comparer object, the array list will be looking to the objects in the collection to perform comparisons against one another as part of the sort aglorithm.



Consider the following example (I like using the good old dog object). Let's say you have a simple "Dog" class that has two properties: Name, and BirthDate. You want to write a collection to store Dog objects, and you need the ability to quickly sort the Dogs in this collection by either name or Birthdate. (Maybe you're writing some kennel software or something - who knows?)



First, a look at the Dog object. It's pretty standard, but you'll notice that it implements IComparer (see my "Implementation and Inheritence Primer" post for more information about this).

public class Dog : IComparable { private string _name = string.Empty; private DateTime _birthDate = new DateTime(); public Dog() { //Empty Constructor } public Dog(string itemName, DateTime birthDate) { _name = itemName; _birthDate = birthDate; } public string Name { get { return _name; } set { _name = value; } } public DateTime BirthDate { get { return _birthDate; } set { _birthDate = value; } } public int CompareTo(object obj) { //required by IComparable if (obj is Dog) { Dog temp = (Dog) obj; return _name.CompareTo(temp.Name); } else { throw new ArgumentException( "Object is not a Dog"); } } }

You'll notice that as required by the IComparer class, Dog has a public method named "CompareTo". The ArrayList will execute this method when comparing two Dog objects during the sort algorithm.



What about non default sorts? We need a couple of IComparer objects to pass into the ArrayList. Here's some examples of objects that will compare Dog objects by Name or Birthdate:

public class DogNameComparer : IComparer { public int Compare(object x, object y) { if (x is Dog && y is Dog) { Dog dog1 = (Dog) x; Dog dog2 = (Dog) y; return dog1.Name.CompareTo(dog2.Name); } else { throw new ArgumentException( "Object is not a dog."); } } }

public class DogBirthDateComparer : IComparer { public int Compare(object x, object y) { if (x is Dog && y is Dog) { Dog dog1 = (Dog) x; Dog dog2 = (Dog) y; //let the underlying data type do the work: return dog1.BirthDate.CompareTo(dog2.BirthDate); } else { throw new ArgumentException("Object is not a Dog"); } } }

Now on to that collection. We implement a pretty standard collection, including a couple of handy overloads for the Add method. We also add a "Sort" method to tell our collection to sort itself. Note that the Sort method makes the underlying ArrayList do the heavy lifting.

public class DogCollection : CollectionBase { public DogCollection() { //Empty Constructor } //Add this dog directly to the inner list //The inner list is an array list, and we'll //use it for sorting later public virtual Dog Add() { Dog newDog = new Dog(); this.InnerList.Add(newDog); return newDog; } public virtual void Add(Dog dog) { this.InnerList.Add(dog); } public virtual Dog Add(string name, DateTime birthDate) { Dog newDog = new Dog(name, birthDate); this.InnerList.Add(newDog); return newDog; } public void Sort() { //easy as pie - since no sort type was specified, //the InnerList ArrayList object will use the // implementation of IComparable built into the //dog object itself this.InnerList.Sort(); } public void Sort(DogSortType type) { //since a sort type was specified, //we'll use one of our Sorter objects //in conjunction with the array list to //do the sort switch (type) { case DogSortType.Name: { this.InnerList.Sort(new DogNameComparer()); break; } case DogSortType.BirthDate: { this.InnerList.Sort(new DogBirthDateComparer()); break; } default: { throw new ArgumentException( "Unsupported sort type: " + type.ToString()); } } } }

And finally, a little bit of enumeration to define the types of sorting allowed:

public enum DogSortType { Name, BirthDate }

Viola! It's cake.



Watch for updates to this post (there are details I still need to add), but one thing I would point out is to ALWAYS CODE DEFENSIVELY. For example, you'll notice that the methods in these objects don't trust the data passed in - they all test for invalid values, and take appropriate action.



Happy coding!

Singleton Duplicity in 5 Minutes

Once you've finished laughing at the tongue-in-check title of this post, you can read on for a discussion of the Singleton Pattern. This is not meant to be an all-inclusive resource for Singleton development, but rather to provide a birds-eye view of what the pattern is all about, and one (extremely quick) way to implement it in C#.


Note that the Singleton is a design pattern, which means it is not language specific. I use C# in my code examples simply out of personal preference; however you can implement this pattern using just about any object-oriented language.



What is a Singleton?

In the simplest terms, a Singleton is a class for which there is only a single shared instance. Any code that accesses the class uses the same instance of the object. Consequently, Singletons must provide a global point of access to their instance.



Why use a Singleton?

Think about your computer. There are certain shared resources of which there can only be one. For example, your computer has a single keyboard that is used by all of your applications. You probably (but not necessarily) have only one mouse. From a software standpoint, your Operating System can reasonably have only one process manager.



Sometimes there are programmatic situations that require one and only one of something, too. A great example of this is a logging service. A logging service only needs to exist in memory one time, and that instance can be shared across all functionality that needs to log an event.



Quick and Dirty C# Singleton

Here's an example of an extremely basic Singleton class. In the real world, you'll want to make sure that any Singleton class is thread safe, but the intent here is to simply provide an overview of the basic Singleton framework.

  public class Singleton
  {
      private static Singleton instance;

      private Singleton()
      {
      }

      public static Singleton GetInstance()
      {
          if (instance == null)
          {
              instance = new Singleton();
          }
          return instance;
      }

      public string SayHello()
      {
          return "Hello World!";
      }
  }

In the example above, you'll notice that the constructor is private rather than public. This prevents the class from being instanciated. Because the constructor uses the "private" access modifier, it is inaccessible to any code outside of the Singleton class. But, since a private method (and the constructor is simply a method) is accessible from within the same class, code within that class can create an instance of it. In this way, we force all access to the object to go through the GetInstance method, which will return the static (shared) instance.



To use the object above, you might have code that looks something like this:

      Singleton mySingleton = Singleton.GetInstance();
      string helloMessage  = mySingleton.SayHello();
      mySingleton = null;

Note that although the reference to the Singleton instance is destroyed when the local object is made null, the instance itself remains, and can be reused by subsequent calls to the GetInstance method. In the first example, note that the instance variable is private, so it is not implicitly accessible to code outside the Singleton class.



Other Considerations

There are multiple ways to implement the Singleton Pattern. The code provided here is merely an example of one implementation method to facilitate discussion of the pattern itself.



If you're planning on implementing the Singleton pattern, do so with care. There are some in the industry who refer to a Singleton as an anti-pattern because it is so often misused. Make sure any objects that interract with singletons are still loosely coupled, and that you're not using a Singleton simply as a global variable.



For more information on Singletons, visit these resources:

• Singleton Pattern at Wikipedia
• Use Your Singletons Wisely
• Implementing the Singleton Design Pattern
• Simply Singleton - Navigate the deceptively simple Singleton design pattern
• Singleton Design Patterns in C# and VB.NET
  

Sorting Directly in a Data Table

One of the nice things about ADO.NET is that it provides a rich set of functionality for sorting without retrieving new data from the database. Furthermore, with ADO.NET, data binding has moved out of the fringe and is now considered the norm – particularly where Web Applications are concerned.



The standard approach to filtering and sorting data in .NET is to use a DataView. In a nutshell, the DataView acts as a layer between your bound object and the underlying data object. For example, to use a DataView to sort the data in a DataGrid, instead of binding the grid directly to a DataSet (just for the sake of argument), you would declare a DataView and set its source to the DataSet. Then you’d configure the sort options on the DataView, and bind the grid to it. Viola! Instant sorting under the hood without the need to write any code!



What if you have a situation where you need to sort data without binding to it? In that case, using the DataView isn’t a viable option. Well, take heart – the DataTable object provides a mechanism that allows you to sort and filter the data directly on the Data Table.



You can use the Select method of a Data Table to sort and filter the data. The syntax is:



    datatable.Select(filterExp, sortExp, rowstatevalue)



The select method returns an array of rows that meet the filter criteria in the sort order specified. Furthermore, you can control what types of rows are returned. You say you only want the rows that have been added since you populated the Data Table? No problem – just set the RowStateValue parameter to DataViewRowState.Added.



What if you want to sort, but not filter the data? That’s not a problem either. You can pass in null to any parameter you don’t want to use. For example:



    DataRow[] sortedRows = customerTable.Select(null, "LastName");

C# Ternary Operator

Although it is sometimes misused, the ternary operator (also called the conditional operator, although I personally prefer ternary) in C# can be quite a timesaver. For those who don’t’ know, it is roughly equivalent to the IIF function in VB.



The C# language specification contains a really convoluted definition for what essentially amounts to a very simple operation. In my own words, the syntax for using the ternary operator is as follows:



    test-condition ? true part : false part;



In other words, if “test-condition” evaluations to true, the true part code will execute. Otherwise, the false part code will execute. It’s like an if-then-else bundled into one statement. In fact, the statement above may be rewritten to:




if (test-condition)

{

    //true part code here

}

else

{    //false part code here

}



Arguably, a programmer could get carried away with what amounts to a shortcut. One great use of the ternary operator that I’ve found, though, is assigning the value to a variable at the time of declaration based upon a specified condition. For example, reading the contents of a config file, and storing the value in a variable.



Note that when reading from a config file, if the specified key does not exist, the value returned will be null. If you then try to perform a string operation (like testing the value of the string), you’ll end up with a nasty little System.NullReferenceException. To avoid this, I use a technique with the ternary operator that allows me to grab my value, and account for the possibility of null all in one statement. Here’s an example:




//read a setting from the config file,

//and assign it to the mySetting string:

string mySetting = ConfigurationSettings.AppSettings["KeyName"] != null ?
      
ConfigurationSettings.AppSettings["KeyName"] : string.Empty;



Another great use is for the ternary operator is when retrieving values from a Data Reader or Data Table. You can use a similar approach to the example above to test for a condition of “== DBNull.Value” before performing any operations on the object that may potentially have a null value.

Implementation and Inheritance Primer

* Note: This post is geared toward beginners, and should be relatively easy to understand. (Note 2: forgive the lousey code formatting -- I'll figure something out for that)

Lacking a more in-depth topic, I thought I’d take a few moments today to share a great way to explain the difference between inheritance, and implementation inheritance (that is, implementing or inheriting an Interface).

To put it as a one-liner, inheritance is like saying “is a…”, whereas implementation inheritance is like saying “acts like…”.

Consider the following C# code example. In the example, we have an abstract class named “Dog”. (Recall that an abstract class cannot be instantiated – it may only be inherited)

public abstract class Dog : IDog { private string _name; public Dog() { //Standard object constructor } public void Bark(int times) { //Actual code here to make the dog bark } public void Sit() { //Actual code here to make the dog sit } public string Name { get { return _name; } set { _name = value; } } }

The Dog object presumably encapsulates all of the basic required functionality of a dog. We have a Name property and methods for Bark and Sit. Any object that class that inherits Dog will have access to all that functionality.

We also have an Interface, aptly named IDog. (Note to newbies: best practices are that Interface names are always prefixed with the letter I)

public interface IDog { void Bark(int times); void Sit(); string Name{get; set;} }

In contrast to an abstract class, an interface does not contain any functional source code. Rather, it merely defines the way in which objects that implement it may be interacted with. In our example, any classes that implement the IDog interface must have their own Name property and Bark and Sit methods.

The following are examples of implementing the IDog interface, and inheriting the Dog class:

public class Poodle : Dog { public Poodle() { //Because this inherited the actual dog object, //we can make the base class do the bark base.Bark(3); } }

public class Collie : IDog { public Collie() { //standard constructor, but we don't have //any functionality available from IDog - //it simply defines what methods and properties we //must have } public void Bark(int times) { //required by IDog interface throw new NotImplementedException(); } public void Sit() { //required by IDog interface throw new NotImplementedException(); } public string Name { //required by IDog interface get { throw new NotImplementedException(); } set { throw new NotImplementedException(); } } }

Note that in our example, the Dog class itself implements the IDog interface. Strictly speaking, it doesn’t have to. However, if this were real world code, we could use the IDog interface as one way to address the Class Factory pattern as in the following example:

public class DogFactory { public DogFactory() { } public IDog GetDog(int height) { if (height <> { return new Poodle(); } else { return new Collie(); } } }

In the real world, this approach is most often seen in functionality that interacts with databases. Taking this approach allows the programmer to write code that will interact with logic that is highly optimized for a specific database platform, while still affording the ability to support multiple platforms. I’ll discuss more about this topic in a future post.

Finding Your Audience

Arguably, one of the challenges of writing – particularly technical writing – is deciding who your audience will be. Are you writing to a very high level that will help PhD candidates conduct their research, or are you keeping it simple enough to help a newbie or perhaps the casual layperson who doesn’t know a lot about technology?

My intent with this blog is evolving. Originally, I waxed poetically that perhaps I would be able to build something to “take it to the next level”. I’m beginning to see, however, that the best value for this blog may lie in helping out people who are perhaps not so technical.

Years ago I started an MSN group to act as an online study group for college students taking their first VB.NET programming course. The group has since taken on a life of its own (admittedly, I rarely even have to look in on it anymore), but I’m quite pleased that it has helped a tremendous number of people along the way. There just don’t seem to be enough resources to help people who lack a fundamental baseline in programming.

My parents read my blog. There – I said it. Although I doubt Steve Jobs, Bill Gates, or Sergey Brin could boast such personal success, it does create some unique challenges. First, my mom continues to proof-read my work. I can get away with just about any technical error, but damn it, those words had better be spelled correctly, and word choice is up for evaluation (my mom's comments on my latest blog posts relative to my choice of the word “indeed”: You have to now retire your favorite word for at least a month or six. Indeed, it is inappropriate to use "indeed" in every blog. People who read you will think this is your personal crutch that replaces "uhhhh", or "ya know?"). Indeed, I see her logic.

Back to the topic at hand, I still need to decide who my audience is. While this is a work in progress and is apt to change over time, I’ve decided to write to the appropriate level of the topic I’m discussing (e.g. if I’m blogging on multi-threading, I’ll be writing for an audience I assume is somewhat familiar with the terms), but I’ll try to include more links to explain technical terms and concepts.

A few thoughts I have on upcoming blog posts:

• The programmer psyche and lack of architectural direction
• The hype around Service Orientation and contract-first development

Kids Programming Language

Years ago I toyed with the idea of writing my own programming language. The simple problem was that while I had the desire to build a better mousetrap, I had no idea how to make the existing mousetrap any better.

Morrison Schwartz seems to have tackled that issue with Kids Programming Language.

KPL is freeware (that will output .NET code, no less), and from what I’ve reviewed so far, it provides an easy way to render graphics without worrying about all the low-level details. There are several example programs available that do everything from rendering a Mandelbrot set, to complete graphical video games.

If you have kids and you want to get them interested in programming, or even if you don’t have kids but have a taste for nostalgia, I recommend you take a look.

Update Time

Few people would argue that 7 months between blog posts is excessive. This is something I've been struggling with, but I've decided to make an honest effort to post more frequently.

It's difficult to step into the spotlight, largely because to do so is to risk ridicule, and indeed, public embarrassment. One thing I’ve struggled with is that I know dozens of people who know more about Software Development than I do. Notwithstanding my knowledge of this fact, I had an epiphany.

It’s true that I know far less than a lot of people. It’s equally true, however, that I know far more than a lot of people. So, while some will read this blog, uncover errors, and perhaps chuckle arrogantly at my posts, other might find it helpful. At the end of the day, isn’t that what techie blogging is all about? I know I’ve certainly benefited from blog posts!

Here’s a preview of some topics to come:

• Using .NET Directory Services with Active Directory and LDAP
• Service Oriented Architecture (SOA), or Service Orientation if You Prefer
• My Take on C# 3.0 and the Next Generation of .NET (a popular topic since the Microsoft PDC)
• Rants, Raves, and other Ramblings
• Assorted off-topic oddball posts

Here We Go

Inevitably, someone will ask why I decided to start a blog. Why would someone opt to indulge in yet another task that is bound to be demanding of an already strained schedule? Well, there are several reasons.

In the world of the PhD and higher learning in general, the term “publish or perish” has been thrown about much to the chagrin of those forced to do the publishing. In software development, I’m noticing a trend that successful programmers (and indeed, other techies) share their knowledge with the world in the form of blogs. Not one to let a trend pass me by, I’ve decided to get with the proverbial program, and in the process get in my two cents on programming and other fascinating topics.

Another thing that comes to mind is that some skills are perishable. If you don’t continue to use exercise these skills, you’ll lose them. I contend that writing is one such skill, and having recently completed my Master’s Degree (in Internet Security, for those who are curious), I’m faced with the fact that my writing skills may wane without an active reason to write something for an audience each week. By having a blog, I hope to keep my writing skills honed.

These things considered, please be gentle with your comments because I am new to this. I hope you’ll enjoy reading my blog as much as I enjoy writing it. If you don't, there is always this site to amuse you.