#Issue64
3 posts

Four load testing mistakes developers love to make

Being too focused on what you set out to test and ignoring any other warning signs while testing is a common mistake developers make. Reusing test data is another common mistake.
Read more

Four load testing mistakes developers love to make

  • If you run a short load test and it works fine, it is no guarantee that your service can handle that load for a long time. You should run your performance tests for more time and understand your system’s performance characteristics.
  • Being too focused on what you set out to test and ignoring any other warning signs while testing is a common mistake developers make. It’s good to pay attention and investigate unusual results or changes in your application’s behaviour as you increase load.
  • Reusing test data is another common mistake. You should either generate new data or spin up a new environment for each test.
  • Assuming the production environment is perfectly healthy permanently. Deliberately make things to go wrong during your load test to find out how your service will perform if such failures happen.

Full post here, 7 mins read

How not to store passwords

One of the good options for storing passwords is key derivation functions. They require more compute time to get cracked which means an attacker needs to spend more money to crack them.
Read more

How not to store passwords

  • It can’t be said enough - do not save passwords in plain text.
  • Encryption is only slightly better than plain text. It is not THE answer for sure.
  • Plain hashes are pretty weak too. They are vulnerable because users tend to replicate the same passwords for different websites and they also use very simple passwords making it easy to crack.
  • Salted hashes are much better at protecting passwords. But the speed at which hashes can be calculated by attackers makes brute-force attacks reasonably possible.
  • One of the good options for storing passwords is key derivation functions. They require more compute time to get cracked which means an attacker needs to spend more money to crack them.

Full post here, 7 mins read

Go: best practices for production environments

Use a single, global GOPATH for your development environments. Try cloning your repos into their canonical paths within the GOPATH, and work there directly.
Read more

Go: best practices for production environments

  • Use a single, global GOPATH for your development environments. Try cloning your repos into their canonical paths within the GOPATH, and work there directly.
  • For repository structures, a good practice is to limit the number of source files. Your repos (with the exception of a vendor subdirectory) shouldn’t contain a directory named src, or represent their own GOPATH.
  • When it comes to passing configuration, package flag provides the best value and has strict typing and simple semantics.
  • Formatted code can significantly increase clarity. Use gofmt to format your code.
  • For logging and telemetry, try using package log that implements a simple logging package. It defines a type, logger, with methods for formatting output.

Full post here, 11 mins read