Friday, 27 March 2015

Unit Testing - Why should you do it?

Unit testing -- it's a lot of work. There's no doubt about it, it can be a long time before unit testing seems like it is worth it. I know for a good long while I thought unit testing was for the birds, but I think this week's lecture may have changed my mind.

Let's see -- what is useful about unit testing, especially when it comes to Python? Unit testing is very useful for having a good developed program, and especially when working in teams. Unit testing allows you to make small changes to your code and check that it still works, which can be very useful when dealing with large codes or multiple programmers. This can save a lot of time and headache, which can be very useful long-run.

Unit tests also really help you understand exactly what your program is all about. Yes, yes, I know -- you wrote it. Who knows it better than you yourself? But you can't claim to know all the inner workings of every Python class you call forth, or what exactly your code is doing every moment of its run. Unit tests make sure you have a better idea of the general idea of your program, and help you keep track of everything that could possibly need fixing. Unit tests give you a lot of immediate feedback, and really help define your code.

Unit testing helps keep your code concise and of quality. It's something you may not want to do, but it is a good habit to get into and will help you a lot if you manage to keep it up!


Thursday, 19 March 2015

The Second Test - Impressions of Week 9

Despite the strike, we continued on with our second test on the semester, which focused mostly on Trees and Binary Trees. All in all, I didn't find the test too challenging -- as long as you keep up with class work and don't fall behind, you should be good! LinkedLists threw me for a bit of a loop, but as I said last week - draw, draw, draw!

As for the other activities of the week, we focused on a short lab on Binary Search Trees, or BSTs. When initially reading the question, I thought it was a lot more difficult than it was -- I thought they wanted us to include an insert method with property, but it turns out there was already an insert method like that in the starter code.

Binary Search Trees and property -- this is the one thing I forgot on the test, which I kicked myself for later. Property refers to the idea that all the lesser data goes to the left of the node, and the greater data goes to the right. The picture below demonstrates this.

All in all, not too much new news for week 9 -- whenever you have a test, that tends to take up most of your focus. I am looking forward to starting assignment 3 though!

Sunday, 15 March 2015

How to Draw Your Code

One of the main themes from week 8 was drawing pictures... But only to understand linked lists, of course! CSC 148 is branching (and I'm not only talking about Trees here) away from the easy data structures, and getting into some of the more complex ones. Linked lists can give you a bit of a headache, but once you understand how everything is connected, they are not too bad.

Linked lists are, as the name would suggest, a new form of list. They represent a sequence of a collection of nodes, all connected to one another. It's a bit abstract to explain, but they make a lot of sense when you draw out the connections.

A lot of our lab excercises this week covered inserting new nodes into previously created lists. I'm stealing a picture from Wikipedia to help explain myself, as you can see below.


All you have to do is create a new node, and relabel the values of the node before the place you want to put the new node and the one that' coming up next. Each node keeps track of what the next node is, but when you write your code you have to create a new variable to keep track of what the old node was, in order to properly organize your data structure. It makes a lot of sense, and helps keep your data structure neat and organized.

Linked lists are good for memory, and they keep the program run time down. Stacks and queues are especially useful for linked lists. However, linked lists do have their downfalls -- they don't have a lot of built in functions for indexing, meaning you might have to write your own helper functions. Traversing a linked list is not as easy as traversing a tree. Most crucially, it is really easy to get confused by linked lists -- if you don't keep careful track of what's doing what, you might find your code completely misses the point, as do the nodes in your linked lists! All in all, linked lists are one of the many data structures available in Python, though maybe not always the most convenient.

Tuesday, 3 March 2015

The Seven Week Itch

Ah, the week back from reading week -- so full of hope, anticipation, positivity. Until you realize that all the work you thought you caught up on was for naught -- there is a never-ending torrent of work to be done, especially in your computer science class.

Week 7 was devoted to finishing up the second assignment, which was not as easy as the first one. Assignment 2 is all about designing a game called Tippy, in which you play a game similar to tic-tac-toe, but instead of trying to get three in a row you try to place a tetromino somewhere on the board. Sounds easy, right? Maybe to play, and even maybe to code, but it's when you get down to the strategy that things get difficult.

In the first assignment, all we had to do was come up with a random strategy. In assignment two, we have to deal with a strategy called Minimax -- it can never lose, apparently! How are we supposed to write a program that can never lose, if we ourselves are always capable of losing? It was actually surprisingly simply, once you figured out everything that had to be done and applied the Tree methods we've been learning to your Minimax code. I won't post the details here, as the assignment hasn't been handed in yet, but needless to say I think I've learned a lot from writing the Minimax code.

Otherwise, week 7 sees things going as smoothly as ever in this computer science class -- classes are informative, labs teach me something new every time, and I'm genuinely enjoying the work that I'm doing. Binary trees are a good thing to learn, and I'm glad to have added them to my list of Python comprehension!

Thursday, 26 February 2015

To Tree or Not to Tree

(Please mark my previous summary on Object Oriented Programming, found here)

Think you understand recursion? Just wait until you hit trees. Trees are a great way of structuring data -- they link several little trees, or nodes, together. Trees are just like trees in nature -- they start at the root, and then they branch off into different sections, ending with leaves. Each one of these branches is a child of the previous root, but a root with no children is called a leaf.

Trees are a little difficult to visual, especially as Python represents them as several nested nodes, all Trees -- it can get quite confusion. However, you can write a string representation method that helps you visual a Tree better. If not, do what I do -- I draw the tree I'm working with out, if it's not too long, and it helps me visual it and completely understand what I'm doing.



That's a diagram of a simple tree, but most trees end up looking something like that. The node "1" has children: 2, 3, 4, and 5. All but "3" have children of their own, and "4" even has some grandchildren. Visualizing a tree like this can really help with your understanding of your code -- especially when we get down to recursion.

Trees are made of recursion -- each tree contains several little trees within it, going around and around, just like recursion. It's a little difficult to wrap your head around it, but the trick is to not think about it too much! In the diagram above, not only is there a Tree that has a root of "1" but there is also a Tree that has a root of "2" -- it just happens to be a sub-Tree of the first tree! And so on and so forth. Overthinking Trees can be the death of you -- just make sure you have a visual understanding of what is happening in your program, and you'll be sure to get to the conclusion!

Thursday, 12 February 2015

OOP(s) -- Learning Object Oriented Programming is NOT a Mistake

Object oriented programming. What is it? That's the question most students of computer science must ask themselves on a daily basis, and I'm here to give you a quick summary. Object oriented programming is crucial in our understanding of computer sciences methods and theories, so we have to know exactly what it is. Object oriented programming is exactly what it sounds like -- it's programming that organizes itself around objects rather than other actions or methods. Object oriented programming likes to focus on data rather than ordinary logic.

OOP involves many aspects that we've already been using in class, such as property and inheritance. Inheritance and ADT make your life as a computer programmer a lot easier, by allowing you to have one big generic abstract class instead of having to repeat methods for a bunch of similar classes. It cleans up your code, and makes your work a lot more organized and simple -- also makes it a lot easier for someone else to follow later on! This also means you can access classes in any other object oriented program, making things very organized and simple -- write one class, and you'll never have to write a class remotely similar again. OOP also allows for property, which lets data hiding occur and heightens the security of your program. Dottoripy has some really good points on property in OOP -- head over to her blog if you want to learn more.

Data structures such as queues, trees, and stacks would all be impossible without OOP. OOP allows you to refine your code and further understand exactly how to think out your code. Object oriented programs are easy to read, easy to modify, and work quickly, hence their resounding popularity today in the world of computer programming. Python, Java, C++... All are object oriented programs, making them both fairly easy to learn but also they allow to write complex code, and produce good, fast working programs. Object oriented programming is something everyone needs to learn, and they'll be thankful they did.

Thursday, 5 February 2015

Tracing the R-word

Tracing. Sounds easy, right? Absolutely not. Tracing forces me to slow down my thinking and actually see how my program works, step by step. I understand that tracing helps with understanding how one's program actually works, but for me it can get tedious quickly, and often I get lost in my own thinking and add far too many mini steps in between each step. Especially when we start dealing with nested lists -- I start having to make my writing minuscule, just so I can fit all my layers and written out recursions in one line.

Tracing, despite the pain it causes us poor CSC 148 students, is however necessary for complete and total understanding of your program. It helps you realize exactly what steps your program takes to get to the answer, and increases your Python knowledge on a whole. Especially when it comes to the dreaded R-word: Recursion. In order to understanding recursion, one must first understand recursion, in order to understanding recursion, one must first understanding recursion, in order to.... You get the point.

Recursion is difficult to explain -- you either get it or you don't. It involves calling a function within itself, either once or infinite times. In layman's language, it's meta, it's Inception -- something within something within something within something. The concepts may sound simple, but putting it into practice can be a little more difficult. Especially when tracing. When tracing recursion, I know what the answer will be before I start, but when actually writing out the lengthy steps, I can get really lost in my own muddled thoughts of recursion. I think to truly become more comfortable with tracing recursion, I will need to fully understand exactly what recursion means.

Dottori and I seem to be on the same page when it comes to recursion -- we both understand the concepts, but find it tricky to put it into action. Both of us will need a little more time to actually wrap our heads around it, and hopefully by the time the exam rolls around, we will be 100% on top of recursion, no matter how many nested lists it involves.