2009-10-27T14:10:00.949-07:00here's a great link for me to remember on using Cucumber/Webrat/Mechanize to automate/test remote sites:
2009-10-20T05:00:33.695-07:00Been listening to for a while
2009-03-04T10:38:40.953-08:00I've been talking for a while about starting a series of git repositories that can be used as tools for doing focused practices, the first of which will be a sudoku solver. This is the story of my initial attempt at setting up the git strategy, having troubles, then having David Chelimsky help me find what I think will be a better way. I am just a beginner with git, so building these repositories is also a way for me to practice my own git-fu.I'll write about my initial, failed strategy, then explain the approach that David recommended, as well as paraphrase a bit on the approach we took to get there. Of course, I'm interested in other people's opinions and ideas, as well, so feel free to comment below or write a blog post. I'm planning more of these repositories, so I expect that experience will guide me to a better repository strategy.Goal: I would like to have a git repository that contains a set of cucumber features for a sudoku solver. These features would contain many sudoku boards of differing difficulty, allowing someone to bypass the initial bother of finding boards to use in practice session.While I'm building the features, I am also going to be writing a sudoku solver, as well. I want to maintain a branch with just the features in it, as that will be what is pushed to github.Attempt 1branches:master = cucumber features + step definitionsrspec = rspec examples + implementationapproach:As I add cucumber features on master, I then rebase over to the rspec branch. The rspec branch will always have the most up-to-date features from the beginning, so I can see if things are still working, as well as access them. The rebasing will put all the feature stuff at the start of my commit tree, so it will be a similar situation to someone who is using it after all the features are written.result: massive painThis worked great until I started having to make some small changes to the features/support/env.rb file to include my lib code for the features to run. Well, I did it in the rspec branch, since it wasn't related to the core features. Well, this caused some merge conflicts when I was trying to rebase the master over to the rspec branch. Plus, it was a bit confusing to me to have to jump from branch to branch depending on what I was working on.retrospective:I only got a reasonable idea of the differences between rebase and merge last week from Tom Kersten, so I had a bit of a naive view of its uses. I still like the idea of having a clean branch with just the cucumber features, but rebasing doesn't seem to be the correct approach.Why do I even want to have the cucumber features all placed at the beginning of my commit history on the actual implementation branch? Why not just merge? With hindsight (and perhaps a bit of foresight would have been good), my initial idea doesn't really hold much water. My commit history is based on the incremental development of the features, so trying to take more recent changes that affect my implementation and pushing them back to the front of the commit log just sounds like a recipe for grief. And, amazingly, it did end with much wailing and gnashing of teeth.Paraphrase/Summary of Conversation with DavidWhile David was making oatmeal, I explained the rebase/merge conflict problems. After explaining my approach, he started offering some ideas around using rebasing. Pretty quickly, though, he switched his questioning more towards why I was trying to do what I was doing. It didn't take long to get to the heart of what my goal was: have a clean repository that contained just the cucumber features that would be needed to begin implementation of a sudoku solver. Here's the suggestion that David offered, and the one that I'm going to switch to.Attempt 2branches:master = cucumber features + step definitionsimplementation = rspec examples + implementationapproach:Develop entirely on the implementation branch.Any changes in features directory are committed atomicallyFeature commits are marked prominently for easy ident[...]
2009-01-30T17:39:31.332-08:00So, I was working with Jeff McWherter on some TDD stuff in C# today, and I came upon a trick that I really like. When I used to do C#, I was working in the 2.0 version of the .net framework. This meant that, while I had cool things like generics and anonymous methods to help me out, I didn't have extension methods. Well, Jeff and I were working in .net 3.0, so I had the benefits.