Day 4, data structures 2

There are two sprints for data structures, with two days per sprint. My pair and I finished the first data structure sprint yesterday and started to work on the second data structure sprint today. We implemented LinkedList, Tree and Set today.

One thing that really slowed us down was debugging the contains function for Tree. Because the contains function needs to search recursively, the function was written as a recursive search. However, when we passed the result around as a parameter of the function, we override results from our previous round. This creates enormous confusion and it takes us a good two hours to find the bug. I swear that from now on, when possible, I will try to avoid pass results in recursive function. Using a global variable is less clean, but much easier to read and debug.

Something important for today:

– Testing. During testing, only test the interface, and nothing else.

– Coding convention about capitalized function names. A capitalized function is supposed to be run with the new key word. For example, we should run: new Tree() or makeTree().

– Constructors in JS is only referred to the psedoclassical style(?) maker function.


Yes. There are so much to learn about Git such that we could have a lecture for it everyday. Marcus did a fantastic job today on Git and my understanding is getting much better.

First, I realized that pull request is a GitHub feature, not a Git feature.

Second, I realized that SHA is the unique ID associated with each state, and all the other stuff (branch names, tag names, HEAD) are variable names referring to SHA. As long as I accept the fact that Git will point those variable names to different SHA automatically in the background, life is not that complicated.

Third, HEAD is almost the same as the “you are here” star in the maps.

Fourth, I am guessing that the difference between fast-forward merge and none-fast-forward merge is whether a new SHA has been created or not, but I am not 100% sure.


Day 3 – data structures

Day 3 is the first day of 4 days of data structure.

First, we talked about high level concepts.

To break down a big problem into smaller problems and come up solutions, it is nature to do: modular -> isolate each module -> make sure each module are loosely coupled -> make sure each module has an interface -> make sure each module has some privacy

We also talked about abstraction. A good example is: a remote control abstracts the RC car. Abstraction is introduced for many reasons, including:

– to interprate js code to byte code

– to introduce modularity

– to digest complex ideas (so you can ignore most part of the idea and just focus on one tiny piece)

Second, we reflected on the previous sprint – re-implementation of the pre course work. The criterion we use are: clear / actionable / compassionate / honest. Key questions to address are: who drove / were you engaged / how could each of you improve? Because my pair in this previous sprint has three people instead of two people, we sit together and give each other feedback. My negative feedback is that I didn’t mention that we should continue to work on the extra credit.

Third, we talked about class. Interestingly, class in js is defined as “a function that produces many objects”. There are four ways to create a class. (I miss you, Python!) They are: functional, functional with shared methods, prototypal, pseudoclassical. The current sprint requires us to implement Stack and Queue in four different ways. Jake and I move fairly fast and we even had time to compare the performance of those four types of implementation. It is not surprising that pseudoclassical was about one order of magnitude faster than the functional and functional shared.

A couple of notes on those four ways of doing it:

– When use new Class1(), two magic lines code are inserted in the body of the function where Class1 is defined.

//the first magic line appears at the very top

this = Object.create(Class1.prototype);



//the second magic line appears at the very bottom

return this;

The effect of those two lines are such that we don’t need to redefine a new object and try to return it manually.

– No function can be both shared and have access to private variable inside class definition. Does this mean that the classical way of doing OOP (such as Java) is better in this regard???

– We also had tons of confusions about prototype during class. The only thing that seems to solve the problem is prototype basically means delegation of failed lookups.


Day 2

I brought FlashCards to take notes so I have a little bit more to report on the blog.


– the magic keyword ‘this’.

– In one sentence, ‘this’ always refers to “at run time”, the left side of the dot, of the function where ‘this’ was invoked.

– Exceptions are when there is nothing to the left of the dot, ‘this’ refers to ‘window’

Other tips:

– the prototype chains. Pass by reference. Object.protoype is the top level and there is nothing above that.

–  _.uniq() might be a common question in interviews

– will return [object Object], [object Array], [object Arguments] depending on what parameters are being passed in

– is a really visualization cool tool to show how your js code is being parsed

– array.reverse()

– typeof n === ‘undefined’

– In underscore, most of the time, the iterator takes three parameters, i.e. _.iterator(value, key, collection). Notable exceptions are _.reduce(function(memo, value, key, collection){})

– git commit every 5 to 10 lines

– Array.isArray() is not always working depending on the environment

– _.delay() doesn’t have the ability to pass a context as a parameter

– apply() vs call()