| Back to Current Newsletter |  |
 | |
Application development can be a great thing. A proper development environment can help your team create applications quickly and efficiently. There are many different ways to do application development. Following a few simple rules can greatly improve the entire process. This articule can help you with strategies and tips. Some of the thing you’ll learn include:
There are some basic steps that can be performed to create long term success. It’s easy to create a standard directory and development structure to help in the process.
Creating source code control.
Source code control systems allow you to work in a team environment, allowing developers to work together, preserving change histories of programs.
Informix application development involves creating programs, screens, and queries that access Informix databases. Applications can be a combination of different types of things, including 4GL programs, PERFORM screens, Ace reports, C programs, and client-based (PC) programs like Java and Visual Basic. No matter what you use, the process is very important.
Creating the right environment from the beginning can save lots of time and money. It is almost always worth the time to properly design the environment from the beginning. If this is not done, you might be always acting in panic or fire-fighting mode, decreasing quality and production. In this section, I discuss some of the ways to set up the environment.
Planning and Defining Responsibilities
A proper plan is essential to success of a project. This
can be as simple as a text file on the operating system or as complex as
a project management software tool. The plan should include things like
due date, priority, responsible parties, estimated hours, and task description.
Working from this plan can greatly help a team complete a project: It is
organized and provides specific goals. Here is an example of a simple project
plan:
Due Date Priority Responsible Est Hr. Task Description
1/1/98 1 bob, nancy 20 Create directory structure
1/10/98 2 ron 25 Create customer screen
1/15/98 3 spike 40 Design databaseBe sure to define the goals of the project. What do you expect to get out of the project? What do the users expect? What will the Informix and operating system requirements include? When should the project be completed?
If you have more than one member on your development team, be sure to clearly define the responsibilities of each team member.
The team must have a leader, someone that is accountable for timely delivery of the project. Of course, this person can perform some of the application development, but he or she must also make sure that the team is meeting its goals as a whole. The leader should keep track of due dates and tasks. This person should be responsible for resolving conflicts and helping others when they are stuck.
Outside of the team leader, you might want a technical leader. This is required if the other leader is not responsible for the technical end of things, just due dates and project plans. The technical leader can be someone that helps design programs and how they are implemented, helping others with technically-oriented questions.
The rest of the team will vary, depending on the needs of the project. In fact, there is no one way that assures success. The important thing is to have a leader and have a plan.
Creating the Development Environment and Directories
It’s important to create the right development environment. You need to define a process that allows multiple developers to work on the same programs, a directory structure for your programs and screens, and a way to move things into production. I’ll analyze at each of these items now.
Source Code Control
Source code control is used to control the revision of programs in a development environment. Two of the most important things provided by source code control include:
· Revision history. A good source code control system allows you to keep multiple revisions of a program or screen. This way, if you need to go back to an older version of something, you can do it.
· Multi-user management. When multiple developers are working together, it is essential that they don’t change the same program at the same time. Source code control must include the ability to "check out" programs to users, preventing others from changing it.
There are many commercial tools that provide source code control, both in GUI environments like NT and text-based environments like Unix. Of course, the change management tool must allow you to move programs to their target environment. For example, if you are creating a Unix application but are using a NT-based tool, you’ll need to make sure that there is an easy way to transfer files back and forth. Popular Unix change control commands are sccs and rcs.
Most Unix systems include the command sccs. It’s basic syntax is sccs keyword [files]. Some Unix systems don’t require the sccs portion of the command (instead of typing sccs get you would type get, for example). The concept of "checking out" means that the person that performs the command has locked the file so no one else can edit it. When the person is done making changes, he can "check the file in" so it is available for edit by others. The main keywords for sccs are described in Table 30.1. Note that not all Unix systems support all the commands.
Table 30.1
keyword description
create Check a file into SCCS for the first time.
delta Check a file in with your changes (must have been checked out with edit).
diffs Compare the file in your directory with the one in SCCS. This is a great way to verify what you changed after checking the file out.
edit Check a file out for editing. It will be placed in your working directory.
get Get a read-only version of a file into your working directory. You can also use the -e option of get to check a file out for editing (like the edit command).
info Get information about files that are currently checked out.
prs Print a change history for specified files.
unedit For a file checked out via the edit command, delete the file you are working on and allow someone else to edit it.
Within the SCCS directory, SCCS keeps a change history file for each file that has been checked it. This is the name of the file, prefixed with "s.", as in s.cust_scr.4gl. If you check a file out for editing, a file with a prefix of "p." will be created, as in p.cust_scr.4gl. NEVER DIRECTLY EDIT THE FILES IN THE SCCS DIRECTORY; USE THE PROPER SCCS COMMANDS!
Using SCCS to create and edit programs is simple:
2. Create the SCCS directories. SCCS changes are tracked in directories named SCCS. This directory is typically created beneath the directory that contains the latest versions of the programs. The number and location of SCCS directories depend on the decisions you made in step 1. For example, if you have a directory /usr/dev/4gl, you can create an SCCS directory with a pathname of /usr/dev/4gl/SCCS for your program changes.
3. Check files in to SCCS for the first time. The SCCS directory contains a change history file for each program. You need to create this file one time. To do this, use the SCCS keyword create as in:
6. Check the program back in. When you are finished changing a program, you can check it back in by using the delta command. This creates a "delta", a unique version number for this set of changes. The delta is incremented for each new version, beginning at 1.1. Some Unix systems support the command delget, which is essentially a combination of delta and get. Similarly, deledit performs a delta and an edit. Here are some examples:
Directory Structure
The directory structure defines where programs and screens are kept, both for development and production. Directories can be defined in many different ways, including:
The way you configure your directories depends on the environment. The important part is to just choose a scheme that works for you.
In all cases, you should separate the executable code for production and development. Below is an example of one way to create this directory structure:
The /usr/apps/prod/bin directory would be used for executable production versions of programs, screens, and ace reports. Note that source code is not really necessary in production if you’re using SCCS, all copies of the source code is available.
Setting up a Common Environment
In a team environment, there’s a good chance that most developers will need many of the same tools and environment variables. Instead of having everyone create their own way of doing things (which is all too often the case), why not just create a few simple rules? Here are a couple easy ones:
Knowing and Sharing the Environment
A commonly overlooked, yet basic, part of an environment is letting people know how it works! One simple document and occasional meetings might be all that is required. If it’s not done, people can start working in their own world, greatly slowing development.
Creating Common Setup Scripts
Most team environments define basic environment variables, database settings and directory path names. It can be very useful to create a common shell script that can be run from each developers’ login .profile. For example, the listing in Listing 30.1 sets up several common environment variables that could be used by the members of a team.
Listing 30.1Example of common shell script.
#!/bin/sh
# setup_env.sh
APPBASE=/usr/app/src # directory under which all development is done
FGL=$APPBASE/4gl # 4gl directory. Allows the command: cd $FGL
PER=$APPBASE/per # per directory. Allows the command: cd $PER
# The following allows execution of commands in the application’s bin directory
# without being in the directory
PATH=$PATH:$APPBASE/bin; export PATH
# The following allows running compiled forms (Perform screens with .frm suffix)
# and reports (Ace reports with .arc suffix) without being in that directory.
DBPATH=$DBPATH:$APPBASE/per
# informix variables
ONCONFIG=onconfig.test; export ONCONFIG
INFORMIXSERVER=test_shm; export INFORMIXSERVER
DBEDIT=vi; export DBEDIT # set default text editor for InformixBy simply placing the following line in each user’s login file (often .profile on Unix), the variables can be shared by every user.
Once your application is released, you can follow a similar strategy for the users of the system. In fact, since user environments tend to be more controlled, it’s probably much more important to create central utilities like this. As the last line of the users’ script, for example, you could run the menu program and prevent them from using the command line.
If you want the users to be logged out of the system when they’re done using the menu, you can use the Unix exec command as in the following example:
Using Common Programs and Libraries
A common practice in the application development world is to create common functions or libraries that can be shared by many different users. This is most useful when a common utility has been developed. Each programmer might benefit from using it and wouldn’t have to rewrite it. For example, suppose you created an Informix-4GL function that allowed you to override a program’s default database by setting the environment variable $CURRDB. This function might be useful (or required) for every program. Rather than cut-and-pasting it in every time, you can create a program that is placed in a central place (a lib directory, for example) and compiled by multiple users. This is much like the shell script shown in Listing 30.1 it’s kept in one place and only needs to be changed in one place. Listing 30.2 shows the code for such a function.
Listing 30.2 A function to dynamically select database
name.
function select_db()
define tmp_dbname char(10)
initialize tmp_dbname to NULL
let tmp_dbname = fgl_getenv("CURRDB")
if tmp_dbname != " " then
close database
database tmp_dbname
if sqlca.sqlcode != 0 then
display "ERROR selecting database ", tmp_dbname
sleep 3
return false
else
return true
end if
else
return true
end if
end function # select_db()
By Ron M. Flannery, rflanner@speedlink.net