Ben Selby

The Prolific CLI

This post is going to be an introduction to the Prolific CLI for data collectors/researchers. The Prolific CLI is not affiliated with Prolific in any way, and I work on this in my free time as an open source project.

So Prolific have this to say on their website:

• Easily find vetted research participants and AI taskers at scale.
• An unrivalled participant pool.
• Data quality you can depend on.

OK, so you want to collect some data to train your AI model (I mean, who doesn’t nowadays?), then Prolific is the place to start. The CLI is aimed at:

Running Ubuntu on a MacBook Pro

Note: This post is a work in progress, and mainly for my notes. It’s current as of May 2024!.

I had a ten year old MacBook Pro lying around not really doing anything. It wasn’t doing very well with the macOS either, so decided to run Ubuntu on it. Ubuntu was my main development environment from about 2008 until about 2011, and I miss it.

However, as a life long Mac user, the keyboard shortcuts and combinations are too much muscle memory for me to try and move away from. Also, this is a fun side project. I’m not entirely moving over to Ubuntu, so I don’t really want to change my muscle memory too much.

Stop tracking changes to certain files in Git

If you’ve used git before, you’re probably aware of the .gitignore file. This is what the manual has to say:

A gitignore file specifies intentionally untracked files that Git should ignore.

This file is usually tracked in your Git repo, so every contributor ignores the same files. Interestingly, you can also have a global ignore file in your home directory too ~/.gitignore. I have a global ignore file for ignoring basic IDE files.

Working with Zed for a week

I took Zed for a spin this week, and this post covers what I noticed whilst using it as my day-to-day editor.

This is what Zed is:

Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter. It’s also open source.

Projects worked on:

These are the projects I managed to work on this week with Zed:

Show your working out

Does anyone remember what your Maths teacher used to say?

Show your working out!

I mean, I bet they said more than that, but this is what I remembered. I think we used to get marked down if you just provided the answer. You got more marks when you showed how you derived your answer.

This post is a plea for software engineers to do the same when answering technical questions, or debugging an issue in group communication channels.

A case for using a Makefile in your project

This post is going to present a case for using a Makefile in your project. This will be the top-level task runner for your project. You can use make to run all of your project tasks such as building, linting, testing, and deploying your project. It doesn’t matter what language your project is written in.

What is a Makefile?

Make gets its knowledge of how to build your program from a file called the makefile, which lists each of the non-source files and how to compute it from other files. When you write a program, you should write a makefile for it, so that it is possible to use Make to build and install the program.

Read more ›

Automating the startup of a dev workflow

Hopefully, this is the first of many small posts showing how I automate my workflow.

Back around 2008, I had a mentor/buddy for my new job. Rys. He was a wonderful, knowledgeable, and supportive buddy who always seemed to be one step ahead.

One day he noticed that I came into the office each day, opened the terminal, and created x amount of tabs, which I then named (So I knew what each terminal was there for, e.g. logs, database, git, and codebases etc).

Naming Slack huddles

I’m pair programming more and more nowadays. One thing that features heavily in pair programming is a Slack huddle. My main recommendation is to name the Slack huddle.

Slack is a very useful tool to use when pair programming. For me, it’s simply the ability to draw on each others screen. Trying to describe the many buttons, areas of an IDE, or where to change a line of code is painful. Being able to draw on the screen is not.

Mephisto and dev containers

I’m currently looking into what Mephisto can do. Mephisto describes itself as

Mephisto was designed from the ground up to work with different “crowd providers”. You can use Amazon Mechanical Turk, an internal platform for your organization, or something else. Additionally, launch your tasks on Heroku, EC2, etc.

So I wanted to check it out and run it locally to see for myself. I started with the 10-minute Quickstart guide but hit issues with the installation of dependencies. I tried Python 3.8, and 3.11, and with pip install and poetry install. I am fairly confident this is to do with my Apple Silicon Mac (I have issues with other Python projects too!). So rather than get bogged down in that world, I thought it would be easier to spin up a dev container in VS Code. This post is going to show you how you can do that (and provides a reference for me as to what the configuration is).

Setting up k9s skins for different Kubernetes clusters

This post was updated on June 19th 2024, to document the latest way to do this.

This post is going to show you how to define different skins for k9s, so you can quickly see which environment you’re working on.

k9s is a terminal application that allows you to manage your Kubernetes clusters. So if you’re managing your production cluster, for example, you probably want to take extra care of what you’re doing.