May 2003 - Posts
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.
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.
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?
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]
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?
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.
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 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.
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?
Clemens noted this article on the new features for J2SE 1.5. It's a bit ironic to me that they (Gosling and friends) included features they downplayed (read: criticized) about C# a few years back. It does look like they beat us to generics though...
It's nice to see .NET become that which is (at least in part) imitated. I wonder what will happen when the .NET Framework v2 is released?
More Posts
Next page »