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…
Read more…
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!
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.
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…
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…
Yesterday, I was doing some refactoring on some code in Rational Application Developer (a derivative of eclipse) and I ended up creating a couple of new projects to house some of it. When I told my colleague he’d need to synchronize with CVS and pull down the new projects he expressed some concern about why I had created the new projects. It made me revisit why I actually did it.
Read more…
I’m not a data architect or DBA, but in my current and past positions I, like most software developers, have been responsible for designing schemas for both simple and complex databases. One thing I always waffle about is whether to compose keys from meaningful data or generate surrogate keys for my tables.
I have always been a proponent of using surrogate, or blind, keys. The reason is that I have faced scenarios where what is said to be an iron-clad rule about the business meaning associated with a primary key suddenly changes requiring the need to change that primary key – most DBs don’t handle this well. It’s also cumbersome constructing joins on natural keys when they are composed of several columns. With that said, I do see advantages to having real meaning attached to the fields used as a composite key.
What do you think? Is this a matter of preference of the database designer or is there some rule or advantage that I don’t know of that would be a definite answer one way or another?
Here are a couple of articles to refer to for arguments.
http://www.bcarter.com/intsurr1.htm
http://searchsqlserver.techtarget.com/general/
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…
I have accepted a position at a company in Dayton. The position is with a company that I have been working for as a consultant off and on (mostly on) for the last three years. I will be a ‘Technical Architect’ in the ‘Enterprise Solutions’ group at WinWholesale. I am very excited about this new opportunity. In my new position I will be the technical leader of the group that is dealing with newer technologies. We will be making use of open source technologies where they make sense and employing an agile software development methodology. One of the most important things to me is Read more…
