From 82e1d9fc0c63b2d0adc6357dce022e9047e08914 Mon Sep 17 00:00:00 2001 From: Rosia E Evans Date: Wed, 11 Oct 2023 00:19:40 +0100 Subject: [PATCH] Adds first prototype code to create navigation categories, needs majour cleanup and optimisations --- Resources/Input/Aardvark.md | 35 -------------- Resources/Input/CatTowerDefence.md | 15 ------ Resources/Input/EPQProject.md | 17 ------- Resources/Input/MindMap.md | 16 ------- Resources/Input/RoboticsSociety.md | 7 --- Resources/Input/SBSWork.md | 38 --------------- Resources/Input/SailBot.md | 14 ------ Resources/Input/ThisSite.md | 41 ---------------- Resources/Input/aberCompSoc.md | 5 -- Resources/Input/index.md | 9 +++- Resources/Input/inputfile.md | 21 --------- Resources/Output/Aardvark.html | 33 ++++++++----- Resources/Output/CatTowerDefence.html | 33 ++++++++----- Resources/Output/EPQProject.html | 33 ++++++++----- Resources/Output/MindMap.html | 33 ++++++++----- Resources/Output/SBSWork.html | 33 ++++++++----- Resources/Output/TestFullArticle.html | 33 ++++++++----- Resources/Output/Wireframe.css | 3 +- Resources/Output/index.html | 44 ++++++++++++------ Src/BlogPageBuilder.cpp | 67 +++++++++++++++++++++++---- Src/BlogPageBuilder.h | 7 +++ Src/Page.cpp | 4 -- Src/Page.h | 20 -------- 23 files changed, 237 insertions(+), 324 deletions(-) delete mode 100644 Resources/Input/Aardvark.md delete mode 100644 Resources/Input/CatTowerDefence.md delete mode 100644 Resources/Input/EPQProject.md delete mode 100644 Resources/Input/MindMap.md delete mode 100644 Resources/Input/RoboticsSociety.md delete mode 100644 Resources/Input/SBSWork.md delete mode 100644 Resources/Input/SailBot.md delete mode 100644 Resources/Input/ThisSite.md delete mode 100644 Resources/Input/aberCompSoc.md delete mode 100644 Resources/Input/inputfile.md diff --git a/Resources/Input/Aardvark.md b/Resources/Input/Aardvark.md deleted file mode 100644 index 7e4ae44..0000000 --- a/Resources/Input/Aardvark.md +++ /dev/null @@ -1,35 +0,0 @@ - -# AardvarkXR - -## What it is -Aardvark is a development framework, currently in alpha, designed to allow users to open small apps (known as gadgets) over the top of virtual reality programs or games. You could think of it as a mobile phone for use within -any vr software, its main focus is providing small utilities such as calculators or note taking apps. Developers can create apps for Aardvark using web code which it then renders over the users view, these renders can be 2D -or 3D which is a rather big positive as steamVR doesnt support 3D rendering on overlays so Aardvark has to do this itself. Due to all the code being webbased 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. - -I was first introduced to Aardvark through a hackathon the developers ran on its inital release to the public in an attempt to gain developers to create basic apps for it, and since then I have periodically revisited it -when ideas for gadgets come to mind. When taking part in the first hackathon I had little to no experience with javascript or html, let alone typescript (the main language used for Aardvark development), so I was required -to teach myself over the course of the 3 days the hackathon ran for. - - - - -## What I did -During the first hackathon I proposed and worked on an audio visualiser tool that would run in the background of the users environment as they worked, reacting to their desktop audio. I also designed and created 3D models for other -developers programs, such as icons for a playing card app; one of the first apps to be published on the platform. - -Around 4 months later I revisited Aardvark to create a photo viewing app which 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 (a decentralized storage system) and had multi-user functionality allowing different people to show each other photos. The main idea of the program was to allow vr artists to -open reference images within their prospective drawing apps. - - - - -As well as this I have also worked 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 alot 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. - - - - diff --git a/Resources/Input/CatTowerDefence.md b/Resources/Input/CatTowerDefence.md deleted file mode 100644 index 5facf50..0000000 --- a/Resources/Input/CatTowerDefence.md +++ /dev/null @@ -1,15 +0,0 @@ - -# Tower defence game - -## What it is -A tower defence game, mostly created over the course of 1-2 months to allow myself and a friend to gain a better understanding of python. Players can place cats to attack balls of wool rolling along a path. Cats can -be upgraded with different upgrade paths and can be deleted to allow for a partial refund. The tower system was designed to be easily expanded and altered along with a rudimentary map file system that allowed users to -add maps of their own design. Although a functional prototype was created, no artist was ever found to allow for a proper art pass or visual redesign so the project never left this first phase. - - - -## What I did -Almost all of the project was a team effort with I and my friend sharing ideas and working on the same code in a pair programming set-up, swapping and working off each others ideas. I proposed alot of the original logic behind the movement -systems, the level select menu and the file structure for custom maps along with alot of the smaller features such as tower placement and selection. These proposals were built off by both myself and my partner as the system -evolved in complexity and scale. - diff --git a/Resources/Input/EPQProject.md b/Resources/Input/EPQProject.md deleted file mode 100644 index f1d2e70..0000000 --- a/Resources/Input/EPQProject.md +++ /dev/null @@ -1,17 +0,0 @@ - -# EPQ Project - -## 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++. diff --git a/Resources/Input/MindMap.md b/Resources/Input/MindMap.md deleted file mode 100644 index 1ac2b4c..0000000 --- a/Resources/Input/MindMap.md +++ /dev/null @@ -1,16 +0,0 @@ - -# Mind Map Maker - -## What it is -This project was completed as a large percentage of my final A-level computer science grade. Every student had to choose a language or development framework and create a program for a client, whilst most students chose to -create video games for their siblings, I chose to create mind map software as my sister was soon to start her GCSEs and was struggling to revise. The software had to run on a £70 laptop and allow for files to be transfered between -copies of the software. I also aimed to create an intuitive and relatively unrestrictive system as my sister was an art student and had little experience with digital design software. - - - - -## What I did -I independently created this program over the course of 24 hours spread over 2 months. I chose to write the sofware in Unity as I wanted to learn a new engine and knew that unitys use of scenegraphs -would make the process of development alot faster as I wouldn't have to calculate scales and positions of mind map components as unity would do this all in the background, allowing me to focus on the larger aspects of the project.

-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, this regularly meant having to -weigh up the strengths and weaknesses of different libraries, often choosing ones with drawbacks in favour of their lower usage of memory. diff --git a/Resources/Input/RoboticsSociety.md b/Resources/Input/RoboticsSociety.md deleted file mode 100644 index a609f7d..0000000 --- a/Resources/Input/RoboticsSociety.md +++ /dev/null @@ -1,7 +0,0 @@ - -# Aber Robotics Soc -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 quatermaster 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. diff --git a/Resources/Input/SBSWork.md b/Resources/Input/SBSWork.md deleted file mode 100644 index 5ae3631..0000000 --- a/Resources/Input/SBSWork.md +++ /dev/null @@ -1,38 +0,0 @@ - -# SBS Internship - -## What it is -Inbetween my time at University and Post-16 I took a gap year where I interned at Skipton Building Society as a software tester. This was a paid 9 month internship where I waspushed for automated testing -with SmartBears TestComplete system and worked with their API team to ensure their software remained stable whilst they slowly worked through all their API's transitioning them from TIBCO to Azure. - -I was also asked to research Gherkin and Behaviour Driven Development to see if it would be worth transitioning to, helped to run a coding club to educate other members of the Society and later set-up -the Society's standards for all their future automated testing. - -## What I did -I was initially hired to experiment with the idea of automating the Society's testing using SmartBear's TestComplete system. I taught myself a large portion of the tools over the course of a week -and then worked with one other collegue who came from a testing background to fully automate the UI testing of the Ds customer portal system. -From this we decided the tool may be worth using across the wider Society and worked with individual agile scrum teams to help them automate their testing. During this time I produced a presentation -on the inner workings of TestComplete and its benefits to the Society's senior developers convincing them of its worth. I also worked with my collegue to produce an educational talk, some tools and documentation -in order to educate other testers on the system and encourage widespread use. - -After 3 months of working on TestComplete I was assigned to an Agile Hub in order to help them with their testing on the side whilst still working on TestComplete. This team was built to slowly -transition all of the societies APIs from TIBCO to Azure and my job was to ensure any software interacting with the API currently being replaced would still work when the team had finished. This was -done through large amounts of manual regression tests and a few automated tests where their work overlapped with my other TestComplete work. This was somewhat challenging for me to begin with as I had -little understanding of alot of the software I was testing and I found myself somewhat anxious when communicating with the team, however I slowly improved at this over time and ended up working with relative -efficiency. I did this through pushing myself to ask people questions and eventually reorganising my time by meeting with all the teams developers at the very start of an API development cycle to have a full -conversation with all of them on what needed to be tested and how rather than individually asking developers and having to compile the individual comments of each developer. - -On the side of this I also ran a talk to teach testers the basics of javascript to increase the flexibility of their automated tests and later helped some lead developers to run a bi-weekly "Coding Club" to -educate testers on programming with C#. One of these lead developers also tasked me with researching into the testing language "Gherkin" and the concept of Behaviour Driven Development, I spent 2 months -experimenting with it on the side whilst doing my regular work and produced a presentation to them and a group of senior testers where I then facilitated more conversation on the viability of the system its -usefulness to the Society. I then organised regular meetings to continue the discussion. - -## Skills Learnt -Throughout this internship I feel that my social skills developed greatly, I got alot better at giving critisism, being willing to ask questions and admit I didnt understand things and developed my self-confidence. -I also learnt a large amount about Microsoft's Azure Cloud Systems and manual and automated testing. I also gained real experience of an Agile working environment which I greatly enjoyed and I 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 intend to work for them over summers and during my industry year at -University as I found it an incredibly friendly and safe feeling place with a really healthy culture. Their attitude towards change was very exciting to work in and multiple times I found I would make a mistake -and be worried my teams would be annoyed or upset only to find they wouldnt even consider it an issue and with zero negative responses they would just ask how they could help to fix it and help me plan a solution. - diff --git a/Resources/Input/SailBot.md b/Resources/Input/SailBot.md deleted file mode 100644 index 5472188..0000000 --- a/Resources/Input/SailBot.md +++ /dev/null @@ -1,14 +0,0 @@ - -# aberSailBot -SailBot is a university society I joined in my first year. They build and race robot sailboats. I joined the society as it seemed like a really interesting challenge building robots that have to deal with the insane variety of variables the outside world offers. Especially in the ocean where you rely on those to move. - -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: -- Coat the hull in resin -- Build a sail -- Design and 3d print parts -- Write ESP32 code to run it using a digital compass and gps -- Design a mechanism for its steering - -We were building these along with other teams, the idea being at the end of the building period they would be tested and raced in a small still water pool near the local docks. By the end of the year only our team and one other had finished our boats so we tested them in a less competetive manner at the docks. Our boat failed to find a gps connection and was unable to said but the developer from the other team lent us his software which allowed remote control over wifi and that was used instead. - -![Image of both teams on the day](BoatingTeams.jpg) diff --git a/Resources/Input/ThisSite.md b/Resources/Input/ThisSite.md deleted file mode 100644 index 970dbec..0000000 --- a/Resources/Input/ThisSite.md +++ /dev/null @@ -1,41 +0,0 @@ - -# This Site - -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](https://www.lighttpd.net/) 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. Everytime the server turns on it pulls from a repo, builds the code and runs it, this then builds the website and puts them in a folder for lighttpd to host. - -## The Thoughts Behind This - -During my first year at university I read a lot around the concept of [Permacomputing](http://permacomputing.net/). This is a set of ideas around reusing old computers and writing small systems that avoid [code rot](https://en.wikipedia.org/wiki/Software_rot) and use 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 low-risk jobs and can be used in an eco-friendly way when worked with 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 but also as a nice homage to it. - -## The Code -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 but found lighttpd, a relatively old and incredibly light weight server program, as I was researching good libraries and it seemed much more efficient than any of the libraries I could find were benchmarked for so I decided to use that. - -I initially planned to write a markdown parser and spent a day or two working on one, writing a [SAX-Style](https://en.wikipedia.org/wiki/Simple_API_for_XML) parser. 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 soon found however that it 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. It's benchmarks showed 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. - -After discovering this I implemented it 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 `
` body and placed the generated html within it and a similar thing for the `