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.
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…
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.
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. Read more…
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. Read more…
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 Read more…
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 Read more…
Here in the midwest we were inundated with a massive snow storm this weekend. I took the time I was stuck inside to finally give Groovy (and Grails) a day long once over. Recently I have checked out Scala and JRuby. I have to say, I like them all at this point. I definitely haven’t spent enough time with any of them to endorse one over the other, but it is exciting to see that the JVM is being ‘extended’ beyond plain ol’ Java.
If I was pegged down and had to pick one considering the limited time I have spent with them , I’d say I’d go with Groovy. All other things being equal, I like its closure style and Grails simply rocks. All the playing I did was really simple, but I tried enough scenarios to determine it would be capable of handling some of the database and domain scenarios I would like to throw at it.
I’m definitely going to get more into these dynamic languages for the JVM.
A few years ago, I worked as a consultant at a company that used DB2/400 as its main database platform. The company did not have journaling ‘turned on’ so their database platform did not support transactions/commit control. This did seem odd to me, but what I’ve found is that its pretty common that DB2/400 shops don’t use this feature. While this seemed like a mere oddity and an inconvenience for commit control, it actually caused a more measurable issue which was that we couldn’t use Hibernate, one of, if not the most common ORM framework. Hibernate requires transactions. This is a problem for anyone wanting to use a non-journaled DB2/400 instance… in particular me. Read more…
One of the cool things about the new job I will _officially_ be starting in November is that we are going to look to use open source tools first. The biggest choice we have to make on that front is which open source application server to use. We have the go ahead to get an environment setup and in-use for some pilot applications that are less mission-critical than most of the apps we have on our primary WebSphere servers. Now comes the time we need to decide which open source application server(s) we will use. Read more…
