Agile IT Experience, Day two

The day is over. The bar is still going strong… and no smoke tonight!!! But I’m done. I spent enough dough (my own) and my boss and I had enough conversation that it was time to call it a night. We have a long drive home tomorrow… after two more sessions in the morning.

Agile IT Experience, Day one

The day is over. The bar is still going strong, but too much smoke for me… and I’ve been in enough sessions on the day after a night of partying at a conference and I just dont have it in me anymore (Getting old I guess). So I ordered one last cold one to go and decided to write a few lines in the blog about today’s sessions.

Off to Agile IT Experience Tomorrow.

Well, a colleague and I are off to Agile IT Experience in Reston, VA tomorrow. It runs Thursday, Friday, and a half day Saturday. Im so ready for it. There look to be a lot of very good sessions and I plan on attending all of them that I can.

The sleepy software bug.

First thing this morning I got an email with ‘high’ priority. The subject was ‘The Learning Center seems to be down’. We’ve been having a lot of problems with the product that underlies our ‘Learning Center’ application lately (we’re currently making a major switch) so I thought it was one of the run-of-the-mill problems we knew exactly how to fix. How wrong I was. Before I explain the story, I should give you some background info…

Cue dreamy effect and go back in time…

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