Mando continues his work on the GENESIS 2 SLI: for some time, the target has been to get the classic Purkinje cell model to work because it uses different types of channels, has a complex morphology, and obviously because its behavior is well described and links nicely with experiments that have been done in the past. It seems like quite soon this model will work, from using the vanilla GENESIS 2 scripts. And for sake of completeness, this model obviously works already for a long time using Neurospaces NDF model files and SSP stimulation configuration files.

Last week I have worked a fair bit on the project browser, such that the morphology analyzer built into the model container can be accessed. This means that a project can have say 10 different morphology files in .p files or NDF files, and your webbrowser allows to examine the number of branchpoints between soma and terminal tips, compute cell surface area and other things. These operations can be applied transparantly on individual morphologies or groups of morphologies. The part to define the groups from the morphologies in the project still needs some work, right now I use a configuration text file in the YAML format.

One thing that became more and more clear over the last few days is that it would be good from a maintenance point of view to merge the project browser and the Neurospaces studio. From the user / installer viewpoint, this means that the Neurospaces project only ships one integrated GUI rather than two, which is obviously a good point too.

Starting to mature

With the Neurospaces project maturing and becoming more useful, I decided to start blogging on tangible progress of the software development. The intent is to give a weekly update, for myself and other people interested and participating in the project.

People somewhat familiar with the project know that we are currently focusing on single neuron modeling. This does not mean that network modeling is not supported, but instead that we are focusing on a complete toolchain that allows scientists to build single neuron models from scratch, explore their behavior, compare the results between alternative models.

Over the last few months, the Neurospaces software toolchain has been used for all the functions mentioned in the previous paragraph by scientists doing scientific research. Multicompartmental models as well as single compartment models have been used, from passive morphologies til active morphologies showing spike frequency adaptation due to the calcium dynamics.

We hope to do a first alpha release early next year. And as said, this alpha release will focus on single neuron modeling.

More to follow.

Application software development

This is what I consider important when doing software development:

1. An application is (often) inherently limited by the technology used to develop the application. So before starting the development of an application, try to assess how flexible the application should be (in the future). Or better, try to anticipate on interfacing, and try to avoid (future) vendor or technology lockin. If interfacing of a technology is a potential future problem -- an example for Java based applications could be the complexity of having to deal with JNI -- then choose another technology. If you have enough money and human resources, interfacing is never a problem.
   
2. A brandnew application is best developed in an organic way. So not first design, then implement, that only works for applications we already know how to implement, and those applications can often be written in one day (so it is a configuration, not an application). An example of a 'configuration' is relational databasing, using Microsoft Studio, the development of such 'applications' is fully automated. If your true application needs good support for workflows, good support for customizability, talk to your (potential) users on a regular basis. Maintaining the appropriate data layering when an application grows, is one of the most important aspects of organic growth. So sometimes, organic style development means splitting one software component into several software components, as indicated by the nature of the data (don't mixin recordsets with workflow configuration data). OTOH, sometimes appropriate data layering is not possible, because there are no efficient data conversion algorithms to do the job (a couple of times I had to develop algorithms to do such conversions -- tricky job). In either case, organically grown applications must always be complemented by good tests, see below.
   
3. An application must be tested on user visible functionality (not: atomic unit tests, I have seen that go wrong quite often). Functional testing and integration testing have several aspects to the inner, like guarding consistency, but also to the outer, like defining workflows and as a guide for user documentation writers. So tests should be self-documenting for the documentation writers. The way I implement this last feature is by using a single set of test specifications, to run the tests, and to convert them to HTML.

I think of these three points as the most important things to keep in mind when developing a (brandnew) software application. I did not talk about backward compatibility, installation, deployment and roll-out. Then, there is obviously also sales and marketing.