So...I think this will officially be the first of many video logs, or vlogs, to come. :)
Clarification: Where I said that if I see another video I'd scream, that was not about Flatiron. Rather, it was criticism of all my past online learning environments compared to how good Learn.co really is. Sorry for any confusion on that point. When I first started learning through Learn.co I was astonished at how much better an approach it provides, contrasted with so many past instances where I had to watch a series of pre-recorded lessons with no immediate technical support to understand a lesson.
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.
I began my journey as a FS Web Development student in the first week of April. I am a quarter of the way through the curriculum and would like to share some patterns that I have noticed in my learning in hopes that it will be of some help to any other beginning FS student.
What I have learned about my learning:
- Get comfortable with being uncomfortable with broken code. In fact, get comfortable with breaking and redoing or refactoring code to higher efficiency. In a phrase, think in drafts. Writing code is not unlike writing a paper that is too wordy, uses overused terms, or is poorly formatted. Working code is not necessarily "good" code. All of this is part of the ongoing process of programming. Think: Less is more. Simplest or abstract code is the good code. Although, I grant that for beginners that the "efficient" is relative to our experience and what little we know. So be patient with yourself.
- Read test specs carefully and plan accordingly. As great as it is to have pre-written test specs, don't make the test specs a crutch. Remember this is a learning environment intended to simulate and teach; that is, to train as you fight, figuratively speaking. This is to say, you need to learn the way a programmer is expected to program in the real world or learn by doing as programmers do. However, Learn.co is still a teaching environment and not the real world. Therefore, plan and think, as opposed to slipping into autopilot--because it is possible up until a big challenge comes along and appears wholly unfamiliar on top of whatever labs are supposed to be challenging all their own. Don't get me wrong! These lessons and labs are scaffolded to comprehensively challenge you. But this does not rule out the personal responsibility to review, take some notes, and make connections to prior knowledge; assimilating knowledge, while consistently taking in entirely new experiences.
- Strategize, strategize, strategize! Object-oriented ruby, for example, will begin to introduce you to more realistic interaction with code, where you will code in one file while having to pause work on that file to accomplish some working code in another to enable the prior file to work. The implied task is that you will need to understand what to code in some necessary order. This makes the previous steps crucial.
- Think about your thinking and approach. For example, when you make an error, and whether you are able to resolve it quickly or not, take a moment to understand how you got to that point, whether your code is passing or failing the tests specs. In terms of a failing spec, think: What am I missing in this method/class/lab? What does the test spec say? Does my code address every facet of what the spec requires? (On the latter, all but a missing piece of code could be causing an error to be thrown, demonstrating while you have to think both with and beyond the given test specs! Stated inversely, all your code is set to work if one piece of code weren't missing.) So you kind of have to be a Sherlock who must really observe your code to embrace the possible problem that just isn't popping out at you despite having run yourself through several loops to figure out why your code is not working. And in terms of a passing spec, ask yourself: How did I accomplish this? Do I know and understand what I did to achieve this success? Implied task: Take time to evaluate your learning, even if you are a high-speed FS student with previous experience.
- Evaluate and document (summarize in your own words) what is being asked of you to accomplish a particular specification(s). Although Learn.co has built-in tests for you, you still have to do the work of thinking. As you progress through the curriculum the tests will become less and less specific. There will be gaps in the logic of the test specs that require you to fill in the blanks for how you get from one end of a problem to its expected outcome or output.
- Remember that computer programming's technical and essential purpose: To solve real-world problems. You should be excited by the presentation of a problem to solve, as opposed to feeling bothered by problems. So to further break a broken record, learn to love problems so that you can get to the place to appreciate how your work as a programmer can improve people's daily lives, because that is what it's all about at the end of the day.
Dig deep. Think. Code. Evaluate. Adapt. Keep going. :)
Originally published at http://wayofthecode.com/.
Here is a great message from the dean of Flatiron School, Avi Flombaum.
"Work hard, be nice, stay positive, and have faith."
It was a long time ago actually that I took a nascent interest in coding at all. In the spring of 1996, I completed my high school freshmen enrollment schedule before graduating middle school. The fall came, and I found myself in a computer programming class learning BASIC. At the time I felt intimidated by not only the programming language, but especially the other students who seemed to have prior experience and were keeping up with the teacher. It didn't click for me at that time. I visited my guidance counselor and got out of it. It would be years before I'd ever seriously look at code again. Instead, I took a serious interest in music for the remainder of my high school years, all the way through college and meanwhile harboring a deep love of tech.
In 2005, I graduated from the University of Florida as a music educator. Five years later the county cut my music position after I enlisted in the U. S. Army Reserve in 2010. So from 2011 onward I spent years on and off active duty, bouncing between the Middle East and the United States from 2012 until the present. Throughout all of these years I really wanted to code. In fact, it grew to the point that I knew I didn't want to teach anymore. I still felt that it was beyond my ability until I met my good friend, Staff Sergeant Myers, who encouraged me to take the plunge because he had seen my raw potential in tech whether as an information technology professional or software developer.
In short, while I deployed to Kuwait in 2016, that year proved to be what I consider the most crucial year for tech and my country (US), whether one was a systems administrator, cybersecurity professional, and/or a coder. In my eyes, 2016 was a pivotal year where the virtual world and the real world coalesced, or maybe even collided, in perhaps a perfectly unintended way. I was both riveted and dismayed by the entirety of 2016, and the role tech had within it. Something ignited within me that year, such that I formed a plan to get educated and experienced in tech some way, somehow.
My values were ignited that year and were challenged! And my passion for tech suddenly had deepened with meaning and purpose. All I needed was the means to act on my vision to create, that is, to code and collaborate on health-conscious technologies. Why? 2016 was a call to action. That year showed me that the unintended consequences of things we develop without any ethical foresight and preemption could have real-world implications--particularly in the areas of privacy, security, and epistemology or truth. That year also proved that software developers (or engineers) have a philosophical imperative to create with a conscience. Apple made a subtle but powerful video advertisement titled, "Designed by Apple in California." One portion of the video asks the following: "Will it make life better? Does it deserve to exist?" One can hate Apple's high-walled ecosystem of products, but we certainly cannot doubt their intention and caring thoughtfulness about user experience.
Finally, the current business model for the most popular web platforms enlivened me to the importance of the way web technologies are designed. For instance, I would encourage moving away from user interfaces and experiences that are inherently meant to commoditize the user. What do I mean? Perhaps define and create better social media platforms that do not psychologically and physiologically exploit the user's baser instincts (e.g., dopamine-fueled scrolling on bottomless feeds and a token economy of "Likes.") To wit, I think existing web and mobile technologies are amazing! But I believe that we can do better, and I would like to be part of shaping a future that cares about the mental and social well-being of the user. I believe learning software development enables me to have a seat at the table and even perhaps help to remake the table for a better social web and real-world experience.
Shortly after writing my previous blog post I jumped headlong into my final Intro to Ruby Lab (OO Tic Tac Toe) and completed it. I think it didn't take me long to refactor the code because I have prior experience with creating objects with classes in Java. (Cringe? LOL) In case, you haven't already read my about page, I completed an Introductory and intermediate course in Java at the University of Maryland University College online between the timeframe of Fall 2016 and Spring 2017. So it was basically a matter of a transliterated understanding of how Java classes work uniquely compared to how Ruby classes work.
This is a lab the requires that I refactor all of my procedural code for a Tic Tac Toe game to object-oriented programming. This entails removing certain arguments from many of the methods I created due to the lossy and buggy potential of continuously passing around the same value. Also, the procedural code makes scalability a nightmare; to expand functionality and behavior. You'd essentially have to re-write old code and then write entirely new code to expand the application. Conversely, using an instance variable wrapped within a class method is a better and less buggy practice. This is what I understand so far from my reading and labs in Learn.co
I just started this lab. I'll show you my results later.
Completed the biggest project yet in my introduction to ruby on Learn.co. :)
Short and sweet.
I was working on the Tic Tac Toe Game Status lesson in Learn.co and got stuck on a particular method--the #winner method. I got frustrated because I was just not able to abstract what was needed to solve the test problem. So I got up and watched television.
"David! Isn't that irresponsible and a time waster?"
Ordinarily, you'd be right. But no, it was not a waste of time. And it was a mature and responsible response to the moment of frustration. I got up and walked away to do something completely different. And on top of that the very show I watched hit on the very thing I was struggling with from quite an esoteric angle. (The show was HBO's "Here and Now," by the way.)
When I was done, I plopped back down in front of my computer and in under two minutes, I solved what I had initially toiled over for about an hour prior to walking away from it.
Life is not all logical and clean and neat. It's ugly and beautiful and random and scary and amazing, and so much more. Sometimes you have to let go in order to learn real control and discipline.
Take it or leave it. :)
Lastly, I did ask for help with other things earlier on in the lesson. You gotta let go and ask for help. This is a form of strength and maturity!
What does it mean to write code that is both efficient and eloquent? It means we rely on abstraction. A method is a form of abstraction.
While reading my lesson called Rspec Fizzbuzz, I learned about the Fizz Buzz Test. It's intriguing! Check it out here: Fizz Buzz Test.
Description from the site:
"The 'Fizz-Buzz test' is an interview question designed to help filter out the 99.5% of programming job candidates who can't seem to program their way out of a wet paper bag. The text of the programming assignment is as follows:
Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print 'FizzBuzz'."
The site's author is pretty snarky, but his sentiment is well-heeded. A computer programmer should be able to problem-solve beyond wrote skill knowledge and proofs. Here is a blog post talking about it and an excerpt below:
"FizzBuzz was presented as the lowest level of comprehension required to illustrate adequacy. There's no glory to be had in writing code that establishes a minimum level of competency. Even if you can write it in five different languages or in under 50 bytes of code.
The whole point of the original article was to think about why we have to ask people to write FizzBuzz. The mechanical part of writing and solving FizzBuzz, however cleverly, is irrelevant. Any programmer who cares enough to read programming blogs is already far beyond such a simple problem. FizzBuzz isn't meant for us. It's the ones we can't reach – the programmers who don't read anything – that we're forced to give the FizzBuzz test to."
With all this said, it is my plan to complete at least one coding challenge per week.