go to:

Tuesday, February 24, 2009

Binary Data Transforms, Hex Editing, Design Patterns, and Me…

Lately for work I have been responsible for developing a .NET layer to read from and write to an existing application's binary data files.  The task has proven tedious, but not necessarily boring, as I've discovered some invaluable tools and development principles from this.

First off, the HxD hex editor, and, more importantly, comparison tool is simply perfect for the job.


Many minute differences in my binary output were discovered with this tool.  By using the comparison feature:


I could determine the first instance of a difference in output and, if unexpected, use the location from HxD to quickly narrow down the area of code responsible.


In my code, a Stream is passed to a method that will populate a struct representing the file.  This Stream is put into a BinaryReader for sequential type-based reading of the file.   By simply adding conditional breakpoints at various places in the code, locating the problem was easy.  The condition of the breakpoint would be something like:

myBinReader.BaseStream.Position > 10000

where 10000 would be just below the difference location given by HxD.


So this greatly, greatly, very much helped speed up the process of making sure I was reading and writing the native binary file format out correctly.  Next, I was to transform some of this data to XML for use by another application.  I already had the struct of native data, and wanted to make the transformation to and from XML as stupidly simple as possible.  To do this, I threw down a bunch of different classes, each representing the XML element I was to turn out, and had the elements inherit a base interface with a ToXML() contract method.  Some of the “element” classes contained List<>s of the other “element” classes, so when churning out the XML, it was as simple as doing a foreach and callling ToXML() from each of those to produce my child nodes correctly.

I very much realize this solution is neither new nor ingenious.  I am using it, in fact, as a tangent off into a discussion on this patterns-war stemming from the Spolsky comment on the SOLID method.  Quite frankly, I’m not sure what pattern or patterns I implemented above.  The Proxy or Facade?  I would like to know, as I’ve used this technique of a sort of “translation class” a bazillion times, except my bosses really don’t provide me much time to learn about it, much less, say, spend time with my family (I know you gobblers are reading this).  However, I have an opinion on this patterns-war that I would love some feedback on.  It centers around hiring:  if your team is hiring a new developer / engineer, and you or your team are big into design patterns, don't make knowledge of design patterns a requisite for hiring.

I have been programming most of my life, but only somewhat recently have been able to make it my career.  Already I've met a good range of coders: the hardcore enthusiast, the day-job-only coder, the serious professional.  They seem to come in all types, but all have the same common denominator:  they enjoy writing code.  Some more than others, but ultimately, there is a certain gene-pool that simply enjoys writing code.  It actually has little to do with being a computer enthusiast.  A good majority of systems administrators I've worked with or under don't like programming, period.  But there are those of us who are addicted to "realizing" our thoughts right there on the screen.

Until maybe two or three years ago, I knew little to nothing about design patterns.  As I became familiar with and researched them, I've discovered that I've been using many of them for a long, long time.  And that's exactly what they are:  patterns that have been "recognized" in the programming trade.  As such, they are most valuable as a means of communicating an approach to a task or problem at hand.  They are not, however, a requirement to attack a programming task, nor are they any indication of the competency of the prospective engineer / developer.

If your programming shop or R&D department or whatever group you work in is a pattern-heavy group, then make the applicant aware of this, but don't dismiss them if they simply don't know design patterns.  Most likely the applicant would be more than eager to learn them, and will discover they’ve already used many of them anyways.  Ergo, it's a subset of a lexicon we, as coders, may or may not need to know, depending only on how to be most efficient in our team.

I've noticed that a majority of the programmers I've worked with thus far who are heavy into patterns arrogantly criticize and judge their colleagues when they find out they don't know what a singleton is or the proxy pattern or whatever.  So far, from what I've seen, neither camp has shown to be better programmers than the other.  The real thing that quickly separates an experienced programmer from a truly great programmer, though, is ego.  I personally love everything from learning new tricks and techniques from my colleagues to having them point out where I was really dumb in my code.  It only makes me ultimately a better programmer (hopefully).  What I don’t want to do, and I think this is a pretty unanimous feeling, is converse with an asshole.

When you really think about it, the literal sense of “conversing with an asshole” is identical to it’s figurative sense: an asshole really never listens, and only barks out useless foulness you’ll want to stay away from.  Plus, your friends, family, and colleagues all may very well think less of you if they see you regularly conversing with assholes, even if it’s the same asshole.

So really, whether you’re big into design patterns or not, don’t be an asshole, because it just means you don’t listen and no one wants to be near you anyways.  And if you’re hiring, replace “do they know what a flyweight pattern is?” with “are they an asshole?” on your checklist.  You’ll always build a better team that way.


Submit this story to DotNetKicks

Tuesday, February 10, 2009

Baby Toys, Potty Words, SQL, and Me...

So little Liam just had his first birthday last Thursday.  Among the plethora of toys dumped on him is an incredibly annoying, er, wonderful alphabet speaking caterpillar:

My fat son!

There’s a small yellow bow switch just below the head with three settings, plus off (dear God): letter pronouncing, alternate letter pronouncing, and color word.  These obviously coincide with the feet, so if you press the A foot, the caterpillar will speak “A” on the letter pronunciation, “ah” on the alternate pronunciation, and “red” on the color one.


I had the setting on alternate pronunciation, and was lying back letting Liam play and climb on me.  While smashing the caterpillar, he hit a bunch of keys, seemingly at once.  The F key said “fuh” first, then the caterpillar giggled and said “that tickles!”, and then “kh” for the K key.

This immediately caught my attention, and I had to make the evil caterpillar curse violently so mom would toss it in the closet.  With Liam’s full attention, I hit the F, then K keys.  Again, “he he he, that tickles!” between the two keys.  I took the caterpillar from Liam.  This was now science!  I tried K, O, “he he he, that tickles!”, K.  FASCINATING!  They built in anti-potty-wording!  It blocked T-I-“he he he, that tickles!”-T, F then C, K-O-“he he he, that tickles!”-C, C-O-“he he he, that tickles!”-C, C-U-“he he he, that tickles!”-M, and P-I-S (latin for to pee).  J-I-Z worked, as well as B-U-T.  The word for buttocks or donkey (A-“he he he, that tickles!”-S) did not.

This makes me wonder about other alphabet toys and whether they were as thoroughly scrutinized or not.  Needless to say, I had been working on some SQL for work and decided to see how well it tells the SOUNDEX difference between various spellings of rather naughty words using DIFFERENCE.  Using SQL 2005, the results were startlingly poor.  In a few instances, SQL was smart in its comparisons, however in many cases a comparison between, say, a naughty reference to a woman’s genitals and a man’s returns a DIFFERENCE value of 3.  For those who don’t know, the value returned ranges from 0 to 4, 0 being completely dissimilar to 4 being extremely similar if not identical.  The values in the above case should have been a 0.  The SQL and source for the simple tests are here.  Basically, I’d at least look at additional resources for filtering potty language from user input.

I guess really the only useful thing that came out of this arguably utterly useless exercise is some quick C# I threw together to de-Cartesian-ize my SQL result set:

using System;

using System.Collections.Generic;

using System.Text;


using System.IO;


namespace ConsoleApplication1


    class Program


        static void Main(string[] args)


            List<string> csv = new List<string>(File.ReadAllLines("potty.csv"));

            List<string> csvmod = new List<string>();

            csv.FindAll(delegate(string s)


                string[] l = s.Split(new char[] { ',' });

                if (csvmod.FindIndex(delegate(string s2)


                    return (s2.Contains(l[0] + ",") && s2.Contains(l[1] + ",") && (s2.IndexOf(l[0] + ",") != s2.IndexOf(l[1] + ",")));

                }) < 0)


                return false;


            File.WriteAllLines("potty-less.csv", csvmod.ToArray());




Just an example of hot anonymous delegate action for ya.



Submit this story to DotNetKicks

Tuesday, February 03, 2009

Visual Studio Extensions, C++ Debugging, and Me…

So, I am lazy, as I believe most programmers are.  I follow Bill Cosby’s sage advice to work hard to keep from working.

At work I’d “inherited” a code-complete medium-sized application in C++ that requires somewhat extensive feature enhancements / changes (due to the customer, of course).

I’ve been noticing that it seems much easier to write very foreign looking code in C / C++ than it is in C#, and although this application was obviously brilliantly coded, it is quite foreign indeed, seeming to be more of a C+ application than full-on C or C++.

Nevertheless, I have my work cut out for me, and it needs to be done FAST.  I need to make changes and see what breaks, then fix it, and so on.  The problem was, no debugging code was written into the application at all.  What was I to do?  I could spend a good 2 to 3 weeks adding debug output to all the functions, but I don’t have 2 to 3 weeks.  WHAT DO I DO?

Introducing AutoDebugIndexer!  It’s a simple Visual Studio Extension in C# that tried to add an OutputDebugStringA to the beginning of every function it finds.  What’s great is it seems to work!

It simply recurses through all the CodeElements of each Project’s CodeModel, checks to see if each (as a C++ CodeElement) is a vsCMElementFunction, and if so, tries to slap an OutputDebugStringA containing the function’s FullName at the beginning of that function’s BodyTextDownload the source and see for yourself.  Really you only need to look at AutoDebug.cs, everything else is pretty much Extensibility Wizard code.

On a side note, this is an extremely simple solution here.  I did not try at all to make this pretty, nor make it work beyond C++.  The latter is easy, however.  You’d just test for the code type, at the very least at the project level, and if it is say C#, insert a System.Diagnostics.Debug.WriteLine(“blah”); instead of the OutputDebugStringA.

Hope this is as valuable to you as it certainly will be for me!


Submit this story to DotNetKicks