If you're an US citizen, I would understand why. If you're from elsewhere, looking at how both countries deal with foreign policies, perhaps the answer requires some serious reflection.
That would be really helpful. At the company I'm working for, we are transitioning to Keycloak, and one question that I have no answer for yet is how to standardize deployments across environments. Ideally, I would love to apply DevOps best practices, and try to script the provisioning of as many components as I can (clients, flows, etc.), avoiding config drift between environments. The only solution I found out for now is configuring the realm as I like and exporting it into JSON through the admin UI, placing the resulting file in the appropriate directory, and supplying the --import-realm flag at startup. That seems very fragile.
Here's another interesting excerpt, from Neil Postman's "Amusing ourselves to death":
As Huxley remarked in Brave New World Revisited, the civil libertarians and rationalists who are ever on the alert to oppose tyranny "failed to take into account man's almost infinite appetite for distractions." In 1984, Huxley added, people are controlled by inflicting pain. In Brave New World, they are controlled by inflicting pleasure. In short, Orwell feared that what we hate will ruin us. Huxley feared that what we love will ruin us.
This book is about the possibility that Huxley, not Orwell, was right.
The book was released on 1985, and its main premise is that the mass-media has a damaging effect in our capacities to understand and elaborate rational arguments. In his opinion, TV was their age soma. I wonder what he would think today...
Lambda scales well... until it does not. If your traffic pattern is very spiky and unpredictable, the burst limit can be a real pain in the neck. It ranges between 500 and 3.000 Lambda instances, depending on the region, and when that threshold is reached it can only spin up 500 more each minute. This is sufficient in most cases, indeed, but it's important to be aware of the implications of this limitation before believing that you can throw anything at Lambda and it'll just scale up to accommodate any workload.
Just look for another job, don't even waste a single second of your life considering that offer.
I worked for a company that would allow us working from home some days a week, and we even had some remote colleagues. At some point, our manager made us install one of those applications, which denoted he didn't trust us anymore. The app worked exactly as you say, and it was frustrating and infuriating at the same time. It would "measure" your productivity based on the mouse and keyboard activity, giving ridiculous results like a 20% or 30% of effective time worked. Surely a monkey banging on the keyboard would have a much better score, but that's not what developers get paid for. Not only so, but I had the perception that the app had a special preference for taking screenshots when I was on Slack or writing an email, which feels like an utter violation of privacy. Obviously, most of us either left the company or refused to use the tracking software.
Be conscious of the value you can provide and look for someone that judges your work by your output, not by the number of keystrokes you do a day.
Please elaborate. I'm not questioning what you say is true, but I'm interested in a tool like this one and would love to know more before choosing one or another.
A strictly typed pure functional language that generates JavaScript. That, along with a clever compiler, makes them claim that apps built with Elm don't have runtime exceptions.
The recipients did however report “less stress symptoms as well as less difficulties to concentrate and less health problems than the control group,” said Minna Ylikanno, lead researcher at Kela. “They were also more confident in their future and in their ability to influence societal issues.”
It did help people be healthier and happier though, but the headline only points out that they're still unemployed. We must be doing something really wrong as a society when we treat jobs as an end, rather than a means.
Yes, once you get used to the development environment, coding Serverless is pretty smooth. However, when you need something a bit more convoluted than executing a single function, but rather orchestrating a bunch of them across different services, you have to think about stuff like service discovery. Making the right decisions and designing an event driven architecture is going to take time, which is worth money that could pay a lot of servers. With Serverless you get scalability almost for free, but there are trade-offs, so the first you should ask yourself if you're really going to need that scalability or would rather getting to market quicker. In some cases it makes more sense going for Serverless straight away, in some others just using the web framework you're experienced with and in some others a combination of both.
Rails is a great framework that prevents you from dealing with a lot of boilerplate when it comes to web applications and to focus only on the business logic. There are some great platforms out there (Heroku, for example) that deal with most of the stuff you mentioned (logs, tracing, autoscaling, etc.), and no one prevents you from using a third party service for auth in Rails as well (Auth0, for example). FaaS is awesome, but you've got to code a lot of stuff that Rails gives you for free. Besides, pushing some logic down to infrastructure locks you in the provider you chose. I'm not saying that's bad, because as I've mentioned before I run some apps fully Serverless in AWS, but there's some stuff you've got to take into consideration.
For the large majority of CRUD apps the least cost you should be concerned about is hosting, but development time. This kind of architecture adds an extra layer of complexity that is trivially solved with most of the web frameworks out there. I love Serverless, which I chose to design and build a couple of applications, but for some use cases it might not be the best solution.