davidgf

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.

By any chance, is that Terraform open sourced somewhere? It's for a friend :)

It will always respond "it works on my local machine".

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...

I'm not too sure about that... Just to clarify, I'm referring to the burst limit, not the concurrency one.

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.

Interestingly enough, the .top domain gives what it promises: it's at the top of the worst performing TLDs list

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.

It's in the wiki https://github.com/huginn/huginn/wiki/Agent-Types-&-Descript...

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.

You should check out the Pinephone then: https://www.pine64.org/pinephone/

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.

At least they didn't remove the good stuff in VEVO https://www.youtube.com/watch?v=dQw4w9WgXcQ

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.

AWS SAM is ok, but I encourage you to take a look at Serverless framework https://github.com/serverless/serverless, which eases a lot managing the whole infrastructure. There are already some applications running completely on Lambda + Serverless, such as this one https://github.com/microapps/MoonMail

If I saw your reply before writing mine, I wouldn't have bothered responding :) Absolutely agree with every single word

I wouldn't stop learning new languages. They are just tools, and knowing several of them lets you better judge how to face a new project/problem. I was (in fact, am) a happy Rubyist, but had to start working with Node and learnt to love the beauty of event-driven programming and prototypal inheritance. Now I'm learning Elm, as I'm quite interested in functional programming and event sourcing. I wouldn't say that any language is better that another, but knowing some of them and the principles they are based upon is helping me evolve as a developer and changes the way I code, regardless of the language I choose for a certain project.

Slack! That productivity killer... at least from the point of view of a software developer

Unfortunately not, my opinion is simply based on my personal experience and on what I've been learning along the way. I find promises really handy for data processing pipelines (grab some data and perform some transformations over it to get it in the form you need), regardless of wether any of the steps is async or not. I still find async/await really useful and mix it with promises if I need it, but I prefer to keep my code as functional as I can. Besides, I don't really like how JavaScript handles exceptions and would rather staying away from try/catch if possible

Although async/await is simply syntax sugar around promises, there's a huge difference indeed. With async/await your code keeps an imperative style, while with promises code end up with a functional look

I started using Async/Await and liked it, but I've been learning more about functional programming and went back to Promises

That's right! However, what are the chances of AWS severely increasing fees or shutting down one of those services? Pretty low I guess. Due to Lambda pricing, computing costs are insignificant, and not having to worry about high availability, peak loads, etc., is a priceless advantage.