As is Packt’s tradition, their Christmas book promotion has started. For the next week or two all books and videos are $5 in their ebook/video download format. Including the titles I have co-authored as well as others that I have contributed to as a reviewer.
When it comes to development, we have had coding standards for almost as long as we have been coding. We tend to look at coding standards for purposes of helping to promote good quality code and reduce the likelihood of bugs and so on. But they also help with readability, making it easy to navigate a code base and so on. This is sufficiently important that there is a vast choice of tools to help us ensure we align with good practices.
That readability etc, when it comes to code interfaces lends to making it easier to use an interface as it promotes consistency and as Don Norman would say avoids ‘cognitive load‘, in other words, the effort involved in performing actions with the interface. Any Java Developer will tell you, want to print out an object (any object) you get a string representation using the .toString() method and direct it using the io packages.
That consistency and predictability are important not just for code if you look at any API best practises documents you’ll encounter directly or indirectly the need to use conventions that drive consistency – use of singular or plural for the name of entities, application of case – camel case, snake case etc. Good naming etc and we’ll see related things appear together in the documentation. Products such as Apiary and SwaggerHub include tooling to help police this in our API design work.
But what about policies that we use to define how an API Gateway handles the receipt and routing of API invocations? Well yes, we should have standards here as well. Some might say, governance gone mad. But gateways are often shared services, so making it easy to see and logically group APIs together at very least by using a good naming convention will help as a minimum. If API management is being administered in a more DevOps fashion, then information security professionals will probably want assurance that developers are applying policies in a recommended manner.
This year’s UKOUG TechFest 19 conference is over. The first time in a number of years where the user group conference hasn’t been a combined Tech, Apps and JD Edwards event. I have to admit that I was a little concerned with the separation of Tech and Apps as some of the tech stack overlaps for the two groups – for example, Integration Cloud.
That said, the situation being what it was, I got involved with the committee for planning the event including inheriting the stream lead responsibilities for Dev (in the sense of modern development e.g. microservices etc) and what had been historically referred to as middleware (Integration Cloud, Digital Assistant, Helidon, WebLogic) with a lot of support and input from Mark Simpson, Grant Ronald and Susan Duncan.
From my perspective, I don’t think there was a concern (and this isn’t an attempt at being self-congratulatory) as the hard graft is done by the UKOUG office staff.
As the number of people was smaller, we had a smaller venue rather than the ICC in Birmingham or the ACC Convention Centre in Liverpool – which actually worked out well. The problem of the ICC and particularly the ACC is that main community spaces had been very large as a result atmosphere suffered. This time the Grand Hotel in Brighton was really busy and vibrant as a result.
We had a good blend of sessions covering traditional integration, low code, cloud, microservices, API, UI with people from customers, partners and Oracle travelling in from all over Europe and the US to participate and present.
In terms of my presentations and the ones, I managed to see, I’d particularly recommend checking out in the UKOUG library …