Archive for March, 2010

Publish or perish

Wednesday, March 31st, 2010

As the old adage goes, one needs to publish or be forgotten. It’s been quite some time since we gave you Pro Spring 2.5; in that time, Spring 3.0, then 3.0.1 came out and we’re all eagerly awaiting Spring 3.1.
Now, I’ve been fighting off the writing bug for quite some time, but no more. I am starting work on the new Spring “book”, except this time, it will not be a book at all. I will publish the PDFs of the various chapters here on our blog and I will also run the best parts of the text in the Open Source Journal–yes, the printed edition.
So, keep an eye on this space for the first chapter–give me 2 – 3 weeks from now!

Spring MVC on the iPhone

Thursday, March 25th, 2010

…and, as we discovered at the Open Source User Group meeting on 24th March, also on the iPod Touch!
If you’d like to explore in detail the application I used yesterday, download it from GitHub. The webapp uses, as the headline suggests, Spring MVC (with particular focus on ViewResolvers), and alongside the bog-standard JSP code, exploits jQTouch to make the iPhone/iPod Touch interface look very native app-like.
Alternatively, if you don’t want to get messy with the source code, you can just download the Spring MVC iPhone Slides.

Memory management module updated

Wednesday, March 17th, 2010

I have made significant updates to our memory management and garbage collection training module. Previously, I left out the details of the memory manager in the OS and some of the hardware details of the UMA platforms. I also skipped the low-level details of the JVM and covered just strong, weak, soft and phantom references.

With the new version of the module, the first attendees are going to explore how deep the rabbit hole really goes! I talk about the various types of memory in a computer, then show how the operating system presents this memory to user processes (see Figure 1).
Low-level memory overview
I then take a plunge into memory management in user processes. I start with the simplest memory management strategy: reference counting. Even though it is not applicable to Java and [safe] .NET code, it is still widely used strategy.
Once the reference counting is out of the way, I look at true managed environments. I explore the operation as well as management of the managed heap. The example slide in Figure 2 shows what the JVM does to allocate an object on the heap.
Managed heap
Next, I show what happens when the JVM frees some objects and I don’t skim on the details. You will learn about the defragmentation strategies and you will understand exactly why generational heaps are an excellent idea (see Figure 3).
Heap compacting
But that’s not all. Lifecycle of Java objects is not simply active -> freed; Java objects can be finalizable, in which case, the garbage objects fester around until the finalizer thread deals with them. (Does ‘festering’ sufficiently convey the fact that finalizers are generally not a good idea? Yes? Good!)

Obviously, I did not remove the content on the reference types and their operation and typical usage. So, after taking this module, you will have a good understanding of what the OS and the JVM does to manage memory. You will also be able to use this knowledge to make your Java programs perform much better by configuring the garbage collector and using the appropriate references in your code.

A word of warning, though: this module is complex and you may be wishing that you did not sleep through those hardware architecture and discrete mathematics lectures!

Training offer–not for the faint-hearted

Tuesday, March 16th, 2010

We have exciting new addition to our training programme. Our best trainers, Jan or Aleksa, can deliver a workshop, where the trainers and the attendees will analyse, design and implement a problem you are currently facing in your development. Our trainers will be able to combine their extensive experience in domain-driven design, Java EE (particularly the light part of Java EE: the Spring Framework, Hibernate, JMS, JMX) with a bit more abstruse AOP, logic and expert system programming. The trainers will also call on their deep understanding of the fundamentals of the UNIX and Windows operating systems, principles of relational databases (we wish today’s RDBMSs actually used the relational algebra). Even though we understand the operation of the Java VM, know the theory and practice of concurrency, garbage collection and can can [endlessly] discuss the merits of dynamic vs. static, strong vs. weak typing, we will never use Java when there are much better languages for a particular problem. We regularly use Ruby, Groovy, ObjectPascal and Erlang; we have dipped our toes in kernel-mode C programming and microcontroller assembly.
Languages alone are not the complete solution, to get the best results, we combine the right language with the most appropriate runtime environment–”we know the lot”, from console applications, through servlet containers such as Tomcat, to OSGi environments such as Eclipse Virgo.

If you take up our offer of workshop, all our trainers will need is a keen team of developers and a room with whiteboards or flipcharts. It will be up to your team to pick any problem you are currently facing. Our trainers will then discuss the problem with your team to understand it fully. We will then coach your team through the best possible solution. Our trainers will help your team discover the best design and the most appropriate implementation strategy. We will not stop there, our trainers will then work with your team to implement the solution entirely, or, to implement the most difficult portions of the solution.
The workshop is by far the most demanding session on your team as well as on our trainers. We ask that the team members that attend the workshop are not afraid to try new things, that they are prepared to tackle, understand and learn completely new concepts.

The workshop events are the best way to discover the unknown unknowns; our trainers may be able to show you approaches that you had never considered and that will bring immense productivity boost to your project.

Oh, and one more thing: depending on the trainer, we will need a steady supply of coffee and biscuits for Aleksa or tea and vegetables (preferably iceberg lettuce, carrots and celery) for Jan.

Spring and iPhone

Monday, March 15th, 2010

The talk for next week’s open source user group is ready. I will give brief overview of Spring 3 MVC and explain how to create native-looking iPhone web application using as little code as possible.
It would not be a proper user group talk without a live demo, so bring your good selves with your iPhones and we’ll create a Spring MVC application that looks just amazing on the iPhone, all within about 25 minutes!
Figure 1 shows what we will achieve: the iPhone will send a request through the Internet to our Tomcat, where our Spring-driven MVC application is going to process it.
smvci
Figure 1. Spring MVC & iPhone

Lucky us–OSJ editorial

Wednesday, March 10th, 2010

A few weeks ago, I had a chance to catch up with a friend from university days. Inevitably, we ended up talking about our jobs. We both had a little moan about the amount of work we have to put in.
I can honestly say that not a week goes by where I start something in the office and simply have to continue working on it at home; not because I must, but because it is so bl**dy interesting that I cannot wait until the next day. We are all very lucky to work in a field where work can be so fascinating that it stops being work and becomes play.
However, this play quickly turns into frustration when you have to use something that you paid for, that the vendor says should work, but doesn’t. Closed source, anyone? If a closed source component doesn’t work, I can report a bug to the vendor, but what next? Sit around and wait for a response? Hack together a workaround in my free time? No thanks, I’d much rather be out in the Peak District.
By all means, go ahead and moan about work with your friends, it is therapeutic. But know that we are lucky to be able to work with open software!

Domain driven design

Tuesday, March 2nd, 2010

Almost every developer will agree that DDD is important. But what is DDD and why exactly is it so important? The best way of looking at this is to consider the conceptual differences between DDD and non-DDD scenarios.
But, you say, aren’t we are doing DDD simply by carefully separating our applications’ tiers into domain, repository, services, web, and et cetera? I can see the domain tier in my application; the only things that live in the domain tier are the domain objects, therefore my application uses DDD. Right?
Well, possibly. It is important to make clear distinction between domain objects as buckets for data and true objects, that is things with data and behaviour. A good indication of buckets of data situation is where your services contain a lot of non-transactional logic that shuffles data in your domain objects. A system implemented in this way is very similar to the old-school procedural programming approach. In procedural systems, there are no objects, there are only data structures and procedures that operate on those data structures. Keep term here is data structure; a data structure can be very rich:

typedef struct __INVOICE_T {
  int id;
  char invoice_number[100];
  supplier_t supplier;
  date_t invoice_date;
  invoice_line_t *invoice_lines;
} invoice_t;

in C is not that different from

public class Invoice {
  int id;
  String invoiceNumber;
  Supplier supplier;
  Date lastLogin;
  List invoiceLines;
}

The similarity is striking. Both structures (the C structure and the Java class) are simply holders for data. Both objects hold enough information to calculate the sum of all net amounts on all invoice lines. This is where the difference between procedural and true DDD code becomes apparent. In procedural approach, you would write a procedure (by all means in a service-tier object, but ultimately a procedure) that takes the Invoice or (invoice_t) and returns the total.
A DDD approach would be to have BigDecimal getTotal() method in the Invoice object. This is the simplest take of the DDD world; the methods in your domain objects could and should do as much work as possible. This is because the functionality of the domain objects is available to all tiers of your application.