Small Code Differences

I enjoyed this post about a scenario where code goes through an evolution based on different types of developers discovering it in succession and applying their own ‘style and wisdom’ to it. The post itself was creative and interesting, but the coolest thing about it are the comments, in my opinion. People are getting downright crazy about it. It just shows how literal, logical, and nutty we software developers really are. To each his/her own!

Unit Testing: The proving grounds for the team

After weeks of development a change in a fundamental aspect of the domain has surfaced. To outsiders (read: the business) this change may seem insignificant, but to people who write lines of code, it is understandably a relatively big issue.

Value Objects vs Tool/Framework Bean Req's

A recurring scenario is annoying me. The scenario is this: Create a value object, in the Domain-Driven Design sense, and use it in a Hibernate persisted domain model. Following the DDD style, a value object shouldn’t have a default constructor, because its state should be present upon it’s creation as arguments to its constructor. It should be immutable and have no setters for its state. This won’t work if you’re using any tools/frameworks that require default constructors on the objects in your domain model.

Value Objects vs Tool/Framework Bean Req’s

A recurring scenario is annoying me. The scenario is this: Create a value object, in the Domain-Driven Design sense, and use it in a Hibernate persisted domain model. Following the DDD style, a value object shouldn’t have a default constructor, because its state should be present upon it’s creation as arguments to its constructor. It should be immutable and have no setters for its state. This won’t work if you’re using any tools/frameworks that require default constructors on the objects in your domain model.

I'll be heading to Agile ITX this summer

For a long time my career had me doing a whole lot of product installations and integrations where domain models and agile development didn’t necessarily fit.  Any conferences or training I attended was based on specific product issues

I’ll be heading to Agile ITX this summer

For a long time my career had me doing a whole lot of product installations and integrations where domain models and agile development didn’t necessarily fit.  Any conferences or training I attended was based on specific product issues