1,505 karma · joined July 18, 2013
The daycare rules here vary place by place, though. Some of them just check for fever, some don't like running noses.
- Merging was automated (a robot tried to run tests against fresh master and merge only if green).
- Deploy was fully automated and limited to working hours.
- We added tests for problematic parts. For example static analysis for database migrations to prevent only safe actions in an automated fashion.
However, if something goes wrong in some component, you have to revert and stop the deploys for everyone which sucks. I'd say around 8 - 10 deploys per day, it makes sense to start splitting the components or at least not adding new teams to the same monolith.
We have a similar model with Django. We deploy at least four times a day, so it's much easier to just redeploy everything than reason about what needs and what doesn't need to be redeployed.
It's not an exclusive choice either. At least in Europe, the amount of free time grows with each generation. 37.5 hours per week, 5 weeks vacation and many bank holidays is a significant change from how much people worked in the fifties.
Yes, we can do better. But both our wealth and our free time are visibly improving.
Re. finding the sources, a central namespace may still be useful, hence the use of caching proxies.
Vim can be very slow with a ton of plugins.
A modern (or any) IDE, in my opinion, can debug your code, push parts of the editor into REPL (with debugging), understand code for things like autocomplete, linting, quick navigation and usage search. And yes, Vim can serve as a modern IDE if you spend enough time with it.
They say: It has a built-in LiPo and stores your data for up to a year.
It seems to me it's a tool made in AWS by some team close to AWS IAM. My original comment didn't relate that much to Cedar itself. Rather, I tried to express my long held frustration with AWS IAM which Cedar doesn't solve even though it must have costed a lot of effort.
Don't worry too much about it. I'm just a random Internet commenter talking about a topic that's not even mentioned in the original article but tangentially connected.
Imagine I'm a new AWS customer that creates their account, starts an Elastic Beanstalk application and tries to automate deployment via CI. The access key will need some permissions to EB, EC2, S3, maybe RDS, ECR... The best thing I can do at the moment is to expect that an example policy is somewhere in the docs.
In the real case I don't know what context the actions carry that I may use for filtering, I don't know the action names and I may not even know the full list of API calls the tool I use wants to make.
AWS knows (could record) all of the above for me.