Survival Skills for WebLogic Developers - dummies

Survival Skills for WebLogic Developers

By Jeff Heaton

As a WebLogic developer, it’s important to know how to structure your applications and development environment. You must also know how to reach out to the WebLogic community when you run into problems. This article offers up a few recommendations and other information to help you get the job done.

Keep adequate documentation

Documentation is an important part of any application. As a developer, you should do your part to ensure that your application is properly documented. Documentation falls into several categories:

  • Program code documentation. The most obvious form of documentation consists of the comments in the source code. Javadoc is a good way to provide this documentation.
  • Developer handbook. A basic but often overlooked use for documentation is bringing new programmers up to speed. On mature applications, developers’ computers often contain a mix of files used as the application was developed. This environment can be difficult for a new developer to recreate. The developer’s handbook describes the process needed to set up the development environment on a new machine.
  • Program specification. Changes to the specifications of your application must be communicated to all who are involved in these changes.
  • End user documentation. This is the documentation that your users refer to for information on how to use your system. As features are added to the system and existing features changed, make sure that you update the user documentation.

By keeping all forms of documentation properly maintained, developers and users can stay current with the application.

Use Usenet

One of the greatest benefits of the Internet is the sense of global community. And no single portion of the Internet embodies this more than Usenet, which consists of a large collection of messages posted by Internet users on a variety of topics.

You can access Usenet in several ways. You can install client programs that download and filter Usenet postings for you. You can also use Web-based portals. One of the most common Web portals is Google Groups.

Set up development environments

WebLogic enables you to create multiple servers that run from the same machine. This provides a convenient way to provide several development environments, such as the following:

  • Development. The development environment is where developers test their code. This allows developers to test their code in a controlled environment. Stable versions on the development server are usually rolled over to the test server.
  • Test. Your project team will likely consist of quality assurance (QA) people who test the software and report new bugs. QA people shouldn’t be testing from your development server because the server is too volatile. Rather, you should roll out a stable version from your development server to the test server. This version can then be tested by your QA staff.
  • Demo. You’ll have to demo your software, either to clients to show the progress of the system you’re creating, or to internal users who will soon be using your system. If you don’t create a demo server and a developer destabilizes your development server, your demo is shot.
  • Documentation. It’s likely that a group of people will be creating the documentation for your application. They’ll be logging on to the server and taking screen shots and performing other activities related to the end-user documentation. It is important to give your tech writers a stable environment from which to develop their documentation.
  • Beta. When you think that your application is ready for production, have your end users test the software one final time before it’s rolled out to production. This process is called end user acceptance testing. It’s a good idea to perform this testing from a special beta server.
  • Production. The production version of your program is the one that’s used by end users. It’s up to your server administrators to make sure that the production server stays available to them. This will be the last stop that any version of your software is rolled to.

It’s not necessary to set up all these environments on different machines. Several of these environments can be combined on a single machine.

Know what you’re developing

As a developer, you should understand the problem you’re trying to solve. This may seem obvious, but developers on large applications can easily lose sight of the goal for several reasons:

  • Unclear program specifications
  • Developers who are aware of only their own local areas of the program
  • Poor access to business users who understand the specifications

Understand the tools

Many tools are available to make the developer’s life easier. Unfortunately, you can spend a lot of time learning to use these tools before you realize any gain in programming time. In effect, your time to learn a tool is an investment. A developer should at least have the following tools:

  • A text file editor
  • An integrated development environment (IDE) that supports debugging
  • A build tool, such as ANT
  • A source code beautifier
  • WebLogic Resource Workshop
  • Version control

Create modular, decoupled systems

A large application will have many classes and intertwined systems. Creating a system composed of many modules has several advantages:

  • Common modules can be reused.
  • The program is easier to understand because large problems are broken into many smaller problems.
  • Different programmers can be working on different modules without interfering with each other.

As the system grows, specific modules will move from active development to maintenance mode. Make sure that these modules are constructed in such a way that ongoing development doesn’t cause errors to occur in previously working code. Such errors are called regression errors.

Be mindful of security

The media is filled with reports of people exploiting security faults in software. As you design and implement your application, you must be mindful of security. Security faults can creep into your system in many ways:

  • Taking advantage of unvalidated parameters
  • URL tampering
  • Buffer overruns
  • Injecting commands into parameters that may make their way to SQL
  • Exploiting known security flaws in the operating system or server software

Many security flaws are the result of not having the latest patches for your operating system or server software. Make sure that you have the most current patches.

Test your software

As a developer, you should always test your modules as well as you can before they’re integrated with the other modules. This is called unit testing. When you first create a module, you should do all unit testing by hand.

When you’re satisfied with the results of the unit test, you’re ready to integrate your module with those developed by others. This process is called integration testing. Integration testing involves teamwork with other developers as your components are put together for the first time.

In addition to testing performed by the developers, there will be testing performed by QA people and end users. As these users test your software. they’ll find bugs. If you have a number of QA people and developers, a bug-tracking tool can be handy. In addition, bug-tracking tools allow notes to be attached to individual bugs. When developers or users find a bug, they can document the resolution. This is important because not all bugs are a result of programming errors.

When the system is almost ready to be run from the production server, you should perform end user acceptance testing. This gives end users one final chance to test the system before it is rolled into production.