sparsely

I didn't realise how precise the reflections from retro-reflective materials were. I'd always just thought they were for high vis gear, cool to see such a creative use for them here!

They absolutely love adding them to previously functional systems even so!

The biggest issue IMO is that the safety standards more or less only seem to account for the driver/passengers. The EU equivalent has a pedestrian safety rating, that would be a good start.

It's vastly better than previous iterations on the same idea. Some (e.g. Airtable) are much better than others, perhaps because they have a clearer niche. Others are useful but drive you straight into a swamp called Technical Debt (retool). I don't think they represent a paradigm shift, more an iterative improvement on existing tools.

> Or when I find a really nice Node.js library that Just Works™.

This happens to me all the time. Every day really, whenever I type `npm install` I'm just delighted by the results. Those node libraries just make my programming experience so smooth and carefree, just like Apple products.

The result is that everything will look and feel slightly off, as the recreation of native elements will never be quite perfect.

> Some of the stats say property crime is actually down in San Francisco, but that is probably a reporting issue, because some store managers have stopped bothering to waste their time filing police complaints.

Seems like these stats could have done with a more rigorous investigation, given that they contradict the thesis of the article?

The payroll, taxes, and labour laws are a big barrier at the moment. Even if you are happy hiring someone as an independent contractor to simplify the first two, how do you know that you aren't breaking local laws, e.g. about disguised employment? You still have to be familiar with local laws and regulations.

It seems like something that an intermediary could help with, and a few do exist, although they are pricey.

Simplification of regulations into a standard framework (without weakening them) would be a huge win here but I can't imagine that happening anytime soon, even in the EU, as labour laws are so sensitive.

> Unlike SQL, which can only manipulate normalized data, JSONiq natively works on the entire normalization spectrum: textual, heterogeneous, deeply nested

Maybe I'm misunderstanding something, but isn't SQL perfectly capable of acting on denormalized data? We often talk about the degree of normalization that a RDMS has. Perhaps this is in reference to nested data structures (which would normally be represented in RDMS via FK relations), but even there it's implementation dependent.

Neither of the suggestions for avoiding nested Lambdas seem very satisfactory - the situation described there is one which would make me consider if Lambdas were actually a good fit for my problem.

I gave up carting my webcam and stuff around with me - in 90% of zoom meetings it makes essentially no difference. I'm sure there's some specific scenario where Zoom will send actual HD video but they're pretty rare.

Cool idea, the numbers in this blog post are very much a worst case scenario outside of running the entire process on 1080 GPU or something though

MSSQL comes with (very nice) temporal table support out of the box, if you can stomach the license fees.

"using green power" vs "using coal power" has a similar impact on at least some actions (e.g. mining bitcoin)

There are various Kafka to Postgres adaptors. Of course, now you're running 3 bits of software, with 3 bottlenecks, instead of just 1.

I've also had much more success with "queues in postgres" than "queues in kafka". I'm sure the use cases exist where kafka works better, but you have to architect it so carefully, and there are so many ways to trip up. Whereas most of your team probably already understands a RDMS and you're probably already running one reliably.

Having just turned 30, this is a topic on increasing interest to me. I'd love to know what HN posters who are over 35 and were devs when younger are doing now?

I think in this case the surface interaction effects with the nanotube are likely to be much bigger

I think the OP's point was that it forces you to do all the number crunching via those extensions, and if what you want to do doesn't match up with their APIs it's a bit of a pain. Granted, they have fairly complete and flexible APIs but I can still imagine it being very annoying sometimes.

Well, he no longer has to maintain it, and an even better version of the feature now exists

> So far, most analyses show very little job growth differentials between US states that terminated subsidies vs those that didn’t1. That said, some forecasts call for 1.3 million new jobs by year-end due to expiring unemployment benefits and another 300,000 new jobs due to school reopening

"The evidence so far contradicts these forecasts, nevertheless..."

> No, in trunk-based development, you push to the trunk, aka master.

If you follow the ops link there are multiple diagrams where that is not the case.

If that's fairly common it doesn't seem like a great setup? Why not automatically run the tests beforehand?

And presumably there is no need for a staging env, since your code is deployed to production as soon as it has passed tests.

This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in (their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?)

The replies seem to suggest that there are a mix of interpretations, it's very confusing.

> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members.

I occasionally see statements like this floating around - does he mean:

* Devs make their changes locally, commit and push directly to main, and then the CI/CD either notifies them that tests failed or deploys to prod

or

* Devs make their changes locally, commit and push on a branch, and rapidly (ideally automatically) merge to main if tests pass. This happens on a cycle of minimum coherent set of code changes, not a whole feature at a time or anything like that.

The first seems like it would be very frustrating if code with failing tests if pushed with any frequency, but seems to be literally what the phase "work on main" means. I also don't really see a drawback to the second one in comparison.

Sometimes parallel, rather than async, processing will help there, and it's pretty easy in dotnet with .AsParallel()

This was a really clarifying comment for me, thank you.

It links nicely with the positivists' ideas about meaningful/non meaningful statements as well - which I believe were inspired by Wittgenstein.

I noticed this after commenting, but was a bit confused at first!

Perhaps they could consider reducing their oil and gas production next.