I recently had to fix an Elixir service that was slow to start. I was able to pinpoint the issue with only a few commands and I want to share a couple of the things I learned.
I’ve been a maintainer of asdf for about 6 years now. Most of my work these last several years has been fixing bugs, writing automated tests to catch regressions, and ensuring overall correctness across various operating systems. Maintaining a tool written in Bash isn’t easy. For most things there are far more edge cases and compatibility issues than happy paths. Certain commands need to be banned from the codebase to ensure compatibility across operating systems. Bash strict mode also helps but it introduces other issues that have to be worked around.
All this to say I haven’t had a lot of time to step back and assess the other aspects of asdf. Other maintainers have stepped up and helped with documentation and UX, but performance has fallen by the wayside. Over the last couple of months I’ve noticed some asdf commands that I use often seem to have gotten slower. Many asdf commands are fairly slow but with the way asdf was designed it is seldom a problem.
asdf current was never fast enough to be used as part of a shell prompt showing the current versions, but that was user experience enhancement that wasn’t critical. But it seems like things are getting worse and I wanted to assess performance. In this post I am going to benchmark several asdf commands and see how their performance has changed over time.
One of the big benefits of static websites is simplicity. Static websites are simple so there is much less to worry about. There are no login credentials to be compromised. There is no dynamic content that must be stored and displayed. There is no danger of a bug in the code allowing SQL injections. But there are still things that should be done to secure a static website. In this blog post I will list some of the important things that still need to be done to provide a secure static website.