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

What Can One Do in a Year?

One year. Three hundred sixty-five days. Eight thousand seven hundred sixty hours. Seems like a lot of time, right? Where does it go, and what do we do with it all? If you're like me, you might spend the majority of that time sleeping, working, spending time with family and friends, doing chores, and eating, in roughly that order of time consumption. When all is said and done, I have about two hours a day of leisure time that I can do with as I please, although not every day. Maybe 300 days out of the year, let's say, I can do self-driven activities.

A Barely Adequate Guide to the Google Blogger API using Ruby

For some time now, I've been wanting to do some things with this blog that are just too tedious to do by hand. For instance, I'd like to download all posts with pictures to have a local copy, you know, just in case. Google leaves a bit to be desired in this regard with its backup feature. I would also like to get a word count of all of the posts I've written, just because I'm curious. These things would be done best with an API, so that's what this post is going to explore.

Chess Book Face Off: Best Lessons of a Chess Coach Vs. Pandolfini's Endgame Course

In my recent efforts to continue to improve at chess, I've read through a couple more books on the subject. As always, I read books in pairs so that I can get multiple perspectives on a topic and learn it more thoroughly. Sometimes the books cover nearly the same material, and other times—like in this case—the books are only loosely related. The first book is Best Lessons of a Chess Coach by Sunil Weeramantry, a FIDE Master and highly successful chess coach. This book is the kind of book that explains a handful of games in intimate detail. The second book is Pandolfini's Endgame Course by Bruce Pandolfini, a USCF National Master and a more famous highly successful chess coach. Being a book about endgames, it does not go through full games, but contains an extensive collection of endgame positions to study. So both books were written by accomplished chess masters and coaches, meaning they have at least that in common.

VS.

Chess Book Face Off: The Development of Chess Style Vs. Chess Endings

I've been getting back into chess lately, after taking a break for a couple years, and to get back up to speed, I've been reading quite a few chess books. I thought it would be fun to review and compare some of them, which is why I explored how to add JavaScript chess boards to the blog in my last article. Now I'll put that new feature to use while discussing a couple of chess books I've read recently: The Development of Chess Style by Max Euwe and John Nunn and Chess Endings: Essential Knowledge by Yuri Averbakh. Both of these books are somewhat older, being written in 1997 and 1993, respectively. That doesn't mean they're obsolete, because plenty of good chess books are also classics. Chess as a game is still progressing and theory changes, but the fundamentals are solid. Besides, one of these books is more about the history of chess, so it's only downside to being older is that it doesn't include more current developments.

VS.

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.

Tech Book Face Off: Physics of the Impossible Vs. The Physics of Star Trek

It's been a while since I've done a Tech Book Face Off. The idea here is to review a couple of books together and compare and contrast their ways of explaining something I want to learn about. Sometimes both books are good, sometimes neither, but reading at least two books on a subject is a great way to get multiple perspectives on it. We learn different things from different teachers, so more than one point of view can be invaluable for learning about something deeply. In this Tech Book Face Off, I'm going more for future tech than modern tech—future tech in the nearly (or actually) science fiction sense. We have Physics of the Impossible: A Scientific Exploration into the World of Phasers, Force Fields, Teleportation, and Time Travel by Michio Kaku and The Physics of Star Trek by Lawrence M. Krauss to look at. Both books are as much popular physics books as they are books on technology, but they each take different approaches to exploring the ideas about the technology of the far future. They were also both a blast to read, with fascinating discussions about what could be possible and what is, as far as we know, quite impossible.

VS.

Learning What to Know or Knowing How to Learn

As I get older, I notice more and more that I am slowly forgetting. Things I once learned in high school or college are fading from memory. Hard-fought knowledge has since gone unused and languished into oblivion. This process is not entirely a bad thing, as some of that knowledge has never been useful since the last paper was written and the final exam was finished, and more heavily-used knowledge has taken its place. Learning and then forgetting all of that knowledge was not a total loss, either, because along the way I learned something else even more valuable: how to learn efficiently.

What do I Care if Polar Bears Die?

A friend of mine asked me this recently, and I couldn't be sure if he was genuinely curious or just trolling me. I didn't give him the greatest response, something along the lines of, "That question shows a general lack of systems thinking." Then the conversation moved on to other topics. I was caught off-guard by the question because the premise that someone wouldn't care about the survival of an entire species as iconic as the polar bear is well outside my normal lines of thought. I can't stop thinking about how poorly I answered the question, so it's time to dig in and get to the bottom of the matter.

Credit: Arturo de Frias Marques from Wikipedia

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.

Finding out if I've Improved as a Programmer: Part 3

I've been walking through one of my old college projects of a shell program in an effort to see how much I've improved as a programmer over the past however many years. So far this exercise has been pretty enlightening, and I hope to finish it up in this post. I've improved the formatting and added a better set of automated tests to the project, and I've made it part way through what originally was the only function in the simple shell program, main(), refactoring as I went. Now we're at the main loop of the program that reads in and executes the commands. I've tried to be as brutally honest as I can in assessing the faults of my old coding style, and I'll keep that up as we finish this out. Let's dive right in and see how to clean up the rest of the code. As before, you can follow along with my GitHub repo to see all of the refactorings in context.