Tools of the Trade

Language: From the mid 1990’s until at least 2010, nearly all AVs were written in Java, either as applets, using WebStart, or as distributed applications. The primary reason was Java’s portability. Prior to Java, it was difficult to implement for a range of operating systems. Java solved that problem. However, Java’s day is over. Unless you are compelled to develop for an existing Java-based system, there is currently no rational alternative to creating your AV for HTML5. HTML5/CSS/JavaScript implementations run on pretty much every browser, on every operating system, on most tablets, and even many smart phones. The other current web-based technologies such as Java and Flash cannot compete with that.

This does not mean that you need to literally write HTML pages with JavaScript for the dynamic content. You just need to use tools that produce HTML5 output. For example, the OpenDSA project (which has a lot of content as well as AVs) uses ReStructuredText for its authoring language, which is compiled into HTML5. The Google Web Toolkit will let you write in Java and compile to JavaScript.

Version Control: Whether you favor SVN (SourceForge) or Git (GitHub) or one of the other choices, use some sort of version control system to manage your project. Even if you are only planning to write a one-off visualization that only you will work on, once you learn to use a repository (and save to it frequently!), you won’t go back. Over time, you will find more and more uses for it, including keeping track of what you need to do (issue tracker) and managing your project (milestones). And if you plan to go Open Source, this is the best way to distribute your code.

Licensing: Speaking of Open Source… It won’t do anyone any good to have your code if you don’t put a license on it. If you just stick your code out there with no license, then by default it is copyrighted with all rights reserved. That means that they cannot (for example) fix your bugs and post those fixes. Or pass a copy of your project on to their friends. Putting your code under license is necessary in order to give others explicit rights to do certain things. And if you posted your code in the first place, then you probably wanted them to be able to do those things.

Licensing can seem complicated, because there are so many choices and the distinctions can be pretty subtle. So here are basic suggestions if you want things to be easy.

  • If you don’t want anyone to use your code or your program for commercial purposes, then consider the GPL.
  • If you don’t care how people use your code, so long as you get credit and won’t be sued for the bugs, then consider the MIT license.

Using either of these is easy. Just put a copy of the license file in with your project, and put a comment at the top of your source files that references the license.

If those choices don’t satisfy you, then there are a ton of discussions on the Internet about different license options. Start with the OSI OpenSource Licenses list.

Be aware that Creative Commons licenses are not officially sanctioned as "open source licenses" for sourcecode. Most importantly, that means that you are not supposed to use SourceForge or GitHub to host your project, since they both required that your project be licensed with an OSI approved license.

AV Development Toolkits: You will be a lot more productive if you don’t try to reinvent the wheel. There were several Java-based AV toolkits produced when Java was a viable option, but only Jhave and AnimalScript got many users outside of their own developer community. If you are developing in JavaScript (and you should be, see above!), then we recommend JSAV. Look through the OpenDSA AVs for tons of examples of JSAV in use. You will probably find something with features similar to what you want to do.