So, the hectic pace of school and life has left this blog seriously lacking. That's ok though, because this shameless plug comes with a reminder that (for me) that this blog exists, and some ideas for new posts. The plug: Wosaic.
Yea, I think I've plugged this already, but today (Sunday) marks the first official "beta" release for our project. It's pretty exciting, as it represents a couple months of hard work and problem solving, not only in the domain of programming problems, but also project management and software design. Maybe in the course of this plug, we can get some insight from the project's ups and downs, and how to manage a project.
This is a must. Anyone who's done any kind of serious coding within a group, knows this as common sense. Luckily for me, this has become my intuition as well as the intuition of my project partner, Scott. However, living in the world of undergraduates, it's easy to come across people who have not been exposed to such situations. So, for anyone not aware: verison control is crucial. It allows you to organize your code such that it is available to all your project members, is up to date and synchronized with your latest changes, and serves as an archive of your code, should something go terribly wrong. Typically the flow is something like, check out some source code, make your changes, and commit them. For instance, if you wanted to toy with Wosaic (say, add a new source plugin, which is nice and easy to do), you could check it out with the following svn command:
svn checkout http://wosaic.googlecode.com/svn/trunk/ wosaic
Subversion (SVN), for example, keeps track of the files that you change and will recognize this when you are ready to commit your changes. Committing simply adds your changes to the 'trunk,' or the rest of the source code. Now when other people checkout, or update their code, they will get your changes. Neat, huh? Not only is it neat, but it is an excellent way to stay synchronized with your project members.
No project is perfect, but good projects can track their imperfections and schedule fixes. This is where having a database of bugs is useful. The idea is that someone can file an issue, or bug, document it, and assign it to someone. This gives the developers a clear list of the things they have to fix and how to reproduce issues. Not only is it good documentation, but having a glaring list of bugs helps remind project members about what needs to be done, and ends up making people more productive. I mean, let's face it, nobody wants to admit that their project has bugs. One resource people rave about, though I haven't used it myself, is Bugzilla. This has the advantage of being free, fully featured, and developed by the open source demi-gods of Mozilla. On Wosaic, we used a simple Issue Tracker that came with our Google Code site.
Another useful thing to have is a website for the project. It's useful to aggregate releases, documentation, and discussion in one spot. For this, we used Google Code. This was an invaluable resource, as it sets up a nice SVN repository. Additionally, it provides a wiki, and issue tracking. The wiki is perfect for documenting features and project design. Having the ability to get feedback from users is also a valuable tool... assuming, of course, that you have users.
This was probably the most interesting part of developing the Wosaic project. Being an open source project, Scott and I wanted to make it accessible to all platforms. Naturally, we chose to implement our idea in Java, since Java prides itself on striving for platform independence. This is all well and good, but you still need to sort through the small nightmare of different JRE versions, IDEs, building jars, automating the build process, and producing 'native' applications for multiple platforms. One tip for Java developers: decide what JRE to use right up front. Say, "Hey, let's be compatible with Java 1.5 and up" and stick to it. This is important, regardless of the language, as there are and will continue to be revisions to languages and their compilers. Java is interesting because it requires a virtual machine to run, which gives it the platform independence, but lacks the feel of, say a native OS X (or Windos, or *nix) application. The ability to create executable jars makes the experience close, but not quite there. We resorted to some other tools to help us out, such as Launch4j for windows, and Apple's Jar Bundler for OS X.
Such tools are nice for releases, but for day to day development, there's nothing that beats a good Ant script. This is very similar to a Makefile, for those lucky enough to be acquainted with Makefiles. For others less (or more?) fortunate, this means that with a simple command, 'ant' you can build the source of your project, run it, generate documentation, and brew a cup of coffee. Well, maybe you can't get coffee out of the deal, but just about anything else you might want to automate with regard to the build process can be automated with Apache's Ant. It's pretty sweet, because an ant script just boils down to an XML file that specifies various targets and tasks. One cool thing about this is, if you are a documentation freak like me, you can whip up a little XSL stylesheet and transform this xml into a website that details your build targets for anyone to view at their leisure. You can even use ant to perform the transform (
Phew. Well, that turned out to be more substantial than I anticipated. There are plenty more lessons to be learned, but I think we've hit on some important point here. Remember to check out Wosaic's project site, and grab yourself a copy of our source (or one of our sweet binaries... Mac users note the handy disk image). Until next time, peace!
