Ben Fletcher

(A signed video about this post.)

At my work, it is sometimes essential that a specific meaning of a verb is emphasised.  The question is: how can the sign language interpreter distinguish between “integration” and “integrator“, for example?

The technique used in British Sign Language is to adapt the sign to reflect the specific meaning – for example, for “integration”, the basic sign for “integrate” is first signed and then this is followed up with “processor” – in one fast flow, as if both were one whole sign.  For the other word, “integration”, this is signed using “integrate” and then following this up with “set”.

The sign for “integration” is “integrate” + “going on”.

The following video demonstrates, in this order: integrate, integrator, integration, and integrating.

English: integrate + or, ion, e, ing…
BSL: integrate + “processor”, “set”, <nothing>, “going on”

Finally, it should be noted that adapting the basic sign to reflect the meaning needn’t be done if this needn’t be emphasised or can be taken as a given.

I hope all this makes any sense, but certainly, I hope, to demonstrate how rich British Sign Language can be.

I have a Java-based web server called Tomcat running on a remote machine (in my case, on Amazon’s cloud computing infrastructure called EC2).  I also run a Java-based video streaming server on the same remote machine called Wowza.

I do the development work using an integrated application called Eclipse, on which I do the various coding for the servers using Eclipse’s “dynamic web project” facility.  All this is done on my local machine (in my case, a laptop).

A rapid development “cycle” – where I can go through the steps of coding, deployment, testing, and back to coding, testing, deployment, and again for a number of cycles – is essential.  For the cycle to be rapid the actions that are needed to go from coding to testing need ideally be automated.

With the servers running locally, this is very easy, however with the servers running on a different machine, this often involves doing some work to automate the local to remote deployment process.

There is an Eclipse plug-in from Amazon to automate some of these however at present this requires the use of their predefined server configuration termed “machine image”.  This is an issue for me because this does not have Wowza present, and Wowza forbids installing Wowza on a non-Wowza server configuration on EC2.

I still use the plug-in Amazon for its other capabilities, namely the ability to list running machines (instances), starting and stopping them, amongst others, from within Eclipse.

To automate the deployment process to a server configuration with Wowza, I have taken the following approach:

• extract Tomcat Client Deployer (downloaded from Tomcat website) into the dynamic web project in my Eclipse workspace – I use Tomcat version 5.5;
• configure Tomcat Manager on the remote machine with a new username and password;
• configure the Ant script included in the deployer installation to point to the web project using the following properties (set in deployer.properties in the same directory as the script):

build=../build/
webapp=../WebContent/
path=/TalkToWife
url=http://ec2-174-129-110-38.compute-1.amazonaws.com:8080/manager
username=<username>
password=<password>The TalkToWife is the contextual path, in my case, is the name of the web application, and the address is where the Tomcat manager is located.  The address for this application would therefore be http://ec2-174-129-110-38.compute-1.amazonaws.com:8080/TalkToWife.  The username and password are as set with the Tomcat manager earlier.

In the dynamic web project, the servlets, by default, have their compiled classes put in build/classes, which I have modified to WebContent/WEB-INF/classes in order for the Ant script to include these in the deployment as follows (mileage may vary for Eclipse versions other than 3.4):

1. right-click on the project in Project Explorer and select Properties
2. in the left pane, select “Java Build Path”
3. in the right pane, tick “Allow output folders for source folders”
4. Edit the “src” folder’s properties to output to “WebContent/WEB-INF/classes”

Now the following tasks can be automated using Eclipse’s built in Ant support:
compile

• deploy web application to remote Tomcat server
• undeploy web application from remote Tomcat server
• start the web application on remote Tomcat server
• reload the web application
• stop the web application

… and now the cycles are automated.

With my thanks to the following, whose materials have helped me to realise this solution:

Patricia’s contribution produced here: http://linux-sxs.org/internet_serving/a1421.html

Sathya’s blog post here: http://arkblog.wordpress.com/2008/01/08/creating-a-deployable-war-file-from-eclipse-project/