I'm really starting to like the ideas behind Google Web Toolkit (GWT), which allows developers to write client-side code (e.g. HTML, CSS and Javascript/Ajax) using Java... Yes, that is correct - you can write your browser-based UI in Java and have it compiled into Javascript before being sent tn the client for rendering!

The GWT team are pitching that the resulting client-side code is very compact (and hence performant), and also takes care of cross-browser issues by compiling multiple browser-flavours of your GWT code, and sending only the appropriate optimised  code after the client's browser has been detected. You can also do lots of cool stuff like debug your Java code responsible for the UI generation in real time - that is, you can set breakpoints and watches in your Java code, which will be triggered when you interact with the compiled Javascript in the browser.

You can find more info from the GWT home page over at Google code, but I personally wanted a more high-impact overview which I have found in several videos of Google I/O sessions:

Check out this presentation for a good intro on how to migrate apps to GWT, and also a very cool introduction on GQuery, which is the GWT equivalent of jQuery .

http://code.google.com/events/io/sessions/ProgressivelyEnhanceAjaxApps.html

This is also a good presentation, which shows some of the more programmatic low-level concepts, such as how to build a GWT-flavoured app, recommended design patterns, and also includes a demo app

http://code.google.com/events/io/sessions/GoogleWebToolkitBestPractices.html

And finally, a very cool video showing how the Google Wave client UI was built using GWT

http://code.google.com/events/io/sessions/GoogleWavePoweredByGWT.html

The fact that I often wear both client-side and server-side developer hats in an organisation makes GWT an appealing toolkit. I am very comfortable with Java, design patterns and Unit Testing, and typically my hair-pulling days involve Javascript or cross-browser issues. If I can write my whole app in Java using accepted design pattern and unit tests, and then have GWT deal with the fiddly issues such as cross-browser problems, I would be more than happy! I also believe the prevalence of this type of toolkit strengthens the position of Java within the developement market, and as I am a Java Consultant, I quite like this...

My final comment is that Google is playing it very smart in the rapidly growing browser app market lately (not that they ever play it dumb...) - UI platforms are converging, for example modern mobile devices are increasingly offering fully-functional browsers, and many apps traditionally confined to the desktop are now being served via the browser (i.e. email, word processing and document sharing). Released from the shackles of a desktop machine, many of these apps are now also benefiting from being location-aware.

Google is primed for this kind of shift - GWT allows developers to build a flexible, performant and highly compatible browser app and Google Gears takes care of any persistence and desktop interaction limitations of current browser deployment. Google is also investing heavily in the new HTML5 developments, which I believe will only serve to augment the functionality offered by their existing toolkits and platforms (check out the new Firefox 3.5 Release Candidate which supports some of the new HTML5 features). Finally, I think we all know how much Google is investing in location-awareness, location-based services and GIS.

It might be time to buy some more Google Stock...

Daniel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS

As a JME developer who builds applications which will be deployed to multiple device types it can be tricky knowing which platforms and tools support the various JME functionality and JSRs available.

Sun has very thoughtfully produced a nice article to help with this problem...

http://java.sun.com/developer/technicalArticles/javame/stateoftheunion/

In particular the platform/tool comparison matrix is priceless:

http://java.sun.com/developer/technicalArticles/javame/stateoftheunion/#8

Daniel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS

As a Google Maps API developer I have recently been thinking about where this kind of API sits within the Geographical Information System (GIS) application domain. GIS is big business, and many large companies and organisations that are responsible for managing distributed assets rely heavily on this type of application. Until several years ago GIS applications were often deployed “behind the scenes” out of the public eye, and tended to be highly specialised, very technical, and when initially constructed both the data itself and transfer/storage mechanisms were quite esoteric. I refer to these as first-gen GIS apps (although I’ll caveat this by stating that there may be existing classifications of GIS apps, of which I am unaware).

2005 heralded the arrival of second-gen GIS apps for general public consumption, which presented a nice Web 2.0 style interface and associated APIs for global mapping applications, such as Google Maps. Now in 2009 everybody and their cat are using these applications daily...

In addition to the locations of roads, petrol station and tourist attractions which are currently spilling out of Google Maps there must also be hundreds of other first-gen GIS applications around the world that hold interesting data. Obviously some of this data is not for public consumption, but even if the data is destined for private use it would surely be reasonable to assume that an organisation could benefit from combining their existing GIS data with the user friendly and highly malleable second-gen style of GIS applications, albeit in a restricted fashion? Combine this with the prevalence of today’s low cost GPS devices, for example packaged within many modern mobile phones, and also the emergence of services such as Google Latitude, we are rapidly hurtling towards a location-aware and highly contextualised future which will only get better with access to more and more data...

So, how easy would it be to integrate first and second generation GIS applications? My main research questions revolved on where the functionality of Google Maps/Earths type applications sit within the GIS domain, identifying any interesting nuances with storing/manipulating data, and the type of functionality offered in terms in interoperability. The preliminary research turned out to be quite interesting...

• GIS apps tend to specify locations and geographical features by latitude, longitude and also elevation. Google Maps doesn’t manage elevation, as this application provides a 2D view onto the globe. Google Earth on the other hand, is quite capable of handling all of this information, and now work is well and truly under way to merge Google Maps and Earth

• Although lat/lngs are used to specify a location, there are variations in different formats (or "datum" in GIS-speak) depending on the map projection used. I am assuming that if a high level of accuracy is required when integrating data from multiple sources that the datums in use throughout the applications would have to be identified and compared.  I can’t see any reason why coordinates stored using different datums couldn't be programmatically converted (more info on datums @ http://en.wikipedia.org/wiki/Map_projection#Choosing_a_model_for_the_shape_of_the_Earth and http://en.wikipedia.org/wiki/Datum_(geodesy)  )

• There are several GIS standard protocols from the Open Geospatial Consortium which may be of interest:
  • Web Map Service (WMS) defines an API to allow a high-level layered image of a specified location to be retrieved.  More info @ http://en.wikipedia.org/wiki/Web_Map_Service
  • Web Feature Service (WFS) defines an API to enable lower-level manipulation of GIS features and concepts, such as adding data to a location or spatial analysis. More info @ http://en.wikipedia.org/wiki/Web_Feature_Service
  • Geography Markup Language (GML) specifies an open XML-based interchange language to express geographical features. More info @ http://en.wikipedia.org/wiki/Geography_Markup_Language

• There is a Java-based open source reference implementation of WFS named GeoServer, which in turn is built upon another Java-based open source GIS Toolkit named GeoTools. These could potentially be integrated into both new and old GIS applications to enable the sharing of data using the above standards, essentially exposing a standard WFS API to third-party developers allowing integration of your data into their GIS apps.

Google happens (by design I’m assuming ) to be in good standing with its current GIS flavoured offerings:

• Google Maps supports WMS and Google Earth supports WFS.
• Google uses it's own Keyhole Markup Language (KML), which compliments GML, to transfer and manipulate Geographical feature data. If an existing GIS app exposes data using the above standards, then integrating this data (in addition to your data) on Google Maps/Earth should be possible.

That turned into quite a bit of text, but in a nutshell there are plenty of options to support the sharing/integration of data between 1G and 2G GIS apps, which would be made much easier if the above open standards are supported.

The open questions? Do existing first-gen GISs, which would be pervasive within well established organisations/companies, support these standards, and how do we find out about these GISs in the first place?

Daniel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS

As the title suggests, I was recently searching for a free open-source CRM with a good API, which actually proved to be trickier than I initially thought. Many of the "open source" CRMs tend to offer the majority of their code as open source, but the really useful features are proprietary and require a monthly subscription to use. Tut tut tut... The Open Source Initiative has more details of this kind of practice here...

After jumping down from my high horse I managed to find a good overview and review of existing "open source" CRMs http://www.insidecrm.com/features/top-open-source-solutions-121307/

SugarCRM http://www.sugarcrm.com/ looks very comprehensive, especially from a business/end-use perspective, although the "free" open source Community Edition only offers approx 85% of what is on show. The full product (of which there are 3 flavours) is chargeable on a monthly basis....

SugarCRM does offer an API, but I couldn't get as much detail as I would like in a quick scan (although I've found this to be the case with a lot of open source products which charge for support) The core engine appears to use the LAMP stack, which means it is built using PHP with a MySQL backend.

Another CRM that looks interesting in HiperGate http://www.hipergate.org/ which is a genuinely open source and free application. This CRM doesn't appear quite as "flashy" as SugarCRM, and I would recommend that anyone interested has a look at the business/end-user functionality in order to ensure it has all of the desired functionality.

A big plus is that HiperGate is written in Java and has an excellent programmatic API, which was exactly what I wanted for bi-directional communication between existing bespoke JEE applications and the CRM (more info @ http://www.hipergate.org/docs/api/4.0.0/ )

I don't know if anyone else has any better suggestions?

Daniel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS

Two weeks ago when I was trawling through my regular blog list I stumbled across
this article from Google, which detailed some modifications the Geo Developer team have made with the integration of Maps and Google Earth. Essentially it allows you to view your Google Map (embedded in your webpage) using the Google Earth interface i.e. you can view your map in 3D and "fly" through the terrain.

The functionality in this updated version is very cool - it even integrates with the existing pin/polygon line API, allowing you to plot all of your applications data using the usual Maps APIs, hit the "Earth" button, and as if by magic you are seamlessly transported into a 3D representation of the current map view complete with all your data (markers etc) - very cool.

Here is the basic code to get you up and running:

//...
// the code below should be in a JS
// function that is called by onload
//...

if (GBrowserIsCompatible()) {

//create map
map = new GMap2($("map"));

//set default view to G_PHYSICAL_MAP, which looks cool,
//and add the large style map control
map.setMapType(G_PHYSICAL_MAP);
map.addControl(new GLargeMapControl());

//add the new G_SATELLITE_3D_MAP to the mix
map.addMapType(G_SATELLITE_3D_MAP);

//add the GMapTypeControl to the UI to allow
//the new "Earth" view to be selected
map.addControl(new GMapTypeControl());

}

// other functions...

You may need to do some tweaking in order to get all of the data representation working correctly - all of my custom pins appear correctly, but I can't get the pin clustering images I blogged about recently to display properly...

Viewing the Google Map in G_SATELLITE_3D_MAP Earth-style does require a small plugin installation in your browser (which may hamper deployment in some organisations), but so far I haven't heard of any particular problems with any browser...

Daniel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS

In a nutshell this book reads more like a consultant’s journal than a technical manual. This is not necessarily a bad thing, and if you’re looking for a good read about life in the trenches as a technology/solution consultant, then this is a book for you. If you, like me, are looking for a technical overview on how to improve your Java application server (GlassFish, WebLogic) management skills, then this is NOT the book for you.

I am a technical consultant specialising in designing, developing and deploying enterprise applications using JEE, Web 2.0 and RDBMS. Although I didn’t realise this before I bought the book, a good portion of this text is clearly out of the scope (and area of interest) for the type of role I typically occupy within an organisation. In all fairness the book’s back cover does state that the target audience is application/system admins and IT managers, but in my opinion it even misses the mark for these three roles. There is not enough technical information for first two roles, and in contrast provides way too much content for the third (I would estimate that someone could condense the book down to 10-20 pages as an executive summary for IT managers who are looking to become aware of application deployment terminology etc)

I also have three key criticisms from a technical aspect:

1. First, no concrete technical examples are provided (such as JVM memory configurations, deployment descriptor examples, or performance testing methodologies).
2. Second, the book doesn’t provide enough detail about certain key concepts, and at the same time also talks too much about some topics. For example, at several places within the book the author labors the point about using n-tier architectures when designing applications, but doesn’t really define the concept (I already knew this from my Uni days, but the non-techies or middle managers might not).
3. Finally, and probably the most important today, is that the technologies covered are not up to date, and the book doesn’t cover important application/ORM frameworks such as Spring, EJB 3.0 and Hibernate, or concepts such as RESTful Web Services, all of which feature heavily in modern applications.

If you are looking for a technical overview of how to manage and tune the performance of your application server, and also improve your JEE applications then I would recommend these two books:

* Pro Java EE 5 Performance Management and Optimization, by Steven Haines – This is _exactly_ the kind of book I was looking for. The author provides a comprehensive introduction to performance management, a guide to optimising both application servers and applications themselves throughout the development lifecycle, and a great overview of load testing and common JEE performance problems - including excellent (and very technical) examples. The chapter on generic tuning for application servers is worth the admission price alone, and is something I have used on troubled production servers!
* Java Power Tools, by John Smart – In addition to several chapters providing technical details of tools useful for performance management and testing of your application server (such as load testing with jMeter, and Profiling with jConsole and jstat) this book also provides a very technical overview of best practice for build processes (ANT, Maven, Version Control, Hudson CI etc), development quality metric tools (CheckStyle PMD, Findbugs etc ) and Unit testing. This book is a very useful addition to any developer/consultant’s bookshelf.

In summary, there is no denying the author of Affinity knows his stuff, but the book could have benefited by defining the target audience more clearly. If your background and reasons for reading this book are similar to mine you can most likely take away a few nuggets of information from this text. However, you can acquire the same information (in a better format) from my recommendations above, and in the process also benefit from literally hundreds of other tips and practical examples for managing a JEE application server.

[The above text is a copy of the review I recently submitted to amazon.co.uk for Affinity: Managing Java Application Servers]

Daniel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS

I'm not sure how many of my fellow Google Maps developers are using the Google Maps Local Search bar, but it's actually quite cool. In essence it adds a small search box to any maps view (replacing the "powered by Google" icon) that allows a user to search locally via the current map view for things of interest (restaurants, petrol/gas stations) and also search more globally for Locations (towns, cities etc).

Enabling the search bar is deceptively simple...

// within script tag

//onload function - create map
var map = new GMap2(document.getElementById("map"));
//show the bar on the map...(yes it really is this simple!)
map.enableGoogleBar();

// end of script tag

However, configuring the bar is slightly more tricky, and the docs on this are not so easy to find. This is because you don't actually configure the bar options directly, instead you configure a GMapOptions and pass this into your GMap2 constructor. In turn this config info is utilised when you enable the bar on the associated GMap2 instance.

Here is an example that I used to ensure the search bar is open by default, and also add a callback that is fired after the the local search pins are added to the map (which happens after a user's local search completes, and the map is zoomed/panned)...

// within script tag

//onload function - create map, passing in a GMapOptions
map = new GMap2(document.getElementById("map"),{
googleBarOptions:{
showOnLoad : true,
onMarkersSetCallback : myCallback
}
});
//show the bar on the map...
map.enableGoogleBar();

//function myCallback defined here...

// end of script tag

There are many configuration options you can add once you have the above constructor setup. Here are links to the appopriate Google API configuration docs

GMapOptions - list of constructor config options available
GGoogleBarOptions - detailed list of options for local search bar config

Best wishes,

Daniel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS

I was recently looking for a nice (simple) html/javascript RSS viewer component to put on the main Tai-Dev web page which would provide a summary of recent blog posts and tweets via their respective RSS feeds. I first ran into this blog article which makes a very valid point about javascript alone being incapable (at least on first glance) of displaying RSS feeds as some processing of the feed is required in order to extract the data from the xml...

Essentially either a server-side component is required (which didn't meet my simplicity requirement...) or you can utilise a third-party service which parses the RSS feed and provides a simple javascript API to allow display on a web page. The aforementioned article lists several such third-party providers, but does warn that you will become reliant on the provider - if they disappear, so does the usefulness of your RSS viewer component...

In these slightly unpredictable times none of the provided third-parties were names I knew or filled me with confidence in regards to their reliability. However, another session of searching revealed that Google actually provides such a service as part of their Ajax Search API - you can find details of this ajax Feed API here... (and of course, I am assuming that Google won't disappear overnight )

I plugged the details of my feeds into the Google Feed Wizard and copied the resulting code into my web page. A quick look at the Feed API reference docs allowed me to customise the functionality and looks, and also offer some hints in regards to displaying multiple feeds on a single page.

You can check out the results on the Tai-Dev home page or see below...

Not bad for 10-15 mins work, and I think it looks very good (cue sound of own trumpet playing). Let me know what you think...

Best wishes,

Daniel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS

Why not check out the Tai-Dev Twitter account @ http://twitter.com/taidevcouk

I will mainly be Tweeting info when it doesn't require the full blog treatment, such as links to interesting articles or tools I'm using.

Daniel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS

A common problem for Google Maps developers who plot addresses on the map via postcode or other address data is getting the actual lat/lng coordinates of the address.

Now we all know we can "geocode" a postcode or address into lat/lng vales for plotting in real time via Google's JavaScript API (details @ http://code.google.com/apis/maps/documentation/services.html#Geocoding), but this has obviously got to be conducted client-side and is not suitable for geocoding a large (bulk) number of addresses. Frequently when you are loading lots of new addresses into a database these restrictions prove a problem...

The Solution Google also offers an HTTP Geocoding service which can be called server-side and is more suited for bulk geocoding! I'll let you read the details @ http://code.google.com/apis/maps/documentation/geocoding/index.html

However, Google don't give you much support in respect to how to actually programmatically use this HTTP service, and so I've included a pseudo-java implementation below that should be enough to get you started...

private String googleURL = "http://maps.google.com/maps/geo?output=csv&oe=utf8&sensor=false&key="; //note csv output requested
private String googleKey = "_your_key_here_";
private String googleQuery = "&q=";

//
//...
//
private void geocode(String geoTarget) {
//encode the geoTarget in case there are any non-URL friendly
//characters included (such as spaces and quotes)
String encodedGeoTarget = null;
try {
encodedGeoTarget = URLEncoder.encode(geoTarget, "UTF-8");
} catch (UnsupportedEncodingException uee) {
throw new InfrastructureException(uee);
}

//build the geocoding URL
URL googleGeocodeURL = null;
try {
googleGeocodeURL = new URL(googleURL + googleKey + googleQuery + encodedGeoTarget);
log.finer("Complete URL for geocode request : " + googleGeocodeURL.toString());
} catch (MalformedURLException mue) {
//do something
}

try {
in = new BufferedReader(new InputStreamReader(googleGeocodeURL.openStream()));

if (in.ready()) {
response = in.readLine();
log.finer("Google Responded with : " + response);
String[] split = response.split(",");
log.finer("split is " + split);

try {
//first check the response code for sign of problems
responseCode = Integer.parseInt(split[0]);
log.finer("Response Code: " + responseCode);
if (responseCode.equals(620)) {
//max number of queries exceeded
} else if (responseCode.compareTo(new Integer(201)) > 0) {
//Google indicated a problem occurred - the responseCode value will provide more info
see http:code.google.com/apis/maps/documentation/geocoding/index.html#StatusCodes
}

//response code good
//parse geocode data from CSV response...
latitude = Float.parseFloat(split[2]);
log.finer("latitude is " + latitude);
longitude = Float.parseFloat(split[3]);
log.finer("longitude is " + longitude);
accuracy = Float.parseFloat(split[1]);
log.finer("accuracy is " + accuracy);
} catch (NumberFormatException nfe) {
log.severe("Problem parsing response..." + nfe.getMessage());
}

} else {
log.severe("Unable to open URL @ " + googleGeocodeURL.toString());
}
} finally {
if (in != null) {
in.close();
}
}
}

Feel free to drop me a line if you need more info...

Daniel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS