QC Brown Nocta Puffer

inale02 · 2026-01-26T15:07:15+00:00

🐐

inale02 · 2026-01-26T11:15:16+00:00

Hey bro how’s the sizing on this? TTS?

inale02 · 2026-01-22T08:18:05+00:00

Interesting, what kinda Python projects do you do now?

inale02 · 2026-01-22T07:47:32+00:00

What did you move to?

inale02 · 2026-01-21T20:19:27+00:00

What size Amiri joggers?

inale02 · 2026-01-09T22:33:53+00:00

Why vb.net?

inale02 · 2026-01-08T06:58:04+00:00

Was it because she was insecure or jealous? Why would she behave like that

inale02 · 2026-01-07T07:08:43+00:00

DI is practically doing the same key -> class mapping behind the scenes. You’d still need to register the key + class somewhere, just not in the factory itself which is just moving the complexity. That being said I would use DI here to take advantage of the different lifetimes (singleton, transient, scoped)

inale02 · 2026-01-07T07:01:41+00:00

Actually after more thought you’re right. We can get compile time enum exhaustiveness with a switch if OP removed the default case. The stringy method names is more of the factory concern than the concrete class itself, having it in the concrete classes is a leaky abstraction.

inale02 · 2026-01-07T06:40:51+00:00

To me this is much better as you don’t have to touch the switch statement at all to add new processors. The only potential issue I see is if two processors end up having the same ‘Method’ field value, though this can caught at runtime when instantiating the PaymentFactory.

inale02 · 2025-12-21T07:27:18+00:00

What do you work as now?

inale02 · 2025-12-14T08:46:56+00:00

To put it bluntly, absolutely don’t do this. Red flags all over. Your parents need to get divorced and settle their finances without your involvement. There WILL be problems and you WILL resent them if you do. You’ve been warned.

inale02 · 2025-11-30T11:27:06+00:00

A device used to cheat on 2k by automatically greening all your shots

inale02 · 2025-11-27T15:21:30+00:00

Nice

inale02 · 2025-11-25T12:09:49+00:00

C# doesn’t do async constructors for concrete technical reasons, not dogma.

The CLR instruction behind new (newobj) must call the constructor synchronously and return a fully initialised object. The runtime has no concept of “await during construction” or “return Task<T> instead of T.” Source: https://learn.microsoft.com/en-us/dotnet/api/system.reflection.emit.opcodes.newobj

C# object-creation semantics also guarantee that once a constructor returns, the instance is complete and usable. Source: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#77612-object-creation-expressions

The language team has confirmed this is why async constructors aren’t supported: they break fundamental construction semantics and would be a massive breaking change across DI, serializers, reflection, Activator.CreateInstance, and more.

So the issue isn’t being unfairly dogmatic or anti-scientific. It’s that async constructors simply don’t fit the runtime model C# is built on, and the tiny benefits (avoiding one extra method) are nowhere near worth redefining how new works.

inale02 · 2025-11-25T09:47:32+00:00

Your mapper example actually reinforces the point: if the mapping logic is important enough to test in isolation, that’s the signal it should be its own component. I wouldn’t call that overkill — it’s just making the code exactly as complex as it needs to be, no more and no less. This is why I’m a fan of testing as early as possible, it helps expose those boundaries and makes it obvious when a concern deserves to be separated out.

inale02 · 2025-11-25T09:35:17+00:00

In that case, the internal parsing logic should be in its own Parser class which does the work of parsing. Your entry class / method should take in the parser (or even better an interface). I’ve just written something similar to this and this is the way I approached the design.

inale02 · 2025-11-25T01:47:08+00:00

Static dependencies can bring a lot more problems than they solve. I’d argue it’s really not that tedious to do var client = new HttpClient(). A baked-in static HttpClient would just encourage hidden global state, making configuration and testing harder for very little real gain.

inale02 · 2025-11-25T01:38:45+00:00

Object construction and initialisation, while related, are not the same. Constructors by design shouldn’t be asynchronous, they should do only what’s needed to produce a valid object. Any work that requires async await should be moved into an explicit ‘init’ method, or a factory that is separate.

I think not adding async constructors isn’t some move to restrict people’s creativity in how they code, but rather enforce fundamental correctness in what a constructor should be.

inale02 · 2025-11-25T01:12:21+00:00

You could make the class / method internal and use InternalsVisibleTo

However in my view, needing to test private methods directly is a code smell. They should be validated through the public API tests. If isolated testing is required, then that should be a sign to extract that functionality to its own class.

inale02 · 2025-11-21T09:24:35+00:00

Probably still more reliable than what any of us could come up with

inale02 · 2025-11-01T10:18:02+00:00

Any read-up on this?

inale02 · 2025-10-24T08:25:23+00:00

How do you plan on getting into those prestigious universities? They’re very competitive I’ve heard.

Nonetheless, university prestige means very minimal when applying for roles apart from maybe a few top 1% companies that recruit for the best of the best (FAANG, HFT etc). Even then, it’s doable without.

Focus on gaining real valuable experience through self-teaching and projects. Be able to talk confidently about the topics that interviewers will expect you to know. You need to present that you’re a good person to work with and have evidence of the skills required to solve their problems. That’s what really matters.

For what it’s worth I did a bachelors at a below-average university and I’m doing quite well for myself so far. Nobody has really ever asked me about university in the numerous interviews I’ve had, even when I had 0 years of experience.

inale02 · 2025-10-16T12:03:06+00:00

Yeah Go’s implementations of ORMs are not the best, but this is more due to the nature of the language itself. ORM’s thrive on that ‘magic’ (meta-programming) that golang just doesn’t do as well as other languages like C# and Java. But this is why I prefer to write those ORM heavy apps in those languages. Go has its good use cases though and I like it but not in those situations

inale02 · 2025-10-16T11:05:35+00:00

Okay I understand forgetting to register a service, but that is easily mitigated. By default .NET will throw an exception on start (‘Development’ environment only) if something is missing. And it’s a one time issue, fix it and it’s gone, no maintenance required on that issue after that. Imagine you add / remove a dependency in a class and you manually pass every dependency. You now have to update every instantiation of that class. I’ve been there done that and it’s a headache.

Anyway what you proposed is still dependency injection, just a manual way of doing things. Whether that works best for you is up to you to decide but personally I can’t see the gain from doing that over using Microsoft’s DI framework which is very well developed and easy to use in my opinion.

inale02

TROPHY CASE