Chad Osgood's Blog

Chad Osgood's Old, Expired Blog
Why do you take so long?

On more occasions than I like, I've been asked by pointy-hairs why my initial efforts in a given project take "so long" [1].  My mentality with regards to almost anything development-related is to put forth more effort initially so that I can put forth less later on.  If you compound the time savings for subsequent uses of your project, your initial efforts will look very small. 

A recent example of the above would be a small tool that I wrote to convert a bill-of-materials data file from a client's business software and convert it to a tabular format for use in a relational database.  A lot of older business software platforms seem to like using monolithic data structures with all the information for a given record on the same row; makes it difficult to generate reports.  It took someone else a little over a half an hour to perform the conversion.  It took me a little over an hour to build a tool in C# to perform the conversion.  It takes the former a little over a half an hour each time.  It takes me less than 2 minutes each time using my tool.  You can easily see the time savings here, but that is not what is at issue.  This is a fundamental difference in thought process, and the perception of those who would rather repeat a task every time will always perceive those who hack out tools as being slow--at least initially.  This applies to almost all facets of development, not just tools.  

Even when there is a need to develop a "disposable" tool, a tool which is ostensibly useful only a single time, they seem to find a way to recycle themselves in the future.  I'd say it's a conscious decision on my part to always build a recycleable tool even for remedial tasks, but it's not; I can't think any other way.  I believe most developers are this way, and so does Steve McConnell:

Suppose you're given five hours to do the job and you have a choice:

  1. Do the job comfortably in five hours, or
  2. Spend four hours and 45 minutes feverishly building a tool to do the job, and then have the tool do the job in 15 minutes.

[Code Complete p505]

When I was thinking about this, I remembered reading the above in Code Complete many years back, so it seems a lot of what I read really did stick with me.  A lot of technical books I assimilate then expunge. 

I will stick with my current mentality.  If I do one task more than once and the second time around it takes the same amount of time as the first, something is wrong. 

[1] The perception of "so long" is usually without reference to the equivalent that takes less than "so long", so it's entirely subjective.

Generating a database schema from an XML schema

I have been looking for xsd2db, a tool for generating a database schema from an XML schema, ever since I read this article.  Unfortunately, when it came time for me to recall the location of the tool I had forgotten where I found it in the first place (I'm sometimes lazy on my bookmarks).  Thanks to Mike Gunderloy's most recent Daily Grind, I was able to locate the tool.

It works as promised, and I was able to create a database with the appropriate entities for a few complex types defined in my XSD for a SQL Server database and an Access database. 

Why C# developers earn more

A while ago I posted a link to the first salary survey I had seen that included .NET developers.  It seems a lot of devs got riled up about the difference in pay between C# and VB.NET developers, so they just released a short article explaining why they feel there was indeed a discrepancy.

I haven't personally noticed the discrepancy their data suggests, and although the reasoning in the article for the discrepancy largely echoes what those in blogspace felt as well, I think we'll get to a point where it is less so.

Interoperability with antiquated systems

I do a lot of work in the integration world, primarily with (often older) accounting systems like Mas90, Great Plains, and SouthWare.  At face-value, these systems appear extremely antiquated, but a lot of the plumbing I have seen is very precocious indeed.  It's interesting to see how many of these systems are so modular; built with extensibility in mind before extensibility became the word du jour.  It's not as though modularity is a new concept, but I find it intriguing how well some of these systems were designed sans some of the facilities we current developers have in our tools/languages.  We devs constantly argue about extensibility points in our software, yet these guys have been getting it right for decades.  Perhaps we have too many choices?

What brought this about is a new project with fairly extensive reporting requirements.  To facilitate this in the past, I've often had to export flat files from the accounting system, import them (DTS, BCP) into SQL Server, then create a report on that data instead.  This is sometimes a problematic exercise, as sometimes links between the accounting systems and SQL Server break (especially since many of these accounting systems are Unix-only which necessitates a third-party SMB daemon), but it does work.  I've long wanted the remove the middleman and just consume the data directly from the accounting systems, something of which is not available on these older systems. 

Fast forward to two hours ago when I learned that SouthWare has the ability to define an XML data dictionary; a map between XML elements and fields in their COBOL (*gasp*) files.  SouthWare also has the ability to define data dictionaries between different formats, including SQL Server; a clear extensibility point.  Big deal, right?  Many systems these days embrace interoperability, and XML is the lingua franca.

Considering that I can now run reports within the accounting system that output an XML file, I can publish said file to a web server running on the Unix box.  I can then easily consume this XML in my favored world of .NET, apply my XSLT stylesheet to it for reports, and even employ an MVC framework like Maverick.NET to handle a lot of the plumbing for me.  If I have enough coffee in any given day, I could even build a web service around it on the Unix side using Axis.

It's great to see how pervasive XML has become, and it's intriguing to see how well the new paradigm fits in with these systems that were built, in many cases, decades ago.  I wonder if our current work will have that sort of staying power when the next paradigm shift hits?

Internet C++: Internet Virtual Machine

I saw this via the Win Tech: Off Topic list.

You can have the real thing. Why program in proprietary languages, such as Java and C-Sharp that are incompatible derivatives of C++? Tried and tested standards, C and C++ are the most widely used programming languages worldwide. With the Internet Virtual Machine, they come with runtime portability.

[IVM

More on hungarian notation and field prefixing

Frans is talking about ceasing the use of HN.  Variable naming is a pet peave of mine, especially when HN is misused; indicating type as opposed to intent.  For example, most VBers assimilated something like the following for integral values:

int for Integer
lng for Long
etc. 

The above HN prefixes tightly couple the type to the name thereby necessitating the renaming of the variable should the type change.  Unfortunately, I've seen many cases where they simply left the prefix alone and changed the type (analogous to out-of-sync comments). 

VB isn't alone in this regard, as much of the Win32 API is riddled with WORDs, DWORDs, etc. with their respective prefixes 'w' and 'dw.'  Instead, I prefer to use a prefix like the following:

n for Number
s for String
h for Handle
etc.

This is similar to some of the HN styles you see in C code.  The difference is that it shows intent, not type.

Frans had issue with reserved keywords when declaring a variable sans HN:

Well, a little. I'm still convinced Hungarian Coding is necessary. F.e. I had an input parameter 'iOperator'. You can't change that to 'operator' because that's a reserved keyword. 

While I can certainly understand that, I have to argue that "operator" is not a very descriptive name.  It seems ambiguous, so I would further quality it: operatorID, operatorName, operator.  I try to follow the camel-cased variable naming format of entityAttribute or attributeEntity.  I admit I don't have a standard that I follow, but the following would be good names in my opinion:

inputFilename
filenameInput
employeeAge
etc.

Of course, the use of the entity name is not always needed as it would be superfluous to name something employeeAge in class Employee.

Member prefixing is another advantage, however you can also have that with your caMel cased members, f.e. by using a '_' prefix.

I've never enjoyed the use of _ prefixes for private fields either, but it seems most prefer this style.  I've always preferred to be explicit as possible.  What follows is an extremely contrived example:

public class Employee
{
 private int age;

 
 public Employee(int age)
 {
  this.age = age;
 }
 
 public int Age
 {
  get { return this.age;  }
  set { this.age = value; }
 }
 
 public void DoWork()
 {
  this.DoInstanceWork()
  Employee.DoStaticWork()
 }
 
 public void DoInstanceWork()
 {
 }
 
 public static void DoStaticWork()
 {
 }
}

Explicit and unambiguous.  When I reference instance members, I use 'this.'  When I reference class members, I use the class name.  This ensures that there is never an ambiguous reference to a member when there are locals of the same name.

Any opinions on this style?

Car accident and random musings

I had a car accident a couple of days ago, and although it was not severe (my car would claim otherwise), it was enough for me to feel quite horrible indeed.  I have what feels like a horrible sinus headache, blurred vision, diminished hearing, etc..  Needless to say it's difficult for me to concentrate, so I actually went a day where I thought of .NET for less than a few hours.  Lets hope that doesn't happen again.

Enough whining.  Just be careful out there; never know who will decide to pull out in front of you :-)  Now for a couple of pseudo-random musings...

The police officer who handled my accident had a laptop running Windows 98 with an application written in VB6 (the icons, controls used, message box format, etc, were dead giveaways) using some TTS engine.  I think he became annoyed with my inundation of tech-related questions, and probably also because I was hovering over his laptop the entire time he was entering in all the information.  He was able to pull my information in real-time; anyone know what communications equipment they use?  That would have been a cool project to work on. 

This XSLT tip is good to know, as I had used msxsl:script as well when I ran into performance problems with XSLT templates; I didn't even think of trying to use .NET facilities.  Sometimes it's almost too convenient to resort to msxsl:script, especially since some ostensibly simple things in XSLT are quite difficult.  XSLT 2.0 should help balance things out.  I'm guessing we won't get XSLT 2.0 in the .NET BCL or in the MSXML SDK until it at least becomes a recommendation, but the latest Saxon release includes some of the facilities defined in the working draft.   

I had a discussion with the president of my company regarding .NET adoptance.  We have several medium-sized .NET projects coming up, and he had heard that .NET adoptance was low.  This wasn't surprising to me, but I believe I was able to instill a level of confidence. 

 

 

TSQL snafus in Query Analyzer

I do 90% of my raw TSQL work in Query Analyzer, so that means I often have statements with a significant potential snafu factor (e.g. truncate, delete, drop, etc.).  Once upon a very late and long day I was cleaning up anomalous orders for one of our ecommerce customers when I accidentally hit F5 against a batch of statements, including one that deleted legitimate orders.  I immediately segued into the snafu realization state and permuted all feasible exit strategies from my office, including the roof.  Realizing the futility of escape, I restored the orders from backup and vowed to always do the following when working in Query Analyzer:

  • Always put a comment around my entire TSQL "workspace."  This way, no statement is executed unless I explicitly selected it and hit F5 (or right-click execute).  For example:

/*

truncate table VeryImportantTableThatYouShouldntBeTruncatingAnyway

insert into SomeTable (field, ...) values (...)

*/

You do lose syntax highlighting, but I have to argue that if you don't know the keywords well enough already you probably shouldn't be using them anyway.

  • Always write the criteria first.  If I'm going to be removing any records from a table, I always begin with the where clause first.

Simple safeguards that have worked well for me over the years. 

I prefer to do much of my TSQL by hand, as Access'esque query designers have always annoyed me.  I prefer having raw access to my data, so Query Analyzer is definitely my tool of choice; however, as with anything raw, caveat emptor.  The Query Analyzer in SQL Server 2k is also vastly superior to that of SQL Server 7's.  I wonder what, if anything, will change with the Yukon release?      

I'm a CLI monkey

I admit it, I can't live without my CLI.  I have so many tools, many of which I wrote myself, that are CLI only.  I have a single \dev\bin directory that houses most of my development-related tools, and in most cases I can simply get more done than using a functionally analogous GUI-based tool.  

I think there's something to be said for the Unix toolbox philosophy, to "Write programs that do one thing and do it well."  Whenever I look for a new tool, I almost always go for the lighter tool that is functionally granular.  This seems to be somewhat of a disregarded notion these days, as even current Unix tools employ the idea of swiss-army knife functionality.

I'm also going to admit that I had an initial aversion to adopting VS.NET.  I think this is because I employ more of a combinatorial learning pattern as opposed to a decompositional learning pattern.  In other words, I prefer to take many well-understood discreet ideas and combine them to achieve a more profound result, whereas using all the little incantations performed by VS.NET would require me to decompose the ideas into their underlying functional counterparts.

I also find this to be true in books, as I largely prefer reading a book on the CLR internals versus reading how to drag a datagrid on a web form.  Being completely abstracted from the internals of things has always irked me, thus my affinity for the CLI. 

All that being said, I do indeed use VS.NET; I couldn't live without it; however, I still have UltraEdit and a CLI window open at all times, and I still prefer to have more control over things like the build process.

Moving RSS feeds

For those that don't know, I created the initial RSS feed for Fabrice's list of .NET tools.  Fabrice is creating his own set of feeds, so the question came up as to how I should go about letting feed subscribers know that the feed has been moved.  I had planned on just emitting a single RSS item letting them know the feed has moved, and Fabrice confirmed his wishes that I do this as well.

Is this the most polite way to move a feed?

More Posts « Previous page - Next page »