Day 14, Sunday and more coding

I have been trying to improve my personal project for a while. It is extremely frustrating when trying to get oAuth to work with Flickr. God…. I tried many node libraries and most them are so close to working, but none of them is good enough. Until today…. I finally give a try and it is amazing!!! I got most things to work just after two hours. Amazing!


– Setting Git color in OS x:

$ git config --global color.ui true

– Oh. I stayed in this coffee Shop. Farley’s Coffee at 33 Grand Ave  Oakland, CA 94612. Totally awesome. Wifi is fast and there are tons of desks to work. (hint, there is a 2nd floor).


Day 13, paybuddy and D3.js

I can’t believe it is already two weeks into the class.

Zak, Jake, Sonomi and I took a very nice walk during our two hour lunch break today. It was great to walk around and explore the area with friends. We even went to a cathedral that sits on top of a hill. We joked about we should use D3.js to replicate the cathedral glasses. It would be really cool and when you hover the mouse over, the image would change into Marcus. hehe. That would be nice.

Anyway, there is no formal lecture today.

– Marcus went over the solution for the bind(). It was fairly straightforward but some classmates were still confused.

– Marcus live coded some D3 with us today and it was fun to see him approaching a new library. We struggled around how to get element positions per frame. Then, we realized that d3.transition.tween(‘name’, callback) will run callback() per transition. It also expects callback() to return another function (let’s name it worker(t)), and subsequently it runs worker(t) per frame. It makes total logical sense to separate those two things: actions per transition and actions per frame. But hey, hindsight is always 20 20. In the debug process, the class shouted and offered tons of wrong ideas, myself included. I will try to be more careful next time.

Social life:

– The class went to Karaoke at 6:30pm. Most people went but I didn’t go. Instead, I worked on Paybuddy repo. Paybuddy basically asks you to validate a payment form. It sounds easy, but there were tons of small twists. For example, credit card ccv can be 3 or 4 digits; the month of expiration date needs to be between 1 to 12  and tons of others. It is tedious , but every frontend developer should try it at once. Validation form is hard enough, and all other payment steps are going to be even harder. No wonder Stripe is a big success.


Day 12, layout and D3.js

This sprint was slightly ambiguous because we have four repos to work on. They are: layout, pay buddy, d3.js and regex.  I am fairly familiar with regex so that one is not a big deal. In layout, we are supposed to copy the layout of three websites.

The layout was a simple exercise yet was tremendously helpful. Throughout, I realized

– floated divs won’t give its parent any height info unless you say parent { overflow: hidden}

– If you want to keep things on the screen in sync with where they are in the HTML, try float:left

– One way to rearrange three divs in one row: div1, float left; position: absolute  / div2, float left; margin-left: 100px / div3 paddling-left: 600px

Other lessons:

– the safest way to hi-jack this binding

var bind = function(fn, context){

var args =,2);

var new_func = function(){

return fn.appy( context, args.concat( arguments) );



– Arguments are passed as references, but some are immutable


Day 11, N queens and bit shifting

Today is crazy and most people agreed that this is one of the hardest sprint so far. Marcus made a deliberate point that the N queens sprint tends to divide people into two groups. As a matter of fact, I can provide anecdotes. At least one person said “this is one of the most awesome sprints” and at least one person said the other way.

Zak and I were average in this sprint. We made solid progresses and finished all basic requirements plus some extra credits. The road map of optimization is : using all the helper functions provided -> using HashTables -> using bit shifting. We got the HashTable version up and  running, and I was disappointed that the speed boost wasn’t as big as I expected. Zak spent tons of time on bit shifting but we didn’t have to time to implement it.

Anyway, an exhausting two days. The most difficult concept for me is to recursively traverse all possible arrangements on the board. Recursive traversing is such a hard concept in general that I still need sometime to really get it.

Now I know at least two solutions to traverse. One is to toggle on the location before going to the next row and toggle off  when finished. The other is to pass two parameters, namely a prefix and a bag. I got the toggle version working. I got the prefix and bag solution to work on traversing a tony matrix, so the solution is close.

Other lessons:

– There are 3 ways to solve the 1to5 to 1to7 problem. First one is the one I used, throwing dice seven times; second one is using a 5 by 5 matrix, basically only throwing dice twice; third one is using bit shifting. Not 100% sure about the other two ways.

– Also learned about “grep – R ‘searchterm’ * “; ENV_VAR = 1, then echo $ENV_VAR. I keep forgetting about the $prefix…


Day 10, N queens

Today, we started working on N queens problem. I don’t even know the rules of rooks or queens, so when I was asked to answer a question from Marcus, I totally bluffed.

Our toy problem is an interesting one. In short, you are supposed to use Math.random to write a random1to5 function that returns a random integer of 1 to 5. Then, you are supposed to use random1to5 to write a random1to7 function that returns a random integer of 1 to 7. My initial thought was fairly naive because I forgot about the integer requirement. I scaled the number space between 1 to 5 to the number space between 1 to 7. That was easy, I thought. When I started writing the test, I realized I answered the wrong question. The real question is similar to: given a dice, how to generate a random integer between 1 and 7. My short answer is that you just need to throw the dice 7 times.

We also learned about jQuery. It is ridiculous that I have been using jQuery without understanding the difference between the jQuery collection object and the DOM objects.

What is jQuery?

The short answer is jQuery is a function that produces jQuery collection object.

What is a jQuery collection object?

– It is an array-like container.

– It contains zero or more DOM nodes.

– It also contains tons of jQuery methods, which are functions that attach to the jQuery collection object and allows easy interaction with the wrapped DOM nodes.

– $node[index] will return a DOM node WITHOUT any jQuery methods.

Three ways to generate a jQuery object:

1. jQuery(‘<p>dd</p>’);

2. jQuery(‘.name’);


4. Note: jQuery collections don’t update dynamically. (I miss you, Meteor)

What can jQuery methods do?

– CRUD + more. Create; read such as $node.parent(), $node.each(callback); update such as $node.animate(), $node.on(‘click’, callback), $node.appendTo(target); delete;

Other lessons:

– Elements panel in Chrome is the actual DOM object represented in HTML. That is why they are perfectly indented.

– Any object has a splice() method will be treated by Chrome console as an array like object.


Day 9, dancer party sprint continued

Life was fairly easy today. The instructions were very vague about what we were supposed to do, so the amount of work was up to us. Tuhin and I had a blast. We created a “dotting with friends” where mouseover attracts all the dots on the screen, single click repels them and double click makes them into a perfect circle. It was a cool game and Tuhin was really addicted to play around with it.

Other lessons learned:

– About “this”. Any function that accept a call call, the “this” binding is likely to be lost inside the call back. For example:

//this is not good

setTimeout(this.stepfunc, 5000)

//this is good

var that = this;



}, 5000);

– About re-use functions from the super class:

BlinkyDancer.prototype.step = function(){;


– Marcus said we should try implementing particle simulators in the future.

– He also said that the commit message should be about the interface, not about the implementation. Basically, tells “func1() is now doing this” instead of “func1() is using x and y”.


Day 8, dancer party sprint

We started a new sprint, with the purpose of using jQuery, CSS and HTML5. The assignment is fairly straight forward. There is a Dancer class that we need to extend to a subclass and the subclass are supposed to do all kinds of random stuff.

The biggest challenge is to convert the Dancer class and its subclass from the original functional form to the industry standard pseudo classical form. It takes a very long time for us to figure it out.  The syntax is not very intuitive. For example, we had Dancer class and BlueDancer subclass.

To establish the class-subclass relationship, we need to do:

BlueDancer.prototype = new Dancer(); // or BlueDancer.prototype = Object.create(Dancer.prototype);

BlueDancer.prototype.constructor = BlueDancer;

Inside the BlueDancer class definition, we need to add one line:, arguments);

A couple of lessons:

– When a class creates its instance, the instance’s constructor property is automatically pointed back to the class.

– As soon as a function is declared, its prototype property and its prototype.constructor property come to existence. This is before any call to this function has been made.

– Mixin. They seems to be a cool way to modify objects efficiently. Mixin is more like a graph, while subclassing is more like a tree. When the constructors are mostly empty, they can just use Mixins.

– The difference between Mixin and subclassing is that Mixin works on existing objects and subclassing are creating new objects.

– We talked about whether ‘this’ would be part of the _.each()’s interface. The conclusion is that if the understanding of ‘this’ is required to use the function correctly, then ‘this’ is part of the interface.

– We also learned about pseudo classical, prototypal and functional


Day 6, Hash Table and Binary Search Tree

Today is the last day of the second sprint on data structure, and I am getting into a new domain of knowledge.

In the last three days, we covered fundamental data structures such as Stack, Queue, LinkedList and Set. They are very simple, with real world analogy and easy to understand. In contrast, HashedTable and Binary Search Tree are slightly further away from the physical world. Jake and I finished almost all the extra credit on HashedTable, and some extra credit on Binary Search Tree. I should find sometime to finish all of them because they are helpful in job interviews.

The big learning today is the algorithm for algorithm. In short, you need a plan before writing the program. In more elaborated terms, you need:

– Establish the rules of the problem. In other words, clarify around the problem and make sure you are not solving the wrong problem. Marcus gave an example on how to arrange queens on a chess board. The problem could mean any of the following thing:

1. An arrangement of eight queens

2. A single solution for any n queen

3. The total number of queens you can possibly put on a board

– Explore the problem space. It includes limited testing (still inside the problem domain) and edge cases (borderline and maybe outside the domain). A good example is when testing sum(a, b): limited testing would be a=0, b =10; edge cases would be a = infinity, b = infinity or a = “hello”, b = “bar”.

–  Test Driven Development. You start by writing a tiny test that is doomed to fail and try to fix the test. The only problem I had is the “tiny” test piece. I prefer a reasonable size of test that is going to fail and then try to fix that test.

– Make a plan that solves the problem. For example, if you are going to pair socks from a pile with 10M socks, are you going to try sorting all socks by color first, or are you going to do context based hashing(?) ?

– Write pseudo code. Jake and I tried some pseudo code today and it works pretty well for us.

– Step through your pseudo code.

Oh, social night. We went to the trampoline park today for a social event. It was fun and someone were definitely more adventurous than others. I begun to wonder whether adventurous is a good thing or bad thing for being a developer.


Day 5, data structure 2 continued

We learned more about different types of data structures and continued to work on the second sprint of data structures. We learned about:


– LinkedList (single or double linked). The single linked LinkedList is great for modeling the prototype chains.  Constant in insertion time. Linear in look time.


– Constant in lookup time. Linear in insertion time if insertion is not in the end of the array.


– Similar to LinkedList except each node can have multiple children. It is good for modelling hierarchy; and it is good for finding an element if the tree is sorted.


– A collection of key-value pairs that satisfies the following constrains:

1. constant in lookup time.

2. constant in insertion time.

3. each key has to be unique.

Jake and I spent a lot of time time on HashTable and I think if I were an interviewer, I would ask my interviewee to implement a HashTable for me too.

The hash function is deterministic, stateless, and a upper limit. I can image those hash functions must come from the best mathematicians.

Rehash is also necessary when the current hash table becomes either too crowded or too sparse.

We end up implementing a HashTable with nested arrays. The approach is cool, just working with nesting arrays really requires a clear mind all the time.


-Marcus emphasized that optimization should focus on the # of steps, not how much time each step spend. That is a great point. We also learned about the notation of O(1), O(n), O(logn), O(n^2) and O(x^n, where x is a constant).

Oh, code review. We did our first code review with another pair. It was ok but I pointed out they shouldn’t use the javascript Object when implementing the HashTable and they disagreed. Now I can see how code review can hurt people’s feelings. Everyone is emotionally attached to his code.