Source control is a topic that periodically crops up around Domino. And if source control is important, there is only one choice for documentation - Jekyll. It's not hard to justify why. I'll come onto more detailed coverage of the technologies involved in the next blog post. But suffice to say, for now, that some key reasons are:
Three years ago I presented at IBM Think I presented a session called Domino and JavaScript Development Masterclass with John Jardin. In that session I talked about the various REST options for Domino and used the term "API gateway". Particularly at this time it makes sense to expand more on what was in the slides.
How can you get a "Type Mismatch" error in a Forall loop in LotusScript?
This was the question a few of us hit with a recent bit of coding. You can't declare the forall variable, and if you're iterating over a variant containing only strings, surely this shouldn't happen. The loop was quite basic:
Over the weekend we lost another long-standing member of the Domino community, Nathan T Freeman. Nathan was outgoing, often controversial, but passionate about open source and helping others. Everyone who met him will have stories about him. But I know he is one of the individuals I have to thank for being where I am today.
In my last blog post I talked about challenges we had to overcome as a team with regard to caching of constants. But a bigger challenge we hit was caching of design elements.
Part of the solution we built required copying design elements from one database to another. Part of the beauty of Domino is that everything is a Note - including design elements. Design elements are just Notes with a special flag. So just as you can copy a document from one database to another by getting a handle on the note, you can also copy a design element from one database to another by getting a handle on the design note. The API is exactly the same - Call NotesDocument.copyToDatabase(targetDb).
Recently I've been involved in a project with a lot of LotusScript. As a team our approach has been to structure the code according to best practices and leveraging what we've learned from other languages. Standards are always good, but there are always peculiarities that impact what you do. The crucial skill is to be able to work out what is happening when the standard ways don't produce expected results. And most importantly, work out how to work around them.
There are a number of challenges when it comes to two-way REST and Domino. But one of the biggest challenges for manipulation between NotesDateTime objects and JSON is timezone handling. There is an Product Ideas request to provide serialization / deserialization between Domino objects and JSON strings, which surprisingly only has 31 votes, but it's not there yet. So for Volt MX LotusScript Toolkit, this needs handling within the toolkit itself.
Earlier this week Jason Roy Gary announced the Volt MX LotusScript Toolkit. It's important to put some background to manage expectations. There will be an OpenNTF webinar on December 17th where we will explain more about our aims for the project and provide a call-to-arms to the community to join us driving this forward. I encourage everyone to attend if you're interested in using Agents outside the Notes Client or a Form's WebQueryOpen and WebQuerySave methods. But in advance, let's cover some questions I expect people to have.
Part One: Domino and Statistics
Part Two: Prometheus
Part Three: Micrometer and Prometheus
Part Four: Micrometer and Composite Registries
One of the big additions in Domino V10 was statistics publishing, initially focused on New Relic. But as Daniel Nashed showed this can easily be re-routed to other locations, for example a Domino database. When I worked at Intec I tried the New Relic reporting on Domino early on and was very impressed at what was provided. My response wasn't focused on what statistics were delivered - what is outputted is not the important factor, it can easily be change. My opinion came from how easy it was to set up. New Relic itself is straightforward, but what needed to be done on the Domino side was even easier - a few Notes.ini settings, restarting and the statistics flowed. Since the days of Embedded Experiences I have been convinced that ease of implementation is critical for adoption, and adoption is key to value for effort.
Most Domino developers use Windows because that's the only platform Domino Designer runs on. For most of my application development life, my main device has been a Dell laptop of some variety for this reason. For almost a decade now I've also been running a Windows Domino server because Domino Designer local preview is not an effective test environment for a Domino web application. If you're using source control you are also usually testing locally unless you're developing cloud functions. So for development, you typically want a Domino server, and if you're using Domino Designer, the easiest server install to develop against is a Windows Domino server. If you want Linux on Windows and you're using Windows Professional, Docker is a sensible approach, if you take some time to understand port access from Docker.