Hello, I’m Dominic, a software engineer whose main ethos is pragmatism and getting stuff done — rather than mindlessly following software principles, patterns, and “best practices.” I’m an agnostic engineer who works across any tech stack and is known for getting up to speed quickly.
I’ve worked most deeply in TypeScript (web development) and Java (backend). I’ve also explored a range of other technologies and frameworks including Python, C#, C, PowerShell, Erlang, and PHP. I enjoy taking full ownership of my work — from writing the code to deploying it. I dislike bottlenecks and inefficiencies; if I can do it myself, I’ll find a way — often improving the process as a result.
I don’t follow any one methodology religiously. I have experience with TDD, pair programming, object-oriented design, Scrum, Agile, CI/CD, and more. Each has its place and trade-offs, and I’m always open to trying new approaches.
Below is a collection of things I’ve worked on to give a clearer picture of me as a developer.
I made this website for a game that I play where tracking the quests online manually was a bit cumbersome. So I developed a website specifically to manage it myself with a nicer UI.
Developed with Nextjs due to ease of development and deployment. The main focus of this app was making a satisfying user experience. The UI itself is very simple. I only designed it track quests, so there isn't any bloat. Everything is smoothly animated, satisfying and, most importantly, mobile friendly. As the main player base for this game plays on mobile.
For added convenience, since the dailies are the same each day for each player I implemented a simple Redis cache which tracks the most selected quest each day and these most selected quests are the ones which will be selected by default. This simple and cheap feature removes the need for the user to even search a quest if only one player selects the correct daily quests.
A site I built to share thoughts on software and technology. While I could've used an off-the-shelf blog platform, I wanted full control—and it seemed like a fun project.
Since I was the only author, I didn’t need a full CMS. At the same time, I didn’t want to write everything in raw HTML.
I wanted the simplicity of markdown, with the flexibility to include custom components when needed. react-markdown
was
a good fit—it turns markdown into HTML and became the foundation for the site.
I chose Next.js
because it simplified deployment, especially with Vercel handling the infrastructure, just like my
portfolio. Initially, I served blog pages by dynamically reading markdown files, but this caused performance issues.
Switching to static generation solved it—building all pages at build time made everything faster and more reliable.
In the end, I had a manual CMS based on markdown files. Each .md
file was paired with a metadata file to support
features like tagging, hiding posts, and showing placeholder images.
I made some test articles for development, if you want to see they are:
This site went through many iterations that weren't finished due to one reason or another. V2 improved many things
by using a React SPA rather than a PHP server, making it cheaper to deploy and easier to develop. V3
introduced using .md
files to store project descriptions. There were other improvements, but those were the main ones.
This brings us to V4. The main problem I wanted to solve, starting from V1, was easier hosting. The old PHP
server required manual SSL certificate renewal, keeping the server running, and had no CI/CD pipeline. To overcome
all this, I decided to host V4 on Vercel and develop it using Next.js
, utilising React Server Components (
RSC). This came with additional benefits: better performance, lower cost (it's now serverless), and improved
search engine visibility (since SPAs aren't search engine friendly).
All my choices were made to optimize feature development and avoid the complexity of managing infrastructure. Vercel also provides a pipeline and automatically deploys my website—all without costing me a penny.
I made this site completely from scratch, only using Bootstrap. I took this opportunity to make the site in a mobile-first manner—making it completely responsive was a goal of this project.
With this project, I also put to use some lessons I learned in my prior social network project. Some key aspects I explored in this project were: use of PHP for templating repetitive page elements, using Google Fonts, using CSS animations, responsive design, and content management.
One design decision I made on this site was not to use a database, as this seemed overkill for a static website (no complex data or data relationships), at least at the scale it is now. It was much easier to manage with PHP arrays that dynamically create content—essentially a database as PHP arrays instead.
This website will continue to grow over time as more projects get developed. At the moment the layout is fairly simple, and I plan to evolve it into something more visually appealing in the future as a passion project. Some usability improvements are also planned.
This project was undertaken as part of my university placement. It involved developing a social networking site through the full software development life cycle (analysis, design, implementation, testing, and evaluation). The company was facing some internal social communication problems—no one knew what events were happening or what their co-workers were up to. Initial need-finding took place via interviews and a company-wide questionnaire, data was quantized, analyzed, and requirements were derived, among a Minimum Viable Product ( MVP) plan.
The requirements were designed and then implemented successfully, meeting the MVP. The project later went on to form part of my dissertation designing an incremental development technique for Enterprise Social Networks. The ESN was made with CakePHP, which sped up development and taught me a lot about web development, the general architecture, and approaches most common frameworks employ to streamline development.
During the testing phase, the company was unable to deploy my solution on their services in good time. Therefore, over a weekend I decided to move my solution to Amazon AWS. This was my first time deploying a web server on a Linux distribution—it involved lots of rapid learning and was a very fun experience. The knowledge I gained from this experience was invaluable, as I'm utilizing it right now to write and host this portfolio website!
The finished product was feature-complete, containing the following features:
A system developed where simple jobs could be submitted via a web interface. Simple jobs such as encryption, text analysis, and hashing were available. The results of these jobs were available to download asynchronously from the browser on completion.
The distributed system was developed entirely in Java, using a Java servlet to send/receive REST API calls. Data was stored on the backend using a Distributed Hash Table (DHT), using a robust architectural topology with nodes arranged in a ring.
This project stressed my OO design capabilities, making nodes that could function as workers, storage nodes, or both, using inheritance to achieve this feature. Along with experience of developing concurrent applications, processes, and implementing abstract algorithms into code.
Conclusion of the project involved a fault-tolerant system able to keep track of stored files, their status, manage node or operation failures, and handle collisions.
This was a group project named HEART (Historical Experiences in Augmented Reality). The application was developed in Unity (using C#) using a library called Vuforia which specializes in the development of AR applications.
HEART's goal was to digitally reconstruct old heritage sites and provide an innovative approach to delivering information about such a site. We developed a prototype, not having the technical expertise or resources to achieve the full product.
My responsibilities in this project were coding parts of the application, such as scripts to play media, progress bar & its trigger, researching voice controls, etc. I also designed an experiment to test the usability of the application following a validated scale for measuring usability, which I adapted specifically for the experiment. I gathered participants, explained the procedure and statistically analysed the results.
Meeting deadlines within this project was important, therefore I made and managed a Slack to keep track of everyone's work. I integrated this with Google Doc notifications to ensure the team was always aware of when new files were added to our shared resources. The project demonstrated the importance of keeping active communication with a team to ensure a project is on track and help team members with any bumps along the way. Along with asking for help from people on the team with more Unity experience than me, they were a valuable source of learning.
The conclusion of the project was a proof of concept AR application with voice assistant, hot spots, voice controls, audio and video logs, animated historical scenes, etc. that highlighted the future challenges such an application would face.
A Natural Language Processing project using machine learning techniques to identify the language of a particular corpus of text.
The classifier was made completely from scratch using Java, with no external machine learning libraries used. Cross-validation, frequency analysis, and variable training set size methods were used to evaluate the effectiveness of the technique implemented.
My language identification system works by using rank-order n-gram statistics to predict a language. The output of my system is a distance metric that determines how likely a piece of text is to be a particular target language. Implementation was based on a research paper.
Building this system taught me a lot about machine learning and the processes that need to be undertaken in order to process data. It gave me experience in handling high volumes of data (300k sentences) and analysing that data to form conclusions.
The conclusion of this project was an accurate classifier, maintaining 95% accuracy even for corpora only 20–40 words in size, needing 30,000–40,000 words to give stable predictions. This was all validated using 10-fold cross-validation (tested only with English, Czech, German, and Slovenian).
A distributed fault-tolerant auction system made with Java. Featured a dynamic replication server, authentication mechanism, encrypted data transmission, and a 5-step challenge-response protocol.
The project made strong use of Java RMI (Remote Method Invocation) for communication between clients and servers. There were distributed auction servers that had to keep up-to-date with the system as a whole to function correctly. JGroups was used as a group server communication protocol library to ensure atomic interactions, guarantee packet arrival, manage dead connections, etc.
The project concluded with a robust and simple distributed auction system, giving me lots of experience in the challenges associated with design, architecture, and programming distributed systems.
Micro:bit Mesh was a mesh network protocol I developed for the BBC Micro:bit. It was a feature added with the aim to teach kids about the computing concept of networking, giving them a tool to play around with.
The project involved very low-level C/C++ programming using the Micro:bit's runtime called codal. This project stressed reading and understanding how, at a low level, embedded systems hardware could be manipulated to achieve the desired effects, working a lot with the Micro:bit's radio. One of the biggest challenges I faced during this project was debugging the Micro:bits, as it's difficult to know what programming logic/state each system was in. To aid in this, I made use of the Micro:bit's LEDs and serial I/O to print debug data.
Feasibility tests, design, implementation, and evaluation of the protocol were conducted. The protocol was based on Glossy, a controlled packet flooding approach to mesh networks that came up during research.
The conclusion of this project was that this approach is possible, however it encountered strange patterns of high packet loss in correlation to distance/physical network topology and therefore requires more thorough investigation from a physics perspective.
A game developed through Java's JSFML library. This game was developed alongside some friends of mine. Art was made by a friend and the majority of the coding was done by me.
The experience taught me a lot about the importance and effectiveness of object-oriented design. Before development, I made a UML diagram to plan out the object design, with inheritance and along with how the code would flow, what particular classes and objects should generally do, how the engine would work, and any extra challenges we may face.
The parts of the game I coded were:
Working within a group also meant it was important to keep code well documented and commented. I therefore kept all code commented and up to date. I scheduled regular communication and meetings to ensure we were making steady progress, catching problems early.
The result was a game with a refined twin-stick combat system. The game does however lack content to consider it a full-fledged game, however the baseline exists for this game to be developed into something official.
A basic project that was developed for fun entirely through Java. The Snooker game was used as a way to practice object-oriented design and tackle the challenges associated with building a game (such as dealing with frames and game logic).
The conclusion of this project is a fully implemented game of Snooker, tested for following all the rules correctly.