Week 12: This Is The End

.............and we're done (almost)! I hope everyone had as much fun in this course as I did. If this is any indication of what the rest of my degree in Computer Science will be like, I can't wait for what else is in store for me. We've yet to hand in Assignment 3 and I can't wait to complete it. I would definitely recommend this course to anyone who enjoys problem solving and critical thinking, whether they are in Computer Science or not. Danny has been a great lecturer and support throughout the duration of this course, and I hope I will be able to TA alongside him at some point in my time at UofT. If there was a single thing I would have the power to change about my experience with CSC148 this semester, I would change the class time (because seriously, when you're a commuter student every single day actually starts 2 and a half hours before your first class). But even though it was annoying having to wake up early to attend this class I still enjoyed it. Some moments that stand out from this course were (play this song while you read the next few lines)

• Making a human binary tree in class 
• Danny's two-page long introduction to tic-tac-toe for Assignment 1
• Volunteering to answer a question in class without having listened to anything prior to the question, but Danny still prompting me in the right direction even though I was totally wrong
• Working on Minimax for three consecutive days having made no progress, but finally getting it on the fourth day
• Danny's use of the turtle module to demonstrate recursion
• Danny bringing in a stuffed animal to demonstrate the way an arrow changes direction on command

And finally, I would like to thank my greatest support throughout this whole course. Having stayed by me for all of CSC108 and CSC148, we've created a unique bond. Even though sometimes we disagree and other times I can't stand you, I really appreciate all of your help. I'll never forget our late-night sessions and even all that time you spent yelling at me for making stupid mistakes.
Thank you.

Week 11: Look How Far We've Come (Part 2)

I often expressed how I was nervous about implementing recursion in previous posts, and finally now near the end of the semester I can safely say: I'm still nervous. Maybe it'll take another year (or another CSC course) for me to get completely comfortable with the concept and implementing it in different situations, but for now I'm still not 100% solid. I think I should be okay with implementing recursion with trees, but I'm worried I'm learning a formula that I keep regurgitating for a different condition every time. Does anyone else ever feel this way?

I've been following along with some of my friends' slogs as the term has progressed, here are some of my favorite ones:

Zhilin Zhang: "3 Essential OOP Concepts To Know For Your Technical Interview"
Zhilin's post on OOP was great. Not only did it mention the key concepts of Object Oriented Programming, but it gave you a step forward in your knowledge of what employer's expect of you. There's more to Computer Science than just knowing how to code - it's about understanding concepts and applying yourself. This is what employers look for in technical interviews, and this is precisely what Zhilin was able to reflect on in his Medium post. A lot of what I appreciate about Zhilin's slogs is that he always remains focused on conceptual ideas rather than the nitty-gritty details of syntax and definitions. It's been a pleasure following his hipster Medium blog throughout the term.

Abhinav Chawla: "Mission Minimax"
I had the pleasure of working with Abhinav on Assignment 2, and sat by him as he "thought" and "sweat" and "worked". Although his slogs are always refreshing and flavorful, I enjoyed this particular post because he was able to reflect on his individual experience working with a specific concept. Abhinav is a friend of mine that I hardly ever see struggling with school work, and watching his gears turn and rust over this assignment was definitely an experience. Me, Abhinav, and Jahid sat together for hours working on this assignment together, and our logical thinking processes definitely clashed during that time. However, we pulled through and supported each other through not only this assignment but through this course as a whole, and it was an honour to have worked with them both.

Jahid Ahmed: "OOP"
This was probably one of the most well-written and detailed posts on OOP I've read in this course. Jahid took this post step-by-step, introducing each and every term and idea individually and slowly building up to classes and objects. The examples he used to demonstrate OOP were great, and the importance of OOP really hit home with his post. Jahid's attention to detail and references to individual lines of code were extremely thorough, and I would genuinely recommend a beginner in OOP to read his summary. Great job, Jahid!

Nagee Elghassein: "It's Starting to Link"
First of all, Nagee has a great sense of humor and the image he attached to this post instantly made it my favorite one. Other than that, it was great to read about Nagee's journey with Linked Lists as an ADT. I actually worked with Nagee to understand Linked Lists on Lab 7, and I agree with him in saying that this class makes it very easy to understand. The labs and class worksheets were great in that they helped us stretch our legs with LLs, and get us familiar with the types of things we can do with Linked Lists. Reading through Nagee's posts, it's easy to see that we are having a similar experience with this course as a whole - the instructors and TAs have been great and super helpful, and we're really enjoying learning the material.

There are lots of other slogs I've been following throughout the semester, these are just a few of my favorite posts from a few of my favorite sloggers. If you have any cool slogs you think I should read (including your own, if you want), let me know! I'd love to read them.

Week 10: Minimax PTSD

Recursion. Seriously...recursion. We had our second midterm this week on recursion and linked lists and I'm actually nervous. It's been a weird concept to wrap my head around since we started with it, and implementing it with binary trees gives me Minimax PTSD. I really hope I did well on this test (if not, I'm totally fine with the TAs being on strike and not marking them on time for finals... Kidding. Totally kidding).

Discussing ways to represent data in trees (post-order, in-order, pre-order) is fine, as is understanding the basic structure of them - but once it comes to traversing through trees based on specific requirements, I am pretty unconfident. I really think I need to solidify concepts as the course goes on because I know that manipulating trees is fast-arriving. Other than the recursion question on the test, I am semi-confident about the linked lists question (I'm not sure if I covered all my basis) and the first couple of questions about data represented by trees. Still, recursion haunts me. I need to get it together for the final exam. I must conquer the concept! I haven't felt this determined since I entered in that donut-eating contest in grade 7 (yes, I won).

Week 9: My Problem Solving Biceps Are Growing

"...why didn't I know how to make these when I was taking Data Management in high school and had to calculate the probability of a certain outcome?!"

Genuinely an exact quote from my last post - and now here we are implementing Minimax for Assignment 2. Me and my group have been at this for hours and we've gone through at least three different full concepts of how to implement this strategy with trees. I'm beginning to feel like I don't understand trees fully... or maybe I'm just getting really frustrated by Minimax. Although I am really frustrated, I really feel my problem solving biceps growing and my logical muscles stretching. We've eliminated some possibilities of how not to do this assignment, so surely we're closer to figuring out how to do this assignment?! I have faith in myself and my group that we'll finish it on time (check out my group member's posts on their perspectives on working on this assignment), and if anything we'll have bonded over conflicting ideas, arguments, and sheets of pseudo-code surrounding us on all sides.

In other, less stress-inducing news, we're learning about linked lists in class! My excitement arises from the fact that I have previously studied and implemented linked lists in high school, although slightly differently in Java. I feel like I thoroughly understood how linked lists worked and how to manipulate them previously, so hopefully it won't be so bad this time around. Looking forward to implementing some cool functions with Linked Lists and expanding my knowledge on this ADT!

Week 8: Look Up (at the Trees)

This week in class we discussed trees. No, not the oxygen-producing, sky-reaching, tire swing-supporting structures of Mother Nature - rather, the Abstract Data Type. From what I'm understanding this just seems like a fancy application of OOP, and we're just using trees to visualize the way data is represented in memory. I really appreciate the appropriate terms and definitions in the way that the structure is represented because it's a HUGE help in understanding what exactly is going on. The root, the leaves, the parents, the children - it all just makes sense! It's a pretty cool way to represent data as well... why didn't I know how to make these when I was taking Data Management in high school and had to calculate the probability of a certain outcome?! I was drawing trees like it was my job back then.

Danny has been pretty good with answering my questions in class and an exceptional teacher in the course overall so far. I've gone to his office hours before and he's really drilled good practice and complex concepts into my head. I don't hesitate to ask or answer questions either just because of how friendly and kind he is to all of us students. It's always a pleasure to go to Danny's lectures (although not-so-pleasant having a 10AM class with a 2-hour commute) and I look forward to the rest of the course.

Week 7: Down and Dirty with OOP

To discuss in more detail the conceptual ideas of Object Oriented Programming, refer to last week's post; this week we'll be looking at how Python handles OOP. Let's first look at the structure of a class and what it entails:

The class is defined on line one and given the name 'Circle'. The __init__ method runs the moment the class is instantiated (we make an object of the class). We can see that the instance variable of this class is 'radius'. Since it is an argument of the '__init__' method, we must pass in an argument when creating an object of class Circle. However, if the parameter is assigned a value in the  method definition, it will be defaulted to that value if it hasn't been mentioned in the object initialization. Here's some examples:

Line 11 will run regularly and create an object of class Circle with a radius 5. Line 12 will give us an error because the __init__ method did not set a default value for the radius, and you are not allowed to create an object of the class Circle without giving it a value for the radius.

Now, on to line 6. Any method can be run by accessing the objectname.methodname(). Every single method must be defined with at least the parameter (self) - think of it as the class making sure that it can access it's instance variables. Here's some sample code to demonstrate OOP a little more complexly:

I've added some docstrings and an additional method to spice things up a bit. Here's the main:

You can see I've made 2 different objects of Circle with 2 different radii. obj1.radius gives a different value than obj2.radius because they are different Circle's with different properties. This is what the shell would show following having run the program:

Methods initialized with double underscores on either side are special, because they are called without being explicitly called - i.e. they are called when you perform other manipulations on objects. An important thing to realize about objects are that they are packages of data. If you say you want to to "ride the Six Flags Theme Park", you'll likely be looked at in an odd manner because this makes no sense - rather, you want to go to the Six Flags Theme Park and ride the individual rides. In a similar way, you can't add two objects because they are not single integers, they're much more complex than that. For example, if you try to do obj1 == obj2 without defining a '__eq__' method in the class, the computer will try and compare the memory addresses of the objects to see if they are the same object. Remember: if I create two objects with the same attributes, they are still separate packages of data that exist at two different addresses.
Here are some important methods you should define in a good class implemented for Circle:

And demonstrated in the shell:

Now that you've seen and understand some uses of OOP, I'd like to a few words on the magic of this concept:
Object oriented programming allows one to set up organized and efficient code, and helps you avoid having an overload of variables and oddly represented data. Yes, classes are like recipes, thank you Grade 11 ICS teacher (refer to Week 6).  A class sets up the structure and blueprint of something that has the potential to exist in memory - creating an object takes that structure, copies it, and allows you to create a tangible set of data that is organized and makes sense. OOP makes way for Abstract Data Types such as trees and linked lists, which are all based on the concepts presented in this post.

Week 6: OOP-De-Loop

Object-Oriented Programming! What an important programming concept. Once I learned how to effectively implement OOP, I never wanted to go back to purely functional programming. However when I first learned about what an 'object' was, I was far from convinced.

I still remember it like it was yesterday - it was the night before my Grade 11 Introduction to Computer Science exam and I was on the phone with my friend who was going through an impressive list of metaphors to try and help me wrap my head around the idea of 'objects'. That phone call lasted about an hour and a half before I hung up, extremely frustrated. Why does everyone keep talking about recipes? And what does the human race have to do with classes? Long story short, I did the exam pretending to understand what an object was (and I did surprisingly well, considering). Two years later, I sit here in the very same spot I was sitting when I was on the phone trying to wrap my head around objects, with a complete understanding of classes and object-oriented programming. It took a summer of re-doing the Grade 11 ICS curriculum and three half-year courses, but finally here I am. And now I'm obsessed.

To explain the basics in a way that I wish I was taught, think of an object as a circle. And that circle has arms (you can have as many arms as you like - for this example, let's say there are 3 arms). Each of these arms represent a different feature about the circle; say, the circle's favorite movie or it's favorite color or it's last name - just features of the circle. Now, different circles may have different preferences of colors and movies but at the end of the day they are all circles with preferences.

Following this example, the class would be a Generic Circle with three arms. Since each of the above circles all came from the single Generic Circle (class), they would be objects of the class (each object is an instance of the class it belongs to). And finally, each of the arms are called instance variables, basically just attributes or 'preferences' of the objects. Often times you can make classes do things or give you outputs by creating functions within the class called methods, but more on that later. More complex ideas such as inheritance and super-classes will be elaborated on next week. I hope this helped you understand the conceptual idea of objects in relation to classes - we'll get more down and dirty with actual code soon!

Week 5: Tracing In Circles

Come one, come all! Gather 'round, don't be shy! Bring your mother, brother, sister, father, cousin and neighbour you have a questionable relationship with! Witness the magical capabilities of our latest act - Recursion! 
We've been waiting to be offered the deathless death of recursion (yes I'm listening to Hozier as I write this) since last semester's 148 students wrote their second midterm and came out bathing in their tears. Finally, it's here - well, kind of. We've been tracing recursive calls this week, and it really hasn't been all that bad. As far as I can tell, it's the same process as Alice traveling through Wonderland - you keep going deeper and deeper until you reach a turning point where you can't go any deeper, at which point you have to leave with everything you picked up along the way.

Okay, I'll try going the rest of this post without going on too many tangents.

Danny's introduction to tracing recursion was very useful, and it really helped me understand how and why each step was happening. It was very interesting to see how such short pieces of code could produce such long traces, and be so powerful. Not to mention the representation of recursion using the Turtle drawing module was pretty freaking cool. I'm interested to see how recursion is used in application in future classes and labs, and I can't wait to begin writing some recursive code on my own as well.

Week 4: Who's Your Daddy?

Alternate Title: Look How Far We've Come (Part 1)

This has actually been my favorite of all my courses this semester, so far (which I hope is an acceptable statement as I intend to pursue a Computer Science Specialist degree). We've been introduced to the idea of inheritance in class this week, and the practicality of using parent classes has definitely dawned on me. The applications are literally endless and I really appreciate how this concept stresses efficiency (which wasn't always a focus in CSC108). Inheritance allows for bigger ideas to be executed in much cleaner ways, as well as symmetry and consistency which I think is important to reinforce the idea of writing clear code. We discussed how Python calls methods in regards to inheritance, and how it interacts with over-ridden and inherited methods. All-in-all I'm really enjoying the topics discussed thus far, and my appreciation for code-equitte (code-etiquette - so clever, I know!) is definitely growing. 

Week 3: Geek Week

    Let's face it: we can only hide behind our screens with Atom and Emacs shielding us from the terrors of writing coherent sentences for so long - but trust me, it's not all bad (and as it turns out, it's actually really important).

    As Computer Science students (or 'geeks' as some playground-bullies would be so inclined to call us), it's important to be well-versed in a number of languages, including the English language. This is important for a number of reasons, but it can be very accurately summarized by a quote by Martin Fowler:

"Any fool can write code that a computer can understand. Good programmers write code that a human can understand"

    Computer Science is an extremely collaborative faculty that requires a lot of team work. It's rare to find a widely successful software that was created by a single entity without any discussion or help from other entities. Therefore, a single project's code base will likely be viewed by several different programmers that all add and contribute to it. For this reason, it's extremely important to not only create intelligent code, but well-written code. This means following appropriate style guidelines, including comments, and writing full and coherent docstrings. The ability to communicate your idea is almost - if not more - important than the idea itself, for if you cannot explain your genius then it's hard to believe your genius exists at all.

Let's create somewhat of a 'case-study' regarding a sample of well-written code that demonstrates how to identify all natural even numbers less than a given top_number:

Although this is a very simple example, it still demonstrates the essence of good programming.

    Variables are named with clarity and are appropriate to the situation, as opposed to vague and indiscernible names such as 'x', 'num', and 'var'. It is easy to identify what role each of the variables are playing in the scenario.
    In-line comments can be the key to unlocking all the answers of the universe - if done correctly. There are many ways to approach a given problem, so indicating what the purpose of certain data structures that may be difficult to understand otherwise, is essential. We can see in the given example that the purpose of the while loop is clear, and as a result our approach to the problem has been communicated more efficiently.
    Writing clear code can help immensely in the process of debugging, and makes the lives of the writer and the reader of the code much easier. If one were to try to trace a program without understanding how the different parts are interacting, it's safe to assume they would struggle greatly before reaching a conclusion.

    Additionally, keeping a clear and coherent log of your common mistakes can turn out to be the most useful tool you'll ever possess. Writing about a problem and tracking your progress through the issue can help you identify where your concepts are weak/strong, what improvements you can make in terms of approaching a problem, what kinds of problems you face most commonly, and ultimately how to become a better programmer.