I still really like the concept of configuring my system as code, especially the ability to define per-project environments without relying on containerisation or virtual machines. However, Nix has several flaws.

The biggest issue for me was the steep learning curve. I never fully grasped the Nix language, which made it difficult to make changes, particularly since I wasn't writing Nix code on a regular basis. The syntax and structure are unlike most other tools I’ve used, which made it harder to retain.

On top of that, the error messages were often hard to interpret. Small changes often resulted in build failures, which I then had to spend significant time debugging. The process of deciphering and fixing these issues became frustrating.

In the end, I found myself spending more time trying to get Nix to work than actually working on the projects it was supposed to support.

For now, I've decided to try out GNU Stow for managing my dotfiles, which you can see here: https://github.com/Amwam/Dotfiles. I need to take some time and fully flesh out the configurations, but its a start. A few hours in and its already been easier to manager.

I would like to find a nice way of configuring a new MacOS system via code, but so far I've not been able to find much. I suspect I'll dive into some shell scripts to help configure the system the way I like.

What is Nix?

Nix is a powerful, purely functional package manager that allows you to define and manage software environments declaratively. What sets it apart from traditional package managers is that it provides reproducible builds: no more “works on my machine” scenarios. With Nix, your environments are guaranteed to be exactly the same on every system, ensuring stability and consistency across different machines.

It shares many benefits with Docker, but one key advantage of Nix is its ability to configure a system declaratively, whereas Docker is more focused on packaging and containerizing applications.

Some of the benefits I’m most interested in are:

1. Declarative Configuration
   Being able to have my desired packages listed out in a file feels a lot more ergonomic to me than hunting through the output of Homebrew.

2. Isolation
   I’m able to set up a set of packages (using a shell.nix) on a per-project basis. No more need for version managers installed globally. It’s made my shell startup time a lot quicker.

Here’s an example of a basic shell.nix configuration for a Python project that sets up a specific version of Python, installs some dependencies, and creates an isolated environment:

# shell.nix

{ pkgs ? import <nixpkgs> {} }:

pkgs.mkShell {
  buildInputs = [
    pkgs.python39
    pkgs.python39Packages.pip
    pkgs.python39Packages.virtualenv
  ];

  shellHook = ''
    export PIPENV_VENV_IN_PROJECT=1
    echo "Welcome to the isolated Python environment!"
  '';
}

In this example:

• pkgs.python39 ensures the Python version is locked to Python 3.9.
• pkgs.python39Packages.pip and pkgs.python39Packages.virtualenv make sure pip and virtualenv are available for managing Python packages.
• The shellHook section can be used to customize the environment, like setting environment variables or displaying a welcome message when the shell is started.

With this configuration, each time I run nix-shell in the project directory, I’ll be placed into a reproducible Python environment, with the same versions and dependencies every time.

Being able to recover my system by rolling back is also interesting, but I’m not really sure how I would use that. Modifying a single config file and reapplying it seems to serve the same outcome for me.

I’ve found the Nix language a bit difficult to grasp, and the documentation isn’t easy to understand for beginners. However, I did manage to get a working setup, which works well for me, and that’s probably good enough for now. I haven’t fully explored creating my own flakes, but that would be useful in the future to be able to share some configuration between my personal and work machines.

Most of my configuration has been done with nix-darwin and Home Manager.

Nix-Darwin: Tailoring macOS to Your Needs

While Nix works well on Linux, Nix-Darwin is an extension of Nix tailored specifically for macOS. It allows you to manage macOS system settings declaratively, including configuring services, user settings, and even the system’s shell environment. Instead of dealing with complex system preferences manually, Nix-Darwin lets me define everything in one configuration file, making it easy to maintain consistency across devices or recover from a system failure.

Home Manager: Personalizing Your Development Environment

Home Manager is a tool that integrates seamlessly with Nix to manage your user-specific configuration files and software. Think of it as a way to manage your dotfiles, shells, editors, and other personal settings in a reproducible way. For me, managing my dev tools like Neovim, Zsh, and Git configurations with Home Manager has been a game-changer. I can easily sync my configuration across multiple machines and roll back changes if something goes wrong. No more wrestling with hidden configuration files or trying to remember all the tweaks I’ve made to my setup.

I’ve still got a long way to go understanding Nix, but I’ve started configuring my work machine to use a shell.nix for different projects, which has made switching between different language versions and tools a lot easier. When working with unfamiliar projects that haven’t already been converted to Docker, it’s made setting up a container to run the application a lot simpler.

Have only done some basic setup so far, mostly logging into accounts.

Jumped straight in today, and installed TailScale, so now I can access the mac from anywhere, using a VPN. I can also use the mac as an exit node if I want.

Also setup a VNC, so I can use my iPad when away (and also connected via tailscale). Seems like one of the most recomended solutions was Screens. Easy to setup and get started, and works quite well.

Only been able to use it on my local network so far, but performance seems pretty good.

Not a lot to share about the install experience yet, both these two applications didn't take up to get working.

Next thing I'll likely start looking at is Nix, to install packages, I'm currently writing this via the GitHub online editor.

Why a new Mac?

I've been trying to use an iPad as my main machine for some time now. It works well for day-to-day web browsing and email, but i've found it difficult to really do any sort of development with with. I've tried making use of GitHub Codespaces and running my own virtual machines. These have tended to work well, with the biggest issue being iPad OS. Its mouse and keyboard support make it difficult to be truely productive on it.

I've also wanted to start exploring some software engineering items outside of my regular job, things that may not fit with what I do regularly. Having my own machine I can do that on is a major plus point.

There are also other admin activities I have to take care of, that I think would be better suited to a desktop computer. Using the iPad plugged in with Stage Manager works, but isn't often ideal for my workflow.

What do I want to do?

I've got a bunch of ideas of things I want to explore, so here is a non-exhaustive list. I may not get around to all of these, but I itend to write up journey.

Dev tools

• Switching from pyenv/virtualenv to uv.
  • I write a lot of Python code, uv seems to a favourite in the community. I've been using pyenv/virtualenv for over 10 years now, so now feels like a good time to start exploring other alteratives
• Shell environment.
  • I've been using zsh with oh-my-zsh for the majority of my career, and have never attempted to look into alternatives. I'm not sure if i'm really making use of the functionality of oh-my-zsh
• Nix/NixOS for declarative environments
  • Reproducable environments has always been a positive in my experience.
• Vim/Neovim
  • I setup a neovim configuration quite some time ago, and haven't changed it since. I used to work on a mix of Python 2 and 3 projects, so had a lot of configuration to deal with that. I suspect that theres probably more modern ways of doing the things I had configured. There was also a lot of plugins I added, which I'm not sure are really needed/used. I'm also not sure on the status of Vim vs Neovim, so worth looking into that too.
• Docker for Mac alternatives
  • Haven't looked at other options for a while, but there are a few out there. I'd like to run some services on the new machine, and using containers feels like the easiest way.

Other Stuff

• AI
  • Just in general, I want to start experimenting a bit more, having a decenent machine I could run some LLMs locally will be useful
• iOS/iPadOS/MacOS development
  • I used to do a lot of this many years ago, things have changed so much, I'd like to get back into it. I've got a few ideas for apps I'd love to try and build.
• TailScale
  • I already have this setup so that I can connect to my home network and use my AppleTV as an exit node. I'd also like to try and setup VSCode server, so that I could use my iPad on the go, connecting to the mac. Will also want to look at VNC options.
  • Also interested in setting up PiHole again for DNS blocking, and running that from the Mac.
• Home Automation
  • I used to have a lot of smart switches around, but haven't really got them setup yet (since moving).

When building interactive web applications, it's crucial to prevent users from accidentally submitting forms or triggering actions multiple times. One effective and user-friendly approach is to disable the button immediately after it's clicked.

The Problem

Consider a form submission button:

function SubmitButton() {
  const handleSubmit = () => {
    // Perform some action, e.g., API call
    console.log("Form submitted!");
  };

  return <button onClick={handleSubmit}>Submit</button>;
}

If a user clicks this button twice quickly, the handleSubmit function will be called twice, potentially causing duplicate form submissions or API calls.

We can prevent double clicks by disabling the button immediately after it's clicked. Here's how we can implement this using React hooks:

import React from "react";

function submitForm() {
  // Simulating an async action that returns a Promise
  return new Promise((resolve) => setTimeout(resolve, 1000));
}

function SubmitButton() {
  const [isSubmitting, setIsSubmitting] = React.useState(false);

  const handleSubmit = async () => {
    if (isSubmitting) {
      return; // Prevent double submission
    }

    setIsSubmitting(true);

    try {
      // Perform some action, e.g., API call
      await submitForm();
      console.log("Form submitted successfully!");
    } catch (error) {
      console.error("Error submitting form:", error);
    } finally {
      setIsSubmitting(false);
    }
  };

  return (
    <button onClick={handleSubmit} disabled={isSubmitting}>
      {isSubmitting ? "Submitting..." : "Submit"}
    </button>
  );
}

Let's break down this implementation:

1. We use the useState hook to create an isSubmitting state variable, this lets us track when some background action is being run.
2. The handleSubmit function:
   • Checks if the form is already submitting and returns early if it is.
   • Sets isSubmitting to true before starting the submission process.
   • Uses a try/catch block to handle the submission and any potential errors.
   • Sets isSubmitting back to false in the finally block, ensuring the button is re-enabled even if an error occurs.
3. The button's disabled prop is tied to the isSubmitting state, so that the user can't click it again to trigger the action.
4. The button text changes to provide feedback to the user.

We can also take this a step further, and create our own hook to extract this logic.

import React from 'react';

function submitForm() {
    // Simulating an async action that returns a Promise
    return new Promise(resolve => setTimeout(resolve, 1000))
}

export function useIsSubmitting(action): [loading, action] {
  const [loading, setLoading] = React.useState(false);

  function doAction(...x) {
    setLoading(true);
    return action(...x).finally(() => setLoading(false));
  }

  return [loading, doAction];
}

function SubmitButton() {
  const [isSubmitting, doHandleSubmit] = useIsSubmitting(submitForm);

  return (
    <button onClick={doHandleSubmit} disabled={isSubmitting}>
      {isSubmitting ? "Submitting..." : "Submit"}
    </button>
  );
}

The final component doesn't need to handle any logic for reseting isSubmitting, and can focus on rendering the different states.

Conclusion

Disabling the button after it's clicked is a simple yet effective way to prevent double clicks and double submissions in React applications. This approach provides clear visual feedback to the user and ensures that actions are only triggered once, even if the user accidentally clicks multiple times. By combining this with proper error handling and timeouts, you can create a robust and user-friendly interface for your forms and action buttons.

Understanding Multi-Stage Builds

Multi-stage builds allow you to use multiple FROM statements in your Dockerfile. Each FROM instruction can use a different base, and each begins a new stage of the build. You can selectively copy artifacts from one stage to another, leaving behind everything you don't want in the final image. You can also build specific parts of the Docker file, by specifying which target you wish to build. With this you can have a single Dockerfile for both development and production, without needing to duplicate their contents.

Separating Dev and Prod Dependencies

One of the key benefits of multi-stage builds is the ability to separate your development and production dependencies. This is particularly useful in Python projects where you often have different requirements for development (like testing and linting tools) and production.

Let's look at an example Dockerfile:

# Stage 1: Base image for both dev and prod
FROM python:3.12 AS base

RUN pip install requests

# Stage 2: Production build
FROM base AS prod
ENV IS_PROD=true

# Stage 3: Development dependencies
FROM base AS dev
RUN pip install pytest

ENV IS_PROD=false

In this Dockerfile, we have three stages:

1. base: A common base stage with Python 3.12.
2. prod: Includes only production dependencies.
3. dev: Includes all dependencies (including development ones).

Building Specific Targets

To build a specific target, you can use the --target flag:

# Build the development image
docker build --target dev -t myapp:dev .

# Build the production image
docker build --target prod -t myapp:prod .

Default Build Behavior

It's important to note that if you don't specify a target, Docker will build the last stage by default. In our example, if you run docker build . without any flags, it will build the dev stage.

Benefits of Multi-Stage Builds

Let's dive deeper into why using multi-stage builds is beneficial:

1. Smaller Production Images:

   • By separating dev and prod dependencies, your production image only contains what's necessary to run the application, resulting in a smaller image size.
   • A typical Python web application might require development tools like pytest, flake8, and mypy, which are not needed in production. By excluding these, you can reduce your image size.
   • This can be beneficial for services like AWS Fargate and AWS Lambda, as it reduces the load time for the services to download the container image.

2. Improved Security:

   • Fewer dependencies in your production image means a reduced attack surface.
   • Example: Development tools often have their own dependencies and potential vulnerabilities. By excluding them from your production image, you minimize the risk of these vulnerabilities being exploited.
   • You can also use multi-stage builds to run security scans on your code before creating the final production image, ensuring that only vetted code makes it to production.

3. Faster Builds and Deployments:

   • Smaller images are quicker to build, push, and pull, speeding up your CI/CD pipelines.
   • In a microservices architecture with dozens of services, reducing each container size by 100MB can save gigabytes of data transfer and storage, significantly speeding up deployments.
   • Faster builds mean quicker feedback loops for developers.

4. Consistency:

   • Using the same base image for both development and production ensures consistency across environments.
   • This reduces "it works on my machine" problems by ensuring that the development environment closely mirrors production.

5. Flexibility:

   • You can easily switch between development and production builds without maintaining separate Dockerfiles.
   • This simplifies your build process and reduces the chance of discrepancies between environments.

6. Optimized Build Cache:

   • Multi-stage builds allow you to optimize your build cache more effectively.
   • You can structure your Dockerfile so that layers that change less frequently (like installing dependencies) are earlier in the file, while layers that change more often (like copying your application code) are later.
   • This means that subsequent builds can reuse cached layers more effectively, speeding up your build process.

7. Easy Integration of Build Tools:

   • You can use specialized build tools or compilers in early stages without bloating your final image.

Drawbacks

One of the biggest drawbacks using multi-stage builds, is the inability to re-use sections in the middle of a stage.

For instance, typically I would want to have dev and prod images separated only by the dependencies they install. However to produce an optimise build, you would want to add you application code after building the dependencies. This would therefore mean you would have to duplicate the COPY commands in both the dev and prod stages.

Multi-stage builds in Docker offer a powerful way to optimize your container images and streamline your development workflow. By separating your dev and prod dependencies, you can ensure that your production containers are lean, secure, and efficient, while still maintaining a robust development environment.

I wanted to try it out, and see how easy it would be run python in the browser, while also being able to interact with the DOM, as I would normally do in javascript. Turns out, Pyodide makes this really simple. Pyodide will proxy javascript objects with their python counter parts, in a way that feels very seamless.

After I had got the project setup, I decided to have a go and running a small React application, written in Python. As React isn't actually dependant on JSX syntax, this is trivial to get running thanks to Pyodide. All React components just have to return React.createElement` calls instead (which babel would normally translate JSX code into).

The result:

from js import document, window

React = window.React
ReactDOM = window.ReactDOM


def HelloWorldReactComponent():
    return React.createElement(
        "div", {"style": {"display": "flex"}},
        "Hello world. This was rendered with React."
    )


ReactDOM.render(HelloWorldReactComponent(), document.querySelector("#result"))

You can see a live demo at: https://amwam-pyodide-testing.now.sh or alternatively the code at: https://github.com/Amwam/pyodide-testing-playground

Most of the time in React you will pass an onClick handler to a button, and whenever that button is click, expect that function to be called.

<button onClick={() => console.log("I was called")}>Click me</button>

This onClick will get called, every time the button is clicked. Sometimes this function might call an endpoint, and in some cases, you may not want that endpoint to run multiple times.

To get around this, you can use state to detect if the button was clicked, disable the button from being clicked further, then perform our action. The steps would be:

1. Click the button
2. Set the state of the component to track the button click
3. Update the button (re-render) to disable it, and prevent further clicking
4. Perform our action (using componentDidUpdate)
5. Restore the button state, once the action is complete

Example:

Below is a custom component that handles doubleclicking of buttons. All of its props are passed down to the HTML button element, except the onClick handler, which we will wrap with our custom logic.

import React from "react";

class PreventDoubleClickButton extends React.component {
  constructor(props) {
    super(props);
    this.state = { clicked: false };

    this.onClick = this.onClick.bind(this);
  }

  onClick(event) {
    this.setState({ clicked: true });
  }

  componentDidUpdate(prevProps, prevState) {
    // If we previously weren't clicked, and then updated to be clicked, we want to run our click handler;
    if (!prevState.clicked && this.state.clicked) {
      // Here we expect the onClick function passed down, to return a Promise, once complete
      this.props.onClick().then(() => {
        this.setState({ clicked: true });
      });
    }
  }

  render() {
    return (
      <button {...this.props} onClick={this.onClick}>
        {this.props.children}
      </button>
    );
  }
}

// Usage

function handleClick() {
  return fetch("./myData.json").then(() => {
    this.setState({ data: "Got it!" });
  });
}

<PreventDoubleClickButton className="myButton" onClick={this.handleClick}>
  Click me
</PreventDoubleClickButton>;

1. Flow was hard to keep up to date

In one project we were on flow version 0.50 (at the time of writing 0.87 is out), every time we tried to upgrade we suffered broken changes. This got worse and worse as time went on, meaning we were less and less likely to upgrade. This is partly our own fault for not keeping our dependencies up to date, but also partly due to the fact flow isn't a v1 tool, and that we shouldn't have relied on it being such.

2. Using Flow felt like a chore

I saw over time, developers would treat flow like they treat a linter, only correcting things when there was an error in build, rather than constructing types as they went along. This suggested that my team weren't in favour of using flow (or maybe even a type system at all)[1]. If you only run type checks, after you have a feature working, it becomes a pain to go back and correct errors, even if they may be legitimate errors. This then encourages poor type checking or laziness.

3. Poor community support

Quite often it was difficult to get accurate types for third party libraries, and we regularly had to write our own, which then led to further problems with accuracy. TypeScript's community involvement seems to be a lot higher, and so far I've not faced any issues with type information with external libraries, finding that may other libraries are even written in TypeScript.

4. Strong type checking

This may not be entirely accurate phrasing. However, as TypeScript code can't run unless it compiles successfully it encourages writing correct types as you go, rather than after completing work. This results in fewer errors, and actually less time spent debugging, than if the code is written in Flow/plain JS (this is purely anecdotal).

These are just a few of the reasons as to why I've switched over a few of my projects to TypeScript recently, and is certain not an exhaustive list.

1 Turns out my team did like typechecking, but would not run it alongside their editing, so would often forget. ↩

Recently I found myself in a situation where some HTML was rendered server side, and inserted into the browser on request. I wanted to use a shiny new React component, instead of falling back to the legacy jQuery code.

In comes Web Components!

Web Components allow you to write your own HTML tags, and use them through out your application. This solves my problem, by having the server render the new HTML tag, and the front end automatically load the required JavaScript to render/control it. When rendering the Web Component we can delegate the actual rendering to React.

Lets start with a simple React component:

import React from "react";

class MyComponent extends React.Component {
  render() {
    return <div>Hello world! This was rendered using React!</div>;
  }
}

In order to render the component, we have to create a new HTMLElement as so:

class CustomHTMLElement extends HTMLElement {
  connectedCallback() {
    ReactDOM.render(<MyComponent />, this);
  }
}

In this, when the component is loaded by the browser, the connectedCallback will be called, allowing us to render the new component, at this (the location of the element in the DOM).

To finish, we just have to register the element with the customElements API:

customElements.define("x-test", CustomHTMLElement);

Now we can just use the tag <x-test/> in our HTML, to render the React component!

One problem with this setup can be Babel, as it doesn't play nice with transforming classes and extending HTMLElement. We can work around this using a custom class, and extending the prototype of HTMLElement:

function BabelHTMLElement() {
  const newTarget = Object.getPrototypeOf(this).constructor;
  return Reflect.construct(HTMLElement, [], newTarget);
}

Object.setPrototypeOf(BabelHTMLElement.prototype, HTMLElement.prototype);

class CustomHTMLElement extends BabelHTMLElement {
    ...

Now our CustomHTMLElement extends the BabelHTMLElement rather the HTMLElement directly.

To view an example project with this in use, you can checkout the repo here: https://github.com/Amwam/react-webcomponents

It was created using a tool from facebook called jscodeshift, which is a library for building javascript codemods.

Example:

import Main from 'aaaa';
import {ZMain}  from 'aaaa';
   

import First from 'zzz';
import {Third} from 'zzz';


import {Second} from 'zzz';


import * as someDefault from 'bbb';


import {a as b} from 'packageModule';


import SomeClass from './MyModule';
import AnotherClass from '../../Module1';


import * as util from 'util';

Becomes:

import * as util from 'util';

import Main, {ZMain} from 'aaaa';
import * as someDefault from 'bbb';
import First, {Second, Third} from 'zzz';

import {a as b} from 'packageModule';

import AnotherClass from '../../Module1';
import SomeClass from './MyModule';

Imports are separated by node, dependencies in package.json, other and relative imports.

This release contains an update to the login flow to make use of the API token, allowing the workflow to work with any authentication strategy.

There is also now support for nested job structures (such as using the folders plugin)!

There are two practices I apply to make sure that I leave my code changes as clear as I can. They are how I write the commit messages, and the ordering of the actual commits.

Commit messages

The message in a commit is where an explanation for the change should reside. This should include at the very least what was changed, and why.

Some examples of a bad commit messages include (and yes, I have seen these kind of commits from multiple developers on different projects):

fixed bug

and

refactored stuff

A more descriptive commit message would look something like

Fix ImageProcessingFactory not handling images less than 50px wide

Commit messages should ideally tell you what a commit will do if it is applied. I try to write my messages as if being read as This commit will <commit message>

An even better commit message would have a slightly longer message, after the initial message, describing the problem/change in more detail. However, this isn't always practical or even necessary depending on the project. If you have a chance I would recommend taking a look at the git and linux kernal commit messages as examples of great ones!

I've also worked in places that would prepend the ticket number to the commit message. Allowing developers to view the reasons for a change in more detail.

Autosquashing commits

Rebasing commit allows you to keep your history linear. While not everyone agrees whether or not you should be maintaining a linear history, It is almost definitely (in my opinion) and good idea to keep your local branches ordered appropriately, by showing changes as a series of changes to be applied. Ideally each change is isolated from the others (within reason), and can be applied separately.

Development rarely works like this. Too often have I made some changes, progressed a bit further, and realised I there were more changes to make in that original commit. Maybe it was a left over debug statement, or some missing config, or even a chunk of functionality I didn't originally think about. Typically most people would just make a new commit with these changes, and leave it at that.

Git has the ability to squash commits into another, allowing you to make several small changes, and then bundle them up into one, more appropiate, commit. This get a bit complicated, when you start to make changes that aren't in order.

Luckily, git has that solved, with --fixup and --squash. These let you commit changes, and at the same time specify that they should be part of a previous commit. The fixup option will allow you to amend a previous commit, and not change the original commit message. The squash options, will also amend a previous commit, but it will also give you the change to alter the commit message.

To use these, just prepare you staging area, like normal (git add or git add -p), then commit with:

`git commit --fixup=<previous commit hash>`

This will create a new commit, with a message in the form

!fixup <original commit message>

Then when you are at a stage you wish to squash and clean all your commits, just run a rebase with the --autosquash flag (or you can set rebase.autosquash to true in you git config).

You history would then go from:

commit 1234        !fixup Original change

commit 5678        Some other change

commit 91011        Original change

becoming:

commit 5678         Some other change

commit 91011        Original change

Where commit 91011, contains all the changes from the original 91011, and 1234

Rebasing commits can sometimes be a little scary if you don't know what you are doing or how it really works. So squashing commits may not be for everyone, but I would still recommend everyone to put in more effort to their commit messages, as it can help everyone involved in modifying a codebase.

I found out about Git's 'push to deploy' feature today based on this post and figured its perfect for my setup! My site is built so that I don't have to restart when a new post is added, which means silent updates.

I already had a hook which would check out my repo, and pull the latest changes, whenever I pushed to the bare repo. This makes things simpler as I can now choose exactly when I want to deploy.

To set this up, all you have to do is clone your repo on your server, as you would normally (git clone http://path.to.your.repo), then run the following command to allow pushing into the repo.

git config receive.denyCurrentBranch updateInstead

From your development side, setup a new remote such as prod with the command :

git remote add prod http://path.to.your.production.repo

When ever you want to deploy it becomes a simple case of just running git push prod master.

It is just a minor release with a few bug fixes, and mainly a tidy up of the tests, making sure its up to 100% coverage. Also removed the mockito package, as there really was no need for it.

You can download it from either Packal or directly from GitHub Releases.

If you're interested in checking out the source code, you can find it here: https://github.com/Amwam/Jenkins-Alfred-Workflow

If you would like to check out my current configs, you can do so here at GitHub.

I've created a Alfred workflow to help search through jobs on a Jenkins CI instance.

It makes use of the standard Jenkins JSON API, and provides a way to fuzzy search through the job names, and view their current status.

Here is the view with all jobs being shown, the shortcut for this is jenkins (or cmd+alt+ctrl+j)

Simply start typing to filter down the list of jobs.

You can download the latest from either Packal or directly from GitHub Releases.

If you're interested in checking out the source code, you can find it here: https://github.com/Amwam/Jenkins-Alfred-Workflow

For a bit of reference this is a python Flask website.

And I'm using markdown to write all this!