Here is some proof to back up our overly lengthy tagline, Rails-doc is the first Rails documentation app that wasn’t developed by one guy in his underpants. Rails-doc.org has an actual team behind it – a team that employs an agile development process.

There’s hardly a better visualization of Scrum than a timelapse video! It shows the progress of our second sprint.

As of right now Rails-doc.org website is opened. There isn’t much content yet, but a lot of promises, including the first release which is scheduled for next week, current target being Thursday, June 19th. Rails-doc is a community powered Ruby on Rails documentation app. It is open and social. It features an intelligent keyword search that is almost as fast as the native search in your browser. We have two clear goals, the second depending on the first:

1. To provide a highly usable interface for perusing Rails documentation and for contributing with notes and examples and to thus collect a good amount of additional Rails documentation.
2. To expand the actual documentation of Rails by providing tools to active members of the Rails-doc community for incorporating the notes into creating an extended unified improved documentation.

The first release will be the fruit of three sprints’ work from our core Rails-doc development team consisting of three active members and a few of much less active ones. Rails-doc.org is also the pilot project for APIdock, Nodeta’s new social software documentation app.

Many others have tried to develop a Rails documentation app, but none have succeeded. Regardless of that, I know that…

…we indeed can do it!

Check it out!

We’ve been using trac for a long time. It’s great, but it’s written in Python. That actually shouldn’t matter, but patching and running a Rails application would be much easier for us.

Existing solutions have mostly been direct trac rip-offs, except that they’re usually slower, missing some features and visually less appealing. Probably that’s also why their development stalls at some point (see Collaboa for example).

Now that Redmine has reached 0.7.0, let’s have a quick look at its features.

CruiseControl.rb integration

This is only a plugin, but haven’t you always wanted your CruiseControl log and issue tracking in one place? Here it is, the SimpleCI plugin.

Truly multiuser and multiproject

You don’t have to set up multiple Redmine instances to serve multiple projects. Everything is done in the web configuration UI.

Configuration

Everything else is also configured in the web UI. Sometimes even too much: Redmine is not very usable without any configuration.

Workflow can be defined precisely to suit your needs. For example, if you want that developers are not allowed to close tickets before they’ve gone through testing, you can configure different states for the tickets and who’s allowed to do what. This is nothing new in “enterprise” issue trackers, but trac didn’t have this feature before 0.4.

Remote SCM support

trac is pretty much limited to local Subversion repositories. Redmine works well with remote SVN repositories, and it even supports some other SCMs. Git support should be almost there…

Conclusion

Redmine has tons of features you’d never expect to see in a software that’s mostly developed by one guy. Time tracking, Gant charts, localization… You name it.

Even though the user interface may not please everyone (it could still learn some simplicity from trac), it’s definitely worth checking out.

Ruby on Rails documentation sucks. Somehow the convention over configuration idiom translated into intuition over information. It’s not easy to learn Ruby on Rails with the API documentation on your screen and a glimmering pin-up photo of David in your hand. If you are a Rails beginner, you know exactly what I’m talking about. If you’re a Rails veteran, you might have to think back a little: remember when you saw that dynamic scaffolding screencast and dug head first into the new, forever changed world of web development? All those amazing innovations amidst all those inexplicable hash parameters with such descriptive names as options or args.

The bad API documentation was never just bad for the Rails community. First of all it garnered some really good books. A lot of writers wanted to be the first to write that Rails and Ruby bible. These were ambitious, excited writers, which is a hell of a lot better than your average commissioned Joe writing about Symbian or Spring or something.

Secondly, the lack of a good API documentation created a lot of frustration in the beginners’ minds and every single Rails beginner who plowed through that struggle also went through the period of releasing that frustration. I’m talking about those moments when they relied on that convention (and intuition) and felt the hand of David guiding them and, on a mere hunch, wrote something they had never seen anywhere, and it worked – it actually friggin’ worked. Those moments made these people hard core Rails fanatics who never looked back.

Well, the buzz is over and it’s time for a reality check: rails documentation sucks. It still sucks! And it’s not getting better. So we at Nodeta decided to do something about it. It’s time to truly harness the power of the community to improve the documentation. In the age of Rails, that can only mean one thing: a killer app. That’s why we are whipping up a summer project of our own, to create Rails-Doc, the community driven Rails documentation app. The idea came already almost a year ago and the final decision was made a couple of months ago. Since the idea emerged, we have been blessed with some competition and an amazing starting point. Most plans have already been made: the project will start in mid-May and the first release will be out by the end of June. Stay tuned for updates on Rails-Doc.