Blog Title

L-System Explorations

2026-07-14T17:46:58Z

L-System Explorations

A couple of years ago, I briefly played with a Python script to generate svgs based on L-Systems. The code was crude, generated a worrying amount of swastika-like images but it was fun to play with. The initial script suffered some logical issues, such as miss-applying rules, not using the extended syntax, and having a crude method of image generation - calling the script would generate a pseudo-random result each time. At the time, these were shortcomings that, though mildly annoying, were easy enough to work around through brute-forcing the script; generating hundreds of images, and picking out the most interesting ones.

Last week, I returned to the idea, fixing logical bugs, and building out functionality to explore the idea more. Beyond fixing the logical issues, my boals were:

a defined CLI interface where rules and axioms can be specified
extend the L-System grammar to include angle and scale change commands
Develop methods to take an existing image and produce variant forms of it

My implementation is available here.

The script still has randomness at its heart, but it's now possible to create fractal-like images with a greater degree of control:

Similarly, more traditional "nature-like" images are possible:

Using the Script

Calling the script with no parameters retains the original behaviour; a random set of rules will be created. The rules are validated to ensure pushes and pops are matched, and opposing directives are not placed next to each other (e.g., + and -).

python3 lsys.py

There is a configuration file which sets defaults. You can either update these configuration items, or pass the parameters directly to the script. For instance

# Number of iterations to apply the L-System rules to the axiom tree
RECURSION_DEPTH = 13

in config.toml is equivalent to passing --recursion 13 to the script:

python3 lsys_main.py --recursion 13

The resulting file will have a comment describing the rules to generate it:

<!--
TITLE: LSYS PARAMS
PARADIGM: geometric
N: 13
AXIOM: F
RULES: {'F': 'FF+'}
INITIAL_ANGLE: 90
ROTATE_ANGLE: 120.0
LINE_LENGTH: 150
CREATED: 2026-07-17 18:51:54
-->

You could use these definitions to manually create a variation, but there is a --read option which'll do this for you:

❯ python3 lsys_main.py --read output/F→FF+.svg

which outputs the following:

--rules "'F': 'FF+'" --axiom F --recursion 13 --initial-angle 90 --rotation 120.0

which can then be tweaked to generate variations on the first image.

Perhaps more usefully, there is also a --variant flag which will generate a variant of the image, based on the original rules:

❯ python3 lsys_main.py --variant output/F→FF+.svg

there is also an --iterate flag which will generate a series of images, each one a variant of the previous one:

❯ # create five variants of the original image
❯ python3 lsys_main.py --iterate output/F→FF+.svg -n 5

All of these features and more can be explored using the script's --help flag:

L-System SVG Generator

options:
  -h, --help            show this help message and exit
  --rules RULES         User-defined L-System rules dictionary (or literal string)
  --axiom AXIOM         Axiom for the L-System
  --initial-angle INITIAL_ANGLE
                        Initial angle for the L-System
  --rotation ROTATION   Rotation angle for the L-System
  --recursion RECURSION
                        Recursion depth for the L-System (overrides config)
  --title TITLE         Title printed in logs
  --paradigm {geometric,stochastic,extended-geometric,extended-stochastic}
                        Rule generation mode
  --bleed BLEED         Margin padding (in mm)
  --options-per-rule OPTIONS_PER_RULE
                        Rule variations per char for stochastic
  --ppmm PPMM           Pixels per mm
  --paper-size PAPER_SIZE PAPER_SIZE
                        Paper size width and height (mm)
  --background-color BACKGROUND_COLOR
                        Background color
  --precision PRECISION
                        Decimal places to round geometry
  --angle-divisors ANGLE_DIVISORS [ANGLE_DIVISORS ...]
                        Acceptable divisors of 360
  --output-dir OUTPUT_DIR
                        Directory path for SVG files
  --scale SCALE         Scale multiplier for length (< >)
  --angle-increment ANGLE_INCREMENT
                        Angle increment for rotation ( ( ) )
  --weight-increment WEIGHT_INCREMENT
                        Weight increment for line thickness (# !)
  --read READ           Read an SVG file and output the command line arguments to recreate it
  --variant VARIANT     Generate a systematic variant of an existing SVG file
  --iterate ITERATE     Progressively generate iterations of an existing SVG file
  -n, --iterations ITERATIONS
                        Number of iterations to generate (used with --iterate)
  --filename {datetime,rules,unix}
                        Syntax for generating output filenames

Agile Manchester 2024

2024-05-25T17:46:58Z

I've been working in Agile development for a few years, but have never really "got it". The models, frameworks, methodologies always felt un-applicable, or worse, an exercise in kabuki theatre that required extra admin. This is the first Agile conference that I've attended, and it massively helped to reframe my understanding of Agile, and how we can use it.

Rewilding Agile

speaker: Dave Snowden

First day, first talk. Dave's talk centred on the industrialisation of Agile. The competing standards, "certificate factories", and consultancy firms have ultimately undermined the core principles of Agile. Instead of simplifying, focussing on value, and delivering iteratively, Agile has become a sea of dogmatic jargon that is often more about the process than the product. This hugely resonated with me for a couple of reasons. First, the sea of jargon is something I've tried unsuccessfully tried to navigate. Second, Dave's framing in a wider systemic context was music to my ears. The real world is nowhere near as pure as vendor's marketing materials would have us believe. The tools themselves are not bad, but painstakingly applying them to a complex system is an exercise in futility. Dave's talk was a call to arms; we need to rewild Agile, cross-pollinating methods, finding the best contextual use of tools for our circumstances. Instead of using pre-defined Agile recipes we should be chefs, creating our own recipes from the ingredients that work for us. To provide a framework for this, Dave introduced Hexi. I was enthused that Hexi was described as open-source - this seems like an obvious way of unshackling it from consultancy dogma, although when I tried to find it, I couldn't. Irrespective, I'm looking forward to learning more about it, and seeing how it can be applied to my work.

Painful outcomes: 7 mistakes I made in the shift to value-led development

speaker: Holly Donohue

I loved Holly's talk. Whilst Dave's talk was a call to arms, through using an abstract, scientific model, Holly grounded her talk in her own experiences. The combination of humour, humility and experience made for a compelling talk. There was one slide in particular that immediately made the room relax; Expectation Vs Reality. Holly's talk was one of the many where I was left with a sense of "of course, why would you do anything different?". The reality is that even with self-evident truths, we often fall into the trap of doing the wrong thing. Saying "the quiet bit out loud", and reflecting on our mistakes is a cornerstone of Agile, and Holly's talk was a great example of this. Holly presented seven mistakes she made in the shift to value-led development.

1: Balance Discovery with Relationships

The product mindset centres on value. This is fine in perfect, emotionless environments, but we don't live in a perfect world. Purely focussing on value means we can alienate customers, or weaponise the Product Mindset. Holly recounted being asked for a vanity feature; one she knew would gobble up time and yield no value to customers. The feature, however was requested by a senior stakeholder. Refusing the request in the name of value value would harm an essential relationship. Conversely, developing the feature would result in lost value; the features that added tangible value could not be delivered. Holly offered the following advice; you need to balance value with relationships. However logical your argument, you need to consider the emotional impact of your delivery. building the wrong thing (vanity feature) for the right reasons (to build social capital) is sometimes necessary to keep things moving. This introduces a second tension; once you've set the precedent that value can be undermined how can you ensure that the value-led approach is maintained? Holly suggested that instead of weaponising value, and approach of alternative finding can help find accommodations. Played out, this could be a vanity feature that delivers tangible value to the end-user.

2: Stakeholder bank balance

Building on this, Holly described the importance of stakeholder relationships. Building capital with stakeholders is essential to unblocking progress. Holly suggests that the fastest way to do this is to pay in before you withdraw. By building this capital, you can help ensure that when you need a favour returning, it is there. A clever way to manage this is to have those conversations around collaboration, "how can I help you to help us?". By bringing the person into the process, we can avoid Project Managers working against the team because they are implicitly excluded. On reflection, this is such an obvious point, but it's a trap I've fallen into. Holly noted there was a cost to this, these relationships need actively maintaining, and this can cut into our ability to deliver, however managed correctly, it greases the wheels and removes more fundamental blockers.

3: Don’t let product be a blocker

Development is difficult, knowing what to do, and how to do it is hard. A natural reaction is to build a structure to help guide us. Holly recounted a situation where the what and how were so complex that management were left wondering what was happening - where was the value? Presenting to management that your product team have done lots of valuable research, but have no features yet is a particularly hard-sell. Holly's advice was to flip communications; to focus on the results and impact over the process and discovery.

4: Change is Agile too

The only constant is change. I think it's a common experience that "this isn't working, let's rip it up and start again". Battling against this is hard to do. Games are rarely won by changing the rules half-way through; there isn't the time for teams to master the new rules. Holly's advice was to make small, iterative course-corrections; identify what can be improved, and make small changes to enable this. Alongside this, using metrics to measure these changes is essential. This allows us to see what is working, and what isn't. This approach increases transparency, and helps biulding both agency within the team, and trust with stakeholders.

5: Dogma = Bad

There is always more than one way to skin a cat. Becoming locked into dogma means we are no longer open to new ways of thinking. I think that this links back to the previous point; if we constantly change the rules, or assume we work in a vacuum, we are not open to new ways of thinking. Agile is not agile because you doggedly follow the process, it is agile because you are able to apply them contextually. Holly's advice was to be open to new ways of thinking, to craft, rather than apply solutions. Whilst this is another obvious point, there is a clear temptation to assume "it's not working because we're not following the rules correctly".

6: Shift Happens

Start thinking about what maturity looks like before you are forced to grow up. Holly recounted a story of battling for more agency. When she was "called out" on this, she rapidly had to figure out what agency looked like, how it can be measured and so on. Don't get caught out, think about your own (your team's) perfect future before it is gifted.

7: Don’t burn out

As a product owner, there's a risk of becoming the bottleneck for everything product; being the punching-bag for management, the product team, and finding accommodations. A natural response is to do more. Whilst this may work in the short term, it will result in burn-out. The role is the role, but you have a personal responsibility to avoid burning out. Holly's advice was to be aware of this trap , and actively looking after yourself. Try to find sources of energy, exercise, hobbies, socialising, and so on. This is a marathon, not a sprint.

How we improved our ability to herd cats and deliver at scale

Speakers: Samuel Cann & Liam Dewes

Cross-team collaboration is hard; It's certainly a challenge that I recognise. Samuel and Liam Described a major project to massively engineer the back-end of their highly complex, interleaved systems. This work impacted, and required the cooperation of, many teams. They described starting from a traditional hierarchical structure, and moving to a flatter, more agile one. The key to this transformation was developing a narrative through which the teams could understand the impact and importance of the work, and purposefully align their efforts. To do this, they used the metaphor of the Gordian knot to frame their solution. I think this is a good framing, but they perhaps missed a trick; the Gordian knot was either cut or untied. Their metaphor was to cut the knot, removing the cultural complexity. Their description however suggested they had to untie the knot by identifying a using the leverage point of purpose. Rather than defining ways of working, they gave teams agency to define their own. This resulted in an emergent, rather than imposed, solution. They noted that as work progressed, they were conscious of being a decision making bottleneck, and so they worked to devolve decision making to the teams. Overall, this was an inspiring talk; wrangling hundreds of developers across multiple countries to achieve a single goal is no mean feat.

You can’t talk to me like that: How to hold unbiased, non-leading customer interviews

Speaker: Aras Bilgen

I loved this workshop. Research is something that I feel that I can do much better. I'm glad to say I've never gone down the route of rattling through a numbered list of questions on a clipboard, but I am guilty of leading questions. I often go into interviews with a pre-concieved idea of what the respondent will say, and I fall into the trap of leading them to that answer. My research is almost uniformly done alone, I'll build a mental model of the issues and work back from that. The unknown unknowns are often the details that are change a solution from functionally correct to delightfully useful. Aras' workshop was a great reminder of this. We started with a simple exercise; a simple question which we had to figure out how to research. Working collaboratively in small teams, we developed research themes, supporting questions, and finally adding in prompts and reminders to keep us on track. The value of the team was clear; my hypotheses were gently challenged, and ideas that I simply could not have come to alone enriched the research plan. I'm looking forward to putting this into practice both in my work and in my studies.

Psychological safety: The link between speaking up, complexity and high-performing teams

Speaker: Jitesh Gosai

You know when someone nails a talk? This was one of those times. Jitesh used Prezi to map out the importance of Psychological safety in a team. It's years since I've used Prezi, and I'd forgotten how effective it can be. Jitesh described a familiar situation; teams not realising their potential, and a swirling undercurrent of unspoken issues. They described the importance of understanding what psychological safety actually means. Instead of superficially understanding it as "not being afraid to speak up", they described ingraining it into the culture of the team. they described the importance of having the confidence to speak up, and fostering an environment where it is valued. An interesting point was around the tension between being a "nice" team, or a "blunt" team. I think the devil is in the detail here; One team-member's comfort level is another's discomfort. The key is to understand, and adapt to, the needs of the team. This was one of a number of talks that reinforced the idea of "emergent" solutions; we should be the gardeners of our teams, not the architects.

Nudge theory and influencing empowered teams to do the things that matter

Speaker: Sarah Wells

Wow. Sarah described a transformational journey at the Financial Times. Moving platforms, moving from a monolithic architecture to a microservices, and scaling from ~12 releases per year to ~20,000. Whilst I was picking my jaw up off the ground from this, she moved onto the meat of the talk; how nudge theory was used to support this change. Grounded in research, Sarah described how unifying knowledge, making that knowledge accessible, and making the right thing the easier to do than the wrong thing, were key to the success of the transformation. From simple things such as making essential steps mandatory, through to writing for new hires, the FT used nudges to guide their teams to enable the transformation. This was a fantastic talk, and I'm looking forward reading Sarah's book.

Crafting workshops for connection: collective mosaic making

Speaker: Jaimella Espley

This was a powerful workshop. I went in to the workshop with little idea of what to expect, and I was blown away by the power of the exercise. I spend my professional life talking to people, and appreciate the power of a good conversation. Jamella's workshop showed us the power of tactile, physical objects. I've never been to a Lego Serious Play workshop, but the proxy of building things strikes me as a proxy for engineering solutions rather than appreciating the human element. The mosaic exercise was different; we were asked to choose a piece of beach, and describe how it relates to us. composed a mosaic which described a situation, and related to the wider group the meaning our creations. As we iterated, and engaged with the mosaics, we found that objects became layered with meaning; the framing of colleagues' creations gave us a way of clarifying our own thoughts, and becoming vulnerable in a way that felt safe. I saw the physicality of the exercise as offerin

What's the future?

Speaker: Charles Weir

Not Agile, but thought provoking. Charles described his research to identify trends that will define the future of computing. These ranged from the ubiquity of AI and IoT, through to the importance of privacy and security. We then workshopped these themes to identify which we thought were linked, why, and how they may impact us personally. I have a particularly dim view of the future; I believe technology is advancing more quickly than we can adapt to it. To my mind there's an epochal shift coming that will dwarf the industrial revolution. Instead of concentrating power in the hands of thousands of industry barons working within established social structures, I can see the power being concentrated in the hands of a few conglomerates, who have no desire to do anything other than generate revenue. My view was not shared by the table. The consensus was that the future of computing offers both risk and opportunity. The risk is that we are not able to catch the wave of this change, and are left behind. The opportunity is that we are able to shape the future, and ensure that it is a positive one.

Dysfunction Mapping: A tool for empirical agile change

Speaker: Michael Lloyd

You reach the end of a scrum, and something is wrong. Maybe the scrum missed its goals, testing wasn't complete, or the team is dissatisfied. The temptation is to fix the problem, but the problem is often a symptom of a deeper issue. Michael's talk was a great reminder of the importance of understanding the root cause of a problem. He introduced the concept of Dysfunction Mapping; a tool to identify and address the root causes of problems in a scrum. The tool is simple; you start with a symptom, and work back through the dysfunction, purpose, solution, and measure. The key to this is to identify the root cause of the problem, rather than the symptom. This is a common trap; we see a problem, and we fix it. The problem is that the problem is often a symptom of a deeper issue. Michael's talk was a great reminder of the importance of understanding the root cause of a problem.

Dysfunction mapping is something I want to try in my work. I find myself surrounded by symptoms, but defining how to address them is often difficult. Dysfunction mapping looks like a great way to improve systemic issues rather than treating the symptoms.

Guiding stakeholders along in your agile product development journey

Speaker: Karim Qurie

There's a tension between governance and delivering features that users want. I've seen both sides of this; products that are so user driven that they Frankenstein together a solution that is a nightmare to maintain, and products that have so much red tape that they end up in a swamp of slow, painful delivery that alienates the users. In both cases, the product becomes increasingly unfit for purpose. Karim's talk was a great reminder of the importance of balancing this tension. He described a situation where the product team were delivering the features asked for the loudest voice, or those that knew the shortcuts to asking the right person. This resulted in a product that was increasingly reactively developed. Karim took a leaf out of the ITIL book, and introduced a a feature request process. Users had a single, open channel to request features. Other mechanisms were shut down to force users to use this channel. There were two key reasons that this was successful.

1. Transparency

Requests were visible to all users. This meant that users could see what was being requested, if their idea had already been requested, and where it was in the backlog.

2. Alignment with Metrics

Requests had to be aligned with the North Star metric. This meant that some requests, whilst reasonable were rejected because they did not align with business goals.

3. Communication

Combining the above two points, Karim was able to reinforce the goals of the organisation. This meant that the product teams were able to deliver features that satisfied the users, and the business.

Karim noted that the process broadly worked for both product and platform teams, though needed adapting for the Platforms he managed. The ownership of the platform meant that extra care was needed to ensure that the platform was delivering the right features.

Installing Python 3.11 on Debian

2022-12-23T17:46:58Z

Python 3.11 has been out for a couple of months now, and I'm keen to try it out. Not only is it reportedly faster, but it also includes Tomllib which is something I want to use for life-logging scripts I'm working on for my zettelkasten.

There's no direct way to install this via apt in Bullseye, so I've two options: use a virtual environment, or install from source.

I could, of course, use Conda (and have done so on my laptop), but the machine I'm going to install onto has more limited resources. I'm using a server with a single core, and mighty gigabyte of memory, and 8 GB of diskspace, so running a full-blown Conda environment is likely to be problematic. Miniconda suggests it needs 400 meg to download and install alone. Once I start creating environments, I'm likely to outgrow my vps. So I'm going to install Python 3.11 from source.

Thankfully, the Python website has all the resources I need, so the installation is a fairly straightforward case of issuing a few commands.

First, I need to install the dependencies:

software-properties-common
wget
pkg-config

sudo apt install software-properties-common wget pkg-config

Then, for the download, unpacking and installation I'll create a temporary directory

mkdir -p ~/scratch
cd ~/scratch

From there, it's simply a case of downloading and unpacking:

## find latest version at https://www.python.org/downloads/source/
wget https://www.python.org/ftp/python/3.11.0/Python-3.11.0.tar.xz
tar -xf Python-3.11.0.tar.xz
cd Python-3.11.0

and finally installing:

## configure and install
./configure --enable-optimizations
sudo make altinstall

You can check the installation by running python3.11 --version:

python3.11 --version

which should return Python 3.11.0

alternative install means that the new version is installed as python3.11 rather than python3, so you can run both the original version and the new one side-by-side. this should mean that the installation doesn't break any existing scripts. As my machine doesn't have any python2, I decided to use update-alternatives to make python point to the new python3.11:

sudo update-alternatives --install /usr/bin/python python3 /usr/local/bin/python3.11 1

That step's optional, and certainly not for everyone, but it means that I can run python3.11 by simply typing python at the command line - perfect for my lazy fingers.

sudo on AWS

2021-02-17T12:46:58Z

While following the Linux Upskill challenge, I came across some unexpected behaviour: issuing sudo <command> didn't prompt me for a password. No problem I thought; I simply need to set a password for my account. While I'm thinking of it, let's update the password for root too, after all our ec2 instance isn't using a firewall yet.

su - root
passwd root
passwd ubuntu
exit

Passwords duly set, the password wasn't prompted:

Let's check I'm in the sudo group:

So there must be some config that means I'm not prompted for a password. Let's look at the etc/sudoers file:

cat /etc/sudoers

There's nothing in there that is obviously preventing the password prompt. This question on Stack Overflow suggests that the problem may be a file in /etc/sudoers.d. Let's look for all instance of NOPASSWD

grep -rl NOPASSWD /etc/sudoers.d

Output

/etc/sudoers.d/90-cloud-init-users

Let's look at the file (note the lazy history expansion):

more $(!!)

Output

# User rules for ubuntu
ubuntu ALL=(ALL) NOPASSWD:ALL

This line means I'll never be prompted for a password. Let's fix that by commenting it out.

su - root
vi /etc/sudoers.d/90-cloud-init-users

Oh! The file isn't writeable. I could use visudo to edit it, but that is defaulting to use nano. Ugh, no thanks.

Instead, let's check, and fix the file permissions

ls -l /etc/sudoers.d/90-cloud-init-users

It's owned by root, but root cannot write to it. Let's temporarily make the file writeable:

chmod 640 /etc/sudoers.d/90-cloud-init-users

Now we can edit it, and return the permissions

vi /etc/sudoers.d/90-cloud-init-users
chmod 440 /etc/sudoers.d/90-cloud-init-users
exit # exit the root acct, we don't need it any more

and test that we are being prompted for the password correctly:

sudo apt update

Linux Upskill Challenge

2021-02-16T21:44:47Z

With the pandemic, there have been loads of courses that have been made temporarily free. It can be difficult to separate the wheat from the chaff; video courses are better than grinding through dense documentation, but not as effective as practise. Enter the Linux Upskill Challenge. The challenge is a good mix of clear instructions and community support that gives a good grounding in Linux Sysadmin.

As a linux user, there was a temptation to simply use my own machine. This however runs contrary to the spirit of the challenge. Instead, creating and maintaining a virtual private server gives a far more authentic experience of Linux System Administration. Although it's the first day, I have found the experience of setting up an ec2 instance on AWS invaluable.

I'm keeping a repo of my notes here The repo also includes a simple script to manage ec2 instances straight from the command-line rather than use the the web interface.

Terminal Shortcuts

2021-02-15T14:52:05Z

I'm slowly making my way through the Linux Upskill Challenge, and coming across some basic stuff I've completely missed before.

On a professional basis, I'm using keyboard shortcuts all the time. Whether it's snapping (super+arrow key), minimising open windows (super + d), or any of the myriad ctrl + ... combos that are second nature to most users. When it comes to the command-line however, I only knew one: ctrl+c. Whilst this has done me fine for the past ten years, there's far more to prompt shortcuts. Although some of the below may have limited use-cases I have a new favourite way of clearing the prompt (ctrl+l).

Combo	Effect
`ctrl` + `l`	clear screen (equivalent to the `clear` command)
`ctrl` + `z`	send job to background (equivalent to appending a `&` to a command )
`ctrl` + `d`	Log out of the current session (equivalent to `exit` command)
`ctrl` + `a`	Move the cursor to the beginning of the line (equivalent to pressing the `home` key)
`ctrl` + `u`	delete backwards to the beginning of line
`ctrl` + `k`	delete forwards to the end of line
`ctrl` + `w`	delete previous word (like `db` in `vi`)
`ctrl` + `left`	move back one word
`ctrl` + `right`	move forwards one word
`ctrl` + `y`	pastes the buffered output of `ctrl` + [`u` \| `k` \| `w`]
`ctrl` + `p`	cycle through previous commands (similar to pressing the `up` arrow)
`ctrl` + `n`	cycle through next commands (similar to pressing the `down` arrow)
`ctrl` + `r`	reverse search history (like `history
`ctrl` + `r`	forward search history (like `history
`ctrl` + `s`	suspend output updating screen
`ctrl` + `q`	resume output updating screen
`ctrl` +`x`,`e`	open `$EDITOR`

Maintaining a Zettelkasten using Bash and Vi

2021-01-17T18:31:40Z

I've mentioned earlier that I was trying to use 'basic' tools like Vi and Bash preference to gui heavy tools. Describing Vi and Bash as simple tools does them a disservice. Bash is powerful enough to be used as a full programming language,even before you factor in the range of external programs (sed, perl, awk, ad infinitum) that it can call on. Vi has an established vimscript language and a long enough lifespan to ensure anything you are trying to do has been attempted, and likely documented before. Can these two tools be enough to manage a Zettelkasten though?

What's a Zettelkasten?

I'm getting ahead of myself. Zettelkasten is the German term for 'slip box'. It's the colloquial term used for managing and storing notes. The concept spans back five hundred years or so to Conrad Gessner, and his bibliography, but it's Niklas Luhmann who raised the profile of the idea. In simple terms, knowledge is added to cards. Each card is contains a contained idea, but each card may reference others. For instance a card about the stained glass used in Notre-Dame may reference a cards about medieval glass making, religious iconography in the 13th century, lead smelting, and so on. Storing the information is important, but linking ideas and knowledge is where the system comes into its own. Rather than writing an encyclopedia of knowledge, you end up writing something much closer to a wiki. Ideas are captured concisely, reviewed regularly, and linked widely. This book by Sönke Ahrens explains the process, and strategies in far greater (but wonderfully digestible) detail.

What Does an Electronic Zettelkasten Look Like?

If we're looking at making a wiki; that is absolutely possible, perhaps even in Vi alone. Using markdown files, it is possible to king files together simply with minimal effort. Managing and searching files however might need more heavy lifting. The blog here was an excellent resource; the author covers all the functionality I wanted, specifically, naming of cards, and finding them.

In large part, I've simply copied the code wholesale. The fuzzy-find/insert function is perfect for my needs:

"
" see https://www.edwinwenink.xyz/posts/48-vim_fast_creating_and_linking_notes/
"

" CtrlP function for inserting a markdown link with Ctrl-X
function! CtrlPOpenFunc(action, line)
   if a:action =~ '^h$'
      " Get the filename
      let filename = fnameescape(fnamemodify(a:line, ':t'))
    let filename_wo_timestamp = fnameescape(fnamemodify(a:line, ':t:s/\d+-//'))

      " Close CtrlP
      call ctrlp#exit()
      call ctrlp#mrufiles#add(filename)

      " Insert the markdown link to the file in the current buffer
    let mdlink = "[ ".filename_wo_timestamp." ]( ".filename." )"
      put=mdlink
  else
      " Use CtrlP's default file opening function
      call call('ctrlp#acceptfile', [a:action, a:line])
   endif
endfunction

let g:ctrlp_open_func = {
         \ 'files': 'CtrlPOpenFunc',
         \ 'mru files': 'CtrlPOpenFunc'
         \ }

Although I tried the file naming function, I found that my combination of multiple zettelkasten (One for work, one for study and a general one) meant a function with hardcoded path wasn't workable. I decided that a shell function would be easier to maintain across devices. a simple function to decide what ZETTEL_DIR is based on context (is pwd in a study/work path) means the card is created in the correct directory.

# New Zettle card
nz() {
  DATE_STR=$(date +"%Y%m%d%H%M")
  TITLE=$*
  CLEAN_TITLE=$(echo $* | sed 's/ /_/g'| tr '[:upper:]' '[:lower:]')
  ZETTLE=$ZETTLE_DIR$DATE_STR'-'$CLEAN_TITLE.md
  echo '# '$TITLE > $ZETTLE
  vi $ZETTLE
}

Revisiting Jekyll Blog Scripting

2020-12-31T19:44:07Z

It's nearly five years since I first started blogging using Jekyll. Although I haven't exactly been prolific in that time, I have found that my earlier attempts at scripting are too brittle to be portable. every time I try to use them somewhere new, I end up manually bodging a fix that rarely finds it's way back to the original script.

Rather than polish the current rat's nest of scripting and aliases, I wanted a single solution that can be dropped into any shell, so I can use it anywhere, whether it is Termux on my phone, WSL, an old Macintosh, or Linux.

Over the past five years, my tool choices have changed. Rather than using Atom to write markdown I now write almost exclusively in vim. Similarly, my increasing comfort on the command line means I am better able to figure out a way of starting a Jekyll server at the same time, and in the same shell as writing the blog post itself.

Running Jekyll alongside Vi could be done in a number of ways; forking a shell, making the vim process run in a sub-shell, a different session, or using the ! syntax to run Jekyll within vim itself. Whilst any of these would achieve the broad aims of having two processes running simultaneously, I couldn't find a solution to trigger both with minimal effort. In the end, the solution was quite simple; tmux. A tmux session with both processes can be triggered from a single command. By sourcing this command at the point the shell loads, I can easily start writing without trying to remember what sequence of events I need to trigger.

The Script

this script is stored in ~/.shell_functions which is sourced in my ~/.bashrc. There's no reason that you couldn't have the script within your ~/.bashrc; I only have it in a separate file to make it easier to maintain.

# New Blog post
## need to `export $BLOG_DIR` in ~/.bashrc

jekserve() {
  xdg-open http://127.0.0.1:4000/ &
  cd $BLOG_DIR../
  bundle exec jekyll serve
}

create_post() {
  cd $BLOG_DIR
  title="$*";  dte=`date +%Y-%m-%d`;  tme=`date +"%T"`
  safe_title=$(echo $title |sed 's/ /_/g'|  tr '[:upper:]' '[:lower:]')
  echo -e "---\nlayout: post\ntitle:  ""$title""\ndate:   " $dte $tme "\ncategories: writing\nsynopsis: "change me"\n---">> $dte-$safe_title.md
  vi $dte-$safe_title.md
}

nbp() {
  post_title=$*
  echo $post_title
  tmux new-session -d
  tmux split-window -v
  tmux resize-pane -D 10
  tmux send -t 0:0.1 "jekserve" C-m
  tmux send -t 0:0.0 "create_post $post_title" C-m
  tmux select-pane -U
  tmux -2 attach-session -d
}

Splitting the script into three functions should make it easier to maintain/debug. To write a new blog post I simply now need to nbp A Blog Post Title, and start writing straight away.

vim Configuration

2020-06-09T00:00:00Z

My vim Configuration

The more I use vim, the more handy tricks I pick up. I'm currently using vim to write a 10,000 word assignment; something I would have struggled to consider months ago, but with a reasonably minimal configuration combined with some handy configuration tweaks, my experience of writing for longer periods in a terminal prompt isn't too shabby.

My path to learning vim has been a relatively slow one. There were a few aha moments, but for the most part, progress was a result of concerted effort to build both knowledge and muscle memory. If you on a similar journey to learn vim, these are the things that I found most useful

learn the basics of movement.
learn how buffers work (buffers seriously improve your copy/paste game)
don't blindly paste other people's .vimrc into your own, but
do experiment

Of course, vim isn't for everyone. It wasn't for me until I found myself having to use it for work. Choosing a modal editor when you have access to shiny tools like VSCode can be a difficult ask especially when you don't grok vim. I'm hardly an expert, but I've got to a point where I can productively work without having to consciously thinking about it. An unexpected benefit to vim is that I find myself working more quickly with a higher level of concentration than when using VSCode, or shudder Word. There's no secret to this, it's purely a result of a minimally decorated terminal having a far smaller cognitive overhead; by default, there is no visual cruft, decorated menus, or even fancy powerline prompts. I only see what I am actively working on. Extending this idea, I have configured my .vimrc along the following principles:

simple: Don't add plug-ins, or reams of viml, use standard configuration where possible
minimal: Only configure elements that provide active benefit
flexible: be open-minded enough to realise my configuration will evolve

Below are three pieces of my configuration that i think demonstrate these principles:

Spell highlight toggle

The majority of my vim use is in writing markdown. Using spell is key for picking up typos, and simple grammatical errors. It's not as advanced as the tools in Word, but on the other hand, I don't have to deal with the overheads or cost of Word. Out of the box spell is fairly decent, but having the visual problems shouting out at me whilst I'm trying to get ideas out is a distraction that I find slows down my writing. I could configure my colours to be less startling, but that doesn't solve the problem, and arguably makes spotting bad spellings more difficult. What I really want is spell check that is off by default, but can be quickly toggled when needed

`statusline` style information in the ruler

By default, vim shows a minimally decorated ruler that contains the bare minimum of information. You can add a more informative statusline that shows, I believe more useful information, but this is at the expense of screen real estate. On my laptop, the combined status and ruler take up the better part of 10% of the entire space. Instead, I take a minimal subset of information, and place that in my statusbar:

The ruler contains word count(650 in this example), whether the files is modified ([+]), and the line number:column. This is perfect for my needs, anything more would be a waste.

Toggle Explorer

Usually, I work on a single file, and don't need to think about jumping between directories; I'm writing essays, not complex code-bases. When I am writing longer, more complex documents, I do prefer to split sections out into separate files. For instance, I'm working on a 10,000 word essay that is split thematically into six files. This approach lets me focus on one thing at once. Whilst vim handles this magnificently, a couple of lines of configuration means I can use :find or :edit to open different files with minimal (tab completing) fuss, having a dedicated file browser that I can toggle is a brilliant tweak for me; I can remind myself of the document structure, and open new files with a few keystrokes (<C-E> to open the browser, j, k for selecting the right one, and enter to open it)

What's Missing

I alluded to my configuration being a living thing; as my usage evolves, it should be matched by the configuration. There are a few things I want to investigate further, particularly around getting a better workflow between pandoc and vim. Things such as pandoc are top of the list; Vim-Pandoc is something I want to integrate, together with some sort of workflow around rendering documents automatically.

My full configuration can be found here

Keeping a Journal in Vim

2020-05-29T00:00:00Z

For me, keeping a simple journal, provides a easy way of reflecting on the day. Done right, keeping a diary has been linked to creativity, and reflective learning. Moreover, recording one good thing per day has both mental health, and positive habit forming benefits.

Core to my ability to maintain the habit of keeping a journal is making it as easy as possible to add / maintain entries. My journal is a brief affair that balances the main benefits of capturing and reflecting on the day's events with the effort required to do so.

Why Vim?

Given this focus on simplicity, why would I consider Vim? Surely I'd be stuck in a single entry forever whilst I try to exit?

In fact Vim is perfect for the task of journaling; it is readily, freely available on my phone via termux, my laptop, or at a push via ssh. Whilst the same may be said about other editors, Vim's super power as far as journaling is that it can apply templates contextually. Tying these templates together with Vim's ability to process shell commands, makes it is possible to create a personalised entry with effectively zero effort. Using a editor in a terminal means I don't have the visual cruft of a bespoke app with the associated cognitive load and interaction cost. Finally, rolling my own journal process, allwos me to fully own my data. I'm not tied to a proprietary platform, and don't have to worry about about how the data is used.

Ingredients

The solution I have come to is based on three apps:

Vim: to create and populate journal entries
rclone to save entries to a cloud provider
Bash to handle file creation, and invoking vim/rclone

The first step would be to create a template. For the journal, this is essentially a journal entry without the detail. The template may be placed anywhere, but it makes sense to keep it in your .vim directory. mine is stored in ~/.vim/templates/journal.skeleton. Wherever you store yours, it needs sourcing in your local functions.

## What happened


## What went well


## What didn't go well

Next, we need to create a function to invoke the template. My function is designed to only trigger if I create a new file in a specific directory, or any of its subdirectories.

This function is saved in ~/.vim/local_functions. Again, you can save yours elsewhere, but you'll need to make sure your .vimrc is sourcing the correct path


augroup journal
    autocmd!

    " populate journal template
    autocmd VimEnter */journal/**   0r ~/.vim/templates/journal.skeleton

    " set header for the particular journal
    autocmd VimEnter */journal/**   :call JournalMode()

    " https://stackoverflow.com/questions/12094708/include-a-directory-recursively-for-vim-autocompletion
    autocmd VimEnter */journal/**   set complete=k~/documents/journal/**/*

augroup end

we'll source this function in our .vimrc

source ~/.vim/local_functions

So far so good. If I create a file under any sub/directory of ~/documents/journal, vim should paste the template as it opens. To make the journal entries a bit more specific why not add the date? There's a few ways to achieve this, but in the spirit of keeping things simple, why not take the filename, and process that? Let's create the function, again under ~/.vim/local_functions

" set header title for journal & enter writing mode
function! JournalMode()
    execute 'normal gg'
" filename in format dd-mm-yy.md 
" add a line to file in format ## dd-mm-yy    
    let filename = '##' . ' ' . expand('%:r')
    call setline(1, filename)
    execute 'normal o'
endfunction

Now all we need is a script that will:

create the file
open it in vim
save it to our cloud storage

#!/bin/sh

# A Script to create a journal entry, open it in vim, and save it 
JOURNAL_DIR='~/documents/journal/'
# each year gets a dir, each month a subdir
ENTRY_DIR=$(date +%Y/%B)
mkdir -p $JOURNAL_DIR$ENTRY_DIR

cd $JOURNAL_DIR$ENTRY_DIR

vim $(date +%d-%m-%y).md
# my rclone is pointing to an instance of OwnCloud
rclone copy ~/documents/journal owncloud:journal

Looking ahead

as I've been using this, I've found myself repeating simple prases. To reduce this repetition, I've added the following abbreviations to my .vimrc

abbr _ok OK day, 
abbr _gd Good day,
abbr _pd Poor day,

The journal process I have at the moment is a near perfect for my needs, it is low enough to not get in the way of keeping the journal itself, meaning I get the benefit without extraneous effort.

Whilst it's ideal at the moment, there are a few things that could further enhance the process, namely:

using a yaml block to capture richer data
encryption of journal entries
data analysis / sentiment analysis of journal entries

For the time being though, it's good enough to be bulding the habit and reflecting on each day.

Blog Title

L-System Explorations

L-System Explorations

Using the Script

Agile Manchester 2024

Rewilding Agile

Painful outcomes: 7 mistakes I made in the shift to value-led development

1: Balance Discovery with Relationships

2: Stakeholder bank balance

3: Don’t let product be a blocker

4: Change is Agile too

5: Dogma = Bad

6: Shift Happens

7: Don’t burn out

How we improved our ability to herd cats and deliver at scale

You can’t talk to me like that: How to hold unbiased, non-leading customer interviews

Psychological safety: The link between speaking up, complexity and high-performing teams

Nudge theory and influencing empowered teams to do the things that matter

Crafting workshops for connection: collective mosaic making

What's the future?

Dysfunction Mapping: A tool for empirical agile change

Guiding stakeholders along in your agile product development journey

1. Transparency

2. Alignment with Metrics

3. Communication

Installing Python 3.11 on Debian

sudo on AWS

Linux Upskill Challenge

Terminal Shortcuts

Maintaining a Zettelkasten using Bash and Vi

What's a Zettelkasten?

What Does an Electronic Zettelkasten Look Like?

Revisiting Jekyll Blog Scripting

The Script

vim Configuration

My vim Configuration

Spell highlight toggle

statusline style information in the ruler

Toggle Explorer

What's Missing

Keeping a Journal in Vim

Why Vim?

Ingredients

Looking ahead

`statusline` style information in the ruler