Below are the five most recent posts in my weblog. You can also see a chronological list of all posts, dating back to 1999.

I wrote about budgeting nine years ago and I've been a little reluctant to write about it again: by far, it's the blog post that has attracted the most requests from people asking me to link to their blog, site, or service.

I wasn't good at budgeting then and I'm still not good at it now, although I have learned a few things in the intervening time. Those things more properly relate to accounting than budgeting (so there's the first thing: I learned the difference!). I wanted to write about some of the things I've learned since then, starting with our family's approach to pooling income.

Pooling

From talking to friends about how they manage stuff, this doesn't seem to be a common approach. We pay all our income into a shared account. We agree on an amount of "play money" that we can individually spend on whatever we like, and we pay that amount to ourselves from the shared account every month. Crucially, the amount we pick is the same for each of us, irrespective of our relative incomes. All of our shared family expenses come out of the shared account.

Some of my friends, especially (exclusively) the bread-winners, find this a bit alarming. One of the things I like about it is that whichever partner earns less than the other is not disadvantaged in terms of their discretionary spending. When my wife earned less than me, and I believe structural sexism was a contributing factor to that, that impacted us both equally. When my wife was not earning a salary at all, but was doing the lion's share of bringing up our children, she has the same discretionary spend as I do. Apart from the equity of it, there's a whole class of gripes and grumbles that some of my friends have about their partner's spending habits or money management that we completely avoid.

Tags:

Despite my best efforts, I often end up with a lot of branches in my git repositories, many of which need cleaning up, but even so, may which don't. Two git configuration tweaks make the output of git branch much more useful for me.

Motivational example, default git behaviour:

🍊git branch
  2021-apr-cpu-proposed
  OPENJDK-159-openj9-FROM
  OPENJDK-312-passwd
  OPENJDK-407-dnf-modules-fonts
  create_override_files_in_redhat_189
* develop
  inline-container-yaml
  local-modules
  mdrafiur-pr185-jolokia
  openjdk-containers-1.9
  openjdk-rm-jolokia
  osbs-openjdk
  release
  signing-intent-release
  ubi-1.3-mergedown
  ubi-11-singleton-jdk
  ubi8.2
  update-FROM-lines
  update-for-cct-module-changes-maven-etc

The default sort order is alphabetical, but that's never useful for the repositories I work in. The age of the branch is generally more useful. This particular example isn't that long, but often the number of branches can fill the screen. git can be configured to use columns for branch listings, which I think generally improves readability.

🍊git config --global branch.sort authordate
🍊git config --global column.branch auto

After:

🍊git branch
  update-for-cct-module-changes-maven-etc   signing-intent-release
  openjdk-rm-jolokia                        local-modules
  ubi8.2                                    mdrafiur-pr185-jolokia
  ubi-11-singleton-jdk                      OPENJDK-312-passwd
  ubi-1.3-mergedown                         create_override_files_in_redhat_189
  OPENJDK-159-openj9-FROM                   2021-apr-cpu-proposed
  openjdk-containers-1.9                    OPENJDK-407-dnf-modules-fonts
  inline-container-yaml                     release
  update-FROM-lines                       * develop
  osbs-openjdk
Tags:

I woke up this morning to a lovely little gallery of pictures of our children that my wife had sent me via WhatsApp.

This has become the most common way we interact with family photos. We regularly send and receive photos to and from our families via WhatsApp, which re-compresses them for transit and temporary storage across their network.

The original photos, wherever they are, will be in a very high quality (as you get on most modern cameras) and will be backed up in perfect fidelity to either Apple or Google‘s photo storage solutions. But all of that seems moot, when the most frequent way we engage with the pictures is via a method which compresses so aggressively that you can clearly see the artefacts, even thumbnailed on a phone screen.

I still don’t feel particularly happy with the solution in place for backing up the photos (or even: getting them off the phone). Both Apple and Google make it less than convenient to get them out of their respective walled gardens. I’ve been evaluating the nextCloud app and a Nextcloud instance on my home NAS as a possible alternative.

It's been more than a year since I wrote about Opinionated IkiWiki, a pre-configured, containerized deployment of Ikiwiki with opinions. My intention was to make something that is easy to get up and running if you are more experienced with containers than IkiWiki.

I haven't yet switched to Opinionated IkiWiki for this site, but that was my goal, and I think it's mature enough now that I can migrate over at some point, so it seems a good time to call it Version 1.0. I have been using it for my own private PIM systems for a while now.

You can pull built images from quay.io, here: https://quay.io/repository/jdowland/opinionated-ikiwiki The source lives here: https://github.com/jmtd/opinionated-ikiwiki A description of some of the changes made to the IkiWiki version lives here: https://github.com/jmtd/ikiwiki/blob/opinionated-doc/README.md

Tags:

I'm writing up a PhD deliverable (which will show up here eventually) using LaTeX, which is my preferred tool for such things, since I also use it for papers, and will eventually be using it for my thesis itself. For this last document, I experimented with a few packages and techniques for organising the document which I found useful, so I thought I'd share them.

What version is this anyway?

I habitually store and develop my documents in git repositories. From time to time I generate a PDF and copy it off elsewhere to review (e.g., an iPad). Later on it can be useful to be able to figure out exactly what source built the PDF. I achieve this using

\newcommand{\version}{\input|"git describe --always --dirty"}

And \version\ somewhere in the header of the document.

Draft mode

The common document classes all accept a draft argument, to enable Draft Mode.

\documentclass[12pt,draft]{article}

Various other packages behave differently if Draft Mode is enabled. The graphicx package, for example, doesn't actually draw pictures in draft mode, which I don't find useful. So for that package, I force it to behave as if we were in "Final Mode" at all times:

\usepackage[final]{graphicx}

I want to also include some different bits and pieces in Draft Mode. Although the final version won't need it, I find having a Table of Contents very helpful during the writing process. The ifdraft package adds a convenience macro to query whether we are in draft or not. I use it like so:

\ifdraft{
This page will be cut from the final report.
\tableofcontents
\newpage
}{}

For this document, I have been given the section headings I must use and the number of pages each section must run to. When drafting, I want to include the page budget in the section names (e.g. Background (2 pages)). I also force new pages at the beginning of each Section, to make it easier to see how close I am to each section's page budget.

\ifdraft{\newpage}{}
\section{Work completed\ifdraft{ (1 page)}{}} % 1 Page

todonotes

Two TODO items in the margin

Two TODO items in the margin

Collated TODOs in a list

Collated TODOs in a list

The todonotes package package is one of many that offers macros to make managing in-line TODO notes easier. Within the source of my document, I can add a TODO right next to the relevant text with \todo{something to do}. In the document, by default, this is rendered in the right-hand margin. With the right argument, the package will only render the notes in draft mode.

\usepackage[textsize=small,obeyDraft]{todonotes}

todonotes can also collate all the TODOs together into a single list. The list items are hyperlinked back to the page where the relevant item appears.

\ifdraft{
\newpage
\section{TODO}
  This page will be cut from the final report.
  \listoftodos
}{}
Tags:

Older posts are available on the all posts page.


Comments