Firstly, I can’t tell you how much fun it has been to work on this project. It was a bit tedious in the early months working through the nuances of auto-recycling, auto-boxing and completing the busy-work of making sure every delegate reference was complete. But these days every commit is a personal triumph of innovation over complacency.
And the POWER of being able to drop in features at the drop of a hat is incredible! Even big features can go from a passing thought to a complete implementation in just days, hours or sometimes even minutes. When you have a good idea for someone else’s API, you have to think up all the details of implementation and entry points. When you have a good idea for your own API, the *where* and the *how* usually just fall right into place.
What do I mean? Let’s take Document.appendItemValue(String itemname, Object value) as an example. When most developers see this method, they think “oh, so if I have a field named ‘foo’, and it has a value of ‘bar’ and I call .appendItemValue(‘foo’, ‘blah’) then the value of ‘foo’ will be ‘bar’:’blah'” But alas, no, that’s not what happens at all. Instead, the method creates a SECOND field called ‘foo’ with a single value of ‘blah’. This is almost but not quite totally unlike what was intended.
So when you control the API, you can simply decide to fix it. Just open up the code for public Item appendItemValue(String, Object) and change the behavior to be whatever you want it to be; save, test and commit. There’s no defining a use case; no filing a PMR; no lobbying the engineering team; no arm twisting by threatening to migrate; no public shaming on a blog. You see a problem and you fix it. You see an opportunity and you create a win; end of story.
Another great example of this is the org.openntf.domino.Document implementation of Map. It seems kind of obvious that Notes Documents should implement Maps, since every item in a document has a name as a key which should return some value. The implementation of Map on a Document took a little time (two or three whole days for Jesse, which is really an eternity in open source…) but once it was done, we could have conversations like this…
Me: “Wouldn’t it be cool if Document.get(String key) would, if there was no item matching that key, try evaluating the string as a formula against the document and returning the value instead? That way Document.get(“@Created”) would just return the creation time and Document.get(‘@Adjust(@Created; 1; 0; 0; 0; 0; 0)’) would return one year later than the creation time?”
Jesse: “OMG that would be great!”
Me: “I do this all the time in other APIs. It’s really handy.”
Jesse: “It would be fantastic in XPages because you could make really simple value bindings”
Me: “Good point. I didn’t think of that. So, who’s going to implement it?”
Jesse: “I’ve got this.”
*two minutes later*
Jesse: “Okay it’s done.”
This is the pattern over and over and over again on this project: all problems are opportunities for another amazing victory; all previous miseries are simply things that, when we fix them, highlight more and more why we are bringing productivity and happiness to the world of Domino; all new invention is yet another solution that pays off the technical debt of thousands of applications. Some days it’s like being able to walk up to a computer and just type in a new balance to your bank account. You simply think “there’s a problem I never have to worry about again for the rest of my life” and it rings like a chorus of angelic trumpets through your soul.
For me, this is great way to start my 40s; putting the headaches of the last 20 years behind me and helping others do the same. I hope you’ll consider downloading our labor of love and joining us in building the next generation of collaboration solutions. Just look at how happy it made these fine folks at ICON UK!