Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Grug Brained Developer (2022)

grugbrain.dev

Post reply on HN
Print view View original

581–590 of 603 posts

Re: The Grug Brained Developer (2022)

#581

Post by frollogaston »

jiggawatts wrote: post #566
frollogaston wrote: post #134

Earlier quoted context omitted.

The only useful definition of a "service" I've ever heard is that it's a database. Doesn't matter what the jobs and network calls are. One job with two DBs is two services, one DB shared by two jobs is one service. We once had 10 teams sharing one DB, and for all intents and purposes, that was one huge service (a disaster too).

A more precise view is that there are boundaries inside of which certain operations are atomic. To make this more precise: the difference between a “dedicated schema” and a “database” is that the latter is the boundary for transactions and disaster recovery rollbacks. If you mix in two services into a single database - no matter how good the logical and security isolation is — they will roll back their transactions t…

The atomicity is the main reason, but it's also about API boundaries. Sometimes someone makes a "service" that's more like a database exposing a full suite of transactions and CRUD operations, then other teams call themselves "stateless" interacting with it. But really they're sharing a DB, and thus building one giant service, because the API they're using is so broad that it creates an inseparable coupling.

Re: The Grug Brained Developer (2022)

#582

Post by nothrabannosir »

npodbielski wrote: post #577
nothrabannosir wrote: post #522

Earlier quoted context omitted.

microservices and mono repo are not mutually exclusive. Monolith, is. Important distinction imo, Micro services in mono repo definitely works and ime is >>> multi repo. Of course the best is mono repo and monolith :3

I did not stated that they can be used together. I just meant that they are mainly, for me, work as a tool to allow multiple teams work on a single big project. So the tool is more for work organisation purpose not for architectural one. If you prefer working on mono repo it s fine though I think micro services are more popular one now.

Am I reading it wrong ? I understand both your original comment and this one to paint mono repo as an alternative to micro services. E.g.: “ What is the alternative [to micro services]? Mono-repo?” and “ If you prefer working on mono repo it s fine though I think micro services are more popular one now.” What I understand here is that “mono repo is an alternative to micro services”. Is that what you’re saying?

If so: mono repo is not an alternative to micro services. You can have both. You can have micro services in a mono repo. One single repository with many micro services. That is possible.

What is an alternative to micro services is “monolith”.

Curious how I’m misunderstanding this because I looked at it for a while and I really don’t see it.

Re: The Grug Brained Developer (2022)

#583

Post by AdieuToLogic »

geophile wrote: post #580
AdieuToLogic wrote: post #571

Earlier quoted context omitted.

>> There is no value for logging "function entry/exit, with param values" when all collaborations succeed and the system operates as intended. > Well, I agree completely, but those conditions are a tall order. Every successful service invocation satisfies "all collaborations succeed and the system operates as intended." Another way to state this is every HTTP `1xx`, `2xx`, and `3xx` response code produced by an HTTP…

I'm not sure what point you are making with your scenario involving HTTP response codes. What if the HTTP server crashes , and doesn't send a response at all? I don't know from Writer Monads. But if you only emitting log entries on some future failure or request, then that's potentially a lot of logging to keep somewhere. Where? Log aggregator? Local files? Memory? What about log volume? Does this writer monad implem…

> I'm not sure what point you are making with your scenario involving HTTP response codes.

My point was to identify how common the "happy path" scenario is and was in direct response to:

>> There is no value for logging "function entry/exit, with param values" when all collaborations succeed and the system operates as intended.

> Well, I agree completely, but those conditions are a tall order.

Regarding your question:

> What if the HTTP server crashes, and doesn't send a response at all?

Again, the HTTP status codes were used to illustrate the frequency of successful invocations. But to your point, if an HTTP server crashes then log entries for in-flight workflows would likely not be emitted. A similar possibility also holds for local file system logging as buffering exists (sometimes on multiple levels).

> I don't know from Writer Monads.

No worries. All it is is a formal definition of a type having specific capabilities called "laws" in the functional programming world.

> But if you only emitting log entries on some future failure or request, then that's potentially a lot of logging to keep somewhere. Where? Log aggregator? Local files? Memory?

What is meant by "future failure" is a failure potentially encountered during the evaluation of a single invocation. In the context of a HTTP server, this would be the handling of each submission to a specific HTTP endpoint and verb. This is often defined within an IO Monad[0], but does not have to be, and is out of scope for this discussion.

The answer to the rest of your questions is the deferred log entry definitions are held in memory for the duration of the single service invocation, with any log emissions produced transmitted to a network-accesible log aggregator via the logging component used.

> Let me be real clear about all calls and param values leading up to a failure.

The scenario you kindly shared is understandable, yet is one which has been unacceptable in teams I have worked with. Losing the "first error" is not an option in those environments.

0 - https://en.wikibooks.org/wiki/Haskell/Understanding_monads/I...

Re: The Grug Brained Developer (2022)

#584

Post by phito »

9rx wrote: post #553
phito wrote: post #551

Earlier quoted context omitted.

What? We have dozens of microservices owned by multiple teams, but nothing stops you from cloning the git repository of another team's microservice and debug it the same way you would debug your own.

Service is provided by people. You, for example, discover a problem with OpenAI's system that you integrate with and the only way you can address it is to employ the services of the people who work for OpenAI. While that is an example of a macroservice (or what we usually just call a service), it playing out in the macro economy, microservice is the same concept except applied in the micro scale. But you checking out…

Sorry but I fail to see how your comments are relevant in this discussion.

Re: The Grug Brained Developer (2022)

#585

Post by burnt-resistor »

johnfn wrote: post #431
osigurdson wrote: post #385

Earlier quoted context omitted.

It seems unlikely that John Carmack doesn't understand his problem domain. Rather it is more likely the problem domain itself, i.e., game dev vs web dev. Game dev is highly stateful and runs in a single process. This class of program can logically be extended to any complex single computer program (or perhaps even a tightly coupled multi-computer program using MPI / related). Web dev effectively runs on a cluster of…

I posted this elsewhere in the thread, but if you listen to Carmack in the interview, it's quite interesting. He would occasionally use one to step through an entire frame of gameplay to get an idea of performance and see if there were any redundancies. This is what I mean by "doesn't understand the problem domain". He's a smart guy, but no one could immediately understand all the code added in by everyone else on th…

Waste of time. Flamegraphs do that (as a result of instrumentation and/or profiling), and that is the domain of profiling rather than bug hunting.

Re: The Grug Brained Developer (2022)

#586

Post by burnt-resistor »

sapiogram wrote: post #473
chickenzzzzu wrote: post #441

Earlier quoted context omitted.

Thankfully, we live in an era where entire AAA games can be written almost completely from scratch by one person. Not sarcasm. If I wrote the code myself, I know where almost everything is that could go wrong. It should come as no surprise that I do not use a debugger.

AAA games are not even close to being write-able by one person, what are you talking about. You couldn't even write AAA games from 20 years ago.

Depends what you mean by "writable". Triangle-based (software) 3D rendering engines aren't difficult but most people used COTS like Unity or actual 3D hw APIs at least, but it's all the shit that goes around them, the assets, physics, and game logic that sucks.

Back in college, we had to write a constructive geometry object renderer that used GLUT simply as a 2D canvas for a scanline-oriented triangle->trapezoid engine that roughly mirrored the capabilities of OpenGL with Phong and Gouraud shading, texture mapping, and bump mapping. It wasn't hard when each piece was broken down and spoon fed (quaternions and transformation matrices). The hardest part was creating a scene of complex object parts to model the real world programmatically.

Re: The Grug Brained Developer (2022)

#587

Post by jama211 »

chickenzzzzu wrote: post #525
sapiogram wrote: post #473

Earlier quoted context omitted.

AAA games are not even close to being write-able by one person, what are you talking about. You couldn't even write AAA games from 20 years ago.

Find me a bank that will give me a 150k collateralized loan and after 2 years I will give you the best AAA game you've ever played. You choose all the features. Vulkan/PC only. If you respond back with further features and constraints, I will explain in great detail how to implement them.

Imagine being this delusional, sheesh.

Re: The Grug Brained Developer (2022)

#588

Post by osigurdson »

burnt-resistor wrote: post #585
johnfn wrote: post #431

Earlier quoted context omitted.

I posted this elsewhere in the thread, but if you listen to Carmack in the interview, it's quite interesting. He would occasionally use one to step through an entire frame of gameplay to get an idea of performance and see if there were any redundancies. This is what I mean by "doesn't understand the problem domain". He's a smart guy, but no one could immediately understand all the code added in by everyone else on th…

Waste of time. Flamegraphs do that (as a result of instrumentation and/or profiling), and that is the domain of profiling rather than bug hunting.

Many people seem to have this overly reductive take on performance in which you 1) wait until someone complains and 2) if someone does complain the problem will be readily identified by a hotspot and will be easy to fix. The idea is why spent time optimizing things that no one cares about? Usually there are some ROI and "root of all evil" arguments go along with this and perhaps some other unexamined phrases from 00s agile.

The problem is, sometimes profilers don't identity anything in particular or unwinding things to a point where they can be fixed is actually very har. A more realistic ROI argument should include this as it is a real problem.

I think code should be reasonably fast out of the box. I'm not suggesting vectorizing everything or even taking extreme steps to avoid allocations, etc. Rather, if an algorithm can easily be O(N), don't dumbly implement an O(N^2) or O(N^24) version. If O(1) is possible, do that unless you know the numbers are going to be very small. Don't make 500 DB calls when one will do and finally, don't program by unexamined phrases - particularly those than include "evil" or "harmful" or other such adjectives.

Re: The Grug Brained Developer (2022)

#590

Post by burnt-resistor »

osigurdson wrote: post #588
burnt-resistor wrote: post #585

Earlier quoted context omitted.

Waste of time. Flamegraphs do that (as a result of instrumentation and/or profiling), and that is the domain of profiling rather than bug hunting.

Many people seem to have this overly reductive take on performance in which you 1) wait until someone complains and 2) if someone does complain the problem will be readily identified by a hotspot and will be easy to fix. The idea is why spent time optimizing things that no one cares about? Usually there are some ROI and "root of all evil" arguments go along with this and perhaps some other unexamined phrases from 00s…

There are many methodologies and tools for profiling but single-stepping assembly stack frames mythology ain't one of them. Identifying hot sections requires gathering data, not wasting time tinkering manually without a plan.
Post reply on HN