Bringing the Internet to Mars and Beyond

With the exploration of space and the eventual colonization of Mars humanity needs to establish a method for improving internet connectivity for people on the surface.

One method of achieving this is to place one or more satellites in high orbit around the planet.  These would use interplanetary internet(delay tolerant) technology and protocols to service requests as well as actively mirror content for primary sites located on Earth.  The goal of this strategy is to reduce the latency of user requests from 8-48 minutes down to at most a few seconds for popular content.

What is needed for a single node:

  • High bandwidth communications equipment similar to what would have been on the Mars Telecommunications Orbiter.
  • A cluster of servers in an a spacecraft the the size of a supply module.  Something similar to Microsoft’s Project Natick would be about right for a first generation.  There would be a redundant capacity built in to cover eventual server failure.
  • A heat management system.
  • A nuclear power generation system.

Now we just need NASA, Microsoft, SpaceX, Amazon (w/Blue Origin) AWS – Mars, or Google to make it happen!

Posted by Chad Dotson in Doing Things Better, Neat Stuff, Space, Technology, 0 comments

You’re Too Close

Have you encountered the following scenario?

You are trying to solve a problem (or helping solve a problem) and know or at least think you know the solution.  You are in the middle of implementing it when someone else looks at it and says, “why don’t you do it this way, isn’t this way easier/better?”  Taking a step back, you realize that the question not only has merit but is a better and much more obvious solution; you can’t believe you missed it.

What happened?

I think its because you were too close to the problem and had developed a very narrow focus.  That narrow focus prevented you from seeing the better solution.  Perhaps this is even a variation of functional fixedness in that we’ve latched onto an idea of how to solve a problem and our mind’s may not see alternatives easily.

What can we do?

  • Think about the broad (or product) level goals regularly.
  • Entertain questions and/or suggestions from others.
  • Ask: “Is this the best way?”
  • Ask: “Is this the practical way?”
  • Don’t overthink the problem.
  • Get it working then evaluate the solution and/or do a code review!
Posted by Chad Dotson in Doing Things Better, Programming, Tips, 0 comments

Node.js vs Python vs PyPy – A Simple Performance Comparison – Updated


Some History

This is a followup to my original post: Node.js vs Python vs PyPy – A Simple Performance Comparison.  This article corrects a discrepancy caused by a slight difference in the JavaScript implementation which skewed the Node.js results.

The Algorithm

As stated in the previous article, I’ve attempted to implement the same single-thread, brute force, recursive algorithm in many different languages.  There is nothing overly special about this algorithm and I’ve made no attempts to optimize it.

The Findings

Node is fast, very fast.  It easily outperforms any of the other implementations I’ve included in the puzzle’s repository.  As you can see by the included charts, the performance difference between Node.js and out-of-the-box Python is very significant and the difference between it and PyPy while less pronounced is significant.

Special Notes

  • I’ve placed my source on GitHub at the following url:  It now contains functional N-Queens puzzle implementations in JavaScript, Python, Lua, Scala, and Ruby.  There is also a version in Rust, but that needs to be updated to the latest syntax before it can be run again.
  • This is just with one type of algorithm, the best solution might and probably does change depending on what type of application you are researching.  For webserver performance, Node.js is slightly better than PyPy running Tornado.
  • This algorithm is a simple brute force algorithm, there are many faster and better ones out there.
  • See the original article for the Node.js vs Python vs PyPy – A Simple Performance Comparison for more details memory performance.
Posted by Chad Dotson in Misc, Programming, Software Engineering, Technology, 5 comments

Comparing Node.js and Python on the Raspberry PI

Picture of my simple led circuit connected to the Pi.

Picture of my simple led circuit connected to the Pi.

Programming on the Raspberry Pi

Python seems to be the more popular language for writing programs on the Raspberry Pi.  However, it is far from the only language: Python, C, C++, Java, and Ruby are some that are automatically supported out of the box.  As it turns out Node.js is also supported.  Perhaps, just based on my preconceptions, I didn’t originally consider JavaScript when interfacing directly with hardware.  The goal of this article is to compare functionally equivalent sample programs written both in Python and JavaScript.


The Goal

I decided to make the scope of the problem created for this article as small as possible.  Given that the goal will be to create simple circuit diagram consisting of a LED and then to write a program that makes the LED flash for a specified period of time.


Simple LED circuit diagram

Simple LED circuit diagram


With the Pi, a circuit that will make a LED flash is relatively simple: Consisting of just a LED and resistor.  I arbitrarily selected pin 7 on the Pi for this build.  I’ve included a diagram of it on this page.



As the goal states, the following two implementations do nothing except toggle an LED at half the specified duration (0.5s) and automatically shutoff after 60 seconds.



Since Python is the more traditional programming language for the Raspberry Pi, let us start with it.  The Rpi.GPIO module I used can be installed via pip.  Before you read the code sample, let me point out some things about the implementation.  Could it have been done simpler given that the problem was just to make the LED flash for a certain amount of time?  Yes, but I wanted to create something of an asynchronous process that could be controlled from outside its execution context.



I used pi-gpio to interface with the GPIO on the Pi in JavaScript.  It can be installed via npm. It makes use of gpio-admin so that your script doesn’t have to run as sudo.  Follow the installation instructions provided here and it should get you setup.  Note that due to differences int the languages, it was not necessary to thread (web workers) the solution.


The Findings – I was surprised

When I started writing the JavaScript side of this article, I was mainly doing it to gain experience working with JavaScript on the Pi.  I did not expect to come out of it vastly preferring it over my python implementation.  I find the Python implementation above to be to wordy and overcomplicated.  It just seems that the amount of code needed to achieve the same results is excessive.  Perhaps this is because of the problem scope and implementation.  The problem posed here was a simple one, where a functional solution is superior to an object-oriented one.  Could the Python code above be rewritten into something a bit more functional? Sure!  Are there problems that an object-oriented Python or JavaScript implementation would be the better solution for?  Definitely.  The lesson to take away: be open to working outside your comfort zone and pick solutions to problems based on their fit for the problem not your comfort level with them.

I’ve created a copy of the code as a Gist that is available here:

Posted by Chad Dotson in Key Concepts, Programming, Raspberry Pi, Software Engineering, 8 comments

Project Excelsior – Technology Update


Current Project Excelsior Technology

For the past month or so I’ve been working on a little side project that I’ve dubbed “Project Excelsior.”  I’ve not had an abundance of time to spend on it over the past few week, so I’m just now wringing out some of the technology stack.  I’ve almost decided completely on the MEAN stack.  I’m close enough to a final decision that I’ve started prototyping the server side.  I’ve not worked with angular before, but I am familiar with ember and backbone.


Posted by Chad Dotson in Diversions, Programming, Software Engineering, Technology, 0 comments

No Comments – A Failure Twice

Everyone that writes code has encountered or written their fair share of undocumented code.

A failure twice?

I was encouraged to write this article because of something I read about the pinball game that once was included with windows.  According to the article on MSDN, the pinball game was removed due to a bug that should have been fixable.  However, the overall qualify of the code made repair impossible and the game was removed from the distribution.  Two major items can be taken from this:

  • Failure 1: The could should have been self-documenting / few comments required.
  • Failure 2: Code not easily understood should have been commented.

Properly commented code can be tricky!

In college they push you to comment your code while not stressing that over documentation is also bad.  I remember writing programs that had comments on almost every line for assignments.  In the end it doesn’t buy you anything, it just restates the obvious and clutters the solution.  In the workplace, comments and whether or not the code needs them are hit and miss.

Some notes about comments:

  • Many comments are an acknowledgement of your failure to communicate.  Write better self-documenting code.
  • Outdated or wrong comments are worse than no comments.
  • Consider refactoring code that’s not self-documenting.  I find one of the biggest places this can be done is extracting methods from if statements.
  • Choose a good, descriptive names.  I’m a little wordy in my names, but in the end most of my code can almost read like a sentence.


The code is your best documentation.  Think about what you want to communicate with it and how to be as clear as possible.

Posted by Chad Dotson in Doing Things Better, Programming, Software Engineering, Tips, 0 comments

Node.js vs Python vs PyPy – A Simple Performance Comparison


IMPORTANT NOTE: The NodeJS algorithm had a slight discrepancy in it.  See this article for a correction to the performance comparison section of this article.

The Algorithm

Yesterday, I decided to try translate my algorithm for calculating N-Queens to JavaScript.  I’ve implemented the same single-thread, brute force, recursive algorithm in many different languages with the biggest difference being the syntax of the language.  Once I completed the JavaScript Implementation, I ran the program with the latest version of Node.js.

The Findings

I knew Node was fast but it still surprised me.  As you can see by the included charts, the performance difference between Node.js and out-of-the-box Python is pretty significant.  Its not until the algorithms complexity and recursion depth hit certain limits that Node.js’s performance starts to falter.

Node.js and CPython – What’s The Difference?

You might ask what is behind this performance difference.  The answer is actually pretty simple.  It all boils down to how the code is being executed.  Node.js uses the V8 JavaScript Engine (Wikipedia | Google) written by Google and a part of the Chrome Browser.  V8 includes a just-in-time compiler that compiles the JavaScript to machine code before execution and then continuously optimizes the compiled code.  Python is a bytecode interpreter; meaning that the default interpreter (CPython) doesn’t execute Python scripts directly.  Instead, it first generates a intermediate file that will later be interpreted at runtime.

Ways To Get Better Performance

If you want to use Python, we can overcome the differences between Node.js and vanilla Python by using PyPy, an alternative implementation of Python that includes a just-in-time compiler.  For the algorithm I wrote, you can see a pretty good performance boost over Node.js when using PyPy.

Special Notes

  • I’ve placed my source on GitHub at the following url:
  • This is just with one type of algorithm, the best solution might and probably does change depending on what type of application you are researching.  For webserver performance, Node.js is slightly better than PyPy running Tornado.
  • This algorithm is a simple brute force algorithm, there are many faster and better ones out there.
  • At a board size of 15, Node.js could no longer run the algorithm due to its maximum recursion limit.

Edit – A Follow-Up

The original focus of this article was shear performance, but I’ve received a question regarding the memory footprint of the 3 methods.  I think that is a very good and valid question.  So, I reran the tests to capture the peak memory utilization by each.  For this test I used “/usr/bin/time -l” to capture the maximum resident set size.  While this isn’t exactly the peak amount of memory utilized by the algorithm, it is sufficiently close to report on.

New Findings

Upon rerunning the tests for capturing memory utilization, I found that for the most part memory utilization contrasts performance.  A higher memory utilization isn’t really unexpected, if you think about it.  Essentially, the jit is sacrificing memory for performance.  In most cases, this isn’t really that bad.  Using a jit is just a cheap way of boosting performance of code written in an interpreted language.  The boost in performance, speed of which it was written and the maintainability of it outweigh memory utilization concerns in many cases.

The Oddity

As you can see, I’ve included a chart covering all the solutions for boards 8×8 to 14×14.  During most increments in board size, the memory utilization seems to increase exponentially; however, when we hit the 14×14 board size we see all the cases level off at relatively the same memory utilization of around 300 MB.  At this time, I really don’t have a good answer for this.  I could certainly speculate, but I’d rather not until I know more.


Posted by Chad Dotson in Programming, Software Engineering, Technology, 28 comments

The Flood of Social Media Posts – Whats Wrong, How To Mitigate It, How To Fix It

What’s Wrong

Since its creation, social media has taken off at an exponential rate.  Each day more and more people are creating accounts and contributing to the feed.  Facebook is the service most readily adopted, mainly because of the people already on it.  In the case of Facebook, lets say that the typical user has 200-300 friends and lets say that just a quarter of those (50 of 200) are enthusiastic posters (2-3 posts/day).  That equates to somewhere north of at least 100 posts per day then add to that the posts from your other friends.  Lets make a guess of an overall total of 200 posts/day on just that one social media outlet.  Facebook’s solution to the inundation of posts is the top posts vs recent posts feature.

Skip to the services that I think are the most susceptible to inundating users with content: Twitter and Pinterest.  As a user of Twitter, it seems that I have trouble following over 40 people.  Once upon a time I followed near 90 people and found that useful posts actually got buried in the noise.  Pinterest on the other hand seems to violate all that is good with respect to UI design; it is way to busy and your eyes don’t follow any particular lines.  Liberal use of pinterest’s follow feature can unintentionally muddy the content you see.

Tips On Dealing With It

I think the only way to fix usage of Twitter is to limit the number of people you follow.  Pick high quality, low post rate users.  This will improve the overall quality of content you get.  For Pinterest, limit the number of users or boards you follow.

How To Fix It

How do you fix being inundated with content?  Facebook is certainly trying to fix it via their “Top Posts” feature.  The top posts feature attempts to make guesses about what you want to see based on your interests, what you’ve looked at in the past, and probably other metrics (and controversial stuff such as a recent study).  Even though I don’t care for their current top posts feature I believe Facebook is on the right track.  It all boils down to the ability to listen to everything but only pay attention to what your interested in, even when you may not 100% know yourself.

I think the ultimate “Top Posts” algorithm would take into account the following:

  • What you’ve looked at in the past. (Given)
  • Users would be given preferred tags based on what they view.
  • It would tag each post and each would receive an initial ranking based on the types of posts the user normally make.
  • The initial ranking score given to a user’s posts is a function of how well their posts have done in the past.
  • Each post’s rank is updated in each of its tags as people view them based on their rank in the tag category.

Up Next: I may decide to make a post discussing a theory of how people leave one service and adopt another.

Posted by Chad Dotson in Misc, Ramblings, Tips, 0 comments