This is almost what we do as well. The difference being that we have a API Gateway in front that just invokes the lambda on an internal network, which validates the webhook data and only then does it forward it.
Takes the complexity of having to use a queue out of the equation, though at the expense of potentially lost webhook calls.
Which is fine, and surely an honest mistake. Automation is great, but the way I see it is, how many other projects have been forked and automatically re-licensed, and then profited from without proper attribution? An accident still needs to be flagged, and still needs to be corrected. They also need to be learned from and avoided in the future.
Besides what the other commenters have said, I have 32GB RAM. If Firefox or IntelliJ don't use it, nothing else will. I'd rather have the applications I live in utilise as much memory to make the experience faster and better, than to have unused RAM be wasted. IntelliJ is far superior over VS Code, VIM, etc. IntelliJ is batteries included, whereas VS Code, VIM, and most other editors require additional configurations. Some configurations I've seen have required hours and hours of set up and integration. With IntelliJ on the other hand, it just works. I click run on the main function, and it asks me for the compiler/runtime config the first time round, and afterwards it just fully works. Even running tests is as simply as clicking run from there on.
> The CD community is overly obsessed with velocity.
I think CD is about minimising the amount of code released in one go, which allows you to catch issues much faster and revert issues much quicker. Compare that to something most banks do, release once a quarter, and you'll get stuff like that UK bank that went down for days (can't remember which one it was).
I've yet to meet anyone saying you have to finish your features faster.
Seems odd for PM to be vulnerable by the log4j CVE considering (from what I understand) they're mostly Go house. Maybe in the Android app, but otherwise I'd be surprised.
Unrelated: I've been getting quite frustrated with some of the functionality and limitations of PM especially for the price I pay (I have 2 catch-all domains, 1 user for each, which requires 2 times pro accounts), so recently I've been trying to migrate away to mailbox.org. Mailbox allows for automatic PGP encryption when the emails come in which is great. However, there is no way to move all my PM emails onto my mailbox.org account while keeping the encryption (not via the original key set up in Protonmail, nor via new key set up in mailbox.org). Has anyone ever run into such a scenario, and what can be done in this scenario?
I wish there was a good theme out there that has support for lots of different apps, and has a light and dark theme. Dark themes are great when you're working in the dark, but during the day, when the sun is at its highest, and your brightness is maxed, Dark themes just don't work.
Young Dems mirror the behaviour of Conservatives how exactly?
> They have problems with media and depictions that doesn't fit their worldview and don't favor free speech because it was a value by people that partially rejected their ideas.
This is completely missing the point of what the younger generation want. They don't have problems with media and their depictions. They tend to be more inclusive. They fight for people that haven't had a voice previously, or have been mistreated. What they have problems with is hate speech, not free speech.
So you think they'll send ballistic missiles throughout the whole world? Including China, Russia, UK, Germany, France? All of whom have nukes? Good luck with that.
> A court would have to force Bitcoin users and miners
In case it's not clear, even if the court did this and was able to enforce it, they would still need to enforce it outside of the country too, where, if I'm not mistaken, the majority of miners are.
Sure, but, assuming it's not already blocked by IT, are you going to be sending out a link to your colleagues/students/professor with the name "pornhub" in the URL?
JSON in shell might not be faster (or it might be, I've not benchmarked), but it certainly is more efficient to do select and filter and whatnot using something like jq. It's not about network, it's about making the output more predictable when running a script. I've lost count the number of times I've tried to capture a specific part of the output of a command only to be tripped up by an edge case like spaces or something else.
> Can someone elaborate on why Nomad should be avoided?
The answer is, as always, it depends on your use-case. I'm not personally not a huge fan of Nomad for reasons I won't go into because a) they're irrelevant because opinions, and b) they're probably outdated. However, to say "it isn't much better" is very vague and extremely subjective. I don't really know what OP means with it, but consider the following things I know about Nomad vs Kubernetes:
Kubernetes has many more features that you or your users don't have to deal with (in terms of setup). Obviously that brings in complexity that Nomad may not have to deal with. This also means that some features may need to be supplemented using other software, which otherwise means learning those other software and having different interfaces to manage it. Kubernetes on the other hand, provides all of these features using the same interface. Obviously this also means with Nomad you can add some of these features as you need them over time, instead of having it all at the beginning regardless of whether or not you need them. Some features I can think of: secrets management*, load balancing, config management, service discovery.
Kubernetes has a much bigger community, many more tools you can just plug and play. The relatively recent phenomenon that is Kubernetes Operators is just awesome and makes running software a breeze. Software that otherwise requires a lot of knowledge to run.
Kubernetes only does Linux containers, compared to Nomad that has support for just about any thing you can throw at it (Java, containers, plain binaries), and it has first class Windows support (via Windows executables). Last I checked Windows support for Kubernetes was still in its infancy.
In terms of support, with K8s you will need to get a third-party to give you support, whereas with Nomad you can get support directly from Hashicorp.
Nomad requires a Consul cluster, at least last time I looked this up, though as I understand this, HC was working on this in the past year or so, so this may not be accurate any more. Kubernetes uses etcd internally, which itself takes some understanding.
Lastly, Nomad will likely lead to vendor lock-in. Kubernetes can run just about everywhere including on-prem, all major cloud providers, and even at the edge (see KubeEdge). Chick-fil-A famously runs Kubernetes on Intel NUCs in all their stores. I'm assuming there is nothing stopping a Nomad cluster being run at the edge, but I suppose it's not been proven yet.
* note: secrets management is a bit of an overstatement for Kubernetes. By default it is base64 encoded "secrets", and the only thing preventing one from accessing the secrets is ACLs, but if you have access to the underlying etcd cluster, it's game over. If you want proper secrets management (i.e. encryption at rest and/or in transit), you'll need to integrate it with something else such Hashicorp Vault (the most advanced option), or Mozilla SOPS.
Ha. I totally get what you mean, but I wish. I've seen plenty of air-gapped servers, and I'm not even that old. And everytime I've challenged the set up for it to be truly air-gapped, I've been fought for it.
Not OP, but some air-gapped servers can be connected to from a private "trusted" network, but are otherwise unable to connect to the internet or elsewhere. Perhaps that's what OP means?
I wish companies would hurry up and move away from "trusted" networks and move onto zero trust.
Minimal containers shouldn't need that though. Your logs should tell you enough about the application it's running. K8s (get/describe) should tell you about the lifecycle of the pod. Lastly something like "dive" should tell you all you need about the image's file layout.
Even if battery usage was the reason behind it, it's not good enough. Let the user decide whether or not they're willing to sacrifice battery life if they want to.
My parents emigrated to the Netherlands when I was young. In my native tongue we say numbers in the same way as they do in English. My 8 year-old brain struggled to understand this new way saying numbers when I started school in the Netherlands. I got there in the end but I recall it feeling like it took forever.
Sure, except for the fact that this specific email is <firstname>.<lastname>@gmail.com and I have only ever used it when I've been directly in contact with companies after I've gone through the whole process, or when I've developed a relationship with the recruiters. I've never connected it to LinkedIn either. In addition, as I mentioned in my previous comment:
> Every time I reply to ask where they got my email, they mention some service that scrapes emails based on LinkedIn addresses.
Again, zilch to do with my email being allowed to be public.
Every time when I've reached out to these spam companies, they've mentioned scraping and guessing emails. I.e. if my name on Linked is John Smith, and they'll add john.smith@gmail, john.smith@outlook, j.smith@gmail, and some other common name formats.
Takes the complexity of having to use a queue out of the equation, though at the expense of potentially lost webhook calls.