Tuesday, 19 October 2010

moveable UIView example

I was hoping to find a very quick example to for enabling a UIView to be moved using simple touch but didn't. In the end I worked it out for myself and thought I'd share. It's actually just a few lines of code. Subclass UIView and make sure that userInteractionEnabled is set to YES and then add this to your subclass:

-(void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event {

UITouch *touch = [touches anyObject];
CGPoint last = [touch previousLocationInView:self.superview];
CGPoint current = [touch locationInView:self.superview];
CGPoint translate = CGPointMake(last.x - current.x, last.y - current.y);
self.center = CGPointMake(self.center.x - translate.x, self.center.y - translate.y);
[self.superview bringSubviewToFront:self];


Voila! Your UIView can now be moved around.

Thursday, 9 September 2010

OSGi Community Event

Yowsers! I just noticed how long it's been since I updated this blog. Well I don't intend to blather this time, but just thought I would update that I am giving a "short talk" at the OSGi Community Event in London at the end of the month of "The evolution of an OSGi application" which gives a 10,000 mile overview of how Arum's successful DataEye dashboard product has evolved over time.

Of course, I no longer work for Arum, deciding to dedicate 100% of my time to freelance work and my own projects, but I gained a lot of experience working on Arum DataEye and am still convinced that modularity via OSGi was the correct way to go. The product remains agile and easily extendable, ready to be dropped in to any customer environment to be hooked up to their systems. OSGi gives Arum DataEye true system agnosticism.

You can read more about the OSGi Community Event here.

Tuesday, 27 July 2010

Comparing approaches to Vaadin and OSGi

Some time ago, inspired by an attempt I saw on their forums, I set about enabling Vaadin (a pretty amazing RIA derivative of GWT) so that it would work in an OSGi container. You can read about that here.

As it happens Peter Kriens and Neil Bartlett both set about doing the same thing, all our efforts completely independent of each other. In this post, I'll compare and contrast the three approaches.

Firstly, Peter and I both decided to use Declarative Services (DS), where as Neil decided to create a light-weight service driven API.

In that regard, the approaches fragment and it becomes difficult to compare Neil's approach with the approach taken by Peter and myself. The main advantage of the service driven approach is that you don't need to use DS. You create an instance of the service interface and register it, then the rest of Neil's code makes that implementation available as a Vaadin application. This is a great approach if you might not want to use DS and doesn't stop you from using it if you want. The main disadvantage here is that there is an extra dependency on the API that Neil has created.

With the DS approach there's no additional hard-dependency, though there is a dependency on DS implied. In both Peter's approach and mine, we simply extend com.vaadin.Application and mark the implementation as a component factory. After this, things differ slightly between my approach and Peter's.

My code looks for components with the property "component.factory=vaadin.app" and once I find matching component factories I take the "component.name" of the factory and use that for the HTTP alias against which to register the servlet that does the work. Peter's approach is to look for "component.factory=com.vaadin.Application/*" and take the name from the part represented by the wildcard. This seems like a more sensible approach, as the component name tends to be more unique and use a domain name type structure, if not the component classname, period. A classname is not really an appropriate HTTP alias.

Vaadin uses a fair amount of static resources. My view here is that in most cases a dedicated web-server should be used to handle static resources (e.g. Apache), in a classic n-tier setup where static content web servers sit in front of 'application servers'. As such I've created a second bundle called staticres which will proxy static resources from the Vaadin bundle, but the recommended approach is to use a web-server. Further more, if your app has additional static resources that are not in the Vaadin bundle then these can be added by creating a fragment containing those resources and setting the host to the Vaadin bundle. My "staticres" bundle won't know the difference.

However, this highlights another major difference between my approach and Peter's. In Peter's approach, he expects wraps the Vaadin jar and turns it in to an internal library, exporting it's packages to the container. However, the Vaadin is already a bundle, so this seems unnecessary to me. The additional downside of this is that if the Vaadin jar is updated by the Vaadin folks, then people using Peter's bundle will either need to rebuild it for themselves, or wait for Peter to release a new version. The approach I have taken allows people to update the Vaadin bundle independently of the OSGi code I've written.

The remaining differences between my approach and Peter's are at the code level. Peter's experience shines through showing much better concurrency handling and support for multiple HttpService implementations, where as mine only supports a single HttpService.

So in Conclusion, Vaadin must be an interesting technology (personally I love it) for three individuals to decide to skin that cat in their own way. While the DS approach I've taken is considerably different from Neil's service approach, there are definitely enhancements to what I have produced that I can make based on Peter's code. To summarise the pros and cons of all three:

Neil's approach:
+ no dependency on DS and does not preclude it either
+ not coupled to any specific version of Vaadin
+ lightweight easy to use API
- additional dependency on non-standard API
- no clear way to handle additional static resources
- may end up using DS anyway

Peter's approach:
+ well defined and sensible use of DS
+ high quality implementation
- no clear way to handle additional static resources
- tight coupling to a specific version of Vaadin

Brindy's approach:
+ not coupled to any specific version of Vaadin
+ additional static resources easily handled
- limited to one HttpService
- use of DS needs to be better defined
- needs better concurrency handling

If you're interested in working with Vaadin and OSGi and want a forum in which to discuss your ideas or get help feel free to join our Google Group.

Tuesday, 6 July 2010

functional programming and java - no thanks!

If this is a sign of things to come in Java-land I suspect I'll be moving on:


Ugly. Very ugly. So ugly in fact, I want to swear. I haven't looked at the strawman proposal yet, and really don't want to, but I suspect there will all kinds of problem with scope.

Functional programming has it's usefulness, it's great for languages like JavaScript for instance, which I think needs it in order to make up for lack of proper OO syntax or semantics.

What would be really useful in Java is autosynthesis of properties. What the hell do I mean by that?

Well any Java programmer knows that they'll end up writing getters and setters for properties, or ignoring them all together and making the instance variables public (I don't!). A useful feature in Java would be a way to reduce the need for getters and setters while retaining binary compatibility.

It's really not hard:

public class Person {
public property String firstname;
public property String lastname;

Which can then be accessed in *either* of the following ways:


And if you really want a getter or setter ... just add it!

public class Person {

public property String firstname;

public property String lastname;

public String getFirstname() {
// Do something funky, return something completely different, or just return the property itself.
return firstname;


public class Person {

public property String firstname;

public property String lastname;

public String setFirstname(String firstname) {
if (firstname == null){
throw new NullPointerException("firstname cannot be null");
this.firstname = firstname;


That's the kind of thing I want added to Java.

Wednesday, 9 June 2010

Money Tracker for iPhone

Money Tracker is the simplest financial application on the App Store. It is a no frills day to day money tracker to help you watch your spending easily and quickly.

To start, click the button in the lower left to set a spending amount. Then simply add expense items to subtract from your spending amount and you'll be show how much you've got left, or how much you're over.

You can also mark an item as a credit and this will add instead of subtract from your spending amount.

Great for students or people on a tight budget trying to rein in their disposable income!

Money Tracker is only available in English, but it does support your local currency according to your iPhone's setting - so don't worry if you use Euros, Dollars, Yen, Pounds or anything else - it will still make sense!

If you find problems please comment here!

Screen Shots:

My First iPhone App!

I've just submitted my first iPhone app - Money Tracker... a port of my Android app to iPhone. It's been a very interesting journey and once I got stuck in to it I was actually surprised how easy it is. I'm sure I've still a lot to learn, though.

I'll be posting more details in my next post, which I'll be using as the web page for the application.

Saturday, 27 March 2010

practicing with fibonacci

It's Saturday morning, I'm slightly hungover and my wife has gone out shopping with her friend (and my credit card!). What else am I going to do except practice some coding?

I was reading a few academic sources and a lot of them mention Fibonacci sequence and I thought to myself, you know, I've never coded that (I mean, why would I?).

First up, I created a small test harness:

int sequence[] = { 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233 };

for (int i = 0; i < style="color: #2600c9">length; i++) {

assertEquals("fail " + i, sequence[i], fib(i));


And then I knocked out an iterative function in virtually no time:

public long fib(int n) {

if (n < 0) {

throw new IllegalArgumentException(

"Negative numbers are not supported");


if (n < 2) {

return 0;


long result = 0;

long first = 0;

long second = 1;

for (int i = 0; i < n - 1; i++) {

result = first + second;

first = second;

second = result;


return result;


It works, and it's fast, I went back to reading.

After a while I found another example of the Fibonacci algorithm:

static long fib(int n) {
return n <= 1 ? n : fib(n-1) + fib(n-2);

Oh! Recursion - damn it, of course, it's obvious, but wait ... throw in a big number there and what's going to happen? Well assuming you don't run out of memory (the stack frame should be quite small anyway), that's going to be slow...

For every number up to n where n is greater than 2, it looks like that function gets called 2 * (2 ^ n) times, i.e. O(2^n) - so assuming i throw in 50 that's 2 ^ 50 operations ... i.e. a lot.

Note: Further reading reveals that function actually has a complexity of O(2^0.7n) though I don't know how they worked that out. If anyone can enlighten me, I'd appreciate it as I haven't done this stuff in anger for several years now.

I wrote two more tests in my test harness to see the difference in time and threw in 50. The iterative one always finishes almost instantly - you can see by looking at it that it will run in O(n) time, the recursive one takes around 90 seconds on this computer.

The next problem I encountered was testing with larger numbers - I soon started seeing negative results as the maximum value of long was exceeded and automatically wrapped around. For instance, throwing in 200 yields -1123705814761610347 which isn't much use.

Thankfully Java has something called "BigInteger", which, as the name suggests, lets you use Big numbers. I modified the method to use the BigInteger class as follows:

public BigInteger fibIterative(int n) {

if (n < 0) {

throw new IllegalArgumentException(

"Negative numbers are not supported");


if (n < 2) {

return new BigInteger(String.valueOf(n));


BigInteger result = null;

BigInteger first = new BigInteger("0");

BigInteger second = new BigInteger("1");

for (int i = 0; i < n - 1; i++) {

result = first.add(second);

first = second;

second = result;


return result;


Throwing in 200 to that method yields 280571172992510140037611932413038677189525 which looks better, though I will have to take it on faith that it is correct.

Wednesday, 17 March 2010

enable or disable buttons in a mx:ButtonBar

I can't believe there isn't actual support for this built in to the component, but I have come up with a 'cunning hack' which gets around the limitation of the mx:ButtonBar in which it is not possible to bind the enabled state of it's buttons:

So the object's "toolTip", "label" and "icon" properties get propagated through to the buttons added to the button bar, but the enabled property does not. The code above simply fools the binding in to action by calling a method as part of the bind. When the property changes, that method will get called again and the button's enabled state will be set correctly.

Saturday, 27 February 2010

neo4j on OSGi

I need to have a deeper look at neo4j, which I found out about via InfoQ today, but initially I thought I'd see how OSGi friendly it is.

At first look I was quite excited - the neo4j jars are actually bundles. Yay! :)

So I dropped the contents of the neo4j lib folder in to my Apache FileInstall folder to see what happened.

org.apache.felix.log.LogException: org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Import-Package: org.neo4j.index; version="1.0.0"

And was probably due to:

org.apache.felix.log.LogException: org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Import-Package: org.apache.lucene.analysis; version="0.0.0"

Aha! A quick look at the provided Lucene jar reveals that it is not a bundle. Boo! :(

Easy enough to sort out though, create a quick bnd wrapper! Or so I thought. The following wraps the Lucene jar creating a bundle which exports all the packages from the Jar and imports all detected dependencies:

-classpath: libs/wrapped/lucene-core-2.9.1.jar
Export-Package: *;version=${Bundle-Version}
Bundle-SymbolicName: lucene
Bundle-Version: 2.9.1

To use the above, put it in a file called lucene.bnd and run the bnd tool on it. However, that wasn't the end of the problem...

org.apache.felix.log.LogException: org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Import-Package: sun.misc; version="0.0.0"

sun.misc ... WTF? sub.misc is an optional package used by PersonalJava and a few other things that I doubt many people care about these days. Unfortunately bnd detects this package usage when it creates the bundle and makes an import for it. This can be overcome by creating an import specifically for that package and marking it optional:

Import-Package: sun.misc;resolution:=optional,\

The * at the end is quite important, as that tells bnd to make sure it imports all other detected dependencies, as normal.

After that the bundles installed and activated without any problems. Sweet. So I will probably come back and look at neo4j in more detail after I get some sleep.

However, this is the second Apache project that I have looked at this week which has not made it's JAR files bundles by default, the other being Batik (from the XML Graphics project). It isn't a difficult thing to, so why don't they all do it?

Thursday, 25 February 2010

My thoughts on "Alex Buckley on Jigsaw: Modularity for the JDK"

These are the key points I took away from this talk at JAX London:
- Jigsaw is a modularity solution for breaking up the JDK to improve start up times, memory usage, etc
- It is totally backward compatible, e.g. your Java 6 apps should work on it
- if you don't choose a subset of the JDK, you get it all
- The classpath, as it works now, will live forever, i.e. to support those that don't want to use modules
- People can use Jigsaw if they want
- Jigsaw is nothing to do with JSR 294
- There's a bunch of additional optimisations that could be done in addition to modularisation
- Packages will be split across modules, but that's not as important as in a dynamic module system and is basically impossible anyway because of the way the JDK hangs together
- Class loading will work as it does now and all classes from the JDK modules get loaded in to the same class loader
- There was an implication that it would be possible to distribute a cut down version of the JDK which included just the modules you wanted, but that requires clarification.

I don't see Jigsaw having any negative affect on OSGi. In fact the smaller Java runtime that would be the result of this work only enhances the OSGi value proposition. Creating enterprise applications with OSGi is already lightweight compared to using J2EE and [insert any bloated app server here], so having less stuff to bootstrap can only improve that further.

The most significant impression I took away, was that most of Alex's points (e.g. multi-dimensional versioning??) were motivated his grappling with modularising the JDK. This seems to be reflected in his previous responses on the JSR-294 experts mailing list and is disappointing because the JDK we love so dearly has some fundamental flaws so modularity solutions driven by these flaws are potentially inherently flawed also.

I also found it funny that he blamed the poor architecture of the JDK on the fact it was started in 1995 ... so only 23 years after the term modularity was first coined. But I suppose the crazy number of bidirectional dependancies is understandable and as Neil Bartlett says is also a bi-product of it getting so big; a warning to other up-coming languages, e.g. Scala

Thursday, 11 February 2010

In Bed with Vaadin and OSGi

In this post I will show how to create a modular rich internet application that will run on any browser using Java, Vaadin and OSGi. I'll make all sources and binaries available for download at the end of the post.


I've been working with Flex and combining it with OSGi (on the server) at Arum for the last couple of years and while Flash, especially using Flex as a development tool, is a fantastic platform with great penetration, I have found that I still yearn for solutions which require no plugins. In the last few weeks this has become even more important to me with the announcement of the (Flashless) iPad and embarking on a personal project that needs to run on every browser, not just a browser with a Flash Player plugin installed.

Before starting at Arum I had investigated creating modular RIAs using GWT and OSGi. GWT lets you write your UI code as Java then as part of another build step spits out HTML and JavaScript that works across browsers. Most importantly for me was the fact that converting the Java to HTML/JS was a build step, and not done at runtime. As a result, it is impossible to create modular applications with GWT, though that might change with GWT 2.0. However, even if they add GWT modularity, it will still require a build step to convert Java to HTML/JS.

Having spent a great deal more effort looking for a solution to this problem (how to create a plugin free, cross browser RIA using Java and OSGi) I finally discovered Vaadin.

Vaadin is a suite of HTML UI components that have already been built using GWT, then are composed in to a running application using Java... at runtime.

A "Hello World" Vaadin application looks like this:

Vaadin and OSGi

I was particularly interested to learn that someone had considered using Vaadin with OSGi, though I personally do not like the concept of wrapping it in a J2EE style web application (WAR), nesting the OSGi container inside:

It is understandable that people would assume that if a developer that wants to create an RIA with Java they will want to deploy it as a WAR. However, I generally don't use application servers anymore. They tend to be bloated and have a large footprint soaking up much of a VM's heap space just to get started, and as a result tend to have a fairly long startup cycle (from several seconds to over a minute in some cases). Using an OSGi container *as* an application server gives you a much more lightweight application that doesn't require as much memory and starts up almost instantly and out of everything in the J2EE spec, the only thing I regularly come back to is servlets. Everything else seems to be an exercise in telling developers how to build applications with the view of scaling up hardware - obviously a winning approach for Sun in the old days, but not so useful for people wishing to get away with minimum footprint these days (for example by creating a cloud architecture which uses the minimum resources required and scaling up as demand dictates, not the software architecture).

Right out of the box (from at least version 6.2.2 onwards anyway) the Vaadin jar file is already configured as an OSGi bundle which means I can write other bundles which use those APIs.

My next activity was to make Vaadin not just OSGi friendly, but OSGi's "best friend forever". To do this I wanted to achieve the follow things:
- Allow bundles to register Vaadin Applications (whiteboard pattern - it's easier to register services than look them up) and automatically create a http resource for them.
- Allow bundles to register static resources (themes, widgetsets, etc)
- Make no changes to the core Vaadin jar file that you can download from their site

The result is three classes which are built in to a separate bundle that I currently call com.vaadin.osgi.

- StaticResources runs as an OSGi component and serves the themes and widgetsets directly from the core Vaadin bundle.

To add your own theme or widget set create a fragment which contains your theme/widgetset files and export those as packages. The Fragment-Host should be set to the Vaadin core bundle. The fragment containing your theme/widgetset resources will be added to the core Vaadin bundle dynamically.

Of course static resources should really be deployed separately to a web server that proxies servlet requests on to the container, so I wouldn't recommend this for use in a production environment.

- VaadinOSGiApplicationManager also runs as an OSGi component and looks for OSGi component factories with their component.factory property set to vaadin.app.

The component factory name (specified as component.name) is used as the alias to register an instance of VaadinOSGiServlet which then uses the component factory to create an instance of Application. For example, if component.name was set to myapp, the servlet would be registered at http://localhost:8080/myapp

- VaadinOSGiServlet creates instances of applications that have been registered with the container via a component factory.

This is what is registered by the VaadinOSGiApplicationManager.

Creating an OSGi Vaadin Hello World Application

To get the hello world application shown near the beginning of this post up and running we need to create a bundle which registers the application as a component factory. There is no additional Java code required for this step and by far the easiest way to do this is by describing the bundle with a bnd file.

To create the bundle simply run bnd. I used the following command on my system:

java -jar ~/Downloads/bnd-0.0.384.jar helloworld.bnd

More about bnd and how to get it can be found here:

The result is a bundle that uses declarative services to register your application as a component factory. This is the cool part - if you want to access other OSGi services just create binding methods for them in your application and update the bnd file. Declarative services then injects your application with the services automatically when an instance of the application is created.

Vaadin has this great concept of 'production mode'. When an application is not in production mode, you can append ?debug to your application's URL in order to see a debug console that shows you all kind of useful information such as the traffic between the browser and server, how long requests take, the JSON that has been passed backwards and forward and also gives you a useful 'restart application' button which forces the creation of a new application instance. Obviously, you will want your application to be in production mode at some point so to do this you need to pass "productionMode=true" as a property to the VaadinOSGiApplicationManager and because it is running as a component you can do this using configuration admin. With Apache Felix Fileinstall this is as easy as creating a file called com.vaadin.osgi.VaadinOSGiApplicationManager.cfg and specifying productionMode=true as a line in the file.

Every application will no doubt want it's own theme, right? To do that, again we're going to use bnd to create a bundle which simply adds our theme to the resources in the core Vaadin bundle, a using a useful and under-used feature of OSGi known as Fragments.

Create a folder called etc/theme under which create your theme assets. For example, etc/theme/VAADIN/themes/helloworld/styles.css. The following bnd file would then create a fragment.

Install the fragment and update the core Vaadin bundle and your theme is now available (delivered via the StaticResources component). With the theme installed the hello world application now looks like this:

Again, using bnd to create my bundle:

java -jar ~/Downloads/bnd-0.0.384.jar helloworld.theme.bnd

And that is that; a themed hello world application that is primed for dynamic modularity.


[Edit 10th September 2010]

Since writing this I've published an add-on to the Vaadin Directory that contains the bundles you need to run your apps as OSGi apps and a simple example. You can find that here:



Lastly, I have to thank Neil Bartlett for mentoring me through some of the OSGi concepts I've used here. Thanks Neil! You can find Neil's website full of useful OSGi information here:

Saturday, 23 January 2010

TDD FTW! - Android Cineworld App fixed in seconds

That is, Test Driven Development, for the win! =)

I just received an email from a confused user of my Cineworld Android application (UK only) telling me that it wasn't working. I was especially grateful though, as most people just change their rating to one star and leave a comment, but the Android market place doesn't push those comments to the developers.

Anyway, when the application loads for the first time it queries the Cineworld website for a list of cinemas, but in this case an error was occurring so the application was popping up a message saying "Unable to connect to server. Check your settings and try again later.".

At first I didn't think I had time to fix the problem but then I remember I had a bunch of unit tests for the application. So I loaded up the workspace and ran the tests and sure as hell, one of them failed.

But this was fantastic!

I could instantly see that the Cineworld's home page format had changed slightly and that might my app was unable to find the indicator it was looking for in order to extract the list of cinemas. Thankfully, it was only a change on the home page (they have installed some fancy-shmancy Javascript thing) and the 'cinemas' page still contained the list required by the application, so I only had to update the URL I was using, re-run my tests to verify and voila, a fix!

No complicated debugging session, or log viewing or anything like that. Just run the unit tests, make the fix, verify with the unit tests and job done - just the way it should be.

Wednesday, 13 January 2010

Agile OSGi with Eclipse and Nimble

There's a view that doing things 'the OSGi way' adds overhead. In fact, I have even been told in the past "don't worry about the modularity thing just now, just get the demo out of the door".

However, for me, working with OSGi is a no brainer, and adds virtually no overhead even for the smallest projects. Additionally, I find that not only is it sensible to start with OSGi, but doing so speeds up my ability to deliver quality modular software.

There are a couple of tools that help make life easy for me (as it should be for a developer) so that I am not wasting time with my environment. These tools are Eclipse and Nimble.

Firstly, my IDE, Eclipse. I give it a hard time sometimes but it does let me get on in what I feel is a very productive manner. Eclipse 3.5 is generally great and has even more support for OSGi and my personal favourite is the support for declarative services - the editor making it very easy to spit out the required XML making it really quick to build a component based bundle in hardly any time. For those 'small' projects that people consider an overhead, I still recommend this approach, as it is noddy to add a main method (either to that component or another class which uses that component) and you still end up with a jar file you can execute from the command line, especially if you add the Main-Class attribute to the manifest. At the end of the day we're still talking about simple Java objects, but with a little bit of extra metadata.

Finally, the key to clarity when developing OSGi apps in Eclipse is 'targets'. So for each workspace I would create a meta-project that contains an Eclipse target and any top level external dependency bundles. The target references these bundles and when I apply the target to my workspace I now only have visibility of the exports from the bundles in the manifest editor, and those plugins in Eclipse's plugin perspective. All the noise from the hundreds of bundles that Eclipse uses to run is gone.

(For me, the only thing that lets Eclipse down is that I feel it could be more defensive about how it handles plugins which don't always play nicely)

Until recently I made the framework I was deploying to a big part of the development architecture. In fact I would write an ant script to build my bundles, the framework, it's dependencies and then deploy my bundles in to that framework and then run it to do my integration testing.

While doing a development cycle of code/compile/deploy I would tend to have Felix running with fileinstall configured to look at a folder called plugins and then use Eclipse's export tool to drop new versions of my bundles in to that folder. Fileinstall detects the new bundles and adds/updates as appropriate. But what about dependencies? They would have to already be installed in the framework. For for each external dependency I am using I would have to resolve that bundle's dependencies manually... if those bundles have dependencies and so on, this soon becomes long winded and tedious!

These days I am much more agile about this and use 'Nimble', which is OSGi resolver technology from Paremus. To use Nimble, you simply install it and you get 'posh' - the Paremus OSGi Shell, another clever piece of technology that can save a lot of time.

So if I wanted to test my application on Felix I would start posh as follows:

posh -C -F

The -C parameter clears the cache and downloads dependencies from scratch. -F specifies that I want to use Felix as my framework. In a few seconds I have a running Felix OSGi framework and a sophisticated OSGI shell but not much else. (At this point the docs on posh are really useful to see what you can do.)

Once I've indexed my bundles I create a nimble rule which defines a dependency on the activated state of my bundles and osgi services and save this in an xml file of it's own to the plugins folder as well:

Using the command 'nim add app/myapp' my bundles are installed, resolved (including dependancies) and started.

The last thing I have to do is tell the HttpService what port to start port:
setpid org.apache.felix.http org.osgi.service.http.port==8080

but I only have to do that once per Posh session.

The key thing here is that all my dependencies are resolved for me. I don't have to do anything except worry about my production bundles.

Then when I want to distribute my application to colleagues or the customer or deploy to another environment, I just distribute the bundles and my repo xml files, and they fire it up with minimal effort. Glorious!

Please note, that the above does not necessarily constitute best practice. I have been chatting with the Paremus guys about best practices and will follow up with information about that at a later date.

Saturday, 2 January 2010

2010 and me

Firstly, welcome to 2010 everybody!

I don't know about you, but I'm kind of disappointed we haven't had any manned missions to planets in our solar system. By this stage in Arthur C Clarke's books we were on our second trip to Jupiter. Oh well. :)

So what does 2010 have in store for me?

My focus is going to stay on OSGi, of course. In January I am attending the OSGi UK Users Forum, again as secretary. The UK forum has been going for nearly a year now and has some impressive growth and all the attendees are great people with lots of interesting stories to share, so I'm looking forward to that one.

I am also attending Jax London (and OSGi Devcon) - last March I attended The Server Side conference in Las Vegas which was excellent, but frankly a little expensive in terms of cost and time (and environment?). Better all round to support local events, I feel.

I'm still loving Flex and db4o, so plan to keep using those technologies this year, but expand my view in to other OODBs (e.g. Versant and InterSystem's Caché) and rich internet technologies (e.g. Apache Pivot - Java RIA platform, Vaadin - HTML/CSS/Ajax RIA platform. Flash is great, but there is a lot of leverage to be had from 'pure browser' RIAs).

Actually, I've been very quiet on the Apache Pivot front this year, but graduation is afoot and Pivot is maturing nicely, being used in a couple of production environments I believe. While I'd love to donate more time to this, I would be well just donate a little as I have been far too inactive of recent times. I had starting building a an Eclipse plugin to preview Pivot views, so I will discuss with the community how I can enhance this further.

Taban, my REST and OSGi based JSON storage application is still floating around in my mind, but like everything else, it is just a matter of finding the time to finish it off and then find an appropriate place to host it.

I'm still enjoying Android as a platform, but feel it is a little too much in Flux. While 53% of all handsets are running Android 1.6, about 25% are running Android 2.0 or greater and I feel like I shouldn't invest too much time in an SDK which will soon become obsolete.

On the Google front, in May my wife and I are attending Google IO in San Francisco (at our personal expense), though I am sure she is less excited about it than I am. ;) Last year attendees were presented with an Android phone. I can only hope we are presented with something as cool as that, my wildest dream being handed a Google Tablet. We shall see!

With regards to Arum, before Christmas I worked on a very interesting market data platform based on OSGi, Flex and db4o before Christmas and am hoping to have further input in to that. The potential for extending the application is great and has been helped in no small part by the flexibility of the technologies involved and by instigating a modular architecture from the beginning. I used to think that RAD projects should be considered 'disposable' as the speed at which they were built usually meant you were doing something wrong, but by using OSGi, Flex and db4o we reduce time to market for a functional (though not feature complete), rich application, to just over 3 weeks worth of work between two people (myself and Vince). The current application is being demonstrated to the community that will adopt it and I am sure that more functionality will be requested in the new year.

I am also hoping to start on a new version of Arum DataEye, taking lessons learned from the last two years and building an even better management information dashboard, considering software as a service as well as customer site options for deployment. With 2 major sales under our belt and nearly 300 active users, we have excellent feedback with which to make the new version of DataEye even better.

At Arum, we have also been considering a brand new product, so I am looking forward to working with the team to flesh that out, get it built and make it available to the masses. More information on this as it happens, but no doubt will be built on and driven by the excellent technology we've had much success with so far.

I also have plans to build an Eclipse based IDE for rapid development of modular applications based on Flex, OSGi and db4o. This tool will reduce time to market by a massive amount, allowing Arum to produce the majority of a functional application in a fraction of the amount of time, drawing on our library of OSGi bundles that we've developed, and upon those distributed in remote repositories such as Spring's OBR and Maven. Again, watch this space ... but don't hold your breath. :)

With Arum's focus on building low-cost, high quality, open source based, rich internet applications and products, it is a pretty exciting place to be.

Towards the end of 2009, I started doing a little freelance work with Paremus, the makers of Service Fabric (fantastic distributed OSGi cloud platform), Nimble (excellent OSGi resolution tool), Posh (Paremus OSGi Shell) and Sigil (OSGi development tooling, now part of Apache Felix). These are a great bunch of really clue up guys, and I hope to continue working with them in to 2010.

A more general comment about consumer technology; my prediction for this year is that 2010 will be 'the year of the tablet' with Apple (OSX or iPhone OS?), Google (Chrome OS probably) and various Android based tablet products on the horizon, we could be entering a new era of always on and always connected lifestyle. While tablets have been around for sometime I believe that the 7" or 10" touch-screen internet tablet still has room for impacting in popular culture and that 2010 is the year for that. Expect to see people carrying these around commonly, much like the e-book readers that I regularly see fellow commuters using, but accessing electronic magazines and other web applications.

All in all, I am sure that 2010 is going to be an exciting year, in my work, personal projects and with regards to technology in general.