Yes, it looks different here, doesn’t it. That’s because I’ve flipped the switch, loosed the reins, unharnessed the wild boar and turned on Vanilla.rb. Here’s my work-in-progress tutorial: vanilla-rb-tutorial.

It’s going to be a bit broken around here for a while, but the idea there is to motivate me to fix things. You won’t be able to log in (since you can’t register), which means no creating or editing snips for you lot at the moment. You can, however, see what the raw contents of the snips are - just add .raw to the end of pretty much any URL

You can, of course, download vanilla an play about with it locally; the current authentication scheme is trival when you’ve access to the filesystem.

Some notable things that I need to consider in more detail:

• Feeds - an atom one is available at the moment, but it’s implementation is pretty crufty
• Commenting - (Ticket 5)
• Better internal parsing (Ticket 8)
• Muchos other stuff, including documentation about how other folks can use vanilla!

So - here we go!

Already, We Have Vanilla Goodness

After some furious bugfixing (thanks to the strictness of Firefox 3 for chastising me!), things are running quite smoothly here. I’ve written the starts of a conceptual vanilla-rb-tutorial, please do check that out.

I also limited the number of blog posts¹ that appear on the home page to 3, and added a link to the full blog that shows the most recent 10. Making this change with vanilla was utterly trivial – the start snip originally included the blog snip directly, but rather than do that, I can just use the underlying kind dynasnip to grab the 3 most recent blog snips and display them in place.

I really love how flexible vanilla makes the content it stores. I’m looking forward to playing around more!

¹ Oh, and just because I can, this blog post was written using textile, whereas the others use Markdown. All on the same page, naturally. Add .raw to the url for this post to see!

[snip 'comments' cannot be found]

Speaking with Luke, I just had a thought about Test Driven Development:

it pushes implementation to parts of the application where developers are most proficient at testing.

Our concrete example here is a signup process, which has a number of steps that might be presented in a different order (a ‘track’) depending on what’s more relevant to the visitor signing up.

The simplest implementation

I feel like the simplest way to implement this is have a single, large form posting updates to the account, and present them in different orders accordingly. Certainly there could be some validation issues as the record is populated over a number of different updates, but I think in our case, that is fine.

I’ll state right now that I’ve no evidence that this would be the actual simplest implementation; that’s just my hunch, and I could be wrong.

Running away from the view

However, this pushes most of the logic around the presentation of the different signup ‘tracks’ into Javascript, and away from our beloved Ruby and shoulda.

I can’t speak for Luke, but Javascript testing is something I don’t have a wealth of experience in. Worse still, we would probably want to include integration tests, pushing us towards Selenium or another browser-driving mechanism. I’ve not had enough positive experience writing Selenium tests to want to add them to our codebase without hesitating.

And so we’re torn. We want to write tests, but we want to write tests that we know are good. And we’ve got the most experience, and the most comfort, writing tests in Ruby using test/unit and shoulda.

A local minimum

Here’s the crux: if we’re driving the implementation by writing tests, and we are only really comfortable writing tests using shoulda, this will ultimately drive us away from a Javascript-centric solution, towards modelling signups explicitly through the controller and model.

So while we might end up with a pretty simple implementation that satisfies our sets, this might be a local minimum complexity.

I think the lesson here is that we need to become competent (and indeed fluent) in several different testing mechanisms if we’re going to be able to effectively arrive at simple implementations.

If you only have a hammer, everything looks like a nail.

Time to start learning some new testing techniques, I think.

leave-a-comment

Speaking with Luke, I just had a thought about Test Driven Development:

it pushes implementation to parts of the application where developers are most proficient at testing.

Our concrete example here is a signup process, which has a number of steps that might be presented in a different order (a ‘track’) depending on what’s more relevant to the visitor signing up.

The simplest implementation

I feel like the simplest way to implement this is have a single, large form posting updates to the account, and present them in different orders accordingly. Certainly there could be some validation issues as the record is populated over a number of different updates, but I think in our case, that is fine.

I’ll state right now that I’ve no evidence that this would be the actual simplest implementation; that’s just my hunch, and I could be wrong.

Running away from the view

However, this pushes most of the logic around the presentation of the different signup ‘tracks’ into Javascript, and away from our beloved Ruby and shoulda.

I can’t speak for Luke, but Javascript testing is something I don’t have a wealth of experience in. Worse still, we would probably want to include integration tests, pushing us towards Selenium or another browser-driving mechanism. I’ve not had enough positive experience writing Selenium tests to want to add them to our codebase without hesitating.

And so we’re torn. We want to write tests, but we want to write tests that we know are good. And we’ve got the most experience, and the most comfort, writing tests in Ruby using test/unit and shoulda.

A local minimum

Here’s the crux: if we’re driving the implementation by writing tests, and we are only really comfortable writing tests using shoulda, this will ultimately drive us away from a Javascript-centric solution, towards modelling signups explicitly through the controller and model.

So while we might end up with a pretty simple implementation that satisfies our sets, this might be a local minimum complexity.

I think the lesson here is that we need to become competent (and indeed fluent) in several different testing mechanisms if we’re going to be able to effectively arrive at simple implementations.

If you only have a hammer, everything looks like a nail.

Time to start learning some new testing techniques, I think.

leave-a-comment

Speaking with Luke, I just had a thought about Test Driven Development:

it pushes implementation to parts of the application where developers are most proficient at testing.

Our concrete example here is a signup process, which has a number of steps that might be presented in a different order (a ‘track’) depending on what’s more relevant to the visitor signing up.

The simplest implementation

I feel like the simplest way to implement this is have a single, large form posting updates to the account, and present them in different orders accordingly. Certainly there could be some validation issues as the record is populated over a number of different updates, but I think in our case, that is fine.

I’ll state right now that I’ve no evidence that this would be the actual simplest implementation; that’s just my hunch, and I could be wrong.

Running away from the view

However, this pushes most of the logic around the presentation of the different signup ‘tracks’ into Javascript, and away from our beloved Ruby and shoulda.

I can’t speak for Luke, but Javascript testing is something I don’t have a wealth of experience in. Worse still, we would probably want to include integration tests, pushing us towards Selenium or another browser-driving mechanism. I’ve not had enough positive experience writing Selenium tests to want to add them to our codebase without hesitating.

And so we’re torn. We want to write tests, but we want to write tests that we know are good. And we’ve got the most experience, and the most comfort, writing tests in Ruby using test/unit and shoulda.

A local minimum

Here’s the crux: if we’re driving the implementation by writing tests, and we are only really comfortable writing tests using shoulda, this will ultimately drive us away from a Javascript-centric solution, towards modelling signups explicitly through the controller and model.

So while we might end up with a pretty simple implementation that satisfies our sets, this might be a local minimum complexity.

I think the lesson here is that we need to become competent (and indeed fluent) in several different testing mechanisms if we’re going to be able to effectively arrive at simple implementations.

If you only have a hammer, everything looks like a nail.

Time to start learning some new testing techniques, I think.

leave-a-comment