Lamenting

In some ways the CAD software industry is a lot like the fashion industry. The movers and shakers are trying to establish new fads that are just recycled from older fads, while guiding the unwashed masses into adopting new trends that have been carefully molded to ensure perpetuation of the system. Meanwhile the up and comers try desperately to get a share of the action, while an entire industry of hangers-on tries to eke out a living from the scraps left behind by the big players.

It’s a tired old symphony played on the world stage, with pretty much the same players today as twenty years ago. The same seamstresses making the same old faux fluff, dressing it up a bit, draping it over a new model, and parading it down the same old runways.

Bah! I’m going outside, maybe that’ll cheer me up.

This Just In: Microsoft Patents Photons

No, Microsoft didn’t really try to patent photons, but check out the the ironic twists described in this account of a recent US Supreme Court hearing. Here’s a summary (exaggerated a bit for effect):
1. Microsoft argues that software is not patentable, therefore it is not guilty of patent infringement.
2. The US Government argues on Microsoft’s behalf that software is patentable, but photons are not.

DWFx: The Emperor’s New Clothes?

I pointed out in a previous post that while the press release headlines pronounced that Vista will support DWF natively, the fine print says otherwise. What Vista does support natively is Microsoft’s new XPS (XML Paper Specification) format. Autodesk has since clarified that they are working on a new DWF format called DWFx that is, essentially, a DWF in XPS format.

A quick test verified my suspicions that XPS files produced by the Microsoft XPS Document Writer are much larger than comparable DWF files. The jury is still out on DWFx file sizes, but a recent post on Scott Sheppard’s blog (http://dwf.blogs.com:80/beyond_the_paper/2007/02/autocad_2008_dw.html) has buried within it a telling comparison point between DWF and DWFx.

The chart uses a neat gambit by comparing both DWF and DWFx file sizes to the completely different DWG format, but the math cognoscenti among you will notice that “typically 1/20 the size of the DWG” for DWF and “typically 1/10 the size of the DWG” for DWFx translates into “DWFx files are twice as large as DWF”. There is no information on file generation times, another metric worth monitoring.

Autodesk has been pretty generous lately, first giving away Design Review, now perhaps gearing up for an exclusive two-for-the-price-of-one deal on DWFx. I haven’t heard too many customers requesting larger file sizes, though.

Introducing OpenDCL for AutoCAD

AutoLISP programmers may remember a product named ObjectDCL, by 3rd Day Software. ObjectDCL was released as open source in the summer of 2006 by developer Chad Wanless due to his inability to continue supporting the software because of “health reasons”. At the time, many users of ObjectDCL hoped that someone would update the code to work in AutoCAD 2007. Programmer David Robison did some work to get AutoCAD 2007 supported, but the project has been languishing, almost to the point of extinction.

After being asked by several ObjectDCL users whether I could help, I decided a few weeks ago to contribute to the community by getting the original C++ code updated to support AutoCAD 2007. As I am wont to do, I’ve ended up re-architecting much of the code in the process.

The results of my work are available now at the new OpenDCL project on SourceForge. The new 4.0 release is still in the alpha testing phase. If you program in AutoLISP and want to create rich user interfaces for your applications, check it out!

I’ll take web sites for $200, Alex: Part IV

(continued from Part III)

Creating custom modules for DotNetNuke is an esoteric process that I don’t recommend unless you’re prepared to invest quite a bit of time and effort. I slogged through the process because I’m too stubborn to quit, but it’s hardly worth the investment in time for a one-off custom module. I don’t expect many of my readers to try it anyway, so I won’t bother describing the technical aspects in any detail.

My primary objective was to create a Docket History module that renders a court case’s docket history in an HTML table. Since DotNetNuke modules (generally) render data from a database, a large part of my work was defining the database structures and database interface code. The database work was an opportunity to learn more about SQL syntax, something I had never really delved into very deeply in the past. As the module began taking shape, I found myself having to refactor over and over again, often changing the database structure in the process. Changing the database structure meant recreating the data and rewriting the database interface code.

Once I had a working Docket History module, I decided to apply what I had learned to a second custom module for the Grapevine page of the web site. This module would simply display a date-ordered list of links to external web pages, including a column for the “Source” of the linked page — a bit less complicated than my first module. It should come as no surprise that the second one took about a tenth as much time as the first, mainly because I spent much less time refactoring. That doesn’t mean I got it right the first time. In fact, I eventually went back and made yet more changes to the first module to reflect the optimizations and design improvements I discovered while working on the second.

To recap, the web site today consists of DotNetNuke 4.4.0 “out-of-the-box” (I upgraded to 4.4.0 from the original 4.3.7 after 4.4.0 shipped in late December), a free skin from Nina’s Free Skins, the two custom modules I created, and a bug fix to correct a PDF file download issue as described in a DotNetNuke forum thread. Total time spent was around 200 hours over four weeks. Finally, a complete web site — or was it? In Part V, find out what the last missing ingredient was.