Three Twists

A brand new year, and my will to code is making a comeback already.

Better Tracebacks in Automator

It’s as good a time as any to empty out all the cameras, phones and whatnot and consolidate the files and movies of the season, so I dug out my photo scripts again and went at it.

There were a few glitches during automated filing to a missing folder, but I remembered something I read once about a better way to capture Python script tracebacks when running inside Automator and decided to track it down and make a note here.

In short, use this as a basis for your “Run Shell Script” actions with Python:

import os, sys, traceback
try:
  # do stuff

except:
  traceback.print_exc(file=sys.stdout)
  exit(0)

This will dump the full traceback to stdout instead of stderr so that you can capture it in a “View Results” step instead of having to divine what went wrong from the Automator log, which rather unhelpfully only displays a single line reading Traceback (most recent call last):

Now all I need is sort through a thousand photos and pick the keepers – that I can’t really automate yet…

In other news, I’m getting into the habit of doing katas.

Last week it was doing raw HTTP requests in unfamiliar programming languages (started blissfully with three ways to do so in Clojure, decided to use ClojureScript in node and promptly got stuck, never managed to get to Haskell¹ or Scala).

As a curiosity, here’s how I hacked it in wisp atop node:

(ns requests)
; basic HTTP request in nodejs using wisp

(def http (require "http"))

(defn prep-request
  ; naive split, ignoring port numbers
  [url]
  (let [bits    (.split url "/")
        schema  (get bits 0)
        host    (get bits 2)
        path    (.join (.slice bits 3) "/")
        options {:host host
                 :schema schema
                 :path path}]
    options))

(defn do-request
  ; perform the actual request, ignoring the schema
  [url cb]
  (let [buffer ""
        req    (http.get (prep-request url))]
       (.on req "response" 
            (fn [res]
                (.on res "data" #(set! buffer (+ buffer %)))
                (.on res "end" (fn [] (cb buffer)))))
       (.end req)))
        
(defn do-output [buffer]
  (print buffer))

(do-request "http://www.google.com/test" do-output)

Not very elegant given the way raw node works, but definitely nicer in LISP form, even considering I held back on the trickery.

Next up I was going to do LISP macros in a few variants, but it was hard to come up with common ground and I’m not in the right mindset yet – the Force is murky these days.

So I decided to go for front-end development (which I hardly ever do by myself these days). One of my teams is using Angular very heavily while another is extending Ink with Knockout (which I used a fair bit during Summer) and I’ve been mulling the available options without liking either much.

Given all the hoopla about React in the past few days, I decided to give it a go, but with a twist – given my preference for minimalist, battle-tested solutions and fundamentals, I’m going to start out with an “old school” jQuery-based app (by way of Riot, which tacks on an interesting observer pattern and makes heavy use of events), and then I’m going to port it to React (maybe with a detour or two along the way).

That should give me enough data points for an informed comparison. I’m now doing some (mostly) raw, unfettered JavaScript that would ordinarily be anathema to the hipster crowd, and having a fair amount of fun.

Instead of the rather pointless MVC demos, I decided to tackle a different problem that has been bugging me of late – lighweight information displays. In short, I picked up a Python port of Dashing, hacked all the hipster tech out of it (SASS, CoffeeScript, etc.), and am building things up from there.

With luck, I’ll end up with a minimal dashboard solution that can work well² on a Raspberry Pi.