Subscribe: Corey's Ramblings
Added By: Feedage Forager Feedage Grade B rated
Language: English
branch  cucumber features  cucumber  features  git  history  methods  picture  rspec branch  rspec  sudoku solver  sudoku  working 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Corey's Ramblings

Corey's Ramblings

General thoughts not related to other stuff

Updated: 2018-03-06T01:45:39.498-08:00


Getting Cucumber/Webrat to talk to outside sites with Mechanize


here's a great link for me to remember on using Cucumber/Webrat/Mechanize to automate/test remote sites:

My current podcasts


Been listening to for a while

Astronomy Cast
Rails Envy
The Thomas Jefferson Hour
WNYC's Radio Lab
Pragmatic Podcasts
My History Can Beat Up Your Politics

Just picked up

This American Life (used to listen on the radio)
Stuff you Missed in History Class
The Moth Podcast
Dan Carlin's Hardcore History

Me meme



Well, I got it from enrique, so that's my picture. Here's the rules, I guess:

  1. Take a picture of yourself right now.
  2. Don’t change your clothes, don’t fix your hair…just take a picture. (should be super-easy with Photobooth)
  3. Post that picture with NO editing.
  4. Post these instructions with your picture

Practice Sudoku Git Repository Approaches


I'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[...]

Test Utilities using extension methods


So, 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.

We were writing some tests that need a couple instances of a data object. Well, my first test new-ed up the instance and added it to the collection. This instance needed to have the due date property set, so I did something like this:

Extension methods can definitely help do some neat stuff. I don't have to subclass, I can add methods by simply implementing an interface. This also gives me the ability to create interfaces that are focused on different tasks that my test fixtures might need, so I don't have to load up subclasses with unnecessary mixes of unrelated methods.