peaky blinder

Apple and Java

noreply@blogger.com (jim) — Fri, 25 Sep 2009 13:33:00 +0000

Sigh. Just when you think Apple might be getting their act together with regards to keeping Java on OS X up to date, you install the Snow Leopard upgrade to OS X and find yourself in the following situation:
Apple appear to have upgraded Java to 1.6.0_15, but removed the features from 1.6.0_10, namely the next generation plugin features for applets.

Published

noreply@blogger.com (jim) — Tue, 18 Aug 2009 12:19:00 +0000

The much anticipated (by me at least) Swedish translation of Maureen O'Brien's 'Close-up on death' is finally out, and the reason I'm so interesting in it is that it uses a photo of mine for the front cover.

My copy arrived yesterday and I'm pretty pleased with how it turned out - I doubt this is the start of a new career but it's a nice bit of exposure for one of my favourite shots.

I'm currently planning a bike trip through Sweden and Norway next year...let's hope the international fame that results from this book cover doesn't make it difficult for me to travel without being mobbed :-)

My Grand Tour

noreply@blogger.com (jim) — Sat, 25 Jul 2009 16:30:00 +0000

At the start of July I went off for a 2 week motorbike trip around Europe on my new bike, a BMW F800GS.

The route was dictated by having to end up in Cannes for the Bastille Day weekend to meet up with my brother for a few days, and dropping in on Zurich to meet a friend - apart from that I just wanted to see lots of mountains and get used to the new bike on lots of fun roads.

I ended up doing 2,250 miles, door-to-door. My final route is below:

View Larger Map

Highlights were the second day I spent in the Alps, riding from Susa,Italy down to Cannes. A little dirt-road detour to Pontis and the rest of the trip on the N85 were all good fun on the bike.

The Pyrenees were also fantastic - I did a little bit of research before I left and found that the N260 was a good biking road, so I spent about 3 days riding west through the Pyrenees mostly on the N260 - joining at the 44km marker and leaving just after the 500km point. That road varied from 2 lane highways to single lane mountain roads with 30km/h hairpin bends and back again - great sightseeing and biking.

The bike was great - aside from the seat, which after about 45mins becomes the most uncomfortable seat in the world. Apart from that it is an ideal bike for long trips - it does feel a little unsettled sometimes at high-speed on motorways, or in strong crosswinds, but otherwise it handled everything without any fuss and is ridiculously economical too, returning 70MPG+ for several tanks, giving it a range of nearly 240 miles, although I was only brave enough to take it up to 213 miles before filling up.

Instead of the £1000+ for the BMW luggage I went with a £130 Wunderlich tank bag and a bungeed on rollbag of clothes. The tank bag is designed for the F800GS and it shows: it was essential for stuffing credit cards and toll tickets, as well as holding a map, GPS etc. It's a shame it wasn't secure enough to leave on the bike, but it's so easy to take off and put on that wasn't a big deal.

Haven't quite finished going through all the photos yet, but they will all be in the Flickr set in the next few days.

Finally, draggable applets on OS X

noreply@blogger.com (jim) — Fri, 24 Apr 2009 14:05:00 +0000

Apple have a pre-release Java update available on the ADC that updates Java to 1.60_13 on 64-bit platforms, so Mac users can finally take advantage of the new generation applet technology that's been available on Windows and Linux for months now.

I just installed it and tried it with the PDF Viewer applet that we upgraded to take advantage of Update 10 features, and it worked fine - I could drag the applet out and create a desktop shortcut with no problems.

You'll need OS 10.5.6, Leopard, and Safari 4.0 beta or the latest Firefox 3.1 if you want to try this out.

JavaOne

noreply@blogger.com (jim) — Fri, 13 Mar 2009 11:22:00 +0000

Rather obviously, there are a lot of JavaFX technical sessions at JavaOne this year. A couple seem to deal with integrating JavaFX and Swing, and TS-5574 looks particularly interesting, according to the abstract

"The presentation goes into the more technical details of the advantages and limitations of mixing JavaFX technology and Swing. It also explains the correct (supported) way of mixing these, because several people have discussed this in blogs and are not doing it the right way."

Haven't decided whether I'm attending or not this year, but that session would be on my schedule.

A zero-install* cross-platform PDF Viewer

noreply@blogger.com (jim) — Tue, 17 Feb 2009 14:14:00 +0000

After the recent updates to the BFO PDF Viewer applet to take advantage of the Java 6 Update 10 features we have also changed the applet hosting page so that it accepts parameters and passes them onto the applet.

The applet already had functionality to open PDF documents passed to it as parameters, but this provides the ability to open a PDF file in a specified viewer, on any operating system, with a single URL.

For example: http://bfo.co.uk/pdfviewer.html?pdf=http://bfo.co.uk/products/pdf/docs/userguide.pdf&feature.Menus=false

What would be more useful is if this was integrated into your browser so that you can open any links to PDF documents directly in the PDF Viewer - which is what the Firefox extension that I have written does: any link on a page that ends in .pdf will have an extra "Open link in PDF Viewer" context menu option.

Choosing this menu option will open the PDF document in a separate browser window that contains the PDF Viewer applet. You can install the Firefox extension from here: http://bfo.co.uk/bfopdfviewer.xpi

Obviously having Java 6 Update 10 or later makes the applet experience better, although we are specifying that each applet instance runs in its own JVM instance, which might slow down the applet startup a little, but is important for coping with larger PDF documents.

* I know Java requires a JVM installation - but I picked up this bit of marketing bollocks from the early days of Altio and figure desktop Java needs all the help it can get these days :-)

Java 6 Update 12 available

noreply@blogger.com (jim) — Tue, 03 Feb 2009 09:39:00 +0000

Go get it today - all you people with 64-bit browsers will be pleased with the 64-bit plugin.

http://java.sun.com/javase/downloads/index.jsp

PDF Viewer applet and Java 6 Update 10

noreply@blogger.com (jim) — Fri, 09 Jan 2009 11:45:00 +0000

I've spent the last few days finally getting round to updating BFO's PDF Viewer applet to take advantage of the new Java 6 Update 10 features.

It was mostly straightforward, with most of the time taken up with making the applet look and behave exactly like an application when its dragged out of the browser. We did run into a Sun bug along the way, which means that desktop icons created when you drag an applet out of the browser look crap on Vista and Ubuntu because Java takes a 32 x 32 icon and scales it up to 48 x 48, even when you provide a 48 x 48 icon.

I also used another very cool applet to create a video of the applet in action: http://www.screencast-o-matic.com/ - a JavaPosse applet of the week - provides a quick and free way to create screencast videos and host them so that anyone can watch them. Highly recommended. My screencast is here: http://www.screencast-o-matic.com/watch/cQVQeynE5

So, if you have Java 6 Update 10 or later installed then nip along to http://bfo.co.uk/products/pdf/viewer.jsp and try it out. If you want more information on how to update an applet to take advantage of the new Update 10 features then there's a blog post over at BFO detailing exactly what was involved: http://big.faceless.org/blog/2009/01/05/1231151940000.html

The 'official' way to integrate JavaFX with Swing

noreply@blogger.com (jim) — Sat, 20 Dec 2008 22:39:00 +0000

Josh Marinacci has a blog entry on how to integrate Java FX into Swing applications: http://blogs.sun.com/javafx/entry/how_to_use_javafx_in.

It's good to have a final answer on how to accomplish this in JavaFX 1.0, but to be honest it looks like a nasty hack, which implies it's something Sun either hadn't thought about or didn't consider important. That seems peculiar as it was so easy to do in previous releases, and it seems a dumb move not to make Swing and JavaFX as easily interoperable as possible.

JavaFX and Swing - again

noreply@blogger.com (jim) — Sat, 13 Dec 2008 10:41:00 +0000

I've noticed that my previous entry about using JavaFX widgets in Swing applications has been getting a lot of traffic since JavaFX 1.0 was finally released.

Having finally had time to download and try out the JavaFX 1.0 SDK it seems like Sun have done a good job: the demos and samples are all good, JavaFX.com no longer looks embarrassing and the NetBeans integration is great (there is an Eclipse plugin available too).

However, the 1.0 release has removed the javafx.ext.swing.Canvas class, which was crucial in embedding JavaFX widgets in Swing applications, as the Canvas had a method to return a JComponent, so you could simply add it to your Swing application without too much trouble. Now I can't see any way of easily using JavaFX in Swing applications - I have heard some hints that it can be done with some reflection 'hacks', but I haven't seen any more information about this.

I hope there is a relatively simple way of achieving this, because if JavaFX really is 'Swing 2' then they need to make the two interoperate as seamlessly as possible so that people can migrate their existing Swing applications in small steps, rather than having to rewrite in JavaFX.

GPS and MapView in Android

noreply@blogger.com (jim) — Thu, 20 Nov 2008 19:28:00 +0000

Having spent an evening hacking around writing an Android application that uses the GPS position together with the MapView component to show both your current location latitude/longitude and visually I spent a lot of time sifting through sites and blogs that used out of date APIs and overlooked crucial steps, so I thought I'd document how to enable GPS access and MapView usage using the Android Eclipse plugin and the emulator. This will then work when running on an Android device.

Step 1: GPS Access
Basic GPS access is relatively straightforward. You can use code like this in your Activity.onCreate() to get the current position and register a listener for position updates:


LocationManager lm = (LocationManager)getSystemService(Context.LOCATION_SERVICE);

List pro = lm.getAllProviders();
Location l = lm.getLastKnownLocation(LOCATION_SERVICE);

updatePositionOnScreen(l);

Intent i = new Intent(LOCATION_CHANGED);
LocationListener ll = new LocationListener() {
 public void onLocationChanged(Location location) {
   updatePositionOnScreen(location);
 }
 public void onProviderDisabled(String provider) {
 }
 public void onProviderEnabled(String provider) {
 }
 public void onStatusChanged(String provider, int status, Bundle extras) {
 }
};
lm.requestLocationUpdates(LocationManager.GPS_PROVIDER, 30000, 100, ll);

In addition to this you need to add permissions to your Android manifest file to allow your application access to the location services:

<uses-permission android:name="android.permission.ACCESS_LOCATION/">
<uses-permission android:name="android.permission.ACCESS_GPS"/>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION"/>

For running your application in the Android emulator you will need mock position data, as there is no live GPS data from the emulator.

The easiest way to do this is to launch the emulator from Eclipse and then switch to the DDMS perspective (Window -> Open Perspective -> Other). Your Eclipse should then look something like the picture on the right.

This shows you a device browser on the left, w ith an Emulator Control tab underneath. Scroll down the Emulator Control tab until you see the Location Controls section. This allows you to enter mock location data to use when running the Emulator - the best way is to use a KML file, which you can create from Google Earth, or download a default location file from http://www.sunlightlabs.com/earmarks/house_defense_earmarks_08.kml. Once this has been imported click the green play button in the Location Controls (KML) section and your application will receive location updates based on the contents of the KML file.

Step 2: Google MapView component

The Google MapView component allows you to embed the Google map component in your application, so we can combine our live location data with a visual display of that location on a map. Embedding the MapView component has a few "tricky" steps:

Add the MapView component to your Activity:

<com.google.android.maps.MapView
 android:id="@+id/mapview1"
 android:layout_width="fill_parent"
 android:layout_height="fill_parent"
 android:enabled="true"
 android:clickable="true"
 android:apiKey="your api key"
/>

The apiKey attribute should be the MD5 fingerprint of your Maps API key. In order to deploy your MapView enabled application you need to register for a Google Maps API key, but for debugging you can use the Android SDK's debug key. All the details on Google Maps API keys can be found here http://code.google.com/android/toolbox/apis/mapkey.html, with details on how to obtain the debug SDK fingerprint here http://code.google.com/android/toolbox /apis/mapkey.html#getdebugfingerprint.

Once you have this, then to enable the MapView component you need to:

Change your Activity to extend MapActivity rather than Activity.
Add <uses-library android:name="com.google.android.maps"/> as a child of the element in the Android Manifest file.
Enable Internet access for your application so that it can download map data by adding <uses-permission android:name="android.permission.INTERNET"/> to your manifest file.

You can then add code to your application's location listener to update the MapView component to reflect the current position, such as:

MapView mapView = (MapView) findViewById(R.id.mapview1);
MapController mc = mapView.getController();

GeoPoint p = new GeoPoint((int) (l.getLatitude() * 1E6),
           (int) (l.getLongitude() * 1E6));
mc.animateTo(p);
mc.setZoom(16);          
mapView.invalidate();

When you run your application you should see your live MapView control responding to GPS lcoation updates, like below:

Tracking Java versions of web site visitors

noreply@blogger.com (jim) — Thu, 13 Nov 2008 08:32:00 +0000

Gili over at 'Where the cows roam free" has a very interesting post about how to combine Google Analytics and the new Java deployment file to track what version of Java visitors to a website are using:

http://cowwoc.blogspot.com/2008/11/tracking-java-versions-using-google.html

It's trivial to add it to an existing Google Analytics-enabled site, and should hopefully yield some interesting and useful results, so I've added it to this site and Cool Applets too.

Java 6 Update 10 released

noreply@blogger.com (jim) — Mon, 20 Oct 2008 08:20:00 +0000

Looks like Java 6 Update 10 has been officially released - for some reason Sun seem to be keeping it quiet, which seems a little odd, considering how significant this release should be for client-side Java and Java FX.

Windows and Linux users go get it: http://java.sun.com/javase/downloads/index.jsp. OS X users, bang your head on your desk in frustration at Apple's lousy Java support.

Fail blog

noreply@blogger.com (jim) — Wed, 08 Oct 2008 20:56:00 +0000

A photo I took is potentially going to be included on Fail Blog - it's obviously the best one, so please vote it up!

more fail, owned and pwned pics and videos

Debugging Applets on OS X

noreply@blogger.com (jim) — Wed, 08 Oct 2008 13:36:00 +0000

So, despite Apple's best efforts to hide the Java Preferences dialog in OS X (Applications/Utilities/Java/Java Preferences in case you're still looking) enough people must have found it by now for Apple to move to the next step: cripple the dialog itself.

After installing the latest Java Update from Apple I noticed a redesigned Java Preferences dialog, which was certainly more compact than the previous version, mainly because Apple have removed the Applet runtime parameters field. So, if you want to set up your applet for remote debugging, change the default heap size or pass any other runtime parameter you now have to go an edit a file manually, as described at http://support.apple.com/kb/HT3210

This may be fine for developers, although I don't see how it is an improvement over editing via the dialog that was there before this update, but instructing non-technical users on how to set up debugging or heap parameters for applets just got more difficult for no good reason.

Google Chrome and Java Applets

noreply@blogger.com (jim) — Sun, 07 Sep 2008 17:11:00 +0000

Well, loathe as I am to add yet another blog post to the insane amount of Chrome related items that were blogged and reported last week, I did notice something interesting with regard to Chrome running Java applets.

Pretty much the first thing I did after installing Chrome was to try it out with an applet as I wasn't sure whether Chrome supported applets or not. It did, it all seemed to work and I didn't think much more about it. It was only a day or two later after seeing some Java.net forum posts that I realised that Chrome only works with the latest version of Java SE, version 6 Update 10, which contains all the cool new features to make Java applets run better.

This could be a good thing - one thing I've said before is that Update 10 has some great features in it, but getting everyone to upgrade to it is going to be hard work. A lot of people, and especially most large corporations, do not regularly upgrade the version of Java SE on their desktop. So, if Chrome forces people to install the very latest version then great.

However, does Chrome explicitly tell users that they need that version of Java? Does it direct them to the right place to get it? If not, then it's just going to create more client-side Java confusion, and I've seen reports of Chrome not running Java properly even when Update 10 is present, and so it's great in principle to make people install the latest and greatest JRE, but unless it's a seamless and trouble-free experience to do so then it will not help Java's already tarnished client-side reputation.

Compiled JavaFX in Swing applications - again

noreply@blogger.com (jim) — Sun, 31 Aug 2008 14:51:00 +0000

Update: This doesn't work in the full release of JavaFX. Please see here for how to do this in Java FX 1.0.

I posted a while ago about problems I was having integrating a compiled JavaFX widget into a Swing application - theoretically it should have been possible, as it's all Java and Swing, but I hit a brick wall that looked like it was due to JavaFX being in early, early alpha/beta stage, so I left it and decided to come back to it when JavaFX was more stable.

Well, the preview SDK for JavaFX is now available, and I had a wet Sunday afternoon to spare, so I tried it again. Of course, as it has been 4 or 5 weeks since I last looked at JavaFX they have completely changed the structure and location of the classes, so it took me a while to get the hang of things again, but once I had done that actually getting a JavaFX widget into a Swing application was trivial really.

The screenshot above shows the Stopwatch example from the JavaFX SDK inside a Swing window - the two controls to the left are Swing controls.

The key to getting JavaFX to operate with Swing is the javafx.ext.swing.Canvas object, which has a getJComponent() method, so all you need to do is place all of your JavaFX content onto a Canvas object, then use the JComponent returned by Canvas.getJComponent() to add the JavaFX widget to any Swing container.

For the example above, the Stopwatch widget example runs in a JavaFX frame with no Canvas, but all we need to do is write a simple JavaFX Canvas object to wrap the Stopwatch, using the code below:


package stopwatch;

import javafx.ext.swing.Canvas;
import javax.swing.JComponent;

public class SWCanvas {
public function getChildComponent() {
      var sw = StopwatchWidget{}
  var c2:Canvas = Canvas {
        content: sw
          width: 400
          height: 400
          visible: true
  }

       return c2.getJComponent();
}
}

Once we have compiled that, we can use our JavaFX 'SWCanvas' object in our Swing application just like any other Java class, so the simple JFrame example pictured above does just that:


package stopwatch;

import javax.swing.*;
import java.awt.Dimension;
import java.awt.FlowLayout;

public class SwingStopwatch {
public static void main(String[] args) {
  Runnable r = new Runnable() {
      public void run() {
          new SwingStopwatch().runMe();
      }
  };
  SwingUtilities.invokeLater(r);

}

public void runMe() {
  JFrame jf = new JFrame("Swing and JavaFX Test");
  jf.setPreferredSize(new Dimension(600,400));
  jf.getContentPane().setLayout(new FlowLayout());

  jf.getContentPane().add(new JButton("Click me"));
  jf.getContentPane().add(new JTextField("Type into me"));

       // JavaFX widget here!
       stopwatch.SWCanvas c1 = new stopwatch.SWCanvas();
       jf.getContentPane().add(c1.getChildComponent());

  jf.pack();
  jf.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 
  jf.setVisible(true);
}
}

And that's all there is to it. The trickiest part of the whole thing was getting the classpath for the JavaFX runtime right when running the Swing application (your CLASSPATH should look something like: %JAVAFX_HOME%\lib\javafxgui.jar;%JAVAFX_HOME%\lib\javafxrt.jar;%JAVAFX_HOME%\lib\javafx-swing.jar;%JAVAFX_HOME%\lib\Scenario.jar).

With JavaFX's ability to create impressive animated user interfaces quickly, and with relatively little code, then the ability to add JavaFX widgets to any Swing container could be a great way to improve Swing applications incrementally, rather than rewriting the whole application in JavaFX.

I'm definitely not a JavaFX expert though, so if you want some more ideas of the very impressive things that you can do with JavaFX then check out James Weaver's JavaFX Blog.

JApplet and the Swing EDT

noreply@blogger.com (jim) — Fri, 01 Aug 2008 08:32:00 +0000

So, everyone knows by now that doing anything relating to Swing controls when you're not running in the Swing Event Dispatch Thread (EDT) is a big no-no. Unfortunately this is very easy to do, as Swing doesn't enforce this rule and 90% of the time your code will run with no visible problems if you don't do it (right up until you release it to a customer, at which point bugs will become immediately visible).

A lot of the time it's reasonable that Swing doesn't force execution onto the EDT, certainly in high-level application classes, although the closer you get to the Swing classes the more sense it makes to actually enforce the rule in some way.

For instance when writing an application it's up to the developer to get on the Swing EDT before you create and display your Swing controls. However there are other situations in which it's obvious that Swing controls are going to be used and so Swing should put you on the EDT by default: when you're using JApplet for example.

I hadn't noticed before now but I was surprised to notice that JApplet.init() is not invoked on the EDT. Try it:


public class TestApplet extends JApplet {
public void init() {  
   System.out.println("JApplet.init - EDT = " +
SwingUtilities.isEventDispatchThread());
}
}

Now if you're using a JApplet you obviously want to do Swing stuff in your applet, so why not help people out and start them off on the Swing EDT?

I guess the issue with doing it by default is that people who don't know about the EDT rule wouldn't be aware that it is being done for them, so you're just avoiding potential bugs without people learning what is involved in avoiding the bugs, so they may just get into another EDT problem further down the line. That may be true, and Swing is definitely an API not a 'framework', allowing you to write code without any help or guidance on how things should be done correctly along the way, but I still think that you should at least start people off on the right track whenever you can - what they do after that is up to them.

JavaScript and Groovy service functions in AltioLive

noreply@blogger.com (jim) — Tue, 15 Jul 2008 10:41:00 +0000

As discussed in the Using AltioLive with JavaScript whitepaper (http://developers.altio.com/developer/library/JavaScriptw ithAltio.pdf), Java 6.0 has built in support for dynamic scripting languages, such as JavaScript and Groovy, within the JVM (referred to as JSR 223).

That document discussed integrating that functionality with the AltioLive client as a custom control, but you can also utilize the same feature to add support for implementing AltioLive Service Functions with scripting languages. We'll take a quick look at how to implement this in Java 6.0 and earlier JVMs by using the Apache Bean Scripting Framework (BSF).

All that is required is a simple Java service function proxy to handle calling a script and returning the results. There are 2 service functions, one for Java 6 and one for BSF, and the source code is included with the Altio script service function JAR file (http://developers.altio.com/developer/downloads/scriptsvcfunc.jar). Each service function takes the same parameters:

Engine: Name of the script engine to use. e.g. javascript, js, groovy
Script: Name of the script to execute
Function: Name of the function in the script to execute

The examples here are in JavaScript and Groovy, but other scripting languages are supported in both approaches, such as Ruby and Python.

The advantages to using a scripting language for custom Altio Service Functions instead of Java are:

Quicker development time (no IDE or compiler required)
Take advantage of particular langauge features to perform tasks. Some languages are better at string handling, XML parsing etc and are better suited for particular tasks than Java.

The examples here are in JavaScript and Groovy, but other scripting languages are supported in both approaches, such as Ruby and Python.

Setup:

1 - Either:

Run the AltioLive Presentation Server using a Java 6 JDK and use the Java 6 examples.(You should remove 'eics-client.jar' from Altio\WEB-INF\lib before starting otherwise you will have JSP compilation problems)
Run AltioLive Presentation Server using an older JDK and use the BSF examples

2 - Add scripting engines and supporting JARs into the AltioLive Presentation Server CLASSPATH (Altio\WEB-INF\lib).
Java6

There are lots of engines here: https://scripting.dev.java.net/files/documents/4957/37593/jsr223-engines.zip
For each engine you'll need supporting libraries.
e.g. Groovy libraries can be found here: http://dist.groovy.codehaus.org/distributions/groovy-binary-1.5.6.zip

BSF

Altio installs BSF by default, but I had to upgrade to 2.4.0 to get this to work.
To add JavaScript support use Rhino: http://www.mozilla.org/rhino/download.html (copy the js.jar into WEB-INF\lib)
Other engine can be found here: http://jakarta.apache.org/bsf/index.html

3 - Install the Altio Script Service Function by copying the JAR file (http://developers.altio.com/developer/downloads/scriptsvcfunc.jar) into (Altio\WEB-INF\lib)
4 - Create an Altio\WEB-INF\classes\scripts folder and copy the example scripts (http://developers.altio.com/developer/downloads/scripts.zip) in there.

Running

1 - You can reuse the Java Scripting service function proxy to execute any function in any script in any supported scripting engine, as in the examples below. The screenshots below are for the Java 6 implementation - if you are using the BSF then replace the classname with

com.altio.services.scripting.BSFScriptServiceFunction

Execute JavaScript Service Function

Example JavaScript:


function returnSomeXml() {
var result = "<javascript msg="'hello">"
return result;
}

Results:


<RESULT AL_ID="RESULT">
<javascript msg="hello again from javascript, the time is Tue Jul 15 2008 12:17:02 GMT+0100 (BST)" AL_ID="RESULT-javascript"/>
</RESULT>

Execute Groovy Service Function

Example Groovy:


def returnSomeXml2() {
String result = "<groovy>"
xml = {result+="<groovyitem id='${it}'/>"}
val = (1..10).collect(xml)
result += "</groovy>"
return result
}

Results:


<RESULT AL_ID="RESULT">
<groovy AL_ID="RESULT-groovy">
<groovyitem id="1" AL_ID="gi1"/>
<groovyitem id="2" AL_ID="gi2"/>
<groovyitem id="3" AL_ID="gi3"/>
<groovyitem id="4" AL_ID="gi4"/>
<groovyitem id="5" AL_ID="gi5"/>
<groovyitem id="6" AL_ID="gi6"/>
<groovyitem id="7" AL_ID="gi7"/>
<groovyitem id="8" AL_ID="gi8"/>
<groovyitem id="9" AL_ID="gi9"/>
<groovyitem id="10" AL_ID="gi10"/>
</groovy>
</RESULT>

These are trivial examples, but they demonstrate how you can implement Altio Service Functions in dynamic scripting languages. Their advantages of ease of development and deployment should make it simple to start using them for more complicated tasks. Further enhancements to the proxy could include passing parameters to the named script's service function, which would make it possible to send values all the way from the AltioLive client through to a server side script function.

Swurl

noreply@blogger.com (jim) — Fri, 04 Jul 2008 12:11:00 +0000

Yet another social web aggregator site, to compete with FriendFeed and Socialthing, but Swurl does present the aggregated information in a really cool timeline format, which for me gives it the edge over the others, even though it's lacking generic RSS support at the moment.

Try it out: http://peakyblinder.swurl.com/timeline

AltioLive and Applets at JavaOne

noreply@blogger.com (jim) — Fri, 04 Jul 2008 08:48:00 +0000

As I mentioned at the time I was interviewed on video about AltioLive and Applets at the Altio booth at JavaOne. If you can stand to see a slightly 'relaxed' man talk about Applets for 10 minutes then watch the video below!

Hudson CI game - again

noreply@blogger.com (jim) — Fri, 27 Jun 2008 08:19:00 +0000

Despite the impressively fast fix to the Hudson CI game issue with awarding points for breaking a build, I hadn't got around to installing the update before I broke the build yesterday and was awarded 12,800 points for doing so ;-)

We've fixed the build and upgraded to the fixed version. I'm keeping the points though, they're mine!

Using Java 6 Update 10 features in AltioLive

noreply@blogger.com (jim) — Wed, 25 Jun 2008 20:32:00 +0000

I've just posted an item on the Altio developer's blog about using the new features of Java 6 Update 10 in AltioLive applications. You can read the whole thing here:

http://tinyurl.com/42ntx2

The only issue at the moment is the fact that Altio dynamically constructs the APPLET tag, so we need to use a JSP page to generate a JNLP file dynamically. You can simply update the Altio JavaScript file and add in the new JNLP generator to start using cool new features in your AltioLive applications such as bigger heap sizes and separate JVMs per applet.

One thing that I didn't mention on the Altio blog is I that played around with accessing other domains directly from the applet, which I blogged about here.

I implemented this in Altio by allowing Image controls to fetch images from Flickr directly, rather then needing a Service Function to act as a proxy, and this worked well. It is probably a feature more useful in consumer internet applications rather than enterprise applications, but not being able to reference images from other websites directly has always been slightly frustrating, so it was a good thing to get working.

Cross-domain unsigned applets

noreply@blogger.com (jim) — Mon, 23 Jun 2008 12:48:00 +0000

Wow, I completely missed this in the Java 6 Update 10 release notes: it is now possible for unsigned Java applets to connect to servers other than the one it was served from, which means you can easily implement client-side mashups with an applet without having to sign it.

http://weblogs.java.net/blog/joshy/archive/2008/05/java_doodle_cro.html

The great thing about this is that it doesn't really break the sandbox security model, which still protects the user's local machine from any damage from malicious applet code, but it makes applets a whole lot more useful in the Web 2.0 world.

Rebranding

noreply@blogger.com (jim) — Tue, 17 Jun 2008 20:03:00 +0000

I've had the marketing people in, and they have assessed the synergy of the blog with a view to maximising my ability to incentivize visionary channels. Therefore, out goes 'disagreeable surprises' (which was a pain in the arse to keep typing) and in comes Peaky Blinder.

For those interested, it's the name of a gang that were infamous in Birmingham in the early 20th century. The story is that a lot of my Dad's side of the family were members, and they had a reputation as being pretty nasty. Officially the name comes from them wearing caps low over their eyes, but according to family stories it's actually related to the fact that they kept razor blades in the peaks of their caps, so when a fight kicked off they used their caps as weapons to try and slash their opponents' eyes. Yow!

So, that's my new brand ;-)