Software Tools

The Web and its many uses

The Web has a place in every level of your development organization.

Most discussions about the mechanics of software development dwell on the tangible tools, such as compilers, linkers, debuggers, configuration managers, and the like. These are the hammers with which we drive our software nails. What are often overlooked are the less tangible, but equally important, components of the developer's toolkit: the communication tools.

Except for the very small projects, every software development effort requires at least some sort of communication infrastructure to bring the development team together and direct their activities. Without a means to exchange ideas and track progress, a team of developers is destined to struggle, regardless of the quality of their other tools.

Traditional efforts at team communication include frequent meetings, memos, published schedules, and verbal exchanges. Recently, developer groups have adopted e-mail as a handy way to communicate, and more progressive teams are exploiting private e-mail lists, archive servers, and private newsgroups to distribute critical data in a timely manner. Even so, team members still search for more effective methods to share information.

Web strands
The rise of the World Wide Web (Web, for short) offers an unprecedented opportunity to revolutionize group communications. Unlike previous network communications tools, the Web makes it ridiculously easy to browse documents anywhere in the world and to publish your own documents for anyone to read. With a relatively small investment of time and effort, anyone can be an electronic publisher, offering valuable content to others within and without your company.

For those of you who have been cavebound for the last year or so, the Web is a collection of multimedia-enabled documents and interactive services on networked servers. Clients use graphical browser software to access, display, and interact with the Web contents, either over a private network or over the global Internet.

Using a simple HyperText Markup Language (HTML), users transform common text documents into attractively formatted and multimedia-enabled ones for client viewing. The HTML documents also contain interactive "links," which when selected, automatically load another HTML document or other Internet service. Browsing vast archives of data is as easy as viewing a document and selecting links with a mouse click to obtain other documents.

Although commercial copies, including support services, are available, notably from Netscape Communications (Mountain View, CA), free versions of Web server and client browser software are available on the Internet. For details, check out this popular Web site: http://hoohoo.ncsa.uiuc.edu/docs/ Overview.html. Servers typically run under Unix, but Macintosh and PC versions also can be found over the Internet.

Beyond static documents, the Web provides both dynamic documents and interactive forms for its users. Dynamic documents change their content based upon any number of criteria, delivering customized information to each user. In some cases, a server may determine that the requesting client machine is located in a particular part of the world, and deliver information that is pertinent to that user. In others, the servers deliver real-time data, such as stock quotes or sports scores, and modify the transmitted documents on-the-fly to deliver the most recent information to the user.

Interactive forms let users supply unique information to a server, which then customizes a reply or initiates an action on the browser's behalf. The user's browser presents a collection of check boxes, menus, and text fields, which the user fills out appropriately and transmits the form back to the server. The server uses the data to construct a custom reply. A popular example on the Web is the customized weather map, in which users indicate what they want to see (location, temperature, storm fronts, and so on) and the server crafts a custom weather map upon request.

Running a Web server is simple. The most popular is httpd, available precompiled for a number of Unix platforms from the web server run by the National Center for Supercomputing Applications (http://hoohoo.ncsa.uiuc.edu/ docs/Overview.html). Creating HTML documents, services, and forms is relatively easy and a growing number of tools, like Microsoft's freely available Internet Assistant for Word (http://www. microsoft.com), will convert existing documents to HTML.

Webs for developers
Once established, a Web server offers almost limitless opportunities for enhancing your group's productivity by improving communication. In fact, most applications are just an SMOP (Simple Matter Of Programming). Here are a few good ideas for tools that can speed up your development cycles:

E-mail archives. Use a tool like mail2html to automatically convert your group mail archives into HTML. Looking for that memo you sent out weeks ago? Don't bother rummaging through your files. Point your browser at the Web archive and retrieve a copy in mere seconds.

Meeting minutes and reports. Don't just transcribe meeting minutes or reports in simple ASCII and e-mail them out. Write them in HTML (nearly as easy as ASCII) and place them on a server. Then use e-mail to announce their availability and let your group, or anyone for that matter, retrieve and read the documents at their convenience. You can even toss in a link or two to relevant graphics, verbal comments, and previous reports for those who wish to follow meeting threads.

Not only are you saving network bandwidth by sending less e-mail, you have established a common document archive that is readily accessible to anyone in your group. When a person joins the team, they can immediately review your entire history and get up to speed that much faster. Even better, those outside your group who require periodic status reports can be instructed to visit your Web site at their leisure, relieving you of the burden of keeping colleagues informed by holding endless meetings or sending out e-mail documents to satisfy ad hoc requests. Finally, server access statistics will let you know who read which report and when, indicating which reports are useful to your team and which reports are irrelevant.

Tracking billable hours. If everyone must keep track of their time for billing purposes, create a simple Web form that lets people input their time, billing codes, customer names, and the like. When the server receives the form, it automatically squirrels the data away in a simple file, fancier relational database, or just forwards it via e-mail to your billing organization. Because the form design can restrict fields to specific datatypes, the server can validate entries before forwarding or storing it, so you get more accurate billing information. The burden of recording hours worked is eased somewhat for your developers, and you can even implement reporting tools with forms that let people examine the billing database.

Source code control. Like the features of fancy revision control tools, but can't afford to license enough copies for your group? Implement a simple source-code management system using a Web front end to the popular SCCS. While it's clearly no replacement for something as sophisticated as Sun's TeamWorks product, Web-based SCCS is certainly better than its native command line interface. Best of all, it lets developers on non-Unix platforms use SCCS to control access to files on Unix servers.

Webbed SCCS
Because SCCS is so popular for source control, let's look at how you might enhance its usefulness with a Web front end. We also see how the various Web-based software and services work in more detail.

At the heart of the Web form is the Common Gateway Interface (CGI). Every form includes the name of a special CGI server program that processes the form's entry data. CGI applications can be written in almost any language: a shell script, C, or Perl are the most common. And most commercial and freely available Web servers come with sample CGI applications that you can customize to perform almost any task.

A Web-based SCCS is composed of three basic parts: your source code in ASCII format and in directories that can be accessed by your Web server; a collection of Web forms and CGI processes that let your developer clients check source files in and out and view the status of those files; and a top-level "home page" that explains how to use the tools and forms. Once your team becomes accustomed to using the individual forms, they can reset their Web browser to jump directly to the desired form, skipping the home introductory page.

For the "check out" SCCS tracking form, you should supply users with a list of available files, a way to specify which file to check out, and a way to actually copy the file to the client machine. The Web form facility lets us create a scrolling list containing every file available, and a button to click to retrieve the file. The way to program your Web to manage that scrolling list is with a "server-side include."

Server-side includes are a simple concept: They instruct the Web server to run some command and insert the results into an HTML document at a specific point. In our example, we'll want to run a script that determines which files are currently available for check out and insert that list into the scrolling list section of our form.

A button that our developers push to check out a source file completes the World Wide Web form. A CGI script on our server uses the selected element of the scrolling list as the name of the file to check out. The script then interacts with SCCS using conventional SCCS commands to check out and lock the file from the configuration management system. The script then continues to send the file to the client as a generic "octet-stream," as opposed to the "text/HTML" filetype common on the Web. That way, the browser will automatically prompt the user for a place to store the file on his local system.

The other two forms for file check-in and status reporting can be constructed in a similar vein. The check-in form is complicated by the difficulty of returning a modified file to the server. Future versions of the HTTP protocol will include a mechanism for uploading files to a server, but for now we must be satisfied with one of two solutions: specifying the pathname of the file on the local machine and using FTP or NFS to retrieve it from the client or actually copying the contents of the file into a text area in the form and transmitting the file when the form is submitted. The former solution requires establishing a secure channel between the server and all potential clients; the latter is more tedious for users.

Status reporting is a simple matter of running the SCCS prs command to create a revision history for files selected by the user, and using a custom awk or perl script to format the data into HTML. The result is a quick and easy reporting mechanism that allows anyone to check who has modified a file and what changes have been made.

Weave your own Web
We've barely scratched the surface of communicating via the World Wide Web. Once you get a few tools built, you will begin to think of even more ways to help your team work smarter and faster. From simple things like on-line mail archives and team document collections to fancy tools that track customer queries and project status, the Web has a place at every level of your development organization.

About the Author
Chuck Musciano is an experienced software engineer and noted Webmaster with the Corporate Information Management Group at Harris Corp. He can be reached at chuck.musciano@advanced.com.

If you have problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/asm-05-1995/asm-05-swtools.html.
Last updated: 1 May 1995.