Year: 2008

Categories
Development

DNS SOA

This is a pattern I’ve seen in many hosting situations, and ended up debating a little while back. It’s the one-DNS-name-for-a-machine-and-lots-of-services-on-it pattern. 😉 Among the services is typically a SubVersion repository, Maven repository, Maven proxy, Hudson, Wiki and and maybe some other stuff you use when developing. When migrating to new hardware the discussion about timing and responsibilities pops up. The usual plan: A big bang migration with a change in the DNS to point to the new machine.

This brought to mind  some important things to remember when designing services. The funny thing is that this doesn’t just apply to SOA in the sense of integration across a network. These are important things to remember even if you are designing straight up internal object calls.

Connect to the interface or role, not the implementation. In the above scenario, meaning: Use a DNS name for each service, and not the DNS name for the machine. This also applies in Java where you use the interface of the service, not the implementation of it. Think in roles roles. 🙂

Use business meaning names for services and methods on them. Don’t call it LDAPLookUpService, it is a UserAuthenticationService and should have a method called authenticateUser(username, password) not getUser(username, password). getUser will be (mis)used for lots of different stuff that has nothing to do with authentication. With the DNS case this can be a bit trickier since your SubVersion client will of course be tied to a SubVersion repository. It could be handled by calling it http://sourcecontrol/svn/, but that would of course tie several sourcecontrol systems to be on the same machine. Better than the original case though.:) And if you absolutely must, you could do some proxy magic with Apache.

In the above case if each service did have it’s own DNS you could migrate each service separately, only changing the DNS for the specific service that is beeing moved. This would give you a more controlled step-wise migration, and different downtimes for different services. Having the SubVersion repo down doesn’t necessarily match the same timeslot when you can have the Wiki down.

So should this stuff really be handled by something like UDDI? Maybe. Does SubVersion support UDDI? Don’t think so. 🙂

Categories
Development

Clover saving time in development

I read this post about Clover and using it to minimise the number of tests run. A nice idea, so I decided to have a go at it.

What it does is use the test-coverage that it was originally written to do, to figure out which tests exercise which classes. So when you change Class1 and Class2 it knows which that Test1, Test2, Test3 and Test4 need to be rerun to check if you have broken anything.

I did an initial test on our build which takes almost 10 minutes. I’m of the slightly paranoid type so I like to run the full build to verify my changes, at least before I check in. With changes in one class Clover figured it should rerun about 20 tests, and ran in about 4 minutes. That’s 6 minutes saved many times a day for each developer. We’re not using it at our build server just yet, but trying to save time for each developer before commit.

Any downsides? Of course. The initial time (mvn clean removes all info) to build is almost doubled for my project. You won’t catch all errors, and updates to dependencies won’t be caught. And there is a problem handling deleted classes. For some reason it creates a optimized-src directory which is a copy of all your sources and compiles from there. If you delete a class in your src folder it won’t be deleted in optimized-src and you could get compilation errors. After some initial tests it seems these problems are bigger in theory than they are in real day situations.

Using Clover should be no excuse bad tests though. I know all too well how I can really mess up my own tests. The long test times often stem from our inability to focus on testing the logic separately from infrastructure as databases or external services. And of course loading the Spring context is done way too much. But that’s stuff for another post.

But even if you have good unit tests there will be time to save. And everything that can keep me from getting distracted when developing is a good thing.

I’ll give this a good run until the 30 day trial licence expires, and maybe invest. Maybe we will see something similar in Cobertura too…

Update: It looks like it is also activated when doing mvn eclipse:eclipse . Because it redefines the source folders to target/clover/src-optimized this is also what is written in you Eclipse project. So be sure to have an easy way to disable running if you’re going to use this.

Categories
Development

Scala and JRuby compared for scripting

Daniel Spiewak has a nice post on comparing JRuby with Scala for a simple script. Some minor errors, and discussion about how to write them best in the comments. But overall a pretty good comparison.

At least for a Java guy like me, I think Scala will be much easier to pick up. And I even get to keep my strong typing. 😉