|Latest 7 Posts
| "Do I Need to Learn Java?": a brief conversation with a composite character|
Wed, Mar 26th 2014 180
| workaround for severe screen sharing bug in Mavericks|
Tue, Feb 4th 2014 97
| the more essential it is, the less passionate we are|
Sun, Feb 2nd 2014 82
Sun, Feb 2nd 2014 77
| Beyond Documents, part 2: a futuristic example|
Wed, Dec 18th 2013 80
| an easy way to give Domino Designer a ridiculous performance boost|
Wed, Dec 4th 2013 71
| they told me I could be anything|
Sat, Oct 26th 2013 93
Sorry, no records were found!
||XPages Portable Command Guide is a book every Domino administrator should read
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.
Feb 27, 2012
Sorry, no records were found!
| Recent Blog Posts