Posts Tagged Java

Manipulating collections with lambdaj

My day-to-day work often consists of writing web applications that aggregate data from a number of sources. Corporate constraints frequently dictate that I cannot use languages that make crunching of collections easier so I am forced into an old-fashioned for-loop frenzy. Ugh.

On a recent java project my pairing buddy (Jules – thank you) suggested that we look at lambdaj. From the lamdbaj site: “lambdaj is a library that makes easier to address this issue by allowing to manipulate collections in a pseudo-functional and statically typed way”. The following examples are very contrived but I’m sure you’ve seen something like them:

Old school:

List<Customer> activeCustomers = new ArrayList<Customer>();
for (Customer customer : customers) {
  if (customer.isActive()) {
    activeCusomers.add(customer);
  }
}
List<Account> accounts = new ArrayList<Account>();
for (Customer customer : activeCustomers) {
  accounts.addAll(customer.getAccounts());
}
Map<String, List<Account>> groups = new HashMap<String, List<Account>>();
for (Account account : accounts) {
  String type = account.getType();
  List<Account> group = groups.get(type);
  if (group == null) {
    group = new ArrayList<Account>();
    groups.put(type, group);
  }
  group.add(account);
}

New hotness:

List<Customer> activeCustomers = select(customers, having(on(Customer.class).isActive(), equalTo(true)));
List<Account> accounts = flatten(extract(activeCustomers, on(Customer.class).getAccounts()));
Group<Account> groups = group(accounts, by(on(Account.class).getType()));

My verdict: lambdaj certainly lives up to its promises. Obviously the old-school java code will be faster but is it easier to write or more readable? You decide …

Tags: , ,

Update to S3DropBox

I’ve released a new version of my S3DropBox. You can now right-click on any file to download it, delete it or create a public link to it. Comments, feedback and bugs are always welcome.

Tags: , ,

Testing anti-patterns for developers

I’ve been saving this rant for a while now:

1. Test everything at the front-end, in exquisite detail – every project sponsor understands what tooltip 0 really means. Also a great idea if you like long-running and fragile tests that require deployments, browsers, testing frameworks and the kitchen sink. Testing at different layers, and perhaps even without a browser or (in java) a servlet container is for the weak.

2. Perform a database cleanup before and after every test, whether it needs to be done or not. For the truly adventurous add something about clearing out JMS queues and stopping scheduled tasks while you are running the cleanup tasks.

3. Always use the same data for tests, and better still use the same data for different tests. That way you will have do perform anti-pattern 2 with no questions asked. If anyone does ask about random or unique data just scoff sagely.

4. For those tied to java, run each test in its own JVM. If you happen to use a DI framework with lots of XML make sure it is initialised completely for each test. If anyone mentions forkmode=once just pretend to ignore them until they go away.

5. Write your application so that you need a JavaScript enabled browser before you can test anything at all. Progressive enhancement is only for those who cannot see.

Catharsis.

Tags: , , , , ,