The Fugue

I quickly ran some unscientific bench^Wlogmarks (3 or 4 samples after stabilization at the CLI with my friend time) for camping vs. just erb/cgi vs. just markaby vs. my current blosxom blog (with 10 entries):

time ruby -rrubygems -e "require 'camping'"  # about 0.5 seconds
time ruby -rcgi -rerb -e ""                  # about 0.05 seconds
time ruby -rrubygems -e "require 'markaby'"  # about 0.2 seconds
time blosxom.cgi >/dev/null                  # just under 0.3 sec
time fugue.rb >/dev/null                     # just over 1 sec

The blosxom and fugue runs dealt with the same 10 posts and produce almost to the angle-bracket the same HTML. It looks like to me that I should think about doing my super-simple blog without the overhead of a framework, even one as small as camping, and go with straight markaby or erb for the template.

Camping does fine once it's loaded, but I don't really want 20 megabytes of virtual memory being wasted just so the 5 people out there reading my blog can get it in less than two seconds. As it is I'm trying to find ways to prune rails/apache/etc. memory usage. I think I have an idea, too.

So apparently a lot of this time is startup time, but a lot of the time this startup stuff is the same over and over. I started thinking about one master process that somehow subthreads the rails/camping sites, but that gets messy and who knows when a global variable or some other rogue will really mess things up. Not to mention environment. But wait, I don't care about memory usage when it's actually doing something - it's the perpetual waste of RAM that I'm concerned about. Why don't I have N bootstrap processes that have done the equivalent of require 'rails' or require 'camping' and are ready to load the appropriate ruby script on-demand and then die gracefully after the page is served. I get precise control over how many processes are hanging around, the wasted RAM between requests is much less per lingering process than with a full-blown fastcgi app, and you get fast service.

Well, there's at least one problem: most page loads will have a bunch of requests all at once, so maybe it would be better to have the bootstrap process load up a fastcgi process that can serve the rest of the requests and die after a few seconds of idle time.

If you have thoughts on this scheme, let me know. Yeah, I know I don't have comments, so you'll have to do it the old-fashioned way. If my subconcious doesn't churn something up in the next few days/weeks I might just whip it up.

In usability and UI design theory there's this concept of affordance. We say the button affords clicking, or the metal plate on a door affords pushing. Well the latest Firefox .dmg for OS X (Firefox 1.5) strives to make the already dog-simple installation process (drag the .app into /Applications) even easier:

Doesn't that look great? It just begs you to drag it into the Applications folder. There's only one catch: that's not the Applications folder! That's a background image. It's completely worthless. It gums up your mind and prevents you from installing it on autopilot while you try to figure out why you can't just drag it onto that Applications folder.

In my case the confusion was exacerbated because I had recently come across a .dmg that used the same tactic, except they had a symlink to /Applications in there so it actually was dog-simple to install, instead of just looking that way.

10 points for style, -20 for stupidity.

With the announcement of the first Friday from the Pragmatic Programmers, which is Rapid GUI Development with QtRuby, I got really excited. I used QtRuby a little bit back when it was brand-spanking new, because I've used Qt more than once in the past (C++) and I think it is an excellent toolkit. I figured that this PDF book signalled that QtRuby was finally ready for prime time.

It is with great sadness that I report it is not so, at least not for me. It may well be solid enough for serious work. Since it is in Debian now, it may well be the easiest toolkit path on Debian-based Linux. It may have better documentation and a really cool PDF book from the Pragmatic Bookshelf. But it is nigh unto impossible to install on OS X. It claims to be able to, but the extremely complicated instructions fail to tell you what to do when this strange smoke thing fails to compile.

On the other hand, FxRuby is now much easier to get on OS X (and Linux) than it has been in the past. Install Fox (with DarwinPorts on OS X or apt-get on Debian), have rubygems (you do, don't you?), and type gem install fxruby. Nice. It's not native OS X, but it's installable. I managed to get some semblance of OS X nativity with Tk, but I seem to gravitate away from Tk for some reason. I haven't tried ruby/gnome2 yet on OS X. I hear good things about wxRuby, but I have found it also is impossible for mere mortals to install it on OS X.

If I write a GUI app, I want it to have minimal requirements of installation by users. Right now I'd be happy to rely on DarwinPorts/Fink and gems to do the heavy lifting, but asking users to go through an excruciating manual compilation process that fails inexplicably just won't cut it.

Ruby on Rails is really nifty. That's a huge understatement, but it's late and I don't have time to evangelize.

One nifty thing about rails with an un-nifty name is the has_and_belongs_to_many keyword. It is long and awkward, and it is also mentally awkward. For example:

class Recipe < ActionRecord::Base
  has_many :ingredients
  has_and_belongs_to_many :cookbooks
end

Since when did a recipe have a cookbook, or a cookbook belong to a recipe? No, sorry, this is a terrible name. I appreciate the desire to make it read in a natural language sort of way, but trying to english-ize complex relations like this is the sort of thing that gets you in trouble in AI classes and other places where relations are important. Like, say, relational databases. Anyone who has the ability to consciously create a many-to-many database table (as opposed to unconsciously cut-and-pasting one) will know what many_to_many means, and his brain will happily fill in the gaps to read out "Recipe has a many-to-many relationship with cookbooks."

I like that I have very few things in Rails to rant about, but I have never been known to hold back my rants. ;-)

Oh, I almost forgot the solution, which was the whole reason I decided to blog it! Thanks to Jamis for figuring out just what the best way to do this is. Append this to the end of config/environment.rb:

class ActionRecord::Base
  class << self
    alias :habtm :has_and_belongs_to_many
    alias :many_to_many :has_and_belongs_to_many
  end
end

I have never seen a default calculator included with the OS that I like. For that matter, I have never seen a GUI calculator that I like with the exception of HP emulators (which are too clunky) and the RPN Calculator Dashboard Widget (which is great but dashboard currently means heavy swapping because of the RAM shortage). I have been pleasantly surprised once again by my iBook. Apple's Calculator is a marvel to behold.

It starts out as unassuming as you ever thought the default calculator would be.

Then you explore the menu and find that not only can you use RPN, but you can do scientific mode. Neat, but not new. (The RPN bit was exciting though)

Wait! What is this Progammer view all about? Oh wow. Easy base conversion, 64-bit binary, 2's complement, every operation you ever needed to make your CS and EE homework a piece of cake. I'm sold!

Ok, one thing does bug me. RPN is hard to work with without a stack. Sorry, the paper tape doesn't cut it (it might, if it responded to enter). But all in all the best designed software Calculator I have ever seen. It even beats out bc and dc thanks to the programmer feature. Still, there's nothing like my HP 48G...

Ajax? What's that?

I have done my time as a web developer. I don't like it a whole lot, but I think the basic skillz are important ones for any IT or CS professional, like writing and communicating. The reason I don't like it is because I feel it is a poor platform for doing what so many people try to get it to do. I also used to feel that it was a futile excercise to keep trying - a waste of effort.

Then Google hit me upside the head with Google maps. Amazing things were happening there, and it wasn't a plugin. Then I start hearing about this Ajax thing which I at first thought was a new language or server or something. No, it's more comparable with MVC than JSP. The guy who coined the term (in this article) put it well:

Q. Is Ajax a technology platform or is it an architectural style?

A. It's both. Ajax is a set of technologies being used together in a particular way.

I hear some people are acting fairly childish and close-mindedly about the name Ajax. Go away, or we shall taunt you a second time.

Q. Why did you feel the need to give this a name?

A. I needed something shorter than "Asynchronous JavaScript+CSS+DOM+XMLHttpRequest" to use when discussing this approach with clients.

So now you know what Ajax is. I still would mostly object to a web app where a GUI would be better, but at least now there's enough tech, talk, and doc to make a reasonable interface for the user on the web.

I just read Code as Design: Three Essays by Jack W. Reeves. I highly recommend reading it. It has given me a new perspective and I find that it rings true in many ways.

I often tell people that I like "designing" software more than coding it. I was drawing that imaginary line in the sand that so irritates Reeves, and finding that I preferred the top-level design side of it. In reflection, since reading his essays, I will be changing that standrad speel as I now better understand my own feelings on the matter. I enjoy the whole process. I do like top-level design most, for I am a dreamer. But top-level design doesn't give the endorphin rush that coding does when you begin laying out the code that turns the sea of ideas in your head into a real, working system. In retrospect, I do enjoy coding and always have - what I don't enjoy is converting a "design" into code. That goes for my own "designs" as much as for those written by others.

Lately I've been following his suggestion in a subconscious way, out of necessity. I am working as a system administrator which means very little software development in the day job. So I have several side projects I'm playing with, but the scarcity of time has compelled me to spend less time fiddling with "design" and more time creating design (code). I haven't neglected top-level design, and especially not the deep thought that I put into a project at the beginning. It's been more of a rebellion against extra "design".

For a fabulous concrete example, I present the work I've done so far on alex. Alex is a softphone that I am writing, because I have found all available softphones on linux to be inadequate and fundamentally flawed, for what I want to do with them. I thought through major components of alex - audio, network, UI. Then I started the skeleton. Then I started to get lost so I fired up umbrello and made some basic UML. Then I started to code and saw some fundamental flaws. So I completely reworked the UML. Then I started to refactor the code and saw some detail changes that needed to take place. Propogating those detail changes back to UML quickly became incredibly loathsome, so I stripped the UML of almost all detail, leaving it as a shell of top-level design that does what it's supposed to do: show you the top-level design, without bogging you down in details. I'm very happy with it, for now, and I'm happily coding away the details, changing the class and interface design details as I go. The whole process is very fluid, and very satisfying. I feel like I understand the design and the code very well. I've been building up to this, gradually swapping my love for OO and design out for a love for getting something done. "Release early, release often" and all that other stuff.

In summary, I think I've missed out in some ways because I was looking down my nose at coding. I've often had the unpleasant feeling of having too many dreams and not enough to show for it. I have for some time now been trying to act more on those dreams and not let them fizzle until they are dead, and these essays have given me a new perspective that I believe will be profitable in that pursuit. Thank you, Jack.

Hot Dawg!

I released ladspar, a Ruby module for using LADSPA plugins. I'm pretty psyched about it, mostly because it will let me write the textfile-driven software synth I've been dreaming about, but also because it's so darned cool and only took me a week to write. (of course it helps that Erin is out of town...)

Every silver lining has its cloud, though, and mine is my example in the README was seriously flawed. Here's the corrected example (I'm too lazy to repackage and reupload it):

require 'ladspa'
require 'narray'

# load the CMT library
cmt = LADSPA.load_library('cmt')

# get an instance of the amp_mono plugin
amp_mono = cmt.plugins.find {|p| p.label == 'amp_mono'}.instantiate(44100)

# The ports are Gain, Input, and Output.
amp_mono.ports[0].connect_port(2.0) # gain

input = NArray.sfloat(44100)
amp_mono.ports[1].connect_port(input)

output = NArray.sfloat(44100)
amp_mono.ports[2].connect_port(output)

amp_mono.activate if amp_mono.has_activate

# prep the input data ...

amp_mono.run

amp_mono.deactivate if amp_mono.has_deactivate
amp_mono.cleanup