A site devoted to discussing techniques that promote quality and ethical practices in software development.

Thursday, January 30, 2014

Worthy Pdf readers in Linix Mint/Ubuntu

There are plenty of questions on the Internet asking whether there are any PDF Readers (free of course) for Linux that have more capability than the one that is packaged with Ubuntu/Mint, the Evince, that allow the users to annotate and highlight the materials.

Adobe Reader 9 can do this provided that the document contains a policy allowing the users to comment and annotate. In the absence of such a policy, this reader defaults to denying such capability.

There does not appear to be any native Linux PDF readers that can do this. Some such as Okular can do highlighting etc but they are stored in their private format that only the viewer that created it could display them. Hence their annotations are not shown in say Adobe Reader. Therefore this class of viewers are considered not supporting the annotation and highlighting requirements.

As a last resort, I am using 2 Windows PDF viewers running in WINE in Mint/Ubuntu. They are PDF XChange Viewer and FoxIt Reader.

At the time of writing, I have uninstalled "PDF XChange Viewer" because in Mint-64 bit, it consistently crashed the reader when I was switching documents in the tabbed view of the reader. My experience is also supported by reported behaviour in the WineHQ. It is ashamed that it misbehaves in this manner. The other problem with this is with the display when scrolling the document. However, one can alter the display settings to prevent this.

While FoxIt Reader also has a native Linux version, it is a very basic reader similar to Evince that does not do annotation and highlighting. Consequently, this is not used. Instead FoxIt Reader version is installed with the support of WINE.

So far, it behaves well with the only exception that it fails to account for the height of the task bar in Mint when one maximizes the FoxIt window. As result, the navigation bar is partially covered.

The other issue which may unsettle some is the automatic installation and activation of the FoxIt cloud plug-in and the Reader does not have an easy way to uninstall this plug-in.

To disable this plug-in, close the FoxIt Reader and use the following steps in Mint/Ubuntu:
1) Bring up the File explorer, Nemo or Nautilus
2) Press Ctrl-H to view hidden file
3) Locate the Windows system tools in WINE installed directory which is by default located here:
4) Then use the "Wine Windows program loader" to load Control.exe, the Windows control panel program and you should see a window like this:
5) Double click on "Add/Remove Programs" to start the program.
6) Locate the item called "Foxit Cloud" and uninstall that program item.

Next time you start FoxIt Reader, you will not see the "FoxIt Cloud" menu item. I only wish FoxIt would offer a more user-friendly way to disable it and also seek user's consent before activating the plug-in and FoxIt cloud.

Monday, January 27, 2014

Common reasons in software system failure

A post by Charette in IEEE Spectrum on the failure of various government systems sums up pretty much the general reasons why they fail:

put all the blame for the fiasco on Deloitte, which Deloitte heatedly contests. News reports state that at least one Florida lawmaker is suggesting that Deloitte be barred from future Florida contracts, something that Australia’s Queensland government has done to IBM as a result of Big Blue's role in the Queensland Health payroll debacle.
The bottom line was that no one was in charge, vendors and the state did not get along, the vendors themselves did not get along, no one wanted to hear about the myriad significant technical risks, and political motivations dominated decision making. In other words, all the makings of an all-too-typical government IT project.
Could it be that we are trying to develop software to do far more complex stuff, instead of being a tool to help human, they are being developed to replace human? In many of these systems, the common theme in all these failures - hire more human to remedy the failure!

In most of these large systems development, by the time the system is ready, the world has changed; the political scene has changed causing requirements to change; rules are changing all the time before the ink is dried.

Monday, January 6, 2014

Do not accept answers that you do not understand.

Not only it is the duty of the purse string holders needing to know precisely, without being clouded by technical jargon, what a software solution can do for the enterprise, every users need to know. This ensure that the buyers and users know precisely what they are getting and what they are paying for.

It is refreshing to come across this article in Financial Times relaying the experience of a very wise and persistent director of an enterprise that "demanded the computing experts translate their plans into plain English."

Far too often, as I have observed, that the recipients of software products choose to keep quiet for fear of showing up their ignorance or failure to comprehend of the materials from the so-called "technical experts". They all should emulate this "Dennis".

In fact, it is the communication fault of the "technical experts" that fail to explain the materials, particularly the functional part, in the terms that the users can understand. I don't expect them to explain how data base schemas are designed, XML messages being passed around or how to pool connections but at least they should be able to answer user-centric questions like what is the response time of say 20,000 users accessing the system, the stability of the system in terms of how often one expects a failure.

In a theme similar to the "Why Software Sucks" but at a different level, the  messages from the FT article are worth remembering. Admitting one does not understand the gobbledegook, often silently, and then not demanding answers to one's satisfaction is an abdication of one's duty.

Blog Archive