motorest

Is there more information on this somewhere.

Yes, everywhere. You just need to look for it. See the following link, which has references to Apollo and MAWS.

https://blog.pragmaticengineer.com/amazon-notable-systems/

I thought this sounded crazy, and it would be interesting if Amazon themselves didn’t even have what was being asked of us.

Amazon has multiple incantations of this. As legend would have it, AWS was an offshoot of Amazon's internal cloud infrastructure designed to monetize it to amortize their investment on bare metal infrastructure. They partitioned their networks for security reasons and for a few years their infrastructure evolved independently. Then AWS was a huge success and took a life of its own. Only relatively recently did Amazon started to push to drop their internal infrastructure to put all their eggs on AWS in general but serverless solutions in particular.

The original 2003 DDD book is very 2003 in that it is mired in object orientation to the point of frequently referencing object databases¹ as a state-of-the-art storage layer.

Irrelevant, as a) that's just your own personal and very subjective opinion, b) DDD is extensively documented as the one true way to write "good code", which means that by posting your comment you are unwittingly proving the point.

However, the underlying ideas are not strongly married to object orientation and they fit quite nicely in a functional paradigm.

"Underlying ideas" means cherry-picking opinions that suit your fancy while ignoring those that don't.

The criticism on anemic domain models, which are elevated to the status of anti-pattern, is more than enough to reject any claim on how functional programming is compatible with DDD.

And that's perfectly fine. Not being DDD is not a flaw or a problem. It just means it's something other than DDD.

But the point that this proves is that there is no one true way of producing "good code". There is no single recipe. Anyone who makes this sort of claim is either both very naive and clueless, or is invested in enforcing personal tastes and opinions as laws of nature.

The state of HTML parsing should convince you that if you follow postel's law in one browser then every other browser has to follow it in the same way.

No. Your claim expresses a critical misunderstanding of the principle. It's desirable that a browser should be robust to support broken but still perfectly parceable HTML. Otherwise, it fails to be even useable when dealing with anything but perfectly compliant documents, which mind you means absolutely none whatsoever.

But just because a browser supports broken documents, that doesn't make them less broken. It just means that the severity of the issue is downgraded, and users of said browser have one less reason to migrate.

They accept malformed input & attempt to make sense of it, instead of rejecting it because the fields they care about are malformed.

I don't think that's true at all. The whole point of the law is that your interfaces should be robust, and still accept input that might be nonconforming in some way but still be possible to validate.

The principle still states that if you cannot validate input, you should not accept it.

Being liberal in what you accept comes at _huge_ costs to the entire ecosyste

Why do you believe that?

Being liberal in what you accept doesn't mean you can't do input validation or you're forced to pass through unsupported parameters.

It's pretty obvious you validate the input that is relevant to your own case, you do not throw errors if you stumble upon input parameters you don't support, and then you ignore the irrelevant fields.

The law is "be conservative in what you send, be liberal in what you accept". The first one is pretty obvious.

How do you add cost to the entire ecosystem by only using the fields you need to use?

Which cloud company can casually find 100B cash in a year?

AWS. Because AWS reports close to $11B/quarter, which is over half Amazon's entire revenue, and AWS owns the cloud computing market, on which the whole world runs.

These aren't "job losses", these are "firings". They aren't unfortunate accidents of external origin that happened to them, they are conscious internal decisions to let people go.

This. They also make it their point to send the message this particlar firing round is completely arbitrary and based on a vague hope that they somehow can automate their way out of the expected productivity hit, and that they enforce this cut in spite of stronger sales.

How is AWS getting billions of cash and low interest rate loans for capex?

AWS is the cash cow. It owns between a third and half of the world's cloud computing market. Do you think it's hard for AWS to get financing?

Probably many reasons for this, but what I've seen often is that once the code base has been degraded, it's a slippery slope downhill after that.

Another factor, and perhaps the key factor, is that contrary to OP's extraordinary claim there is no such thing as objectively good code, or one single and true way of writing good code.

The crispest definition of "good code" is that it's not obviously bad code from a specific point of view. But points of view are also subjective.

Take for example domain-driven design. There are a myriad of books claiming it's an effective way to generate "good code". However, DDD has a strong object-oriented core, to the extent it's nearly a purist OO approach. But here we are, seeing claims that the core must be functional.

If OP's strong opinion on "good code" is so clear and obvious, why are there such critical disagreements at such a fundamental levels? Is everyone in the world wrong, and OP is the poor martyr that is cursed with being the only soul in the whole world who even knows what "good code" is?

Let's face it: the reason there is no such thing as "good code" is that opinionated people making claims such as OP's are actually passing off "good code" claims as proxy's for their own subjective and unverified personal taste. In a room full of developers, if you throw a rock at a random direction you're bound to hit one or two of these messiahs, and neither of them agrees on what good code is.

Hearing people like OP comment on "good code" is like hearing people comment on how their regional cuisine is the true definition of "good food".

They might be bitter but evangelize Amazon products are their most marketable skills.

I think you are talking out of ignorance and spite. Most of the services used by Amazon employees are internal services that may or may not be on par with the state of the art. Apparently a big chunk of Amazon doesn't even use AWS at all, and instead use proto-cloud computer services that are a throwback from the 90s take on cloud computing.

By your definition then every little part of “Amazon” is technically a separate “company” including every geo.

No. My definition is Amazon's actual organization chart as a holding. AWS is an independent first-level branch of direct reports of Andy Jassy, who was AWS's CEO before replacing Bezos. A similar branch is Worldwide Consumer, which groups what you think Amazon actually is, which means the online store, prime, books, devices, etc.

Kindle is a loss leader?

What do you think "Kindle" is? Is it a specific device? Is it Kindle for Web? Is it the Android or iPhone apps? Is it Kindle for Windows or Kindle for Mac? Among these, can you count how many are paid?

Like a lot of big tech companies Amazon is a small number of teams with profitable products and a whole bunch of other things that don’t make money.

I think that's a simplistic view of the issue. At Amazon, each team owns at best specific features embedded in products. Some projects such as e-readers are there as loss leaders to support cash cows such as it's ebook market. From your simplistic opinion, Amazon would have cut zero employees from it's books organization as it's business is booming and it's a profit center. But that doesn't match reality.

Also note that you are making that unfounded claim while commenting on news that Amazon is going to focus it's firing round on HR. Is HR a profit center now?

Events like this are when the teams not contributing to the bottom line are cleaned up.

Except that's bullshit. Amazon decimated teams by firing new arrivals and by transferring projects out of the US into Europe and Asia. This hasn't anything to do with efficiency or performance in mind.

Amazon includes AWS. They’re not “separate companies.”

Actually, they are. Perhaps what is causing your confusion is that other parts of Amazon, such as Ring or Rivian, are also separate companies, whereas parts such as Alexa and Amazon Music aren't.

Not surprising given folks have been saying Amazon/AWS has been a bloated mess for a while now.

Who exactly do you think is saying this? Because from what I'm understanding, so far Amazon has been decimating teams at the expense of overworking them even more, and by cutting projects at the expense of cancelling maintenance and feature work.

Amazon and AWS are two separate companies.

From the article:

The cuts beginning this week may impact a variety of divisions within Amazon, including human resources, known as People Experience and Technology, devices and services and operations, among others, the people said.

It doesn't solve the problem- its the end of the day when solar has ramped down that the crises happens. Its the duck curve. Where its still hot and air conditioning is still running hard.

Isn't that scenario a problem only when the output from solar is insufficient to meet the aggregate demand?

From a naive point of view, it looks like this issue would be easily mitigated if supply from solar was increased enough to allow energy to be stored during peak hours so that it could be introduced back in the grid during sunset. Why is this scenario being ignored in a thread on how California is investing in battery energy storage?

It surprised me that a project such as NetBSD only managed to raise ~$10k throughout the year. What's going on with the project?

I tried this and it is never as smooth as described.

I think your comment shows some confusion that it's either the result or cause of some negative experiences.

Starting with GitHub. The primary reason it "just works" is because GitHub, like any SaaS offering, is taking care of basic things like managing servers, authorization, access control, etc.

Obviously, if you have to setup your own ssh server, things won't be as streamlined as clicking a button.

But that's obviously not the point of this post.

The point is that the work you need to do to setup a Git server is way less than you might expect because you already have most of the things already set, and the ones that aren't are actually low-hanging fruit.

This should not come as a surprise. Git was designed as a distributed version control system. Being able to easily setup a stand-alone repository was a design goal. This blog post covers providing access through ssh, but you can also create repositories in any mount point of your file system, including in USB pens.

And, yes, "it just works".

The official Git documentation for example has its own documentation that I failed to get work. (it is vastly different from what OP is suggesting)

I'm sorry, the inability to go through the how-to guide that you cited has nothing to do with Git. The guide only does three things: create a user account, setup ssh access to that account, and create a Git repository. If you fail to create a user account and setup ssh, your problems are not related to Git. If you created a user account and successfully setup ssh access, all that is missing is checking out the repo/adding a remote repo. If you struggle with this step, your issues are not related to Git.

How do you concern about strategy all day? Just sit down and think about it?

I'm not OP, but whenever your product is implemented by more than one team you will also have the need to coordinate and set strategic goals as well as accompany and steer each team towards where it's infrastructure/tech stack/systems architecture need to be.

If you do not offer guidance and determine technical directions, each engineer working in each team will happily fill the void and do their best to scratch their itch at the expense of the whole company becoming an unmaintainable big ball of mud.

Let's put things differently: what do you expect will be the output of a company if no one is responsible for things like directing the company's R&D effort, coordinate and specify the company's tech roadmap, even oversee product development.

It might be empirically sound, but it does not make a priori sense that exercising a body will improve it. If I use almost any object in the universe frequently, it typically degrades rather than improves.

Rejecting all evidence, denying observations, and leaning heavily on half-baked hypothesis that culminate somehow on a gotcha. That sounds an awful lot like something someone who "does their own research" would say.

Yes, extreme levels of high-intensity exercise have adverse side effects. Cross-fit and rhadbo is an example.

https://en.wikipedia.org/wiki/Rhabdomyolysis

Drinking water also does everyone good, and everyone's health will improve if they increase their water intake, but drinking water in excess can also be fatal. Does this mean that the idea that drinking water does you good "does not make a priori sense"?

No, it doesn't.

A 18 Tb NAS harddrive is about 320 USD. A 2 bay unifi unas2 199. It pays off in one year. Restoring data from it is free.

That single 18TB HD is hardly safe from a disaster or even plain old hardware death, and it's a single point of failure. You need at least 3 times as many HDs to start to have something you can actually rely on to keep your data for 3-5years.

This is a bit underwhelming because it gives a score and says, "Needs improvement", but has no real indication of what it considers problematic about a file.

I think you didn't bothered to pay attention to the project's description. The quick start section is clear on how the "score" is an arbitrary metric that "serves as a general, overall indication of the quality of a particular TypeScript file." Then it's quite clear in how "The full metrics available for each file". The Playground page showcases a very obvious and very informative and detailed summary of how a component was evaluated.

Maybe as a very senior TypeScript developer it could be obvious how to fix some things, but this isn't going to help anyone more junior on the team be able to make things better.

Anyone can look at the results of any analysis run. They seem to be extremely detailed and informative.

What about debugging.

With source maps configured, debugging tends to work out of the box.

The only place where I personally saw this becoming an issue was with a non-nodejs project that used an obscure barreler, and it only posed a problem when debugging unit tests.

Just feels like an extra layer of complexity in the deployment process and debugging.

Your concern is focused on hypothetical tooling issues. Nowadays I think the practical pros greatly outnumber the hypothetical cons, to the point you need to bend yourself out of shape to even argue against adopting TypeScript.

TS is a linter anyway.

Not really. TypeScript introduces optional static type analysis, but how you configure TypeScript also has an impact on how your codebase is transpiled to JavaScript.

Nowadays there is absolutely no excuse to opt for JavaScript instead of TypeScript.

(...) I assume this tool is meant to focus on cognetive complexity and not things like code quality, transpiling or performance (...)

I don't know about transpiling or performance, but cyclomatic complexity is associated with both cognitive complexity and code quality.

I mean, why would code quality not reflect cognitive load? What would be the point, then?

At some point I suspect a perfect score would be branchless code, but that isn’t maintainable.

That's a failure to understand and interpret computational complexity in general, and cyclomatic complexity in particular. I'll explain why.

Complexity is inherent to a problem domain, which automatically means it's unrealistic to assume there's always a no-branching implementation. However, higher-complexity code is associated with higher likelihood of both having bugs and introducing bugs when introducing changes. Higher-complexity code is also harder to test.

Based on this alone, it's obvious that is desirable to produce code with low complexity, and there are advantages in refactoring code to lower it's complexity.

How do you tell if code is complex, and what approaches have lower complexity? You need complexity metrics.

Cyclomatic complexity is a complexity metric which is designed to output a complexity score based on a objective and very precise set of rules: the number of branching operations and independent code paths in a component. The fewer code paths, the easier it is to reason about and test, and harder to hide bugs.

You use cyclomatic complexity to figure out which components are more error-prone and harder to maintain. The higher the score, the higher the priority to test, refactor, and simplify. If you have two competing implementations, In general you are better off adopting the one with the lower complexity.

Indirectly, cyclomatic complexity also offers you guidelines on how wo write code. Branching increases the likelihood of bugs and makes components harder to test and maintain. Therefore, you are better off favoring solutions that minimize branching.

The goal is not to minimize cyclomatic complexity. The goal is to use cyclomatic complexity to raise awareness on code quality problems and drive your development effort. It's something you can automate, too, so you can have it side by side with code coverage. You use the metric to inform your effort, but the metric is not the goal.

Do you really need a database for this?

I have no idea how this project was designed, but a) it's expectable that disk operations can and should be cached, b) syncing file shares across multiple nodes can easily involve storing metadata.

For either case, once you realize you need to persist data then you'd be hard pressed to justify not using a database.

He’s still disappointed because very few programmers are ever introduced to the history of computer science in the way that artists study the history of art or philosophers the history of philosophy.

Software development/programming is a field where the importance of planning and design lies somewhere between ignored and outright despised. The role of software architect is both ridiculed and vilified, whereas the role of the brave solo developer is elevated to the status of hero.

What you get from that cultural mix is a community that values ad-hoc solutions made up on the spot by inexperienced programmers who managed to get something up and running, and at the same time is hostile towards those who take the time to learn from history and evaluate tradeoffs.

See for example the cliche of clueless developers attacking even the most basic aspects of software architecture such as the existence of design patterns.

with that sort of community, how does anyone expect to build respect for prior work.

Come on, a kid was just fooling around with the developer console and probably had a curiosity just like the comment above

You're failing to address the point. It is also trivial to switch price tags in supermarkets. If a kid rips off the tag of an expensive product, tacks on another price tag for pennies, and proceeds to pay the reported price at the checkout counter, is this something deemed acceptable or even classified as vulnerability research?

Make no mistake: the system was a shit show and all companies involved pulled some "sociopath mid-level manager saving his ass" moves. But the issue is nuanced.