Age | Commit message (Collapse) | Author |
|
Created test cases for the hash function. Tested the code by running the
main function without writting test cases. I wish the starter code was
written in a way that facilitated testing...
|
|
I cheated and didn't modify the starter code so it's testable. It seems
that starter code in this course is not written as well as the first
course.
|
|
Another interesting problem to solve. I gained a much better understanding
of disjoint sets (aka Union/Find) through the coding challenge. A few takeaways:
1. Writing test cases is so important. I can sink my teeth into it and
have something concrete to work on, instead of wasting time beating around the bush;
2. Modify starter code to make it testable, if it's not easy to test to
begin with;
3. Get started early, so I can use my "sleep on it" technique. It really
improves understanding!
4. I'm slightly bothered by the fact that I don't have a test case to catch
the issue with grader test case 8. I looked at the code and added line 61
which enabled me to pass the grader.
|
|
Fun exercise. Facing a difficult problem, always take small/concrete and
concrete steps, and you'll get there! Writing down pseudo code helped,
along with creating a subclass implementing the Comparable interface.
Good thing that I've done that before and have example to follow.
|
|
1. Modifying code so it's easy to test is always worth it!
Easier to identify the next concrete steps and carry them out!
2. Hand build a few arrays helped my understanding.
|
|
Oh man, I spent so much time on this, on and off for more than 16 hours.
But it was worth it in the end! Initially I didn't even noticed that there
is a "what to do" part in exercise file, so I started coding following my
own intuition, which wasn't too bad. I felt like I was going places and passed
a few tests but failed one or two test cases. That's when things started
getting difficult. I tried thinking, paper/pencil, sleeping on it, and reading
forums (coursera, edx has no discussion on this when I worked on it). I
then realized the "what to do" part in exercise and started following it.
I should have stashed my code based on my own intuition, but I didn't. I'm
learning, after all. Then my code got really messy. I added a lot of if
statements and temp variables to get by, but it consistently fails on grader
test case 20. That test case input is from a file, so far I haven't learned
proper way of reading file as input in junit, so I started simplify my code
hoping that I can pass. In the end my code simplification did work and passed
the grader, but I really should learn how to use file input in JUnit, or
how to feed input file. Eclipse makes that easy, but not IDEA, at least not
the version of 2018.2. 2018.3 supposedly has it, but I don't know how to
upgrade it safely on my Manjaro yet.
Woohoo, fun stuff!
|
|
|
|
Yay!!! I got rid of the recursion and used an iterative function to calculate height. The trick used was to use a queue. It turned out to be faster and consumed less memory. Fun stuff and I'm happy :)
|
|
Following example starter code, I had to specify stackSize when creating the thread. Without it, it won't pass tests due to stack overflow error. I'll still try to work out an iterative version using Queue. We'll see.
|
|
Switching from Eclipse to Jetbrains IDEA, still using TDD methods. So far not bad. I like the fact that by using different IDEs, I can see what kind of help the IDE provides (coding style, best practices, etc.). That can be helpful.
|