Recurse Center Application

After working on it for close to two weeks, I just submitted my application to the Recurse Center. We hired a few people from RC at Codecademy, so it has been on my radar for some time. However, Esther recently pointed me there again, and after reviewing the website, I was absolutely hooked. It looks like the ideal experience at this specific point in my life – when I have the time and a strong desire to learn as much as I can about programming. I’ve also had some great experiences in self-driven environments like this, both at Explorchestra and back in Interlochen.

Either way, though, I’m going to focus on learning and improving as a programmer – I’m having a blast working on this stuff full-time.

In other news, I’ve finished and deployed my new two projects alongside the application. I’m happy to present my redesigned website, maximpekarsky.com, as well as a small battle simulator I built as a part of QRL, a game I’m working on.

Advertisements

Cloning an array of objects in JS

I just spent a few frustrating hours trying to debug some code I had written to simulate a battle between groups of units. My script works as following:

  1. Create an array of unit objects based on user inputs, where each unit has a player id, HP, strength, speed, and other typical game parameters. This is our template array for the simulation
  2. By iterating trough this template array of units, create three more arrays:
    • an array with all units added based on their speed count (so that faster units are more frequent and likely to be selected)
    • a filtered array for just Player 1 units
    • a filtered array for just Player 2 units
  3. Run a number of battle simulations with arrays from Step 2. After each simulation, where units attack and change each other’s stats (namely HP), clear my three arrays, and create new ones with fresh unit stats from the template Array defined in Step 1.

The issue I ran into was that my units seemed to carry over their stats from previous simulation runs, even though I wiped the 3 arrays used in my simulation clean, and referenced my master array to clone units. If the error here seems abundantly clear, then you’ve already learned the lesson I just did. I cloned my units as following:

var masterArray = [
  {
    name: "joe",
    hp: 10
  },
  {
    name: "lena",
    hp: 12
  }
]

var tempArray = [];

for (var i = 0; i masterArray.length; i++) {
    tempArray.push(masterArray[i]);                  // !!!
}

The issue, I found, is that I wasn’t copying the object – only an object reference. Therefore, when I made changes to my tempArray[0].hp, for example, it would also affect masterArray[0]. Both objects referred to the same location in memory, so I wasn’t cloning the actual object – I was referring to the same object in both arrays.

The answer, I learned, is “deep cloning“. Though this feels a little like cheating, the following solution (one of many!) worked:

newObject = JSON.parse(JSON.stringify(oldObject)); 
//similarly: 
tempArray.push(JSON.parse(JSON.stringify(masterArray[i])));

We’re converting the object to text, and then parsing it into a new object – no longer referencing the same memory location as the initial object.

I’ve heard about reference vs. primitive variables, but now I’m getting a taste for them.

Step Away

It’s amazing how many technical problems resolve themselves when I step away from the code after working on it for a while. Challenges that suck me in and that seem needlessly complex suddenly become simple when the brain has time to work on them for a little while.

The Right Problem

You’re working on the wrong problem.

I’ve noticed that it’s easier for me to dig into experimenting with code until I get it right than to force myself to think through the best solution for a hard problem. For my current project, a text-based multiplayer game, I’ve created a Trello board to project-manage myself, and prioritized all the tasks – all the problems to solve and components to build.

I’ve noticed that when I butt up against a hard problem, I procrastinate by solving easier, much less important features. For example, a hard problem for my game is how two groups of units enter and resolve combat. Before can tackle the code, I need to think through and decide on the best solution. This is hard and uncomfortable – but it’s also the crux of the whole project, and the reason people would play this game.

Instead of sitting there and patiently thinking through the best solutions, I think for three minutes, and then turn for a distraction. However, I’m too motivated to slack off on Facebook, so I start building something totally non-essential, like a setInterval countdown system – a small UX improvement – which gives me that kick of satisfaction. In the grand scheme of things, it’s a poor decision.

So, I have to consciously stop myself and say: “Max, you’re working on the wrong thing. You should be working on the crucial feature, not the easy, fun one.”

“Also, now you’re avoiding work altogether by writing a blog post. Come on!”

The “Almost-There” Step

One of my favorite stages in learning to code is when you know what the right answer is, know exactly what to type, but don’t understand why. Your mind is close to making sense of a concept, but hasn’t gotten there yet. I call this the “almost-there” step. It’s unsettling and frustrating.

Inevitably, if you persist, the topic clicks into place, and then you fully understand it.

I’m in exactly such a place now with Node routes. A route accepts a function(request, response) as a parameter. I understand that the request is whatever the user is asking for, and the response is what we’re returning – and the response parameter seems to be able to return statuses, redirect, etc. But, on the whole, I still don’t fully get what’s happening here.

Hello world!

It’s 2017, and I’m  charging ahead with my programming journey. I’m not a total beginner – I built a website with a few projects (all Rails on the back-end) and I lead a team of programming teachers over at Codecademy. However, I’m definitely not an engineer, and I have so much to learn before I feel like I can prototype, build, and manage products effectively.

After working with Rails on the back end and the basic HTML/CSS/Bootstrap/JS/jQuery front end, I want to really dive into the exciting world of JavaScript. I just started learning Node.js and Express, and from there, aim to either settle into Express, or continue onto Meteor, as well as React.  I’m also working with my great friend James Mayr, whose back-end background is in PHP. So, a JS back-end should be unifying for both of us, especially if we want to continue to work together (and we do.)

Rails was a wonderful experience, and on my own, I’d probably continue to dive deeper into it. Learning Rails was tough, and it didn’t help that everyone said it should be easy. Ruby wasn’t difficult to wrap my head around – however, understanding Git, ERB, how HTML requests work, what application architecture is, MVC, REST structure, basics of SQL for my database – all of that was overwhelming. Over time, I’ve understood many of these concepts, er, kind of. I hope these skills help me in my JS journey.  The danger of Rails has always been how much you can build without really understanding what’s going on underneath. I’m hoping to correct this the second time around, and really understand what’s happening  in my Node/Express apps.

My goal is to become a PM, and envisioning, planning, and building products is what drives me at the core. However, I find programming fascinating, calming, and endlessly enjoyable. So, I’m really excited to kick up my skillset to the next level.