#338 – October 20, 2019
Devs like you are in demand on Vettery
Vettery is an online hiring marketplace that's changing the way people hire and get hired. Ready for a bold career move? Make a free profile, name your salary, and connect with hiring managers from top employers today.
OWASP Top 10 Vulnerabilities List — You’re Probably Using It Wrong
First issued in 2004 by the Open Web Application Security Project, the now-famous OWASP Top 10 Vulnerabilities list (included at the bottom of the article) is probably the closest that the development community has ever come to a set of commandments on how to keep their products secure.
You cannot cURL under pressure
cURL. The wonderful HTTP plumbing tool that powers both a lot of command line debugging and bash scripts, but also exists as a strong foundation in our applications in the form of libcurl.
Sometimes we need information from our servers instantaneously. For this sort of use case our usual AJAX request/response doesn’t cut it. Instead, we need a push-based method like WebSockets, Long Polling, Server-Sent Events (SSE) and - more recently - HTTP2 push. In this article, we compare two methods for implementing realtime - WebSockets and Server-Sent Events (SSE), with information on which to use and when.
Don't get locked up into avoiding lock-in
A significant share of architectural energy is spent on reducing or avoiding lock-in. That's a rather noble objective: architecture is meant to give us options and lock-in does the opposite. However, lock-in isn't a simple true-or-false matter: avoiding being locked into one aspect often locks you into another. Also, popular notions, such as open source automagically eliminating lock-in, turn out to be not entirely true. Time to have a closer look at lock-in, so you don't get locked up into avoiding it!
Over the years I’ve developed a command-line tool I use for routine tasks such as provisioning my machine, generating project templates and managing secrets. The tool is written in Ruby and I invoke it with the zz command.