MAven Enforcer Plugin Example

A little snippet which I have found useful when enforcing maven dependencies in a project, below is a Gist which demonstrates how to fail a maven build via the maven enforcer plugin for Log4j and commons-logging

Cre8ive Thought - Software Development is not a Jenga game

Reloadable Application Properties with Spring 3.1, Java 7 and Google Guava

The Problem

 One common problem I have experienced when developing applications especially web applications is having the ability to specify application configuration properties at start-up or runtime. This problem isn't an old problem and has defiantly be solved over and over again by many frameworks and libraries out there. Spring provides the ability to specify properties files for use inside your spring application and nicely provides spring expression for looking up properties values and setting them on class files etc.

One thing I have always wanted to achieve is the ability to have a property re-load itself if the properties file ever is changed, although this may seem dangerous it does mean that an application wont need to be bounced in order for a new property to take effect (in theory).

One of the great new API's in Java 7 is the WatchService API, this is handy set of tools which allow you to watch and react to file changes. Other libraries are available and have been doing this for some time but this is a good opportunity to get stuck into some of Java's new features and evaluate its usage. 

From the Java Doc:
A watch service that watches registered objects for changes and events. For example a file manager may use a watch service to monitor a directory for changes so that it can update its display of the list of files when files are created or deleted.

Spring provides functionality to load application properties via a PropertyPlaceholderConfigurer class, this is used to configure the application container giving exposure to each properties file and its properties specified allowing them to be referenced to configure the application.

What I have created is a proof of concept library which allows class fields to be set from properties files via a @ReloadableProperty annotation. These properties are also auto reload if the given properties file changes during runtime.
 

How it Works

When Spring starts an Application Context an implementation of Springs PropertySourcesPlaceholderConfigurer is instantiated to perform additional logic when loading and setting values from a given set of properties files. (see: ReadablePropertySourcesPlaceholderConfigurer)

During the instantiation phasae of an Application Context a new instance of InstantiationAwareBeanPostProcessorAdapter is also created which allows post bean processing to occur.

Google Guava is used to implement a simple Publish & Subscribe (Pub-Sub) Pattern so that beans can be updated once created, i.e. a bean can subscribe to property change events. (see: EventBus) EventBus was chosen as it is a very easy and simplistic way to implement loosely couple object structure. (see: blog)

When each properties file resource is loaded a PropertiesWatcher is started and attached to the given resource set, reporting on any java.nio.file.StandardWatchEventKinds.ENTRY_MODIFY events from the host operating system. When an ENTRY_MODIFY event is fired firstly the resource changed is checked for property value changes then any bean subscribing to changes to the modified property has the specified field value updated with the new property. Once the field value is updated no other operations are performed on the object.

Each resource specified starts a new thread per parent directory i.e. two properties files in the same directory requires only one ResourceWatcher thread, three properties files in three different directories will start three threads.

Example Usage

Sample Bean Usage




Sample XML Configuration

Sample Properties files
   


Future Changes

• Ability to use Spring Expression language to map properties files
• Support for Java 7 Data and Time classes
• Include the ability to define a database driven properties source not just properties files
• Implement error recovery inside PropertiesWatcher.class, including better thread recovery
• Ability to perform additional re-bind logic when a property is changed, i.e. if a class has an open DB connection which needs to be re-established using newly set properties.
• Replace callback Properties EventHandler with Guava EventBus
• Ability to configure usage via Spring's @Configuration

Problems

As on reload I simply reset the field value for future use, if the property was ever used to create another long lived object there is no way of re-binding or performing additional post reload logic on a class, this could be done but would need a marker to identify what to invoke post reload i.e. annotation of a void empty args method or implementation an interface which then can be triggered ever time a classes properties change and perform additional re-binding logic.

Feedback always welcome and it would be nice for someone else to check this project out and review it/use it. A complete project with sample tests can be found @ https://github.com/jamesemorgan/ReloadablePropertiesAnnotation/


James

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

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

Dynamically Loading Assets in AS3

Recently I have had the requirement to to load assets from a given location inside one of our flex application. It took my a good few hours to work how and or the best way to go around this is so in the hope that this will save someone, somewhere sometime here is the code. Basically it loads a given image resource, showing or hiding the image depending on the outcome of the load.

Asset Loader:

This simple snippet may hopefully save you some time.

Ramblings and the monster TODO.java

After a great Christmas and new year, a fresh year has begun, for me one of my main goals this year is to earn some money, no matter how small, from utilizing my skills as a software engineer. This may consist of Android applications, website design (probably not), web application development, increasing the numbers to my blog and earning some ad revenue. Before Christmas I started work on a new small Android application which I aim to sell in some form, I say in some form as this brings me to my first set of questions for 2012.

What is best way to sell an Android Application?

•  Should I sell the application only on the official Google Market place or use other providers such as Amazon etc?
• Is this easily achievable, manageable, what are the common deployment processes and practices?

• Do I create a trial version and a full version? 
• This seems to be very common, does it not mean you have to maintain two copies of an application?
• Am I missing something, can it all be configured to be part of the build/deployment process using one application?
• I don't like the idea of giving the user two choices, can you force remove/override the trial version with installing the full paid version?

•  Do I stick with a single application and utilize androids in-app billing functionality?
• This was my original idea but after reading various reports about issues with Androids in-app billing feature and after the well known developer Koushik Dutta posted this - Don't Use Android Market In App Billing. Seriously I have serious doubts about whether this is the best option available.

• Do I not sell the application and make it ad-supported?
• I have spent long hours learning and developing the application and as I have little experience developing ad-supported applications, I worry that this is not going to be fruitful enough.
• Who is the best ad provider, I have once tried using AdMob (Google) with my first application "Whos Making The Brew?" and after a months usages and only several clicks, generating me about 20c, my account was banned, with no reason or rhyme?

If I ever work out answers to the above questions, Ill post them here along with any experience or findings.

As part of the my latest project I invented (probably defiantly not) the concept of a TODO.java file.Its defiantly not a new creation but for me, it's a new way to plan out and develop the application in hand. What I have ended up with is a 200 line TODO file, which I think has surprisingly helped me keep on track. I always have a list, a list of tasks, a list of bugs, features etc, usually anything which I need to do I put in a list and software engineer is no exemption. Previously I have used Google Docs but now as I use GitHub to host all my projects I thought this was the perfect place to store/share and collaborate on the list of features. There are probably much better ways of doing this but personally, I don't need a big heavy weight system, no JIRA, BugZilla, FogBugz, Trac etc. They all take to much of my time and when time is the one think you don't have lots of, it seems stupid to waste it on them. To view a snapshot of the beast I talk about, click here.

That's enough rambling for one day!