Portable, durable, leather bound. There's a bit of a learning curve, but fortunately, here's a video tech support guide -- it's in Norwegian, but there are subtitles.

Woo-hoo!  VS2005 has intellisense where it is most needed -- making XSLT style sheets. I've written enough XSL that most of it is second nature, but if I haven't done it for a while there is always some rust. Dyslexic things like:

 is it...

or

take a little remembering sometimes (BTW, the latter is correct).  But VS2005 removes this issue entirely by showing you what the legal entries are based on the context.

Ah, such great excitement in the little things!
 

There are 88 keys on a piano keyboard. 

There are 670 public classes in the .NET System assembly.

How long does it take to master the piano?

How long does it take to master .NET?

The piano has been around in its current form since 1860 .

. NET 1.0 is 5 years old this month , .NET 2.0 has been out for a little over a year, and 3.0 just shipped.

On the piano, a C# in 1860 is a C# today. 

In .NET, C# isn't even the same as it was 5 years ago. It will not even exist in 150 years.

I think about the complexity and constant change of developer tools and am amazed that any working software gets written. No one will ever be as intimate with .NET as Beethoven, or any dedicated composer is with a piano. There are not enough hours in the day to KNOW all the current components and far too many versions/patches/service packs to ever keep up.

Music and software have a lot in common. In each domain, works of great beauty and ungainly abominations are constructed using the same fundamental parts.  There is science underlying both, and known patterns and techniques used by their practitioners to achieve certain effects.  And in programming, like music, there are skilled writers and talentless hacks.

A well written application is no less art, and no easier to achieve than a melodic sonata.  The "why" of elegance and beauty are impossible to quantify in either endeavor, but their existence or absence are readily recognized.

There is one big difference between music and software creators however, is marketing.  Everyone expects that playing a piano well is not something one learns in a week, or even a year.  It is widely accepted that it takes years of practice to master an instrument and further dedication to learn how to write new music for one.  It is also a given that some people have a "gift" for music, while the rest of us must settle for learning how to load an iPod.

Every new generation of software development tools, however, promises to make programming easier, to make it "not programming", so anyone with half a mind (or less) can create an application.  Each improvement tries to remove the need for skill and intution, to deny that it is necessary to learn the craft, to understand the tools, to practice, to study. The expectation is that programming should be something "everyone" can do, like typing or reading. (Please kindly ignore the millions of VCRs flashing "12:00".)

This expectation for easy mastery permeates the industry from CEOs -- "Find cheaper developers!"-- down through job seekers -- "Can you tell me what the interview questions are?". Everyone is seeking the magical shortcut that leads from first touching the keys to creating "Ode to Joy".

This is just how it is, because like in music, or any industry, the bottom line is all that matters.  Without a need for software, no software would be written, and what is written must satisfy the market. If crap sells, there is no need to create beauty.  Heck, the music industry uses technology to remove musical talent as a prerequisite for being a musical act -- insert your favorite prepackaged boy band reference here.

I'm just glad we don't have to suffer through the beta version of Beethoven's 9th Symphony.  He missed a bunch of deadlines but the 1.0 version he released hasn't needed a service pack yet.
 

Stumbled across a bit of fiction over on the MSDN library site. I am converting a .NET 1.1 application to 2.0.  The 1.1 version uses a third-party control to handle the menu, but as there is now a Menu control built in to 2.0, I decided to take advantage of it.

The 1.1 control reads from an XML file, which is convenient because the application has some menu pages that are populated from the same file.  Wanting to change as little as possible, I was hoping that I could do the same with the built-in control.  And according to Microsoft, I should be able to...

The Menu control can also be bound to an XmlDocument object. To bind to this data source, set the DataSource property of the Menu control to the data source and then call the DataBind method.

Looked straightforward enough.  I knew I'd have to set up some bindings so that the control pulled the proper bits from the XML, but otherwise this looked like about 10 minutes of work.

But, alas, the above stament is simply not true.  The DataSource property on the menu control expects an object that implements either of the following interfaces:

IHierarchicalDataSource

or

IHierarchicalEnumerable

The XMLDocument object does not implement either of these, so it was back to drawing board.

One thing that is really starting to bug me about 2.0 is Microsoft's love affair with declarative "programming" in .NET . There lots of nice shiny examples how to build things just by declaring them in the ASPX page, but the examples are extremely light on actual code.  Take the menu class for example, there are two examples in VB.NET on how to declare a menu control in ASPX, but nary a one on how to load a menu control via code.  What's doubly damning is that there are 2 C# examples as well, but since the only thing different about them is that the page directive is

<%@ Page Language="C#" %>

instead of

<%@ Page Language= "VB" %>

they are really just a waste of space. 

Now, if I could use the file in its virginal form, I'd simply declare an XmlDataSource object and be done with it. I could bask in the ease of declarative programming, go home early and read a book.

But, but, but. The file is just a starting point. The XML document used for the menus is manipulated based on some other factors before it is passed to the menu. So what I need to do now is create the XMLDataSource on the fly, after the manipulations have taken place.

None of this is too horrible and I didn't drive myself insane believing the documentation, but I do wonder if the ability to directly load an XmlDocument was in there once upon a time, or if it was just wishful thinking on the tech writer's part.

Once every year or so, I find myself writing/debugging/swearing atC++ code.  This year's adventure was brought on by the upgrade ofmy co-dependent application from .NET 1.1 to .NET 2.0 (finally!). It's a scientific application that designs genomic assays. It has one particularlycomputation-intensive algorithm that begged for implementation innative code.  So, two years ago, I dove into creating a C++application for this purpose.

For those of you who have never crossed the border into C++ Land -- BEWARE -- C++ gives you enough rope to hang yourself and everyone you haveever said "hello" to.  The compilation options alone resemble anApollo spacecraft control panel. Compared to the simple accelerator,brake and steering wheel of VB.NET and C#, it is daunting.  After clawing up asteep learning curve with help from people who actually knew what theywere doing and a couple of false starts we developed a workingsolution, which looks something like this...

Though it istheoretically possible to combine Managed C++/Unmanaged C++ in the sameassembly this turned out to be a nightmare, hence the two assembliesinstead of one.  The Calculation DLL does the heavy lifting. The Wrapper translates managed communications to the Calculation DLLand returns the results in a managed manner.  The VB ControlObject sets up the wrapper and calls it.

Fastforward to this week and our application's move to 2.0.  Much likea regular build, I've started by moving the supporting assemblies into2.0 and creating the new versions. Putting off my trip to C++ Land as long as possible, the last two assemblies I move are the Calculation DLL and the Wrapper.  Unlike the majority of theVB.NET assemblies, these two, of course didn't just recompile and workin 2.0.  That would have been too easy.

I started with the native Calculation DLL, and got a rash of errors that looked like this:

error C2143: syntax error : missing ';' before '<'

HadC++ suddenly changed?  Had the conversion fumbled one of the8-gajillion compiler switches?  Was there a new compiler switchthat needed to be set? Was there a missing header file? After somegoogling and the requisite swearing, I found the answer.  Itturned out to be rather simple.  The code in question was usingthe hash_map object. Well, that's fine, but it's not in the std namespace, it's inthe stdext namespace.  The VS2003 compiler obviously didn't careabout this as much as the VS2005 compiler did. Changing the code inquestion from:

hash_map, double, CHasher> LookupEnergies11;

to

stdext::hash_map, double, CHasher> LookupEnergies11;

fixed the problem, and voila, we had a .NET 2.0 version of this working (well compiled anyway). 

On to the Wrapper. It didn't throw any compilation errors, but had 15 linking errors. 

LNK2028: unresolved token 

This usually means there is something missing, but what? The Wrapperonly relies on the Calculation DLL and the framework."What fresh hellis this?" I thought. Again Google came to the rescue .I needed to add the msvcmrt.lib to the Additional Dependencies. I didso and the managed wrapper was compiling and linking! (Thanks toChucker and the mysterious Senthil for documenting the problem and sharing theresolution.)

But what is this new dependency I have just addedto my project?  What new bit of magic is now required and for whatreason?

Ah, msvcmrt.lib turns out to be, in Microsoft's own words :

The import library references a new library, msvcm80.dll, which provides a proxy between your managed code and the native CRT.

In other words, this is the glue that lets the Managed Wrapper chat with the Native DLL.

So,my annual trip to C++ Land appears to be over. It wasn't as bad as Ihad feared, but I'll be glad to return to a land where the compiler'scommand line doesn't scroll off a 21" monitor.

OK, it's not as as bad as that -- but it's darn close.

I know what I want for Christmas.  I want a tool that makes all my web pages look and behave the same way no matter what browser they happen to be rendered in.  I spend more time tweaking HMTL, CSS and Javascript than I care to think about. The heavy lifting development: architecture, objects, database access, etc.  is much more satisifying -- design, build, test, debug  -- repeat and it works.

But gosh darn it, even the most trivial web page seems to require some tweaking to make sure it plays nicely in all the friggin' browsers out there. The hours spent figuring out why one browser's display is 1 pixel off from an other's add up to huge amounts over the course of a project.  My delay in downloading IE7 and Firefox 2 is simple denial on my part, I don't want to add to the load before I have to.

What I want to do is build my app and get it looking like I want it to look in ONE web browser.  Then I run it through the tool and it tweaks the CSS, HTML, and Javascript so it looks and works in a selected suite of browsers EXACTLY the same way.

There are books and articles, on what to look for, what to avoid, etc.  I've built up a little library of javascript that is fairly cross-browser savvy, but that's only part of the battle and at least that's programming.  HTML/CSS-compatability however is more of a one-off issue on a project by project basis, with the different layouts, images, fonts, etc. and this is where serious time can be wasted. Yes, there are CSS and HTML validators. But just because the CSS and HTML are valid doesn't mean they look right. Eye mean all these words R spelled write.

So, that's why I want/need/desire a tool to get me out of UI tweaking for all these browsers.  I just want to create an ideal page, press a button and a get a set of reworked goodies that work in them all.

It's probably too much to ask for, so I'll settle for world peace, or at least a bottle of vodka to help me relax after wrestling divs all day. 

There is one question, asked by ALL hiring managers, that if answered correctly will lead to:

- an instant offer

- a cash bonus

- an office with a window

Doesn't matter if you can't write code, have the logical skills of sleepy 2 year-old, or can't tell an integer from image, if you can master the answer to this one question, you will have that dream software developer's job. Even if you faked your way through the rest of the interview, even if the hiring manager thinks you're a driveling idiot -- if you can answer this one question correctly -- the job is yours.

It's how I got my first job.  I couldn't believe it worked.  But it did!

The question is...

You've waited this long, you can wait a little longer.

Because you should realize what happens when you answer that question, you are going to have start writing code, good code, code that works, code that can be maintained, or you'll be out interviewing again before you get to enjoy the view.

Do you want to take a job knowing only how to answer interview questions?  Interview question knowledge loses ALL its value immediately after the interview.

Perhaps it would be wise to broaden your knowledge portfolio to include some skills that are long term assets. Perhaps you should actually write an application or two.  Figure out how session state works, explore modeling relational data, build an object framework, create something that does what you want it to do, debug it, write it from scratch when you realize your first approach was loony. Research and answer questions on forums and mailing lists.  It is amazing what you can learn helping other people.

An interview is a date, it might get you into bed, but once you're there you better perform, or there will be someone else taking your place.

Are you ready for the question? Are you ready for the sure way to hop into a developer's bed?

If you are, you don't need to read it here.  You already know the question.

And the answer.

 

Questions like these are best asked and answered at three in the morning with a nearly empty bottle of vodka nearby, but until Web 3.0 becomes reality, we're stuck with  blogs.

 I'm here because:

a) I liked the Strong Coders logo (that's actually an artist's depiction of my right arm)

and

b) Ryan asked "Hey, you want a blog?"

Trusting soul that he is, he didn't bother to give me any content guidelines.  I'm sure he was hoping that I would provide insightful and informative design and development advice on a semi-regular basis.  And, I will, really.

But not tonight. Since this is my first post here, I feel like waxing philosopic, though in a technological sort of way.

I promise.

Really.

Like most of the poor souls reading this, I spend most of my waking hours figuring out how to get these confounded digital machines to do something useful, and to do so in a reasonable amount of time without killing myself or someone else.  The fact that most software works as well as it does frankly astounds me given the view from the inside of the sausage factory.  I think we all forget the mountain of technology that allows me to enter text, press a button and allow hundreds or thousands, (millions? ) of people to view those words seconds, hours or weeks later.  Try to count the individual applications, libraries, etc. that are needed to allow this communication -- it's a crazy big number.

Doing this and doing it mostly adequately requires an investment in time to learn the tools, techniques and tips, which of course get changed just as they are mastered. Anyone programming purely in M$ tools that last 10 years has probably moved from VB4 through VB 5, VB 6, ASP, .NET 1.1,  to .NET 2.0, and that's just on the front end, putting aside the various SQL Server and Access flavors at the back end. It also discounts the various communication tools: DDE, OLE, COM, MTS, COM+ and .NET Remoting and data access technologies: DAO, RDO, ADO, and ADO.NET.  And of course to do anything on the web  don't forget Javascript, HTML and CSS.

One is either constantly learning or constantly behind the curve.  Heck, even with constant learning I feel constantly behind the curve.

This hit home today when I was catching up on some email. One of the emails was  annoucing the impending release of Vista, IE7 and .NET 3.0 . Now, I've been more or less buried the past three months in a pile of code, refactoring, adding features, etc. in a .NET 1.1 app.  I was planning on migrating this  app to 2.0 next month, but the 3.0 announcement has me thinking I should just skip 2.0 entirely.  I didn't even know what 3.0 was all about until I headed to the link above. I've been about 40:60 2.0:1.1 for the past year and am getting comfortable with 2.0.  The first question that popped into my head was "Does this mean I'm going to need three versions of Visual Studio?" 

From a little reading, it doesn't appear so.  There are extensions for VS 2005 for all the 3.0 goodies.  The more I read, it appears that 3.0 is the release of features that were supposed to ship in 2.0.

Sigh.  I keep waiting for that day when code magically writes itself (originally promised in VB 1.0 or was it Case tools?) and I don't have to keep learning new syntaxes, libraries, operating systems, etc. to harness these infernal devices. In the meantime, looks like I need to attack that ever growing stack of MSDN magazines next to my desk and try to climb up the curve a bit -- or least keep from falling off.