Run-time composition of services: like a swan?

Web Services are a fairly amazing concept, when I think about it. You have a service, running on a server somewhere in the world, that accepts requests from other places and then returns information to them. This could be as simple as getting a request for the temperature in a particular city and returning it, or as complex as being asked to search a database for, say, hospitals near a given location, and return their details as an XML document.

Other people can then build onto that, combining different web services in various orders to get more and more detailed and crazy applications. This is what makes mobile development so exciting - there are so many possibilities open to creative designers that the sky isn't even the limit anymore.

What really begins to shake things up, though, is when there's more than one service offering the same results. There are likely to be a few factors separating them - one might cost more, yet one might be more reliable, and a third might return results more quickly.

So we start creating systems that look at the alternatives available when they query these services, in order to optimise the return of results - and that's not an easy task. And then we have to consider what happens when a particular service is unavailable - do we just wait and hope that it sorts itself out sooner rather than later, or do we try to recompose the rest of the service and attempt to get round the problem.

It's only as I dig deeper and deeper into the bowels of service composition that I realise how staggering a task it is - so many variables and so much frantic querying, estimating and processing, and all of this has to be hidden from the end user. It ends up like a swan: perfectly serene and stable on the surface, but flailing around like a mad thing underneath!

News at last

Finally there's a little bit of forward movement on the Masters course - we've got the dates for the seminars sorted. Of course, the first one is scheduled for one of the few days in the next few weeks where I have something on that cannot be cancelled or moved at all, but I guess that's life...

But at least there's stuff going on. In other news there, the collection of papers to do with SOA and the application of genetic algorithms thereto continues. There's been a bit more work done on this field than I'd anticipated, which was a little surprising, and it falls into two general streams.

One takes a composed service, made up of lots of interchangeable component services, and tries to work out the best combination of services given a specific set of requirements. This is pretty similar to work that I've done already in this area, so that's encouraging.

The second uses the genetic approach to try and combine services efficiently into a single component service. This looks fantastically interesting and useful, but it would mean learning a whole new mathematical language of combinatorial algebra, and then trying to code it into Java. Which is unlikely to take place over the course of a single, part-time year.

But hey - I'm meeting up with my supervisor soon enough, and we'll have a look through the papers to see if he thinks that the gaps I've spotted are (a) actually gaps at all and (b) big enough gaps for a research project.

7th Sea Dice Roller

Version: 1.0

Description

A dice rolling application for the now-defunct AEG game 7th Sea (website unavailable: domain has lapsed).

Users choose a number of dice to roll, a number of dice to keep, and

whether the dice explode. The results are displayed and the user can choose to add Drama Dice to increase the total.

Availability

Android Marketplace (search term: 7th Sea).

Requirements

OS: Android 1.6

Hardware: screen resolution 320x240 or higher (recommended 480x320 or higher).

Data usage: none (may be updated in future versions to use Random.org's randomiser)

Storage usage: none

Known bugs: none

Known issues: on altering screen orientation, current dice roll is removed.

Recent changes

Updated portrait mode layout to stop the Add Drama Dice button disappearing on some smaller screens.

Release Candidate #1

So, I've opened up the wallet and shelled out for the developer login over at Android Marketplace. Now it's time to put my mouth where my money is, so to speak, and actually get some content up there.

Now it gets to that point, it's all very intimidating! But sure, what is there to worry about? Apart from, you know, having any mistakes I made exposed to the general public? Um...

I've also been wondering quite heavily on the testing of apps. This first one, see, isn't really going to need that much testing: it doesn't do a great deal, see? But I've only tested it on the Android emulator bundled with the SDK, and then on one handset (and a powerful one at that). I know several people who would almost certainly help with the testing (and might even use it from time to time!), but none of them can easily connect their phone to my PC with a USB cable for debug purposes. The only real solution here, it seems, is to release it as quietly as possible, and hope that people won't flame me horribly if it doesn't work first time round. Not ideal, but hey.

You know what? A blog post would probably serve as a useful standby page for the app website. I should fix that up now...

Rather random

Someone got me thinking earlier about the random number generator that I've been using for the various dice rollers that I've written. Now, usually I'd just go with the default RNG for whatever platform I've been writing for, and that'd be that. I realise that randomisers can only generate pseudo-random numbers, though, but most of the time that's plenty good enough for our purposes.

However, I found a useful looking site today: http://www.random.org/, being operated from Trinity College Dublin. They generate truly random numbers from atmospheric noise, and there's an API to plug into to that can be used to pull sequences of random numbers over the Internet. Now combine that with a smartphone's data connection, and that would be a perfect dice roller! Of course, I'll have to think about things like user permissions (and give the user the choice to go online or not - particularly if they happen to be roaming at the time), but this could be an interesting little project to make sure that I'm reading data correctly from Android's http connections.

Not sure how much of a rewrite this'll end up being, though. Possibly fairly extensive...

Fragmentation

Usually a problem considered to occur to hard drives, I'm beginning to hear this addressed at the Android OS as well. It's a totally different context, mind: in this case it means the difficulty in developing applications for a supposedly unified operating system that in fact runs on many different devices of wildly differing specifications.

Take, for example, the dice roller app I'd worked on for a while. It was developed for a pretty standard screen resolution of 320x480, and the interface seems to fit quite nicely that way. Scale this up to the oh-so awesome HTC Desire, with a resolution of 480x800 (or whatever it is: it's ludicrous, for a phone!), and it looks even smoother.

The other day I tried to pop the same app open on the emulator running the specs of the HTC Wildfire. Oh dear. The screen is a tiny 240x320, which seems minute for a smartphone, and the app is unusable. Having looked at average screen sizes when I began the development, and settled on 320x480 as a useful size, it's a little frustrating to now discover that a newer device can't run the app. I can only imagine what other development teams who have put weeks and months of work into apps, now to discover that the new range of budget smartphones will require them to rewrite sections of the interface to make sure that they fit onto them cleanly, or they'll just have to put a minimum resolution requirement onto the app itself (I'm lazy: that's the approach I'll be taking, I'm afraid).

Service composition

Electronic journals are both big and clever, it seems. It's also very useful to be working from within the library, and thus gaining instant access to said journals from my own laptop: technology is a marvellous thing!

I've started looking into service composition techniques now, and they're looking to be really quite a complex beastie, particularly when you begin to factor in dynamic service composition which, for my sins, is what I'm attempting to research. Obviously, when you have a group of x services that can e combined in a variety of orders to achieve a variety of results, searches to try and combine them are going to need to be heuristic to some degree: the mind-boggling number of combinations rapidly rules out a brute-force search for all but the smallest number of systems. However, the number of combinations and techniques available for a heuristic search is also beginning to hurt my brain ever so slightly.

Fortunately, it appears that not many people have looked into the method that I'd like to look at (genetic algorithms). Unfortunately, this means that I'll have to start this all from scratch!

New Project: HealthWhere

I've got another Android project on the go at the moment: HealthWhere. It's an adaptation of a utility by Russ Philips to help find local hospitals and pharmacies, using the data from OpenStreetMap.

The plan for the project as a smartphone app is to use the positioning tools available to smartphones (satellite positioning, or just approximate cellphone mast positioning) to get the user's current location, rather than just asking them to input an address. The OpenStreetMap database can then be queried, and the results returned for quick and ready reference. It should also be possible to fire those co-ordinates over into a navigation app to provide instant directions. Just add water - or something!

Plan:

The interface is roughly divided into two halves. The first half is to determine the user's location (or a location to search in, if you want), and the second is to display the results of that search in a usable and meaningful way. Of course, there needs to be a bridging part which actually gets those results, but that'll be behind the scenes.

My plan for working at the moment is to consider the app in order.

1) Determine a position to search from.

2) Carry out a search, and parse the results.

3) Display those results.

4) Give an option to upload location data if it's not there already.

I'm sure that other ideas will occur to me as I go, as well, so we'll have a (5) Other interesting stuff.

Progress:

The first stage of the app is just about complete. The opening menu screen fires up and gives the user the various search options:

• choose between searching for hospitals or pharmacies.
• choose a search radius
• choose to input a location, or to use the phone's positioning features to find the current location.

From this point, the geocoding and reverse geocoding work as well, to either determine co-ordinates from the address entered, or to determine a local address from a set of co-ordinates.

The second stage is going well: the search query is constructed, and an XML file is returned which contains the results.

Next steps

The next step is to write up the classes for the different healthcare amenities, and to parse the results file into something meaningful.

Lastly, I'll be working on displaying those results as a list for the user to scroll through.

At some point, I'll also need to have a look at how to upload data as well.

I have never done this

In all my time working at P&C, I never made this mistake.*

I did make a few others, though, and I'm well aware of that sinking feeling that Mr. Brooker describes so well. It is pretty easy to do, though. You can have comfortably five or six different proof versions, from the first proofs through to the final to-the-press proofs, and even then it's possible to have someone be looking through the book at the last minute and discover that you've spelled the author's name wrong on the title page (it's happened!), so your file of "Final, final, no really final, book.pdf" is suddenly invalidated.

Actually, an entertaining part of this story has been the blame game going since Friday, as each of the parties involved tries to point the finger at someone else.
- Franzen himself initially blamed the printers: "They printed the wrong file."
- The printers (qutie fairly) pointed out that "we only printed the one file we got given guv'nor - and we're not responsible for the content". They blamed the publisher.
- The publisher, on receipt of this hot potato, smoothly and immediately tossed it across to the typesetters: "The typesetter passed the incorrect version of the text to the printer. It's nothing to do with us."

At this point, my sense of professionalism kicks in. At no point should the Production Manager ever sign off on something he's not seen. You don't just get a phone call from an outsourcing company saying "We've done the work, OK?" and say "Sure, good job guys, bung it over to the printer and tell them to run off a cool 80,000 copies, right?" instead of getting the file back, checking it, and passing it to the printer personally. And you know what? If you do, you deserve something like this to come and bit you in the arse. No matter who ends up copping the blame in the media, there is a Production Manager over at HarperCollins who will be feeling the burning glare of a thousand angry supervisors for the next wee while.

*: One of my first assistants did, though, but fortunately the mistake was deemed insufficiently awful for the book to be pulped. Thank goodness.

Propositions

This morning I had a very quick chat with one of my lecturers about the prospects of continuing study to take an MSc. There were a few things that I would have been very interested in looking at, and - by some amazing fortune - two of them can be combined into a mega-research project that should be both (a) useful and (b) fascinating.

I'd get to carry on developing the genetic algorithm that I worked quite hard on during the diploma (one of the highlights of the course, to be honest) and try to integrate it into the wider context of Web Services and a more useful application than the rather abstract "workers and tasks" scenario that I'd been testing previously.

So, all in all, a rather productive morning! Now I actually have to do a bit more background reading and sort it all out as a full on research proposition. All very exciting!

Platformer blues

"I've got a great idea for an app - but what phones should I write it for?"

It's an interesting question and - as it turns out - the answer is harder than I thought. Now, in an ideal world, you'd just write and release it for all the major smartphone OSs - Symbian, iOS, Android and RiM. But that's quite a lot of effort for just one person! So how do you maximise your returns or exposure for minimal effort?

First of all, it's probably an idea to think about what language you're comfortable working in, and what operating systems that the language plays well with.

• Nokia -- a whole variety of languages supported, so you'll pretty much have to pick the one you want and grab the relevant package for it.
• RiM Blackberry -- Java
• Android -- Java
• iOS -- one of the C languages. You'll also need (yes, really - it's mandatory) a Mac.

Next up, let's look at the different platform distributions (data from Gartner).

• Symbian: 41%
• RiM: 18%
• Android: 17%
• iOS: 14%

It might be worth noting, though, that the market share for Android jumped from 1% in 2009 to 17% in 2010 - obviously this might not be indicative of future trends, but Google have put a lot of effort into getting it onto as many handsets as possible. Also of note is that Oracle are currently taking legal action against Google for unlicensed use of the Java platform - though the future of that action is somewhat uncertain.

Lastly, we'll need to have a look at the different distribution systems for the different operating systems. (This is just a summary, though - there are multiple delivery platforms for most operating systems, so you don't have to follow the well-trodden path - it might just be a lot easier! Also, having not personally explored them inch by inch, there may still be pitfalls to discover...)

• iOS: Sign up for an AppStore developer account - this is $99 per year, and lets you distribute your apps through the AppStore, after they've been checked out by Apple.
• Android: Sign up as an Android Market developer for $25 (one-off fee), and this lets you distribute your apps through the Android Marketplace. However, there are caveats here based on countries - the list of countries where you can charge for your apps is currently quite small.
• Nokia's Ovi store: Sign up for $50 to register yourself as a publisher - this lets you upload content for distribution via the Ovi store.
• RiM's Blackberry AppWorld: I can't find a price for signing up as a developer, but again, there's a central hub for app distribution.

Most seem to offer a standard 30% distribution charge.

So, where does this leave us? Personally, I'm going to carry on working with Android for now - I think that it has a good future ahead of it, and I'm far more comfortable working in Java than with C. At some point, I'd like to give the iOS development thing a go, but it would mean buying another computer, which would be a little annoying.

Android app: details

Seventh Sea dice-rolling application
This is something that I've been working on for a little while. The dice rolls in the role-playing game Seventh Sea are not the most intuitive or easily calculated sometimes, particularly later in the game when you can be sorting through handfuls of dice, frantically adding some - but not all - of them together to get a total. This isn't exactly adding to the fast and frenetic nature of the genre. Therefore, I've been working on some kind of application to help speed this up.

History
It started out as a purely Swing based Java application, and since developed into a Java applet for ease of access. Finally, it has evolved into an application for Android platform phones, purely as a development challenge...
The development has taught me a good deal about developing for Android - and mainly that it's actually not that hard (particularly for something as simple as this)! There are plenty of good tools available, and the UI creation tools are a breeze - certainly much easier to get into than Swing.

UI
The UI is very simple for this app: there is a main menu screen with a few options available. The only one of any real practicality is the Roller screen, which contains the nuts and bolts of the application. There are two keypads, one of which selects the number of dice that you want to roll, and the other selects the number of dice that you want to keep. There are also buttons available to choose whether the dice "explode" or if and Drama Dice are added to the roll.

• Splash screen
• Menu screen
• Roller screen: Portrait 1 -- Portrait 2 -- Portrait 3
• Roller screen: Landscape 1 -- Landscape 2

The layout files are all quite simple XML files, detailing the page elements available to each page of the app. Each layout file comes in two "flavours", one for the portrait orientation of the phone, and one for the landscape. On a change of handset orientation, the phone switches between the layouts. (This does, however, call the onCreate() method of the layout again, resetting any options that have been chosen.)

Problems
There haven't really been many problems in development at all. The most challenging part was to develop the object-oriented approach to the dice-rolling, as there are some slightly awkward options and corner-cases to be handled.

Future tweaks
There are still some tweaks that I'd like to make to this app, though.
Firstly, it would be nice if changing the orientation of the phone didn't cause the app to forget any dice rolls that it had just made - this, I assume would be handled by a new implementation of the onCreate() or onResume() methods of the particular activity.
Secondly, it'd be nice to check out the RNG for the engine as a whole. This probably isn't essential, as I'm using the Random class, which should be more than enough of a random generator - each single die is given a 48-bit seed based on the system time when it's created - but it might be an interesting experiment to run some tests on how random it actually is.
Lastly, it'd be nice to add some extra touches from the mobile interface itself - perhaps some (optional!) sound effects. On the other hand, they are rather gimmicky, and would probably become extremely irritating rather quickly. (On the other hand, it would be a good reason to start working with storing user settings, so that's a good reason to implement them by itself!)

Thank the Maker!

It finally works! My first Android application - the 7th Sea dice roller that I've been going on about for a while and that has seen simultaneous development as a Java applet - is up and running. It's not available online yet, but depending on how confident I feel (and if I can convince anyone to be part of a beta test) I might end up forking out the $25 to sign up for Google's Android Marketplace and set it out in the real world.

The UI on the Android app is considerably nicer than the UI on the Java applet. I think I might need a little bit more practice using the Swing controls.

More detail will follow, when I'm not shattered :-)

Experiments in digital video, part 1

Finally! I've managed to convince an old XP machine that our (rather) old camcorder does indeed have a valid video driver. The result of that is that I can actually import a load of video from the tape that's been in there for ages and bring it into Adobe Premier. Now all I have to do is try and figure out how the heck Premier works! It's all a bit trial and error at the moment, but I'm making progress.

Of course, the next step will be to try and work with the other tools available in things like AfterEffects: you never know, at some point I might even convince a few people to get together and we'll attempt something crazily ambitious like Beyond Black Mesa. But that's a long way away yet ;-)

In the mean time, I get to watch the "Encoding Video" dialog tick ever so slowly towards completion...

An applet is born

Having found a pretty useful little article on the deployment of applets the other day, I promoted by 7th Sea dice roller up the priority ratings as an experiment to see what they can do. So there's now an unlinked page on my regular site which I'll be using as a sandbox (here) to test them. The current applet is a little crude, but serves to demonstrate that it works.

Next steps

The next steps will be to implement the option to change the number of dice that are kept on a roll, and to set up the other options mentioned on the dice roller development page.

(The article is here, and I found it very useful, even if it is a little old!)

Documentation is important

Well, the coding/planning part of the work is over, and now I'm onto the big cycle of documentation.

It took a couple of weeks to really get going on the project: the first week was spent doing research into the capabilities of the Creative Suite, and the next was spent exploring the variety of ideas I'd had. Most of them, sadly, ended up being junked as being a bit too complicated for non-technical folks to follow (the designs really did have to be idiot-proof: we'd previously sent PDF proofs to people who still had trouble signing into Windows!), but finally I had a set of ideas that (a) worked, (b) saved a lot of time and (c) don't crash unless the user is really, really trying. So I'm happy.

Sadly, there wasn't enough time to be able to set up an proper intranet for them, which I still think would have been quite handy; I'm doing the documentation as a small model of an intranet though, just to demonstrate the ideas behind it. You never know: I might get a call-back!

My plan is try to make the documentation sufficiently interlinked that it's never too hard to find the walkthrough that you're looking for: to write lots of small chapters, with plenty of links between them, and to reuse the same chapter structure wherever possible. (Lazy - or consistent? A bit of both, perhaps.)

It was a great couple of weeks spent in London, though, and a great little bit of work to be getting on with to get me back into the swing of things. I didn't manage to write any Java that week, but at least the old grey matter was getting a bit of exercise nonetheless.

Next up: finish this darned documentation, and then start writing my applets!

Messy Acrobats

We all hate losing work on a computer. And yet it continues to happen, through crashes, momentary incompetence, or glitches. Which is why a lot of software companies do their level best to ensure that this happens a little as possible, or that files can be recovered when they fall apart.

Which is why I'm a little worried about some behaviour I've been finding in Acrobat 9. One of the big draws of the latest couple of versions of Adobe's PDF creating software is the ability to do a shared review, where - by uploading the file to a central server - a bunch of users can write and reply to comments on the document to get it ready for final production. It's a fantastic idea, and far better than the old approach of emailing everyone a copy of the file, and trying to hold further discussions over email, compiling all the comments and finally working out what to do.

But here's the problem: with Acrobat 9.x, you must have a copy of Reader 9.x to get this feature to work. If you're working in Reader 8.x, a dialogue box pops up when you open the file to tell you this.

And then it goes away, and the commenting and online review tools all appear, exactly as you'd expect.

Great, you think. Maybe it will work after all, and the problem was exaggerated. So you blithely go through, add a few comments, ask for a margin to be reduced or a graphic sharpened. And you hit the "Publish Comments" button. Nothing much seems to happen, but hey - all the comments are there, right?

Except that the guy who sent out the review can't see them. He calls you up, asking you to upgrade to Reader 9 - which you do. You open up the file again, and suddenly BAM! - all the comments are gone. Reader 9, it seems, opens the file, talks to the server, and - seeing there are no comments - syncs your file to the file on the server.

It does beg the question: if you'll lose all the annotations you've made when you upgrade to the correct version of the software, why does it even allow users to make them? Why not just have a flag in the file that says: if opened in Reader 8 or below, disable commenting features?

I'm quite surprised that this hasn't been noticed yet, or fixed - perhaps it's not such a bad problem as I thought, and the other comments are recoverable. But software shouldn't give you such a heart attack moment, I'm sure.

Anyway, I'm going to go back to trying to find a more elegant solution!

Science: It Works.

With a little help from some very nice people over on the Adobe Forums, some of yesterday's problems are now (mostly) solved.

Yes, there are issues with importing Word files into InDesign; both packages have suffered from feature creep over the last couple of versions, so the integration of file types only gets harder and harder.

But what really solved the issue was the appliance of old-style scientific trial and error. Going through the processes that InDesign automates by hand, and working out which one of them was causing the error. As it turns out, ID isn't keen on long footnotes which split across three or four pages (you know what? I'm not keen on them, either!) and as soon as that was taken out, everything worked perfectly.

Once again, the principle of working through a process and breaking it down into the most basic steps you can find to figure out what's going wrong gives results. Excellent. Now I can get back to what I was supposed to be doing, and automating as much of the typesetting as I can.

Interoperability; or Play nicely, boys

I'm back at work for a while now, trying to convince two very separate applications to play nicely with each other.

In the red corner (as it were) is Microsoft Word, the very commonly used word processor & text editor. In the blue corner is Adobe InDesign, the heavyweight page layout software.

Despite the similarities of the two, there are some really fundamental differences between them, going right down to the basic level of what the software is designed to do.

Word

Word is designed to make it very easy to type simple documents, apply some rough page and type formatting, and print it out or email it. Apart from a few character and paragraph styles, the formatting and layout options are pretty limited.
What Word excels at, though, is the process of writing the document. Find & replace is very good, with a useful selection of wildcards. A variety of forms of annotation are available, all relatively easily.

InDesign

InDesign, on the other hand, is designed to create very high quality printed output, with as much typographic and graphical integration as possible, and it excels at this. It's fabulously easy to create inventive page spreads with precise positioning of all the elements. It's a doddle to combine multiple documents as a single book, and link between them all seamlessly in whatever output you want to create.

The drawbacks

At some point in the publishing process, though, you'll need to take input from the authors (usually in Word or one of the alternatives) and put it into InDesign. This is where the problems begin to show.
InDesign doesn't handle the same number of annotation options, and anything that doesn't fit is just dumped out at the end of the document.
Word doesn't allow cross-references between documents, so unless you combine everything into one big lump, you can't end up with anything saying "See page xx", unless you want to manually update them all in InDesign later.

The solution?

Luckily, InDesign has a great scripting toolkit. You can write bits of JavaScript that do practically anything you like with the document, which is what we're doing now. The trick I'm finding at the moment is that you have to work out exactly what you want from the workflow before starting the scripts (which is a good first step for any project) and then build them up very slowly.
These packages may not want to play well with each other, but with a little thought and effort, you can certainly paper around a lot of the cracks.

Consultations.

And, in a break from the (currently) personal projects, here's one that there's actual money in! I'm helping to upgrade my previous company from the Adobe Creative Suite 2 to the current version 5, which involves a whole load of bits and pieces, but one in particular is the updating of the scripts that I wrote to automatically import images into InDesign.

InDesign is a page layout application with a number of advantages.
- it is (relatively) cheap
- it is very powerful
- it has excellent integration with Adobe's other products (particularly PhotoShop and Illustrator)
- it has marvellous scripting support that lets you write scripts to make life just that little bit easier.

It's actually the inspiration behind my first ploddings into JavaScript - I had becoe tired of importing hundreds of images into a book, and decided that it would be much more efficient to have a script do it for me. With a little experimentation, I managed to knock something together that just about worked, and from then on I never really looked back.

So now I get to look back on my handiwork of several years ago with a newly-qualified and practiced eye, and think: "Good grief. Did I really think that this was sophisticated? Yikes!"

I mean, really. In answer to the question "How do I check if a number is odd or even?", I had used the solution: divide by two, convert to string, and search for ".5" within the string. Bad form, old chap, bad form indeed.

So I'm really rather looking forward to rewriting these, both from an efficiency standpoint and to try and make them that much more featured. Obviously, progress will be noted here (where else) as well as what I'm learning.

So far, what I've learned is that the scripting features in the later versions of the CS are massively more advanced that the ones that I was originally using. For a start, it has a complete package for helping to write scripts (though I'm not actually finding it as useful as, say, Eclipse).

Fascinating article: Everything you need to know about the internet

A brilliant article here on the Guardian's website is an excellent summary of quite a few interesting bits and pieces. Most useful is the fairly simple differentiation between the Internet and the World Wide Web. (I wish I'd had that example in my recent exams!)

I'd be very interested to see the book that's coming from this. I'll have to keep and eye on John Naughton's updates to find out when it's coming out.

7th Sea roller; chapter 2

I said in an earlier post that I was planning on writing a dice-roller application for 7th Sea, and that screenshots of the initial interface would follow soon.

Well, here they are!

They're not exactly complete yet, but this should give an example of the overall layout that I'm aiming for. Colours and actual appearance is going to change at some point, after I get a bit of user feedback.

Experimental Ajax, episode 1

The first Ajax-based page is now up and running! Marvellous.

It's a skill-picker for a series of rpg events run in the UK, and this is designed to extend the booking system written by a good friend. Instead of merely typing in a list of the skills that a character has, this script lets a user type in a few characters from the skill's name, and the server then returns suggestions of the skill that was intended.

In a nutshell, this is Google Suggest done all over again. But by me. ;)

Currently the system generates and refreshes a list of buttons with the skill names on, and adds any skills clicked on to a list. (Edit: and now looks just a little bit more professional, keeps easy track of how many selections you've made, and clears the text and suggestions whenever you add a new skill to the list.)

Next elements of the project will include database interactivity: i.e.: it'll pull the information out from a database, and use that to generate help pages on the fly.

The page can currently be found at this location.

Actually up and running!

With a couple of spare hours, I've actually published my "professional" homepage and sorted out a few more of the niggling CSS issues. And beaten the file permissions on the server into shape.

What more could people possibly want? Content? Nah, it's overrated, surely?

Well, that's what's coming next - a few pages to explain the various projects rather than just linking directly to them, and perhaps a continuation of the development of the RSS reader.

With any luck, I'll also be getting database functionality on the server pretty soon, so then there can be plenty of extra features enabled, too.

7th Sea roller

I'm going to be starting a new roleplaying game up in the near-ish future, and I'd like to try and develop some kind of dice-roller to speed up the game, and take away a little bit of the slow dice-rolling that can go on.

RandomRolly isn't quite up to the job - we're playing face-to-face round a table, rather than on Wave, so it's going to have to be a project from scratch.

Ideally, I'd like it to be accessible over web-enabled phones, so that players can use it on them - if they want. Which means it's got to be pretty simplistic, and also universal.

Currently I'm leaning towards a simple web page to start with, probably powered with JavaScript. After that I might aim for a Java application (and then an applet) that I could host somewhere. If all of those work and I'm still feeling ambitious, I might even end up trying to create a full-on Android app (though that would mainly be to see if I could!).

Thoughts:
- I'd like this to be both flexible and expandable, so I'm going to try and really use the object orientation lessons that were drummed into us.
- I'd also like it to be quite user-friendly, so there'll be lessons from the HCI side of things showing up here as well.

Plans:
- First of all there'll be a few screenshots for the interface going up.
- Then, we start planning the data types and overall structure of the app.

More news as it comes...

RandomRolly update

RandomRolly is still going strong: I dusted him off today to have a quick fiddle around with some of the settings.

In particular, I'm looking at the DocumentChangedEvent settings, and how to filter them so that they're only fired when a user actually completes one of the dice commands.

How hard can it be? (part 2)

Answer: not all that hard - mostly!

The feed is working quite nicely, opening up an xml file saved from the feed, reading out what I want it to read out, and outputting it as pleasantly formatted HTML. Fantastic.

Now all I need to do is to figure out how to get it to read the XML file on the server itself. That's proving tricky, and I'm not sure why: the links I'm creating to the file just don't seem to work.

(Edit: as I suspected - it's because the script to get the XML file is hosted on a different server to the one that I'm trying to pull the RSS feed from, so it's a security issue. Hmm.)

(Further edit: and the webserver that I'm using doesn't like using PHP to access files not stored on that server. Trickier & tricker. One solution would be to figure out a way of caching the feed file each evening, so that I could just read from that file instead; but I'm not quite sure how to approach that. Will require further thought, apparently.)

More news later.

How hard can it be?

One of the things that I'd quite like to include on this proposed homepage of professional(-ish!) stuff is an RSS feed from this and possibly other blogs. Obviously, there are tools out there to make that easy (Feed2JS being one of them, and the one that I'm using at the moment).

But I quite like to know exactly what's going on under the hood in these things, so I'm going to have a quick go at putting together a home-grown version of it. How hard can it be, right? I get an XML file (the feed itself) and parse it. There have to be a thousand and five ways of doing that!

Optimism. What a fantastic feeling!

Baby steps

The first draft of my planned "professional" home page is just about up and running. It's not much at the moment: just a page with my name, contact details, and an RSS feed from this blog, but it's a start.

The next step is to try and write my own XML parsing code for pulling in an RSS feed, rather than relying on someone else's!

Happy coding :-)

Kicking off

Yet another development blog! What is it that makes this one different to any other coding blog out there?
Not much.
Apart from the fact that I'm still very much learning how all this stuff works.
My current big projects are:
- Work Schedule: a variant on the classical "Worker Allocation Problem" and a genetic algorithm to solve it.
- RandomRolly: a dice-rolling robot for Google Wave
There'll be more to come, I'm sure. Like learning perl, like all good little coders should!