Tech Book Face Off: CoffeeScript Vs. Simplifying JavaScript

I really like this setup for a Tech Book Face Off because it's implicitly asking the question of what can be done to improve the quagmire that is the JavaScript language. Should we try to simplify things and pare down what we use in the language to make it more manageable, or should we ditch it and switch to a language with better syntax that transpiles into JavaScript? For the latter option, I picked one of the few books on the CoffeeScript language, aptly named CoffeeScript: Accelerated JavaScript Development by Trevor Burnham. Then, for sticking with JavaScript, I went with a recently published book by Joe Morgan titled Simplifying JavaScript: Writing Modern JavaScript with ES5, ES6, and Beyond. It should be interesting to see what can be done to make JavaScript more palatable.

VS.

What I've Learned From Programming Languages

I just finished up learning about fourteen new programming languages, and while my head may still be spinning, I've been struck by one thing about learning new languages. Every single new language I learn teaches me something new and valuable about programming. Some languages reveal many new things because they happen to be the first language I've learned based on a new programming paradigm, and other languages may expose only one or two new ideas because they overlap quite a lot with languages I already know. Every language has shown me at least one new thing, though, so I thought I'd take a look back and pick out one thing learned from each language I've encountered. Some of these languages I've used extensively and others I've barely scratched the surface, so I may miss some great insights in the languages less well-known to me, but that's okay. There's still plenty to reflect on.

Explore Simple Game Algorithms with Color Walk: Part 12

We've now been exploring and discussing game algorithms using the simple game Color Walk for months over the course of 11 posts. We started out extremely simple with random and round-robin algorithms, advanced to some obvious greedy algorithms, and wound up discussing a number of graph algorithms. We've discovered a ton of stuff along the way, so it would be nice to step back and review the ground we've covered to see the big picture in all of the experimentation and details of the various algorithms we found along the way.

Explore Simple Game Algorithms with Color Walk: Part 11

In this installment of exploring game algorithms using the simple game Color Walk, we're going to do something a little different. Last time we explored a number of variations and hybrids of Dijkstra's algorithm—the classic, efficient graph algorithm for finding shortest paths—and found that pairing it with a pre-run of Greedy Look-Ahead (GLA) performed better than any other algorithm we've seen so far. This time we're not going to explore any new algorithms. Instead, we're going to look into what makes Dijkstra's algorithm tick: the priority queue. Save for this variant of a standard queue, Dijkstra's algorithm is conceptually the same as Breadth-First Search (BFS), so we want to see what makes this priority queue so special and how we can implement one efficiently with a binary heap.

Explore Simple Game Algorithms with Color Walk: Part 10

We're back for another round of exploring game algorithms using the simple game Color Walk. We finally reached the point of evaluating Dijkstra's algorithm—the classic, efficient graph algorithm for finding shortest paths—in the last post. It performed pretty well against the top dogs: Greedy Look-Ahead (GLA) and the GLA-BFS hybrid, especially when it came to consistently finding the best moves. However, it failed to find the best moves when a board could be solved in under 29 moves, so we're going to see if we can squeeze out any more performance by modifying Dijkstra's algorithm further. To do that, we're going to try combining Dijkstra's algorithm with GLA, running Dijkstra's algorithm in more than one pass, and changing the heuristic we use to guide the search.

Explore Simple Game Algorithms with Color Walk: Part 9

Welcome back for more exploration of game algorithms using the simple game Color Walk. In the last post we covered the other fundamental graph search algorithm, depth-first search (DFS), the counterpart to the previously discussed breadth-first search (BFS). These graph algorithms do a full search of the graph of a color walk game, the full set of board positions resulting from each move at each point in the game. We found that running either of these algorithms to completion is extremely prohibitive due to the graph size being exponential in the number of moves. In order to deal with that exponential growth, we need to look at other graph algorithms, and we have quite a few to choose from. We'll explore some categories of graph algorithms and look at one in more detail, Dijkstra's algorithm.

Explore Simple Game Algorithms with Color Walk: Part 8

We're continuing this ongoing saga of different game algorithms using the simple game Color Walk. In the last post we started exploring the fundamental graph search algorithms with breadth-first search (BFS), because after all, the full set of move choices and resulting board positions of any game can be arranged as a graph. After looking at BFS and finding that we can nominally improve the search for shortest number of moves, on average, it's time we look at the close sibling of BFS: depth-first search (DFS). We'll quickly run into performance issues just like we did for BFS, but let's see if we can come up with a reasonable way to limit DFS so that it can be a useful algorithm.

Explore Simple Game Algorithms with Color Walk: Part 7

We're continuing to explore different game algorithms using the simple game Color Walk. In the last post we took a deep dive into other heuristics that could be used instead of the obvious maximize-the-number-of-blocks-removed approach and found that the obvious choice is actually hard to beat. After looking at various heuristics, it's time we fill in some gaps in our exploration of algorithms by looking at a couple of fundamental graph algorithms: breadth-first search (BFS) and depth-first search (DFS). These algorithms are the two basic ways to search for something in a graph of nodes (or vertices) connected by edges, and a graph is exactly what we have when we draw out all possible move choices with each node representing a move and edges connecting sequential moves. We'll focus on BFS for this post.

Explore Simple Game Algorithms with Color Walk: Part 6

What's next with exploring different game algorithms using the simple game Color Walk? We've come a long way so far with building out the game's interface to support looking at different algorithms, looking at trivial round-robin and random algorithms, and designing a greedy algorithm that picked each move based on the most blocks removed. The last post showed how far we could push the greedy algorithm to look ahead and try to pick a better move that would result in more blocks removed up to five moves ahead, but even after improving the data structure for the board, we hit diminishing returns in looking more moves ahead. It's time to expand our search for algorithms by looking at other heuristics we can use to pick the best move. The greedy algorithm used a heuristic of "the most blocks removed" for any given move, but there are others that we can use.

Explore Simple Game Algorithms with Color Walk: Part 5

We're continuing to look at different game algorithms using the simple game Color Walk as a sandbox for exploration and discovery. The last post covered our first foray into a non-trivial algorithm, namely the greedy algorithm. We found that using the strategy of grabbing the most blocks from the board on each move was a reasonable thing to try, and it outperformed all the previous trivial algorithms. Then we extended the greedy algorithm to look ahead one move and found that it performed even better. Now we're going to extend the greedy algorithm to look ahead arbitrarily far and see how far we can actually look before the run time of the algorithm becomes prohibitive. In this process we should be able to find a way to improve the current data structure of the board to make searching more efficient and allow the algorithm to search more moves ahead as a result.

Explore Simple Game Algorithms with Color Walk: Part 4

In this series we are taking a look at different game algorithms using the simple game Color Walk as a sandbox for exploration and discovery. The last post showed how to add multiple algorithms and select between them, as well as exploring a random choice algorithm and an enhanced way to skip useless choices for both round-robin and random choice. This post will get into our first non-trivial algorithm, the greedy algorithm. Greedy algorithms don't care too much about the future. They will look at the choices immediately in front of them and try to pick the choice that will get them the most stuff right away. That's why they're called greedy, you see? In this case, the greedy algorithm will pick the color that will remove the most blocks on the next turn. Let's see how it stacks up to the trivial algorithms.

Explore Simple Game Algorithms with Color Walk: Part 3

In this series we are taking a look at different game algorithms using the simple game Color Walk as a sandbox for exploration and discovery. The last post showed how to implement one of the simplest algorithms I could think of, round-robin, and how to develop some tooling around the game so that we can quickly run through multiple iterations in a batch mode and see statistics on the run. This post will start exploring some more algorithms, and we'll start needing to think about how to improve the algorithms so they aren't so naive.

Explore Simple Game Algorithms with Color Walk: Part 2

In this series we are taking a look at different game algorithms using the simple game Color Walk as a sandbox for exploration and discovery. The last post was an introduction that described what Color Walk is, explained how to get it running on your own setup, and presented some brainstorming of possible algorithms to explore. This post will start digging into the simplest of those algorithms: round-robin, but first, we need to build up some tooling around the Color Walk JavaScript code to make it easier to test out our algorithms and benchmark their performance. We'll use the round-robin algorithm as a vehicle to help develop this tooling, so we have something to play with while getting the benchmark tooling up and running.

Explore Simple Game Algorithms with Color Walk: Part 1

A few years ago, Jennifer Dewalt did a project where she created 180 websites in 180 days, one every day for half a year, to learn how to program. These "websites" were actually web pages within one website, but the plan and the execution were still quite amazing. I watched on and off as she created page after page, learning all about web development in the process. One page in particular caught my interest: the simple game called Color Walk.

In this game there's a 20x30 grid of colored blocks in five different colors. The top left block is blank, and there are five colored buttons to choose from. Click a button, and the blank space will expand by removing the adjacent colored blocks corresponding to the button clicked. The goal is to clear the board in as few clicks as possible.

Color Walk by Jennifer Dewalt

A Barely Adequate Guide to Displaying Chess Games with JavaScript

I've done a few of these Barely Adequate Guides in the past, the idea being that I want to explore how to do something with code that I've never done before, and I'll figure it out while writing the post so that we can all see my thought process as I go about solving the problem of getting something new up and running. This time I want to bring together two things I love doing in my free time: programming and chess. I wouldn't say I'm an especially good chess player—I'm quite mediocre actually—but I love the game, and I love learning it and reading books about it.

Let's Refactor Some of My New, Bad Code: Part 3

Welcome back to my multi-part post on refactoring some bad code I wrote last year to make it a little less bad and a little more readable. The code is a bunch of copy-and-paste code I wrote for the Everyday DSP for Programmers series on how to do some basic and some not-so-basic signal processing, shown with nifty animated graphs using JavaScript and the HTML5 canvas. The refactoring so far has involved fleshing out the API I had started when I first wrote the DSP series, fixing a couple bugs that I had never gotten around to fixing before, and working my way through the code for the first post in the series, making improvements and cleaning things up. The goal for this post is to pick up the pace because there were 15 parts to the DSP series, and I'm not writing posts for this refactoring series one-for-one with that series.

Let's Refactor Some of My New, Bad Code: Part 2

I've been on a refactoring kick lately, and last time I started refactoring some fairly recent code I wrote for my Everyday DSP for Programmers series. I was able to fix a long-standing issue with touch screen support and refactor the API that I had started for drawing animated graphs on the HTML5 canvas. Now that I have a decent foundation, it's time to start systematically walking through the code in the blog posts and extracting the parts that are repetitive into the API so that the code left in each blog post can be lean and clean.

Let's Refactor Some of My New, Bad Code: Part 1

I've been on a refactoring tear lately, having refactored some code I found on the Internet for use in a rainflow application and some old code of my own from one of my college courses. I had so much fun doing those posts that I thought I'd round out the trilogy with one more refactoring exercise, this time on some code I've written recently, and horribly. The code comes from the JavaScript code I wrote for this blog in the Everyday DSP for Programmers series. All of the DSP graphs in that series used the HTML5 canvas and the PixiJS 2D rendering library to draw the moving plots that I used as visual aides. I wrote quite a bit of crappy JavaScript, or rather, copied quite a bit of crappy JavaScript to make those graphs. I unapologetically copied my code from one graph to another and added tweaks to get what I wanted for each example animation, making that the most non-DRY code I've ever written.

Tech Book Face Off: JavaScript: The Good Parts Vs. JavaScript Patterns

After learning a new language and getting comfortable with its syntax and feature set, it's a good practice to explore how to write well in that language. Each language has its own quirks, and writing well in a programming language means learning how to write in it idiomatically—how to structure statements, functions, and the entire program in a way that is most efficient for that language, and how other programmers expect things to be expressed in that language. I figured it was high time that I learn more idiomatic JavaScript, so I picked up a couple of books on the subject: JavaScript: The Good Parts by Douglas Crockford and JavaScript Patterns by Stoyan Stefanov. Both books are fairly slim, easy reads, but there's no need to read both. Let's see which one comes out on top.

VS.

Tech Book Face Off: Practical Node.js Vs. Node.js the Right Way

I've recently gotten into some server-side JavaScript development at work, and I needed to take a crash course in Node.js to make better progress, so I did what I always do. I picked up a couple of books on the subject and dug in. I did some perusing of reviews on Amazon.com and settled on a couple of books that appeared to be solid: Practical Node.js by Azat Mardan and Node.js the Right Way by Jim R. Wilson.

The funny thing about Node.js (I'll refer to it as Node from now on) is that there's not that much to talk about, so you quickly move on to talking about all of the libraries that you can plug into Node to get stuff done. That's because Node isn't a framework like Ruby on Rails or ASP.NET MVC. Node is a runtime that runs on the Chrome V8 engine, and all it does is allow you to run JavaScript directly on any machine outside of a browser. It includes a small, tight collection of APIs for working with file systems, operating systems, and networking interfaces, and it establishes an asynchronous paradigm for writing and executing code.

This asynchronous paradigm takes a little getting used to. Basically, any function call that could block, be it a file system access, database access, or HTTP request, will take a callback function as its last parameter and return immediately. When the slower operation finally finishes, the callback will be executed with the response from the operation as its parameters. If you forget about this behavior, you'll very quickly run into situations where you're trying to read things out of a database that haven't been written into it yet, or getting empty responses from HTTP requests. Basically, all dependent code needs to be executed inside callbacks, and that leads to the well-known Node existence of Callback Hell. We'll talk more about how to deal with that in a minute, but that pretty much is Node in a nutshell. Let's take a look at the books.

VS.