JSON pretty from inside vim

One liner to be able to format JSON into a readable (pretty) format from inside Vim.

:%!python -m json.tool

Helping Apple with a missing button

Hi Apple,
It's ok, I get it... You're not trying to force Safari down our throats with the popup every couple days... it's just that you didn't have room to add "Don't ask me again" without ruining the aesthetic design.

I don't blame you, I mean look how nicely "Later" and "Try Now" fit together. I wouldn't want to add more options either.

Since Apple couldn't fit it in, here's how to fake the action of clicking on the missing "never ask me about switching to this beautifully designed browser" button. You'll have to open up terminal. Then type these three commands:

defaults write com.apple.coreservices.uiagent CSUIHasSafariBeenLaunched -bool YES
defaults write com.apple.coreservices.uiagent CSUIRecommendSafariNextNotificationDate -date 2020-01-01T00:00:00Z
defaults write com.apple.coreservices.uiagent CSUILastOSVersionWhereSafariRecommendationWasMade -float 10.99

That *should* take care of seeing the pop-up for the next few years...

updatedb on OSX

Mainly because I always forget, on OSX you can run the script the updates the locate db automatically, just run:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.locate.plist

(you only have to do it once)

Before you do, edit /System/Library/LaunchDaemons/com.apple.locate.plist Get rid of the following portion so that it runs daily instead of just once a week though.

                <key>Weekday</key>
                <integer>6</integer>

A refresher on what Java 7 brought...

Java 7 was released way back in 2011, but it's unfortunately not THAT uncommon for a large organization to get set in its ways (having found years ago, those battle-tested, magical, set of exact JVM tuning arguments that work for *their particular* application stack on a certain version of a 1.6 JVM) so that you don't get exposed to "newer" features. And to only get dragged kicking and screaming into JDK8 when Oracle deprecated certain versions.

So, what did Java 7 bring us? As developers, it seemed to be mostly about cleaning up syntax/getting rid of some of the boilerplate...

• Strings in switch statements - sure, other languages had it for years, but you weren't able to switch on Strings until Java 7. Nice to have, not especially mind-blowing.
• try with resources - This was a welcome addition - no longer did you have the super-awkward "declare your variable outside the block just so you have access to it in a second try/catch so you can close it..." e.g.

  Connection conn = null;
  try{
    conn = getConnectionFromSomewhere();
    // do work with the resource
  } catch (Exception e){
    // handle
  } finally {
    if (conn != null){
      try {
        conn.close();
      } catch (Exception someOtherExceptionYouProbablyIgnore) {
        // yah, you probably ignore this
      }
    }
  }
  

  Nope, now you can just do

  try(Connection conn = getConnectionFromSomewhere();){
    // do work with the resource
  } catch (Exception e) {
    // handle
  }

  You can also have your own objects work this way, look into java.lang.AutoClosable
• Multi-catch - Another nice little cleanup, rather than listing out all the exceptions you want to handle (even if you handle some of them the same), you can now use the | pipe operator to union the exceptions you are handling. Instead of this:

  } catch (IOException ex) {
       logger.log(ex);
       throw ex;
  } catch (SQLException ex) {
       logger.log(ex);
       throw ex;
  }

  write this:

  } catch (IOException|SQLException ex) {
      logger.log(ex);
      throw ex;
  }
  

• Binary literals - "0b" prefix, e.g. 0b10100111001 is 1337
• left-to-right Improved type inference (<>) Removed the necessity of writing tripe like:

  Map<String, List<Integer>> m = new HashMap<String, List<Integer>>();

  simplifying it slightly to:

  Map<String, List<Integer>> m = new HashMap<>();

  (This seems slightly backwards to me, we're essentially specifying the details on the interface and waving our hands over the concrete implementation, instead of

  Map<> m = new HashMap<String, List<Integer>>(); // does not work

  but I'm not the designer - you must use the first version =)
• Underscores in numeric literals What's easier to understand at a glance? Counting the zeros in 1000000000 or 1_000_000_000?
• A whole slew of new APIs for NIO - notably, java.nio.Path and the WatchService, which allows you to be notified of changes to a path you're watching (there are a ton of applications for this)

Those are the big ones in my opinion. Did I miss any of your favorites?

Changing default prefix keys for tmux

tmux uses Ctrl-b as the default command prefix, that's ok on Windows but less than desirable on a MacBook Pro. Turns out that it's super easy to remap to something easier to type, but it's a two-step process.

First, let's get some usage out of the vestigial 'caps lock' key. Go to 'System Preferences' -> 'Keyboard' -> 'Modifier Keys' and then change caps lock to do something (marginally more) useful, the Control key.

Now that that's out of the way, remap the prefix in tmux by editing (or creating) your ~/.tmux.conf file. We only need one line in there to remap the prefix to Ctrl-a (which are handily right next to each other):

set -g prefix C-a

Two things to note: first, changing the caps lock key to be control affects ALL applications on your Mac, if you're like me and never use caps lock, that's probably ok - just something to remember. Secondly, sometimes you might want to be able to send Ctrl-a to an application that you're using inside tmux. If you think you will, just add another line to your ~/.tmux.conf file:

bind C-a send-prefix

This will allow you to send Ctrl-a to the application running inside tmux by pressing it TWICE.

Compiling a Go app, that uses Cgo, to run on an Edison

[TLDR - Use a Docker container, install the 32-bit compiler chain and 32-bit dev libraries on the build machine, include the flags to enable CGO, set the target GOARCH, set ldflags to statically link]

So, originally I thought I'd be able to easily get my (trivial) Go app to cross-compile for the Edison (which is running a 32-bit linux variant) but I was quickly disabused of that notion. My app uses the `gopacket` library, which in turn uses C bindings (Cgo) to `libpcap-dev` to do the actual packet capture.

I had originally thought it was just a matter of adding "GOOS=linux GOARCH=386" to compile from my OSX box to target a 32-bit linux binary. It works fine for most apps, BUT it doesn't work for apps that are using Cgo. Ah, just forgot the "CGO_ENABLED=1" flag, right? Nope. That causes all sorts of different errors. Googling/Stack Overflow didn't really turn up anything helpful, but there's *probably* a way to do it. (there were a few projects out there, including gonative that seemed promising, but `gonative` only addresses Cgo-enabled versions of the stdlib packages, not if your project uses Cgo)

Rather than dig into the intricacies of cross-compiling on a Mac, I just pivoted to using a Docker container. I couldn't find an official Yocto linux container prebuilt, which is what the Edison runs, so I just went with a standard Ubuntu image.

root@ubuntu-docker-instance# go build listen.go 

Sweet, compiled. All set, that was easy. Let's just check the binary to make sure all is good with the world.

root@ubuntu-docker-instance# file listen
listen: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=11b30b279fd6580392e72bac70a5be034e12b2a7, not stripped

Oops, dynamically linked. Let's fix that by setting the correct ld flags, and check it again.

root@ubuntu-docker-instance# go build --ldflags '-extldflags "-static"' listen.go 
root@ubuntu-docker-instance# file listen
listen: ELF 64-bit LSB  executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=8a5a63b0151c2cef02399d091ea7339b2ca1d30b, not stripped

Ok, statically linked now but it's (still) 64-bit. The Edison is 32-bit, which means we'll have to fix that... should be cake, just use the "GOARCH" flag...

root@ubuntu-docker-instance/util# GOARCH=386 go build --ldflags '-extldflags "-static"' identify.go 
# command-line-arguments
./identify.go:19: undefined: pcap.FindAllDevs
./identify.go:23: undefined: pcap.OpenLive
./identify.go:23: undefined: pcap.BlockForever

What?! Oh, yes, need to tell the compiler about the Cgo code... (CGO_ENABLED=1)

root@ubuntu-docker-instance/util# GOARCH=386 CGO_ENABLED=1 go build --ldflags '-extldflags "-static"' identify.go 
# runtime/cgo
In file included from /usr/include/errno.h:28:0,
                 from /usr/local/go/src/runtime/cgo/cgo.go:50:
/usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory
 #  include 
                         ^
compilation terminated.

C'mon... now what? Some quick googling turns up the fact that you need the 32-bit gcc stuff, since the host architecture is 64-bit.

root@ubuntu-docker-instance/util# apt-get install libx32gcc-4.8-dev libc6-dev-i386

root@ubuntu-docker-instance/util# GOARCH=386 CGO_ENABLED=1 go build --ldflags '-extldflags "-static"' identify.go 
# github.com/google/gopacket/pcap
/usr/bin/ld: cannot find -lpcap
collect2: error: ld returned 1 exit status

Now what? Oh, although I have the 32-bit compiler chain, I DON'T have the 32-bit version of libpcap-dev. Let's fix that.

root@ubuntu-docker-instance/util# apt-get install libpcap-dev:i386
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package libpcap-dev:i386 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'libpcap-dev:i386' has no installation candidate

Huh? furious googling ensues... Ok, add the i386 architecture and try again...

root@ubuntu-docker-instance/util# sudo dpkg --add-architecture i386
root@ubuntu-docker-instance/util# sudo apt-get update
root@ubuntu-docker-instance/util# apt-get install libpcap0.8-dev:i386

NOW we're cooking with fire. Let's give it one more try...

root@ubuntu-docker-instance/util# GOARCH=386 CGO_ENABLED=1 go build --ldflags '-extldflags "-static"' identify.go 

Looks promising, it's a 32-bit statically compiled binary at this point. No obvious errors.

identify: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, not stripped

SCP the binary onto the Edison and test it...

root@edison:~# ./identify -inf=wlan0
2015/09/04 14:11:02 Starting up...
2015/09/04 14:11:03 Listening for ARP packets on en0 to identify dash button.
Press the dash button and watch the screen. You will want the 'Source MAC'
2015/09/04 14:11:09 ARP packet, Source MAC[74:75:48:a4:59:a8], Destination MAC[ff:ff:ff:ff:ff:ff]
2015/09/04 14:11:24 ARP packet, Source MAC[74:75:48:29:a8:7c], Destination MAC[ff:ff:ff:ff:ff:ff]

SUCCESS!!!

Playing with Amazon Dash buttons

Amazon is experimenting with wireless buttons (for $5 each) called Dash Buttons. The intended usage seem to be for Prime members to stick the button near a product that needs periodic refilling, e.g. laundry soap, so that when you're almost out of the product, you press the button and it (almost) magically reorders for you.

These buttons are nifty little pieces of technology, especially for $5. Someone has already figured out how to use them for something other their intended usage - read his post on Medium, it's very well written. He has source code in Python for accomplishing the hack.

I wanted to take a slightly different route to accomplishing the same type of thing. I have a bunch of hardware laying around that would be fun to play around with, including an Intel Edison board. I could write my code in Go, cross-compile it on my Mac, and just SCP it onto the Edison. Sounded like a fun evening or two, so that's what I did and threw it up on github.

Tested the code on OSX and it works. Attempted to compile it for Linux, so I can deploy it onto the Edison, and compilation fails...

$ GOOS=linux GOARCH=386 go build identify.go
# command-line-arguments
./identify.go:19: undefined: pcap.FindAllDevs
./identify.go:23: undefined: pcap.OpenLive
./identify.go:23: undefined: pcap.BlockForever

I'm pretty sure it uses CGO and there are some details about cross-compiling that I'll need to figure out... but that will be for another post.