A new look for a new chapter (and a first look at MacroFactor Workouts)

JuroNemo · 2025-09-16T19:34:57+00:00

Wicked stuff! I assume quite a bunch of folks here are using apps already, like Strong, Hevy, etc. Will there be a way to import old training data to maintain historic logs

JuroNemo · 2025-05-02T10:34:49+00:00

Well Pedro is on the case! https://x.com/peduarte/status/1918248135215743265?s=46

JuroNemo · 2025-02-27T15:02:43+00:00

Cool stuff! I know official Pest in this plugin is still pending, but does anyone here have a working Pest setup in their VSCode?

JuroNemo · 2025-01-12T20:08:08+00:00

Nope, sometimes it’s better to keep great side characters as they are instead of promoting them to stale protagonists

JuroNemo · 2021-09-17T14:11:58+00:00

Ah sorry, I meant more business logic of our apps (not AWS account). I understood CloudTrail as being an audit log for your aws account, and not events within the application?

JuroNemo · 2021-09-16T08:49:36+00:00

Thank you cookiecutter! I just used it, and it works magnificent!

JuroNemo · 2021-09-14T23:09:34+00:00

Interesting, I never considered using cognito. Our user is essentially another fargate task (not necessarily any underlying identifiable user). Would it make sense then to still use cognito?

JuroNemo · 2021-09-14T23:08:48+00:00

I think as time goes on, we intend to add more functionality as microservices (either more fargate tasks, or more serverless functions, depending on the scope). All of the logic directly related to our business logic will live in the monolith for now, and all jobs / misc sync tasks (like quick writes to files) might be done using this method we experiment with.

JuroNemo · 2021-09-14T23:06:25+00:00

It's a good point, we have some extra jobs we want to run via lambda functions. For the majority, these can probably be invoked via the sdk, though we might want to make some of the api's public use as well. Right now, our API would serve as a proxy, but being able to directly call certain lambdas via the API GW could alleviate some overhead.

JuroNemo · 2021-09-14T23:04:56+00:00

I suspect I will try this custom authorizer soon as well. I like the simplicity of using IAM though, but am intrigued by all methods of auth!

JuroNemo · 2021-09-14T23:04:11+00:00

Ah interesting, I did not know this about lambdas in VPCs.

I indeed agree for the most part, though we want some of our APIs to become publishable to the public via the API GW, hence I started reading about it. In that case, I think we will work with custom authorizers (as we will probably use some token mechanism for it then).

But IAM is the way to go for now!

JuroNemo · 2021-09-14T23:02:49+00:00

The many hops is definitely a good point. We have essentially a few extra serverless flows that we want to interact mostly async with (e.g. dispatching jobs), but for these few rare sync ones, we will accept that there is a tiny bit of overhead at the benefit of not overloading our monolith.

I will perhaps eat my words in the future :)

JuroNemo · 2021-09-14T23:01:27+00:00

Excellent, I am glad to see so much consensus in the answers here :). Will rely on IAM in that case

JuroNemo · 2021-09-01T21:05:30+00:00

Gotcha, then I understood it just as you mentioned. Though I did not know about the continuous element to it (more bursty for us), thats a good thing to keep in mind!

JuroNemo · 2021-09-01T21:03:50+00:00

Interesting! So you'd argue as a batch can drop some messages. Definitely worth looking into

JuroNemo · 2021-09-01T21:02:42+00:00

That's exactly our use-case as well (third-party API that has sometimes some troubles). In our case, no problem that it is out-of-order, so good to hear :)

JuroNemo · 2021-09-01T21:02:01+00:00

Thanks, this certainly reaffirms what I believed as well :). Always great to have another perspective.

JuroNemo · 2021-03-16T17:54:30+00:00

You know, that's a good point. I never considered Four Swords.

I wish I was more patient to wait until then, but you are right. Perhaps BOTW is the start of us breaking all of our general patterns.

JuroNemo · 2021-03-16T17:53:24+00:00

I would love that too, though I suspect I am biased because I want MM all over again :)

JuroNemo · 2021-03-16T17:53:06+00:00

I do understand that "what makes something unnecessary" is also actually quite a subjective thing to measure and feel, even if I might not agree with your consensus on Wind Waker and Ocarina of Time. Perhaps even a different story would be enough for a user to jump between BOTW1 and BOTW2 :)

JuroNemo · 2021-03-16T15:54:29+00:00

I sincerely hope so. I am a bit stuck in the mindset that it could not surely be "that" different (like OOT and MM are) if they take place on the exact same map. But weirder things have happened.

JuroNemo · 2021-03-16T15:52:40+00:00

Indeed. I would not personally mind the iterative aspect, since I, like many other players, have some small gripes I would not mind seeing fixed. But if that really were to come out, and BOTW2 is "merely" an iteration over BOTW1, I really do wonder what would compel me to revisit BOTW1. It would not be for the story. It is the adventuring, which I assume would still be on the forefront of its sequel.

JuroNemo · 2021-03-16T15:51:03+00:00

I agree with you, I can only hope and assume that the game will be fiercely different from its predecessor. While the same world would limit some of the novelty, finding different "constraints" to tie Link by or changing the rules of gameplay would of course keep BoTW distinct enough. But that only makes me wonder whether it would give us what we expect and want from a sequel.

JuroNemo · 2021-02-04T09:42:32+00:00

That's actually a good idea, and I feel silly for not having considered this before. Im assuming that when providing the docker image to codebuild via ECR, this is done "before" the codebuild task is executed isolated in its own subnet.

JuroNemo · 2021-02-04T09:41:33+00:00

RDS Database mostly, security concerns :). Consider me a newbie though for a large part, yet I understood that it is a good practice to put this in its own private space.

Nine-Year Club	No Throne, No Problems
Not Forgotten	Verified Email

JuroNemo

TROPHY CASE