Thomas Denney

Student and app developer

The KOSMOS Pen

Aluminium KOSMOS ink in Night Sky
Aluminium KOSMOS ink in Night Sky

In general I am not a fan of ball point pens, but the magnetic cap design of the KOSMOS pen intrigued me. Rather than pressing a button or removing a cap, the KOSMOS pen by Stilform, a design studio based in Munich, allows you to pull back on the cap, which is then held in place magnetically. It is a simple but effective idea.

Stilform clearly care about design, and the KOSMOS pen is certainly the best designed ballpoint that I’ve used. That design does come at a price; my aluminium model cost €50, but a titanium bodied model is also available at €100. The aluminium models come in five colours, three of which are intentionally similar to Apple’s MacBook lineup.

Aside from the magnetic cap, one of pen’s best features is barely mentioned in Stilform’s marketing: the pen rolls very little. I suspect they’ve weighted the body on one side, but I couldn’t tell where after playing with it for a few minutes. I was a little disappointed to find that it didn’t always roll to show the logo, which is engraved near the top of the pen. I think the engraving could be a little deeper, but the rest of pen's design seems to call for minimalism.

I struggled to find good lighting to show the logo’s shallow engraving
I struggled to find good lighting to show the logo’s shallow engraving

Before I received the pen I wasn’t sure which part of the pen actually moves when you shift the cap. The cap screws onto the black segment that initially separates the cap from the body, and both of these move when the cap slides — the refill always stays in place. I’d like the cap to screw in a little tighter, although only because I fiddled with it repeatedly this week! When I did unscrew the cap I found that the spring inside it would often come loose and fall out; I think a grove near the end of the cap could solve this problem.

The pen, with the cap covering the refill cartridge
The pen, with the cap covering the refill cartridge

The pen is loud. Not to write with, but with the snap as you shift the cap in and out of place. By way of comparison, it is much louder than closing the lid of my AirPods case and certainly louder than any other retractable pen that I’ve used before.

The included Stilform cartridge let the rest of the pen down. I initially found that I had to apply a lot of pressure — a lot more than I would apply with other ballpoints — to get a consistent stroke. Thankfully the cartridge is a standard (it is the same ISO G2 cartridge that Parker include in their ballpoints), so it can be easily replaced. Otherwise, the pen is a very comfortable weight and I didn’t have any issues writing with it for a few hours.

On the top line I applied extra pressure whilst on the second I allowed the ballpoint to roll across the paper.
On the top line I applied extra pressure whilst on the second I allowed the ballpoint to roll across the paper.

As much as I like the elegant design of the KOSMOS pen, I’ll continue using fountain pens for regular writing. At the moment I’m carrying it in my backpack for situations where I have to write on paper that ink would bleed on.

Later in 2018 Stilform will release the KOSMOS Ink, a fountain pen with a removable magnetic cap. I’ve pre-ordered the pen, and I look forward to seeing their ideas applied to other stationery.

Learn to Code 2018

Yours truly presenting the final session

Yours truly presenting the final session

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

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.

Play Time 3.1

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.

Scala's Privates

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:
       0: aload_0
       1: iload_1
       2: putfield      #13                 // Field x:I
       5: return

  public void add();
    Code:
       0: aload_0
       1: aload_0
       2: invokespecial #22                 // Method x:()I
       5: iconst_1
       6: iadd
       7: invokespecial #24                 // Method x_$eq:(I)V
      10: return

  public A();
    Code:
       0: aload_0
       1: invokespecial #27                 // Method java/lang/Object."<init>":()V
       4: aload_0
       5: bipush        37
       7: putfield      #13                 // Field x:I
      10: return
}

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:

Compiled from "Classes.scala"
public class B {
  private int x;

  public void add();
    Code:
       0: aload_0
       1: aload_0
       2: getfield      #14                 // Field x:I
       5: iconst_1
       6: iadd
       7: putfield      #14                 // Field x:I
      10: return

  public B();
    Code:
       0: aload_0
       1: invokespecial #19                 // Method java/lang/Object."<init>":()V
       4: aload_0
       5: bipush        37
       7: putfield      #14                 // Field x:I
      10: return
}

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!

More articles for Microsoft Faculty Connection

After attending the Microsoft Build conference in Seattle in May, I wrote a bunch of blog posts for the Microsoft Faculty Connection blog:

Yeah, I quite like functional programming :).

Typesetting algorithms with LaTeX

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.

I therefore use the following:

\usepackage{algpseudocode}
\algtext*{EndWhile}
\algtext*{EndFor}
\algtext*{EndIf}
\algtext*{EndFunction}

\algnewcommand{\SIf}[1]{\State\algorithmicif\ #1\ \algorithmicthen}
\algnewcommand{\SElseIf}[1]{\State\algorithmicelse\ \algorithmicif\ #1\ \algorithmicthen}
\algnewcommand{\SElse}{\State\algorithmicelse\ }
\algnewcommand{\SWhile}[1]{\State\algorithmicwhile\ #1\ \algorithmicdo}
\algnewcommand{\SFor}[1]{\State\algorithmicfor\ #1\ \algorithmicdo}
\algnewcommand{\SForAll}[1]{\State\algorithmicforall\ #1\ \algorithmicdo}

This eliminates the end keywords and allow for the single line if statements, for example:

The above is typeset using:

\begin{algorithmic}
    \Function{Heapify}{$A, i$}
        \State $n := $ \Call{HeapSize}{$A$}
        \State $l := 2i + 1$
        \State $r := 2i + 2$
        \SIf{$l < n \wedge A[l] > A[i]$} $largest := i$
        \SElse $largest := i$
        \SIf{$r < n \wedge A[r] > A[largest]$} $largest := r$
        \If{$largest \neq i$}
            \State \Call{Swap}{$A[i], A[largest]$}
            \State \Call{Heapify}{$A, largest$}
        \EndIf
    \EndFunction
\end{algorithmic}

Using F# for serverless REST APIs

As part of my role as the Microsoft Student Partner lead at Oxford, I recently wrote an article for the Microsoft Faculty Connection blog on using F# to write serverless REST APIs.

Play Time 3

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.

You can download Play Time on the App Store for $0.99.

Printable diffs

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{mygreen}]+,       % added 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}

Typing

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

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

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.