by ·2 Comments

The waiting is over, the official launch date is tomorrow, and all my ducks are in a row.  Well, I have no ducks, so I’ve neatly arranged my stationery just so, instead.

I have little to add to my status from the last post.  I did finish with all of Block 1 before the start date, our tutor forums have opened, and nearly all communications with fellow students outside the Facebook group has stopped!  I hadn’t really expected that last one, so it’s just lucky that I jumped into the FB group, even though I’ve stopped using FB apart from that.  The Early Bird Café forum was always going to close before the module started, but I’d assumed that student chatter would migrate over to the students association forum for TU100, instead.  Apparently it’s a bit tough for some to find.  (That site makes my kitchen junk drawer look like a hospital.)

I’ve used that forum to revive another student’s great idea.  (I don’t want to post the student’s name, as I haven’t checked if it should be broadcast all over the internet for no good reason.)  The idea was to have some programming challenges in Sense.  Someone runs into a problem while writing code, finds a creative solution for it, then challenges other students to see what solutions they can come up with to satisfy the same problem.  Students who get stuck can then check the challenger’s code to see what they did.

The original challenge involved adding SenseBoard functionality to a number guessing game, which was awesome.  (A SenseBoard is an Arduino-based input/ouput device for Sense.  They’ve stopped selling them, but the Digital Sandbox for Scratch is the closest I’ve found for it.)

My first challenge involved making a custom score counter of arbitrary digits, which was probably the most difficult part of my Jet Bike Steve game.  In Scratch, I used cloned sprites and a lot of modal maths for the digits.  Sense doesn’t allow this solution, so I have to stamp the digits, instead.  My initial solution used the maths from my Scratch solution, held individual digits in a list, and then stamped the list.

Within one or two hours, somebody had completely bested my design by using string slicing, which I didn’t even know was available in Sense or Scratch!  How did I not know that!?  (Because I hadn’t finished reading the programming guide, I later discovered.)  But once he mentioned he did it without maths, I realised I could split my score digits into a list without any maths.  This next revision of the challenge solution was much more optimised than my first, but still not as slick as string slicing.  But the student who used it is already on his final year of the degree (and probably read the guide at some point), so I don’t feel too bad at being shown up, and I learned two great techniques thanks to him.  And that’s the idea of the challenges.

One reason I felt this was necessary was the dismal state of the Sense Programming Guide that comes with the TU100 materials.  And ‘dismal’ may be generous.  In fact, the fiery hellish abyss of computational programming pedagogy might be generous.

It’s not actually bad, I suppose, as it isn’t wrong.  It just doesn’t fit the brief.  According to a paper presented at a symposium detailing the reasons for TU100 and Sense’s existance (Richards et al, 2012, p. 584), one of the main failings of previous OU introductory programming modules was failure to engage students with experimentation.

What they’ve done is assembled a great tool box in Sense and the SenseBoard, and then forgot to actually encourage experimentation, or put another way, to teach the students how to experiment.

Much of the Programming Guide is direct instructions of which buttons to push.  When it comes for explorative activities, the exercises are only open so far as to find the “correct” answer to a limited scenario.  There are no open-ended exercises of any kind in the guide.  It actively discourages experimentation.

It does, however, go over string slicing, so I didn’t have to discover that on my own.  It was more fun, engaging, and easily remembered that way, though.

Reference: M. Richards, M. Petra, and A. Bandara (2012) ‘Starting with Ubicomp: using the senseboard to introduce computing’, SIGCSE ’12 Proceedings of the 43rd ACM technical symposium on Computer Science Education, pp. 583-588.

by ·0 Comments

As some have said in my TU100 forums, it’s my last week of freedom!  After this, it’s all deadlines and regret.  (Which isn’t a huge lateral step, as it would have been mostly regret if I hadn’t started the degree.)

Before the big start, let’s take stock: Where am I?  Well, mostly I’m done.  Okay, not with the whole module, but I’m on track to being finished with the first block (of six) before the first day of the module.  In a word, that’s terrible!  For oh so many reasons:

  • I honestly didn’t want to get very far ahead.  I was thinking that being about a week ahead would help me smooth out any emergencies that came up.  (I’ve got a wife with a medical condition that sees me in A&E for about twenty hours a year, typically on a Friday night, doing my best to worry more about her being doubled over in pain than laughing at the drunks who can’t keep from sliding out of their chairs, I’ve got a baby who wants to practice parkour before he can walk, and a six-year-old who very commonly needs emergency snuggles.  Unavoidables happen.)
  • I’m kind of running out of things to study.  Problems worth having, right?  But my study habits have proven effective, so the last thing I wanted to do was to destroy them by letting up.  I might not be able to find this steam again for this module if I take my foot off the … Petrol?  Do you guys even have that saying over here?  I’ll settle with accelerator.  I didn’t want to take my foot off the accelerator.  I don’t know how that makes it steam, but that’s what I don’t want to run out of, so acceleratoring it is.
  • What happens if I actually do run out of things?  If I’m “done” by, say, February, but there are little bits and pieces that aren’t available until May, how will I find the motivation to go back and do them?  For example, TMA02 requires you to use TMA01’s tutor feedback.  So before I can put TMA02’s first draft down, I have to have submitted TMA01, waited for its deadline to pass, wait for it to be assessed and marked, and then I can start it.  And then draft, draft again, and then maybe a draft or two.  And then draft.  And finally submit TMA02.  And then wish I’d given it a few more drafts.  But all the material for it will be ages out of mind again.

And keep in mind, all of this is while doing other computer science MOOCs on the side.  Those ones, in fairness, I’m not really giving my full attention.  I’m watching the lectures, I’m doing the activities and exercises, I’m handing in the assessments, but I’m not taking notes, doing extra reading, researching questions I have, or studying them, I’m just doing them.  Like high school.  Just showing up and doing what I’m told.  (I have a nagging feeling that didn’t turn out so well …)

So one solution I’m thinking of is increasing my study intensity.  Which one do I worry about more?  Burning out by taking on too much, or losing interest by getting bored with insufficient materials?

I have a feeling in a few years I’m going to think back on this decision quite wistfully, that my biggest study problem was not having enough to study.

Okay, then, what have I done?

Block one is allegedly about “Myself” in relation to a digital world.  I don’t recall reading anything about me, really.  I may have missed it.  I haven’t been asked my opinion on much, either, except how much more awesome the writing skills of teenagers have become due to digital technologies.  (Err …)

The first part is allegedly about making students aware of the digital nature of our world around them, but is really about making sure we can simultaneously read and think.  Go me!

The second part is allegedly about the history of computers from a curiously narrow context: The four generations of computer hardware, spanning their entire history … From the mid 1940’s to the late 1970’s.  (Also some maths about exponential growth and binary counting.) Really the second part is about taking notes.  (Mental note: NEVER AGAIN WITH THE SPRAY DIAGRAM! IT IS THE DEVIL!) (Mental notes are not covered in this part.)

The third part is allegedly about HTML and markup, but is actually about … Well, no.  It’s actually about HTML and markup.  Well done, guys.  (It also has a critical process for evaluating sources.)

The fourth part is allegedly about how digital communications technologies make the world smaller, but is really about forcing you to play with a terribly dated Java applet that someone is waaaaaay too proud of, that basically amounts to a graphical TraceRT and a minor security violation all in one!  Yay!  (There are other and better tools.  Good luck to all the tutors who have to fight with students to disable their Java security settings!)  There’s a very (very) bad primer on TCP/IP, as well.

The fifth part is part of the programming guide.  The less said about this here, the better.  I’m not a fan.

And the sixth part is … Well, I’m supposed to find out tonight.  It’s allegedly about wireless and mobile networking, but is probably really about … Iunno, maybe someone’s recipe for guacamole.  It’s hard to keep track.

I’ll have to write more about the programming guide tomorrow.  As this is the second-to-last presentation of this module, it won’t really benefit anybody, but my recommendation is to skip it and study a children’s Scratch MOOC, instead.  (See previous blog entries.)

by ·0 Comments

Course Title: CS002x Programming in Scratch
Provider: Harvey Mudd College via edX
Price: Free
Level: Introductory (suited to children)
Effort: 6 hours per week for 6 weeks, commencing on a set date
Prerequisites: None
Completion awards: Verified Certificate for USD$49

About the course:
This is not at all a bad course.  It’s well-suited to children, or really just about any ability level.  The children do need to be able to understand a fair amount of logic.  It’s a bit much for my 6-year-old son, even though he enjoys using Scratch.  (His ability level is simply knowing that command blocks are instructions for sprites, and lists of command blocks can be strung together.)

The course is described as a computer science course, but I really can’t feel like that’s justified. It’s a tour of Scratch’s capabilities, but doesn’t often describe theory or reasons for much.  There is an excellent amount of work with iteration, however.  One brief section also compares Scratch to industry standard programming languages, to show how the learning can be applied outside the Scratch environment.

Aside from it using Scratch, there was no prior indication that it was aimed at children, which it really is.  As Open University’s TU100 uses Sense, an off-shoot of pre-1.4 Scratch, there’s no reason to believe that a computer science course which uses Scratch must be a de facto children’s course.  There were plenty of students across many abilities and ages, so the discussion forums were a bit uneven at best.

The tour of Scratch begins with Scratch as the idealogical descendant of Logo incorporating a turtle graphics system.  This was bizarrely effective, because I was able to recall line-for-line programmes I wrote in Logo back in 1986 or ’87 after two weeks of lessons during elementary maths.  I reproduced it with just the addition of colour.

It winds past variables, iteration (as mentioned above), input, sprite-interaction, if-then-else logic, more iteration, functions, external calls, and even implies recursion with sprite clones.  Okay, for me, it took about 10 or 11 hours to get through everything but the final project, but that’s quite a list, and I can easily see it taking a young student a few weeks to get through that all.  But they will get through it all.  It’s all very logically laid out, it’s interesting, fun, and cool to keep them engaged, there are always lots of examples, and the progress made is a great confidence builder.

One confusing aspect is that the course has been adapted from some other curriculum, so it occasionally refers to weeks or other structures not present in the online, self-paced course.  It’s easy enough to ignore, but raises questions of how thoroughly prepared it is.

Two questions you might have for me are why did I take it, and what did I learn.

As stated, TU100 at the Open University, my first degree course module, uses Sense, which is based on Scratch.  Though I’ve played with Scratch before, and been impressed by it, I haven’t done anything in depth with it.  I was unaware of its true capabilities.  In a way, it’s a bit of a tragedy that I did that.

Scratch 1.6 is amazing.  It has functions, clones, lists, recursion … It’s great.  Sense, based on 1.4 or before, does not have clones, has no in-built stack for handling recursion data, and has to use calls for functions.  It appears as though it does have lists, in a custom solution.  I haven’t used it yet, so I’m still not sure.  I’m just lamenting that if I want to do recursion, I’ll have to use those lists to build my own stack.  Every. Single. Time.

And what did I learn?  Plenty!  One of my favourite moments was when I was polishing up my final project, and I wanted a custom score counter.  I searched the Internet for a Scratch solution, but couldn’t find anything that worked the way I wanted.  The closest I found was one which had a pre-set number of digits, with a separate sprite for each digit.  I realised that I could use recursion to call new clones of a single sprite to dynamically create as many digits as I wanted.

Another great moment is when I wanted to re-write a Rock-Paper-Scissors demo to include Rock-Paper-Scissors-Lizard-Spock.  The course wanted an If statement for each of the possible outcomes.  With Rock-Paper-Scissors, that’s just 6 possibilities.  With Spock and Lizard in the mix, it goes up to 15, and that’s already annoying.  So I diagrammed out the possibilities, saw a pattern, applied some modal maths, and realised there were really only three possible outcomes after said application.

So here are a couple of the things I created.  You can look inside any of the programmes to see how I did them, keeping in mind that I was learning as I went, so it’s not always the most logical way in the simpler programmes.

Jet Bike Steve: You Win Some, You Jetsam (Final project) WASD or arrow keys, up, W, or space to fire. 10 points per second survived, 10 points per star shot or collected, 25 points per bomb shot, and 50 points per guided-missile shot.

Derpa Deadfish (a game for my oldest boy)  You can go down, right, or left, but can only float up. Collect worms, avoid sharks (or turn them off), and use the safe-zone pad at the bottom.

by ·0 Comments

Course Title: How to Code – Systematic Program Design
Provider: University of British Colombia via edX
Price: Free
Level: Introductory
Effort: 5 hours per week, 5 weeks per course, 3 courses – about 75 hours
Prerequisites: None
Completion awards: Verified Certificate for each of the three courses (USD$49 or $50, depending on which link you click on), automatically awarded XSeries Certificate if all three Verified Certificates are awarded

About the course:
Go.  Sign up now.  I don’t care if you hate computers or have been programming professionally for years.  This is an amazing series and getting through the course is highly rewarding.

There’s a lot to say about this series.  For one thing, the level of effort required is very real.  It took me three or four weeks to get through all three courses, and I was staying up late for hours on end.  And I’m considering working through it all again so that I retain it longer.

Beyond that, let’s start with the concept.  The SPD course introduces the idea of designing a computer programme as an abstraction layer between the solution and the coding.  It’s a tool for producing a template for a solution which is orthogonal to the language being used.  And it’s genius.

SPD takes this method from the How To Design Programs book, by Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, and Shriram Krishnamurthi.  It focuses on data-driven programme design, which was a new concept for me.  You define data, which informs what can be done with it, which influences function design, and so on.  By the end of the course, there were still experienced code-jockeys decrying the lack of well-named variables, without realising that when you’ve clearly defined your data and what it can and can not represent, it’s irrelevant. You can’t possibly be confused what “variable c” means when you’ve stated that the only valid data type for variable c is degrees Celsius.  If you’re an old hand at programming and haven’t used data-driven programme design before, it’s worth a look to evaluate why you do things the way you do them.

It uses its own beginner language that isn’t outrageously useful outside educational context.  It is Turing complete, but it’s a bit of a pain to use in real situations.  Its environment is also quite slow.  The reasons for not using a commercially viable language are discussed early on, and I wholeheartedly embrace those reasons.

By the end of the first course, you’re already designing your own programmes using the data-driven model. It was around this point that I realised the beauty of defining the data and describing functions based on it.  If data X has properties Y and Z, then I can write functions for X that read and/or modify Y and Z, either by itself, or in relation to other data.  It dove-tails beautifully with object-oriented programming, but the course doesn’t cover application of its high-level theories to low-level techniques with other languages.  (However, the ProgramByDesign project is also working on How to Design Classes which features at least a subset of Java.)

Professor Gregor Kiczales is one of the best technical instructors I’ve ever seen, and I used to do that professionally.  His focus is on getting the programme design right, so that the code can flow naturally from that design.

It is an amazing foundation for how to approach programming design.  Playing with Scratch, I didn’t imagine I could possibly apply the HtDP principles to such a strange and specific programming environment.  However, I ran into a few bumps so I broke out data definitions and templating, and solved the problems in minutes. (Note: Never underestimate the power of testing well-chosen and well-defined examples.)

Anyway.  Just sign up.  Sure, it’s 50 to 80 hours out of your life, but it re-introduces you to the digital world in a way which will undoubtedly increase your comfort with it.