SLV-Rust is a high-performance networking project developed in Rust, focusing on efficient server-client communication. This project explores advanced networking concepts and aims to provide a robust and scalable foundation for distributed applications.

SLV-Rust

SLV-Rust is an experimental project exploring high-performance networking paradigms using the Rust programming language. The primary goal was to build a robust and efficient server-client communication system capable of handling concurrent connections and data transfer with minimal overhead.

The project specifically delves into asynchronous programming with Rust, leveraging its ownership model and concurrency features to ensure thread safety and optimal resource utilization. This was a deep dive into the intricacies of low-level network programming.

The core of SLV-Rust is built around an asynchronous architecture, primarily utilizing the `tokio` runtime. This allowed for non-blocking I/O operations, enabling the server to handle multiple client connections concurrently without creating a new thread for each, thus significantly improving scalability.

A custom binary protocol was designed for efficient data exchange between the server and clients. This involved careful consideration of message framing, serialization, and deserialization to minimize overhead and ensure reliable communication.

Rust's robust type system and emphasis on explicit error handling were instrumental in building a resilient networking application. The project incorporates comprehensive error management strategies to gracefully handle network failures, malformed data, and other unexpected events.

One of the main challenges was mastering Rust's asynchronous ecosystem, particularly understanding the nuances of `async/await` and the `tokio` framework. Debugging concurrent network applications also presented a unique set of difficulties, requiring careful use of logging and tracing.

This project provided invaluable experience in designing and implementing low-level networking components, understanding the trade-offs between different architectural choices, and leveraging Rust's performance characteristics for demanding applications.

This is a generic version of a food delivery app I was contracted to develop in 2019. Built on Rails, it emulates functionality from other popular food delivery apps. Utilizing a number of APIs, we were able to make this project come to fruition in a timely manner.

Food delivery app

In summer 2019, I was contracted by a startup to develop their food delivery app—a platform designed to combine the convenience of traditional food delivery with catering capabilities for offices and large groups. Built on Rails, the app emulates functionality from popular food delivery platforms while incorporating unique features for bulk ordering.

When I joined the project, a previous developer had created a basic prototype but had left before implementing core functionality. Recognizing both the strong business plan and the opportunity to work on my first production app, I took on the challenge of bringing the concept to full fruition.

Our lean team consisted of three people: the CEO, a graphic designer, and myself as the sole developer. The CEO defined must-haves versus nice-to-haves, collaborating with me to assess technical feasibility for our minimum viable product (MVP). We organized our workflow using Trello boards to track development priorities, with my time estimates for each feature guiding our planning.

The development process followed a structured approach: I focused on backend functionality while the CEO worked with the graphic designer to create layouts for frontend implementation. Weekly meetings ensured we maintained focus and could pivot as needed throughout the development cycle.

From the outset, our priority was implementing order processing and payment functionality. [Stripe's API] proved ideal for our needs—well-documented and robust enough to handle our requirements with room for growth. The payment flow implementation was surprisingly straightforward thanks to Stripe's solid engineering foundation.

A critical requirement was real-time communication between customers, admins, delivery drivers, and restaurants throughout the order lifecycle. While automated email provided necessary documentation, SMS updates through [Twilio's API] offered the reliability and immediacy we needed.

Designing SMS templates presented an interesting challenge: maximizing information within character limits while maintaining clarity. For drivers, we prioritized streamlined UX with maximally concise messages and a one-word response system for confirmations and updates to minimize delays.

During backend QA, we recognized that the existing UI felt dated. This led to a complete frontend redesign to give the app a modern edge, ensuring the user experience matched the robust functionality we'd built.

The MVP mindset served us well for rapid deployment, but it also created some blind spots in long-term planning. If I were to approach this project again, I would consider using Electron and React (or similar component-based frameworks) from the beginning, along with a mobile-first design perspective. The logical next step for this type of app would be mobile transition—significant undertaking that would have been easier with different initial architectural decisions. Having never previously architected a full-scale production app, I learned valuable lessons about planning for application evolution beyond the initial launch phase.

The most rewarding aspect was testing the complete user flow after API implementation—witnessing the seamless communication between different code systems working in tandem to create something genuinely useful. There's something deeply satisfying about that orchestration of technologies, like hearing a beautiful symphony where each component plays its part perfectly.

JJNotes is a current project in the works, addressing the need for a modern cross-platform note-taking app. It should be reliable, secure, functional, and simple.

JJNotes

One of my friends has been letting this idea percolate for a while now. Since I've had some time to spare recently, and wanting to make sure I was up-to-date on modern JS, I decided to help bring this idea to fruition.

I haven't had a chance to do much mobile-first development since attending CodeCore here in Vancouver, so I was eager to explore how the landscape has changed since then. I came up with a working prototype with Next.js and HeroUI (formerly NextUI) based on my friend's consultation. I initially constructed the app with Electron in mind for cross-platform, but soon realized that I had wrongly assumed that it covered mobile OSes as well. Currently, I am rethinking the architecture, likely starting from React Native and working on compatibility from there.

Saltybot is an experimental project, designed to collect statistics from saltybet.com. The variability in character code and random matchup selection make reliably predicting the outcome a difficult task.

Saltybot

Saltybot is an ongoing project, designed to collect statistics from [saltybet.com]. The statistics include the outcomes and variables of 1v1 CPU matches on the fighting game platform MUGEN. Each character has been uniquely programmed, with designs often pulled from various other games and uploaded to the internet over the past 25 years. With a roster estimated to be upwards of 9000 characters, and 24/7 uptime, saltybet.com provides a fun platform in which the audience can gamble using virtual currency on the outcome of a fight.

I first stumbled upon saltybet during my time at CodeCore Bootcamp in Vancouver, BC in 2017. It was a simple distraction that I would turn my attention to while waiting for bundler to fetch rubygems (particularly nokogiri at the time), or just to take a break from digesting the algorithm lesson of the day. Suffice to say, in spite of the mild enjoyment of making a wager on what was essentially a coin-toss, I didn't have the bandwidth to memorize the sheer volume of combinations of fighter attributes and statistics. The obvious solution was to create Saltybot.

The initial data collection phase was crucial. I needed to gather enough fight outcomes to start seeing patterns. Each character's performance was tracked across multiple matches, considering factors like opponent type, stage selection, and even time of day. The right-side image shows an early version of the statistics dashboard where we could monitor win rates and prediction accuracy.

The system architecture evolved as the project grew. What started as a simple data collection script became a full-fledged prediction engine with multiple components working together. The left-side diagram illustrates how data flows from the source through various processing stages to generate predictions.

Code Projects

null

<-

Code Projects

null