Posted by Lars Vonk in the wee hours: July 31st, 2006
We are currently working on a project that uses an Oracle 9 database, Hibernate as ORM tool and Spring for our dependency management. Our application processes millions of records per month which means that some tables will grow with approximately 15 million records each month. For maintenance and performance reasons it is a must to partition these tables. But does partitioning fit into Hibernate, and if so, how?
Posted by Okke Harsta at around evening time: July 30th, 2006
You have finished your first iteration in your project and in order to get feedback from the business you wish to have your application deployed on the test environment. In many projects the test environment is maintained by the developers. That is fine, but the acceptance and production environment are not. Why not start packaging and delivering your project artifacts like you would with a production release? This way you have a chance to fine-tune this process. When the time comes that you will have to deliver to an acceptance or production release you will have automated this process, aligned it with the expectations of the department responsible for deployment and, hopefully, made it less fallible. Where to start?
Posted by Serge Beaumont around lunchtime: July 19th, 2006
We’ve put up a new article. Summary follows:
Polymorphism is the main mechanism to create maintainable object-oriented code. Client code uses other code through an abstract interface, and as long as we don’t break the behavioral contract, we can change the implementation behind that interface at will.
You will only achieve real maintainability if client code has dependencies to other code through an abstract interface and nothing else.
Unfortunately creational logic will – by its very nature – break this rule. When you create an instance, at some point you will
need call the constructor on the actual implementing class. This creates a dependency that prevents you from changing the implementation transparently, effectively cancelling the advantages of polymorphism.
The solution to the creational problem is to protect the abstraction by hiding the creational logic from the client code. Dependency injection is the ideal solution, in this case the client does not use creational logic at all. But in its turn the injecting code needs to create real instances.
This article is the first of a series of three: this article will illustrate how the creational problem manifests itself, the second will deal with some advanced implementations of creational code, and the third will deal with dependency injection.
Posted by Okke Harsta just before lunchtime: July 16th, 2006
How to deal with platform environment (Test, Acceptance, Production etc.) specific variables in Java applications?
Applications often need resources like databases, third-company web services, ldap servers and other external systems. It is common practice to externalize the configuration of such resources. In the case of a database dependency the use of a DataSource (hiding the complexity of configuring and connecting to the database) is a good example of this. The details of the configuration are in most cases platform environment specific. So how do we properly externalize the details of the configuration?
Posted by Viktor Grgic mid-afternoon: July 14th, 2006
Technical experts are often hired to fix some problem which hasn’t been solved after spending huge amounts of time and money. An example could be trying to integrate legacy code with an object-oriented environment. The expert will typically try to address all mentioned problems. He uses his knowledge and experience to approach the problem in the most effective way. Experienced experts have many possible solutions and they choose the best one.
Wouldn’t be much easier and cheaper for everyone if the first step in every single approach would be to ask: “How do we make this problem disappear?”. It’s funny to find out that almost everyone involved already knows the answer, but those who considered it didn’t have the courage to propose it. Why? It’s often because too much money is already spent on a problem which shouldn’t be there in the first place, especially by the people involved. This is maybe the main reason why external audits are so important.
This happens quite often in J2EE world. For instance a less experienced technical team is asked to write use-cases. The lead developer / architect decides to develop a “state-of-the-art” framework for all future problems, not just this one, just in case someone should be needing it. This team will have one certainty: the more you want, the more problems you will generate, until you spend lots of effort on technical problems that weren’t even requested by the customer…
Posted by Serge Beaumont in the early morning: July 13th, 2006
Through the years, I’ve noticed a correlation between experience and the complexity of the software we produce.
There are three phases. In the beginning you don’t know much, so you create simple things: you simply don’t know how to do complex things. The second phase is when you learn techniques that allow you to tackle complex problems (patterns, patterns everywhere!). In the second phase you use every trick you know, because you can. The final phase is that you know when not to use advanced and complex techniques because the cure would be worse than the problem.