We need to start with some basic assumptions to guide our solution.

Here is my initial list:

1. The applications being built will be important commerce or personalization sites, but will not be the sort of critical applications like nuclear plant software or air traffic controlling programs which require massive testing and documentation
2. The team may be geographically distributed
3. Time, Budget, Functionality, and Quality are all important, but we recognize the inherent truth of the saying: "you can have it: fast, cheap, good. pick two."
4. The application should be considered as being built for an external client. This may be because you work as an implementor, or simply that the "client" is your company's business team
5. You should be able to be proud of what you've build, the code, the look, all of it
6. You should be delivering something of value to the client, ideally something with measurable value
7. You need to be as flexible as you can regarding changes, without impacting the delivery quality of date
8. The process should be well documented, repeatable, etc...
9. Communication is king
10. We can always improve

In a series of blog postings, and hopefully with substantial input from the ATG community, I am going to try to define ATG development best practices. From how to run a development project, to coding standards, and more. I know it will be impossible to make a perfect set of practices for everyone, there is no one size fits all, but based on some basic assumptions, I will strive for a great starting point, instead of a perfect solution.

It will take time, but will be well worth it in the end.

This practice definition will be focused on delivering the highest quality ATG applications, on time, and on budget, while maximizing flexibility to accommodate the client’s changing needs.

More specifically the process needs to:

• Ensure there is a fixed baseline of requirements to build against
• Allow for accurate estimates, resourcing, budgeting, and scheduling
• Leverage ATG expertise at many steps of the process, including strategy, requirements gathering, and creative concepts in order to maximize the benefit of the platform and minimize development pain (defined as time/cost/stress/quality-impact)
• Support a geographically diverse team
• Define the steps, flow, entrance and exit criteria, and roles for the process
• Minimize time waste
• Maximize communication and documentation
• Be supported by a set of tools and practices to effectively enable the process
• Deliver high quality (low defect) applications, on time and on budget

And here are the things I will try to address:

• Project Roles
• Project Process
• Development Process
• Change Request Process
• Toolset to Support the Processes
• Hardware, Environments, Software
• Coding Standards and Best Practices
• Bug Severity Guidelines
• Test Phase Exit Criteria
• Source Code Tagging and Branching Strategy and Naming Conventions
• Versioning and Build Number Conventions and Tracking
• Project Naming Conventions
• Documentation Templates and Conventions

Thanks to Doug Henderson sending me some code updates I have released a new version of the RSS Feed Droplet (first mentioned in this post) which supports configurable character encodings. This can be very useful if you have "interesting" characters in the content you are publishing.

I have also rolled the code into my ATG Open Source Module Pack, so that I can maintain everything in one location.

Also: please note that you cannot reformat the JSP code, or introduce any spaces as it will break the feed. I've made note of that in the module's Readme as well.

Enjoy!

If you have your own content repository items defined, and you'd like the ACC to provide the Upload Image functionality for your internal binary properties, Russell Moore has figured it out:

In /atg/devtools/ create a local version of admins.xml:

 
<repository-admins>
  <default-admin id="YourRepository">
    <display-name>Your Content</display-name>
    <repository-name>YourRepository</repository-name>
    <create-bean-displays>
      <bean-display type="media" class="atg.ui.repository.MediaInternalBinaryEditor">
<property name="internalBinaryExcludedTableProperties" value="path, version, mimeType,data, length,url"/>
      </bean-display>
    </create-bean-displays>
    <standard-bean-displays>
      <bean-display type="media" class="atg.ui.repository.MediaInternalBinaryEditor">
<property name="internalBinaryExcludedTableProperties" value="version, mimeType, data, length, url"/>
<property name="internalBinaryTableReadOnlyProperties" value="path"/>
      </bean-display>
    </standard-bean-displays>
  </default-admin>
</repository-admins>
 

Thanks Russell!

Many things can obscure the real IP address of the end user when they visit your site: a load balancer in front of your ATG cluster, Akamai, the user's ISP or office network, and more. This makes correlating logging events, or using the ATG session IP validation security option, and more, very difficult. In light of that challange I've added a new mini-module to my Open Source ATG Modules called the ProxyIPFixer. It uses a simple ATG pipeline Servlet to examine the X-FORWARDED-FOR request header, and if it finds one, parse through the IP addresses to find the originating IP address of the user, and puts that value into the ATG Request object's remoteAddr property.

This allows downstream pipeline servlets, code, and pages to see the real user's IP address.

The caveat is that the header can be faked, and that some ISPs/companies, such as AOL, do not set the true end point of the user, and you can only see back to their outgoing proxy server. In AOL's case in particular, they can also route subsequent requests by the same AOL user through different AOL proxy points, which will make it appear that someone is hijacking a session (if you're using the ATG session security mechanism). So be aware of the limitations. However it can be very useful.

For those who don't want to download the whole module package, I have attached the Java source and the ATG properties file to this post.

Enjoy! (and as always feel free to contact me with questions, issues, improvements, etc...)

ProxyIPFixerServlet Java Source

ProxyIPFixer ATG Properties File