“Domain Driven Design” by Eric Evans, aka the blue book. It’s very dense however and very object oriented, but concepts apply even if you dont work with object oriented languages, you might have to do more footwork to get from a domain model to services that adhere to the model.

“Head first Software Architecture” might be an easier on ramp and touches on simmiliar concepts.

yes, this is exactly what you have to think about. the left example even aknowledges that deadlines for “tasks” might be different from deadlines for “payments”, which suggests that the abstraction is not “clean”.

“logs show a reoccuring error in layer 8 everytime a subset of users engages with the system, reassigning this to the service desk to gather more information.”

i’ve read that on real ticket, i’ve laughed about it. it also makes me glad that i don’t do customer support, i don’t have the patience to keep explaining the same people that they keep doing something wrong and i lack the diplomacy skills to engage with devs that believe to be infallible and pretend that bug reports are personal insults against them.

because no one follows the damn guide and “scrum” is done so managers can claim the company can work “agile”, because customers dont want “not agile”, customers also dont want to participate in the way it would be necessary for a project thats supposed to follow the scrum guide. that also sounded good for people looking for a new job so hr wants to put that into job descriptions and now everything is scrum and agile and i still have to sneak in refactorings or have to fight to get time to work on our fricking ci pipeline or need to conspire with QA to get them time to work on test automation, because screw the notion that decisions should be done by the people doing the work.

screw “scrum”, and the word “agile” should never have been taught to anyone claiming to be a “manager”, we don’t need managers we need people helping us getting the tools we need and trust that what we do, we do to deliver better solutions and helping us to fascilate constructive exchanges with customers.

data-plumbing-for-corporations tends to be able to be done in a way that’s easily testable, but also most people get paid to bolt on new shit onto old shit and spending time on “done” code is discouraged so once they fall behind on writing tests while developing the new shit those tests will never be written.

and bad developers that won’t write tests no matter what actually do exist.

my problem is not with words changing there meaning its with words losing meaning.

rest api today means any api ontop of http where response bodies are json, but nothing more, we can’t get much more general when talking about web apis than that, “rest” is almost meaningless and we don’t have a new word describing APIs that adhere to the constraints of what restful meant, but those are a useful tool for building web applications that can easily be used by a web browser. no matter if you like fielding-rest-style-apis or not, you lost the ability to call them by a name and gained murky mumbo jumbo for it.

I’d Agree in most cases, but not in this one.

Rigor in definitions allows us to express a lot of complex things in a compact form. this allows us to treat “Cars” as something different than “Motorcycles” while both a motorized vehicles.

the same is true for REST-API and other API-Types, while all of them are just a means to allow services to exchange data, they tell us a lot about how this exchange happens and what to expect, but only if we use the words in a way that they represent the concept they were meant to represent. Otherwise we end up with meaningless buzz words like “rest”, “agile”, “scrum”, “artificial intelligence” and so forth, instead of meaningful terms found in the jargon of other engineering disciplines like “magnetism”, “gravity” or “motor”.

i’ve only read about rust, but is there a way to influence those automatic implementations?

equality for example could be that somethings literally point to the same thing in memory, or it could be that two structs have only values that are equal to each other

Strings are Objects, Doubles are Objects (that are than unboxed into primutives doubles)…

the “what” is interesting on interfaces or when you generate documentation with some tool like sphinx or javadoc.

the “why” is interesting when you are somewhere inside a class or function and do something in a “strange” way, to work around a quirk in the codebase or something like that, or when you employ optimizations that make the code harder to read or atleast less obvious why somethings are done.

• avoid automated documenting tools

the output of tools like sphinx, javadoc and so forth is a good starting point, especially if you feed them properly commented code.

the rule “garbage in, garbage out” definitely applirs here.

good Tester.

If something stupid can be done, it will be done.

I’ve seen enough programmers blindly copypasting code from stackoverflow and other forums without thinking and never understanding the thing they just “wrote”, to know that tools like copilot won’t make programmers worse, they will allow more people to be bad programmers.

people need to read more code, play around with it, break it and fix it to become better programmers.

parquet is cloesely tied to the apache foundation, because it was designed as a storage format for hadoop.

But many data processing libraries offer interfaces to handle parquet files so you can use it outside of the hadoop eco system.

It’s really good for archiving data, because the format can store a lot of data with relatively low disk space, while still providing ok read performance because often times you won’t need to read the whole file due to how they are structured, where csv files would be a lot of plaintext taking up more diskspace.

since none of your examples add anything of value in the body: a plain old 403 is enough.

response bodies for 400 responses are more interesting, since you can often tell why a request was bad and the client can use that information to communicate to the user what went wrong.

best error code remains 418, though.

there is no “undefined” in java. this would either be a map containing the key value pair (“name”, null) or it would be mapped to an object of some class with an attribute “name” which can hold a null value. in any case {} wont equal {“name”:null}.

sounds like you want a MultiKeyMap and a way to store the data from which you build the map, so i’d suggest to look up that data structure. incremental search could than be implemented by filtering on the key sets or subsets of it.