Basternae.org

Now that I’ve passed the base .NET exam (70-536), I’m working on the Windows Forms development certification exam.  Passing that will get me the “MCTS: .NET Framework 3.5, Windows Forms Applications” cert.  I’m pretty confident that I’ll pass it on the first try.  Here’s why:

1. I’ve written a lot of WinForms programs (including 3 for the Basternae project — the help editor, ANSI screen editor, and the zone editor).

2. The exam recommends one year of experience with the topic rather than the two that 70-536 wanted.

3. The book is better-written than the 70-536 book, is more accurate, and is about 300 pages shorter.  It’s less klunky as a learning tool.

I’ve finished the reading portion of the book already, so all I need to do now is spend some time practicing the parts I don’t know all that well.  Look for an exam results report in about a week or so.

I love the refactoring support in MS Visual Studio.  It makes certain things like field encapsulation incredibly easy.

For instance, thanks to its origins in C, most of the Basternae 3 codebase doesn’t have encapsulation yet.  This means that there are tons of class member variables declared like this:

public string _keyword;

Setting the _keyword member variable to private and creating a property named Keyword with getters and setters that reference the _keyword variable would take about 30 seconds.

With Visual Studio it’s easier:  Just right-click on the variable and select “Encapsulate Field”.  It will come up with a reasonable property name and automatically generate the code and set the variable to private.

Pretty nice, but nothing to write home about.

But, here’s the magic:

All references to that variable in code are AUTOMATICALLY changed to refer to the property.  If that member variable was used in 50 different places, Visual Studio just saved you the trouble of making 50 different changes or doing a search-and-replace that may or may not get everything on the first try.

Of course, this doesn’t automatically update any XML files that have been saved using the old variable name.  To take care of that you can do one of two things.

1. Do a search and replace in every XML file that your class would have been serialized to and hope you didn’t miss one.
2. Use the XmlElementAttribute on your property to map the saved attributes to your new type:
[XmlElement("_keyword")]
public string Keyword
{

#2 is obviously safer and easier, especially since it doesn’t require changes to existing data.  Of course, your data files might be clearer to read if they used the exact property names, but do you want to go through the trouble?  Likely not.

I took the Microsoft 70-536 .NET certification exam today.  I can’t say it was easy, but I clobbered it.  It wasn’t for lack of preparation either.  I think I may have read just over 2000 pages worth of material.

In a previous life as a network admin, I took all sorts of certification tests — A+, Network+, I-Net+, CNA, and MCP, which I later upgraded to MCSA and then MCSE.

One thing that these tests always required was extensive knowledge of obscure parts of a technology regardless of their usefulness in working with the technology. You have to know all sorts of useless information to officially be an expert.

Since I’m studying for the Microsoft .NET Framework Foundation (70-536) exam, I’ve been investigating the cobwebbed corners of the framework.  It’s amazing how many things there are that I’ve never used, never thought I’d use, and probably never will use.  Even so, I have picked up a few useful tricks in the process.

What doesn’t help is the extensive amount of errata in the thousand-plus-page study guide.  There’s so much broken that there are FOUR knowledge base articles, presumably due to some sort of size limitation in a KB article:

http://support.microsoft.com/kb/923018
http://support.microsoft.com/kb/935218
http://support.microsoft.com/kb/949730
http://support.microsoft.com/kb/949734

Needless to say, I’m not relying too heavily on a single reference book.

In working on the new WPF-based client, I’ve redone the way I handle ANSI character code processing. Instead of a horrible multi-hundred-line nested if-statement-monster, I’ve created something based on regular expressions that is about 25 lines or so of code. It’s not absolutely perfect, but it’s already better than what we had with the wxWidgets + SDL client (what I call “Client #2″). (FYI: Client #1 was an SDL-only client that used a ridiculously huge amount of CPU and was unworkable in resolutions above 640×480).

Screenshot:

There’s still plenty more work to do on the client.

After running the automated tests generated by Pex, it’s amazing how many functions in the old codebase received various class or structure arguments and immediately started working with the data in them without ever checking for null. It was a paradigm followed by the old public code release of Diku, Envy, Merc, etc. and was unthinkingly carried on by the Basternae 2 programmers, myself included. This lack of data validation is being corrected.

It’s no surprise that the old codebase crashed a lot. After seeing the extent of the damage, I feel like I need to go back and revisit the Magma codebase and add a lot of stabilization.

In fact, one of the main things with Basternae 3 that will help stability is the fact that all player-entered commands are executed within a try-catch block. This means that typing in a broken or unsupported command should never crash the MUD, which was a huge problem in the “bad old days”. Instead it will log an error and appear to do absolutely nothing from the player’s viewpoint.

It’s just screenshots of windows without anything in them — no fancy colors, images, or any bells and whistles yet.  This is just to show that it really exists:

Yesterday I opened up the source code for the Basternae Client in order to make a few changes, fixes, and updates.  What I had forgotten in the two years since I had been programming C++ actively is what a pain in the behind it is to get anything done in C++.

Sure, you can do anything with it, but there’s so much tedium and overhead involved that it takes forever to get anything done.  Sure, it’s great for low-level code where you’re tossing bits and bytes around, but for user interface development it’s just too unwieldy.

Out of frustration, I sat down and rewrote most of the client in C# in a few hours.  Mind you, it’s not fully implemented, but it’s usable as a telnet client.  I’d say about 8-10 more hours of development time and it’ll be ahead of where the other client was.

That makes this the third version of the client.  The first version was pure SDL with C++.  The second version was SDL combined with wxWidgets.  The third version is C#.NET and WPF.

Another benefit of switching to WPF is that the CPU utilization of the client has gone down tremendously, mainly because we’re using only one interface drawing library now.

Check it out, the Magma codebase made it onto the DikuMUD family tree without me putting it there:

http://en.wikipedia.org/wiki/Mud_tree

Strangely enough, I haven’t really used regular expressions until recently. They’re incredibly powerful. In fact, here’s one that replaces about 40 lines of C++ code with a single line of C#.NET code:

text = Regex.Replace(text, @”\e\[\d*;?\d+m”, “”);

It’s not absolutely perfect, but it does the trick for removing all of the ANSI color codes from a block of text.