BarCampSydney v3

At the 3rd Sydney BarCamp, we've got quite a good turnout here and the venue (UNSW) is working out really well!

In a data portability talk now - talking about integrating the data between each online app - facebook, google, etc. Why can't we agree on one data standard?

To me I'd say that it's partly because these app developers don't want to have a standard because it makes their platforms more competitive with each other? (Apparently this isn't so because most companies realise that being competitive means providing better functionality than competitors, rather than locking people in using proprietary formats. This will especially be the case once market expectation makes this a mandatory requirement).

Copying flickr photos from myspace to facebook etc. is a pain in the butt, it's ridiculous that we should have to copy photos from one app to another.

Have photos in a central place?

dataportability.org

scoble

JPA 2.0 - What's coming

A presentation given by Mike Keith from Oracle (co-spec lead of JSR 220) last year at a local JUG meet brought up some interesting information about JPA 2.0. The goal of it is to fill out the standard from 80-90% to 95-98% and the way they plan to do this is to add the features most asked for by developers, which he did at an extended feedback session at the end of his presentation.

The most exciting features they're looking at introducing to JPA 2.0 are:

- Collections of 'basic' objects - like Strings, Dates etc.

- Ordered lists where order is maintained - e.g.

@ManyToMany @OrderColumn(name="EXECUTION_ORDER")
List rules;

- Enhanced query expressions - like Hibernate criteria queries.

I'm currently using JPA with Hibernate extensions, hopefully in the not-too-distant future we can switch to a single feature-rich JPA implementation.

Configuring a new Java project

Since I started working as a software engineer something has always been bothering me and I couldn't quite put my finger on it. A number of things that I thought might have been the problem became clear to me (like not setting up logging clearly and failing to communicate how it should be managed and maintained with your team members) but not until now has it been this clear and obvious.

From my experience it always seems as though the project setup and build process is an afterthought and quickly becomes a time-consuming and difficult to maintain hack. You know what I mean, horrible ant build files that have a million directory specific build exclusions and inclusions; mixed up unit test configuration files; unclear logging processes; missing jar files - it all has a crippling effect on the willingness of developers to fix the problems (they're too scared to touch the build files in case they break something). Surely I am not the only developer who's felt this pain?

One thing became glaringly obvious tonight, in fact it seems so obvious to me that I am posting this to ask you guys why on earth it isn't a standard practice. Am I missing something? Is there some sort of obvious problem with this approach that I have missed?

I believe this is the root cause:

Unit tests stored in the same project as the main application code. Why aren't unit tests stored in their very own, very separate, project in an IDE? Why is it that every project I have worked on has a source directory (inside the main application code project) specifically for testing? When the test code is in its own project it's amazingly simple to manage the build process for your actual application and amazingly simple to maintain your test code without getting lost and confused. The clarity it provides is mind-blowing, at least to me.

So what I want from you guys is an explanation as to why this isn't standard practice (as far as I'm aware)? Is there some sort of fundamental problem I haven't yet found with this approach? Or have I just been working with crappy developers? ;)

Over to you guys..

GC and String intern links

http://www.thesorensens.org/?p=14

http://www.javaworld.com/javaworld/javaqa/2003-12/01-qa-1212-intern.html