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

For loop fun

So I was just doing a bit of reading about Java for loops, and something occurred to me that I hadn't really thought about before, I knew it implicitly but didn't really think it out loud, so to speak.

Two methods, same function (very trivial):

public void hello()
{
String outsideLoop = "0";
for(int i=0;i<5;i++)
{
outsideLoop = ""+i;
System.out.println("The value of outsideLoop is: "+i);
}
}

public void hello2()
{
for(int i=0;i<5;i++)
{
String outsideLoop = "" + i;
System.out.println("The value of outsideLoop is: "+i);
}
}

The main difference here is that in the first method, the variable outsideLoop is available to the rest of the method, if we were to add more functionality. In the second method, this value will not be available. The compiler should optimise the second example to ensure that outsideLoop is not created at every call in the loop.

So I guess it depends on whether you are interested in retaining (and using) the state of the internal for loop variable or not.

Language-level Properties in Java

First class support?

Bean bindings API?

Diametric Orthogonal

Property - Field that has behaviour associated with it.

propertychange listener

glazed list

Proxy servers and loopback addresses

Have a small issue to note when setting up Tomcat and a small web app on my home PC tonight.

Was trying to access this URL: http://localhost:8080/manager in IE but it was giving me an internal server error. If I changed it to http://127.0.0.1:8080/manager it worked fine. First thing to check is my hosts file:

127.0.0.1 localhost

Yep, no dramas there. Hmm. What about Firefox? Works for both localhost and 127.0.0.1. Strange. Then something triggers my memory, I remember setting up IE to use a proxy server when I was doing some security testing of the surveymonkey.com site (for fun). So I get rid of that proxy connection and everything works as it should.

I was under the impression that the host file mappings (and thus the loopback address) would be looked at and resolved *prior* to leaving my box, rather than going out through the proxy server first? Something to read about I think.

Powered by ScribeFire.