Search This Blog

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.

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 Courseby 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.

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.

I've done a few of these BarelyAdequateGuides 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.

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.

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.

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.

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.

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.

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.

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.