Get the fundamentals down and the level of everything you do will rise. - Michael Jordan
As stated in my original post, I do at least 1 hour of video lessons from Watch and Code every day. If you're interested in learning Javascript in a way that goes beyond basic tutorials and gives you a foundational, practical knowledge without relying on frameworks - I'd highly recommend it. If you're reading these posts, please keep in mind that these are just my notes, and I'm not an expert (yet!). If your goal is also to master the fundamentals of Javascript, please head over to Watch and Code and start your journey there!
All screenshots were annotated using Shotty.
I've been less active with the blog posts over the past few days. As I approach the end of the class I'm finding that I'm really motivated to finish. Because of this, I'm enjoying staying more focused on immersing myself in the code than documenting the code in exhaustive detail.
Here's a summary of what I've been up to the last few days:
Format Column
We looked at how Accounting JS uses two separate calls to map to format values to be displayed in columns. This involves stripping away cruft and adding the appropriate amount of whitespace so that currency symbols all line up vertically.
Thinking Recursively
We looked at how formatColumn uses recursion with the two calls to map mentioned above, and when through call stack diagrams to help visualize the process, highlighting the fact that it's best to start with the base case, and then try the simplest possible recursive case. From there and more recursion will just give you repetition.
Broken tests
We looked at the tests for Accounting JS and realized that the tests aren't in great shape. First, Accounting JS uses both QUnit and Jasmine, with no clear reason why it uses both. Second, several of the tests are failing due to the fact that they're testing a very unrealistic edge case that probably doesn't even need to be tested, although we ended up fixing it in the code anyway as an exercise. Big takeaway was that projects aren't always perfect, and that's ok. There's always room for improvement, and finding these imperfections can be encouraging in a way.
Overall when I think back to the first time I read through the code for Accounting JS vs. now, I see a huge difference in my understanding. From the start, it was easy to use the library, but the source code seemed intimidating and cryptic to me at times, usually because I'd come across a new technique that I didn't understand, and it would weaken my grasp on the full method it was contained in.
Having gone through the source code line by line and in detail over the last few weeks, I have much more confidence. I see how the different pieces connect together. I'm a very visual person, so now when I read the code I see lines and ropes running from variables to functions to arguments, and I can see how one piece of data passes through the program and gets transformed along the way.
I also see that some of the cryptic nature of the code is actually due to the creators of Accounting JS preferring brevity over clarity. There were many examples of code that could have been written in more lines but with much higher readability.