jonc211

joined 2 years ago
[–] jonc211 3 points 1 week ago* (last edited 1 week ago) (1 children)

Ship gets lighter as more fuel is destroyed. Ship gets heavier as it gets closer to light speed.

At 90% of light speed, the ship’s mass would be around 2.3x its rest mass.

I haven’t looked at your calculations in detail, but you seem to be missing that important point!

[–] jonc211 23 points 1 week ago (6 children)

Guessing they’re talking about Power-On Self Test rather than the HTTP verb. I’m assuming you were thinking of the latter given you mentioned a software engineer.

[–] jonc211 3 points 1 month ago* (last edited 1 month ago) (1 children)

Yeah, it’s pretty crazy

They made a TV mini-series about it a few years ago. It’s called The Gold. If you’re in the UK, it’s on BBC iPlayer. If not, then there may be other means of acquiring it!

[–] jonc211 12 points 1 month ago (4 children)

Though someone did steal 3,000 kg of gold one time.

https://en.wikipedia.org/wiki/Brink's-Mat_robbery

[–] jonc211 9 points 1 month ago (2 children)

If they just have the guests stay in even numbered rooms, then they’ll always have an infinite number of rooms free.

[–] jonc211 2 points 2 months ago

He was trying to play Forky-Spoony

[–] jonc211 20 points 3 months ago (10 children)

Seeing the Guatemalan cow of paradise is a big deal for cow spotters

[–] jonc211 5 points 3 months ago (1 children)

As already mentioned, the blue book by Evic Evans is a good reference, but it's a ittle dry. Vaughn Vernon has a book, "Implementing Domain-Driven Design" that is a little easier to get into.

Personally, I found that I only really grokked it when I worked on a project that used event-sourcing a few years back. When you don't have the crutch of just doing CRUD with a relational database, you're forced to think about business workflows - and that's really the key to properly understanding Domain-Driven Design.

[–] jonc211 60 points 3 months ago (9 children)

I’ve always understood DRY to be about not duplicating concepts rather than not duplicating code.

In the example here, you have separate concepts that happen to use very similar code right now. It’s not repeating yourself as the concepts are not the same. The real key is understanding that, which to be fair, is mentioned in the article.

IMO, this is where techniques like Domain-Driven Design really shine as they put the business concepts at the forefront of things.

[–] jonc211 25 points 4 months ago (2 children)

Fringe disagrees

[–] jonc211 2 points 4 months ago* (last edited 4 months ago)

If you’re up for reading a book, I can recommend “Healing the Shame That Binds You” to get more insight into this sort of stuff

 

I've just set up arcosphere balancing in my K2SE playthrough.

My set up is relatively simple, though it uses a lot of combinators! I'm taking the inputs for a recipe as signal I and the products as signal P. If I > P then I request the inputs for that particular recipe.

I then added a slight tweak to multiply the products by 1.1, so the inputs need to exceed products by 10% before the request comes through.

Initially, it never reached equilibrium and the gravimetrics facilities would keep churning away. With the extra 10% buffer, it settles down a lot more easily and kicks in only when things start to become more unbalanced.

I've been producing naquium tesseracts and DSS3 data cards for a while now and it seems to be hanging together.

I had a hiccup early on when I ended up really unbalanced due to the length of time bots were in the air with arcospheres leading to the balancing running amok. My fix for now has been to move DSS3 and tesseracts close to the balancing area, but not sure this is going to be sustainable. Let's see!

view more: next ›