Re: £355m for 5 years!!!!
If current conditions continue to apply the problem will be solved. Cities of present scale will become redundant.
42400 publicly visible posts • joined 16 Jun 2014
In this case you've got to wait for them to make the mistake and have the inevitable result. Originally in CC security actually mattered;. Communications were point-to-point and none of your internet nonsense. Even internally subcontractors had to have secure production networks to handle the data. Now it's cloud.
"This does not sit well with beancounter managers though."
When the need for the spare arrives you visit the beancounter, get them to confirm how much the lack of the production machine is costing per minute and then tell them that their machine is the only one with an appropriate spec to swap in.
A frequent variant of this is trying to communicate with a company whose online "Contact us" is a very limited number of FAQs with no message link, an online chat service which is currently or invariably offline and phone. On phoning before even dropping the customers into an ACD system as limited as the FAQs, they're played a long recording to the effect that they could get in touch via the website.
In a sense it's a race condition but think the logic, if the particular legal system accepts it, is that if the clause is severed it's as if it was never there and if it was never there then it couldn't have invalidated the rest of the contract.
In practice I suppose it would depend on how the contract could function without it; for instance the contract might consist solely of the invalid clause and the severability clause.
"I did suggest that adding a machine-readable data format (JSON) would be helpful on the last project I worked on, but this wasn't taken up as it wasn't common for people to be able to process it."
CSV is also a machine-readable format. The problem isn't having the data in a machine readable format, it's having the machine read it in the right way. People have a machine to read the CSV - it's just the wrong machine. For your JSON you'd also have to provide the machine.
I'm not sure a database is the right application for just passing tabular data around. If this were someone complaining about importing straight text files into Word and getting unwanted auto-corrections you wouldn't tell them to use a desktop publishing application instead would you? You'd tell them to use Notepad. Here's the problem - there isn't the equivalent tell-it-like-it-is equivalent of Notepad for tabular data.
"It's not the tool. It's the choice of tool."
I agree it's the choice of tool. But the correct choice of tool isn't something more complex than a spreadsheet, it's something simpler. The standard PC, whatever the OS, doesn't have it. If it were text you'd have the choice of your word processor or Notepad/Kedit/whatever. For tabular data such as CSV you have a choice of spreadsheet or.
Are they?
Not necessarily. They just want a quick and dirty way of viewing and exchanging tabular text data. Excel is a case of "if you have a hammer...". An RDBMS would make that a sledgehammer. What's needed is something simpler, not something more complex. And I say that as a biologist who changed to become an RDBMS specialist mid-career.
"And excel is a stupid program for any data analysis that is more complex than basic bookkeeping... Ok, that's three problems."
I'm sure there's a much larger set of suitable problems than that. However there are other problems for which it isn't suitable and for which a similarly accessible application doesn't exist.
Some-time biologist who moved into databases here. That's databases as a complete career change. You can keep your emacs but vi is hardwired to the fingers.
Nevertheless a database might not be the right solution here. As soon as you start talking about tabular data and databases in the same breath you start thinking about RDBMS but the time taken to set that up for what might be a one-off is probably not worth it. There's almost certainly a need for a simple way to tabulate data without making too many assumptions about the nature of the data. It's a principle I've observed many times; the more assumptions you make in the design of an application the less capable it becomes.
In this case take on the data as text columns which is probably the most minimal assumption you can make. If you want to flag the column* as date - or anything else - that's the time to let the application reformat the text. If you want to use a database to store the data you can, of course, have the application generate the schema at this point.
* Spot the implied assumption here.
Files get passed around. If you rely on setting the program that opens them to something non-default you come up against the problem of relying on everyone to do that correctly every time otherwise munged files start getting circulated. It's a bit like you rely on everyone to use mv or rm -r correctly in root. Of course nobody ever got the latter wrong did they?
I suppose it's just possible that the lobby was easy to break into but the doors into the rest of the bank were a bit tougher. I suppose it's also possible that the only thing removable from the lobby was the sanitizer. I've come across a few criminals dumb enough for that but not dumb enough to choose sanitizer if cash were available.