Hacking from a phone, not the easiest

Recently I've had two people fork and contribute to an open source project I created to add GitHub integration to Linux Mint, inparticularly cinnamon the replacement window manger. Not only was it great to find some people actually using my app but I also really appreciated GitHub for its social and open nature. Using it in a closed cooperate environment does work but when you sit next to the people who are working on the same code its always best to speak to someone in person as opposed to simply commenting. However this isn't always possible and GitHub provides a good medium for this. Both contributions came from forks woth pull requests which allowed for good two way communication and code reviews etc. The problem I did have is that as I'm travelling I have no access to my linux mint install, my GitHub, development and testing tools so it had to be checked, merged and released from my phone, it took a very long time! Hacking from my phone was hardly hacking as the toolset available to me a text editor, zip/unzip application, browser and GitHub app (which has limited functionality). I managed to check the code on the pull request, do some reading, merge it in to master and when it came to a release I downloaded and extracted the zip of the main repo, copied some files to a new folder, tweaked some text and zipped it back up. I also sent it to one of the contributors for a quick test. I can upload the zip with the browser and hopefully a new version will be out and have some new features and bug fixes. Not bad from a phone I reckon!

James

Embarking on a big one!

Approximately 4 weeks before we embark on one hell of a big adventure with +Isobel Perrin my mind is starting to wonder, what the hell am I going to do if I cant write any code for 6 months! I mean....no code, no IDE, no Java, no JavaScript, no AngularJS, no morning standup, no banter with the team, no late night hacking, no diagrams, no mailing lists....the list goes on....it's going to be a challenge!

Hopefully this will soon subside and with my newly created account on Cloud9 hopefully this will hit the spot with any crazy urges to hack away, not entirely sure how well it will work on a nexus 7 though?

The intended itinerary is as follows:

1. China
2. Vietnam
3. Cambodia
4. Laos
5. Thailand
6. Indonesia
7. Malaysia
8. May be somewhere in Europe before we had back to reality

Being nearly a year from birth to actual reality and having privately spoke about it for years I have mixed feelings about leaving work, dropping my routine, not having regular contact with some great friends and colleagues but in reality these opportunities aren't easily come by so why worry, things wont change that much in 6th months. Yes I will be Jobless, homeless and probably a little work shy but helpfully I will return a decent and hopefully more enlightened and worldly person.

Please follow my new blog space to keep track of our adventures, I will update when can!

http://the-travelling-geek.blogspot.com/

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.