Always excited about discovering, designing, building and improving software application and data driven systems.
Mentoring, helping for everything related to Infrastructure-as-Code, Terraform, AWS, Docker, Cloud, API and security
No blogs yet.
Good one 👏 Although I enjoyed Will Larson’s book, I found Tanya Reilly’s The Staff Engineer's Path: A Guide For Individual Contributors Navigating Growth and Change (https://www.goodreads.com/book/show/61058107-the-staff-engineer-s-path) was much more actionable (even to reflect/recalibrate at this level) I’m sure you’ll love this read
Thanks for writing this. This is such an important topic! And this is often not as easy as it seems because there are many grey areas filled with complexity and ambiguity, leading to hard dilemmas. If people like reading this, then they will love this brilliant talk from Bryan Cantrill: Andreessen's Corollary: Ethical Dilemmas in Software Engineering https://www.youtube.com/watch?v=0wtvQZijPzg I share with quite often and I believe any software engineer should watch it at least once, at least to raise awareness. Thanks again 🙏
I forgot about this, thanks for sharing 🙏 It’s also worth noting that Beacon API isn’þ restricted by CORS policies as much as regular XHRs requests. The specs: https://www.w3.org/TR/beacon/ And some interesting story about CORS, Beacon, Chrome (and Firefox) : https://medium.com/@longtermsec/chrome-just-hardened-the-navigator-beacon-api-against-cross-site-request-forgery-csrf-690239ccccf
Great job with the train analogy 🙌 They always say story-telling is a great way to convey a message, I guess here the analogy+story telling is the magic that makes this so easy to read 👏 One key difference between real train and git branches too is that Git let you jump off your current branch to go to another one, with no time and no risk (don’t try that with real trains! 😅) When I think back to the days where we moved from SVN to Git, I think the most difficult but liberating key idea was to realize that Git is decentralized by design. What that means is that anything you do is local first . Even when you experiment with things, you cannot screw up the remote origin (until you explicitly ask to push). So there’s no reason to fear with experiment. Another key idea which was liberating was that branches and tag are super lightweight, there are only references (back in SVN, a branch was a complete copy of the file, so it came with size and latency costs). The consequence is that we should embrace branches and tag: creating a tag to experiment with a feature, some refactoring, or anything, let you easily rollback to your original state. What I mean is that once we get that Git let you do things locally without breaking the shared remote origin, and makes it easy to have parallel versions to easily create experiments, it becomes liberating, and Git becomes more than a version control tool, it becomes a workflow assistant . I don’t know if what I write makes sense, but it really changed and empowered the workflows that are possible compared to what we had a few years ago.
Hi Nice short introduction, thanks for sharing this 🙏. If you don’t mind, there’s one important detail though: it’s the part about HTTP being a stateless protocol. It used to be very true, with a new TCP connection established for each request (HTTP 1.0) But that was very inefficient, so HTTP 1.1 changed that to keep and re-use the TCP connection by default. But the HTTP semantics were still stateless (the underlying stack kept a state for performance reasons, but this was not visible to HTTP requests contents) And now with HTTP 2 (no already used everywhere), this connection and state start to become more visible (i.e. server push with multiple responses is possible because the client and server remain connected after the initial response). Long story short, it was purely stateless, but it became more subtle than that ;) It’s much better explained in the great A Brief History of HTTP (I could not explain these parts better than they do). And for many (too much?) technical details, Ilya Grigorik’s Introduction to HTTP/2 is a gold mine. You’ll find there this note: HTTP/2 breaks away from the strict request-response semantics and enables one-to-many and server-initiated push workflows that open up a world of new interaction possibilities both within and outside the browser. Thanks again for the introduction.
I’m late on this one, but since this question comes quite frequently in our teams too: rule of thumbs: use f-strings if you’re sure all your users will support it (i.e. if you create a package, then the lowest version you support might be a criteria here) But if you can, f-strings are shorter, easier to read, and faster at runtime. There’s no good reason to not use them whenever you can. (re the speed, I don’t have the links here, but google will give you benchmarks about it) The only time I switch back to the .format() stuff is when them we need to build templates dynamically.
👏 Other useful tools: https://regex101.com/ After many years of using tools (I love regexes!), I settled down on this one (rather than others) for a few reasons: easy support of whitespace (when you have to deal with more than just spaces) support various languages. Not all regexes are exactly the same code generation. Ease the process to escape things built-in tests support! http://www.regexplained.co.uk/ which builds a railroad diagram of the regex pattern you give it. Makes it easy to review/read/understand a new pattern.... as they grow they can become hard to read easily, this helps a lot!
As you wrote, there’s regularly some debate. That’s why it’s also useful to have an authoritative source of truth to confirm what a server should do if we want to make it follow the standards. And that’s where RFC 7231 (section 4.3.4) comes in to confirm what you wrote: If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request. src: https://tools.ietf.org/html/rfc7231#section-4.3.4 Every time such discussion starts in a design doc review or code review, following RFC is very helpful. We need very strong reason and special edge cases to pick non standard behaviors.