Going back to basics

19 Jan 2022

Whether it's the past or the future, only one thing is certain: Javascript.

It's been four years since I've written my last technical essay, and I've been able to experience different languages since then. In my opinion, I find that Python is easier to incorporate into most of the assignments and projects that I've worked on. For my Master's project in particular, I was tasked to create a simulated Ethereum network, and one of the Ethereum frameworks available to me was known as the Web 3.0 framework. The most popular version is the web3.js library which uses Javascript to check the balance of nodes, execute transactions, and other node functions. The other version is web3.py, which has been described to sit on top of web3.js and allows the user to use Python scripts to perform a subset of the same actions. When deciding which one to choose, one of the big criticisms of using the web3.js library was that Javascript is hard to debug. This would become apparent when trying to automate certain functions, the console would print out an error and the stack, but I would have no idea on what the console was telling me. This was due to two issues that I had. The first issue was blockchain development isn't very popular. This makes it difficult when it comes to finding issues and errors on forums such as stack overflow. The second problem was that I was very new to Javascript. This made it difficult to create code around certain objects such as a Promise(this will come up later). So I decided to use the Python version of the library and built my project around that since time was a factor.

ES6:It's like ES5 but spicer!

There were two "submodules" in our introduction (or in my case a refresher) to Javascript. The first was a simple introduction to Javascript. With the more interesting exercises involving the manipulation of items within a dictionary, and since I did quite a bit of that on Python it was fairly similar. Functions such as the delete function call were new to me, but allowed for easy JSON manipulation. The second submodule was based around ES6. Although the exercises were easy, the destructing exercises were "awkward". I say they were awkward because I'm very used to the ES5 paradigm, where you can call Object.variable and manipulate data from there.

For example there was the exercise:

//start of problem const stats = { max: 56.78, standard_deviation: 4.34, median: 34.54, mode: 23.87, min: -0.75, average: 35.85 }; //Only change code below this line const half = (stats) => (stats.max + stats.min) / 2.0; //End of problem

The answer was:

const half = ({ max, min }) => (max + min) / 2.0;

My only issue is that I have no idea where it references the stats object in the first place. As someone who isn't familiar with ES6 how can I be sure that my variables are appropriately called without referencing the stats object directly in my code? The ES6 submodule also had the concept of a Promise. From my experience with Promises, I had learned about the basics of the resolve and reject that a promise gives. Promises are used during asynchronous functions, such as requesting a wallet's balance on a blockchain network. From my understanding Javascript isn't designed to have asynchronous processes, but with a promise, your code can: run, initiate the promise, then continue without having to wait for that promise to finish so long as you handle the resolve or reject appropriately. When I first ran into errors in the web3.js library, I didn't know how to handle a reject. It wasn't as simple as using an if statement to catch the reject. It turns out that a promise has a catch function that can handle the return a value. Therefore, you can create a handler for the result of this catch, and utilize that in your code. I would later find this out on my own, but this exercise would have made it a much less painful experience when I came across it.

But is it good though?

With all of that said, I think Javascript is an excellent language. I still find it to be incredibly useful when it comes to working with anything involving web development and Web 3.0 is no exception. When comparing the amount of features that are available for web3.js library to the amount in the web3.py library, the Javascript library is more expanded. It's important to remember that the web3.py uses web3.js library meaning that it's technically a Javascript cake with some Python frosting to make it easier to swallow for new users. Another reason to use Javascript is the amount of libraries that are available. If there's a task that you're tyring to accomplish on the web, Javascript probably has a library out there to help you do it. From my limited experience I've seen libraries to create and animate graphs, libraries to work with smart contracts on the ethereum networks, and various frameworks for app development. One weakness of having such a variety of libraries is that if these libraries are no longer maintained they can be removed. For example, the library faker.js was removed from NPM and there was nothing that developers could do about it. But overall, it's still nice to have the option to use a variety of libraries to get your web development needs to be met.

Drills give you skills to pay the bills.

When I took the undergraduate version of software engineering. I was introduced to the concept of the athletic software engineering. If you read that phrase at face value it seems like an oxymoron. One of the stereotypes of software engineers is that they aren't your typical athlete. If we look at the Wikipedia definition: "An athlete is a person who competes in one or more sports that involve physical strength, speed or endurance..." This definition also doesn't seem fit aspects of software engineering. But if you break down the core concepts of "training like an athlete", then the concept of athletic software engineering begins to make sense. Athletes train in multitudes of ways. One of those ways is by doing drills. Drills can be defined as exercises that involve isolating certain movements and/or situations that may occur in a sport. Drills are often repetitive and allow athletes to precisely understand all aspects of a particular situation or movement. This allows the athletes to gather a better understanding of the mechanics of the movement and/or the thought process to handle the situation. An example of this can be as simple as a drill that focuses on throwing mechanics. This involves understanding where to hold a ball, how to hold the ball with your hand, and what should the rest of your body be doing during a throw are important for sports with throwing. Another example is the two-minute drill in American football. This drill is to simulate a situation where there is less than two minutes left in a game. The pace of the game is much quicker meaning teams need to understand a specific set of plays that they will be doing. The drill focuses on making sure that communication is clear and that players are mentally strong enough to execute the plays properly during the final push of a close game.

What does this have to do with software engineering?

Let's look at the Workout of the Day otherwise known as a WOD. These are supposed "drills" that will teach students how to think on their figurative feet when given a software engineering question that involves the current material. I remember my first WOD in the undergraduate version of this class and how I failed it. After going over it with some of my classmates the logic was correct, but I believe I used the wrong equals sign which caused my function to not work. It made me question myself. If I couldn't complete the easy WODs, how am I supposed to get the hard ones? I watched the screencast, did multiple attempts on the practice problems, and I even went to the practice WODs. For me, it seemed like WODs weren't beneficial in my learning.

How can we make homework WODs more like drills?

Although the WODs were supposed to feel like drills, they felt like any typical exam. Drills allow for immediate and specific feedback, but due to the size of the class it's expected to not have this kind of feedback. Even during practice WODs, dropping hints for students who are lost and/or not used to coding can be helpful. The idea of "time's up, here's my example" isn't a good way for people to precisely understand which part of the WOD went wrong. This only shows that they memorized the screencast, not that they learned something new. Another thing is, if someone doesn't understand their problem, how can they ask a question specifically for a solution? For homework WODs, students are tasked to complete the assignment/exercise at least one time. If they don't finish they can watch the screencast right after and attempt it again from the beginning. Even though it isn't recommended doing the problem with the video up, students could be encouraged to:

Without starting a timer attempt the problem until they get stuck.
Watch the video up to where you got stuck.
Pause the video.
Continue until stuck again.
Repeat 3 and 4 until complete.

This method shouldn't count towards a timed attempt, but it's a way that students can identify which parts they actually need to work on. Rather than repeating the same thing over and over again from the very beginning. For instances where there isn't a TA or teacher available, I think being able to attack the WOD in chunks would be more conducive to athletic software engineering than using "start over and redo it from the top" by itself.

It's not all bad. Practice makes better, and practice WODs are great for that.

On the other hand this class still offers practice WODs. These are a great way to get help students improve and giving specific feedback. I think the practice WODs are great, as they have a teaching assistant to provide direct and precise feedback. It was during the first practice WOD that I heard the TA ask "Where did you struggle". I feel like a smaller class size allows students to be less ashamed to ask questions, while also allowing more opportunities for feedback(trying to give 20 students specific feedback in a single class session is stressful). More importantly, if other students had difficulty on that specific part they also are able to get feedback. Another positive change from the first time I took this class was the addition of having a partner to work with. Being able to ask questions to a person can be beneficial for both students. With all of that said, I'm interested to see what kind of experience the later in-class WODs will provide, and what kind of feedback will be available for students who are struggling in the class.

Going back to basics

Javascript isn't so scary anymore.