New ManuSoft web site

After over 10 years of the same infrastructure and the same look and feel, the ManuSoft web site has finally been given an overhaul. The original web site used Perl scripts that I wrote myself to serve up pages by patching together a header, table-of-contents, and main content frame and displaying it either as a 3-frame web page or by using an HTML <table> to format the layout. It wasn’t exactly pretty, but it functioned well and served its purpose for a long time.

So what prompted the new design? Primarily my desire to make it easier for customers to download updates to previously purchased software. The old web site used a rather simplistic authentication system that resulted in me spending a lot of time looking up order numbers for customers who had lost their order information. There also was no automated way for customers to update their own registration information, so I had to do that as well.

The new web site requires only a user name and password, both of which can be retrieved or reset simply by entering the email address for the account. Hopefully this will reduce the need for manual intervention. If you purchased ManuSoft software in the past, please visit the Customer Service page now to activate your account (in the Legacy Account section).

I used Joomla for the content management system and VirtueMart for the shopping cart, both of them heavily customized. The template I chose doesn’t work correctly with IE6, but later versions of IE, FireFox, Opera, and Chrome seem to work pretty well (except that, ironically, my Google Translate widget displays incorrectly in Chrome).

I think the new site looks a bit nicer and more modern than the old one, although it’s still amateur by most standards. As long as it serves its purpose of making both yours and my job easier, I’m satisfied.

If you want it done right…

I’ve proved once again that if you want it done right, you have to do it yourself. The ManuSoft web site is fully functional again after my longtime ISP had a major network meltdown. I waited for two weeks for them to repair it, then finally moved to a different provider. The new provider’s promised “24/7 tech support” turned out to mean “24 hours to respond, 7 days to fix” every problem, not to mention that I would need to provide step by step instructions to their techs so they could configure the server the way I needed. After two weeks of that, I gave up and configured my own server and now host it myself.

Let this be a warning to all of you hosting web sites with reputable providers, or storing your data somewhere in the cloud. I paid big bucks every month to my old provider for secure servers, redundant power supplies, managed and air conditioned server rooms, nightly backups, 99% uptime, etc., but they still lost everything. Almost a month later they still haven’t restored their customers’ data. Luckily, I make my own backups.

Autodesk Discussion Group Facelift Offer

My participation in the Autodesk discussion groups has been severely curtailed since the notorious “upgrade” a few months ago. One of the many problems introduced by the upgrade is the loss of formatting. It’s now virtually impossible to post messages that include inline AutoLISP or ObjectARX code without them being reformatted into unreadable garbage. Even attaching the code as a file is difficult (the “solution” is to rename files with a .txt extension!) As a result, many queries for programming help go unanswered. Autodesk has made an attempt to provide a fix, but a survey of the posts in any of the programming groups shows that it’s not working*.

* [Thread has been removed by Autodesk, so link was changed to point to archived thread.]

The recently announced layoffs and related cost cutting measures at Autodesk have dimmed my hopes for a resolution. Therefore, I’ve decided to offer my services to fix the problem. Autodesk, I’m offering to donate my time to fix your discussion group software. Just give me access to a development and testing platform, and the right to modify or rewrite the code.

Readers, can I get an “Amen”?

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.