Monthly Archives: April 2009

A New Laptop

I’ve been meaning to get a laptop for a while.  One might say that I don’t need another laptop.  After all, I do have five already.

Of course, all five of these have bad hard drives.  The newest one is seven years old.  One has a blown motherboard.  One lacks a power supply.  One has a dead keyboard.

So maybe it’s time for a new one.

Newegg.com had a sale on one I couldn’t resist — a Gateway T-6345U Pentium T3400 2.16GHz dual core system with 2GB of RAM and 250 GB hard drive for $399 (normally $549).  Since it’s pretty much the same spec as an $800 machine I was considering, it was a no-brainer.  I’ve always thought you had to have no brains to buy Gateway, so in this case it was a done deal.

Believe it or not, the hardware doesn’t actually suck.  You get a lot for 400 bucks.

It shipped with Vista Home Premium.  Resizing the partition to make room for Ubuntu Linux was a bit of a pain — I couldn’t squeeze more than 110GB out of the Vista partiton in the resize, and that was with page files and snapshots turned off and a good solid defrag.  And, of course, after all that ridiculous junk that gets bundled with a new PC was removed.  Why do they even try to sell people Earthlink dialup?

After trying to install Ubuntu 8.04 and totally botching the partition job (it boots, but can’t login because home directories can’t exist — Whoops!), I’ve thrown in the towel on 8.04 and will be installing 9.04 after it finishes downloading (at a blazing 25kb a second — why do I have this 4 meg high-speed connection again?)

Eventually I’ll have the sucker set up for dual booting Vista and Ubuntu and not long after that, set up for developing Basternae 3 and all of the other web miscellany that I’ve been working on (Django, ASP.NET MVC, etc.)

Studying For The 70-503 Exam

On to the next one… this time it’s the .NET Framework 3.5 Windows Communication Foundation exam. The study guide for this one seems pretty dry and repetitive so far.

It might just be that I have less experience with WCF than I did with the other exam subjects, but so far this one is requiring a serious act of willpower to stay focused on reading.

I doubt I’ll be able to continue my one-exam-every-two-weeks pace, but we’ll see…

Passed The 70-561

I took and passed the Microsoft 70-561 exam today and how have the “MCTS: .NET Framework 3.5 ADO.NET Applications” certification.

This exam was incredibly hard, and I didn’t obliterate like I did to the previous two.  A score of 700 was required to pass and I picked up a 768.

The study book for the ADO exam wasn’t really all that good — it was far too sparse and left out too much information.  It was only about 450 pages or so and should have been around 700 to really cover the material.

The Harpers

Believe it or not, before this year I had never read any of the novels in the Forgotten Realms series. I had always been more of a fan of Dragonlance.

Lately I’ve started reading The Harpers series. I started because I read and enjoyed the Dark Sun novels by Troy Denning. Since he wrote the first book in the Harpers series, I decided to give them a try. So far I’m up to the third book, Red Magic, and I’m pretty sure I’m going to eventually end up finishing the whole series.

Of course, I know it’s a gateway drug. Before long I’ll be reading all of RA Salvatore.

Random Character Name Generator

I wrote a random character name generator in Python today. It’s HERE at Xangis.com.

The system used is:
1. Roll a d6. 1-3 = consonant (1d20). 4-5 = vowel (1d6 with ‘y’ counting as a vowel), 6 = end name.
2. Names must be at least 3 characters long, ignore a roll of 6 if the name is too short.
3. If you get three consonants in a row, end the name.

I used to use that method to generate horrible character names for AD&D a decade and a half ago.

Zone Data Encapsulation Complete

Zone data encapsulation is complete now.  It was a long, tedious process, but it’s all for the greater good.

Last time the code was Fx-Copped, It ran 778,249 checks and found 10,850 issues.  This time, it ran 865,441 checks and found 10,370 issues.  It’s an improvement, but not a huge one.

We now have the power to enforce sanity.  For instance, when an object’s condition is set, we cap it at a max of 100% (perfect) and a minimum of 0% (destroyed).

Studying For The 70-561 Exam

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, and it looks like I shouldn’t have too much trouble wrapping my head around the material.  There are a few things I haven’t really worked with, like the Entity Framework and LINQ to XML, but much of the material involves things I’ve been using a lot lately — datasets, LINQ to SQL, etc.

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).

Passed The 70-505 Exam

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).

Pulled Over by FxCop

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.

Halfway Through Encapsulation

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.