scottyschup

[scottyschup]

The thing about programming is that unless you build everything from scratch, there’s nothing to stop the rug being pulled out from under you: One day your code works, the next the world is on fire.

(via thethingaboutprogramming)

Which is why I try to build whatever I can from scratch.

[scottyschup]

The thing about programming is that naming things is known to be one of the hardest problems in the field; so what happens if two programmers have a baby?

(via thethingaboutprogramming)

Whatever name they decide, they probably change it 20 times in the first year.

[scottyschup]

Look at his GitHub—he looks like a cashew.

Brandon Lilly, on why he calls Chris Pan a cashew.

[scottyschup]

I don't know much about CSS, but what I do know is humongous input boxes are sexy.

CJ Avilla, a/A instructor and leading expert on HTML form design

[scottyschup]

finalProject.fetch({ week: 8, day: 4 });

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

add some text to the loading screen, maybe a progress bar...

[scottyschup]

JavaScript temporal woes

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.

There’s also a Date.now() which is extremely helpful if you want the time in milliseconds since midnight of January 1st, 1970 (UTC), which of course is what we’re all looking for when we want the current time. But hey, maybe ECMA6 will have some new temporal functions that are actually useful?

[scottyschup]

Final projects start tomorrow. It's going to be two weeks of nonstop work--staying up late--sleepless nights--energy drinks--we're going to push you hard. 'Eye on the prize!' 'The harder you work the more money you'll make!' Things like that. So if you want to sleep tonight. Go ahead. The end is near.

CJ Avilla, head task master at App Academy

[scottyschup]

$.ajax({   week: 6,   day: 5,   success: ‘One week left!’ });

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.

Next week is Backbone.js, which will add yet another layer of integration to the mix. By the end, I won't actually have to know how to do anything behind the curtain :) Next week is also our last week of web development coursework. Then we get 2 weeks to make our final project, and then 3 weeks of how-to-get-a-job and advanced algorithm training.

[scottyschup]

Sometimes a helper function is in order. Sometimes I just don't want to write two separate functions to do one stupid thing when a simple flag will suffice.

[scottyschup]

$(’.week[6]’).day(3)

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.

And now to sleep. If the child across the way will stop crying. Poor little wee baby Seamus.

[scottyschup]

.week 6 { day: 2; }

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.

It was a long day full of trial and error, but by the end, we at least knew we had mastered the position property. We did some fun stuff with border-radiuses as well. And we go to play with pictures of cats in the process. So it wasn't all bad.

[scottyschup]

var week = 6, day = 1;

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.

[Update: now that I've finished Asteroids, I know that Keymaster is worthless if the user may press more than one key at a time]

[scottyschup]

Every. Fucking. Time.

How to troubleshoot code

[scottyschup]

var week = 5, day = 5;

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.

So far we've just been using Node.js in the console and haven't had to think about the DOM or accessing elements by tags, classes, or ids. Monday we're making another console game, so I guess we get a little more time before we get thrown in that box.

[scottyschup]

JavaScript is just really awesome as far as what it can do. Some people don't like the language itself, but it's getting better. And we'll talk about ways to get around JavaScript's...uh...subtle...shitiness.

CJ Avilla, a/A instructor, unofficial spokesperson for ES6

[scottyschup]

Anyway, IE's dead. That's great news. Happy days for me. There will be no wake.

CJ Avilla, a/A instructor, professional hater of Internet Explorer

[scottyschup]

week, day = 5, 4

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.

P.S. Close runners-up to the top 5: JS requires explicit returns. Also, JS != and Ruby != are not equal. Buh-dum ching!