I made some changes to the way the menus work after my previous post, which explains this project. You can watch the video below.
At last, I am complete with my project. It took exactly two weeks.
The name of my project is True Crime Documentary Database. It offers a list film and television documentary film titles in the True Crime genre.
(Note: Although it indeed is not a database, its functions point in the direction of a database. The term "database" is used here loosely.)
I used the Nokogiri gem to scrape the site crimedocumentary.com.
I created an application that scrapes the category names, the URLs, and the documentary attributes that exist within each URL path. I had to scrape these link (image below).
The program should deliver a menu of options: to browse the documentaries by category or to see a full listing of documentary titles.
Selecting category delivers a list of documentaries displayed with their title, year, category, synopsis, and full synopsis URL.
Otherwise, if list all documentaries is chosen, then the user is taken to a submenu from which to select a title. Similarly, the selection displays the documentary’s details.
Building The Project
Now, based on my initial review of the HTML I felt assured that I could achieve this project based on what I had learned in the previous labs leading up to my CLI data gem. What I hadn’t given better attention to was the layout of the site and how it delivered the data. The categories of a film are front and center, while the documentaries generate (no HTML to scrape) in many places, except inside of category link paths in the right sidebar. Sadly, I hadn’t noticed this quirk until long after getting approval and having coded my scraper class. (With respect to object orientation, this presents some coding challenges. It would be hard to maintain the has a/has many object relationship that I planned.)
In the scraper class is when I realized I might run into trouble when I’d have to connect these objects in the CLI controller class. Sure enough, that difficulty arose. I worked hard to refactor the entire project from start to finish and ended up with a better product.
Something I encountered was that the number of links I decided to scrape tacked on at least 15 to 20 seconds of load time at the start of the program. Coincidentally, in one of my recent study groups, the instructor mentioned how it might sometimes be a better option to have the data load (scrape) upon selection by the user. I thought it was an excellent idea! However, given how far I had come and that I was already in the middle of rebuilding my program from scratch (I created a branch and merged later), it would have proven difficult timewise. So again, the layout and coding of the site presented a hurdle that made any new idea unfeasible.
Overall, I believe that I have met the requirements of the project by demonstrating that I have a good grasp of object orientation and working confidence in coding in Ruby.
- Simple ideas are still complicated when it comes time to code them!
- What you think is simple may not be simple enough.
- *Projects fan the flames of enduring appreciation for Google search! :)
- *This project was, *hard*! However, it I love it!
- *Coding is fun. Learning to code is fun and uncannily cathartic. O_O
Bottom line: The CLI data gem was a challenging project, while also gratifying!
Access the repository here.
I'll explain how it works later in the week. But for now I'm just celebrating having made it through the toughest part, which was building it and getting it to work. It took me a week.
I am one lab away from the CLI Data Gem Project. Although, I have gone over it to evaluate what I need to do to complete it.
Object-oriented Ruby has been one heck of a challenge so far, and I’ve enjoyed every moment, including the parts where I was stumped. I enjoyed the Music Library CLI project the most. However, the CLI Data Gem Project appears to be the most fascinating and open! By open, I mean that I like that I get to choose the content of my project, albeit with some training wheels still attached. But I digress… What the Music Library CLI project brought to bear regarding object relation is where I struggled the most. It was hard to quickly wrap my brain around the intricacies of how the objects were to be linked via methods. Moving forward my takeaway is to draw diagrams with a flowchart of objects to get the big picture. And since I am a big picture thinker, this is almost a must! I am a visual-kinesthetic learner. I must see and touch my solutions, or at least have some physical association with what I am learning.
On the more technical side of the house, these are the methods in the Music Library CLI project that gave me the most significant challenge:
Song Class Song.new_from_filename: Learned that I had to instantiate a new instance of Song.
Artist Class artist#add_song: The key to getting this to pass was the unlessconditional statement, which is the inverse of the if conditional. It just proved to be a far more elegant and efficient means of defining the method.
Music Library Controller Class All of the trigger methods took some careful reading of the test specs and greater thinking along the lines of iterating with an index–that is, Ruby’s each_with_index method, to be more specific. It saved the day! Also, I later realized that I’d be sorting objects, which reframed my entire plan of approach to elegantly and adequately coding specific list methods. It is important to remember that we are to take advantage of the object attributes to maintain well abstracted and efficient code throughout the entire project. So I called on the list of objects stored in the @@all class variables so that I could sort them, then call on their respective attributes to define specific list methods.
Overall, everything that I have learned has challenged me to think broadly–far more than I thought I already could. And the fact that I can learn to think more broadly than I ever have with coding has nurtured both a growing excitement and hunger to learn more.