I thought I would post a quick update on what the LocalView team have been up to over the summer, partly to give some sneak previews of new functionality and templates we’re working on, and partly to give a glimpse of our software engineering process.
New Stuff
We’re just adding the final polish to our next release of LocalView Fusion, which will be known as Service Pack 5. It actually contains some pretty big changes:
- New content type: we’ve extended the types of content that can be managed and published through the LocalView platform, to include Geoprocessing Tasks. We’ve done this to expand the range of functionality that LocalView templates can support, and we’ve tied the GP Tasks to the Survey template so that they integrate a bit more tightly.
- New functionality – for example, we’ve added the ability to switch basemaps in GeoWindows (as long as the other basemaps are in the same spatial reference system).
- New templates: the LVF development team have been working a lot with jQuery and the Compact API, and now consider this to be the best option for tight integration for example when embedding maps and gazetteers within CMS templates. So we’ve added two new “Embeddable” templates that come as both standalone GeoWindows or jQuery plugins. The plugins will load their configuration direct from LVF, so tightly-embedded CMS maps and gazetteers can now be updated by LocalView content publishers without a developer having to update the implementation. We’ve also added a template based on the ArcGIS Viewer for Flex (version 2.3) – extended to include our own Legend, Printing and Gazetteer controls, plus a query builder on top of the editing, geoprocessing, and drawing widgets.
- And of course, a healthy dose of Performance improvements and bug fixes.
A screenshot of the new embeddable map template, with a “Midnight Commander” Open StreetMap basemap.
We’re on target to get everything polished and tested, and the product documentation updated, by late September.
How LocalView is made
We have a pretty small team making LocalView, usually about 4 people. We rely heavily on automation, for example we use Cruise Control.Net to run our automated build servers so that we always have installers available to test any changes we make. We run our projects using Scrum, an Agile methodology that focusses on productivity, making small incremental changes, and delivering fully tested, functioning software to a series of short (2-4 week) deadlines.
Under the hood, there is quite a lot that goes into making LocalView: about 25 Visual Studio solutions get built, we make 3 different installers (32 bit, 64 bit and cloud) using Wix, and support 4 databases (Oracle, SQL Server 2008, PostGres and for our multi-tenancy environment, Amazon RDS), which requires a battery of virtual machines for each combination of operating system, ArcGIS version and database that we need to test. And then there are the browser versions….we have no “magic bullet” for testing in multiple browsers, we use Virtual Machines running Windows XP for IE6, IE7 and IE8, and all the team have the latest versions of Chrome and Firefox, as well as IE9, on their laptops.
We use Team Foundation Server for source control, and we currently manage the codebase in three branches: mainline development, the last major release (for hotfixes), and a cloud branch. Breaking changes go into the mainline, or a new branch as a release approaches (which then becomes the mainline) but the release branches have to stay stable – we manage changes by merging code between the mainline and release versions.
What’s Coming Next
Because we work in short sprints using Scrum, our priorities can be set and changed with very short notice. So I can never say what’s coming in the next release until we get close to finishing it. I can say that we will be starting work on it in October though!