Archive for the ‘IT’ Category

Paperless Offices

Wednesday, September 30th, 2009

I recently inherited a large set of files from a coworker who had moved on to greener pastures, by which I do not mean I received a zip full of Excel spreadsheets. These are honest to goodness paper files and folders. Working in IT, you would think that if the paperless office had arrived, it would at least be present in that department, if no other. Alas, it has not. This is the second set of files that I have inherited during my time here and my own set of files is getting to be fairly large. Most folders are stuffed with hand-written notes I took during various planning, scoping, and implementation stages.

The point here being, I am throwing no stones, but am making an observation: even in technical fields, few people are actually implementing paperless offices. If anything, the laser printer allows us to run off far more paper than ever before because its low threshold of use and expense allows people to use it for far more trivial things than would have ever been justified in the dark ages. Computers allow us to store more information than is readily doable with paper, in a more portable fashion (most laptops have enough hard drive space to carry libraries of information, available at the brush of the finger), more safely (some laptops and spare drives are a lot less of a fire hazard than cupboards stuffed with paper and cardboard), and more intelligibly (typed notes will be legible by anyone, whereas many people, like me, have terrible handwriting).

Here, it would almost be convenient to scapegoat the older workers and simply blame them. It is their dedication to the old order that keeps the rest of us from making progress. There is some small amount of truth here. We have probably all seen that one person who prints off every darn e-mail only to turn around and file it in a cabinet. However, this would be greatly oversimplified. When I was in college, I noticed that few computer science students used their laptops for notetaking. There were plenty of laptops in the room, mind you, but most of their owners were surfing or playing solitaire (I played solitaire through a solid semester of Jewish History–did well on the tests, though). The students who actually took notes did so, by and large, on notebooks or in binders. So, that old guy over there might abuse the printer a little more than usual, but he is not the real issue here after all, the younger generation who is growing up on iPods and Facebook, takes notes by hand.

The reasons for this, then, are more deep seated than a simple matter of generation. The sad truth for the proponent of the digital office is that computers are simply not convenient enough, yet, for this purpose. Notepads are still much more convenient than laptops for most purposes. When taking notes, it is not uncommon to be scribbling down diagrams and making outlines in ways that a computer may present better, but require a little more effort upfront. If you are typing your proposal, those extra few seconds to make the bullets look good is well worth it. If there is a flurry of talk in a meeting or during a lecture, those extra few seconds put you too far behind. Similarly, those diagrams may take, for a fast user, ten minutes to put together–but that ten minutes is simply too long when everything is happening realtime, especially when they can be sketched in seconds.

Laptops, as light as they are, are appreciably heavier so it is a lot more convenient to grab a notepad than to haul out the laptop. Battery life is also a concern. Despite advertising to the contrary, the best you can usually do is a few hours of battery time at full use. Sure, you can get more life if you don’t use the machine as much, but then it isn’t as useful either. This particular group of objections should be handled within the next few generations of hardware. With netbooks becoming more common, general laptop size decreasing, and battery life increasing, this should go away quite soon. Cost does not really seem to be an issue anymore. Most college students have laptops–virtually all have computers and could have had a laptop should they have so chosen. Like I wrote above, the problem was not that students did not have laptops, but that they were not using them to go paperless.

All right, then, if we can’t get people to use their computers yet, what about digitizing the output? At least, we could save the storage and remove that old fire hazard. Not necessarily a bad idea, but retyping and resketching all notes is quite time consuming. Scanning presents another option, but at several times the amount of storage (so, storing those notes as TIFFs instead of TXT or DOC will tax your drive space more) with greater difficulty reading (scans are often, especially with penciled or highlighted text, harder to read), loss of the ability to search (which, as Google, Apple, and Microsoft are all realizing, is one of the most important abilities of computerized documents), loss of flexibility (when things change, altering those TIFFs is a lot harder than changing a text document), and poor software interfaces (have you seen most document management systems?) make this a loss.

The real problem is ultimately one of convenience. We could bring our laptops to everything. We could type it all in Word or OpenOffice. We could use the touch pad to do all of our diagramming. But we don’t because it is not sufficiently convenient for the problem at hand and the reasons lie in both the hardware and the software.

On the hardware side of things, we need to see laptops that are even lighter (without loss in functionality; about the only thing I see being able to go is a CD drive–more and more software is web driven or, at least, could be deployed from another machine and more and more music is being stored digitally) with even longer batter life. Additionally, an easy way to make quick sketches is key. I am sure advancements could be made in diagramming software, but until someone can take a stylus and make a quick sketch as readily as they could with a pen, the laptop will still not be good enough. It would also help if the laptop screens were more like paper–in short, if we could see digital ink making its way from niche ebook readers onto laptops so that notes can be viewed cleanly and crisply in a way that will not tire the eyes the way traditional displays do.

On the software side of things, we need software that is more conducive to taking notes in the way that people take them in real life. Outliners are good, but people do not take perfectly outlined notes on the fly–nor can they be expected to. Often times, notes are taken in brainstorming or design sessions. These meetings cannot be organized or else they will lose all utility. One of the benefits of paper note taking is the loose, semi-organized way in which notes and diagrams can be taken and mixed up. This would need to be made available through software.

There is still the X factor. Speaking for myself, I enjoy the feel of handwriting and the look of paper. It is a relief after using computers and technology all day long to be able to look at and feel something different. I doubt that for me, personally, this will ever go away. However, by and large, except for a few strange people (like me; I even have a manual typewriter) this will fall away in the next generation or so leaving only the items above.

So, will we ever see the paperless office? I do not think that question can be answered with any degree of certainty. My personal point of view is that the hardware will be there within the next ten years. The software is a trickier proposition–it could happen at any time. Tomorrow someone could write the perfect software or it could take another thirty years. Even once this happens, paper will linger a while longer.

Web Servers in the Language du Jour

Tuesday, September 22nd, 2009

Has anyone besides me noticed an increased tendency for people to write new web servers in their language du jour? For example, we’ve got the WebServer CodePlex project to write one in C# .NET. Django packages one written in Python, for development purposes. Ruby has Mongrel. There is Hunchentoot for Common Lisp. Heck, I even found a Perl one on SourceForge whose last file release date was in 2000.

The height of absurdity comes with nanoweb, a web server written in PHP. That just seems wrong, like the programming gods should strike someone down for even thinking about it. That’s right. It’s not enough to watch the world blow security holes in PHP web applications, now they get to do it in PHP web servers, too. That’s just great.

Whatever happened to good old C-based web servers, like Apache? About the only one in that list I can really see is Django’s. It really does simplify development by allowing you to push deployment details off until you are ready to deploy. Visual Studio does the same thing when you are testing ASP.NET applications. The other ones, though, actually want to be production web servers. Django warns you against deploying on the development web server. About the only way you could use Visual Studio’s (which, dollars to donuts, is probably just a stripped down version of IIS) is to run the project in debug mode on the server in an instance of Visual Studio–which would be just plain stupid. Hunchentoot is also nice, because few web servers have good tools to integrate with Common Lisp. About the best you’ll do is straight CGI or mod_lisp–and, with mod_lisp, you will still have to interact with the module at a fairly low level (which I found disappointing).

If you are running a web application for the whole world to see, than you are far better off with a larger-scale HTTP server, like Apache, IIS, or Lighttpd. If you are using embedded applications, use one of the micro C-based servers–you’ll need those precious ounces of resources that C can save even more if you are embedding the thing in a printer or something like that.

Dumb quote of the day…

Monday, September 21st, 2009

“The value of comments should be obvious: in general, the clarity of a program is directly proportional to the number of comments.” –David Canfield Smith, “MLisp Users’ Guide” Stanford Artificial Intelligence Project, Memo AI-84, page 5.

I guess Mr. Smith never bumped into one of those programmers (we’ve all seen them), who do things like this:

i=i+1;
// add 1 to i

Such programmers fill the source with comments that contribute nothing to the understanding of the flow of the program. Or, how about someone who does this:

/*$foo='baz';
[Ed: snipped about three hundred lines ]
*/$a++;
printf('hello, world!');

The Smith Conjecture, as I do here and now dub it, is fatally flawed, doomed to be replaced with: “Programmers are in a race with the Universe to create bigger and better idiot-proof programs, while the Universe is trying to create bigger and better idiots. So far the Universe is winning.” (Richard Cook).

Perhaps, if the whole world were full of Donald Knuths, whose literate programming considered every bit of code as being like a piece of literature, things would be different. However, we have a lot more blub programmers running around abusing comments to their maximum. I would also argue that few real life systems can afford to self-document, whether done by hack programmers or true craftsmen. If you are building anything that is needed, there is probably little room for this approach because the world will keep changing and it will continue to change at such a rate that you cannot write another book every time it does.

ISO and ANSI are Irritating Me…

Monday, August 31st, 2009

Lately, as I have been swinging around various technologies I have been increasingly finding myself directed to various standards issued by the ISO. The latest ones (with reasons raging from curiosity to serious research) include ISO 8879, published in 1986 and specifying SGML the ancestor of HTML and XML, and ANSI/INCITS 319-1998 which specifies SmallTalk (this one I managed to find on the web in the form of its last draft). Now, maybe I am getting spoiled by the IETF, ECMA, and W3C, which release both their drafts and their final standards for free, but I find the prices that the ISO and ANSI charging are ridiculous.

In fact, I would argue that if you have to pay for a digital copy of the standard, then the whole point of standardization has been bypassed. Standardization allows anyone to pick up a copy of the standard and implement what it says with the expectation that it should work with other implementations (hey, that’s the theory; practice varies). Charging for paper copies is, of course, understandable and fair since it costs to put those together. When you charge for access to a standard, and especially when you charge a lot, it dramatically reduces the number of people able to attempt to implement it (slowing down the spread of standards-compliant versions of the technology). It also reduces the industry’s ability to check behavior and see if it matches the specification. Let us say, for example, that the World Wide Web Consortium charged ballpark $1,000 to have a copy of the XML 1.0 specification. I am using some XML parsing library and it does not behave as I expect. If the cost for the spec is $1,000, I cannot afford it. There are many companies who will refuse to afford it. After all, how valuable can that specification be? How can I check whether I am correct or if the parser is correct? I can’t.

Moreover, many of the people chairing these boards are professors or researchers in whatever technology they are working on. So their salaries are basically paid by someone else anyway. The rest of the costs of running the organization should be minimal. Both of these organizations are non-profits, ANSI being a private non-profit and the ISO being an NGO, so why charge for the standards? They are not supposed to be making a profit anyway (I, personally, think that non-profits and our entire tax structure are insane, but that is, again, another blog post), so why not disseminate the standards more widely?

This probably sounds like me deviating from my capitalist roots. It is not, really. That would be the case if I wanted some sort of governmental agency to handle standardizations (blasphemy!) or some sort of regulation enforcing the behavior I described above–but I believe nothing of the sort. The ANSI and ISO have every right in the world to try and make an industry out of technology standards, but I, as a consumer, have the right to try to refuse them. It all comes down to supply and demand and, I think, over the long haul the trend will go very much against the ISO and ANSI. I am sure some larger corporations are only too glad to whip out their wallets and pay up for these documents, but these are in the minority.

Over time, I am certain that ISO and ANSI will be forced to shift towards the policies of the IETF, ECMA, and W3C. For example, when Microsoft decided to publish a standard for C# and the .NET framework, they did not go to ISO and ANSI. Instead, they went to the ECMA. Most likely, this was done for reasons of time and expense, but this too is what differentiates the smaller organizations from the ISO and ANSI. The demand will continue to move in this direction, for more efficient standardization, cheaper standardization, and wider availability of said standards. Ultimately, all standards organizations have two bodies of clients: the standardizers and those who would read the standards. If no one publish specs through your organization, the rest does not matter. Similarly, if you publish specs that no one reads you will be irrelevant. It is ultimately in the best interests of both parties to have things quick, easy, and cheap. Let us say that Microsoft did not want their spec to be widely available. Why would they get it published at all? It would be easier to just use it for you dev teams and never let it see the light of day. With the advent of the world wide web, no one needs a standardization comittee to make their work widely available. A few minutes and a few dollars and it is up for the world to see. Largely, what these committees offer is prestige, but inaccessible prestige fails to serve either clientele.

The Days of the Cybersquatter are Limited

Wednesday, August 26th, 2009

Run any number of searches for domain names and you will find most of the truly good ones taken. This is a minor irritant when a legitimate organization or person of some kind is using it. What is annoying are the boatloads of domains that have been claimed by some person or organization who does nothing but put a page of banner ads for them–then attempts to sell said domain for copious quantities of cash. In short, these entities, known as cybersquatters, claim any domain name that they think someone might possibly want in hopes of cashing in big. Over time, I have heard various ideas for dealing with cybersquatters, most of which involve some regulatory agency (usually ICANN) stepping in. The US has already put some laws into place to help combat this. Really, ICANN, the US, India, and whoever else may take an interest in this should just forget it. The market will work this out and it has already begun to.

The economics of cybersquatting rely on the given domain name being so important that some other person or entity feels they have no choice but to pay an exorbitant sum to acquire or reacquire the domain. This motivation is dying and with it will die the profits, real or imagined, that can be obtained through cybersquatting. For established businesses the motivation is, rightfully, a powerful one. People expect that if they go to ibm.com it will take them to the website of International Business Machines. It is simply too big a company to expect otherwise. Most of these establishments have already acquired the domains they wanted or needed. IBM will not likely lose a domain name any time soon. Even if there were once some large sums made, the big dogs are done playing this game. New businesses by and large cannot afford (or are unwilling to afford) the purchase of a squatted domain. Instead, the choice of business name is made alongside the search for a domain name. If a suitable domain cannot be had, people are moving towards choosing another name rather than pay what amounts to protection money. Squatters are, no doubt, are still attracted to this little get rich quick scheme  because money really has been made that way in the past. Those profits are dwindling and will continue to dwindle until only a few foolish people continue to attempt it. In that day, cybersquatting will be all but dead–without the help of any bumbling, meddling regulatory agency.

A Quick Rant

Monday, August 17th, 2009

For a language that is supposed to be web oriented, PHP really stinks for setting up web services. Take the default SOAP library. It let’s you set up a request handler and populate it with methods, but it has no mechanism for automatically generating WSDL. What the heck? In ASP.NET, when I code up a class and mark methods as WebMethods, the WSDL is built automatically. With the default SOAP library, you have to provide a URI to the WSDL. In short, you have to use a 3rd party WSDL generator or write it by hand. Why in the heck would anyone want to do that? And even if you add a 3rd party tool, it adds one unnecessary step to the process if you make changes: you now have to regenerate the WSDL if you change the signature of a method, add a new method, or drop an existing one. NuSOAP is a little better, but come on. This is the default library. It is fine to consume web services, but who would ever want to write a full blown web service in this environment?

On Cargo-Culting

Tuesday, August 4th, 2009

Like many a working programmer, I get to see the results of cargo cult programming a lot. To those of us who know better, it is evil, but I decided to sit down and write up a quick article on why it is evil. After all, the very reason that most cargo culters cargo cult is that they do not believe that it is evil.

Here is my composite picture of a cargo cult programmer: our cargo-culter is Joe Cargo (I’m feeling creative today). Joe’s interest in computers is mild. There is probably a fascinating story of how he got stuck in IT in the first place. Maybe it started out by setting up a wiki for a few friends. Or doing a quick and dirty website for a local ma and pa shop. Perhaps he worked at Megacorp, where the path to IT aid is a mile long trail of paper and he got conscripted by his real department to fill the gap in their IT resources, only to find his stopgap skills worth more than whatever it was he got hired for (as though anyone could remember). In any event, he never really moved beyond that point. He surfs the web and slaps together whatever kind of, almost, sort of, probably, if you don’t look at it cockeyed works to complete the task at hand. He has no formal training and has never given any thought to what “best practices” would be. Manual, repetitive work is a way of life. He does not give it a second thought. Almost every other job in the world is based around repetitious labor, why should this be any different? Joe meanders from project to project and company to company always in the dark as to the real world of programming and computer science. If Joe ever meets a true practitioner of the craft, he would regard him as a wizard, dark and terrible, but useful.

Joe Cargo is probably fairly proud of his work. Not excited by his craft, but satisfied with a job that he believes is well done. It runs, after all and there are a lot of lines packed into a lot of files. He probably has no clue that someone more skilled than he, let’s call him Sam Sixpack, views the whole creation as the spawn of Satan. Sam Sixpack looks at Joe Cargo’s work and sees unnormalized tables–and I don’t mean the kind that should be 5NF. No, I mean the 250 column wide variety with repetitive data and would-be primary keys that are based on names that are not always consistent. He sees work that takes hours to run, rather than minutes, worst case. He sees code that has been copied and pasted all over the code base, rather than centralized in a function, class, module, or what have you. When Sam sees this, he groans at the hours it will take him to fix or update every single instance of that one block of code. Sam sees code that feels dirty, rather than clean or elegant. It lacks formatting, it rambles, it does unnecessary work. In general, it just does not make sense.

If we assume that this is a reasonably accurate composite of most cargo culters, it is not too hard to examine it and pick out the hows and the whys. Why is easy. Cargo culting is the result of laziness. Larry Wall once wrote that one of the virtues of a programmer was laziness, but this is another kind of laziness. The laziness that Wall wrote about was a programmer who refused to do work that could be automated and, so, would put in extra work to save manual effort in the future. Cargo culting is based on a laziness, not of overall work, but of the mind. They cannot be bothered to think. They see something, but it would require straining the brain too much to understand it. If everyone took this approach to technology, we would still be pushing rocks around with our bare hands because no one would have seen the utility in investing in tools.

What can those of us who care more do? Unfortunately, not much. Cargo culters got where they are through sheer sloth. If they could not be bothered to learn on their own, when computer books, articles, and resources are plentiful (or even just learn from the code they steal on a regular basis) there will not be much that you can teach them. Those who want to learn, learn more from having a knowledgeable person nearby. Those who do not, will not learn anything either way. In the final analysis, cargo culting is like any other form of laziness in business. It can only be handled by the person in question shaping up or shipping out.

It is sad because it is bad for everyone, whether they realize it or not. Businesses get sloppy, second rate software. Users get a tool that is often the bane of their very waking existence. Next-gen coders get headaches from trying to clean up the mess sufficiently to keep their own jobs. Finally, the cargo culters themselves get a bad time of it. The fruits of this mudball building cannot be hidden indefinitely, even if the cause of it can. The cargo culter may be fired, or leave under increasing pressure to maintain the impossible. In any event, they do not get the best they could have, had they built something well. Their own skills (what few they have) decrease in value, since the culter does not learn (if they did, they would not remain cargo culters) and keep up with an ever changing industry. So, just remember, when you see a cargo culter, you see a history of everyone involved losing.

Grokking IIF

Thursday, June 18th, 2009

Sometimes, the best way to integrate to applications is to give up on automatic interfacing and just dump out some common data that can be imported/exported as needed. Recently, an application I was working on reached this point with the QuickBooks API. So, I implemented the relevant exports from the primary application to IIF (Intuit Import Format) and I thought I would go ahead and post some notes on using it. IIF is a tab (hard tabs, not spaces) delimited format that is, in its evil heart, a hybrid approach between EDI and CSV.

An IIF file basically comes down to two components, repeated endlessly (well, almost; the QuickBooks KB has some notes on the process and gives the transaction limit as being at 10,000):

  1. A specification section (which, as its ad-hoc name implies, specifies the format to be used)
  2. A data section

In the specification section, we basically tell the importer what format is going to be used for the transaction. It is really just a list of fields and in which order they will occur. The data section, on the other hand, follows the template specified by the specification section, providing data in the order in which it was specified. So, to take apart one of the examples:

!TRNS    TRNSID    TRNSTYPE    DATE    ACCNT    NAME    CLASS    AMOUNT    DOCNUM    MEMO    CLEAR    TOPRINT    ADDR5    DUEDATE    TERMS
!SPL    SPLID    TRNSTYPE    DATE    ACCNT    NAME    CLASS    AMOUNT    DOCNUM    MEMO    CLEAR    QNTY    REIMBEXP    SERVICEDATE    OTHER2
!ENDTRNS
TRNS        BILL    7/16/98    Accounts Payable    Bayshore Water        -59.25            N    N        8/15/98    Net 30
SPL        BILL    7/16/98    Utilities:Water            59.25            N        NOTHING    0/0/0
ENDTRNS

For emphasis sake: this is a hard tab delimited format, so the spacing shown by this page is a little deceptive. Using C-style escapes (\t for tab, in case you were wondering), the file looks like:

!TRNS\tTRNSID\tTRNSTYPE\tDATE\tACCNT\tNAME\tCLASS\tAMOUNT\tDOCNUM\tMEMO\tCLEAR\tTOPRINT\tADDR5\tDUEDATE\tTERMS
!SPL\tSPLID\tTRNSTYPE\tDATE\tACCNT\tNAME\tCLASS\tAMOUNT\tDOCNUM\tMEMO\tCLEAR\tQNTY\tREIMBEXP\tSERVICEDATE\tOTHER2
!ENDTRNS\t\t\t\t\t\t\t\t\t\t\t\t\t\t
TRNS\t\tBILL\t7/16/98\tAccounts Payable\tBayshore Water\t\t-59.25\t\t\tN\tN\t\t8/15/98\tNet 30
SPL\t\tBILL\t7/16/98\tUtilities:Water\t\t\t59.25\t\t\tN\t\tNOTHING\t0/0/0\t
ENDTRNS\t\t\t\t\t\t\t\t\t\t\t\t\t\t

Which is a lot denser, but also a lot more precise. Any line beginning with an exclamation point (!) is one of the specification lines.

!TRNS    TRNSID    TRNSTYPE    DATE    ACCNT    NAME    CLASS    AMOUNT    DOCNUM    MEMO    CLEAR    TOPRINT    ADDR5    DUEDATE    TERMS

So, this line is specifying that the data to be imported is a transaction (which includes bills, invoices, and several other items), which has the following fields in order: transaction ID (I’ve never used this in my imports; your mileage may vary, though), transaction type (BILL in the case above), date (which will be the bill date here; in other places it has slightly different meanings; check the docs), account (AP), name (name of the entity sending the bill; more on this in a moment), class, the total amount of the bill, document number (reference number, for a bill), memo, whether or not it has cleared, whether or not this bill needs to be printed, an address, due date and terms.

A note on names: these names must match exactly what QuickBooks has on file. If it does not, the IIF importer will create the value automatically. So, if you want to import a bill from “Somecorp”, but type it in “Somecorp, Ltd.” a new vendor “Somecorp, Ltd.” will be created with the bill. This applies to all name-based items in the file, making the IIF import a little tricky and fairly dangerous. Many entities in QuickBooks are hierarchichal, so if you want, for example, a class of “bar” which is a subclass of “foo”, you would specify it as “foo:bar”. Excluding quotation marks, with the colon, and no spaces between the colon and either “foo” or “bar”.

The source listed below links a zip file with information on the IIF format. It is sparse, but enough to get going. It has some example IIF files (including the one dissected above) and some HTML files specifying which fields are available and/or required for each type of data to import. It is also important to realize that IIF imports are officially deprecated, so be aware of this when writing your own importer/exporter.

Sources

Am I the only one who thinks…

Thursday, June 11th, 2009

…that having Google Desktop integrate into QuickBooks is a recipe for disaster?

QuickBooks and ASP.NET

Sunday, October 12th, 2008

Let’s start out with a scenario: we have a series of web apps for internal use (running on LAMP boxes) and we want the data to be pushed into QuickBooks semi-automagically. We wanted more magic and less semi, but the accountants wouldn’t let us. At any rate, we wanted to keep the same setup. We eventually got things working, more or less, by running a web service in ASP.NET on IIS on the same machine as a Quickbooks instance and letting the PHP side talk to that through SOAP. It works pretty well on the whole, but getting QuickBooks to interoperate with ASP.NET turned out to be a pain. After Googling, trial, and error, here are the steps I took to get the libraries to work all happily:

  • Install QBFC and qbXMLRP2; if you installed the SDK, the installers will exists on your hard drive. The filenames are:
    • QBFC8_0Installer.exe (install with the command  QBFC8_0Installer.exe /v”ALLUSERS=1″)
    • qbXMLRP2e.exe (install with the command qbXMLRP2e.exe /RegServer)
  • Go to Control Panel->Administrative Tools-> Component Services
  • From there, navigate to Console Root->Component Services->Computers-> My Computer->DCOM Config
  • Right click on qbXMLRp2e and select properties
  • Here, you are going to grant permissions to the various users associated with an ASP.NET call so that the COM calls can be made
    • Click ‘Customize’ in the ‘Launch and Activation Settings’ section
      • Grant ‘Local Launch’ and ‘Local Activation’ permissions to the following users:
        • Network Service
        • ASPNET
        • IUSR_MACHINENAME
        • IWAM_MACHINENAME
        • INTERACTIVE
      • Where you need to substitute the name of your machine for ‘MACHINENAME’
    • Click ‘Customize’ in the ‘Access Permissions’ page
      • To the same users above, grant ‘Local Access’
  • Finally, fire up QuickBooks and log in (preferably, with a user specially created for the purpose).

The long and short of it is making sure that the correct permissions are assigned to the correct COM components. In our setup, we left QuickBooks running constantly on a dedicated Windows XP virtual machine. I am unsure whether there is a better way to handle this, but it does not really seem like there is.
References