NetStereo is a server which runs on a computer with a sound card and plays music, primarily MP3s. What makes the NetStereo server special is that it accepts commands from remote clients. The server is written in Java, and it features the ability to plug in various methods of playing songs (currently mpg123 and the Java Media Framework) and various methods of communication (currently network and serial port). Currently available clients include a Java client which uses the Swing toolkit and a Palm client.
Distributor is a software TCP load balancer. Like other load balancers, it accepts connections and distributes them to an array of back end servers. It is compatible with any standard TCP protocol (HTTP, LDAP, IMAP, etc.) and is also IPv6 compatible. It has many unique and advanced features and a high-performance architecture.
nVentory is a Ruby on Rails application to manage inventory in multiple data centers. It can manage server functionality assignment, customer/server assignment, racking, and more. It can track which servers are doing what, and where they are in your data centers. It allows you to visualize server locations and rack space with GUI tools.
> It went from I would think about using
> it to I wouldn't. Ruby? RoR? What bad
> choices you have made.
I know sysadmins tend to avoid shiny and new (generally for good reason), but neither Ruby nor Rails is particularly new at this point and Ruby at least has good potential for system administration tools. Perl was my language of choice for 15 years. Ruby shares a lot of syntax with Perl, but has a functional object-oriented programming model. I'm tired of waiting for Perl 6. :) The tradeoff is that the library of 3rd-party Ruby libraries is nowhere near as well-developed as CPAN. Having ported around 5000 lines of Perl to Ruby I find that the resulting code is generally shorter and easier to read, except where you run into a shortcoming or lack of a 3rd-party library.
It does mean that as an etch user you have to write bits of Ruby for your etch configuration scripts, but plenty of non-Perl developers managed to get what they needed with the previous versions because the configuration scripts tend to be short and simple and easily built up by cut-n-paste from other scripts.
I understand that Rails seems out of place in this context, it wasn't the first thing I considered. But after looking around at XML-RPC and other web service libraries I decided that using Rails as a simple CGI layer made the most sense, given that I develop etch alongside nVentory (an asset and configuration database), which is a heavy user of Rails. Developing etch on a separate web service platform didn't make sense. Etch does not make heavy use of the Rails platform, nearly all of the server code is in a generic Ruby library with just a minimal hook into Rails.