Redis has some powerful Lua scripting capabilities. One of the uses I’ve found for this feature is purging cache keys. On occasion I need to purge a set of keys that all have the same prefix.

The following command will do just that.

EVAL "return redis.call('del', unpack(redis.call('keys', ARGV[1])))" 0 prefix:*

Replace prefix with whatever prefix you are looking for and they will be deleted from Redis.

It’s easy for teams to go to extremes with technical debt – either trying to eliminate any and all and the expense of delivering the needs of the business, or ignoring tech debt and letting it happen without any thought or purpose, eventually causing great pains later on in the product’s life.

This interview with Kimber Lockhart has some great advice for engineering teams on how to handle technical debt responsibly. Here are a few highlights:

Begin code review before anyone codes. The best technical teams envision — not just review — code together. “It goes without saying that some form of code review is essential in any type of engineering organization,” Lockhart says. “Early on, pair development or sitting next to each other reading through code will work. As the team grows, it might be important to get code reviews more formally from different individuals or teams.”

For many companies, process evolves so that this code review is the only time engineers get feedback on their code and iterate to make it better,” says Lockhart. “Unfortunately, finding a problem after the fact forces the tough decision between taking the time to rewrite and living with bad code.

Technical debt should be a controlled decision to take a shortcut.

“Technical debt is not the scarlet letter. It happens to the best of teams. I’d argue it’s actually irresponsible for a startup not to have any technical debt.”

Scrap the shortcuts that don’t save time. Lockhart has found that shortcuts can be an illusion — often it takes the same amount of time to write clean code as it would to produce code that introduces technical debt. “The problem is, bad code often feels faster in the same way hurrying feels faster,” says Lockhart, “little time is wasted planning and the code itself is written more frantically.”

Create a rating system for bad code. “Many engineering teams lament the failure of their organization to adequately address bad code resulting from technical debt, but they can’t get their footing when asked how to resolve it,” Lockhart observes. “Engineering teams owe their organization careful prioritization, just like anyone else making requests.”

“Hire seasoned engineers who have some tolerance for technical debt and an earned intuition when it comes to trade-offs. Seek developers who think in pros and cons, not absolutes.”

I was doing some work in Knex today, the fantastic SQL builder for node and needed create a new user. It took some research but here is what I found:

This assumes you’ve already logged into Postgres with another user.

CREATE ROLE myUser WITH LOGIN PASSWORD '';
GRANT ALL PRIVILEGES ON DATABASE "knex_test" TO myUser;

To test it out just log back in.

psql -h localhost -U myUser -d knex_test