…about maps, open data, Git, and other tech.
National Map is a pretty awesome place to find geospatial open data from all levels of Australian government. (Disclaimer: I work on it at NICTA). But thanks to some not-so-obvious features in TerriaJS, the software that drives it, you can actually create and share your own private version with your own map layers – without programming, and without deploying any code.
What you get:
Want to create your own spatial layer – polygons, lines and points? Use geojson.io and choose Save > Gist to save the result to Github Gist. (Gist is just a convenient service that stores text on the web for free).
How about a layer of data about suburbs by postcode? Create a Google Sheet that follows the csv-au-geo specification (it’s easy!), download as CSV, paste it into a fresh Gist.
Using the new TerriaJS Data Source Editor (I made this!), create your new catalog. You’re basically writing a JSON file but using a web form (thanks json-editor!) to do it.
To add one of your datasources on Gist, make sure you link to the Raw view of the page:
Don’t forget to select the type for each file: GeoJSON, CSV, etc.
You might want to bring in some other data sources that you found on National Map. This can be a little tricky – there’s a lot of complexity in accessing data sources that National Map hides for you.
But here’s roughly how to go about it for a WMS (web map service) data source.
In the layer’s info window, grab the WMS URL
You’ll need to put “http://nationalmap.gov.au/proxy/” in front of a some layers, because their WMS servers don’t support CORS.
You’ll also need the value of the “Layer name” field. (For Esri layers you need to dig a bit further.)
(Yes, this layer is called “2”)
Add a WMS layer, and add “Layers Names” as an additional property. So it looks like this:
You can add extra properties to layers to fine tune their appearance. For example, for our CSV dataset:
You might want to set “Is Enabled” and “Is Shown” on every layer so they display automatically.
And finally, you might want to set an initial camera and base map, so the view doesn’t start off the west coast of Africa with a satellite view.
As you make changes, click “Save to Gist” to save your configuration file to a secret location on Gist. You can then click “Preview your changes in National Map”.
Make a note of the Gist link so you can keep working on it in the future. You can’t modify an existing configuration, but you can load from there and save a new copy.
Now you have a long URL like this: http://nationalmap.research.nicta.com/#clean&https%3A%2F%2Fgist.githubusercontent.com%2Fanonymous%2Fc3f181ca742b9ed94fe4%2Fraw%2F10853f7d8bb33610e4f2ce26947eaf6882192957%2Fdatasource.json
So, use tinyurl.com or another URL shortening service to get something more useful:
You want to do some visualisation magic in Tableau, but your spreadsheet looks like this:
All those green columns are dependent variables: independent observations about one location defined by the white columns.
Tableau would be so much happier if your spreadsheet looked like this:
This is called “normalizing” the “cross-tab” format, or converting from “wide format” to “long format”, or “UNPIVOT“. Tableau provides an Excel plugin for reshaping data. Unfortunately, if you don’t use Excel, you’re stuck. It’s kind of weird.
Anyway, I’ve made a Google Sheets script “Normalize cross-tab” that will do it for you.
As the instructions say, to use it, you:
It then creates a new sheet, “NormalizedResult”, and puts the result there.
It’s surprisingly clumsy to share Google Scripts, at least until the new “Add-ons” feature is mature. Here’s the best I can do for you:
Go to https://raw.githubusercontent.com/stevage/normalize-crosstab/master/normalizeCrossTab.gs, select all the text, and copy to the clipboard.
Upload your Excel spreadsheet into Google Sheets, if it’s not there already.
In the window labelled “Code.gs”, select all the text and paste over it the script from the clipboard.
You need to give this script “project” a name. It doesn’t matter.
Click Continue and accept the authorisation request.
Now, switch windows to your Google Sheet, and you’ll see the sidebar.
On the NormalizedResult page, choose File > Download as…
If you want to convert several spreadsheets, you can save yourself pain by loading them all into the same workbook. Just remember that the script will always save its output to NormalizedOutput.
For such a simple device, Google’s Chromecast has created a surprisingly complex network of technology at my place.
Google says that Chromecast works roughly like this:
Actually it’s more complicated than that. My setup is about as simple as you can get (no NAS, no existing media servers, no Netflix or Hulu or Foxtel or anything), and it looks like this:
Chromecast in the real world. Not so simple, really.
That is, depending on what exactly I want to watch and how, I have to choose between 6 different workflows:
And I haven’t even mentioned a couple more complications:
My advice? Figure out the smallest number of workflows to do everything you want to do, and get rid of any extraneous apps, servers, websites etc.
Google’s world centres around casting stuff from your phone. If that was all you could do, the Chromecast would suck. There are few apps, a lot of them are very niche (eg, anime or baseball), junk (like this) or just don’t really work (like the Red Bull app, which drops out every few minutes).
Fortunately, third party tools like VideoStream and Plex fill in a lot of the gaps.
The end result is actually great. Compared to having to plug my laptop into the TV, these things are now easy and fun:
Credit:Tim Strater from Rotterdam, Nederland CC-BY-SA
Of all the well-documented difficulties I’ve had working with Git over the years, a few conceptual difficulties really stand out. They’re quirks in the Git architecture that took me far too long to realise, far too long to believe, or far too long to really grasp. And maybe you have the same problem without realising it.
git branch -d master
git checkout develop -b master
There, I did it. I’m now calling the develop branch master. What you call this branch, and what I call it, and what your Github repo calls it, and what my Github repo calls it just don’t matter. Four different names? No problem. There are some flimsy conventions that Git half-heartedly follows to link two branches with the same name, but it gives up pretty easily.
I have very frequently fallen into this trap:
$ git diff origin/master
$
No differences, so my branch must be in sync with Origin, right? Wrong. What is true is my branch is in sync with the local copy of Origin. If you don’t run git fetch, then Git will never even update its local copies.
Technically, Git has always been upfront about this. The Git book opens the section on remote branches:
Remote branches are references to the state of branches on your remote repositories.
But it’s counterintuitive, and so I keep messing it up. I keep hoping (and assuming) that Git will one day include an auto-fetch option, where it constantly synchronises remote branches
Here’s the message that we have seen many times:
Note: checking out ‘origin/develop’.
You are in ‘detached HEAD’ state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:git checkout -b new_branch_name
This scary looking message threw me off for a long time, despite the fact that it’s actually one of Git’s most helpful messages – it tells you everything you need to know.
It boils down to this: you can’t make a commit if you’re not at the top of a branch. The two most common situations that cause this are:
git checkout origin/develop -b mydevelopgit branch -d develop
git checkout origin/develop -b develop
git checkout a8e6b18For a long time, I thought that ‘git init’, ‘git pull’ and ‘git clone’ somehow created repositories that were different, even if they ended up with the same commits in them. It’s hard to recreate my state of mind, but I spent a long time trying to salvage certain directories on disk when I should have just abandoned them.
Similarly, there is no difference between:
git clone http://github.com/stevage/myrepogit init
git remote add origin http://github.com/stevage/myrepo
git pull origin masterWell, in the second case Git’s a bit confused about which local branches map onto which remote branches, so you have to be more explicit or fix it with some configuration option.
Credit: Chevassu (GFDL)
For some reason, Git encourages you to call the source of the first clone “origin”. I have found this very confusing and ultimately very unhelpful. Let’s say you’re working on a project called widget, and you fork it in Github so you can work on it. You will want both remotes accessible locally, so you will probably do one of these:
git clone http://github.com/stevage/widget
git remote add widget http://github.com/widget/widgetgit clone http://github.com/widget/widget
git remote add mine http://github.com/stevage/widgetSo you either have remotes called “origin” and “widget”, or remotes called “origin” and “mine”. But on the next project, you might make the opposite choice, and soon you really don’t remember what “origin” means.
My tip: never name any remote “origin” ever. Name them all after their Github username.
git init
git remote add widget http://github.com/widget/widget
git remote add stevage http://github.com/stevage/widget
git fetch --all
get checkout stevage -b masterThe difference between “git reset”, “git reset –soft” and “git reset –hard” is beyond your comprehension. And you probably wanted “git checkout” anyway.
Rule of thumb:
(Credit: Flickr’s Carine06, CC-BY-SA)
Here’s my method of keeping track of stuff to do. Other tools just didn’t work for me. Most to-do list tools make two assumptions, I think:
My work, technology for academics, tends to involve coordinating lots of little projects with lots of different people. At any given moment, there are few tasks “in my court”, and they tend to be small. My primary responsibility is to keep all projects moving, and ensure that projects aren’t held up by a task being with me too long.
So, I ran with the ball in my court / ball in your court metaphor. It’s useful when:
“Projects” here can be very small, and often include very early stage proposals that haven’t formed into anything very concrete.
Trello Tennis in (fictious) action
To start with, the two most important columns:
The goal each day is to move projects from the “my court” column to the “their court” column. I periodically review “my court”, placing the most urgent items at the top. I also review “their court”, checking whether I should follow up or offer assistance.
More columns, that turned out to be useful for me:
Trello works really well for this.
The name of each card consists of both the project name, and a quick summary of my current task (if in my court), or what I’m waiting on if in theirs. Examples:
What’s particularly fantastic about using Trello is that each card can also track all the work on that project. Changing the title automatically creates a history trace, or I can add comments to record more information. Need somewhere to record a server name and login details? Use the card’s description field.
You can also use coloured labels to group projects, such as tagging by university in my case.
Of course, each individual project frequently has its own task tracking system: perhaps another Trello board, Github issues, Pivotal Tracker, Google spreadsheets etc. I link to them from the card’s description, ultimately tying together all information systems for all projects under a single roof.
Each day (or whenever):
To make this natural, I order the columns from left to right as follows: Wut, My Court, Blocked, Their Court, All Good, SEP, Archive. Stress is on the left, calm is on the right.
The goal is to get your board to look like this blissful fantasy:
A totally successful day in Trello Tennis land.
These examples are actually tiny compared to (my) reality. By the end of 2013, I had 21 active cards, plus another 10 inactive (SEP and Archive). If you find this technique at all useful, or have any improvements, I’d love to hear about it.
(Added 4 Feb 2014)
Sometimes it gets daunting looking at the huge mounds of work in front of you. Filtering can help cut through the distraction. Two types have worked for me:
Are you working for a particular client today, and don’t want to see anything related to any other clients? Assign one label per client, then turn on the filter!
To focus on just one or two tasks that you need to finish, first assign yourself to those cards. Then, filter to only show cards that you’re assigned to. This feature is intended for collaboration, but it works nicely.
A researcher at the Australian Research Centre in Sex, Health and Society (ARCSHS, pronounced “archers”) carries out surveys that are both:
It’s a tricky combination, not well supported by most survey software. Here’s a solution, using LimeSurvey, that doesn’t require modifying any code. These instructions are aimed at people with no familiarity with LimeSurvey.
Quick summary:
LimeService is a very cheap way to host LimeSurvey, and removes the burden of server administration.
Participants must not sign up for the survey using their actual email address. Instead, they should go to a third-party email forwarding site like http://notsharingmy.info. For the participant:
(Note: as of January 2013, notsharingmy.info is unreliable. I’m working on another solution.)
This solution relies heavily on LimeSurvey’s “tokens” which are explained badly in the interface. Enabling tokens just means you want to track information about individual participants: individual adding them to the list, inviting them, keeping track of who completed the survey or who needs another reminder. We also add “additional attributes”: the participants’ previous answers.
By default, LimeSurvey collects from each self-registering participant their first name, last name and email address. For a truly anonymous survey, you may wish to avoid collecting their name.
...
<script>
$(function(){
$("[name=register_firstname]").parent().parent().hide()
$("[name=register_lastname]").parent().parent().hide()
});
</script>
</head>
The first survey was a success, and there are now lots of entries in the tokens table and the responses table. More in the former than the latter, because some people will sign up and not answer any questions.
The other fields don’t matter. Leave them blank.
In the question text, click ‘LimeSurvey replacement field properties’ then select the extended attribute:
The text then looks like this:
Make sure you retain the additional attribute fields (attribute_1 etc.) They should be blank.
Whew. You’re now ready to launch.
You can then repeat this process for each subsequent iteration.
Git is the source code version control system that is rapidly becoming the standard for open source projects. It has a powerful distributed model which allows advanced users to do tricky things with branches, and rewriting history. What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt.
The information model is complicated – and you need to know all of it. As a point of reference, consider Subversion: you have files, a working directory, a repository, versions, branches, and tags. That’s pretty much everything you need to know. In fact, branches are tags, and files you already know about, so you really need to learn three new things. Versions are linear, with the odd merge. Now Git: you have files, a working tree, an index, a local repository, a remote repository, remotes (pointers to remote repositories), commits, treeishes (pointers to commits), branches, a stash… and you need to know all of it.
The command line syntax is completely arbitrary and inconsistent. Some “shortcuts” are graced with top level commands: “git pull” is exactly equivalent to “git fetch” followed by “git merge”. But the shortcut for “git branch” combined with “git checkout”? “git checkout -b”. Specifying filenames completely changes the semantics of some commands (“git commit” ignores local, unstaged changes in foo.txt; “git commit foo.txt” doesn’t). The various options of “git reset” do completely different things.
The most spectacular example of this is the command “git am”, which as far as I can tell, is something Linus hacked up and forced into the main codebase to solve a problem he was having one night. It combines email reading with patch applying, and thus uses a different patch syntax (specifically, one with email headers at the top).
The man pages are one almighty “fuck you”. They describe the commands from the perspective of a computer scientist, not a user. Case in point:
git-push – Update remote refs along with associated objects
Here’s a description for humans: git-push – Upload changes from your local repository into a remote repository
Update, another example: (thanks cgd)
git-rebase – Forward-port local commits to the updated upstream head
Translation: git-rebase – Sequentially regenerate a series of commits so they can be applied directly to the head node
Remember the complicated information model in step 1? It keeps growing, like a cancer. Keep using Git, and more concepts will occasionally drop out of the sky: refs, tags, the reflog, fast-forward commits, detached head state (!), remote branches, tracking, namespaces
Most of the power of Git is aimed squarely at maintainers of codebases: people who have to merge contributions from a wide number of different sources, or who have to ensure a number of parallel development efforts result in a single, coherent, stable release. This is good. But the majority of Git users are not in this situation: they simply write code, often on a single branch for months at a time. Git is a 4 handle, dual boiler espresso machine – when all they need is instant.
Interestingly, I don’t think this trade-off is inherent in Git’s design. It’s simply the result of ignoring the needs of normal users, and confusing architecture with interface. “Git is good” is true if speaking of architecture – but false of user interface. Someone could quite conceivably write an improved interface (easygit is a start) that hides unhelpful complexity such as the index and the local repository.
The fundamental promise of any version control system is this: “Once you put your precious source code in here, it’s safe. You can make any changes you like, and you can always get it back”. Git breaks this promise. Several ways a committer can irrevocably destroy the contents of a repository:
In the traditional open source project, only one person had to deal with the complexities of branches and merges: the maintainer. Everyone else only had to update, commit, update, commit, update, commit… Git dumps the burden of understanding complex version control on everyone – while making the maintainer’s job easier. Why would you do this to new contributors – those with nothing invested in the project, and every incentive to throw their hands up and leave?
The primary output of development work should be source code. Is a well-maintained history really such an important by-product? Most of the arguments for rebase, in particular, rely on aesthetic judgments about “messy merges” in the history, or “unreadable logs”. So rebase encourages you to lie in order to provide other developers with a “clean”, “uncluttered” history. Surely the correct solution is a better log output that can filter out these unwanted merges.
If your changes involve creating new files, there’s a tricky extra step:
For a Github-hosted project, the following is basically the bare minimum:
In reality though, the maintainer of that Github-hosted project will probably prefer your changes to be on feature branches. They’ll ask you to work like this:
As an added bonus, here’s a diagram illustrating the commands a typical developer on a traditional Subversion project needed to know about to get their work done. This is the bread and butter of VCS: checking out a repository, committing changes, and getting updates.
“Bread and butter” commands and concepts needed to work with a remote Subversion repository.
And now here’s what you need to deal with for a typical Github-hosted project:
The “bread and butter” commands and concepts needed to work with a Github-hosted project.
If the power of Git is sophisticated branching and merging, then its weakness is the complexity of simple tasks.
This post has obviously struck a nerve, and gets a lot of traffic. Thought I’d address some of the most frequent comments.
A few bonus command inconsistencies:
Reset/checkout
To reset one file in your working directory to its committed state:
git checkout file.txt
To reset every file in your working directory to its committed state:
git reset --hard
Remotes and branches
git checkout remotename/branchname git pull remotename branchname
There’s another command where the separator is remotename:branchname, but I don’t recall right now.
Command options that are practically mandatory
And finally, a list of commands I’ve noticed which are almost useless without additional options.
| Base command | Useless functionality | Useful command | Useful functionality |
| git branch foo | Creates a branch but does nothing with it | git checkout -b foo | Creates branch and switches to it |
| git remote | Shows names of remotes | git remote -v | Shows names and URLs of remotes |
| git stash | Stores modifications to tracked files, then rolls them back | git stash -u | Also does the same to untracked files |
| git branch | Lists names of local branches | git branch -rv | Lists local and remote tracking branches; shows latest commit message |
| git rebase | Destroy history blindfolded | git rebase -i | Lets you rewrite the upstream history of a branch, choosing which commits to keep, squash, or ditch. |
| git reset foo | Unstages files | git reset –hard git reset –soft |
Discards local modifications Returns to another commit, but doesn’t touch working directory. |
| git add | Nothing – prints warning | git add . git add -A |
Stages all local modifications/additions Stages all local modifications/additions/deletions |
A few interesting links:
Steve Bennett blogs 
Recent Comments