Chapters at a Glance
The following is a summary of the chapter content, not a list of the included recipes; most subjects contain multiple recipes.

Chapter 1 : Getting Started with JavaFX
- Installing the SDK
- Working with IDEs
- Compiling
- Working with classes, functions, variables and data types

Chapter 2 : Creating JavaFX Applications
- Working with shapes & text
- Stage management

Chapter 3 : Transformations, Animations and Effects
- Transformation API
- Transition API and custom animations
- Visual effects, reflections, shadows et al.

Chapter 4 : Components and Skinning
- GUI Controls
- Using Swing components
- Applying CSS styling

Chapter 5 : JavaFX Media
- Working with images, audio and video

Chapter 6 : Working with Data
- Storage API
- Working with HttpRequest
- Feed API, Atom and RSS
- Using the Chart API

Chapter 7 : Deployment and Integration
- Packaging your application or applet
- Using Web Start
- JavaScript controls and parameter passing

Chapter 8 : The JavaFX Production Suite
- Exporting images (PhotoShop, Illustrator and SVG)
- Loading objects from FXZ

Appendices
- Tools, Products and Frameworks
- Best practices.

Critique
I wouldn’t consider myself a JavaFX novice, but certainly my experience is concentrated in specific areas, namely data and charting. So with this in mind I made a bee line for chapter 6 and the “Visualising Data with the JavaFX Chart API” recipe. Unfortunately I was particularly disappointed with the coverage, with one recipe only covering the basics. The charting API in my opinion woeful, although it is very easy to use and can display simple graphs it offers very few out of the box features. For example without the help of an “enhancement” you can’t even rotate labels an axis. I would therefore consider it a prime candidate for a few helpful recipes, sadly not.

That being said, although fringe areas like the chart API might be lacking the “core” recipes are strong. Sourcing and handling your data in a RIA application is vital and there is good coverage of the use of HttpRequest and fair sized recipe for RSS and Atom feeds. The examples also integrate with the likes of Yahoo weather and Goolge maps, which I think leads to a more interesting experience.

Similarly the introduction to working with JavaFX and the packaging of your product is also thorough. The book therefore caters well for new developers, as well as a few gems for the more experienced.

Not having worked with audio and video before I was keen to see what the book had to offer with that respect. Although the audio recipe was fairly simplistic I felt the two recipes for working with video made up for that; and are incidentally probably the longest the author dwells on one subject area.

As you might expect there are code samples that accompany the book, downloadable from packtpub.com. The samples I fired up all worked well and are in-line with the written examples from the book. The only minor issue being the active platform for chapter 2 samples seems to be 1.3, odd for a book targeting 1.2!

If you’re new to JavaFX development this is a good starting point, it serves as a good introduction to many of the APIs shipped with the SDK. From experience I can say JavaFX Script literature on-line is not as plentiful as most languages, so a single point of reference with this number of examples is beneficial. If you’re more experienced JavaFX Script developer you may feel you have out grown a lot of the content in this title; however the scope is broad, so it’s unlikely you will have experience with everything covered here.

It is worth pointing out, before considering this title, you should be aware that Oracle have recently announced the termination of JavaFX script with version 2.0 of the platform (due late 2011). Although the JavaFX will live on with other JVM languages, this may well be the only cookbook published for the doomed JavaFX Script.

So you’re at the stage where you’ve finished initial development your Grails application and now it’s time to get it online for the world to see. You’ve cast your eye over http://www.grails.org/hosting and EATJ is the one that catches your eye; as it’s the cheap – like the budgie. At $9.85 per month, this is pretty good value for Java hosting, and gets even cheaper if you plump for a year term, $8.21.

So let’s have a look at what’s involved:

1) Register with EATJ

As you can see EATJ lets you create an account for free, sadly that’s all it lets you do. After you have verified your email address you will be asked to “pay for your free trial”, your also instructed to contact customer support for a refund after your trial. I guess this is basically equivalent of a money back guarantee.

After paying via PayPal or credit card you then have email support@eatj.com with your username.

2) Wait

Yes, wait; after emailing customer support it took a mere three and a half hours to activate the account.

3) Set up MySQL Workbench

Your EATJ console comes with links to phpMyAdmin, which is fine if your not planning to ferret around the database much, but likely you will need a half decent browser. Obviously you can use TOAD or whatever floats your boat though.

hostname: s11.eatj.com
port: 3307
username: username
password: password

You need to check you server address in your welcome email, and careful of the port, the default one is usually 3306. Once you have connected to the database you know you have the correct settings for the next step.

Add New Connection

4) DataSource.groovy

Now put your newly determined database settings into datasource.groovy.

Change the dbCreate property if required, but as a production environment I can’t really see this being any different. Update your username and password as necessary; password is by default in clear text. If you want to encrypt the password, the clearest instructions I have found on how to do this are attached to this JIRA, there also this Release Note.

I assume at some point you would have carried out local testing on MySQL and therefore have the JDBC connector on your classpath. If not, you should get the latest version from MySQL, then simply drop the jar into your lib folder.

5) Config.groovy

You need to add the root of your production application to environments block in the config.groovy file, like with the other environments is needed for relative paths in your application.

In the example above I’m using the sub domain that EATJ provide, check your welcome email carefully though as “s11” may be different. If you want to use your own domain you can add one after logging in to your EATJ console at eatj.com, you’ll also find out the ns setting there too. Adjust your root accordingly.

6) Create a war

Now you’ve updated your production settings simply run the war command from the grails console grails war. This should then deposit the war in the target folder of you application, and will be given the name and version provided in the application.properties file. i.e. myapp-0.1.war.

7) Upload the war

You have two choices for uploading your war now, you can either use the up-loader from the EATJ console from logging in at eatj.com, or you can hit the Tomcat manager directly: http://username.s11.eatj.com/manager/html . When asked for credentials, username should be “admin” rather then your account username, but the password will be the same as your account one.

8) Check out your application

That really should be it! It’s fair to say, when I started taking notes during the process I expected to encounter a few more steps and ultimately describe a more involved process. A real testament to how easy it is to deploy a Grails application in the wild. In fact the longest part of the whole process is waiting for EATJ to activate the account!

Its worth mentioning a couple of minor issues though; perhaps more specific to my circumstances:

Get working on local tomcat first.

Interesting point here; be careful of your references in your gsp files. Jetty seems to be case-insensitive when developing in Windows, and therefore in running a Grails application in a dev set-up will hide potential errors. For example I was calling a template:

<g:render template="/landing/templateName" />

The actual file name was _templatename.gsp; an error on my part that was being hidden by Jetty in development. There does appear to be an open JIRA to address this though; worth keeping an eye on. In the meantime I recommend before uploading your war to EATJ you deploy it to a local Tomcat instance and touch each page.

Delete your tables, mine still had data!

Rather lazily and (irresponsibly), EATJ don’t appear to appear to clear down the environments very carefully. The one I was assigned had a database schema (complete with data) from a previous owner. Make sure you drop any tables that shouldn’t be there when you get an account. Similarly I’d make sure you drop all tables if/when you leave EATJ; particularly if they have people’s personal data!

So far I have no other complaints about the EATJ service; although it is fair to say I haven’t stressed it. If you can see past the ropey sign up process and poor housekeeping it seems to be good value.

As a practitioner it is often difficult to find helpful JavaFX information on-line, and given that little user content has been written so far. It is perhaps no surprise then that this offering comes in the form of a cookbook. Vladimir Vivien’s JavaFX 1.2 Application Development Cookbook is no lightweight either, with no less then 80 recipes over the best part of 330 pages.

A full review will follow…

Currently there’s only a Grails plug-in for “old-style” Java applets, and not one that enables you to leverage the Java Web Start functionality with a jnlp file.

Fortunately it’s very easy to get a JavaFX Applet into your web application. If you’re not building a Grails application, a lot of steps are still the same for any JEE application. As I found though the web is not awash with JavaFX how-to’s, probably due to it’s poor take up.

So assuming you have already developed your JavaFX applet and you have a jar and a browser jnlp file. If you haven’t, but want something to start working with here is a simple tutorial.

You now need to make a home for your applet files in your Grails application, and a “dist” folder is a good a place as any. So in your “web-app” directory, create a “dist” folder.

Create dist folder

From your JavaFX project, drop your *.jar file and *_browser.jnlp file into the “dist” folder. If you’re having trouble finding them using Eclipse, try refreshing your JavaFX project and the should be in a “dist” folder there. You will need to have run the JavaFX script as an Applet rather than an Application in order to create the *_browser.jnlp file. You can do this in the Run Configurations in Eclipse.

Once you’ve copied the files you need to update the paths in the jnlp file so it reference its new location, so open it up.

The codebase attribute should be changed so the jnlp tag reads:

<jnlp spec="1.0+" codebase="http://localhost:8080/application_name/dist/" href="Main_browser.jnlp">


and href attribute of the homepage tag.

<homepage href="http://localhost:8080/dist/"/>

Obviously replace localhost with the server you intend to use, and application_name is your actual application name. If you have updated your Config.groovy with … grails.app.context = "/" … so you don’t have use the application name in URLs you should use http://localhost:8080/dist/ instead.

Next you need to make a script declaration in the GSP file where you want the applet to appear:

...
<script>
javafx(
{
archive: "/dist/Main.jar",
width: 200,
height: 200,
code: "package.Main",
name: "Main"
}
);
</script>
...

The archive attribute uses the base url provided in environments block from Config.groovy, so make sure this is correct for your full path. Or if your feeling naughty you can use an absolute path.

<jnlp spec="1.0+" codebase="file:/C:/workspace/JavaFXApp/dist/" href="Main_browser.jnlp">

The width and height attributes should be made similar to the ones defined in your the Stage object of the JavaFX script, otherwise your applet might end up being cropped.

The code attribute needs to have the fully qualified name of the script, so replace “package” with what is appropriate to you.

Next add the script src in the head of your GSP.

<head>
...
<script src="http://dl.javafx.com/1.2/dtfx.js"></script>
...
</head>

Finally you might want to add the following to your grails.mime.types in you Config.groovy.

grails.mime.types = [
...
jnlp: 'application/x-java-jnlp-file'
…
]

Your applet will now display in your application; but you can also hit the URL directly and the applet will load using Web Start e.g. http://localhost:8080/application_name/dist/Main_browser.jnlp

Chikofsky and Cross outline six key terms used within the domain of reverse engineering:

Forward Engineering:
This is the “traditional” process of moving through the stages of design, starting at the highest level of abstraction moving to a specific implementation.

Reverse Engineering:
This involves analysing a “subject” system in order to determine its components and the relationship between those components. It also involves the creation of alternative representations of the system, usually at a higher level of abstraction. Reverse engineering does not involve changing or replicating the system, it is only concerned with an examination of the system and can occur at any stage in the software development life cycle.

Re-documentation:
Whereas reverse engineering will often lead to the abstraction level being raised, re-documentation is concerned with creating an alternative view at the same abstraction level. This alternative view is usually targeted at a human audience, and attempts to recover documentation for a system that for whatever reason no longer exists. A number of tools exist to make the task of re-documentation easier, e.g. pretty painters and diagram generators.

Design Recovery:
This is the process of adding “domain knowledge, external information and deduction” to information directly garnered from the subject system. It is not a process on its own, but is incorporated in reverse engineering. In some instances, it provides a wider range of information then the system itself can provide.

Restructuring:
Restructuring like re-documentation occurs at the same abstraction level; however it is concerned with modifying the representation, whilst providing the same overall outcome. It often involves (but is not restricted to) the restructuring of code and models. Changes are made to components so that they produce the same result, but improve the way they achieve it.

Re-engineering:
Also referred to as renovation or reclamation, re-engineering is the process of amending the subject system. As a process it will provide functionality the system should have originally had, or make changes to meet new business needs. The process usually involves a reverse engineering aspect to understand the subject system, followed by a forward engineering aspect to implement the changes.

The paper goes on to then outline six objectives for the future development of reverse engineering:

Cope with complexity:
Better methods and ways of automation in order to deal with large complex systems.

Generate alternative views:
Usually alternative views are graphical, these are expensive to maintain, both in time and money. Reverse engineering can facilitate the the auto-generation of graphical and non graphical views.

Recover lost information:
Design recovery in particular allows us to discover information about the system that is missing from the documentation.

Detect side effects:
Provides a method to deliver observations on the results of poor design or subsequent maintenance.

Synthesize higher abstractions:
As a discipline reverse engineering requires improved processes, (most likely automated) for the production of alternative views that “transcend to higher abstraction levels”

Facilitate reuse:
Re engineering can assist in the identification of reusable components from the subject system.

As a final point the paper discusses the economics of Reverse Engineering; drawing attention to, understanding and maintenance is particularly costly for software owners. Over the complete life cycle of a product, maintenance may account for “50 to 90 percent”, thus the potential for savings using reverse engineering techniques could be significant.

For me it’s interesting to see that the principals outlined here, 20 years on are still as valid today. As software engineers we often believe we’re breaking boundaries, but most of the time this is not the case. Surprisingly though, in these 20 years we have actually achieved very little in expediting these processes. Having worked on two design recovery projects in the past, one in the public sector and one for a large UK bank, industry seems content with approaching the majority of the work manually.

The overall impression of the day, was a very enjoyable experience; which is perhaps not what you want from a “school”. Doug is a natural public speaker, that can captivate the audience with anecdotes and jokes. For a days entertainment it was good value, but I didn’t really get out what I expected. No discussion on business plans, very little on business models, no advice on how you might go about getting investment. A lot of the content for a intelligent person could actually be put down to common sense: “Sell something people want”, “Do something new”. In fairness however, there is a limit to what you can cover in a single six hour day.

That being said, there were a number of “surgery” sections, when entrepreneurs could come on stage and discuss their own business. These were the people that got the most out of the day, getting specific advice about off the beaten track concerns. I’m sure also, that the people queued to asked questions during the intermissions got as good advice as well.

If your considering going, make sure you have specific questions. If you’re actually thinking of starting a business and want schooling… this is perhaps not for you.

Collection of my favourite quotes/comments from the day:

Ideas are cheap – have 100

People tell you what you want to hear, few are going to tell you, your baby is actually ugly (or your business)

Take something and do it cheaper

Be remarkable, make something worth talking about. Word of mouth in the communication age is more important then ever

Who invented the iPod… Stalin. (in reference to the fact it has fewer features and gives you less rights then competitors)

Go out of your way to get companies to want to crush you. At least your being noticed.

Open source products are interesting as the number of contributors drives improved user experience.

If you want to be rich, be an investment banker. If you want the independence to do your own thing – be and entrepreneur.

There’s always room for expertise.

The first investment opportunities: friends, family and fools.

Start with what you love.

GrepTheWeb allows users to search or rather “grep” the web, as UNIX users will know the key difference between a “grep” and a “search” is the fact that you can use regular expressions. As you might imagine the amount of processing power required to grep the largest data source possible i.e. the web, would be huge.

Due to global time differences, web applications rarely use the same capacity consistently throughout the day. Therefore when large populations like the USA are offline the same level of capacity is no longer required. The developers of GrepTheWeb therefore decided to utilise the concept of cloud computing in what is described as a “Cloud Architecture”.

In a Cloud Architecture the processing and physical storage are shared between multiple systems. As processing activities increase the system garners more resources to complete the activities. Similarly when resources are no longer required, they are released back to the “cloud” for the other systems to use.

Providers of cloud computing hardware then bill their customers based on usage rather then a fixed sum; this is a paradigm similar to mobile phone Pay-As-You-Go billing rather then the Pay-Monthly (contract) alternative.

As we can see from Fig[1] below GrepTheWeb is comprised of a number of Amazon web service products, which have been arranged in a Cloud Architecture:

System Overview - Source (2)

Amazon SQS – The Amazon Simple Queue Service orchestrates calls between controllers and queues requests when the system is under heavy load. You can consider this, as indeed the developer guide describes, as the “glue” between controllers; however I have never been a fan of this analogy, as it implies something permanently fixed and is not easy to change.

Controller – The diagram above is somewhat confusing with respect to the controller, as firstly the controller code is actually part of the EC2 Cluster. Second the system does not have a single controller, but rather multiple controllers each relating to the phases of processing in the system:

The Launch Controller will start the process off in the EC2 cluster, as well as creating a processing record in the Simple DB.

The Monitor Controller will check if a process is complete, when it is notify both the Shutdown and Billing Controller by way of a messages placed in their respective SQS queues.

The Shutdown Controller will relinquish the now unused resources in the EC2 cluster.

The Billing Controller calculates the amount of usage the process utilised and sends the information to the billing service.

Amazon EC2 Cluster – The Elastic Compute Cloud is the essence of the cloud architecture; it offers processing in the form of a Web Service that can be scaled up or down as required. It is also where the application code is deployed and executed. When required multiple processes are run in parallel, before being aggregated into a single output.

Amazon SimpleDB – As the architecture relies on asynchronous calls and as Web Services are inherently stateless it must be possible to determine the state of a given component. Controllers therefore use the Simple DB to query and update a given processes status.

Amazon S3 – The Simple Storage Service is where the content from the web crawlers are stored, essentially an ever changing and expanding dataset from the internet. Similar to the processing of the EC2 cluster, storage is scalable on demand.

Inputs – There are two inputs to the system, one is the internet itself that are provided to the S3 data store by means of web crawlers. The second is the regular expression that a given user wishes to run against that dataset.

Outputs – As the output from a given grep can be particularly large, the content is written to the data store rather then being returned as typical Web Service response.

What purpose does this architecture serve?

Cloud architectures and the way they are offered as services by vendors like Amazon, are unusual in the fact they do not aim to address a traditional design principal like separation of concerns i.e. Object Orientated Architecture or event response i.e. Event Driven Architectures. Rather the purpose is directly related to reducing the costs of running the system.

A more purest view is that the main purpose is to increased the amount of parallel processing capacity a single system could achieve on its own; but ultimately this is directly related to not having to pay for the cost of the hardware yourself.

So how are the costs reduced? Well as alluded to previously when the system is not utilising resources they are releases back to the cloud, to be used by other systems. This allows greater hardware utilisation and therefore a greater efficiency is attained, the other major saving is that an organisation no longer has a massive initial hardware cost.

Who do you think will use it and for what purpose?

The term “cloud computing” is growing in momentum and has gained a lot of coverage recently; however some organisations will always have reservations about their information existing in a shared space; particularly governments. Organisations that are involved with customer’s personal information may also face legal concerns, particularly with data moving across country boundaries.

For those ready to embrace the cloud, there are a number of facets that will appeal to a diverse mix organisations:

Perhaps the demographic that are most attracted to the cloud are new start ups, mainly due to them not having the hardware outlay upfront. As an added bonus these start ups no longer have to estimate the capacity they will require; which can be a costly a complex process in itself. Conversely those organisations that have already paid the costs for existing systems would have less to gain.

Another major beneficiary of this architecture will be web companies that get bursts of traffic. Organisations with uneven server load will ultimately be best suited to the form of “Pay-As-You-Go” computing, e.g. a sports website, that typically has their traffic focused at weekends when matches are played.

Quite different still would be a company that wanted to run processor intensive tasks, data conversion, data mining etc. Most companies run some form of batch processing over night, which often results in complicated scheduling in order to get tasks completed before the start of the working day. With cloud computing you can scale up the processing activities to the Nth degree and have your processing completed in a suitable time frame, before releasing the system resources for the rest of the day.

The power of the cloud...