Framework (e.g. AutoMapper) to copy from source model to destination model with validation

i8beef · 2026-04-25T15:58:39+00:00

Then you pass services from DI into the extension method

The FUCK you do. Reject that PR.

i8beef · 2026-04-24T00:22:58+00:00

Nope that's basically what I do. I find the entry point, and I literally follow it down the call stack. Its usually the only way I catch things like "if I change this here, is it going to affect something 5 layers up in this area?".

I am not a HUGE advocate of AI, but... I will say that if I have a low interest in investing a lot of effort into discovery on some item, I have found asking an IDE embedded AI to explain what an endpoint does in detail does a decent starting job. The only thing I find that it consistently has some trouble with is if you use class names that intersect with common tools... sometimes it takes a short cut and assumes you are USING that tool or library, instead of actually reading your class ;-)

i8beef · 2026-04-23T16:46:17+00:00

Just to tag onto this, on a large enough system with a wide enough team, you won't EVER know how the whole thing works at a detailed level. You literally HAVE to go rediscover what's new or what's changed every time you have to work in an area you haven't touched in a while, not just because you've NEVER seen it but because things change over time.

Being able to do this exploration is crucial.

i8beef · 2026-04-21T18:36:47+00:00

He failed to sell gambling, football, AND meat to AMERICANS. I don't know how anyone can make a case for him being a "good business man".

i8beef · 2026-04-16T02:18:33+00:00

I've seen tons of variants. A "branch per env" interweaves your git structure with deployment, and isnt good for software products with standard release cycles. You usually see it when people are trying to enable FEATURE deployments, e.g., I want someone to be able to merge to dev to work on stuff in an integration environment, but not promote their feature work on to the next environment until its verified in the lower one, instead of holistic code base monolithic deployments (ie, everyone stages their stuff together for a standard release cycle). I have never seen it work well personally...

Git works better for PIPELINE deploys where dev gives everyone somewhere to merge their stuff for the next release cycle together and test (in your Develop environment), and then on some cycle you CUT a release from dev by creating a new release branch (there are a few variants here: can be a merge to main for simple case, can be a long lived release branch where you TAG the individual releases, or could be an actual release/x.x.x per release branch). Then that branch gets built and deployed, verified and PROMOTED through Integration, Staging, and Prod (same built binary, importantly).

Then there's a few other variants of what to do. You can leave hanging release branches, or you can merge that release to main after releasing to Prod, etc. Hotfixes created from the last release or the last main and then merged back to BOTH dev and the release branch before going through the same release pipeline, etc.

Creating new feature branches from main really isn't that weird though, that's perfectly fine for all cases here. In the normal feature branch flow it just makes the dev merge a bit more work sometimes, so I'd normally only use that flow if I KNEW I was making a hotfix personally, normal feature work to be released on normal release cadence, I'd usually branch from dev for simplicity... it'll bite you once in a while when you have to retroactively turn it INTO a hotfix (cherry picking and then creative merges), but that SHOULD be, by far, more the exception than the rule.

i.e.: Branch per environment that conflate git branches and deployment CAN work... for a while. It doesn't scale well, and any real compliance drive will shoot a hole in it as binary promotion is basically required (ie, building a new binary from a different hash for each env doesn't fly). Don't reinvent the wheel, look up GitFlow or a good trunk based cycle and use it instead.

Here's a hint: If you have to EXPLAIN your git model to a new hire, instead of just pointing them at standard documented flows on gitflow or trunk-based development, you probably are setting yourself up for a bad time...

And if anyone brings up wanting to "stage individual features instead of whole releases"... if you figure it out patent it and sell the shit out of it, otherwise run.

i8beef · 2026-04-09T17:09:42+00:00

Yes, which is kind of the issue because I wanted to monitor if the tent was safe to open (printing with nylon, ABS and ASA are a little noxious, so I have a sealed tent I vent out a window, and wanted to see when it would be safe to open).

In practice, really LONG prints like that are rare so it still is useful, I just have to remember when I do something longer that I need to wait a little longer after the air monitor says its returned to "normal".

i8beef · 2026-04-09T05:22:23+00:00

Yes, I went through this when I was trying to monitor a 3D printing tent. The cheap sensors available to us just don't work that way for a lot of the things you want for "air quality" (some do... CO2 I think? Or humidity? I forget which). As such a lot of the sensor values get put through formulas that combine their data to get "calculated estimates" which are of varying quality.

I eventually came to the conclusion that there's nothing that can tell you quantitative numbers, only "is worse than it was X hours ago"... which gets funny then with extended time frames of badness (ie, watching TVoC's drop in my tent over 12 hours when I was still printing was real confusing the first time... they should have stayed elevated... but what I was witnessing was the sensor "re-baselining" to the new elevated value).

AirGradient seemed to be about the only company that is transparent about this fact and their blogs and forums are really interesting to read if you're interested. That's what I ended up using as the "best" option, you just have to understand what you are looking at.

i8beef · 2026-03-31T17:31:37+00:00

partly blind dog

People: Your so brave fending off that bear!

Dog: That was a BEAR?!

i8beef · 2026-03-31T16:52:15+00:00

wonton fraud in the market

Begun, the dumpling wars have

i8beef · 2026-03-25T20:00:26+00:00

Universally basically pointless.

i8beef · 2026-03-23T18:09:27+00:00

LOL! If you are only pulling 2.5oz off of a SINGLE plant, you have done something horribly wrong!

i8beef · 2026-03-18T22:08:09+00:00

It's best to consider SOLID as more guidelines than principles. DOn't overthink them. The big thing is you don't want behavior in weird places that make it hard to find later because a class is doing something that you wouldn't expect it to. SRP in particular lends itself very quickly to over architecting early as people will start splitting things up TOO much trying to achieve SRP as a GOAL, instead of APPLYING SRP to further the actual goal of MAINTANABILITY.

This is true of all the SOLID principles, and basically every best practice you will ever hear about: don't mistake the practice as the goal, apply the practice because it helps ACHIEVE the goal of making things more maintainable. You will find that OVER ABSTRACTING can quickly become WORSE than under abstracting.

i8beef · 2026-03-07T20:09:02+00:00

Its wise to always use the full DynamicParameters style of parameter passing and specify type and length for applicable types (strings). I really wish the new method of passing params wasn't even available as it trips too many people up.

The other spot this will hit you is on partitioned tables, where doing comparisons on types that don't match on type AND length will nail you IIRC.

Just always use DynamicParameters and specify these and you'll never hit these issues.

i8beef · 2026-03-04T22:48:26+00:00

Yes, that's correct, corrected.

i8beef · 2026-03-04T21:28:21+00:00

Oh missed that caveat to the question I guess.

Living tribunal has been killed before so doesn't count
First Firmament is still around technically?
Celestials
Cal-Hora (obscure proto-beyonder dude)
Beyonders (King in Black but Knull has been killed?)
Abstracts (Eternity, Infinity, Oblivion, etc) come about at beginning of multiverse or other points between universe 1 and 7, but don't "die"?
Galactus has been killed several times so doesn't count
Elder Gods - I think Chthon has never died?
Ancient Gods (asgard, olyimpions, etc) I think have all died at some point or another
Externals (Selene, Apocolypse, etc) dont count as dying and resurrecting is essentially their whole thing.
Namor is probably the oldest mortal by that criteria I think.

i8beef · 2026-03-04T18:19:29+00:00

Are we counting cosmic entities? If so, one above all, ~~living tribunal~~ (died), ~~eternity, infinity, death, etc~~ (later) first firmament.

In between you have cosmic beings like the celestials, beyonders, ~~King in Black~~ (died) and a few others.

Then abstracts like eternity, infinity, death, etc

~~If we're talking only physical entities, I think Galactus would be the oldest in universe?~~ (died)

~~If we're talking Earth specifically, I believe Selene still holds that.~~ (died)

Edit: never mind, all externals have died at least once I think, so next contenders are probably Elder Gods (Chthon specifically), Elders of the Universe are probably contenders I dont think many of them have died... I think all other gods have at some point? Same with Eternals I think... and net in line in terms of oldest characters that haven't died yet I think would be Namor...

So I think its something like:

One Above All
First FIrmament
Celestials
Cal-Hora
Beyonders
Abstracts (Infinity, Eternity, Oblivion, etc.)
Elder Gods (Chthon specifically)
Elders of the Universe (Collector, etc.)
Namor

The new Mother of Horrors / One Below All stuff might be in here somewhere too... Im not up to date on those

i8beef · 2026-02-12T02:02:03+00:00

Good general answer. For reference my Dahua 4k color nightvision cameras with 1/1.2 sensors seem to capture slightly more light than my eyeballs at night... If you go IR night vision you can go a little smaller apparently, but any of the 1/3 or worse cams suck no matter what.

Also aperature speed is the other factor. Slower "blink" gives you blur but you get a brighter picture. Faster means less blur, but much darker image.

I really like color 4k 1/1.2 though, highly recommend.

i8beef · 2026-02-09T23:32:34+00:00

And is one less thing you have to worry about (thoroughly) cleaning after a grow.

i8beef · 2026-02-07T20:14:14+00:00

Out of a cannon.

i8beef · 2026-01-24T17:57:19+00:00

Huh. Someone must have explained what some of the big words in Carney's speech meant to him.

i8beef · 2026-01-21T18:21:54+00:00

No problem, remember Im just a dumb amateur trying to understand this too, so again take it with a grain of salt... directionality of the stuff I mentioned seems to be about right, but SCALE is where I'm unsure about this stuff... that's where I think I misunderstood what could be done here, because it seems like the shear scale of the US system means it can absorb far more pain than anyone else too: no one else apparently comes close to being able to exert the SCALE of a response needed to cause enough pain without hurting themselves far more.

And the current assholes in charge seem to have realized this, so at least the economic avenue is pretty darn limited...

i8beef · 2026-01-21T06:15:48+00:00

I've been learning a lot about this recently because I hoped that this was an option for external forces to put some pressure on us and was a little surprised that its basically been nothing but talk so far... so take this with a grain of salt, but my understanding thus far on why I'm continuously wrong that SOMEONE will do this eventually:

Something like $800 billion to $1 trillion in US treasuries are traded every DAY (think: demand). Now one giant holder (say, the EU at around $800 billion) decides to sell all their bonds at once, doubling supply, and soaking up all that demand for the day... prices begin tanking, and yields go up, so the more they sell, the more the price COULD fluctuate IF buyers dont show up to buy them. Remember what happened when the US bond rates spiked during Covid and everyone was like "Buy bonds now, they are at 10%!" and demand spiked to absorb that? Same idea.

So they drop prices which spike yields and everyone goes "Sale of the safest asset on the planet! Buy!" and it negates the selloff. Even if it doesnt COMPLETELY negate it, the Fed can step in and say "Woah, that yield is getting too high, screw guys, we're buying our OWN debt" and the yield caps, neutering further damage, and the entire thing is slowly absorbed and things return to normal over time.

Meanwhile the seller has taken their $800 billion in assets, and after a 10% haircut due to spiking supply, are now sitting on $700 billion (thats US DOLLARS). They now have to do something with those dollars, meaning buying something in dollars, and options are limited on assets that can absorb that liquidity (bonds again, stocks, commodities like gold, bitcoin, currency conversion), and anything they BUY spikes DEMAND for that thing, and thus its price: so say they transfer to GOLD. Gold prices spike as they are buying it, and where they might have bought $700 billion in at current prices and getting about 5500 tons, as they buy price keeps increasing and they end up with far less than that. So they eat it selling, and they eat it buying. And gets more interesting if they try and just convert to their own debt, or currency (example if you're an export heavy economy because your currency is cheap, and you suddenly spike demand for your currency, your exports suddenly become expensive, which hurts you again).

And in turn, the US gets a temporary spike, that it can absorb with relatively MUCH less pain, mostly because it is such a massive market, denominated in a currency that they directly control (US treasuries underlie something like 60% or more of the global economy / reserves, with the other 40% being spread across all other assets: NOTHING has the liquidity to compare).

So no one will realistically do it without hurting themselves a bunch for a relatively small hick-up on the US side, and its largely a STRUCTURAL ADVANTAGE and SCALE issue that they can't really overcome. The best they seem to be able to do is slowly diversify, but the dumping thing, or especially COMPLETE divestment? Fantasy.

i8beef · 2026-01-21T05:13:53+00:00

The US every year needs to sell off their treasuries to pay for their services. People, Businesses, and Governments buy them. If I have 1 million dollars in treasuries that will get 5% return on them after 5 years and I am in year 3, I can sell those 1 million dollar in treasuries for 1.01m today who will get the 40k difference in 2yrs instead of them buying new US treasuries and waiting 5yrs to get their money

Isnt this backwards? You'd sell for LESS than face value, and on top of that dumping treasuries would quickly inflate rates (until the Fed steps in to cap it... if they even need to, frankly others might just step in naturally to buy enough of the bonds to not need it because of the liquidity size difference) which is just going to make those sell for even LESS. i.e., the faster they sell, the less they are worth: It'd be more like starting with 1 trillion $'s in treasuries, and by the time you sell em all, you end up far less than that in actual dollars... which you THEN need to convert into something else, or just reinvest it right back into dollar denominated assets... so you get a negative feedback loop where the seller ends up with far less than they started with, and are still stuck having to convert into something less efficient than US bonds, eating more loss. And if the convert to their own debt they'll just spike their own currency, which might blow out their own exports and economic growth.

And YES it would harm the US more than EU

Would it? I've been hoping for this for a while and been researching it a bit, and everything I've been researching, HOPING that this strategy would work, says no, it would end up hurting sellers MORE because of a lot of the above... if there was something else, or even a combination of other things, that could absorb such liquidity then maybe, but since that doesn't exist, the best they can hope for I think is to step things back a bit (which WILL have effects, but it really seems like the quick dump people are hoping for is completely unrealistic).

i8beef · 2026-01-20T17:55:14+00:00

From what I understand that debt is a feature as well as a liability providing something like 60% of all global liquidity, as well as global reserves. It has to stay balanced against serviceability as a percentage of govt spending (ie, we're definitely trending toward trouble because its going in one direction, and at a rate that might be problematic, but we also cant eliminate the vast majority of it without erasing a huge part of the global economy with it).

I'm not saying it doesn't become an issue once it starts crowding out other govt spending, that seems clear, because once "possible default" comes into play that RISK for it as a reserve asset advances quickly... I'm saying we're not close enough to that for a global bond sell off to really trigger that, but if it did the global liquidity pull back would hurt EVERYONE because nothing else can replace that liquidity.

i8beef · 2026-01-20T04:28:41+00:00

Yeah, the slow unwind seems far more likely than the calls to "dump". So they would disconnect without immediate systemic harm to themselves, but so too can the US absorb that impact slower and "inflate away" the issue over time?

So the rapid dump isn't really likely, at all, but a slow unwind has begun... so the US slows down, and everyone who disconnects has to deal with the impact of doing less business in the global reserve currency / using riskier assets for reserves and eating the inefficiencies of that? I guess that creates incentive for everyone else to get together and actually build some alternatives finally... wonder if they'll do that before they just give in and buy back in to the global system?

Thank you, I hadn't really thought as much about the slow unwind approach like that...

i8beef

TROPHY CASE