These last few months started strong but ended up slowing down code-wise. I renamed dStore to svarm and got lots done with it. When I last left it, I was working on the data replication logic. I have a plan in place, but I got distracted. A friend and I decided to start a different project. I won’t go into too much detail on it since it is not an open-source project, but I will say it was a serverless application written in rust to be launched on the AWS platform.
That project started strong, and we had lambdas behind API Gateway endpoints talking to DynamoDB, with plans for SNS/SQL and other features in the future. We developed the project locally and tested it with localstack. Localstack integration was kinda buggy at first but once we got into it, it worked pretty well though could be slow on new deploys.
We were making progress then I made the mistake to try to ‘enterprise’ it. I tried to get IoC for code-injection, mocks for tests and injecting common used ‘libraries’ into the various lambdas. It worked until I took a step too far. I wanted to mock out a common component I was using to fake IAM controls that was also injected. (Localstack charges for IAM and we weren’t ready to go down that path yet.) I got the strangest bug. I had assumed I did something wrong, because rust, but after some research found out this was due to a year-old bug in the rust compiler. And it has the craziest workaround that I still do not understand what it’s doing. You can read about the bug here
Because we are using AWS rust libraries, everything you write is
marked async because everything AWS has is async. (Forget that
lambdas are not multi-threaded. It has to do with you being able to
use their code in anything you do, lambda or otherwise). So you have
to add crates to help with the async work to make your life easier.
You have to define your traits as async which requires the async-trait
crate and whatnot. But these magic little packages are adding features
via macros that are difficult to parse for a novice rust programmer. I
tried to understand what was going on in the macros of the shaku or
mockall crates and it still warps my brain.
So, I have my code with async all set. I’ve got traits so I can do IoC via shaku and mocks as well and everything works. When I tried to inject an instance into a lambda that already had classes injected, I ended up with this bug. The work around suggested didn’t work because of the IoC I’m using doesn’t implement the async trait the way it does in the work around. And I don’t understand it enough to apply the ‘learnings’ to the code myself. So, I basically said forget it. Time to rip out the IoC, mocks and all and do this as plain as possible.
In a normal work environment I would have spent the day or two doing just that… refactoring out all the magic I spent weeks adding to the codebase. But given there is no money in this project yet, and I’m getting a bit tired of reading all the wacky macro implementation people are writing in rust so I understand what they are doing, I needed a break. So I put this project on the back burner and wanted to start a game again.
If you look at my github repo, you’ll see a rust game call star_field. No, its not really started. I wanted to learn the bevy game engine in rust. I started to play with the code to put something together. But it made me miss writing games in Java. So I started a private repo to work on the game instead… leaving the rust one just in case it gets interesting again later.
So that’s where I’m at. Still have my day job and working on games at night. Sometimes writing them, sometimes playing them. (And yes, still playing WoW… though not like I used to.) It’d be nice to have an initial release of my game by October. Android deployment, with non-obtrusive ads that you can remove for a buck or two. Standard issue. Trying to add some juice to it and make it fun. I give it a 75% of success. For me that’s good. Reason for that high probability? Graphics for this game are easy. I don’t have to draw much.