In
a previous blog post I described the use of virtual
postings to track accidental personal/family expenses. I've always been
uncomfortable with that, and in
hledger 1yr I outlined a potential scheme
for finally addressing
the virtual posting problem.
separate journals
My outline built on top of continuing to maintain both personal and family
financial data in the same place, but I've decided that this can't work,
because the different "directions" (or signs) of accidental transactions
originating from either the family or personal side can't be addressed with any
kind of alternate view on the same data.
To illustrate with an example.
A negative balance in
family:liabilities:jon means "family owes jon". A
coffee bought by mistake on the family credit card will have a negative
posting on the credit card, and thus a positive one on the liabilities
account. ("jon owes family"). That's fine.
But what about when I buy family stuff on a personal card? The other side of
of the transaction is also going to have a positive sign, so it can't be
posted to
family:liabilities:jon: it would have to go to somewhere else,
like
jon:liabilities:family. Now I have two accounts which track versions
of the same thing, and they cannot be combined with a simple transaction
since they're looking at the same value from opposite directions (and signs).
Back when I first described the problem I was using
a single journal file for all my transactions. After moving to lots of separate
journal files (in
hledger 1yr), it's become clearer to me that I don't
need to maintain the Family and Personal data together, at all: they can be
entirely separate journals.
getting data between journals
When I moved to a new set of ledger files for 2023, I needed to carry forward
the balances from 2022 in the form of "opening balance" transactions. This was
achieved by a report on the 2022 data, exported as CSV, and imported into the
2023 data (all following the scheme outlined by
fully-fledged hledger.))
Separate Personal and Family journals need some information from each other, and I
can achieve that in the same way as for opening balances: with an export of
the relevant transactions as CSV, then imported on the other side. HLedger's
CSV import system is flexible enough that we can effectively invert the sign
of liabilities, addressing the problem above.
Worked example
We start with an accidental coffee purchased on the family card (and so this
belongs to the Family ledger)
2022-08-20 coffee
liabilities:creditcard -3
liabilities:jon:expenses:coffee 3
I've encoded the expense category that the Personal ledger will be interested
in (the last bit,
expenses:coffee) as a sub-account of the liabilities
category that the Family ledger is interested in
1 (the first bit,
liabilities:jon). When viewed on the Family side, the expense category is not
interesting, and we can hide it with
HLedger's alias feature2:
alias /^liabilities:jon(.*)$/ = liabilities:jon
It then looks like this from the Family side:
2022-08-20 coffee
liabilities:creditcard -3
liabilities:jon 3
This transaction (and others like it) are exported via
hledger reg -f family/2023-back.journal liabilities:jon: -O csv \
jon/import/family/liabilities.csv
(The trailing colon on
liabilities:jon: is important here!)
In the resulting CSV file, the running example transaction looks like
"55","2022-08-20","","coffee","liabilities:jon:expenses:coffee"," 3.00"," 3.00"
This is then converted into a journal file by
hledger import. The rules file
for the import is very simple: the fields
date,
description,
account1
and
amount are taken as-is;
account2 is hard-coded to
liabilities:family.
The resulting transaction looks like
2022-08-20 coffee
liabilities:jon:expenses:coffee 3
liabilities:family -3
Before this journal is included by the main one, we have to adjust the expense
account, to remove the
liabilities:jon: prefix. The import rules can't do
this
3 , so we use another journal file as a go-between with another alias
rule:
alias /^liabilities.jon:/ =
This results, finally, in the following transaction in the Personal ledger:
2022-08-20 coffee
expenses:coffee 3
liabilities:family -3
avoiding double-counting
There's one set of transactions that we don't want to export across this divide,
and that's because they're already there: any time I transfer money from myself
to the family accounts (or vice versa) to address the accrued debt, the transaction
is visible from both my family and personal statements. To avoid exporting these
and double-counting them, I make sure those transactions don't post to an account
matching the pattern used in the
hledger reg report. That's what the trailing
colon is for: It ensures I only export transactions which are to a sub-account
of
liabilities:jon, and not to the
root account
liabilities:jon itself:
which is where I put the repayment transactions. I could instead use a more
explicit sub-account like
liabilities:jon:repayments or similar, since the
trailing colon is quite subtle, but this works for me.
Wrap up
I've been really on the fence as to whether the complexity of this scheme is
worth it to avoid the virtual postings. The previous scheme was much simpler.
I have definitely made some mistakes with it, which didn't get caught by the
double-entry rules that virtual postings ignore, but they're for small sums
of money anyway.
On the other hand, a lot of the "machinery" of this already existed for getting
opening balances between calendar years, and the gory details are written down
and hidden inside the
Makefile. I also expect that I will continue to see
advantages in having Family and Personal entirely separate, as they can each
develop and adapt to their own needs without having to consider the other side
of things every time.
It's a running experiment, and time will tell if it's a good idea.
I acquired some unusual input devices to experiment with, like a CNC control
panel and a bluetooth pedal page turner.
These identify and behave like a keyboard, sending nice and simple keystrokes,
and can be accessed with no drivers or other special software. However, their
keystrokes appear together with keystrokes from normal keyboards, which is the
expected default when plugging in a keyboard, but not what I want in this case.
I'd also like them to be readable via evdev and accessible by my own user.
Here's the udev rule I cooked up to handle this use case:
This post serves as a report from my attendance to Kubecon and CloudNativeCon 2023 Europe that took place in
Amsterdam in April 2023. It was my second time physically attending this conference, the first one was in
Austin, Texas (USA) in 2017. I also attended once in a virtual fashion.
The content here is mostly generated for the sake of my own recollection and learnings, and is written from
the notes I took during the event.
The very first session was the opening keynote, which reunited the whole crowd to bootstrap the event and
share the excitement about the days ahead. Some astonishing numbers were announced: there were more than
10.000 people attending, and apparently it could confidently be said that it was the largest open source
technology conference taking place in Europe in recent times.
It was also communicated that the next couple iteration of the event will be run in China in September 2023
and Paris in March 2024.
More numbers, the CNCF was hosting about 159 projects, involving 1300 maintainers and about 200.000
contributors. The cloud-native community is ever-increasing, and there seems to be a strong trend in the
industry for cloud-native technology adoption and all-things related to PaaS and IaaS.
The event program had different tracks, and in each one there was an interesting mix of low-level and higher
level talks for a variety of audience. On many occasions I found that reading the talk title alone was not
enough to know in advance if a talk was a 101 kind of thing or for experienced engineers. But unlike in
previous editions, I didn t have the feeling that the purpose of the conference was to try selling me
anything. Obviously, speakers would make sure to mention, or highlight in a subtle way, the involvement of a
given company in a given solution or piece of the ecosystem. But it was non-invasive and fair enough for me.
On a different note, I found the breakout rooms to be often small. I think there were only a couple of rooms
that could accommodate more than 500 people, which is a fairly small allowance for 10k attendees. I realized
with frustration that the more interesting talks were immediately fully booked, with people waiting in line
some 45 minutes before the session time. Because of this, I missed a few important sessions that I ll
hopefully watch online later.
Finally, on a more technical side, I ve learned many things, that instead of grouping by session I ll group
by topic, given how some subjects were mentioned in several talks.
On gitops and CI/CD pipelines
Most of the mentions went to 
On etcd, performance and resource management
I attended a talk focused on etcd performance tuning that was very encouraging. They were basically talking
about the 
On jobs
I attended a couple of talks that were related to HPC/grid-like usages of Kubernetes. I was truly impressed
by some folks out there who were using Kubernetes Jobs on massive scales, such as to train machine learning
models and other fancy AI projects.
It is acknowledged in the community that the early implementation of things like Jobs and CronJobs had some
limitations that are now gone, or at least greatly improved. Some new functionalities have been added as
well. Indexed Jobs, for example, enables each Job to have a number (index) and process a chunk of a larger
batch of data based on that index. It would allow for full grid-like features like sequential (or again,
indexed) processing, coordination between Job and more graceful Job restarts. My first reaction was: Is that
something we would like to enable in 
KDE Elisia snap
For this summer, I ve just made a nice 
Since the fabric was bought online as a remnant, I didn t exactly know what to expect, and was pleasantly surprised by how soft it is: it feels like touching a cloud.
This however means that it felt like working with a cloud, and, well, let s just say I m happy that both patterns were quite simple and I didn t have to deal with fiddly bits.
I was also not so pleasantly surprised by the fact that part of the fabric had a few small holes as if the end of the roll had been caught on something; I was able to cut everything around the holes, other than a small bit that I hadn t noticed and had to be mended. It s not a big deal, but I suspect it s a sign that this fabric may not be as sturdy as it could have been, and that there will be more mending in the future as I wear it.
And then, when I had finished the set I was faced with another problem: taking pictures. For one thing, worn on their own they aren t exactly decent, and then there was the fact that after a week of late spring weather in March, as I was working on summer clothing the temperature dropped and there was even a hint of rain.
I solved this by wearing the new set on top of another set of fitting top and camisole, with matching 
Still, the pictures were taken in quite a hurry, because I wasn t completely freezing, but still pretty cold.
Anyway, I m off to find some other piece of summer wear to make, hoping that it will bring proper rain. :)
Update on 2023-03-23: thanks to Daniel Roschka for mentioning the