Sometimes the simplest solution is the best. I spent many frustrated minutes trying to get RSpec to mock calls to the built-in SOAP libraries, each time coming back with very strange errors about “SSL not supported” or “ssl_config not set”. Lots of headscratching over that one…

Turns out I was approaching it from an over-engineered and awkward angle. I started out writing code like

@handler = SOAP::HTTPStreamHandler.new(SOAP::Property)

and ended up writing code like

(in the lib itself)

def make_soap_call(soap_request)
... soap calls ...

(in the spec)


So the lesson here? Think carefully about your method structure so as to facilitate writing your specs in as painless a way as possible.

(N.B. Thanks to Lee Hambley for steering me out of complexity’s way.)


So, James and I have been working for the past couple of weeks on Collaborific.com, the collaborative fiction site where friends take turns to tell the next part of their stories.

The basic concept is down: Stories are made of sections called Fics. A user starts a story, sets an (optional) fic length, then invites people to work on it with them. Once a user submits their fic, it is down to the next collaborator to work upon their part of the story.

So far, we’ve done our best to stick to a rigid BDD/TDD work ethic, where we write our behavioural tests in Cucumber and our unit tests with Machinist and Shoulda *before* we write our code. We’d both had some basic Cucumber experience previously but this really gave us a chance to flesh out our knowledge so we jumped right in and got to grips with scenario layout and custom step definitions. There was something of a workflow learning curve and we haven’t always stuck to the strict test-then-code principal but it’s been a lot of fun so far and I feel like it’s making us think more about the code we’re writing.

Featurewise, we have the basic fic-writing down and users can already sign up and work on stories together. I also added a simple RSS feed mechanism to allow people to subscribe to stories in their feed readers. This was very easy to do and I’m proud of how dry the code is (plus the cuke test automatically asks w3.org for RSS validation at runtime). James has really gone to town on the Unit tests with Machinist and Shoulda plus he has the heroku app talking to GMail SMTP to send out story invitations to potential collaborators.

What we’re looking to add (besides more tests) is a more organised approach to site layout and user flow – some kind of notifications dashboard, a more personal approach to the use profile page, avatars, statistics (how long people take to write their fics, perhaps with a coloured chart), story/fic ratings in digg style etc. We’re a way off launching a proper 1.0 but I feel like we’ve got a solid start in.

Coming next techonologywise is RSpec – we have a pragmatic text which we’re both reading through to see how we can use it to improve the definition of Collaborific.com. In the coming weeks I hope we can really bulk out our tests and specifications to cover every aspect of functionality properly. As ever, it’s hard to know if you’ve written all the right tests but I suspect each bug we come across in future will give us a new test to write and it will end up being like a painting – never truly finished, you just reach a point where what you have is good enough.

I also started taking steps towards learning typical security vulnerabilities in Rails apps and discovered our app already suffers a number of weaknesses which I hope we can close out and manage properly with our future commits. I’m actually going to use Cucumber to produce a security.feature which will automatically run some security attack vectors (request manipulation, XSS, injection etc) to help future versions be more robust.

If anyone knows of any good automated vulnerability testing frameworks for Rails then please do add a comment and let me know!


Today, frosty and myself began work on Collaborific, a simple rails app for writing collaborative fiction. We did some buddy programming making a simple start with Cucumber feature outlines leading to simple code surrounding the signup process – nothing too complex but I feel like we’ve started out on the right foot with good behaviour driven development. Should be fun to see how it turns out!

Here’s the wonderfully pleasing site of a set of cucumber scenarios passing with green:


This week, I wrote Rubex, a very simple interface to Ruby’s regular expression engine in Sinatra using Haml for the markup. Soon there will be Sass, Ajax and tests.

As a quick deploy, I decided to give Heroku a try and it turns out it’s very very nice. From my git working directory, I typed:

$ gem install heroku
$ heroku create rubex

This created a remote point in my git repository pointing to rubex.heroku.com. Now I can enter:

$ git push heroku master

And my local repository gets pushed to Heroku with commit hooks to start the app (in this case, run the config.ru file to start Sinatra). And there we go. Easy app deployment for free. Go Heroku 🙂

So I’ve spent the last three years professionally working on projects dominantly within C# (and, consequently, the .NET framework on which it sits). I’m going to discuss the tools and techniques which tend to surround the Microsoft ecosystem when it comes to developing applications for Windows and stack it up against web app development in Rails and associated tools and principles.

Let’s start over in the Redmond camp. .NET development in the real world always happens within Visual Studio (ok, it’s possible to work in an editor of your choice, invoke the SDK components/compilers manually and write some batch files to automate tasks and stitch a workflow together, but practically, everything happens in the one-stop-shop of VS) and this ties you down to working in Windows. Microsoft tech, Microsoft rules etc.

Visual Studio does a lot for you – syntax highlighting, refactoring tools, directory organisation, wizard helpers for project types and test authoring, interactive debugging, source control etc.

Some of this is very nice. I have yet to see an interactive debugger as good as Visual Studio’s – everything is available for closer inspection, the exceptions and stack traces are clear and logical and the ability to attach debugger to a remote process is highly useful in a distributed application. The on-the-fly syntax checking is largely very good and error messages always point to the problem precisely .IntelliSense (code completion) is also a handy tool for peeking into a namespace’s methods, a class’s members and any XML documentation associated with an object; basically a memory jogger for the structure of a codebase without needing to look it up separately.

The .NET framework itself is vast and contains libraries for virtually all common boilerplate tasks and objects (with a few notable exceptions – lack of an RTSP implementation being a major one I’d cite).

All of this expedits the programmer’s ability to jump in, get coding and come up with something that compiles and does complex tasks without undue boilerplate stress or extended debugging time – the .NET libraries are guaranteed to do as they say on the tin because you’ve paid Microsoft handsomely to ensure this is the case.

But is this mammoth codebase of libraries, time-saving tools and utilities, undersigned by Redmond really that great when you’re working on an industrial strength project? Where are the specification authoring tools and frameworks? How do you keep track of code behaviour without a clear spec and testing framework? Ok, unit testing got bundled into Visual Studio 2008 but it’s a bit of an afterthought and clearly designed to be tagged onto existing code after it’s written.

My feeling (and actual experience) is that projects in Visual Studio can be written quickly but leave a team wide open to an infinite support scenario since so much of the code is unspecified and untested. It is certainly possible, with care, to do it properly and end up with code that is well defined and fully testable. But this is rarely the nature of the beast since, when joining a company who uses Visual Studio, the initial code will have been set up already and the authors will have gone with the Microsoft flow and just dived right in.

Perhaps it gives a manager a feeling of safety to know his team can access code quickly and just get writing but it was thinking like this that led to the advent of Basic (and that worked out soooo well…). Managers who know just enough to be dangerous, typically are dangerous and poisonous to a project’s beginnings. A codebase and culture without automated specification and  testing will almost never recover and I feel Visual Studio lets programmers down on this front. It’s all very well being able to write cool software quickly but if you can’t guarantee it works then the devils will creep out from the detail when the project hits critical mass a couple of years in.

On the deployment side – there is no package management framework where dependencies can be stated and automatically resolved. Patches and their changes must be manually tracked and it turns out that this is a hard problem to solve properly and that rolling your own framework in addition to maintaining your application is a task most companies don’t have the luxury of dedicating proper time to.

A brief note on version control. The default for Visual Studio is SourceSafe, which integrates with the environment fully and is very very basic. No branching (!), file locking for all edits (great for when your codev is on holiday in the hills for 3 weeks) and a tendency to corrupt the repository files (which are actually implemented in SMB filesharing!). Here’s a great rundown of SourceSafe’s shortcomings. If you want to spend a lot of money, you can get Team Foundation Server, which scales better and does allow (somewhat awkward) branching. Sadly, this still locks files for edits and relies on a central network repository across the network. Sad face.

Over to the Ruby/Rails camp and we have a very different world. We’re not hemmed in by an IDE, all tools are free and open source and a bustling community is ever producing more neat tools to make your life easier and your project better.

The very nature of a project in Rails means you’re using a range of tools, each of which adheres to the Unix principles and does one thing well. Authoring a project is like being in a sweet shop and picking the right mix for your goody bag. Add GitHub, the mother of all sweet shops, and you have access to fork the code to your heart’s content. If you know what you’re doing then you have granular control of all the details. Boilerplate is still written but it is extensible – Ruby itself allows this idea through mixins, as I discussed briefly in my talk last week at Swansea University: core library classes can be extended and altered through the magic of metaprogramming.

What we have in Ruby, Rails and the ecosystem of open source projects, then, is a world of programmer freedom and choice. I start out with RSpec or Cucumber and specify my project. I write unit tests defining the inputs/output expected from my objects. And then I actually write my code and get the tests to pass. Now refactoring and regression testing is easy and my project will stand up down the line, so long as I stick to this workflow.

Using a source control system like git, the team can work distributed and in tandem with fast and cheap branching and no locking headaches. If your project is open source then putting it on GitHub links it into the community and gives a great frontend view to your code and commits.

Since Ruby code is terser, leaving much of the syntax implicit where necessary, code tends to be smaller than in C#. Often, the ideas expressed in Ruby are clever and pleasing to develop, compared with what is often in C# a drudge of syntactic hoop jumping to please the editor. Ok, .NET does a lot of heavy lifting for you, but the code you have to write to work with it is still unnecessarily large, unwieldy, and (let’s face it) ugly. C# reads like Java with delegates support thrown in. Ruby reads like poetry, gently spoken by kind, noble wizards. This in itself is a bonus, because (on some level) I think it makes developers happier when coding in it which is bound to have the positive offshoots of positive thinking – innovation, productivity, passion.

I can’t help but feel C# is rapidly being left in the dust (not unusual for Microsoft tech) and that the future is much more agile, extensible, interactive, smart, beautiful and free. I would encourage all C# developers (or any developers at all) to read around Ruby and Rails and consider how it is a step forward in technological terms. It will be good for your brain to ponder how abstracting away from the details makes the pure science of application development easier and more fun, and more stable and robust.

In summary, Microsoft’s C# and .NET work well in solving the problems they were designed to tackle. However, I don’t think they’re quite on track with how software projects should be structured and laid out and that it is far too easy to code into a corner and be hemmed in by your environment. Ruby, Rails, open source and the Agile programming movement all stack together to form a much smarter animal which I believe is coming of age right now and will prove itself throughout the industry in the next five years. Whatever Microsoft counter-attacks with, I can guarantee it will be only a shadow of what the open source ecosystem will have produced…

So this week I’ve been learning a few bits and pieces.

I watched the slides from a fascinating talk which details how Ruby allocates memory, handles garbage collection and how to build a tool to catch reference-based memory leaks. MemProf itself isn’t ready yet, but the slides show more manual processes you can go through to chase down leaks – useful skills to know, even languages as high level as Ruby can be leaky.

I’ve also been playing with Rails middlewares via Rack. Ryan Bates shows how to add a response timer to page requests via a middleware app. Code sample is on GitHub.

The first 5 chapters of Gregory T Brown’s “Ruby Best Practices” book are available for free in PDF format on GitHub. Well worth downloading and reading through. I haven’t gotten through them fully but a skim through the topics shows promise and I’ve added them to my (growing) reading list.

With my active hacking (currently the beginnings of the Watched.it website), I’ve been looking at adding a captcha to the beta registration page using Recaptcha. I may be slightly over-engineering the beta registration page but it’s all good for my learning to go through the process of integrating third party gems into a project.

At the SUCS Lightning Talks this week, James Frost gave a very nice introduction to Sinatra and some projects he’s been hacking on. He also gave a great tip on using the #=> markers feature in the TextMate Ruby Bundle. Adding “#=>” to the end of a line of Ruby marks the line for the bundle, then running the “Execute and Update ‘# =>’ Markers” command (by default ⌃⇧⌘E) makes the bundle execute that line of Ruby inline and dump the result into the comment. This is really handy for posting source code where you want to show the results alongside the code, giving the reader a greater understanding of what you’re doing. Neato!

Just finished the SUCS Talks session for the evening. Much fun! Learnt some interesting things about space battles, spam, Sinatra and full adders. My slides are up now at http://sucs.org/~talyn256/github.pdf if anyone would like a peek!