Friday, June 22, 2018

Developing in GitHub using Cloud Shell

If you're not familiar with Google Cloud Shell, it's a great tool for doing command line development in a Linux environment. I've been using it as an always-on development environment for web focused projects. Whichever machine I happen to be using, my dev environment is always available.

One of the ways I'm using Cloud Shell is as a development environment for my open source projects. Cloud Shell comes with loads of developer tools pre-installed, including git which is quite handy if you are hosting projects on Github. Head over to to start using Cloud Shell.

Here's how you can set up your own open source development environment with Github in Cloud Shell, in three easy steps!

Set up your git environment

First, you'll need to have the git client available. Easy, git is already installed (yay!)

Next, set up your git environment with the email address and name that your changes will be published under:

git config --global "YOUR NAME"
git config --global "YOUR EMAIL ADDRESS"

If you are using two factor auth for your GitHub account, you'll need to generate an access token. Once created, you'll use the hexidecimal string instead of your GitHub account password. For example, the generate password might look something like


Clone a repo from GitHub to Cloud Shell

With command line credentials in hand, you can now clone the repository from GitHub into your Cloud Shell environment to start making changes. Step three!

For example:

git clone

Now the files are available in your local Cloud Shell environment and you can change them to your heart's content. There is a simple text editor available in Cloud Shell which you can launch from the command line with a command like

cd jsBytes

Commit and publish your changes

After editing a file or two, commit your changes to your local repository and then publish them on GitHub. Remember that when prompted for the password, use the access token you generated earlier instead of your GitHub password.

git status
git commit -a -m 'Add one usage example to README.'
git push origin master

There you have it, an easy way to work on your GitHub project using Google Cloud Shell as your development environment.

Friday, February 24, 2017

Arduino Programming in ChromeOS

Are you ready to turn your Chromebook into a lean mean Arduino programming machine? No? Maybe? Great!

I've recently gotten into microcontroller programming, chasing dreams of electric guitar fueled audio bliss. Several microcontrollers have played the role of distortion effects prototype, and I haven't settled on one yet, but I can say the easiest I've found to use so far are the ones produced by Arduino. In fact, you can set up a Chromebook as development environment for programming an Arduino.

Here are the steps you'll need complete this amazing Chromebook transformation. Note that there are some risks in tweaking the setup of your machine.

First you'll need to enter developer mode, hold down escape and refresh while pressing the power button. Then on the warning boot screen, press ctrl+d.

Then, install Crouton. Here's a helpful download link:

Then run Crouton setup by entering the terminal, which is done by hitting ctrl+alt+t then run shell (type shell followed by enter). I ran my setup like this: sudo sh ~/Downloads/crouton -r trusty -t xfce.

To run once installed, use sudo startxfce4

From time to time, as Chrome OS is updated, it may be necessary to update the Crouton installation. I've updated by running sudo sh ~/Downloads/crouton -r trusty -t xfce -u

Now its time to get the development environment for Arduino. There are some helpful instructions here:

I've set up a couple of Chromebooks with the Arduino dev environment and as time has gone on, the approach has changed a bit. In my first setup, I did the following to install it:
sudo apt-get update && sudo apt-get install arduino arduino-core 
I then tried running arduino as root (sudo ./arduino ), but had the following error:

error while loading shared libraries: cannot open shared object file: No such file or directory

Ah, there was a missing dependency, which I was able to install as follows:

sudo apt-get install libncurses5-dev

In a later version of Arduino's software, I got the following after downloading the Arduino IDE and running sudo ./install then sudo ./arduino:

Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/.../arduino-1.6.13/java/lib/i386/ cannot open shared object file: No such file or directory

I resolved a sequence of errors by installing the following
sudo apt-get install libX11-6:i386
sudo apt install libxext6:i386
sudo apt-get install libxrender1:i386
sudo apt-get install libXtst6:i386
sudo apt-get install libXi6:i386
sudo apt-get install libstdc++6:i386

I also edited the audino file, which is an executable script, and removed the reference to GTKLookAndFeel. This allowed me to run the Arduino IDE without having to replace my installation of Java.

From there I've been able to compile programs and upload them to the Arduino to my hearts content. Happy coding!

Wednesday, July 22, 2015

Teaching Kids to Program - Part 1

This summer, I've been teaching my two oldest kids to program. They're ages sever and four and a half so I'm tailoring our lessons to what I imagine they can grasp in what can be a very abstract field of study. I've been super impressed with what they've learned so far!

The first challenge was thinking how to make programming interesting and compelling. Something too abstract feels like it would be challenging, there needs to be immediate feedback. Type this in, see what changes on the screen. How about we set out to make a game? That was one of the first pursuits that got me into programming in my teenage years.

The second consideration was balancing simplicity and ease of use. When programming, I always felt more confident when I could understand at a pretty low level what was going on. For this reason I wanted to make sure they gained an understanding of the fundamentals. We'd start with a view of a computer as a very simple machine. Even if this means there is some extra coding needed to get the desired effect on the screen. It's better (IMHO) to add abstractions later once they have an underlying understanding than to try to understand a powerful but complicated library that initially gets quick results.

I'm planning to post what we covered each week. We spend 30-60 minutes in a once a week session though some weeks we're taking off. It is summer after all!

Here's what we covered in our first lesson.

1. You can tell a computer what to do!

We opened up the terminal and I told them to type

print "Hello [name]"

Here it is, immediate feedback with the simplest possible "program." To get this working, I added a bash alias print=echo. Seems like print is a more common name across programming languages for "write something to stdout."

This went over pretty well, both kids typed some things.

Time to introduce some programming concepts. I explained that this was calling a function named print. The print function writes out whatever you tell it to write. I hope purist will forgive my painting with a broad brush.

Next I explained that the words that you give to the function to put on the screen are an argument, er, well, a parameter. The looks on their faces when I called these arguments made it pretty clear that they were thinking of what transpires out in the sandbox.

So here we'd covered the main ideas I wanted to teach them in the first lesson. You can tell a computer what to do! The "what to do" is specified using a function and the parameters that you pass to the function to tell it what or how you want things done.

Time for more fun.

Our four and a half year old can read basic words, but I imagined typing and reading might get tedious pretty fast. So next we turned to something just as simple that doesn't require reading from the screen, and not surprisingly was quite a bit of fun: the Mac say program.

If you've never played with this, in the Mac terminal there is command "say" which works like echo except it speaks whatever you give it in a computerized voice. We started with

say "Hello [name]"

Great fun! From there I asked them what parameters we should give the say function next. This filled the rest of our time. By far the biggest hit was say "[Baby's name] are you pooping?"

Yup, teaching kids to program.

Wednesday, May 15, 2013

Easy Raspberry Pi Setup (Using Windows)

So there I was, new Raspberry Pi in hand. Now to set it up. One small setback, I don't exactly have a monitor, keyboard, and mouse handy. How did I end up with so many laptops?

Turns out setting it up and getting to a command line was a breeze, no monitor (etc.) required. All it took was an Ethernet cable and my router.

Here's what I did.

First, I wrote the operating system disk image to an SD card using the instructions on the Raspberry Pi Quick Start Guide.
  • Downloaded the latest image from
  • Extracted it and found the .img file
  • Installed Win 32 Disk Imager
  • Plugged in the SD card
  • Used the disk imager to write the .img file to the drive for the SD card
Second, I started up the Raspberry Pi to connect to it.

I plugged the Raspberry Pi into the router using that Ethernet cable, then powered it up!

The next step will depend on your router but some routers will show you a list of the devices that are connected to the network from the admin screen. Here's an example

Armed with the IP address, you can ssh into the Raspberry Pi machine. (I used PuTTY.)

There you have it. From the command line you can configure whatever else is needed and you'll never have to scrounge up one of those pesky keyboards.

Thursday, July 19, 2012

waitFor JavaScript

In the spirit of building the simplest thing that could possibly work, I revisit the concept in another of my posts: simple asynchronous JavaScript.

Time and time again I see web developers relying on the order that JavaScript loads in a page to ensure that the site will work. This keeps the mental model simple, "all the stuff above this code will be available here", but it means that people trying to speed up browsers and JavaScript interpreters have their hands tied. Why not instead load and execute as much JavaScript in parallel as possible, like a mutlithreaded application, and wait for your dependencies to load or preconditions to be met before your code runs.

You could do it all in just a few lines:

function waitFor(condition, callback) {
  function waiter(condition, callback) {
    return function() {
      var condMet = false;
      try {
        condMet = condition();
      } catch (e) {}

      if (condMet) {
      } else {
        setTimeout(waiter(condition, callback), 5);

  waiter(condition, callback)();

Using it looks a bit like this

  // condition
  function() {return window.dependency;},
  // callback
  function() {
    // do things using dependency.

For example, here's how you might set this up to check if jQuery has been loaded and that a particular element on the page has been loaded in the DOM.

waitFor(function() {return $('#msgid');}, function() {
    $('#msgid').html('jQuery says "hi"!');

Now it doesn't matter what order your script tags are in. Of course, you'll get the best performance if jQuery gets loaded before this waitFor call is made. The wait and retry loop adds some cost. If browsers had an event model available for script loading or conditions then we wouldn't have to poll using setTimeout/Interval. But for existing browsers all the way back to IE 6, this simple helper function will work.

For managing JavaScript dependencies there's also require.js which does quite a bit more (and is larger). I wrote this to be lighter weight and it is more general and flexible than a framework like require.js. Using waitFor, you could set up logic that is triggered if and when certain arbitrary conditions become true.

One little improvement, if you are waiting for lots of things then you would probably want to replace multiple timers with a single timer that will check all conditions. Like this:

function waitFor(condition, callback) {
  waitFor.waitingFor.push([condition, callback]);

waitFor.waitingFor = [];

waitFor.check = function() {
  var stillWaitingFor = [];
  for (var i = 0; i < waitFor.waitingFor.length; i++) {
    var condMet = false;
    try {
      condMet = waitFor.waitingFor[i][0]();
    } catch (e) {}
    if (condMet) {
    } else {

  waitFor.waitingFor = stillWaitingFor;
  if (stillWaitingFor.length > 0) {
    setTimeout(waitFor.check, 5);

Here's a minified version. I added some newlines for formatting which you can take out.

function w(c,b){w.w.push([c,b]);w.c()}
w.w=[];w.c=function(){for(var s=[],b=0;b<w.w.length;b++)
{var d=!1;try{d=w.w[b][0]()}catch(e){}
if(d)w.w[b][1]();else s.push(w.w[b])}w.w=s;0<s.length
&&setTimeout(w.c,5)};var waitFor=w;

Happy coding!

Friday, May 11, 2012

JavaScript Caching: appendChild vs document.write

I found myself trying to prefetch some data which would appear in an iframe. I wanted to see if requesting the same JSON in the parent page and then in the iframe would cause the second request, made in the iframe, to hit the browser's cache in all cases. It turns out that for Internet Explorer and Web Kit based browsers it depends on how you request the JSON in the parent page.

If you use appendChild in IE the identical JS request will hit the browser cache.
If you use document.write in IE it will not hit the cache.

However, in Chrome and Safari if you appendChild in the parent, you will miss the cache. Using document.write in the parent page causes a cache hit.

Here are the results I gathered.
Cache Hit? both document.write parent document.write
iframe appendChild
parent appendChild
iframe document.write
both appendChild
Internet Explorer miss miss hit hit
Firefox hit hit hit hit
Chrome hit hit miss miss
Safari hit hit miss miss
Opera hit hit hit hit
Android ? ? ? ?
iOS ? ? ? ?

All versions of IE behaved the same, I didn't check different versions of the other browsers.

To test this I wrote a test web application called json-caching-exploration. It's a simple web app that runs on App Engine.

Server and HTML

I haven't run this against mobile browsers yet. If you give it a try please let me know what you find.

It's a shame that these browsers behave differently, especially given the differences in browser behavior between loading JavaScript using document.write and appendChild.

Saturday, May 28, 2011

Go on App Engine Example - Part 1

The App Engine team recently announced support for Go as a runtime for use in apps. Summary up front, the App Engine SDK for the Go runtime is the easiest way I've found yet to get started with Go. As I change my code, it is recompiled in the background when I make a request to my app, so it feels very much like developing in a scripting language.

I've been excited about the Go language for some time now (specifics on why will have to wait for another post) so I was eager to try it out in one of my favorite platforms: App Engine. I wanted to start with something small, so I wrote a simplified version of a web app that I've been itching to write lately, a site for hosting plain text content. Specifically, I want something that preserves whitespace, allows me to line up columns of text, and supports non-English characters (Unicode). Those are the kinds of things I need to share and talk about code. Also there is a great deal more you can do with plain old monospaced text, maybe you'll find this useful as well.

With that objective in mind I give you the Plain Text Machine. This little app lets you enter a small amount of text, somewhere around 2,000 characters, and gives you a link that others can visit to see an HTML reproduction of your writing. I mentioned I wanted to keep this simple, so here's the odd little bit, this app doesn't store your text anywhere. The URL that is generated contains the text, hence the somewhat low limit on message length. It certainly keeps the app simple, the most complex logic is that which converts the text from the URL into HTML.

A request starts by hitting the Init function:
func init() {
http.HandleFunc("/", handle)
http.HandleFunc("/show", show)
The main page, at /, is just static content, we're just interested in the /show handler. It looks like this:
func show(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "text/html; charset=utf-8")
// Get the message from the URL.
PrintHtml(utf8.NewString(r.FormValue("msg")), w)
The above does two things, sets the content type of our response so that the browser will know it is HTML, and reads the message URL parameter from the request to convert it to HTML.

The PrintHtml method prints out some boilerplate HTML then reads the message one character at a time and converts each character to its HTML-safe equivalent. There's a tiny bit of complexity to make sure that the whitespace is preserved instead of being collapsed as would normally be done with repeated spaces in HTML. Here's the code:
func PrintHtml(text *utf8.String, out http.ResponseWriter) {
spaces := false

fmt.Fprint(out, textHeader, middle)
for i := 0; i < text.RuneCount(); i++ {
currentChar := text.At(i)

if currentChar == 32 && !spaces {
// A first space.
fmt.Fprint(out, " ")
spaces = true
} else {
if currentChar == 32 {
// Space following another space
fmt.Fprint(out, "&nbsp;")
} else if currentChar == 10 {
// Newline
fmt.Fprint(out, "<br>")
} else if currentChar == 9 {
// Tab
fmt.Fprint(out, "&nbsp;&nbsp;&nbsp; ")
} else if currentChar == 38 {
// &
fmt.Fprint(out, "&amp;")
} else if currentChar == 60 {
// <
fmt.Fprint(out, "&lt;")
} else if currentChar == 62 {
// >
fmt.Fprint(out, "&gt;")
} else if currentChar < 31 || currentChar == 128 {
// Skip control characters.
} else if currentChar < 127 {
fmt.Fprintf(out, "%c", currentChar)
} else {
fmt.Fprintf(out, "&#%d;", text.At(i))
spaces = false
fmt.Fprint(out, footer)
The textHeader, middle, and footer variables are string constants containing the wrapper HTML which gives style information.

If you're interested in the full source code for this tiny little app, you can find it in the Plain Text Machine open source project. Hopefully this example provides an easy to understand picture of what Go code for App Engine looks like.

I had quite a bit of fun putting together this app. By keeping it simple I was able to go from idea to done in less time than it took me to write this blog post. As an added bonus, having an app with no persistent storage brings up some interesting philosophical questions. For example, if a message is created but no one stores the link to it, does it still exist?