hvidgaard

The old version yes - but it has gotten worse and worse over the years unfortunately.

If tech heads valued convenience enough we would see some solutions in the space. Instead they spend their free spare time on a million other things - and that is okay. But they really shouldn't be surprised when non tech people use Discord over IRC, or even when young techies do to work on other things they find more interesting.

Developers are in fact a cog in the machine. They do not define or even have possibility to define the overall process that should counter this. Some times they don't even know the scope of the use of what they are working on. That is squarely on management, and that is also why management should be responsible for a failure like this if they didn't put a reasonable process in place.

The reason for this is quite simply because it's impossible to develop bug free code. The process needs to reflect this, and if it doesn't it's not the individual developers fault.

The only place there is a failure here is on the management level on both sides.

Any kind of certification in this space have you have the following for developing core functionality regarding financial data:

* Proper definition of hard requirements and acceptance tests. * Developers have to develop and write tests against this specification. * Another developer have to perform a review and sign off that this code indeed lives up to this specification. * QA will run tests that verify the specification is met, and sign off that it met specification.

That is a PM/PO that have responsibility for the specification. At least two developers and a QA person that have verified that the specification was met. A bug like this only goes live due to impossible to meet deadline or incompetency on multiple levels.

The only remotely acceptable explanation would be that this is the result of some really weird edge case or possibly race condition. But in that case we're back to incompetency, since no experienced developers should design financial software without well known patterns and technologies for the core of the application.

In this particular domain there is zero excuse for a bug like this.

We cannot let anecdotal evidence dictate anything. You're free to not get the vaccine, but at large we cannot base any recommendations on "I know someone that ..." stories.

Most of the western world has free health care and people report any small sign of unexpected side effects and they do count in this statistic. An especially during this pandemic people have been very good at contacting their doctor with adverse side effects.

This is not new to social media, but it has made it pervasive.

I think one of the things that "old school" people completely miss, is convenience. Your examples of Discord and Dropbox are two very good examples of that. They just work. They work on workstation and mobile devices alike. I totally get why people choose that.

I think the sad thing is that the free tools could be close to that and with careful open standard planning, it could even have for-profit companies participating. Email is one such example. Chat and screen sharing should have been another.

There is two sides to Netflix. One is the content side, which is much like HBO, and the other side is the infrastructure side, which without a doubt is a tech company. They could contract out their infrastructure and they would surely not be a tech company, but as long as they develop that, they are a tech company in my book.

That is a really clever solution.

Considering that some cars can change how much the wheels turn based on the speed you're driving, we know it must have been approved for road use.

If you are unable to recite 7x6 and reach for the calculator for it, I don't think many people will memorize it.

I did the same, up to 20. I've used it so much since then that even though it seemed silly at the time of learning, it has proved that my total time saved is far greater than the time spend memorizing it. It helps that I went to STEM for university and in general are interested in it. But I'd say over a lifetime average Joe/Jane that handle a normal persons finances will at some point have saved more time than spend learning it.

We're at a point where you can have your coins on a hardware wallet, and have a simple route into an proper exchange with the possibility to pay fiat to your bank account. Documenting this and updating it yearly is not that much extra work if you really believe in it. Every year, practice the process with your wife/sibling/whoever and 10$ so they are accustomed to it.

It's work, but you are running your own bank.

That is quite a odd failure. Have you by any chance done some research on why it happened?

Quite the opposite for me. As a child I grew up in a "small" town of 30-40.000 I think, I would go to the store to see what was new including computers, I would swing by the local cinema to see what was coming. I don't recall advertising was in paid newspapers either. I would know about books from the library. It was far less advertisement driven and all about reputation and recommendations from experts, professionals and store owners.

Before advertising was as widespread and exploited as it is today, people build businesses around service, quality, worth of mouth and recommendations. That resulted in some truly great things, and it seems that with advertising we've lost a lot of that. Ultimately it's probably to do with people being cheap and advertisements just exploit that.

At least for me personally, it has come to the point where I don't believe advertisements anymore.

True, I was thinking about density. Unfortunately weight to size for an EV is complicated and more weight is not good.

It's cheaper but with less capacity, so I guess it's alright for the second car that is strictly used for commuting.

It's because they value short term gain over long term gain and stability. I see it all the time in software development too.

Nice straw man. But I'll go with it for no other reason that I hope no one believes in that absurdity as an argument against planning for component supply issues. Issues that businesses have experienced time and time again since we began mass producing transistors.

That is because it's a utility that source power from several producers. The risk of no power what so ever for a prolonged time is not something to even be considered. Should that happen, society as we know it is probably at risk and my job is no longer important at all. Oh, and someone actually do plan for intermittent power delivery failure including having two different outside sources for power, a battery backup and diesel generators, data centers come to mind.

If you're that dependent on components that there is no replacement for, then perhaps buy enough stock to last you through a redesign and recertification is in order. Having a contingency plan for such scenarios seems like a no brainer.

That is all well and good until the day you need to it to return two different results depending on which context its running in.

Relying on fixed global state is asking for trouble down the line if it's something that will be evolved over time. DI makes such changes possible because you're injecting it with the constructors, while still allowing you to have a singleton DB managing class today.

Another major benefit for long term maintainability is the ability to see _all_ dependencies in the single constructor. It certainly makes writing tests simpler from unit tests to in memory integration tests.

Docker has become synonymous with OCI images, and my comment was exactly in that context (or at least state of mind) - I should have stated that as well.

Docker can be considered a deployment tool. You package your application in an image and run said image. Development and test of that application does not have to be in a docker image.

I usually propose a rather simple, albeit not cheap, experiment for this.

1. Find a sufficiently large "shallow" body of water. 2. Build a number a number of masts/poles in a straight line, all with an identical height over the water.

Now when standing at the shore and looking at the masts I predicts one of two things.

a. you can see all masts in their entirety with a telescope, or b. you can see less and less of the masts the further away they are.

There are actual places with power lines that satisfy this requirement. For b. you can use high school math to reason about the curvature needed to explain the results. There is no such sound logic (to my knowledge) explaining this for a flat surface.

Not the comment you replied to, but the parent comment.

I agree with what you said, but I wanted to put in the context of what I wrote. Unless your windows and doors have actual anti burglar features, the lock doesn't matter at all. A large screwdriver is often enough to force a window open and a pry bar will make short work of a door. Not until those have been properly secured does the lock matter. And according to some insurance companies in Denmark, thieves does not pick locks anyway. They use a method of force.

For the majority of applications, locks are for "keeping honest people honest". With the right tools most locks take seconds to circumvent, think breaking a window, cutting the steel, drilling out the lock. For situations where it actually matters, professionals know to secure elsewhere before the actual lock is considered.

Of course it's simple to do for every app. But they have to keep that database updated. Either by running a service and listening to all changes to the file system or by running it from scratch every so often. Neither is a good idea from a performance point of view.

I can see where you're coming from with the false start if looking at it from that isolated point of view. I see it more as the first step to storing data, in general, in an RDBMS and once applications start to utilize that, new use cases will start to emerge. Linux in particular with it's "everything is a file" philosophy seems to suited to use this model. A table for processes, files, network connections, ect.

You don't need the relational aspect per se, but if you have indexes by filename, filetype, creation date and size (which I do not find unreasonable). It becomes trivially fast to ask the question:

> Give me all image files > 100 KiB from 31. December 2021 to 1. January 2022

While in current file systems you need to scan the entire content of file metadata to get that information. It will take a long time, especially if you have a lot of small files (think Windows C: drive).

That might not be something the average user would do by themselves, but developers of, say, image processing apps certainly would.

I would see it more as a different and better way to store the same and additional information. In a RDBMS an index is already storing references in a tree format. If you map that to files and folders you now have basically the same thing as a file system.

Doing it more as a DB enables the OS to use the knowledge from RDBMS for efficiency, which I'm sure rivals the best file systems and it's possible to create multiple indexes and views for other use cases.

Our current view on file systems and the knowledge we have is heavily influenced by slow spinning disks, while RDBMS have leveraged RAM a lot more. With todays fast SSDs the file system operates in a reality that is more like RAM than a slow spinning disk.

The Russians cold war era rockets was so far ahead of anything USA produced that old rockets from that time is still being bought up used today.