https://www.plasticexpert.co.uk/how-many-times-can-plastic-b...
Once they know that they can decide for themselves if it’s ok for their take away food container to end up as a park bench at best.
2,818 karma · joined April 7, 2016
https://www.plasticexpert.co.uk/how-many-times-can-plastic-b...
Once they know that they can decide for themselves if it’s ok for their take away food container to end up as a park bench at best.
The article then launches into recommendations about requirements gathering and writing down your thoughts (functional specs anyone?) which kind-of sounds a little bit like the waterfall method to me. I believe the waterfall method has a bad reputation for overengineered and overcomplicated solutions. We have come full circle, again!
No matter the methodology there seems to be this behavior in the industry that as soon as some code does the job, regardless of how terrible it is, it must not be touched again and we must move on. Whether it was over-engineered because of bloated requirements gathering or because it was hacked into some sprint period the end result is the same.
My recommendation is this: Don't discourage people from refactoring code that already works. Good code will survive refactoring or even rewrites.
Anecdotally, I have been impressed by the RFID system the the Decathlon sports store uses. Used it myself and it works a treat. Throw all your items into a bucket, tap your payment card on the normal card machine (or use apple or google pay), collect your stuff and walk out.
The technology isn't even that fancy. Each item has a very cheap radio frequency id tag in it which has a unique number. If that doesn't work there is a handheld barcode scanner (which I've never had to use). A successful payment marks the specific item in a database (probably in-store) so the scanners at the entrance don't set off an alarm when you leave. You don't have to download an app or have an account with anyone. It doesn't need AI, special cameras, weight scales or offshore workers to run.
Here is a random article about it: https://www.nfcw.com/2019/03/19/362056/decathlon-adds-rfid-t...
In a circle around London with distances ranging from 8 to 40 miles from the city. Doesn’t seem that confusing for travellers, just gives them more options.
Increasing Codegen units (multi unit compilation) is just the user taking a risk that splitting things up will not affect performance optimisations. Nothing smart about it.
If you had tiny compilation units and the frontend understood their significance to the backend then it would be able to build a graph of dirty code to be recompiled when a small piece of it changes.
Pc UPS’s are underpowered and the market is so swamped with cheap garbage as the rant suggests that it is difficult to find anything decent.
https://techiescientist.com/does-distilled-water-conduct-ele...
Seems to ring true with a lot of leaders.
Except for those that discover the fork button. /s
In all seriousness I think that what you mean is that people rarely have the power to fork a project and drag all the users and development expertise over to their version. Especially if they are simply users of the system and not contributors. Users of commercial software can get companies to do stuff for them with their wallets.
https://help.ui.com/hc/en-us/articles/12594679474071-Standal...
Tbh, I’ve never understood the appeal of server side blazor. High latency is too risky and you may never know that your clients are experiencing it. This hybrid approach in .net 8 is interesting but for a business app, initial load time is a once off thing and only a few seconds anyway. Kind of like an installer in a way.
I have a few criticisms though. I work almost exclusively on Linux now and it was extremely painful to try get an old .net project up and running because Microsoft aggressively sunset old .net versions. 4 years is not that long ago and I didn’t want to go through the pain of upgrading to the latest to make a few minor changes. So I had to dust off an old pc and use that. I understand that the .net core era was a turbulent time for change so maybe that’s why. But dammit, at least leave the old SDK’s up for a decade for this very reason!
Ironically, the slowest part of the system is the hosted sql server instance that is prohibitively expensive to run at a half decent speed with laughably low volumes of data. What a captured market that is when you can simply spin up a free PostgreSQL instance on the same vm and be done with it.
Anyway, to answer your question. Yes, it can be used in production. This one has 3 production instances and is used by about 30 people on a daily basis.
How about they pull their socks up and use peer to peer technology instead? Messages are asynchronous so they need to be temporarily stored but routing real-time audio and video is a technology problem that they have chosen the expensive way to solve.
I’m newish to embedded software and hardware and I find it difficult but oh so rewarding. Highly recommended.
Not bash the researchers or the quality of their research but I'm unsure if a negative result would have been acceptable to their continued funding. I'm sure P&G would like to use this research to sell their diffusers after all.
The article explains how work-stealing is a way to solve tail latency. I understand tail latency to be caused by tasks that yield (by themselves) after an unexpectedly long amount of time. This cannot be know in advance. The article explains how work-stealing results in cache misses and extra developer constraints like Send, Sync and ‘static.
What if the executor only moves a task to another thread after a timeout period has expired? This should result in no latency penalty if things are running smoothly and a constant, low, extra latency when tasks need to be stolen now and again. This would mitigate cache miss issues but alas not the developer overhead of all those multithreaded constraints.