Building secure web applications is really, really hard. One of the biggest attack vectors in modern webapps is passwords. Even if we set aside the dangers of phishing or other more sophisticated attacks, passwords themselves are a source of danger, between simple passwords, guessable passwords, shared passwords among family members or teammates, and reused passwords across accounts.
We all love Javascript [citation needed], but if you use it a lot you’ve probably run up on small areas where the standard library doesn’t quite cut it. Maybe you’re looking through documentation for an Array#random method (we don’t have it), or trying to find how to compare two dates in two different timezones (hope you’re using moment!) or learning there’s no builtin function to reverse a string (hint: make it an array first).
If you find yourself frustrated by all the little idiosyncrasies, it might be good to know that the kind folks that make our language spec are looking out for us. Here’s three upcoming language proposals to keep an eye on if you’re looking for small quality-of-life improvements.
If you work on a lot of react projects, you’ve probably seen some interesting unit test suites. After all, there’s lots of schools of thought around how to properly test react applications, right? Some folks will sinon.spy() everything and play with the require lookup. Others might connect all their components to redux or graphql, and in so doing ensure that they can only test their components in the context of that state management.
Perhaps surprisingly, one of the most challenging things about operating RubyGems.org is the logs. Unlike most Rails applications, RubyGems sees between 4,000 and 25,000 requests per second, all day long, every single day. As you can probably imagine, this creates… a lot of logs. A single day of request logs is usually around 500 gigabytes on disk. We’ve tried some hosted logging products, but at our volume they can typically only offer us a retention measured in hours.