stevedoria.net

It seemed that I would be unable to persuade an ISP technical support representative to change their server configuration, while talking with him at 4am. Setting up a 301 redirect between a domain with a www subdomain and a domain without a subdomain is pretty easy. I usually do something like the following when setting up virtual web hosts to enhance SEO for a particular domain:

<VirtualHost 11.22.33.44:80>
   ServerName stevedoria.net
   RedirectPermanent / http://www.stevedoria.net/
</VirtualHost>
<VirtualHost 11.22.33.44:80>
   ServerName www.stevedoria.net
   DocumentRoot /home/stevedoria.net/www
   # Other server directives...
</VirtualHost>

Luckily enough for me, the ISP allows shared hosting clients to use an .htaccess file and has mod_rewrite enabled. I’m pretty sure that people have used mod_rewrite to effect the same results as the configuration above, but after a couple of minutes searching for the appropriate solution on Google, I figured that it might take less time to derive the solution for myself with the Apache Web Server documentation. Here’s my solution of permanently (301) redirecting a non-www domain to the corresponding domain with a www subdomain:

RewriteCond %{HTTP_HOST} ^stevedoria.net$
RewriteRule ^/?(.*)$ http://www.%0/$1 [L,R=301]

The 4th Berkeley Distribution manual page states, “chkconfig provides a simple command-line tool for maintaining the /etc/rc[0-6].d directory hierarchy by relieving system administrators of the task of directly manipulating the numerous symbolic links in those directories.”

Being commissioned for the development of a large software system caused me to reflect on the sources of past software production faults. Three elementary sources of problems were minimal or unacceptable project visibility, compressed schedule, and incomplete requirements analysis and design. These elementary problems resulted in secondary problems such as faulty software implementation, seemingly endless rework and refactoring, late delivery, lack of team coordination, demotivation or demoralization of development teams, and departure of team members.

Time and time management are the biggest factors in the success or failure of most software development projects. Underestimating the time needed for a software project guarantees late project completion. Attempting to complete a project that is not allocated sufficient time also results in corners being cut: design is shortchanged, testing is inadequate, and quality is hampered. Overestimation may discourage potential clients from proceeding with software development.

Estimating the duration of a project is an early opportunity for increasing project visibility. It encourages communication within the development team and allows the team to produce a project artifact, a somewhat detailed estimation on the resources needed for the project, early in the project lifecycle. Having the team develop resource estimates allows these estimates to be visible to all team members. These estimates serve as early deliverables that are given to clients to enhance their view of the project.

Delivery of the project artifact to the potential client gives the client more information to decide on continuing with the project. A prospect’s reception of a thoughtful time estimate, which is supported by consensus among the development team, gauges the prospect’s expectations. Prospects with reasonable expectations tended to be content when software systems were delivered on time, and they also tended to be moderately ecstatic when projects were completed before their respectively scheduled completion dates. Prospects with unrealistic expectations usually turned out to become problematic clients who demanded more attention and technical resources, causing a reduction in the quality of service provided to other clients. Clients with unrealistic expectations also tended to be insensitive to increased developer efforts to deliver high-quality software systems within reasonable time frames.

Requirements analysis is an essential tool for formulating an acceptable time estimate. Analyzing the desired system’s functionality requirements provides a concrete basis for estimating project duration. The complexity and time required for the development of software systems within a software class vary widely. The variation is based primarily on the differences of requirements. Listing a particular system’s required functionality and summing the estimated times to fulfill each of the requirements provides a more accurate estimate than one that is based on the system’s software class. Deriving a project duration estimate from system requirements analysis is an alternative to the common practice of making educated or whimsical guesses.

Like other artifacts of the software development lifecycle, the project duration estimate is affected by the completeness of the requirements analysis. Pockets of required time are hidden by abstract requirements. “Web pages are ranked by popularity on the ‘popular web page’ results page” is an example of an abstract requirement. This requirement is incomplete without coverage on the basis of popularity. The software system may use services like ping-o-matic or rely on a system component that spiders the Internet for information to determine web page popularity. The time required to fulfill the requirement, “popularity of pages is determined purely on recency information provided by ping-o-matic with the most recent page being the most popular,” is significantly different than that used to fulfill the requirement, “popularity of pages is determined by the number of people that bookmark a particular page on the social bookmarking service with the most popular web page having the most bookmarks.” Not eliminating abstract requirements causes project estimates based on the requirements to be inaccurate. It potentially causes the project and the delivered system to overrun its allocated resources.

Acquiring the requirements from the prospect, analyzing the requirements with the developers, and reviewing the requirements with the prospect after receiving feedback from the developers is a good start for developing a complex system. Requirements determine the time frame and form the foundation for system construction. Solid requirements provide a solid foundation for successfully building complex software on schedule. Incomplete requirements provide a shaky foundation that causes efforts to build potentially late software to topple.

Gmail’s “Why Use Gmail?” page suggests that “storing mail in folders with subfolders and nested sub-sub folders is not a productive way to spend your day.” Because search is Google’s primary strength, they encourage users of their free email service to perform a search query for an email of interest rather than actively organize their email and navigate through a folder hierarchy. In this way, Google is untraining many computer users who are so immersed in the file, folder, and cabinet paradigm of organization that they find other organization techniques incomprehensible.

Finding a particular email among the thousands that can be stored on Google’s email service can prove challenging, especially when more than 80% of all email falls under a small number of topics. Keyphrase queries fail to deliver results when items are not palpable to search engines. A typical email received by a network operator is presented here:

Meaningful queries to dig up this particular email seem to be “login,” “login info,” and “from:sales@gmail.com.” This being the typical kind of email received by a network operator, such queries would provide a large number of results.

The difficulty of tracking emails as encouraged by Google’s free email service has reached a level where certain technical teams have considered reverting to traditional email clients, such as Microsoft Outlook or Mozilla Thunderbird. After all, the teams are very familiar with the email folder schemes in these applications and organization has not been much of a problem before. These are proven email solutions after all.

One problem with traditional email clients comes to mind. Sometimes, email messages discuss multiple topics. These email messages, for example, may ask for a follow up on client XYZ while providing a task list for client ABC. In this scenario, the email is concerned with both ABC and XYZ. A system that uses the file and folder paradigm would require that the email message be filed into a folder for either ABC or XYZ. Using a more general folder such as “Tasks” or making copies of the email are also solutions. Taken to an extreme, the use of a general folder constitutes one folder, named “Email,” for all email. By reductio ad absurdum, the use of general folders is a less than optimal solution. Generating copies of an email is also suboptimal, because it requires more email to be filed by its very nature.

One feature of Google’s Gmail may help overcome organization difficulties that are faced when relying solely on search queries. Labels offer similar advantages to those provided by email folders of traditional email clients. They also overcome some disadvantages of email folders that were mentioned earlier.

Labels provide the grouping feature that is common with email folders. People who rely on a folder hierarchy for organization are still out of luck as Gmail has yet to implement a hierarchical system for email labels. They may be able to get around this limitation by setting a naming convention. Labels such as “CLIENT-abc” and “CLIENT-xyz” can be used. With labels, all emails that pertain to a particular subject can be viewed in a similar way that folders allow.

Emails in Gmail can be tagged with multiple labels. This allows an email that covers multiple and possibly unrelated topics to be placed in multiple groups. This feature is not directly supported by the file and folder paradigm. The time needed to label email messages may be comparable to that of filing email into folders, but the advantages of email labels should be sufficient defense against transitioning to traditional email clients on the basis of organization.

The Linux Programmer’s Manual states, “ldd prints the shared libraries required by each program or shared library specified on the command line.” This tool is useful when setting up a chrooted shell environment. It is also useful when creating custom boot CDs, which may include programs that dynamically link to shared libraries.