use Perl

This assignment was a small one, estimated to about 20 hours, it did however go a bit over estimate. The project scope was to develop a form to collect data to populate a PDF page.

I know that the PDF format has a form technology integrated, but I did not have the time to investigate this any further. so I spent a friday evening prototyping different PDF modules from CPAN and settled PDF::API2. Developing it in Perl would allow me to integrate with the existing framework - a new technology from Adobe or similar was too much of a risk for such a small task.

We started out two developers, this backfired a bit when we got to integrate the two parts we had developed and we spent a lot of time testing and debugging. I ended up wrapping up the project myself.

• + Good prototyping
• + PDF::API2
• Best practice: component separation
• - Lack of focus, too much on the table
• + Two developers
• - Lack of communication between developers
• + Good additions to new application super class
• - UTF-8 problems, we always have issues with UTF-8, see also below
• + UTF-8 problems, we are getting very good and solving UTF-8 issues, some time in the future we will not experience UTF-8 issues I hope
• - Too many iterations and bugs, I do not mind many iterations, but in this case it was getting silly since the iterations became necessary due to bugs introduced during development and bug fixing, lacking automated test could perhaps have addressed this
• + Lacking human test in development phase, we just delivered stuff to test, which contained rookie mistakes - lack of focus and automated tests too blame (developers)
• - Lacking automated test, almost no automated test (see below)
• - Non-testable code, the application was designed so it was hard to test programatically, the output was a PDF. This gave me the idea for PDF::Template (see below). The idea would be to use a Data::FormValidator (DFV) like strategy where the actual rendering of the PDF would respond with a result set much like DFV, so data written to PDF and not-written would be reported back as return value for evaluation. This would be a shallow, but useful evaluation of the process. Re-processing the PDF post-rending would of course also be an option, but much more heavy-weight.
• Reflection: Hash::Util (lock_keys), this module (see Perl Hacks #87 Lock Down Your Hashes), this could have helped us connecting the two components developed so we would not have experienced so many bugs
• TODO: Add support for additional headers in existing Response class
• Possible TODO: PDF::Template (see above)
• - Diversity in platform (air-bubble bugs?), a really bothering thing, when moving from test to production, other bugs appeared. this would leave us to test in production, a practice which is bad in my opinion. Environments should be as uniform as possible