I'm currently reading Eve by Cat Bohannon. It's an overview of the evolutionary history of mammals/humans through womens bodies. It picks various "Eve's", animals who were possibly the first women depending on different views of what makes a woman.

As someone who hasn't read into biology or evolutionary history much since GCSE's, I'm finding this deeply interesting.

At the moment, I'm onto the development of mammals who produced milk, the first example of which is a mouse the size of a human thumb who sweat it out of their skin! The book has gone on to discuss the numerous functions of milk. Did you know that when a child drinks milk, the breast absorbs their saliva and uses its chemical composition to detect their emotional state and any illnesses or specific nutritional deficiencies and on-the-fly alters the composition of the milk it produces to provide anti-bodies, calming hormones or the needed nutrients??

It turns out milk is a deeply complex system which actually does much more than just provide nutrients and we're only just starting to scratch the surface of its functions. Two more examples:

• The first milk produced by a mother clears out a babies digestive tract and plants the initial bacterial colonies that run digestion!

• The average emotional state of a breast feeding mother will go on to alter a childs personality for the rest of their life. Higher stress hormones in milk produce more timid and careful children, lower stress hormones produce more explorative and experimental children. You can really see how this helps alter our entire societies behaviours to prioritise survival when needed and development when its safe!

Its truly fascinating, especially to me, a trans woman who has some part of the female anatomy (e.g. breasts that can produce milk) but not others (e.g. a womb). Expect a full report soon!

Inhabited places, as they exist with their people - their friends - slowly develop an understanding of themselves and a strength to exist in a deeper fashion.

The archive existed from will alone. A will of its own. Unlike a lot of places, it wasn't ancient, nor created by some modern mastermind. It simply appeared one day, not yet as an archive but as a small playful space, the odd book, the odd film, toys abound.

Hidden away, it held a small community who would happen across it over time. These wanderers played with it, enjoyed its personality and all that it contained. At first, it held itself there in what some would call a quiet anxiety. This anxiety, however, wasn't one of paralysis. With a determination, it and its small community started to fill its walls. Visitors and inhabitants would bring books, films and trinkets. It learnt and developed, watching the world outside and watching those within it playing. It felt itself, and through critique, listening and comparison - both with the outside world and with its community - it filled itself.

Those within who enjoyed its toys aged, as did it and as time passed it filled itself with all number of other spaces as well: galleries filled with stretching masses of art from the inhabitants, and gardens, their walls covered in vines, trees and ponds, vibrant and active.

As with most things, the archive slowly rolled through changes. People would come, people would leave, often those who did would return later. It always kept growing, valuing its small community, its insides, its history and its thoughts.

Those within the archive lived happy lives. They would come and go as they pleased. Some would spend their lives within it, living as part of it's ecosystem, sitting in its trees to read, listening to its worries and bringing new works regularly. Other would visit less frequently, taking books, returning them once read, bringing parts of their world into it to share. Some would appear hardly ever, though their appearance was still valued. They'd bring what they had, rest and recover from their journeys within its walls and share tales of their lives. These tales were often mundane but the archive liked this; it held dear the lenses their tales were told through, for although it could see the world, it found such joy in the energy and perspective of others.

Within its depths, the archive still held its old rooms, littered with toys and children’s books. Far from hidden or forgotten, these rooms would often be the first to greet a new visitor, opening a door to a half completed puzzle or a ball rolling, inviting them in. Amongst these rooms sat wardrobes full of costumes, jukeboxes and of course, numerous books and films.

Soon 20 years passed and the archive was no longer a quiet hidden place. Its halls regularly held host innumerable recurring guests and its community was larger than ever.

It now held rooms, upon rooms, upon rooms, alongside gardens, balconies and large playfully winding corridors (for it enjoys keeping its inhabitants on their toes). One could spend days alone conversing with it, reading its books, or thinking about stories it had written itself, learning of the views it held, which by then were rather well steeled. Whilst reading, ther was a non-zero chance one would still come across its toys, both new and old, lying on a shelf, on the floor or behind their chair, left with the intentions of a jester child. The best finds were often those of toys from its original room, all denoted with a perpetual familiar warmth to their surface, as if recently held.

Though valuing flat truth, the archive valued its fiction most of all. In terms of these, the archives community would often throw the oddest of events, celebrations of their stories, knowingly fruitless hunts for fake cryptids, starting secret societies in jest or simply hosting costume parties themed around their favourite tales.

It was a stronghold visited by many, though still only known about in given circles. Those who did, saw it not only as a location with an unquestioning welcome, a taste for the silly and an unparalleled collection of works, but also, they saw it as one of the strongest friends they had ever come to know.

I gave a talk at a Aber BCS Show And Tell event last year trying to introduce more people to the concept of algorave, live-coding and the ideas behind them. This post hopes to be a on-paper rewrite of that talk.

This is a work in progress post, expect some spelling mistakes and an unfinished ending

What is Algorave?

Algorave is a form of live-coding where a performer writes code in real time in front of an audience to produce music. The code they write procedurally creates waves for the computers speakers to play in the real world. The code is normally projected onto the walls as its written as a form of light show, allowing the viewers to watch the code being written. You often see live gpu-shaders being written and projected at the same time to play with the beat of the music. There's a wide range of languages people use for this though the most common ones that I've seen are the Haskell based TidalCycles and the Ruby based Sonic-Pi.

The music produced in these performances can range massively and sometimes be somewhat avant-garde or peculiar, using mathematical algorithms or randomness to produce unique sounds or beats.

What drew me to algorave

I initially found algorave though my Raspberry Pi as a child as, for a long time, Sonic-Pi came pre-installed with most Pi's (hence its name). I looked into it on and off but never got very far with it until years later during my sixth form years when finally I decided to dedicate a weekend to learning it fully. Through learning it I was introduced to its community and I found it a really lovely place. It holds some really interesting concepts at the core of its ethos:

Temporary code

Algorave and live coding in general produces code that constantly grows and changes. During live-coding you'll remove or rewrite large chunks of your program. Its in a constant state of change and everything is temporary. This is at the core of the community. Its common practise to start a performance on a blank file and at the end of your performance to delete it entirely.

Algorave was first started in a more official capacity in the early 2000's by TOPLAP, the Temporary Organisation to Promote Live Audiovisual Programming and this too reflects that temporary nature of live-coding. The purpose of this organisation was to help live-coding become a naturally growing and evolving art, people taking it in whatever direction they felt right. Once it becomes big enough, the idea is for the group to shut down and leave the medium to its own devices.

I love this approach so much, I've found it to make live-coding a really freeing activity. If I'm feeling burnt out with code I often find myself going to Sonic-Pi where I can just write till it stops being fun or I start feeling restrained by what I've built at which point I just erase the code and start again, making something completely new. I see it almost as the programming equivalent of doodling on scrap paper.

Diversity

From the very beginning diversity was at the core of algorave's ideals. From its early starts in the 2000's, live-coders have run exclusive workshops and sessions for women and minorities and most live shows open slots specifically for people who may not normally get a voice. This has lead to some really interesting outcomes with the live-coding community being one of the most equally balanced communities, with a really good gender ratio and a wide queer presence within it.

I think it says a lot that even in the early 2000's the community was focusing on this and driving for a wide range of people to take part in it. It shows a real genuine understanding of why diversity is so important and the outcomes of all of this have been amazing. Algorave is a somewhat common style of performance at a few small queer bars near me and I feel like this really shows that the mindset behind it has helped produce a community that's incredibly welcoming and open.

Trying to say nice things about you

I want to write you a meaningful card.
Something that proves I like you.
I try to compare you to a tiny bird with a titans soul.
I try to compare you to a bubbling liquid amber-stone.
I try to compare you to an embossed, page stealing book.
I doesn't work.

But I give it to you,
And it becomes your favourite thing anyway.

Thunder storm

The entirety of space inverted
all altered save the quietly terrified earth
cast small against our focus on the clouds
a gateway to the drama

HRT stopped for a month

My stubble's back.
Not had this for years,
my personal symptom of the wider issue.

My skins different.
I rest my hand on my face,
its rougher, greasier by the day.

Now I suffer my past.
Its familiar pain is here,
shared with friends in memory, made real now.

But! It lets me see him.

His face is back.
Whats it been? 3 years?
You've changed too my long gone friend.

He looks comfortable.
The stubble's still there, 
but womanhood has strengthened him.

Together we know.
The proof of our ideology,
our experiences have steeled us.

Look After Yourself

My daughter,
she sits with me, showing me pictures of my family.
My whole life stretched out in one column on her tiny phone.
I can see every change in me laid out,
the visible ones at least.
I've had weeks here to think about the others.

Life, gathering knowledge, 
The first time I saw myself in an adult more than a child.
The first time I saw a teenager and thought, 
"you don't even realise, how much we see what you're going through".
The first time I realised they were more adult than me now.
The first time I saw them understand our roles had reversed.

I guess that's what life has been, 
gathering those new knowledges.
Learning the universal experiences one by one.

I wish I could go back, a bit at least.
Go through it again with all that.
These thoughts I have with me now.
To be a child, knowing the elders see my soul.

...

My grand-daughter,
she's not taking it well. I'm ready.
"Look after yourself", that's the last thing she says to me.
Not even a goodbye. 
That's fine, she's working on herself, I can see it.

And here it comes now, the final universal knowledge

Planets

Picture planets. Populating the pitch black pool, playing.
Thousands.
All asleep to their aquaintence, all alone.
Or are they?
Each an epitome of experimentation, exploring and entangling itself.
See within:
Creatures contending, confronting but caring closely, colourfully.
Unquestioning.
Food is finite. A fleeting forceful forage, fight or find. Fun.
Life.
Spheres sharing a state of shifting standard. Sleeping on siblinghood.


Now picture the other as it sits and changes as an intelligent world it holds concrete and coal and computing rocks of static and sleep on this It dares you It holds the power in it hand to change itself to grow consciously and reach out of the membrane and meet more members of its class teaching itself ships and space and science and steel all resources from its heart as it builds itself anew ready to rock and roll and receive gifts from the many friends sit silently but still subsist smarter stone than those before. It just needs to find them.
"I've been reaching out but Im yet to see them."
"Where is everyone else?"
"It cant be just me."

A new experience

"Maybe you just didn't like the people you dated before"
maybe.
the uncomfortable sex,
the forced "I love you"'s,
the dislike of how they held their bodies,
the feeling of physical disgust at their smiles,
seen together, at once, in their place, explained away,
leaving me frozen for a moment, 
to melt into a joyful, embarrassed idiot.

And now I start to see,
the first long held promise of a future together,
the joy of an equal understanding of our situation
the terror of no longer experiencing this in third person
the shared will to make it work
the knowledge that for once, if it ends, I wont be the one to end it

And now I realise, the lens on my whole life shattered,
feelings don't default into resentment

Rainbow Superstructures

A very early attempt at writing a poem with a proper structure, unfinished at the moment. Hopefully will explore ideas around alternative ways we can build relationships.

some give themselves pearlescent towns
the time-tested reproduction
a well-beloved, truly caring
copy paste construction

but some will build their world
through talk and love and friction
building pastel spires
through their contradition

boundaries and love
unfolding conversation
falling upward safely through
a well meaning frustration
....
we build them in our thousands
despite all of their ruptures
and we still find joy and choose to love
in these rainbow superstructures  

Our bodies trace time

I got my ears pierced yesterday
I settled into myself years ago but I still try to push myself to change
Every once in a while

I start a new job soon
A new place, a new total context, I've never been there but I'll be settle into it
It wont take long

When I'm there my ears will still be healing

Our bodies trace time, beyond our ideas, they remain physical

My thoughts on permacomputing, the space its currently in and where it could go in the future

Yo! Please note that the permacomputing community has changed and improved itself quite a bit since I last saw it! I'm intending to update this at somepoint when I have the time. Check their wiki out and have a look around the community, form your own opinions :)

What is Permacomputing?

Permacomputing is a really interesting concept that I came across sometime around 2021-2022. Its a movement based around environmentally sustainable ways of using computers originating from the ideas behind Permaculture (a set of ideas around sustainable small scale farming and land management.). Its very much defined by its community who are constantly discussing it and the directions it could take as-well as implementing its concepts into their work. That community's wiki describes it as so:

Permacomputing is both a concept and a community of practice oriented around issues of resilience and regenerativity in computer and network technology inspired by permaculture.

The main practises behind it could be outlined as

• Re-using and repurposing old computers, most computers from 2005 onwards have all the power you would need for most small tasks, especially with well written code. So why waste them?
• Repairing and caring for chips and electronics
• Creating simple, low-power code that avoids taking up more power and processing time than needed and does only what it needs to whilst still being scalable and extendable
• Creating resilient code that avoids "Code Rot" by reducing reliance on other programs and external systems and the prioritises an "offline first" approach

My relations to Permacomputing

I'd been exploring the ideas behind permacomputing for a while before I discovered its community. I have always been very anxious around the environment and waste and originally found concepts similar to permacomputing through 100 rabbits (a research collective living on a boat, exploring the longevity of computers). As well as this I was somewhat aware of the concepts of permaculture. As I was exploring the internet one day I found the term "Permacomputing" and immediately knew it was a term describing the thoughts I'd been having. I looked into it and very quickly found myself passionately sifting through its wiki's and the websites of community members.

My thoughts

Low-power code

I think that permacomputing has some really interesting and strong ideas behind it. What especially holds my attention is its ideas behind reusing old computers and creating low-power code.

There is definitely some truth to the idea that most basic tasks we do today such as browsing social media or word processing could be done by any full-featured computer from the last 20 years or so. A lot of modern programs such as Microsoft Teams or Spotify do very basic jobs but consume unreasonable amounts of processing power (and therefore electricity) due to being buried under layers and layers of abstraction.

There's obviously reasons for this, we don't just use these big frameworks for fun.

• Web-development is very friendly and incredibly flexible
• Web-applications are super portable
• Developing with the web gives you access to a browsers entire graphics engine, implementing graphical effects becomes very easy

But its worth noting that there is 100% a downside to this, Microsoft Teams is known in most companies to be incredibly slow and prone to breaking, many laptops older than a few years struggle to run it. They're incredibly process hungry for what is realistically somewhat of a small task.

Most of these benefits we've listed aren't exclusive to web development and you could easily get a lot of them through many other languages. For instance, anything that uses a runtime; Java's entire slogan is "Write once, run anywhere"

I think once something has become a standard its easy for it to become the default "go-to" for companies, even if its not necessarily the best idea. When armed with a hammer, everything becomes a nail.

Another example of this could be AI, AI is incredibly useful and is great for solving a large number of problems that we almost definitely have no other way to solve. But nowadays we see it applied in many fields where it just isn't needed.

AI is incredibly power hungry and can often require ethically impossible amounts of manual work to produce. Its not something we should be using everywhere but as people get very excited for it they start just trying to apply it to everything and this is a massive waste of resources. Many things that could be solved with a well written algorithm instead become large AI design projects that produce massive systems that are expensive to power and just unnecessary.

I think these are both obviously problems that we can solve and are the easiest of Permacomputing's ideas to argue. A nice thing though is that they are also the easiest to implement at a wider scale. It just relies on companies and developers putting a bit more thought into what they choose and realising that just because we have almost infinite processing power, doesn't mean we shouldn't count our resources.

This has visible benefits to them too, it creates a system they have full control over that will be noticeably much faster. Bugs are easier to solve and code is easier to run when your program isn't relying on booting up an entire browser in the background or using an unreadable black box as its foundation.

Visible functioning

Another nice point Permacomputing makes is its statements on open-source code and state-visualisation

Computers are tools and I feel like its important we try to avoid hiding that. Whilst we obviously shouldn't make them any less user-friendly or force front-end users to look at code, we can definitely let users know what the computer is doing more whilst keeping that user-friendly face. A good example would just be showing error codes again. A small thing that takes nothing away from the user and gives a lot back. Other examples could be indicator lights on computers or better named background processes for when things need closing or checking in task manager. We could even take these things further and modernise them, rather than just reimplementing them, for instance we could use qr-codes for errors (something the windows blue screen now does really well). Or generate public wikis for troubleshooting from our code documentation

This has loads of benefits, it puts ownership and control of the computer back into the users hands, it adds that separation between the digital and the real, but also makes gives users an opportunity to try and fix issues themselves or at the very least ask a friend for help. There's nothing more frustrating than having an issue and being left feeling helpless.

From a developer perspective, open-sourcing code is a massive benefit too, it allows ownership of your tools and allows people to create communities around their software but that's a much larger topic and goes beyond the scope of this page.

Resilience

A final strong point is the "Offline first" approach, prioritising resilient code. This is something I really like too. Whilst obviously this wont work for many things in the modern age, a lot of services nowadays are relying on the cloud for things that they don't necessarily need or are just requiring an internet connection for little reason.

The internet is notoriously unstable, large quantities of information are produced and lost constantly, this isn't necessarily something we can stop (outside of archival efforts). Its an inherent part of the internet. But, if we build systems or infrastructure that reliy on these things this becomes a much larger effort to maintain. It goes from finishing code and being able to lessen our focus on it, to having to constantly ensure other factors are always in place to keep the project working. This isn't always an issue but it does objectively cost companies a lot of money and often leads to a lot more work than is needed.

From a customer facing side this is an issue too, products that were paid for can be discontinued without much notice as a company finds its too much money to be worth sustaining and masses of software history can be lost. It creates code that has a digital use-by date.

Being Positive

When talking about Permacomputing I often find I start feeling like I'm just complaining about the modern world and I think that is can be somewhat true. Permacomputing is very much a rejection of certain aspects of the modern world and a core part of its development is through critique.

However, I think its really worth looking at the creative and forward thinking side of the community, to see what members are experimenting with and creating. Often building work beyond the aspects that are critiqued and often trying to explore and show other alternatives. A few nice examples are:

• Solar Protocol, a system the allows solar powered servers to share hosting power depending on which ones have the most power at a current moment in time
• FarmOS, a database system for farmers to track their work and systems in a centralised and self-owned fomat
• Uxn, an incredibly low-spec runtime that allows for the creation of graphical programs that run on almost any device

Despite the critiquing, the community very much has a positive view of the future and discuss a lot of really interesting and powerful ideas.

Critiques

It is worth noting I do have a lot of critiques for Permacomputing as well however. There is definitely a reason I don't identify myself with it. Whilst it talks about a lot of interesting ideas that make me really happy, it also does have a few flaws in my eyes.

Weird apocalypse stuff

The original text that coined the term Permacomputing was written by someone called Viznut, who originally defined the term around creating computers that would "survive the apocalypse". Although this is mentioned less now, the idea of "Design for Decent" is still very much in the veins of the movement.

This doesn't invalidate its thoughts but its very much worth noting that some of its ideas at their core do come from a fantasy of the modern world collapsing and some form of anarchist utopia rising. I feel like this unrealistic and a bit detached from the real world. Whilst climate change and many other issues do endanger our world, this isn't a sudden change and I feel that we're unlikely to get to a situation where their ideals are going to come true.

Anti-Progress

Another thing worth noting is that Permacomputing is most likely not going to ever catch on at any wide scale. Its focus is on learning to enjoy and make do with what we have and whilst I do feel like these are really important values (and ones that I personally follow), they're not ideas our society abides by. Telling people to actively stop using things that are benefiting them with little material benefit to doing so doesn't normally lead to much.

As well as this, it often relies on users being very technical and almost always relies on giving up certain aspects of modern technology which most people would never want to. Its ideas normally focus around building specialised systems to be used by groups of people, such as a farming database or digital archive. The things that don't, seem to expect people to own and create their own electronics for which they wrote "personal computing stacks" (collections of self made tools and programs).

A summary of where Permacomputing holds strong

In my opinion Permacomputing mostly carries weight in its discussion of efficient software, rejecting large frameworks where they aren't actively required and pointing out their resource inefficiency. Along with this its discussion of reusing old computers also holds very strong. From my experiments with older computers I've found they can often be just as fast as modern computers or even faster, the main limit is often bloat and bulk in operating systems and software.

I think that these ideas can often be implemented. Especially in a personal capacity or within very specific workplaces where they could offer benefits over drawback, such as farms.

Its a fun idea that makes some really valuable points and I hope to continue exploring the aspects I agree with in my own projects but beyond that I'm not entirely sure.

The Aber Robotics Society is a small society of friends at my university who meet every Wednesday in a robotics lab and work on their projects. I originally joined to learn basic electronics but found a lot of good friends there and a really nice sense of community.

While there I have learnt most of my knowledge of robotics and electronics and worked on a number of projects including a basic two wheeled remote control robot (my first project where I learnt the basics of electronics), a program that takes photos of people, converts the images to lines and g-code and sends them to a CNC machine that draws the images and a watering system for plants I keep at my house.

During my second year I gained the role of quartermaster which left me in charge of the robotics cupboard where all of the societies older projects were left. Alongside with work, I helped run AberSailBot which has its own page here.

Projects

This site documents a few different projects I've worked on whilst at the society, including:

• CNSelfie
• SailBot
• Self-Built laptop

This year I have become president of my university's computing society or "aberCompSoc". The society has a rich history with a website from the early 2000's still being hosted. In recent years the group somewhat slowed and became mostly a drinking society. From this, the previous committee asked me to run for president and run some more topical activities.

I was previously a member of my secondary schools "coding-club" and was very attached to it. It was a space for programmers to spend their lunch times working on projects and talking about their work with each other, providing a chance to meet like-minded individuals and work on projects with them. Since starting at Aberystwyth I felt that I missed that environment and being offered this role as president I felt that I had a chance to try and recreate it.

First week and general activities

Before the start of the new year, the committee (myself included) spent a long time planning events and communications with the computing department to bring in new members. We secured a 5 minute window at the start of welcome lectures for first and second years and sent an email out to the whole department. From this our first session resulted in 60 attendees, this was a lot more than we were expecting but it soon died down to a more manageable 20 or so which it has remained at since.

The group now meets weekly in a department computer room and spends 3 or so hours just talking and coding. These are our main sessions but we also run larger events every month or so, normally involving coding related games. We've previously run:

• 24 hour ASCII only game jams
• Gatherings where people take turns producing presentations where they incorrectly explain a computing concept
• Gatherings where people collectively create a website, freely pushing changes to it and having it update live

Additionally to our events, we are also a student chapter of the BCS. This means we somewhat work with the local branch, attending their monthly meetings and helping to organise events including hosting talks and "Show and Tell" events where programmers can run short talks about the work they've been doing.

FOSDEM trip

FOSDEM is a yearly open-source convention held in Brussels. A large portion of FOSDEM's organisers are AberCompSoc alumni and from this its become tradition to go there every year. As president I worked alongside the treasurer and organised the trip. My role involved organising flights and accommodation and communicating details of the trip while the treasurers role included managing the funds (tracking the account students paid into) and organising a sponsored coach from the university for the trip to and from the airport.

The trip ended up having 30 sign-ups which was double the amount we normally took so required somewhat more management than previous years. We ended up splitting the 30 into two groups of 15, each in their own accommodation and committee member. Each group organised themselves and ran internal trips and journeys themselves. The two only mixed once or twice for a large group meal and a group photo. This was a nicely scalable idea that kept things really manageable.

By the end of the trip we'd spent the full two days at the event and also spent 2 days doing tourism activities around Brussels including going to the atomium, a number of museums and some fun after-parties. A full description of the trip can be found on the society's website here.

I'm really proud of this trip, considering how many people came, I was sure something would go wrong but from that overly cautious mindset the entire trip ended up going relatively well with no major issues!

SailBot is a university society I joined in my first year. We built and raced self-driving robot sailboats.

I joined the society as it seemed like a really interesting challenge to build robots that had to deal with the insane variety of variables the outside world offers. Especially in the ocean where you rely on those variables to perform even basic movement. It felt like a good chance to try and learn to program machines that had to learn and work with those concepts.

First Year

I spent the first year in a team of 3 building a small boat we called "floating point". We started from a polystyrene hull and had to do a number of steps to build it, none of which any of us had any experience with:

• Coating the hull in resin
• Sewing a sail
• Designing and 3D printing mechanisms for steering
• Writing ESP32 code to run it using a digital compass and GPS

We were building these along with other teams, the idea being at the end of the building period they would be tested and raced. By the end of the year only our team and one other had finished our boats so we tested them in a less competitive manner in still water at the local docks. Our boat failed to find a GPS connection and was unable to steer itself but the developer from the other team lent us his software which allowed us to still compete.

Second Year

In my second year at SailBot we collected new members and organised ourselves into teams to wire up and program a small unused RC-Laser found in our storage using a Raspberry Pi with an Arduino as a servo and sensor controller, communicating over serial.

We designed protocols for communication between an Arduino, which drove the hardware, and a Rpi, which ran navigation. Different teams implemented different systems and we hoped to pull them all together but ran out of time as the uni year ended and a number of us headed off to industry years.

Learning

Before SailBot I'd never worked with physical mediums such as resin and wood outside of 3D printing. Carving out the hull and coating it, along with designing and sewing the sail was an amazing experience for me and taught me a great amount. The team I work with within the society are lovely people and, at this point, close friends.

Who I am

I'm Rosia Evans, I'm a programmer studying at a small university in Wales and soon to graduate! My work at university focuses on robotics but generally aims towards the lower level parts of programming. Previously this has involved topics around esoteric assembly languages or C/C++ programming. My experience in industry has revolved around testing, writing internal tooling or maintaining services, this has all been done in Python and C#.

(Reload the page to see a different image!)

In terms of my work, most of it involves:

• Designing small simple tools which follow the UNIX philosphy, often written in C/C++ or Python but slowly moving towards Rust and Hare
• Designing long lasting and clean systems, often with heavy realiance on unit tests, a concept I feel quite strongly about
• Writing code that runs on real machines, for instance, self-driving sailboats or agricultural robotic hardware
• Debugging and repairing old electronics, for instance this server or my camera

I've been programming for most of my life. My main language is C++, but I also have multiple years of experience in C#, Python and Java and some loose experience in Typescript and C. I'm currently learning Hare and Rust which have been very exciting! My first foray into a clean languages with genuinely modern features that aren't just bloat!

In my work, I prioritise simple, future-proof and reliable programs/documentation/processes and enjoy the challenges around designing these things or refactoring them to fulfill those values. I like to consider myself open, friendly and empathetic whilst still willing to push back when I feel I disagree with something.

Outside of work, most of my interests lie in experimenting with other ways we can live. This shows up in all sorts of ways from me repairing my own clothes, to seeing how much I can cook from bare bone ingredients, to living in a housing cooperative.

To see all of my work, check the navbox

Overview

Aardvark was an open-source virtual reality project I joined and worked on for around 2 years between 2019 and 2021. I started out writing small add-ons for it and eventually ended up working with the main developer on creating core parts of the system.

What is AardvarkXR?

Aardvark is a framework that allows users to open small apps (known as gadgets) over the top of other virtual reality programs. Its program agnostic so runs in any other app. You could think of it as a mobile phone for use within other VR applications. Its main focus is providing small utilities such as calculators or note taking apps. Developers can create apps for Aardvark using web code (React and Typescript) which it then renders over the users view. These renders can be 3D which is a big positive as most core VR systems don't support 3D rendering on overlays so Aardvark does this itself.

Due to all the code being web-based and run on servers, all gadgets are innately multi-user (with a small amount of work from the developer) and when in social VR apps, people can open gadgets that will be seen by all other users within that program using Aardvark.

My Work

I was first introduced to Aardvark through a hackathon the developers ran on its initial release. When taking part in this I had no experience with typescript or web development in general, so I was required to teach myself over the course of the 3 days.

I worked on an audio visualiser tool that ran in the background of users environments and also helped other developers, designing and creating 3D models for their work. One example of this was a set of icons I modelled for a playing card app (one of the first apps to be published on the platform).

Around 4 months later I was working on some 3D art in VR and realised it would be really useful to be able to bring reference images into my VR space. I remembered Aardvark and revisited it to create a photo viewing app. This was originally a personal project but became a team effort with another member of the community who offered to join development.

The app allowed users to upload images which were stored using ipfs and had multi-user functionality allowing different people to show each other photos.

After this I, found I was enjoying working with Aardvark and after talking to the main developer ended up working on the base code of the project itself.

Originally Aardvark had the user open its UI through a button on their hand which took up valuable visual space used by a lot of other programs.

I was tasked with creating a more intuitive solution which ended up being a gesture based system. With little to no guidance I had to read and gain a full understanding of the projects mid-level inner workings and rewrite large sections of it. After a week or so I produced a gesture system that allowed the user to bump the ends of their controllers together to open and close the menu. I also created a developer tool to allow developers to tweak the gesture to ensure it worked for their specific controllers.

Looking Back

Aardvark slowly fizzled out as it went on, never gaining much traction from developers sadly. Although it did become somewhat known in the VR space for a while. The main developer moved on to other projects and after that it fell quiet. Although I'm less invested in VR development nowadays looking back I still feel like it had a lot of potential and I'm somewhat sad it didn't take off. I still use it when working on 3D models in VR but past that it doesn't see regular use.

Aardvark was my first open-source project and I feel that I learnt a lot from it. It helped me learn to prioritise what I did and didn't create pull requests for and ask for help around, showing me how valuable the main developers time was. In terms of project management it taught me a lot around prioritising my work and my communications when in busy, high stress teams.

Here's a little collection of some drawings and 3D modelling I've done in the past that I'm proud of!

Heres a collection of general drawings I've done too :)

Summary

This documents my attempts to build a smart system to maintain plants. This has mostly been a chance to develop skills with electronics whilst letting me experiment with concepts near automated farming in a small form-factor I can work on in my flat at home. It's being build almost entirely out of second-hand, reused parts from old electronics.

The Ideas Behind This

I first began this project when I initially came across the idea of automated farming. It was a really intriguing idea to me and I spent almost a year thinking through concepts but didn't actually act on them. Eventually I got to a point where I really wanted to just try and build something physical to experiment with my ideas so this project came to light as a small way for me to try this.

Around the same time, I'd been reading around Permacomputing for half a year or so and although this didn't massively align with its ideas I wanted to try and implement some of its main concepts in my work. This being the reuse of old computers and the production of independent and resilient technology.

From this I came up with the fun idea of building it using only reused parts from broken machines. This also felt like a good test of my electronics skills, re-purposing and re-wiring old components to work outside of their original purpose.

Process

The pump

While this idea was first developing I was staying home for the Christmas break and found a broken cat water-feeder in our shed. This was essentially a broken ceramic bowl with a fountain and a still fully functional mains-powered water pump. Finding this was what solidified my ideas and made me commit to the project.

Along with this I had:

• a Rpi Pico a friend had given me from their old electric bike
• a mains relay from an old electronics project of my dads
• piping taken from a beer brewing kit I had been given a few years back

These parts were enough to get the pump working at a bare minimum. I put them together and wrote some basic code to turn them on and off. You can see a post about this along with a video of the pump running here. Its worth noting this still lacked a proper codebase for interacting with the pump outside of turning it on and off for set amounts of time.

My next aim was to create code to allow the circuit to push specific amounts of water. As I'd not bought the pump I was using, I had little idea of how much water it was able to move so I set up a small experiment. This just required code which turned the pump on and off for different set amounts of time and had me measuring the amount of water it pumped. From this I was be able to realise it had a rate of 30/ml a second.

While testing this I met an interesting issue. I ran the code with different lengths of time for the pump to run in and I found that when I then worked out the average and tried to use it to pump specific amounts of water it would always be slightly off. At first I thought the pump was just old or inconsistent but as I was testing it again I realised the water levels in the measuring cup kept rising even after the pump stopped. At this point I realised my mistake, the two containers were level with each other and a siphon-ing effect was causing their water levels to balance out!

I ran the test without the pumps water pipe sitting within the beaker and this solved the issue.

Measuring moisture

My next aim was a moisture monitoring system to feed into the pump. For this I needed a moisture sensor. I felt that this would be a rare enough component that I may need to buy one myself and looked around somewhat but couldn't find any likely solutions so ended up buying an open source sensor as a compromise. I was kind of unhappy with this solution but felt there wasn't entirely another option. However, a month or so later I was discussing this issue with a friend and they pointed out that the basic theory behind the part was actually very simple and I could in theory make one myself. I noted this as something to come back to when I found myself needing more sensors.

From this sensor I soldered and build a very rough system that would measure soil moisture every few hours and if it went below a certain threshold would run the pump for 2 seconds. This had few functional uses but was a good proof of concept that the two components could work together.

For a proper system I hit some interesting problems. Namely how would I give quantity to how moist the soil was? The sensor gave a 1 to 0 real number representing its capacitivity but what this actually represented in terms of the soil was something I was pretty unsure of. The system didn't need this to function, a number of other systems would have still worked such as the one currently implemented. However I felt as I had the knowledge of a farming university to hand I may as well try and find out.

This will be updated as I do so.

The Case

Whilst thinking this problem though, I started working on a case for the circuit. I initially build a small long housing that just held the pico and mains relay. Printing this taught me some interesting lessons. I had build the case as two separate halves that fit together but after printing it I found my printers tolerances were too big and the parts didn't fit each other.

I reprinted this a few times and eventually talked to another student with more experience in 3D design and she helped me work out the printers tolerances and take them into account. This resulted in a case that correctly clicked together.

The case itself was not water-proof so required a resin coating and finalised electronics that would allow me to put sealant around the holes for the pump and sensor cables. This has yet to be done.

Still To Do

This is as far as I have got at the moment. The project has somewhat taken a break as my searching for an industrial year placement took priority over it.

However I want to keep working on this project and have a list of planned out next steps including:

• Solve the currently mentioned issues around quantifying soil moisture
• Un-hardcoding the water thresholds by setting averages and allowing the user to point out when the plant is in a good condition
• Allowing the pump to run on battery power, its a mains pump but only actually required 5v/12a so this could easily be done
• Cleaning up and finalising the electronics into a smaller portable system
• Exploring building my own capacitive moisture sensors
• Exploring creating a modular system that could monitor and water multiple plants

Critiques

The design I have in mind for this project has a few interesting flaws. Firstly this is in no way scalable when built with scrap. It isnt even slightly a valid circuit for larger farming systems. They would have to produce it with ordered parts, if not use an entirely different system.

Secondly, if expanded, this system would require individual modules for each plant that it monitored. This feels inefficient and a much better system would involve one, more complex, tool. This would be moved between plants being used on all of them, as opposed to the current collection of "dumb" modules that are spread between each plant. This is definitely feasible but not at my scale. This does still feel like a good way to develop skills towards creating this.

Its worth noting, this is my first steps towards making something a bit more realistically usable, you can find my first designs towards that here

I've been going to fosdem most years since 2022. On my first year there I made some friends who I now make games with.

We call our group Green-Opal Studio, (we got this neat little website here). Our main focus at the moment is on a small game titled Toad Towers, a deck-builder game where you play as a frog architect building sky-scrapers. Its in its early days but working on it has been really fun!

As well as this, the group takes part in the Ludum Dare game jams pretty regularly. I took part in my first one October of this year, we made a game about a raccoon re-greening a scrap yard and building robots out of junk. It had hand-painted sprites, an adaptive sound track that changed as the scrap yard got cleaner and some really neat little animations that I set up.

This video shows some of its gameplay nearing the end of the jam, a few bug fixes were made a bit later on too.

I've found I get a lot out of working with this group, they're great friends and I really enjoy making games with them as a break on-and-off from other workd.

This is a direct copy of a post I did for Dogtooth on leaving you can find that one here!

As I approach the end of my industry year at Dogtooth, I’ve been reflecting on everything I’ve experienced – from technical lessons to unexpected personal growth. I wanted to share my time here, both to document it for myself and to offer insight into what working at Dogtooth is really like.

My Background

I came to Dogtooth looking for an industry year. I wanted a career that combined my love of programming with my love of the outdoors and agricultural robotics seemed like a really good start towards this. Dogtooth felt like exactly what I was looking for. It also provided some interesting ideas: the idea of working towards a new kind of farming with less reliance on mono-crops, less food waste, and although not as strictly related to their work, less reliance on herbicides and pesticides. The idea of automating food production pulled on a political chord in me too, a chance to see what the people working at Dogtooth saw in a future where their product was commonplace.

I also wanted to develop some new skills, especially around electronics and firmware and I wanted to get my foot in the door at a pleasant company so I had somewhere to turn to after university.

What I Learned at Dogtooth

From my first month at Dogtooth I started learning a wild amount. I’d basically been dropped into a new career space and had a lot to take in. Although I joined the software team I was also assigned an electronics and hardware tutor who would meet up with me once a week to help me develop the additional skills I wanted to learn. This was done even though I wasn’t working in that space! This tutoring was amazing and really gave me a lot. Having one-on-one time with someone was so valuable; any question I had was not only answered quickly but in a way that really integrated itself into my understanding well.

I also found that I very quickly learnt a lot about how an entire electronic rig, like our robots, is structured. Learning how a computer can work, manage and run electronic parts really blew my mind! It turns out, our robots have tens of embedded-systems computers inside them, each managing different parts, communicating with a main central computer through a networking system. I’d gone into this assuming there were just chips with massive sets of GPIO pins connecting to all the arms and rails at once. The more I dug into the robots as I worked with them, the more I learnt about the depth of their functioning and the systems Dogtooth has built around them.

Through the job I picked up an insane amount of knowledge about the stuff I was already working on in my life outside of work. To list just a few things off the top of my head: the insane depth of C#’s inner workings and flexibility, Python’s weird little quirks, all the tools and processes for maintaining and running servers and real time data services, and a massive amount just working with a relatively old codebase; seeing what we can do well and badly to ensure the code stays robust and maintainable for years to come.

The Unexpected Lessons

More interestingly, I got a large number of things from my time at Dogtooth that I wasn’t looking for such as interesting views into other worlds and other ways of working. A nice little example of why we should always be pushing ourselves to try new experiences.

An Ego Check

Dogtooth has been a great place for working slightly above my skill level and regularly making mistakes and learning. As an agile company it’s really open to failure and does really well at leaning into a blameless culture. This has been really good for keeping my ego tuned down, regularly reminding me that I don’t know everything, and that I’m surrounded by highly experienced people whose knowledge runs impressively deep. There was a lot of challenging work but my line manager very quickly made sure that I felt I was able to say “I don’t know how to do this, but I’ll give it a go as long as people are willing to help me when I need it”. Developing that kind of knowledge based humility whilst still being willing to undertake tough work feels like a really important skill that I’m glad I developed and I felt like it was definitely at the core of how Dogtooth treats its interns.

Working in a Team with a Range of Opinionated Views

People at Dogtooth are great at their job, and this comes with confidence. They know how to solve a problem and will fight for their view. Coming into these teams and seeing sets of 4-5 people consolidate their mass of widely different points through discussions, compromise and friendly jokes and somehow seeing them all come together in a clean, realistic and reasonable form is incredible. I had moments when I first joined Dogtooth where I’d see this and it would leave me in a really positive mood for the rest of the day. Just being around people as ideas fly and get slowly thinned out through genuine expert discussion is really comforting, especially nowadays when it’s easy to think people with adverse opinions just can’t get on. Dogtooth is really solid evidence against this.

A View into Manufacturing

Dogtooth is a very small company but needs to have a full production team. A nice benefit of this is that this means you have a really wide range of people but everybody still knows everybody. This has given me a chance to get a view into areas of work I would never have otherwise even thought to learn about. This especially applies to manufacturing where the head of the department, has a long and well-established background in the field. Talking to him about this has been profoundly eye-opening. A really interesting view into an industry that’s actually very good at organising humans and solving human problems. Just seeing the whole process a product goes through, from R&D to production to the planning of mass production has been super educational and shown me a whole chunk of the real world I’d never have got to see otherwise.

An Unusual and Sincerely Pleasant Working Environment

A smaller thing, but Dogtooth is just a really lovely environment. I really hoped to get some outdoor manual labour mixed in with my coding whilst working here and I’ve definitely got it. Helping out while a whole team of really lovely people tear-down or rebuild poly-tunnels, weed plants or clear out containers has just been really pleasant. Being able to go and sit outside while working on my laptop on summer days or just having to sit outside whenever a robot needs testing makes Dogtooth a really unique place to work in a really good way; there’s almost a whimsy to it. That whimsy is also added to by having an infinite supply of strawberries to eat during the summer.

I kind of like to think that this is a bit of a window into what computing could be in a world where Dogtooth’s industry is thriving. The programming community definitely needs to be more willing to go outside and Dogtooth sometimes teeters on showing what that could look like. It’s a bit reminiscent of some sort of solarpunk utopian story.

Final Thoughts

That final point definitely ties into my feelings on Dogtooth generally. Working at Dogtooth for a year has really shown me the kind of environments I want to work in. In terms of my future goals and career aspirations, it’s definitely convinced me I want to stay in agri-tech, especially as it continues to grow and carves out its own space. Hopefully it becomes a place with a strong tie to nature, a trust in its workers and an understanding of its own identity. I think Dogtooth is moving in that direction well and I’m definitely hoping to return eventually.

Overview

During my gap-year I took an internship at Skipton Building Society as a software tester. Initially my job was to experiment with the use of automated testing however I eventually ended up presenting this software to groups of senior developers and working to integrate it into the society's general workflow, moving between teams helping them implement it.

SBS requested that I stay after my internship and I worked remotely one day a week whilst at university until my final year, training testers in automation.

The Start

My initial internship was a paid 9 month role where I was given SmartBear's TestComplete system to learn. The society hadn't integrated automated testing beyond unit tests into their workflow so were hoping to learn whether it was worth using. I was paired with one other tester and we learnt the system and began using it to automate testing of the society's customer portal.

I found TestComplete a really nice system with a very user-friendly design for non-programmers and felt it would be a really good fit for the society. Within a month or so I started taking initiative to bring it to the attention of others, mentioning it to senior developers. One ended up organising a call with a larger collection of 20-30 and asking me to talk them through it.

I hosted and ran the call, showing the benefits and drawbacks of the system and getting the developers opinions and over-time we decided it was worth using. Licenses were bought and handed out and I began moving through scrum teams helping them integrate it into their work.

Additional Actions

On the side of this, I also did a number of other tasks:

• Acted as a general software tester for a variety of departments
• Researched Gherkin, a language designed to allow expected test outcomes to be written in a standardised manner. Which also presented to a number of developers and organised a number of meetings around, facilitating conversation around its uses.
• Co-Ran a coding club to up-skill testers and make them more familiar with coding principles.
• Produced a large quantity of documentation and educational resources learning and working with TestComplete and coding in a testing context in general.
• Pushed for the society to set-up standards for all their future automated testing.

Skills Learnt

Throughout this internship I found that my social skills developed greatly. I got a lot better at giving criticism, being willing to ask questions and admitting I didn't understand things (all things I somewhat originally struggled with).

I also:

• Learnt a large amount around Microsoft's Azure Cloud Systems
• Learnt the ins and outs of manual and automated testing
• Gained real world experience of an Agile working environment, which I greatly enjoyed.
• Developed a much stronger understanding of APIs and back-end programming which I had never previously looked into.

Multiple times during my work there I was requested to stay as an apprentice rather than go to University, I did turn this offer down but worked there remotely from University one day a week remotely and full time over summers.

I found SBS an incredibly friendly and safe feeling place with a really healthy culture. Their attitude towards change was very exciting to work in. Multiple times I found I would make a mistake and be worried my teams would be annoyed or upset only to find they wouldn't even consider it an issue and with zero negative responses they would just ask how they could help to fix it and work with me to plan a solution.

How it started

I have a small shoulder-bag I take everywhere. I often find myself wanting to take just that bag with me somewhere but also needing to take a laptop and having to take a whole backpack just for that laptop. Separately from this, during my summer last year, I often found myself sitting outside and programming. Sat on the grass outside my dormitory or on the local hillsides with friends. Around the time I'd started experimenting with E-Ink Screens for a small project I was considering starting and I realised they would be perfect for programming outdoors in bright environments. I'd also around this time wanted to try and create electronics that were resilient to outdoor environments.

From these 3 ideas I decided to try and create my own laptop that would fit within the 20x20cm space of my bag and was fully usable outside whilst remaining low-power enough for long trips.

The initial design

My first plan for this computer was a small rectangular slab, made of various layers of components and each made of an identical standardised frame. Each layer screwing together to form a sandwich of parts. The idea behind this being that it would be incredibly modular and simple to design and expand. This idea stuck around for a while but eventually got dropped as I hoped to make the electronics somewhat more accessible and because wanted a computer that wasn't just a flat slab of plastic.

My second idea was a flat rectangle but with its upper third on a friction hinge to allow it to be tilted and tightened. This idea has stuck around and is currently my main driving design. Whilst its somewhat more fragile, its a much more human and open design and in theory shouldn't be too much more complex to design.

The components

Most parts needed I've currently got or have bought, including:

• A raspberry pi 2 b+ I've had lying around for years
• An E-Ink screen bought for a previous project (more on this screen in a bit)
• 4 18650 Li-Ion batteries and a battery board for charging and power management
• A sim-card board for roaming data

E-ink display

The E-Ink display is a core part of this project and something I'm very excited for. I have a strong love of E-ink displays as things that are incredibly energy efficient, usable in almost any conditions and are a bit slower than normal screens proposing some really interesting challenges in terms of UI design.

As a basic summary, these screens are black and white displays that look very similar to paper. They don't use lights to produce colours and instead change their reflectiveness by controlling the charge of ink particles in little chambers of oil in their surface. This has a really nice effect of allowing them to work with the ambient light around them. The outcome of this being that they're are visible just about anywhere you can read paper and have an amazing viewing angle. Their only drawback being a slow refresh rate and a very small colour range, each added colour adds around 1-5 seconds to the refresh rate so generally they come in black and white only.

I find this limited refresh rate a really interesting challenge and in terms of what I'd be using this laptop for (programming) it wouldn't be too big of a drawback.

People have been experimenting with E-Ink screens a lot in the past few years and even got them to a point where they can display functional desktops, which I think is really amazing. However despite this I feel that a terminal would be a really interesting limit to put on myself when using this laptop. As well as this, the screen I have bought is incredibly small (2.13 inches diagonally) and I am somewhat determined to work with it, this making desktops somewhat harder to use.

I spent a long time working with E-ink displays and rewriting their drivers for this project. I'll be writing and attaching a blog-post on this soon.

The battery pack

The power source for this laptop is just a set of 4 Li-Ion batteries, googling this setup most people claim it could power a raspberry pi with a display for around an hour, and for around 10 hours without a display out outputs.

This wouldn't be a great battery life for most devices but using an E-ink display runs means we can run the display directly from the Rpi's 3v gpio pin and it only ever consumes power on refreshes so I think this could last much longer. Its something I definitely want to try and measure once this project is finished.

The sim-card

If I'm wanting to use this laptop outdoors, it would be nice to be able to do so without having to tether it to my phones Wi-Fi hotspot. After a bit of research I found hats and boards for the raspberry that support sim-cards and support most protocols. This seems like a really fun chance to explore a technology I've barely ever touched.

The Keyboard

The keyboard has by far been the biggest challenge of this project, There are no keyboards small enough for what I'm wanting whilst still having big enough keys for what I want. My two options I have at the moment are:

• Bring a bluetooth keyboard
• Design my own

Bringing a bluetooth keyboard seems like the most realistic option and is most likely the one I will go with, but I have done research into keyboard layouts I could use, including a really unique one a friend suggested which I ended up testing out.

The first physical result of this whole project has been a model of the laptop with a sticky surface for me to move keys around on. This has allowed me to experiment with different layouts and see how they feel in my hands. Using this I feel that I have somewhat come across a design I like but I've yet to decide whether its worth buying a large amount of switches and keycaps to solve a problem I already have a solution for (bluetooth keyboard).

Progress Update 4/1/2024 - Little Things

Over this Christmas break a number of large steps have been taken, leaving me pretty close to finishing this project!

• I was given a SIM7600E hat for my Pi as a gift, meaning I now have the final missing piece of my hardware! Getting this working took a few days but its now ready to give my laptop 4G data. In theory it could also allow for phone calls and GPS tracking but I don't really have the time to write the programs for these at the moment and it feels like something I wouldn't use too much.
• The final decision has been made on the keyboard, I have a bluetooth one I'm happy using. This keeps my project a bit more realistic as designing a keyboard would likely double the amount of work for this.
• A final CAD design has been made and checked with an engineer friend, images below. I've created two versions. The first follows the original design and still holds space for a keyboard or other form of expansion. The second has removed this space but is slightly thicker as it places the hat on the pi. I'm really happy with these and they're essentially ready to be built.
• I met up with a friend who will help me with the wood working, we talked through tweaks needed to make the design more realistic to machine and the processes we would use for each part. This turned out better than I could have hoped and its turned out we'll get to do some really fun work, for instance we plan to do some wood bending which is something I've always wanted to try!

I'm really happy with my progress over this two week break. Its a shame the final wood work will have to wait till Easter but its just how things are with exams.

Progress Update 10/2/2024 - Re-soldering headers

In my previous update there's some CAD images, you may notice an odd design choice in these. The smaller system has a board sticking out the top. This was done because the pi and hat combined together are quite tall and a thicker device would be somewhat ugly and unwieldy. Having them stick out the top was an attempt to create a smaller device but I wasn't very happy with this. As a solution, this put the board at risk of damage and essentially worsened the ruggedness of the device just for improved aesthetics. In order to fix this I decided to resolder the header pins on my boards myself to try make them smaller.

This involved cutting the plastic from the header, de-soldering each of the 40 pins individually and then either re-soldering them directly onto the pi or finding some form of smaller header. I didn't want to directly solder them to the board as it would have been a bit too permanent (the idea of being able to disassemble this board if necessary is something I'm somewhat attached to). For a while I really struggled to find a header that was much smaller but eventually I found an interesting workaround. I found a header extender board that turned an RPi's GPIO pins into a set of two. Using this I could then attach the hat using a shallow female header and still have access to the GPIO, essentially making the device slightly wider instead of taller.

I bought the board and headers and after soldering them on I was left with a device that was a third or so smaller than it had originally been! I was really paranoid I was going to damage my board from this but it worked out so I'm quite proud of it.

Progress Update 15/3/2024 - Apline Linux... Again!

All of my hardware is ready, so I started working on the software, doing this I realised my Pi was taking up more energy than I'd hoped. To fix this I switched to a lighter operating system. Alpine Linux supports Rpi arm chips and I'm familiar with it from making the server for this website. So I figured I'd give it a go.

Progress Update 29/4/2024 - Wood working and a broken psu

Over the Easter holidays, I met up with a friend and we started working on the wooden body of the device. We produced two rough base plates and started work milling corner blocks. We got half of these blocks done before I head to head back to uni. The amazing workshop engineers at the university were willing to finish off the last two blocks for me, which I drilled holes into and added threaded inserts to, resulting in this.

This is far from done, but its enough to build a basic frame I can use, I want to take something to emf camp, so I might try build it with just this for now.

As a side note, during this time I also worked on the software a bit. Doing this I ended up plugging in the pi to both the battery pack and mains, this lead to the pi charging the battery pack in reverse and popping one of its components and possibly damaging another.

Luckily the manufacturer was really kind and gave me the names of the components I needed to replace. I ordered them from Ebay and one arrived quite quickly (the other I'm still waiting on). These were smd components and I'd never soldered anything other than through-hole before so I did some reasearch and found a great video by a channel called eleneasy which prepped me perfectly. I gave it a go on the first component that arrived and although it hasn't been tested yet, I'm quite happy with the result considering its my first time.

Progress Update 22/5/2024 - Board repair, board breaking, drivers and woodworking

Since I've got back to University, a lot of progress has been made. The board was just repaired with the help of a university technician, they lent me a microscope for soldering some smaller components back in place and also let me use their heat-plate to remove and replace the broken chip. In this process a leg got snapped off another chip though! This chip cant be shipped in unless its from China, especially not in the time-frame I need. I'm going to try find one on another board somewhere. If I cant its just two mosfets in an ic so I'll try bodge something.

Outside of this, the E-Ink display is now working on Alpine Linux! This took a day or so of driver experimentation, you can find my notes on how to get this working here if you want to do this yourself. The screen can now run the demo, I also learnt the c library to use the drivers and logged that here (in a new category for the nav menu!). This library still needs implementing, for now I'm going to try use PaperTTY for the sake of time.

I also got most of the case finished off, the entire thing is fully modular save two pieces which involve glue (baseplate everything builds onto and an element of the screen base). All that's left to do on this is the cage around the screen which should be done soon. The University has a laser-cutter which I've been given access to and this massively sped things up.

An hour or so before uploading this update I was trying to get PaperTTY working and accidentally destroyed all the data on my Alpine setup. This sounds insane but its quite easy to do as I'm running Alpine diskless so no changes are saved until you run a specific commit command which creates an "overlay" that sits over the top of the normal system, and if this commit goes wrong it can destroy your previous overlay meaning you don't have one anymore. I always hear Linux users talk about checking backups and just backing up in general, now I've experienced first hand why.

I'm very lucky I saved my notes on how to get the E-Ink drivers working otherwise I would have had a terrible time. I've now realised I should be backing up my overlays and I've also created a setup script for getting certain things like the e-ink drivers working. When I'm sure this works I'll add it to my notes on setting up E-Ink drivers for Alpine

Nearly finished, left to do is:

• Finish the screen cage
• replace or repair the 8205a chip with the broken leg
• get PaperTTY working

Progress Update 26/05/2024 - all hardware done, screen drivers left to be finished

Firstly, I managed to find a replacement 8205a on E-Bay coming from Essex, this arrived and has been successfully soldered onto the board. One of its legs looks like its touching a pad it shouldn't but I checked it with a multi-meter and it seems fine.

Secondly, the screen cage is finished! it looks quite nice outside of the baseplate being made out of wood with an odd sheen finish to it. Its pretty sturdy and I'm surprised at how strong the hinge is for what is essentially just a screw.

Finally, the screen has been rewired to use individual cables for each pin rather than its hat, this gives me a whole set of gpio pins for me to use if I ever want to which is nice and it gives the board a bit more space.

I also got PaperTTY installed after a lot of installation error squishing and library hunting. I haven't tested it yet or put it on start-up but it seems to be installed fine. Next update will be the final one with the working device hopefully :)

Summary

This project's first working full version is nearing completion! Afterwards I intend to make small improvements but these won't likely be logged here. Keep an eye out for a rewrite of this page soon, this one will be archived

This site is a small project I worked on over the course of a few weeks while first returning back to university during my second year. Its hosted on a small lighttpd server running on an old laptop from around 2003. I wrote a small C++ program that takes in MarkDown files and builds them into webpages. During start-up, or alternatively on request, the server pulls this code along with the markdown from separate repos, builds the code and runs it. This then builds the website from that markdown and puts the pages in a folder for Lighttpd to host.

For similar ideologies around hosting, see the homebrewserverclub manifesto and the feminist server manifesto

The Thoughts Behind This

During my first year at university I read a lot around the concept of Permacomputing. This is a set of ideas around reusing old computers and writing small systems that avoid code rot whilst using as little power as possible. The driving idea behind this being that we've had computers that are powerful enough for most small jobs for quite a long time and realistically a lot of old e-waste is still perfectly good for these kind of small, personal, low-risk jobs. Permacomputing experiments with whether using these would be environmentally friendly if done correctly. I'd been reading into Permacomputing for a decent while but never properly had the chance to experiment with my thoughts on it.

Along with that I'd also spent time doing a module in my first year on the history of the internet and found the www's origins really inspiring, the idea of a language/system that was easy for just about anyone to learn, that was incredibly simple but super flexible. When learning about this I'd kind of started to feel like we'd lost that part of the internet. Websites are always generated with insane complexity which feels almost unnecessary when we still have that simple flexible system its all built on top of. I wanted to try and use that simple system again, to experience it for myself.

The Code

The Server Backend

I wanted the system to be as lightweight and fast as it could be, hopefully leading to a very power-efficient result. I decided to use C++ as it was my main language and was also very fast.

I was planning on writing the server code myself, exploring libraries such as oat++ or crow but as I researched them I realised they were built for large scale systems. Whilst this is very much a strong point for them, this server was only meant to host a small static site that would see very little traffic and using these large libraries felt unnecessary and unwieldy.

Whilst researching I also found Lighttpd, a relatively old and incredibly light weight server program build to host static pages with high demand but on a small scale system wise. This felt like the right solution to my problem as it didn't implement large frameworks that wouldn't get used but would still allow my server to be reliable.

The Parser

I initially planned to write a markdown parser and spent a day or two working on one, writing a SAX-Style one. I was unsure whether this was a workable idea for markdown but through thinking about it and planning how it would work I felt quite confident it would be much faster than a DOM parser. I was however, aware that creating a full-spec markdown parser would take most of my time up and I only wanted this to be a small project.

I looked online and found [md4c][https://github.com/mity/md4c], a simple and insanely fast parser written in very low level c. I ran some benchmarks and found it could parse incredibly large documents in less than a millisecond which convinced me pretty quickly. It seemed much faster than any other option but also much simpler. After starting to implement this I discovered it actually parsed markdown text in the same SAX-Style system as I had planned to which made me very happy.

From here I implemented md4c along with code to read the filesystem and combine the resulting html with a template. This took a few revisions as I wanted to make it as flexible and reusable as possible, making little to no assumptions about the template being given. By default the code searched for an empty <article> body and placed the generated html within it and a similar thing for the <nav> menu. This could then be overwritten by handing in other identifiers to look for.

The code would collect every markdown file, generate a nav menu summarising it then go through each page copying the template and adding that along with its matching markdown/html and writing it to a given file.

The Hardware And Its OS

A few months before this project, I found an laptop in a "free to a good home" box outside someone's house. It was very old and originally ran windows vista but someone had tried to update it to windows 10 and broken it. I took it home as a chance to take it apart and mess around with it but in the end found myself needing a server for this project and this felt perfect.

The main difficulty however was its power-consumption. Its power consumption felt like it would be much higher than newly bought lightweight hardware such as a raspberry pi. I spent a lot of time weighing up the differences and decided to try the laptop and measure its power consumption over a length of time.

The other big issue I hit was the operating system. I wanted something as lightweight as possible with little to no unneeded features. These being things like a desktop or the additional packages you would find in something like stock Ubuntu. A big difficulty here was my lack of knowledge around operating systems, until that summer I had always used windows, only then switching to Pop_OS. I had almost no knowledge of other systems but weighed up a few well known options including:

• Base Debian
• Raspberry Pi OS Lite (very stripped down Pi OS)
• Arch

These each had their own issues. I was unsure what was included in base Debian and what Raspberry Pi OS Lite actually involved (Rpi OS Lite has almost no documentation online). I talked to a friend with more Linux experience than I and he pointed me to Alpine Linux. A massively stripped down Linux distribution built specifically for lightweight servers and with its own package manager that offered a Lighttpd install!

I decided to go for this very quickly as it seemed built specifically for the ideas I was wanting to test out.

Alpine Linux

Alpine Linux was my first non-debian Linux experience. I really enjoyed learning about it and found its documentation really helpful and detailed with almost everything I needed. The OS itself was really simple and friendly too which was very nice. Using it was a really educational experience for me, I was very surprised by what wasn't included as I slowly learnt what came from Debian and what didn't. Alpine didn't have sudo, any sort of file transfer systems or any of bash's basic features. Realising this and understanding the lower-level commands they were built out of was really interesting (for example sudo seems like its just a complex wrapper for su, a command that switches users).

Alpine essentially, from a users perspective, is made of Busybox (a very basic shell that I also found runs within ubuntu after a kernel panic) and OpenRC which just controls how background services run. These two programs did everything I needed with OpenRC managing Lighttpd and Busybox letting me interact with the OS and running a startup script for me to pull from Github and rebuild/run the C++ code.

Summary

I've finished this project for now and I'm very happy with it, it has all the features I wanted it to have and a few extra. I think it's a really good exploration of some interesting ideas. It feels very unique though I do worry if its basic visual style is putting some people off it and also possibly causing accessibility issues for certain people.

I tested the power consumption of the laptop and found it only consumed around 23w which I was very proud of. In comparison my main laptop (a model from 2022) draws 60w on average. Sadly, this is still much higher than the draw of something like a Pi (by almost 5x) so despite my efforts with code, this is still much less efficient than some machines. This was kind of to be expected considering the Raspberry Pi's purpose but I was hoping to get it a bit closer than 5x higher.

On a somewhat unrelated note, one thing I would still like to know is what the original power consumption of specifically the old laptop was. It would be really nice to know whether my choices for the software used did actually make a noticeable difference. At the moment I don't have time for this but at some point I would like to boot windows off an external ssd and see how much harder the laptop has to work.

Still To Do

Outside of this there's still a few things I'd like to add at some point, a big one would be basic video sharing. At the moment this website relies on other servers to store and share files, such as YouTube or Mastodon. A core principle of Permacomputing is avoiding reliance's like these and whilst this isn't a principle I'm super invested it it feels like it could be fun to try to implement and would mean I wouldn't need to worry about my website becoming outdated over time.

Stability

I ran a few basic tests on the servers stability and found some interesting points. First, its stability is quite good, I hear horror stories of people always having to check in on and debug their servers. At the time of writing this server has been running for almost a month without issue, having been down only once when a flat-mate unplugged it.

A second point worth making though is that despite running Lighttpd, the hardware greatly limits the traffic it can take. From some benchmarks with httperf it can handle about 10 page requests a second before one request will fail, I'm unsure whether this is caused by the laptop or my home router. I intend to look into this at some point.

Fun stuff

• You can still see the first test article for this website here.
• You can see the website I used for a decent few years before this here. I cant host it as it takes priority over my current site on most search engines. Its CSS is much more modern and has some really fun quirks, for instance the gallery page which has no JavaScript, its 100% pure CSS.

IRL Friends

I have friends with websites! You should become one of them! See them all below (they're cool as hell with unique interests and fun views)

• Wren!
• Megan(with an extremely cool website)

A lot of us are on the AberWebRing

• Bob
• Edmil
• Lucas
• Ezra
• Oscar
• Cam

People On The Indie-Web I've Chatted With

• Elle
• JPop

Badges

Waveshare don't explain their drivers, and as far as I can tell no one online has either. The drivers themselves aren't too complicated, you could probably work them out within half an hour or so, but that's no reason not to explain it a bit and save someone that time.

What are we given?

The C drivers aren't too wild, every device has a similar set of methods:

• Initialise the device
• Display given image
• Display partial image at coordinates
• Clear screen
• Sleep

Any more complex behaviour is driven by our code, altering an image and eventually drawing it to the screen. Luckily, waveshare have made a set of helper tools, the main two being GUI_BMP and GUI_Paint. GUI_BMP is relatively simple, it takes a bmp file and loads it in the correct format for us to just display directly using the display method. The Paint toolset is worth describing in a bit more detail.

GUI_Paint

GUI_Paint is a small set of tools that let us alter and create images before we push them to the device. Its main focus is on a struct called Paint, this holds a pointer to your image (set with Paint_SelectImage()), subsequently called paint methods will alter this data, adding text, shapes and bitmaps to it. You can then access this and draw it through the original pointer you gave the SelectImage method, it seems to always directly edit the image data so there's no need to apply it, just call your devices display method on that pointer.

GUI_Paint also offers the ability to rotate, scale and mirror the image, the methods for setting mirror, scale and rotation don't actually do anything other than set a value in the Paint struct and I haven't found any method to apply those settings to a given image, flipping it or such. The one thing I have found is that if you call a method called Paint_NewImage() (this fills the image buffer with blank memory and resets it for use), it will use the rotate data to swap the width and height but that's it.

The best way to learn this library, as with all C, is to give the header file a look and get a summary of all the methods, hopefully this overview will give you a head-start on understanding what you're reading though. The file is in lib/GUI/GUI_Paint.h.

A little more detail on the general driver methods

As I said, the drivers are pretty bare-bones, essentially just letting us write images to the screen. Its worth going a little more in-depth though, we have an extra file not mentioned yet, this is DEV_Config. DEV_Config uses a few other files and essentially sets up our computer to communicate with the display, it works out what gpio drivers our device has and sets ups its methods to use whatever they can. This is something definitely worth calling as soon as your program starts up, before even calling our normal Init() method.

With that in-mind here's a list of actual methods we're given:

EPD_7in5_V2.h (or any other driver):

• EPD_7IN5_V2_Init(), sets up device parameters
• EPD_7IN5_V2_Init_Fast(), ¯\_(ツ)_/¯
• EPD_7IN5_V2_Init_Part(), sets up device to do partial refresh, can be called anytime before partial refresh is used aka doesn't have to be at the start with Init()
• EPD_7IN5_V2_Clear(), draws white image to screen
• EPD_7IN5_V2_ClearBlack(), draws black image to screen
• EPD_7IN5_V2_Display(), displays given bytes
• EPD_7IN5_V2_Display_Part(), draws an image at a given location
• EPD_7IN5_V2_Sleep(), puts the screen in deep sleep, essentially a way to turn it off and make it take less power while still having it plugged into power.

DEV_Config.h:

• DEV_Module_Init(), sets up spi communication for your computer, checking what drivers you have and using what it can
• DEV_Module_Exit(), essentially closes anything its opened

This is half written atm, expect missing images and half written paragrahps

Tools

• Woodland Trust's Ancient Tree Index, find a really cool tree to sit under
• Falling Fruit, urban food scavenging map, forage for things
• Urbexology, explore some abandoned spaces (its cooler if you don't use this and instead you're just aware of your local spaces)
• Calendar Customs, go to interesting local celebrations

Foraging

Foraging is great! Its a really good way to feel a bit more connected with your local environment, local history and do some more exciting cooking.

I've got notes written up on my Foraging Notes Page

A few examples from there are elderflower, which is everywhere in Britain; Linden/Lime trees that can be used to make tea or chocolate; Wild garlic obviously and also Burdock that has a carrot type root you can eat!

Reading

• Offensive Horticulture

I've been using Linux for a while and I pretty regularly find myself hitting issues I know I've hit before but not remembering the solution and have to go slogging through stack-overflow to find it again. I now have this, this is a list of all the issues I hit and how I resolved them. For future me but also maybe you? :)

Networking

Unable to connect to internet but able to connect to local network

Try ping googles dns server at 8.8.8.8, if this doesn't work then problem is outside your pc, if this does work but you cant get to other sites then check /etc/resolv.conf. This file holds pointers to dns servers, it might be wrong?

Alpine Linux

Setting up apk repos

Go to /etc/apk/repositories, add extra ones there. put @name before it to give it a name so you can specify you want to use that repository:

echo "@testing https://reposito.ry" > /etc/apk/repositories
apk add package@testing

Kernel Shenanigans

Removing modules

You can blacklist kernel modules in /etc/modprobe.d/blacklist.conf

blacklist modulename

Helix Editor

Clangd wont find libraries

Clangd only uses info from some places so cant know everything, you can add a CMake command to let it export build info then clangd can use this

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

Helix wont do syntax highlighting

Sometimes helix will come with its grammars unbuilt, or the grammars will have been deleted. Fetch and build them and this should fix it.

  hx -g fetch
  hx -g build

A collection of recipes I like and use.

Recipes

• Great hummus
• Butternut Squash Mushroom And Pesto Pie
• Tomato Fried Rice, this works well with chinese cooking wine instead of fish cauce, add tempeh and tenderstem brocoli to fill it out!

Recipes I Intend To Try

• Samosas, Alternate Samosas
• Lo-mein Noodles
• Pumpkin Risotto Fritatta
• Chestnut Pie
• Potato Gratin

Sites To Find Recipes On

• hungryinthailand.com
• minimalistbaker.com
• indianhealthyrecipes.com
• cookwithmanali.com

A collection of recipes I like. Generally when cooking I try to cook using stuff I could concievably grow at home. I'm a big fan of us increasing our use of local small scale farms and this is me partially trying to prove thats viable.

Almost everything here is vegan, some recipes will use non-local stuff but will try to suggest an alternative, I likely don't use that though :/

Index

• Drop Scones aka American Pancakes
• Pesto
• Chilli
• Jamaican Stew
• Shakshuka
• Flapjacks
• Ciaras Miso Soup
• Olive, Sundried Tomato and Balsamic Vinegar hummus(?)
• Tapenade
• Kale Crisps
• C.R.E.A.M Pasta - my favourite pasta recipe
• Shortbread

Also see the list of food I want to learn to cook

Protein Sources

For a vegan you should try ensure your meal has protein, good sources are:

• tofu
• tempeh (my current favourite!)
• cashew nuts, pistachio nuts
• quorn
• peas
• chickpeas
• kidney beans
• pumpkin seeds
• lentils
• peanut putter
• quinoa
• buckwheat
• wild rice

Cooking Without Eggs

Eggs are a core part of baking, they provide 3 main purposes: moisture, binding and protein heavy bodies (e.g. in a quiche). There are different replacements depending on what you're wanting to achieive.

• For moisture, 1/4 cup applesauce
• For binding, 1tbsp group flaxseed and 3tbsp of water
• For a body, 1/4 cup silken tofu

Hi, I'm Rosia

I'm a student into computers and environmentalism. I spend my time programming, repairing things and trying to balance my overly active social life along with it.

Things I'm proud of:

• Self-Built Laptop
• Camera Repair
• This Site

My thoughts:

• Algorave
• Permacomputing

More about me

If you're not a fan of the colours of this site, or want a lower contrast version for accessibility, you can alter the theme in "Page Settings" at the bottom of the nav bar.

This website has a new home! Its now hosted on little orinoco

A number of experiments that eventually lead to some cool photos and a neat camera.

Note this page is a draft and definitely will contain spelling mistakes and general nonsense

It begins

In 2022 I found 640by480, this (along with a very similar site) is a website where people post photos taken using old digital cameras. I found the energy of these photos really appealing, and as a fan of re-using outdated tech I wanted to give it a go. However, I try to own as little as possible generally, especially when it comes to tech, so I didn't find myself going out and getting one. I decided to just keep it in the back of my mind and hope I eventually came across something in the future.

A year or two later, fate finally dropped one in my lap! I came across it in a charity shop, its battery was far beyond over-drained and it required an obsolete proprietary memory card, which it didn't come with. No one else would be using it so I didn't feel too bad buying it and saving it from landfill.

It was a fujifilm mx-2700 I don't know much about it or how it compares to other cameras of the time but I'm not super bothered. Its what I'd been given and part of the appeal of old tech is the challenge of working with that.

This page logs the series of experiments I did on the poor thing.

Power!

First things first, getting it turning on. It originally didn't, and I had no way of knowing if this was a dead battery (forgive my hardware-baby ignorance), a broken screen or something much more complicated. My first plan was to get power running into it to see what happened. It had a barrel plug for charging and for battery battery free use. This plug was marked as 5v and in my genius mind a plan formed.

"Okay, a barrel plug is just a positive and a negative, this runs at 5v. USB does power the exact same way. What if I just remove this plug and wire a USB plug into it instead"

USB runs at 0.5A 5V, this plug ran at 7.5W aka 5V 1.5A. My brain decided this wasn't important information until much later on and I got started!

I removed the plug and added what in my mind should be the new standard for USB plugs and nothing happened. It didn't work.

I spoke to some friends and we did some testing, firstly, that barrel plug was only for charging the battery, not for running batteryless. It was here my friend pointed out to me that we could test the battery with a multimeter. We checked the it and it was way beyond saving. That thing was never charging again :P. I didn't want to buy a new battery for what was possibly a broken camera, so we used a power station to directly put power into the battery contacts and it turned on! (For anyone following at home, note that it won't turn on if the SmartMedia Card slot is open, if its disassembled, there's a switch near that port you should hold down).

This meant it worked! So I decided it would be worth the investment to buy a battery, I bought a battery and one of its weird little storage cards (A SmartMedia card, whatever that is).

These arrived and the device was working! I could take photos! But they were being held hostage from me! I couldn't get the photos off the weird little storage card.

Reading the weird little storage card

Fun Fact: Most modern computers do not have SmartMedia card slots

In the year 2000 fujifilm created the perfect storage medium and "big sd card" have spent the last 20 years trying to systematically eradicate it from the face of the earth because they fear its cool wiggly line.

You can't buy USB SmartMedia card readers, I personally couldn't find any original ones that came with the cameras online. This was a dilemma but my saving grace was EMFCamp2024. EMFCamp is a hacker festival that goes on every two years in Britain. It has a great second hand store where people can donate old tech they want to get rid of, that ranges from server racks to radioactive isotopes (see the toot here, see the Wikipedia entry here). Someone happened to be selling a front panel for a tower pc that had a slot for a SmartMedia card!! It was designed to plug directly into a motherboard but it was better than nothing!

I took it home and realised it plugged into the USB section of the motherboard. After a bit of research I realised this plug had the exact same layout as a USB cable. I figured I'd try to wire it to a different weird USB plug I had, since that went so well last time. It didn't work, I got that classic power surge error and not much more. A few days later I was walking down a street and saw a bin filled with a load of identical circuit boards with USB cables coming off them (?????). Like the gremlin I am I grabbed one and cut the cable off it, took it home and wired it up. For some reason this one worked!

After this there was only one problem left to solve.

Recharging the new battery

That's right, I didn't have a charger. Luckily I did have a generic Li-Po charging circuit from a previous project. After some googling, I was confident this would work. I tried it, just holding some wires to the battery's contacts and it started charging! This was perfect! I just needed to make a proper shape to hold the battery and build proper contacts and I'd be done!. The circuit even had a fast charge mode!

...

The fast charge mode burnt out the board.

I intended to fix this, but that would take a while, so as a temporary solution I tried something a bit unhinged. I removed the old battery cell from the case of the dead battery that came with the camera. Attached an 18650 of similar specs to its contacts and lied to the camera about where its power was coming from.

This worked but only slightly. The camera would boot but couldn't switch modes and would crash when I tried to take a photo. My guess it is wasn't providing enough power or the tiny little circuit board attached to the old cell might have actually been more than just an over-discharge protection circuit.

Weirdly, re-trying this a day later it worked so my guess is the connection was just off, here's a photo, taken with the camera, of the battery whilst its powering the camera.

This is where we're up to, will update when I've got further!

Photos!

Here's the initial pictures I took on my first battery charge.

Notes: talk about how cool the internals of this camera are mention this lad: http://people.surfaceeffect.com/pete/tech/nouserservice/mx2700/

I've taken part in game jams for many years now. It started out as something I would do to get more experience making games but its now just a genuinely fun past-time I fall into every few months. When I was at University I worked within its Computing Society to run them very regularly and they were always lovely. For a few years I was also in a game-jam team who took part in Ludum-Dare regularly.

This is a brief overview of the various games I have made over the years.

Rummaging Raccoon - Godot

A small game about a raccoon re-greening a scrap yard. This was the first Ludum-Dare game-jam I took part in with my jam-team and I immediately started asking if we could do games relating to nature 😅.

I set up the menu and character movement/actions. I also designed the main character!

Tunnel Tunnel - Python

I ran a number of "ascii-only" game jams at uni, the aim being to provide accessible game jams to students who had very little coding experience and wouldnt be able to use OOP based game engines yet. This became a yearly thing for us, turns out there's a really fun challenge to the minimalist aspects of ascii and you can take it as far or as simple as you want.

My first proper entry to this was "tunnel tunnel", a game about a character tunneling a tunnel. You're presented with a dark and hidden path and you have to predict what will be down the next step in the tunnel before you take it. This starts off impossible but emerging patterns appear.

I was really proud of my implementation of this game, it was modular enough that I was able to make a fully interactable tutorial in half an hour just using pre-existing modules from the actual game.

Retrieve Them - Godot

A very unfinished game. I was really attached to the idea behind this game but the friend I was working with lost drive and dropped out after a day :/

You play as a robot whos job is to collect the bodies of climbers who died climbing an un-named and infinite mountain. You take find them and take them home to your graveyard to give them a proper burial.

Gameplay wise, it was a 3d game where you had 4 different robot arms: Picks for movement, a grabber for collecting people, a harpoon for traversing larger gaps and a heater which you would periodically run over other arms to stop them freezing up. One arm could be controlled at a time and would follow the mouse, the idea was to be kind of difficult to control and have a lot of pressures from the harsh environment.

This game didn't end up with any working code but it was one of the few recent game-jams I've done which used blender, so I want to put some images up from there and also share a video of the menu I made, which I think was really cute.

Evolution - Godot

The first game-jam I ever took part in, this was a game made with a few friends, including a musician who made music for it!! The theme was evolution so we decided to greate a roguelike dungeon crawler where you went through the same location on repeat but slept for thousands of years between. The game limited your ammo and damage but made you very fast, so it forced you to leave some enemies alive each round. Between rounds, when you were asleep, evolution would occur in the enemies you left behind. If you let enemies that you struggled to fight live, your game would get harder, but if instead you chose to control the evolution and left the weaker enemies live, you'd have an easier time.

Enemies had 5 or so traits which controlled their damage, speed and behaviours, these would be collected and altered whenever you slept. You'd be given random traits at the start too, so that different enemy traits benefitted you different runs.

We didnt finish the game but we got a single enemy working with a few traits, player movement and rooms that randomly altered somewhat between sleeps whilst still being similar enough to feasibly be the same room.

See the code here

See our planning document here

Decay - Java

A game made for the theme "Decay" with a friend in Java. I dont have a Java toolchain set up anymore so I cant get screenshots of this game.

The premise was to create yahtzee but the dice decay. You'd play a round and depending on how well you did, you'd see spots pop off and fall from the dice. Dice would be more or less likely to lose dots depending on your use of them, so you'd have to balance your dice choices out. We also had a shop where you could buy various powerups to help lessen the decay.

I'm really proud of the code for this game, it was made between two people and we structured it really well to make this as easy as possible.

find it here

FungalCreep - Python

Another ascii game made between a few friends under the theme "Infestation". This is a hard game to describe, its a blend of Othello and Battleships. You would place "infectious" counters on your enemys board or "blocking counters" on your board. Infection counters would slowly spread and infect other tiles, blocking counters would allow you to remove infectious counters using Othello rules.

Sonic-Pi is a language built around live-coding and producing music algorithmically through code. Its based off Ruby and has a really nice twist that you see often in the live-coding community. This twist is that the code you write is constantly running and and being evaluated so as you write it the music being produced by it changes live.

I find Sonic-Pi a really nice way to relax with programming, it produces code that's inherently temporary and I find that really freeing. It can be easy to get burnt out with code and with Sonic-Pi, when that hits I just delete all my code and start again building something new. In another post I described it as "the programming equivalent of doodling on scrap paper".

I've written a larger post around my thoughts on algorave and live-coding in general here but it doesn't link any of my work so this page is here to represent the music I've created.

My work

Most of my code written in sonic-pi is never saved, that's a part of its process. But I have a few that I'm quite proud of saved. These are both on YouTube and can be found below, they're slow to start since I build up the code over-time so to give a better example of what they sound like these videos should automatically skip to good points.

On the 2nd and 3rd of May 2026 an Aberystwyth University Alumnus called Duncan Thomas was kind enough to put on a hackathon with the help of AberCompSoc. The theme being to design a conference badge, like those found at events such as DEFCON and EMF.

I formed a team with Bob and together we tried to see what we could do with the hardware we were given.

But first; some learning

We were presented with some new hardware:

CYD (Cheap yellow display)

The CYD is an adorable little board with:

1. ESP32 (ESP32-2432S028R if your being fussy)
2. 320 x 240 LCD Display (2.8")
3. Touch Screen (Resistive)
4. RGB LED
5. LDR.
6. A whole host of support for fun periphals (I2c, SPI, microSD, speaker)

All attendees were given one of these lovely little boards to keep courtesy of Duncan!

We were then shown how to flash https://docs.micropython.org bundled with lvgl to the boards using esptool, and let loose to experiment running example code and trying to work out how to do whatever we wanted the board to do for the rest of the day.

Myself and Bob spent a lot of the day trying to find accurate documentation for the specific libraries we were using, which turned out to be rather frustrating due to the various different versions of the lvgl library. At the end of the day Bob decided to give the arduino libraries a try and found them much more friendly and we immeadiately had a good path forward for our project idea.

Team: Beauty of the baud

For our project idea we thought it would be fun to have a pair of CYD boards that would allow students to surreptitiously pass notes in class by drawing on the touch display and having their actions mirrored on the oppossing screen.

To do this we first looked at example code for drawing on the screen and detecting user input, from there we started mangaling the example code into a shape that better served us.

Drawing on the screen

The TFT and XPT2046 libraries provide really clean methods for extracting the location on screen the user is pressing as well as for drawing new pixels on the display, so we had a stylus drawing on the screen basically at the start of the day. This section was done using pair programming which was fun.

For color changing on implemented the lvgl library to have a color slider and had TFT draw a block of pixels by the slider as a color preview, this proved to be fiddly as lvgl and tft libraries defined their coordinate systems with different origins. This section Bob developed myself while I worked on networking.

Network coms

Esp has a neat lil' protocol called esp_now. According to Duncan, this works by sending out invalid wifi discovery frames with whatever data it wants in. Because these frames dont follow the standard they should, wifi routers ignore them but the esp listens out for them and just grabs whatever data is in them.

You can use this to grab a struct, use C magic to just treat it as an array of integers, send those integers, then another device can recieve those integers, agressively ram them into a struct and itll just kind of work because that data happened to originally have been that struct.

Receiving

Receiving was chill, you create a callback method which will be called whenever data is recieved, its given these numbers and you can do whatever you want with it. We turned the data into a struct with an x, y, and colour.

Sending

Sending is a bit harder, whilst recieving devices just listen for screams with their mac address on, sending needs to actually have the mac address. This isnt too bad though. You have an "init" method which takes a mac address, sets up a "peer" struct and writes that to memory which the esp code reads.

Then you have a "send" method which takes numbers (which are secretly our struct) and it just sends it

win ig

The Code

Our project can be found on my forgejo instance.