Single file Shiny app to take GET parameters and return date range input boxes

I’ve spent quite a long time fiddling around with some code for the feedback website for which I am responsible for all the reporting so we can distribute custom URLs to individuals who have specific reports they want to run. We use Shiny to do custom reports, the application lives here, and many of the people who run the reports (our staff in Nottinghamshire Healthcare NHS Trust, mainly) would welcome the ability to have the date range preselected by means of a URL containing GET parameters which they could just click so that the date range is pre-selected.

The code is not very well commented and does not handle bad URLs very well. In time I may fix this or I may just tell people that if they can’t figure out how to write well formed GET querys that I will make some for them.

Nonetheless, I thought it would be useful to share in case anyone else is doing something similar and wants to get started or steal some of the code. It’s all hosted as a single file shiny app on Gist here which means that by the magic of Shiny you need only run:

runGist(gist = "79a592a83ccda153efae")

for a demo. You will need to paste the correct GET parameters in yourself, obviously. The app does one of three things, all selectable using a type=”xxx” GET parameter. There follows a list with a URL that does something for each one. The output to the right of the date widget is just some debugging stuff so I can see what’s happening as I go along, you may wish to keep something like that in anything you write while you’re building it.

You can run it on your own machine or I host it on my server, if you run on your own machine just add to the end of the address bar everything after and including the “?”, or click the link to see it on my server. It looks a bit funny because I have an old version of Shiny on the server, I can’t upgrade at the moment because of various issues with IE7 etc. but hope to soon. It works, anyway, which is the point, and looks fine on the newest version of Shiny (0.12 as I write this).


This is the simplest one, you just put the date (begin and/ or ending) straight in as dmy format (which UK people will prefer, more on which later) like this:

Missing out either is fine, if you miss the beginning one it will just go to a year ago and if you miss the end one it picks today.


This is for people who want to find the previous n months, rounding to months (e.g., today, in September, n = 3 would bring back the three months previous to September- June, July, and August).


And lastly and most complicated-ly, people who want to use just quarters and years. It took me ages to debug this because the quarter() function from the marvellous lubridate package returns January as 1, April as 2, etc., which apparently is the US way of doing things, whereas in the UK January is 4 (of the previous year, obviously), April is 1, July is 2, etc. I never had any idea there were different systems. In fact, there are different systems all over the world. Amazing what you learn some days.

Converting the output of quarter() to what I want entailed moving from a year that cycled 1, 2, 3, 4 to a year that cycled 4, 1, 2, 3 and so I used our old friend modulo arithmetic to convert between the two (%% in R). I won’t say anything further about that because I’m completely hopeless when it comes to modulo arithmetic and if I’m honest the code came about more through trial and error than anything else.

And that’s basically it. Browse the code, run the application, I hope it’s of some use to someone looking to do something similar.

Producing headings in Word files programmatically using knitr

I love knitr. Sometimes I have to send people documents in Word. It works beautifully except when I want to produce headings programmatically in code using cat(). This is fine in HTML:

sapply(headings, function(x){
  cat(paste0("<h1>", x, "</h1>"))
  cat(paste0("<p>", rep("Some text here", 10), "</p>"))

However, when writing Word .docx files using Rmarkdown the heading tags are not recognised. Well, they’re not printed, so they obviously are recognised, but they don’t work.

I’ve struggled for a long time to understand how to produce headings in Rmarkdown and to be honest in the past I’ve actually done it with a lot of guesswork and some silly hacky unnecessary code. Today I have finally figured out a foolproof way to do it very easily every time, so I present the whole document to you and to my future self when I inevitably forget how to do it:

title: "Minimal example"
author: "Chris Beeley"
date: "1 September 2015"
output: word_document

```{r setup, include=FALSE}

knitr::opts_chunk$set(echo = TRUE)


```{r, results = 'asis', echo = FALSE}

headings = letters[1:4]

  sapply(headings, function(x){
    cat(paste0("#", x, "\n"))
    cat(paste0("<p>", rep("Some text here", 10), "</p>"))


That’s it! Don’t forget the invisible() because otherwise if you use lists and things like that you’ll get the names of the list at the end.

Digikam crashes on startup

To be honest, this post is really designed as a reminder to me in case I ever reinstall my OS, but it will probably get a bit of Google juice and could possibly help somebody else.

If you’re using Digikam (a fine piece of software for organising your photos, well worth a look) and you find that it crashes on startup with Linux Mint, then

sudo apt-get install kdelibs-bin kdelibs5-data kdelibs5-plugins

Convert pdf to text on Ubuntu

We had rather an ugly scanned pdf of a very lovely poem over on our feedback website so I thought I would try to post the text from it using Optical Character Recognition using tesseract.

On Ubuntu start with:

sudo apt-get install tesseract-ocr imagemagick

You’ll need to convert the pdf to an image file:

convert -density 600 input.pdf output.tif

and then output to output.txt like this:

tesseract myscan.png out

Do note that if you have problems where an empty text file is returned (as I did) this could be because the margins around the image are too large- crop it down (not too tightly) and it should work nicely (although I would say it returned “l” a lot when in natural English that is obviously going to be an “I”, seems kind of obvious to a user but there must be some technical problem there, I suppose).

Five tips for five years

I saw some wonderful tweets the other day where the author gave their former naive self some time-travelling advice from their present self about how best to get started with programming. I did intend to keep the link but sadly my filing system has failed and it’s fallen through the cracks. I’m grateful to the author, in any case, for inspiring this post, written on the fifth anniversary of my own initial foray into the world of programming. I will give myself five pieces of advice for five years, also because five is a nice round-ish number.

1. It may sound obvious, but it’s worth saying and it’s probably the most important of the points in this post- write code. Write code to solve problems you face in your work. Write code to find out why the code that you’re writing doesn’t work. Write code to make sure that the code that you’re writing gives you the right answer. Write code for fun. Write code to see if you can do something with code instead of by hand. Write code to write “Hey, look what I did” blog posts. Write code to produce minimal examples so you can get help on forums. Writing code is an art (we’ll come back to the points in this post that caution against churning our code that “just works”), and, like all arts, you need to log the hours. So log the hours.

2. Following on from this, and as espoused by the pre-eminent stats guru, Hadley Wickham, never be ashamed of your code. The code I wrote five years ago is laughably bad. At a glance it’s quite obvious I had no idea what I was doing. Many of the functions are the wrong functions. It’s by turns ridiculously verbose and frustratingly taciturn. It’s badly commented and baffling to me, never mind about any other poor individual who might have to maintain or change it. But you learn by experience and coming back to all this dreadful code taught me WHY it’s important to write legible, well commented code and WHY it’s important to refactor code and WHY it’s important to use the paradigms in the language you’re writing in (functions, objects…).

3. At the same time as you’re writing code that solves problems, having fun, and learning how to make code that works, listen to the experts. You won’t understand it all yet but you need to file it away for later. There are many brilliant people on the internet sharing their knowledge with anybody who cares to listen and you need to listen to each and explore for yourself what they’re saying. In my time I’ve run down many dead-ends (or, I should say, things that are dead-ends for me now, with my level of skill) but have learned a great deal when I crashed into the wall at the end. Emacs is the best text editor in the world? Great! Wham! No, Vim is the best editor. Great! Wham! You must use MVC for PHP/ MySQL applications? I’ll use CakePHP! Wham!

CakePHP was probably the brick wall that I hit the hardest. I didn’t understand it at all. Now I’m starting to understand the principles, and the why, but haven’t quite got to the how.

4. While it’s good to just roam the internet, writing terrible code, reading advice from experts, and generally just having fun, there is definitely value in doing a paid course where you get help with your own code from an expert. I’ve taken two courses now, one with the Open University, Introduction to object oriented programming with Java, and one with O’Reilly, Web security with PHP and MySQL. Having a real person read, assess, and improve my actual own real code not only taught me a lot but also gave me discipline to write code that could be understood and easily criticised by somebody other than me. This is also a good way to dip your toes into different waters and start to understand the strengths and weaknesses of different languages and approaches. I have learnt Java and Python (on and although I haven’t yet used them for anything serious it’s helped me to understand the situations in which you would use them for something serious and why.

5. This only applies to certain types of programmer, but it certainly applied to me. Run your own server. They’re quite cheap to rent (or you could use an old computer in your own house) and you can do fun things with them like run WordPress (I self host this blog) and Shiny Server. Running a server will cause you a lot of headaches but will teach you a tremendous amount about your operating system as well as giving you an insight into the world of running applications and servers in real world applications. This only applies to people who want to write applications for the web, of course. Some programmers will spend their whole lives blissfully ignorant about such matters.

6. One extra one for fun. Use Linux. It’s fun. You can “take the back off” quite easily which makes it good for learning and the community is great. You’ll probably break and replace your operating system many times getting your graphics/ sound/ network card working and that’s more grist to the mill learning how your operating system works.

Don’t apologise- it’s just feedback

I’m cross posting this to my team’s blog which can be found here to bring together my two worlds of programming and Linux-geekery with the Involvement and experience in UK health services which I use programming and Linux-geekery for in my job. Here it is, a story from a meal out in a pub and the lessons the NHS might learn from it.

I witnessed a rather amusing event after a meal in a pub last week, but thinking about it the next day I thought perhaps there are some lessons in it.

A man approaches the bar after eating his meal, wishing to pay, and asks “Do you have a feedback form?”. It’s only a village pub, not the sort of place you’d really expect to have a feedback form. They look a little bit baffled and suggest he could email. Unperturbed, he rattles off three complaints, counting each off on his fingers as he goes.

They apologise, and he responds “You don’t have to apologise, it’s just feedback. But I don’t think I’ll be coming back”. And with that he walks off, presumably never to be seen again.

The incident stuck with me for a couple of reasons. Firstly, he clearly felt quite irate. His complaints, to be honest, were pretty valid and I basically agree with most of what he said. I had a pleasant evening myself so will be going back, but he was essentially spot on with his assessment of the experience. Despite being irate, however, he clearly had no desire for an apology, since he dismissed the offer of one.

Secondly, because he felt irate, the whole experience was quite uncomfortable for everyone. You could see the bar staff (all junior in age and seniority, the manager being inside the kitchen somewhere) were quite taken aback at his manner and didn’t know quite how to respond.

Thirdly, although he clearly wanted to feed back, and didn’t even seem necessarily to want to vent his spleen in person (given that he first asked for a feedback form), he wasn’t really interested in improving the venue for his own benefit (as regular customers might) since he vowed never to return.

So what can the NHS learn from all this? I think there are a few lessons.

Firstly, although feedback forms are often criticised for being impersonal, it’s clear that in this situation it would have helped the staff by removing them from this confrontational situation. The individual in question clearly didn’t want an apology, or compensation, or even to see improvements on their return, so feeding their very accurate impressions of the venue back on a form would have spared the staff the awkwardness of meeting this challenge face to face.

Secondly, it’s a good reminder that everybody has their own idiosyncratic relationship with feedback. Some people just want to have a rant at somebody and get it off their chest. Some people want to constructively engage and keep using a service and watch it improve. Some people just want an apology. Some people (as in this case) just have a good assessment to share and feel natural about sharing it on a form or face to face, and have no interest in apologies, or improvements, or anything else.

Thirdly, it just goes to show that good feedback can be found anywhere. It was quite a difficult situation and proved impossible to resolve face to face, with the poor old staff just looking uncomfortable, and the man disappeared into the night before they’d even replied at all. Nonetheless, he was spot on and I certainly hope that they do make all the changes which he suggested ready for my next visit.

Downloading Lucida Console on Ubuntu

Well, it’s been a horribly long time since I blogged anything. There’s another small chaos generator in the house and he and his older brother are keeping me pretty busy.

Anyway, this is a quick post to solve a problem which appears to have no Google Juice at all- downloading Lucida Console for Linux. If you want Lucida fonts generally there’s some stuff here, but at least when I tried it there was no Lucida Console. There are various bits of outdated and broken links on the subject, and I’m pretty sure one of the sites I was visiting tried to give me a Windows virus, so be careful out there, nonetheless I have found and installed it successfully.

The download that worked and didn’t try to infect my computer is here. I installed it following the instructions here (basically just pop the file in /usr/share/fonts/).

And is how you install Lucida Console on Ubuntu. Hopefully this will work its way up Google’s list and save somebody some head scratching (some of the links on the first page were from 2008, needless to say the links and instructions in them did not work).