Wednesday 21 October 2009

Linux - Disk usage

The amount of times I have to Google for the Linux command to calculate the amount of disk-free space from the present working directory, I decided to blog it so others can share in it too!

Simply type

du -ks directory

Where du = Directory Usage
-k = Use units of kb (1024 bytes) for size
s = Display summary only
directory = Is the directory to start reporting sizes, or if not provided it defaults to the current directory.

Tuesday 20 October 2009

JavaFX Week 7 (Animation)

The signer certificate has expired


When trying to run the sample application CustomNode_animation_colliding_balls_3steps I noticed that it would not run due to the following error

init:

deps-jar:

keytool error: java.lang.Exception: Key pair not generated, alias already exists

Warning: The signer certificate has expired.

compile:

jar:

standard-run:

java.lang.NoSuchMethodException: collidingballs.MotionBall_3.javafx$run$(com.sun.javafx.runtime.sequence.Sequence)

at java.lang.Class.getMethod(Class.java:1581)

at com.sun.javafx.runtime.Entry.start(Entry.java:63)

at com.sun.javafx.runtime.Main.main(Main.java:80)

browser-run:

jws-run:

midp-run:

run:

BUILD SUCCESSFUL (total time: 3 seconds)

To fix this, I simply went to the project properties, selected the 'application' tab, then disabled the 'self signed jar' option. I guess another project already has stored a certificate that conflicts with this demo.


Adding a little debug on-screen


I was asked whether we could output some debug quickly to see the values of the x position offset (xoff), scale and xflip, after a little consideration I added a VBox to provide a simple layout manager and then added three labels that were bound to those values. Hey presto, simple on-screen debug.


import javafx.ext.swing.SwingLabel;

import javafx.scene.layout.VBox;

.

.

VBox {

content:[

SwingLabel {

text: bind "Xoff = {xoff}"

width:400

},

SwingLabel {

text: bind "Scale = {scale}"

width:400

},

SwingLabel {

text: bind "xflip = {xflip}"

width:400

}

]

}

.

.


Flipping Sharks!


It took a while to work out what timeline was required to move the sharks form the top-left of the screen to the bottom-right, to include the zoom and flipping of the Sharks.


I used three variables that I bound at different locations in the scene graph (actually I had help on this one by collegues at work).

var scale = 0.3;

var xoff = 0;

var xflip = 1.0;

My timeline was always pretty much right, but the key part is in the next section

var st = Timeline {

keyFrames: [

at(0s) {

scale => .3;

xoff => 0;

xflip => 1.0

},

at(2s) {

scale => 1.0 tween Interpolator.LINEAR;

xoff => 300 tween Interpolator.LINEAR;

xflip => 1.0

},

at(2.5s) {

scale => 1.0 tween Interpolator.LINEAR;

xoff => 350;

xflip => -1.0 tween Interpolator.EASEBOTH;

},

at(4s) {

scale => 0.3;

xoff => 0;

xflip => -1.0

},

at(5s) {

scale => 0.3;

xoff => 0;

xflip => 1.0

}

],

autoReverse: false,

repeatCount: Timeline.INDEFINITE

};

The Sharks ImageView was not happy having a transform applied to scale the sharks position and flipping in one go, so Chris at work came up with this option to have a sequence of transformations that are applied one after the other.

var shark = ImageView {

.

.

transforms: bind [

Transform.scale(scale,scale),

Transform.scale(xflip,1,theImage.width/2,0)

]

translateX: bind xoff

.

.

};



Tuesday 13 October 2009

Learning EJB 3

Recently I have been trying to learn a mix of Spring Restful web-services and IBATIS, but in this journey I started to get a little frustrated with them both. I admit this is probably due to my lack of knowledge with both of those frameworks, but recently I discovered that I purchased an O'Reilly book over 12 months ago on EJB 3 and thought "I wonder if that's any better". Certainly if you read the hype on Spring you will be convinced that EJB is heavy weight, complicated and typically the wrong option.

I've only read about four chapters in the book, but so far I must admit it's cleaner and simpler than I expected. You could argue that Spring has many features that would be advantageous, such as dependency injection, but in my opinion the level of dependency injection provided within EJB 3 is probably sufficient for my needs. Spring seems to be growing almost daily and I started to feel like I was drowning rather than at least treading water - but I haven't given up. I successfully managed to use the new Spring annotations to expose Restful web-services, plus started to integrate with IBATIS, but I was getting increasingly concerned about parts of my code getting more and more coupled to Spring.

This past week I have been looking at restructuring my code, to enable me to support different frameworks (Spring and EJB for exposing business methods over the network from a client and various persistence technologies in the server).

Below is a diagram that sums up where I am at the moment.



I'll try to explain in words how to interpret my class diagram - but bear in mind, some of the relationships are hiding what really goes on behind the scenes, but should give you a general idea.

First, if you're new to EJB 3 like me, it's worth pointing out to you that you can pretty much develop your business logic using plain old Java objects (POJOs) and then add Java 5 annotations to 'decorate' them with EJB 3 features, for example, I have annotated my UserStatelessSessionBean with two EJB 3 annotations, EndPoint and Stateless. Those annotations will indicate that a SOAP based web-service should be used to access the service and that the bean is not expected to hold state between requests, the latter enables many requests to share the same object and increase scalability.

The MyStatefulSessionBean used three annotations Local indicates that certain methods can be invoked from within the same JVM without the overhead of remote method calls, dramatically increasing performance - but this does not help you if you want to access the methods from a client application. In this scenario I have used the Remote annotation to indicate that the methods will be accessible via JAX-RPC style web service requests. The Stateful annotation indicates that this bean is expected to hold state across invocations and therefore it can't be shared between sessions.

From my understanding, Stateful session beans are closely linked to fine-grained services, i.e. you might invoke the service with 20 messages/methods to do one job. Whereas Stateless session beans are closely linked to course-grained services, i.e. you might invoke only one method to do one job (use-case). I have yet to throw myself into this to fully appreciate one model over the other, but my suspicion is that scaleability is best achieved by being as stateless as possible. My rational for this is to consider some large application like facebook, if you have a simple course-grained service that says something like postMessage(myUserId, targetUserId, theMessage), then the message has everything it needs to service the request and could therefore be sent to any server in a cluster, enabling load balancing and all those wonderful things to work best. If I used a stateful session bean, either the state gets replicated across the cluster which must be slow, or you are restricted to talking to the originating server to complete your session.

My aim in this class diagram is to show flexibility and therefore re-use. Firstly I have a GUI that talks via an interface to 'do things', then I have an implementation of that interface that uses EJB3 and another that uses Spring. This means that if I find one to be more reliable, faster, better suited for intranet/public internet access, I can easily swap the client to server communications very quickly, without affecting any GUI code!

The same can be said on the server, The EJB session beans and Spring web-services are controllers that I have made as dumb as possible. The controllers simply delegate their work to a Manager class that does all the business logic. This means I can add say a CORBA controller, or perhaps implement the Google protocol buffers and re-use all the manager code as-is. Obviously if I add some features in the server, I might want to add the option in the GUI to use that new service too.

Okay, so far this all sounds dandy, but is it really likely that I want to swap between Spring or EJB or Google protocol buffers? Well, perhaps not, but the option would be nice wouldn't it?! There is another good reason for doing this though, perhaps you can expose these APIs to enable other developers to add value to your application, the more API's you expose, the more chance you have of increasing developers to your API.

The last part of my class diagram is to show that I've done the same thing with the Data Access Object, I can therefore implement the DAO using EJB3 JPA or IBATIS, Hibernate or pure JDBC.

The Domain objects can remain POJOs in most (if not all) cases, therefore my intention is to re-use the domain objects in the client tier and server tier.

I guess at some point I will have a sample application to prove my thoughts, but in the meantime, if anyone has any comments then I would be very happy to learn from you!

Many thanks
Rob.

Tuesday 6 October 2009

JavaFX Week 6 (GUI Week 3)

I have tried some of the sample applications, I remain unimpressed with the performance on the Mac using the FireFox browser.

Three levels of skinning


  • CSS Theme - Most accessible method and will accommodate 60-80% of use, although Java FX 1.2 is not fully CSS featured. A very basic example of CSS use can be found here http://javafx.com/samples/CSSFun/index.html


  • FXD for Skin - Use the Java FX production suite to export artifacts from Illustrator or Photoshop.


  • Custom Skin - Replacement of a skin for a button for example by using your own image for the button, but you're responsible for the tedious details, such as overriding functions to provide preferred size information.


The default 'skin' in JavaFX 1.2 is called Caspian, this site covers the decisions about the colour schemes used and why http://fxexperience.com/2009/06/caspian-skin/

Charting - Six types in Java FX 1.2

Area Chart
Bar Chart
Bubble Charts
Line Charts
Pie Charts
Scatter Charts

For more information refer to http://pleasingsoftware.blogspot.com/2009/06/this-is-test.html

Internationalisation - JavaFX is very similar to Java in the way that it handles I18N, but instead of using a .properties file it expects a .fxproperties file. All message keys and values are quoted, i.e.


"NB_Title" = "JavaFX 用 NetBeans IDE"


To reference one of the properties, it's as simple as using two hashes followed by the key of the property, i.e.


Locale.setDefault(new Locale("en", "US"));
.
.
{
title : ##"NB_TITLE"
}


For a full explanation see the following link