Felk

Are you talking about their backend tech specifically? Because the MS Teams frontend is lacking far behind Discord in terms of polish. It has 5% of the features and already performs like a bloated mess. It's hard to tell how robust their backend tech is but given that opening new voice channels takes 5-10 seconds, or that they had to update the client to have more inaccurate online statuses to fix backend performance issues does not give me much confidence either.

Yep, it's a direct quote I remembered from the Changelog Podcast #201 "Why SQLite succeeded as a database" starting at timestamp 15:58

https://changelog.com/podcast/201

> SQLite is called ‘lite’ for a reason. If you need functions, add them yourself.

Most people I know, myself included, pronounce it that way. But Richard Hipp, the creator of SQLite, actually pronounces it SQL-ite, like a mineral.

Technically deleting a directory is done with the rmdir command. But rm with flags is flexible enough that I've seen very few people use rmdir

I got a function that assigned the same expression to three variables. Then it declared a void function with documentation stating "returns true on success, false otherwise". Apparently that code was written by a human, which makes me either doubt the correctness of that website, or the quality of the code it was fed with

Source code is on GitHub: https://github.com/netflix/dgs-framework

I've used online diff checkers in the past for their convenience, but in the end I went out of my way to find a convenient way to quickly diff two texts locally. It's not that I believe that online diff checkers upload the contents to some third parties - in fact this one explicitly says everything is performed locally - but the fact that they _could_ made me feel uneasy.

The same could be achieved by having the server return different views of the data for different HTTP Accept headers, although not as convenient as appending a file extension. I once did this to interpolate REST API responses into dedicated HTML templates if requested with Accept: text/html, which made exploring the API in the browser more enjoyable.

I think having a backup solution is the better choice here. You can use your SSDs until they die or become too slow, and you won't lose your data if it breaks before you replace it after a year

Is that demo of yours available somewhere? It sounds interesting and I'd love to read up on it

> either up-arrowing until I found the last time I ran tests

just as a substitute for up-arrowing, have you tried ctrl-r/reverse-i-search? (if that's a thing in fishshell)

edit: I see wodenokoto already mentioned this workflow in another comment

For me one of the biggest advantages of using GraphQL is that clients consuming data can directly express what they want. The backend implementation can then do all sorts of magic to turn intent into execution.

Regarding the n+1 problem: of course that can be solved with plain rest endpoints as well, but it requires you to form your API around it, where if you have one unified endpoint solving the n+1 problem is a mere implementation detail on the backend.

In situations where it's desirable that a system's complexity is expressed in the API design, I can see GraphQL not being a good fit. If I compare it to SQL it is understandable that you sometimes do need to restrict what can be done to clear predefined operations, say for performance reasons. But if you can get away with this general "intent-based" querying, which GraphQL does well, I recommend it over plain rest endpoints.

It sounds like you interpreted malux85 suggestion as cutting the bot off from putting things in the cart altogether. What I understood is that, given it's recognizable by user agent, those carts can be marked as created by a bot to exclude it from statistics and reminder mails only.

The modal that pops up is not in the dom until you click the "See details" link, which has target="javascript:;". The "Add to cart" button is an actual link. I wouldn't be surprised if Google just doesn't want to run javascript to extract pricing information if it doesn't necessarily have to.

JSON generally requiring the entire document to be present before parsing can indeed be a problem. However, for one common use case there is a pseudo-standard, namely "JSON lines".

"JSON lines" extends JSON by a) not allowing newlines in values and b) allowing newlines to be used as a top-level separator for elements of a list, instead of the JSON-compliant comma-separated list enclosed in square brackets

This allows for per-line parsing, which can significantly reduce memory usage and allow for partial parsing in some scenarios. I've seen it used where the data is fundamentally a large collection at the top level where producing proper JSON was using too much memory

Regarding metadata: Considering windows already lets you strip metadata from images directly from the properties menu, is there anything this tool or other metadata stripping tools do that goes beyond what windows offers? Is it risky to rely on the built-in tool?

Isn't that a good thing? If a thing does X, I'd very much like to know what other things do X as well to try and understand how they differ.

I found myself using msgpack as a drop-in alternative for acceptable mimetypes for HTTP responses in a flask app. Browsers would get the response data with the pretty-printed json embedded (or even a custom template with the data fitted in, if there was one for that specific endpoint), api clients asking for nothing in particular would get pure json, and clients asking for msgpack would get that.

Seemed like a free way to offer slightly better performance on the API (both serialize/parse times and bandwidth), since it can just serialize any data without specifying protocols or schemas, like json serializers can too. I didn't know about any alternatives that would also require no further configuration or infrastructure, so it seems like msgpack fills this 'free performance boost' niche quite nicely

If you want to see Herb Sutter's take on exceptions (and RTTI), I can really recommend this talk where he explores his Result-esque (like in Rust) solution that he wrote a paper about and proposes for standardisation: https://youtu.be/ARYP83yNAWk

httpx makes a pretty good first impression on me. The homepage provides examples, key selling points, install instructions, and links to any further reading one could hope for. However, I am missing one thing: The features this offers over the popular requests library do not seem to require httpx to be a competitor, but an extension or fork. There surely must be some major incompatibilities that allowed this library to do something fundamentally different, right?

I had to use ffmpeg from within python once and gave ffmpeg-python a shot. It works very nicely for a lot of things, but had some limitations that made me write a very lightweight, somewhat OO wrapper around ffmpeg filters. Using it to e.g. generate a silent colored screen with text on it looks something like this: https://gist.github.com/Felk/975c096083e8434a8b5823173f8b22f...

Are there already existing, more polished wrappers around ffmpeg that include enough escape hatches to be able to fully leverage everything ffmpeg supports? I probably just didn't search and evaluate options long enough.

Is that a freudian typo?

If you're into reading C code, you could probably check how git's `git log --graph` is implemented: https://github.com/git/git/blob/master/graph.c

A tool that lets me do code reviews, but like really good and integrated. I use gitlab on a daily basis, but it's painstakingly slow and basically just lets me stare at text. Some of the below features may be available, but not satisfactory in my opinion:

- I want to see the changes in a directory tree that I can navigate through!

- I want to comment on any piece of code, not only changes and their surroundings!

- I want to hide things, or mark them as "seen", to be able to look at things in the order I want without any risk of losing progress!

- I want to be able to filter/sort by the "change type", e.g. Imports, renames, indentation changes etc.!

- I want the diff to be aware of programming semantics, e.g. know when a function just moved from one file to another, or I add a method overload and don't get a diff telling me I added a closing bracket and another whole method signature in the middle of the old method!

- Let me type code! I want to try out and propose changes!

- I want freedom editing my review before submitting it the way I have freedom editing my branches before committing it!

- I want to have single comments refer to ranges of changes, which aren't necessarily connected or in the same file!

- I want to easily see what happened to the changes since I reviewed them! (Not a clickable link "changed since then bla bla", show me right there!).

- And probably most important: It has to be fast! Hyperbole: Having to wait for the page to load for a minute for large diffs, and then having to wait another minute for all changes to _actually_ be visible is a no-go.

The available tooling is already very powerful, but it still frequently fails me and I believe having this be extremely polished would be a real productivity game changer. Maybe there are already some great tools? Last time I had to look over a huge amount of changes I resorted to a patch file; grepping away unnecessary changes like package renames etc and just deleting text lines I considered sufficiently reviewed.

but why would it work with a revealed password then? and why would typing one of those characters, hiding the password and then typing anything else clear the entire password? I'd really like to know what the heck is happening here

I suppose they count the whole transaction as malicious if one party acts fraudulently

Which works if you either expect a dictionary with a predefined set of fields (which isn't really a dictionary then), or parse your xml in a way that handles arbitrary tags. For a generic dictionary the shown approach is still the way to go, if you really want to use XML for that.

Oh wow, I click on stuff and it just loads another boring html page in a few milliseconds. One request, 4-10KB HTML, and it's absolutely beautiful. It really speaks volumes when a website deliberately sticking to over 20 years old technology is a poster child for great UX.

Also small sidenote: Does it not properly sign the PGP test mails for anyone else?

There are cases where I very much prefer a declarative style. Multiplying matrices for example. Depending on the context, I will know what it does conceptually, but don't want to see the implementation, as it probably won't matter. My rule of thumb is: are you doing something unexpected ? show the implementation : show the concept

I don't know the reasons behind that policy, but I'd guess with the exploit already being used, there is less incentive to keep silent about the issue. The opposite is true: putting more pressure on the vendors to provide patches, and disclosing any malicious actions that are already underway as soon as possible