Skip to main content

Ask the Institute

Have a query about software? The Institute can help! Does your software-related research need a kickstart? We can help with that too! Orginally called the AskSteve! blog, this service has been moved to our main site and now includes not only Steve Crouch's considerable expertise but advice from the rest of the Institute and its many experts on software and research. So, if you have a question, contact us now.

Continue Reading

AskSteve has covered quite a few topics on general software development, but I recently received an interesting query about portal-based development in particular:

“We’ve been developing sets of portlets which gather information from different sources, run simulations and display the results in a variety of map and graph based methods. These have been developed using the Sakai portal infrastructure but we’d like to be able deploy the portlets in LifeRay and other platforms.

What should we be aware of when trying to port to another portal infrastructure, what techniques can we use to ensure everything is working correctly, and where can we find out more about which portal platforms we should be testing deployment against?”

Since this is such an interesting question, and one that deserves and requires a comprehensive response, I decided to write a guide about it. In short:

  • JSR-168/JSR-286 compliance: this is the key. Ensuring compliance with the JSR-168/286 specifications, which provide a common development model for portlet development, will greatly assist your portlets in running across a number of portal…
Continue Reading

Last month Mike Jackson and I were tutors at a Software Carpentry event at Newcastle University. If you haven’t heard of the Software Carpentry project, it’s a great idea. It teaches scientific researchers a core set of useful, software-development skills, and uses short, intensive workshops followed by self-paced online tutorials. Anyway, during one of the practical sessions, the issue of when to optimise code came up. In other words, at what point should you optimise your code to make it run faster?

At a previous Software Carpentry course run by it’s project lead Greg Wilson, Greg introduced a great page that presents three rules of optimisation (I’ve…

Continue Reading

It’s such a joyous time becoming a parent! Your software’s been conceived and is now going through an exciting and healthy period of development. You’ve fought your way through bouts of sickness and the odd craving (I’ll write it in… Malbolge*!!!), but everything’s on schedule. But wait… the delivery date is next week! Stay calm, remember your breathing and follow these top tips for delivering something wonderful into the world.

1 – Always release software with a licence – without a birth certificate, no one will know who the parents are.

2 – Waiting isn’t going to make the delivery any better – a late delivery can be as difficult as one that is premature. If things are taking too long, it can be best to induce labour.

3 – Version your software releases – things are going to get complicated if you don’t distinguish between who’s Sr. and who’s Jr. (Michael Jackson’s a bit of a visionary in this field, having included a version number in his son’s name “Michael II”).

4 – Provide contact information – make sure your software has a name tag just in case there’s a mix up at the repository.

5 – Download and test your release – on the big day, you should make a test run so that you’re happy that there’ll be no complications (pack an overnight bag).

For a slightly more, er… 

Continue Reading

We mention things you should do when developing software quite a bit. But we were asked an interesting question at the Software Sustainability Institute’s Collaboration Workshop this year: what things shouldn’t you do when developing software?

Come on, there has to be some. And there are – many! But let’s focus on five of the big ones…

1. Don’t develop code you can’t maintain

This has got to be high on the list. Code can turn into spaghetti from out of nowhere, and it’s always worth avoiding. Best to get into good habits early on in the project!

2. Don’t make your software difficult to build and install

We’ve all experienced this with other people’s software. If user’s can’t install it, they’ll move on – perhaps to a piece of software that has inferior capabilities. Why not make it easy, and simplify (or even automate) the build and install processes that are so often fraught with peril?

3. Don’t keep the source code to yourself

If you hold the source code in only one place – your development machine – and you lose it, you only have yourself to blame. If your development machine is your laptop, it’s even easier to lose. Avoid the pain and use a suitable source code repository from the outset!

4. Don’t forget documentation

Writing documentation is boring, but it is necessary. It’s…

Continue Reading

At the SeIUCCR Summer School in September I was asked a blinder of a question:

“How do I choose sustainable software for my project?”

Assuming an open-source context for this question, there are many things worth considering. It could be that the functionality of your software needs extended. Not wanting to re-invent the wheel, you’re looking for an appropriate library to provide that functionality. Or perhaps you have an analysis tool that outputs a certain data format that you need to post-process into an image. What should you look for in software?

It’s easy to reach for the first software package you come across that seems to do what you want. Perhaps it’s already installed in your target platform, or it’s the first thing you found on Google. But picking the wrong software can have expensive consequences if it doesn’t do everything you want or, even worse, development and support comes to a stop!

Taking a little time to make an informed choice is time well spent. So what questions can you ask about the software to find out if it’s suitable?

First off, and…

Continue Reading

Security in complex systems is always a tricky business. Consider production Grid infrastructures as an example. The intricacies of establishing working trust relationships between the users and the infrastructure, and between the systems themselves, is a mammoth task. Solving problems with such systems is also very tricky, as I’ve previously found when developing EU-wide Grid interoperability demonstrators of open standards. They appear like dragons: huge, daunting, and difficult to defeat.

The UK National Grid Service asked Steve (well, the Institute really) to help them out with their SARoNGS system. Our arrangement was very effective. The Software Sustainability Institute provided development effort for the investigation, whilst the NGS fixed issues and offered the in-depth systems knowledge that only they could provide.

So what is SARoNGS all about? The Shibboleth Access to Resources on the NGS service greatly…

Continue Reading

“Programming is 10% science, 20% ingenuity, and 70% getting the ingenuity to work with the science.” – Anon

Software developers working on an academic research project will, unsurprisingly, do just that: develop software. But to what extent should a developer care about the research field in which they work? This and other related questions have popped up a few times recently, and this theme also permeated a few sessions at our Collaborations Workshop back in March.

The first thing to realise is that researchers and software developers both use long words, but they are generally different long words. Each group comprises experts (in their own discipline), but each group has its own language. For example (with elementary translations in [ ]) …

Researcher: Can you imagine what we could do with a more timely lattice energy landscape minimisation for these carbolyxate salts!? [If only we could do our calculations faster!]

Developer: Nope – does it have something to do with matrices?

Developer: Did you see that amazing multi-threaded C++ app for…

Continue Reading

One of the big problems with research, particularly in these austere times, is finding the money to travel to all those great conferences. You miss opportunities to present your work, and you can miss out on discovering first hand what is afoot in your research field.

The great news is that if you use software in your research and you have a good understanding of what’s happening in your field, funding is available from the Software Sustainability Institute. Regardless of discipline, the Institute will pay a number of researchers £3000 a year – in return for keeping the institute up to date on the latest developments in the researcher’s field. This helps you with disseminating your greatness and keeping up to date, while allowing the institute to build a network of Agents to understand which fields most need help.

There are some compelling benefits to consider:

  • Up to £3000 a year to attend the conferences and events that you want to attend
  • Your advocacy will ensure that your field benefits from the best support for software development
  • Add world-leading researchers to your professional network
Continue Reading

So, continuing on from Part 1 of Developing software in an open way, let’s answer the last two aspects of the question from Alex Voss…

“Should I make all my source code available from the start to attract potential collaborators and to solicit contributions or should I keep it close initially to avoid getting locked into early solutions that have been taken up by others?”

You will have project goals to fulfil, so I think it’s always a good idea to start development internally. This means you can put your software firmly on the path to meeting your own project’s goals. When and how external involvement comes into play will depend on the project.

Firstly, it’s important to consider how you want to govern your open-source project. If you are worried about becoming locked-in to a solution chosen by others, you should stay away from the democratic/meritocratic systems, because you lose some control with these approaches (you can be outvoted). A benevolent dictator approach means that you alone have the final say on which contributions to include into your software – and which ones to exclude. You gain control, but benevolent dictators have to put in a lot of work…

Continue Reading
Subscribe to Ask the Institute