by ·0 Comments

I shot my final TMA of the year off to the submission service last Thursday, but just finished with the proof reading and resubmitted it. (I’d rather have an unproofed version marked than forget to proofread and submit.)

The TMA was really enjoyable, and there was a lot of room for creativity, more creativity than I’ve experienced at the OU so far. I do pity the tutors having to mark submissions which can basically come from anywhere. I was, perhaps, a little too free with the specification. There are times when it informs a specific order of steps to be taken, and I change the order and do the seven-step process in two (well commented) steps, instead. I’m pretty sure that I will lose marks for it, but I’m extremely confident of this assignment. I expect to get better than 90 marks, but even if I did spectacularly poorly, I’m unlikely to get anything but a Distinction on the OCAS portion of my results.

(Wow! Look at me be all cocky. I’m normally hedging every prediction I make. It feels good to be completely confident, for once.)

The OU and I both agree that one of the best things that students can do is reflect on their study methods to discover the most effective way for them to learn. Because of my own reflection, I’m not going to start my revision for the exam quite yet. If I were to do so, I fear I’d burn out well before June, and forget half of what I’d revised.

Instead, I’m currently making small programming challenges for myself, and trying to code them by hand. (An example from last night is to parse a maths problem written in text, such as “28 × 17.04”, along with some error handling and resiliance.) I’m not having much luck witing code by hand, though, because I don’t design programs from top to bottom. If I’m writing a method, and realise I need a helper method, I normally jump to my helper methods section of a class, and put a method outline there, including proper header and an appropriate (but wrong) return line, then jump back to the method I was writing. I can’t do that on paper. I’ll have to learn how to plan every single detail before I write anything, and I just don’t know that I care to train myself how to do something I never plan to do. I’ll take a lower result if I have to, I think.

Anyway, we’ll hit up revision some time toward the end of April, I think.

by ·0 Comments

Course Title: 6.00.1x Introduction to Computer Science and Programming Using Python
Provider: MIT via edX
Price: Free
Level: Introductory
Effort: 15 hours per week, 9 weeks (really 8 weeks and 1 day) — about 120 hours
Prerequisites: Basic algebra, aptitude for mathematics, prior coding experience helpful
Completion awards: Verified Certificate ($49) with at least 55% course marks, and 3 credits “Academic credit” through Charter Oak State College (65% course marks and $100 in addition to the verified certificate)

About the course:
This course is heavy on the “Introduction” and “programming using Python” portions of its title, and somewhat lighter on the “computer science” section, but it does a credible job of each.

It dovetails beautifully with the Systematic Program Design series I reviewed a few months back.  On one hand, this course gives object-oriented context to the basic principles in the SPD course, and provides a great roadmap of what’s next.  On the other, the SPD course fills in a lot of the data structure and raw theory gaps in the MITx intro course, as well as showing recursive design in a much more powerful light.  Taken together, they really feel like solid first steps into really understanding what’s going on under the hood, and how to direct the processes.

This edX course is an updated and platform-specific version of the MIT Open Courseware teachings on the same topic.  I flipped back and forth between the 2011 version and this one for at least half of the course, so some of the specifics I remember may actually be from the OCW course.  It’s difficult to choose a favourite lecturer between Profs. Grimson and Guttag; they both present the lectures with humour and clarity that’s easy to follow.  The bite-sized pieces of the edX course are generally better, but the poor “finger exercise” knowledge checks count against it.

To help students gauge their comprehension of the material, these finger exercises are interspersed between lecture segments.  Often, though, it seems like they’re just there to make busy work, as they’re not checking knowledge that’s useful, they’re just exercises that test nothing so much as your patience.  The worst of these are when they test concepts not in the lectures, which is defended by the TAs as inspiring independent study.  This excuse is somewhat undercut by the text on some finger exercises which states not to get too frustrated with a concept, as it’s explained in a later lecture.  If it’s explained later, then clearly that’s where we’re supposed to learn it, not through independent study, or they wouldn’t ever explain it.

There are so many concepts taught (well) through this course, I really can’t pull out a list.  In general, there’s a lot of coding principles, such as operators and operands, expressions, variables, calls, specific data structures, loops, recursion, conditionals, etc.  Discussion of address pointing supports lessons on mutability and cloning. Functions and objects, heirarchies.  There’s a fair bit to do with abstraction, though I feel this is handled better in SPD.  On the other hand, this course did a much better job of exploring algorithm complexity and costs.

Among the most useful (to me) portions of the course were the problem sets.  These were typically program problems you were let loose on to solve however you wish. Well, that’s how it was on the OCW version of the course.  In the edX version, which grades your programs and therefore has a very narrow interpretation of success, you mostly had to solve the problems how they wished.  It was really frustrating after the freedom of the OCW problem sets, especially when the same problem sets from one couldn’t be used on the other, and one case where the accepted solution technically required a different answer than what the problem description requested.

The required time for this course is way off.  First of all, this is not a self-paced course, and each “week” is released serially.  However, though it takes eight weeks before the content is all dished out, there’s really only six and a half weeks of content.  There’s a two week break between the third and fourth week releases, and the midterm exam is then inserted AFTER the fourth week begins, so it’s not to allow time for that.  Then the last week and a half are likewise empty of content, aside from the final exam.  (The final half week isn’t really useful, feels tacked on to advertise the next course, and falls well short of the OpenLearn data science introductions.)

The time you spend is then split three ways: Time watching the lectures and doing the exercises, time doing the problem sets, and time researching and revising.  If all the problem sets were written lucidly, I’d estimate about 10 hours per week, or about 65 hours.  Poor writing on the problem sets (similar to the above issues with poorly written finger exercises, but with an emphasis on the required solution differing from the requested solution) probably expand it to roughly 12 hours per week, or around 80 hours.  This is very close to the 50 to 80 hours of the SPD course, but I feel the SPD course is more informative of computer science, and less frustrating.

I think if I had it to do over, I’d do the OCW version instead of the edX version, just because it’s easier to evaluate my progress on my own than to have a computer do it.  Oh, the irony.

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

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.