- What problem do you solve and why would I give you money to solve it?
- When’s the last time someone went above and beyond the call of duty at the company/on the team? What did they do?
- What are the current goals that the company is focused on, and how does this team/role work to support hitting those goals?
- What are the projects in this company you think are really key to its future and how would a motivated person go about getting on them?
- What do you see as your largest technical challenge currently?
- Pain Points beyond headcount
- What is a project you wish a new member of the team could take on?
default['sshd']['sshd_config']['AuthenticationMethods'] = 'publickey,keyboard-interactive:pam' | |
default['sshd']['sshd_config']['ChallengeResponseAuthentication'] = 'yes' | |
default['sshd']['sshd_config']['PasswordAuthentication'] = 'no' |
This is a collection of the things I believe about software development. I have worked for years building backend and data processing systems, so read the below within that context.
Agree? Disagree? Feel free to let me know at @JanStette.
Keep it simple, stupid. You ain't gonna need it.
This oral history of password storage on the Web originally appeared as a remark in the #infosec channel of the Hangops slack—the conversation had turned to a mention of “hashed, salted passwords” in a breach announcement in a way that made me suspect at least some of our friends had not studied the topic in detail. Several participants then encouraged me to expand the remark into a blog post, and now here we are.While I was around for some of this, much of it predates my career; everything is as accurate as I can reasonably make it, but corrections of gross errors are welcomed.The first time people attempt to design a Web login system, they will usually default to simply inserting their users’ passwords in their database. This solution is simple, obvious, and wrong.The problem is that database storage is not nearly as private as we would all like it to be. Even the databases that we’d
Helm attempts to solve a specific problem: How do you package up a bunch of Kubernetes manifests in a way that's (relatively) easy to consume.
For simple applications, this works out pretty well. You get a few knobs to tweak on the installation (such as whether or not you want the Chart to create RBAC resources), Helm renders a stream of YAML and then applies it to your cluster. Where this breaks down is when you try to do anything more complex, and that break down happens in 2 areas: Maintenance and Usability
Sufficiently complex (read: any) Helm charts can be thought of as a piece of software. It takes a series of inputs (the values) and produces a series of outputs (the YAML stream of Kubernetes objects). With "traditional" languages, there's facilities for syntax checking, static analysis, testing, etc. that help ensure the software both functions correctly now and in the future. The Helm ecosystem has some of those same things (e.g. helm lint
) as well, however they're generally limited to treating th