phpMoneyBooks

Clearly not ready for public use yet since it has some very serious SQL Injection vulnerabilities. The readme states that the code is pre-alpha quality in the install directory and the ReadMe.txt in the installation root appears to be completely out of date since it discusses a 0.0.12 (RC1). It's an okay start but I wouldn't trust it to handle my finances today if customers are allowed to interact with it. It's just not secure enough yet. I am a fan of "letting it suck" for a little while in order to get the ball rolling. There are enough vulnerabilities and incomplete parts in the code, however, that I wouldn't consider this 1.0-level yet. Unfortunately, that opportunity is gone. I'd shoot for the 2.0 release as being security and documentation-complete so users could begin developing trust in the system. Suggestions to developer(s): * Include a developer_guide.txt file that points people wanting to help with more information on how to get involved. * Develop with security in mind. Assume that someone will try to break in to this system. If an attack happened, what vulnerabilities are likely to be exposed? I don't think any business owner wants to willingly put their financial data at-risk. * Validate data before sending it to MySQL. Consider what happens if someone sends you a string that's too long, or has ticks in it trying to gain access to the server? FYI, when trying to set the company name during installation to a name with a tick mark (') in it, I got an SQL error. When I properly escaped the tick mark, it worked as it should have originally. * Just glancing at the code, it looks like it could be refactored quite a bit to make it easier to read, review, and maintain. Consider using PHP Classes to help separate out major parts of the code and to make it easier to work on specific concepts / parts of the code. * Do you do unit tests on this code at all? If so, how do we get a copy of those tests? If not, how do you test the code you have today? What test cases do you have? What data supports those test cases? * Make the zip file unpack to a subdirectory, not the current working directory. This is a common practice for most software and helps the installer know that everything in that subdirectory is what he/she needs to get going. By installing to the current directory, that can cause files to be overwritten and may change the behavior of a system unexpectedly. For example... ./phpmoneybooks1_0_5/blah_blah.blah * There are numerous grammatical and spelling errors on the site. This does not instill confidence in users about the quality of the software. Get someone to proof the site. Develop a review process prior to release to help you catch "stuff" before the release. :-) * Use source control to help you keep track of changes making it easier to create detailed release notes. Make sure you publish the release notes and keep your ReadMe.txt (or similar) up-to-date. * The TODO.txt is okay but what would be better is to use an issue tracker like Bugzilla, Trac, Jira, or similar. That helps developers keep up-to-date on what the current projects are. Your TODO.txt could give a quick summary of what's planned for the next release, but should also point users to the issue tracker for the latest info. * Assume that session variables in MySQL are not configured the way you want them to be and set them in connection library (i.e. storage_engine, autocommit, etc.). * Comments in code can be helpful or wasteful. Code should largely self-document. Comments are used to document concepts and parameters as well as why things are happening a particular way. It's unusual for comments to tell the reader what the code already makes fairly obvious. Use PHPDoc to document your functions. IDE's like Eclipse can use those PHPDoc blocks to help developers see how to use a function quickly as they're writing code. I could go on but I'll stop here for now. Keep up the good work. You'll get it. Feel free to drop me a note if you'd like more info.

Basic, but serves my needs for much lass than the Official QuickBooks.