A Beard, An App, A Blender

Editor's Notes

• #20: The advantages sell themselves. As for disadvantages, if anyone believes it’s more time consuming to approach a proper layout to an application when it’s being initially constructed or in its infancy, there is virtually no cost. Converting takes time, so lay your foundation well. I used to think that my management would have some difficulty accepting my thoughts and approaches on the higher level side of my application development efforts, but when it came down to it, after running into multiple issues over multiple years with our largest app (which I maintain and continue development on in a few areas), I’ve found that the more I do talk with my management about the larger issues, the more they assume I have any tedium handled. This has taken a few years but has paid dividends; especially when it comes to building trust with my management after several creative solutions following the POODLE + other HTTPS/SSL debacles over the last year or so. In other words, when your management take you seriously when you prefix a thought with “Eric’s crazy talk”, you’ve reached a level of trust; trust cultivated from time and effort spent not just on creating widget X, but also understanding the ramifications of that widget, it’s interactions, and how it will work in a deployed, at scale capacity.
• #21: Focusing on application structure and the flow of data (which is how my head works). There are great other angles to look at an application before/during/after during continuing development, such as user interactions (how many clicks, ease of access), but when it comes to interfacing with data, which is usually my biggest concern, this is what makes sense to me.
• #23: Rango may be in a whole heap of trouble for all his tall tales, but “stay with me now”.
• #24: I’m not the only one talking about app structure. In fact, this is probably one of the most common 2nd or 3rd order themes amongst developers since applications began being developed. Here are some references which have been great additions for the cause in the Domino / XPages world.
• #26: Domino/XPages SSJS is a weird beast, only supports up through ECMAScript 4, and while you can specify a variable’s type (using colon notation), it’s not the norm for most people. Also, if you’re going to specify type for each variable, what’s the big complaint about Java? “No runtime exceptions” = shouldn’t be likely, if ever. If only we could deal with a native API that doesn’t throw NotesExceptions for about everything. Eclipse “does java well” in the sense that the content assistance and overall Java editor experience is an excellent standard.
• #27: Some have avoided Java in XPages because Java is “scary”. While some may seem daunted, it’s not that hard for a developer to pick up, has been around long enough to be a mature language, performs
• #28: As my data service diagram depicts, there are options. Finding the needs of an application, connections and integrations with other systems and points of entry, so to speak, can help drive our direction.
• #29: Note: some of these require a change in the java.pol(icy) file for security permissions. Non-obvious things: GSON lets you reflect data from JSON to a proper Java Object (by its class definition) in addition to a convenient toJson method; it sure beats the snot out of typing out the lines for creating a new object, create new property (by type), then setting the value, etc. Swiper eliminates a lot of the “bloat” of syncing with an On Disk Project (ODP) and is what allowed me to take our largest app to its first, prototype stage of build automation using headless DDE (was previously generating too many conflicting design elements, making the app non-usable OoB).
• #34: What I chose and why, along with other options.
• #42: My quest isn’t over, as I’m learning something new every day.