Technology

Feb

2016

Raspberry Pi 7″ Touchscreen Unboxing and Thoughts

This week I ordered and received the official Raspberry 7″ touchscreen ($60). I’ve been tinkering with some ideas for it (some car based projects) and wanted it on hand to try out.

Opening the Box

: Excellently packaged 7″ touch display

: Standard safety guide in many languages.

: 4 Screws, DSI Cable, and Jumpers.

: The screen in anti-static container.

The screen is packaged and presented really well. It comes with all that you need to connect and power it from the Pi itself. It comes with 4 screws to mount the Pi, the ribbon cable to connect it to the Pi’s DSI port, and 4 jumper wires, 2 of which are for powering the display on the Raspberry Pi 2 B+. The other 2 are used when attaching the display to an older model A or B.

The Screen Itself

: The touchscreen

: The controller for the display.

The screen itself seems really well made, I’m really impressed by it. The LCD side seems pretty sturdy and the backside seems better than I would have expected. Mine has a little give around the are the ribbons from the control board enter the LCD itself, but its nothing to complain about.

Connecting It All

: The controller for the display.

: The Raspberry Pi mounted to the screen.

In this case with the Raspberry Pi 2 B+, the screen connects easily via DSI ribbon and 2 jumpers to 5V and ground. Once wired its an easy job to mount the Pi onto the screen. In these pics you also see my cheap wifi and old keyboard dongle. I think I will want to buy a good Bluetooth adapter and keyboard shortly. I found a really need looking one here: http://www.amazon.com/gp/product/B00BX0YKX4.

Up and Running

: Raspbian booted up to console.

: Raspbian GUI up and running.

Once all connected, the Pi boots right up to the console. At this point you need the external keyboard to actually login and run startx, unless you’ve already configured Raspbian to do so. You will also need to install a virtual keyboard like Florence or Matchbox.

Using It

The biggest shortcoming is the need for a physical keyboard, like I mentioned in the preceding section, and it is probably the biggest drawback. The out of the box touch features seems only to augment physical keyboard functionality. That’s because unlike Android or iOS, the virtual keyboard isn’t dynamic, it is either always there or not. I suppose that a custom interface would be more touch oriented. The one oddity I have found is that counter to other touch screens, the hotspot for a touch seems off and to me it seems more exaggerated near the edges of the screen. It’s not a show stopper, but takes some getting used to.

Overall Opinion

After getting it all hooked up, I found that it seems a bit clunky. It left me wondering if a better solution isn’t just a raspberry pi running as a server and using a Android or iOS device as a head. However, assuming you stick with the Raspberry driving its own display, a longer cable might be desirable, depending on your project. In that case a regular HDMI touchscreen with usb connections might be the better fit.

The lack of good cases is also a problem. Nothing I have found yet, fully encloses the pi and the display. Coincidentally, I had an old project box laying around that seems to fit almost perfectly. At 7.5″ x 4.3″, the Hammond 1591ESBK‘s dimensions are only a little shy of the actual dimensions of the displays bezel (less than 0.25″). I’ll post new photos if / when I do that.

Other Resources:

Official Announcement – https://www.raspberrypi.org/blog/the-eagerly-awaited-raspberry-pi-display/
Buying the display: http://www.mcmelectronics.com/product/RASPBERRY-PI-RASPBERRYPI-DISPLAY-/83-16872
Pimoroni’s FAQ – http://forums.pimoroni.com/t/official-7-raspberry-pi-touch-screen-faq/959

: Excellently packaged 7″ touch display

: Standard safety guide in many languages.

: 4 Screws, DSI Cable, and Jumpers.

: The screen in anti-static container.

: The touchscreen

: The controller for the display.

: The Raspberry Pi mounted to the screen.

: Raspbian booted up to console.

: Raspbian GUI up and running.

: Hammond project box that seems to fit the Raspberry Pi display almost perfectly.

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!

Nov

2015

Python Logging – Best Practices

The python logging module offers a wide variety of logging options and handlers. One thing missing from the documentation is when to use each level.

A quick foreword

You really should familiarize yourself with the logging package. How to create new loggers (I find creating them by module very useful). There are many ways to configure logging, I tend to like dictConfig from logging.config (but start off with basicConfig form logging).

A Word on Optimal Setups

I prefer to setup my logging with each module having its own logger. This allows me to configure logging levels at a package and/or module level. I typically do the following in each module to create a logger.

from logging import getLogger
...
logger = getLogger(__name__)
...

from logging import getLogger

...

logger = getLogger(__name__)

...

Assuming my package structure consists of the following:

– foo (package)
—– core (module)
—– bar (module)

We can configure varying levels of logging for each element, as seen in the following snippet from a dictConfig.

...
'loggers': { 
    '': { 
        'handlers': ['default'],
        'level': 'INFO',
        'propagate': True
    },
    'foo': { 
        'handlers': ['default'],
        'level': 'WARNING',
        'propagate': True
    },
    'foo.bar': { 
        'handlers': ['default'],
        'level': 'DEBUG',
        'propagate': True
    },
}
...

...

'loggers': {

'': {

'handlers': ['default'],

'level': 'INFO',

'propagate': True

'foo': {

'handlers': ['default'],

'level': 'WARNING',

'propagate': True

'foo.bar': {

'handlers': ['default'],

'level': 'DEBUG',

'propagate': True

}

...

In this example, the root ( ” ) logger (those not configured by any other settings) reports INFO level and up messages. With the exception of the bar module, the foo package only reports WARNING level and up messages. The bar module is set to a more verbose DEBUG level, to show information needed for debugging.

Selecting A Log Message Level

Out of the box, there are six default logging levels recognized by the logging module, most are self-explanatory. I’ll just make some notes about usage. (From here on out, I’ll refer to my logging instance as logger.)

For general status messages, you should use logger.info (INFO). For errors, use either logger.critical (CRITICAL) or logger.error (ERROR). For all exceptions, use logger.exception (ERROR). logger.exception will automatically include stack trace information about the exception for you in the log. When you want verbose debugging information, use logging.debug (DEBUG)

In Closing

Use the logging module instead of print statements.
Always use logger.exception for logging exceptions.
Favor logger.debug for verbose log statements.
Favor logger.info for most other log statements (with the exception of errors).
Don’t forget that each of the logging functions uses C-style formatting.

Oct

2015

Creating Web Workers From Functions (No File Needed)

So, you want to create a web worker from a function, the problem is all the examples examples show creating a web worker using a separate JavaScript file or from embedded JavaScript source. There is a way to do it and that is using Blob URLs. In the example below, I have taken the simple dedicated worker example from mdn and modified it appropriately.

First, we assume that we have a function that we want to serve as the source of the web worker.

var workerScript = function () {
    console.log("starting worker");

    this.onmessage = function(e) {
        console.log('Message received from main script');
        var workerResult = 'Result: ' + (e.data[0] * e.data[1]);
        console.log('Posting message back to main script');
        postMessage(workerResult);
    }
}

var workerScript = function () {

console.log("starting worker");

this.onmessage = function(e) {

console.log('Message received from main script');

var workerResult = 'Result: ' + (e.data[0] * e.data[1]);

console.log('Posting message back to main script');

postMessage(workerResult);

}

Next, we use that function’s source to create the web worker.

// Get the source of the function we want to use and make the source
// where it will be interpreted as an iife.
var workerScriptIifeSource = workerScript.toSource() + "()";

// Create a blob of the script source, specify it as JavaScript.
var workerScriptBlob = new Blob([workerScriptIifeSource],
    {type: 'application/javascript'});

// Create a worker by creating a url from the blob.
var myWorker = new Worker(window.URL.createObjectURL(workerScriptBlob));

// Get the source of the function we want to use and make the source

// where it will be interpreted as an iife.

var workerScriptIifeSource = workerScript.toSource() + "()";

// Create a blob of the script source, specify it as JavaScript.

var workerScriptBlob = new Blob([workerScriptIifeSource],

{type: 'application/javascript'});

// Create a worker by creating a url from the blob.

var myWorker = new Worker(window.URL.createObjectURL(workerScriptBlob));

See this example in action on jsfiddle here: http://jsfiddle.net/chaddotson/jr5p3L7r/

Notes:

The createObjectURL function is experimental according to MDN, so that is a bit of a warning bell. However, according to caniuse, it is mostly safe across all browsers.
This can be used to create shared web workers, but they will not be shareable between tabs or windows.
This makes it more difficult, but possible to assemble dependencies for the web worker.
This isn’t the officially supported way to create a web worker.
I think this approach to creating a worker should be used sparingly, if ever.

Oct

2015

Creating Downloadable CSV (Or Any Other) Files In Browser With JavaScript

Many of us have wanted to create downloadable content straight from the browser. I remember several years back where it was more difficult and the solutions were not clean. Today, it is much much more simple and clean. Enter Blob URLs.

In this example, I have an object of arrays. These arrays may or may not all be the same length. The csvify function accounts for this by letting the user optionally specify a default value and whether or not the pad at the beginning or at the end for arrays that aren’t the same size as the max.

It’s what comes after the csvify function that allows all this to work. To make this csvified data downloadable, I first create a blob. This blob contains the csv data and is created with the csv mime type. I then create a url from that blob using createObjectURL and set that url as the href attribute on the download link.

Links:

jsfiddle

Sep

2015

“On The Job Training” vs “On The Job Learning”

A career in programming consists more of “on the job learning” than “on the job training.”

Training

Training as something someone else teaches you to do. There may or may not be any real expectation of advancing the concepts covered in the training. The analogy would be that if you work in a sprocket factory, you are not taught about the design of the sprocket nor any concepts behind the design of sprockets, you are taught how to make sprockets given direction. Training is limited, it can only take you so far in a programming career.

Learning

Learning is progressive and continual and a critical necessity for a career in programming. You should spend lots of time learning concepts, principles, and techniques. Then you should attempt apply and further those ideas. A good programmer is always learning from their experiences and asking, “How can I do this better?,” “Have I clearly communicated my intentions?,” and “Did I do a good job?” Will you ever find that you have done a bad job or written crappy code, most certainly! I think that realization is a sign of progress.

TLDR; Be a good programmer, don’t stop learning.

Aug

2015

Installing Technical Analysis Library for Python

I’m tinkering with some financial analysis scripts so when I got to looking into some useful python packages, Technical Anaysis Library popped up. The python bindings require the TA Lib (Technical Analysis Library) which on osx is available via homebrew. Now, when I originally installed I didn’t want to install it globally so I’ve got the less preferred, local install setup. This local install results in the following necessary commands to get the pip package to install correctly.

# Activate homebrew
export PATH=~/homebrew/bin/:$PATH

# install TA-lib
brew install TA-lib

# set C_INCLUDE_PATH
export C_INCLUDE_PATH=~/homebrew/include/:$C_INCLUDE_PATH

# set LIBRARY_PATH
export LIBRARY_PATH=~/homebrew/lib/:$LIBRARY_PATH

# Activate homebrew

export PATH=~/homebrew/bin/:$PATH

# install TA-lib

brew install TA-lib

# set C_INCLUDE_PATH

export C_INCLUDE_PATH=~/homebrew/include/:$C_INCLUDE_PATH

# set LIBRARY_PATH

export LIBRARY_PATH=~/homebrew/lib/:$LIBRARY_PATH

Now that I’ve brew installed TA Lib and set the new include and library path, I can install the python bindings via pip.

# make virtualenv using virtualenv wrapper.
mkvirtualenv financial

pip install numpy
pip install TA-Lib

# make virtualenv using virtualenv wrapper.

mkvirtualenv financial

pip install numpy

pip install TA-Lib