I worked at a company that had to deal with EY as a part of a tech certification. Tha auditors barely knew why they were being sent over. Out managers and techs had to explain the process to them and assure them the numbers in the report were correct. The auditors happily accepted that, and then charged around 100k. Top job.
I recently got into c# and it seems really nice, but the "customs and traditions" of the dotNet world horrify me (eg: never write a function when you can write three classes instead)
You can actually write an entire, complex C# application without using a single class via top-level statements. Named tuples make it easy to wire together functions without invoking the full OO type system.
Which customs and traditions? I work for nearly two decades in the .NET space and it seems I missed that indoctrination. What I see is a developer population moving through time, adapting the technology trends as they come and go and taking the best for the current projects. And so did also the language and platform itself. When I started I needed a Visual Studio on Windows, 3 xml files and at least 10 code classes to startup a simple app. Today, I (can) code/deploy on Linux, use Visual Studio Code (or any editor), my project has two files, zero classes and looks more like nodejs than anything else.
IMHO, there is a huge misconception regards C# regards their OOP enforcement. Most classes you ever write for business logic in C# are nothing more than namespaces/grouping containers. And that is for good. There are so little business logic object hierarchies (aka the Pattern world or OOP fantasy world). The other reason to write classes are object to transfer data (no logic). There are the sinful years of DTOs (which are an OOP abomination) but that is obsolete for some years already in favor of records.
C# is a follower of DDD, mostly. Which is a 'standard' practice for OOP design. I highly recommend reading the book about it, but that is how you end up with many classes instead of a simple function. Also, in C#, you can't generally mock a function (or static method?, not 100% sure on that, it's been nearly 10 years since I've written a unit test in C#).
With `dynamic` and `DynamicObject`/`ExpandoObject` proxies (or even lower level System.Dynamic/System.Linq.Expression fun) you can mock anything you want to in C#.
Those tools go all the way back to the early days of Linq (and useful but somewhat broken DLR visions like IronPython). If you need to time travel even further back in the .NET stack, or if you are just allergic to/deathly afraid of the DLR as some people seem to be, System.Reflection.Emit has been there since day 1. It's awful to work with and even worse low-level experience than the DLR, but it is capable of a lot of things. If you've got an up-to-date compiler you can go the other direction and use the recent Source Generators to do all the same low-level things but this time in the context of Roslyn and at build/compile-time.
Obviously, that doesn't necessarily make it a good idea that just because you can do such things that you should do such things, but C# has far more powerful raw tools at its disposal than many people realize.
A lot of the boilerplate in DDD styles is simply a preference for it and (over-)design patterns as comfort food.
It's a further aside, but hand-written "Fakes" patterns require more up-front work but often seem to me much better than automated Mocks. I've never seen a good DDD pattern focus on good "Fakes", though, and sometimes I find DDD complexity gets in the way of good "Fakes".
I'm on of those people that had no idea about all this extra functionality- thanks for opening that door. Do you have any resources on the hand writting "Fakes" patterns?
I don't have any resources directly off-hand, but the basic concept is implementing "shareable across multiple tests" versions of your dependencies that implement things relatively similar to the end product but in a way that uses fewer resources during testing and is hopefully more reproducible/unlikely to encounter transient environment bugs. (Though still overall more "fake" than "real", otherwise you are just building artisanal integration test harnesses.) Things like using in-memory or SQLite data stores instead of your production database type. Ideas like true secondary, simplified implementations of your abstractions. (There's no reason to have an interface that is only ever implemented by one class, so at least this is one reason to have a second implementation that fakes doing something useful.) In some ways I feel "the fakes pattern" really just means "the old way of writing tests before auto-mocking frameworks became popular", but testing patterns love to have names that change every couple of years.
There are obviously good reasons auto-mocking frameworks became popular as it can be too easy to fall into performance traps or to try to maintain two separate dependency stacks (and get dangerously close to all of your units tests as just baroquely complex integration tests), one of which may easily get out of date/diverge and is extremely fragile, especially if you don't have good abstractions up front. It's too easy for how easy you can build your "fake" data sources to accidentally create a lower common denominator of what you can safely test, either limiting the types of queries that you feel like you can add to production code (forcing you to avoid things that your production DB supports, but an SQLite or In Memory storage can't easily fake) or create growing missing coverage boundaries between "testable" and "production" code.
On the flip side though, the benefits of hand-written fakes should be that you better prove out your abstractions and how they are factored (if it is too hard to manually fake a dependency, then maybe that becomes a sign that the dependency needs to be refactored and/or a better abstraction found for it), and the tests overall more resemble your production code and how it operates in the wild. (Versus how I feel excessively mocked code starts to resemble "stage plays" that don't necessarily approach or model real world usage and behavior and it often remains too easy to "stage play" even when your abstractions are wrong/not helping you enough.)
The scenario I was referring to is one of many gems found in app we outsourced.
The piece of code in question had a very straightforward task: look at some bytes in the input and produce a string label to be stored alongside the whole input value. There are 5 different labels tied to equal number of fixed byte sequences.
I would like to think that most people would solve this problem using an if/else or a switch statement inside a function. Instead, what we got is a group of matcher classes, a mapping of matchers to enum values representing the labels, another mapping of enum values to actual strings, and a class that actually calls those matchers and does the mapping.
I really hope this is not the DDD way and instead we just managed to find a team that's prone to massively overcomplicate solutions to simple problems.
My unsolicited, socially unacceptable pet theory on this: that’s what happens when you’re building your 15th e-commerce web store. C# is a great language, but it’s a worker’s language. Its domains tend to not be the most exciting ones (e-commerce, calcified Excel replacements, Windows desktop applications, …). [1]
Hence, so my theory goes, the smart but bored engineering minds wander out and conjure up complications to fill their days and minds. A common pattern in IT I’d say.
Yes, this is generally true, so the workaround is to put your function in a class, and use an interface + dependency injection to mock what you need. Sometimes it's a hassle.
And to follow it up, read the actual book by Eric Evans. He tells you when, and just as importantly, when NOT to use the things in the book. I have to point that part out whenever I see people replacing CRUD with DDD.
I gave a UX person a snippet of debugging code to paste into the console, but didn't notice that the chat app ate the quotes around a string. GPT was able to fix the snippet for him. SO far this is the only case where someone I know managed to use it for something useful in practice.
I asked it to write a trivial c#/dotnet example of two actors where one sends a ping message and the other responds with pong. It couldn't get the setup stage right, called several methods that don't exist, and and had a cyclic dependency between actors that would probably take some work to resolve.
Event after several iterations of giving it error messages and writing explanations of what's not working, it didn't even get past the first issue. Sometimes it would agree that it needs to fix something, but would then print back code with exactly the same problem.
Does a device even know that it's connected to a ded cable? I'd imagine that it's only after you plug in the second device that they both suddenly see they're being connected to something.
I believe that some cables (especially conversion cables) can have some sort of processor. I have no idea if that's the case with USB-C cables, though.
Isn't XD pretty much dead? The last release that wasn't just bugfixes happened a year ago, while before that they were pushing out something new every month or two.
Figma has amazing collaboration features but working on larger projects on figma is terrible. It gets very glitchy and doesn't match the responsiveness of XD in my limited experience.
Domestic or international? I flew with United transatlantic around 10 times and after hearing nothing but bad things about them online for years, I was quite pleasantly surprised by how much better they were compared to companies like Lufthansa, for example. But maybe it's just me... I also loved Air France, another massively hated airline.
A good mix of both, my flight history is on FlightRadar[1]. Most of my spend is on International, most of my flights are domestic.
I don't hate United, they're actually my airline of choice and I've held their 1K status since 2018. Based out of SFO and a frequent flyer its really the best choice as they hold close to 50% of the flights out of SFO. Maintaining 1K is totally worth it as anytime I call in I get a representative within 30 seconds, and in case of irrops I'm basically guaranteed a seat on the next flight.
My to biggest complaints are cleanliness and the service on board. I'd say neither of these are BAD, but there are other, better airlines.
Cleanliness: If I had to estimate, I can note cleanliness issues on a third of my flights on United. The worst is looking in the seat pockets or looking at the air vents above the windows (don't look there on any airline its usually disgustingly full of dust).
Service: As for service on board, the flight attendants are a little more rough, less attentive than other airlines on the same route. A common route for me is SFO-NRT and ANA flight attendants are checking in every 5 minutes during dinner service, where as United FA often disappear. The ANA food is of quality I would pay for not even on a plane. On United, I often get offered "chicken or fish", no paper menu, no table cloth, even in business. I think some of this is United being slow to bring back a higher quality of service post-pandemic, whereas ANA never dropped their quality of service.
United Polaris hard product is good but the service is a joke. I have honestly had better service in economy on some (Asian) airlines. ANA business class is exceptional in comparison. I would never choose to fly United on that route. My last flight I was greeted with “Did I take your order yet? [They forgot… on a 1/4 full business class.] Ok, what do you want? … It’s chicken or fish. [No menus unlike nearly every airline in the world.] Great.” and that was 1 of 3 times a flight attendant talked to me on a 12 hour flight. Bizarre.
Surely you are joking. Lufthansa used to be bad ~15 years ago, but International United is on a whole different level.
I used to fly regularly from OZ to the US and often had to take United as they used to often be the cheapest by quite a margin. They had the oldest and most uncomfortable cabins on those routes. The cabin crew is absolutely atrocious, everytime they come through the cabin shouting "elbows and knees" (why is that so common on US Airlines? Never heard it anywhere else) and still manage to bump into everything. I have had coffee spilled on me at least 4 times and not once did I get an apology (and no I didn't have my elbow out). If you ask for something you often get rudely told off..
The food is absolutely the worst I ever ate on a plane and it goes on.
