Finished one exam, on to the next now. The upcoming target is the Microsoft 70-561 exam, “Microsoft .NET Framework 3.5 ADO.NET Application Development”.
I’m already a fair way into the book
It should be a couple weeks before I’m ready to tackle the exam, but I can’t imagine that it will be all that hard. It’s the WCF and ASP.NET ones I’m worried about (mainly due to lack of experience with the technologies).
Over the weekend I took and passed the Microsoft 70-505 certification exam and now have the “MCTS: .NET 3.5 Windows Forms Application Development” certification. It was far harder than I expected, but I still ended up with a score of 914 (passing score was 700).
Just a progress report — things are moving along slowly but steadily and it shouldn’t take all that much longer to finish data encapsulation for the zone data classes.
FindMUD.com has broken the 500 MUD listing mark. It’s growing slowly but steadily.
I ran FxCop against the Basternae source for the first time today. It ran 778,249 checks and found 10,850 issues.
While some of these really are design flaws, some minor and some serious, many of them are not applicable to this project, such as the security declarations and assembly signing. Here’s how I break down what FxCop has complained about:
Applicable issues:
* Array fields should not be read only.
* Avoid type names in parameters.
* Avoid uncalled private code.
* Avoid unnecessary string creation.
* Collections should implement generic interface.
* Consider passing base types as parameters.
* Do not cast unnecessarily.
* Do not concatenate strings inside loops.
* Do not declare visible instance fields. (This is what the encapsulation I’m working on is all about, and was a significant percentage of what FxCop complained about.)
* Do not initialize unnecessarily.
* Do not name enum values ‘Reserved’. (This was a surprise.)
* Do not pass types by reference.
* Do not raise reserved exception types.
* Enums should have a zero value.
* Flags enums should have plural names. (Dang, this one is pretty nitpicky.)
* ICollection implementations have strongly typed members.
* Identifiers should be cased correctly. (Yes, it actually complains about that, and there were a lot found.)
* Identifiers should have correct suffix.
* Identifiers should not have incorrect suffix.
* Identifiers should not match keywords. (Alias, Object, Event, and Exit classes.)
* Implement standard exception constructors.
* Interface methods should be callable by child types.
* Lists are strongly typed.
* Mark all non-serializable fields.
* Mark assemblies with assembly version (Been doing this, but missed one.)
* Mark ISerializable types with serializable. (Fixed these immediately. Duh.)
* Mark members as static. (It’s not the right solution for the ones FxCop found, but there are problems with what it found.)
* Nested types should not be visible.
* Non-constant fields should not be visible. (Encapsulation again.)
* Operations should not overflow.
* Operator overloads have named alternatives.
* Override equals and operator equals on value types.
* Provide correct arguments to formatting methods.
* Remove empty finalizers.
* Remove unused locals.
* Rethrow to preserve stack details.
* Review visible event handlers.
* Static holder types should not have constructors.
* Test for empty strings using string length.
* Type names should not match namespaces.
* Types that own disposable fields should be disposable.
* Use properties where appropriate.
* Validate arguments of public methods. (Note that FxCop does not appear to be Contract-aware, so some of these will be non-issues.)
Non-applicable issues found:
* Assemblies should declare minimum security.
* Assemblies should have valid strong names.
* Mark assemblies with CLSCompliant.
* Mark assemblies with ComVisible.
* Specify CultureInfo. (This is not an internationalized application.)
* Specifiy IFormatProvider. (Yet again, not an internationalized application.)
* Specify MessageBoxOptions. (This refers to right-to-left reading language support, also not applicable.)
Issues I don’t agree with:
* Do not catch general exception types. (Sometimes it really is the simplest and best solution.)
* Do not declare read only mutable reference types.
* Do not expose generic lists.
* Do not pass literals as localized parameters. Use a resource table instead.
* Identifiers should be spelled correctly. (FxCop didn’t like my use of “x” and “y” as variables in a coordinate class.)
* Identifiers should not contain underscores. (There are a ton of these, about 30% of the Cop’s finds. Pretty much all of our flags are named using underscores.)
* Long acronyms should be Pascal-cased. (Side effects of the previous issue.)
* Only FlagsAttribute enums should have plural names. (Stop whining about names already!)
* Prefer jagged arrays over multidimensional. (No. There’s a specific reason for multidimensional arrays.)
* Short acronyms should be uppercase.
* Used preferred terms.
So yes, there are quite a few things to be fixed. I’m not going to spend any extra effort on that right now — some of these problems will resolve themselves as part of the in-progress changes. Even so, it’s nice to be aware of what doesn’t match preferred style, even if it accomplishes nothing other than having a solid knowledge of which rules are being broken on purpose. I’m sure I’ll post updates on FxCop stats as the code evolves.
You have passed the halfway point and are nearing your next codebase.
There’s a lot to do, but I’m halfway through encapsulating all of the data for the zone classes. This will give us the power to validate data before assigning it to a variable and will help us reduce the number of boundary checks in the code by moving them to the property we’re trying to set. End result: code that’s easier to maintain and modify.
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
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
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:
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.
I just checked Alexa stats for FindMUD.com. Although Alexa isn’t exactly the full measure of the web since only a small percentage of people have the plugin installed, here are the MUD sites that FindMUD outranks:
mudmagic.com
mudbytes.net
mudlists.com
mudmaker.com
ftpgame.org
dikumud.com
mudlist.betterbox.net
dune.net
envy.com
silverden.com
It’s a respectable list, but we are far from surpassing the 800-pound-gorilla of MUD sites, the MUD Connector. I don’t expect that to happen, but I do hope to get into the top three at some point (the other two being topmudsites.com and mud.de.)
Of course, FindMUD needs a lot more work that won’t happen in a single day, but I am gradually improving the site. Just today we posted our own version of the MUD timeline.
Back when I was programming C++, I worked with a great test tool: Parasoft C++ Test. It was great for auto-generating unit tests, which in my opinion is the best place to start. Even if they need to be modified by a Human to get proper coverage and real-world test results, the ability to generate tests that automatically check for things like NULLs and ridiculous value ranges is a good start to build from.
Even better is the savings in time. Manually typing out all of the tags, code, and various other “boilerplate” pieces is a pain. With automated test generation, all you have to do is go in afterward and add rows for the tests you want to run.
This is especially helpful for larger projects (more than 100K lines of code), such as Basternae.
After creating a test project, I told Visual Studio 2008 to auto-generate tests for me. It took about twenty minutes with the processor thinking at full speed. I can’t imagine how long it would have taken a human, but since the Human brain functions at about 300Hz it would have taken a mighty long while.
After auto-generating 1,966 tests, I decided to run them. It got just over a quarter of the way through with *LOTS* of failures (approximately none of this new code has ever been tested) and Visual Studio crashed.
One Visual Studio restart later and I was running tests again, with a massive amount of failures.
In the “CharData” class alone, 212 tests were generated and 199 of them threw exceptions on the first run. The rest were “Inconclusive”, which is the default result for auto-generated tests.
Already, Mr. Pex has made it obvious that the application has some architectural flaws, chief among which is the random number generator. The generator lives in an instance of the “SystemData” class when it should be in the “RandomNumber” class, which should be a singleton. When running without the controlled startup environment of the entire codebase, things break horribly. That’s one of the things a test framework is supposed to point out, right?
While automated test generation is not all-inclusive, Pex is extremely helpful for getting to the point where your tests are at least “Inconclusive” and ready to edit by a Human. If you get exceptions without even getting that far, you have some work to do (as I have).
I have seen no better tool for getting a quick and easy start on unit testing. Writing meaningful tests? Well, that’s something you have to figure out on your own, but at least the boilerplate is done for you.
Here’s where you can get more info on Pex, including a video demonstration:
http://research.microsoft.com/en-us/projects/Pex/
It is worth noting that this Pex is extremely beta. Every time I run it, I get the “VSTestHost.exe has stopped working” dialog box. Even with that, all of the tests do manage to run.
When we last saw our hero, he was working on migrating spells from being hard-coded in 15 different places to being individual XML data files that are loaded at boot time.
While this makes it easy to modify, enable, disable, rename, or adjust spells without a recompile, the main reason I’m doing so is because there’s just so dang much clutter in the codebase with spell info strewn about everywhere. It’s like a pack of wizards exploded in there, I swear.
This will also make it far easier to make minor adjustments for balance. Instead of having to track down a developer to go through many slow tweak-recompile-reboot cycles just to adjust spell damage, the “balance engineer” will be able to work independently. In the future it may be possible to perform online editing of spell attributes without a reload. This is obviously not something that everyone should be allowed to do.
Part of the migration will be to move most of the actual function code into the spell files. Most spells are pretty generic in nature — add an affect (flight, strength, poison) or affect hitpoints in some way (fireball, heal). Even so, the same ~10 lines of code are duplicated for pretty much every spell with only the name changed.
Making the spells somewhat independent of the game engine also makes the engine less “tied” to Basternae. At some point I’d like to create a space-based MUD using the same code, and the spells would obviously be dead weight.
As you can probably tell, there hasn’t been any real activity here for a while.
I really enjoy working on Basternae code, but there’s no money in it, so for now it’ll be on hold while I work on more lucrative projects.
Don’t worry, I’ll return to B3 at some point…
Cheers,
Xangis