David Chapman - Chapman Consulting
I am an expert contract software developer in San Jose, California who has written over 1,300,000 lines of code in my 30 years of industry experience. I specialize in compute-intensive algorithms, Electronic Design Automation (EDA), and parsers/compilers.
I provide algorithm design, development, testing/debugging, and optimization services for high performance, high value, and high reliability software. If you don't know how to get your software project started, need help writing or testing it, or need to improve it, I can help.
After 1,300,000 lines of code, I've learned a few surprising things about writing quality software. I have written a series of essays about software development, testing, and optimization. A few are featured below. Read some of the essays, then call or write to find out how I can help you deliver code that works - and works well.
Software Development Done Right.
"Do I Really Need to Fix Small Memory Leaks?"
Recently I was asked whether a few memory leaks were a problem. It depends, I said. Was the test case representative of how your program will run? If the program will never run for a long time, then maybe the errors are not serious.
When you run a leak analysis tool like valgrind or PurifyPlus from IBM/Rational, often the test case you choose is relatively small because these tools slow program execution considerably. The concern is that the memory leaks will continue as the program continues to run, and memory consumption will grow until serious problems (out of memory, page faulting) occur.
Several years ago, after noticing the system overhead of the standard Joomla Web site administrator login page during a password attack, I added a secondary Apache password to the administrator page using a .htaccess file stored there:
AuthName "Secured Area"
Two passwords are now required to gain access, but the first one does not require launching PHP, so it consumes much less CPU time. For a microserver like mine (an Intel Atom CPU on a fanless Mini-ITX motherboard), that's a big deal. The gateway password also provides more security, much like disallowing root remote logins to a Linux server. I do this on all my servers - first login to a non-privileged account, then use su to gain privileges. An attacker must guess the non-privileged account name, then the password, and finally the privileged account (root) password.
Usually an attacker will try a few passwords and then go away forever. On May 11, 2016, I noticed that there were a large number of attacks from separate hosts. Each one would try to login using the user name admin and an unknown password (Apache does not save failed passwords). Since there is no such user, that would fail and the host would try five more times for a total of six.