I really enjoy gardening, but I am always late in getting seeds or plantings into the ground. With this in mind, I thought it would be cool to make a command-line-interface (“CLI”) app that can quickly tell me some basic growing information about fruits and vegetables and hopefully make me a more-timely gardener.

This led to the creation of Tardy Gardner. It’s a CLI app is written in Ruby and relies on the Nokogiri gem to scrape data from various pages of Cornell University’s gardening guides. After scraping the data, the app uses it to create various “vegetable” Ruby objects behind the scenes, and then the app makes information about the vegetable objects available to the user via command line prompts.

For anyone dabbling in Ruby or thinking of making a similar CLI app, here are the main lessons I learned from this exercise, in case helpful:

  1. Scraping has a run-time-cost. Know your math. Racing through my plans at inception, I jotted down that I would have to scrape only three webpages. Turns out, had I built the CLI app as I originally planned, it would have been 123 webpages. Big difference*. And, I wanted to do all this scraping as the CLI app loads, so that each vegetable object would have all of its data and that data could be used for sorting and outputting particular lists based on growth times. By the time I coded enough so that 62 webpages were being scraped and used to give life to 61 vegetable objects, the app was taking anywhere from 30 to 60 seconds to load. Patience is a virtue, but to me this wait-time was starting to feel too long for a little CLI app. So I decided not to scrape the remaining 61 pages and sacrifice some of the functionality of the CLI app for now.

  2. When using an instance variable within an instance method, always prefix the instance variable with @ or self. (e.g., @<variable_name> or self.<variable_name>). Even if you’ve defined the instance variable with attr_accessor, bugs can arise if you try to use just <variable_name> without @ or self. in front. Long story short, I incorrectly though that using attr_accessor to establish a setter and getter method for an instance variable absolved one from having to prefix the instance variable with @ throughout the rest of the class. I starting running into all kinds of problems under this faulty thinking, until I simply changed every instance variable to begin with either @ or self. . The funny thing was, using the “pry” gem to peer into how my code was working, I could tell that some instance variables worked fine without self. and without @. But for whatever reason, all of the instance methods within the particular class would not cooperate until self. or @ was in front of each instance variable.

  3. Remember upfront to tell git to ignore files you want ignored. This sounds simple enough, and it is, but in my newbie state, I would often create files like “scraps.md” or “todo.md” in my local directory, containing all kinds of comments directed only to myself, and I would commit and push my whole directory to github. Then, of course, I would find these files uploaded to github and had to figure out how to remove them. The simple thing I learned, several times, is to simply add the names of these files, or their prefix followed by the “universal” character *, to the .gitignore file in the local directory. For example, if you created a file in your project’s root directory called “scraps2.md,” simply put scraps* in your .gitignore file. Now git will ignore all files or folders beginning with scraps, and you’re protected from mistakes similar to the ones I was making.