Last month, 52°North staff visited the Schloß Eringerfeld for our yearly retreat. We wracked our brains from thursday through saturday, targeting 52°North road maps and aligning common goals and strategies for 2013. We braved the cold and snow to discover hidden archery talents and topped off the event with a medieval banquet in the castle dungeon! All in all it was a very informative, productive and constructive event.
Archives for March 2013
This is my first blog in a long time. It will be the first in a potentially long series and the subject will be quite different from that of my series of blogs in 2011/2012. In 2011/2012 I mostly wrote about functionality in ILWIS, i.e. the development of the new map window and all the visualization stuff that spawned from it. I probably will still write about that (work never stops), but my main focus will now shift to programming – programming for ILWIS NG (or ILWIS-Objects as people suggested to me).
In the first blog series, I tried to explain what changed in the 3.8 version and why it was so fantastic (!?). I consider that done now. Sure, new things will still be included in 3.8 and old things will be improved/resurrected or whatever, however, it is unlikely that you will see such sweeping changes as the 3.8 introduced. Since 3.8.3 is now more or less finished and a big reference document about the map window has been written, it is time to shift direction.
Last year I mentioned that a decision had been made to redesign ILWIS from ground up in order to align it more closely with current developments in the GIS/RS and IT world in general and of course the goals of 52°North. At the end of last year, after a number of sessions about the design goals, principles, documentation and other related subjects, I started with a base implementation of the low level stuff for ILWIS-Objects.
My new blog series will focus on why the programmers do certain things, which choices are made and how some mechanisms work. Why do I spend time on it? Well, there two reasons.
First of all, it is immensely useful to be forced to write your ideas on paper (ok, screen). It forces you to clarify your ideas and to make a defensible case for it. As long as the ideas remain in the informal space that is your mind, it is easy skip logic and muddle along. It is always surprising to me how people (including myself) are able to support remarkably incomplete notions and still have the feeling that they “have thought things through”. Writing things down shows the gaps in the logic, the things you missed. No, it is no panacea. Stupid things remain stupid even if you write them down, but at least others may point that out to you.
Secondly, I hope to interest others in the process and maybe even motivate them to participate. Redesigning and rewriting ILWIS is a huge task that will take some time. Will it be successful? I don’t know. I am optimistic about it, but I don’t fool myself about the magnitude of the task. So it will be useful if others feel motivated to help in this process. Help could be useful at many levels – at design level, at requirements level, at documentation level and certainly at coding level!
We will see how this pans out. For us at 52°North and the ITC there is a business case for doing this work, so it is not a short term hype that will ebb away after a few months. It will continue, but the pace is dictated by the availability of resources.
The next blog, next Monday, will be about the business case for ILWIS-Objects.
In the meantime, on a more practical and short term level
- Ilwis 3.8.3 will be done this week and put up on the download site. I hope it is there this week but it might also be next week.
- It will be accompanied (as a separate download) by a document (~60 pages) that describes the new 3.8, map window. Maybe, at a later date, I will include it in the help. It is rather large (many illustrations) and I found it a bit doubtful to significantly increase the size of the ILWIS download for a piece of documentation. But I could be mistaken in this.
ITC is a partner in the European Marie Curie Initial Training Network “CHANGES”. The CHANGES network will develop an advanced understanding of how global changes (related to environmental and climate change as well as socio-economical change) will affect the temporal and spatial patterns of hydro-meteorological hazards and associated risks in Europe; how these changes can be assessed, modelled, and incorporated in sustainable risk management strategies, focusing on spatial planning, emergency preparedness and risk communication.
One of the main components of the project is the development of a Web-based Spatial Decision support System to analyze the effect of risk reduction planning alternatives on reducing the risk now and in the future, and support decision makers in selecting the best alternatives. ITC is responsible for the development of the data analysis modules within the SDSS.
Preliminary Remark: This blog post targets Open Source developers and will basically cover technical details.
Automated Integration Testing for Java Web Services is an important pylon to ensure the stability of a web service and in particular its internal workflows. It is a very convenient way to ensure that the server is reacting just as expected in a set of pre-defined situations in terms of responses to specific requests. An easy way of defining integration tests is to provide a certain set of fully-defined requests (POST, GET, …) and corresponding responses. However, if you also are maintaining a client framework or library dedicated to that service, you are in the sweet situation of being able to kill two birds with one stone:
End-To-End Client-Server Integration Testing.
This is the first of two blog posts on End-To-End Integration Testing. For now, I am focussing on the Maven project setup. The follow-up will provide some insights on the actual implementation of integration tests – the client side.
In the following I will try to provide a guide on how to incorporate an integration testing component into your existing Maven-3-managed web service. I will use the 52°North Sensor Event Service (SES, server component) and the 52°North OX-Framework (OXF, client library) as a hook for the following sections. Knowledge of the following topics is helpful for understanding the article:
We will cover all needed steps to enable integration testing in your web service project. In particular, details on preparing a temporary webapp, reserving network ports dynamically, bootstrapping a servlet container and the actual execution of the integration tests will be illustrated.