Introduction

The time is 7PM. Your software project is due at 11:59PM. You have yet to write the developer guide to document your software which is part of the submission. You are writing a testing plan which also serves as a guide for your graders to assess your software. As you were writing the steps to test, you discovered a regression. This feature that was working just 3 hours ago is now causing the application to crash! What happened? What would you do?

I was in this exact situation recently for a school project. I had to decide whether it was worth identifying this bug and writing a patch for it (and potentially breaking other features for whatever reason it might be), or whether I should continue with the rest of the submission documents. I panicked really hard. In that moment of desperation, from a deep region in my memory, I suddenly recalled: git bisect.

I had known the principle of git bisect – it essentially performs a binary search for the first commit which caused a particular bug. It was going to be the first time I was using it. I quickly looked up tutorials and documentation online. 10 minutes later, I found the commit which caused the bug. Quickly patched it up (whether there were further bugs is another story altogether), and went back to writing my other submission documents.

In that one usage, git bisect easily became my favourite git command. In this post, I hope to provide a simple use case and guide to use git bisect, while demonstrating how fast it can help you identify the violating commit.

A basic understanding of data structures and algorithms (array/linked lists and linear/binary search) and git (e.g. committing, checking-out commits) is preferred, but I think the concepts are intuitive enough and I will try to make it as accessible as I can.

Continue reading

Introduction

This is a reflection that is quite overdue! I was a little busy throughout the May-July vacation period, and could only find time to update my blog now. Better late than never, I suppose! Just a warning though, there is a lot of text, and almost no pictures in this post.

CS2040S is NUS’ Data Structures and Algorithms course. Originally, there were only two variants of the module, CS2040 and CS2040C. The CS2040S variant is introduced this recent academic year (AY19/20) as a means for module management of the growing computing cohort (or so I heard). More specifically, it is compulsory for Computer Science undergraduates matriculating in AY19/20 to take this variant of the module. The module uses Java for the problem sets, but written exams allow usage of pseudocode.

This recent semester (AY19/20 Semester 2), the module is taught under Prof Seth Gilbert, Prof Ben Leong, and Prof Soo Yuen Jien (also known as Uncle Soo). Prof Seth does the main delivery of content, while Prof Ben and Uncle Soo handle the administrative matters of the module. The module does not always have the same lecturer(s). When I was taking the module in AY19/20 Sem 1, it was taught under Prof Harold Soh. Future semesters might also be different.

I was a teaching assistant (TA) who taught a weekly 2-hour tutorial (discussion group) sessions of 12 students. I’ll write about my experience in this blog, while making some comparisons with my experience teaching CS1101S in the previous semester. Take note that this post is not meant to be a review of the module.

Continue reading

Introduction

In NUS, CS1101S Programming Methodology is the introductory course to programming for CS freshmen. It uses the Structure and Interpretation of Computer Programs textbook, which is adapted to JavaScript (it was recently announced that the adaptation is going public!). The course itself is actually taught by using a subset of JavaScript called Source, written and developed by the teaching team together with some students. I am aware that there are many undesirable things in JS, and Source aims to mitigate that by “providing the good parts”. That way, freshmen can still learn fundamentals of programming without having to learn the intricacies of the actual JS.

The module has been taught by Assoc Prof Martin Henz and Dr Low Kok Lim for several years now. Traditionally, it used to be an optional 5-Modular Credits module, slightly more workload compared to a standard 4-MC module. As of AY18/19 (the year I matriculated), it became a compulsory 4-MC module for CS freshmen.

Avenger is a term used in the module to refer to the tutors, usually undergraduates. A tutorial¹ class in CS1101S usually comprises of 6 to 8 students (only!), and led by an Avenger which serves the role of facilitating discussions. Perhaps they are best described as ‘Discussion Group Facilitators’. But hey, that’s a mouthful, and an ‘Avenger’ does sound way cooler!

In AY19/20 Sem 1 (Fall 2019), I took up the role of an Avenger. I led a discussion group of 6 students (initially it was supposed to be 8 but there was some reshuffling around). It’s been a super busy semester, and I would like to share my experience on being one. If you are a student contemplating on whether to apply on being an Avenger, hope this post can help provide you with some insights!

Actually, during the holiday break prior to the sem, I also worked as an Avenger for SWS3012, which is a 2-week Summer Workshop for visiting international students, taught with condensed CS1101S material. Due to this exposure, Prof Martin asked if I was willing to be an “Avenger Mentor” to mentor the new Avengers once the sem took a full swing. I took up this role. I will briefly talk about these 2 experiences as well.

This post will not be a review of the module, but rather a reflection on my experience as an Avenger, as well as my personal approach to being one.

---

¹ A tutorial class in CS1101S is called a 'Studio'. For readers who are not from CS1101S background, I will try to stick to the term 'tutorial' in this blog.

---

Continue reading