Search This Blog

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.

Physics of the Impossible front coverVS.The Physics of Star Trek front cover

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.