Day 13: Sydney JavaScript Study Group – REJECTED

Unfortunately, we have had to be very strict on the numbers…

I’ve just received official word from the Sydney JavaScript Study Group organiser that due to the number of people who RSVP-ed for this study group, I won’t be permitted to attend.


I guess I’ll just have to show them up by blitzing through their The Odin Project JavaScript Curriculum.

Today’s activities to date:

  • Attended additional job interviews. More scheduled throughout the week.
  • In between waiting for interviews, I’ve gone to local cafes/Starbucks and continued reviewing concepts I thought I had a grasp on, but which it turns out I didn’t really. For example, I was looking into understanding .call(), .bind(), .apply() methods, which led me to attempting to understand ‘this’ which led me to attempting to understand closures, which led me to attempting to understand variable scope and hoisting. I can say the JavaScriptisSexy articles have been outstanding to date, although the sticky parts in code have sometimes had me scurrying about the internet to try and understand it at a more basic level.

Day 13: MDN Sometimes Kind of Sucks (For Beginners)

Right after the wonderful explanation on, I went straight to MDN’s article on the .bind() function method to crystallise the concepts. And boy, did it not do that. Their first example, from a beginner’s perspective, is a mess.

this.x = 9; 
var module = {
  x: 81,
  getX: function() { return this.x; }

module.getX(); // 81

var retrieveX = module.getX;
retrieveX(); // 9, because in this case, "this" refers to the global object

// Create a new function with 'this' bound to module
//New programmers (like myself) might confuse the global var getX with module's property getX
var boundGetX = retrieveX.bind(module);
boundGetX(); // 81

My main issue is the fact that they add a number of sticky points in their example that only adds to the confusion, and that you have to mentally untangle before understanding what should be a simple example.

  • module.getX(); is a method/function call with zero arguments being passed, although you could pass arguments into the method call like so, module.getX(9, 2, 4) and it wouldn’t matter. But it’s definitely a call on the function. Which is definitely not the same as module.getX which returns only the value of the property getX. And the value of the property getX is an uninvoked function i.e. function(){…}. And that’s why your this value inside the function changes to the global this referred in the top line, when you call retrieveX();. Of course, leaving out the above explanation makes it very difficult for a beginner to follow, so that really kind of sucked.

Day 13: Review of ‘this’ at

My review of .bind(), .call() and .this() led to JavaScript is Sexy, which recommended as prior reading, it’s article on understanding the use of the this keyword in functions. I took up their recommendation.

  • Just finished the first ‘Sticky’ point or most confusing/tricky instances where this won’t operate as might be expected. And I actually understood it completely, which is a testament to the article because other tutorials/resources really weren’t as helpful.
  • My main takeaway right now is that this inside a function called as a method to an object will refer to the object. The problem in passing that object.method as an argument in another function or object.method is that this will refer to the new object that is ultimately invoking the function holding this. But you fix this by binding the old/previous object to this using the .bind() method on the object.method that currently holds this. So instead of newObject.method(oldObject.method), you write newObject.method(oldObject.method.bind(oldObject)).

Day 13: The Odin Project & JavaScript Curriculum for beginner JavaScript-ers?

I managed to find a local JavaScript Study Group based right here in Sydney!

Naturally, they won’t be following the Hack Reactor curriculum, and their initial project commences with use of vanilla JS and jQuery. They’ll actually be mirroring the JS curriculum developed by The Odin Project, which I will be following for the next 2 days at least to familiarise myself and possibly get ahead before the first meet in 2 days.

Elegant JavaScript vs Me

I managed to take down the first Warmup question, however naturally StackOverflow returned with more elegant solutions, one involving use of the Math.max function and the apply() method. Even more naturally, I’m reviewing call(), apply() and bind() methods because those options didn’t occur to me intuitively, which is a sign that I didn’t understand the purpose of the method at heart.

Will update as I proceed.

Day 10: No Progress (Except On The Job-Hunting Front)

Looking, Looking … Found? 

As per the title, very little to no progress was made today. Largely due to the fact that I was attending job interviews for a government position. Tomorrow, I need to call back a few other recruiters so I can finally secure a position that will let me pay my mortgage in peace, and keep me well fed for my JavaScript nightly pursuits.

Currently still reviewing Re-Introduction to JavaScript, at least until my pizza arrives.

Funnily enough, anime and ordinary TV shows (besides Netflix’s Narcos) don’t seem to interest me as much as watching videos about web development – whether it’s an AirBnB ‘Evolution of our Front End’ presentation, or a freelance WordPress developer speaking about how they are living in paradise in Bangkok, Thailand doing what they love.

Technology is amazing, isn’t it? 🙂

Day 9: Update on Type Coercion, ‘==’ Operators and ToPrimitive

So, between dinner and temporary job applications to finance my JavaScript ninja training, I am still stuck on the same article: ‘Truth, Equality and JavaScript’ by Angus Croll.

Where I Get Stuck: ToPrimitive

It’s not that it’s a bad article, but just that I’m a slow learner. I did pick up and better intuit the flow of type coercions that occur when using an ‘==’ operator. But I’m currently stuck on ToPrimitive, and particularly the valueOf and toString object methods, and how they operate in converting objects to primitives. Even the MDN resources were not particularly helpful, in my opinion. I’m currently traversing other online blog/content on these two methods to really come to grips with them, they’re my only sticking point in the otherwise relatively easy to follow flow of type coercions.

My Type Coercion Brain Gains

  • if (expression) conditionals will evaluate the ‘expression‘ using ToBoolean. Angus Croll describes the type coercion flow here, which is essentially the standard truthy/falsy paradigm we’ve all likely been introduced to: null, undefined, 0, NaN and “” (empty string) resolve to false, everything else resolves to true.
  • ‘==’ comparisons follow a higher order type coercion flow. The way I’ve memorised it is:
  • Booleans get converted ToNumbers() (True is 1, False is 0)
  • Then Objects get converted ToPrimitives (and this either by valueOf or toString object methods)
  • Then Strings get converted ToNumbers() (e.g ‘12345’ becomes 12345, but ‘abcde’ becomes NaN because it can’t be converted to a numeric value).
  • Once everything’s been reduced as far as possible, or is the same type, then treat ‘==’ as if it were ‘===’.
  • The only exception in all this, or another rule, is null == undefined, which always resolves to true (as opposed to a strict equality operator ‘===’ which would resolve to false).

*Note to self: Still need to understand how valueOf and toString methods convert Objects to a primitive value (Primitives are the basic JavaScript values, such as Strings, Booleans, Numbers, as well as undefined and null).

Anyway, this JavaScript Gangsta headed to watch Straight Outta Compton see, JS Gangsta-p rolling out!

Day 9: Remedial JavaScript Update

Quick update: Type Coercion Sidetrack 

I’m up to operators (and the minimal type coercion footnote) in the ‘Re-introduction To JavaScript’ resource.


I’ve decided not to follow MDN’s advice in using only strict ‘===’ comparison operators. I want to know how ‘==’ works and when I might be able to use it for advantage in my JS code.

Currently reviewing an article titled ‘Truth, Equality and JavaScript’ from the blog of a Twitter Front End Engineer, Angus Croll. Dated 2011, so I’ll have to review the information further to verify it’s still valid, but the article is working a treat with in-depth explanation of type coercions in the instances you’ll encounter them (If (expression) evaluations as well as the ‘==’ operator).

Wish me luck!

Day 9: Remedial JavaScript

Back To Basics

A quick update: I’m currently taking today to be a day solely dedicated to remedial JavaScript.

Essentially that means revisiting simple concepts, tips, tricks and all the basics which underpin JavaScript.

My resource for this venture is going through the wonderful MDN resource, “A Re-Introduction to JavaScript”.

Additionally, little focus points I’d like to work on include:

  • testing for NaN, null, undefined
  • when to use ‘;’ (I’ve been employing this after every function declaration, which apparently is not the thing to do)
  • coming to grips with what’s an object, what’s a function, and the methods available to each
  • comparison and logical operators (very urgent)
  • method chaining
  • from my read of Object Oriented JavaScript and JavaScript Cookbook (2nd ed), to quickly review and ingrain the concepts surrounding ‘this’, the function methods call(), apply(), bind(), typeof testing, and using strict and loose comparison operators == and ===.

Will update on progress soon!

Day 8: Eloquent JavaScript Chapter 5 Higher-Order Functions

So, first thing’s first – my doctor’s proclaimed me healthy! Apparently the only thing I’ve been suffering from is paranoia stemming from me googling my own symptoms. So phew for that. (Although I am going in for an abdomen ultrasound for peace of mind this Friday).

Chapter 5: Higher-Order Functions

Now, somehow I’ve discovered I’m still on Chapter 5 of Eloquent JavaScript: Higher-Order Functions. For this chapter, I have read a bit more of my other book, ‘Object Oriented JavaScript’, which luckily covered similar ground along with some additional concepts regarding ‘this‘. However, my lack of familiarity with general coding and coder-think started to show today.

Prior to attempting the 1st and 2nd exercise for Chapter 5, I was still reading, writing, and re-reading about the array methods available in JavaScript (think .forEach, .map, .filter, .reduce). My resources included MDN (which I am definitely becoming more comfortable interpreting), Eloquent JavaScript and a Youtube Tutorial by a Spotify Developer. The last was great for reviewing the concepts again, with slightly different examples and for comparing the non-method loop version to the application of the method to an array.

Brain gains made today

  • Gained much more confidence dealing with the common array method functions
  • I understand now how the callback functions declared in methods work. For example, when I first encountered these array methods, because of all the continuous back-and-forth interaction between the functions/methods/objects/callback functions in Eloquent JavaScript’s examples (and examples generally), I would be able to memorise the method’s general form, but not really be able to apply or understand it outside of a simple, straightforward example (such as the 1st exercise). I would confuse myself between the ‘arguments’ passed in the method call, and the arguments in the callback function, and just about everything else. Now, I get it.
  • .map is exactly like .forEach, except .map is not destructive (so it doesn’t mutate/change the original array).
  • .filter accepts a callback function that has one purpose – to perform a test which will return either a true or false value. Remember also, .filter goes through each element of an array, and during each ‘loop’ it is using that test/Boolean value to determine whether to add the current element to the new array that it’s creating.
  • .reduce is kind of like .forEach or .forMap. It accepts a callback function, but also another argument (let’s call it “initialValue”). As for the callback function itself, it accepts four arguments, and the special one is the first one, which I call “previousValue” (thanks MDN). Think of it like an accumulator argument: during each ‘loop’ executed by .reduce’s internal/abstracted logic, .reduce is going through an element of the array and performing an operation on it (just like .forEach and .map do). However, after each loop, .reduce’s internal logic adds whatever values/result returns from the loop (or ‘callback function invocation’ as they say) to ‘previousValue’, and this new version or value of ‘previousValue’ is used in the next version of the loop. The final thing .reduce’s internal logic does does is return the final result of the callback function/loop. And that’s it purpose – to return that final result, whatever it may be (depending on what you coded the callback function to do/pass to previousValue).

Biggest non-coder think problems

  • I was (and am) up to the 2nd exercise in Eloquent JavaScript, but even though my final partial answer was close to the SandBox answer, in the end it wasn’t close enough.
  • I’ve discovered I need to do more exercises involving calling/using objects, object properties, object values and arrays of objects. Sometimes, it can be very difficult to ‘think’ through how to call a particular array-of-object’s property value, especially when you have to use something like the byName object in the exercise (and think through that lens of an object) whilst keeping track of the variable names. It was definitely headache inducing stuff, for a non-coder turned coder, but I have high hopes that exposure and familiarity will extinguish any future migraines.
  • Method chaining: although my partial final answer didn’t let me apply this in the end (because I was breaking everything up into new arrays and separate functions), I did have the end goal of method chaining filter and map, so I think practice with this on my own will help me more comfortable in applying this correctly (for example, right now I believe it operates left to right, but again, something to double check)
  • In the end, my solution was actually extremely close. The biggest let down? I’d figured out after doing an initial solution, that my .filter callback function was catching objects where the person’s mother also had their own object somewhere. What it wasn’t catching was instances where a person (and therefore their whole object) was a mother to another person in the array. So the great grandmothers with no further mothers were being culled… and I needed them so I could use their born/died year data to calculate the age differences between them and their children. I (stupidly) tried to solve this using another function and an or || operator but ultimately got stuck on this point. After substantial hair-pulling, when I checked the solution, I found I’d only been missing 6 freaking characters:
    return byName[person.mother] != null;


*Note to self: learn to intuitively think/apply comparison operators, particularly for IF and .filter type tests (where Boolean values are required). Practice as much as required, because this kind of elegance beats whatever the hell else you just tried to do.

A slightly deflated JavaScript balloon, signing out!