Thomas Denney

Student and app developer

Over the course of the last term I presented five introductory Python sessions as part of the Oxford University Computer Society's Learn to Code series. This year we saw the highest demand ever for the course, with over 1,100 people “interested” on Facebook and more than 200 attending the sessions — we packed out both lecture theatres in the Department of Computer Science!

All of the session materials from the course are available here. Note that this is my personal fork of the course materials with the version that I presented (it is quite likely that a future commmittee will present a different version next year). A playlist of all the screen recordings is available on YouTube. This was the first time I'd ever done any video editing, but in the end it turned out to be more of an exercise in audio editing.

Editing the final session in FCP

The first video was edited entirely in iMovie, but from the second session onwards all the video was edited in Final Cut Pro. I imagine that iMovie would have been sufficient for all the videos, but I fancied trying out Final Cut Pro.

We used a Focusrite Scarlett Solo interface along with the cheapest wireless mic I could find on Amazon to record the audio. I later had to redub a few of the sessions due to recording issues in the lecture theatre, but most of the audio was recorded live. The sessions recorded in the lecture theatre sound a lot better and, as a friend commented, avoid the “teenager making Minecraft videos” vibe. I struggled to get audio levels right until the very end of the course, so many of the early videos are far too quiet. By the end of the course I was also a lot more leniant in what I allowed through the editing process; some of the early sessions don't have a single utterance of “erm”, “OK”, or “so” but by the end I gave up and tried to keep the editing process straightforward.

It would have been nice to record video for the session in addition to the screen captures, but a lack of preparation on my part killed this plan. Besides, each session required around a total of ten hours a week to prepare the resources, reheasrse, execute the session, and then edit the video and I don't think I could have spared much more time out of an already packed term.

I am indebted to the dozen-or-so Oxford CS students that dedicated their Thursday evenings with me to run the course this year, in particular to Sauyon Lee, who presented sessions in a second lecture theatre. The student helpers managed everything from registration to helping out students with exercises, which allowed me to focus on just the presentation during the sessions.

Although Learn to Code was undoubtedly my greatest success as president of Oxford's Computer Society, there are many ways in which the course could be improved, and I leave this advice to my successor next year:

Don't be afraid to go slowly. In the first session I discovered that around half the audience had done some programming before, and sped up the session to cater for them. This was a mistake — I should have continued with my plan to aim the content at complete beginners

Encourage students to do exercises as much as possible, as early as possible. A small number of students went away and did nearly every exercise in the notes, and they definitely made the most progress over the course

Provide other materials that students can look at after the course or between sessions

Video editing is really hard! If the next committee plans to film the 2019 sessions then I hope they can find somebody that can edit the video content, because it certainly consumed far too much of my time

Focus on getting syntax right before introducing algorithms. My experience this year and last year was that once students mastered the basics of Python syntax they were far more able to solve problems than introducing algorithms and syntax concurrently. We definitely introduced the binary search algorithm too early this year, for example

Overall, teaching Learn to Code this year was an absolute pleasure. Even after relatively high demand for the course last year I was shocked to see so much demand this year, and I loved seeing so many students returning each week.

At the beginning of term I met with David Malan, the originator of Harvard's CS50 course, and after hearing of such high demand at Harvard for a programming course I was delighted we could replicate similar demand on this side of the pond. I wish the very best to my successors teaching our course, and I've no doubt its popularity will continue to grow.

As well as the usual public, protected, and private access control modifiers, which have with same rules as their Java siblings, Scala also supports the private[this] modifier, which prevents access to a property from other instances. For example, the following code would not compile:

class A {
private[this] var x = 0definc(a: A) = a.x = a.x + 1
}

Whereas this would be fine:

class B {
privatevar x = 0definc(a: A) = a.x = a.x + 1
}

Whilst the access control rules are applied at compile time, they lead to slightly different code generation. In the case of a property marked private a private field, a getter method, and a setter method are added to the class. All code that accesses the field (aside from its initialisation) will go through either the getter or setter. On the other hand, a private[this] field will only add the field to the class, and all access to the field is direct, rather than through accessor methods (as, after all, all access is only done by the instance).

The behaviour of the Scala compiler can be verified using the javap tool, part of the JDK that prints Java bytecode in a human readable form. I compiled the following two Scala classes:

The particulars of the JVM's instructions aren't important for our discussion, but we can see that Scala methods x() and x_=(int) are generated here, and we can see that they are used in the add method. Meanwhile, we see the following for javap -c -p B, the class using private[this], is:

Here the add method directly accesses the field via the getfield and putfield instructions, rather than generating accessor methods. The astute reader may wonder whether Scala's use of accessor methods for all private properties is slower than using private[this] or writing similar code in Java. Should you aim to use private[this] whenever you can to give yourself a performance boost?

The short answer is no. The JVM will eventually inline the getter and setter where they are used so that each access is executing the same native code as the private[this] version. In my tests, over 10 million invocations of the add method the class that used private was around 1% slower than the one using private[this], but over 100 million invocations it was around 0.3% slower.

By passing the flags -J-XX:+PrintCompilation -J-XX:+UnlockDiagnosticVMOptions -J-XX:+PrintInlining to the scala command you can view when a method is inlined by the JVM (these are Java flags, hence the need to prepend them with -J). I found on my machine that it generally took fewer than 20,000 invocations of the add method for the x_= method to get inlined inside it, leading to identical execution of both versions. The number of invocations of the method isn't a fantastic metric to go by, as other factors (CPU load, timing, etc) also play a part in when a method gets inlined, and not all methods can be inlined because they are too large. For more complex methods, the cost of method invocation is much smaller than actually executing the method.

private[this] should therefore be used when you need it for the specific access control for which it was designed. There is no need to hand optimise your code to use private[this], the JVM will do it for you!

The algorithmicx package provides macros for typesetting algorithms that can include math or text, and code blocks are automatically indented. I don't particularly like the default style, however, as it redundantly includes a line for the end keyword for each block and doesn't allow for single line if statements, while loops, or for loops.

The third major version of my music statistics app Play Time is now available on the App Store. Play Time allows you to find out which songs you've spent the most time listening to, and allows you to analyse your music listening habits over time. The new version of the app allows you to do more specific breakdowns for your music library, find out which songs you've spent the most time listening to this week, and view more statistics about your library as a whole.

Previous versions of the app only showed songs sorted by the time you'd spent listening to them, i.e. the play time of the song, but it is now possible to sort by other statistics, such as the play count or duration of the song. Like the last version of the app this extends to artists and albums, and Play Time 3 adds the option to analyse genres too.

Since version 2 Play Time has supported viewing when you've spent time listening to your music, but it was harder to view what you were listening to. Play Time 3 adds a "top this week" feature and can optionally remind you to check out what you've been listening to once a week.

One of the more whimsical features of the app is the set of bonus facts and statistics it can provide about your music library. The most recent addition is comparing the height of your music library as CDs with other objects and buildings.

At Oxford we submit almost all of our practical assignments on paper, which usually means printing out the diff of the work that we've done. Generally most people just generate the diff with git and send it to the printer with lpr, but I'm yet to succeed at getting output that I like with this approach.

Therefore I am now generating the diff, saving it to a file, and then using the LaTeX listings package to produce line-wrapped, coloured output.

Firstly, I generate the diff file itself:

git diff ORIGINAL_COMMIT_HASH -- > all.diff

Then I generate a PDF via xelatex diff.tex from the following LaTeX file:

This is the second of a two part series on writing. The first examined how and what I write by hand, and in this second article I discuss the software and hardware that I use when typing.

For several years I used Apple desktop keyboards, and these are what I learned to touch type on. With time, however, I began to find the flat surface and shallow keys less comfortable, so I began to look for something more ergonomic. I settled on the Microsoft Sculpt keyboard, which is the successor to Natural Ergonomic 4000. This keyboard is a much more comfortable shape for resting your hands, although it takes some getting used to, has slightly deeper keys, and is split down the middle, forcing you to use the correct fingers when touch typing.

Microsoft Sculpt keyboard

I did consider using a mechanical keyboard, however I have never particularly liked the sound that they make, and I am yet to invest the time in determining which key switches I prefer. I have no doubt that in the future I'll go down this path, but for now I'm happy with my Microsoft keyboard.

The Apple Smart Keyboard deserves an honourable mention here. I don't use it all the time, but it's surprisingly good when I do. I expected that I would dislike the small, shallow keys but I've found that it is possible to touch type on at a comfortable pace close to what I could do on a full sized desktop keyboard.

NeoVim running in tmux

Since 2015 my primary text editor has been Vim (although I use NeoVim these days). Before that I'd used TextMate for years, and despite my determination not to catch the 'Vim bug' I went ahead, dived in, and now I'm trapped! It now seems slightly odd to use a text editor that doesn't have separate normal, visual, and insert modes, and I've found that Vim's shortcuts significantly improve my productivity without being awkward or uncomfortable. My use of Vim has increased pretty much linearly with my use of terminals, and these days you can pretty much guarantee that I've got a tmux session with Vim running somewhere.

Aside from code, when I edit documents in Vim they tend to be either Markdown or LaTeX, with the vast majority in Markdown. Both are great formats for my typeset lecture notes or problem sheets, because I can use pandoc and xelatex to generate PDFs that contain plain text, syntax highlighted code, equations, and diagrams (which pretty much covers everything I need to do). I haven't used a regular document editor (like Word or Pages) for several years because I find Markdown a great deal more convenient.

When I'm editing a document or note that will not need to be typeset, but I still want to use Markdown, I tend to use Ulysses as it syncs documents across all my devices, looks great, and is fast even with large libraries. I've replaced my use of Evernote entirely with Ulysses, after a long series of strange UI and policy decisions at Evernote. My most recent blog posts were all written in Ulysses, for example. The Apple Notes app, after adding support for rich text, lists, and images certainly deserves a mention, but I don't use it as much for longer notes.

I am also totally dependent on TextExpander for text expansion on my computer. I'm currently using an older version of the app that predates their move to subscription pricing, and I expect I'll continue using it until a future macOS update breaks it, but hopefully that will be in the distant future.

On my phone I use SwiftKey rather than the standard iOS keyboard. This comes with the occasional disadvantage that it is slightly slower to show up, but the benefit of swiping to type is a big win. I've experimented with other similar keyboards by Google and Microsoft, but I have found that SwiftKey is the most reliable over time.

Surprisingly, for a computer science student, I evenly split my time between typing and writing by hand. I generally begin by writing out my notes and problem sheets by hand before later preparing a typeset version of them, depending on what is required. In this first of a two part series I discuss the pens, inks, paper, and notebooks that I use, and why I often choose to write by hand.

For most of the last decade I've exclusively used fountain pens, with occasional forays into ball points, roller balls, and fine liners. Fountain pens have the significant advantage that ink will flow out of them with very little pressure, whereas a ball point requires you to apply pressure directly to the page, which is significantly less comfortable. The section (the part of the pen you grip) is also far nicer to hold on most fountain pens, firstly because it is often far wider than that of a ball point, thus keeping reasonable separation between your fingers, but also because many pens will also be shaped for holding (see the pictures of Lamy pens below) comfortably.

Unusually for a fountain pen user, I rarely write in cursive and do not italicise my letters. The main reason for this is that I have to write a lot of mathematical notation, and I've found it helps to be consistent between text and equations. I do, however, enjoy calligraphy but don't do it for regular note taking.

Parker Sonnet, Lamy Safari, and Pilot Metropolitan

At the moment I am currently switching between Parker, Lamy, and Pilot pens. Parker pens are widely available in the UK, and I've found them to write very smoothly. My Parker pens all have medium nibs, which forces me to write slightly larger to ensure proper separation between characters. More recently I've come to enjoy using Lamy pens, which are often inexpensive, with fine nibs. I particularly like my Lamy demonstrator pen, which has a clear case, allowing you to see the internal working of the pen.

Lamy Demonstrator pen

In nearly all my pens I use converters, rather than ink cartridges, as this allows me to use a far broader variety of inks. Until very recently I exclusively used Parker Blue-Black, but I've come to find the colour a little too grey. Instead, I have started using J. Herbin 1670 inks, with Emerald of Chivor and Ocean Blue pictured below:

To say these inks are fantastic is an understatement. The ink flows perfectly in all my fountain pens, and both have a deep, rich colour. The emerald ink contains small flecks of gold, so the writing will sparkle in some lighting conditions. These inks are very expensive compared to most, but they are by far the best I've ever used.

From personal experience I must also recommend Amodex Ink Stain Remover, especially if you use thicker, oil based inks. Aside from a dip pen that I use infrequently for calligraphy most of my pens do not have a tendency to leak, but when they do this stuff is a life saver.

Whilst pens and ink are important, the quality of the paper I write on is equally important to me. When I was at school I tended to use Ryman Superior paper, which is thick enough to avoid bleeding with most inks. The paper is, however, quite coarse so I've therefore switched to using Rhodia pads instead. I started with a dot pad, which is great for diagrams and testing pens or inks, but I then began using the larger lined pads. I recommend Rhodia Nº 19 in white with lined pages. The pages of this pad do not come hole punched, and have a margin that is slightly too wide for my liking (although they're good for taking notes) but the paper has a much smoother finish than the Ryman paper. I've found that when writing on the back of sheets in Rhodia pads (which fold at the top, with a perforated edge for each page) it is generally best to either only fold over the top few sheets onto the back of the pad, or tear it off immediately.

Moleskine and Leuchtturm notebooks

As well as paper pads, I also write a great deal in notebooks. I currently use Moleskine and Leuchtturm notebooks, and I far prefer the latter. My Moleskine notebooks are smaller, so I tend to use them for todo lists and for jotting ideas down, whereas I tend to take longer notes in the larger (A4) Leuchtturm notebook. The paper is also more translucent in Moleskine notebooks, meaning that you get slightly more bleeding. The Leuchtturm notebook also has page numbers and a table of contents, which make it ideal for university notes (although, sadly, they don't come cheap). As all these notebooks are narrow ruled I've preferred to write with a fine nib and also use a darker ink colour, as the pages are not pure white. Fine liners also work well in these notebooks, but with ball points you generally have to apply so much pressure that you'll mark the page below. Furthermore, I wouldn't recommend using Lamy roller balls or the Moleskine pen in these notebooks, as the former is much to thick and the latter smudges too easily.

Whilst much slower than typing, I enjoy writing by hand because it gives me a lot more creative freedom over the appearance of my writing, is more ergonomic than typing, and the slower pace tends to force me to think a great deal more about what I'm writing.

Overall, I am very happy with my current writing setup, and I look forward to evolving it in the future. In the second of this two part series I will discuss the software and hardware that I use for typing.