“Who could hate comments so much that they would label them as a code smell?” I thought.

Well, I had an epiphany the other day.

I’ve never seen a block of code that actually needed a comment. Ever.

If you have a section of code that feels too complex, instead of adding a comment do any/all of the following and you can, in almost every case, reduce the need for comments by 100%:

1. add a sourcecontrol commit comment
2. do a simple refactor (Compose Method ftw people),
3. use more descriptive variable/function/class/whatever names.

If you do all of these things and the code you are working on still seems too complex, you may have bigger problems with your overall architecture/design and adding a comment isn’t going to help. In this case it’s time to go back to the drawing board.

Also, everytime you commit a changeset into sourcecontrol that contains a section of code commented out god kills a kitten. Please think of the kittens.

Ever been working with a programming language you’re not 100% familiar with and find yourself wondering:

Is this function a built-in function or in some included library?
What assembly is this class in again?
Can I name my class XXXX without conflicting with another class?

I’ve had these questions recently and found myself annoyed and frustrated to no end (PHP, I’m looking at you) so I’ve decided to build a system to keep track of this stuff for me :D.

The first thing on my list (because it was the easiest) was to do a data dump of all the public classes in the .Net Framework, including the ones in my GAC, and store some metadata for each one in a database table. I’ve just finished this step and thought that this data might be useful, so I’m posting it here.

Currently the fields included in the data dump are:


[namespace] = The namespace that the class exists in (ex: System.Collections.Generic)
[class_name] = The name of the class (ex: StringBuilder)
[assembly_fullname] = The display name of the assembly (ex: mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
[assembly_file] = The full file path to the assembly (ex: C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll)
[framework_name] = The framework that uses this class, for this dump they will all be 'Microsoft .Net'
[framework_version] = The framework version that uses this class (ex: v.2.0.50727)


The .sql file takes about 18 seconds to run to completion on my AMD Athlon X2 2.53ghz machine with 4gb of RAM.

If you’re curious about how I generated the .sql file, below is the code I used to find all the classes. It’s not pretty but then again it was just meant to get the data into the database. Just paste the code into a new console app and run it in a command window like so:

[application_name].exe > c:\classes.sql

Or, you can download the .sql file I’ve generated (it will also create the table you need to store the data).

static void Main(string[] args)
{
	var dictionary = new Dictionary(){
		{ "v2.0.50727", @"C:\Windows\Microsoft.NET\Framework\v2.0.50727" },
		{ "v3.0", @"C:\Windows\Microsoft.NET\Framework\v3.0" },
		{ "v3.5", @"C:\Windows\Microsoft.NET\Framework\v3.5" },
		{ "v???", @"c:\windows\assembly\gac" }
	};

	var types = new List();

	foreach (var pair in dictionary)
	{
		var path = pair.Value;

		var assemblies = Directory.GetFiles(path, "*.dll", SearchOption.AllDirectories);

		foreach (string file in assemblies)
		{
			try
			{
				Assembly asm = Assembly.LoadFile(file);

				foreach (Type t in asm.GetTypes())
				{
					if (t.IsPublic)
					{
						Console.WriteLine(String.Format(
							"INSERT INTO Classes (" +
								"[namespace], " +
								"class_name, " +
								"assembly_fullname, " +
								"assembly_file, " +
								"framework_name, " +
								"framework_version" +
							") " +
							"VALUES (" +
								"'{0}', " +
								"'{1}', " +
								"'{2}', " +
								"'{3}', " +
								"'Microsoft .Net', " +
								"'{4}'" +
							")",
							String.IsNullOrEmpty(t.Namespace) ?
								"GLOBAL" :
								t.Namespace,
							t.Name
								.Replace("`1", "")
								.Replace("`2", "")
								.Replace("`3", ""),
							t.Assembly.FullName,
							t.Assembly.Location,
							pair.Key == "v???" ?
								t.Assembly.GetName().Version.ToString() :
								pair.Key
						));
					}
				}
			}
			catch { }
		}
	}
}

If you found this useful, let me know in the comments!

I built the initial JSOQ Console (which is still included with the JSOQ source code) in about 20 minutes and it increased my productivity by 10x.

It was much faster to test JSOQ functions with the JSOQ Console than it had been with unit-tests. As a result I was able to prototype new functionality in about 1/2 the time.

I’ve finally moved v0.2 of the Jsoq Console to my blog here so you can use it to quickly test out your own JavaScript code!

How it works is pretty straight forward. If you’ve got a snippet of JavaScript, be it jQuery (for the moment jQuery is the only external library that is supported but that will change soon), JSOQ or any other javascript code, you can run it with the JSOQ Console.

Just navigate to http://tinyurl.com/jsoqconsole or http://codeimpossible.com/jsoq for those of you that like to type, paste your code into the textarea at the top of the page, press “Run” and your code will run!

So enjoy! If you get confused there are also samples that will show you how to use the more “advanced” features. Also, drop a comment or share the console with others if you thought it was useful!

The client pointed that the our order wasn’t matching up with what they were seeing internally so I spoke with their developer who suggested that we make sure that the request wasn’t being cached on my machine.

I opened up Fiddler locally and was surprised to see that the none of the request/response data for the connection to the webservice was showing up.

Fiddler, for those that don’t know is a really excellent Http tracing application that allows you to see what kind of http traffic is going in and out over your network connection. You can download fiddler here.

Thankfully, Fiddler runs a simple proxy service which you can point your service requests to in .net using:

if (System.Environment.MachineName.ToLower().Equals("MyMachineName"))
{
    service.Proxy = new System.Net.WebProxy("http://localhost:8888");
}

After adding that code we were off and debugging our .Net service requests in Fiddler!

Usually it’s because of a forgotten semi-colon or parenthesis in some external javascript file. But sometimes it’s something more sinister… Something darker, dirtier and just a little bit more evil.

After seeing the error message, I opened up Internet Explorer’s options dialog and unchecked the following options:

• Disable script debugging (Internet Explorer)
• Disable script debugging (Other)

I then closed IE, returned to Visual Studio, stopped and re-started debugging (ctrl+shift+F5), and watched Solution Explorer as my page began to load.

Oh! That’s not good. See the WebResource.axd request that has the same icon as the Default.aspx file? That means that a bad request was sent for an embedded resource and – most likely recieved a 404 page back instead of the javascript file, which caused our syntax error.

Ok, so how do we figure out which WebResource reference caused the problem? Well, the only way that I have come up with so far, is to manually copy and paste each WebResource.axd url from the html source of the page to the address bar and navigate there. The pages that give return a file download are ok and the ones that don’t will return a 404 page in the browser.

After finishing this long process of elimination, I found the resource request that was causing my headache:

/WebResource.axd?d=MaCiPhUUtdXNj16OOucV5e5lHCBZO...SNIP...

So how do we figure out which resource has embedded this troublesome URL into our html source? I found the solution to that in Irena Kennedy’s blog post on “How to Decrypt an ASP.NET Encrypted Data”:

Please note, that the code below should not be used in production code! It’s only meant for debugging and troubleshooting, and it may break in future versions of the .NET framework if DecryptString private method changes.

1. Add a web page (e.g. DecryptData.aspx) to your web application. For the code to work, it must run in the same appdomain as the web application that created your encrypted string.
2. Add a text box where you will type in the encrypted string.
3. Add a label where you’ll display decrypted results.
4. Add a button.
5. In code-behind on button click event, add the following code:

System.Reflection.BindingFlags bf =
    System.Reflection.BindingFlags.NonPublic |
    System.Reflection.BindingFlags.Static;

System.Reflection.MethodInfo DecryptString =
    typeof(System.Web.UI.Page).GetMethod("DecryptString", bf);

DecryptedData.Text = DecryptString.Invoke(
    null,
    new object[] { EncryptedData.Text } ) as string;

After I created this page, I pasted the WebResource.axd URL (everything up to the &t=) into the DecryptedData textbox on my DecryptData.aspx page, clicked the Decrypt button, and saw that one of my custom aspx controls was responsible. I then corrected the resource path and the page loaded as it should.

See the screenshot below for an example of the DecryptData page, or download the DecryptData .ASPX and Codebehind from my box.net folder.

Here is the post-build script that will accomplish this:

c:
cd\
IF Release==$(ConfigurationName) "C:\Program Files\Inno Setup 5\Compil32.exe" /cc <PATH_TO_ISS_FILE>


• Never under any circumstances store a password in plain-text.
• Do not insert unfiltered strings into a query. Ever.
• Users aren’t stupid. They are clever. Like foxes. Like foxes with augmented AI Skynet brains. They will do things you would never think of in 1 x 10^1000 years.
• Develop and test on the same platform / permissions level that your app will run under. Trust me, this will save you serious future debugging time.
• And on that note: Test, test, test, test.
• Regular expressions work 90% of the time but you only really need them 10% of the time.
• If something doesn’t feel right it probably isn’t. If you can fix it fast do it, otherwise root out code smell and refactor in your down-time.
• XXXX technology isn’t always the answer. Be pragmatic. Solve problems as easily as possible. We exist to reduce and handle complexity in non-complex ways.
• Open source is a good thing.
• Contribute to or start an open source project. Extra XP and a good resume bullet.
• Did I mention test, test, test, test.
• Only re-invent what you absolutely have to. Would you rather spend a week implementing and testing your own GridView or install a commercial control in a day?
• It’s not the hours you put in, it’s what you do with them. Refactor your own development process. If you spend 1/2 a day doing something, odds are you can improve that time.
• “It works on my machine” is ok if, and only if, you are coding for your machine.
• Nobody makes bug-free software. Learn from the bugs you make now and you’ll make newer more interesting ones.
• Oh, and Test, test, test, test.

The items on the list above are definitely not things I knew coming into software development. They are all things I’ve had to learn the hard way, usually by falling completely on my face. The first two especially.

We all make mistakes, it’s part of learning. All I hope is that this list prevents someone from making the same mistakes I made so they can go on and make their own, newer, more complicated, and more interesting mistakes.

I was always obsessed with understanding how things worked. I had to know. Everything had to be taken apart and then put back together, whenever my dad or mom would throw out some piece of computer hardware or other machinery I would ask to see it before they did.

Then I would retreat to my room and take whatever it was apart and see how it did what it did. Even if I didn’t really understand what was going on with whatever I was taking apart in the end it was still fun and exciting. Transformers were, of course, my favorite toys.

I think it was late 1995 / early 1996 when my dad bought me a copy of Visual Basic 4.0 at one of our local computer shows. I remember being really excited because I would finally figure out how programs like WordPerfect, xTree, Windows, and Commander Keen really worked.

Unfortunately my copy of Visual Basic never really showed me how Windows or Commander Keen worked but it kept me occupied for that whole summer and opened me up to a whole world of new things to figure out.

I know exactly why I got into programming. I’m not so sure when it happened but at least I know why.

Think of it as a hi-tech version of Woody Allen’s statement that life is what happens to you while you’re out doing something else. 

The above excerpt was written by Jeff Johson, the creator of the Xtree file management software in his quasi-blog post title “An Unapologetic History of XTree” written in 1991, six years after Xtree 1.0 was released.

Jeff was the lead developer on the Xtree software project that originally started out as an in-house tool but would soon become one of the most popular applications ever released for the DOS operating system.

What set Xtree apart from every other application was how it showed you where your files were located.

Among the subjects discussed were how the program would represent the DOS directory structure on-screen, and what the screen might look like. I drew a picture of this outline on a white board. It looked like a tree that needed water. It was a swell picture but no one thought it could be done. Impossible, they said.

Famous last words.  

Xtree was the first application to use what we now call the Tree View it was created and shipped a full ten years before Microsoft would patent the idea and claim it as theirs. Although never officially credited, Jeff Johnson created of one of the most widely used UI components since the button.

Sadly, Executive Systems, the makers of Xtree, were aquired by Central Point Software in 1993. Symantec bought Central Point Software in 1994 and stopped all production of Xtree in 1995.

Jeff never recieved any compensation from Microsoft when they added file manager to Windows and, in 1992 he contracted the flu and his health began to decline. Although he has not gotten any better he does plan to work on another file manager when his health improves.

His article is a must-read for anyone that used Xtree and a strongly suggested read for anyone that develops software professionaly. Next time you open folder view in Windows Explorer, think of Jeff Johnson and all the talented people at Executive Systems.

I know I will.

I never really got into the microsoft javascript libraries that shipped with the ajax control toolkit because I found that I could do things much faster using external javascript libraries .

It will be interesting to see what Microsoft contributes back to the Jquery community in later updates to the ASP MVC product.