Archive for the ‘Ruby on Rails and Software Development’ Category
Posted by Rahoul Baruah on December 27th, 2008 under Beautiful Code, Designing Great Software, General, Ruby on Rails and Software Development •
7 Comments
I’m sure you’ve all heard the Rails 3 announcement. When I first found out my initial reaction was “fuck me“. But shortly after I was filled with a feeling of dread and general unease. And I didn’t know why ….
Firstly, a bit of history.
I first tried programming on a Commodore [...]
Posted by Rahoul Baruah on December 20th, 2008 under Designing Great Software, Ruby on Rails and Software Development, Writing Reliable, Bug-Free Code •
No Comments
I’ve recently been updating some old code - partly written by someone else, partly written by myself. At the time, I thought I had written this code really well; looking back on it now, it looks awful. Fair enough, I’ve learnt a lot - I want to look back on old code and [...]
Posted by Rahoul Baruah on November 21st, 2008 under Beautiful Code, Designing Great Software, Ruby on Rails and Software Development, Writing Reliable, Bug-Free Code •
No Comments
I’ve written up a new post at the Brightbox blog detailing how we are using RSpec and Cucumber to build acceptance tests for the next generation Brightbox systems.
Posted by Rahoul Baruah on November 19th, 2008 under Ruby on Rails and Software Development •
No Comments
I’ve done a quick write-up on the recent CSRF vulnerability on the Brightbox blog.
Posted by Rahoul Baruah on October 16th, 2008 under Designing Great Software, Ruby on Rails and Software Development, Writing Reliable, Bug-Free Code •
No Comments
Last night I gave a talk at Geekup about RSpec and RSpec User Stories.
Telling Stories With RSpec
View SlideShare presentation or Upload your own. (tags: ruby rails)
Thanks to Ashley Moran for talking it through with me.
UPDATED to use Slideshare to display the slides.
Posted by Rahoul Baruah on September 24th, 2008 under Ruby on Rails and Software Development •
No Comments
Rails 2.2 deprecates the inbuilt Rails MySql driver and you are recommended to use the native MySql gem instead.
Unfortunately, when I tried to install this on my fresh Leopard box I got:
Error installing mysql:
ERROR: Failed to build gem native extension.
Followed by a load of guff about options.
After a bit [...]
Posted by Rahoul Baruah on August 5th, 2008 under Beautiful Code, Designing Great Software, Ruby on Rails and Software Development, Writing Reliable, Bug-Free Code •
No Comments
Two (related) thoughts on “The Specification is the Documentation“.
One of the things that I like to do, when developing, is to start with a sketch (you know, with 95g/m2 paper and a 6B pencil) of how the UI will look. There are two reasons for this. Firstly, it helps communications with the client [...]
Posted by Rahoul Baruah on August 1st, 2008 under Beautiful Code, Designing Great Software, Ruby on Rails and Software Development, Writing Reliable, Bug-Free Code •
1 Comment
In a former life I used to write “functional specifications”. These were long, dense, hard-to-read documents that detailed what an application (not yet written) was supposed to do. I would spend (literally) weeks typing these things up, the customer would read it, think they understand and I would quote them based upon the document. [...]
Posted by Rahoul Baruah on July 10th, 2008 under Beautiful Code, Ruby on Rails and Software Development, Writing Reliable, Bug-Free Code •
No Comments
One of the great advantages of using mock objects to test and specify your objects is that you concentrate solely on the thing you are testing.
If you weren’t using mocks to tests that a controller re-shows the “new” form if given an invalid object, you would do post :create, :model => { … } where [...]
Posted by Rahoul Baruah on July 9th, 2008 under Beautiful Code, Ruby on Rails and Software Development, Writing Reliable, Bug-Free Code •
1 Comment
A very interesting article about how DRY you should be in your specs.
http://lindsaar.net/2008/6/24/tip-24-being-clever-in-specs-is-for-dummies
Personally I agree with everything said. Readability comes first, even at the expense of efficiency and DRY; “be nice to those who have to maintain the code”. The really interesting thing though is the example is actually quite DRY - it’s more [...]