Nodeta is a software development company that focuses on web software. We employ a highly agile and effective process. We have worked
both on light independent projects and in the environment of large global enterprises.
Rails-doc.org 1.1 has just been deployed. It features:
a revised front page with latest good notes
search improvements
fixes to some cache problems
other minor fixes
We had a good first weekend and we are now getting a steady few thousand daily users. However, we still need more registered users to post more notes. I want to again thank Fabio Cevasco, who interviewed me and wrote an early review on Rails-doc. We also got noticed on Rails Inside and a dozen other blogs. Thanks to all who posted about us!
We got loads of nice and encouraging e-mails from users. We try to answer them as quickly as we can. Thanks for all the feedback!
lightning-fast keyword search with weighted sorting
community based notes inline with the documentation
Many other features are included already in this release. Amongst the most important is showing of
visual representations of the importance and relevance of classes/modules/methods initially based on the amount and complexity of their documentation. The formatting of the documentation has been improved vastly and it is now both easy to read and easy on the eye. The formatting also includes nice-looking syntax highlighting which is also used in code examples that you can give as a part of notes.
Each page of documentation has a list of related methods and you can also move to namespaced parents and children. Class and instance methods are separated, so are public and private.
The search feature also includes keyboard controls. After typing in your search query you can move from on result to another by using the arrow keys and move to the chosen result by pressing return.
Notes can be thanked and so we can ensure that good notes are shown more prominently than not-so-great ones. We provide an RSS feed of good notes (notes that have been thanked a few times) for active developers who want to know everything about Rails.
Currently, only documentation for the most recent Rails release, 2.1 is included. The next big release, coming out in a couple of months, will include support for multiple versions of Rails and version handling/separation on class-module-method level.
A technical writer from Italy, called Fabio Cevasco, was kind enough to write an early review. Check it out, if you’d like to read a more extensive first look.
We’ve been feeling sorry because we didn’t pay much attention to rails-doc IE compatibility. Today I had a look at the server statistics, and it seems that even the iPhone browser is more popular than Internet Explorer. :) Good to see that Rails developers have such a good taste.
Anyways, today is the Firefox 3.0 download day:
Go and get it! The super-fast JavaScript interpreter is going to enable lots of new possibilities in web UIs. I’m really looking forward to see stuff like SproutCore used in different kinds of applications.
PS. The upcoming Rails-doc.org JavaScript search is already going to benefit from the upgrade. ;)
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:
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.
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…
I think everyone who participates in Scrum ought to know the essential laws that Scrum was created to deal with. But much more important, I think that the client must acknowledge them, since I do not believe it is possible to be successful at buying software without being fully aware of these fundamental laws, coping with which is of utmost importance when it comes to developing software. It never hurts to remind oneself of the laws, that Scrum was created to deal with:
Specifications and requirements will never be fully understood (Ziv’s law)
Where your mind sees a square, the next guy’s sees a circle. Specifications should be documented but the maker of the specifications has to be fully available for the development team to ask questions and to communicate eye-to-eye. The maker of the specifications, who should be or at least strive to be the best expert of the actual requirements, absolutely cannot be a stranger to the development team.
The users will never know what they want until the system is in production and maybe not even then (Humphrey’s law)
The users may also believe they need something they in actuality have no use for. Users customarily claim they need a feature for a business requirement that can often be covered much better by a very different feature. Users cannot make specifications. Users’ feature requests obviously still need to be heard so the developers can come up with the right feature to cover the business requirement and empower the user to reach his goal. Users’ goals and the software’s business requirements should be crystal clear to the developers and the developers need to show interest towards them.
An interactive system can never be fully specified nor can it ever be fully tested (Wegner’s lemma)
Important to acknowledge, and just as important it is to understand that regardless of the impossibility, full test coverage, automated and manual, should be attempted to achieve. The specification of a software is always a work-in-progress, even after the software itself is ‘completed’. This needs to be accepted and specification documents need to be constantly edited during the process of developing the software.
