Shell script time-savers are handy. Why? They give you time to focus on important things rather than tedious yak shaving. The time it takes to write a little script is hardly anything compared to the time it saves.
In my previous article please don’t organize for speed, I shared this paradoxical quote from Cisco’s Scott Cherf:
To go faster, slow down. Everybody who knows about orbital mechanics understands that.
Say what? Slow down to go faster?
What do you think Cherf is talking about? Not rushing? That’s probably most people’s first thought. I bet most of us have had the experience of rushing to get a task done and screwing something up in a way that makes us have to go back and do the work over.
What is defactoring?
Defactoring is actually refactoring, but it looks and feels wrong because it seems like reverse refactoring. Defactoring is refactoring code toward a seemingly worse state, such as one with duplicate code and code that has moved from higher to lower level abstractions. I once shied away from defactoring, feeling like I must be committing some crime, but now I embrace it, under certain circumstances.
Why would I want to defactor?
No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes.
Although Maven documentation has a whole page on their password encryption feature, it doesn’t actually tell you how to do what you need to do to encrypt Maven passwords.
What am I talking about?
If you have authentication to Maven repos in your organization, you normally store the username and password in the Maven settings file located by default at