So, you’re learning to code… When you sit down at the computer, do you open an online course? A book? An IDE and start hacking away?
After all, what is the most effective and efficient way to learn to code?
We live in exciting times and the ability to code can open a lot of doors. Never before have this many top notch resources been so readily accessible to anyone willing to roll up their sleeves and dig in.
So, what is the best way to learn to code?
Learning to Code Strategies
The way I see it, there are two main strategies for learning to code.
The first, passive learning, involves the consumption of resources. By this I mean reading books, websites, and other blogs, or watching tutorials on Udemy, Coursera and YouTube.
The second, active learning, involves lots of practice. This can include building side projects, working through the freeCodeCamp curriculum or writing solutions to algorithm challenges at sites like CodeWars or HackerRank.
But which is better, active or passive?
The answer, in my opinion, lies somewhere at the intersection of the two.
I know, way to take a stance, right? Let me explain…
When to Make the Leap
I’ve given this question a lot of thought lately with how it relates to my own situation…
I’ve been learning Angular over the last several months while working my way through the Free Code Camp data visualization and back end sections.
I started with Angular by doing some reading, then enrolled in this Udemy course. Max is an excellent teacher by the way, and I highly recommend his courses.
The problem is that there are almost 400 lectures and over 26 hours of content! Considering that I coded alongside the examples and took copious notes (not to mention my full time job and two kids!), this course would take me forever to get through.
After spending a few weeks working my way through most of the course and it’s examples, I started wondering — “do I know enough to try to build something??” It turns out, no, I really didn’t…
It wasn’t that I didn’t know Angular in enough depth. You don’t necessarily need to know something in great depth to get started, that’s where the iteration between active and passive comes in.
The problem was that I didn’t have the breadth of knowledge to start on my own. I had a hard time moving from the active phase to the passive phase because I didn’t know what I was looking for.
This led me to come up with the following guideline to use in the future
“Try to learn what you don’t know before you starting on your own…”
I know, sounds pretty asinine right? Let me try to explain with an example…
How can you possibly “learn what you don’t know”?
Let’s return to the Udemy course example.
I had worked my way through the components, data binding, directives, services and forms modules of Max’s course. Of course, I didn’t know everything about implementing them off the top of my head, but at least I had a general idea about how they each worked.
In other words, I knew that these parts of Angular existed and generally what they were responsible for. That way, when I encountered a problem, I knew where to start digging for a solution.
For these topics, I knew what I didn’t know.
I had not, on the other hand, looked at the HTTP section of the course. So when I had to make an API call in my Angular app, I didn’t know there was a mechanism in Angular to handle this.
So I turned to something I already knew… I tried setting up a jQuery.ajax() call, not knowing that Angular had their own HTTP service.
Had I at least glanced through the HTTP module, I would have learned enough to know it existed, and therefore would have turned to the proper solution make my API call.
The Take-Home Lesson
My point here isn’t that I’m an idiot for trying to set up $.ajax() in an Angular app. Although if the shoe fits, right??
My point is that I would have been better off if I had gotten a broader understanding of Angular before I had begun. I didn’t need to know exactly how the Http service worked, just that there was one, and therefore, would have known where to turn to make that API call.
To sum it all up, the passive phase is great for exposing yourself to the breadth of a topic (concepts, ideas, etc), whereas the active phase will really hammer home the knowledge and give you a deep understanding of what you are learning.
The trick is finding the sweet spot where these two intersect.
Thanks for reading, I hope you were able to take away something of value for your time. Please feel free to comment below either way.
What is Scope?
Variables are extremely important to computer programming. They allow us to write complex and dynamic programs.
But how and where should we create variables? How and where do we store them? And, maybe most importantly, how and from what part of the program are we able to access a particular variable?
Given that scope is a fairly broad topic, with many different aspects to cover, I think it best to break this into multiple blog posts. The goal here will be to introduce the topic of scope and provide a foundation that we can build upon in later discussions.
Right now you may be asking yourself why this is relevant to a discussion on Scope… That’s a great question, let me try to explain.
Simpson describes that, at a very high level, the 3 basic steps in compilation are 1) tokenizing/lexing, 2) parsing and 3) code-generation.
The tokenizing or lexing step breaks up strings of characters in your code into chunks (tokens) that are easier to understand. Next, the parsing step takes all these tokens and forms a tree of nested elements called an Abstract Syntax Tree. This tree represents the grammatical structure of the program. It is from this AST that code is generated in step 3.
Still not clear on how this relates to scope, right?
This means that the scoping for a program is determined at the time of lexing, based on where the variables fall within the blocks of scope. Therefore the author is able to control the scope at the time he is writing the program without worrying that the scopes will change at run time.
This is a key concept in understanding the behavior of scope. For more detail, please read the first 2 chapters in “Scope and Closures”.
As with most rules, there are exceptions…. Simpson discusses several ways to change lexical scoping at run time. This can be accomplished using eval() and with(), both of which he frowns upon using. I don’t plan on going over these here, but you can be read about them in Ch. 2 .
What does this mean?
You can think of scope as a series of boxes contained within each other. These boxes contain the functions and variables that are declared within that function. This structure enables control over how one block of scope is allowed to access another.
And so on, and so on, as functions continue to be nested within other functions…
Mentally, you can picture scope as something like this:
Let’s use the model depicted above… Let’s say the function for scope #5 referenced a variable called ‘foobar’. If ‘foobar’ was not found in scope #5, the JS engine would then search scope #3. If not found in #3, it would search #2, then #1. Scopes #6 and #4 would not be searched.
What happens if the JS engine reaches the global scope and is unsuccessful in finding ‘foobar’? The answer to that depends on what you are trying to do with the variable.
LHS vs RHS References
Simpson describes two scenarios for referencing a variable. He calls them LHS (Left hand side) or RHS (Right hand side) references and they are handled differently in the case of an unsuccessful lookup.
While LHS and RHS refer to which side of the assignment operator (=) the variable is found, this shouldn’t be taken literally, as there are multiple ways to assign a value to a variable.
Rather, think of the difference as such… LHS is a lookup where we are trying to assign a new value to the variable, whereas RHS is merely looking up the value of the variable to use within your function.
Let’s look at an example:
First, let’s go through this code, find the variables and decide in which scope they reside. There are 2 distinct blocks of scope here. The global scope and the scope inside the addOne function.
There’s only 1 variable in the global scope and it’s the function addOne. The scope nested inside the addOne function contains 2 variables, sum and a.
Now, where and how are these variables referenced?
There are 2 references to each variable in the addOne function.
Line 1 contains an LHS lookup for a. It’s LHS because we are assigning the value of 9 to the variable a when the function is called. Then there is an RHS lookup of a in line 2, as we are only looking up the value of a to use in a+1 (the value of a will not change as a result of this reference).
There’s also one of each type of reference to sum. The LHS reference to sum is on line 2, where we are assigning the value derived from a+1 to sum. The RHS reference to sum occurs on line 3, where we lookup and log its value.
The last lookup is on line 6 where we perform an RHS lookup to addOne by invoking the function.
Note: Originally, I mistakenly assumed there was also an LHS reference to addOne on line 1 when we declared the function. Simpson states in ch. 1, however, that due to the way the compiler handles function declarations, it would be wrong to think of them as LHS references. Please see YDKJS for further clarification.
RHS… LHS… Why does it matter?
You may be saying to yourself RHS… LHS… ABC… XYZ… Who gives a $*&# as long as I have access to my variable… The distinction comes when the engine is unsuccessful in finding the variable for which it’s looking. Knowing the difference now might save you a loooong time in debugging later.
So, what is the difference between an unsuccessful RHS vs LHS lookup? The difference lies in how the engine handles them.
When the engine is unsuccessful in an RHS lookup it throws a ReferenceError. If the engine does find the variable, but the program is trying to do something with the variable that doesn’t make sense (i.e. invoke as a function a non-function variable), the engine will throw a TypeError.
LHS lookups, on the other hand, are a different story. If the engine is unsuccessful in an LHS lookup, it simply creates the new variable in the global scope and hands it back to the engine. As you can imagine, this can lead to all kinds of headaches.
You can prevent this by running in strict mode with "use strict";. An unsuccessful LHS lookup in strict mode will result in a ReferenceError, similar to that of an unsuccessful RHS lookup.
Let’s look at some examples…
Let’s say we make a typo on line 3 when we are logging sum and mistakenly write sums.
//ReferenceError: sums is not defined
Getting a ReferenceError: sums is not defined tells us that we tried to reference a variable named sums that we failed to declare in a relevant scope.
Another example… Let’s say we try to invoke something that isn’t a function.
//TypeError: b is not a function
Again, the error we get tells us exactly what we should be looking to fix.
Now for an LHS example. Consider the following:
You can see here that 10 is logged to the console. Even though we didn’t declare sum as a variable, the engine went ahead and created it for us and the function completed without an error.
What about strict mode?
//ReferenceError: sum is not defined
We can see here that strict mode prohibited the creation of an undeclared LHS reference.
As you can see, knowing the rules of scope and how errors are thrown can significantly cut down your troubleshooting time.
I am the scope master!!
Ok, that was a lot to take in, but seemed pretty straightforward. Is there more to learn on scope or am I now a scope master?
Settle down Yoda… There are some more advanced topics on scope that I plan to cover in a future post, such as function expressions, IIFEs, hoisting, block scope and the use of let and const.
There are also scope closures to discuss… I’m not exactly looking forward to writing that one, as closures can be pretty damn confusing. But, hey, that’s what these rubber ducking exercises are all about, right?
I hope you found this helpful, feel free to leave your comments below.
That’s it for now, I hope this helped straighten out the code…
“Uhhh, no, you just don’t get it…”
Now that sounds like someone I want to learn from! Taking this approach establishes a level of accountability and responsibility to one’s craft.
So when other authors are saying ‘JS is a shitty language, here’s how to get around it’s shittiness’, Kyle Simpson is saying ‘JS is a deep and powerful language, here’s how to embrace it and have it work for you.’
I’ve read three of the six YDKJS books completely and skimmed through the other three. There are some really difficult concepts covered that take a couple times reading through to fully grasp. Concepts like closures, modules, ‘this’, prototypes and async to name a few..
What’s the point of this post??
I plan on writing a series of blog posts that work through these concepts and explain them at a basic level. Do I think I can explain these better than the author? Absolutely not, so I encourage you to read the books (in addition to my blog, of course).
I am, however, doing this for two reasons.
First, obviously I’m far closer to a beginner than Kyle Simpson, which, believe it or not, can have it’s advantages when trying to explain complex concepts. It’s possible that I can word these concepts in a way that might be more relatable to someone just starting out. (I’m not saying it’s going to happen, just that it’s possible)
If you haven’t heard the term, rubber ducking is a technique by which you try to understand something by explaining it to a rubber duck.
The theory is, in order to teach it to someone who has no previous understanding (i.e. the duck), you must completely understand the concept yourself! (if you haven’t noticed, I do a lot of rubber ducking here at Crooked Code)
So rather than just read through these books for a second time, I’m going to work through them and try to teach these concepts so they might be understood by a beginner.
More rubber ducking posts to come, I hope you enjoy and get something out of them. That’s it for now…
Further, I wondered if it would be better if I were taking advantage of the methods built into the array prototype. Methods such as forEach(), reduce(), map() and filter().
Let’s take a look…
For reference, MDN is a great resource to learn more about arrays and the array prototype. They cover forEach() in far greater detail than I will here, so I encourage you to go read it.
How do you use forEach()?
Simply put, forEach() takes a callback function as an argument and executes that function on each element of the calling array.
The callback function takes 3 arguments – the element value, the element index and the array being traversed. Instances where the index and array are not needed in the callback function, you’ll see it invoked with only the element value.
A simple example of forEach():
Simple example of using forEach()
When should I use forEach vs. a for loop?
Researching the differences between a for loop and forEach() to write this post has been somewhat enlightening (there are some very opinionated people out there).
First, if you need to stop or break out of the loop before every element is visited, forEach() is not the right function. In such cases, use a for loop, or look into using every() or some().
Other than that, it seems to come down to performance vs. readability.
Improved Readability with forEach()
Let’s revisit the example above and compare the same functionality using a for loop.
//log array using forEach()
//log array using for loop
I’ll let you be the judge as to which one is more readable…
Personally, I think the more you use forEach(), the more you’ll prefer it to a for loop for readability. Clearly, not using additional variables or worrying about ‘off by one errors’ is an added benefit too.
It’s also worth mentioning that ES6 syntax, with the arrow function, improves the readability even further. I’m still writing my functions the archaic way, which is what I did above, but the same function written in ES6 would look something like this:
//log array using forEach()
I used jsperf to run performance tests to compare for loops, while loops and forEach().The tests were run in the Chrome browser.
The for and while loops were the clear winners (6,233 and 6,261 Ops/sec respectively). forEach() was 18% slower at 5,202 Ops/sec.
So, on a sheer performance basis, the loops were faster than the function call to forEach(). I was a little surprised, however, that forEach() was only 18% slower than the loops.
I think you could argue either way of which one, the for loop or forEach(), is better. Ultimately, I think it depends on the use case…
If you’re developing something that is very data intensive, and the extra performance of the for loop will make a difference, go with the for loop.
Otherwise, if you find forEach() to be more readable and aren’t iterating over huge data sets, use forEach()…
Either way, get out there and build something cool… That’s it for now, see you next time.
Finally, I need to mention that the forEach() method takes an optional second argument that provides the value to use as this when executing the callback.
I recently posted about an overly elaborate solution that I wrote to a CodeWars algorithm. That post has been lurking in the back of my head since I wrote it…
I’ve come to realize that I can’t be too hard on myself for coming up with the solution that I did. After all, the only tool I had available to me was a hammer, so I treated every problem like a nail.
My point is that up until then, any time I had to traverse an array, I had used a for loop rather than any of the methods native to the array prototype. Setting the conditions of the loop to something like (var i = 0; i < arr.length; i++) allows you to easily access and manipulate any element of the array using arr[i]. So that’s what I did…
While there’s (usually) nothing inherently wrong with that (in fact, it’s how I solved many of the algorithm challenges at Free Code Camp), loops aren’t always the most elegant solution to a problem, especially when you start to consider asynchronous options in your code. Besides, the point of this journey is to become the strongest developer I can, so let’s explore other options.
While going through the front end program at Free Code Camp, I was exposed to many of the methods in the array prototype, including forEach(), reduce(), map() and filter(). The problem was that those methods required callback functions, of which my understanding was tenuous, so I found it much easier at the time to use loops.
Working with Node.js these past few months has given me much more exposure using callback functions, so I’d like to revisit these methods and solidify my understanding of them. That way, when I encounter problems in the future, I’ll have more than one tool at my disposal.
Over the next couple weeks, I will write a post that will cover each of the four array methods mentioned above in detail. Hopefully, these posts will serve as good resources for others in my position and, at the same time, give me extra practice using each.
I’ll be sure to come back and provide links to the follow up posts once they’re written.
Since starting FCC in March I’ve made pretty steady progress through the curriculum. Of course I’d like to be moving faster, but considering all the other commitments in my life, I’m happy with my pace thus far…
That is until the past few weeks…
I was moving right along through the back end program. Learning Node and Express was going well and I got through the API projects relatively quickly…
Then I moved on to the voting app, the first of the Dynamic Web Application Projects.
The past few weeks, though, it’s hit me something fierce…
While thinking about how to approach the voting app I considered using a framework, maybe React or Angular 2. So I dug a little deeper…
As someone still relatively new to the JS world, comparing React and A2 isn’t exactly easy. How do I compare JSX vs TypeScript if I haven’t seen either?
Babel and Webpack. Huh?
Redux? Flux? WTF??
I’ve spent the past couple weeks paralyzed with indecision and frustration…
When I was thinking about writing this post, I made a quick list of all the JS libraries and frameworks that I could think of. In about 2 or 3 minutes I came up with 39 of them!!
Off the top of my head!!
I have the scrap of paper to prove it! No wonder JS fatigue is a real thing.
I just wanted to put this out there in case anyone else in the Free Code Camp program was going through the same thing. Plus, I’m hoping this will serve as a bitch session to get it off my chest so I can move forward.
I’ve decided to say F-it and move on without a framework for the time being.
I plan on building 1 or 2 of the full stack apps without a framework, then decide between moving forward with either React or Angular 2.
At that point, I’m hoping FCC has updated their data viz section and the decision will be a little easier.
That’s it for now… Get out there and code something cool, I’m certainly going to try.
I’ve been thinking about writing a post like this for a while but have put it off because, frankly, it’s pretty embarrassing…
Today, I saw a post in the Free Code Camp Forums that made it clear, however, that I’m not the only one that goes through this. So hopefully this post will encourage other beginners to keep going, even if their code looks terrible in their own eyes…
The purpose of this post won’t be to walk through the algorithms and explain everything that’s going on, but rather to emphasize how different two answers to the same problem can be.
Codewars, as I’ve mentioned in previous posts, is a great way to practice solving algorithm challenges. It can be pretty humbling at times, though, because after you solve the problem, you have the opportunity to look at other people’s solutions.
So, when you solve what you thought was a difficult challenge, only to see that others have solved it in one or two lines of code, it makes you wonder if you’re writing in the same language. When you realize you are, you wonder further if this coding thing is really for you…
The upside to this, and, in my opinion, the real strength of Codewars, is that you can learn from these solutions… I’ve only done a handful of algorithms on this site so far, but I’m going to show my first and last solutions as examples of how things can improve.
My First Codewars Solution
The first algorithm I solved at Codewars was called ‘Decode the Morse code’. Try not to laugh….
The site’s description of the algorithm is as follows:
In this kata you have to write a simple Morse code decoder. While the Morse code is now mostly superceded by voice and digital data communication channels, it still has its use in some applications around the world.
The Morse code encodes every character as a sequence of "dots" and "dashes". For example, the letter A is coded as ·−, letter Q is coded as −−·−, and digit 1 is coded as ·−−−. The Morse code is case-insensitive, traditionally capital letters are used. When the message is written in Morse code, a single space is used to separate the character codes and 3 spaces are used to separate words. For example, the message HEY JUDE in Morse code is ···· · −·−− ·−−− ··− −·· ·.
NOTE: Extra spaces before or after the code have no meaning and should be ignored.
In addition to letters, digits and some punctuation, there are some special service codes, the most notorious of those is the international distress signal SOS (that was first issued by Titanic), that is coded as ···−−−···. These special codes are treated as single special characters, and usually are transmitted as separate words.
Your task is to implement a function decodeMorse(morseCode), that would take the morse code as input and return a decoded human-readable string.
decodeMorse('.... . -.-- .--- ..- -.. .')
//should return "HEY JUDE"
The Morse code table is preloaded for you as MORSE_CODE dictionary, feel free to use it. In Java, the table can be accessed like this: MorseCode.get('.--'). In C#, the preloaded Dictionary can be accessed like this: MorseCode.Get('.--');.
All the test strings would contain valid Morse code, so you may skip checking for errors and exceptions.
In C#, tests will fail if the solution code throws an exception. Please keep that in mind. (This is mostly because else the engine would simply ignore the tests, resulting in a "valid" solution.)
So, in thinking about the solution to this algorithm, I immediately pictured various ‘for’ loops to split the Morse code into words, then letters. Then I could replace the Morse letters for real letters and reassemble the message using more ‘for’ loops.
Here is what I came up with…
//accept morse code string as argument
//trim leading and trailing whitespace
//create 2d array by word then letter
//loop through array exchanging morse code for letters
//compress array into words and return
I was feeling pretty good about myself (it worked after all!) until I saw some of the top rated solutions…
Ok, so was this last attempt better?? Sure… Still room for improvement? You betcha…
Looking through past examples definitely helped me put together a more concise solution for this problem, but I still have a lot to learn…
For instance, looking at the answers to this algorithm reminded me that the array.filter() method doesn’t change the array on which it is called. So, once I filtered the non-zero values into a new array, I still had the original array to work with. I could have used it again to add the zeros to the end of the new array.
Hopefully, next time I come across a problem like this I’ll remember the more elegant solution.
In my experience, learning a new skill, especially one as difficult as programming, is all about repetition and practice. So I encourage you (and myself too) to use sites like Codewars to practice these skills over and over.
I also encourage you to take the time to look through other people’s solutions and learn from them. It’ll probably help with your approach to your next one.
It ain’t necessarily about having the shortest solution…
The second point I want to make is that the shortest solution isn’t necessarily the best solution.
We can argue that ‘for’ loops are actually faster than native functions like array.filter() and array.map(), and they are, but that argument is mostly semantic. Unless you are writing an application that demands extremely high performance, it is unlikely that the user will see a difference between the two.
I believe, therefore, that prioritization should be placed on the readability of the code you write.
Going through the process of teaching myself how to code, I’ve read many examples of code written by others, and can say for certain that all code is not created equal.
Some code is nicely written and readable… Other code is like a plate of spaghetti and impossible to decipher.
Let’s go back to the answers to the first algorithm. My code, while drawn out and overly complicated, is fairly easy to follow. The last two solutions listed, while being the shortest, are not that easy to read (at least to a newbie like me).
I’d argue that there’s gotta be a happy medium, maybe something like the one written by czyzykowski. Their solution is logical, modular and very easy to follow.
Feel free to comment below if you disagree, like I said, I’m still new to this, so maybe those last 2 examples are perfectly readable to someone who’s been at this a while.
I think the takeaway from all this should be – don’t worry if your code looks like a fanewgi wrote it, just keep plugging away…
Read code others have written and keep writing more of your own. Before you know it, you’ll look back at code you wrote a while ago and realize just how far you’ve come!!
That’s it for now, I hope this helped straighten out the code…