Skip to main content

Posts

Showing posts from June, 2012

Screen scraping with Nokogiri

So a few months ago I put together a side project at  http://www.myrecipesavour.com/  . Basically, the site allows you to put in the URL of a cooking recipe page and will then parse the recipe for your collection. So it turns out, reading data from another site is very easy with Nokogiri. The source code is available here  https://github.com/abreckner/MyRecipeSavour There is a lot I am going to cover in the next few posts based on this code base (like Devise and Heroku), but for now we are focussed on this file  https://github.com/abreckner/MyRecipeSavour/blob/master/app/models/site.rb So we are going to look at the add_recipe method. First we need to require a few packages require 'open-uri' require 'rubygems' require 'nokogiri' Unfortunately, I haven't yet figured out a heuristic for separating a recipe web page into a recipe's components (Title, Ingredients, Instructions, Amounts, etc...) but as a workaround, I maintain a catalo...

How DRY is too DRY?

One of the earliest development principles we learn as programmers is Do not Repeat Yourself or DRY for short. Copy and Paste are supposedly your worst enemies. Rather than rely on copy and paste, you create functions and subroutines and call them from your code so you don't have to reimplement it continuously. It also has the added advantage that if you need to make a change to that subroutine, you only need to make that change once. (Note: I realize that functions and subroutines are different entities, but for the purpose of this article they are interchangeable). Sometimes you come across 2 pieces of functionality which are very similar, so instead of copying and pasting, you merely instantiate your function/subroutine with different variables to factor out/handle the differences, even where the core functionality is the same. For example, you might have a Customer object and a Vendor object. Both customers and vendors have addresses and you need to send mail to them both...

We know JavaScript is weird... enough already!

So it looks like JavaScript is close to being considered a "real" language nowadays. There are frameworks which allow you to do MVC (like Backbone.js), you can use it on the server (with Node.js) and you can even use it to interact with datastores (via MongoDB). So why is it that almost every job posting you see for a JavaScript gig and/or every interview you go to that has a JavaScript component, asks you to interpret/debug (without using a browser) some esoteric fault of JavaScript that you probably wouldn't run into in a 100 years because you actually write decent JS? Like var cities = ["NY", "SF"]; cities.length = 1; console.log(cities); // outputs ["NY"] or var a = 1 + 1 + "1"; // equals "21" var b = "1" + 1 + 1; // equals "111" It's as if they are trying to say to you "Look at that piece of crap language you are programming in! You must be an idiot!" while at th...