(The following announcement is taken from the release notes)
The AFP Renderer development team (that’s Pete and I) is pleased to announce the release of AFP Renderer 1.1.0.
This latest release can be downloaded from http://afp-renderer.sourceforge.net/download.html.
The important changes since the last release (1.0.2) are:
- added support for outline fonts
- added sample fonts with distribution
- added XML2AFP command-line utility
- added examples
- fixed rendering of tables removing double lines
- fixed rendering of tables in landscape
- fixed shading table cell problem in landscape
- expanded and updated documentation
Existing users should read the notes on upgrading the configuration in http://afp-renderer.sourceforge.net/configuring.html, as the structure of afp-fonts.xml has changed slightly.
For more information about the AFP Renderer, see http://afp-renderer.sourceforge.net/.
I am a very enthusiastic champion of life-cycle processes and development techniques that can produce better software products. My view is that improving process methodology in key process areas can give enormous benefits in terms of quality and time to market for software development. However, too much process change in the short term can have detrimental effects; pragmatism must always be applied, especially when commercial realities mean that corners must be cut sometimes in order to meet deadlines.
As can possibly be surmised from my last post, I have recently been involved in a job interview. I found it to be a very interesting and educational exercise in the relative importance of process versus product. You’ll have to read on to determine the winner in this case.
I was called up out of the blue by an agent with a fantastic job description that sounded like it had been written using my career goals as a template, located two miles down the road from home, and a much better pay to boot. Of course I took an interest, and sent in my CV. What followed was one of the most thorough and challenging interview processes that I have ever been through. There were three contact points with the company:
- A seventy minute telephone interview. This went very well, as I thought that there was a fair amount of mutual agreement on development methodologies and technologies. I though I had a good rapport with the interviewer.
- I spent about three hours working on a program to solve a coding problem set by the company (obviously, my code was excellent!).
- I was called into an interview on site that lasted over three hours, as my work history was queried in excruciating detail, along with my opinions on development strategies and methodologies.
The end result? Although I had an excellent background, there was concern with my emphasis on process rather than the end product, and hence they did not want to progress things. Although I feel the slight sting of rejection in this decision, I can’t really take this as a setback, as I was not even looking to change jobs anyway.
I think the lesson to learn from the experience is that you need to choose your moments carefully when advocating process improvement. In the end, the people with the money what to know that you can deliver saleable product within budget and before the competition does. Although I firmly believe that attention to development process will actually help the business goals, the correlation is not always obvious.
It’s taken two years, but I’ve finally updated my Curriculum Vitae. After dusting it off and reading over it again, I’m surprised by how many different technologies I’ve managed to play with so far in my career. I still have the sneaking suspicion that I won’t be stopping learning new things yet, and the holes in my knowledge leave plenty of room for improvement.
I’ve been preparing a slide show to present to the “Best Practice” group at work. I was looking for a simple way to do the presentation, when I came across Eric Meyer’s Simple Standards-Based Slide Show System (S5 for short). I’m really impressed with how simple and easy it was to create a new slide show, and adapt the look and feel for the company style. Kudos to Eric!
My Introduction to CruiseControl presentation is now available on-line. If anyone has any feedback, or feels that they can use the presentation themselves, please let me know.
I’m a big believer in the benefits of Continuous Integration, and so I have become a user and then contributor of CruiseControl.
I find the continually increasing awareness of CruiseControl in the development community quite exciting. Mike Clark’s new book has been receiving a lot of attention , which has been translating directly into a lot of new users. I find the CruiseControl project statistics graph at SourceForge very interesting indeed. I expect that this month will break page view and download records again, especially if version 2.2 gets released on time.
Why am I excited about this? Besides the fact that Continuous Integration is a fantastic development process, I also have a personal stake in CruiseControl. I have been making contributions to the website and documentation, an area that is traditionally quite weak in open source projects. In helping out and assuming ownership in a relatively unmaintained area, I’ve become quite connected with the success of the project. Marking out my home in the noosphere, I guess.
As part of a project that we’re working on together, my friend Pete Townsend developed some library code to generate prints for insurance policy applicants. Input data comes from an XML document, and is converted to an AFP print stream (AFP is a MO:DCA print format used on mainframes). Leveraging available open source tools, Pete created a plugin output renderer for Apache FOP.
There’s nothing unusual about this type work, any developer working for a large corporation will do similar tasks. The amazing thing is that Pete managed to convince our management that donating this project back to the Apache Foundation would be a good idea. The result of this is the AFP Renderer project on SourceForge. In a fit of madness, I told Pete I could help out with creating the AFP Renderer Homepage.
The ultimate aim is to get the AFP Renderer source code integrated directly into the Apache FOP codebase. In the meantime, SourceForge has (yet another) project.
It’s been a long month. I’ve learnt more than I wanted to about Linux hardware compatibility, but I’ve finally managed to get Fedora Core 2 up and running. Configuring mail, web, etc has been interesting, as it’s all slightly different from what I’ve been used to with Debian. Over the next few weeks, I’ll tweak things into usable shape, but it won’t be quick.