Technology

Feb

2016

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!

Dec

2015

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!

Dec

2014

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: https://github.com/chaddotson/puzzles. 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.

Aug

2014