0.7.2 (beta)
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 Google Code.
So if you have any ideas for how you can make Waves better, please drop by the support forum and introduce yourself!
(No, seriously. Do it now.)
Announcements, tutorials, guides, etc. about Waves.
We’ve joined the cool kids and gone all git, so if you’ve been using the SVN repo, stop, drop, and roll. If you have questions about how to use Git or transition from SVN to Git, please stop by the forum, and we’ll do our best to help!
Well, that happened. On consecutive days, Waves was featured on two popular Ruby blogs, InfoQ and Peter Cooper’s RubyInside. It was fantastic exposure and a great way to cap of Waves’ first month since it’s public launch.
One of the things I always found myself doing in Rails was refactoring my models and controllers so that I could create new ones by simply inheriting from an appropriate base class and then maybe add a few tweaks and be finished. I typically ended up with three or four base classes representing different types of resources. For example, I might have one for administrative-related controllers, another for content-delivery related controllers, and so on.
I am probably way more excited about this than I should be, but I don’t care. Matz has a blog entry about Waves!
I got into a bit of discussion about the concept of request mappings on the mailing list, so I thought I’d recap that here as my first attempt to look at the nuts and bolts of Waves. Request mappings are akin to routes in Rails or Merb. But there are some profound differences. Request mappings are exactly that – they map a request to a block of code.
We’ve joined the cool kids and gone all git, so if you’ve been using the SVN repo, stop, drop, and roll. If you have questions about how to use Git or transition from SVN to Git, please stop by the forum, and we’ll do our best to help!