100 Days of Code Progress: Day 5

It’s been a while since I’ve posted here, but I’ve been actively working on code every day all the same. I’ve been pouring most of my thoughts into my 100 Days of Code log in lieu of  posting here (but I’m now seeing that I’ve got a handful of readers, so I wanted to check in and let you know what I’ve been up to).

When I first heard of 100 Days of Code, I thought it was a series of code problems you had to solve 100 days in a row. It’s actually much simpler: you code whatever you want, but you do it for at least an hour each day for 100 days straight. I am in the process of securing a full-time day gig, so I’ll no longer have as much free time as I have had up until now to work on my coding skills, and this sounded like a great way to keep my momentum going.

I forked the official repo on Github and got started about five days ago. Lately, I’ve been going through the coding challenges on CodeWars.com using JavaScript to solve them. Each problem is called a “kata,” and I was making pretty steady progress until the kata I started on around the time I started the 100 Days challenge. (As a side note, you can click here to join my team on that site!)

I worked out all the syntax errors and got the program to run, but the output was totally wrong. I struggled to modify the logic to get it working, but kept hitting a brick wall. So I just decided to erase the meat of the function, work through it in plain English via pseudo code, and start again. And it worked! It’s such a great feeling to finally break through after being stuck on a persistent problem. Part of me wishes I picked everything up without getting stuck in the first place, but another part realizes that perhaps getting stuck is a valuable educational experience in its own right.

I am gearing up to create my very first game in Python using the popular Pygame library. The idea of creating video games is what piqued my interest in computer science/programming in the first place, and even though I know what I crank out will inevitably be rudimentary, I’m still excited to get my first little demo up and running. I’ll be sure to keep you posted as it develops. It won’t be anything innovative or revolutionary, but it’ll be mine, and I’ll be proud of it all the same.

I don’t know if I’ve mentioned this previously, but about a month ago I installed Ubuntu on my laptop alongside Windows 10, and I haven’t logged back into Windows since. The overall environment is so much more amenable to programming. I love it. I have to Google how to use certain features a lot more regularly than I did with Windows, but I’m excited to be learning new skills. I actually wrote my latest log for 100 Days using a very stripped-down editor called Vim; it’s anything but intuitive, but from what I’ve read, it’s very powerful. I’m looking forward to getting further acquainted with it, though I’ll probably still be heavily using Atom for the foreseeable future.

As for now, I should probably try to get some sleep. I’ve got to return to my week-long temporary day job tomorrow. Believe me, I’d much rather be coding, but I’m still not to the point of getting paid to do it.

Not yet, at least.


Photo of a worn house with random colored numbers hand-painted on the side

My first JavaScript program!

Well, that’s not entirely accurate. I’ve written scripts before, but they’ve all been fairly specific in their scope (hiding DOM elements on a particular page for my convenience, for example), and it’s been years. So I’m basically starting over.

In today’s exploration, I came across this list of questions a front-end developer might reasonably be expected to answer in an interview, so I decided to start working through them. The first problem is to develop a function which checks whether an inputted number is prime. All things considered, it’s a pretty basic problem, but it’s been a long time since I even thought about prime numbers, so it took some minor mental gymnastics to get to the solution. Here’s my code:

function isPrime(number) {
	var remainder;
	if (number <= 1) {
		console.log("Number must be greater than 1!");
		return false;
	for (var i = 2; i < number; i++) {
		remainder = number%i;
		//console.log("Dividing " + number + " by " + i)
		if (!remainder) {
			//console.log(i + " is a factor! " + number + " is not prime. Exiting!");
			return false;
		/*else {
			console.log("The remainder of " + number + " divided by " + i + " is " + remainder);
	//console.log("Looks like " + number + " is prime! Congrats!");
	return true;

console.log(isPrime(0)); //should return false
console.log(isPrime(1)); //should return false
console.log(isPrime(17)); //should return true
console.log(isPrime(10000000000000)); //should return false

As you can see, it’s primitive and anything but optimal. I doubt a prospective employer would be impressed by my ingenuity, but it’s a starting point nonetheless.

Before beginning, I had to understand pretty well what a prime number was. I now understand that it is any number, greater than 1 (a stipulation I initially overlooked), which is not divisible by any number other 1 or itself. Before jumping into coding, I wrote out some pseudocode in an attempt to guide my thinking. It went something like this:

  • Accept number as input parameter
  • Loop iterator from 1 through (number-1)
    • If remainder of number divided by iterator is 0, return false
  • Else, return true

To put this into action, I declare function isPrime with a single parameter, number. I then declare a variable, remainder, which I’ll use shortly. The next line checks whether number is less than or equal to 1, logging a warning to the console and returning false if this condition is true. If the number passes this test, I then proceed into a for loop. It is here that I realized I’d made an error in my pseudocode; rather than starting with 1, I needed to start with 2! So I set a for loop to run with iterator, i, from i=2 until i<number, incrementing by 1 at the end of each pass.

At the beginning of each pass, I divide number (the input) by i using the modulo operator, storing the modulus as the remainder (though I learned while typing up this blog post, that modulus and remainder are not the same thing…for the purposes of this example, I’ll go ahead and use them interchangeably). If remainder is zero, that means that we’ve found ourselves a factor which divides evenly into number, so number is not prime – thus the function returns false. If remainder is not zero, the loop continues, checking the remainder with each pass until the condition is met. If, during the execution of the loop, false is not returned, then the number must be prime, thus true is returned.

I called the function against four test cases mentioned in the website – 0, 1, 17, and 10000000000000 – expecting the function to return false, false, true, and false, respectively. And my program passed the test each time! It’s a minor victory, but I’m proud to have solved the problem without cheating or asking for external help (save for some cursory research into the concept of prime numbers to make sure I had a clear understanding).

If I were to improve this program, I would probably remove the console.log statements I put in initially to debug. I would also like to figure out how to write the results to the barebones HTML document I included the script in to run it. As it stands right now, the results are posted only to the JavaScript console in my browser, but not to the page itself. I intend to figure out how to make this happen soon. As for now, it’s onto the next problem.