Pros & Console

Usually, when I'm done with a project, I leave it alone (with a few exceptions). But when I was told that the lines looked like strings on a pegboard, my friend convinced me to make it musical.

Actually, he challenged me to build an audio component by the time he got home from our hangout. (Un)Fortunately, there were subway delays, so I had plenty of time to hook it up to the audio.js “library” I made for previous projects.

First, we construct a list of available instruments. Some come from my "library," and users who've built their own on toneMaker will see custom sounds as well. Next, we pick one:

This function attempts to pull all the JSON data tied to a specific name, then build an actual audioContext API instrument from those parameters.

I was already keeping track of the cursor's position for two reasons: to find the closest dot when you start or stop drawing a line, and to find the closest lines - above - when you're erasing them. (Note that the callback function is a stand-in for erasing... or whatever else we want to do!)

Since we're plucking strings, (not pegs,) the latter is more relevant. We also need to figure out how long the string is, using the Pythagorean Theorem, since wavelength is inversely proportional to frequency.

That's right: physics time. v = fλ, where v is the speed of sound, f is the frequency (ie, the note) and λ (lambda) is the wavelength (ie, the string length). Of course, this is cyberspace, so I also multiplied by an arbitrary constant to get the pitches in a comfortable range. ...How does it sound to you?

tl;dr: callbacks make code more flexible - they're not just for async stuff; small, clean functions with obvious inputs and outputs make for more reusable code; in addition to his famous triangles Theorem, Pythagoras also determined the ratios of intervals, as seen in the first screenshot

It's pretty easy to make a square grid. But rectangles? Triangles? Hexagons!

Usually, when I need squares, I just make a Google Sheets spreadsheet and set all the cells to the same height and width. Rectangles are easy too - just stretch those squares in either the X or Y direction. (Below, an irrelevant example:)

But quadrilaterals are not the only shape that tessellates! So I decided to build an application that lets you draw lines along a variety of grids.

Besides the many, many options, you can also see (highlighted) the visualization framework: HTML <canvas>.

Let's start with a square grid, since that's the most straightforward. And just like in a spreadsheet, a rectangle is just a square stretched by some factor in either the x or y direction:

Note that <canvas> keeps the origin in the top-left - so I'm drawing “down & right” from there. But since the whole thing is draggable, I need to draw in the other 3 quadrants too, to fill the screen.

Anyway, on to the fun stuff: triangles.

A bit of math (and/or Wikipedia) shows that the base to height ratio of an equilateral triangle is 1:√3/2, which means for every 1px we move in one direction, we just move Math.pow(3, 0.5) / 2) px in the other.

Oh, but that would give us rectangles again, right? Not if we offset every other row! In this case, shifting and shifting back by half a length each time makes the dots line up like triangles.

This application also supports a triangle grid rotated 90 degrees; for this, the main difference is switching the x and y from the function above. Remember this, as it's also how we'll rotate the hex grid.

Hexagons were the most interesting. They seem complex at first glance, but in reality, a hexagon is just a bunch of triangles without a dot in the middle. When you look at them as a big grid, the pattern is obvious: skip every third.

In the function above, you can see where the Boolean for “hexagon” and the “skipCount” variable make this happen. And again, for sideways, we just flip the x and y - just like triangles.

Oh, right - the dots! The only thing of interest is that I use the same function for the gray dots of the grid and the larger colored dots of the lines (using that ternary operator). Also, the lines between these dots work just like they do in the aptly named dotConnector, but now on <canvas> instead of <svg>.

I feel like I’m forgetting something else though...

tl;dr: start with the simplest shapes and build more complex ones with little tweaks; name your variables and functions consistently and clearly

After making Snake, I decided to go for a more complicated arcade classic: Tetris.

Style-wise, it's the same box-shadow heavy aesthetic you've seen before. And logic-wise, it's fairly simple: a large grid whose squares are lit up different colors as a setInterval() moves "blocks" down the coordinate system.

So let's talk about player inputs. You'll notice some <button>s on the side of the screen, laid out like an arrow pad.

As it turns out, both clicks and keydowns will trigger the action.

I used standard arrow symbols (whose HTML encoding I found here) to avoid loading in a library, and to reinforce the fact that you can also use your arrow keys for this.

Maybe I should break out Snake again - and make it so you can play on mobile, with similar onscreen controls. Hm...

tl;dr: give users multiple input options; use simple symbolism to reinforce functionality; Tetris is great precisely because it is simple to play

It's definitely important to stay flexible when working with someone else, and in this case, that often came in the form of CSS flexbox.

Not everything is flex; the board itself was easier to build dynamically in JavaScript, using display: inline-block; and sizing that equates to an eighth of the space.

But we wanted this to work on mobile too, so flex was the best way to style the container and sidebar...

...which takes on a completely different format on mobile.

Using media queries, we set a different flex-direction for each screen size, changing the overall orientation of the options.

We also used flex for centering things vertically and horizontally. Normally, I'd achieve this with some hack-y position: absolute; top: 50%; left: 50%; stuff, which moves the top-left corner to the center of the container - and then transform: translateX(-50%) translateY(-50%); to slide the center into the center instead. But look at all the stuff you can do with flexbox!

There are tons of options for this CSS gem, which is both widely supported and easy to learn. And that's exactly what a project like this is all about.

tl;dr: know when to compromise to move things along; use modern CSS features like flex for cleaner, clearer code

Really think about this for a second: what is checkmate?

In chess, checkmate is the goal - the configuration of pieces on (and off!) the board that leaves your opponent with no escape. It means that on your next move, you would capture the king, and there's nothing your opponent can do to stop that.

Okay, so let's use the moves functions from the previous post; we run through all of the moves for all of your pieces, and see if any of them are capturing the king.

That's check. That means you could take the king, so your opponent had better do something. Above, we effectively simulate your turn and test out all the moves until we find a match.

...But now we have to simulate your opponent's turn, and try to get out of it.

Checkmate means every possible future state of the board, no matter which move your opponent makes, still leaves them ready to lose.

Another possible end-game: draw. There are a few scenarios that lead to no one winning. For example...

...if you're down to just a handful of pieces, it may be impossible to eke out a win. How would you checkmate a king if all you have is a king?

Another way to draw is by repeating the same moves again and again. This prompted us to track every move in a global history array - which lends itself to an awesome post-game replay tool.

With these functions, we can see if the game is over after every move - good luck checkmating your friends!

tl;dr: sometimes big problems are just a bunch of small problems in a row; sometimes there's a standard answer already

Check(mate) it out!

Max and I worked on a Chess web app, on and off, from April to July - mostly out of a Think Coffee, where they don't ask many questions. The goal was to build a fully-functioning, 2-player hot seat, front-end-only chess game - and to not kill each other.

The first big challenge was figuring out where pieces could go. In addition to just showing the player, this is necessary for validating choices and, as we’ll explore later, checking for check (and checkmate).

Using an (x,y) coordinate system, we figured out that knights would always move to one of 8 locations: (±1x and ±2y) or (±2x and ±1y). But of course, only if that square is within the 8-by-8 grid. And only if that square is unoccupied, or is occupied by an opponent piece:

And that naturally led to restructuring our data. See, while it's important to know the location of each piece of each player...

...it's equally important to know the occupant of each square...

Sure, you can do an intense lookup each time, but creating a copy of the same data, and organizing it in a different way, was a powerful paradigm shift. And, as it turns out, really important for getting the moves of other pieces. Unlike the knight, they can't just jump to the destination; they all depend on the occupancy of every square in between too:

The queen is just the combination of the rook and bishop...

...while the king is just a subset of the queen, plus some special moves for castling:

And then... the pawn. Sigh. It's different directions, depending on the color. Attacking is diagonal. Reaching the edge triggers a promotion. And ugh, how I hate en passant.

Look at that monster. And that’s only half - the other color is moving in the opposite direction! But I’m pretty confident that no illegal moves are allowed, and no legal moves are not allowed. Maybe.

tl;dr: one problem leads to the next - I think they call that "scope creep"; getting your data structure right is key; reusable functions save coding time later on

APIs can be frustrating - so much so that I sometimes need to walk away from a project for a day or two. The Internet Games Database API was no exception. Let's follow the logic!

Okay, so you've submitted a search term. First thing's first: let's sanitize that sucker.

We'll also need encodeURI(), since spaces aren't supported in query strings, which is how the API expects the search terms.

The extra parameters all come from the documentation. in this case, I'm filtering out games whose ratings are not greater than 0 (ie, don't have a rating); ordering by popularity, so we're more likely to get legitimate results; and setting the limit to 50, which is (sadly) the maximum. Let's execute that request:

When we get a response, I know it'll be an array-like string, which we'll .map() down to game ids, sending out a second request for all their info.

Note that I'm attaching these game ids to the request variable, and passing that, along with the callback function, into the next step. This keeps everything clean, since every function knows to expect the full request and the “final” callback, which will send the response.

Okay, same story here. What's happening .on("end") now? What do we do with the data?

First, we make a simple list of all the words you originally searched for - this lets us .filter() out any results that don't contain the actual search terms.

Second, we clean up the otherwise complex data. To make those pretty graphs, we only need a few parameters, though the JSON from the API may or may not have them, and might even call them something different.

Third, we .filter() out games that don't have both a rating && a date, since both are necessary to plot the point on the graph.

And finally, we .sort() the games chronologically, then return them back up to trigger the callback function, which sends the response client-side for visualization. ...What games are you gonna look up?

tl;dr: this story glosses over the struggles of API authentication and error handling; third-party data is sloppy, so make sure to clean it up and organize it; making a request from nodeJS looks a lot like responding to one

I'm enjoying my continued exploration into HTML <canvas> and all its quirks; today's travels take us to the wonky way we go about rotating.

The goal here was to connect with an API (more on that later) to display some data: the ratings for related video games as a function of time.

The data comes through as JSON, and the browser has to plot points on a graph. Above, I draw the axes; below, I add some labels.

Just like with lines and circles, everything here is drawn in Javascript, so instead of CSS, we need to temporarily change the parameters of the context. In this case, we set the color with .fillStyle, the alignment with .textAlign, and the font with... uh... .font.

But for the y-axis, we need to turn the words. What exactly is going on here?

Well, you can't actually turn the words... but you can turn everything else. Instead of drawing on an angle, you rotate the <canvas> - like moving a piece of paper while holding a paintbrush over it.

However, the <canvas> is always rotated around (0,0) - generally the top-left corner - so we need to translate the whole thing, then spin, then un-translate so we're drawing in the right spot.

Knowing I'd need to do this for every result, I made it a reusable function that takes the (x,y) pivot point, the angle to turn, and a callback function - whatever I intend to do on this temporarily altered backdrop. I'm looking forward (relatively speaking) to reusing this block in a future project.

tl;dr: translate the <canvas> with .translate(x,y), turn it with .rotate(radians); use callback functions to do something different within something repeated

Here's something I've been neglecting since I started coding: connecting everything.

Sure, my main website links out to all my projects, but none of them linked back, making it hard for interested people to find their way to new stuff. Well... now I've added my blue J to just about every demo.

It's just a tiny bit of CSS...

...and a single line of HTML...

...but now you can look to the top-right of every project if you want to bring up the list of all the others.

In a few cases, the structure of the existing application meant I couldn't claim that corner, so I had to get more creative.

But I found a spot for that little logo in every site nonetheless.

I guess it's going to be my calling card from here on out. Plus, planning ahead means I won't need to customize as much (like different filter: drop-shadow() colors or different top and right positions from the edge) to match existing styles. And I won't end up in a situation like this...

...or this...

...or this...

...where the corner's already kinda used. Instead, look for more intentional navigation bars...

...or simple standalone "watermarks"...

...where it fits more naturally. Of course, this is only one way to do it; how do you sign your projects?

tl;dr: link back to your main site from each of your others; use target="_blank" to open in a new tab; keep a consistent logo or catchphrase (like Max’s “made with <3”) to sign your work

Long before I was ready to make lasers bounce around, I built a pretty pointless app - though it was technically full of points.

This "game" (and I use the term loosely) generates a whole bunch of random coordinate pairs and draws dots in the HTML:

The user clicks them to "connect the dots" - albeit without any interesting image at the end. Clicking a dot starts a line (referenced as window.drawing)...

...and clicking another ends it - and maybe starts a new line. (It all depends - dots can only ever connect to two lines!)

I also added a rule: lines can't cross. And that means my code needs to know when they do - so it can delete the new line and update its dot (to free up a slot).

If you've got any two points, you can find the equation of the line connecting them. First, find the slope (m) by dividing the x-difference by the y-difference. Then plug it into the famous equation, y=mx+b, with one of the existing points as a coordinate pair, to find the missing y-intercept value (b).

All lines that are not perfectly parallel will intersect eventually, so we can set the two line equations equal to each other to find the coordinates of their crossing point.

Then the last step. It’s time for checking if that point is within the depicted segments: the previously drawn line, and the line you're making now.

That's it! This kind of code has served me well in many applications; hopefully you can connect the dots.

tl;dr: simple geometry strikes again; name your variables explicitly; string conditions together with && and/or ||

Sure, light is both a point particle and a wave (OR IS IT!?), but in this case, let's just pretend it's a line. A lot of lines.

First thing's first: placing laser pointers on the board. I'm using a combination of mousedown listeners and mousemove listeners to figure out where the cursor is, then creating an object with an x and y value set to the event's .clientX and .clientY.

I'm also randomly generating an angle - which looks a lot like randomly generating a string or number - between 0 and 359.

Over the course of building this application, I found myself reusing a lot of math - converting between degrees and radians, finding the diagonal distance between two points, calculating the slope and y-intercept of a line based on two points (or a point and an angle) - so I pulled out a bunch of geometry into standalone functions.

Also, sometimes my angles ended up outside the 0 > x > 360 range. And sometimes my calculations produced long trails of decimals. So this pair of functions keeps the numbers reasonable:

Okay, with all that abstracted away, a laser line shoots out of an emitter... and goes where? Remember that <canvas>'s .lineTo() paradigm connects two points, so we need to figure out the far end of that laser. ...Well, if nothing else, it'll hit the edge of the window, right?

Remember from part 1 that, onload and onresize, we change the <canvas> height and width - in reality, this also stores the coordinates for the corners, which we’ll use in a minute. But before we fall back on the border, we need to run through all the mirrors, refractors, prisms, and more:

When it comes to mirrors (lines), refractors (circles), and prisms (triangles), I need different methods to detect a collision with each - to see where this laser line intersects with each of those shapes, essentially by setting the equations of various arcs and lines equal to one another and seeing what (x, y) points we get. And then...

...once I've got all the options - all the possible intersection points - I can compare - by looping through with findDistance() - to determine which is closest. And then, finally...

...we draw the laser! But here's where it gets interesting: unless that collision was with the outer window edge, something fun will happen to the light, and we'll need to run the function again. Hello, recursion, my old friend.

For mirrors, it’s easy to calculate the angle of reflection, as long as we've got the angle of incidence (which is the angle of the incoming laser, from the perspective of the angled mirror).

For a refractor, things are a bit trickier - we need to call in Snell’s Law. Every material has a different index of refraction - essentially, how much it bends light - so for this simulation, I made it slightly more pronounced than water. This bit took some trial and error, but under the hood, it definitely works much more like real-world physics than my last project.

And prisms are just fancy refractors that also happen to split light up into its component colors. For simplicity, the application only supports red, green, and blue, but I make sure to shoot them out at slightly different angles to produce that prism effect.

And that's all there is! I mean, there's definitely more math, but that's the big picture. I guess the last important thing to note is that I added a counter that increases every time through the recursive function to avoid infinite loops and crashed browsers. So here's what it looks like when you push it too the limits:

Yeah. I'm pretty proud of this one - take a look and let me know what you think!

tl;dr: abstract away your math with helper functions for cleaner code; research the real-world equations first so you don't have to reinvent physics; avoid recursive loops with a counter and an extra condition in your while loops

For the longest time, I was resistant to learning how to use HTML's <canvas> element - instead of DOM nodes, you draw in JavaScript, and that seemed... scary. But it truly was the best way to make these lasers work.

In the next post, I'll go through the math that makes this work; for now, let's focus on the fun stuff. To start, I saved a global variable for the <canvas> element and another for the context - the visual analog of audioContext, i.e., the environment in which we're drawing.

Then, every 10 milliseconds, I trigger a drawing function, which clears the screen...

...and pulls info from a global object storing the location information for all the laser pointers, mirrors, and more.

After the math, I'm left with a series of points. This could be the center of a circular refractor (i.e., a drop of water)...

...or the corners of a triangular prism...

...or the two endpoints of a line representing a mirror, filter, or wall...

Using these context methods, I can loop through all the items and set colors - via strokeStyle and fillStyle - and thickness - via lineWidth. Since these objects are not real HTML elements, they can't be styled in CSS... which took a bit of getting used to. In fact, here’s all the CSS I need for this <canvas>:

The only other thing to keep in mind is ensuring the <canvas> scales to match the screen size, both on load and when the window is changed.

Again, it's not the CSS that needs to change, but a height and width parameter pair that informs the math for placing points in the first place. ...But we'll get to that; for now, enjoy the lasers!

tl;dr: doing this with HTML elements would make it slower, because DOM calls are expensive; .moveTo(), .lineTo(), and .arc() are your friends; setting <canvas> size on resize avoids weird scaling issues

Synesthesia comes in many forms, and for my girlfriend (.age++ today!) happens to be a grapheme-color synesthete, meaning text symbols register as colors to her. Kind of like this:

Emphasis on the kind of. In reality, letters group together and influence one another more than this... in a way not easily emulated by JavaScript. At one point, she built a website where you can enter text and see it how she sees it:

I took her colors - a long CSS list of letters (classes) and colors (#hex codes) and built it into a Chrome Extension that can color the text on any website.

It searches down the DOM tree, and every text node it comes across gets split into an array of letters. I wrap each one in a <span> - to apply those classes from before - and then override the node with these new ones.

It's a simple, though somewhat intense, process, but it makes for a cool effect. And a great birthday present. (Last year - this year, I composed her a song.)

tl;dr: Chrome extensions are just JavaScript; they also let you change the icon to depict statuses (in this case, a loading animation); text can't be styled, so just wrap it in a <span>; happy birthday, Liz!

It's been a busy couple weeks at my job, where I'm now working across three separate engineering teams (and all the projects that entails). I've also been coding a lot, and we'll get back to that, but first I thought I'd share something interesting from the Growth Team.

Google Search Console is a tool that lets you see what Googlebot sees as it tries to index your website. In our case, it saw a not-insignificant number of 404s - that is, links on our pages directing traffic to non-pages. Google's guidelines say this ain't so bad, but I bet it becomes a problem when we're getting as many as we’ve got.

So... I need to figure out why. And I certainly saw some problematic patterns in our processes - for example, when an old article is deleted, it's up to an individual (non-technical) writer to create a "redirect" to a new one - or a listing page - to avoid 404s. Stuff like that. But that's not what's happening here:

See, our custom content management system (ie, the analog of the editor I'm typing this Tumblr post on) interprets HTML, meaning links look like this:

See the problem? Since there's no automatic link formatting or validating, writers can accidentally create internal links (to non-existent pages) when they mean to make external links (to other websites). So I spent a few hours one morning coming up with a regex pattern to catch these guys:

Obviously, this catches the problem after the fact, when the links show up in HTML, but our engineers were able to make it more useful by making sure the markdown includes a protocol/scheme (http://, https://, mailto:, etc.). The fix isn't in yet, but fingers crossed, our 404s go missing.

tl;dr: treat the disease, not the symptoms; Google Search Console is a great error-catching tool; regular expressions come in handy

In the film National Treasure - this is as much patriotism as I can muster this July[3] - there's a scene where Riley enters the unsorted letters of a secret password into an algorithm to get all the possible anagrams. This is not that.

This small project from many months ago is much less capable - it finds words that use some or all of the letters you give it.

Since I'm using the same free, downloaded-from-a-Google-search dictionary that powers wordFinder, the program can only come up with vocabulary in that limited list (of ~10000 terms, to be fair).

It works recursively, building a branching tree of word stems by starting with each letter, testing out all the options for the second, and then, for each of those, all the options for the third...

Ultimately, the tree needs pruning, by looking up the .indexOf() each word within the dictionary array that corresponds to its first letter.

I imagine there must be better ways to do this - because for a long enough word, the whole thing simply seizes up. But if the count is something less than infinite, the words are sorted by .length and divided into separate arrays (above).

Those arrays are .sort()ed so the 2-letter words take the top spot, then 3-letters, etc. Then each one is alphabetized (using the default .sort() behavior) and displayed within <details> / <summary> blocks. So... give it a go, but don't try too hard - and look for another post soon, about a similar project that avoids similar problems.

tl;dr: recursion is great for tree-making; little efficiencies (like subdividing big arrays) can go a long way; I actually hard-coded a length limit to avoid crashing users' browsers

I recently led a second tech talk at my job, and to adequately explain websockets, I built perhaps the dumbest project yet:

ClickClique is a competitive real-time button-masher wherein you and your friends trigger that mousedown event as fast as you can. On the front-end, visiting the site establishes a two-way websocket connection with the nodeJS server:

When you click, the x and y coordinates are sent using the built-in .send() method:

The server stores everybody's connection in local memory, in an object, meaning no database is necessary:

Instead, there’s a big ol’ array of “clicks” - (x,y) coordinate pairs with timestamps and randomly generated user IDs. Incidentally, those user IDs are constructed such that they can be used as hexadecimal color values:

When you add a new click to the clicks array, the oldest one is pushed out - so there are never more than 100:

Then this updated array is sent out, and not just to the clicker, but to everyone:

In a long-polling or short-polling AJAX application, this would be either more resource-intensive or less immediate, respectively. But websockets make it seamless. Anyway, the background color updates to show who's winning, and a small CSS transition depicts the opponent clicks as growing, fading circles:

When I showed this to a room full of software engineers, of course someone wrote a script that auto-clicked 100 times a second... but outside of cheating, can you best your friends?

tl;dr: websocket is great for instantaneous two-way communication; click listeners give you the event position with .clientX and .clientY; CSS transitions are a simple way to gradually adjust height, width, and opacity

When it comes to password management, there are good practices, there are best practices... and then there's this:

So today we're gonna talk about keeping users' passwords secure. First, does your site even need accounts, or can you just create a random new session id for each visitor (and store that in a cookie on the client-side)?

Assuming your users have some personal data that needs to stay attached to them over time and space, you might need to make accounts. That means storing a username and password in a database.

Note that these passwords are all complete gibberish. If I stored them as plaintext, a hacker (or I) could see the actual passwords... and then log into other sites where people reuse those passwords.

So we hash them.

A hash is a complex algorithm that obscures the data so much that you can't go backwards - unlike encryption, which can be decrypted with a secret key. Hashing takes a string of any length and turns a random-looking string of fixed length (often in binary or hexadecimal).

But if the sha1 hash for "sandwich" is always 579d b7d6 67a2 1ecf ff23 3f26 7a78 2cb7 7ee9 4437, couldn’t you figure out the password from the hash? You’ve just invented rainbow tables - a collection of the most common passwords... and their hashes. So we need to introduce a little chaos. (Above, PHP; below, nodeJS.)

Here's the idea: when a user sets a password, we create a random string, called a salt, then run the password + salt combo through the hashing algorithm. When a user later tries to log in...

...we fetch the salt - the one associated with the user - and combine it with the password attempt, feeding that into the same cryptographic hash function from before. At no point do we directly check the password; instead, we see if the same process yields the same result... which would imply that the input is the same. Here’s similar code, once again in PHP:

There are lots on different algorithms (sha512 is way stronger than the sha1 I used in my PHP days) and different ways to generate that salt. Plus, there are trusted packages that handle this all for you. What I'm saying is in 2018, there's no excuse for plaintext password storage.

tl;dr: security breaches are a real thing - don’t expose users' passwords; salt and hash, or load in a library; yes, I know - SQL injection - but this is old, dead code