The point is that the realities of not being able to deploy in lockstep erode away at a lot of the claimed benefits the monorepo gives you in being able to make a change everywhere at once.
If my code has to be backwards compatible to survive the deployment, then having the code in two different repos isn’t such a big deal, because it’ll all keep working while I update the consumer code.
The point is atomic code changes, not atomic deployments. If I want to rename some common library function, it's just a single search and replace operation in a monorepo. How do you do this with multiple repos?
> If I want to rename some common library function, it's just a single search and replace operation in a monorepo. How do you do this with multiple repos?
Multiple repos shouldn't depend on a single shared library that needs to be updated in lockstep. If they do, something has gone horribly wrong.
They do, it's just instead of it being a library call it's a network call usually, which is even worse. Makes it nigh impossible to refactor your codebase in any meaningful way.
But if you need to rename endpoint for example you need to route service A version Y to compatible version in service B. After changing the endpoint, now you need to route service A version Z to a new version of service B. Am I missing something? Meaning that it doesn’t truly mater whether you have 1 repo, 2 repos or 10 repos. Deployments MUST be done in sequence and there MUST be a backwards compatible commit in between OR you must have some mesh that’s going to take care of rerouting requests for you.
You just deploy all the services at once, A B style. Just flip to the new services once they're all deployed and make the old ones inactive, in one go. Yes you'll probably need a somewhat central router, maybe you do this per-client or per-user or whatever makes sense.
You can do phased deployments with blue green, that's what we do. It depends on your application but ours has a natural segmentation by client. And when you roll back you just flip the active and passive again.
> - There is a difference between things that are actually the same (or should be for consistency (such as domain facts, knowledge) versus ones that happen to be the same at the time of creation but are only that way by coincidence
For my money, this is the key point that people miss.
A test I like to use for whether two things are actually or just incidentally related is to think about “if I repeat this, and then change one but not the other, what breaks?”
Often the answer is that something will break. If I repeat how a compound id “<foo>-<bar>” is constructed when I insert the key and lookup, if I change the insert to “<foo>::<bar>” but not the lookup, then I’m not going to be able to find anything. If I have some complicated domain logic I duplicate, and fix a bug in one place but not the other, then I’ve still got a bug but now probably harder to track down. In these cases the duplication has introduced risk. And I need to weigh that risk against the cost of introducing an abstraction.
If I have a unit test `insert(id=1234); item = fetch(id=1234); assert item is not nil`, if I change one id but not the other, the test will fail.
But if I have two separate unit tests, and both happen to use the same id 1234, if I change one but not the other, absolutely nothing breaks. They aren’t actually related, they’re just incidentally the same.
> A test I like to use for whether two things are actually or just incidentally related is to think about “if I repeat this, and then change one but not the other, what breaks?”
I really like this question as a way of figuring out whether things happen to look the same or actually should be the same for correctness, plus it feels like it should be an easy question to answer concretely without leading you down the path of 'Well we might need this as a common component in the future'.
I also think you can frame it as a same value or same identity type question.
They’re not talking about the squiggly line. The word return/retunr gets highlighted in slightly different colors based on whether the highlighter is picking it up as a keyword or a variable name, but in the scheme the colors are similar.
But their argument is based on the underlying assumption that it's the responsibility of the syntax highlighter to tell you when you've made a typo.
I am presenting an argument against this - and stating it's the responsibility of _diagnostics_ to tell you when you've made a typo, not syntax highlighting.
I would add that no highlighting would be applied to this mistyped word as it would not be recognised as a variable or a keyword. This may depend on the way syntax highlighting is handled. A common solution like treesitter would sus out that no variable with the name retunr exists, probably causing the mythical base colour to be applied, heh. That is arguably a big highlight in a colourscheme that rarely uses its base colour.
* Mobile email clients that open links in an embedded browser. This confuses some people. From their perspective they never stay logged in, because every time they open their regular browser they don’t have a session (because it was created in the embedded browser) and have to request a login link again.
* Some people don’t have their email on the device they want to log in on.
Sending codes solves both of these problems (but then has the issues described in the article, and both share all the problems with sending emails)
Magic links can be used to authorize the session rather than the device. That is, starting the sign in process on your laptop and clicking the link on your phone would authorize your laptop's sign in request rather than your phone's browser. It requires a bit more effort but it's not especially difficult to do.
Wouldn't that be incredibly insecure? Attacker would just need to initiate a login, and if the user happens to click the link they've just given the attacker access to their account..
The reason why magic links don't usually work across devices/browsers is to be sure that _whoever clicks the link_ is given access, and not necessarily whoever initiated the login process (who could be a bad actor)
> and if the user happens to click the link they've just given the attacker access to their account
Worse: if the user's UA “clicks the link” by making the GET request to generate a preview. The user might not even have opened the message for this to happen.
> Wouldn't that be incredibly insecure?
It can be mitigated somewhat by making the magic link go to a page that invites the user to click something that sends a post request. In theory the preview loophole might come into play here if the UA tries to be really clever, but I doubt this will happen.
Another option is to give the user the option to transfer the session to the originating UA, or stay where they are, if you detect that a different UA is used to open the magic link, but you'd have to be carful wording this so as to not confuse many users.
That, or a background process that visits links to check for malware before the user even sees the message.
> Isn’t there a way to configure the `a` element so the UA knows that it shouldn’t do that?
If sending just HTML you could include rel="nofollow" in the a tag to discourage such things, bit there is no way of enforcing that and no way of including it at all if you are sending plain text messages. This has been a problem for single-use links of various types also. So yes, but not reliably so effectively no.
And we get back to the original point of the article (sort of). Opening a magic link should authenticate the user who opened the magic link, not the attacker who made the application send the magic link.
This is what makes securing this stuff so hard when you don't have proper review. What seems like a good idea from one perspective opens up another gaping hole somewhere else.
Off the cuff suggestions for improving UX in secure flows just make things worse.
You need to be careful with some circumstances. I recently had to fix up a case where someone had tried this with a recurring local date. Something needed to happen at 4am local time every day. They had converted 4am local time to UTC based on the timezone offset on the day the config was saved. This then restored incorrectly when the timezone offset changed because e.g. a DST transition.
Well, I guess I should have written in the OP, that I do both conversions at the time of the query. It's useless to try storing the UTC. It needs to be JIT.
Having click and drag not be limited to a line is actually useful for ringing around a completed ship. You can tap a number clue on the outside to fill in the missing water, which can help avoid needing to draw long straight lines.
But having it only perform the same action would make things nicer.
Restricting to straight lines would be the most straightforward, I think. It follows the convention of only changing squares that you touch.
Drawing rectangles introduces a new paradigm where you can fill in squares you don’t actually touch, so it might be less intuitive. At the least, you would probably want to highlight the affected squares in a different color before finalizing the action.
repl as a name kind of describes the requirements for something to be a repl - it has a read-evaluate-print loop. It would be more confusing to say that something with a read-evaluate-print loop isn't a repl.
If my code has to be backwards compatible to survive the deployment, then having the code in two different repos isn’t such a big deal, because it’ll all keep working while I update the consumer code.