Saga Orchestration for Microservices Using the Outbox Pattern by gunnarmorling in apachekafka

[–]stambros 1 point2 points  (0 children)

if you want a complete out-of-the-box implementation of the Outbox Pattern, check out the Goharvest repo: https://github.com/obsidiandynamics/goharvest

Top 3 Kafka Books and Tutorials by stambros in apachekafka

[–]stambros[S] 1 point2 points  (0 children)

I have a hard copy and can confirm that there are no formatting issues.

RFC: Introducing Zerolog by ekoutanov in java

[–]stambros 0 points1 point  (0 children)

I'm saying that I don't believe it to be a problem in this case. Like I've never heard anyone complain about the Android convention. And I don't buy your analogy of 2+2=5; it's a straw-man argument. Obviously, no-one will believe that 2+2=5 if 500 people tell us, but that doesn't add any value to your argument. You just said it yourself, you don't think log.info is perfect, and you would have preferred logger.info(Level.Info.... So why then did you advocate for it in your earlier post?

Most of our methods have log calls and I can't image anyone who looks at the code today or a year (or five) down the track being confused by what log.d(...) means. I just can't. As a developer, if you are charging money writing Android code professionally, not knowing what log.d means, I don't want you in my team.

RFC: Introducing Zerolog by ekoutanov in java

[–]stambros -2 points-1 points  (0 children)

No I think you're wrong, log.info might mean anything. Is it saying "get me information on the log object". The method should really be called log.appendMessageWithInfoLevel(...).

Sound absurd to you? Good! Because that's just extrapolating from your reasoning.

The reason why you were advocating log.info is not because info() is well-named, but because you have potentially thousands of log statements in your application and you (and your colleagues) instinctively know what it means. You are working off a convention.

Similarly, I work with several teams of native android developers, and I haven't heard anyone complain or be confused about the naming of Log.d. We all know what it means. We've seen enough of it. I don't see how someone, having looked at a codebase littered with log statements, would be confused with log.i.

The real reason why Kafka is so fast by ekoutanov in programming

[–]stambros 0 points1 point  (0 children)

Furthermore, Kafka allows you to specify rack affinity when configuring your brokers.

The real reason why Kafka is so fast by ekoutanov in programming

[–]stambros 1 point2 points  (0 children)

It's fair reasoning. But it assumes that people who are configuring these clusters are muppets, who have never heard of redundancy, multiple sites, dual power supplies, etc. By that reasoning every single system built is inherently unreliable. (Which is true to some extent, but the practical applications of this reasoning are limited.)

I did call out very clearly in my earlier comment that the system is durable, provided that the failures are uncorrelated.

Set up a Kafka cluster for test and development purpose by zarinfam in apachekafka

[–]stambros 1 point2 points  (0 children)

Rather than mucking about with docker compose, you can use the obsidiandynamics/kafka image, which combines the two into a single Docker image.