Plurrrr

a tumblelog
Wed 11 Nov 2020

Systematically removing code

It's easy to miss things when removing code, leaving behind unused methods, templates, CSS classes or translation keys. (Especially in a dynamic language like Ruby, without a compiler to help you spot dead code.)

I avoid this by removing code systematically, line by line, depth-first.

This is one of those things that seems obvious when you do it, but in my experience, many people do it haphazardly.

Source: Systematically removing code, an article by Henrik Nyh.

How To Write Unit Tests For Logging

Once in a while I get asked the question whether one should write solitary tests for logging functionality. My answer to this question is the typical consultant answer: “It depends”. In essence, logging is an infrastructure concern. The end result is log data that is being written to a resource which is external to an application. Usually the generated data ends up in a file, a database or it might even end up in a cloud service.

Source: How To Write Unit Tests For Logging, an article by Jan Van Ryswyck.

Fixing leaky logs: how to find a bug and ensure it never returns

I lay out a case for moving security enforcement into the hands of developers. I show how I and another developer at r2c successfully identified data leakage in our logs, fixed the issue, and prevented it from happening in the future. We did this in a matter of hours, without assistance from our AppSec team.

Source: Fixing leaky logs: how to find a bug and ensure it never returns, an article by Nathan Brahms.