Scopp Schupcademy

So it's final project time at a/A. My project is a clone of Kayak.com, but for stargate travel. It's called PuddleJumper.

In case anyone wants to follow along at home, PuddleJumper (currently hosted on Heroku) is 15ish% operational. You can see a search form, submit it (if you know what you are doing, because no input validations yet, other than the normal security ones), or you can click the "Surprise me!" button to get results for a random trip early next month. Then the magic happens: Stargate loading screen, ajax requests, json whizzing through the air (if you're on WiFi at least), and then search results. I only just got to the point where I have results to work with, so they're just stringified JSON, but, hey, you've gotta stop somewhere at the end of the day.

If you really want to follow along at home, feel free to check out the source code at GitHub. It's mostly straightforward Ruby-on-Rails backend, Backbone.js frontend stuff right now. I'll let you know if I do anything SUPER CRAZY AWESOME in the future.

ToDo (shortlist):

add typeahead to planet input boxes

format search result data into pretty rows

In Ruby now = Time.now this_time_tomorrow = now + 1.day

In JavaScript var now = new Date() var thisTimeTomorrow = new Date(new Date().setDate(now.getDate() + 1))

o_O

Alternately, I suppose there’s new Date(now + 24 * 60 * 60 * 1000) but that still seems a little ridiculous.

A is for Asynchronous

J is for JavaScript

A is for and

X is jor JSON?!

Today we started using AJAX (Ansynchronous JavaScript and XML, except that XML has pretty much been replaced by JSON as the preferred portable data type). It's basically a way of reducing the impact of network latency, accessing and updating the server without having to resend and reload the same page multiple times, and shifting some of the server-side work over to the client side.

It's pretty incredible how powerful the JS, jQuery, and AJAX trinity is. We've only just scratched the surface, and there's a lot to know to really master it all, but just understanding how it all fits together and knowing that these tools are out there is a huge step forward.

jQuery and the Rise and Fall of Modern Civilization

...would be a great book or article title. But I don't actually have anything to say that's even mildly related to the title. sry.

jQuery is fun. It takes some of the tedium out of writing JS. Underscore.js on the other hand, only added more and new headaches to the mix. Everytime we tried to use it, we couldn't get it to do waht we wanted. This was likely 90% user error, but it was quite frustrating that everything we wanted to do that led us to underscore.js was just the tiniest bit different from what we actually wanted to do and therefore didn't work. For instance, we tried to use _.defaults() to assign default values to a large number of Arrays in the creation of a board grid for Snake, however the _.defaults() function only works with JS Objects, and even though an Array is just an object with it's keys set to sequential numbers, we couldn't get _.defaults() to work in our project :/

By the end of the day, we had a jQuery implementation of Tic Tac Toe (so that's three TTTs now, for those of you keeping track at home: one ruby console version, one JS node console version, and now (finally) one JS version playable in the browser. We also had a Towers of Hanoi (again, our third), and we had about half to two-thirds of a Snake game. We had a board, a snake, the ability to move the snake, but no apples to munch on and no growth feature. Nor did the game end at any of the appropriate places. It was recommended that we finish our snake implementations ASAP so as to have them to show off to potential employers during the not-too-distant job search portion of our lives, so I hope to get to that and Asteroids this weekend.

So much to do, so little time.

So much CSS, so little that makes any sense

Today we did nothing but CSS (well, and some HTML, but otherwise all CSS). No JS. No Rails. No lovely, sweet Ruby. Just evil, disgusting CSS.

Ok, so it wasn't THAT bad. But CSS does some really weird shit sometimes. One of the problems my partner and I had (in fact, almost every one of the problems we had today) was related to CSS's position property. While attempting to adjust the layering of two elements, we learned that the z-index property is ignored when an element's position is set to static. We also learned that every element's default position is static. A little later, we discovered that setting an element's position to relative does not, as one might expect, place the daughter element relative to any points of the parent's box model, but only adjusts the daughter element relative to where it would be if it were set to static. And finally, absolute position completely removes an element from the flow of the page and so does not factor into the resizing of its parent container(s). Yet, as we expected of relative, its position is calcualted relative to its parent. Knowing how relative positioning behaves, this one felt slightly more intuitive, but we still had to learn it the hard way.

Where am I?

That is the question my partner and I had to keep asking ourselves. When working with prototypal inheritance and within namespaces of our own devising, it’s easy to forget where you are, what classes/methods/variables are available to you, and if something isn’t working, how to get to where you need to be.

Asteroids was the playground in which we explored these issues, and though we got caught in what felt like the deep emptiness of space more than once, we made some real progress toward a playable game. We have asteroids, and a ship that can turn and move and be blown up by an asteroid. All that’s left is giving our poor little ship a means of defending itself.

The most interesting parts of today’s project were working with the HTML5 <canvas> tag and the Keymaster library for JS. Both super fun and extremely useful in this sort of project.

JavaScript: Asynchronous Single-threaded Programming Solutions™

So thus far our forray into JavaScript has been comprised of repeating a large portion of the Ruby exercises we did in weeks 1 and 2, but you know, in JS. We did a JS console version of Towers of Hanoi and Tic Tac Toe. We did all the fun recursive problems from w1d4 again: recursive sum, recursive fibonacci, recursive make change, etc.

Today my partner and I finished everything early, and there was no bonus, so we went back and started the bonus project from the previous day which is a game variably called "Reversi", "Othello", or "Morocco". The app version on my phone is a favorite of mine for passing the time, so I was excited to work on this game. We didn't get too far in the 40 minutes we had left, but as we worked on the more basic setup aspects of the game we talked about what we expected would give us the most trouble down the road. We agreed that the most difficult part of the logic would likely be determining the valid moves and that our implementation would likely ened up looking a lot like the Queen class in chess which inherited most of its basic functionality from the SlidingPiece class. We assumed we would end up with an array of 8 directional deltas that we use to check each direction from the starting position for valid moves, checking each potential endpoint with an #onBoard method and an #empty method that makes sure the position is valid.

The most difficult part of the day (and I'm given to understand it's also one of the more difficult aspects of JS overall) was keeping in mind the current scope when invoking keyword this and remembering to properly bind functions used in callbacks or otherwise sent as arguments of other functions in order to keep this in the intended scope. The second most difficult part was getting our chronologically dependent methods to get called in the correct order via callbacks. This is difficult because, as we all know, JavaScript is (say it with me now) single-threaded asynchronous. Meaning when you ask for user input, the program doesn't just sit and wait for the input, it keeps reading and executing code. So if some portion of the program is dependent on that user input, you have to force JS to wait for it by passing the dependent portion as a callback. While callbacks make complete sense once you get the hang of them, they aren't particularly intuitive at the outset, or at least they weren't for me.

JavaScript: it's neither a Java, nor a script. Discuss.

Day 1 of JavaScript was a wild success in that I did not want to rip all of my hair out by the end of the day. It's always a little frustrating starting a new language when you've been so throughly immersed in another, but it's also kind of refreshing to think about how to solve familiar problems with a slightly different set of tools at your disposal.

That said, the things that stuck out the most today were the nuanced (and some not-so-nuanced) differences between The Ruby Way and The JavaScript Way. So without further ado...

My desert isalnd, all-time top five Ruby-to-JavaScript annoyances, in the order in which I discovered them:

All numbers in JS are floats. Which is cool at first, until you want to divide an array length by 2 and get a whole number to use as an index, then your life is literally over.

Variable assignment without a preceding var is allowed, but 9 times out of 10 it will break everything. I now know that it has its usefulness, but I wish Brendan had had one more day to work on JS and chosen to make local variable assignment the unmarked form.

JS has no built-in exponent operator. So 2 ** 3 does not equal 8, it equals

SyntaxError: Unexpected token * at Object.exports.createScript (vm.js:44:10) at REPLServer.defaultEval (repl.js:117:23) at bound (domain.js:254:14) at REPLServer.runBound [as eval] (domain.js:267:12) at REPLServer.<anonymous> (repl.js:279:12) at REPLServer.emit (events.js:107:17) at REPLServer.Interface._onLine (readline.js:214:10) at REPLServer.Interface._line (readline.js:553:8) at REPLServer.Interface._ttyWrite (readline.js:830:14) at ReadStream.onkeypress (readline.js:109:10)

The JS Way is to call a method from the Math object like so: Math.pow(base, exp) Which is just fine. I guess.

JS, unlike Ruby (and Python too for that matter), does not allow parallel assignment. This is particularly annoying when you're writing bubble sort and you need to swap two elements in an array. In Ruby/Python, arr[0], arr[1] = arr[1], arr[0] is all you need to get the job done. In JS, it's a little more convoluded.

And finally, Ruby classes and JS classes are Way Different™. They're created differently, they behave differently, you monkey-patch them differently, you include and extend them differently...there's just not a lot of overlap there. But syntax aside, they're still classes. They have properties and methods. They serve pretty much the same function (as far as I can tell at this point, at least). And they're hella cool.

So there you have it. A n00b's take on transitioning from Ruby to JS. I'm sure there will be more of the same to come in the next few days. Stay tuned.