in reply to Production obfuscation
I know this horse has been beaten and there is plenty of info out there
Actually, I don't think it has.
As the author of Acme::EyeDrops, the only animal
I'm aware of being harmed for production obfuscation
is not a horse but a
proposed by `/anick in 2002 to enhance
"psychological obfuscation" because
"surely the script dealing with
super-secret FBI passwords isn't that ASCII picture of
a frolicking wombat".
So, I'm want to know issues of Acme::EyeDrops in production and what
liabilities I need to be aware that when converted could cause me issue
If you haven't already done so, read the "EyeDropping EyeDrops.pm"
section in the Acme::EyeDrops documentation and follow
the advice there.
As that section indicates, EyeDrops.pm (a non-trivial module)
has been successfully converted into 151 camels and all tests still pass.
At that time, I was considering distributing the module itself in
EyeDrop'ed form but decided against it not because it didn't work
but because it was four times slower.
Also note that if you set the PERL_SMOKE environment variable
before running "make test", the test suite will automatically convert
EyeDrops.pm and the test suite itself into camels and run them again.
Which passes. So I have fair confidence that you won't hit any serious
problems with your approach and if you do, you should be able to work
around them (as was done with the "eval-hostile" line in EyeDrops.pm,
described in the "EyeDropping EyeDrops.pm" section).
Having said that, it would be prudent to have a test suite for your
code and to run it both before and after EyeDrop-ification.