I want to start tracking the books I've read and my thoughts on them so I remember them more and take more from them.

• Half-Earth Socialism

Unwritten so far

• Reclaim Your Mind: A Manifesto
• Capitalist Realism

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.

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.

A space for smaller, more personal thoughts, not full essays, not political/philosophical sections for the lines, but little things

• An Obituary For My Living Mother
• Poems
• The Archive
• Things That Things Shouldnt Do

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 have gained the role of quartermaster which leaves me in charge of the robotics cupboard where all of the societies older projects are left. I took the role hoping to archive the projects and build wikis for each project, encouraging members to document their work better for later members to come back to though this somewhat took a back seat as the president developed an amazing system that logs the owners of projects and peoples permissions for the projects using qr-codes and additionally we began to share more of our cupboard and its stored resources with additional societies.

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 build and race 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're currently collecting new members and teaching them the basics with the hope to eventually finish and re-race the boats from last year when the winter weather calms down.

Our current project is wiring up and programming 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.

Additionally to this we are intending to join The International Robotic Sailing Regatta race in Massachusetts at lake Attitash later in 2024. For this we're repairing and renovating an old bot build pre-covid at the uni named Dewi.

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 topics around agriculture and the environment. My major project/dissertation is on databases for seed-banks for example.

In terms of my work, most of it involves:

• Learning how robotics can work in real world environments
• Experimenting with how we can use computers in environmentally sustainable ways,
• Teaching myself to create low-power/high efficiency programs and robotics,
• Learning about ideas behind farming automation and how we can produce more food whilst keeping our methods sustainable, becoming an active member of communities such as TwistedFields,

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 which has been very exciting! My first foray into a clean and minimalist language with genuinely modern features that aren't just bloat!

Outside of work, most of my interests lie in politics and thinking up other ways we can live. This shows up in all sorts of ways from my repairing my own clothes to seeing how much I can cook from bare bone ingredients.

To see all of my work, check the navbox

This is an older post from my first personal website I created in secondary school, its yet to be re-written for this new website so expect varying degrees of quality

What it is

This project was completed for my Extended Project Equalification (also known as EPQ). During the EPQ, a student will pick a subject of their choice, research it and then either write a paper or create a piece of media (an "artefact") based on what they have learnt. For my subject I originally chose physics simulation as at the time I lacked confidence in maths and wanted to force myself to relearn and become more comfortable with it. The idea of combining VR with this later came about in an attempt to make the project more modern so more primary research and testing could be done.

The end result was a system that allowed the user to interact with a virtual environment with 6 degrees of freedom, they could pick up, move and throw objects with their fingers, hands and head being fully tracked to the real world. Due to time restraints, the physics simulation was released separately and, although fully capable of location and force calculation, could not take rotation of objects into account. The project was given a high A grade.

What I did

Over the course of 4-5 months I researched and taught myself a large amount of vector maths, the basics of C++, the basics of physics engines, a large portion of Blender and Unreal Engines toolset, a small amount of 3D rendering theory and the basics of game design for virtual reality. Using this I created a fully functional VR interaction system with many custom made assets, materials and classes as well as a very basic physics engine built in C++.

This project was completed for my computer science A-level. Students had to find a client and create a program for them, I chose my sister and created software to help her revise for her GCSE's. The software had to:

• run on her £70 laptop
• allow for files to be transfered between devices
• allow actions to be undone and redone
• be generic enough to work for any subject

At the time I was finding myself really interested in intuitive UI design so I also aimed to create a simple and unrestrictive system that I felt was easy to learn and use. Though I found I had to cut a lot of it for time constraints.

We were given 24 hours spread over 2 months to create the program and were allowed to choose our own langauges and frameworks. I chose to write the sofware in Unity as I wanted to learn a new engine and knew that unitys use of scenegraphs would let me avoud calculating the scaling and positioning of mind map components.

As one of the software requirements was to run on very low end computers I also had to ensure I was creating scripts that would run as efficiently as possible when compiled, so I ended up finding myself weighing up the strengths and weaknesses of different libraries, often choosing ones with drawbacks in favour of their lower usage of memory.

The outcome

The final system had a number of features:

• Fully working undo/redo system
• The ability to create and link text bubbles
• The ability to import images
• A drawing tool, along with options to optimise lines for slower pcs
• A save and load system
• A settings panel
• The ability to navigate and magnify the mindmap

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 still currently work remotely one day a week whilst at university, 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:

• 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 I still currently work there 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.

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.

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.

Generally, I don't massively enjoy game development but I've found that with this group I get a lot out of it and I'm enjoying visiting it on and off as a break from my other work.

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.

Over the last few months I've been slowly building up designs in my head and on paper for a future project, this page is for me to store some of those to show to friends.

The first problem is the moisture sensor, this is kind of long and I could imagine it blocking things or being hit against things so it needs to be able to be tucked away. This would be a moving part which isn't super ideal, main problems are:

• Mud debris getting in the mechanism
• Becoming overly complex or delicate
• Water-proofing

My initial solutions are below, but it feels like it would be worth looking into finding a solution that doesn't need to move at all, if the tool was attached to an arm then it could be something only gets in the way at a certain rotation and we'd only use that rotation when we're using the tool, that feels like a stretch though.

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!

A lot of us are on the AberWebRing

• Bob
• Edmil
• Ezra
• Oscar

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 my scribbled line, its a collection of things I find interesting or want to remember. Here you can find a good summary of my world views in the writings I find important and things I just think are neat.

If you ever want to make a personal website that feels alive, I think you have to accept that it's like a room: iterating between moments of cosy messiness, and moment of cleaning and sorting that are also good for the soul. The more you will force everything into a pre-fixed structure, the less it will feel like a space where someone's living. - ungual.digital

Pages

• Clear Line, An attempt to tie strict views I hold with evidence and citations. This is of dubious quality and likely will often be in need of a clean.
• Quotes, A list of quotes I like.

Important things

Writing that permanently altered me

• Kae tempest - A book of traps and lessons this poetry is genuinely probably the biggest driver behind a lot of my world views. Whole thing should be experienced in one session, somewhere outdoors alone and dark, whether that's sat outside a pub at night with a drink or in a forest.
• silly, goofy article about football in the future showed me that you should try to find wonder and whimsy in the everyday and the mundane, and that those things are vital to existing as a human.
• Contrapoints helped me realise how I want to experience love and helped me learn to respect myself, though nowadays I've realised they're a pretty flawed person sometimes
• CJtheX helped me work out how to exist in the moment and just actually feel things (the first of the two linked videos, second is a better summary but came out much later)
• Leon Rosselson showed me that its okay for life to be messy and imperfect, that we don't need a system to solve every problem and helped me understand what people say when they mean property is theft. He's a bit too radical for me sometimes but that's fine. He's 93 now and only has 3000 or so listeners on spotify. I wish more people knew about his music, there's a lot you can take from it that applies to modern politics.

Healthy conversation, thought and debate

• Cory Dransfeldt - Just Enough News
• xxiivv - how to have healthy discorse
• Some Defenses Against Misinformation

The value of other cultures (especially non-scientific, stereotypically "primitive" cultures)

• Against his-story, Against Leviathan! This is possibly the strongest narrative for properly emotionally integrating this point into your world-view, though the book itself is incredibly biased and a bit unhinged. Would recommend chapter 1 or 23 specifically, 23 especially.
• Twitter thread on african architecture

Anti-Growth, Small-Web, Small-Tech

• Factorio hate-post
• The reckless, infinite scope of web browsers
• Fucking webmaster
• Machines of Loving Grace by Reagan Bird - The utter evisceration of one of my core beliefs through empathetic story-telling
• Programming is forgetting A really amazing critique/rethinking of hacker culture
• A society that lost focus - A blog post complaining about the attention economy, reading it makes me want to stop owning a phone
• Damaged Earth Catalog
• Feminist Server Manifesto
• A set of notes from a feminist-server workshop run in 2013

The value of community

• Transcender manifesto
• The sky is falling, we've got this

The merits of open source

• Predator drones run linux
• The sustainability of the commons
• How to kill an decentralised network, a post about how companies purposefully kill off foss software

Less important side notes

Interesting Wikipedia pages

• The Autuer, a myth around the idea that something can be fully conceptualised and designed by one person

Cool people

• Lynn Conway, transitioned and restarted her career from the group up

National anthems which are neat

• Nepal, wholesome metaphone about people being flowers in the garland that is Nepal and being a multi-national country.

Interesting old internet things

• Red-bean
• Chiark/Greenend
• Old usenet posts I host

Neat Permacomputing/culture things

• Tiny polish farm working on self-automation
• Edge Collective
• Social media for old photos
• Group that writes low power software (suckless.org)
• Solar powered website/blog about eco-tech
• Photo album from farming commune EarthwordHousingCommune
• Main environmental cost comes from the production of a device
• Dude lives off grid and makes cool machines

Neat programming things

• Tetris programming
• Internet archiologist
• Bikeshedding
• OurPaint - FOSS Node based painting software
• Egotistical but funny rant about low level programming
• History of browser impersonation

Artists I like

• Aristotle Roufanis does photography of lonely cities
• Kate Lycett creates vibrant, glowing paintings of yorkshire
• The Designers Republic, creators of wipeout and masses or other bright bullish art
• Thomas Cole, paints tiny people across awe filling terrifying landscapes, ngl he was probably a cringe person though, hated industry and idolised america as the new world away from it all

Neat design things

• Walkman archive, a collection of examples of really lovely design

Stories where programs defy reality

• Email wont go further than 500 miles
• Wifi only works when its raining
• Magic switch
• Hard Drive wont work until you go to a meeting
• Janet Jackson’s Rhythm Nation crashes computers when played near them
• Passwords dont work when typed standing

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)

Usenet posts are one of my favourite forms of internet content, they age amazingly since they only stay on the internet for as long as someone is keeping them archived. They only stay archived while some random programmer still finds they hold place in their mind. They only stay in that persons mind while they're funny, unique or in some other way interesting.

I have a few posts I really like and I don't want to lose them so I've started holding them here, mostly just for myself. If you have another you've found that you think I'd enjoy, email me and I'll add it :)

The Benefits Of Using The Scheme Configurable Window Manager

Found listed as inspiration for the ratpoison window manager

A post I got completely obsessed with for a few weeks back in March of 2024, it describes how you can avoid drug addiction through the use of a good window manager. It also ends with an amazing little rant that really captures a certain breed of programmer that I love.

Advanced Missile Garbage Collection

Found in a microsoft blogpost

A description of an advanced form of garbage collection used in military equipment. Funny but also obvious when you think about it.

The Usenet Cookbook

Not deeply related but a useful list of interesting recipes a friend of a friend maintains. Also see his smaller list.

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

Boujee recipess

Other external recipes

Sites to find recipes on

https://hungryinthailand.com/ https://minimalistbaker.com https://www.indianhealthyrecipes.com https://www.cookwithmanali.com

Recipes to try

easy!! https://www.recipetineats.com/lo-mein-noodles/

https://madeleineolivia.co.uk/butternut-squash-mushroom-pie/

https://minimalistbaker.com/easy-vegan-fried-rice/

https://www.indianhealthyrecipes.com/samosa-recipe-make-samosa/ this is a great looking website^

https://www.indianhealthyrecipes.com/recipes/

https://www.cookwithmanali.com/samosa-recipe/

https://www.indianhealthyrecipes.com/samosa-recipe-make-samosa/

https://www.bbc.co.uk/food/recipes/vegan_pie_with_chestnut_13207

https://www.seriouseats.com/vegan-ramen-miso-creamy-vegan-vegetarian-food-lab-recipe

https://www.forksoverknives.com/recipes/vegan-menus-collections/vegan-leek-recipes-soups-casseroles-pastas/

• chipatis
• curry
• thai curry
• chilli
• stir fry
• fried rice
• lasagna
• potato + sauce bake
• steak and ale pie
• sushi
• avocado toast
• pasta and tomato sauce
• pasta and cream sauce
• pesto pasta
• drop scones
• mushrooms on toast
• soup
• stew
• roast veg on toast with hummus
• bruchetta
• stuffed pepper
• seasame ramen
• casserole, sausage casserole
• gratin!
• leek and potato soup
• canoloni!!!!!
• roti!! fluffy flatbread!!

https://www.forksoverknives.com/recipes/amazing-grains/pumpkin-risotto-frittata-mushrooms/

https://minimalistbaker.com/garlicky-vegan-potato-gratin/

for if you have chard beetroot and celeriac https://www.bbcgoodfood.com/recipes/vegan-pie

notes: eggs for moisture, 1/4 cup applesauce for binding, 1tbsp ground flaxseed and 3tbsp water for quishes and pies, 1/4 cup silkenn tofu

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

• tofu
• cashew nuts, pistachio nuts
• quorn
• peas
• chickpeas
• kidney beans
• pumpkin seeds
• lentils
• peanut putter
• quinoa
• buckwheat
• wild rice

Hi, I'm Rosia

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

The world stresses me out quite a bit and I want to help make it better, so I spend a lot of my time reading/thinking about politics or volunteering for activist groups. Most of my thoughts turn out to be off but I'm slowly getting there.

I'm learning to value simplicity, community and things outside of infinite growth.

Things I'm proud of:

• Self-Built Laptop
• Camera Repair
• This Site

My thoughts:

• Scribbled Line
• Permacomputing

More about me

If you're not a fan of the light mode 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/

This was my first project created at my univeristy's robotics society. Created as an interactive robot for kids coming to university open days, it would display a camera view and detect outlines then when a photo was taken with it it would generate gcode from these lines to direct the society's CNC machine to draw out what it saw. The idea being that kids could have drawings of themselves made by a robot they could take home.

It was finished over the course of two weeks in collaboration with a friend at the society.

Overview

The program worked using OpenCV. OpenCV would detect sharp edges and produce an black and white image, this would then by converted into a vector which was then converted into gcode as paths for the CNC machine. I found a library for converting between vectors and gcode but found it didnt have all the functionality I needed so ended up adding alot of extra methods and rewriting a few of them.

This GCode was then sent by Universal Gcode Sender to our CNC machine.

Gallery

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

Summary

When first starting out at university I found I had a decent chunk of spare time. The previous year spare time had been hard to come by so I decided to use this as well as possible and teach myself a new library for C++ and possibly try and make my first proper large C++ project. This started out with a number of experiments with SDL but eventually became a digital replication of the Uno card game with basic ai opponents. You can see the github for this project here.

The learning curve of C++ projects

This was my first major C++ project and it was a really interesting challenge. I came into it with 2 years C# experience, 4 years Python experience on and off and light C++ experience from slowly working through a book on the subject. Actually applying it in a large project with classes in different files and having them interact with each other was a really interesting learning experience. Previously all my work had just been making single files and learning the basic alphabet of the language. This was my first time making words.

For beginners, C++ has a somewhat complex compiler. Where interpreted and runtime languages let us off easy with simple compile options or often just a single default button to compile code with, C++ requires a decent few flags and often relies on a strong understanding of the processes going on under the hood (just like when writing with it). Without this I found myself hitting a lot of linker errors with little direction or explanation as to their cause.

I barely understood what a linker was to begin with so errors felt very arbitrary and I got very little from them. This often resulted in relying on trial and error, compiling individual parts of the codebase or commenting out sections of code, trying to work out what was causing the error. Eventually however I came across a really lovely explanation of header files on StackOverflow. Reading this really made what the linker did click for me and since then I've had very few issues. I've actually found myself sharing this post with friends and class-mates whenever I hear people struggling around headers or the compilation process in general.

Aside from compiling, C++ lets you do a lot of things that at first seem fine and wont be met with any complaints but later on can lead to issues (memory leaks for instance). Other languages will limit or warn you of these issues but C++ very much leaves you to it and assumes you know what you're doing. My lacking in knowledge of some of these issues are definitely somewhat obvious looking back at the code, whilst I knew about reclaiming memory and actively tried to use it wherever needed I've definitely missed certain areas, especially where it was used implicitly.

This meant that there was a lot of going back and refactoring as the process went on and the code still has a major few flaws even in its finished state. I'd like to go back and rewrite a lot of this sometime but that's not happened yet.

I would say that despite this, I really found myself enjoying having to think about memory when working on this. I was really proud of myself for how I handled a lot of resource usage. I managed to only instantiate each the Uno card texture once and use that amongst all the cards which I was very proud of. Using deconstructors for the first time had a similar rewarding feeling.

The final result

This program was my main project for the first few months of university. I feel like it taught me an incredibly large amount and I really got a lot from it even if the final result isn't super polished.

It was a really good chance for me to try building a large system of classes that all interact with each other and better learn to consistently name things. Since this project I've started coming up with the terms I use to refer to things by before I code.

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.