In the previous parts one, two, three and four I talked about various aspects of LotusScript / VoltScript classes. But there's a LotusScript function which has become very relevant for me recently, in the context of classes.
Before going onto that one more LotusScript function that is relevant to classes, there is another topic worth discussing with regard to classes. This is not functionality in LotusScript classes itself, but a design pattern which has been available ever since LotusScript began, but one which has become very commonly used in other languages as they have developed. It fits well after the discussion on using Static for creating builder classes, because the builder pattern in Java is where it's most widely used. The design pattern I'm referring to is a fluent interface.
In part one I covered the basics of what constitutes a Class in LotusScript / VoltScript. In part two I covered abstract classes, base and derived classes. But there are more things that can be done with classes and properties.
In the last part I covered the basics of what constitutes a Class in LotusScript / VoltScript. I also said that user-defined classes in LotusScript are often avoided because developers can interact with their data via the platform classes in lsxbe (Notes...) and lsxui (NotesUI...). When classes are used in proprietary applications they may typically be very straightforward - standalone classes with no inheritance. But there is much more possible, as Java developers will be aware of.
Classes have always been a part of LotusScript, an aspect used heavily in many open source projects. Recently I came across an OpenNTF project OpenDOM, which not only includes a number of sophisticated classes and design patterns in its design, but also in the UI covers a variety of projects that provide Object Oriented extensions for Domino. Unfortunately, the project seems to be one of many on OpenNTF that have become unsupported, and many of the projects it points to have either been lost or are unsupported. With so few people in the community covering these kinds of development topics in blogs or conference sessions, I wonder how much knowledge on more advanced topics has been lost. Indeed over the last few years I have also learned things about LotusScript that I did not know before, as I have had to create more sophisticated LotusScript / VoltScript functionality. So this blog series is intended to explicitly share some of that knowledge, specifically relating them to experience of other languages.
So you think you've found a bug. What next? Create a support ticket, right? Wrong!
At Engage 2022 Volt MX Go was announced including features like Volt Formula, a JavaScript-based fusion of Notes formula syntax and Open Formula, and VoltScript, a derivative from LotusScript, and inspired by many modern implementations of BASIC, which will run in Foundry, Volt MX Go's middleware layer. Already at Engage we demonstrated live running code of VoltScript with Try/Catch/Finally, an alternative declaration keyword "Def" for "Dim" and deprecation of GoSub; which let’s be honest is Satan’s spawn. These are the first changes to the core LotusScript language keywords in over 30 years. In addition, we showed live demos of code running triggered from Foundry as well as standalone VoltScript outside of HCL Notes or Domino, for the first time since the end of life of Lotus 1-2-3. We also showed a number of new extensions (LSXs / VSXs) that will obviously be required, as well as developer productivity tooling like unit testing, mocking and a POC of dependency management.
LotusScript agent profiling is not new, but there are still some developers who are not aware of it. It's something I blogged about more than ten years ago. At that time talking about the relative performance of specific API calls, in that case the relative performance of checking .count was greater than zero vs getting the first entry and checking if it was nothing. On other occasions it's also identified mistakes in my code, because it demonstrated more API calls than I expected or needed.
But sometimes it's not a single API call that affects performance, sometimes it's a combination. That's the scenario I came across recently.
Docker has been a significant development tool for me for some time. The ease of spinning up a clean, standalone development environment for applications is a great benefit. The ability to switch seamlessly between different versions is a big benefit when testing. Another benefit is the ability to create demo environments for conference sessions and share them via GitHub for others to easily deploy samples.
But when Docker announced new licensing terms last year, it shook up the desktop development landscape. Rancher, who have a long history of expertise with Kubernetes, stepped into the desktop game by announcing Rancher Desktop. I was aware of the open source project last year, but when Daniel Nashed pointed out to me that 1.0 had recently been released, I decided it was time to give it a try.
Whether it's Docker or Kubernetes (or some flavour thereof), running microservices in containers is a powerful option. It can make it easy to deploy development or test systems, ensuring consistency across your development team. But when you move from consuming to building, particularly when you're building less out-of-the-box containers, there are some deeper elements that you need to be aware of.