I would recommend email for this. It’s a text-based protocol and the original RFCs 821/822 are pretty straight-forward. There are some additional rabbit holes related to content encoding, but if one can implement a simple MTA, a huge amount of the magic of the internet becomes accessible.
I would not recommend trying to build a “production grade” MTA, as there is a lot of minutia to get right, and it’s easy to screw up.
You can still keep password + 2FA on GitHub and Google Suite (probably anything else that's currently implementing them), it's just a convenience/anti-phishing feature right now.
The passkey is synced between devices if it's kept in a password manager, I haven't looked at the mechanism that Apple uses to sync it/use it if you store it in the system keychain. I guess you could also have multiple passkeys configured for a few devices.
Which is what putting most of this stuff on the background accomplishes. It necessitates designing the UX with appropriate feedback. Sometimes you can’t make things go faster than they go. For example, a web request, or pulling data from an ancient disk that a user is using - you as an author don’t have control over these, the OS doesn’t even have control over them.
Should software that depends on external resources refuse to run?
The author is talking about switching to some RTOS due to this, which is extreme. OS vendors have spent decades trying to sort out the “Beachball of Death” issue, that is exceedingly rare on modern systems, due to better multi-tasking support, and dramatically faster hardware.
Most GUI apps are not hard RT and trying to make them so would be incredibly costly and severely limit other aspects of systems that users regularly prefer (like keeping 100 apps and browser tabs open).
I think it’s a double negative: “against not using”
As in, use a bundler.
Hard agree.
It looks slightly gross if you try to read/internalize it, but I’ve been making web pages since the mid-90’s and it’s the least obnoxious way to style html I’ve ever used.
You can stage individual chunks of a file.
Useful if you have a large set of changes you want to make separate commits for. I also just find that it’s a good way to do a review of each chunk before committing changes blindly.
Give it a shot some time, worst case is you stage some stuff that you don’t want to commit, but it’s non-destructive.
I use git on the CLI exclusively. I almost never rebase, but otherwise get by with about 5-10 commands. One that will totally change your experience is git add -p
I also have my diff/mergetool configured to use kaleidoscope, but still do everything else in the CLI.
We used JIRA effectively at my last job, the things that made it work for us:
I agree with the premise of the article, JIRA is a communication tool, not a management tool.
I have no idea what you mean when you say you found an error in the design that says it was an INSERT instead of a SELECT.
If you are relying on a design doc with SQL in it, that’s a massive waste of time.
How many tables are in the schema? Have you reviewed them? Are there any naming conventions being followed, or is everything inconsistently named? Are there specific cases where tables are not normalized properly that you can ask specific questions about why they are that way? If the person that designed the schema is making “trivial” mistakes, there’s no reason to expect that stuff that doesn’t make sense to you will be something they intentionally did.
I guess what I’m saying is, you need to do some due diligence and survey the schema and write down some specific questions and that may lead to writing a UML or other doc to identify errors, but it doesn’t sound like you’ve done that.
Fair, I was saying if this was important to you that you might ping them and let them know.
Obvious typos do not contribute much confidence that the author cares at all about quality.
I quickly skimmed this, and it looks kinda overwrought to me.
This is the format I’ve been using:
{
success: bool
error_code: number,
message: “human-centric error message”,
context: { optional, user-defined details }
}
I generally find that writing code that requires a lot of “accounting” is very prone to mistakes that are easier to avoid with recursion. What I mean by this is stuff where you’re tracking multiple counters and sets on each iteration. It’s very easy to produce off by one errors in these types of algos.
Recursion, once you get the hang of it, can make certain kinds of problems “trivial,” and with tail-call recursion being implemented in many languages, the related memory costs have also been somewhat mitigated.
Loops are simpler for beginners to understand, but I don’t think recursion is all that hard to learn with a bit of practice, and can really clean up some otherwise very complicated code.
My general opinion is that we are all beginners for a short part of our journey, but our aim shouldn’t be to make everything simple enough that beginners never need to advance their skills. We spend most of our careers as journeymen, and that’s the level of understanding we should be aiming for/expecting for most code. Recursion in that context is absolutely ok from a “readability/complexity” perspective.