Monthly Archives: February 2014

Meeting on the 28th Feb.

For our meeting this week we have an overview of referencing in LaTeX from the wonderful Damian Murphy.

IMAS AURORA LECTURE THEATRE – it’s the big lecture theatre on the left as you walk into the waterfront building foyer.
FRIDAY 28th Feb at 9:30am
All future meetings will be in this room on friday mornings. This is because it’s really hard to find space in the waterfront building during the Uni semester and it turned out that friday morning is the only time we can easily book space. As of this week, I have booked every friday until the rest of the year… So get your thinking caps on and let me know what you’d like to talk about in the future.

You can already code…

This article, although not written with scientists in mind, does a brilliant job of capturing the anxiety and confusion suffered by most PhD students trying to learn to code.
Originally posted on by Ed Rex in the section On Coding  – [ ]

When someone tells you they code, it’s as if they’re calling you from inside the world’s most exclusive club. It’s probably a pretty great party in there, but you’ve got no idea how they got on the guest list and you’re fairly sure that even if they came out, floored the bouncer and physically carried you in, the bar staff would spot your trainers and you’d find yourself back on this side of the door in ten minutes. Like speaking Chinese or perfecting the moonwalk, coding is just one of those things you’ll never be able to do.

This, of course, is a complete myth. There’s nothing stopping you learning to code. In fact, you could start right now. Go on – don’t even read to the end of this post. Click here instead. You’ll have written your first lines of code before you next check Facebook. Or here if you want to make a website. Or here if you fancy giving an iPhone app a go. Like most things, getting started turns out to be as simple as Googling it and clicking on the first link that’s not an ad. Every coder out there has to start from square one at some point.

But you’re not really starting from square one. Because really, deep down, you already know how to do it. Code is instructions. You write the instructions, and the computer follows them. Any time you’ve given someone directions to your house, or typed in a sum on a calculator, or lined up a row of dominoes, you’ve essentially been coding. The person following your directions, you pressing the equals button, knocking over the first domino – that’s the code being run. Coding is pretty much teaching a series of steps to a computer, for the sole reason that it can follow those steps a hell of a lot quicker than you can.

Running your first line of code and seeing it do whatever it was you told it to, you quickly realise this is something you could get used to. Most of us love giving orders, and when you sit down to code you’ve got what amounts to an uncomplaining, untiring, unerring servant literally at your fingertips. Sure, you have to issue your edicts in a fairly precise way – but ask nicely and it will do pretty much anything for you. And learning the language is easier than you might think; you’ll quickly find that amateur coders are probably the third best served group on the internet, losing out only to Google Incognitos and cat-lovers. For literally every problem you come across, someone will have had it before, asked the rest of the world about it, and received an answer that sounds like it’s been taken straight out of a computer science textbook. It’s as if Tim Berners-Lee is sitting in a room somewhere, scouring the Internet for helpless beginners, and answering each of their questions in turn under a different, ill-judged pseudonym. Bless him.

There’s the usual spiel about the astronomical salaries, the free lunches, the wearing hoodies to work – but you already know all that. Everyone has since they made that film about Justin Timberlake going to Harvard. No, a better reason to start coding, one that may trample all over your better judgement, is that it’s fundamentally creative. You just have to look at what some of the tech companies out there are doing – the Twitters and Apples of this world – to see that this much is true. Thinking that coding is the nerdy IT guy at work rebooting your computer is like thinking that music is what happens when the piano tuner comes round.

Let’s be clear – like anything, getting really good is tough. Unless you happen to be a 7-year-old, you’re probably not going to find time to rack up your 10,000 hours. But that’s not what most of us are going for, and it’s certainly no reason not to pick it up. So if you’ve ever thought you’d like one day to give it a go, treat today as that day. Or at least some time this week. Because, basically, you can already do it.

How to LaTeX

On Wednesday the 19th Feb 2014 the wonderful Tom Remenyi gave us an overview of the LaTeX document preparation system and worked through his famous LaTEX training document.

For those that couldn’t attend here are a few useful links and videos to bring you up to speed:

  • Most importantly, here is a link to the downloads page for Tom’s LaTeX training document [ ]. This is a ‘how to use LaTeX’ training document. It is aimed at people who do not like using MS Word or Mac Pages for producing large documents and do not know how to write computer code. It aims to gently introduce LaTeX to users and considerably lower the learning curve.
  • Tom’s recommendations for installing LaTeX: If on a Mac, download the latest version of MacTeX. This comes with TeXShop as the main ui and is a very smooth and gentle tool for working in LaTeX [ ]. If you’re on Windows or Linux, download the latest version of MikTeX, which is based on TeXShop [ ]. Please keep in mind that there are many ‘flavours’ of LaTeX user interface out there and that these are just a couple of simple examples – try to find the one that best fits your workflow and style. Google is your friend.
  • A great cheat-sheet of commonly used LaTeX commands: [ ]

Finally, the ethos of TexWorks – simple, clean, uncluttered, powerful:

Meeting on the 19th Feb.

As you may have noticed, there will be no Data Science Hobart meeting this week, this is due to the AMOS conference occupying most of my time.

BUT, next week we have an introduction to LATEX rom Tom (TANK) Remenyi. LATEX is a document preparation system and a document markup language.
IMAS FLEX SPACE – on the left as you walk into the waterfront building foyer – I’ll put a sign up this time.
Wednesday 19th Feb at 9:15am
See you there.

Intro to the Shell.

On Friday the 7th Feb we covered some simple bash commands and bash scripting in prep for the Software Carpentry Bootcamp that was held in Hobart the following week.

I have reproduced an overview of the shell teaching material they used for this course and I have linked to Damien Irving’s GitHub repo that contains the original files, code, and examples.


A guide to the shell teaching content:


This directory contains the shell related content that I teach at Software Carpentry bootcamps.

## Novice lessons

### 1. Files and directories (novice/

* The file system is responsible for managing information on disk.
* Information is stored in files, which are stored in directories (folders).
* Directories can also store other directories, which forms a directory tree.
* `/` on its own is the root directory of the whole filesystem.
* A relative path specifies a location starting from the current location.
* An absolute path specifies a location from the root of the filesystem.
* Directory names in a path are separated with `/` on Unix, but `\` on Windows.
* ‘..’ means “the directory above the current one”; ‘.’ on its own means “the current directory”.
* Most file names are something.extension; the extension isn’t required, and doesn’t
guarantee anything, but is normally used to indicate the type of data in the file.
* `cd` path changes the current working directory.
* `ls path` prints a listing of a specific file or directory; `ls` on its own lists the
current working directory.
* `pwd` prints the user’s current working directory
* Most commands take options (flags) which begin with a ‘-‘

### 2. Creating things (novice/

* Unix documentation uses ‘^A’ to mean “control-A”.
* The shell does not have a trash bin: once something is deleted, it’s really gone.
* `mkdir path` creates a new directory.
* `cp old new` copies a file.
* `mv old new` moves (renames) a file or directory.
* `rm path` removes (deletes) a file.
* `rmdir path` removes (deletes) an empty directory.

### 3. Pipes and filters (novice/

* Use wildcards to match filenames.
* ‘*’ is a wildcard pattern that matches zero or more characters in a pathname.
* ‘?’ is a wildcard pattern that matches any single character.
* `command > file` redirects a command’s output to a file.
* `first | second` is a pipeline: the output of the first command is used as the input to
the second.
* The best way to use the shell is to use pipes to combine simple single-purpose programs
* `cat` displays the contents of its inputs.
* `head` displays the first few lines of its input.
* `sort` sorts its inputs.
* `tail` displays the last few lines of its input.
* `wc` counts lines, words, and characters in its inputs.

### 4. Loops (novice/

* Use a for loop to repeat commands once for every thing in a list.
* Use `$name` to expand a variable (i.e., get its value).
* Do not use spaces, quotes, or wildcard characters such as ‘*’ or ‘?’ in filenames, as
it complicates variable expansion.
* Give files consistent names that are easy to match with wildcard patterns to make it
easy to select them for looping.
* Use the up-arrow key to scroll up through previous commands to edit and repeat them.
* Use `history` to display recent commands, and `!number` to repeat a command by number.

### 5. Shell scripts (novice/

* Save commands in files (usually called shell scripts) for re-use.
* Use `bash filename` to run saved commands.
* `$*` refers to all of a shell script’s command-line parameters.
* `$1, $2, etc.,` refer to specified command-line parameters.
* Letting users decide what files to process is more flexible and more consistent with
built-in Unix commands.

### 6. Finding things (novice/

* Everything is stored as bytes, but the bytes in binary files do not represent characters.
* Use nested loops to run commands for every combination of two lists of things.
* Use `\` to break one logical line into several physical lines.
* Use parentheses `()` to keep things combined.
* Use `$(command)` to insert a command’s output in place.
* `find` finds files with specific properties that match patterns.
* `grep` selects lines in files that match patterns.
* `man` command displays the manual page for a given command.