So much for updating this blog more regularly. I guess this blog simply doesn’t rank high on my list of priorities. Work has been, for lack of a better word, intense! Fortunately it has been so in a good way. There has been no shortage of challenges, most of which were technical, challenging and generally interesting. And the really good news is the work continues.
From a personal projects perspective, I’ve had to pick and choose which to run with. Failure to do so would have left me with a hollow list of ideas that never amounted to anything beyond entry level academic exercises. I have played around virtualization some early in the year using OpenVZ. I like the results, but have found it was not the good bet for my future use, as my work has started to turn to VMWare and Solaris Zones in a big way. Shortly after my post in February, I was able to complete an upgrade of the Django based websites. I am still quite pleased with Django, though I’ve not been keeping up to date on that scene very well.
I’ve spent most of my free time focused on Scala Bazaars (sbaz). I’ve been improving the sbaz code base in earnest only since June or so. I am a bit ashamed it took me so long. This is in part due to my needing to better familiarize myself with the existing code. The bigger reason was lack of vision, and therefore unsure direction. I spent more time contemplating what to do instead of doing. Sbaz has lost ground as a tool used by the public due to a variety of reasons. First and foremost has been the waning development of both code base and public repositories. I am attacking the former head on, and the later soon after. A more basic question is what use cases we should target. Most prospective users today are developers who have other tools that are more deeply integrated with IDEs, build tools, version management, etc. Should sbaz adapt to compete in the development space? Sbaz was modeled after the Linux package management tools, and I’m not convinced such a design can satisfy both the flexibility and consistency needs of developers unless we can establish some large scale release process similar to Linux distributions. My next post, if it happens within the next month or so, will likely be ramblings around some of these thoughts, and how I would like to see a sub-community start to form around sbaz.
Ultimately, I decided on a path of incremental improvements to existing functionality. This way I could contribute as little or as much as my existing family responsibilities and increasing work commitments would allow. My primary goals this far have included:
- Update to scala 2.8 and eliminate all compile warnings, including Java deprecations
- Introduce no backward incompatible changes (beyond minimum Java5 per 2.8 upgrade)
- Improve dependency audits to prevent a broken managed directory from ever appearing
- If an audit fails, make it clear to the user why
- Keep the user informed (specifically when downloading)
- Expand the body of automated testing
- Improve Windows support
These are still works in progress, but there has been good progress made. I have also added a few features like asynchronous downloads and support for pack200, the latter I’m amazed I haven’t seen used more. I suppose the scala requirement of java5 or later makes such support easier..? At the time of this writing, there is still more to be done; however, the code base isn’t far from being ready for the next major distribution release of Scala. I’d be working on it now if I wasn’t away from my primary development machine.