Nightmares in web hosting

About six weeks ago I decided to update my web site and upgrade my CMS software. That required having my web host transfer my site to a server that was configured to handle the new features. Upon request the site was moved, but afterward “Support” failed to:

  1. verify the site subsequently was accessible via the domain URL, which it was not.
  2. send the new URL for the site admin access.
  3. send the new settings needed for email.
  4. send the new URL for webmail access.

Support was so unresponsive that within a week I moved to a new web host just to get the site accessible again.

Lesson 1: Check web host reviews to verify whether support is responsive and thorough as well as available.

My admin and I agreed to try a VPS (virtual private server) at the new host, thinking that a virtual machine, which typically is set up within an environment that has already been secured, such as on a PC with malware protection or on a PC or server inside a network firewall, would prevent some issues that caused problems for the previous host.

My web administrator is a veteran of nearly 30 years on UNIX systems who is known for securing them well. The new web host recommended an OS that was somewhat new but assured us, orally as well as via the statements on its web site, that it would “hand-hold” as much as necessary for set up, maintenance and security.

It took several days to build the VPS and the site and to investigate and address every security issue we could identify. Within a week, however,the web host sent a nasty email notifying us that the admin password for the site - which is set through software selected and installed by the web host and which we could neither configure nor replace - had been cracked and the site was being used to send spam.

I took the site offline, got support on chat (phone support, we realized after we moved, was reserved for emergencies only) and repeatedly asked for instructions on how to block hackers. I was told only to change the admin password and make sure all software patches had been applied.

Lesson 2: Make sure phone support is 24/7 for all causes, not just for emergencies.

Read moreTeaser break marker

Technical writing: the step-child of IT?

technical writing logo

In my experience, technical writing alone of all the information technology functions is treated as a luxury. One large company for which I worked, for example, immediately eliminated the technical writing team whenever financial troubles loomed. Technical writing was considered “overhead” that did not directly contribute revenue; therefore, it was expendable.

This attitude has seemed nearly universal, at least in large companies. Only two conditions seem to make documentation a high priority.

1. Regulatory requirements

If a regulation requires documentation, it will be created. A number of people will want to have an imprint on the product. They will want their names listed as contributors, their points of view addressed and their concern for doing things properly noted.

After the document is written and the regulation satisfied, however, it is likely no one will ever read the document or direct anyone to do so, until something goes wrong. Then, the document will become the proof that someone - usually someone in the rank-and-file who is considered expendable - was at fault.

2. Downsizing and cost-cutting

When companies decide to eliminate jobs or lay off or replace personnel, the work those employees handled must be done by someone else. The tasks might be added to the workloads of remaining personnel, or they might be outsourced. In either case, documenting procedures becomes critical. I have even heard of companies penalizing outgoing personnel, via severance packages, who fail to train their replacements.

Read moreTeaser break marker

Managing documents

technical writing logo

Any kind of writing involves multiple drafts of the same document. I think technical writing can be especially challenging, because normally there are several documents in development at the same time, often there are multiple reviewers for each. Some organizations have streamlined collaboration so that one document comes back with all the suggestions.

In my experience, however, most companies' review process is something more than handwritten notes from 15 reviewers but something less than the ideal single draft containing all 15 reviewers' changes. Planning how to handle all those files before the numbers explode can make the project run more smoothly. That attention to organization can also provide a solid base for clients unsure about how to manage documentation once it is created.

Read moreTeaser break marker

Bugs along the Python trail

python programmingOne reason my sister gave me the raspberry pi was to help keep my interest in learning Python programming after I hit my first snags. I started with a book called Learn Python the Hard Way.

It is excellent in some ways. First, it focuses on the command line, which is good both for someone who likes knowing why things work the way they do and who hates the limitations inherent in using a   GUI (Graphical User Interface). The emphasis on manually typing in every command, rather than cutting and pasting for speed, helps you learn the commands faster. My favorite feature of the book was the image of what you should see on the screen after running each lesson's program.

I quickly became frustrated, however, with the extent to which the book relied on the "just do it" and "figure it out for yourself" approach in the study drills. Making you think through the logic is one

thing; asking you to do something for which you are not properly prepared is another. For example, at one point the exercise was to search the web for a "list of all Python format characters." During my search, I actually found a message board post where someone asked, in the exact language used in the book, where such a list could be found. One response to the query said the question was unanswerable as it was asked.

Read moreTeaser break marker


Subscribe to RSS