Yes, you read that right: every Domino administrator should read the new XPages Portable Command Guide. Developers should too, but from what I've read so far, I feel it's more crucial that admins pick up a copy of this book.
Let's assume that you're a diligent administrator. You've known for maybe a decade now (or more) how best to configure an end user's Notes client installation. You can set up an efficient replication and mail routing topology in your sleep. You've even kept current, so you now know all the best practices for configuring DAOS and Traveler. Congratulations! You're a top notch email administrator.
But if I'm your Notes developer, and I need you to deploy a new XPage application, do you know what questions to ask me in order to ensure that the correct persistence settings are enabled in the application's xsp.properties file? Do you know what heap size should be set in the server's INI to provide a solid balance between performance and scalability? It's fantastic that you know exactly how to support every last detail of an email environment, but do you know how to support applications?
If you don't, or you're not sure, or even if you think you're sure, buy this book. Sorry for the blunt honesty, but I haven't met a single Domino administrator who could instinctively tell me what the xsp.persistence.mode setting should be, based on whether the users want the application to be fast, scale to massive amounts of concurrent users, or provide a healthy compromise between the two. If, at a minimum, you can't answer that question without even stopping to think, and you administer production Domino servers running 8.5, or ever plan to, you need this book.
Hint: the answer is on page 24. In fact, the entire first chapter - all 81 pages of it - are just about how to configure one file: xsp.properties. This is where you define, either at the server level, or at the application level, or both, resource management (such as CPU and RAM), cache management, and the like. There are plenty of settings that can be defined in this file that only the developer should care about, but many of them you don't want the developer to decide. Trust me, if you leave it to me, I'm typically going to max out the RAM consumption in an attempt to provide lightning fast response times. But it's your server. You should be overriding me on that decision... as long as it's still in keeping with the end users' business needs, of course.
Chapter 2, with the exception of a couple pages at the end about defining very specific security settings, is also about a single file - notes.ini - for tweaking stuff like Java heap sizes and improving post-restart performance by preloading certain JVM tasks. Again, pretty much all admin stuff. Developers should also understand these things, or we won't be writing efficient code, but it's the administrators who need to know what the appropriate settings are based on the hardware available and the users' needs.
Chapter 3 is all about Domino console commands. Very useful for the developer when doing unit testing, but obviously this is still primarily targeted at the administrator.
Okay, admins, the second half of the book would probably just bore you. So feel free to move along now. But buy the book, okay? Your end users would love for their admin to know how to support their apps as well as their mail, even if they don't realize that's what they want. Trust me on this.
Developers, still with me? Good, 'cause we're getting to the half of the book you'll actually find interesting.
Chapter 5: Server-Side Scripting. This chapter digs slightly deeper into the server languages like SSJS and Java than Mastering XPages did, but honestly I didn't see a whole lot new here. On the other hand, this is, after all, a "portable command guide". So whereas, in the words of one of the authors, Mastering XPages was about the "journey" of learning to develop XPages applications, this is kind of the "yellow book" (for those of you who have been around a while) for XPages: the handy reference you keep conveniently next to your mouse pad at all times.
Chapter 6: Server-Side Debugging Techniques. This is where it gets really interesting. A loose form of some of this has already been distributed in PDF form with the XPages Extension Library (the actual library itself, not the next book about XPages that I'm going to tell you that you should buy), but this provides the same information in a more polished form, as well as much more detail. Spoiler alert: once you've finished this chapter, you'll know how to bind your test server's HTTP task to an Eclipse debugger, so you can step through your code just like you used to do with LotusScript. Mood killer: that does you no good if you write all your code in SSJS... you only get step-through for your Java code. Sorry. Take it from a guy who used to hate Java: just get it over with and learn Java. You'll write better code, your XPage apps will run faster and be more powerful, and your skills will be more portable should you ever decide (or be forced) to seek employment outside of the Domino microcosm. If your experience at all resembles mine, after a few months you'll wonder why you ever liked LotusScript. *
In summary, this is an excellent read for developers and admins alike. It's not as sprawling an epic as Mastering XPages, but it's not meant to be. This is a reference guide, something you'll want to absorb as much of as possible, but should keep on hand to revisit as the need arises.
workaround for severe screen sharing bug in Mavericks
Tue, Feb 4th 2014 3:40p Tim Tripcony I love my MacBook Pro... once you go Mac, you never go back. Unfortunately, there's a massive problem with screen sharing once you've upgraded to Mavericks: models that have both an "integrated" (low-power) and a "discrete" (high-power) video card started using a feature that Apple calls "Dynamic Switching". This feature attempts to maximize battery life and other aspects of OSX performance by toggling between the display modes depending upon what you're trying to do at the time. As a r [read] Keywords: apple
an easy way to give Domino Designer a ridiculous performance boost
Wed, Dec 4th 2013 4:10p Tim Tripcony From the top-level menu, select "File > Preferences"
Choose "General > Appearance"
Change the option labeled "Current presentation:" from "Styled Presentation Factory" to "Classic Presentation"
When prompted, allow the "workbench" to be automatically restarted
I do feel obliged to warn you that the behavior of Designer after following the above instructions can be extremely disorienting. For instance, removing an app from the Applications navigator no longer cau [read] Keywords: domino
the reason panel data sources can't be accessed outside the panel
Thu, Oct 10th 2013 7:40p Tim Tripcony Marky Roden recently called attention to a lesson he learned: if you associate a data source with a specific panel, you can only refer to it by name via events (or attributes) attached to components inside that panel. There are two very specific reasons for this:
Hierarchical component processing
The role the requestScope plays in variable resolution
While there are no doubt some subtle exceptions to this premise, you can consider all runtime processing of XPages to be hierarchical. To co [read] Keywords: xpages application
quick tip: persistent query string parameters
Thu, Aug 22nd 2013 8:00p Tim Tripcony Here's a handy bit of code to drop into the afterPageLoad event of your XPages:
One of the best characteristics of XPage applications, in contrast to their non-XPage Domino counterparts, is their statefulness. The capacity to maintain consistency of data, user behavior, and user preferences between interactions with the "current" page, across pages within an individual user session, and even across all (or select groups of) users of an application is sim [read] Keywords: domino