Continuous Integration Patterns (and Anti-Patterns)

I have these nagging questions about the way I've setup a few of my CI builds. (Blog-In-progress)

1. I have a very granular Hudson build where each of the major build steps are individual jobs rather than have one job that calls each of the steps.  There are pros and cons to this. One of the reasons I chose this is to get better feedback I know what part of the build broke. The other reason was that it was easier to re-order the tasks in a build. I wish Hudson allowed a) build steps to be commeted out, b) build steps to be described c) build steps to be inserted or d) build steps to be re-ordered.  The cons are that there is more to maintain and more to have to replicate when I want to add another branch to CI.

1. Is it an anti-pattern to use a task (such as a special clean) that is not part of the developer's normal workflow?  I have a groovy task just for the CI that is two lines in a groovy script.  Less code, but it sits outside of the normal use of developers so I forget about it being there and it wouldn't get changed if the main developer's clean got changed (violates DRY).
   

Burgers are burning.. gotta run.

HBW0777 Sears / Craftsman 1/2 HP Chain Drive Garage Door Opener

Problem: Neither of the remotes work but the manual button bar (the wired one in the garage) and also the keypad operate normally. The green LED behind the manual button bar flashes. The batteries in the remotes are fresh.

Fix: Get on a step ladder and press the green button up in the center rear of the motor housing. I couldn't dig up the manual but I believe that the system is in a secure 'lock' mode which disables the remote sensor for use at times when you will be away from home for a long period.  It is possible that someone pressed a combination of buttons on the remotes and caused this, or that holding the manual button for a certain period of time enables lock mode, but I don't have the manual and could not locate it on-line and the buttons on the remotes do not have any labels on them.

Other problems I've had:  Door reverses direction in the middle of closing. If the motor runs too fast and causes some binding when the door reaches the arc of the tracks, the system reads this as an obstruction and reverses. Solution 1: There are two slotted adjustment ports (they look like plastic screws) in rear right-hand side of the motor housing. These allow you to adjust the speed of the motor, one adjusts opening speed and one adjusts closing speed.  Fix: Slow down the motor on the closing side.  Solution 2: It is also possible that the optical sensors are out-of-adjustment and need to be re-aimed.  It is possible that the tracks are loose or mis-aligned.  One or both of the optical sensors may need to be re-aligned up or down.

System Details: Sears/Craftsman 1/2 hp chain drive, manufacture date: 11/93.  Model: HBW0777.  Logic Board Part No: 41A4315-7A.  If anyone has the owner's manual for one of these please forward the URL.

Fantasy Footbal as Introductory OO Metaphor

I try to collect good OO Metaphors and this Fantasy Football domain example has just-enough complexity to be useful yet easy to comprehend without having to be a sports fanatic.



Domain Model (buckets of nouns that can also 'Act')
league
commission
commissioner
official
team
owner
manager
general manager
coach
player

Services Model (buckets of verbs associated with domain object actions)
manager.add( player )
manager.fireCoach()
coach.callTimeOut()
player.play()
player.transfer()
owner.transfer( player )
team.play()
team.goTo
official.reviewPlay()


Attribution

I heard this one in October 2006 during a discussion among two of our best Software Architects.

There was some debate as to whether domain objects should have behavior or just be POJOs and whether the service layer should provide all behavior strictly. [See Transaction Script Pattern (all business logic belongs in Service tier)]. 

On the POJO side, it was asserted that most simple VOs can (should) be generated (from Hibernate mappings) ang that DTOs represent a totally unnecessary layer that needs to be coded & maintained and that it was wrong to require that they always be used.  All agreed that DTOs should have no behavior and it would be an antipattern to do so.

Expand upon the definition of Value Object (VO) vs Data Transfer Object (DTO).

Expand upon the concepts of where business logic belongs.  This used to be a major hang-up prior to the 'Service' concept was popular.

Expand upon the concepts of:

• Value objects as data types (rather than intelligent beings with autonomous capabilities)
  
• Should Domain Objects have Behavior?
  
• "Middle Tier as Service Layer" aka "Service Layer as (a) Tier"
  
• Service vs Business Process
• Service vs Function 
• Parent/Child composition hierarchy
  
• Service as bucket of Functions?
• Shared/Reusable Function vs Reusable Service
• Facade
• Domain
• Dependency
• Where does EJB fall in the service vs pojo continuoum?