All entries for September 2006

September 29, 2006

Skype

Writing about web page http://www.skype.com/

So that I can help out and experiment with Steve’s video streaming experiments, I’ve got a lovely new webcam sitting on top of my monitor (it’s a Logitech Quickcam Ultra Vision).

So far the video streaming stuff is pretty cool, but as we don’t have a University-wide IM system (let alone one that supports video), we are left with the likes of MSN and Skype.

I’ve signed up to Skype now and tried one or two test calls so if anyone wants to try it out, trying calling me (username: kieranshaw)

This is all in preparation for giving my Dad a new webcam when I visit in South Africa next week (yay!) and try to get him to try it out over his not quite full broadband 3G connection they have at the house out there (it’ll probably be rubbish).

Steve’s video stuff will do a great job of allowing recording and video conferencing at set times or in a set chat room, but we don’t yet have an on-demand type solution (except to sign up for Skype or something). Perhaps we should allow people to list their Skype usernames in our email/phone book directories.


September 25, 2006

Getting a project up and running

Follow-up to New online files project from Kieran's blog

Starting a new project is quite intimidating as you start with absolutely nothing. Before you really get going you’ve got to get the following stuff together:

  1. A JIRA project (this is our great bug tracking software from Atlassian)
  2. A CVS project (gotta backup that code)
  3. A basic project structure in Eclipse (need to ensure you can easily build multiple distributions from a single code base)
  4. An Ant build.xml file to build the project…even though there’s not really got much to build yet…there will soon
  5. All the basic Jar files you’re going to need, such as Spring and the like

Once you’ve got the basic project infrastructure in place, you might actually be able to write some code. Some people might say that you’ll have to write a spec first, but that’s not how we do things. We are very keen to get things out the door because we and our users don’t really know what they want until they start using stuff. This works well for us as we’re pretty good at being responsive to our users’ needs and can keep the project nice and easy to refactor and change as we go along.

Being a good boy, I’m making sure that I’ve got lots of tests right from the start. This kind of project is basically all about files so the key thing that it would be nice to get right first time is how to model the file system. It is worth spending a bit of time on the really key parts of the system as you could refactor this later on, but you really wouldn’t want to.

Whilst this very early coding and infrastructure work is going on, it is quite hard to have more than one person working on the project. Once there is a bit more meat to the project someone else can start to get a bit more involved and start something like the file download part of the project. In the mean time it’s worth doing some things that can be done in parallel. A couple of things we have going on in the background are:

  1. The visual/graphic design work is starting to be looked at by Hannah
  2. Looking into how we might implement certain file system protocols is being done by Sarah

Although it’s only a couple of days in, I already have some reasonably good code for basic file management and file upload, but not much in the way of a web interface for it yet, except a basic file upload and file listings page.


September 20, 2006

New online files project

After working on Single Sign On and BlogBuilder and various other smaller projects on and off over the last couple of years, I have a big new project to get my teeth into.

Basically we (me and Sarah) are reworking how members of the University can get at their files over the web and send and receive large files given the restrictions and problems with emailing large files.

The full scope of the project is not yet known so I couldn’t just list all of the features that the system will have. However, our basic goals are:

  • Upload files to a web based file store (and of course then download them so that you can get at them at home easily)
  • Set permisisons on those files (based around our SSO and WebGroups system)
  • Be able to send other users files that you’ve uploaded so that they get a link to the file to download over the web
  • Allow non-Warwick users to send you large files that you won’t be able to get over email

There is a lot more possible detail in these features that we’ve had a think about already, but a lot of the finer decisions are yet to be taken.

We like to do things in a fairly agile way so that we get out working software quite quickly and then rapidly improve it based on testing and user feedback. This means hopefully there’ll be something to see relatively quickly (but don’t expect miracles) and it’ll improve with new versions all the time.

I’ll be writing about our progress here and giving some insights into how projects like this get built here at E-Lab.


September 13, 2006

Implementing the Atom Publishing Protocol

Writing about web page http://www.ietf.org/html.charters/atompub-charter.html

Yesterday I did a deploy of BlogBuilder that includes support for the Atom Publishing Protocol (APP). What this essentially means is that you can use a desktop client, a web service or your own programming to create, edit and delete entries from a Warwick Blog.

We chose the APP because the other blogging APIs out there are all a bit horrible really and the APP is new and shiny and relatively easy to understand and program for.

The implementation was not without its difficulties. For a start reference clients and servers are very thin on the ground at the moment as the spec is not actually 100% complete (although almost there). This meant a fair bit of time just getting my head around how it worked and sniffing traffic to spot what a working client and server actually did when they talked to each other.

In the end, with the help of the Atomic Client, Tim Bray’s Atom Protocol Exerciser and Elias Torres’s public server implementation I was able to get it all working…and here’s how I did it :)

We already used Rome in places for our Atom/RSS feed creation and parsing. It’s slightly tricky to get it to do everything you need to create an Atom Protocol server as you don’t always need to send and receive whole feeds. Sometimes you’ll just want to parse/create a single entry. This leads to code which manually creates or strips the feed around the single entry so that Rome can then parse it properly… blah.

As we’re a Spring shop here, I used a single MultiActionController to do all of the GET/POST/PUT/DELETE functionality that the Atom Protocol needs. You can easily map incoming requests to the right method with something like this MethodNameResolver:

public class HttpMethodTypeMethodResolver implements MethodNameResolver {

    private Map<String, String> methodMappings;

    public final String getHandlerMethodName(final HttpServletRequest request) throws NoSuchRequestHandlingMethodException {

        String method = request.getMethod().toUpperCase();

        if (methodMappings.containsKey(method)) {
            return methodMappings.get(method);
        }

        throw new NoSuchRequestHandlingMethodException(request);

    }

    public final String[] getSupportedMethods() {
        return methodMappings.keySet().toArray(new String[] {});
    }

    public final Map<String, String> getMethodMappings() {
        return methodMappings;
    }

    public final void setMethodMappings(final Map<String, String> methods) {
        this.methodMappings = methods;
    }

}

Then you just set this up to map your DELETE -> deleteEntry() method and PUT -> updateEntry() method and so on…

Another little thing with Rome is that you have to use the Atom specific parts of the API, you can’t just use the generic SyndFeed/SyndEntry classes as they do not convert to/from the exact Atom markup you need. So instead you need to use the Feed and Entry classes in the com.sun.syndication.feed.atom package.

So far I’ve only tested our implementation against Tim Bray’s APE and the Atomic client (which doesn’t send authentication headers when doing POST/PUT/DELETE operations so we could only really try it out with the GET stuff.

We’ll be trying it out against the new Office 2007 Atom client code later on today so it’ll be interesting to see if we need to tweak it a bit more (as I think everyone interprets the as to be completed standard a little differently).


September 2006

Mo Tu We Th Fr Sa Su
Aug |  Today  | Oct
            1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30   

Tags

Search this blog

Most recent comments

  • One thing that was glossed over is that if you use Spring, there is a filter you can put in your XML… by Mathew Mannion on this entry
  • You are my hero. by Mathew Mannion on this entry
  • And may all your chickens come home to roost – in a nice fluffy organic, non–supermarket farmed kind… by Julie Moreton on this entry
  • Good luck I hope that you enjoy the new job! by on this entry
  • Good luck Kieran. :) by on this entry

Galleries

Not signed in
Sign in

Powered by BlogBuilder
© MMXIX