This is a revision to a prior blog, 13 ASF Practices. Some elements have been condensed, and some new bits added … and now there are 11.
People often mention “Apache Rules”. We don’t actually have a rule book, but if we did, here’s what I believe might be the top eleven practices.

0

Individuals compose the ASF.
Projects must be managed in a collaborative, meritocratic way, so that new volunteers are encouraged to join the project group, and so that the volunteers doing the work are the individuals who make the decisions.
PMC members are encouraged to nominate qualified contributors as new committers.
ASF Members are encouraged to nominate qualified committers as new members.
Given sufficient time and sustained interest, the set of committers should equal the set of PMC members, and the set of PMC members should equal the set of ASF members.

1

Merit never expires.

2

The mailing lists are a project’s only venue for the conduct of business.
All development discussions must occur on the project’s public mailing lists, or be summarized to the lists, and the lists must be archived.
Development support products, like version control systems, issue trackers, and wikis, should log changes to a public mailing list.
Comments posted to a list through development support products are a normal component of development discussions.

3

The project’s private list may only be used to discuss pre-disclosure security problems, pre-agreement discussions with third parties that require confidentiality, nominees for project, project committee or Foundation membership, or personal conflicts among project personnel, and nothing else. Posts to a private list are considered confidential and must not be quoted on public lists without the permission of the author.

4

A project’s primary web site and mailing lists must be maintained on ASF hardware.
Resources maintained elsewhere are not ASF resources, even if maintained by individuals who happen to be ASF committers.

5

Project source code and documentation must be donated to the ASF under a Contributor’s License Agreement.
Donated source code and documentation must carry the ASF copyright and be placed under the Apache License.
Code and documentation donated to the ASF must be maintained on ASF hardware.
Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged.

6

A PMC member can veto a product change with a technical or legal justification.

7

A release must include the ASF source code being released, binaries are optional.
A release vote must be on the actual bits that comprise the release, preferably already digitally signed by a release manager.
An ASF release must be approved by at least three members of the PMC and by a majority of the members voting.
A release cannot be vetoed.

8

Other libraries included with a distribution may be under a different license but must be redistributable under the Apache license.

9

The PMC chair/Project VP must submit regular status reports to the ASF board.

A

Author tags in source code are discouraged but permitted.



Of course, there are other customs of Apache culture, but I believe that most other ASF practices would stem from this initial set. And, as with all things ASF, YMMV! :)

I have no idea why JIRA, Confluence, and Subversion are still separate products. (Well, being a working engineer I do have at least an idea …)

In practice, most of us use JIRA, Confluence, and Subversion as if they were one product. (A rich man’s Trac.) I’d like to be able to refer to using all three products together as “Convergence”, but that would be confusing, since it sounds too much like a real product. There’s the hollywood hybrid approach, but terms like “JirFlusion” or “ConVera” or “SuJiCo” seem distracting. Let’s just go with a simple acronym, like JCS.

At work, we use JCS for everything. When we are ready to do something, anything, we open a JIRA ticket. If it’s a coding task, the ticket will relate to a Use Case that we create in Confluence, which will link back to the JIRA ticket. When we commit the bits to Subversion, we reference the JIRA ticket, and the JIRA-Subverson plugin closes the loop.

In these days of “TeamCity“ and “Team System“, we like to think of JCS as “Team Best of Breed”, especially when you toss JetBrains IDEA or Resharper into the mix.

But, issue tracking, document management, and version control aren’t just for coders. Other workers in the enterprise been using it to draft grant proposals and evaluate accessibility compliance. These are products that any information worker can (and should) use.

At work, one of our more ambitious Confluence applications is the infrastructure documentation. I spent the last week of last year’s contract dumping everything I knew about our infrastructure into Confluence. We ended up finding another contract for me after that, and another one after that, but at the time, I wanted to be sure the team had a solid reference.

Of course, a problem with putting software documentation into software is that you need software to use the software that tells you how to install the software. Happily, between the Confluence autoexport plugin and SpiderZilla, that’s not a problem. The autoexport plugin renders the Confluence wiki as plain text, and the FireFox SpiderZilla plugin sucks it down to a local machine. Here’s the result, no server required.

The fully-loaded “Team Best of Breed” doesn’t stop at JCS. Clever shops will also want to install ViewVC, so that prior Confluence revision logs and diffs are only a click away. ViewVC means adding Apache HTTPD to the mix, but it’s worth the effort. (And HTTPD makes a good host for exported Confluence spaces!)

A developers mailing list with an archive is the final, but perhaps most important, team member. Each component of JCS can send change alerts to a list, to keep everyone in the loop with no extra effort. JCS doesn’t include an actual mailing list, but Confluence can be used as an archive.

Taken together, I like to think of these products as creating a PRIM architecture: Portal - Repository - Issue Tracker - Mailing List. Every successful open source project I know uses PRIM. Every closed source project I know, doesn’t. (Well, except mine!) Many will use two or three of the four components, but most teams will wobble on the mailing list. In practice, an archived mailing list is essential. A list ties the other components together, creating a coherent communications system.

It’s truly beyond me why more product managers don’t insist on an archived development mailing list. It’s the best way to keep track of what everyone is doing. You can just sit back, watch the emails come in from JIRA, Confluence, and Subversion, and know exactly who is doing what and what they plan to do next.
People wonder how open source projects manage to create high-quality products without managers or accountability. The answer: we’re accountable to our infrastructure.

PRIM is the open source secret sauce.

Over the years, there’s been a steady trend within Microsoft example applications. The trend has been away from what Java geeks calls Model 1 and toward Model 2 development. It’s been a forced, dragged-by-the-hair trend. At every step, the architect seems to be looking for alternatives to MVC/Model 2, and every time, the alternative comes up short, and the next iteration is one step closr to Java-style MVC.

The trend is clear if you spend a day reviewing the various ASP.NET application that were developed for ASP.NET 1.x. The trend is even more evident in ASP.NET 2.X. The platforms now offers an actual business logic component that can also be used to separate the data access code from the rest of the application. The only problem is that the component is still embedded in the web application, and, as far as I can tell, these “business logic” components can’t be tested outside of the web application. Though, it is most definitely another baby step in the right direction.

Rumor now has it that Microsoft is ready for another step toward MVC/Model 2. In his CodeBetter blog, Jeffrey Palmero outlines a new feature that Scott Guthrie is supposedly developing for the next generation of ASP.NET.

According to the blog:

---

A url might look like http://localhost/myApp/ShoppingCart.mvc/CheckOut where ShoppingCart is the Controller class and “CheckOut” is a method like:

[Action]
public void CheckOut(){
 //do so

}

The MVC model can be used with regular control-based pages. The url determines the handler that’s activated, so it can be mixed an matched. In fact, a Controller could dispatch a view that uses some controls. i.e. Telerik controls could still be used without Telerik modifying them. From what I saw, no capabilities are taken away, just more options are added.

In this prototype, the controller loads the appropriate view by relative path to the .aspx. The view can be only markup - pure template, or it can take advantage of controls. This can work without postbacks, or you can use postbacks if you prefer.

The view has to inherit from PageView or if it needs properties from the controller (like the Model to display), it can inherit from PageView where T is the type of the controller it depends on. Then the view can grab specific properties off of the controller.

I would recommend making “T” an interface so that the view doesn’t bind directly to the controller type. I’ve been collaborating with Scott Guthrie to work out the kinks. There is still a lot of work to do. This is only in prototype form.

---

Of course, Microsoft has been warming up to MVC and front controllers patterns for some time. This is not the first time we’ve heard that MVC or front controller will be in the “next” version of ASP.NET.

But, not to worry. If Microsoft comes out with a MVC technology, we will do what we always do … reinvent it as a JSR.

Since client-side JavaScript is event-driven, Ajax libraries follow suit. For many developers, Ajax is their first time around the event-driven maypole.

When event-driven controls for the first time, it’s common for a noobe to attach some application-specific behavior to a control’s onClick event. As the application grows more complex, we often want to invoke the same behavior without the help of the control. A common question then becomes “How can we send the control a change event, as if the user had himself clicked on the option?” As with many programming problems, the solution is to add a layer of abstraction. :)

Instead of attaching our behavior directly to primitive events, like onClick, we should create our own idiomatic events to describe what happens when the user selects the option. Selecting the option is a means to an end. If we create own custom event for that end, the select control change event can turn around and raise our event. Then, when our custom event needs to be raised from another point in the workflow, we can just go ahead and raise it progmatically.

It’s not about clicking the control, it’s about the action that the control triggers.

In essence, user-interface widgets raise primitive events, like “change” and “click”. This is a Good Thing, because those events represent what widgets do (or appear to do). Applications don’t “click”. Applications update state and run reports. An event-driven application should create its own layer of idiomatic events that describes what the application does in its own terms. In that way, we are not chained to the controls, and we can call our own events whenever we like. Architectually, idiomatic events increase cohesion and lower coupling. Also Good Things.

An excellent introduction to event-driven design is Christian Heilmann’s Event-Driven Web Application Design (which I like to call “Brace yourself, Bridget!).

There’s still the last mile to go, but at least the text for part one has reached its first full draft. Now, it’s down to fussing with the figures. :)

From the GoogleCode site:

Apache Struts 2 from Square One is a training course designed for people who want to create Java web applications, not just quickly, but correctly. Training sessions include a technology primer and a coding exercise. This Project hosts materials used by the course including slide presentations, coding exercises, and a companion text book. The course can be used for independant study or in a classroom setting.
As mentioned, the course is something I developed over the years for Struts 1, and then adapted for WebWork 2, and now for Struts 2. The course itself is the usual “slides and labs” affair.

Struts 2 from Square One is a textbook adaptation of the course. I’d like to print the text through LuLu.com and include it as part of the course. If people want to use the textbook for individual homestudy, that’s fine too. Eventually, what I started at the Struts University site will be migrated to the Square One GoogleCode site.

With Struts 2 in GA mode, I’ll have a bit more time to work on this, but there’s no telling how long it will take to finish the other three parts. To an extent, how much effort I can put into the text depends on whether people engage me to present the course this year.

In the meantime, an early release of the manuscript is available as a PDF. Enjoy!