The subject of the book is how those three laws are fallible. In almost every story, something goes wrong with a robot that causes a big issue but doesn’t violate the three laws.
Don't forget to add "A robot shall not access unlimited means of self-reproduction" and "A robot shall be able to explain the basis for its decisions and actions".
For AWS, as with many cloud offerings, read the pricing small print: AWS Secret Manager also charges per API request [1]. It isn't expensive, but you should keep it in mind when you architect your infrastructure. (We actually switched from fetching secrets at runtime to injecting them into containers are deploy time, and this was one reason).
This bit us too. We use goodaddy's external secrets [1] to fetch secrets from AWS secrets manager and make them available to the cluster. It polls the secret every n seconds, but with many services consuming secrets, it can scale up pretty quickly and start to build up cost.
Sorry the pricing is unclear. In Secret Manager, secrets are versioned (a "secret" is a named collection of "secret versions"). We only charge for active secret versions (you can destroy secret versions, usually after a rotation operation).
The secret version contains that actual secret data (i.e. "ABCD1234"), and you can choose the regions in which you want that secret data replicated. Each region you choose is $0.06.
So if you had 1 secret with 12 versions stored in 2 regions, that would be 12 x 2 x $0.06/mo = $1.44. Hope that helps!
EDIT: replaced "*" with "x" in math because it was getting parsed as italics
Seems more comparable to parameter store, which comes in both a paid and "free" version. Secrets Manager does have some of the same capabilities, but it also extends it to things like short lived credentials.
That’s nonsense and magical thinking. Sanskrit is a language like any other. Latin meanings haven’t changed for a long time because it’s a dead language but they certainly changed while it was being actively used. Sanskrit is certainly similar.
Having a phonemic orthography does not stop changes in meaning.
As an aside, if the language is living rather than dead a phonemic orthography doesn't prevent change to spelling and pronunciation either, you just get extra alternative spellings and pronunciations, rather than divergent spelling and pronunciation.
Simply not true. Vedic Sanskrit is quite different from classical Sanskrit. If you track the meaning of individual terms across texts from different eras - even famous ones like 'Dharma'- you'll notice that Sanskrit words are polysemic and have changed in meaning.
> what you speak is what you write and what you write is what you speak
I am not a Sanskrit scholar by any means, but IMO, being phonetic is not necessarily the reason for that. It is more so because Sanskrit words are often derived from a small set of root words. In other words, the words are actually descriptions of things using smaller components. In this case, the root is Bha which means "to be" or "to exist", from which there are words derived such as Bhavatu - "so be it", Bhavita - "existed", Bhavana - "place of existence/dwelling".
That is amazing. I've only used english and a touch of spanish, and those words are so slippery. Even latin has a drift over time. i've poked at Aramaic, but never more than a week or two of half hearted effort.
I'm really interested in Sanskrit now. Perhaps 5 years of concentrated effort to access thousands of years of writing sounds amazing. I have a hard time with Twain, much less Chaucer. English slips so much, so quickly.
I suppose there really aren't puns or double entendres though. I can't imagine how semantics would survive the abuse of irony for thousands of years.
Just wondering: Why not simply share your https://cv.me/ link (or any similar) instead of a link to your resume document. Makes it easier for HR to scan.
It's a recurring theme: Media outlets publish whatever they 'want' to believe with little due diligence and the product makers have to scramble to put up clarifiers.
Media outlets certainly do that, but can't product makers sue them for damages, when they publish false information that can tank a stock or kill a company's sales?
Usually not. To prove libel you have to prove: 1. the information is false, 2. The speaker knew it was false, 3. The speaker spread the false information with the intent to harm the plantiff. Without all three it isn't libel in the US.
WE are heavy users of AWS. SQS is the only service where we have had zero downtime. The only downside we have about SQS is you can pull out only 10 messages at a time (without batching). You can have parallel readers but they result in some duplicates. There is SQS FIFO but it is throttled.
It went down on us once for extended period in 2015. It was chaotic as you don't expect it to fail. If memory serves me right, even S3 suffered that day.
A whole slew of AWS services went down that day. Tim's not wrong when he indicates that almost every service in AWS has a dependency on it (Amazon has services split up in to tiers based on how much they can rely on other services for critical components, SQS is pretty high up in the tiering.)
I was on-call that day for an AWS service. There wasn't much I could do but sit muted on the conference call and watch some TV, waiting for the outage to be over.
TLDR: The huge bill was a result of an improper way the application was coded. They contacted Google/Firebase who were gracious enough to waive off the bill.
You can, cloudwatch can shut things down on reaching threshold or scale-down.
With cloud you really have to optimize your code/architecture as you pay for what you use.
With your own servers that is not an issue unless you overload them, then you can have an outage.
EDIT: I thought Firebase is amazon for some reason, it is not. So in general Google panel doesn't have that functionality (from my experience with it), they have billing alerts but I never saw anything that would shut off things on reaching that alert.
You can limit by API requests usually but not by credit amount so if you use multitude of API's it can get tricky and they likely didn't limit anything.
That's very nice of them. However I'd have to read all of firebase's small print before i would consider using it.
Does their SLA guarantee data availability even if google dcide to spin it off or sunset the way they did with google+, reader and such?
Does it matter what their fine print says if you have to bang your head against a buggy automated bot process to get support things done? Switched over to MS appcenter recently(they added support for cosmosdb + authentication). Their customer care is so nice by comparison
Former Firebase PM: firebase.google.com/terms has all the details.
TL;DR: minimum 1 year deprecation policy, and you've got access to the data at any time (e.g. do a backup and get everything as JSON, or download an entire store bucket and transfer it to S3).
Glad to hear that Google has done something with it.
Also that's one of the reasons I try to use the realtime database, and not firestore. But they still charge for bandwidth there (most if it is consumed by downloading the SSL certificates from the clients).
This must be the first time I hear about Google responding timely and adequately to a specific problem of a customer. Could the publicity have something to do with it?
More likely because google responds timely and adequately to customers all the time but nobody tweets about it or writes a medium post that gets shared.
Their report reads like they had it coming big time:
> The app was running, all the supporters were able to support and the comments on social networks were that the app made it really simple to do support. We were very proud :)
> We didn’t want to release any new feature with that many users on the site, so we decided to merge a version with Angular V.6 […]. The site started to load slower, for some users it took them more than 30 seconds to load the page. That was weird. Our team was not comfortable with that and we couldn’t understand what was causing it and now we had our code with a completly new version of Angular, and probably many other bugs in production.
Am I reading this right: Their site was running well. They didn’t want to interrupt it by adding new features (potential bugs) so they casually update the framework and push the new version of their website to production hastily? And instead of rolling back the release they double down and optimize their code without knowing the source of the slowdown. Like WTF? Apparently they hadn’t even opened the browser’s network console to check if/what requests cause the slowdown. How did these people get $25K grant money?
Rgerding grant money post says: NXTP Labs acceleration program - so venture capital basically.
Looks like incompetence really, using a framework and unable to pinpoint the bottleneck and deciding that maybe upgrading version will somehow fix their bad code.
Not a completely pointless idea as framework might indeed have been changed enough to force them into using itself correctly, but still lot of questions.
I see. Thanks. Hadn't realised theres a link to the actual post-mortem. I thought that part was underlined for emphasis.
Really should've just linked to that hackernoon post though IMO, contains a lot more details thats very helpful in understanding what actually happened.
1. Be fair to your company. They are paying you to make their product succeed. Imagine a future situation where you are running a succesful company. Would you want your employees taking your money while working on their own pet projects?
2. An hour or two every day and code marathons on weekends can get your a basic version of product out in a few months.
3. Never give in to temptation to steal office hours to work on your project.
Re 1: put yourself first when it comes to careers. As long as you are putting in the required number of hours (physically and mentally) at your employer, there's nothing wrong with spending your free time on your own projects.
> 1. Be fair to your company. They are paying you to make their product succeed. Imagine a future situation where you are running a succesful company. Would you want your employees taking your money while working on their own pet projects?
On this point in particular, if you're doing pet project work outside of working hours, then your employer should have absolutely no say on what you're doing. You wouldn't have them manage your hobbies, your social life or your dating life, that would be unreasonable, same goes for side projects.
1. Why would the company care what he does in his free time? Assuming he is not using company IP or working on company time, it should be completely up to him.
Sure, the company will not want him to suddenly leave to launch his company, but the way to combat that is by making the position more attractive, and screening for it when hiring.
The American view on labour seems quite similar to slavery.
The simple answer is that the employer needs a clear picture of what they own.
Let’s say you’re a scientist. Your employer sets you up in a lab (that you could never afford on your own) and gives you the task of solving a problem that, if solved, would be worth millions to the company. One night you go home thinking about the tough problem. The next morning at home you have a shower and suddenly you realize the solution!
Who owns the solution? Did you solve it by yourself? Can you now take the solution and launch your own company? If the company puts itself up for sale can they claim ownership of the solution?
This is why in the U.S. these “the company owns everything while you’re our employee” clauses exist. Consider them legal laziness: It’s easier to declare ownership of everything than it is to negotiate with every employee over who owns what under what circumstance.
Edit: These clauses are enough to take to trial. At the very least a deep-pocketed employer can scare off investors from investing in the employee.
Clearly anything related to company IP belongs to the company, even if you come up with it in the evening.
I am of course talking about innovations or just work done in unrelated areas, while employed.
The idea that an employer owns everything you create is offensive to human dignity and happily that is not how it works in Europe.
You are even encouraged to start your own company, in some countries you have a legally enshrined right to take a LOA for six months and work on your business, and then come back to your old employer.
I do not think the issue here is (1) to be fair to the employer, to take the employer's money (the money I earn while working is my money), (2) to find personal time or to (3) steal office hours.
The problem is that the employer pretends to own all Intellectual Properties produced by the employee while in contract. Be it during code marathons, night hours, week-end time...
I used to have a contract of that kind, and I found another job to keep ownership of my weekend pet projects.
