Yesterday we verified that our Crawler was able to hit a document and, given the right selector, pull down a list of words and their frequency on the page. We also created a custom exception to be used whenever the selector fails to pull down the right content. I’m going to repeat this process today with the get_metadata_by_selector. If there’s time we’ll try to output another file with our data, otherwise that’ll be tomorrow’s homeworkd :D
Last night I got the Crawler passing its test for #get_words_by_selector. This morning I realize that when someone sends in a junk selector I want to raise an exception of some kind. Since I don’t know much about Ruby Exceptions I’m doing a little digging…Ruby has both throw/catch and raise/rescue so what’s the difference between throw/catch and raise/rescue in Ruby?
Continuing from our previous post we’re going to keep working on our Crawler and our specs to see if we can start pulling real data from our site.
As an experienced developer if you find that you are performing the same actions over and over naturally your brain will start to think “Hey, this isn’t very DRY”. DRY, or the principle of “Don’t Repeat Yourself” is pretty common dogma for most developers. How many times have you heard something like, “If you’re doing it twice, you’re doing it wrong.” Typically when I do an action more than once I start looking for ways to wrap the work into functions or objects. This process can easily lead to what some refer to as “Design by Configuration,” or breaking your work into configurable operations.
I’m a big fan of sites like RubyQuiz and CodeEval. In my opinion doing short puzzles and brain-teasers is a great way to explore a language. Here’s one such puzzle taken from CodeEval which asks that you devise a program to read in a file, parse each line and decide if it is a pangram or not.
The sentence ‘A quick brown fox jumps over the lazy dog’ contains every single letter in the alphabet. Such sentences are called pangrams. You are to write a program, which takes a sentence, and returns all the letters it is missing (which prevent it from being a pangram). You should ignore the case of the letters in sentence, and your return should be all lower case letters, in alphabetical order. You should also ignore all non US-ASCII characters.In case the input sentence is already a pangram, print out the string NULL
I did some cleanup this morning on the Options class and the options_spec, mainly to remove items that seemed like they shouldn’t be tested. Here’s where I’m currently at: