colemorrison

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.

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.

(reference article: https://www.allthingsdistributed.com/2019/08/modern-applicat...)

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.

You can even simulate weather!

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.

In the "How it all started section" -

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.

nah, I asked, it's for the amount reserved, not the amount used. https://twitter.com/nathankpeck/status/935930795864211461

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 (https://fieldboom.com/) | Senior Frontend Developer (React) | Remote | Contract to Full-Time

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

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

Anyhow, maybe I just don't understand it enough.

Shameless plug - I've got a 15 hour course on building a full infrastructure on AWS:

https://awsdevops.io/p/practical-and-professional-devops-wit...

We go from zero to fully scalable/loadbalanced etc. infrastructure on AWS. :D

The base analogy - Building a VPC like building a Sim City

- 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

Without even having to dive into userdata or metadata, just (a) create the role for the ec2; (b) attach the trust and permission policies; (c) create an "instance profile"; (d) attach the instance profile to your target instances.

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.

Oh wow. That's an interesting case for inline policies. Now that I think about it, yes there's plenty of cases for reusable ones, and there seem to be just as many cases where a policy is unique to exactly that one service/situation.

Just for anyone wondering, as per joshpadnick's great suggestions, you can specify other AWS account's users/roles via Principal in a policy as well. Just use the other AWS account in the ARN. edit: if you want to do so via policies that is

I'd be interested to see your team's workflow for multiple accounts @joshpadnick.

This is good stuff right here. Separate accounts can do tons. Also helps prevent stuff like dealing with VPC collision overhead.

It's honestly going to depend. In some cases you don't really have a choice. For example if you want to limit an S3 bucket to an IAM group, since S3/Resource Policies don't support IAM groups ARNs in the principal, the only solution is to apply the permissions around access to that S3 bucket to the IAM group (as opposed to the bucket).

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

Indeed, they're just a "resource" policy. They're still talked about and share the so many same attributes that it became more character saving to say AWS IAM Policies vs. AWS IAM, S3, SNS, SQS, Glacier Policies =P

Yeah, I mention that in the "Who" aka Principal section. It's like that for any resource based policy (i.e. like S3). So IAM Users/groups have it implied, but Resource based ones like S3 do not have it implied.

I wonder how much criticism and hatred this post would've received had it not used Rails as the example case. Monoliths exist in other stacks (obviously), but the Rails community always seem to take offense first. This is the first time I've seen such an opposition to micro services (maybe I'm not looking through forums hard enough).