joseph8th

I think this is insightful thanks. We did this recently, and combined with the OP article, I'm really reminded of how fundamental and ubiquitous queues are. They aren't always obvious, or even intentional. I generally don't set out to design a queue. It just sort of happens while I solve a problem.

So yes, adding an MQ specifically just embeds another queue in your original queue. If your scaling problem is an unbounded, maybe unintentional queue, then the MQ can provide just the throttling you need to keep from overloading your consumer end.

Yep, the system just got more complicated, but now it's also more manageable, because we hacked a governor into our unregulated queue.

As discussed elsewhere, you still have to deal with the back-pressure on the producers' side.

Oh well, if YOU define it THAT way...

I'm one. Just a schmuck, but I haven't given up on the idea of America. Not like George Washington, or Abraham Lincoln, or JFK, but like George Washington Carver, or MLK Jr. The idea that the American Revolution never ended. That the Civil Rights era was just another phase in our centuries long progressively more democratic experiment in self-government

I have always considered myself a patriot, even in my commie youth. The idea of America to me was revitalized and given honor and dignity in the Civil Rights era. Real sacrifice. Self sacrifice that leads to progress, not sacrificing others for personal profit. Something indefinite, yet you know it when you see it, like porn.

A coworker originally from Russia the other day expressed dismay about Ukraine and worry for the democracy there. Her family back home doesn't know much about the war, but she does. She became a citizen last year, and but she seemed like George fucking Washington in that moment

Clearly you should have read Orwell's essay. He makes clear the distinction between patriotism and nationalism in the first couple paragraphs.

Dad? Are you on HN?

ETA: I love my dad. He does this.

Ah look at that! Nice catch. Yes, I can see that something is done to fix that, though I'm not on that team (I'm backend).

And to address the debate below, I do in fact appreciate risk-averse and focused engineers. The 'don't say no' thing I think has merit when interfacing with business. But within the team, as long as you're in your own lane I appreciate it very, very much when my coworkers help me find flaws.

Most of this comes up in planning anyway, when we're spit-balling best approaches. If the problem is difficult enough, someone will get a research spike to discover best practices and form a set of initial proposals and alternatives.

ETA: and yes this is my public profile. I don't mind. I'm proud of my work at CIELO.

Yah... I have a long-standing habit of commenting `TODO` for some debugging or WIP code. Then, before I commit, I can just do `git diff | grep TODO` and see all the new TODOs I've added.

Emacs `magit` might qualify, if you don't mind first learning Emacs

I don't need to repeat that Git has terrible UI, but you can get this "history" with `git merge --no-ff <MYBRANCH>` (no fast-forward).

In fact, it's a pretty common branch-based flow. Our team pushes feature branches to remote, where they are vetted by QA, and we have a chance for review.

When pulling changes into any branch, we always `git pull --rebase`. When merging feature branches, we always `--no-ff`.

For small, local merges, we don't use `--no-ff` because it's useless noise. But if someone forgets out of habit... Oh well. I spend on average 0.000000001% of my time going through git log. And when I do, I tell it to show as a tree

We had a DevOps engineer who was brutal this way. Personally I found it only occasionally annoying, but our PM almost fired him several times. I talked him down by pointing out that risk aversion is a good quality in an engineer.

When we interview for engineers, we always ask candidates if they are risk-taking multi-taskers, because those are desirable qualities... In some other field.

Uhhh... I use all of those things. And Firefox. It's less demanding on resources, and the containers are game-changing.

Why choose Chrome? I can't think of a single reason to prefer it over FF, but have just provided 2 reasons to prefer the opposite

"How dare you use my words and actions against me!"

Yah here ya go: https://github.com/joseph8th/oporg

I keep meaning to try org-roam, but when I looked into use-cases it didn't really match my flow. I tend to take two kinds of notes: jots and dev notes.

Jots go on paper, and are dealt with quickly.

Dev notes are for my own reference, and I provide them with a certain formality and completeness, as if I were writing documentation.

Years later, when questions inevitably come up about that legacy code, I have a plain text file I can send to whomever, with reference to the Jira ticket. Often I attach these notes to the ticket.

So a whole back-linked network of little informal notes and jots isn't in /my/ flow. It has no useful place. Instead, notes are where I expect: in local files related to the project.

My other major use for notes is the novel I'm working on. There, I can relate to the OP's "where do I put this?" dilemma. I have a scratch section, but it's more like a graveyard of ideas. Otherwise, my notes already have so much structure that I have to make decisions. But, that's the job, isn't it?

I'm guilty of the same thing. Especially between jobs I do an incredible amount of tinkering heheh.

My worst such shelved toy turned an org-mode file in your project repo into Kanban board, locally editable in the browser using a websocket to running Emacs server. Spent weeks getting it to sort of work. Never used it once

Really it's just a souped-up Python interactive shell. When you give it bash commands, it forks to bash. When you give it python it evaluates like a REPL

No new syntax, unless you want to write scripts in xonsh, or mix bash and Python in the same command. There's rarely any reason to. 99/100 times I just write pure bash or pure python

And then there's `xonsh`, "The unholy union of bash and Python."[0]

Which I've been using as my daily driver for a few years, and absolutely swear by it.

https://xon.sh

YyyyyyyyyyyyyyyyyyuuuuuuuuuuP. 9 times out of 10 it takes me right where I want to go. It's lightweight and fast. And on that 10th time it gives a list of choices to jump to.

Like the author, I also enjoy making things out of plain text. I'm perhaps less evangelical, but after all they are a Vim user, so... ;)

My own flow occurs entirely in Emacs, where I write in Org Mode, then build and deploy to GH Pages using Nikola. No more command-line steps for me! And no inferior new-fangled plain-text format: good ole Org Mode stands the test of time.

What a great read! Way to keep the reader engaged while building up the basis for a wide-ranging analysis.

Hermeticism might be mentioned in this context, as well, and it's many offshoots over the centuries. If gnosticism has proved insidiously long-lived, it might be attributed to the close association with early Christianity. More likely it has roots in a much older archetypical dualism in which the material and spiritual were the original duality. One rooted in personal experience of "inside" and "outside" which is, kinda ironically, projected onto the outside world. "If all people have an inside and outside existence, then so does everything else, including Everything."

It's pretty trippy thinking. And it follows both Christianity and Judaism down the centuries. First in sects and then heresies and then secret societies. Always initiatory, always exclusive, it's "the occult": that fervent desire in humans for the divine promethean magic. To be as gods. To will into existence that which we desire, without consequence.

It persists! It's getting worse! Flat earthers are a THING. In 2022.

It kinda makes sense that Gnosticism followed the religious through history. It's more surprising to me that Magic did. I see that as a bigger problem.

Found the Hobbesian

Ok I'll ask the question:

Will it fill the oceans with indestructible junk?

Yeah, I encountered this difficulty while writing the "literate" API documentation that my blog post was based on. The example in my post is very simplistic. The real thing makes numerous database queries to set up data, then creates an entire mock "client" with a mock employee, mock location, mock services, appointments, etc., by making successive requests to the (local dev) API. Order matters. And it's still a pretty simple example of literate programming (if, as someone mentioned earlier, it could be called "literate programming" at all in the sense that Knuth meant it).

In that regard, I'd say it is. True, we don't tangle and weave to separate artifacts. In fact, it doesn't tangle at all. However, I'd argue that in this case that isn't the point of the program. It's essentially a TUI to build an HTML artifact. Obviously we can't tangle `restclient` source blocks, but nor are we just dumping the results of `restclient` requests. Everything is piped into bash and post-processed by `jq` to clean up the final result for display.

That said, I accept that it's still not really "literate programming". It's literate API documentation.

I know what you mean. I was paid to write the API, and the documentation, which provided the necessary motivation to try to write it "literate". I had already been using `restclient` instead of Postman to interact with other APIs I work on. It was just a matter of being paid to take it to the next level.

Good question. In my case, I use the Org file instead of Postman (or some other API client) and I keep it in the same repo with the code.

When I generate the `index.html` from Org, I point it at my local API, so there is never any doubt they are on the same version.

I always liked the idea, but I was a pure math major, CS minor. Turns out I was better at programming that proof-writing, but Literate Programming is associated with the "Ivory Tower Academic Elite" because it really is handy.

Jupyter notebooks can provide a literate programming experience as well, but the plain-text experience of Org is something special.

This approach would work just as well to document and develop, for example, a local Python API. Instead of using `restclient` source blocks, we'd be using Python blocks. Otherwise, it's the same idea.

In my case, I'm documenting RESTful APIs for clients who want to write their own client code.

Sorry! Fixed the links. Thanks for point it out. It was WOMMing.