General Assembly WDI, Week 3: Project Week

Project week! *jumps for joy* *whimpers* *bravely soldiers on*

Squeaking this one in under the wire—the last two weeks have been a whirlwind (I expect I’ll be saying this for a while)!

Last Monday was a holiday. Tuesday was a normal class day. Wednesday through Friday were allocated for work on our first project: a single page Tic-Tac-Toe game built in JavaScript and jQuery, using a Rails API for user authentication and game data storage.

To sum up:

Let’s start at the very beginning, with Tuesday’s class on CSS and SASS:

Day 11

SASS (which GA teaches) and LESS are probably the two best-known CSS preprocessors, but many others exist. We didn’t talk much about the pros and cons of different options, but based on some quick Googling:

  • SASS is written in Ruby; LESS is written in JavaScript.
  • SASS seems to have more available tools to help developers: frameworks like Compass, mixin libraries like Bourbon. LESS has libraries, too, but they’re not quite as powerful and less cohesive.
  • SASS offers selector inheritance via @extend, which is pretty sweet.
  • SASS has better logic than LESS, which is fairly limited.

Fun fact about colors in SASS: the native lighten and darken functions aren’t stellar—they move pretty quickly into complete white/black, rather than tinting or shading things gradually. To fix this, you can use mix to adjust your colors with a bit more control. You can also write custom tint and shade functions that mix colors with white and black to lighten or darken more gradually.

A CSS style best practice I didn’t know before: you should sort your rule declarations by property name in alphabetical order.

Days 12-14: Project Work

The assignment was fairly simple: build a single page JavaScript-based Tic-Tac-Toe game that:

  • renders a game board
  • alternates turns between X and O
  • shows in the browser who’s won at the end of the game, or identifies the game as a tie
  • allows the user to play multiple consecutive games
  • uses AJAX to interact with a provided Rails API to
    • handle authentication
    • store and retrieve game data

My instinct when we got the assignment was to start downloading and playing as many mobile games as possible. I knew I wanted my game to be responsive—who really wants to sit with a laptop and play game after game of Tic-Tac-Toe? It seems like something to do on the train, or while you’re waiting in line for your (much-needed) coffee. Looking at mobile games to identify examples of clean design and intuitive user interaction felt like a good place to start. (The final UI is heavily inspired by the Dots.co family of games, which are among my favorite mobile games for their design, which feels colorful without being overwrought, and their fluidity.)

In hindsight: I wish I’d spent more time thinking about my data models, key functionality, and game logic first. I wrote a handful of user stories and spent a lot of time playing tic-tac-toe and diagramming win conditions, and I didn’t start *coding* the design until I had was able to authenticate users, play games, and log them to the server, but even as I worked on those things, I kept having to stop and reorganize my code to accommodate new features. Taking an hour or two to try to diagram the flow of logic and the exact points at which I needed to interact with the server would have brought more helpful structure to my approach and, I think, kept my code more elegant.

That said: I’m pretty proud of what I built in the span three five days (counting a few hours each on Saturday and Sunday):

Tic-Tac-Toe: large screen log in

Tic-Tac-Toe: mobile game play

Tic-Tac-Toe: mobile game end

Give it a whirl here (and please do let me know if you find any bugs!), or check out the code on GitHub.

Things I learned: I wrote a bit about my adventures in game board design earlier. As I built the functionality, I got some great practice with AJAX (including learning how to pass additional data to AJAX callbacks), and as I styled, I learned how to make a sticky footer. I also learned that it’s shockingly, embarrassingly easy to keep reverting to “x and y” instead of “x and o.” Warning to future tic-tac-toe game developers: this will cause you at least an hour of distress.

Current status: I’m midway through fixing a few small bugs, and I’m still waiting to hear feedback from my instructors at GA—I’m planning to ask them about ways to refactor/restructure and make my logic and flow a bit more elegant.

And my last takeaway: I CAN’T WAIT to learn how to do test-driven development. The single most frustrating part of building this app was having to test each feature manually every time I changed something. I tried to keep careful track of what I needed to test each time, but I *know* I missed things—as evidenced by the remaining bugs in my game—and the process was prone to error (see: manual). I’m not sure if GA teaches TDD explicitly or not, but tests are built into some of the repos they use in training, and I’ve started to track down the frameworks they use (Rspec for Ruby; Mocha and Chai for JavaScript). (In writing this paragraph, I learned about TDD vs BDD. So many things to explore….)

On to week 4 (which is coming to a close today, so expect another recap soon!)!

General Assembly WDI, Week 2

More JavaScript, our first encounter with Rails, and three days of AJAX.

Friday wrapped up my second week of General Assembly Boston’s Web Development Immersive program: as of this weekend, I’m one-sixth done, which is at this point mostly terrifying. How can there be only ten weeks to go?!?

I feel like I’m learning cool things (making AJAX requests that use methods other than GET, for example), but in a very, very controlled and somewhat black box-y environment. GA’s basic approach to a day of class is: pull down these git repos, run Node and/or Bundler commands, and then open up a specific file and do a specific thing. I understand why they don’t want to throw us off the deep end and go too far into things like “runtime environments” and “what is a gem” while we’re still asking questions like “what does ‘PATCH’ mean?,” but at this point I would struggle to implement what I’m learning outside of the structure of GA’s pre-packaged tooling.

To be fair, this is probably because at this point, most of us are only maybe half a step above this:

So. On to the cool stuff:

Day 6

More about fat arrow functions, which (along with template literals) remain one of my new favorite things about JavaScript:

  • The value of this doesn’t change (and can’t be changed) within a fat arrow function. this is fixed at the value it was when the function was called. (This is also known has “having only a lexical this, not a dynamic this).
  • Fat arrow functions can’t be used as Constructors: they don’t have a prototype, and they don’t have a Construct method.
  • Fat arrow functions don’t have an arguments variable.

A bunch of methods for array manipulation: .every().filter(), .forEach(), .map(), .reduce(), and .some().

Assignment using the || (OR) operator: result will be set to the first truthy value. If there are no truthy values, result will be set to the last value. Examples:

     let result = 'result' || 0;
     > 'result'
     let result = undefined || 0;
     > 0
     let result = 7 || 3;
     > 7

Apparently it’s now déclassé to set CSS styles on IDs.

A couple of cool tricks for Sublime/Atom:

  • ⌘ + ? will add an empty comment (using the correct syntax for whichever language you’re using)
  • ⌘ + multiple clicks will set multiple cursors within a document

Day 7

Building multi-row, multi-column CSS layouts from scratch: a serious weakness of mine. Ouch. Also, wireframes that don’t conform to a grid: BOOO.

There are THREE values for box-sizing: content-box (default), border-box (reasonable), and padding-box (only supported in FF.). More in CSS Tricks: Box-Sizing.

An explanation of those horrid unwanted spaces between inline-block elements.

Day 8

First time using Rails! Though only very, very lightly: we cloned the existing Rails code for a simple API and got it running locally so we could make curl and AJAX requests against it.

Some conventions for writing JavaScript:

  • “Predicate” functions return true or false. Begin names of predicate functions with “is” (isEven, isOdd, etc.).
  • Use “on” as a prefix for handlers (onGetAllBooks, onSignUp, etc.).

You can use debugger; as a standalone line in Node to set a breakpoint.

Day 9

Philip Roberts’ “What the heck is the event loop anyway?” is an excellent introduction to the JS event loop. My notes:

  • one thread === one call stack === one thing at a time (single threaded)
  • call stack: data structure. records place in the program. step into a function: add something to call stack. complete a function: pop it off call stack.
  • slow things “block” the stack b/c JS can only do one thing at at time.
  • particularly bad in JS b/c of browsers: you click on a button and get stuck, and the browser can’t return that button back to its un-depressed state. everything hangs. this is because the browser can only render when the call stack is empty.
  • callbacks get pushed to a queue when they’re ready to run, NOT to the call stack.
  • the event loop monitors the queue & the call stack. when the call stack is empty, it moves one thing from the queue to the call stack so it can run.
    • this is why callbacks passed to setTimeout with a timeout of 0 ms will run *after* lines of code that follow setTimeout. the event loop has to wait to give that callback to the call stack until the call stack is empty, even though the timeout is 0.
    • setTimeout is not a guaranteed time to execution. it’s a *minimum* time to execution, since we have to wait for call stack to clear before callback can run.

Day 10

We spent the last three days of this week on HTTP methods (GET/POST/PATCH/DELETE) and AJAX. We started by using curl requests to interact with a basic books API, then built AJAX requests to replicate that process in the browser (click on a button, send the request, handle success and failure). Day 10 focused on authentication: signing up/logging in/logging out, and doing things (changing information, viewing protected information) that require an auth token.

Coming up

Next week is our first “project week.” The challenge is to build a single-page tic-tac-toe game in JavaScript that relies on an existing Rails API to help with authentication and data storage. I’m looking forward to putting what we’ve learned over the last two weeks together into something usable, rather than a series of code snippets that aren’t connected. I feel like I have a good pile of building blocks now, and I’m excited to start using them to *build.*

General Assembly WDI, Week 1

Template literals, fat arrow functions, callbacks, closures, and overwhelming joy.

Today is the first day of my second week in General Assembly Boston’s Web Development Immersive program, a twelve-week, full-time course focused on JavaScript and Rails. The course is intended to take people from no knowledge of programming to a full-time position as a developer, so some of the past week has been review, but I’ve loved every single second of it. Instead of my standard-ish This Week I Learned posts for the next three months, I’m hoping to do quick weekly recaps of how the program’s going.

Day 1

We spend most of Day 1 on the command line interface and on git. A couple of cool things:

  • cd - takes you to your previous working directory. SO HANDY.
  • use git checkout -b newbranchname to create a new branch and check out that branch simultaneously
  • I fixed my first-ever merge conflict!
  • GA emphasizes frequent commits and long commit messages. This wasn’t part of the course, but I recently learned about Angular.js-style commits, which seem like a great way to organize and communicate.

Day 2

Day 2 was our first day working with JavaScript. A couple of new pieces of information/new conventions:

Day 3

  • Seems obvious in hindsight, but you can isolate the unique elements in an array like this:
    let words = ['lots', 'of', 'words', 'of', 'words'];
    let uniqueWords = {};
    for (let i = 0, max = words.length; i < max; i++) {
      uniqueWords[words[i]] = true;
    } 
    

    This will give you an object where the keys are the unique elements in the array, and the values are true (as a convention; you can choose anything you want for the values). This is much simpler than my original approach, which involved…comparing all of the elements of the array to all of the elements? I don’t know. It was complicated and involved, and I don’t recommend it. Do this instead. If you want the final format to be an array, you can use Object.keys() to extract the keys (the unique words) and store them in a new array.

Day 4

  • Object properties are “attributes” when they point to values/primitives. Use constructor functions to attach attributes to an object.
  • Object properties are “methods” when they point to functions. Use prototypes to attach methods to an object. (Why? Functions that are attached using a constructor will be copied and attached over and over again to each new instance of an object. This is a huge waste of memory.)
  • Properties that begin with underscores are private (by convention): not intended for direct access or assignment.
  • “accumulator pattern” (all of the online resources I can find about this talk about it in Python, but it applies in other languages): initialize result, iterate, return result
  • We started using node to run and test scripts.
  • A callback is a function that is passed as a parameter to and executed inside of another function.

Day 5

    • When filtering and transforming an array (arrresultsresults[i] within an if statement can result in “holes” in the array when the original arr[i] doesn’t pass the filter. It’s better to use results.push to skip values that don’t pass, resulting in a cleaner results array.
    • Template literals (WHAAAAAAAAT so cool).

To sum up the week:

This Week I Learned (2016-06-02)

Bicycle face, female depravity, floating point math, and the paamayim nekudotayim.

Three Sisters Lighthouses in Eastham, MA

  • A surprising number of early New England lighthouse keepers were either three-limbed men or widows. The Lighthouse Handbook New England has the tragic details.
  • Two things about bicycles in the 1890s:
    • The fear of something called “bicycle face.”
    • The fear that bicycles would lead to female depravity: “If there is any object on earth which makes jubilee in the realm of unclean spirits, it is a ‘society woman’ in masculine habiliments, straddling a bicycle and prepared to make an exhibition of her immodesty on the thoroughfares of a great city.”
  • (Compound) assignment operators: I knew about += and -=, but there are many, many more (JavaScript, PHP, Ruby).
  • Fun with operator names:
    • -> in PHP is called the “object operator” and is used to access the property of an instance of an object or to call a method of an instance of an object.
    • => doesn’t have an official name, but serves as the separator for associative arrays and is used to assign a value to a key.
    • :: is called the “scope resolution operator” but also the “paamayim nekudotayim,” which means “double colon” in Hebrew. It’s used to access static or constant properties or methods of a class.
    • (I wasted far too much time last semester trying to tell students when they should use the “dash plus the right arrow” or the “equals sign followed by the greater than sign.” Glad to have names for these, though I’m not sure “use the paamayim nekudotayim” will be much better.)
  • Fun with floating point math: “While floating-point addition and multiplication are both commutative (a + b = b + a and a×b = b×a), they are not necessarily associative. That is, (a + b) + c is not necessarily equal to a + (b + c). They are also not necessarily distributive. That is, (a + b) ×c may not be the same as a×c + b×c.”
  • Advice from GitHub on writing the perfect pull request, plus ThoughtBot’s guide to code review.

This Week I Learned (2016-05-10)

I’m better at adding things to my #TWIL file in Simplenote than I am at actually blogging about them.

  • I’m better at adding things to my #TWIL file in Simplenote than I am at actually blogging about them.
  • If an input field’s font size is >= 16px, phones won’t automatically zoom in when a user focuses on the field.
  • Closures, via the JavaScript class I’m taking this semester, Preethi Kasireddy’s article in the freeCodeCamp channel on Medium, and the MDN reference. Key ideas so far: “an important use of closures: to maintain a private reference to a variable in the outer scope”; “you can use a closure anywhere that you might normally use an object with only a single method.”
  • In 1915, the New York Philharmonic had to issue a public notice asking concertgoers to refrain from knitting during the performance.
  • How to get data from the Digital Public Library of America API: particularly proud of this one because I helped write and edit this API’s documentation several years ago as part of my role as the senior project manager for the DPLA at the Berkman Center. I used it to build DPLA Images, an interface for searching the library for image records.

DPLA Images