This blog no longer exists.
You will be redirected to something cool.

Tuesday, May 10, 2011

RSpec is really, really awesome

Tonight I found out that RSpec is coding zen. For real! It was the first time I'd written my specs BEFORE the code (like you're sposed' to) and it just made my job a LOT easier. Here's what happened:

I wrote the specs:
describe "#make_urls" do
  it "should replace /s with a +" do
    make_urls(["oranges apples"]).should == ["oranges+apples"]
  end
end

While I was writing the code, I'd accidentally used a method for string on an array. Upon testing the code, I couldn't, for the life of me, figure it out. Back in the day when I didn't use RSpec (last week) I'd be shutting down and restarting the Sinatra do-hicky and going back and forth to 192.168.1.more_ip:4567/get_page. However, with RSpec, I was able to tell right away that my code wasn't working. Magic! I'm sold on it.

I accidentally did this:
def make_urls(arr)
  arr.gsub(" ", "+")
end

Instead of this:
def make_urls(arr)
  arr.each do |e|
    e.gsub!(" ", "+")
  end
end

Friday, May 6, 2011

Breaking Ruby code up into methods

I wanted to try out RSpec so that I could more easily test my Ruby code, but had to break it up into methods. Going from this code to something nice and easy to test with RSpec was very difficult for me as I still have problems writing methods. After receiving help on StackOverflow on how to set up the methods, I was able to fill in the blank spots. While I'm not really "on my own" with writing methods, this was definitely a good exercise in getting me where I want to be with that.

In the same night, I was able to figure out how to use RSpec with the nice, clean Ruby code and to get my project up on GitHub. I still will have challenges ahead in writing methods as well as writing my specs BEFORE writing my Ruby code. Git also will throw a few curveballs at me as I continue to learn to use it. While difficult for me to really understand right now, RSpec is already helpful and Git is a godsend.

Here is the code after breaking it up into methods. Later I will show all of what I completed in a post about RSpec.

Sunday, May 1, 2011

Trying out RSpec for SERP checker

In my latest project, I am rewriting a PHP script that checks the SERPs of a website in various search engines. In the original PHP script there were several lines of code that weren't needed. There also are problems with how the script "pulls" links from Google... it's not really a problem, per se, but a strange way to go about it.

In adapting this code to Ruby, I decided to start out by just having it check Google SERPs, so the original PHP script has been edited in order to make my job of rewriting the script in Ruby a lot easier.

I intend, from this point, to use RSpec to better test and develop the script as I'm already finding a number of bugs that are making the development process a headache. I find that if I write tests, I can check whether or not the code is working without opening my browser and entering different examples that could break the code. Doing it manually is not only time-consuming, but it also makes it difficult to remember what conditions I've tested and which I haven't.

In this script, the user may enter several keywords and their website url in order to check where their website places in the SERPs for each keyword. At this point, I am working to make a clean list/array of keywords... removing any extraneous commas, spaces, newlines, and returns. A sample "clean" array would look like the following:

array = ['code gurl', 'RSpec', 'tennis', 'Sinatra',
  'Flying Spaghetti Monster']

In hand-testing (without RSpec) the code, I've come up with some problems/specs to keep in mind:

Cannot separate list by a space as the user is not required to use a space to denote a new keyword. Note: If a user enters multiple words on a single line without comma separation, they will be counted as a single keyword to account for longtail keywords. I think that covers everything.

The tests aren't written, but I do think that currently, the code would pass. However, if I had the tests written, I would haven't to wonder/worry if any changes to the code would break something. Currently in order to check that, I would have to manually enter the keywords (as pictured above) for each case and visually check out the results to see if it passes all cases. With testing it would just say "Hey, you passed this one, this one, and failed this one." Handy!

View the code here
Stay updated and follow the SERP checker project here