You or the developer could piggy back on “aws configure export-credentials --profile profile-name —-format process” to support any authentication that the CLI supports.
The AWS APIs are quite stable and usually do exactly one thing. It’s hard to really see much risk. The worst case seems to be that the API returns a new enum value and the code misinterprets it rather than showing an error message.
I wonder if you could pay them to tweak the messaging about your products. So when a user asks: Is drinking Coke everyday good for my health, it starts saying yes because sugar is vital to our survival.
I couldn’t find a library like this in PHP, but realized for my use case I could easily hack something together. Algorithm is simply:
- trim off all trailing delimiters: },"
- then add on a fixed suffix: "]}
- then try parsing as a standard json. Ignore results if fails to parse.
This works since the schema I’m parsing had a fairly simple structure where everything of interest was at a specific depth in the hierarchy and values were all strings.
If I’m not mistaken, even JSON couldn’t be parsed by a regex due to the recursive nature of nested objects.
But in general we aren’t trying to parse arbitrary documents, we are trying to parse a document with a somewhat-known schema. In this sense, we can parse them so long as the input matches the schema we implicitly assumed.
The parent is making a philosophical argument. The exact Hollywood definitions aren’t important since there are far many more job roles in film production compared to software development. If you insist though just replace creator with producer in his original argument and it’s the same - you can produce a movie without doing the acting yourself.
Naively it seems difficult to decrease the ratio of 1.8x while simultaneously increasing availability. The less duplication, the greater risk of data loss if an AZ goes down? (I thought AWS promises you have a complete independent copy in all 3 AZs though?)
To me though the idea that to read like a single 16MB chunk you need to actually read like 4MB of data from 5 different hard drives and that this is faster is baffling.
RAID doesn’t exactly make writes faster, it can actually be slower. Depends on if you are using RAID for mirroring or sharding. When you mirror, writes are slower since you have to write to all disks.
I think they are solving two different problems at the same time. One is the order of elements in a single operation (SELECT then FROM then WHERE etc), and the second is the actual pipelining which replaces the need for nested queries.
It does seem like the former could be solved by just loosening up the grammar to allow you to specify things in any order. Eg this seems perfectly unambiguous:
from customer
group by c_custkey
select c_custkey, count(*) as count_of_customers
Space-wise, as long as you compress it, it's not going to make any difference. I suspect a JSON parser is a bit slower than a CSV parser, but the slight extra CPU usage is probably worth the benefits that come with JSON.
“I'm planning on migrating the build system on Wednesday (26th); please let me know if you have any concerns.”
The original wording makes it sound like it's already been settled, so nobody will bother responding. But by saying planning, you might get some feedback.