13 posts tagged with "thoughts"

Motivation​

const genericFn = <T>() => {
    return "This is a poorly written example generic function"
}

Above is an example of a function with a generic parameter T that could potentially be used within the function body. However, if the above code is saved in a .tsx file (In my context, within a React application, while trying to create a generic custom hook), you will receive with the following error when hover over <T>:

JSX element 'T' has no corresponding closing tag.ts(17008)
Cannot find name 'T'.ts(2304)

Exploration​

Defining generic function in TypeScript​

To resolve the issue, I started with researching on how to properly define a generic function in TypeScript. Perhaps I made a mistake somewhere in the above syntax. I landed on two articles here and here. Both of them talked about how to create a custom React hook that uses generics. However, the syntax used in the articles were similar to the above example but no errors were discussed.

While I did not find an answer after heading over to TypeScript-CheatSheets, I thought the note on avoiding type inference when declaring custom hook was an interesting point that I did not know about.

If you are returning an array in your Custom Hook, you will want to avoid type inference as TypeScript will infer a union type (when you actually want different types in each position of the array). Instead, use TS 3.4 const assertions:

export function useLoading() {
  const [isLoading, setState] = React.useState(false);
  const load = (aPromise: Promise<any>) => {
    setState(true);
    return aPromise.finally(() => setState(false));
  };
  return [isLoading, load] as const; // infers [boolean, typeof load] instead of (boolean | typeof load)[]
}

This way, when you destructure you actually get the right types based on destructure position.

Credit: TypeScript-CheatSheets

Google the error​

Moving on with the second strategy: "Google & Stack overflow". Searching the above error landed me on the following issue in the Microsoft TypeScript repository. There were a few more interesting links here and here.

So according to the reported issue:

The usage of <T> prior to the function braces causes a JSX error within .tsx files: "JSX element has no corresponding closing tag.". Basic example works as expected in a .ts file.

The issue was claimed to be a limitation and there were a few workarounds mentioned (in the thread and also in the related stack overflow post):

• change from .tsx to .ts
• add a comma: const f = <T,>(arg: T): T => {...}
• extend this way: const foo = <T extends unknown>(x: T) => x;
• or extend this way: const foo = <T extends {}>(x: T): T => x;

Thoughts​

Funny how issues like this one will continue to bite us even way into the future... simply because no one is going to do anything about it?

Motivation​

When I completed my first module in NUS, I winced at the thought of applying to be a teaching assistant(TA). I could not understand why one would put himself through reading messy and error-ridden code from students who just started programming. While comments from my TA of that time were helpful, they did not significantly impact my learning.

I changed my impression of TA after my first semester at NUS.

Two things happened​

I had a TA who told us "free feel to contact me for any queries and I will respond ASAP". Given that the class size was small(less than 10 students), I made full use of the opportunity to shoot many questions at my TA via the class Discord server. I received responses that were timely and thoughtful. This was great even though I did not require help that often. I had a sense of confidence that no matter what questions that I had in mind, I would have someone who could address them immediately. When I did require help for concepts that were difficult to understand, my TA was able to communicate with me via a Discord voice chat or a screen share. In summary, I had a great "user experience" provided by an excellent teaching staff.

I was also actively involved in a class discussion forum. While I didn't really ask questions, I read through many interesting ones that provoked my thinking. At times I would be drafting an answer to a question raised by another student and I would find loopholes in my justification. Or, when I thought things were supposed to work in a certain way, I would find compilation errors in the example code that I was going to use to illustrate my point. There were many late nights in which I researched and refined my answer to someone's question in the forum. That's when I knew peer learning or learning from what others have to say could be extremely valuable.

I realized that TA could greatly supplement learning and made an impact on how students perceive a module. The second realization is that the students who are taking a module have questions that challenge and poke the module material further. Utilizing that source of learning can make one acquire a deeper understanding of a module, even after taking it. Becoming a TA is a great way to tap on that resource.

My Turn​

The application​

I am grateful for such TA opportunities available for undergraduate students in NUS. I applied for a TA position in CS2030 Programming Methodology II with the following note to the prof, in case anyone who's interested to see a sample of how I broached the subject:

Hi Prof,

This is Yongliang, a CS student from your module CS2030S. I would like to indicate my interest to be a TA for the next semester.

Coming from background in Python(CS1010X), I was totally not “type aware” and had some difficulties with more complicated languages such as C and Java.

Before the current semester, I took CS2040 with Java and even after that, I had no idea why things were coded in a certain way. For example, why do people

write List<Integer> m = new ArrayList<>(); instead of ArrayList<Integer> m = new ArrayList<>();. So I looked forward to CS2030S very much

before the semester and I would say that this module really make it clear to me three aspects of programming: Java itself, OOP & Functional Programming.

Besides the module content, I also particularly enjoyed meaningful discussions I had with other classmates in our Github issues, where I learned more about type inference

and even things like “target type” and “type witness”. I personally enjoyed this module very much and would love to contribute if possible.

Also taking this opportunity to thank you for your care and support for the students, I appreciate it 😊

The experience​

Given that this was my first run as a TA, I would just summarize that the experience was fruitful and humbling. I shall write about it in detail in another blog post.

Reflecting on Teaching Tactics​

The whole teaching experience made me realize that teaching is difficult. Like most of the things I do, I then look for ways to improve. I chanced upon the essay "Teaching Tactics" by Eric Hehner near the end of the semester. Eric, who is a computer scientist and a professor at the University of Toronto, wrote about his thoughts and observations on teaching computer science courses. I find the insights expressed by him interesting and would like to discuss those that were surprising to me and gather some actionable items to incorporate into my teaching in the future.

The first point is on "acting stupid". In his essay, Eric described an experiment he conducted. In one of the semesters, he was tasked to teach two sections of the same course. He took on an authoritative attitude with the first class, where he solved all problems and demonstrated his excellent grasp of the material delivered. However, he acted unsure of himself in the second class. He appeared "stupid" and confused when presenting some problems. At the end of the semester, there were two comparisons made by Eric. The first comparison being teaching evaluations. The first class evaluated him to be an excellent professor who knew his stuff. The second class deemed him terrible and incapable to teach the topic. The second comparison being student performance. The first class did not do as well as the second class. While acknowledged by Eric that the standalone experiment would not be able to produce any significant conclusion, I thought it was a creative approach in understanding the best learning environment for students. I felt like I would have acted the same way as students in the two classes.

The second point is on "assignment vs assessment". Briefly speaking, Eric talked about his view that assignments should allow collaborative peer learning and answers should be freely available; Assessments, on the other hand, follow the more traditional examination approach. I thought that the separation is beneficial. As a student, I know that we can't solve all problems and there might be times where we would look for hints online or from our friends. Discussing a particular problem with others would also help us consolidate our learning much better than doing it alone. There is also the issue where we might have given up on attempting a difficult problem after hours of clueless efforts. A nudge from a friend could help tremendously, without revealing the solution itself.

The last point is on "online teaching". Learning has shifted online due to unforeseen circumstances that no one has expected. In his essay, Eric cautioned that simply recording a teacher teaching a class as per offline setting is letting go of the opportunity to harness the prowess of technology. He talked about bite-size videos and making the online sessions interactive by solving problems instead, given that students can view the lecture content beforehand. This got me thinking because I was teaching lab sessions where a problem set will be released and attempted by students in the session. As a TA, I can either do some more sharing of the lecture content that might be useful for students to tackle the problem set, or I can walk around to answer questions when students start to step through the problems. If I spend much time on the former portion, I would unavoidably eat into the time for students to ask me questions during the lab session. This balance is hard to achieve because I realized that explaining the concepts often takes up a lot of time in front of the class.

One possible tweaking, should I be given another chance to TA a programming module, will be that I might look into recording bite-size content to walk through some example code that explains the concepts related. I will then release them before the lab sessions for students to watch. If students are unable to watch it in their own time, they can choose to watch it during the lab session. If they know that they understand certain topics well enough, they can go ahead and attempt questions in the lab and ask me questions if any. This way students have control in deciding what kind of lab setting is most optimum for them. If they find my teaching style and explaining video to be ineffective, they could spare themselves the time and focus on the problem set and the guidance I could provide when they are tackling the questions.

Conclusion​

I expect my belief and thinking around the topic of teaching to evolve and therefore will continue to post related content on this area.

Reference:​

• Teaching Tactics by Eric Hehner

Goals​

Here is a mid-year update to the goals that were mentioned in my "hello world 2020" article:

• Secure one summer internship (or NUS'CVWO)

I managed to secure both NUS CVWO and an internship position at a local startup (I chose to go with the latter).

• Continue to write CS & web dev related stuff (at least on a Bi-weekly basis)

I wrote an article or two and had a few in the pipeline, but did not follow through with the promise of bi-weekly publishing. I need to reconsider this due to my other commitments.

• Be great at one module each semester (aim to TA for it)

I am fairly happy with what I learned in CS2103T Software Engineering, though I can't say I am great at it (result unknown as of now). I started to be active in the class forum right after midterm and that was fun. There were interesting discussions and I benefitted from peer learning.

• Put in efforts to develop one of my ideas to fruition

I am excited to start working on my ideas in the upcoming summer.

• Do one open-source project

Same as above, looking forward to contribute to possible open source projects under NUS in the second half of the year.

• Be wholesome and happy while doing the above:)

School​

Maybe it's time for me to write reviews for the modules that I have taken:

CS2100: COMPUTER ORGANISATION​

Low level stuff that computer science students might be interested to know. Lot's of 1s and 0s. Overall an interesting module that has a somewhat similar vibe with CS1231S Discrete Structures. Most content can come off as surprising and complex at first glance, but once I start to get familar with the topics, things like control, MIPs instructions and other binary stuff seemed less scary. Certainly not a module that I mastered, but I feel that the information in the module is good to know.

CS2101: EFFECTIVE COMMUNICATION FOR COMPUTING PROFESSIONALS​

A compulsory communication module paired with CS2103T Software Engineering. Focused on class interaction, group presentation and ended with essay writing. Because of my tutor's enthusiasm, it was easy to participate in class. The opportunities to practice group presentations served as great way to receive constructive feedback on individual communication shortcomings.

CS2103T: SOFTWARE ENGINEERING​

My highlight-of-the-semester module and I think it has an excellent coverage and great delivery. The course taught me things that software engineers should at least be aware of. This include UML diagrams, test case design heuristics and things like software project management. I would say it is fairly comprehensive and I picked up lot's of nuggets of wisdom that could possibly help in my future software engineering projects. Prof Damith and the teaching team were considerate and responsive.

The module also served as a playground to create and contribute to small to mid size code bases. The collaborative nature meant that one has to work with their team mates and participate in a range of team activities such as weekly meeting and peer review and discussion of issues as well as pull requests.

ST2334: PROBABILITY AND STATISTICS​

Another compulsory math module for CS students. Builds on top of JC H2 Math Statistics knowledge. Pretty much self-study.

DMY1401TT: DESIGN YOUR OWN MODULE (Machine Learning in Practice)​

Not as expected and I could have self taught the content provided. Mostly surface level stuff with some in-depth knowledge that was communicated at the surface level.-.

GER1000: QUANTITATIVE REASONING​

No intention to put any efforts into this module and going to SU.

IS1103: ETHICS IN COMPUTING​

I understand what this module is trying to do and appreciate how it at least requires minimal efforts each week. I won't explain much because of the super low workload.