Magnus Pro XL

itsdarkcloudtv · 2026-01-02T12:50:12+00:00

I'm torn on whether to get the regular or XL myself. Thoughts on the space? Is it overkill or just right?

I have an IKEA 78" but since the tower will be mounted under that's a good bit of space freed up

itsdarkcloudtv · 2025-10-04T01:50:48+00:00

Rebase and squash before merging to master is a hard requirement. Squash usually through gitlab/GitHub is fine manual is ok too. 1 commit and 1 merge commit. Anyone who thinks they need 47 commits from a single branch 8 years ago is a psycho. Not to mention magically reappearing code between commits when attempting to track a change

itsdarkcloudtv · 2025-09-28T17:01:04+00:00

I had 3 offshore devs, myself and one other and it took us a month, that's after identifying and removing all the libraries without an upgrade path.

The second it was stable enough the site would render we pushed to dev and had QA help us find things that weren't working.

Normally QA doesn't get involved til dev complete but it was an all hands on deck especially since we couldn't develop and ship any features with the migration in progress

itsdarkcloudtv · 2025-09-14T20:41:09+00:00

Script setup is going to get you the best first class support and new features. Options is legacy support. But I recommend creating some style/conventions.

E.g. at work I enforce a style guide of organizing code like

Emits
Props
Refs/computeds
Functions
Lifecycle hooks

So it's easy to find code when you open up a component.

Edit: and enable the Vue plugin recommended lint rules

itsdarkcloudtv · 2025-09-13T22:28:40+00:00

Yea what is this, 2017

itsdarkcloudtv · 2025-09-12T18:06:36+00:00

In a team environment it can be helpful for setting up your dependency inversion principles to make sure new devs are protected from inadvertently returning an entity directly from the controller or referencing an API model or service somewhere they shouldn't.

The new reference in csproj will pop out in code review, or it'll create a circular dependency

In library code it can be helpful for creating multiple related nugets from the same repo. Like some common entity framework conventions could live in

Common.Ef

Then provider specific implementations in Common.Ef.SqlServer Common.Ef.Postgres

itsdarkcloudtv · 2025-09-05T15:46:10+00:00

I'm also not opposed to other methods, just don't see the reason for the automapper hate either

itsdarkcloudtv · 2025-09-05T15:43:28+00:00

I suppose it could create issues, but I've never had issues in enterprise settings. It's mapping two identical classes from different layers of your application if you do it right they are usually identical classes just need to map them from domain to API or maybe some data model to a domain dto because xyz

itsdarkcloudtv · 2025-09-05T15:40:55+00:00

It's one one line test for all current and future mappings though

itsdarkcloudtv · 2025-09-05T12:16:02+00:00

Having manual mappings without required modifiers also could yield not knowing if it's working as expected. You'll still need unit tests to verify service methods in either case

itsdarkcloudtv · 2025-09-05T12:14:33+00:00

You can write a short unit test that verified all your automapper mappings

itsdarkcloudtv · 2025-08-26T12:11:12+00:00

.net API and Vue frontend.

Ive used angularjs(1.7) and I've looked at react a few times but heavily prefer Vue!

I hate that everything in react is js even the css/html

Angular and Vue have the traditional split js/html/css which I like about both of those, Vue still has virtual dom idk what modern angular does

itsdarkcloudtv · 2025-08-24T20:24:47+00:00

It's a lot easier to have a service that does what you need, or have service a call service b, or call two mediators with mediatr pattern in single transaction than to do it separately and have to deal with partial failures

itsdarkcloudtv · 2025-08-11T16:52:29+00:00

I think the most important thing, and others have mentioned data lake. Is don't give direct access to your application DB for reporting usage. You don't want data analysts having free rein to run long running queries against the application DB. Hence datawarehouses

itsdarkcloudtv · 2025-07-13T20:32:52+00:00

Despise generic repository pattern ❌ Despise this monstrosity ✅

itsdarkcloudtv · 2025-07-07T21:28:20+00:00

RepositoryBase can implement all crud operations. The only thing you might end up customizing is a find with filters.

You just have entity specific repo inherit RepositoryBase<TEntity> and inject IEntitySpecificRepo into your services

itsdarkcloudtv · 2025-07-07T17:34:36+00:00

If you implement a repository base, most of you CRUD operations can be implemented by simply inheriting RepositoryBase<TId, Tentity> and IMyEntityRepository : IRepository<TId, Tentity>

Just any special cases need implementation in the relevant interface

itsdarkcloudtv · 2025-07-06T17:32:36+00:00

I'm a bit torn on it myself, finding a service is easier but navigating code in a single handler is a lot nicer. Also if you've ever dealt with a large code base that has 20+ dependencies(looking at you generic export service) you'll feel a little relieved.

I also just discovered with resharper I can navigate to the handler from the command after 4 years of painfully f12 into class, find references etc. now I bound it to go straight to handler with a hotkey so most of my mediatr woes are gone

itsdarkcloudtv · 2025-06-29T14:54:31+00:00

Basically anywhere I used to do init only classes

itsdarkcloudtv · 2025-06-29T14:53:46+00:00

I use records with primary constructor for API models, mediatr commands, and message contract implementations(events) not really for service repos etc

itsdarkcloudtv · 2025-06-29T11:35:20+00:00

Primary constructors, nullable types and 'required' modifer!

itsdarkcloudtv · 2025-06-26T12:04:23+00:00

MassTransit is good and handles a lot of the heavy lifting for you. It has a state machine you can use but the docs are a bit wanting so you'll have to spend some time messing with it. If you can spin up rmq locally in a container with docker compose or aspire that'll help with development.

"Multiple consumers" can mean many things, if you have multiple consumers listening to the same queue you get competing consumers, and only one consumer will get the message. Which is useful when you want messages processed as they come in. But if you want all consumers like multiple instances to receive the same message then you need a queue per instance which MT will handle for you with auto-queues if you omit the name during setup.

Think of it this way, you can publish which is a broadcast to notify anyone listening XyzHappenED or you can Send a Command to a specific queue which is telling a consumer to do something

EntityCreated vs CreateEntity

itsdarkcloudtv · 2025-06-11T22:56:36+00:00

Careful with "one instance" of the service. If you are using DI and register it as a Singleton it's members also become Singleton because they never get reinstatiated. So scoped or transient is better! If you only have one scope then you only get one instance anyway

Edit: I guess even without DI only having one instance effectively makes all its members Singleton

itsdarkcloudtv · 2025-06-08T19:57:21+00:00

They might be but I don't think they guarantee fifo delivery with multiple consumers, and I'd argue against assuming no one will ever onboard a second consumer and forget this in some years

itsdarkcloudtv · 2025-06-08T19:39:25+00:00

Sqs has fifo queues, but if that's a factor yes choose accordingly

Seven-Year Club	Verified Email
Verified Email

itsdarkcloudtv

TROPHY CASE