Now someone should open a Jira ticket, refine the task, estimate it, define its priority, push it to the backlog and maybe the next sprint (if it is important enough), someone will be assigned, checking all the DoD and DoR boxes, submit a PR, getting it approved and then it will be fixed.
I wish it was that easy! You are missing the 'triage' state after the ticket is opened, the 'review' state after priority, and the 'approval required' state after moving to backlog, sprint and fixed.
Plus all the other steps in the custom workflow some upper management spent weeks putting in place without speaking to the actual workers who need to follow it.
Exactly-once semantics is virtually impossible to achieve, there is a lot of literature all over the internet, but an easy example could be the following.
Imagine a client sending messages to RabbitMQ with some retry policy if it doesn't receive the ACK from the broker. If the client sends the message and it doesn't receive the ACK in the terms it has been defined (maybe a timeout of 30s), it will retry to send the message, as the consumer assumes that the message hasn't been received by the brokers, but it could be that the ACK back to the client is the one that failed to be sent to the client. The brokers actually saved the message, and they stored it, but the client doesn't know, so it retries the message.
If you don't have some control over the messages, this retried message is _new_ to RabbitMQ, so it will store it and send back the ACK. Maybe this time it is successful and no other retries are made.
With this scenario, the brokers would have received the same message twice. By adding this kind of control (Kafka does more or less the same by discarding messages with already processed IDs when configured as exactly-once) you can try to avoid duplicates. Of course it is limited by memory and it is not in fact exactly-once semantics, so they are calling it now _effectively exactly-once semantics_, as it is more precise.
"Exactly-once semantics is virtually impossible to achieve".
Impossible to achieve for a broker, yes. Combination of at least once delivery everywhere upstream and deduping in the consumer gives that consumer exactly once processing.
Lots of people don't grok that and they can be duped into buying certain products with claims that they offer "exactly once". Kafka does or used to do this, SQS (FIFO) also gives this false impression although they are a little more subtle about it. As soon as 1 vendor does it, they all have to do it.
Yeah...but at the same time, it's not like normal people are going to know about it, certainly nobody would bring it up in a corporate environment or risk outing themselves as some kind of weirdo, so it's probably fine? It's not their fault that random forums prescribe shock value to regular words.
I did almost the same last weekend. I wanted to start a blog[1] but all options seemed too much for a simple purpose that is a blog. After researching about VuePress, Sapper, Next.js, Gatsby and so on, I finally decided that it wouldn't have any kind of JavaScript. I was tempted to create yet another static site generator, but I am sticking to the old HTML + CSS duo (and, regarding CSS, classless CSS) for my blog. Yes, it has some downsides, but hey, it only needs a text editor and internet connection and the blog is blazingly fast.
For ease of maintenance and portability I think markdown is really the king of formats for blog content. Are you writing the posts in HTML? Why are you intermittently using <span> for paragraphs and to wrap other elements?
Yep, I am writing the posts in HTML. The reason to avoid Markdown (which I love) and other things is to avoid any kind of building tools. I tried to install Gatsby on a Windows machine and I had several errors. I wanted to remove any dependency on external software. I wanted it to be modifiable with just a text editor and nothing else.
Regarding the use of <span> is because the <p> tag with the chosen CSS leaves too much space after <h*> tags, while <span> doesn't, and as I wanted to just use HTML tags and not create my own version of the CSS, I found <span> the easiest way to achieve that.
I definitely understand the desire to avoid a build-time tool. Especially Gatsby is way harder than it should be to get up and running. But for me, portability and data integrity trumps ease-of-publishing. If you want to move your blog to a new system in 5 years, you'll have to migrate a bunch of HTML. If you had the posts in markdown, chances are it would be a plug-and-play with the new system.
That's the reason I pointed out the <span> usage - your source of truth for your data is HTML, but in this case it's already getting mixed up with design-related oddities.
Not bashing your choice for your blog, I think it's reasonable. I just wonder if HTML is the most resilient way to store blog data. It's something I considered a lot when redoing my blog last year.
Also zola, hugo, and other pretty light weight generators are quite okay. I'm using zola which runs nicely on Win/Mac/Linux. All you need to get started is some theme/template and your blog posts in Markdown. Then enrich it with whatever floats your boat.
