Since the due date for my first assignment in CSC148 just passed, I thought I would take this SLOG to reflect on the assignment - what I enjoyed, what I found interesting, and what was a challenge.
I really enjoyed working on this project. I almost always enjoy projects in my computer science courses, because they give me such a large sense of accomplishment at the end. Not only have I completed the project, but I have a working program! One that does something, if not useful, then at least entertaining. I love the feeling that I'm actually doing something worthwhile, not just work for work's sake. I really loved that I could see a graphical version of my work at the end as well. It made the code feel very tangible, and it was an amazing feeling to know why what I was seeing on the screen was actually working.
My favourite part of the assignment was coding the recursive function tour_of_four_stools. I found it very interesting to see recursive code in action, especially recursive code that I had written. I liked being able to apply the recursive three-stool function we had learned in class to a new function. It really solidified for me how the recursion was working. This assignment made me feel much more confident in recursion. Although I was beginning to grasp what it was before, I really think I'm starting to understand WHY it works much more now.
One of the most challenging parts of the assignment for me was the coordination between the different parts of the code. Getting one code file working would cause another to stop working and vise-versa. The same thing happened within files as well - just when one function started working, another would stop. Often it wouldn't even be the functions I were tweaking that caused these problems, but some third function that was also related to both of them! I had trouble figuring this out a couple of times. Debugging this program could be really frustrating at some points, but figuring out problems in my code was also really satisfying once I found them.
Now that assignment 1 is finished, it's time to start studying for the midterm! Hooray!
Saturday, 15 February 2014
Friday, 14 February 2014
Week 3 SLOG - Scope
I found the section on scope in this week's lectures very interesting. After going to the lecture on scope, I realized that quite often the bugs I find in my code are to do with scope, which I didn't realize before. I can be sloppy with variable names, so I find myself reusing a variable name several times throughout my code to reference several different things in several different scopes. This tends to return unexpected results a lot of the time, but I've gotten away with it by just tweaking a couple of names here and there until it works. Now that I understand scope, I realize that I really need to be more careful with my variable names; it will help me escape a lot of avoidable problems.
In the lecture, we looked at some code that played around with scope - names.py. During the lecture, I found it slightly confusing - and it was supposed to be, so that was okay! When I got home, I took a look at the code again. At first, I didn't understand why when asked to print spam, the code printed nonlocal spam after both the nonlocal spam assignment and the global spam assignment. Now I understand that it's because Python looks to the nonlocal scope before it looks to the global scope. So even after a global spam is assigned, Python still looks to the nonlocal scope first, and returns the value of spam from there before it ever even gets to the global value.
Even though scopes can be confusing, I think that as long as you take the time to carefully trace out what's going on in your code, you can always figure out how Python is using the different scopes to look at your variables.
In the lecture, we looked at some code that played around with scope - names.py. During the lecture, I found it slightly confusing - and it was supposed to be, so that was okay! When I got home, I took a look at the code again. At first, I didn't understand why when asked to print spam, the code printed nonlocal spam after both the nonlocal spam assignment and the global spam assignment. Now I understand that it's because Python looks to the nonlocal scope before it looks to the global scope. So even after a global spam is assigned, Python still looks to the nonlocal scope first, and returns the value of spam from there before it ever even gets to the global value.
Even though scopes can be confusing, I think that as long as you take the time to carefully trace out what's going on in your code, you can always figure out how Python is using the different scopes to look at your variables.
Thursday, 13 February 2014
Week 2 SLOG - Unittest
With the past couple of weeks being filled to the brim with midterms and projects, you can probably see that I have neglected my SLOG. I know. Terrible. However, what I did do was write down some notes on things I wanted to talk about, so today, tomorrow and the day after that I'm going to post a SLOG summarizing some of the things I wanted to talk about in my SLOG for the two weeks that I missed, plus a SLOG for this week.
Today, I will go back to the SLOG Week 2 version of me.
This week, I completed lab 3, which involved unittesting. This lab was a huge wakeup call for me. Although we'd briefly looked at unittesting in my past programming course, throughout the course of this lab I realized that I actually had no idea how it worked. My partner and I managed to make it through the lab with our limited knowledge of unittesting, but over the past week I've been starting to review how it really works. I don't quite have a grasp of it yet; it just doesn't seem intuitive to me. But each time I look at it, I feel like I understand a little more.
One thing I definitely understand about unittest now is its purpose. It makes testing easier by making it automatic. Instead of typing your test cases into the Python shell over and over again, you can type them once into unittest code and just run the code to test it. It also allows you to group test cases together, which can make your code more organized. Unittest uses the setUp() function to create an object to be tested. It then has a function for each test case, the names of which should describe what you're testing. Using the 'assert' keyword, you can test whether performing certain actions on the object returns the values you are expecting. For instance, you can use assertTrue to check whether the test object or an action performed on the test object returns true.
Hopefully as I continue to look at unittest, it will become more and more clear to me until I no longer have any trouble with it at all.
Today, I will go back to the SLOG Week 2 version of me.
This week, I completed lab 3, which involved unittesting. This lab was a huge wakeup call for me. Although we'd briefly looked at unittesting in my past programming course, throughout the course of this lab I realized that I actually had no idea how it worked. My partner and I managed to make it through the lab with our limited knowledge of unittesting, but over the past week I've been starting to review how it really works. I don't quite have a grasp of it yet; it just doesn't seem intuitive to me. But each time I look at it, I feel like I understand a little more.
One thing I definitely understand about unittest now is its purpose. It makes testing easier by making it automatic. Instead of typing your test cases into the Python shell over and over again, you can type them once into unittest code and just run the code to test it. It also allows you to group test cases together, which can make your code more organized. Unittest uses the setUp() function to create an object to be tested. It then has a function for each test case, the names of which should describe what you're testing. Using the 'assert' keyword, you can test whether performing certain actions on the object returns the values you are expecting. For instance, you can use assertTrue to check whether the test object or an action performed on the test object returns true.
Hopefully as I continue to look at unittest, it will become more and more clear to me until I no longer have any trouble with it at all.
Subscribe to:
Posts (Atom)