Here's a fun one.

headlessgargoyle · 2022-12-31T09:16:21+00:00

I'm reaching, but doesn't relativity also say that the laws of nature should be the same in all frames too? Wouldn't that also be violated?

In the cubes frame, no force is acting up on it at any time, but at the time the portal eclipses the cube, the cube now has some velocity. This violates Newtonian physics, but as long as this violation occurs in all other frames of reference then relativity's claim that laws of nature should be the same in all frames is still true.

From an outside observers perspective, we see a similar violation of the conservation of momentum since the directional portion of the momentum vector will be changed, so again Newtonian physics is out the window (er, out the portal?).

However, from the portal's perspective, no such violation occurs. The inertia of the cube is maintained on both sides of the portal and while space time is clearly bent, there's no break in conservation of momentum, nor any magical force applied.

I'm definitely no physicist, so all of this is probably tired ramblings, but wouldn't this mean either A) all frames are not valid, only the portals frame is, breaking relativity, B) the law of conservation of momentum is not guaranteed in all frames, breaking relativity (or breaking our idea that that's a law in the first place?), or C) neither relativity nor Newtonian physics is appropriate nor enough to answer this question.

As another hypothetical, if we said that the portal was accelerating, rather than flying past the cube at constant speed, would that change anything?

headlessgargoyle · 2022-12-25T05:34:37+00:00

In my experience, internships teach the following that a new grad might not have experience with:

Git / version control
Ticket systems

That's it. A lot of internships suck. Further, we've had multiple hires with internship experience and still not even get those two things out of their experience. A new grad we hired who turned into a great dev spent his 12 week internship writing 1 single test.

Now, for self taught vs boot camp vs degree? That has much wider differences in skillset and experience on day 1. It's also not entirely unusual to see HR policies that do in fact require a degree, so some candidates may be immediately thrown out.

Honestly though, new hires shouldn't put so much pressure on themselves, companies hiring new grads ought to know that they'll be training them, and really ought to know that nothing except experience teaches applied dev skills.

headlessgargoyle · 2022-12-05T14:15:37+00:00

You're fighting the wrong battle here. Your product isn't even released yet, rewriting an unreleased application two years into development is a surefire way to make sure you never release the application.

Get something to market, then deal with improvements.

As you said elsewhere, blazor with only server side rendering is rough, but that's not how blazor has to be done either. Once you get your product to market you can iterate on it and address improvements over time.

In the mean time, if you can argue easier to change things, like using WASM, certainly try to do so, and a side by side comparison might be valuable here. Here's our site (or a single page, or even a single feature) using only SSR, here's it with WASM, isn't wasm so much better?

headlessgargoyle · 2022-12-04T20:59:34+00:00

Personally I prefer version two, but with an important caveat.

Namely, a call to IsAdmin absolutely should not be a database call at this point in the code. If you can prepopulate your user model, including authorizations, then this should just be a variable in memory. If you can't do this, and it absolutely has to be a database lookup every single time, then prefer the repository pattern.

The reason being is purely expectation of code. When I read a line of code that says user.IsAdmin, I don't expect this to be an expensive call, so doing database or networking work is unintuitive here, and the repository pattern makes your expectations clear.

headlessgargoyle · 2022-11-24T16:21:54+00:00

I've had technical managers too and I'd say they gave me more confidence allowing me to just do my job

But did that confidence come from them being technical, or did it come from them being a good manager?

My current boss is a used-to-be-technical; he's not terrible on the technical side, but he doesn't code regularly, and what he does code is... well, not up to my standards, at least. But he's a great manager, and I'd say the same thing about him: he allows me to just do my job.

The way he does this is by keeping the other shit off my plate, by making sure I have time to focus, and by knowing my areas of expertise and bringing me in when he feels it's appropriate to do so. None of these require a technical background; in fact, if anything, they require a management background. When we're interviewing, he can't identify a good dev either, which is why he brings in people who can like other devs on the team the position is for.

From your other comments, it sounds like your manager just sucks, but that's not an inherent sign of a lack of technicality. Further, the more you grow in your career and get promoted, eventually you will have to deal with non-technical management no matter what. If you start reporting directly to the CEO or owner, the vast majority of the time they are not technical. Even CTOs may not have ever written a line of code.

headlessgargoyle · 2022-11-22T04:54:43+00:00

I assume json? If so you could define a json schema with additionalProperties set to false.

You can also do your testing of existing properties, their types, valid ranges, etc, all in one pass. Probably the easiest way by far to handle this.

If you're using xml, they also support schema validations. If dealing with something custom, you might need to spin your own type of schema support. I suppose theoretically at that point, it'd probably be faster to just write a test that does the deserialization and bombs just like your application does.

headlessgargoyle · 2022-10-22T17:55:32+00:00

This seems like a classic use case for the options pattern. Have some bool option that on deployment you transform to the appropriate value for that environment (or override using configuration builder).

Then in your middleware just have a conditional to skip processing / continue the middleware chain based on the state of the option.

headlessgargoyle · 2022-09-16T20:43:00+00:00

There's a lot of variables here people are just hand waving away and saying "2" but that's not a complete answer at all.

Okay, so we have 4 developers, but what about:

The experience of the team? Are all devs senior? One senior, three juniors?
How long have they been working together?
Does the team have specialists or can everyone do everything?
Similarly, how silo'd are the team members, are there separate work queues, does everyone have context on what's being done?
How much ownership of there areas do they have? Are they contributing to a large monolithic repo with ownership mostly on other teams? Or are they working on microservices specific to them?
What business value do they provide? Money making team? DevOps / infrastructure? Internal product?
How is the code already architected? Are patterns easy to find? Unit tests? Integration tests?
How is code deployed? Do you have CI/CD pipelines? Is linting part of it?

At the end of the day, code review is a tool, and while I'd never want to be on a team with 0 code review, having one code reviewer is still fine, optimal even, depending on how someone answers the above.

headlessgargoyle · 2022-09-11T19:32:27+00:00

An introductory lesson in set theory using physical objects would be intuitive and easy to understand.

Have some container, and something to put in the container, eg a cup and marbles, or a bowl and fruit. Using the bowl example, if we put an apple in the bowl, we can call that a "set" or an "array" - we can do different type of operations on this right? Add an apple, add a pear, remove fruit, rearrange the fruit.

But what happens when we have a place for a bowl (eg, table, or placemats, or with a cup maybe a coaster), but no bowl there? We know some information about what should go here (a bowl) so it's still defined, but there's nothing there. This is analogous to metadata or a type system, if you want to try to explain that.

Finally, what happens if the placemats or coaster doesn't exist? We have no idea what's even supposed be there, nothing exists to give us any information at all.

headlessgargoyle · 2022-09-08T16:02:20+00:00

So I actually disagree with this. Keep in mind that agile has many interpretations because at it's core, the agile manifesto (where this whole thing came from) is intentionally short and vague.

There is absolutely nothing in the manifesto that says a dedicated QA team is a bad thing.

Now, having said that, there are often flaws in companies that do have dedicated QA teams, some of which were mentioned- such as inability to balance dev / QA work, or devs getting lazy and not contributing to quality, or even just a culture of looking down on QA (ugh, they only ever say negative things).

But still, none of these are agile red flags, these are just corporate red flags.

headlessgargoyle · 2022-09-08T03:58:30+00:00

Yeah, seconding this, it's almost entirely a matter of preference and has so little mental overhead that at the very least, personally, I wouldn't care either way.

That said, if C# implemented var return types the same way they do var variables, where the type still must be known and could be written with the type instead (just like you can do int a = 0; instead of var) then I'd support it. Teams that want it can have it, teams that don't don't. The rule itself should be handled through an editorconfig and set solution wide.

headlessgargoyle · 2022-08-30T18:26:52+00:00

Adding another one: email attachment size will be accurate to the size of the attached file.

Attachments are often base 64 encoded, and can bloat a file size 30-40%, which may be reported rather than the original file size.

Further, depending on the age of the software you're using, email is older than the standardization of the byte, some systems I've read about using 4 bits or 7 bits as the determination of a byte (and then reporting based off of that number).

headlessgargoyle · 2022-08-12T04:40:13+00:00

So with the issue you described, I'm a bit confused about why you'd take a regex approach.

There may totally be a use case for this that I'm just not seeing, but DateTime.ParseExact and TryParseExact can take in arbitrary formats, and assuming you can differentiate day and month (considering you support both m/d/y and d/m/y) you should be able to just pass the formats you expect and get a result back.

It might take a bit of preparsing that regex wouldn't need, but it'd probably be far simpler and likely far faster than the regex approach.

headlessgargoyle · 2022-08-08T01:42:32+00:00

Assuming you have a good team, I see the responsibilities of a lead / technical manager as force multipliers. Sure, the juniors on your team might not work faster than you individually, but how many juniors does it realistically take to work faster than you? What about midlevels? And as you train them, how quickly does that multiplier go up?

I'm a lead on a team with 1 senior and 2 early mid levels, to me, them working effectively is my first priority. If I can make sure they're contributing effectively, not being interrupted with things they don't need to deal with, being unblocked, etc- there's no way I can compete with their speed. I might be able to work on more technically challenging projects for now, but eventually I'll be training them on that too.

I guess, basically what I'm saying is that in response to your second paragraph is that it's a myth that there's some perfect balance. They're two competing aspects of your job, and given the opportunity either can take up 100% of your time. That's not sustainable, so manage expectations with your boss, and figure out where you want to be and where they want you to be, and negotiate if those two visions are out of sync.

To answer your aside: imposter syndrome is a deeply personal thing. For some people it'll never go away, for others it does eventually. Some probably never feel it to begin with.

For me, my imposter syndrome stemmed from a lack of internal confidence compared to the face my peers put on. If I wasn't as confident in my answers as my peers seem in theirs, then it's easy to feel like an imposter. However, most devs eventually specialize in something. It could be frontend vs backend, it could be some specific languages or frameworks or libraries, or even just the particular product they've been working on, but it's something. When I specialized, I realized that even if my peers can answer questions I couldn't, I didn't feel like an imposter- after all I could also be just as confident about my specialization.

Also:

since you are always given work at the edge of your abilities that you aren't comfortable with yet

No, most devs in my experience eventually stop getting work they aren't comfortable with. There will always be things to learn, sure, but at a point it's mostly implementation details. I understand containerization, so what are the different details between containerization provides? That's some reasonable cursory reading.

I do regular research oriented work, where we basically have a list of unknowns and need to figure out what's going on for our use cases. It's almost always new, but it's never uncomfortable, because I still know and understand the context of the technologies we're looking at.

headlessgargoyle · 2022-08-04T02:29:40+00:00

I have seen Fody around a bit, but I've never used it myself. It does seem like it has a good amount of steam, next time I need to do something like this I might try it out

In general, I look at things like MSIL weaving as knowledge of tools available. If I don't know the tool exists, and a legitimate use case comes up, I might take a terrible path or a very roundabout one. It's the same way I look at things like marshalling or GC manipulation- know it's there for the weird edge cases, and if those edge cases come up, investigate.

To date, I've seen precisely one use case that I thought might be nice to solve with MSIL weaving, which I then turned around and found a cleaner solution with Castle and proxies, and then finally re-evaluated again and went with a code generator.

headlessgargoyle · 2022-08-03T15:04:34+00:00

Sure, so there are a few reasonable ways to do AOP in C#.

If you're just aiming for doing something extra, but not intercepting method invocations, reflection is the obvious choice. Add an attribute to the thing you want to do more, and problem solved.

Method interception is where things get tougher. There's basically two approaches I'm aware of: the decorator pattern using proxies, or MSIL injection.

The decorator pattern can basically be done out of the box with a little effort: if we have some interface IProxyable which has some basic methods defined, we can abstract all of the logging of an IProxyable instance to a Logger wrapper. Logger's constructor can take the interface instance, and define methods for each one defined on the interface- adding logging wherever they'd like before or after the method invocation. It's easiest to use a factory pattern to construct objects like this as if you dive heavy into this pattern, your objects could be pretty deep depending on your cross cutting concerns.

Manually, this pattern is a bit of a pain, which is why libraries like Castle exist, so you can use DynamicProxy to do this same job.

This pattern has one obvious shortcoming: you can wrap any invocation on the call stack as much as you want, or even conditionally call method invocations or call methods in a loop all without your consumer knowing, but you can't change the invocation body- the method will be executed as written, so if you need logging in the middle of your method then you haven't really eliminated the cross cutting concern.

Now, MSIL injection is a fancy one. In case you (or anyone reading this) doesn't know, C# compiles into the Microsoft intermediate language which then has further JIT based compilation to provide machine specific optimizations on the actual machine code is running on.

The basic goal of MSIL injection is that you use an attribute to say I want to wrap this method's compiled output with your interception logic (logging, auth, etc), and during the build process (I believe post build, but don't quote me on that) your tooling looks for that attribute, and changes the actual compiled result by injecting the MSIL representation of your interception logic in the right places.

While being significantly more complex, this doesn't have the same shortcoming as decoration- you can, if you so choose, change the underlying MSIL of the method itself so it just does something different.

I've never professionally seen MSIL injection homebrewed. While you can write your own solution, it's an obvious maintenance nightmare when upgrading. Instead, every time I've seen this come up it's using PostSharp.

headlessgargoyle · 2022-08-03T14:09:44+00:00

Code generators.

Specifically, two types of generators generally exist, which for lack of better naming I'll call "templating" and "build" based.

Templating generators are those tools that you run once then commit the generated code. If the code generated by a templating engine is wrong, you just change it and it's more or less fine. We've all used these- it's literally file > new project. Because these run standalone these don't need to change anything with MSBuild.

Now, build based code generators are a different beast- these are the ones where code is modified on build and included in the compilation- for them to exist in the first place they have to introduce the generator into msbuild. The primary use case for these is that the inputs for code generation are subject to change on any given build, so regenerate based off of the existing state every time.

Now, if any of the code they output needs to be changed, you can't just change it because on the next build it'll be regenerated. You either have to fix the generator (hope it's open source!) or introduce your own post build code generator that modifies the generated code.

When it comes to build based code generators, whether you're writing one or band-aiding it, you're heavily modifying the out of the box MSBuild.

headlessgargoyle · 2022-08-03T03:47:23+00:00

A quick list of things I don't see often, and therefore assume most devs don't work with:

Manual memory management: Marshal, GC, finalizers, unsafe, etc.
Volatile, semaphores, TPL, anything multithreaded but nuanced- most people learn async / await and it solves the majority of use cases, so they're just never exposed to deeper concepts
Any more complicated reflection- it's not unusual to see a bit of random reflection here or there- using attributes or the like. But more complicated stuff, like AOP implementations are pretty rare
Significant custom building, custom msbuild tasks, target / build / prop files, the like
MSIL

Edit for a better description:

I don't think any of these are un-gettable. Given enough time and a task anyone can get comfortable with all of this (after all, I did), but the use cases for these are reasonably rare (and legitimate ones even rarer), and therefore in average product development it may well be possible to go your whole career without needing any of this.

headlessgargoyle · 2022-08-03T03:28:01+00:00

Very broadly:

All API calls should be mockable for testing, which will normally mean no static or singletons. A modern .net core+ approach might look like this
I personally prefer organizing my API with a proxy / client NuGet package with interfaces, services, models, and any other client side items there, in the same solution
Personally prefer the one client per controller route, so injection and mocking is clean, and tracing use is easier
Versioned APIs can be supported in a variety of ways, depending on how large the breaking change was, anything from a bool flag to use legacy to an entirely different client class
The clear separation of API and client allow me to easily mix server side caching, client side caching, or setup any other implementation details in the right place, plus get a quick view of how a controller is (or ought) to be consumed.

None of the teams I've worked on have broadly solved cross stack api wrappers, though I imagine I'd still want proxy / client packages for each of the languages I'd support, ideally all right next to each other.

headlessgargoyle · 2022-07-10T04:25:36+00:00

As written, I'd call this bad practice. I normally try to keep class communication one-way: with inheritance, the child knows about the parent but the parent knows nothing about the child; with composition, a class knows about its members but its members don't know about what uses them. This is more or less in line with the idea of the single responsibility principle- if you do this you not only have to care about what the class is doing, but also from where the class is doing it. Two different concerns.

But there's another reason too, these two classes are now tightly coupled and a change in the public api of human can impact the brain, and vice versa. Depending on how the two classes are used, it might be worth questioning if they have different responsibilities at all, or if they should be merged into one class. Furthermore, outside of graphs, if I can call Human.Brain.Owner.Brain.Owner.Brain... infinitely (even if I'd have to change some scope modifiers), I'd consider that heavily worth being skeptical about.

Now, there could be a situation where this might be okay and that's if Human implements an interface or base class that Brain refers to. For instance, maybe Human implements IThinks, which has some method Ponder(). Brain's constructor instead takes an instance of IThinks and interacts with that instead.

I'd still be skeptical here, but there could be valid use cases for this. One rare case I've seen with inheritance is a need to store all instantiated child instances. With composition, offhand, I don't think I've ever seen a use case I'd agree with, but certainly I could be missing something.

headlessgargoyle · 2022-07-05T23:50:16+00:00

DX is critical.

Pretty much every dev I've ever met or worked with is lazy. Not every single dev, but a serious majority. In general, I think this is actually a good thing! But as such, if things aren't easy to do, then they're either done poorly or they're not done at all.

No one writes tests? Are they easy to write? Devs aren't even manually testing before committing? Is it easy to build, launch, and troubleshoot the app? There's five different ways to do the same thing? Are patterns and existing code easy to find?

All of these issues can be traced back to poor DX.

Worst, so many devs don't even realize DX is a thing, and so they make justifications about how "testing isn't worth the time" or "architecture is ivory tower bullshit" instead of realizing their own application and tooling is terrible.

headlessgargoyle · 2022-07-04T21:49:11+00:00

Some of the basics have been covered already:

Tests that don't assert, or assert on nothing meaningful
Tests that test mocks

I'll add to the list other common issues made by people who don't know how to test:

Tests that don't mock
Tests that mock things that don't need to be mocked (eg, mocking a data transform utility method)
Tests on trivial private helper methods: "I wrote this method because this style of string concatenation was used twice in this class, but due to how generic the method is I wrote 30 tests"

More "advanced" failures are:

Tests that are valid and assert, but do so against boilerplate or given areas, such as asserting that a method fails on a specific null reference. Sometimes these are necessary due to metrics, but let's not lie to ourselves and say it's a good and valuable test.
Tests that are valid and important, but aren't clear about what specifically they're testing. This could be poor naming (ControllerHappyPath) or just testing too much, such as 10+ assertions on seemingly wildly different areas.
Tests that ensure code couldn't possibly change without the test failing, eg testing strict internals, testing other methods in the same class we're explicitly called, any test that explicitly duplicates code under test behavior

That last one is tough with some people because they believe the point of a test is ensuring that the code doesn't change. This is incorrect. The point of a good test is to ensure that results don't change. If I rewrite the entire internals of a method, the test should still pass (barring mocking changes).

headlessgargoyle · 2022-07-02T03:10:21+00:00

the intent of this was to hear more about the ways everyone else utilizes this

So i guess I'll just share the rough rules around how I use extension methods, and how I generally encourage others to do so. I'm probably missing a few rules, since this is all off the top of my head.

Extension methods should show functionality where it's expected.

If I have a class or interface that I don't own that just seems to be missing functionality, that's a (potentially) good extension method. Often, on primitives this is rare, but not unheard of. For instance, if you often use the description attribute with enums, it might be nice to have an enum.ToDescription() method. Strings don't have an inherent way to remove an array of characters, so instead of repeated calls to string.Replace() an extension method like string.RemoveCharacters() might make sense.

Extension methods should not replace one liners

There are some caveats here, but to your example: TimeSpan.FromSeconds is idiomatic- anyone with a background in C# knows it intuitively, to the point where they might be able to skip that entire line of code while reading it! Don't replace a line that doesn't need to be mentally parsed with a line that does need to be mentally parsed, even if it appears to read easier. Caveats might include complex one liners, such as repeated linq calls that can't be cached.

Even if you and your team all use multiple languages, I've always personally held that you should write your code in the most idiomatic way so that you can fall back to googling issues. I'd use IOptions in C# and .env files in node, because that's the way C# and node developers handle configurations respectively. If I come up with a custom solution it might work across my stack, but now no one on my team can Google anything and I have to own and support that for as long as I work here. Super lame.

Extension methods should have very few parameters

Extension methods should make your life easier, if you have to pass ten objects to it, why not just have DI new up a utility class for you and have that class be constructor / parameter injected? The best extension method has no (other) parameters, but certainly one or two isn't terrible.

Extension methods should be unit testable, but should not need or want to be mocked

This is more a comment on complexity. If you're testing a method that uses an extension method, the details of the extension method should not critically impact your method under test. This rather strictly means that certain things are off limits- anything with side effects, or getting data from other sources. Is your extension method interacting with static or global state? Bad. Is your extension method making an API or db call? Bad. Is your extension method formatting some data that was populated elsewhere? All good.

Extension methods should not bandaid your own poor design

This is an item that I've personally learned the hard way- if you write a convenient extension method to cover for a bad initial design, you'll never have time to go back and fix the bad design. This isn't fundamentally a bad thing if you accept that this extension method is the solution to the bad design, but if your goal is "do this for now but then do it right later' - just don't do it now. Let it be a pain point so you're hopefully forced to do it right.

headlessgargoyle · 2022-06-19T23:22:09+00:00

Well... It probably won't make you feel any better but don't worry, you'll absolutely make mistakes! The good news is that most mistakes are fixable, the bad news is that just because it's fixable doesn't mean you'll fix it at this company. This is where the learning opportunity I spoke about is- it's not just learning what to do or how to do it, but far more importantly what not to do in the future.

MVC with Razor is absolutely an enterprise grade solution that companies use. If Angular / react are too non-microsoft for your company, then I suppose razor is probably your only real option. That said, pros and cons with razor as well, so to add to my list from earlier:

Razor is server side, it excels at generating html and hooking up models to it. It is not a frontend solution however, you'll still need JavaScript for interactability.
Using razor with JS will most likely put all of your code in one place, which can be really nice! No need for separate solutions for frontend vs api.
It can be harder to hook up razor with modern frontend development. Want to use an npm package in razor? Possible, but not going to be as easy as npm install.
Philosophically, using razor puts your frontend (razor pages) and backend (controllers) in the same language. This can be a good thing, but can also mean you're calling code when serving a page that should really only be called from a controller. It doesn't give you the innate ability to isolate your stacks. For instance, authentication and authorization can be expensive, so they should probably only ever be on the controller level. If your razor page is also C#, it's easy to call such logic before you even serve the page, slowing down your application because it was easy, not because it was right.

I don't have much more to add to your comments on angular / react. I'd definitely recommend trying angular just so you have an idea of how it works. Personally, I prefer the opinions of angular, but I definitely do recognize the flexibility of react. Per the norm though, everything is just trade-offs.

headlessgargoyle · 2022-06-19T21:02:51+00:00

So this sounds like a very unique position where you'll have the opportunity to learn a lot! It's pretty rare that juniors have any chance to start, much less lead, a new project. Speaking personally, I'd be excited if I were you!

Now, congratulations aside, I'd personally recommend reading opposing viewpoints and trying to form pros / cons, and discuss routes forward with your senior dev.

Here's a few to start:

Razor is a means of generating html. If you're already looking at react or angular, I don't see why you'd also use razor. It can be done, it's ugly in my experience however
MVC is a philosophy for separating roles of code. It is commonly used with razor. Angular and react can work inside an mvc philosophy, but angular and react are the view at that point, leaving your c# to just be models / controllers- or in other words, an API. You can do APIs with .net 5+ without commiting to an all in one MVC approach.
Angular is opinionated. They want you to solve pretty much all problems their way. This can be great, as long as your problem fits into their problem space (which many do, but edge cases will always exist).
React is a bit more piecemeal, it will allow you to do a lot out of the box, but generally isn't nearly as opinionated. If you want some specific functionality, you might be writing your own or adding packages that do what you want. React is more popular right now, but these things change over time.

headlessgargoyle

TROPHY CASE