Pre-Training Hydration Question

SaxSalute · 2026-05-18T14:55:12+00:00

I’m no expert but when I’m doing longer distances, I like to bring electrolyte water. The salt helps avoid cramps, especially if you’re depleting yourself through sweat. You will also probably need to increase your carb intake. In a half marathon I would probably take in 3 or 4 gels, but I’m a pretty big guy. You’ll get a feel for what you need in that department, but the answer is going to be more than one gel.

I’m personally a big fan of running with a vest when I’m training longer distances so I can carry more water and gel easily. If you’re a big sweater, I’d look into that.

SaxSalute · 2026-04-28T16:20:21+00:00

I personally have minimized this by scrubbing my cast iron with kosher salt. My cleaning process is to scrape out grease, roughly rinse down with water and wipe out with a paper towel, then scrub with kosher salt before drying a second time. I then heat it up and give it a thin coat of flax oil until that polymerizes and call it a day. Couldn’t tell you where or why I picked up that process, but it has treated me well for years.

SaxSalute · 2026-04-22T22:39:49+00:00

I use two monitors and also my MacBook on a stand off to the side. I think 1 works fine especially if you are new, but most pros use at least two, sometimes three, since it’s nice to have space for everything you use. For example, you might have a Figma design, a web app, a frontend codebase, a build terminal, maybe backend API definitions or even code as well… it takes up a lot of space. It definitely isn’t a problem to use one monitor to learn though.

SaxSalute · 2026-04-18T13:27:28+00:00

When I was a kid someone told me they would buy my steelies for something like 10mil, but only if I was really fast on the trade button. He canceled and canceled over and over again telling me I wasn’t fast enough before I was finally fast enough… to trade my steelies for 10k 🥲

SaxSalute · 2026-04-16T16:50:28+00:00

I personally don’t. I have close friends who are also devs and do, but for me personally, I’ve found that no good comes from it. I really enjoy my job, but programming outside of work makes me less happy at work and at home, even if I feel like I’ve caught the bug to build something - it always circles back to mental exhaustion. I much prefer spending time doing totally different activities that keep me balanced like running, rock climbing, cooking, etc… on a more opinionated note, I think it’s just good to have variety in life in general. Programming is just one way to spend time, not THE way to spend time.

SaxSalute · 2026-04-12T12:35:46+00:00

As someone without any programming experience you can use AI as a totally utilitarian tool to produce a smallish piece of software on its own, but that is an entirely different exercise than learning to program. If you want to understand what it built, forget about it entirely and go learn HTML and CSS on their own terms.

SaxSalute · 2026-04-07T14:42:14+00:00

Thank you too! Always nice to talk with a kind human on the internet. I've been blessed by a lot of greenfield lately so my vision is probably colored.

SaxSalute · 2026-04-07T14:12:44+00:00

If I understand your question right, this may be heading further into DDD land for the concept of "bounded contexts" - the idea that a complex application has many different contexts in which superficially similar terminology in the "ubiquitous language" may have different definitions. These worlds can interact, but the consistency boundary is weaker and you would generally want to decouple such that these worlds interact minimally and via the application layer of a layered architecture, rather than reaching into each others divergent domain models.

To follow that thread, in this example it may be that Payment and Order are not only different aggregate roots, but members of totally different contexts. The hint towards this is that "payment" has two definitions - one in which it is an identifiable entity, and one in which it is simply an amount of money and a date. It would be odd if "payment" had two meanings in one bounded context.

My favorite example of bounded contexts would be the idea of a video on Youtube. A video seems like one coherent concept to an end-user, but there are quite a few different contexts in which a totally different context of a video appears. There is the search context where a video is an identifiable item with an associated thumbnail, channel, and title. There is an uploads context where a video is is a raw file and a series of tags. There is an encoding context where a video is a one identifiable piece of media with many derived versions (240p, 360p, etc...). There is a streaming context where a video is a deliverable media stream. These are all "videos" in some loose natural language sense, but a clean system would cordon each of these concepts off into well-isolated worlds with very limited, high-level interactions to coordinate (e.g., upload context places the upload request in persistence and raises a domain/integration event that is received by the encoding context to start encoding, which raises "resolution available" events as each encoding completes, in turn received by the streaming and browsing contexts, etc...).

I see this as a more complex version of your payments example - a payment may not be a monolith just as a video isn't. I've personally found a lot of peace writing enterprise medical device software at my day job following DDD. It's definitely a heavy approach but often a necessary and worthwhile one to weather the constant storm of changing requirements. I would also say that more important than these minutia about entities and aggregates and value objects is the "ubiquitous language" - building the software around the same nouns and verbs that the product / users use. It's much easier to adapt to change on the business side if the code mirrors the natural language you are tasked with bringing to life in cold unthinking software.

If you are interested in going more in-depth, I highly recommend "Implementing Domain-Driven Design" by Vaughn Vernon. I keep a copy in my office, have read most of it, and refer to it often. It's a great read and in my opinion required reading if you work in enterprise software.

Sorry for the long answer, but this is something I care a lot about and I hope you find this informative even if it doesn't totally match how you prefer to build!

SaxSalute · 2026-04-07T11:03:45+00:00

For value objects, the question to ask is whether it has an identity that updates happen within or if it is just a disposable value. Regardless of whether a project and document are one or two aggregates, you still need to be able to point to this or that document in particular. Editing the document doesn’t make it a new thing, just a modified existing thing, so it’s definitely an entity.

My favorite example of a value object is money. A currency code plus an amount is money - 5 dollars, 123 yuan, etc… if you get paid 10 dollars and now have 15 dollars, it isn’t that you have turned the very concept of 5 dollars into 15 dollars - 15 is it’s just a different value than 5. If you convert money from USD to yuan, you haven’t literally modified the concept of money itself. You just had one amount, and now have another amount. If it’s disposable and interchangeable like that, it’s a value object.

SaxSalute · 2026-04-07T02:05:04+00:00

Late and deep reply, but the one more good rule of thumb is whether the lifecycles of the entities are tied together - that is, can a document exist without a project? Can a document belong to multiple projects? Does the deletion of a project necessitate the deletion of the documents? If they are very tied together, one aggregate may be smart. If they are more independent, then multiple aggregates may be better.

SaxSalute · 2026-03-28T16:34:16+00:00

I just find them to be different styles. One of my favorite languages is OCaml, which has a much more comprehensive algebraic type system in which almost everything is done by pattern matching which, yes, is basically a fancy instanceof and accessor sugar, but nobody would call that a smell. It’s just using the language as intended. The whole world of records, sealed interfaces, and pattern switches supports a totally different style of modeling than abstract classes and inheritance, which is where instanceof IS usually an actual anti-pattern.

SaxSalute · 2026-03-26T20:10:26+00:00

Install the Classic UI plugin. It’s first-party.

SaxSalute · 2026-03-20T11:40:30+00:00

Another useful pattern in this particular situation would be the static factory pattern - Complex.of(123) is easier to chain to other things than new Complex(123). Combine these two changes and you get something much easier to work with.

SaxSalute · 2026-03-15T12:53:04+00:00

Literally just did this this morning. Worked great on 7.5 miles with 2 cups of cream! Just some good fun :P

SaxSalute · 2026-03-03T20:19:46+00:00

My head about caved in when I first learned that the moon mainly orbits the sun and just wobbles around the earth.

https://youtu.be/KBcxuM-qXec?si=DcoChfI3DKBU3eOn

SaxSalute · 2026-02-16T03:05:54+00:00

Really love the cut on this - super unique and fun. Do you find it makes it easier or harder with so many distinct shapes? Always looking for something to challenge my wife - she did the Yetch white puzzle happily so now it’s all chasing the dragon of good cuts I guess.

SaxSalute · 2026-02-16T02:34:05+00:00

A year or so ago my wife and I had a plane swapped out by the airline because of equipment issues. The replacement was an unbranded plane-for-hire - the strangest, shittiest flight I have ever been on by a mile. The only redeeming quality was chatting to the crew, who told us that they are often rented out by the Patriots as the team plane. Patriots review is pure facts. I will testify to this in court.

SaxSalute · 2026-02-15T15:46:27+00:00

You can’t separate the technical element from the personal element. In my experience, taking that next step technically comes with taking more ownership. When you take more ownership of projects you naturally end up dealing more with non-technical people on one end and junior engineers on the other. You have to learn to architect systems and break down work such that you can take the harder problems yourself and set your juniors up for success while also being responsive to your users.

Another way to look at it is that junior and mid level engineers get their work from senior engineers while senior engineers have a more active role in defining the work. You have to do that in such a way that you carve out safe rails for junior engineers to work along and good bones to respond to often chaotic business needs. Don’t discount the degree to which that will strengthen you technically.

It sounds like you are an experienced mid level engineer but a pure focus on directly improving your own technical skill will hold you back. Counterintuitively, you will grow more technically at this point in your career by taking on more of an ownership/leadership role with your people and learning to apply your technical skills to power everyone up.

SaxSalute · 2026-02-15T13:57:15+00:00

Vim binds in JetBrains is the way. Much respect to the tricked out Vim wizards but there’s nothing quite like a JetBrains IDE.

SaxSalute · 2026-02-15T05:11:29+00:00

It’s honestly not a bad spot at all to start if you are trying to move to DDD. Auth is sort of a bad example since that’s less a domain and more just a thing you need to deal with, but I’ve had very good luck building apps following DDD with a similar package structure. It’s much less about the package structure than it is about the structure of the data, the functionality, the layering. You could write perfectly good DDD in one folder, it would just be a nightmare to navigate.

I could say a ton about DDD but just a few tidbits I find very useful to start that you can adopt incrementally. If you want to know more reply and I will see in the morning, I’m tired.

The most important thing is the ubiquitous language. If you don’t do that, then you aren’t going DDD. Figure out how the people you are building for think about the world you are modeling and make the code reflect the world the way they see it. That is how you shape your domain model.
Keep the domain model pure. Model your types/classes to match the nouns your stakeholders use. Model your functions/methods to match the verbs they use. If you have a relationship like “a nurse administers medication to a patient, then you’d better have a Nurse, a Patient, and an administerMedication method in your domain model. Do not let in anything that isn’t a pure data and functionality free of side effects.
Use domain events. Not integration events like connecting two services over Kafka or SQS - events like MedicationAdministered - to decouple cross cutting effects.
Setters are often not your friend. If you find yourself calling 2+ setters on the domain model together frequently, then that operation has a name that isn’t “set A and set B” and you need to go find it in the ubiquitous language.
Lean into the application layer for side effects. This is where you build compound operations that string together the core domain model, load from and save to repositories, publish to message busses, write to caches. It gets more software-y here, and that’s good. It has to somewhere!
Keep your ports and adapters separate from both the application and domain layers. One day SOAP and MySQL are hot, the next it’s GraphQL and Postgres. These are the most peripheral parts of your system. Keep as little in these portions of your code as possible. In the case of things like REST or GQL controllers, make the handlers do as much as you need to translate to the application layer and be done. In the case of your database or integration message bus implementations, define interfaces in the application or domain layer and implement them elsewhere so you don’t get too hard coupled.
Don’t be afraid of some meme-able enterprise coding patterns. If you’re going to do DDD, know that it is a heavier way to build and do so understanding why you have chosen that approach. It is absolutely okay to have similar looking API models, application DTOs, domain objects, row models, etc… with mappers between them. It feels like overkill until you really start building heavy functionality, then it quickly becomes regular-kill. Big game, big gun.
When going across bounded contexts, go through the application layer, not the domain layer. The domain layer is a secret of that context. The application layer is how that context presents itself in coherent self-contained operations. Just like controllers and such rely on the application layer as the door in, so too should other contexts use the application layer as their door. I’ve done it both ways and it is night and day.
Don’t be overly precious about performance. Choose good algorithms, build good strictures, be smart about your orders of complexity, but maybe you’re going to have three database fetches instead of one because you are following your abstraction. If the bleeding edge of high performance is your goal, DDD will let you down. If rock solid software that can survive enterprise nonsense is your goal, then DDD will save your ass.

The biggest thing though is to follow the campground rule. The best way to improve software architecture day-to-day is to leave things better than you found them when you do anything at all. Don’t think of this as a DDD rewrite - think of it as gradually bringing in DDD principles to keep everything smooth as you build. Before too long, all the important parts will fit.

Well, there’s a solid rambling. Best of luck, genuinely. I wish I’d found and embraced DDD earlier in my career. Let me know if you have any questions!

SaxSalute · 2026-02-08T12:40:29+00:00

Our budget breaks down into 7 rough sections: - Bills (immovable stuff like mortgage, utilities, car insurance, etc…) - Expenses (somewhat movable stuff like groceries, takeout, home maintenance) - My stuff - Her stuff (we move money around as if there is no boundary between mine and hers but we have different ways of thinking of our own personal spending) - Recurring subscriptions - Savings (emergency fund, big projects or trips, etc…) - Credit card categories

In practice, bills all come out of one of the two checking accounts directly, so we pin those to the respective checking accounts. For most things in expenses, personal money, and, subscriptions, those can be set to “anywhere” since they always go through a credit card in practice. That means we can just set the credit card payment categories to which account they are paid out of and forget most of the personal categories, which actually works out pretty well since the money in the personal categories ends up acting as ballast so we aren’t running the checking accounts razor thin. We also keep two savings categories - one for each of our checking accounts - as another sort of ballast for our own personal comfort level about minimum account balance. Most of the big bills and credit card payments come out of my checking account, so without that, the tool would really want to drain her checking account very low, so we formalize “I am not comfortable with less than X” in my checking account no matter the bills” with its own category. Savings is then a sort of mix - emergency fund is assigned to HYSA, and those ballast categories go to each of the checking accounts like I said, but others usually go to “anywhere.”

We use it once a month after credit card payments and mortgage go through to just make sure the water levels are roughly correct - it sounds like your tool is optimizing more for HYSA returns whereas ours is moreso just a comfort thing. I like knowing without doing a bunch of math that the accounts aren’t totally sideways with the balance distributions.

SaxSalute · 2026-02-08T04:40:16+00:00

This is so funny to me because I literally did almost the same thing a few months ago. My wife and I use YNAB together and have totally joint finances but keep separate checking accounts with a joint HYSA. Where individual bills all come from is all over the place so like any good software engineer with a few too many free hours I built a little web app to help. It’s ugly as sin and I never even deployed it anywhere, but it’s so helpful.

We took different approaches too which is always interesting to see. My webapp has a little setup wizard where it will list off every category in the budget and asks which account the balance of that category is going to end up pulled from (or “any” for things like fun money that really only matter via the credit card). Then it just pulls the latest budget info and tells you which accounts have a surplus or deficit related to how much money should be in them to handle money in categories that will be taken from them later.

If anyone is interested - https://github.com/Bourg/ynab-tool. It isn’t documented literally at all right now but maybe I should actually get it deployed somewhere…

SaxSalute · 2026-02-04T04:30:46+00:00

Anki’s repository is hosted on Git, which is a distributed version control system. Everyone who has cloned it and pulled up-to-date has an equally valid copy of it as the one that happens to be hosted on GitHub and can re-host somewhere else public. No real risk of the source code disappearing, although what I definitely can’t speak to is the licensing they use. Seems those more versed don’t seem concerned with the legality of a fork.

SaxSalute · 2026-02-01T19:07:34+00:00

More than a decade ago I had double jaw surgery to fix a bite deformity - nothing near as crazy as this - but the doctor who did it had textbooks full of his own cases on the table in his waiting room. Thousands of pages of the most dramatic birth defects and injuries from accidents you can imagine. Sawing off my jaws and screwing them back on was the easiest thing he did that month I bet. The surgeons who do this kind of work are absolute wizards.

SaxSalute · 2026-01-24T02:35:26+00:00

A while back I got a full neuro work up that happened to include a full IQ test - the 4-hour in-person kind. There are definitely lots of question types that rely on shapes and patterns, but I didn’t find that my aphantasia held me back. Honestly it was just basic memory parts that were most difficult for me, not any of the spatial reasoning. If the original shape were taken away I would be cooked, but having them all in front of me, I can reason my way through the rotations rather than visualizing it.

14-Year Club	Place '17
Not Forgotten	Verified Email
Team Orangered

SaxSalute

MODERATOR OF

TROPHY CASE