karolinepauls

It statrs with "At the same tiem" so it's consistent.

I am aware that the purpose of an overwhelming majority of companies is to earn money. Does auto-playing their own video with audio increase revenue? It's not an ad someone is paying for.

This is completely off topic but I'm shocked that zdnet autoplayed a video with audio on after I opened the page and scrolled down a little. Incredible that we still have websites whose primary purpose isn't playing audio automatically play audio. There's no way this doesn't annoy a vast majority of users.

This phenomenon terrifies me greatly - how large organisations can be ignorant of the basics of their purpose. I believe it is one and the same mechanism of collective incompetence, which can affect both a media company, a school, or a government. It's as if the humanity, under any system, were bound to create inhospitable conditions for one another.

s/everything is/everything seems to me/

As demonstrated, crisps are more valuable to the society than art.

That's too reductive. Vacuum full isn't just slow, it exclusively locks the table for the duration of the vacuum and is basically a no-go when the database is in use.

And make sure your `random_page_cost` is about 1.1 if running on an SSD or if >~98% of your hot pages fit in memory. Rather than 4 by default which makes the planner afraid of using indexes.

Two things - the word "idles" and the nature of CPython's allocator which generally doesn't return memory to the OS but reuses it internally. So you cannot really "spike" memory usage, only grow it.

> Python: ~60% waste (Mostly sized for startup spikes, then idles empty).

I understand we're talking about CPU in case of Python and memory for Java and Go. While anxious overprovisioning of memory is understandable, doing the same for CPU probably means lack of understanding of the difference between CPU limits and CPU requests.

Since I've been out of DevOps for a few years, is there ever a reason not to give each container the ability to spike up to 100% of 1 core? Scheduling of mass container startup should be a solved problem by now.

I wonder what would happen if someone evolved a circuit on a large number of FPGAs from different batches. Each of the FPGAs would receive the same input in each iteration but the output function would be biased to expose the worst-behaving units (maybe the bias should be raised biased in later iterations when most units behave well).

Sorry not to have made this clear: I am not a frontend developer. I'm a backend/infra developer who's forced to work on a React app abandoned by a frontend developer who incorporated their own wrappers-of-wrappers-of-wrappers.

Meanwhile the client is telling me is virtually impossible to find frontend devs willing to write HTML.

Good riddance indeed. The last 30 years of software teaching basically trained developers to produce complexity for its own sake, while calling it engineering. I'm not sufficiently full of myself to link to my own writing (yet) but I'm full of myself enough to self-paraphrase:

1. Programmer A creates a class because they need to do create an entry point, a callback, an interface... basically anything since everything requires a class. Result: we have an class.

2. Programmer B sees a class and carelessly adds instance variables, turning the whole thing mutable. Result: we have an imperative ball of mud.

3. Another programmer adds implementation inheritance for code reuse (because instance variables made factoring out common code into a function impossible without refactoring to turn instance variables from step 2 into arguments). Result: we have an imperative ball of mud and a nightmare of arbitrary dynamic dispatch.

At some point reference cycles arise and grandchild objects hold references to their grandparents in order to produce... some flat dictionary later sent over the wire.

4. As more work is done over that bit of code, the situation only worsens. Refactoring is costly and tedious, so it doesn’t happen. Misery continues until code is removed, typically because it tends to accumulate inefficiencies around itself, forcing a rewrite.

Phages don't devour bacteria, they get inside and hijack them, like viruses tend to do with cells.

I was responding to as single comment. I do not have a responsibility to respond to the whole thread. I'm going to include it again, in full:

> A forest or wetland is a carbon sink only in the growth phase. In a long-term equilibrium, it's carbon-neutral, like biofuels.

Highlight: *In a long-term equilibrium*. The comment literally talks about long time periods...

The parent comment I'm responding to is literally:

> A forest or wetland is a carbon sink only in the growth phase. In a long-term equilibrium, it's carbon-neutral, like biofuels.

To which I'm stating that forests and wetlands are not carbon-neutral but carbon-negative.

Then you miss the parent comment's context and start in an inflammatory way:

> Bwahaha, this is so ridiculous.

And take it somewhere else (move the goalpost) - from whether forests are carbon neutral or not to how effective charcoal creation is at carbon capture, in our human timescale.

Meanwhile the only practical point wrt. charcoal creation from forests was:

> Humans could actually cut down old trees, dry them, and convert them to charcoal later used for soil enrichment.

Which doesn't propose an effective carbon capture solution. At most it's something like emission reduction - the key phrase is old trees. And soil enrichment.

Recommendation: don't argue against points people didn't make.

The root of good faith conversation is that we don't latch on fuzzy meanings of words like "comparison" but try to understand which precise meaning should apply.

The result of subtraction is a difference. In my mind this is the most basic way to compare things. Subtraction of differing units is illegal.

The result of division is a quotient (day to day we say ratio). Division of different units is legal but not always practical.

`kg of fuel per metre` is division, not comparison. You can divide different units by each other. It isn't guaranteed to always make sense but it's very useful.

It's always been like "you cannot compare values of different units" to me. Maybe we should start saying "you cannot compare kilograms to metres".

It's as ridiculous as the comparison of the most recent 12k years of the holocene to the age of plant life on the Earth.

As for using lumber for timber, when eventually disposed it would have to be turned into charcoal rather than burned for energy or let decompose in conditions that don't sequester carbon.

You also missed the point about using charcoal for soil enrichment.

The world is more complicated than a 17th century lab experiment in combustion.

Forests sequester carbon through forest fires producing charcoal. Humans could actually cut down old trees, dry them, and convert them to charcoal later used for soil enrichment.

Wetlands capture carbon by incorporating wood from dead trees in anoxic conditions.

> When plant productivity exceeds decomposition, net soil carbon accumulation occurs. This process eventually leads to the formation of deep peat deposits, which can accumulate for thousands of years.

https://link.springer.com/article/10.1007/s44246-024-00135-y (first search result for wetland carbon sink)

I'll go further and elsewhere at once: APIs should not present nested objects but normalised data. It enables clients to easily to lay out their display structure independently of API resource schemas and eases out tricks like diffing between subsequent responses, pulling updates or requesting new data by passing IDs and timestamps of already known data, etc. API normalised data obviously shouldn't correspond to DB normalised data. Nested objects are superior only for use with jq.

Sadly, the minorities (in the Anglosphere at least) don't deliver at either "think" or "independently". Their counterculture is as countercultural as joining a church. Just another way to fit in. Be be slightly different and they'll chastise you - a high-profile example of this mechanism has just happened again https://archive.is/qeDfU. Unless that's what it's always been.

Hooligan-like countercultures are also excluded as far as "think" or "independently" goes for an obvious reason.

Thus, the only independent thinkers I've encountered are individuals who don't aim to have all the answers, who can accept disagreements, who attempt to know themselves - but those are individuals, not countercultures.

I'm erring on saying that countercultures were never about independent thinking. They were about fitting in with different people.

I've heard of good experiences using a 3rd party QA company (for frontend-heavy changes) and had pretty OK experiences doing it in-house with subject experts (though testing backend changes, so pretty much "either it works or it doesn't" in my case).

The way loosely-defined "we" call(ed) things in different periods of time isn't a good basis for conclusions, especially in topics in which there was basically no good science 50 years ago.

  Location: London, UK
  Remote: Yes
  Willing to relocate: Maybe
  Technologies: Python (mostly Flask/FastAPI+SQLAlchemy, browser automation), Postgres, Clojure, FP, frontend (JS/cljs, React/re-frame), DevOps (Terraform, Kubernetes), Linux (erhm, GNU/systemd/Linux), some Rust/C/C++/Go
  Résumé/CV: https://drive.google.com/file/d/1dKFmLj3ILK7n7GcnlyS2WcybiPWg1uia/view
  Email: jobs2025.extent293@passinbox.com
  Website: https://karolinepauls.com/

Experienced (mostly) backend developer, with 12 years on the record. Wearer of the DevOps hat when needed. Eager to share skills and learn. Willing to expand to adjacent domains.

I am able to work with minimal resources and deal with inherited problems. I aim to produce solutions of minimal size and complexity. If possible, I try to solve classes of problems to avoid dealing with problems one by one.

Currently a contractor with a short notice. Recent projects involved an LLM content generation pipeline and stabilisation of a reporting system.

> Your software will still be a mess

Your software will still be a mess but a mess you can work with. Not a horror beyond comprehension. We should aim for workable mess.

This is from experience working with both procedural/functional mess and OO mess.

Because not everyone wants to be a part of the asyncio trend.

Asyncio in Python is a poor feature that splits the language's ecosystem into 2 mutually-incompatible worlds, something Python only gets away with because it's too big to fail.

Meanwhile we've had Gevent for decades now. It gives us async that you can forget you have. Because rather than making code async, it makes the VM async.

Gevent could have been merged into CPython, but they chose explicit "structured concurrency" and the rest is history. History of sometimes moving forward and sometimes straying from the path and getting lost.

And lost Python's asyncio is. PDB, which lots of other debuggers base on, is still broken (cannot use await). The ecosystem? IPython uses asyncio internally so it cannot easily be embedded in a working async program. The only embeddable REPL I was able to find is this: https://github.com/prompt-toolkit/ptpython/blob/master/examp...... actually, it looks like someone is working on adding `await` support to PDB now, years after asyncio's first release.

Overall, lots of churn to get something (maybe) as good as Gevent, which we had in Python 2.7, or even before.

If a similar amount of effort was spent on first-class support for code hot-reloading and live program inspection, we would get a massive boost of productivity. But somehow even otherwise bright people choose to reimplement working solutions into something objectively worse, meanwhile our development/debugging loop still emulates loading punchcards into mainframes.

A good pitch for dynamic (context) variables is that they're not globals, they're like implicit arguments passed to all functions within the scope.

Personally I've used the (ugly) Python contextvars for:

- SQS message ID in to allow extending message visibility in any place in the code

- scoped logging context in logstruct (structlog killer in development :D)

I no longer remember what I used Clojure dynvars for, probably something dumb.

That being said, I don't believe that "active" objects like DB connection/session/transaction are good candidates for a context var value. Programmers need to learn to push side effects up the stack instead. Flask-SQLAlchemy is not correct here.

Even Flask's request object being context-scoped is a bad thing since it is usually not a problem to do all the dispatching in the view.

I don't know who's right but I know that it's the ergonomics of programming languages that make producing stateful blobs fast and easy that are in the wrong.