Gem Version

0.8.2 (beta)

Do not use 0.8.1!

Contribute!

Waves welcomes contributors! Waves was designed to be extended, so there are literally countless ways for you to participate.

The API is already pretty darn well documented, and the source is available on GitHub.

So if you have any ideas for how you can make Waves better, please introduce yourself. We’re often on IRC or you can drop us a line on our discussion forum list.

Hang Ten

Announcements, tutorials, guides, etc. about Waves.

GoRuCo Rocked

by Dan Yoder on Jun 06, 2009

First, for those of you who haven’t heard, I’ve left AT&T Interactive and am now with new startup, SharesPost.com. (Launch is coming soon.) And, no, it isn’t running on Waves. At least, not yet. More on this momentarily.

Second, some thoughts on the recent GoRuCo, held at Pace University in Manhattan … to begin with, awesome. That is how you do it. I haven’t been to all the regional RubyConfs, but I’ve been to several, as well as the national conference, and many smaller non-Ruby conferences. They all tend to suffer from one common malady: too many talks and too little socializing. Furthermore, there just aren’t enough women involved. I realize this has become topical lately, but I’ve always thought the imbalance in the technical world (not just Ruby Nation) was ridiculous.

REST FTW, Part 3

by Dan Yoder on May 03, 2009

In my last post, I suggested thinking about REST and ROA in the context of an object-based platform and protocol neutral approach to distributed computing. The "objects" are the specific representations (MP3, JSON, HTML) of a resource. The semantics of a resource itself are intentionally vague because you never interact with them directly, at least from the standpoint of ROA. This ensures that the "platform neutral" part of the bargain is never compromised.

REST FTW, Part 2

by Dan Yoder on Apr 21, 2009

REST is not an architecture, but a set of constraints for an architecture. I like to use the phrase Resource-Oriented Architecture to talk about the specific Web-based architecture that satisfies those constraints. But the main thing to remember is that these are constraints for a bandwidth-optimizing object-based distributed computing architecture that is both platform and protocol neutral. In that light, one thing that should be clear is that REST therefore applies to pretty much everything Web developers do these days.

REST FTW, Part 1

by Dan Yoder on Apr 21, 2009

Lately, in my talks on Waves and how it supports RESTful architectures, I've found I've had to take a step back and talk more about what REST is and why it matters.

This is a bit surprising, since REST has been on the buzzword bingo card for years now. However, it turns out that most of what has passed for RESTful is really what I have come to call REST-lite. Essentially, REST-lite focused on the verbs of the HTTP protocol and (more or less) ignores ... well, the rest.

Speaking At GoRuCo

by Dan Yoder on Apr 05, 2009

I’m very happy to announce that I’ll be speaking on Waves at GoRuCo in The Big Apple (specifically, Pace University in Lower Manhattan) on May 31st. I love Manhattan (or, at least, I love visiting there) and I really enjoy these smaller conferences. I wanted to speak at last year’s GoRuCo but narrowly missed the deadline because I had been completely immersed in getting the first version of Waves out the door.

The Waves Architecture

Waves follows a few simple design principles, which are probably worth noting up-front.

Keep code compact and extensible.
Leverage the expressive power of Ruby.
Configuration and convention.
Loosely couple major design components.
Use best-of-breed solutions.
Preserve architectural choice.

The Waves Stack

Waves is runs on a state-of-the-art application stack, although remarkably it is not really tied to any single solution, except possibly Rack. That makes sense: Waves is a framework for building Web apps, and Rack is a framework for frameworks like Waves. Other than that, it depends on what application you’re building. That said, Waves does tend to favor some libraries over others, especially at this young stage of its development.

Web Server

Rack provides the HTTP processing engine. This provides Waves with a easy-to-configure processing pipeline, via Rack’s middleware, plus support for most major Ruby Web servers, via Rack’s handlers.

Data Storage

Sequel is the preferred ORM at the moment because it supports migrations and because it supports the use of plain old Ruby for defining queries, but it would only take minor changes to support DataMapper or other ORMs. Again, the need to be able to support these different configurations has led me to initially constrain them.

Coming soon: DataMapper and Filebase.

Template Engines

At the moment, Waves supports only two templating engines: Markaby, which given that it is actually Ruby code was a no-brainer for inclusion, and Erubis, which is useful for all those times when the structure of Markaby is a bit too much, or your not generating HTML.

We’ve also recently added HAML support.

Runtime Support

Waves supports ruby-debug and provides true code reloading and just-in-time generation using AutoCode. Coming soon: support for LiveConsole.

Testing And Debugging

This is an area that has not been addressed with Waves. You can use whatever testing approach you prefer. Waves doesn’t favor any approach – it doesn’t even generate a tests directory for you at this point when you generate a new application.