Search This Blog

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.

Polar bear jumping on fast ice
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.

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

I've been looking into whether or not I've improved as a programmer by dusting off an old shell program I wrote for a college course and seeing if I can make it any better. The exercise has been eye-opening so far. I really have come a long way on my programmer's journey, with much longer to go, I'm sure. To quickly recap, all of the refactorings I'm doing are going up on my GitHub repo so you can follow along with the changes, and I identified these general issues with the code:
  • It doesn't compile
  • Minimal tests
  • Inconsistent indenting and formatting
  • One long function in main()
  • Poor structure and organization
  • Major memory management issues
In the first article, I tackled the first three items, so I now have the last three—breaking up main(), giving the program better structure, and improving memory management—to address before I'll be happy with the revision. Let's jump right in, shall we?