The Firefox plugin, Ubiquity, is an awesome extendable Swiss knife command line of the web. The other day I noticed that Jack Dempsey had written a Ubiquity command for searching the Ruby documentation from APIdock. After quick googling, I found out that different people had done the same for Rails and RSpec as well, based on Jack’s command. Talk about community effort! Here are links to the Ubiquity commands (you need to have Ubiquity installed):
Blog Archives
As the Rails documentation discourse is really bubbling, our schedule has given us the sweet chance of taking a few steps back and let us concentrate on the first release of APIdock.
APIdock will be deployed today and we’ll import different versions of the included projects slowly for the next couple of days. The app will be completely usable during the version roll-out. Here are some of the most important changes from Rails-Doc.
Multiple projects
The most important difference of APIdock in relation to Rails-doc is of course multiple projects. You will be able to surf your way to APIdock.com and search and browse Ruby and RSpec documentation (in addition to Rails) with the same (except for the improvements that we’ve made) interface that you have been able to use in Rails-Doc. To begin with, the newest patch level of Ruby 1.8.6 will be included as we slowly roll older versions in. Ruby 1.9 will follow later if there proves to be a demand for it. Users wont yet be able to add their own projects, but we’ll provide an easy way to suggest new ones to be added.
In this first release, all the included projects will be listed in tabs, but later on when more projects are added, the idea is that users will be able to choose their “favorite” projects that will be shown as tabs. This way the app will be custom-made for each user.
We’ve added some project specific stuff like extensive project details and version history of the added versions. Behind the curtains the importing of new versions is done with a web interface.
Cross-project searching
When developing Rails applications, you are often faced with situations where you can’t be completely sure, whether a certain method comes from Ruby or Rails or somewhere else (like RSpec when writing tests). To help with this situation, in APIdock, after you have filled in a search term, you can simply click on another project to get the results for that same search term from that other project.Moderators
We have also made our ACL more complex under the hood. We can now have moderators that have some extra rights like editing other users’ notes. This way we can give moderator rights to other people including some of our most active collaborators. If you’re interested in becoming a moderator, please contact us at team@apidock.com.
Rails-Doc => APIdock migration
Your Rails-Doc accounts will be preserved in APIdock, the notes will be where you wrote them and the thanks you’ve got won’t disappear either. Any URIs to the rails-doc.org domain will redirect to the correct page under apidock.com. There aren’t any drawbacks to the migration – no functionality is lost. The app was designed to support multiple projects right from the get-go and now that decision is paying off.
APIdock: what’s to come?
Rails-doc and APIdock has been our first Summer on Rails project, something we hope to be an annual feat. The general idea behind SOR is to hire young talented developers to develop something cool and not-too-business-critical over the summer under the mentorship of some senior developers. We think APIdock is a pretty awesome result and huge thanks go to our team of emerging Rails superstars:- Hannu Pelkonen
- Jyri Tuulos
- Ville Lautanala
The summer is starting to be over and that means the super-active development cycle of APIdock will slow down. We will continue to maintain the app, fix any bugs that are found and concentrate only on absolute key features.
Hopefully you’ll enjoy this first installment of APIdock. In any case, let us know what you think.
Test-driven development (or even Behaviour-driven development) is increasingly popular, but sometimes old habits make you write tests afterwards – just to keep your test coverage up.
This is just plain wrong.
If you’ve never seen your test fail, how can you know that you’re testing the right thing? Let’s imagine we were trying out XMLBuilder for the first time:
module Demo
def self.build_xml(xml)
xml.parent do
xml.child :id => 1
end
end
end
Could it get any easier. We already have a parent tag. Now let’s write the test afterwards:
require 'demo'
require 'rubygems'
gem 'builder'
require 'builder'
describe Demo do
before(:each) do
@xml = Builder::XmlMarkup.new(:indent => 2, :encoding => 'UTF-8')
Demo::build_xml(@xml)
end
it 'should have a parent' do
@xml.should match(/
Indeed, it seems that we have a parent. And our test coverage is blasting 100%.
However, just out of curiosity, let's try writing an invalid test:
it 'should not behave like this' do
@xml.should match(/THIS WAS NOT IN MY XML/)
end
It still passes. Why? Well, XMLBuilder's method_missing happens to catch RSpec's should method. All possible matchers just pass. When outputting XML everything could seem to be in order.
And this is not the only problem. I've even seen cases, where someone is using a clever doas(:username) helper to run tests under a certain user. Too bad that the helper method itself happened to be broken and even the craziest tests passed.
I pretty much assume that if a certain code block is not unit tested, it's broken. The same goes with tests: if you haven't seen a spec failing before implementing the feature, there's usually something wrong with the spec.
