Funny enough I just picked up Authy a few months ago and it's leagues better than Google Authenticator. Losing my data once in Authenticator was enough pain to make a switch.
Until you dig into deeper use cases, it's easy to get hung up on Vault as JUST a KV store. Honestly, if that's all you want, and you're on a cloud provider, using a combo of their storage + KMS or other services (i.e. SSM Parameter Store) is probably the more practical approach.
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...).
This makes me think of the Amazon CTO's analysis from Modern Applications on AWS where they push Serverless as the future:
"...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.
Congratulations! Stripe has consistently made my life as a developer and entrepreneur significantly easier. I still remember that feeling of relief some 5-6 years ago thinking, "Yes! I don't have to use PayPal's API!"
Wow, they even let you simulate and control pedestrians? Between that and the pre-made, 3d, urban world to use as a testing ground...what a practical approach to getting these chops under your belt.
Honestly, I think it's a good thing in general. Like you've said, being able to just do things here and cut out all of that wasted time spent connecting disparate services... I mean assuming they pull this off well, it will absolutely make things better for me personally.
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.
This "sounds" interesting, and I'd absolutely love to manage ci/cd in github. Can anyone point me to some clear docs or articles on its usage? The blog post and developer guide on actions reads like some hybrid of a marketing page and a plain index of terms. Most of the examples on workflows/actions documentation and the like are in HCL which is being deprecated.
Indeed. We remove advertising, how many folks lose their jobs that are allowing them a level of self-actualization where they can analyze advertising effects on society at large?
Having taught software, devops, and the like for years at this point, while this article touches on some difficult parts of teaching, they're all just side effects of bigger difficulties of teaching software.
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.
I agree if you have no idea what you're doing - which seems to be the case for many developers starting new projects stuck in the paradox of choice.
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.
Wow. Ya know, for every case this might "help" solve (workplace harassment and the like), I just can't help but say ultimately it will hurt far more.
"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.
Aside from all of the usual hot fluff, I know some will disagree, but..
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.
On one hand, I absolutely agree. The amount of change that happens for the sake of nothing more than change is laughable theme in front-end development.
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.
Yes yes, this is incredibly impressive. Very smart as well for ease of getting people to adopt the new version. I was fearing that I'd have to redo who knows how much just to use 16.
I had 2FA activated, changed phones and lost it. I couldn't log in to my account, so I contacted support. Within about 30 min they had put me back into my account.
The dude who helped me was super chill and understanding as well.
I've looked at GraphQL a number of times. Does anyone have any practical examples of integrating it with backend(s), APIs, and/or specific databases?
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...