Agree, this is a huge pain point when dealing with multiple clusters. I wrote a wrapper for `kubectl` that displays the current context for `apply` & `delete` and prompts me to confirm the command. It's not perfect, but it's saved me a lot of trouble already — but encouraging other members of the team to have a similar setup is another story.
Totally agree. Docker for Mac performance is just unbearable when dealing with a semi-large webapp. I recently moved to remote development – macOS with Ubuntu running in VM (VMware) via Vagrant. I edit code using VSCode & Vim (via SSH & tmux tabs in iTerm2).
Based on my benchmarks it's more than twice as fast as Docker for Mac – and only minimally slower than native Docker running on a Dell XPS.
I'm enjoying this setup so much that I'm considering moving all my dev-related tools to a VM (which will hopefully allow me to get rid of homebrew too).
Implemented this recently in my SaaS app, replacing passwords with magic links and it was a mistake. Sure, it has some obvious benefits: it forces users to always provide a valid email and logging in confirms that the email address is valid, without any additional logic.
But moving auth logic to email links has increased my customer support work significantly: "I can't log in", "I didn't get the link" complaints are quite common now. People use email they didn't sign up with, messages go to spam, arrive with a delay - or recently, gmail outage caused messages to hard-bounce. These are only some of the issues I've had to deal with in the last few weeks, that never came up when I had password auth.
Also, I've found that some email clients automatically follow links included in the message and that meant login link was invalidated before user got a chance to click it. I've solved it by adding a button on the page, but it's not ideal.
Magic links were supposed to be convenient, but they cause a lot of frustrations for some users. Keep that in mind.
I was bitten by this issue already two times. First time wth magic links via email. Suddenly your application depends on the mail infrastructure that sometimes is hard to "scale on demand" or even isn't under your control. Second time with OTP via SMS. Both incidents led us to be unreachable for long periods of time, and the SLA provided by our mail provider and telecom weren't really known until the incident. We assumed that everything would just work under high load.
Quality insight from someone who has actually gone through this. Thank you!
If you could share, can you share what exactly led to the discovery that things are unreachable. Were there any status check mechanisms you were able to put in place to check that incident was raised and / or solved?
Also, do you still continue that (Email login / OTP login) OR is it moved something else?
> If you could share, can you share what exactly led to the discovery that things are unreachable.
We have some heavy monitoring with InfluxDB and Grafana built in our application and one of the alerts is if the number of logins/minute drop under a threshold. That's how we noticed it first time. The main reason was some network issues affecting our mail server provider. We were holding on a support ticket with our provider while trying to find a solution to our customers.
After that we added as well we extended this monitoring to the mail queue. To be fair we used to monitor it before, but with the infra team, now we have it in our SRE dashboard, with Slack notifications and etc.
> Also, do you still continue that (Email login / OTP login) OR is it moved something else?
The OTP as second factor of authentication is something that we couldn't disable, but it's a requirement for one very specific application. We just looked for different partners with better SLA and built some monitoring around it.
The Email login is still there, but we didn't roll-out it to all our applications as we initially intended to. We are still studying what would be the best solution here. The company is heavy user of microsoft's 365 mail service, and although the overall experience is pretty good, we have 0 influence in their SLA if we get impacted by any issue on their side. I don't think that the solution is bad per-se, just you have to plan mail infrastructure as core part of your application.
It allows you to run a local shell script on the server via ssh, using bash command substitution - the "$(<" part. The -t option (force tty) executes the script in an interactive session - without it stuff like password prompts won't work (if I remember correctly).
Author here. It's just a matter of personal preference. If you're proficient with Ansible then I'm sure you can achieve the same task even quicker. But to me, shell scripts are a more natural & faster way to get going for single-server setups and I always have a hard time with Ansible yaml syntax.
Ansible has some undisputed advantages (e.g. idempotence) and if I had to recommend Ansible vs my approach, I'd always recommend Ansible. But for my personal needs (single-server rails apps), I prefer shell scripts.
Can you elaborate a little more on the "company car" thing? It sounds interesting. Does it mean that you basically get a car from your employer as part of the job benefits, but in reality you cover the cost (which is deducted from your salary)? How does it work?
Pretty much like that, it gets deduced from salary and not only insurance and maintenance but also fuel expenses often (sometimes? always?) go through that black box that shields the user from full awareness of car ownership cost. The taxation aspect is complicated enough that everybody has an opinion wether it makes a difference or not, but nobody is entirely sure. Many users will claim that there is no benefit, but secretly hope there is. It might have a bigger impact on the employer side where I suspect that these costs are something entirely different than salaries in terms of bookkeeping, to the point where in some companies you might be able to negotiate a bigger total if you take a party of it as a car (big maybes, this is me trying to get a consistent mental model of why these arrangements are so crazy popular, if you ask me this is either a shameful subsidy for those who need it least our an entirely pointless overcompication of something that could be so simple).
Oh, and a fun anecdote further illustrating the craziness of it all: there's an organization now that sued for eligibility of all kinds of vehicles, so if my employer had such a programme I could get my next fancy bicycle through them! (But as an inner city renter, my bike ownership is limited by storage anyways, and pretty much maxed out already)
If you have a company car that is free for full personal use, driving around, on holiday etc. then the car is paid for and given to you by your company. Insurance, service and often gas is paid by the company.
On the flipside, 1% of the car's list price as well as 0.03% for every km distance between your residence and place of employment is taxed per month. So for 20km distance, it would be 1.6% of the car's list price. That is added as income onto your monthly salary for tax calculation, and those taxes then deducted from your actual cash salary.
To readers that might think otherwise: while this certainly is a powerful setup to give Tesla a hard time in the market (if you only paid personally relative to initial cost, nothing at all for consumables, would you still want to go electric?), it clearly predates them. I have personally (and legally, I was told) burnt company fuel in "daddies car" (which he did not own) back in the 90ies.
Nice work joeyespo, it's definitely a much-needed step forward. NFS, though, is a huge pain point for me on OSX performance-wise. The only reliable solution I've found so far is Unison sync between Mac & Vagrant (Ubuntu). That also comes with some caveats, as Unison has to be compiled with exactly the same version & dependencies on both OSX and Ubuntu.
FS sync, may it be for the code, the assets, the data, the logs, is painfully slow on osx, because of vboxsf poor performance.
If you intend to use docker containers on osx as an isolated runtime, with all your "data" sync'd in realtime between your host and your container, then use linux.
Fswatch / Rsync / unison over NFS, ssh or cifs are hacks of a greater order than having to source an env script.
Out of curiosity, why would you need directional sync/unison?
Sorry for any confusion; this wasn't my work. I only shared it on HN. Nathan LaFreniere is the author of this post and project (https://github.com/nlf).
Here's the script (along with a bunch of extra utils): https://github.com/pch/dotfiles/blob/master/kubernetes/utils...