Over the years I've spent a lot of time supporting applications. I would like to think I'm pretty effective at it. So I thought it was the right time to share my approaches. The key is a systematic, logical approach to identify the cause - or causes.
Over the years I've done a lot of development on a variety of platforms. Error management is something developers either bake in from the start, add in later, or never get round to! It seems a good time to review my experiences and my philosophy.
tl;dr - it varies.
People discussing Domino application development have been using a new term since early this year - "mid code". This has become necessary because of the evolution of Domino development since Domino V10.
Recently I've been diving back into running Java outside of the Domino HTTP stack, picking up some work I did quite a few years ago playing with Vert.x and Domino based on Stephan Wissel's blog series on Vert.x and Domino. Quite a few things have happened since I was last working on the project, not least the laptop I had at the time got rebuilt, I have got a new laptop, several version of Eclipse have been released and XPages SDK has been deployed to the Eclipse Marketplace (thanks Jesse Gallagher).
One of the themes which crops up from time to time in Domino application development and beyond is the theme of "performance". It's a topic which makes me grit my teeth because of the basic premise. Most articles start from what, for me, is a narrow terms of reference: performance optimisation being about how quick a specific amount of data can be served to a specific environment. My interpretation of the term "performance" is much wider and that is the reason for my scepticism and concern of how people may interpret or use such articles. There are important points raised, but there are also caveats that need to be borne in mind.
Following on from my last blog post it's now time to move on beyond the tooling related to Domino and XPages.
I've recently had a new laptop. Since I last had an upgrade of hardware a lot has changed. Back then, I think my development tooling was Domino Designer, a Domino server, and possibly SourceTree. Now the software I needed to install was much more significant. So now is a good time to cover that.
When I began my personal blog last year, I was investigating new technologies beyond the IBM Collaboration Solutions stack. This last week I've been attending and presenting at the conference, including covering one of those new technologies. The experience for me has changed drastically the direction I was heading. But this is not about a vendor's products, this is about the open source technologies I intend to pursue over the next year.
Last year I blogged about an initiative to take TitanDb to the Apache Foundation as an incubation project. Yesterday, the next step for TitanDb was announced, when the Linux Foundation welcomed JanusGraph, a project which uses TitanDb as its starting point. The current documentation will look familiar to anyone who has investigated TitanDb, but the news will be welcomed by the TitanDb community. So it's worth keeping an eye on the JanusGraph website.
A few weeks ago, IBM announced Watson Workspace, the final name for Project Toscana, and its API Watson Work Services. The product itself has similarities to Slack or Microsoft Teams, but this post is not about discussing a comparison of the products. It's about the API backing it.
Watson Work Services is a REST API that uses GraphQL, a method of querying and posting via REST that focuses on configurability. Whereas traditional REST services have fixed endpoints that take fixed parameters and return fixed data objects, GraphQL is a sort of "API-as-a-service". You call an endpoint, pass a JSON object determining what elements of which data you want to return, include any dynamic variable values. The queries are passed to an engine at a REST service endpoint which parses the JSON passed, replaces any variables with the dynamically passed values, and returns just what the application or user asks for. This may include data from what, in a traditional REST API application, would be from different REST endpoints. For example, to get members and messages from a space, you might need to make a REST call to get the space ID, then another REST call to get its members, and a third to get the messages.