Systematic Program Design - Part 1, Sec. 3a & 3b

Sections 3a and 3b are estimated to take anywhere from 8-13 hours. At 2x video speed I was able to get through all the videos and video questions in a little over 2 hours. I can't give a reliable number for time spent writing the code for this section, for reasons I will explain below, but if you take the estimates from the course, you'll spend about 2-3 hours on this part. If you're able to work through this stuff without any hangups, you'll be cruising through these sections in about half the time you're expected to take.

If you read my last blog, you already know I've been cheating a little bit with how I prepare my data for functions, and how I write out function definitions so I've been cutting out some time here. Also, I coded only some of the exercises, in C# again, which took less than an hour, It would have taken much longer, but I completed the drawing exercises in pseudo code, which is hardly enough to qualify for a grade should you actually take this course, and certainly no where near enough to qualify for learning something new if you've never used code to draw pictures (to be fair, it's not all that exciting).

In doing this, I've noticed is that I've betrayed this learning opportunity by making things too easy in some areas, and too complicated in others. I'm so used to using C#, that I can write the code for simple problems (EX. create a definition for a point) with very little effort, and it feels like I'm wasting time. I want to go through all of these courses as thoroughly as I can, without wasting my own time, so I can give a fair analysis of the content, but using C# has actually proven to be a waste of time for things that may be very simple in Racket (drawing shapes/images), and too familiar for things like designing compound data (movies with title, budget, release date, etc.) and comparing certain values.

In short, I've decided to download Racket and use it for the rest of the course, starting with parts 2 and 3. The lesson learned here, is that if you want to participate in any course, even if you're told you can code in the language of your choice, it's best to use the tools provided.

As for what you can expect to learn in section 3, there's some seriously valuable ideas. The major concepts are: using templates, domain analysis, programming through the main, using 'wishes' to work out the details for the main function, and creating compound data structures. I'll explain the details of each concept in bullet form here.

• Using Templates
• The essence here is that using templates allows you to break apart your solution into manageable steps that can be worked on one at a time. With a template you can work systematically, then end up with all of the pieces of your solution
• Domain Analysis
• Start with a sentence to describe the goal of your function
• Ex. This function will draw a cat walking across the screen
• Identify the things that stay the same
• Height and Width of the screen might be a couple constants
• Speed of the cat, and the image of the cat might be a couple more
• Identify the things that change
• If the cat is moving horizontally, its x-coordinate will change
• You might want it's rotation to change to give it a wobble effect
• Draw pictures to represent the things you've listed
• Programming Through the Main Function, Using 'Wishes' Where Necessary
• Start coding your function with the assumption that it has all the functions you need, and when you run into a piece of missing functionality, create a 'wish'
• That is, if you write, using the big bang example, (on-tick advance-cat) you've assumed the function advance-cat exists. However, advance-cat does not exist yet, so you've made your wish for it to exist, and now you need to quickly write a short section  (this section already exists in the big bang template) for your wish, the same way you would any other data definition.
• Mark incomplete wishes with !!! (often marked as //TODO in C#)
• Essentially, this means, when you run into missing functionality in your program, just write the name of the function you want to exist, then fill in the details for that part of the code later.
• Creating Compound Data Structures
• As the word compound suggests, these are data structures with multiple parts
• Example: (define-struct point (x y))
• Access x through: point-x
• Access y through: point-y
• Example 2: (define-struct cow (point dx))
• Access x through: cow-point-x
• Access y through: cow-point-y
• Here, dx represents velocity and can be accessed similarly: cow-dx

There was certainly some valuable information in these sections. I discovered the importance of drawing pictures and writing program goals in natural language very early on in my computer science education, but I never had a full-on systematic strategy like this course teaches. As annoying as it can be to write out all the details for a simple program, I am excited to see how this strategy really shines when attempting to write more complex designs.

Systematic Program Design - Part 1, Sec 2

If you've been following along on this journey so far, you probably know what to expect from this post. I finished section two today (I think it's referred to as module two, but w/e). Much of the content has been a form of review for me again, but I think it was still worth going through. Again, I smashed through all of the video lectures at 2x speed. At that speed it took me about 5 hours to complete basically all of the content. I'll be fair here and note that when I say basically all, I mean I did all of the code work, but I didn't write down every step.

This section really tries to drive home the importance of laying the foundation, before writing a function, by strictly defining the data you'll be using and how you'll be using it. I'm cheating a little bit, in that I don't write out every detail. Also, because I'm coding all of the problems in Visual Studio, instead of DrRacket, I can use XML Commenting to describe the data for my function and even provide documentation through IntelliSense when I go to use that function elsewhere in my code.

If you've never used either, the documentation for a function in DrRacket - using the style taught in this course - might look something like this:

;; Time is Natural
;; interp. number of clock ticks since start of game

(define START-TIME 0)
(define OLD-TIME 1000)

#;
(define (fn-for-time t)
  (... t))

;; Template rules used:
;;  - atomic non-distinct: Natural

While in Visual Studio you might do something like this:

/// <summary>
/// Given the current game time, this function will provide the elapsed time,
/// since the start of the game.
/// </summary>
/// <param name="currentTime">This is the current game time.</param>
/// <returns>Returns a TimeSpan indicating the elapsed game time.</returns>
*/
    private TimeSpan GetTimeSinceGameStart(DateTime currentTime)
    {
         // TimeSpan gameDuration;
         // ToDo...
         // return gameDuration;
    }
/*

Note that I don't follow the exact same pattern emphasized in the course. Because I don't follow the same structure, or maybe better said, because I don't put 100% effort in, I won't be getting 100% return on my education. I don't suggest you follow the same path I've taken if you're still fairly new to programming.

Overall, this section was time well spent. I got to practice writing definitions for functions, and I got to look at very thorough examples of a proven technique to design data definitions. I also learned some new vocabulary (not necessarily new concepts) to talk about data definitions, like Simple Atomic Data, Interval, Itemization, Compound Data, etc., and gained some insight into the number of tests appropriate for functions using different kinds of data.

It's really important, in any field of work you choose to go into, to understand most of the vocabulary used by professionals in that field. Often times seemingly simple words can carry a ton of information, and it's important that everyone can communicate with common words to their industry, in order to transmit ideas efficiently. I've always loved expanding my vocabulary, because expanding your vocabulary, often means expanding your understanding of new concepts.

Systematic Program Design - Part 1, Sec. 1a & 1b

I spent 5 hours at the library today, working though some WGU course work, and week 1 of this course. I'll probably start on week 2 after I finish this blog post, but I wanted to write this while everything was fresh in my mind. If you were to go by the syllabus you are expected to spend 9-15 hours working on sections 1a and 1b, but I finished both sections in 3 hours.

To be fair, most of the information I went over is stuff I already understand, so I was able to go at a very quick pace. I also skipped 3 modules to keep up my pace. I watched 12/14 lectures at 2x speed and I coded all of the problems in C#, rather than downloading DrRacket and coding in BSL.

If you're not familiar with a programming language already, I would suggest using the tools provided. I found BSL to be an ugly language, but the IDE, DrRacket, appears to be very beginner friendly. There's a section about drawing shapes with BSL, that DrRacket makes very easy, but I skipped doing any actual drawing because I've already done a lot of drawing in C#, and I was still able to answer the quiz questions by understanding the BSL functions that draw shapes.

If you took CS-50 before moving on to this course, you probably won't learn a whole lot of new information in section 1a, but you'll have to go through it, or at least review the material, in order to be able to use BSL. Section 1b, however, is all about writing functions and tests for them. This section is a gem, and you'll want to work though it and understand everything thoroughly. I can't tell you how many job opportunities I've looked at that included the requirement: 'experience with unit testing and test driven development'. I see that line everywhere, it's probably in about 80% of the job requirements I've reviewed.

The rest of this blog post is more of an exercise for myself to regurgitate what I learned, and you may want to stop reading here, but feel free to continue on, or stay tuned for the next post about my thoughts on week 2's content.

I said I wasn't using BSL and the DrRacket IDE right? Well shoot, I can't use the check-expect function if I don't write in BSL, so I can't do the whole section on testing... or can't I?

I couldn't let a lack of BSL support stop me from learning the material and actually coding the problems. I've seen a video or two on unit testing in C# but I've never done it myself, so I had to take this opportunity to learn how to create unit tests. I couldn't just write the code on paper, and pretend like I did the exercises. What did I do then? Well, I went to Microsoft's documentation and figured out how to write unit tests. As it turns out, that was quite easy for me to grasp, though I must stress again, if you're not familiar with another programming language, stick to BSL. I won't explain too much about unit testing here, you can certainly read the documentation above and gather some insight whether you know C# or not. In particular I suggest understanding the AAA approach to unit testing.

The AAA (Arrange, Act, Assert) pattern is a common way of writing unit tests for a method under test.

• The Arrange section of a unit test method initializes objects and sets the value of the data that is passed to the method under test.
• The Act section invokes the method under test with the arranged parameters.
• The Assert section verifies that the action of the method under test behaves as expected.

The value in going through section 1b is that you'll learn the HtDF (How to Design a Function) recipe, if you're familiar with writing code and designing functions, it's going to seem a bit cumbersome at first, and if you're not familiar with designing functions it's going to seem quite complicated. The essence of the HtDF recipe is this:

1. Signature, purpose and stub.
• The purpose is generally a problem statement. Or a description of what you're trying to solve. One simplified example is to design a function to pluralize a word.
• Ex. Input: "Dog" Output: "Dogs"
• The signature of a function describes the type of input and output
• String -> String
• The stub is a syntactically complete function definition that produces a value of the right type. It doesn't tell you how the function will complete it's work, only that there will be a function defined in such a way, and it will produce this type of output.
• (define (string str) "")
2. Define examples, wrap each in check-expect.
• An example is simply a snapshot of what a call to your function would look like. You're asked to wrap it in a check-expect function call, because this is the function that's going to test that your example is in the proper form.
3. Template and inventory.
• The template is what your function will look like with everything except the actual work to produce the desired output. Simply write the work as an ellipse '...'
• (define (string str)
      (... str))
4. Code the function body.
• I mentioned it was cumbersome right? At this point we can finally write the code that does the work for us and produces our desired output.
• (define (string str)
      (string-append str "s"))
5. Test and debug until correct
• Hopefully, at this point, things are pretty strait forward. If your test(s) fail, check first that you wrote your test(s) correctly. If you did, then check that you wrote your function correctly and that the body is doing the correct work.

Keep in mind, you don't have to get everything right the first go-around. You may find that you write a function for a Number that produces a Number. For instance, you might write a function that turns any number into the positive version of that number. You may write your signature as such: Number -> Number, but then realize that your output is always part of the natural numbers, in which case you should go back and change your function's signature to be more specific. Number -> Natural Number, for instance. Really, you should probably go as far as to say Integer -> Natural Number if indeed your input is an integer.

Effective Thinking Through Mathematics - U of Texas Austin

In my previous post I mentioned a bit about the first course I completed for my OSS 1.5 year challenge. This marks course 1/30 (recall I skipped the first course, reducing the total down from 31) that I have completed. This post will focus briefly on my experience with this course, and whether I think it's worth completing.

Effective Thinking Through Mathematics is taught by Michael Starbird at the University of Texas at Austin. The course is delivered though EdX and is designed to take 5 weeks. I set the video player to 1.5x speed and plowed through this course in about 8-12 hours. I'll try to get better at tracking my time in the future, but it is what it is at this point.

The course opens with a puzzle called the Meanie Genie, and it's pretty good. I don't want to spoil anything by telling you how I solved it, but I'll tell you that the essence of the puzzle is to teach you to examine all the possibilities when you're faced with a problem, and to convince you of the importance of following through with your ideas. The problem (in short form) is this:

Suppose you have 9 identical looking stones, one of which contains a valuable gem that adds a slight amount of weight to the stone. You have a balance scale, and it can only be used twice. You must answer, is it possible to find the stone containing the gem in only two attempts or not. If it is possible, what can you do to find the stone?

I presented this puzzle to my 12 year old niece at Christmas this year and she wasn't into it. Surprisingly my sister was captivated, but was really frustrated that she couldn't solve it right away.
"Obviously there has to be a way to solve it or you wouldn't be asking the question in the first place", she said.
"Well... yea... you caught me", I replied. But I refused tell her how to solve it.

She did eventually solve the problem, but it was really interesting to see her struggle with the puzzle in a very similar way that Scott (the student helper) did in the videos. She became really frustrated, as many of us do when we struggle to work through a problem, but I nudged her to keep thinking. Stealing techniques from professor Starbird, I got her to consider all the possibilities and forced her to follow through with each trial until she found the answer and it became so painfully obvious.

As professor Starbird says, the easy way is the easy way because you've solved the problem or similar problems and understand them at a level which makes them now seem easy. It's easy for a Major League Baseball pitcher to throw a strike down the middle of the plate, not because they are gifted (though they may be), but because they've practiced this challenge so much that it's no longer hard to do.

I really enjoyed the course, there were lots of puzzles that I forced myself to work though, and I gained a lot of insight into how I can approach future problems I find challenging. I learned something interesting about the concept of infinity and that there different size sets of infinity... in fact I learned there are an infinite number of sets of infinitely long sequences, really mind blowing stuff.

I felt the course was a great primer for the OSS curriculum, and I'm excited to tackle the next course, starting tomorrow!

Reviving the blog / OSS 1.5 year Challenge

I've been studying computer science for three years now. I graduated with my AAS in Computer Science from Renton Technical College in March of 2016. I took 1 month off to recoup, then in June, I started working on my BS in Software Development through an online course offered by Western Governors University.

In my first 6 months with WGU I wasn't asked to read or write a single line of code. I find that to be quite disheartening coming from a Bachelors course in Software Development. I've learned a lot of information from this course so far, but that information has been aimed at teaching me what I need to know to pass Comp TIA exams. In fact I've had to pass the Comp TIA A+, Network+ and Security+ so far. I'm not certain how many more they'll make me dredge through (my fault for not doing more research, and taking suggestions from my peers 😔). It's not that bad though. I like the structure, it saves me a ton of money, and I'll still end up with a regionally accredited degree.

Unfortunately, certifications are not enough for me. I want to be a great software developer. I am incredibly lucky in that my family has given me the opportunity to live at home free from rent. I'm lucky also, in that I have the opposite problem with money that most American twenty-somethings have. Instead of feeling like I need to spend my money on stuff, I feel like there isn't much stuff worth spending money on, so I save it - lots of it. I look at other guys my age and see them spending every paycheck on stuff they don't need, or worse, gambling it away. But let me get back to the point. It's not enough for me to earn a few industry certifications each semester, I don't have the money to pay for an MIT education, but I have enough to provide myself with all my basic necessities. Although I can't pay for a high quality university, I (and you) can still learn from high quality courses, many of which are free.

I recently discovered a free learning initiative called the Open Source Society. They might have other degree paths, but the one I found, and am most interested in, is marketed as a "Path to a free self-taught education in Computer Science!" They've got an interesting collection of 31 courses, most of which are taught by the same high quality universities I can't afford to attend. Here's a link to their Github repository if you're interested: https://github.com/open-source-society/computer-science

I started working through this coursework on December 22nd, 2016. I hope to complete all of the courses that don't already overlap the knowledge I have gained over the past 3 years of studying. This means I won't be completing them all. In fact, I skipped the very first one, 'Introduction to Computer Science - CS50' (Harvard). It's a pretty good course from what I've seen, but I watched many of the videos from this course when I first started taking computer science seriously a few years back, and I'm pretty certain I won't gain much by completing this one at this point. So where am I now?

Well, earlier today I completed 'Effective Thinking Through Mathematics' (The University of Texas at Austin). It's staged as a 5 week course, but It took me about 8-10 hours to watch and attempt all of the content. I'll have to get better at tracking my time. It's certainly a fantastic start to my goal, which is to complete all of the courses by the time I graduate with my Bachelors degree. It was also a very fun course to partake in. There isn't anything too complicated within this particular course. It's mostly a bunch of puzzles that are designed to teach you the importance of trying something - anything - when you reach a problem you're not sure how to solve, and to teach you to follow through with ideas, even if you're certain they will lead to the wrong answer. The puzzles were fun and challenging to solve, and the lessons learned were well worth the time spent.

With a fantastic start, but with 29 courses left to finish, I've got a long way to go. I hope to complete the whole course within a year and a half, while also staying on top of my other studies at WGU. I hope to spend about 40 hours a week on this course and 15-20 hours a week on my classes for WGU. I haven't touched this blog in something like two years, so I'm going to revive it and keep track of my progress here.

I was inspired by Scott Young's MIT Challenge: https://www.scotthyoung.com/blog/myprojects/mit-challenge-2/ but I wasn't sure if I wanted to take the same route as him, but when I reviewed the content in the OSS course, I saw that much of it was designed for online learning instead of being primarily designed for the classroom like much of what Scott completed. I decided what the hell, lets give it a shot, so here I am.

Like I said, I'll be using this blog to keep track of my progress and hopefully when I'm all said and done, I'll be able to offer some criticism about the course and be able to help others make an informed decision about embarking on a similar challenge.

It's getting late, I'm super tired, and this post is already losing quality and gaining in size. I'll end here before I get too carried away, and leave you with this thought.

The best thing you can do when faced with a problem is to just try something. Even if you know that which you are trying will fail, you'll be able to confidently eliminate one wrong answer, and likely gain insight toward reaching the right answer.