See you there!

I'd never heard of VPS, but it seems to be all the rage in the web hosting business--and rightfully so. VPS gives you root access to your own virtual Linux machine, so you get just about all of the control and flexibility of running your own physical server: you can add your own Apache modules, install new languages (like Ruby!), run a J2EE app server, provide IMAP access, schedule jobs, create users... whatever.

Unlike running your own physical server, though, VPS is dirt cheap. We're talking $20/month cheap, compared to $10 for shared hosting and, say, $100 for a dedicated server (and that's not counting the cost of the server itself!). I'm guessing most VPS hosting companies deploy dozens if not hundreds of virtual Linux instances on each skinny little 1U server; the incremental cost of each additional VPS account follows the economies of shared hosting, not the economies of dedicated servers.

The downside, of course, is that you don't get a 2.6GHz of that Xeon and all 4GB of fancy ECC RAM all to yourself--you have to share it with all the other customers on that particular server. Really, though, how many sites need more than 2% (on avg) of a modern server's CPU time?

Every VPS provider I've seen also throws in friendly web-based control panel software that make it easy for you to play webhost to your friends or customers--just a few clicks through a wizard interface and the software automatically configures a new virtual host in Apache, creates the appropriate FTP, shell, and e-mail accounts, and makes the relevant changes to the VPS provider's DNS servers. Luckily, VPS providers generally don't charge you per virtual host, and many don't set any artificial limit on how many virtual hosts you can have.

As of tonight I'm running Resin (with jikes and JDK 1.4.2) on my VPS. I'm planning to run an rsync daemon for backup purposes. mod_python came pre-installed, but not mod_ruby, which I'll have to remedy. It still amazes me that I can say all that about a $20/month account!

Frankly, I don't see why any serious web developer would get a traditional web hosting account these days--VPS gives you so much for so little, it's too good a deal to pass up!

Thanks to these libraries, you don't need to have a very deep understanding of cryptography to begin using it to help secure your applications. You don't need to understand how or why one-way hashing or asymmetric encryption work; you just need to understand where and why you would want to use each one.

If you're a Java or .NET programmer and you're unfamiliar with (or intimidated by) cryptography, take a look at this intro at MSDN. Practically every serious developer should have an understanding of these concepts, especially since the tools are already sitting there in your classpath or GAC, just waiting to be used!

Several other toys have caught my eye lately. One is the Echo Indigo, a CardBus sound card that supports 24/96 playback and has incredibly good specs. At work, I've got my poor 580's plugged directly into my laptop's headphone jack, and it sounds terrible--very audible line noise and distortion. Seems like the Indigo, on the other hand, would do justice to even very high quality headphones. At $130, it's even a decent value, though I'm not sure I personally could justify buying it over the cheaper, less elegant alternatives [1, 2].

The next is VIA's new(?) P4-ITX motherboard, which supports most P4 or Celeron processors and includes S-video out, USB 2.0 ports, optional FireWire support, network adapter, and a PCI slot, all in an area smaller than 7" squared! Stick it in one of these and you've got the start of a book-sized PC with some serious grunt.

And finally, in the "Stuff I'll Never Own" category, Meridian, one of my favorite hi-fi manufacturers, has launched the G Series line of components--and wow. These things are drop dead gorgeous. The G Series is a step up from the already expensive 500 Series, which means these components are well into "Should I buy a lightly used BMW instead?" range. (Scroll to the bottom of this page for the damage.)

Now my commute is being spent learning Lisp, via Paul Graham's ANSI Common Lisp. So far it's absolutely excellent. Paul Graham must be one of the most articulate voices in computing. Everything I've read by him (check out his website) has been incredibly well written: interesting, clear, concise, and generally pretty convincing. So far ANSI Common Lisp is the most readable and enjoyable programming language book I've come across, eclipsing my previous favorite: Programming Ruby. The Lisp community is lucky to have this guy as an advocate.

Lo and behold... I actually succeeded this time! I've finally got my own Linux mail server: hush.joecheng.com. (It's called "hush" because it's a near-silent machine, using a tiny VIA EPIA board and a very quiet Seagate Barracuda hard drive.)

Unfortunately, my ISP blocks all traffic on port 25 unless it is going to their mail servers. So I actually have all of my mail delivered first to a POP account with my webhost. Hush polls the POP account for messages and then serves them up via IMAP. This is exactly the setup I wanted to support with my own Poorman IMAP server.

To anyone who is familiar with Linux administration, the following will sound like a plain-vanilla ho-hum mail setup. But I suspect it might seem a bit like a Rube Goldberg machine to anyone from the Windows camp! Here are all the programs involved.

1. fetchmail - Polls the POP account at my webhost and delivers any mail it finds to localhost.
2. sendmail - Accepts the mail for delivery and drops it off with my local account.
3. procmail - Filters all mail received by my local account (I'm using it to keep separate mail folders for each mailing list I'm subscribed to), saving it to folders in my home directory. This is the "traditional" Unix mailbox system.
4. imapd - Serves up IMAP sessions to mail clients, optionally over SSL.
5. iptables - The built-in Linux "firewall". Port 993 (secure IMAP) was being blocked by default, so I had to figure out how to unblock it.

Luckily, my Red Hat 9 machine already had all of these programs installed! But I still needed to learn how to configure each of the services.

At first I was a little irritated that so many programs in the chain. But really, this is what the Unix philosophy is all about: chaining together small programs that each do one thing well. The downside is having to learn a ton of small programs. The upside is the incredible amount of flexibility and power you get in return.

I realized that configuring Linux has more in common with programming than it does with configuring Windows. With Windows, you can just click and hunt around until you find the checkbox you're looking for; if you have a general idea of what you're trying to do, it doesn't generally take long to figure out how to do it. With Linux, you really have to spend some time learning the program you're about to configure. Each program has its own set of config files; you probably wouldn't even be able to find them without the docs, much less figure out the configuration syntax. So before you even start touching anything, it's best to take a breath, sit down with a tutorial or the man page, and really spend some time learning about  and understanding the program. As a programmer, you wouldn't want to jump in and start playing with the Java 2D API, calling different methods until things work; it's the same with configuring sendmail.

I'm not just trying to present a familiar metaphor here. Traditional Unix programs really are more like APIs than like end user programs on other platforms, and using the shell is very much like interactive programming. So if you're starting out with Linux, understand that for good or ill, you must give system configuration tasks the same kind of attention and respect that you might give programming tasks.

With that in mind, I spent a few nights learning and configuring and learning and configuring. In most cases I only needed to add or modify perhaps a single line to a config file, and often the exact thing I was trying to achieve was specifically addressed somewhere in the documentation. (These programs have been around for a long time; anything you could want to do with them has probably been done thousands of times before.) So this time around, there was very little trial and error involved. I was able to make each change with confidence, and most of the time, it worked the first time.

Fortunately, after all that, it was very much worth the trouble to get it all working. I'm happily using Mozilla Thunderbird 0.4 at home and at work, and I have a consistent view of my mailbox wherever I go thanks to IMAP. I don't have to add mail filtering rules on both clients. I can be sure that when I delete a piece of spam, I'm not going to see it again when I log in from the other computer. And it's all extremely stable, secure, and... free!

The first talk (by Dana Moore and Bill Wright) presented Jabber as a way to control distributed software agents. The user fires up a Jabber client and his "buddy list" consists of all the different agents that are floating around the system. He can send chat messages to interact with each one, getting info such as "help", "status", or directives such as "kill cpu" (their project involved agents that attack a distributed system to see how it holds up).

I really like the idea of using Jabber to communicate with "headless" software in general. The usual solution these days seems to involve embedding a web server into the program, or maybe telnet--and that's if the software has a user interface at all. More commonly, input is restricted to config files, environment variables, and command line switches, and the only output you get is a logfile.

Embedding a Jabber client in your program is much lighter weight than embedding a web server: all you need is a client library (the Smack library for Java, for example, weighs in at 124KB, while Jabber4r for Ruby is less than 75KB) and maybe a thread to poll for messages (I assume--I'm not too familiar with the protocol yet). And sending warning or error messages to an administrator through Jabber is much more likely to get attention than if the messages are simply written to a logfile.

I'll refrain from going into any more detail until I've tried this with one of my own projects. If and when I resume development on my IMAP server, I'd like to use Jabber as the interface to add/remove users, reset passwords, and other administrative tasks.

Take Python and Ruby, which are very similar in many important ways: interpreted, dynamically typed, "object oriented". Check out these two snippets:

# Python code
def test():
  print x

x = 1
test()


# Ruby code
def test()
  print x
end

x = 1
test()

Even though the code looks almost identical, you get two very different results. The Python code prints 1; the Ruby code throws the error NameError: undefined local variable or method `i' for main:Object. The reason for this is that Python scopes are dynamic and Ruby scopes are static. Depending on your programming background, you may find one or the other very hard to get used to!

This is just a simple example, but it illustrates the kind of subtle differences that make one language "feel" right to some people but not others.

A more fundamental concept I've learned about is "programming without side-effects", which seems to come from the functional programming world. Programming without side-effects means that when you call a function, the only variables that matter are the inputs, and the only effect of the function is returning a value. In other words, given a set of inputs, you must always get the same answer--the answer can't vary over time, or based on the state of a database record, or whatever. It also means the function must not change the state of the world at all, so calling or not calling the function cannot change the behavior or result of some other function.

Why put these restrictions on functions? What's wrong with side-effects? Well, it turns out that if you can count on a function to be side-effect free, you can be less careful when using it. You can cache results without worrying about them becoming stale. You can skip executing it without having to prove the program is still correct. There is guaranteed to be no coupling between one function call and any other function calls that come before or after. For example, imagine your program contains this statement for logging:

if (DEBUG)
  print("DEBUG: Window handle: " + getHandle(window));

Let's say the getHandle function is not side-effect free. On the contrary, it will create a handle for the window if one does not exist. You should be nervous about removing this logging statement--what if the next line of code implicitly assumes that the window already has a handle? But if getHandle could be guaranteed side effect free, there is no way removing the logging call could change the behavior or your program. (Well, actually print itself is not side effect free.)

That's not to say I'm going to go to work tomorrow and start programming without side-effects; far from it. While there are functional languages that encourage or even require your code to be completely side effect free, it's hard to imagine trying to achieve that in a real world Windows app written in C#; most objects are inherently stateful. But recognizing the value in programming this way will help me write better libraries by avoiding side-effects where possible.

The bottom line is that there is great value in studying different programming languages, even if you never adopt them as your own.

One thing about the book is that it's somewhat dated: the edition I read was ©1987. However, the principles and techniques taught in the book are still very relevant today. I really enjoyed this book and I imagine most hardcore programmers would too.

I've also just purchased Programming Language Pragmatics by Michael L. Scott, and I can't wait to get started on it. It's a very large and imposing volume that seems to give a pretty comprehensive treatment of the design and implementation of programming languages. Parsing techniques, type systems, variable scoping, instruction-level optimization, it's all in here. There's also a chapter on functional and declarative languages that should be interesting.

Hopefully I can keep my brain from exploding.

I've got some ideas about how to create a nice high-level C# binding to this. You should be able to take a marshal-by-ref object and just make one API call that says "make this available to everyone on the network."

Let's compare this idea to making an object available to .NET Remoting clients. Start with the following class:

public class MediaLibrary : MarshalByRefObj
{
  ///
  /// .NET Remoting housekeeping--make this a singleton
  ///
  public override object InitializeLifetimeService()
  {
    return null;
  }

  ///
  /// Returns a list of media on this server that 
  /// matches the given pattern.
  ///
  public string[] ListMedia(string pattern)
  {
    // ...details, details...
  }

  ///
  /// Returns a stream that is the raw file data
  /// for the requested media.
  ///
  public Stream GetMediaStream(string path)
  {
    // ...details, details...
  }
}

If you want to make this a marshal-by-ref singleton object, you need to add the italicized text. As you can see, it's not very expensive in terms of extra lines of code you have to add (though having to derive from MarshalByRefObj could obviously be quite invasive if you're building off an existing class hierarchy).

So now we have a class that can be remoted. How do we get the CLR process to start listening for requests? Well, there are a lot of knobs you can turn here, depending on what kind of serialization you want (binary or XML) and what kind of communications protocol (bare TCP/IP sockets or HTTP) or if you want to customize/extend the process. Let's ignore all of that; here is a simple cut-and-paste template for basic binary TCP/IP communication (which is generally what you want anyway when you're not dealing with firewalls or interop):

ChannelServices.RegisterChannel(new TcpChannel(1234));
RemotingConfiguration.RegisterWellKnownServiceType(
    typeof(MediaLibrary),
    "MediaLibrary.binary",
    WellKnownObjectMode.Singleton);

The first line creates a TcpChannel on port 1234 and registers it with the runtime, which will from then on listen for remoting calls on that port. The second line takes our particular class and publishes an instance of it at the URL "/MediaLibrary.binary". Thus, these two lines make a media library available at tcp://hostname:1234/MediaLibrary.binary.

Clients connect to the server like so:

RemotingConfiguration.RegisterWellKnownClientType(
    typeof(MediaLibrary),
    "tcp://myserver:1234/MediaLibrary.binary");
MediaLibrary remoteLibrary = new MediaLibrary();

The first method call needs to be done just once (per CLR lifetime), and then any call to MediaLibrary's constructor will result in the creation of a MediaLibrary remoting proxy that connects to our server, as demonstrated in the last line. You can bury the first call somewhere in your client startup routine, and after that it all looks like magic. Need a MediaLibrary? Just new one up, don't worry about how it is implemented, pay no attention to the man behind the curtain.

While remoting as I've presented it is convenient, it's not particularly dynamic. The client has to know the server hostname, the port, and the service URI in advance; I suppose this info is usually gleaned from a config file, registry key, or user dialog. That's pretty annoying for something like a media library (well, I don't mind having a static service URI; just the hostname and port). What I really want is to be able to automatically get references to any (and hopefully, something approximating "every") MediaLibrary service on the LAN. Furthermore, I'd like to be able to do it without the user ever explicitly setting up a directory server.

Using the same MediaLibrary class, I want the following API on the server:

void EasyZeroConf.Publish(MarshalByRefObj serviceObj, string serviceUri);

And the following on the client:

object[] EasyZeroConf.Find(Type desiredType, string serviceUri);

The Publish method is simple enough: Take serviceObj and make it available to anyone requesting the service identified by serviceUri.

The Find method is a little less obvious: Search the LAN for serviceUri, and return the results as an array of remoting proxies of type desiredType. Here's an example:

MediaLibrary[] libraries = 
    (MediaLibrary[])EasyZeroConf.Find(typeof(MediaLibrary), "MediaLibrary");

That should be literally the only two methods most library users should need to get simple zeroconf LAN services, though I can think of many scenarios where more customization would be very desirable. This post is already getting long though.

I'll also save design/implementation details for another time. My day job beckons...

Turns out there is a nifty free tool called exerb that compiles a Ruby script into an executable that contains not only the script, but also all dependencies from both the core Ruby interpreter and any Ruby modules you load (whether part of the Ruby standard library or not). The end result is a totally self-contained (albeit slightly bloated) .EXE that will Just Work on any reasonably configured Windows machine, without the end user ever having to know about Ruby.

About that bloat... a trivially simple .rb script under 1.8.0 compiled to an .EXE weighing in at almost 0.5 MB. But that's a small price to pay for the convenience of a single program file with no dependencies.

Of the three major parts (GUI frontend for editing content; generate website by merging content with templates; checksum-based sync files with web server via FTP), the first part is done and the second part is about half done. That is, the eRuby part of the templating system is written and the C# front-end is set up to interop with it, but I don't currently have a way to manage or choose between different sets of templates.

Still, I'm really excited that the eRuby stuff was so easy to integrate. I simply wrote a standalone Ruby script that reads in the data file, turns it into a nice array of articles, reads the template into memory, then runs the eRuby processor on the template (making the array of articles available to the template). It's great; I can combine the power and expressiveness of eRuby templates with the easy wysiwyg editing of CityDesk (and Contribute and whatnot).

I have a feeling the template management problem could end up being surprisingly difficult. I don't have a clear picture at all about how it should work. Need to let that one stew a little...

So, of course, I've decided to write my own blog software. (Yes, I realize that the world needs yet another blog program like it needs a hole in the head. I just can't help myself.) Actually, I didn't decide to write it as a result of CityDesk letting me down, particularly. I was just messing around with Microsoft's DHTML Edit Control and the blog software grew up around it by accident.

Like CityDesk, a simple WYSIWYG interface will be the input method for individual articles. A static website will be generated on disk, using HTML templates impregnated with Ruby code. Said static website will then be synced over FTP to your web server. (Sorry for all the passive-tense. I haven't named the software yet.)

Though the mechanism is, at a high level, almost identical to CityDesk, I am in no way attempting to create a competitor or substitute. CD lets you do some important things that I am not interested in tackling, such as organize your entries in arbitrarily nested folders, create multiple templates, "intelligently" manage links between entities within your site, etc. I currently intend to punt on all of the above. So my program will only really be useful for blogs, or other one-dimensional content.

The first of the three major parts is done: you can create, edit, and delete posts through a Windows Forms (C#) interface. I am using my own simple file format to persist the posts to disk, to make it easy to marshal the data into the Ruby interpreter.

Screenshots coming soon (not that they'll be very exciting).

Holy crap... between generics and this, the collection classes in Whidbey are going to rock. I can't wait to do this:

List<Employee> employees = ...
List<int> employeeIds = employees.Collect(delegate(Employee e){return e.Id;});

Now if only there was a C# IDE that could keep up with IntelliJ...

// Red Flag
flagRed.Name = "Red";
flagRed.Text = "Red";
flagRed.OnSelected += new FlagSelectionHandler(flagRed).Handler;
flagRed.Image = "flagRed.jpg";
flags.Add(flagRed);

// Blue Flag
flagBlue.Name = "Blue";
flagBlue.Text = "Blue";
flagBlue.OnSelected += new FlagSelectionHandler(flagBlue).Handler;
flagBlue.Image = "flagBlue.jpg";
flags.Add(flagBlue);

// ...and so on for green, yellow, orange, purple...

I can just fire up irb and type the following:

template = <<TEMPLATE
// @ Flag
flag@.Name = "@";
flag@.Text = "@";
flag@.OnSelected += new FlagSelectionHandler(flag@).Handler;
flag@.Image = "flag@.jpg";
flags.Add(flag@);
TEMPLATE

['Red', 'Blue', 'Green', 'Yellow', 'Orange', 'Purple'].each do |color|
	puts template.gsub(/\@/, color)
end

and cut and paste the result to Visual Studio. So easy.

I also wanted to share this little bit of Ruby that parses Unicode script data and writes C# code with the result:

require 'net/http'

# get latest script from web
h = Net::HTTP.new('www.unicode.org', 80)
resp, data = h.get('/Public/UNIDATA/Scripts.txt', nil)
if resp.code !~ /^200/
	raise "Error code: #{resp.code}"
end

list = []
scripts = []

# the full text is in 'data' var
data.each_with_index do |line, i|

	# skip comments and all-whitespace lines
	next if line !~ /[^\s]/ or line =~ /^#/

	# parse single-point
	if line =~ /^([0-9A-F]{4,})\s*;\s*(\w*)/
		range = [$1, $1]
		script = $2
	# parse range
	elsif line =~ /^([0-9A-F]{4,})\.\.([0-9A-F]{4,})\s*;\s*(\w*)/
		range = [$1, $2]
		script = $3
	else
		raise "Parse error on line #{i + 1}: #{line}"
	end
	
	list << [range, script]
	scripts << script
end

scripts.uniq!  # remove duplicates

# now print C#

list.each do |x|
	(low, high), script = x
	if (low == high)
		puts "scripts.Add(0x#{low}, Script.#{script});"
	else
		puts "scripts.Add(0x#{low}, 0x#{high}, Script.#{script});"
	end
end

puts
puts scripts.join(",\n")

This is the kind of thing at which Ruby really excels: banging out one-off text processing apps.

Yesterday I replaced my Lian-Li PC60 with a (just discontinued) Cooler Master ATC-710-GX2 in dark grey. The PC60 is sort of a classic. It was the case that, along with the Cooler Master ATC-200, started the aluminum case trend that dominates enthusiast cases today (a whole, what, three years later). Until the PC60 and ATC-200 hit the scene, the aftermarket offered only standard issue beige or cheap and cheerful plastics. Now all the über-geeks go to LAN parties toting sleek aluminum cases, unfortunately usually ruined with big plexi-covered portholes brimming with neon light. Yeesh... kids these days. I wonder what kinds of sick mods they'd inflict on a Porsche. They'd probably line the rims with blue LEDs and etch a Quake 3 logo into the rear window.

The ATC-710 is quite a nice case, especially considering it's only around a hundred bucks (if you can find one). Even though only the faceplate is aluminum (the rest is ordinary steel), it looks as slick from the outside as any of its pricier all-aluminum brothers. The (all-aluminum) PC60 was over $200 when I bought it, though I think it's now down to $120 or so, which qualifies it as a bargain as well. One nice thing about the ATC-710 is the door over the drive bays; it's hard enough finding a case that looks good, let alone finding drives that match.

My other weird computer fetish is noise control. It really bugs me if my computers are louder than a whisper, mainly because I invested a lot in my stereo system and they share a room. The ATC-710 is noticeably louder than the old PC60, in spite of having a quieter case fan; the new case seems to resonate sympathetically with vibrations from both the hard drive and the power supply, which the Lian-Li did not. Hopefully I'll be able to solve that with some isolation pads from Directron.

The big news to me was anonymous methods. I had expected them to be much like Java's implementation of anonymous classes, only at the method level; in other words, I could write something like this:

public void SomeMethod() {
  string label = "Foo";
  this.Changed += new EventHandler(object sender, EventArgs args) {
    MessageBox.Show(label + " detected change in " + sender.ToString());
  }
}

and the compiler would expand it to something like this:

public void SomeMethod() {
  string label = "Foo";
  __anon_1_label = label;
  this.Changed += new EventHandler(__Anon_1);
}

private string __anon_1_label;
private void __Anon_1(object sender, EventArgs args) {
  MessageBox.Show(__anon_1_label + " detected change in " + sender.ToString());
}

While convenient, there's nothing really magic about what's going on here. It's just that the compiler would make up an opaque method name for you and move your method body there, while making copies of the caller's local variables for the method body to use. (OK, the code shown above wouldn't actually work because the same instance of __anon_1_label would be shared among potentially many instances of the anonymous method--let's just pretend.)

Well, it turns out that C# anonymous methods are not anything like the above. They're way better. They're real closures.

The difference between a closure and the above is that a closure is directly wired into the scope of the enclosing block of code. In the above example, it means that after SomeMethod() creates and registers the anonymous method, it could change the value of label and the anonymous method would "see" the new value when it gets called. Or, rather than just printing out a message, the anonymous method could change the value of label and the change would be reflected in the enclosing scope (assuming the enclosing scope is still around).

This opens up C# to all sorts of new styles of programming. For example, Ruby's beloved blocks and iterators will be possible:

List<i> list = new List<i>();
list.Add(1);
list.Add(3);
list.Add(5);

int total = 0;
list.each(new Visitor<i>(int i) {
  total += i;
});
Console.WriteLine(total);

It's not as pretty as Ruby's syntax, but it's about as powerful and totally typesafe.

More fun with anonymous methods to come...

I've got some ideas about how to create a nice high-level C# binding to this. You should be able to take a marshal-by-ref object and just make one API call that says "make this available to everyone on the network."

More on this later.

Just admit it. It's not pretty. And yet, I still want one, and you probably do too.

The Power Mac G5 is to Apple what the Enzo is to Ferrari. The Ferrari Enzo is a distinctly un-beautiful car; all angles and protrusions, with none of the sensuality that Ferrari--and Italian design in general--is known for. Yet this is the most expensive Ferrari in history, and the one model to bear the first name of their founder.

Unsurprisingly, the Enzo's appearance was roundly criticized by the automotive press... but they all sang a different tune once they finally got a chance to get behind the wheel. The Enzo was designed to be a no-compromises performance machine, and that meant the design was dictated purely by the wind tunnel, not the eye of the beholder. Once you come to grips with that fact, it's not hard to see a different kind of beauty in this street-legal race car: an intense sense of purpose, an unswerving dedication to function over form. You don't need to look at the spec sheet to know this is the most powerful roadgoing Ferrari ever--it's spelled out for you in carbon fiber.

And so it is with the Power Mac G5. This is the first Apple in years that can run with the best Intel desktops. While I personally don't believe the benchmark numbers Apple has posted on their site, there is no doubt that it is a seriously fast computer. And thus, the big-metal-cage-o'-fans look works. "The better to cool my monstrous Power4-derived processors with, my dear."

The Enzo was designed by the wind tunnel; the Power Mac G5 is a wind tunnel. Impersonal, brutal, utilitarian... and very, very desirable.

Of course, I could be way off base. Maybe Ive and his band of elite designers actually think the G5 case is beautiful in the same way previous Macs have been. But I kind of doubt it.

(By the way, today's hot Mac comes with dual processors derived from the Power4, requires nine cooling fans, runs a UNIX-like operating system, and comes in a box that looks like a 4U rackmount. Do they still show that friendly, smiling Mac icon when the OS boots up? If so, they should change it to a pitbull.)

LANMP3 and RemoteMP3 let you have a music server running on your LAN that contains MP3 files and is hooked up to speakers, which you can control using any Windows machine on your LAN. This is not as nice as my Jini Jukebox pipedream, which would let you (sitting at any PC) direct any PC to play music streamed from any PC, but it does solve the problem of controlling my main workstation's tunes from my wirelessly-connected laptop.

The RemoteMP3 server was a headless Java program that wrapped the Java Media Framework, while the RemoteMP3 client was a Windows desktop application written in C#. They communicated using a custom protocol over TCP/IP sockets. For LANMP3, I decided instead to write the server as a C# program that wraps the Windows Media Player ActiveX control. The client is still a desktop C# program, but now it communicates with .NET Remoting (similar to Java RMI).

There were several problems with RemoteMP3. The worst was that JMF had problems playing many real-world MP3s that sound fine in Winamp or Windows Media Player; it would stutter or completely stop on probably one in fifteen MP3s in my collection. Furthermore, after it finished the last song in a playlist, it would make low-level pulsing static noises, as if it were looping the last second of the last song (just my guess). LANMP3 exhibits none of these issues, and as a bonus, WMP exposes a much simpler API than JMF (no surprise there).

Secondly, there was an unacceptable amount of latency between the RemoteMP3 client and server, despite the fact that I was using my own, very compact, direct TCP/IP socket protocol. The lag was on the order of *seconds*, even on a LAN, so there was definitely something screwy going on in my code. I never was able to track it down. On the other hand, .NET Remoting performs more than fast enough, and was much, much easier to work with. You have to know the particular incantations to publish an object as a remoting target, but once you do, it Just Works (well, usually).

LANMP3 binaries can be downloaded from my code page. Feedback is welcome.

You can see a list of other MS Research projects here... they are definitely not sitting still.

(Just for symmetry... here's a list of Sun Labs projects.)

If I understand correctly, Knoppix won't touch your hard drive unless you do something to them. In fact, you don't even need a hard drive at all. For those who just want to try out Linux without having to repartition their hard drive or otherwise fudge with their perfectly tweaked Windows machine, this is about the least-invasive experience there is.

This isn't news for the Linux set... "live CD distros" have been along for quite some time, apparently, and range from tiny text-only installs intented for disaster recovery to full-on desktop setups like Knoppix. In fact, even I had heard of them quite some time ago, but never got around to actually trying one until now. It's the kind of thing that doesn't sound too exciting until you actually see it happen... like pausing live TV with TiVo.

Anyway, I highly recommend Knoppix. You've got nothing to lose but a blank CD...

Ruby's syntax and design philosophy are heavily influenced by Perl. It has a lot of syntactic variability. Statement modifiers (if, unless, while, until, etc.) may appear at the end of any statement. Some key words are optional (the ``then'' in an ``if'' statement for example). Parentheses may sometimes be elided in method calls. The receiver of a method may usually be elided. Many, many things are lifted directly from Perl. Built in regular expressions, $_ and friends, here documents, the single-quoted / double-quoted string distinction, $ and @ prefixes to distinguish different kinds of names and so forth.

I knew it! Is it just me, or is Perl at the root of all things evil!? ;)

All kidding aside, I have been very impressed with Ruby overall. It is as convenient as Python, but feels more coherent--some of Python's features kind of seem arbitrary or grafted on, as opposed to Ruby where a smaller number of constructs are more widely applicable.

I like that Ruby uses backquotes to `execute any arbitrary system command`--that's one Perlism that I wish all scripting languages followed.

I like blocks and iterators a lot.

I like how almost every statement returns some kind of expression.

I simply love eRuby. I don't know how many web scripting languages I've used over the years, but as far as basic syntax goes, I think Ruby-impregnated HTML is by far the best solution for me. I have been longing for a language that is fairly powerful (i.e. not a stripped down "templating language" like Velocity or CityScript), doesn't result in ugly code (see looping over collections in JSP), lets you do includes, and can (optionally) be used at "compile time" to create a static set of HTML documents.

(Note: This is a pretty unfashionable set of requirements these days--the trend is to move the power out of the hands of web developers and into dedicated logic classes, thus enabling better role separation. By taking the real code out of the HTML, you can hire (cheap) HTML developers who don't know how to write real code. Well, I know how to code, and I often need to create websites. Sometimes it's just really nice to be able to declare variables, perform arithmetic operations, and create and manipulate lists from right within the presentation tier. So keep your flaccid, stripped-down templating language outta my face.)

eRuby does all that and more. It is so wonderful that I'm having trouble expressing it in words.

It's just the little things. Say you have an array of images and want to filter out the ones that don't actually exist on disk. You can do this in one line:

<% imageList.delete_if { |img| File.exist?(img) } %>

Contrast that to, say, JSP:

<%
ArrayList tmpList = new ArrayList(imageList.size());
for (Iterator it = imageList.iterator(); it.hasNext();) {
  String thisFile = (String)it.next();
  if (new File(thisFile).exists())
    tmpList.add(thisFile);
}
imageList = tmpList;
%>

or ColdFusion:

<cfset tmpArray = ArrayNew()>
<cfloop index="image" list="imageArray">
  <cfif FileExists(image)><cfset ArrayAppend(tmpArray, image)></cfif>
</cfloop>
<cfset imageArray = tmpArray>

This is just one example of Ruby taking one line where most other languages need five. Furthermore, it seems like the general problem of taking data and turning it into richly formatted HTML involves many of the kinds of operations that Ruby makes very easy:

• Manipulating and iterating over data structures
• String processing
• Dealing with potential nulls

It's almost as if Ruby was specifically designed to be embedded into HTML! (It wasn't.)

Also, I have found that static typing--while a huge boon in general--is less useful in this area, specifically because there is generally so much iterating and unmarshalling (from request parameters) going on, so you end up doing a lot of casting and parsing which defeats much of the static type checking anyway.

So anyway, there you have it. If nothing else, use Ruby for generating web pages. (I'm using erb as my eRuby implementation because it is small and portable.)

Ruby seems fine... not a whole lot different than Python at first blush. I like that it has stronger OOP support; an object's instance variables can't be accessed from outside of the object (you must use accessors), and there are formal notions of public/protected/private methods. Contrast this to Python's laissez-faire approach (i.e., no access control whatsoever). And of course, Ruby's iterators are very nice.

On the other hand, there seem to be an uncomfortable number of things you have to "just know". For example, there are quite a few predefined, global variables; one controls the default separator pattern for the String.split method, another holds the last line read by Kernel.readline and is used as the default for most print operations, another is the exception in a catch clause. Here's an example:

$, = ','
$; = '\t'
while gets
  data = $_.split
  puts data.join
end

This block of code converts tab delimiters to commas, but you'd have to know what $, and $; mean to make that connection.

In all fairness to Ruby, there always seems to be a "clean" way to do it as well:

while input = gets
  data = input.split('\t')
  puts data.join(',')
end

I'm also a little sketched out by how little you can rely on parentheses if you want to; to these Java-tainted eyes, it can make for some difficult-to-read code. When you see a comma-separated list of identifiers, you have to pay attention to figure out what's going on.

min 0, 100                     // method call
min 0, max x, y                // nested method call
a, b = x, max x, y             // parallel assignment w/ method call
rescue SyntaxError, NameError  // catch clauses

Contrast this with Java, which forces you to use parentheses to on method calls and such. They cost you a few more keystrokes, but the resulting code is utterly unambiguous and easy to read. (Note that Ruby doesn't force you to leave off the parentheses; in fact, the book says you should use parens in all but the most trivial cases.)

It just seems like there's a little bit of Perl's "There's More Than One Way To Do It" thinking going on here, moreso than Python. Personally, that's not a mantra that appeals to me when it comes to syntactic details like where parens go, whether to use && or and, whether to make blocks with do..end or curly braces. I'd rather have an simple, consistent, easy-to-read language and sacrifice those freedoms.

Any machine on a LAN could run the Library service and/or Player service. Library would simply offer up a catalog of available MP3 files on that machine, and allow those files to be streamed to clients. Player would allow files to be queued up and played. All of this would be controlled by Swing clients from anywhere on the network.

With such a system, you could use your 802.11b-enabled laptop to have your HTPC start playing a song that is stored on a server in your basement. You'd never have to sync up your MP3 collection across multiple machines. And since it would all be based on Jini, it could all be very robust and decentralized, with no "central server" necessary. New Players and Libraries connecting to the network would be autodiscovered by everyone else.

All of this would be extremely easy to do; the Java Media Framework makes it easy enough to play MP3s, and the rest is just pushing bytes and messages around.

I'd love to build this, if only to give Jini a try. Oh well, tack it on to the end of the "To Do (Maybe)" list...

• Any number of read operations can happen simultaneously.
• Only one write can happen at a time.
• Read and write operations cannot happen simultaneously. (i.e., a write cannot begin until any outstanding read operations complete.)
• Write operations should not starve forever during read-heavy periods.

That's a description of a fairly standard read/write lock. What makes it more interesting is that this read/write lock must protect a resource across multiple processes. Thus, most of the standard .NET threading constructs are useless, since they're only good for coordinating multiple threads inside a single process.

Win32 does provide a few cross-process synchronization primitives, however: Mutexes, Semaphores, and Events. These can be used from .NET with relative ease (i.e., relative to many other interop chores). Between my friend John and me, we figured out that you can actually satisfy the requirements using only Mutex and Semaphore. It sure isn't pretty, though.

Start by picking a number that is slightly higher than the number of concurrent reads you can reasonably expect. In this case, let's say it's 100. We will create a global semaphore with this number of permits. We'll also create a global mutex. (The code that follows should be considered pseudocode: for illustration purposes only.)

// create or open global mutex
GlobalMutex mutex = new GlobalMutex("IdOfProtectedResource.Mutex");
// create or open global semaphore
GlobalSemaphore semaphore = new GlobalSemaphore("IdOfProtectedResource.Semaphore", 100);

public void AcquireReadLock()
{
  mutex.Acquire();
  semaphore.Acquire();
  mutex.Release();
}

public void ReleaseReadLock()
{
  semaphore.Release();
}

public void AcquireWriteLock()
{
  mutex.Acquire();
  for (int i = 0; i < 100; i++)
    semaphore.Acquire();
  mutex.Release();
}

public void ReleaseWriteLock()
{
  for (int i = 0; i < 100; i++)
    semaphore.Release();
}

Thus, having read lock simply means holding one of the semaphore's permits, while having write lock means holding all of the semaphore's permits. It's a little bit nasty and inefficient, but it seems like it should work.

Tune in next week, when we'll be creating a FIFO monitor using only bubble gum and a pocket watch. ;)