Documentary trailer about how simple text became code we trust to run modern life, told by the builders who made it so. Currently in production.
583 karma · joined March 9, 2013
That said, the proposed drawbacks aren't necessarily ... drawbacks? Granted my perspective is from deploying Vault to the Cloud vs. on-prem.
1. Yeah, Vault needs a separate place to do its storage. However, that's a strength if you're following an immutable infrastructure pattern. You store the data in something like DynamoDB and still have the freedom of tearing down and re-creating the Vault servers themselves.
2. Vault may be more expensive right out of the gate, but if you're trying to cover ALL of its functionality with cloud services, it'll start saving you money eventually. Furthermore, many of the cloud alternatives have service limits and quotas. I mean geez, if you want an internal CA through AWS, you're paying a flat $400 a month + costs per certificate.
3. Vault has a learning curve, but it's not worse than having to memorize the buffet of CLI commands through your cloud provider. Yes, getting it set up for the first time can be a jigsaw puzzle, but when everything is up and running, it's smooth sailing. (Plug - I have a project that automates setting up Vault on AWS: https://github.com/jcolemorrison/vault-on-aws)
4. As for vulnerabilities of the "default implementation" - Yes, the public cloud presents more opportunities for exposure, but that's not limited to just Vault. Furthermore, if someone gets root access to your vault servers...that's not a vault thing. 80% of the 2019 massive cloud breaches are the result of misconfigurations and account compromises (source: https://www.paloaltonetworks.com/resources/research/unit42-c...).
"...we anticipate that there will soon be a whole generation of developers who have never touched a server and only write business logic."
Honestly, which sounds more like a nightmare than a dream. Knowing what your software runs on and how it works is critical if you want to create REALLY GREAT software.
(reference article: https://www.allthingsdistributed.com/2019/08/modern-applicat...)
You can even simulate weather!
That all being said, I'm not sure how the long run comes into play here? It's bad if we extrapolate a long run prediction where no one else innovates or creates something in this space. But in reality, someone's going to be annoyed by it, someone's going to start up a different solution, and whether it works or not...it'll be there. Whether it's a small startup or a big enterprise challenging - if there's market gains to be had from adding this, it'll get added.
Don't get me wrong, you're on point with a lot of things in tech. Monoculture and monopolies are becoming super "in-your-face" considering just how much control the FAANG companies have in influencing tech and the like. However, I do find it odd that a single feature release by a larger company results, more often in not, in much of HN community losing their minds over prospective world domination. (not you op, but just in general...granted similar outrage happens to small open source stuff just as much so maybe this point is moot).
As John Maynard Keynes put it, "In the long run we are all dead." But in the short run, this just seems like a super useful feature added to a super useful product that will just make things easier for all developers.
a) Everything is the "tip of the iceberg" - which makes teaching what you actually want to teach tricky. Which is why so many resources do the whole "we won't go into it, because this is a large topic." For example, Linux. Most projects and resources require this, but barely any actually go in-depth.
b) Everything is always changing - and so you have to either support your students in the face of these changes or constantly keep the materials up-to-date. This is one of the largest challenges, if not the largest challenge.
c) Everything has to be engaging - it's not enough to know what you're talking about. You have to know how to talk about it in a way that creates engagement and thus learning. This isn't something you learn how to do when slinging code left and right.
d) Everything needs to be TAUGHT, not said - the ability to teach is often an after thought for folks looking to educate. If you want to really help your students, you have to learn how to teach so that they can think independently. Not rely on cheatsheets, prep tests, and step-by-steps.
e) Every student needs the motivation to learn - usually instructors' will stop at spitting out their knowledge. The best instructors help their students push through their barriers, whether personal or professional, and get the learning done. It's easy to learn in a structured school system. It's hard to learn when you have multiple kids, a full time job, and all the emotional baggage of being an adult.
Now, to be clear, I'm talking about teaching modern, practical implementations of software...not CS theory or other things that are far more evergreen and less technical.
But like anything else, if you understand the toolset, ecosystem, and have the experience, it can take far less time than esoteric documentation and conversation would have you believe.
I always begin with this pattern, but it's because I've acquired so much experience and know-how with it that it's a quick upstart. However, this didn't come with any ease. Most want to just dive into really myopic course work or tutorials that are "just examples" and "shouldn't be used in production." The WORK to understand it is getting each nuance under your belt. It's just like any other skill set - it takes patience and deliberate effort. Documentation spelunking and trial / error experiments.
That being said, under the fire of a manager, timeline of capital, or just the raw impatience inherent to humans we wind up falling back to what's safe, what has plentiful easy-to-learn patterns, and listen to all the other folk who get 50% through, stop, and then just spin up terribly organized monoliths.
> E explained that the main impetus behind the introduction of code review was to force developers to write code that other developers could understand; this was deemed important since code must act as a teacher for future developers.
This should always be at the forefront of the code reviewer's mindset. It's quite easy for the review process to degenerate into a style argument, quest to find every inefficiency, or attempt to make code as "clever" and brief as possible.
"But employers/managers/execs will operate more responsibly with more data about their employees!"
Will they really? I think they'll be able to operate more "powerfully" with respect to controlling employees... but with that power I wouldn't be surprised if the abuse outweighs the positive utility.
Additionally... this is going to kind of kill the culture between people (ESPECIALLY REMOTE) using slack. Do you really want to talk about your weekend, or forge any type of bond over chat now? Why would anyone every do anything rapport building over slack now?
Yeah yeah "but managers/employers won't be that extreme, you're being extreme." There's a lot of cases in the past where I've thought "sure an exec or manager wouldn't do X" and then sure enough, there it is at the top of HN, and the company is going under.
So...someone else on here speculated correctly. It's clearly a selling point for employers since they're the main target to increase revenue. Unfortunately I guess that means using it for interest groups goes out the window though.
a) open source activity b) github activity c) active blogging on knowledge or topic related to dev
The reason? Remote work takes a lot of independent work (obviously). And external activity from just a job is a great signal that "hey they like this enough to do it in their own time." This indicates that their interest goes beyond just what they're getting paid for.
I know, I know. "But that's not necessarily a great indicator!"
When you're on a big time crunch to fill the role, and you have 100s of folks to look through, you've got to filter somehow. And quite frankly things like this are going to be far more proving than just "well I have nothing up because it was all company work so I can't show you" or "I have a life outside of coding" etc etc.
And if it's not for changes sake it becomes some weird squabble over how to best handle X, and we wind up with numerous ways to do so. At that point we have to take a bet as to which approach we think will be supported and pushed forward in the future (i.e. promises? generators? callbacks? async/await?). If we're right? Great. If we're wrong. Well, let's hope the libs we're using keep support for the way we've written our code.
On the other hand, it does finally seem like React has one the shake out of front-end frameworks. While it's ever changing, it does seem like it's longevity will be far greater than most front-end frameworks of the past. And it does solve a lot of the BS that one would deal with if they didn't have a framework to leverage.
But yeah.. The danger with front-end development is how fast the knowledge depreciates.
edit: by danger, I more mean difficulty of keeping up with.
Fieldboom is simple marketing software that helps you capture more leads and customer feedback so marketers / founders / small business owners can grow their businesses faster.
Tech: AWS, Docker, Node.js, React, MySQL/AWS Aurora, NGinx, and more.
Apply here: https://weworkremotely.com/jobs/5440-senior-frontend-develop...
The dude who helped me was super chill and understanding as well.
So instead of "we use GraphQL, much love" + basic example and how it looks on React - a "here's how we take that structure and resolve it and return it." Because that structure looks amazingly sweet - but if in the background it's requiring circles of work, work and rework...
Anyhow, maybe I just don't understand it enough.
https://awsdevops.io/p/practical-and-professional-devops-wit...
We go from zero to fully scalable/loadbalanced etc. infrastructure on AWS. :D
- The AWS Account: The Landscape
- The VPC: The City (Range of Postal Codes)
- Subnets: Individual Postal Codes
- Route Tables: The Road Infrastructure
- Network ACLs: The Security Gates around Postal Codes
- Servers/Services: The Buildings
- Security Groups: The Security Guards for Buildings
- Availability Zones: Parallel Dimensions
- Regions: Alternate Realities
If via console, that gets done behind the scenes when attaching the role. But ya roles use the security token service behind the scenes which allow for temp creds vs. storing sensitive stuffs on the instances.
I'd be interested to see your team's workflow for multiple accounts @joshpadnick.
As for which direction, this is going to be a bit of preference and need. Do you want permissions to begin at the user or at the resource? For scenarios, like a bucket controlling access to non-aws users, it makes sense to have it on the resource. For others, like delegating bucket access to certain EC2 instances, it makes more sense to keep it on the role user.
The fuzzy lines of gray are only exaggerated by the fact that the docs love doing stuff like: "These two policies are equivalent!" And showing examples that accomplish both.
Tl;dr, (a) pick the permission direction that makes sense (b) set a standard for your team and infrastructure and stick with it (c) try to not use NotVersions of actions