Update on my wiki

Since i last wrote, i have gone in a few directions trying to get started with my apprenticeship wiki task, got a bit stuck, talked to Enrique a lot, thought a lot, and i think i’m on track now.

My first mistake was to focus on the test framework. I was pretty pleased with my given/when/expect framework, and it actually sort of worked, but it wasn’t really necessary for what i needed. In the spirit of “the simplest thing that could possibly work”, this is the bare minimum you need for a testing framework:

def assert_equal(actual, expected)
  puts actual == expected

My second mistake was to get carried away with making a web interface. I learnt a bit about WEBrick and how to embed ERB into a web page. That will become useful later, but it was the wrong place to start. After i had done all that experimenting, i still didn’t have anything remotely like a wiki framework!

Enrique asked me, “what is the most important part of the wiki?” – the answer is: content. If i have no content i have no wiki. So i am making it as basic as possible: creating a Page object and assigning it some content. Then i am moving on to a PageFactory that has the responsibility of finding pages. The pages may be stored in a database, filesystem, or even just in memory. It doesn’t matter for the moment. Whatever i decide to use, the PageFactory will deal with it.

My progress is now on github so you can follow along with my progress if you wish. The repository is sermoa/licky – licky meaning ‘little wiki’! :)


A testing framework

Enrique has amended my task so that i cannot use any existing testing framework, not even Ruby’s built-in Test::Unit. However, i must practice test-driven development! Ha ha ha!

So here i am trying to ponder how to write a unit testing framework. Which is actually really nice because i get to decide the syntax i would like to use, and maybe – just maybe – i’ll come up with something that suits me really well and i’ll use again.

Enrique pointed me to the Given specification framework which i like because it uses the BDD ‘given/when/then’ approach for unit-level specifications. I’m already used to this kind of format for Cucumber features. Effectively, we use ‘given/then/when’ for Rspec, but it’s not made explicitly obvious. My comments in this trivial example should make it obvious:

describe "example" do
  before do
    @counter = 1             #(given)

  it "increments the counter" do
    @counter += 2            #(when)
    @counter.should == 3     #(then)

Now i think i could make the ‘given/when/then’ more obvious, and i can also simplify it. I might actually change ‘then’ to ‘expect’, meaning i can do away with the ‘should’ method. Effectively i’m saying that whatever is in the ‘expect’ block should return true, otherwise the spec fails. Here’s what i’m thinking of:

spec do
  given { @counter = 1 }
  when { @counter += 2 }
  expect { @counter == 3 }

I suppose this is what people call a DSL – a domain-specific language. That is the kind of language i’d like to use to write my specs. I’ve never written a DSL before, but i’m excited by the idea of being able to write specs like this, so i’m looking forward to giving it a go!

A little voice in the back of my head is telling me i’m going to have to finally understand ‘lambda’ properly. Lambda is one of those things that never sticks in my head. I can look it up when i need to and blunder my way to making it work, but i never really understand what it’s doing or how or why. I have a suspicion that i’ll be making extensive use of ‘lambda’ in my testing framework! :)


I am pleased to say that today i have been offered an apprenticeship under Enrique Comba Riepenhausen and i have accepted! From this moment on we have entered into a formal mentor-apprentice relationship where i will learn as much as possible from Enrique, and Enrique will mentor me to become a better software crafter. I expect it to be hard work but very rewarding.

I am proud and honoured to have been given this opportunity. I am glad that it has become official because i need my learning to be accountable to somebody. I am great at starting new things but really bad at following them through. To be answerable to Enrique will be very good for me, and i know that there is a lot that i can learn from Enrique.

My first task is to write a wiki engine in pure Ruby, with no libraries other than a testing framework. So no Rails, no Sinatra, no Mongrel, no plugins. This is to teach me the real core of Ruby as a language, without relying on other people’s code for shortcuts.

I guess the first thing i need to figure out is how to make the application listen for HTTP requests. Which i can honestly say right now i don’t have the faintest clue! Let the learning begin!