‹ go back

CPSC 110: 1b.

Published 27 December 2020 at Yours, Kewbish. 1,011 words. Subscribe via RSS.


This post is unlisted and has been archived. This doesn't represent my best work; please check out the posts listed here instead.

Introduction

Why I felt the need to ruin augment my Christmas week with some Racket, I don’t know. It was fun to go through some HtDF material with CPSC 110 this week, however - surprisingly, it wasn’t as tedious or repetitive as it seemed.

For non-Racketers (Racketeers?), the HtDF recipe, or guide, I suppose, is a method essentially detailing How To Design Functions. You write a signature (the types expected), the stub (the minimal function needed to get the function to run), the check-expects (unit tests, basically), the template (the stub, but a little bit more), and the final function. While it does get slightly boring to do the same things for each function (and a bit annoying for small, one-line functions), Kiczales does remind people that it’s not a must-follow for everything, but it’s good guidelines.

I also finally acquiesced and have started using DrRacket - I needed the stepper for the problem set checking. Besides, some of the distribution files that contain images are in some vaguely newline-filled format that doesn’t read nicely in Vim. However, I managed to get vi-like keybindings via this package, which still works nicely. It’s a lot easier to try things out in the REPL, and I can run check-expects aside.

There wasn’t much besides the actual recipe covered this week, so we’ll see if this post might be a bit shorter. Also, see the CPSC 110 module 1a post I wrote a couple weeks ago.

Notes

  • htdf recipe is a non-waterfall set of instructions to write and easily debug functions
  • begin with writing a signature, listing the two types
    • forex, Integer -> String
    • ensure this starts with two semicolons - Kiczales mentions that this is tested for (two semicolons start a line of comments, a single one goes at the end)
    • sources conflict regarding whether to put the function name first, but for CPSC 110 don’t
  • purpose statement => one line statement regarding the purpose of function
    • should be as specific regarding return paths as possible
    • should specify what conditions should be met for a boolean function
  • function stub => define the function with its arguments
    • return an empty value for the function
    • 0 for integers, "" for strings, etc
  • write examples and wrap in check-expects, which will function as unit tests
    • need to test each code path for example behaviour
    • ideally number of tests should be around 3 (for boolean), one for each case
    • DrRacket will highlight unchecked paths in orange
  • if tests fail on first run => expected, no functionality has run yet
    • just checking if well-formed
    • if test fail later, consider the test itself if correct
    • otherwise, check function definition
    • however, both can also be incorrect, as Kiczales points out in the video
  • add a template, which is the stub but with a ... and returning the argument
    • keeps track of all variables and what to do
  • finally, can copy paste and implement function
    • remember to test intermittently to catch problems as they come up
  • isn’t a hard and fast rule, can use different steps along way
    • however, don’t jump right into function definitions, which will lead to problems in future
  • if a problem is poorly formed, clarify all constraints and possible corner cases first
  • (regarding problem sets and labs) keep htdf and htdd signatures, used by autograder

Problem Set and Lab

I still have no idea how the problem set to module timing system for CPSC 110 works. While in module 1a, the first problem set contained material about functions that was covered in module 1b and that I had, at the time, not done yet, so I left it for the next week. However, the first lab was entirely of material covered in module 1a. I’m sure there’s a schedule somewhere1.

The problem set this week was actually quite interesting, and a good challenge level, I feel. I like that it’s in a self contained starter file, and that you get to edit and make changes to each part. It reminds me a lot of CS50’s distributions each week. Having each question target a specific area of knowledge and material taught in the module while giving everyone an even starting ground is beneficial, I feel, for my learning process. It makes everything feel a lot more manageable.

Lab 1, the intro lab, was also very straightforward. I wasn’t able to get access to the quiz, but it was simple material covered in the lectures. I like that each subpart is very short, and that it’s sort of like a problem set. It was definitely good practise.

I’m not submitting anything for grading - I’m still very unsure if I’m allowed to be in this edx course at all. I figured that grading might be a bit of an issue, especially as I started the course later, but theoretically I might be able to properly do the course next semester?

Conclusion

I’ve recently found out I do have a possible chance at changing my student status to properly enroll in the course, but it’s a bit late to do that for second semester. I’d ideally like to challenge in the summer, but I also have several other plans. We’ll see. In the meantime, I’ve realized that CPSC 110 has a lot more modules than I’ve expected, so I think finishing the course will take a lot longer, especially with work after winter break. Hopefully I’ll be able to still preview before the April close date, and finish preparing for the summer.

Happy holidays, and we’ll see what I decide to write about in the new year. I’ve got a lot more HCI topics to think through before I write about them, but I think they’re interesting enough.


  1. [later edit]: Upon further inspection, I’m pretty sure each week number corresponds to one complete module number. It probably makes more sense that (the hypothetical) week 1, problem set 1, lab 1, and module 1 (containing both module 1a and 1b) are supposed to be done together. I’ll probably leave 1a and 1b as separate posts, but combine them in the future. ↩︎


‹ go back