Brain.Reflection()

Awesome ClientSide Syntax Highlighter.

2005-09-29T17:23:00.000-04:00

For the two people subscribing to this blog, my apologies for the 8 million test posts.

Via Jeff Atwood I stumbled upon this fantastic client side syntax highlighter for web pages/blogs. Here's a sample below:

/*********************************** ** My Class **********************************/ public class MyClass { private string _name = string.Empty; public MyClass(){ /* constructor */} public void DoSomething { if(true) { // print the name Console.WriteLine(_name); } }

I post a fair amount of code snippets so felt it was worth the effort to get this installed. It took a few trys though. First I needed to take the multiple files supplied and incorporate them directly into my Blogger template. Then via a ton of trial and error, I finally figured out that a) having any html tags (such as a <br>) within the textarea tag "shuts off" the formatting, and that b) by default both my blog editor (w.bloggar) and Blogger converted newlines into br tags. This latter feature is great when I'm being lazy about the html in my post, but it was killing my code samples. So I've turned off that feature, but now my previous posts look like crap since I was being lazy. Oh, well it'll give me something to do this weekend, cleaning those all up - but at least now my code samples will look really, really cool!

Test Code Highlighter 4

2005-09-29T11:50:00.000-04:00

Testing a syntax highlighter 4 ...

AppDomain.CurrentDomain.UnhandledException is not an exception handler (it's just an event)

2005-09-28T17:46:00.000-04:00

To some the title of this post may be a no-brainer. But, until this afternoon I thought that AppDomain.CurrentDomain.UnhandledException was some sort of "global" exception handler (iow, a giant try ... catch around everything). Hook up a method, log the exception and you the coder decide whether to let the app continue on it's merry way. And never, ever see that standard .NET crash dialog (after all if I've "handled" the exception why is CLR stepping in?). Only it wasn't working that way at all. No matter what I did I was still seeing the crash dialog. (And some other weird behavior I can only attribute to the fact this was a Windows Service). I googled and googled and couldn't find anything. Then finally I found I wasn't alone. Thankfully, the final comment on that post by Jonathan Keljo (CLR Exception PM), kicked the lightbulb on. In part Jonathan explained:

The first thing to understand is that the UnhandledException event is not an unhandled exception "handler". Registering for the event, contrary to what the documentation says :-(, does not cause unhandled exceptions to be handled. (Since then they wouldn't be unhandled, but I'll stop with the circular reasoning already...) The UnhandledException event simply notifies you that an exception has gone unhandled, in case you want to try to save state before your thread or application dies.

So it's just an event handler, giving you one last chance to clean up or log, or whatever before the CLR handler kicks in. (Be sure to read the rest of his comments and this article to understand how unhandled exceptions are "handled" by the CLR for various thread types. In some cases your app won't die at all in v1.0 and v1.1.) Oh, and btw, if anyone has links to some decent articles on "hardening" a Windows Service please comment. At this point all I can come up with is a try catch in the .ctor, and the OnStart, OnStop, etc. methods. But, other than logging can't figure out what I should be doing in the catch block.

Restraining your inner Colonel Jessup (You can't handle the truth!)

2005-06-29T17:44:00.000-04:00

This was brilliant. To be honest, there are days when I too wish I could just mandate some things and get the talking over with.

Peel away the Abstractions - Reference Types, Value Types, ByRef, ByVal, where are my pointers?

2005-06-29T17:38:00.000-04:00

Aaron pointed out this pretty decent article by Jon Skeet that describes the difference between value and reference types in .NET. In that article Jon points to another article of his that describes the difference of passing by value and passing by reference in .NET. I read both articles with interest because this question comes up at times at work, and I'm always grasping for a simple way to explain it. As hard as I try, I still find the easiest way to understand these things is to reach back to C and understand pointers. That's what's really going on under the .NET covers. MyCSharpMethod(ref Object o) is equivalent to MyCMethod(Object** o), it's as simple as that once you understand pointers.

Other Languages: The return keyword - use it!!

2005-06-14T10:44:00.000-04:00

In VB "classic" there is no return keyword, rather you assign the return value to the function name. So, that would look like something like this:


Public Sub SomeProcedure
    Dim result As Integer
    result = AddFunction(1,1)
    MsgBox(result)
End Sub

Public Function AddFunction(paramOne As Integer, paramTwo As Integer)
    AddFunction = paramOne + paramTwo
End Function

Way back when I was first (re) learning programming the VB "classic" syntax for returning values from a method/function made perfect sense to me. Back then, to a hobbyist with no concept of stack frames and such, a function call looked an awful lot like a variable, so why not just assign to it? It's funny how quickly confusing syntax like this becomes a distant memory. I'd completely forgotten that VB.NET, while providing a Return keyword, still supports the above syntax. Until yesterday. A coworker asked me to help him figure out a bug. We stepped into a property accessor only to be completely confused when we saw the code assigning to the property, and then using the Exit Property keyword to break out of the accessor. It took minutes for it to dawn on me that the assignment wasn't calling the property setter, and that Exit Property was legal syntax. I'd just like to say, please don't use this syntax! It is confusing and misleading. In a property it looks downright wrong! (Can you say stack overflow!!) In the interest of readable code use the return keyword. (I poked around to see if there was any other language that didn't use return. All of the C derivatives - C, C++, C# and Java use it. Python uses it. Interestingly, Ruby has the return keyword, but it isn't always required. If you don't explicitly return a value, Ruby returns the value of the last executed statement in the method. I still stand by my assertion that such "implicit" help from the interpreter/compiler makes code less readable.)

No, really, who am I? (The video game character thing)

2005-05-27T10:00:00.000-04:00

I am a Defender-ship.

I am fiercely protective of my friends and loved ones, and unforgiving of any who would hurt them. Speed and foresight are my strengths, at the cost of a little clumsiness. I'm most comfortable with a few friends, but sometimes particularly enjoy spending time in larger groups. What Video Game Character Are You?

Interestingly, the "fiercely protective ..." part is really true, as is the "I'm most comfortable with a few friends". The speedy, foresight, clumsy thing, not so sure about ...

Sniffing out stinky code

2005-05-24T13:19:00.000-04:00

Good naming conventions and practice can really help make code more readable, and even help prevent hard to find bugs. Mike Clark gives a concise, yet thorough explanation of how well written code can be self-documenting, as well as when, why and how to comment your code in the article Write Sweet-Smelling Comments. I particularly got a laugh out of his examples of good comments in the box "eye-popping comments". I had started feeling guilty about the "police tape" style comments I'd liberally sprinkled throughout a particular code base. Seeing Mike's example was extremely validating, and I now proudly stand by those comments. In a completely different vein, but still on the topic of code clarity, Joel Spolsky makes a convincing argument for "Apps" Hungarian notation as a valuable tool for "Making Wrong Code Look Wrong", thus preventing hard to find bugs. I'll admit that early on in my programming career I succumbed to the "wrong" way of doing Hungarian, but even today in my not a bit of Hungarian anywhere .NET code, I rely heavily on certain conventions to make my code readable. For instance I'm a huge fan of "_" as a prefix for member variables, which makes them easy to recognize when reading code. Casing and other conventions are additional tools that I love to take advantage of. (This is a big reason I prefer case-sensitive languages. I like to be able to enforce that someVariable and SomeVariable are two different things, and hence be able to attach meaning to the different cases)

To GAC or not to GAC

2005-05-23T13:23:00.000-04:00

This question comes up at work from time to time, mostly in a rhetorical sense. The GAC represents a great way to share and version assemblies across multiple applications. If you remember "DLL Hell", then you can understand, if not feel, the shudder that paralyzes me when I hear of that kind of functionality. Chris Sells summarized my feelings on the subject very well in his post Avoid the GAC. On the other hand, Junfeng points out that 'Avoid the GAC' is not official MS policy, and that the GAC should be used 'whenever it makes sense' for 'shared components'. I agree, that like most decisions, you can't make a blanket statement to never use the GAC. However, personally this is one of those things where I would err on the side of just don't use it. If you think we do need it, you had better be prepared to convince me why- (hint: simply saying more than one app is going to use the assembly isn't going to cut it.)

Greasemonkey - the way the Web was meant to be

2005-05-09T13:10:00.000-04:00

One of the reasons I switched to Firefox was Greasemonkey. I was going to write about what Greasemonkey is, but instead found this excellent description. Check it out. For me the combination of Greasemonkey, Firefox, Bloglines, Delicious makes the web the way it ought to be.

The original CLI

2005-05-03T22:27:00.000-04:00

Reading through the essays on Emacs and UIs I linked to earlier reminded me of the power that you can get from a command line. In a previous life I worked as an engineer and so I spent many, many hours using AutoCAD. Over those years I developed the habit of almost never using the menus. This would allow me to keep the mouse positioned whereever I was in the drawing and with my left hand I would type commands, most of which were aliased to one or two characters, all characters easily accessed from the "home" position on the keyboard. It was truly an extension of me as I worked. I used to get a chuckle watching new engineers as they struggled, wasting time moving their mouse all over the place searching through menus, clicking back on the drawing, clicking on popups and dialogs. Somedays it was downright frustrating to watch them struggle. Day to day administration of your pc can also be revved up by using the CLI, and this is part of my motivation to learn to bash and related utilities. And the same keyboard-centric approach can really improve productivity in using your IDE. In Peter Provost's confession of keyboard zealotry he explains that it was watching other developers amaze him with their ability to drive using the keyboard alone that made him a convert. ... now I just need to learn all those shortcuts!

Other Languages: Indentation for block scope

2005-05-03T22:20:00.000-04:00

Last fall on Channel 9 I was watching an interview on the upcoming MS command shell Monad, and while describing the syntax Jeffrey Snover made the most convincing argument for curly braces I've ever heard. If you've been programming awhile you've undoubtedly stumbled across many ways to indicate block scope - curly braces, end [blah], etc. (Some of my personal favorites are the 'nix shells - if ... fi, case ... esac, etc. and VB classic's Wend.) The argument made was that for a new user curly braces are easier to learn. You only need to learn the keyword, you already know the end block characters. Which means you have less keywords to learn, and you don't have to learn special and unintuitive rules (is that elihw, end while, or ... Wend?!). Makes a lot of sense to me. Python does one better. Most of us agree that good indentation makes the code more readable, and so whatever our scope keywords/characters we tend to indent based on the scope. Python takes that convention and makes it law, and completely eliminates the curly braces versus end [blah] argument in the process. In Python to indicate block scope you must use indentation. Personally I find this extremely readable and elegant. Plus one for Python (Ruby which I'm beginning to really like, uses begin and end which I don't like)

Doing IDisposable the "right" way

2005-05-02T21:33:00.000-04:00

Joe Duffy posted some updated design guidelines for implementing IDisposable and dealing with resource management in general. The length of the article alone should convince you that this isn't a subject that you want to approach as a "cargo cult" programmer. As Joe says in the intro:

"Implementing this pattern correctly—when appropriate—is critical to ensuring proper, timely cleanup of resources, and also to provide users with a deterministic, familiar way of disposing of resources."

What's cool too, about the article is the added annotations. One jumped right out at me:

(Krzysztof Cwalina): Many people who hear about the Dispose pattern for the first time complain that the GC isn’t doing its job. They think it should collect resources, and that this is just like having to manage resources as you did in the unmanaged world. The truth is that the GC was never meant to manage resources. It was designed to manage memory and it is excellent in doing just that.

I want to learn to do that (Ruby is so cool)

2005-05-02T21:30:00.000-04:00

As I mentioned I've been poking around with Python again as my foray into dynamic languages. A workmate is working his way through learning Ruby, and so we often compare the two. At first glance the two seem very similiar - both are dynamic, both have cool string handling (more on that in upcoming post), both are OOP-ish, etc. I originally chose to learn Python because of it's Win32 library/support. But in the past few days John Lam has posted some of the cool things he's doing with Ruby, things like testing ASP.NET apps, and doing some ADSI scripting which showcase it's Win32/COM support. I'm jealous! Those two posts alone are making me want to abandon Python and start learning Ruby. (Adding additional weight to this desire is the Ruby references in things I've been reading about continuations/closures - more on that soon, too.) So I decided to do some poking around to find out what the true differences are between the two languages and found this excellent paper. Me - I'm still undecided which I'll learn. But based on the few examples I've seen it just might have to be both. (and I'm still hearing lots about this cool thing called RAILS)

Region Expando Macro

2005-05-02T21:24:00.000-04:00

In one code base I spend a lot of time in, regions are used extensively to organize the code. I often like to scroll through a source file, and for this regions seriously get in the way. I quickly discovered that there is no easy way to expand all the regions in a source file from the IDE. So this macro and the key binding 'ctl-shift-=' has become my new best friend. For more info, read the whole article, as well as the comments.

Perception (and Language Wars)

2005-05-02T20:36:00.000-04:00

I don't care if VB is better than C#. To be honest, that ridiculous war was over a long time ago - and the answer is that by and large the two languages are equal. But what I do care about is the perception of the community in general and how that might impact my career. For the record, as my coworkers will testify, I'm a pretty big C# fan. I personally prefer case-sensitivity and curly braces. I prefer keywords that closely approximate commonly accepted terminology (see abstract versus MustInherit). I prefer a compiler that will catch common (at least for me) programming mistakes (and therefore am thrilled to see the new warnings in VB 2005). I prefer clarity and expressiveness (see out/ref versus ByRef). Nonetheless, I have nothing against VB. I still spend large portions of my time programming in VB. However, I am concerned that if my resume includes years of VB.NET and classic VB, am I going to be lumped into a sub-standard "group" of programmers? Sadly, in some minds the answer is yes. A few weeks ago I was talking with a friend of a friend who is the tech lead for a medium-sized .NET shop. We talked shop for awhile, but one comment stuck with me. He claimed that they simply don't hire someone who doesn't have at least some C# experience. Why not consider VB.NET experience? They feel that VB programmers just don't grasp OOP, or more complex programming. I could spend hours poking holes in that theory, and a quick look at the DailyWTF will help provide many counter-examples. But I realized later that it doesn't matter. The truth is that language makes little difference, but as long as the perception is that VB programmers are somehow deficient in comparison to C# programmers, people are going to lose job opportunities. Is this perception entirely by accident? Check out this cover of a magazine that I regularly read and enjoy. Now check out this editor's note in the latest issue of Visual Studio Magazine. As you read through notice what is emphasized as important new features of C# and contrast that with VB. From MSDN in regards to C# "Create elegant code with Anonymous Methods, Iterators, and Partial Classes". What can we look forward to in VB? The "My" namespace. Not to take anything away from My. It looks like it will be helpful. But the impression is that VB is getting features to make the framework more accessible for people who couldn't figure it out before, while C# is getting features to create elegant, more powerful code. Sadly, every time I read anything about VB 2005 all I hear about is the My namespace, and maybe some footnote about how it will have generics too. In the blog community I'm reading all kinds of cool posts about closures and continuations, and in those discussions I'm seeing references to C#, Ruby, Python, Java, Scheme, Lisp - but not a whisper about VB.

Flying the User Interface

2005-05-02T20:13:00.000-04:00

Like Rands, the first time I read Joel's User Interface Design for Programmers I thought I could actually design user interfaces. Despite quickly coming back to reality (one of my favorite Dilbert series follows the chaos and mayhem that ensues when an engineer designs a UI - translation engineers can't/shouldn't do UI design it's just not in our nature), I still love the topic. Flying the user interface describes how our brain works when doing tasks like driving a car (ever been so deep in thought during the commute home that when you break out of your reverie you don't know how you got to where you are?), and what this should teach us about how to design our applications and their user interfaces. In a seperate essay, Peter uses emacs as a concrete example of some of the lessons described in Flying the User Interface, and gives some of the pros and cons of that power user's tool. The way he describes it I actually want to learn e-macs! If you have any interest in UI design (or API design for that matter) check out all of Peter's essays - highly recommended.

SQL 2005 First Impressions

2005-05-02T17:22:00.000-04:00

Last week I installed the VS2005/.NET2.0 Beta and the SQL 2005 April CTP. To be honest my first impressions of SQL2K5 are entirely IDE focused. I haven't had time to play with any of the new relational engine or CLR integration features, but I have been using SQL Server Management Studio to do my SQL work for the last few days. Some things I like Having SQL Solutions, Projects and version control builtin to make this a powerful IDE for SQL development. I've started using that feature right away and love it. Finally I have a workable way to organize all those operational scripts and data-centric projects, and keep everything easily ascessible from the IDE. (There is a caveat below). I do like too that I can work in the IDE, with syntax coloring, etc. without actually being connected to a database. Having Enterprise Manager and Query Analyzer merged into one tool makes sense. I like having everything at my finger tips. That said, there was a lot going for having seperate tools. At one job we used to give Query Analyzer, but not Enterprise Manager to the data analysts. They had all they needed for their job, but were kept out of trouble by not having EM. There's also the size consideration. Doing development and operational work I typically have one to three instances of QA open, but almost never EM. Those three instances would cost roughly 30MB RAM combined. SQL Management Studio is taking about 70-80MB. Some things I hope get better! I'm relearning ctl-Q, instead of ctl-N and I can live with that. But what is a pain is that opening a file (from File-Open or from the solution explorer) forces me to make a new connection to the database. I do a lot of work with a production database where I need to connect with a SQL login which has a strong password. I miss doing ctl-N (new window) in Query Analyzer which would use the same connection properties of the current window where I'm already logged in, and then opening a file into that Window, keeping the connection properties.

Power Browsing (or why you should switch to FireFox)

2005-04-19T21:37:00.000-04:00

A few years ago I stumbled upon Firefox and loved it. Tabbed browsing is very convenient, and works well with my browsing habits. It quickly became my browser of choice, except in those cases where IE was needed. About 9 months ago I got a new laptop, and being in the middle of a crazy push, I couldn't be bothered to download and install it, so I stuck with IE. I found that XP's grouping of taskbar items kept all of my browser windows semi-organized, and definitely out of my way so I had little motivation to go back to Firefox. A coworker finally convinced me to overcome my laziness and make the switch (again). Some reasons why you might want to switch. Developer Tools: A few months ago a co-worker was neck deep in some new UI work which depended heavily on CSS, and he switched to Firefox for it's awesome developer support. For instance he extensively used the Add-in CSSEdit to interactively verify and expirement with the CSS. Browser Features: Highlight a word or phrases on a page in Firefox and a right click brings up a context menu that will allow you to search the web on that word or phrases. Tabbed browsing is just plain awesome. I often will find myself researching some subject and have 5-15 browser windows open just on that subject. In my usual NADD manner, I'll be researching 3-4 subjects each with their own set of browser windows. In IE there was no way to organize this mess. In Firefox I'll have a session open for each research area (plus one for my daily stuff like BlogLines, e-mail, news sites), and the tabs can be used to organize the 5-15 sites I'm on at that time. When I hit my limit and decide that either my pc is crawling, or I've lost interest in a particular subject I can save away the state of that research by bookmarking all the tabs into one bookmark folder (with a single menu selection!), and then later restore the whole thing, again with a single menu selection: Bookmarks>Folder>Open in tabs. Do you want to see all pages in a particular del.icio.us tag - navigate to the tag, add active link, and open the active link in tabs. The next Firefox add-in I need (or maybe should write?) is a way to dump a set of bookmarks to my del.icio.us.

"Other" Languages : OOP without encapsulation?

2005-04-19T21:28:00.000-04:00

Having programmed in VB "classic" for years, I've grown used to a warped view of what an OO language looks like. Sure most people will say that there are *three* pillars of object orientation (encapsulation, inheritance, and polymorphism), but any die-hard VB programmer 'back in the day' would quickly point out that VB was object oriented even though it didn't support inheritance. Supporting arguments would be hair-splitting arguments like the fact that VB supports "interface" inheritance, and that technically you could achieve implementation inheritance via containment/delegation. Well, as if my brain was warped enough, now I'm learning that Python, like VB claims that object orientation is only built upon two pillars, just a different two. Unlike VB "classic" Python does support inheritance, the documentation even goes so far as to say that a feature would not be worthy the name "class" without supporting inheritance. However, Python completely and proudly throws out encapsulation. That's right, there is no notion of private or protected or anything resembling encapsulation (ok, there's a naming convention that 'kind of' hides members, but it hardly counts). But, but, but you're encapsulation wired brain is stuttering. Never fear. The following from the documentation should put your mind at ease 'Clients should use data attributes with care - clients may mess up invariants maintained by the methods [if] they stamp on their data structures'. Oh, good, glad that's cleared up, we don't need encapsulation - our clients will tread with care. If the sarcasm in wasn't obvious, let me just say that although I love many of the features of Python, I just can't come to grips with the lack of encapsulation. I still have hope for dynamic languages though, since a friend of mine pointed out that although Ruby and Python are very simliar in many ways, they differ here. Ruby fully supports encapsulation.

Properties or getter Methods?

2005-04-19T13:02:00.000-04:00

Did I mention that I like code which is self documenting? This is often much more than an aesthetic consideration - it can lead to developers succeeding (or miserably failing) in using your code. During a design session today the question came up about using properties or methods. The attribute in question was a simple boolean, and at first glance seemed to obviously be a Property. However, calling the attribute would result in a database call(s) and some involved logic. Which should it be? A few of the guidelines I try to follow are cited below. From Eron Wright:

A good practice is for property access to be computationally cheap; client code should not be forced to place the property value into a local variable - it's premature optimization. Expensive code should be placed in methods - client code is sure to store and reuse the result. The exception is if the property getter method caches the result in a private field, which can be a challenge as the class instance is mutated. The property syntax in .NET languages is not syntactic sugar. It adds considerable richness to classes.

Brad Abrams points out that this explicitness might be invaluable during a good code review. And of course MSDN Design Guidelines for Class Library Developers, Properties vs. Methods

Use a method when:
The operation is a conversion, such as Object.ToString.

The operation is expensive enough that you want to communicate to the user that they should consider caching the result.

Obtaining a property value using the get accessor would have an observable side effect.

Calling the member twice in succession produces different results.

The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.

The member is static but returns a value that can be changed.

The member returns an array.

"Other Languages": Painless Polymorphism without (explicit) interfaces

2005-04-12T21:45:00.000-04:00

I'm still undecided on static v. dynamic typing, but I have to say that I love how dynamic typing allows for polymorphism without having to declare or implement interfaces. Polymorphism is a powerful tool, but without good refactoring tools, designing and implementing interfaces in a static language like C# can be a bit of a pain. In Python however, it is completely painless, perfectly natural. Take these classes defined in Python:


>>>class Person:
...     Name = ""

>>>

class Employee(Person):  #Employee is derived from Person

...

     JobTitle = ""

>>>class Animal:

...

     Type = ""

...

     Name = ""

Now create a function that prints Names:


>>>def PrintSomethingWithAName(theNamedThing):

...

    print theNamedThing.Name

At first the lack of any type specification in that function definition might be a little disconcerting, it certainly is for me. But the key part - which of the above classes do you think you can pass to the function PrintSomethingWithAName? The answer is all three! If you think about it this makes perfect sense. All three classes do share a common interface - the Name attribute. It just doesn't have to be explicitly declared and implemented. What could be more natural or intuitive?!

Using the right (scripting) tool for the job

2005-04-12T17:48:00.000-04:00

One of the toughest things about being a weekend-warrior type do-it-yourselfer around the house is all of the time spent getting ready to do the actual work. More often than not it seems I spend more time running to the store for materials (and some new tool), setting up my work area and cleaning up than I do the actual work itself. I was talking about this with a friend of mine who is a carpenter by trade. Too my surprise, he said the same thing happens to him. As a matter of fact, he said, he usually gets more done in his house when he leaves his tool trailer on a job - far from home! Most small jobs don't need all of the power tools and gadgets. Usually, you can get by with just a few simple tools if you know how to use them well. My mom is proof. She definitely is not a carpenter, but give her a small hammer and a cordless drill and look out! When it comes to simple, small tasks on my computer I find that all too often I'm like my friend. No matter how small the job, I tend to reach for the power tools. Need a batch program for selectively moving and renaming files? Fire up VS.NET, new->C# project. Before I know it I've spent way too much time building forms, lining up controls, trapping events, yadda, yadda, yadda - all to do one simple task, one that I'll probably never do again. Failed Attempts I know that C# is overkill for these types of projects, so why do I keep going back? Because I've never learned to be effective with the right tools. I've flirted with bash, (and grep, gawk, etc., etc.), DOS batch, various windows command line tools and wscript, but never become effective with any. Every time I swear that I'm going to master one of them, and then I'm done with the task and move on. The right tool? Enter scripting, er, um, I mean dynamic languages. All the power of the 'nix shell script and tools (maybe?), but one consistent syntax and environment. So now I'm re-tackling Python, with the hopes that this time I can stick with it by finding useful things to do with it. And according to some pretty smart guys, dynamic languages may yet take over the world.

"Other" Languages: The C++ "pure virtual" keyword

2005-04-08T16:03:00.000-04:00

If you know C++ you're scratching your head, asking "What in the world is he talking about?" If you aren't familiar with C++, I lied in the title of this post. There is no "pure virtual" keyword in C++ - but there should be. I was sitting at lunch today re-reading Effective C++ (some great stuff on when to use inheritance v containment v interfaces), when it hit me. For a language that is so often elegant, the declaration of pure virtual functions is down right ugly. A pure virtual function is equivalent to a C# abstract method. In C++ you declare it like this "virtual void foo() = 0;". The weird "=0" is what differentiates a pure virtual (abstract in C#) from a simple virtual (virtual in C#). Not only is the syntax ugly and beyond counter-intuitive, but it's called a pure virtual method. So the keyword ought to be "pure" or "pure_virtual" or something along those lines. Gotta' give the point to C# on this one for the abstract keyword. The whole reason I was even prompted to write this post was this bit of history via Tim Lesher:

For example, in The Design and Evolution of C++, Bjarne Stroustrup explains why pure virtual methods use the awkward "virtual foo() = 0;" syntax rather than a "pure" keyword: the last standards committee meeting for release 2.0 of the spec was just around the corner, and if he'd suggested adding a "pure" or "abstract" keyword, the resulting debate would have delayed inclusion of abstract classes beyond the impeding release of the spec. In other words, a short-term hack, based on the fear of bureaucratic delays, has been enshrined in the language for all time.

"Other" Languages: The C++ const keyword

2005-04-08T12:29:00.000-04:00

One of the things I highly value in programming is self-documenting code. Why write a comment if the code can be self-explanatory? In Code Complete, you're encouraged to ask yourself is my method's interface obvious and clear? Unfortunately, sometimes the language itself makes some parts of the interface ambiguous. In C++ the const keyword can greatly reduce such ambiguity. The C++ const shouldn't be confused with the C# const keyword. In both C# and C++ you can apply this modifier to a local intrinsic type, and it works the same in both languages. But the C++ keyword goes much further. First C++ allows you to apply const to the equivalent of a reference type, effectively making that reference type readonly. This is useful at times, but for me not a showstopper. The real advantage for self-documenting code comes from the fact that you can apply const to method parameters (and return values). This allows you to specify that a method does not as a side effect of its invocation modify the class state. This is the kind of explicitness that makes code more self-documenting. For example, say I have the following methods in C#:


static void CallingMethod()
{
Client myClient = new Client();
myClient.Name = “Jason”;
MethodThatTakesClient(myClient);
Console.WriteLine(myClient.Name);
}

//method in some library for which you don’t have the source
static void MethodThatTakesClient(Client someClient)
{
//does some stuff
}

In this example, what is the Console.WriteLine in CallingMethod going to print? Chances are your answer is “I don’t know”, and you would be correct. Without pulling out your favorite disassembler you have no way of knowing whether MethodThatTakesClient has changed any of myClient’s state, .Name included. However imagine a C# that supported const parameters in the way C++ does:


//pseudo C#
static void MethodThatTakesConstClient(const Client someClient)
{
String localName = someClient.Name; // works all day long
//can’t modify someClient it’s const!!
//someClient.Name = “Joe”; <- this won't compile!

} If I call MethodThatTakesConstClient I know exactly what is going to happen to myClient's state – nothing! Ahh, sweet bliss from using an explicit interface. Yeah, but what if you declare a method such that its parameter isn’t const? Again you’re still being explicit about your intentions – you intend to modify the parameter. Therefore I’m going to take necessary precautions (i.e. make a copy to pass to your method if I need to, or simply accept that I can’t assume anything about the state). (Now, I do have to admit C++ does have a back door to this const-ness - you can cast the const parameter to a non-const variable. But to me there's a big difference between a language forcing you to jump through hoops to break a method's expressed contract and a language which forces you to jump through hoops to ever enforce such a contract in the first place. People generally follow the path of least resistance.) So why don’t we have const parameter in C# if they’re so great? There’s some thoughts here, here and in the links here. Some argue that for const parameters to even make sense, the BCL would have to use it extensively. (The nature of const parameters is that either you use them from day one in your app, or you don’t. It’s not a good candidate for retro-fitting). Additionally, as one theory goes, MS probably didn’t think they could get the average VB programmer to do or accept something that some would say many C++ programmers fail to do correctly. Regardless, this would be a difficult concept to apply to many languages. Personally, I tend to think that even a non-CLS compliant support for const parameters in C# would be really useful. A great deal of the applications I work with have large amounts of business and data layer code that have very little BCL interaction. So that argument doesn't stand up very well in my experience. CLS-compliance is important to me, but again it would have little effect on the internals of the business logic I work with everyday, yet this is a place where I could see some real benefits to using const parameters. Is there anyway I can achieve the same level of explicitness in C# (or any .NET language)? Yes, you can. However, it’s a bit of a pain. All you have to is have the class implement two interfaces – a read-only interface which only implements getters and another one that is read-write. (or you could use a base class). Then any method parameters would need to be one interface or the other, making everything explicit. Personally, the additional effort means I reserve this approach for rare occasions when readonly is vital - the rest of the time I just hope for the best.

"Other" Languages: An Intro

2005-04-08T12:26:00.000-04:00

My professional work deals primarily with .NET, C# and VB.NET, T-SQL and a little client-side Jscript mixed in from time to time. But I really enjoy learning other languages and platforms. Over the last few weeks I’ve been rekindling my interest in C++ and Python and decided to blog about the things that I really like about those (and other) languages. Hopefully along the way I’ll understand them better, and maybe some one else will benefit from a managed coder’s perspective on these languages.

C# Tops ComputerWorld Development Survey

2005-04-01T17:07:00.000-05:00

Computerworld recently conducted a developer survey and found C# to be the leading language in use. The survey found 72% used C# compared to 66% Java, 62% Visual Basic and 54% C++. To me this solidifies my feeling that .NET developers should be fluent in both VB.NET and C#. While there is still a ton of "classic" VB code out there, I wonder somedays about the future of VB.NET in the enterprise. I wouldn't be comfortable only knowing VB.NET, and certainly hope to keep my C# skills sharp.

Programming with Exceptions

2005-04-01T16:43:00.000-05:00

When I first moved to .NET I spent a lot of time trying to understand programming with exceptions. I'll make a seperate post on this later, but I found that there's a lot more to exceptions than, "hey, look .NET has structured exception handling, everybody cheer at how easy it is to catch and throw exceptions". There are solid arguments against using them at all (sticking to the function returns error code model). And when you do use them, you need to be extremely careful - since any call at any time can throw an exception (more here.) However, since the error model in .NET is largely exceptions I thought this information from Strousop was excellent guidance for programming with exceptions. It's a bit of tough read at points if C++ is like greek to you, but the basic principles very much apply to .NET. (A briefer summary also by Strousop is here on Informit, not sure if registration, etc. is required)

Why Crunch Time Doesn't Work

2005-04-01T16:22:00.000-05:00

Found this great explanation of Why Crunch Time Doesn't Work via Johanna Rothman. I've never been a through a true 'death march', but having been through my share of crunches I found that article very informative. What was surprising to me is the number of studies that show that five eight hour workdays (a 40 hour week) is the only way to achieve sustainable, maximum productivity. I never knew that this number grew out of a great deal of study and research. (I actually never stopped to think where that number came from - that's just the way things are, right?) Additionally, on 60 hour week, your additional productivity quickly disappears, within 8 weeks or so you're actually getting less productivity than if you had been working 40 hours a week all along. Studies even show that total output working 8 hour days is 16% - 20% higher than total output working 9 hour days. This was surprising to me. I've always thought that the first week or two of a crunch are extremely productive for me. A 14 hour day of being totally in "the zone", sleeping and resting for 10 and doing it all over again the next day for a few days I can get a lot done. (Admittedly I'm a vegetable for the next two weeks while I try to recover.) And I never would've imagined that an extra hour a day would have such a negative effect.

.NET Tips: The "right" way to do a Managed entry point

2005-03-30T17:51:00.000-05:00

Your .NET application's entry point (Sub Main/ static void Main() ) is pretty simple stuff, right? Something simple, like:


static void Main()
{
  Application.Run(new MyMainForm());
}

Think again! Jason Clark does an excellent job of explaining why the above code should be avoided, and provides some recommended boiler plate for your entry point.

Debugging Tip : ISOLATION

2005-03-29T11:29:00.000-05:00

Fowler posted this fantastic debugging tip on isolation:

if you [] get [...] intermittent test failures, suspect any data that gets shared between tests

Read the whole post, it's reassuring to see that the "greats" sometimes make the same mistakes we all do.

An Investment in Knowledge Always Pays the Best Interest

2005-03-29T09:54:00.000-05:00

- Ben Franklin. A friend pointed me to this post by Scott Reynolds (actually it's a whole series, check it out), and that led me to this post by Jason Haley. Both posts resonated deeply with me - not only is my story similiar, but I too feel that knowing what I'm doing is my most valuable asset. (Scott's thought's on knowing what you're doing closely mirror my thoughts on the subject.) Both posts reminded me of tip #8 from "The Pragmatic Programmer". Like most of the tips from that book, it's one I try to follow regularly. Knowledge is our best asset as developers. We need to continually invest in it. My professional work is entirely with Microsoft products (currently .NET), yet I've found that a great deal of my programming knowledge has come from regularly reading trade magazines and web articles from that other VM based platform. Structured exception handling, OOP, design patterns, etc., etc., are all things that really are language neutral - and in this case the Java community often seems to have a bit of a head start on us .NET devs (or at least those of us coming from "classic" VB). I never need to use pointers (or even know what they are) in my day to day VB.NET or C#, nor am I ever concerned with things like the heap or the stack. Yet knowing "just enough" assembly and C, in which such things are right in your face, helps me to have a much deeper understanding .NET. For instance, try understanding or explaining the difference between ByVal and ByRef (especially with regard to reference types), without including pointers, the stack and the heap. My scant assembler knowledge has often proven invaluable during debugging. So here's my goals for the year (in no particular order):

.NET 2.0 (generics, anonymous methods, ASP.NET 2.0, etc.)
Finally get my MCAD
*nix - (cygwin or SFU3.5), become semi-proficient with bash, grep and awk.
Python - actually be able do something useful with it
C++ - Get better with MFC (get beyond text boxes and list views, try some tree views, grids, ADO), with the long term goal of moving to WTL. (I'd like to tackle the STL and templates in general)
Get to know the GoF patterns better. (better == know 80% by name, and be able to create example code off the top of my head for 60%)

Installing Access97 when you already have a newer version installed

2005-03-26T19:39:00.000-05:00

About 9 years ago I developed an accounting app for a volunteer organization, which I've maintained off and on since. It's been about 2 years since I last touched that code, but they recently contacted me to ask for some enhancements. What a trip down memory lane as I dug out a CD on which I'd archived the source, installed VB6 (boy does that IDE look downright archaic!) and then pulled out my Office97 CDs (the app's reporting and some forms are in Access97). So the bottom line of this post. If I ever need to install Access97 again, there's a few tricks when you already have a newer version of Office on your pc. Here's the skinny from MS KB article 241141.

Learning a new (programming) language

2005-03-25T17:25:00.000-05:00

Mike Clark outlines an intriguing way to explore and learn a new language here. I loved the idea. My "/code/tests/" directory is littered with little one off command line apps that were my attempt at "figuring out" a particular feature of some language (new or familiar). The idea of throwing all of those into one unit test project is awesome. Additionally I've always liked the idea of letting the language be the definitive reference on itself. Thanks for the tip Mike!

SCM Best Practices

2005-03-25T15:02:00.000-05:00

"A tool is only as good as you use it". That's how the introduction to High-level Best Practices in SCM begins. We've been having a great amount of discussion and thought here at work in regards to SCM. The move from VSS to SVN has really opened a lot of doors, and we're finding that the change is more than just using a new tool. It's really causing a mind- and process- shift (for the much, much better, IMO). The recommendations in the above article will likely become part of our process here. A few that really stood out: Each codeline (the trunk, branches) should have

a policy specifying fair-use and permissible checkins and
an owner who can interpret and resolve ambiguities in said policy

Branching:

branch on incompatible policy. I found this very enlightening. The others I've read elsewhere, but this helped clarify in my mind what constitutes "necessary" in "branch only when necessary".

Change propogation:

Make original changes in the most stable branch (the one which has evolved the least since branching)
Propogate early and often

Builds:

Use common build tools. This really hit home. Currently our dev's "build", selectively building certain projects from within the VS.NET IDE. I was at first really puzzled when Mike Robert's suggested Dev Tree included NAnt and build scripts on the dev's machine. Now it makes sense. We should all have the same build, so there are no discrepancies between the build machine and our developer environments.
Source + tools = product. This too clarified greatly for me what our Dev Tree and version control repository should look like.

Process:

Track Change Packages
Track Change Package propogation. I can see the need for these two. I'm just really scared about how well we're going to do with this. I can see where tool help would invaluable. (And I'm assuming Perforce probably has tools for this!). I'll have to look into how SVN or SVN plug-ins might help us here.
Give everything an owner. I love the analogy of ants marching around an obstacle. I've seen this first hand with things like coding standards, etc.

.NET Tips : Using External Config Files in .NET

2005-03-25T14:41:00.000-05:00

I came across this little tidbit on using External Config Files in .NET awhile ago, and simply thought, "hey, how cool is that". Then the other day I came across a great use for it. In our source repository we have a "master" web.config for our project. It's a constant source of frustration though, since individual dev's often have a valid need to change some of the settings. One common example is the database connection string. During development you need it pointing at the Dev database, sometimes a local database, and often during QA bug fixing you'll want it pointed at the QA database. The trouble is when one dev modifies it, we all usually get the change. Hence, external configs to the rescue. Since we're re-working our dev tree, what we're going to do now is have each configuration section in web.config point to an external config called [configSection].config.user. SVN is set to ignore .user files. Each dev can override settings by creating [configSection].config.user, but everyone can rest easy since these changes aren't propogated by the version control. Since these local copies should basically only be used for temporary local overrides, we don't worry that they're not versioned or backed up. And, yes, .NET gracefully handles it if the external doesn't actually exist, making the presence of the file completely optional. There's a good caution here and here if you use externals in your production environment (ASP.NET monitors web.config, not any externals).

Is there coding life after 40?

2005-03-23T15:51:00.000-05:00

I'm still a few years from that life milestone, but The value of experienced coders was still extremely thought provoking. If you enjoy coding, check it out. In short, the author (who's over 40) has noted a general feeling in our industry that developer/coder is the bottom rung of a career ladder, a rung to be populated by young, energetic and inexperienced people, and one to be quickly left behind by those who are getting older and more experienced. I have to say that it's a bit disturbing to me. I've given a lot of thought to my overall career direction. About five years ago I made the jump from professional engineer/hobbyist programmer to professional developer. I love being a developer. I am deeply interested in the architecure space, enjoy mulling on the software development process, and try to keep up with trends in requirements gathering. But right now I love writing code. Now, I can't say that I *never* want to move into management or another non-code space, but it's scary to think that I might have no choice - that there is a limit to how long I can enjoy a career as a developer. Hmm. Food for thought.

VSTO (CommandBar) problems?

2005-03-23T12:07:00.000-05:00

The other day I was goofing around with a VSTO solution and kept having problems with Microsoft.Office.Core assembly. Basically, any reference to an object in that namespace (specifically CommandBars in my case) resulted in a null reference exception. I tore my hair out for awhile, then came across this. Basically my problem was twofold. 1. When using VSTO with Office2K3 never, ever create a reference to the C:\Windows\Microsoft.NET\Framework\v1.1.4322\office.dll. This is an OfficeXP IA. 2. You actually shouldn't normally have to manually reference an Office PIA. There's more detail in the above link, but basically needing a manual reference likely indicates that your PIA's aren't installed correctly. (You should be able to find the following in your GAC - C:\WINDOWS\assembly\GAC\Office\11.0.0.0__71e9bce111e9429c\Office.dl). This is either because you did a default install of Office (which didn't include the PIA's), or you installed Office before the .NET Framework, in which case it won't install the PIA's. (This is what happened to me). The solution is to do a repair of the Office install, being sure to install ".NET programability support" under each piece of Office (Word, Excel, Shared, etc.). 3. There is also a potential for problems when installing an Office hotfix. More here.

Subversion resources and thoughts

2005-03-23T10:50:00.000-05:00

As I mentioned Subversion is my latest technology love. The copy-modify-merge mindset took a day or so to sink in, but it's benefits over lock-modify-unlock are easy to see. We're using the HTTP server (apache) since this gives us NTLM security integration (a huge win), and great accessibility. Locally, I'm using the file based repository and I'm working on moving all of my personal code into this local repository. IMO, you won't live without TortoiseSVN - it's a subversion GUI that integrates with Windows Explorer. There is a Visual Studio plug-in, called Ankh . At first I thought this would be a must have. For the last year or so on VSS I've come to rely heavily on the Solution Explorer VSS integration to tell me which files are checked out, and the Pending Check-ins window was the only way to discipline myself to not lock a file too long. But honestly neither of those things is important in the copy-modify-merge style of version control. With those objections aside, I still thought it'd be easier to do my updates and commits from within the IDE, instead of having to switch to Windows Explorer to use Tortoise. The only problem is that Ankh doesn't provide all the features that Tortoise does for resolving merge conflicts. Basically, Ankh will show you via icons next to the files that there are merge conflicts, but it's up to you to fire up your favorite tool to resolve them. Tortoise on the other hand will provide you with a dialog listing all of the conflict files, and allows a double-click on the filename in that list to launch the configured merge tool. So for now, I'm going to pass on Ankh. Speaking of merge tools - a great review of various merge/diff tools that integrate with subversion and tortoise can be found here. Having played with most of those that are reviewed, I'd say Araxis merge is by far my favorite. I understand Aaron's initial frustration, but I would not characterize the Araxis merge interface as 'clumsy'. The difference between Araxis and say KDiff3, is that it's feature set is much greater, so I found that I needed to actually read through the overview in the help file. Once I had done so (and it only took about a few minutes), I found the interface very intuitive - and powerful. To Araxis' credit, when you first run the software a dialog prompts you to read said overview, with a link that will take you to it. I will admit though, that if you're looking to dive in without reading any manuals, the other tools are pretty easy to use. KDiff3 would probably by my recommendation out of the list. It has a pretty full feature set, and you can't beat the price (it's free), whereas Araxis is a commercial offering with an enterprise shop pricetag. One of the things we've bounced around here at work is having one copy of Araxis for heavy duty merging (i.e. bringing a long running dev branch back into the trunk), and as dev's use KDiff3 locally for day-to-day merging. If you're not very familiar with version control, I'd highly recommend the following books. Version Control with Subversion is online and free (there are links on the home page to also buy the hardcopy from O'Reilly). Not only is it a great reference manual for subversion itself, but it's full of good theory on version control - copy-modify-merge, branching, merging, and much more. Pragmatic Version Control is a must read. What I loved about it was the balance of the theory and best practices suggestions (the why) and the how. We've passed it around at work, and it's really helped us to "get" the key concepts of version control. On the other hand, all the theory aside, it's been an indispensable reference as well. I've just recently gotten interested in version control, so I will undoubtedly have more to post as time goes on.

Subversion Tip : Externals URL must be URL encoded

2005-03-23T10:29:00.000-05:00

A recent do or die need for branching finally pushed us over the edge here at work, and we're dumping VSS. The leading replacement candidate is Subversion. We've been experimenting with it for about two weeks now and I have to say I love it. We're using it with TortoiseSVN, which is a fantastic GUI for it. One gotcha to look out for. The Tortoise GUI nicely handles the repository URLs for you, allowing and displaying special characters. So this means that if your local repository resides at "file:///C:/Documents and Settings/you/My Documents/svn" Tortoise will display this as your URL spaces and all. No problems here, except that underneath the covers svn is storing that URL in it's RFC 1738 compliant format: "file:///C:/Documents%20and%20Settings/you/My%20Documents". As I mentioned this almost never poses any problems when you're using Tortoise, but it bit me when adding an Externals Definition to a folder. (An external is similiar to a share in VSS). The URL in the Externals Definition must be URL encoded, if it isn't you'll receive an error "error parsing URL". I spent about 1/2 an hour scratching my head over this one until I went to the svn command line, started poking around and noticed that it displayed the URLs encoded.

.NET Tips : Favor System.Convert over ValueType.ToXxxx()

2005-03-23T10:12:00.000-05:00

Just read the System.Convert SLAR by Brad Abrams. Until now I've often liked the ValueType.ToXxx methods for conversion since they're easy to find. However, as Brad points out the purpose for the System.Convert() class is that it improves maintainability. To plagerize Brad's example if we have this bit of code


int i = 10;
double d = Convert.ToDouble(i);

A maintenance programmer can later change the type of i to a long and the conversion will still work. Whereas double d = Int32.ToDouble(i); would need to be modified.

Hello Blogger

2005-03-23T09:51:00.000-05:00

Hello Blogger. Was having some trouble easily posting to my old blog host, so I thought I'd give Blogger a try. For now I'll leave my old blog up (it can be found here). When/if I get "comfy" over here, I'll move over.

Test Previous date

2005-03-22T12:04:00.000-05:00

This is just a test.

Brain.Reflection()

Awesome ClientSide Syntax Highlighter.

Test Code Highlighter 4

AppDomain.CurrentDomain.UnhandledException is *not* an exception handler (it's just an event)

Restraining your inner Colonel Jessup (You can't handle the truth!)

Peel away the Abstractions - Reference Types, Value Types, ByRef, ByVal, where are my pointers?

Other Languages: The return keyword - use it!!

No, really, who am I? (The video game character thing)

Sniffing out stinky code

To GAC or not to GAC

Greasemonkey - the way the Web was meant to be

The original CLI

Other Languages: Indentation for block scope

Doing IDisposable the "right" way

I want to learn to do that (Ruby is so cool)

Region Expando Macro

Perception (and Language Wars)

Flying the User Interface

SQL 2005 First Impressions

Power Browsing (or why you should switch to FireFox)

"Other" Languages : OOP without encapsulation?

Properties or getter Methods?

"Other Languages": Painless Polymorphism without (explicit) interfaces

Using the right (scripting) tool for the job

"Other" Languages: The C++ "pure virtual" keyword

"Other" Languages: The C++ const keyword

"Other" Languages: An Intro

C# Tops ComputerWorld Development Survey

Programming with Exceptions

Why Crunch Time Doesn't Work

.NET Tips: The "right" way to do a Managed entry point

Debugging Tip : ISOLATION

An Investment in Knowledge Always Pays the Best Interest

Installing Access97 when you already have a newer version installed

Learning a new (programming) language

SCM Best Practices

.NET Tips : Using External Config Files in .NET

Is there coding life after 40?

VSTO (CommandBar) problems?

Subversion resources and thoughts

Subversion Tip : Externals URL must be URL encoded

.NET Tips : Favor System.Convert over ValueType.ToXxxx()

Hello Blogger

Test Previous date

AppDomain.CurrentDomain.UnhandledException is not an exception handler (it's just an event)