acidbaseextract

For example, if you want to index a "foreign key" id stored in each "record" in a JSON array of objects, you build a hash table from the FK id values to the JSON array indices of the objects that have that id. It can be as stupid simple as an `fk_index = defaultdict(set)` somewhere in your program, to use a Pythonism.

Now when someone wants JSON objects in that array matching a given FK id, they can just O(1) look in the index to know the position of records that match. Much better than an O(N) scan of every item in the array.

Of course you have to to maintain the index as writes to the JSON happen, but that's not bad once you understand how things work. No real secret sauce.

Thank you for including this tidbit. I'm a man in my early 30s interested in having kids and recently discovered that I've poorly vetted my 5+ year SO's interest in having kids. Her "yeah, I'm hypothetically interested" has become "hard not interested".

The requirement to break up with her if I want kids is deeply painful, but the real source of my dread is the feeling that I won't then be able to find someone good in time. I'm very glad you found someone good to have a family with.

unexpected null/undefined values

This is an issue and has led to bugs. Switching to TS and making the compiler flag them fixed it.

mistyping variable or attribute names

Not an issue. Code obviously breaks if you have incorrect names.

using the wrong number of equal signs

This is an issue but causes few bugs. Linting generally catches it, though cute boolean punning still bites us.

failing to catch errors and handle rejected promises, etc.

This is an issue and has led to bugs.

Pretty much anything where there's some implicit details that the compiler or linters can't reason about programmers find a way to get wrong. One thing I like about the hooks linter setup is that what it encourages you to do by default will prevent most bugs, only lead to potential performance issues, unnecessary rerenders, unnecessary refetches.

[1] https://twitter.com/dan_abramov/status/1104414469629898754

I don't want to be dismissive, but I hate deploying my applications for this reason. I'm an application developer. I'm not averse to infrastructure as code, and containerization, and I'm happy to do ops for my preferred stack. But I can't learn all this stuff too.

Apple ultimately went with the NeXT / Steve Jobs combo, quite wisely, but for a long time there was a whole gang of BeOS fanboys lamenting that decision.

It feels like "put the template in the query" is a great Uno reverse to "put the query in the template" and the associated issues it brings, but I'll have to think on the consequences more. Thought provoking article!

I've had one or two fundamental version conflicts with a 5+ year old application with 100+ dependencies and a decent amount of legacy stuff. They were a pain in the ass, and the sdispater's stance on not allowing overrides is a pain in the ass. We ended up forking the upstream libraries to resolve the version conflict.

With all of that, poetry is amazing and a huge step forward. I'd advocate it wholeheartedly.

In a GraphQL API, tools such as Dataloader allow you to batch and cache database calls. But in some cases, even this [isn't] enough and the only solution is to block queries by calculating a maximum execution cost or query [depth]. And any of these solutions will depend on the library you’re using.

For those who wondered: Accelerated Expertise: Training for High Proficiency in a Complex World

https://www.goodreads.com/book/show/17399473-accelerated-exp...

But yes, consider alternatives before you pick asyncio as your approach!

Talk: https://www.youtube.com/watch?v=oLkfnc_UMcE

Blog post: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

[1] https://www.youtube.com/watch?v=fGG9dApIhDU

It seems like an identity confusion issue where the VDOM diff is ambiguous, and React resolves it in the "wrong" way. Adding keys to each `LabeledInput` resolves the issue, but I'm surprised that the runtime doesn't complain when you create the inputs without keys.

I wonder if this is why the checkbox that's checked moves, but stays in the same relative position (the second checkbox in the list): https://medium.com/@ryardley/react-hooks-not-magic-just-arra... or if it's just the ambiguous VDOM diff causing that.

I'd be curious about the performance of these. A time series featurization library I've liked the look of but haven't used for real is catch22: https://github.com/chlubba/catch22

In particular I like catch22's methodology:

catch22 is a collection of 22 time-series [that are] are a high-performing subset of the over 7000 features in hctsa. Features were selected based on their classification performance across a collection of 93 real-world time-series classification problems...

If it were my business or my team I would want an ML Engineer to relentlessly knock down any barriers to getting models into production.

My favorite is when they knock down the question of whether a certain project even needs ML to focus on getting ML into production.

Many teams fail at ML because there was an essential task that nobody wanted to do that didn't get done.

Many teams fail at ML because there was a task that didn't need ML (or at least anything more than a linear model) that is made opaque to anyone but an ML engineer after they implement it.

https://github.com/datamade/usaddress - "usaddress is a Python library for parsing unstructured address strings into address components, using advanced NLP methods."

https://github.com/datamade/probablepeople - "probablepeople is a python library for parsing unstructured romanized name or company strings into components, using advanced NLP methods."