Thomas Denney

Student and app developer

Play Time, my music statistics app, now supports the iPhone X and has lots of fixes for iOS 11. Here's what's new in this release:

• Support for new iPhone sizes and iOS 11
• Use the predominant colour of an album's artwork when artwork is disabled
• Sorting by Album Artist
• Sorting options when breaking down by album, artist, or genre
• Removed option to display play count - it is now displayed based on context
• Explicit songs play time

Fixed:

• Crashing bug when collecting library data
• Resolved bugs related to row selection
• Ensured the typeface is consistent across the app
• Removed old style app rating

You can download the Play Time for $0.99 on the App Store. Published on December 13, 2017 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 = 0 def inc(a: A) = a.x = a.x + 1 } Whereas this would be fine: class B { private var x = 0 def inc(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: class A { private var x: Int = 37; def add() = x = x + 1 } class B { private[this] var x: Int = 37; def add() = x = x + 1 } The output of javap -p -c A, the class that doesn't use private[this], is: Compiled from "Classes.scala" public class A { private int x; private int x(); Code: 0: aload_0 1: getfield #13 // Field x:I 4: ireturn private void x_$eq(int);
Code:
2: putfield      #13                 // Field x:I
5: return

Code:
2: invokespecial #22                 // Method x:()I
5: iconst_1

Published on February 15, 2017

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:

\documentclass[11pt,]{article}
\usepackage[margin=1in]{geometry}
\usepackage{listings}
\usepackage{parskip}
\usepackage[rgb,dvipsnames]{xcolor}

\definecolor{mygreen}{rgb}{0.1,0.25,0.01}
\definecolor{myred}{rgb}{0.25,0.1,0.01}
\definecolor{mymagenta}{rgb}{0.5,0.05,0.25}

\lstdefinelanguage{diff}{
morecomment=[f][\color{blue}]{@@},       % group identifier
morecomment=[f][\color{myred}]-,         % deleted lines
morecomment=[f][\color{mymagenta}]{---}, % Diff header lines (must appear after +,-)
morecomment=[f][\color{mymagenta}]{+++},
}

\lstset{
basicstyle=\ttfamily,
numberstyle=\footnotesize,
stepnumber=1,
numbersep=5pt,
backgroundcolor=\color[RGB]{255,255,255},
showspaces=false,
showstringspaces=false,
showtabs=false,
tabsize=2,
captionpos=b,
breaklines=true,
breakatwhitespace=true,
breakautoindent=true,
escapeinside={\%*}{*)},
linewidth=\textwidth,
basewidth=0.5em,
}

\begin{document}

\lstinputlisting{all.diff}

\end{document}
Published on February 3, 2017

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.

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.

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.

Published on January 7, 2017

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.

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.

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.

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.

Published on January 7, 2017

When I come home for vacations from Oxford I suddenly find myself using real dates again, rather than thinking in terms of "Tuesday of 5th week" or "Sunday of 3rd week". However, during term time there is the occasional need to map between 'Oxford dates' and real dates.

Wolfson College provide a calendar that you can subscribe to that provides each week of each term, which is invaluable when scheduling lectures and tutorials into my calendar. Sometimes, however, I just need to very quickly find out what date an 'Oxford date' falls on, or what 'Oxford date' a regular date falls on.

I have therefore created a very simple Python script that provides this functionality, allowing you to run ./oxtermdate.py 2017-02-14 or ./oxtermdate.py Tu5 to map between the two. Currently you have to set an environment variable for the start of term (which you can find here), but seen as this only changes three times a year I am currently not bothered about automating it.

Published on January 7, 2017