aastronaut

no, but you can definitely talk about it.

i also had a chat with a C++ dev that created a "Database"-class abstraction for our MongoDB instance and implemented methods to access each field of every documents separately - didn't care about side-effects, didn't know about ACID transactions and didn't care.

finding a good abstraction that allows for performance tuning later on is hard, no matter the language, and react devs should make use of good abstractions as well.

It could also mean they stick around just as long as to notice that they have to deal with the consequences of the decisions they inherited and cannot change.

SPAs and REST APIs moved a lot of the complexity around data to the client side. GraphQL moved it back to the server side. I think that's a reasonable decision, as the client - compared to the server - runs in a much more unpredictable environment. Of course some backend devs complain about more work, especially work that could be moved to the client side at first. Making things the proper way is hard, yes.

I also just finished Thinking in Systems and really liked it. I think Feedback Control for Computer Systems[0] is a bit more on the side of a working software engineer (python2 though). Probabilistic Robotics[1] is also an technical approach on control and feedback.

[0]: https://www.amazon.com/Feedback-Control-Computer-Systems-Int...

[1]: https://www.amazon.com/Probabilistic-Robotics-INTELLIGENT-RO...

Solved this by manually removing the piezo from the microwave of a flatmate... so annoying.

There was once a thread here on hacker news about missing features of operating systems, as such a thing could only be achieved on OS level... can't find it anymore, unfortunately. It was mentioned that passwords etc. could be a nightmare. A feature like that would be a big dream of mine: Some kind of an individualized semantic archiving processing and a vector search engine to search through it.

except for the autogenerated docs, you can also make use of Pydantic in Flask easily to validate your models with Flask-Pydantic[0]

[0]: https://github.com/bauerji/flask-pydantic

stupid question incomming: isn't that a '+= await' problem?

i think the discussion style of the "the little" series is quite nice to introduce concepts. it feels like i'd observe a discussion between two experienced people.

Agree here. Programming is a social discipline that should encourage discussions, rather than the enforcement of dogmas. I once worked in a team where the goal for a PR was to have as little lines changed as possible - never again.

Also a great talk from Richard Feldman about "Making Impossible States Impossible": https://www.youtube.com/watch?v=IcgmSRJHu_8

memoization is a means of simple optimization to speed up a program, just like GP wrote. you exchange the cost of executing a function with the cost of memory utilization.

say you memoize a function that is referentially transparent, needs 10secs to finish its execution and return its result (eg. factorial). then the memoization would just cache the arguments plus the return value to reduce the 10secs into a simple comparison. the worst that could happen is a missed hit which would invoke the expensive function again - just like what would happen without the optimization. that isn't a big concern, as the function is referentially transparent (without side-effects). memoization lives in this perfect mathematical world where memory for maxsize entries will always be available.

but if your expensive function is referentially opaque, but still pure, then you can't only depend on the arguments of the function, but you need to take more context into account and the additional context requires a form of cache invalidation. the context can be counter-based (only re-evaluate every nth call), time-based (re-evaluate at most once every t time, throttling or debouncing), or both (only allow for at most n/t re-evaluations over time, rate-limiting) etc. in my book that isn't memoization anymore, it's just caching. and you need to define a policy that defines its invalidation.

if your stream of inputs exceeds the available memory, it lives outside the perfect mathematical world and i'd guess you have other problems than a speed optimization through memoization. you'd then need to consider space-efficiency and i would argue that memoization is the wrong kind of optimization for that problem.

tbh i never ran into such an issue with my applications and it sounds to me like a physical constraint: i don't expect to be able to keep something cached in memory that is larger than the available memory. if i would see myself optimizing for the best "maxsize" property (assuming lru_cache), then i would rather change to a probabilistic data structure like a bloom filter or cuckoo filter (or whatever the contemporary approach there is).

can you elaborate the problem a bit more please?

I only need invalidation policies if i want to cache functions that aren't referentially transparent.

my 24" external 4K display no scaling works flawless with my 15" 4K 150% scaling notebook. (fedora 35/wayland)

I just read through your post on servers[1], as I'm currently in a similar boat (webdev working with C++ devs). I think the biggest hurdle for such developers are things like:

- statelessness of the server (REST)

- the lifecycle of a single request

- the lifecycle of a single (server-)app (microframweworks)

OOP devs unfamiliar with server development tend to pollute the app lifecycle with hidden state in some singletons that are swirling around globally. The requirement that servers should be able to parallelize request-processing is mostly an afterthought and hidden app state makes it impossible to parallelize anything.

A sequence diagram of a single request would help there a lot IMHO and a short explanation of how to keep the response times short, by doing long-running tasks in the background with message queues.

[1]: https://blog.isquaredsoftware.com/2020/11/how-web-apps-work-...

we considered PouchDB[1] (client) and CouchDB[2] (server) for an PWA back then (2017). nowadays i would probably favor WatermelonDB[3].

[1]: https://pouchdb.com/

[2]: https://couchdb.apache.org/

[3]: https://nozbe.github.io/WatermelonDB/

I have to give Elektron some credit on how consistent their design language in the Digi-/-takt family of products is. Since the first showcase of the Digitakt in 2017, that brings it to 5+ years of consistency - that has to be really rare to see. I read it like they found a solution for a cover and are now just optimizing on the internals.

thank you! here[1] it is in action in the playground.

[1]: https://www.typescriptlang.org/play?#code/C4TwDgpgBAkgzgBQE4...

From your link:

> An HTTP method is idempotent if an identical request can be made once or several times in a row with the same effect while leaving the server in the same state.

Which is according to what OP wrote.

I wouldn't translate this into "the intended effect happens at most once", as that behavior includes the effect of the transport. "at most once", "at least once" and "exactly once" are messaging behaviors after all, and idempotency is a method to convert an "at least once"-messaging-effect into an "exactly once"-change-effect.

My guess would be https://www.macworld.com/article/549755/m1-macbook-app-memor...

Frankly, time doesn't work that way... if i am atm (CET) and i make an appointment for sometime in summer 2022 (CEST), then i don't expect the hair salon to make the appointment in CET.

You seem to make a contradicting statement here with what you wrote in the sibling comment, no? timezone information are influenced by political means, whereas localization (lat/long) information is not. UTC timestamp + localization seem more correct to me.

As far as i'm aware, you should only store the location next to the timestamp and let the IANA[1] do the maintenance of the tz database. Please avoid the housekeeping on your side.

[1] https://www.iana.org/time-zones

1. MITMProxy[1] is scriptable (Python API) to modify requests/responses, or HTTP ToolKit[2] seems to be more on the non-code side (haven't used it).

2. Sure, but there's not much value in it. An API is the available contract for the communication between services. The server needs to guarantee it and the client can implement the needed parts. The client should implement solutions for server-side error cases either way, handle rate limiting, and send each request with a timeout. Everything else relies on the guarantee of the server, which, as the client, isn't your responsibility.

3. Only when i need a quick workaround for a feature the server doesn't provide (e.g. CORS injection) and maybe for test automation.

[1] https://mitmproxy.org/

[2] https://httptoolkit.tech/

you are referring to the "tally light", which uses a very limited range of values, usually 2 (off/red) or 3 (off/red/green) in a studio setting. since this here is a continuous value (based on multiple parameters) i would also think in terms of green being desirable and red being non-desirable.

As another self taught, my favorites would currently be something like (from low- to high-level):

- The Elements of Computing Systems: Building a Modern Compiler from First Principles

- Operating Systems: Three Easy Pieces

- Systems Performance: Enterprise and the Cloud

- Exercises in Programming Style

- The Little Typer

- Conceptual Mathematics: A First Introduction to Categories

i thought the little typer does also a great job in getting you into thinking about type theory.

This is an interesting bit in particular:

Data management became as critical for the hunters as marksmanship skills. As goats are social animals, sterilized Judas goats, fitted with radio collars and then released into the population, would seek out the remaining feral goats, allowing them to be located through radio telemetry and then eliminated.

DDG might has a helpful !bang[0] available or zeal[1] (or dash[2] for macOS) can also be of help

[0]: https://duckduckgo.com/bang?q=

[1]: https://zealdocs.org/

[2]: https://kapeli.com/dash