A surprisingly local meetup this time, in Bristol! Thanks to Paul Brown of Jordans for organising this and his interesting talk on using Vaadin as a portlet MVC framework. It was great to finally have opportunity to meet the Gavin Beckett, Chief Enterprise Architect of Bristol City Council. Several of his team were present too, and I wish I had more time to speak to them. Bristol are doing some great work on redeveloping their online transactional services delivery platform and using Liferay Portal to achieve this. It is clear that they are taking time to understand citizen needs and using this knowledge to design a great citizen user experience. Prior to the meetup I had been approached by Digpen organiser Sophie Dennis who as turns out is helping project manage the Bristol on their Liferay Portal implementation. This was a really big surprise to me because I have known Sophie for some time from attending Digpen conferences and Exeter Web Dev meetups, but the topics of these have almost always been PHP or lifestyle related. Liferay user groups have mostly been in London, and a whole different group of developers to me. It is quite exciting that Liferay Portal projects are becoming more commonplace in the south west! A UK user group meetup may be hosted in Exeter in the not too distant future.
I have a strong interest in developing approaches where software is not only developed in a modular way, but also in a way where each module can be mashed up with other modules from other software that was developed in isolation. This interest was first sparked when I encountered the JSR286 Java Portlet specification for portals a few years ago. Portlets are a good candidate for software modules, though in order for them to become this, they need to communicate. JSR286 brought more standardised IPC (Inter-Portlet Communication) to the Java portal world, though it did not go all the way. I feel I have achieved some nice composite applications with reusable portlets by creating strategies on top of the events publishing & processing framework that JSR286 IPC brought. This approach is working well whenever a small team is developing all the portlets, but becomes more challenging when integrating portlets developed by other teams in isolation. By integrating I mean without writing code. This is where I feel the problem with JSR286 IPC resides and it is a major problem in a world where app stores are king and mashups are gaining popularity.
In 2010 I posted in this topic (Achieving a federated single view of the customer) and it remains a challenge. I still feel this is a good approach, but it does require a bit of code to be written for each integration. Can we do better?
A couple of topics which have interested me for a while now is CI (Continuous Integration) and automation. I’m introducing tools to provide developer support using these approaches for my team to enhance the experience of new application builds and regression testing. The latter is of particular important as this removes the need to hassle the original developers of applications whenever a change has to be made, to a large extent. There are also benefits in the area of handing over support more effectively to first and second line support teams. However, achieving CI and automation is a complex challenge because our applications are loosely coupled n-tier, spread across three core platforms: Liferay Portal 6.1 EE, Orbeon forms 4.0 PE and Weblogic 12c middleware (coming soon!).
For those who are not familiar with CI, this is the practice of integrating code changes frequently into a shared code branch, often your mainline (a.k.a. trunk or master). The theory is that by integrating frequently, you will be integrating smaller changes, and in larger teams this means a decreased likelihood of code branch merge conflicts. As it turns out, this is true. It is made easy with support from powerful SCM (Source Code Management) solutions like Git where branching, and more importantly merging, is a low cost activity. To get the full benefit it is recommended that you integrate your SCM with an issue tracker and branch for every issue, no matter how small, and make include issue IDs in commit messages when you commit the code changes that represent fixes. This facilitates automatic generation of release notes for builds and issue trackers are often able to tell you which commits resolved which issues.
September was an interesting month packed full of interesting meet ups and opportunities to put into practice concepts that I have been evolving over the past couple of years. In this post I will cover the Liferay UK User Group (@LiferayUKUG) meet up on the 17th September hosted on LGA (Local Government Association) premises in Westminster (London). Continue reading
Historically I have been a advocate of CRM technology. Now I’m no longer sure if it’s going to survive long term; at least not without a radical shift in approach.
Service providers commit a lot of resources into keeping their customer data up to date, so that it can feed into delivering a more streamlined service to the individual, facilitate BI and power campaigns. There appears to now be a realisation that this approach is both expensive and, in reality, ineffective. They’re always playing catch up. Continue reading