Sunday 15 April 2012

Various Methods to Print PDF's from Java

Due to the company I am currently employed by I have had quite alot of experience in trying to print various documents through Java. Below I'm going to simply give brief examples of how printing in Java can be achieved. The post relates mainly to printing PDF's but probably can be applied to many types of document. From experience printing a document in Java is just as much a art (with lots of luck) than it is a science.There are so many factors which will effect the quality and ease of printing a document that it usually is a time consuming task to get it correct and from experience compromises usually have to be taken.

Factors such as:
  • The Printer: There are thousands of printers out there, each one may handle spooling and a document different
  • Print colour profiles can change from printer to printer
  • Windows and Linux variations in colour, depth etc.
  • The print driver language installed will make a difference, e.g. PostScript, PCL5, PCL6 etc.
  • Paper quality
  • Available font
  • Graphics quality inside your document
  • One print library will render the same PDF print job differently to another.
  • Usually each printer has a multitude of settings which can be tweaked, which ones make a difference?
The list goes on and on, and the most annoying and time consuming bit of this is as the deliverable is a physical piece of paper the only way to test this is to slowly work your way through the options, printing out lots and lots of paper and examining them by eye. Also since things like colour interpretation are so unique to each individual you will often disagree with others about which one is the best fit. I'm sure there are some really fancy pieces of kit which will do this measurement but they usually cost lots of money!

Below are some of the various means I have used in the past to print PDF documents through Java. I have used a few of the below libraries in production before, changing when better alternatives are found or problems come up. You can print document directly through the java.x.print libraries which come with the JDK but these libraries don't handle PDF's very well. (or atleast the PDF's I have had to print) I think the problem with most of these libraries boils down to the interpretation from PDF to the required print language.

Adobe Reader (Free)


I have once used this in a production environment but if you start to print large volumes of documents problems soon start to arise. A common issue I have experienced is that Adobe Reader doesn't shut down properly and after several days running the windows box running the application crashed due to memory issues. Its not an scalable or elegant solution to a problems that can be complex in reality.


ICEPdf Printing ($)

I have used this in production before and is a comprehensive library however incompatibilities arrose when new printers where purchased and thus we have moved away from ICEPdf.


JPDF Printing ($)

JPDF is a simple to use and good quality library from my experience. It produces good a quality output and also can render POSTSCRIPT files with ease.



I have never had much look with the two libraries below and have only evaluated what can be achieved. Having never been able to produce a suitable output Apache PDFBox and PdfRenderer are not suitable for printing production documents.

Apache PDFBox (OSS) - Source link


PdfRenderer (OSS) - Source Link


In know way am I trying to promote or sell any of the above libraries, I know lots of hard work and hours have been spent designing and developing them. My aim is to simple speed up the process of evaluation for people. All examples from this post can be downloaded form my GitHub account here.

James

Sunday 1 April 2012

Are Agile Retrospectives a Must?

Originally when I finished University and took my first step in the big wide world of work, taking on the role of a junior software engineer, we would perform some form of a retrospective after each release cycle. Thinking of ourselves as being agile, practising Scrum, amongst other things we would be working on 2 week sprints, releasing to the business at the end of each sprint, morning stand-ups, planning poker, retrospectives and all the other tools and practices available to an agile team. This wasn't always the case but when time permitted and resource allowed, we would get together in a room, usually lead by my boss, and come up with a list of "What went well?", "What went wrong?" and "How can we make it better?", voting on each point, prioritising a list and if we get chance trying to elevate some of the points noted.

That was four years ago, I have no doubt that I have changed in those 4 years. Becoming a more proficient and confident engineer, become more confident with the business and with others and having changing opinions about the agile movement. I think it’s worth noting that agile rocks, or what I think agile is all about rocks and I love the software craftsmanship movement, probably as I am a true geek at heart, feeling very passionate about the software I write. I also like to think the craftsmanship movement relates to myself a little, always striving to produce high quality software which will add value to my users, always trying to write clean code, always trying to practice TDD etc. Software Engineering being such a broad subject there are obviously things which I don't do so well and obviously things which I should change, this could cover an entire blog post itself so I will miss those bits out and focus on the question "Are Agile Retrospectives a Must?".

As far as retrospective go, I haven't been on any courses and defiantly don't have a certification in it. On the other hand, I have read several books, attempted to lead several retrospectives and attended a lot. I will put forward my foundations for asking this questions and my reasoning's behind it.

So retrospectives are primarily a forum to reflect on the last iterations set of work and highlight issues or problems people are having. These problems could relate to any topic e.g. technology, the business, fellow team members, 3rd parties or maybe just the general feeling for the ongoing project by the team. Below are some of the good and bad points about Agile Retrospectives:

Good
  • Points get raises
  • People get issues of their chest
  • Issues can be resolved
  • Blockers come out
  • Team disagreements come to the surface
Bad
  • People don’t remember on long projects
  • Difficult for people to get involved
  • Difficult when people work on different projects
  • People take things to personally
  • Actually dealing with the issues after, who, how, when?
  • Doesn't fit a Kanban approach.
  • What if you don't have sprints but are constantly developing and releasing?
Now obviously there needs to be some sort of forum where team feedback and conflict resolution can occur and my main point is that with all the good will in the world having a de-facto agile retrospective doesn't always work? As companies move to a more continuous and lean approach to software development, sprints go out the window. You tend to work on projects which may span months, weeks, days or hours but you’re putting out software daily, easing the impact on the user, reducing the risk on every release, little and often is the game we play (or try at least). So how does this practice work with the agile retrospectives I have read about and practised in myself? It doesn't, when we would release every 2 weeks without failure it was great, every 2nd Friday afternoon we would have a retro, trying lots of ideas (usually from here) and usually it was productive. But even when you have set release cycles likes this I find two weeks can be long time and things which have caused issues can be missed.

Alternatives to retrospectives in my mind are purely dependant on how well communication in your team is. In my opinion a short weekly get together combined with good daily communication will solve most if not all of your problems. Spread the knowledge, get some sort of forum in place like campfire, and post issues you’re having to the whole team. Get a wiki so complex process can be documented (briefly); make sure everyone in the team is in the know. Simply by sharing as much knowledge as you can you will find that tension drops, people are more confident in taking on any task, code ownership is spread amongst the team and people are not solely responsible. Business issues which you are having report them up the chain but ensure everyone is aware you’re having issues and then they won’t be so frustrated if they hit them to. Internal team issues can be brought up in a short weekly meeting, put the issue on the table, let everyone know and see what people say. People should already know if things haven't gone well as they have heard it, read it on the forum, or witnessed it during the week. 

Now the above approach won’t always fit your team and I may be completely mistaken as to what I think best practice is and what is the best solution to solving conflict and issues which are preventing software from being delivered. What I do feel strongly is that once you have moved away from a scrum based development style to a more Kanban based development style, dropping the set release cycles and moving to a more on demand approach, the usefulness of a set retrospective won’t fit your need. You can obviously elbow the practice into your process but thinking again about this approach you may find taking a different angle on the subject you may find it will yield better results. 

James