Sofware engineer might be the best job in America, but when you tally them up, most web application developers still need to use, on a regular basis, a stunning array of technologies.

1. Desktop operating system
2. Telnet or Remote Desktop
3. Server operating system
4. Email
5. Web Browser
6. Internet Relay Chat or Instant Messenger
7. An IDE (Eclipse, Visual Studio, Aptana) or programmers editor
8. Image editor
9. HTML
10. CSS
11. JavaScript
12. DOM
13. HTTP
14. HTTPS
15. XHR (XMLHttpRequest)
16. Cookies
17. POP / SMTP
18. High-level language (Java, C#, Ruby, …)
19. XML
20. Unit testing framework (xUnit, TestNG)
21. SQL
22. DBMS (MySQL, SQL Server)
23. Data access framework (Hibernate, iBATIS)
24. Web server
25. Web container
26. Web services (SOAP, JSON RPC)
27. Server pages (JSP, ASP, PHP)
28. Page testing framework (Selenium, Mercury, WebCanoo)
29. Ajax Library (Dojo, YUI)
30. Web framework (Struts, ASP.NET, Rails)
31. Repository (SVN, CVS)
32. Wiki
33. Issue Tracker
34. Office sofware (Word, Excel, PowerPoint)

And that’s not even counting readng, ‘riting, and ‘rithmetic!

Agile programming in India writes:

“I hear alot about open source, everything is open source, how people write code on mailing list and Apache and all that… but I ask dear reader, how do they manage to fix BUGS? When many people write code it is hard and you need a methodology, but open source tell us that we don’t need methodology, any person can change code? How does this work? I know, they are good, but no methdology? Open source needs a plan. A new plan. It is not agile enough. you want to insert problems in my code, boy?! Go, join open source mailing list! NO good.”

Most people who work on open source projects are professional programmers who use the products at work. The individuals in the Apache HTTPD group contribute to the web server because they each use the server at work. The same goes for most any open source project.

Very few open source projects let any one change the code, in the way that Wikipedia lets any one change an entry. (And even Wikipedia is locking some entries down now.) Anyone can submit a patch, but an established “committer” has to decide whether to apply the patch.

How do you get to be a committer? Easy: Act lke a committer. File tickets, submit patches, and post to the mailing list. (But most of all, submit patches!) Once the group sees that a developer knows what he or she is doing, usually, someone in the group will offer write access. But you have to prove yourself first.

As to methodology, most projects use tools like mailing lists, commit logs, issue trackers, and wikis to discuss the code and apprise everyone of every change we make. For more about open source infrastructure, see The Open Source Secret Sauce

The framework defines several constants that are used to identify common result use cases, such as, ERROR, INPUT, FAILURE, LOGIN. NONE, and SUCCESS.

When an application has common result cases of its own, such HELP, MENU, or CANCEL, the application should define additional constants to represent various result types.

The use of constants reduces programming errors, increases cohesion, and also documents an application’s common result types.

Version 2.2.2 of the Yahoo! User Interface (YUI) Library is now available.

Usually this kind of update means downloading the new scripts, dropping them into your development folder, and ultimately updating the server. But since YUI is also serving the minified scripts from Yahoo! servers, downloading the release is optional, all you may have to do is replace references to “http://yui.yahooapis.com/2.2.0/” with a reference to “http://yui.yahooapis.com/2.2.2/”.

Of course, any decent IDE will do the search and replace for you, so it’s not any more work. We simply trade updating our local copies of the scripts with touching all the files that use the script. Since my team wasn’t checking in the YUI scripts, it’s actually less work, since only one of us has to do it once, and we don’t have to touch the server at all.

One handy result of the trade-off is the potential for mixing and matching versions. The 2.2.2 release is suppose to be a bug-fix, though the beta (repeat beta) DataTable saw some significant internal changes. In fact, my DataForm widget can’t use the new version (yet). But, no worries, I changed that reference back to 2.2.0 and its running, giving me breathing-space to sort out the problem. (Which I’m sure will be yet-another case of me pushing the envelope, and the envelope pushing back!)

Meanwhile … the YUI release notes are helpful but high-level. That’s not a bad thing, but if you are working closely with the library, and perhaps building your own widgets on top of YUI’s, then it can also be helpful to have a line-by-line change log. Towards that end, I’ve checked in the last two YUI releases to the Yazaar project. Having the releases under SVN means that we can obtain DIFFs between versions, and review the line by line changes. To keep the YUI archive out of the way, I tucked it under the branches folder. (Gotta love Subversion!)

Of course, I’ll be resolving my DataTable glitch today, and looking to see if Jenny Han Donnelly and company slipped in any new goodies.

I submitted my ApacheCon 2007 US proposals in this morning. I often submit multiple proposals, but I’ve never had more than one accepted at a time.

Migrating to Ajax - Leverage your hard-earned web development experience and learn how to migrate old-school web applications to Ajax and RPC. This full-day training session covers “Model 2″ applications based on frameworks like Struts, as well as “Model 1″ applications based on PHP or JSP. Prior Ajax experience is not required.

Ajax Petstore Smackdown - Let’s compare conventional implementations of Petstore using Struts or Tapestry with Web 2.0 implementions using Ajax and RPC. Which is better, faster, cheaper … or just more fun to write!

.NET @ Apache.org - Like it or not, many open source developers are moving to the Microsoft .NET platform, and we’re bringing our favorite tools with us! In this session, we look inside ASF projects that are creating software for .NET and Mono … iBATIS, Logging, and Lucene … and show how to create leading-edge ASP.NET applications with open source libraries.

Whether one of these are accepted or not, I expect I’ll wander down to Atlanta this November. It’s one of the few places where I can get a direct flight!

The CFP announcement was inadvertently delayed, so the deadline is unusually close this year. If you’d like to submit a proposal, act today!

The Call for Papers is now open for ApacheCon US, to be held November 12-16 at the Peachtree Westin, Atlanta. The conference will consist of two day of tutorials (November 12-13) and three days of regular conference sessions (November 14-16).

Please log in to the website at http://apachecon.com/html/login.html to submit your proposal. Further details about fees and are avaialable on the CFP form. Topics appropriate for submission to this conference are manifold, and may include but are not restricted to:

• ASF projects
• ASF-Incubated projects
• Scripting languages and dynamic content such as Java, Perl, Python,
  Ruby, XSL, and PHP
• New technologies and broader initiatives such as Web Services and
  Web 2.0
• Security and e-commerce, performance tuning, load balancing, and
  high availability
• Business and community issues surrounding the ASF and Open Source

The paper submission deadline is Monday, 28 April 2007, Midnight GMT.

Thanks, and we hope to hear from you, and to see you in Atlanta.

Often, actions will share a number of common results. Rather than configure redundant result elements for each action, share common results through a global result handlers.

/common/Error.jsp

/common/Error.jsp

Login_input

Using global result handlers ensures that common results will be
handled consistently, while reducing redundant code. Global results
increase coupling, but any action that needs to handle a result
differently can provide a local handler.

Unlike template systems like FreeMarker and Velocity, JavaServer Pages cannot be served from a JAR or loaded from the classpath. The next best thing is to name the JSP folder after the namespace or Java package for the corresponding Action class.

By creating correlations between the pages and the Actions through a shared set of naming conventions, we increase cohesion within the application. If wildcards are used, consistent, shared naming conventions can reduce the number action elements an application needs.

Since Action classes tend to access the same business layer, most Actions often need to catch the same set of exceptions. Rather than sprinkle Actions with nearly identical try..catch blocks, configure an Exception handler to catch whatever exceptions an Action may throw.

<struts>

<global-results>

    <result name="error">/Error.jsp</result>

  </global-results>  <global-exception-mappings>

    <exception-mapping

      result=”error”

      exception=”java.lang.Throwable”/>

  </global-exception-mappings>

  <!– … –>

</struts>

Exception handlers can be either global or local to an action mapping.

<struts>

  <action name="Login"  class="actions.Login">

    <!-- ... -->

    <result name="expired" type="chain">

      ChangePassword

    </result>

    <exception-mapping

      exception="dao.ExpiredPasswordException"

      result="expired"/>

  </action>

  <!-- ... -->

</struts>

Use of exception handlers separates concerns and reduces redundant code. Each Action has fewer lines of code to maintain, and we know that exceptions are being handled consistently.

Newsflash:

Sponsorships for ApacheCon Europe 2007 are still available!

The conference opens May 1 in Amsterdam, The Netherlands, so time is short, but if your organization might be able to help, please contact Delia Frees at delia@apachecon.com or on +1 707 765 0823. Various sponsorship levels and other custom strategies are available. Our willingness to work with people does extend to convention sponsorship!

ApacheCon Europe 2007 is the official conference of the Apache Software Foundation (ASF). ApacheCon draws ASF Members, innovators, programmers, developers, vendors, and users to experience the future of Open Source development. Meet, mingle, and exchange ideas with like-minded participants on groundbreaking technologies and emerging industry trends, through informal networking, peer discussions, birds-of-a-feather sessions, and entertaining social events.

In related news, the US conference will be held in Atlanta GA, November 12-16, 2007. For Atlanta, I’m hoping to snag one of the whole-day training sessions or maybe an “Ajax Smackdown” presention, and then do that meet and mingle thing