« December 21, 2004 | Main | December 23, 2004 »
December 22, 2004
Adobe Fallout and Resolution of Adobe Download Manager Problems
Saturday, I complained that Adobe had sold me a piece of software and then failed to deliver. The problem was the download manager dumped core as soon as it started up. I sent an email to Adobe support and got back a long list of instructions. They didn't help. Here's my second note to Adobe:
No joy. I followed these instructions. The ADM downloads and when I launch it, it says "Safari, IE, and Mozilla must quit to run this application" I say OK, it kills the browser windows, runs the installer (which installs ADM as Applications:Utilities:Adobe Download Manager), and then launches ADM. Almost immediately, I get "ADM has unexpectedly quit. Submit a report?" I'm running OS X 10.3.7.
Adobe responded with a note that was so general that I wondered if they any idea of the history:
Hello Phil,
Thank you for contacting Adobe Customer Service.
It could be that there are download managers within the browsers that you have mentioned that could be conflicting with the Adobe Download Manager.
It appears your order for the Photoshop Elements 3.0 has been 'requested' as you have begun the download.
I am re-enabling the product. The download manager should be replaced with an updated version and the download should proceed accordingly.
I hope this information helps to resolve your issue with downloading your Photoshop Elements 3.0 to your computer. If the issue is not resolved please call the customer service number below for more immediate service.
For more information on Adobe¨ products or services please visit us at: http://www.adobe.com or contact Adobe customer services at 1 (800) 833-6687. Customer Service Representatives are available 6:00am-8:00pm PST, 7 days a week.
Best Regards,
Jacqueline S.
Adobe Customer Service
I struck out on my own and found out that not only does the ADM install itself in Applications:Utilities, but it also puts a plug-in in ~/Library/Internet Plug-ins. I deleted both the ADM application and its plug-in and, viola, things works. Apparently ADM can't deal with an old version of its own plug-in and doesn't overwrite it or check it. So, I'm in business, three days later, no thanks to Adobe Support.
03:45 PM | Comments (0) | Recommend This | Print This
Using Virtualization in Software Testing
The January 2005 issue of Dr. Dobb's Journal contains an article (unfortunately not available online) by Sam Tregar on using Perl and VMWare GSX to test builds of Krang. Rather than having a large farm of machines with various versions of perl and the OS on each machine, he used VMWare to build all of these environments on a single machine. A set of Perl scripts called Krang Farm that controls VMWare and automates the building and testing on each environment. He uses GSX since the personal version of VMWare isn't scriptable. GSX and ESX provide Perl and Com APIs that you can use to control the virtual machines.
Besides scriptability, one of the key features of VMWare that makes this application a perfect use of virtualization is VMWare's non-persistent mode. In non-persistent mode, any disk actions are simply forgotten when the machine is halted and the image returns to its original state. This is a great feature in a testing environment, where you always want to start in a known-good state.
The why comes down to this simple analysis:
- Building and hosting a farm of six machines costs $18,000 in capital expenditure and another $14,000 per year in operating costs (mostly hosting). Each new environment requires another machine which adds $3000 to the capital costs and $2400/year to the hosting bill.
- The virtual farm costs $6775 in capital costs and $2400 per year to host. Adding a new environment is free.
Moreover, the virtual solution is more flexible since new environments can be created at the drop of a hat whereas adding a new machine requires planning, staging, and deploying real hardware.
The downside is the rather obvious point that the virtual solution doesn't scale as well as the hardware solution. In this application, it doesn't need to. Your milage may vary.
Another use Sam gives for the farm, which is not yet implemented, is testing upgrades. Pretty easy to have an environment that represents each version of your software and automatically apply upgrades to them as part of your regression testing.
This is a great article on using virtualization as part of a software testing environment--made even better by its hands-on nature. If you do software testing and haven't started using virtualization, this article will help you understand why you should.