As a result of the recent Meetups on the subject of Helidon that have been occurring recently, we made the suggestion that Helidon be the subject of a Groundbreaker’s Podcast, net result I was invited to be part of the panel. The podcast was recorded a few weeks ago, and know available (here). Go check it out, as it includes the key contributors to the project Dmitry Kornilov and Tomas Langer.
An Unkle performance is always going to be a little unusual given James Lavelle is very eclectic crossing many genres such as the ground breaking Psyence Fiction album.
The first half of the performance was very much DJ lead by James at a desk and decks, live drums, keyboard/guitarist and Cello. This instrumentation alone really shows the diversity of the musical styling.
No live locals as a result the staging certainly didn’t have a central focus, everyone was with their instruments. Even Moby who crosses genres, as a live artist is in front of the other musicians or moving around the stage when not using a singer. Like any rock concert the performance ebbed and flowed with raising and lowering of the tempo. With the slower pieces being the more cinematic pieces like Heaven.
Unlike a conventional performance the lighting didn’t pick out any of the performers, and like a club made more use of strobing light effects, but in contrast a lot of video was used as well including the amazing Spike Jonze directed skateboarders for Heaven.
Part 2 …
An intermission or perhaps a very long encore? Not what you’d expect half way through a performance of this nature. But the change gave emphasis to the use of 5 different vocalists.
This changed the dynamic but also gave the second half a bit of a stuttering feel as the different singers can on stage and left.
Added to the fact that the delivery of performances originally by the likes of Ian Brown and Richard Ashcroft had the timbre of a female voice. But things got going and and then just built to a thumping finale.
Interestingly even with the use of live vocalists they weren’t lit up.
All said and done, Unkle doesn’t perform live very often and it’s great hearing the music performed live. I would love to have caught James Lavelle working with the Orchestra as he did with the Heritage Orchestra.
When it comes to the use of micro-services and APIs. It appears pretty common for a few key response codes to be used. However, if you look at the IANA Status Code Registry of defined codes, there a number of other very useful codes that can help convey issues clearly, without compromising security.
The IANA list, references the relevant IETFRFCs, but I’ve taken this a step further and obtained the relevant deep hyperlinks to the code explanations. In addition to that, I’ve also highlighted some response codes, that perhaps benefit from a closer look, or considered with caution.
Another Spring means another excellent Oracle EMEA PaaS Forum for Oracle partners. Every Year Juergen Kress organizes the event, finding really nice venues to host several hundred people over four and half days.
The event is split into several parts, Monday afternoon normally involves Oracle Ace’s presenting on best practices, insights on applying the various technologies etc. For me this meant presenting on the London Developer Meetup, looking at how it worked, what has been successful, and what hasn’t. For those know have read my blogs on the subject (here) will know about our Drone initiative.
Then Tuesday is a single stream day where Juergen has managed to pull in SVPs and Senior Product Managers from around the globe to provide a high level views of what has been going on with their products. For anyone consulting in the Oracle domain this is incredibly useful. For example there is a clear strategy coalescing around AI and Machine Learning both as a service proposition to users, but also how these technologies are being made available and used within other products. Other areas such as OIC and SOA CS have stability and maturity, and the road map is about maximising connectivity with the newer products.
But before the sessions start, Juergen starts with opening remarks, and demos’ something engaging. In previous years this has been things like Digital Assistants/Chatbots and so on. This year, we have been fortunate to be an active contributor by demoing the drone through the use of APIs and talking about the ideas. The dry runs of the demo on Monday went without problem, but when it came to the main show, the drone was a little uncooperative – we think because the air-con had really kicked in. But importantly, even not achieving the desired result, the message of engagement made it home.
Wednesday is split into streams with in-depth sessions from the different Product Managers, he amount of insight gained from these sessions is tremendous, some of which is very much protected by safe harbour statements or not for public disclosure such is the honest and open discussions. The day closes with an Ace Director initiative which demonstrates the application of Oracle Cloud products to a plausible use case, and Luis Weir (Capgemini Oracle CTO) is part of. This session has become something of a tradition now.
The day’s business concludes awards, and for a second year the UK Capgemini team have taken home two awards for APIs and PaaS Contribution.
The final two days are then a choice of Hackerthon or 1/2 day training sessions on different products with the relevant Product Managers, and an excellent opportunity to pick the brains of the presenters as well as get hands on experience with the different products.
The week isn’t without it’s social and networking activities of course …
I have been working my way through Building Evolutionary Architectures by Neal Forward, Rebecca Parsons and Patrick Kua. Three senior and respected members of Thoughtworks (also the home of Martin Fowler). Having read and listened to Neal and Rebecca’s presentations and writing I had expected a deeply thought provoking read, but have to admit to being disappointed. There are some good points without a doubt, but the book pretty much focuses on one idea, the application of fitness functions. But I’m not convinced it warrants several hundred pages of a book as result the point does at times feel laboured.
There are some arguments made, that leave me thinking that there is a view that the only answer is microservices in the conventional model of Kubernetes, Docker etc, which I agree is a powerful paradigm to allow solutions to evolve, but it isn’t a silver bullet and not always right in every case (if you have a team lacking the underlying appreciation of the goals, or put in to place in an ad-hoc manner (see Chris Richardson‘s work) it isn’t going to help.
Alongside this, there is little said about the interface definition for microservices (typically APIs of one form or another). Whilst mention of leaky abstractions is made, the material illustrations such as code lead API definitions are omitted (risk being, code changes, the API changes and the impact cascades).
What surprised me the most is the on more than one occasion the books points to ERPs not being sufficiently customisable. Yet, anyone working with ERPs will tell you that ERPs are at their best when you use them to leverage industry best practices rather than crow bar them to fit unconventional ways of operating. If you’re a manufacturer, is fiscal reporting part of your differentiator; probably not, so why not take best practice OOTB.
As usual I have mind mapped things as I read through the book. The dynamic/interactive version is here, the image (but not in full detail) is below.
In January we presented our 1st online training, looking at API Design and use of Apiary and Swagger. Things went well until near the end where for some reason voice and video dropped for no apparent reason. Our coordinator Lindsay kept the recording going and soon as we reconnected I continued the session and went through the Q&A.
So if you missed the end of the end of the training, please do check back with the recording.
If you missed the training – we’ll be rerunning in March – go here.
For those on the training will have seen at the start of the training links to my social media profile, so happy to try respond to any further questions.
We are also scheduled to run the session again in a month or so.
One of the questions received during the session I thought worth mentioning was when would Apiary support Open API 3.0. Well according to their blog very soon, looking forward to it as the OAS 3 does look a little cleaner.
A while back I made some utilities I developed to help with managing the API Platform. At the time we didn’t have access to an IDCS based environment, so credentials worked using basic auth (I.e. user name and password). But with environments managed by IDCS tokens are used.
As a developer with a Java background I have to admit to liking Groovy over Python for scripting, not to mention for the API Platform groovy is part of the gateway deployment and SDK. Meaning it is readily available in its 2.x form (3.x is relatively recent and aligning to the latest Java idioms). We haven’t tested against Groovy 3.0
Tomas, opened by explaining the evolution of the micro-profile being championed by the Eclipse Foundation who are now the guardians of J2EE also known as Jakarta and how the J2EE and Micro-Profile standards compare (in simplistic terms – micro-profile is J2EE stripped back to be simple and support what is typically needed in a microservice world).
In addition to talking about what can be done, Tomas described the kinds of features being developed, this includes:
Bringing micro-profile support up to the very latest specification,
More reactive persistence technologies support,
With the scene set, Tomas then worked through a series of live code scenarios starting with a clean slate and building Hello World in both the SE & MP models illustrating the differences in approach. This was then built upon to add the following capabilities:
You can get the complete example which uses Helidon in both configurations from Tomas GitHub.
In addition to Helidon itself on GitHub, there resources provided include rich documentation and examples of each key feature. Plus a Slack community, that if you contact any of the Helidon team will get you invited allowing you to discuss with the development team how to do things along with other developers using Helidon.