How to Slow Down Time

Posted by & filed under Essays.

A french chronobiologist (he studies time and living things) named Michael Siffre once conducted a hell of a self experiment. He spent two months in a cave alone. No clock, calendar, or sun light. He did have artificial lights, food, and a journal though. His experiment is covered in the excellent book ‘Moonwalking With Einstein’. It makes some pertinent points more eloquently than I could, so I will quote it at length right now.

“Very quickly Siffre’s memory deteriorated… Since there was nobody to talk to, and not much to do, there was nothing novel to impress upon his memory. There were no chronological landmarks by which he could measure the passage of time… When his support team on the surface finally called down to him on September 14th, the day his experiment was scheduled to wrap up, it was only August 20th in his journal. He thought only a month had gone by. His experience of time’s passage had compressed by a factor of two.
Monotony collapses time. Novelty unfolds it. You can exercise daily and eat healthy and live a long life while experiencing a short one. If you spend your life sitting in a cubicle and passing papers, one day is bound to blend unmemorably into the next — and disappear. That’s why it’s important to…have as many new experiences as possible… Creating new memories stretches out psychological time, and lengthens our perceptions of our lives.”

I remember the first time I read that passage. I sat on my couch and soaked in the implications. I had visions for how it might change my daily life. Over the months, however, the ideas from that passage became — as ideas are wont to do — rather intellectual. But recently I had an experience that brought them to life again. I understood them personally and viscerally.

For 13 weeks, I averaged 12 hours each day focused on one goal. Specifically, it was spent learning software, but it could have been anything. Painting, accounting, writing; any deep pool of knowledge would do. What I learned is that the passage of time isn’t constant. In fact, it’s under your control. You just have to pull the right levers.

There’s a lay theory that as you get older, time seems to speed up because each passing year is a smaller and smaller percentage of your life. That the year from 9 to 10 represents 10% of your life, but the one from 33 to 34 is only about 3% of your life. It’s intuitively appealing because it explains the universal feeling in a way that puts no fault on ourselves. It’s just math, nothing I could have done to stop that inevitable speed-up of time. But I don’t buy it anymore.

Your sense of time is actually answered by a simple question: how much are you learning? Each thing you learn is another ‘hook’ you give to your memory, and each hook is another time marker. When you have a lot of markers, time feels slow. When you have few, life starts to feel a lot like driving down the open, straight roads of the midwest. Hundreds of miles will fly by because you don’t have to do anything except keep your foot on the gas. The sad part is you still feel like you’re going somewhere.

While I was at Hack Reactor (an intense programming school), I was learning a metric ton each day. I felt so disconnected from other responsibilities that it felt like a different world. We had a 3-week personal project period where I was given (basically) free reign to build anything I wanted. I built a tool that visualizes, in 3D, a two-handed piano performance of any song, given a MIDI file. It required some complex algorithms, and new technologies I hadn’t used before. I was working on it so much that my brain had no choice but to show it in my dreams each night for 3 weeks. I also learned more in those three weeks than about any other time in my life.

And here’s the paradox: while in these periods of ‘flow’, time moves fast. The hours cruise by, and your 14 hour day of work feels like a pittance. And yet, I look back for even a second, and it feels very slow. I have so many memories and associations for those 3 weeks that it feels more like 3 months. And that was the pattern at Hack Reactor. In fact, after a few weeks, we were so deep and disconnected that fellow Hack Reactants and I would joke that we had no lives before HR; and ‘this is all that has ever been.’

Which is funny, because there’s the old adage about cherishing time, “The days are long, but the years are short”, but, actually, it seems when you do things right, it’s the opposite: “the days are short, but the years are long”.

This theory also explains the child/adult time gap phenomenon. As kids, we all learned a lot each day. New words, new skills, new social rules. As you become an adult and leave school, that slows down. Certainly we learn, but less so than before, so time flows faster.

So how do you slow down time? A cliché would be dangerously easy here. ‘Live life to its fullest’ or some garbage like that. But dig in a bit, and it goes deeper than that. Your perception of life is built exclusively from your memories, which are in turn built from surprising experiences. I purposely didn’t say ‘novel’, because hell, your commute to work each day is technically novel, since I guarantee you don’t see exactly the same people on the way, or hear exactly the same broadcast, etc. But surprising captures the reality better. You must have experiences where you aren’t totally sure what the results of your actions might be. Where maybe, you’re even a bit uncomfortable. Such experiences often happen when learning a new skill, or traveling, but they can happen everyday in the strangest of times if you go after them.

For instance, there’s a bakery just around the corner from my house. I’ve always heard that bakeries tend to just give stuff away at the end of the day, because they’re gonna throw it out anyway. I didn’t know for sure though, partly because I never go to bakeries, but also because I’m shy about asking for things that shouldn’t obviously be mine. But I was walking home late at night the other day, and I saw the bakery owners closing up shop. The lights were on, but the door was locked. I thought, hell, why not try this out? I knocked and pointed at the doughnuts. They were hesitant, but opened up, and asked in broken English, “What you want?” I asked for 2 chocolate doughnuts. They put in 3 and threw in 2 bear claws too for free. It was the most exhilarating doughnut purchase of my life. I finally learned the truth of this ‘free baked goods myth’. It was true, and I didn’t even have to ask. I did have to knock though.

Ya know, fruits and veggies are great, and I eat them every day so that I’ll stick around. But that night, I think the doughnuts lengthened my life more

Empathy for The Machine. Or, How to Improve as a Programmer and a Human.

Posted by & filed under Coding.

Stop getting angry at the computer and start getting angry at yourself. When you’re learning to code, it’s easy to get frustrated at the tiny details that derail your program. It seems like the computer is being dumb. But it’s not. It’s doing exactly what you told it to do, and you just need some empathy. That empathy is key in separating beginner and experienced developers. When beginners throw up their hands, experienced developers try to debug by gaining a deeper understanding of the machine. What was it thinking? Why did that thinking cause this bug?

Sometimes at Hack Reactor, we tell students to walk through code line by line, pretending you are the machine. Here’s a simple example (if you’re new to javascript, console.log basically means ‘print’):

var superHero = {name: 'Batman'}
console.log(superHero[name]);

What happens when this code runs? You get nothing (undefined, actually). But no errors. Why? It looks like we’re just trying to print out the name property of the superHero object. Everything should work, right? No it shouldn’t, and this is a subtle bug because it doesn’t throw errors. But if you understand what the machine is doing, and treat it as an equal, the answer is clear. Let’s run it, looking through the computer’s eyes.

1.) Set aside memory for a variable.
2.) Let the string ‘superHero’ point to the newly constructed variable
3.) Make an object, and give it a property ‘name’, with a value of ‘Batman’
4.) Assign that object to the memory slot that ‘superHero’ refers to
5.) Look for a variable called name
6.) Oh no! No variable name has been defined before, so I’ll call it ‘undefined’
7.) Try to find ‘undefined’ property on the object superHero
8.) Can’t find it, so return undefined
9.) console.log what we found, which is undefined.

Ha! There we go. Step 5 is the secret. Because the word `name` wasn’t written with quotes, JavaScript thought you meant a variable called `name`, and it went looking for that variable. No such variable had been declared, so it kinda cascaded from there in to a bunch of undefined-ness. Had we written console.log(superHero['name']) , then everything would be fine, because it would know you meant to look for a property directly on the object with the string ‘name’. That does exist, and it has a value of ‘Batman’, so we’d get what we wanted.

Without empathy, this would be an easy time to get frustrated that the computer can’t simply ‘get’ what you mean. But with empathy, we see that we were the ones who made the mistake, because we didn’t think about how the words would be interpreted, and so our meaning was lost.

Man, having my meaning lost because I didn’t properly think how my words would be interpreted. That sounds eerily familiar to what I’ve heard from ex-girlfriends. And now we come full circle. Really getting in the mindset of your receiver is make-or-break whether you’re dealing with machines, or people. We can’t assume our meaning will be transferred just because we said the ‘right’ words. Often our meaning is confused by tiny details in how we interpret those words (or semi-colons, or tones of voice). So practice this kind of empathy on machines, and then bring it home to your loved ones, and you’ll see that everyone’s happier.

Coding terms that are much broader than you think.

Posted by & filed under Coding.

The english vocabulary that surrounds coding can be just as intimidating as the code itself. Or worse, the words look and sound like words you think you understand, but in fact have much different meanings in the context of programming. Such painful misunderstandings need to be eliminated as soon as possible for beginners, so let’s get to it.

App: The most basic term of all. We hear this mostly in the context of your smart phone. As in, “there’s an app for that.” But really the term ‘app’ is very broad. Like so broad you could define it as “any software that causes a computer to perform useful tasks.” Yeah, that’s like freaking everything. If you wrote something that did nothing by take text from a user and then show that text on the same web page, you’ve built an app. But hell, if you built a function that adds two numbers together and it’s only on your local computer, you’ve built an app. The level of complexity, or the platform it’s on are totally irrelevant to it’s classification as an app. Why is this important? Because otherwise it’s easy to get intimidated by the entire idea of building an ‘app’. You shouldn’t be. You start with limited functionality. You’ve still built an app. Then go from there.

API: Now that we’re good with app, let’s look at ‘Application Programming Interface’. It usually gets used in sentences like, “Developers can build some amazing apps on top of Twitter’s API.” This gives the impression that an API is just a way for some developer to use the data of another website. While true, an ‘API’ is wayyy more broad than that. Allow me the liberty of changing something slightly. What if it stood for an Application‘s Programming Interface? Yeah, just add the apostrophe + s, and you can see that API really just means ‘the way one interacts with an app’. And remember how broad the term ‘app’ is? Thus, API is extremely broad too. It’s actually impossible for any program you write to not have an API. To illustrate, let’s see how you could change the API of a super simple function that adds two numbers together.

Option 1: addNumbers(number1, number2) → You pass the two numbers as two separate parameters

Option 2: addNumbers({num1: number1, num2: number2}) → You pass one parameter. It’s an object with two keys ‘num1’ and ‘num2’. The values of those two keys represent the numbers we want to add.

Option 3: addNumbers([num1, num2]) → You pass one array paramater that has both numbers in it.

Each one of these options represents a different API to the exact same application of ‘addNumbers’. Each API comes with advantages and disadvantages. For me, seeing API’s as this broad concept was really enlightening and helped me conceptualize what I was doing as a programmer much better. It will also just help you understand documentation better because the term gets thrown around all the time.

Pattern: This one can be confusing only because it’s a word we all know so well in English. And the two are indeed related, but it’s not immediately obvious how until you see it in context a few times. When programmers talk about ‘patterns’, what they really mean is ‘broad conceptual way you achieve a task’. Or, according to Addy Osmani, patterns are templates for how we solve problems.” For example, if your problem is “creating an object”, then here’s two patterns for doing so.

Option 1: var myObject = {};

Options 2: var myObject = new Object();

Each pattern solves the same problem, but in different ways. Each way requires certain things that the other doesn’t. This gives each method it’s own advantages and disadvantages. I won’t get into that here, but suffice to say neither is necessarily ‘right’ or ‘wrong’. They’re just different patterns.

Stay tuned for future posts on more specific terms that are also easily misunderstood.

Hack Reaction Week 12: It’s done! Would I Tell My Friend To Do Hack Reactor?

Posted by & filed under Hack Reactor Journal.

Yes. I would tell any friend with a deep interest in programming, a serious work ethic, and 3 months to spare that they should highly consider Hack Reactor. What’s my basis? Well, let’s look at the promises that were made to me, and how the school delivered.

Promise #1: Learn a lot, through long hours: This is almost silly to discuss. All of my past posts show, through time graphs and paragraphs, that I put in a ton of time, and got even more out of it. The amount of software knowledge I possess now is so much more than when I started, and so much more than I could have gotten on my own. It’s also strongly evidenced by the great projects my class and I deployed. Consider this promise delivered.

Promise #2: Learn to think like a software engineer: This one is taken straight from their website. It’s hard to quantify, since I can’t exactly know what ‘software engineers’ think like, as if they all think the same. That said, I learned a number of strategies for attacking technical problems. I know some fundamental concepts of computer science, and maybe most important, I no longer feel like technology is black magic. I’ll consider this delivered.

Promise #3: Jobs & Profit – $110k/year. That’s the head-turner average salary that’s flashed on the front page of Hack Reactor’s site. Is that for real? From talking with cohorts above me, and seeing my cohort already start to get offers, I can safely say the answer is yes. The median might be slightly lower than the average, but the sentiment is correct. There are a ridiculous number of jobs available for JavaScript engineers, and those jobs pay very well. Hack Reactor provides excellent technical preparation, but the job assistance they give you beyond that is highly valuable, and not to be underestimated as a reason to attend such a program. Consider this delivered.

All told, what is my ‘Hack Reaction’? It’s ‘wow.’ I do not use that word lightly, but that’s how I feel about the experience. I learned a ton technically, but just as much about non-technical things too. I learned a lot about myself, and the importance of a physical community, and about learning itself. Stay tuned for more in-depth posts on those topics. They’re gonna be good. 🙂

Until then, I sign off as your humble correspondent to the world of one software immersion school. I thank everyone who has read this series, shared it around, and e-mailed me questions. You are all awesome!

-Blake

 

Hack Reaction Week 11: Re-starting Life, and Job Hunting

Posted by & filed under Hack Reactor Journal.

Most Interesting Thing: Life is starting again and I’m not happy about it. For the first time in 11 weeks, I have to check my e-mail. I have to respond to people. I have to look at my schedule. What the hell?

Well I now work for Hack Reactor, and this first week is requiring a good amount of ‘set up’. Getting my Gmail and Gcal set up. Figuring out the best assignments and ‘on-boarding’. I’m looking forward to the work, but the ‘pre-work’ is annoying. I also found and landed some contract work, which is awesome, but was also time-consuming. And I’m in the midst of hunting for apartments. Even more time-consuming. None of these things have to do with code. That’s what I’m not happy about. Not like I’m complaining. It’s gonna be an awesome 3 months. I’m just observing my disproportional dislike for something that was previously such an integral part of my life, answering e-mails and getting back to people. HR has affected me in many ways.

There was something amazing about being able to focus on only code for 10 weeks. It’s freeing. It feels insanely good to be so productive and learn so much. But that focus is also what makes it unsustainable. The focus is so powerful that it pushes everything else away, and eventually you have to pick things back up. Yet, I want to retain the best parts of that focus. Try to have as few things to do at a time. For instance, I had originally thought I might do 10 hours/week on about 3 different side projects. But I talked to others and realized what I should do is do 1 project 30 hrs/week for about 3 weeks, and move on. That’s best for everybody involved.

What’s happening?

All of my classmates who aren’t Hackers in Residence are running around like crazy doing the job hunt. Everybody is killing it too. Several people already have offers, and it’s only a week after hiring day. Everyone else is interviewing with great companies, big and small. There’s little doubt that Hack Reactor will keep up it’s impressive job placement rate.

Also, HR is doing it’s part with daily mock interviews, resume review, negotiation help, and more. Even though the official code teaching part is over, HR is unquestionably adding tons of value to the students.

 

As always if you have any questions, e-mail me! Next week will be the final installment of Hack Reaction! So stay tuned…

Hack Reaction Week 10: Group Project Demo’s, and Starting a New Phase.

Posted by & filed under Hack Reactor Journal.

Most Interesting Thing: Time to show off. Our class’s group projects are done, and today we’re presenting them to a room full of over 30 employers. These include numerous household-name tech companies, as well as some fantastic startups. I’ll have deets and pictures on that next week. For now, check out a few of the awesome projects my class completed.

www.readup.co – Find the best articles on code. My group created Read Up as a response to the fact that Hack Reactor students were sending around tons of various blogs and tutorials, via e-mail. We try and stop this madness by making a centralized location to vote and curate the best blog posts on various technical topics.

www.cfh.io – Cards for Humanity is a fast paced online version of the popular card game, Cards Against Humanity, that gives you the opportunity to donate to children in need – all while remaining as despicable and awkward as you naturally are. 

www.scheddit.com – A way to pre-schedule your Reddit posts. This is a super helpful tool if you run a community sub-reddit, or you’re a marketing professional of any kind. Or, as the site says, it’s for “everyone who has a brilliant idea for a post at 2am but wants more upvotes than the Australians can offer.”

 

There were some other great ones too, including one that crunched over 5 billion rows of stock data to create a unique indicator for traders.

What’s going on?

Life at HR gets more flexible in the final weeks, but no less intense. I think that’s the best way I can put it. Somebody left in the middle of the day to see an apartment. It’s totally fine to extend your gym time by 20 minutes if you want. But while the more regimented schedule of being a junior is gone, we are in fact generally staying later. Also, in many ways, it’s more serious now then it was before, because this work is going to be shown to employers, and it needs to look professional from top to bottom. Also, I’ve noticed that while the ‘official’ social nights are still happening, more seniors are opting for impromptu unofficial socializing each week.

What I’m learning?

No new specific technologies this week as we just continued work on our projects. Yet continuing to learn a ton each day, and about the realities of doing real, complicated projects.

Using MIDI.js: Look Past The Pirate Tuna.

Posted by & filed under Coding.

MIDI.js is a pretty great little library for making your dreams come true with MIDI on the web. However, it’s not very well documented and the website design is well, hilarious, so you’d be forgiven for passing it by. But you shouldn’t! It’s got a lot of great features, and after building this project (called Performer) I’ve got some tips for understanding how it works, and getting it to do your bidding.

1.) Usage: The whole library creates an object called ‘MIDI’ that you have access to anywhere in your code. This object has several properties, which basically correspond to the files in the ‘js’ folder of MIDI.js. For example, there’s a file called ‘player’ which has a property called ‘currentTime’. You can access it by saying, MIDI.Player.currentTime;

2.) Most of the good stuff is in Player.js. This is where MIDI files get loaded, parsed, and turned into ‘Replayer’ objects that your browser can play. It’s also where you can use the addListener function that will get fired every time a new MIDI event is triggered. And that right there is probably the single best thing about MIDI.js. You can really hook up anything you want through that listener function. For instance, I animated my Three.js objects with this:

  this.player.addListener(function(data) {
    //Setting up convenience vars
    var rightHand = _this.rightHand;
    var leftHand = _this.leftHand;
    var NOTE_ON = 144;
    var NOTE_OFF = 128;

    //The data from each event
    var note = data.note;
    var message = data.message;
    var finger = data.finger;

    //Routing events to the right functions.
    if (message === NOTE_ON) {
      _this.keyboard.press(note);
      if (finger > 0) {
        rightHand.press(finger, note);
      }else {
        leftHand.press(finger, note);
      }
    }else if(message === NOTE_OFF) {
      _this.keyboard.release(note);
      if (finger > 0) {
        rightHand.release(finger);
      }else {
        leftHand.release(finger);
      }
    }
  });

3). Slay async issues!

This is critical. You should set up some kind of initMIDI function, or else you’re liable to run into async problems where the browser isn’t ready to play your file, so you hear no sound and your app is essentially broken. This is extra critical because it’s deceptive. When your developing locally, it will probably load quickly enough that you don’t need this next trick, and you’ll think your app is totally fine. Then you’ll put it into production, and it will load slower and your app will have no sound and you’ll be sad. Luckily, it’s easy to fix. MIDI.js has a built-in function for detecting what browser people are using, and loading the appropriate audio context. It’s called MIDI.loadPlugin, and it takes a callback. This is nice, because you can then set up your initMIDI function to take a call back, and pass that to loadPlugin. Then you’ll be able to make sure there are no async issues, because the rest of your app won’t start until the MIDI is ready to go. This might look like this…

  var App = function() {
    this.initMIDI = function (callback) {
    //We're just calling “loadPlugin” from the MIDI.js library.
      MIDI.loadPlugin(function() {
       callback();
      }
    }
  }

Don’t be afraid to put a bunch of stuff in that callback. For instance, the call back I used for Performer contained a separate ‘initScene’ function that set up my THREE.js scene. But it also did an ajax call for songs from my database, and auto-played the first song.

4.) Have a player object: Let’s say you have your App.js file, where you’re creating all your needed functions. It can be useful to set the MIDI.Player object as a property of the App. Something like this,

  var App = function() {
    this.init = function() {
    //set stuff up
    };
    this.player = MIDI.player;
  }

This way you’ve got that player object as a property of your app, and you can easily refer to it as needed. This isn’t necessary for the code to work, but it keeps things cleaner and more organized.

There’s other nice features of MIDI.js, such as the time-warp and, if you’re into crazy colors, the Synesthesia components. Those have all these color-note mappings that can let you create trippy effects that sync with the sound. I didn’t bother with it, but it’s there if it suits your project!

Hope this gets you started, if you have other questions, feel free to get in touch!

Much thanks to Euphony , and MIDI.js, both of which were instrumental (yeah, I said it) to making my Performer project.

Hack Reaction Week 9: Already got a job…

Posted by & filed under Hack Reactor Journal.

Most Interesting Thing: Before the official recruiting process has begun, I’ve just accepted a position as a ‘Hacker in Residence’ at Hack Reactor. The HiR program started 3 cohorts ago, and it’s an honor to be offered one of the 6 spots that were available for my class. The program works like this: I stay on for another 3 months, doing 20 hours of (paid) work for Hack Reactor, and the rest of my time I work on whatever I want. After it’s over, I’ll attend that cohort’s hiring day.

The work I do for Hack Reactor could be student help requests, it could be interviews, or it could be building internal software for HR. The things outside of that are indeed whatever I want. Personal pet projects, client work, taking outside courses. Whatever. The program is largely what you make of it, and I plan to make it awesome.

The rest of my cohort will be going through the job hunting process and I fully intend to relay their tales back to you, so stay tuned if you’re interested in that part.

What I’m learning?

-The complexity of software scales exponentially, not linearly: This is one of those things that you ‘know’, but don’t actually feel till it’s happening in your real project. We’ve had to layer on more modules, external tools and libraries for this group project, and I’ve started to really see how fast those interactions turn into more problems. It’s all kinds of little things, but just as one example, a CSS library we’re using was accidentally overwriting the actual CSS we wanted to write. It took a while to realize this though, because the way it was being overwritten was pretty subtle.

-Stylus: This is a CSS pre-processor. Technically I used this for my personal project (http://performer.io), but during this group project I’ve spent a lot more time understanding it’s power, and why it’s so helpful. I highly recommend this tool if you have to write even moderately interesting CSS.

 

Till next time, feel free to get in touch with any questions!

Hack Reaction Week 8: No Recognition

Posted by & filed under Hack Reactor Journal.

Most Interesting Thing: Do not say that Hack Reactor made you a good engineer. That’s the message we got during our Hiring Day “Prep” Sprint. This is so counter-intuitive, it’s jarring. The staff pours their heart into this place. I took out $17,000 of loans, rearranged my entire life, and put in 14 hour days to attend this school, and now I’m supposed to make it a footnote in my resume? And no one involved can show a little pride? Yes. That is exactly correct. The reason is two fold.

One is that HR wants to show off their student’s long history as it relates to tech, and not the last 3 months. But the second is that honestly, no one believes (yet) how much people can learn here. If I say I went to a 12 week program, I sell myself short. Those words “12 week program”, no matter how many superlatives are attached, simply do not translate what Hack Reactor does. People will think “school for 12 weeks”, but really that’s off by a factor of like 3-5. Because of that, Hack Reactor doesn’t bother trying to be recognized for their students success. It’s simply not worth it to attempt convincing anyone. Instead, you should focus on what you’ve built, and why you’re a good person to join the team. I guess that’s probably what anyone should do anyway.

What’s happening?

Group projects have started, so we’re now in groups of 3-5, working on bigger web apps. These will get demoed on Hiring Day in front of everyone. I’ll certainly post ours when it’s ready in 2 weeks. I’m excited to show this one as well.

My group is great. We get along well, and everyone is working hard. Having to work on bigger codebases with multiple people is also a great prep experience for real jobs.

What I’m learning:

Since it’s group project time, we’re really consolidating and applying skills we’ve learned before. But specifically, our stack for this project is MySQL/Angular/Node/Express, which we have lovingly coined the SANE stack.

I’m mostly working on the front-end for now, so I’m getting deeper in Angular.js, which is quite a powerful and super interesting framework.

 

Till next time, feel free to write me with questions!

Hack Reaction Week 7: Showing Off Personal Projects

Posted by & filed under Hack Reactor Journal.

Most Interesting Thing: I’m staying later now than I was before. You might think that as seniors, things get a bit looser, but not so. It has only ratcheted up (in a good way). These projects will represent a major piece of our portfolio, so it’s important we do well on them. Without further ado, this special edition of Hack Reaction will showcase 3 of the projects from me and my classmates. I’d say these are in and of themselves interesting, because these are fully functioning web apps made in 3 weeks by students who started building them only 5 weeks in.

Performer – This one’s mine. It takes in MIDI data for any song, and (through an algorithm I wrote), auto-magically figures out what fingers to use to play that piece on piano. It then visualizes it using a JavaScript library for 3D rendering called Three.js. Beware of trying this on your phone! 3D rendering is pretty processor heavy, and not yet supported on most mobile devices. So use Chrome on your laptop, and enjoy!

www.codercombat.jit.su – Coder combat is a real-time one-on-one programming competition. It attempts to simulate the emotions felt in a technical interview while also improving your coding skills.

http://questiongame.jit.su/#/ – A multiplayer ‘family-feud’ type game that’s surprisingly addictive. You answer a question, and then see the results of everyone else who answered that question at the same time.

What I’m learning:

Deployment – I used Heroku to deploy my app. Really the interesting part is how easy this is now-a-days. It used to be kind of a hassle to put whole web apps online, but there are a number of services now (like Heroku) that make this fairly painless. You still have to know a few little tricks, but once you do, it’s smooth sailing. They have great docs on their site if you’re interested.

Back-end review: I wrote about learning this stuff earlier, but for those interested, I used Node, Express, and MongoDB for my app’s backend. Node/Express served the pages, and Mongo stored pre-computed data from my algorithm.

Software engineering concepts: This project help solidify a number of the concepts I’d been using for weeks now. Good code organization, inheritance patterns, small git commits, writing tests, etc. These best practices, and the reasons behind them, all came to life now that I’m writing projects of real size.

 

As always, feel free to reach out. Till next time!