Monthly Archives: May 2014

2014/05/30
Leave a comment
Uncategorized

To learn BDD with Cucumber, you must first learn BDD with Cucumber.

So I read about Cucumber a while back and was intrigued, but never had time to properly play with it. While writing my MQTT broker, however, I kept getting annoyed at breaking functionality that wasn’t caught by unit tests. The reason being that the internals were fine, the problems I was creating had to do with the actual business of sending packets. But I was busy so I just dealt with it.

A few weeks ago I read a book about BDD with Cucumber and RSpec but for me it was a bit confusing. The reason being that since the step definitions, unit tests and implementation were all written in Ruby, it was hard for me to distinguish which part was what in the whole BDD/TDD concentric cycles. Even then, I went back to that MQTT project and wrote two Cucumber features (it needs a lot more but since it works I stopped there). These were easy enough to get going: essentially the step definitions run the broker in another process, connect to it over TCP and send packets to it, evaluating if the response was the expected one or not. Pretty cool stuff, and it works! It’s what I should have been doing all along.

So then I started thinking about learning BDD (after all, I wrote the features for MQTT afterwards) by using it on a D project. So I investigated how I could call D code from my step definitions. After spending the better part of an afternoon playing with Thrift and binding Ruby to D, I decided that the best way to go about this was to implement the Cucumber wire protocol. That way a server would listen to JSON requests from Cucumber, call D functions and everything would work. Brilliant.

I was in for a surprise though, me who’s used to implementing protocols after reading an RFC or two. Instead of a usual protocol definition all I had to go on was… Cucumber features! How meta. So I’d use Cucumber to know how to implement my Cucumber server. A word to anyone wanting to do this in another language: there’s hardly any documentation on how to implement the wire protocol. Whenever I got lost and/or confused I just looked at the C++ implementation for guidance. It was there that I found a git submodule with all of Cucumber’s features. Basically, you need to implement all of the “core” features first (therefore ensuring that step definitions actually work), and only then do you get to implement the protocol server itself.

So I wanted to be able to write Cucumber step definitions in D so I could learn and apply BDD to my next project. As it turned out, I learned BDD implementing the wire protocol itself. It took a while to get the hang of transitioning from writing a step definition to unit testing but I think I’m there now. There might be a lot more Cucumber in my future. I might also implement the entirety of Cucumber’s features in D as well, I’m not sure yet.

My implementation is here.

Advertisement
Tagged , , , , , , , , , ,
2014/05/12
Leave a comment
Uncategorized

Knowing when to abandon a project

I like to finish what I start. It feels like a failure to me to not see a project to completion, which is mostly the reason why I persevered with my PhD thesis despite not particularly liking what I was doing every day, having no money and living with my parents at age 30. So it’s with a heavy heart that I decided to stop working on my videogame.

This thing goes back a while. Once upon a time in 1995 I think, I went to a friend’s house to play some games on his Amiga. One of them was Gravity Power, which was so cool that I wanted a version of it for the PC so I could play it at home. Since there wasn’t one, I decided I’d write it. And so I did.

The version I wrote back then was in C and x86 assembly, 320×200 graphics on one screen and crude but playable. It wasn’t particularly good though. At some point I decided I’d write a better version, from scratch, with what were then high definition graphics (640×480). I did but soon enough my lack of experience with a larger software project showed and it was hard to keep adding modifications to the gameplay. So I rewrote it in C++.

This was my 2nd project in C++, and it showed as well. I can’t remember much about this version, I’d have to go look it up, but at some point I decided to rewrite the whole thing from scratch again. I’d toyed with enabling networking in the game, and once I realised how much work that would entail, I made an executive decision: no networking. That way I’d implement everything else I’d wanted in the game but at least at last finish it.

And I did, the result of which can be found at sourceforge. It turned out alright, I think. But I’d come back to it yet.

A few years later the C++11 standard came out and I wanted to know it. My background is mainly C++ so I thought it would be inexcusable for me to not know the new standard of the language I know the best. The only way to properly learn programming is to write code, so in that in mind my plan was to write the networking code for Gravastar in C++11 and bolt it on the existing codebase. It was a lot harder than I had anticipated. I’d painted myself into a non-networking corner and decoupling everything was taking an enormous amount of time. C++ itself wasn’t helping, and the new standard had given me oh so much more rope to hang myself. I kept putting off working on it since it was so hard, getting distracted by other projects. Then I learned D, and my desire to write any more C++ dwindled to nothing.

I’d written enough of C++11 to get a good feel for it though, and I just didn’t want to work on networked Gravastar anymore. It just wasn’t fun. And since I was doing this in my leisure time, what was the point? So… I quit. I learned C++11, I learned that I still make a lot of design mistakes in code that’s not that old, and I learned that this time it’s just better to let it go. And once I’d done that, it felt like a weight off my shoulders.

I still want to write a game with a networking component. I just don’t want to do it in C++, or to adapt a codebase that had been designed in such a way to never accomodate networking to do it. It might just be time for a new project.