The New Adventures of Judy2k

Run Any Project with 'r'

2025-07-28T00:00:00+00:00

This is an article about fish shell</a> customisation. Fish is an alternative to bash, zsh, or powershell. It’s powerful as both an interactive shell, and a scripting language, and I’ll be demonstrating a little bit of both of these domains.</p>

This article demonstrates the creation of an r</code> abbreviation in fish, that will automatically expand to the correct “run” command, based on the files in your current directory. It might be of use even if you don’t use fish as your shell. Maybe it will convince you to try it out!</p>

The Running Man</h2>
I work with a bunch of programming languages
– primarily Python, Rust & JavaScript.
Running these projects is all slightly different.</p>
Here are some examples:</p>

# Python:
</span>uv</span> run a_script_or_something.py
</span>
</span># Rust:
</span>cargo</span> run
</span>
</span># JavaScript:
</span>node</span> run dev
</span></code></pre>
Something I’ve been doing for a few years now is to add a Justfile</a> or a Makefile to each of my projects.
They all follow the same convention, so if I run just run</code> or make run</code>,
it will execute whichever command is appropriate for that particular project.</p>
So that I don’t have to type just run</code> over and over again,
I created an alias.
Now … fish doesn’t really</em> have aliases, it has functions</em>.
The alias</code> fish command just creates a function and puts it in the right place.</p>
# ~/.config/fish/functions/jr.fish
</span>function </span>jr </span>--wraps=</span>'</span>just run</span>' </span>--description </span>'</span>alias jr just run</span>'
</span>  </span>just </span>run $</span>argv</span>; 
</span>end
</span></code></pre>
This is fine, but when I checked the alias documentation</a>,
I saw the following sentence:</p>

If you want to ease your interactive use, to save typing, consider using an abbreviation instead.</p>
</blockquote>
… so I had to check out abbr</a>.</p>
That’s when I got a bit carried away.</p>
Lots of abbreviations</h2>
I immediately set up a bunch of abbreviations for running different types of projects:</p>
abbr --add</span> jr  '</span>just run</span>'
</span>abbr --add</span> mr  '</span>make run</span>'
</span>abbr --add</span> uvr '</span>uv run</span>'
</span>abbr --add</span> cr  '</span>cargo run</span>'
</span>abbr --add</span> nr  '</span>node run dev</span>'
</span></code></pre>
The great thing about abbr</code> over alias</code> is that whereas alias</code> executes the command</em> when you hit enter</em>,
abbr</code> replaces the abbreviation with the command</em> when you hit space</em>.
That means you can view and edit the command before you run it.</p>
Abbreviations also come with some neat features,
like being able to put the cursor in the right spot after expansion.
That means abbr --add gcm --set-cursor 'git commit -m "%"'</code> will expand to git commit -m ""</code>,
with the cursor already between the two quotes, ready for you to write a commit message.</p>
But the five abbreviations above are super-wasteful.
They all “run”,
but I need to decide which shortcut to type out,
based on the kind of project I’m working on.</p>
Wouldn’t it be great if I could just type r</code> and have it automatically expanded to the correct command?</p>
If I type ‘r’, run the project</h2>
Here’s a function I wrote to echo the appropriate command-line based on the available files and folders in my project.</p>
function </span>_expand_run </span>-d </span>"</span>Expand the 'run' abbreviation into a project-specific run command.</span>"
</span>    
</span>    </span>if </span>test -e </span>Justfile </span># Test for a Justfile in the current directory
</span>        </span>echo </span>just run
</span>    </span>else if </span>test -e </span>Makefile
</span>        </span>echo </span>make run
</span>    </span>else if </span>test -e </span>Cargo.toml
</span>        </span>echo </span>cargo run
</span>    </span>else if </span>test -e </span>package.json
</span>        </span>echo </span>npm run dev
</span>    </span>else if </span>test -e </span>.venv
</span>        </span>echo </span>uv run
</span>    </span>end
</span>end
</span></code></pre>
This function assumes it is being run from the project’s top-level directory,
i.e. the directory that contains a Justfile or a Cargo.toml file.
(Don’t worry, I’ll come back to this later.)</p>
Abbr allows you to attach a function to an abbreviation with the --function</code> parameter,
like this:</p>
# When expanding 'r', run `_expand_run` and use whatever that prints out:
</span>abbr --add </span>r </span>--function </span>_expand_run
</span></code></pre>
Now, if I type ‘r’ and hit space,
if I’m in a directory with a Justfile,
it expands to just run</code>.
If, instead, I’m in a directory containing a Cargo.toml file,
it expands to cargo run</code>.</p>
When you’re deep in a project</h2>
The function above worked well for me for a while,
but occasionally it … wouldn’t.</p>
As I pointed out above,
a flaw in the function is that it assumes it is being called from a project’s top-level directory.
Most task runners don’t</em> require this.
I can run just run</code> or cargo run</code> from a deeper directory,
and it doesn’t matter if the Justfile or Cargo.toml file is a directory or two above where I’m working,
the command will find and run them as if</em> my current working directory is the project directory.</p>
If I try that with the expansion function above,
it will get to the end of the if-else block without matching,
echo nothing,
and so the line goes blank. Eventually, I got around to writing a function that recursively searches parent directories for a file or directory with a given name.</p>
It occurred to me later that I probably could have gotten an LLM to write the following for me,
but like some kind of programmer</em>, I wrote it by hand:</p>
function </span>project_file </span>\
</span>    </span>-d </span>"</span>Find a file in parent directories</span>"
</span>    </span># Find a file in the specified directory (or PWD), or any parent directory.
</span>    </span>#
</span>    </span># Usage:
</span>    </span># project_file [-p START_DIRECTORY] [-v] FILENAME
</span>    </span>#
</span>    </span># `project_file FILENAME` will look for 'FILENAME' in the PWD or any parent directory.
</span>    </span># `project_file -p START_DIRECTORY FILENAME` will look for FILENAME in START_DIRECTORY,
</span>    </span># and then all parents of START_DIRECTORY.
</span>    </span>#
</span>    </span># If -v is provided, project_file will print the path of the found file.
</span>    </span># The exit code is 0 if a file was found and 1 otherwise.
</span>
</span>    </span>argparse </span>v/verbose '</span>p/path=</span>' </span>-- </span>$</span>argv
</span>    or </span>return
</span>
</span>    </span>set </span>filename $</span>argv</span>[</span>1</span>]
</span>    </span>if </span>test -z </span>$</span>filename
</span>        </span>echo </span>"</span>project_file: missing FILENAME</span>" >&</span>2
</span>        </span>return </span>-2
</span>    </span>end
</span>
</span>    </span>if </span>set -ql </span>_flag_p </span># Use the -p value, if provided
</span>        </span>set </span>p </span>$(path</span> resolve "$</span>_flag_p</span>"</span>)</span>
</span>    </span>else
</span>        </span># Default to the working directory
</span>        </span>set </span>p "$</span>PWD</span>"
</span>    </span>end
</span>
</span>    </span>for </span>i </span>in </span>(</span>seq </span>1 64</span>) </span># Avoiding an infinite loop
</span>        </span>if </span>test </span>$</span>p </span>= /
</span>            </span># File wasn't found in any parent directory
</span>            </span>return </span>1
</span>        </span>else if </span>test -e </span>"$</span>p</span>/</span>$</span>filename</span>"
</span>            </span># File found. Return
</span>            </span>if </span>set -ql </span>_flag_v
</span>                </span>echo </span>"$</span>p</span>/</span>$</span>filename</span>"
</span>            </span>end
</span>            </span>return </span>0
</span>        </span>else
</span>            </span># File not found here. Check in parent.
</span>            </span>set </span>p </span>$(path</span> dirname $</span>p</span>)</span>
</span>        </span>end
</span>    </span>end
</span>    </span>print </span>"</span>project_file: possible infinite loop. aborted</span>" >&</span>2
</span>    </span>return </span>-1
</span>end
</span></code></pre>
Why isn’t this part of a standard library?</p>
I then hooked this into my expansion function:</p>
function </span>_expand_run </span>-d </span>"</span>Expand the 'run' abbreviation into a project-specific run command.</span>"
</span>    </span>if </span>project_file </span>Justfile  </span># Test if this dir or a parent contains Justfile
</span>        </span>echo </span>just run
</span>    </span>else if </span>project_file </span>Makefile
</span>        </span>echo </span>make run
</span>    </span>else if </span>project_file </span>Cargo.toml
</span>        </span>echo </span>cargo run
</span>    </span>else if </span>project_file </span>package.json
</span>        </span>echo </span>npm run dev
</span>    </span>else if </span>project_file </span>.venv
</span>        </span>echo </span>uv run
</span>    </span>end
</span>end
</span></code></pre>
Summary</h2>
I’ve made my full script</a> available as a gist.
It includes b</code> and t</code> expansions for building and testing projects, too.
Feel free to drop it into your own ~/.config/fish/conf.d/</code> directory.
Don’t forget to start a new fish session to pick up the script.
You might also want to edit the expansion functions to match your own tools and conventions, too.</p>
I’ve found r</code> for “run”, b</code> for “build”, and t</code> for “test” reduces cognitive load more than I would have expected,
especially when switching between projects.
Don’t expect your friends to be impressed, though
– it’s so fast, they won’t see it unless you explain it to them!</p>
It’s possible to rewrite these expansions as standalone functions or scripts,
but I like the way abbreviations work as a smart autocomplete.
I’ve also considered extending the expansion functions to parse the Justfile or package.json for available tasks.
But I’ve decided to stop for now!</p>
The abbr</code> command can do a lot more than I’ve shown here.
I highly recommend checking out the abbr docs</a> to see what it can do.
I’ve also become intrigued by the ability to call functions based on fish events</a>,
but I think I’ll save that for future experiments.</p>
If you found this article useful, or you have suggestions, let me know on Mastodon</a> or Bluesky</a>!</p>



Using Fortune to Reinforce Habits
2025-07-23T00:00:00+00:00
A while ago I installed a bunch of new command-line tools,
some of which replaced my existing tools, like eza</code></a> instead of ls</code>.
Other tools improved the way that I work, such as LazyGit</a>
– the only interface to Git that I’ve found to be better that just using git</code> commands.</p>
If you’re looking for some recommendations for a modern command-line,
I can highly recommend Supercharge your shell</a> by Justin Mayer,
or Oxidise your command line</a> from the No Boilerplate YouTube channel.
Many of these tools are written in Rust,
which is a favourite language of mine,
but that shouldn’t make much difference to you!</p>
I had two problems though.</p>
Problem 1: Forgetting to use the tools</h2>
One problem was that muscle-memory meant I kept using the old commands instead of the new ones.
I could fix this by creating aliases, like alias ls=eza</code>.
That would mean that whenever I typed ls</code> the command that actually</em> was run would be eza</code>.
That’s fine with commands which are backwards compatible.
eza</code> supports all (or at least most!) of the flags that ls</code> supports.</p>
The problem was with commands that aren’t</em> compatible.
For example, the duf</code></a> command is much more powerful than du</code> which I used to use,
and isn’t a drop-in replacement.</p>
Problem 2: Forgetting I installed the tool</h2>
The other problem was that I kept forgetting that I had installed a tool,
or if I remembered,
then I couldn’t remember what the tool was called</em>.</p>
While I was working on this post,
I couldn’t remember the name of the xh</code></a> tool.
It’s an HTTP client for the command line.
It’s a replacement for HTTPie which was a replacement for Curl!</p>
The Solution</h2>
I needed some constant reminders that these tools existed on my computer,
and a reminder of what each tool did.</p>
What I imagined was that every time I opened a terminal window,
I would get a short message saying,
“Don’t forget you’ve installed xh</code> – it’s a command-line HTTP client!”</p>
Yes, I really write messages to myself in that chirpy style.</p>
In steps fortune</code>, fortunately</h2>
I nearly started coding something in Python.
I am a programmer after all.
Then I remembered…</p>
There’s a tool for managing a database of short text snippets,
and selecting snippets at random.
It’s called fortune</code></a> and it’s a proper old-school UNIX utility.</p>
These days, fortune isn’t usually installed by default on Linux.
The following are the commands I know for installing fortune on different platforms:</p>
# Debian etc.
</span>apt</span> install fortune-mod
</span>
</span># Fedora etc:
</span>sudo</span> dnf install fortune-mod
</span>
</span># Arch:
</span>sudo</span> pacman</span> -S</span> fortune-mod
</span>
</span># MacOS:
</span>brew</span> install fortune
</span></code></pre>
Once it’s installed,
you can see a random snippet by running the fortune</code> command with no parameters.
You’ll get a different snippet each time.</p>
$</span> fortune
</span>"</span>Earth is a great, big funhouse without the fun.</span>"
</span>        </span>--</span> Jeff Berner
</span>
</span>$</span> fortune
</span>Honesty</span> pays, but it doesn'</span>t seem to pay enough to suit some people.
</span>        -- F.M. Hubbard
</span></code></pre>
I suspect that most people who install fortune just use the data files that come with fortune,
just like I did above.
They contain a bunch of jokes, quotes, technical and philosophical observations.</p>
But you can also create your own</em> data files for fortune.</p>
Create your own fortune file</h2>
I created a short text file called “habits”, and added some short snippets to it.
The format isn’t very complicated.
Each snippet is separated by the percent character (%) on its own line, like this:</p>
Don't forget about hexyl! A handy binary file viewer.
</span>%
</span>Still using man? Try using *tldr* first!
</span>%
</span>Don't use *ps* - use *procs*!
</span></code></pre>
Fortune can’t use this text file as it is.
First, it needs a data (or “dat”) file to be created.
The data file sits alongside the text file
and contains information that allows fortune to look up a random snippet really quickly</em>.
Fortunately the tool that does this processing is packaged with fortune</code>,
and it’s called strfile</code>.</p>
To create a file called “habits.dat” from the file “habits”,
I ran strfile habits habits.dat</code>.
This created “habits.dat” in my current directory.
Now I can run fortune</code> and point it at my text file.
It will find the dat file automatically:</p>
# Check that both habits and habits.dat are in the right place:
</span>$</span> ls</span> -1
</span>habits
</span>habits.dat
</span>
</span>$</span> fortune habits
</span>Still</span> using man? Try using *tldr* first!
</span>
</span>$</span> fortune habits
</span>Don</span>'</span>t forget about hexyl! A handy binary file viewer.
</span></code></pre>
Make it easy to update the habits file</h2>
I often forget how to update the data file when I’ve updated my fortune text file.
(I had actually forgotten when I started to write this post.)
I created a Makefile to make it easier to update the data file.
Makefiles are also pretty old-school,
but they’re also the perfect tool for this job!</p>
# Makefile
</span>
</span>habits.dat</span>: </span>habits
</span>	</span>@</span>strfile</span> habits habits.dat
</span></code></pre>
Just make sure your text editor isn’t going to replace the indent with spaces
– it’s important that it remains a tab character.</p>
I have to admit that my</em> Makefile is slightly more complex than this,
but I’m a nerd. The Makefile above is fine.</p>
After writing this, I can now just run make</code>,
and it will update “habits.dat” if the “habits” file has changed.</p>
At this point,
I filled out my “habits” file with details of all the commands I’d installed.
I stole some content from tldr</code></a>,
which is super-helpful for learning the basics for a new tool.</p>
$</span> tldr duf
</span>
</span>-</span> List accessible devices:
</span>    </span>duf
</span>
</span>-</span> List everything (such as pseudo, duplicate or inaccessible file systems)</span>:
</span>    </span>duf --all
</span>
</span>-</span> Only show specified devices or mount points:
</span>    </span>duf</span> path/to/directory1 path/to/directory2 ...
</span>
</span>-</span> Sort the output by a specified criteria:
</span>    </span>duf --sort</span> size|</span>used</span>|</span>avail</span>|</span>usage
</span>
</span>    </span>...
</span></code></pre>
Automatic reminders</h2>
Do you remember that I wanted to print out these snippets every time I opened a terminal window?
How you do that depends on the shell you’re running.</p>
First, I moved the directory containing “habits”, “habits.dat”, and my “Makefile” into an appropriate directory.
I chose “~/.local/habits”.
Afterwards, I could do this:</p>
$</span> ls </span>~</span>/.local/habits
</span>habits</span>  habits.dat  Makefile
</span></code></pre>
If you use bash or zsh you can add the following to the end of “~/.bashrc” or “~/.zshrc”:</p>
# ~/.bashrc or ~/.zshrc
</span>
</span># ... existing content goes here ...
</span>
</span>fortune ~</span>/.local/habits
</span></code></pre>
If you’re on fish shell</a>, it’s a bit different.
(You should try fish shell, I absolutely love it!)
In this case, you need to add the above command to a function called fish_greeting</code>.</p>
# ~/.config/fish/functions/fish_greeting.fish
</span>
</span>function </span>fish_greeting
</span>  </span>fortune </span>~/.local/habits
</span>end
</span></code></pre>
However you configure it,
once you’ve made the necessary edits open a new terminal window and you should see a handy reminder!</p>
Bonus points</h2>
The code above is pretty useful,
but the text doesn’t stand out very much in the console.
I found it was a little too easy to ignore it.</p>
There are a few neat tools for the command line that can format text in interesting ways,
for example, by drawing ascii-art frames around the text.
Two popular ones are cowsay</a> and boxes</a>.</p>
I changed the fortune</code> call so that it pipes the output through boxes</code>.
My command looks like this:</p>
fortune ~</span>/.local/habits | </span>boxes -d</span> parchment
</span></code></pre>
… and the end result looks like this:</p>
</p>
Summary</h2>
Building my own habit reminder as I’ve described above was something that I’ve found surprisingly useful.
I had never really thought of using fortune</code> in this way,
but it’s proven to be quick to set up,
didn’t require any coding,
and it’s helped me to improve how I use the command-line!</p>
Update</h2>
This post has done some numbers, and apparently inspired some people!
I love that the phrase “habits file” is being used by others as a shorthand for this idea.</p>
If you’d like to configure chezmoi</a> to synchronise your habits files across the different machines you use,
do check out Chris’ post, Habits in the Shell, shared</a>.
Chezmoi is a tool that I also use,
to share config between my computers.
It’s an awesome piece of software,
with a bit of a learning curve.</p>
If you found this tutorial useful, let me know on Mastodon</a> or Bluesky</a>!</p>



Rust Trait Implementations and References
2023-02-22T00:00:00+00:00
If you implement a trait on a type,
and then take a reference to that type,
does the reference also</em> implement the trait?</p>
For a while I thought so! Let me explain why.</p>
Sometimes the things that Rust does for you can obfuscate what’s really going on under the hood,
and I discovered one of those recently while having a minor battle with Rust’s type-system.</p>
To illustrate, let me start with a trait called Speaker and an empty struct that implements the trait:</p>
/// A trait for things that can speak.
</span>trait </span>Speaker {
</span>    </span>fn </span>speak</span>(&</span>self</span>);
</span>}
</span>
</span>/// BasicSpeaker is an empty struct that exists
</span>/// only to implement Speaker.
</span>struct </span>BasicSpeaker;
</span>
</span>/// BasicSpeakers must be able to speak.
</span>impl </span>Speaker </span>for </span>BasicSpeaker {
</span>    </span>fn </span>speak</span>(&</span>self</span>) {
</span>        println!("</span>Hello!</span>");
</span>    }
</span>}
</span></code></pre>
Now, in my main</code> function, the following code should work:</p>
// Create a BasicSpeaker struct:
</span>let</span> speaker = BasicSpeaker;
</span>// Call the speak method defined on the BasicSpeaker:
</span>speaker.</span>speak</span>();
</span></code></pre>
And it does! If I run this in a playground</a>,
then it prints the message “Hello!”</p>
If I have a reference</em> to a BasicSpeaker,
I can still call speak</code> on it,
because Rust automatically dereferences the variable.
So the code below also works:</p>
// Take a reference to the BasicSpeaker:
</span>let</span> speaker_ref: &BasicSpeaker = &speaker;
</span>// Call the speak method defined on the BasicSpeaker,
</span>// via the reference:
</span>speaker_ref.</span>speak</span>();
</span></code></pre>
(I know I don’t need to explicitly specify the type of speaker_ref</code> as &BasicSpeaker</code>,
but I want to make it really clear what type the variable is.)</p>
This might lead you to believe
that as well as BasicSpeaker</code> implementing Speaker</code>,
that a reference, &BasicSpeaker</code>, also</em> implements Speaker</code>.
Perhaps by some kind of Rust magic?</p>
Let me test this out more specifically by defining a function that takes a parameter of type impl Speaker</code>.</p>
fn </span>speak_to</span>(</span>s</span>: impl Speaker) {
</span>    s.</span>speak</span>();
</span>}
</span>
</span>fn </span>main</span>() {
</span>    </span>// Create a BasicSpeaker struct:
</span>    </span>let</span> speaker = BasicSpeaker;
</span>    </span>// Pass speaker to the new function:
</span>    </span>speak_to</span>(speaker);
</span>}
</span></code></pre>
This works, because BasicSpeaker</code> implements the Speaker</code> trait. You can check it out in another playground</a></p>
Let’s try the same thing, but this time with a reference to the BasicSpeaker</code>:</p>
// Take a reference to the BasicSpeaker:
</span>let</span> speaker_ref: &BasicSpeaker = &speaker;
</span>// Pass the reference to `speak_to`:
</span>speak_to</span>(speaker_ref);
</span></code></pre>
This doesn’t</em> work! You can check it out</a> for yourself.
The error message looks like this:</p>
error[E0277]: the trait bound `&BasicSpeaker: Speaker` is not satisfied
</span>  --> src/main.rs:31:14
</span>   |
</span>31 |     speak_to(speaker_ref);
</span>   |     -------- ^^^^^^^^^^^ the trait `Speaker` is not implemented for `&BasicSpeaker`
</span>   |     |
</span>   |     required by a bound introduced by this call
</span>   |
</span>   = help: the trait `Speaker` is implemented for `BasicSpeaker`
</span>note: required by a bound in `speak_to`
</span>  --> src/main.rs:16:21
</span>   |
</span>16 | fn speak_to(s: impl Speaker) {
</span>   |                     ^^^^^^^ required by this bound in `speak_to`
</span>
</span>For more information about this error, try `rustc --explain E0277`.
</span></code></pre>
The initial error message is a touch cryptic, but the message next to the first block of code is clearer: “The trait Speaker</code> is not implemented for &BasicSpeaker</code>.”</p>
The earlier code examples demonstrate that you can call methods on a reference that are not implemented on that reference</em>, because Rust silently dereferences the value for you.
Under the hood, Rust does this:</p>
// Rust converts `speaker_ref.speak()` into:
</span>(*speaker_ref).</span>speak</span>();
</span></code></pre>
What it doesn’t</em> mean is that a &BasicSpeaker</code>, a reference</em>, implements Speaker</code>.</p>
A Direct Solution</h2>
The most direct solution is to implement Speaker</code> on  BasicSpeaker</code> references, like this:</p>
/// BasicSpeaker _references_ must also be able to speak.
</span>impl </span>Speaker </span>for </span>&BasicSpeaker {
</span>    </span>fn </span>speak</span>(&</span>self</span>) {
</span>        println!("</span>Hello!</span>");
</span>    }
</span>}
</span></code></pre>
With this added to the code, it compiles and runs</a>.
So it’s a kind of success!
But it’s not ideal.
For one thing, this is basically duplicated code from the previous implementation.
Here’s a slightly improved implementation that just calls through to the underlying struct:</p>
/// BasicSpeaker _references_ must also be able to speak.
</span>impl </span>Speaker </span>for </span>&BasicSpeaker {
</span>    </span>fn </span>speak</span>(&</span>self</span>) {
</span>        </span>return </span>(**</span>self</span>).</span>speak</span>();
</span>    }
</span>}
</span></code></pre>
In case it’s not obvious,
I have to dereference self</code> twice because the function takes &self</code>, and self</code> is &BasicSpeaker</code>.
That means the argument is a &&BasicSpeaker</code> and it has to be dereferenced twice to get the BasicSpeaker</code> that implements speak()</code>.</p>
Okay, so now there’s not so much code duplication,
but there is another problem.</p>
The code only</em> implements Speaker</code> for references to a BasicSpeaker</code> struct.
If I want to define another Speaker</code>, something like NamedSpeaker</code>,
then I’ll have to write that code twice as well - once for NamedSpeaker</code>, and again for &NamedSpeaker</code>. </p>
Excuse my language, but that sucks</em>.</p>
Fixing This With a Blanket Implementation</h2>
Because Rust doesn’t</em> suck,
it has a feature called blanket implementations for traits.
They’re actually one of my favourite things about Rust.</p>
I can write a blanket implementation that says: “If a struct T implements Speaker, then here is an implementation of Speaker for &T.” And then I can have that implementation</a> pass through the calls to the referenced struct’s definition.</p>
/// All references to things that implement Speaker must also be Speakers.
</span>impl</span><T> Speaker </span>for </span>&T
</span>where
</span>    T: Speaker,
</span>{
</span>    </span>fn </span>speak</span>(&</span>self</span>) {
</span>        </span>return </span>(**</span>self</span>).</span>speak</span>();
</span>    }
</span>}
</span></code></pre>
Or, if you prefer, you can use the following, slightly shorter syntax that means the same thing:</p>
/// All references to things that implement Speaker must also be Speakers.
</span>impl</span><T: Speaker> Speaker </span>for </span>&T {
</span>    </span>fn </span>speak</span>(&</span>self</span>) {
</span>        </span>return </span>(**</span>self</span>).</span>speak</span>();
</span>    }
</span>}
</span></code></pre>
What I Learned About Interface Design From Rust for Rustaceans</em></h2>
Chapter 3 of Jon Gjengset’s Rust for Rustaceans</a> book is called Interface Design</em>,
and it starts out by covering the basics of building ergonomic interfaces in Rust. It states the following:</p>

“When you define a new trait, you’ll usually want to provide blanket implementations as appropriate for that trait for &T where T: Trait</code>, &mut T where T: Trait</code>, and Box<T> where T: Trait</code>. You may be able to implement only some of these depending on what receivers the methods of Trait have.”</p>
</blockquote>
This paragraph was a bit of a revelation to me!
Because I haven’t been reading</em> enough Rust code,
I wasn’t familiar with standard practice when writing</em> Rust code.
I had accidentally been writing code that was non-idiomatic and surprising without intending to.</p>
There’s lots of other good advice in that chapter particularly.
I recommend picking up a copy of the book,
either directly</a>,
or at your nearest independent bookseller</a>.</p>
The excerpt above led me to realise that even though I’ve now written an implementation of Speaker</code> for &BasicSpeaker</code>,
that doesn’t apply to &mut BasicSpeaker</code>!
So this won’t work:</p>
// Take a mutable reference to the BasicSpeaker:
</span>let</span> speaker_mut_ref: &</span>mut</span> BasicSpeaker = &</span>mut</span> speaker;
</span>// Call the speak method defined on the BasicSpeaker,
</span>// via the mut reference:
</span>speak_to</span>(speaker_mut_ref);
</span></code></pre>
That requires another blanket implementation:</p>
/// All mutable references to things that implement Speaker must also be Speakers.
</span>impl</span><T> Speaker </span>for </span>&mut T
</span>where
</span>    T: Speaker,
</span>{
</span>    </span>fn </span>speak</span>(&</span>self</span>) {
</span>        </span>return </span>(**</span>self</span>).</span>speak</span>();
</span>    }
</span>}
</span></code></pre>
And just for completeness,
here is the same thing for Box<T></code>,
for when you want to put a Speaker implementation on the heap:</p>
/// All Speakers in boxes must also be Speakers.
</span>impl</span><T> Speaker </span>for </span>Box<T>
</span>where
</span>    T: Speaker,
</span>{
</span>    </span>fn </span>speak</span>(&</span>self</span>) {
</span>        </span>return </span>(**</span>self</span>).</span>speak</span>();
</span>    }
</span>}
</span></code></pre>
Once those blanket implementations are added,
it means that any new implementations of Speaker</code>
are automatically implemented for the new type,
any reference to the type,
and also any Box</code> containing the type!</p>
You can find the full code listing</a> in a Rust Playground,
including a second Speaker</code>-implementing struct.</p>
Conclusion</h2>
Because Rust will automatically dereference trait references,
it can look like references</em> to trait implementations are also themselves</em> trait implementations.
But they’re not.
Fortunately, in many cases, you can fix that with some blanket trait implementations.</p>
Rust for Rustaceans</em> states that if your trait interface allows,
you should</em> provide blanket trait implementations for &T</code>, &mut T</code> and Box<T></code> so that you can pass these types to any function that accepts implementations of your trait.</p>
I certainly plan to follow that advice in future,
in the hope that it will avoid problems using the types I’ve defined.
I’m looking forward to what I learn next in the book!</p>

Thanks so much to
Carlton Gibson</a>,
Jorge Ortiz Fuentes</a>,
Diego Freniche Brito</a> &
Aaron Bassett</a> for reading the draft of this blog post.
Any errors that remain are probably my own fault,
but that doesn’t stop you from blaming one of them if you want to.</p>


Use Justfiles to Work with MongoDB
2021-05-21T00:00:00+00:00
I have started to write Justfiles</a> for all my new projects.
There’s a good chance you haven’t heard of Just or Justfiles.
They’re very similar to Make and Makefiles.
Whereas Make is designed to build artifacts from source files,
and combine them in potentially complex ways,
Just is “just” a task runner.</p>
</span>
Just can be installed with a bunch of different package managers</a>,
or you can just download a prebuilt binary.</p>
A short Justfile, containing a single recipe to import some data into a MongoDB cluster looks like this:</p>
import:
</span>    mongoimport $MDB_URI --collection recipes recipe_data.json
</span></code></pre>
The file is literally called Justfile</code>, with no file extension.
You would usually put this file at the root of your project directory.
This will all seem familiar, if you’ve ever worked with Makefiles!</p>
This specifies a recipe</em> called “import”. 
When I ask Just to run the import target, 
it will run the mongoimport command I’ve written on the line below.
The environment variable $MDB_URI</code> specifies the cluster (and database) that the data stored in recipe_data.json</code> will be loaded into.
As long as I’ve set the $MDB_URI</code> environment variable correctly,
then if I go to the directory that holds the Justfile and run the following,
it will run the mongoimport command and load the data into my MongoDB database.</p>
just</span> import
</span></code></pre>
Back to that $MDB_URI</code> variable.
Just has this great feature – it automatically</em> loads environment variables from a .env</code> file you put in the same directory.
So if I create a file called .env</code> containing the following,
then when I run the just</code> command, I’ll be able to refer to the $MDB_URI</code> variable,
like I did in the Justfile</code> above.</p>
# .env
</span>
</span>MDB_URI</span>=</span>mongodb+srv://username:password@timeseries.abcde.mongodb.com/cocktails</span>?</span>retryWrites=true&w=majority
</span></code></pre>
The idea in this case is that local configuration,
like the connection string for connecting to a MongoDB cluster,
is stored in the .env</code> file.
The .env</code> file is not committed to revision control,
whereas the Justfile can be committed and then reused by other team members.</p>
I’ll often have a handful of targets for setting up my database in any MongoDB project that I’m working on:</p>
# Justfile
</span>
</span># Recreate the database with sample_data.
</span>all: init import
</span>
</span># Drop all the collections, and recreate them with associated indexes.
</span>init:
</span>    mongosh $MDB_URI init_database.js
</span>
</span># Import recipe and review data into the cluster at $MDB_URI.
</span>import:
</span>    # Load recipe_data.json into the recipes collection:
</span>    mongoimport $MDB_URI --collection recipes recipe_data.json
</span>    # Load review_data.json into the reviews collection:
</span>    mongoimport $MDB_URI --collection reviews review_data.json
</span></code></pre>
Let’s break this down:</p>

Lines beginning with #</code> are comments. They’re (mostly) ignored by Just.</li>
The first target is the default target, so it will be run if you execute just</code> or just all</code>.</li>
The items after all: </code> are the targets this target depends upon.
They’ll be executed before any commands associated with the all</code> target.
(All doesn’t have any commands associated with it. It’s just there to collect together the other targets and run them in order.)
In this case, executing the all</code> target will first run the init</code> target, and then the import</code> target.</li>
A target is often followed by a list of commands to be run when the target is executed.
The commands should be indented,
but it doesn’t matter if they’re indented by tabs or spaces
(unlike Make, which is notoriously picky and weird!).
Those commands will be run in order when Just executes the target, and if any of them fail, Just will exit with an error.</li>
</ul>
So with this combination of Justfile</code> and .env</code> files, I’ve gained two things:</p>

I’ve got a quick and easy way to run commands related to my project.</li>
I’ve got documented</em> commands related to my project, for easy reference.</li>
</ol>
Speaking of documentation,
now that I added some comments to my Justfile,
if I run just --list</code> I get the following output:</p>
❯ just --list
</span>Available recipes:
</span>    all    # Recreate the database with sample_data.
</span>    import # Import recipe and review data into the cluster at $MDB_URI.
</span>    init   # Drop all the collections, and recreate them with associated indexes.
</span></code></pre>
It prints out each target, along with the comment above each one.
Self-documenting code!
I ❤ it.</p>
Why Don’t You Use Make?</h2>
I used to use Makefiles for this kind of thing in the past.
I continued to use Make even after I became aware of Just;
I couldn’t quite see the benefit of using a less ubiquitous tool.
But since I switched I’ve become a total convert, mostly for the following reasons:</p>

The syntax is much less weird and tricky than Make.
(Make differentiates between indentation by tabs and spaces,
and you end up using both in the same file for different reasons!)</li>
There’s no need to declare a .PHONY</code> target.</li>
Just automatically loads variables from a .env</code> file, if one is available.</li>
Just allows you to pass arguments to a command on the command-line.</li>
Just allows you to write commands in any language you like, not just shell!</li>
</ul>
Some Useful Snippets</h2>
Here are a few useful targets that I’ve found myself using across different projects:</p>
Connect To Your Database</h3>
I have the following short recipe in every Justfile!
It runs mongosh against the MDB_URI</code> that’s stored in the local .env</code> configuration,
so you’ll get an interactive connection to your database you can use to run ad-hoc commands against your data.</p>
# Connect to the configured database
</span>connect:
</span>    mongosh $MDB_URI
</span></code></pre>
Initialize Your Database For Development</h3>
I usually have a JavaScript file that can be run against a new database, with mongosh, 
to initialize collections and indexes in a reproduceable way.
An example init script looks like this:</p>
// init.js
</span>
</span>// Drop the collection if it already exists:
</span>db</span>.</span>scores</span>.</span>drop</span>();
</span>// Create a unique index on "username":
</span>db</span>.</span>scores</span>.</span>createIndex</span>({ "</span>username</span>": </span>1 </span>}, { unique: </span>true </span>});
</span>
</span>// Drop the collection if it already exists:
</span>db</span>.</span>stock_exchange_data</span>.</span>drop</span>();
</span>// Time series collections need to be created ahead-of-time.
</span>// Have you tried MongoDB's new time series collections? They're awesome!
</span>db</span>.</span>createCollection</span>("</span>stock_exchange_data</span>", {
</span>    timeseries: {
</span>        timeField: "</span>ts</span>",
</span>        metaField: "</span>source</span>",
</span>        granularity: "</span>hours</span>"
</span>    }
</span>});
</span></code></pre>
Then I’ll set up an “init” recipe to run it:</p>
# Initialize the configured database
</span>init:
</span>    mongosh $MDB_URI init.js
</span></code></pre>
Now I can run just init</code> to run the “init.js” script against my database.</p>
A Parameterized Target To Run Mongosh Scripts</h3>
If I have a bunch of scripts I may want to run against my database,
I’ll add a “run” recipe that can run any of the scripts.</p>
The following target makes use of recipe parameters</a>.
In the example below,
“script” is a variable that is passed on the command-line,
and then referred to using {{script}}</code></p>
# Run a script on the configured database
</span>run script:
</span>    mongosh $MDB_URI {{script}}
</span></code></pre>
With the recipe above in your Justfile,
you can execute a mongosh script called “create_view.js” like this:</p>
just</span> run create_view.js
</span></code></pre>
Other Features</h2>
The documentation for Just is very long – a good indication of quite how many features it has!
Nevertheless, it remains relatively straightforward to get up and running.
Some features I’ve found useful:</p>

You can write recipes in other languages</a>,
like Python or JavaScript.</li>
Create a User Justfile</a> that contains recipes you want to be available everywhere.</li>
Just will run, without any dependencies on Linux, MacOS, and Windows.
(Although you will need a shell, if you don’t have a version of sh</code> installed.).
It even includes some handy path manipulation</a> functions for cross-platform path manipulation.</li>
</ul>
There are a bunch more features.
I recommend you scan the documentation</a> to get a better picture of all it can do.</p>
In Conclusion</h2>
I’ve seen a bunch of benefits since I started to add Justfiles to all my projects.
It speeds up my day-to-day operations when I’m working with MongoDB (and other tools).
When I come back to a project after a while,
I can see the commands needed to create and work with the database,
by running just --list</code> or just scanning the Justfile.
The ability to document each recipe and easily list them is super-helpful,
and it also provides a way to help others work with the projects I’ve worked on.</p>
The examples in this post are relatively straightforward,
but Just really comes into its own when you want a recipe to run multiple commands,
each with their own list of flags that you would otherwise have to remember.
They’re an excellent alternative to writing shell scripts!</p>


Automating Blog Deployment with GitHub Actions
2021-03-12T00:00:00+00:00
Okay! Day 2 of the new blogging platform, and I’ve solved the automated deployment problem using GitHub Actions.</p>
</span>GitHub Actions to Test Python</h1>
I worked on a small Python project a little while ago and wanted to get CI running with as little effort as possible. I’d heard good things about GitHub Actions (my friend Michael Heap</a> is even writing a book</a> about them).</p>
That project’s CI issues were solved by following the instructions</a>. I copied the following YAML into .github/worflows/main.yml</code> and I was more-or-less done.</p>
name</span>: </span>Python package
</span>
</span>on</span>: [</span>push</span>]
</span>
</span>jobs</span>:
</span>  </span>build</span>:
</span>    </span>runs-on</span>: </span>ubuntu-latest
</span>    </span>strategy</span>:
</span>      </span>matrix</span>:
</span>        </span>python-version</span>: [</span>2.7</span>, </span>3.5</span>, </span>3.6</span>, </span>3.7</span>, </span>3.8</span>]
</span>
</span>    </span>steps</span>:
</span>    - </span>uses</span>: </span>actions/checkout@v2
</span>    - </span>name</span>: </span>Set up Python ${{ matrix.python-version }}
</span>      </span>uses</span>: </span>actions/setup-python@v2
</span>      </span>with</span>:
</span>        </span>python-version</span>: </span>${{ matrix.python-version }}
</span>    - </span>name</span>: </span>Install dependencies
</span>      </span>run</span>: </span>|
</span>        python -m pip install --upgrade pip
</span>        pip install flake8 pytest
</span>        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
</span>    - </span>name</span>: </span>Lint with flake8
</span>      </span>run</span>: </span>|
</span>        # stop the build if there are Python syntax errors or undefined names
</span>        flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
</span>        # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
</span>        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
</span>    - </span>name</span>: </span>Test with pytest
</span>      </span>run</span>: </span>|
</span>        pytest
</span></code></pre>
Porting the Knowledge to Deployment</h1>
What I wanted to do this time was quite similar. I wanted to build the site’s static pages, and then, if on the master branch</em> copy the files to my personal server, using SCP.</p>
I found an existing Zola deploy action</a> that builds a Zola site, and then deploys to GitHub Pages, but that wasn’t quite what I wanted. Nevertheless, it seemed like a good starting point, so I forked it, and then started hacking on it.</p>
And then I had an epiphany! I already had steps that checked out the code and built it into a static site. All I needed was another small, specific step</code> to SCP to my server. A quick search on GitHub’s Action Marketplace</a> showed up the perfect action, appleboy/scp-action</a>.</p>
So, now I have the following workflow:</p>
name</span>: </span>Build and deploy
</span>
</span>on</span>:
</span>  </span>push</span>:
</span>    </span>branches</span>:
</span>      - </span>master
</span>  </span>pull_request</span>:
</span>jobs</span>:
</span>  </span>build</span>:
</span>    </span>runs-on</span>: </span>ubuntu-latest
</span>    </span>steps</span>:
</span>      - </span>name</span>: '</span>Checkout</span>'
</span>        </span>uses</span>: </span>actions/checkout@master
</span>      - </span>name</span>: '</span>Build only</span>' 
</span>        </span>uses</span>: </span>shalzz/zola-deploy-action@master
</span>        </span>env</span>:
</span>          </span>BUILD_ONLY</span>: </span>true
</span>  </span>deploy</span>:
</span>    </span>if</span>: </span>github.ref == 'refs/heads/master'
</span>    </span>needs</span>: </span>build
</span>    </span>runs-on</span>: </span>ubuntu-latest
</span>    </span>steps</span>:
</span>      - </span>name</span>: '</span>Checkout</span>'
</span>        </span>uses</span>: </span>actions/checkout@master
</span>      - </span>name</span>: '</span>Build Site</span>' 
</span>        </span>uses</span>: </span>shalzz/zola-deploy-action@master
</span>        </span>env</span>:
</span>          </span>BUILD_ONLY</span>: </span>true
</span>      - </span>name</span>: </span>Deploy Site
</span>        </span>uses</span>: </span>appleboy/scp-action@master
</span>        </span>with</span>:
</span>          </span>host</span>: </span>${{ secrets.HOST }}
</span>          </span>username</span>: </span>${{ secrets.USERNAME }}
</span>          </span>key</span>: </span>${{ secrets.KEY }}
</span>          </span>source</span>: "</span>public</span>"
</span>          </span>target</span>: "</span>/var/lib/websites/judy.co.uk</span>"
</span>          </span>strip_components</span>: </span>1
</span></code></pre>
It’ll build on any push to master, or any new PR. If the commit is to master, then it’ll also deploy to my server using SCP. Using a small set of focused actions (Unix philosophy</a>, anyone?) has led me to something much more simple and maintainable than maintaining my own “build and deploy and …” action.</p>
One thing I’ve noticed is that it’s building the Docker images each time, before spinning up the containers. I haven’t found a way to speed things up by getting around this, but if you know, please contact me</a> and let me know!</p>
I have to say that it’s nice when a task that shouldn’t be hard turns out to not actually be hard.
Now I’ve reduced the friction for publishing to my blog, so if you come here in 2025 and this is the last post then there’s nobody else to blame.</p>
I think it’s time for a Negroni.</p>


The Traditional First Post
2021-03-11T00:00:00+00:00
I guess it’s traditional to write a first blog post about the new blogging platform.
Tradition, right? Not cliché?</p>
</span>My New Blogging Platform</h2>
My main driver this time, moving to Zola</a>,
has been to simplify the build and deployment process.
I’m halfway there.</p>
So that’s the half that’s done</em>.
The second half, automatic deployment</em>, is a little more complex, and not implemented yet.
But it should be easier, given the availability of the Docker image I mentioned above.</p>
In general, getting the blog set up has been straightforward.
Everything came “out of the box”.</p>
What’s Zola?</h2>
Zola</a> is a static site generator,
a bit like Hugo</a>,
and a whole</a> host</a> of others</a>.</p>
My criteria was that it would be:</p>

Reasonably fast, offer live preview,</li>
Run from a Docker container (so I can automate deployment from a GitHub repo).</li>
It also had to be quick to set up. Otherwise my goldfish attention span will stop me from deploying anything</em>.</li>
</ul>
Honestly, my guilty secret is the main reason I checked out Zola was because it was written in Rust.
I found this comparison</a> of various Rust-developed static site generators helpful.</p>
Zola’s great!
It’s flexible enough for my requirements - I wanted a listing of talks I’ve given as well as blog posts.
The template language, Tera</a> is inspired by Jinja2 & Django, two of my favourite templating engines.
(Did you know that Jinja came out of a project to speed up Django templates?</a>)
I quickly found a theme that suited my purposes, simple-dev-blog</a>,
which got me off to a good start,
although I’ll probably tinker with it some more over time.</p>
The new system is built from a Docker image.
With my old, Hugo-based, system, I attempted to Dockerize the build environment,
and while I learned a lot about sticking command-line tools in Docker containers,
I never quite got it up and running.
This was a while ago.
Things may be better now.
The real driver for moving away from Hugo was the templating system,
which I learned to hate with every fibre of my being.
With Zola, I was pleased to discover that a Docker distribution is already available.</p>
I have a certain amount of faith that Zola is powerful enough for my requirements - I’ve already set up templates to show YouTube video previews in the talk listings</a>.
The next things to set up are a listing of upcoming events I’m at,
and a listing of projects that I want to show off.
Stupid Python Tricks</a> anyone?</p>


Getting Started with MongoDB & Rust
2020-12-14T00:00:00+00:00
MongoDB is probably the world’s most popular document database. </p>
It may not be well known, but MongoDB released their first driver for Rust back in 2013. Since then regular driver updates have been released, supporting new database features and adding improvements. This year, the driver was rewritten, adding support for Tokio & Async-Std, and is now officially supported. So maybe it’s time to give it a try! </p>
This talk will give an overview of the features of MongoDB, including some features that many think MongoDB doesn’t support, including transactions and joins. I’ll cover:</p>

What MongoDB is (and isn’t); </li>
The basics of running a MongoDB cluster; </li>
How to effectively use the document model; </li>
Transactions; </li>
Aggregation queries, including joins. </li>
</ul>
And I’ll show how to use the Rust driver to make use of these features, and cover the areas the Rust driver does not yet support. I’ll also cover some of MongoDB’s lesser-known features, such as GIS data types and queries, and time series queries, at a high level. </p>


Pyjamas Conference Advocacy Panel
2020-12-05T00:00:00+00:00
I got to be on a panel with Tania Allard</a>!</p>
</span>
Just as good, the panel was run by Lais Carvalho</a>.
This panel, arranged at the last minute to fill a slot in the schedule was super-fun for me, at least.</p>


Stupid Things I've Done With Python
2020-12-05T00:00:00+00:00
Sometimes I do stupid things with Python.
I’m not proud of it.</p>
Okay, I am</em> proud of it.</p>
</span>
And I’m going to teach you some of my techniques.</p>


How to Get On This Stage (and What To Do When You Get There)
2020-09-18T00:00:00+00:00
It’s my first ever DjangoCon Europe talk!</p>
</span>
I’m super proud of this talk.
Applying to speak at a conference,
and then preparing to actually give the talk
(and dealing with rejection) can be frustrating.
I’ve been on the talk selection committee for a few conferences, 
and I wanted to pass on the things I’ve learned about good proposals,
as well as just demystifying the whole process for new speakers.</p>


Everything You Know About MongoDB is Wrong!
2020-07-25T00:00:00+00:00
This 10 minute talk attempts to list and counteract the eight most common myths about MongoDB.</p>
If you didn’t know that MongoDB was a secure, robust, ACID-compliant, transactional, relational database, then you should probably watch this talk.</p>


It's Pythons All The Way Down!
2019-08-04T00:00:00+00:00
A deep dive into how inheritance and metaclasses work in Python.</p>
</span>
I was quite nervous about this talk,
partly because it was 70 minutes long(!),
and partly because it’s the most advanced topic I’ve ever spoken about.</p>
In the end I was super-pleased with the results.
As I was researching how types and metaclasses work in Python,
I had a couple of epiphanies which I felt really helped make the subject understandable.</p>
When I got home (from Australia!) I discovered my wife had made notes and had a bunch of questions,
which is the most definite sign I’ve ever had that she found the talk interesting.</p>


Publish a Perfect Python Package
2019-07-10T00:00:00+00:00
An opinionated guide to building and distributing high-quality Python packages.</p>
</span>
Note that there’s no audio for the first 30 seconds.</strong>
It’s no great loss.</p>
I’ve never been super-happy with the delivery of this talk.
I felt the delivery was a little rough around the edges,
and I had some friends in the audience who were enthusiastically distracting me
(in a nice way)
which meant that I dropped some in-jokes that probably went over the heads of everybody else in the audience.</p>
All the same, the content of the talk is super-practical,
and this talk is one reason I was encouraged to come and work at MongoDB,
so maybe I should give the talk some slack.</p>


More Than you Ever Wanted to Know about Python Functions
2018-07-26T00:00:00+00:00
What exactly are functions? Let’s talk about functions, methods, callables and closures - what they are, what you can give them, what they can give you, what you can do with them … and what’s inside.</p>
</span>
You probably think you already know everything about functions, but you probably don’t!</p>
Input & Output: How do you get things in and out of functions? I’ll cover parameters and the myriad of ways they can be specified, provided and accessed - including helpful hints to avoid common mistakes! I’ll cover return values, briefly, along with variable scopes and exceptions.</p>
Closures: What are they, how do they work and how they can affect memory usage.</p>
Methods: How does a method differ from a function, when are they made, how do they work and how to access the function inside every method.</p>
__magic__: Make your own callables from any object!</p>
Introspection: Using modern Python techniques, what can you find out about a function, and what can you do with that information?</p>
Bytecode: What happens if you open up a function and look at its insides? Can you change it and put it back together again? (Spoiler: Yes, you can.)</p>
By the end of this talk, I guarantee* you’ll know more about callables than when you walked in, along with techniques both practical and so extreme your colleagues will never let you merge them to master.</p>
(*This guarantee is legally non-binding and cannot be redeemed in any way.)</p>
Notes</h2>
This talk was given in Edinburgh, my home town!
It was a really large audience, and a great venue, and I had a blast
… but I also ran out of time and had to rush the end of the talk - which is the most difficult bit!</p>
I gave the talk again at PyCon Ireland, but then had massive A/V issues,
so I don’t really have a better version to link to online.
Maybe one day I’ll manage to give a great version of this talk in full.
Until then, this is what you’ve got.</p>


Pythonic Refactoring: Protecting Your Users From Change
2017-07-14T00:00:00+00:00
So you’ve released a library! Now you need to maintain it. You want to add features, restructure the code, fix bugs, and maybe improve the library’s usability. Your users just want their code to carry on working. That’s okay!</p>
</span>
This talk will cover techniques in both code and project management to allow you to keep your code moving forwards without breaking your users’ code. It is aimed at developers with a little experience of writing libraries in Python, and will cover some intermediate subjects like function decorators and magic methods.</p>
Refactoring in Python is a mixed bag - on the one hand you have powerful tools like the @property decorator, dunder</strong> methods, and even metaclasses. On the other hand, because Python code has no concept of private or protected like some other languages, it can be difficult to know what your public interface even is.</p>
I’ll talk about how to identify your public interface, and make that clear to your users. I’ll cover how to structure your tests so you know when you’ve broken your public interface. I’ll discuss how to use some of Python’s language features to trick your users into thinking your code hasn’t changed at all (except for those brilliant new features you’ve just added!). And finally, I’ll cover how you know it’s time to break backwards compatibility and how to break it to your users.</p>

The New Adventures of Judy2k

Run Any Project with 'r'

Using Fortune to Reinforce Habits

Bonus points</h2> The code above is pretty useful, but the text doesn’t stand out very much in the console. I found it was a little too easy to ignore it.</p>

Rust Trait Implementations and References

Use Justfiles to Work with MongoDB

Some Useful Snippets</h2> Here are a few useful targets that I’ve found myself using across different projects:</p>

Other Features</h2> The documentation for Just is very long – a good indication of quite how many features it has! Nevertheless, it remains relatively straightforward to get up and running. Some features I’ve found useful:</p>

Automating Blog Deployment with GitHub Actions

Porting the Knowledge to Deployment</h1> What I wanted to do this time was quite similar. I wanted to build the site’s static pages, and then, if on the master branch</em> copy the files to my personal server, using SCP.</p>

The Traditional First Post

Getting Started with MongoDB & Rust

Pyjamas Conference Advocacy Panel

Stupid Things I've Done With Python

How to Get On This Stage (and What To Do When You Get There)

Everything You Know About MongoDB is Wrong!

It's Pythons All The Way Down!

Publish a Perfect Python Package

More Than you Ever Wanted to Know about Python Functions

Pythonic Refactoring: Protecting Your Users From Change

Some Useful Snippets</h2>
Here are a few useful targets that I’ve found myself using across different projects:</p>