A few days before New Years, I posted how neat it’d be if we had a Ruby Appliance. This, and the mail to the ruby-talk mailing list has resulted in a couple of results already.

For one, we found a name: Ruby Zen, which fits quite well, and is appropriately Web 2.0 without being unintelligible.

For another: rubyzen.org has been registered, and we are feverishly working on getting the website up and some content, too.

We are also working on evaluating Linux distros, with Gentoo, Turnkey Linux, and Ubuntu being hot candidates for the appliance’s operating system.

We’ve also decided to focus on Ruby 1.9.1.

The guys over at gemcutter.org were so kind to provide me with a quick dump of the top 100 hottest gems, so we can pick some great gems to start with.

Unfortunately, this is happening behind closed doors of sorts, since, at the moment, we are using Google Wave which is still closed to the general public. However, if you leave me a comment here, we can organize a handful Wave invites for certain! (I still got 5 or 6 left from the first batch alone.)

So, what else?

Future plans!

In the short term:

• Get a website up for easy contribution (and to move the development process in the public, where it belongs, it’s done by the community for the community, after all)
• Have a prototype VM ready in a couple of days
• Get more contributors. You can help if: You can test a virtual machine, read proposals and comment on them (provide a reality check! Always good!), write a tutorial (maybe for your favorite gem, or Ruby feature)
• Got TikiWiki experience? I’d be glad to hear from you, if you could lend a hand in implementing features (like an issue tracker, or user wiki page).

So, yeah, the Ruby Appliance isn’t forgotten. Considering that this was between the years we did get quite a bit done yet. Thanks to every one (here or on Ruby Talk) who contributed already.

ClothRed is in dire need of help. Your help.

I simply don’t have the time, or will–truth be told–to begin work on ClothRed again. The code’s become foreign to me, way too foreign, and I have to get back into the thick of things, to write any useful developments for ClothRed.

So, what is ClothRed? In theory, it’s an HTML to Textile parser, for example to filter user input, so it goes well with RedCloth (see what I did there? Boy, did I think I was clever).

However, the architecture of this thing is rather stupid, if not braindead, working off of hardcoded Arrays of HTML tags and entities, and #gsub’ing those tags. Embarassing, really.

However, it has a complete set of tests from my TDD (it even passes them, except the one I left off, natch). Still kinda proud of this, since ClothRed was my first project to make use of TDD, and the Unit::Test framework).

If you don’t know where to start: I’d get a rewrite off the ground, using Nokogiri, it seems simple enough (and allows to extract innerHTML, and attributes, and all kinds of neat stuff. Would’ve been nice to have that available when I worked on ClothRed).

The Rakefile needs clean up, too.

So, head on over to http://github.com/CynicalRyan/ClothRed, and take a look if you’d be willing to take up the work from there.

Update: Fixed link.

In this context, an appliance is a ready-to-run virtual machine. No set up to speak of required.

But why? Isn’t it easy to install Ruby wherever you like?

That is very true.

However, the Ruby ecosystem is very *NIX centric. Not everyone has the luxury, or time or ability, to setup and maintain a UNIX-like operating system.

Virtualization and thus appliances turn operating systems into just another kind of program. They reduce the risk of using a different operating system. Further, not everyone using Ruby wants to, or can, dig through C extensions to make them work on their operating system of choice. The hurdles as a Windows user are too high in most cases.

An appliance makes it easier to setup test environments, so they are great for seasoned developers, as well!

You can start with a clean slate, only Ruby, RubyGems, and a compiler tool chain are installed, and you can easily revert to this blank slate at the push of a button. With the different networking tools in today’s VM tools, you can even test network deployment of Rails applications.

So here is my proposal:

To create the best possible Ruby appliance and experience, I want to know which Gems and tools the Ruby community sees as essential to make life as a Rubyist easier.

Submit your ideas, and the Ruby Appliance will benefit and with that, all of the Ruby community.

So, curious fellow that I am, I have taken a look at the website.

And I’m left with a big “huh?”

Yes, that’s right, I have no idea what it is about. And I have the feeling that I’m not alone in this. A lot of the negative reaction seems to be that nobody has an idea what RMM is actually about. The website itself doesn’t make it too clear.

The FAQ says:

A lot of what makes the Rails community special might not have that much to do with Rails technology itself. We could be right about that, or we could be wrong. Either way, we’re interested in finding out about the practices of the Rails community and don’t really care about other communities.

So it’s about finding out what makes the Rails community commercially successful. Fascinating.

But at the moment, it only shows what Rails corporations use. There is no real explanation except a short marketing blurb (nothing wrong with marketing, but it doesn’t allow for critical discussion). There is no discussion as to what the practice is, how it is done, nor what its benefits and downsides are. There is no way to get meaning out of the data.

Of course, if you are in the Rails space, you’ll know everything about TDD, BDD, Cucumber, git, Textmate, and pair programming.

You’ll know about continuous integration, collective code ownership, or Passenger.

RMM is very young. You can’t even sign up for the beta yet, except by sending an email. No problem with that. After all, any database needs seeding with data first, not to mention development of features and bug fixing. No better way than getting user feedback for that.

But to become a database of best practices, it needs to provide context.

For that it needs a couple of features:

• The size, revenue, and target demogrpahic / area of expertise of a corporation using any given technique
• A definition of techniques, and their benefits and downsides. Any technique has downsides. If it is just cost or space requirements
• A way to discuss a technique
• Visualizing how techniques, revenues, employee morale, and corporations relate (if at all possible. How to assign a hard and fast value to morale? Or how to normalize corporations of different sizes, revenues, and markets?)
• A lack of rankings. I don’t care how many people actually endorse a given technique or tool. wycats already expressed why that can be a bad idea.

At the moment, I fail to see what the benefit of RMM is for me, somebody interested in how others do their thing. To be of use, it is at least lacking some of the above features (size & revenue, as well as area of expertise). In short, I can’t build useful relationships from the data presented.

In any case, I’m looking forward to see RMM mature beyond this point. Until then, take a look at it, and keep an open mind, no matter on which side of the fence you are.

The article, which is un-surprising good in the technical aspect, claimed that the testing framework is able to process your testing scenario in plain text, from the user’s perspective. Without having looked at Cucumber: This is wrong.

“But wait,” you say, “you haven’t looked at Cucumber.” True. However, I bet you dollars to donoughts, that, just as with RSpec, Shoulda, and any other testing frame work, you’ll have to learn a vocabulary to express your thoughts, so that the tool understands what you want. Just because computers can’t do natural language processing. Yet, anyway.

Let’s stop misleading ourselves, in implying that “plain text” means “natural and intuitive”. It isn’t. If I wouldn’t know that Cucumber is doing Behavior Driven Development, I’d have no idea what “Given a…” meant in this context.

For us humans, text needs context, and that has to be provided somehow. This is even worse with computers: We can derive context from content, computers are too stupid to do that. Accordingly, Cucumber needs you to write the test parser (judging by the most curious look I gave it. It’s probably just fine tuning the actual testing and mock ups). Using Regular Expressions, too (just to add insult to injury )

How about we call “plain text” and similar things “understandable”, instead? After all, while these tools don’t live up to what is implied, they are able to make a key point of (agile) development accessible to the most important stakeholder: The customer, while giving us, the developers, a basic template for sanity checks. This is more than important, it is an absolute necessity for our survival as business entities, and in part even as hobbyists! Cucumber’s BDD tests probably don’t need an understanding of the programming language you happen to use, but abstract this away, since it is, in general, not needed at this stage.

Just remember The Law of Leaky Abstractions

Well, this won’t quite work out, since I already have the contract in hand.

However, I’ll write up what I am going to do, what I am doing, and the milestones reached. Well, a software development blog.

So, what’s the project about?

I have to build a web-based Document management system.

Requested Features:

• Single Sign On
• Import documents from a network share
• Storage of metadata (an odd one in this case is, that physical locations have to be recorded, too, in case the government agency sending it cannot deal with electronic documents. Legal requirements are fun like that)
• Fortunately, no detailed tracking for SOX or other such regulations.

What’s coming up

At first, I’ll post progress about gathering requirements, proposals and recommendations of solutions for these requirements that go out to the client (after I’ve sent them, though).

After that, I’ll report my progress with the application: What I did, why I did it, and what the challenges were.

And last but not least, I’ll talk about the deployment of the application, and its maintenance.

So, what are you using?

The web application framework is going to be Ruby on Rails, the database back-end MySQL, the webserver will be Apache of some sort. What’ll serve the Rails pages I don’t know yet. Maybe Glassfish with JRuby, maybe mod_rails, possibly the classic Apache + Pack of Mongrels solution. We’ll see when I get there.

My development OS will be Windows XP together with a Debian VM and a Kubuntu 8.04 installation as primary development OS.

The deployment will be on FreeBSD 5.4 (I know, I can’t influence that, and neither can my client).

The approach I’ll be using, even though I’m just one person, is a simple variant of Agile Development: Sprints, and loads of tests before I write the actual code.