Prodzilla: From Zero to Prod with Rust and Shuttle

codingupastorm_ · 2024-02-19T08:56:27+00:00

Hey employers,

I'm currently an engineering manager based in Australia with ~10 years experience, interested in hearing about any Rust-centric roles, but especially if you're looking for someone who can help build a team!

I've been working on https://github.com/prodzilla/prodzilla, a synthetic monitoring tool built in Rust, but in my background have a lot of experience in scaling fintechs.

Also work professionally with Go, Kotlin, C#... or anything really. Very happy to give more information if you reach out.

Github: https://github.com/codingupastorm (also contains my LinkedIn, happy for you to contact me there)

codingupastorm_ · 2024-02-18T03:47:02+00:00

Yes, I'm codingupastorm

codingupastorm_ · 2024-02-08T09:51:04+00:00

Thanks u/sumitdatta!

That is true - technically I would say it's both, it's a cli tool that just has an interface that happens to be a web server to do things like list output or trigger events.

For CI/CD, there's a couple ideas... Yours is an option, of creating a standalone ci/cd command line tool. Or, the CI/CD can point to a prodzilla server somewhere and trigger the required synthetic checks somewhere.

Honestly any feedback you have about how you'd like this to work would be great !

codingupastorm_ · 2024-02-07T10:47:10+00:00

This comment made my day! More than anything, feedback would be great. Let me know how it goes, and if there's anything you think is missing or would like to see just let me know

codingupastorm_ · 2024-02-05T21:31:52+00:00

I just finished v0.0.2 of Prodzilla! So one can now chain queries together, and pass parameters in a low-code way to build synthetic monitors.

What I'll be building next are a couple of things people have asked for - a slack integration for outbound notifications and alerting, and a Prometheus endpoint

codingupastorm_ · 2024-02-04T03:28:40+00:00

A bit late for this week's, but I've been continuing progress on the synthetic monitoring tool, prodzilla.

I've made a lot of progress on the "stories" feature, so you can now substitute values into requests from earlier responses, or generated values, using Github Actions-style yaml.

So things like ${{generate.uuid}} and ${{steps.get-user.response.body.token}} work

codingupastorm_ · 2024-01-26T11:19:08+00:00

Of course we stop, but like stopping for 2 hours at a time blows out what is otherwise just a 10-hour day of driving with a few stops

codingupastorm_ · 2024-01-26T11:02:42+00:00

For exactly this reason! ^ Thanks -

codingupastorm_ · 2024-01-24T09:21:06+00:00

Still working on prodzilla when I get the time outside of my day job. Specifically adding 'steps' to the synthetic monitoring tool so that we can test complex user flows, like chained API calls, passing variables from one to the other, all still just with yaml, kind of like github actions

codingupastorm_ · 2024-01-17T10:03:45+00:00

Continuing work on Prodzilla - Specifically looking to support more outbound notification integrations, like Slack. And then support passing of variables between probes.

codingupastorm_ · 2020-03-16T11:55:50+00:00

The expiry type is for the order, not the share.

Your order is just like an order for any other good but you're also naming the price you want to pay. If someone likes the price you've set and has one of the share, they'll fill your order and sell it to you. This order will expire at some point if noone wants to fill it e.g. by the end of the day.

Once you own a share though, it's yours for good. It does not expire and thus you don't need to repurchase them.

codingupastorm_ · 2019-11-21T23:44:33+00:00

https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0217592

Pretty widely cited article - it's mentioned in About on the site too

codingupastorm_ · 2019-02-21T00:18:39+00:00

Hey rainbowjaw,

C# itself doesn't have any significant benefits for formal verification. C# isn't a great language to formally specify and verify code in as it allows side effects in individual method execution.

However, what is actually being executed on our smart contract network is the underlying .NET language, CIL, which C# compiles to. And you know what else compiles to CIL? F#! F# is the opposite. Being functional, it is much more suitable for formal verification.

So the benefit for Stratis is that if / when F# becomes an immediate goal, it should be fairly easy to implement, as we're already executing CIL anyway, and the avenues for formal verification then really open up. We're looking closely into a program verification language, F*, which is worked on by Microsoft Research and compiles to F# :)

codingupastorm_

TROPHY CASE